Desarrollo e despliegue de dependencias inter-almacenes

En este artículo, aprenderá a modelar e implementar dependencias entre almacenes mediante proyectos de base de datos SQL en Visual Studio Code. Empiezas desde dos proyectos de almacén existentes y configuras dependencias unidireccionales entre ellos usando referencias de bases de datos.

Este artículo se basa en los conceptos de Desarrollo de proyectos de almacenamiento en Visual Studio Code y supone que ya está familiarizado con la creación y publicación de un único proyecto de almacenamiento.

Prerrequisitos

Antes de empezar, asegúrese de que:

• Cree dos almacenes de tejido en la misma área de trabajo.
  • Para crear un almacén de ejemplo, consulte Crear un almacén de ejemplo en Microsoft Fabric.
• Cree o extraiga un proyecto de base de datos para cada almacén en Visual Studio Code.
  • Para crear un proyecto de base de datos para el almacenamiento existente o un nuevo almacén, consulte Proyectos de almacenamiento de desarrollo en Visual Studio Code.
• Instale Visual Studio Code en la estación de trabajo.
• Instale el SDK .NET para compilar y publicar proyectos de base de datos.
• Instale dos extensiones de Visual Studio Code: SQL Database Projects y SQL Server (mssql).
  • Puede instalar las extensiones necesarias directamente desde Visual Studio Code Marketplace si busca "Proyectos de SQL Database" o "SQL Server (mssql)".
• Los proyectos de almacenamiento validan, compilan y se pueden publicar en Visual Studio Code.

Escenario: Almacenamientos entre dominios de Zava Analytics

Zava Analytics usa dos dominios empresariales:

• Ventas : pedidos de clientes, ingresos y métricas de canalización.
• Marketing : campañas, canales y métricas de involucración.

Cada dominio tiene:

• Un almacén de tejido en la misma área de trabajo:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Un proyecto database en Visual Studio Code:

  • Zava.Sales.Warehouse
  • Zava.Marketing.Warehouse

Para construir procesos ELT e informes integrales, cada dominio necesita vistas de solo lectura para acceder a los datos del otro dominio.

• Sales necesita compromiso de marketing por parte del cliente.
• Marketing necesita rendimiento de ventas por campaña.

Necesitas:

• Establecer dependencias unidireccionales entre almacenes a través de referencias de base de datos.
• Evite las dependencias cíclicas.

Asegurarse de que las dependencias entre almacenes son unidireccionales

Para cada par de almacenes, elija una dirección para la dependencia lógica:

Ejemplo:

• Sales depende de Marketing para los datos de interacción.
• Marketing no depende de Sales para ninguno de los objetos necesarios al implementar.

En la práctica:

Zava.Sales.Warehouse tiene una referencia de base de datos a Zava.Marketing.Warehouse.

• T-SQL en el Sales almacén de datos puede usar nombres en tres partes como:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse no hace referencia a Sales objetos que provocarían un ciclo de dependencias en el momento de la implementación.

Evitar dependencias cíclicas

Una dependencia cíclica se produce cuando el almacén A y el almacén B dependen entre sí de una manera que el motor no puede resolver en una sola implementación.

Ejemplo de problema (no hagas esto):

• ZavaSalesWarehouse.dbo.CustomerRollup vista:

  CREATE VIEW dbo.CustomerRollup AS
  SELECT  c.CustomerId,
          c.TotalRevenue,
          m.LastCampaignId
  FROM    dbo.CustomerRevenue AS c
  LEFT OUTER JOIN   
          ZavaMarketingWarehouse.dbo.CustomerEngagement AS m
          ON c.CustomerId = m.CustomerId;
  

• ZavaMarketingWarehouse.dbo.CampaignAttribution vista:

  CREATE VIEW dbo.CampaignAttribution AS
  SELECT  m.CampaignId,
          SUM(s.TotalRevenue) AS RevenueAttributed
  FROM    dbo.Campaigns AS m
  LEFT OUTER JOIN    
          ZavaSalesWarehouse.dbo.CustomerRollup AS s
          ON m.CampaignId = s.LastCampaignId
  GROUP BY m.CampaignId;
  

En este antipatrón:

• CustomerRollup en Ventas depende de CustomerEngagement en Marketing.
• CampaignAttribution en Marketing depende de CustomerRollup en Ventas.

Este antipatrón crea un ciclo: la vista de Ventas → la vista de Marketing → la vista de Ventas de nuevo.

Guía:

No modele las dependencias mutuas entre almacenes como objetos de nivel de esquema normales. Si realmente necesitas este tipo de lógica, mueve un lado de la dependencia a un modelo semántico o informe posterior que una los dos almacenes en el momento de la consulta.

Referencias directas entre almacenes mediante referencias de base de datos

En este patrón, modela las dependencias unidireccionales directamente en los proyectos de base de datos mediante referencias de base de datos.

Paso 1: Empezar a partir de dos proyectos de almacenamiento existentes

Ya debería tener:

• Zava.Sales.Warehouse → implementado en ZavaSalesWarehouse
• Zava.Marketing.Warehouse → implementado en ZavaMarketingWarehouse

Cada proyecto se creó o extrajo siguiendo los pasos descritos en Proyectos de almacenamiento de desarrollo en Visual Studio Code.

Paso 2: Agregar una referencia de base de datos de Ventas a Marketing

• En Visual Studio Code, abra la vista Database Projects.
• Haga clic con el botón derecho en el Zava.Sales.Warehouse proyecto.
• Seleccione Agregar referencia de base de datos....
• Elija una de las siguientes opciones:
  • proyecto Database en el área de trabajo actual (un proyecto de base de datos al que se hace referencia de esta manera también debe estar abierto en Visual Studio Code) o
  • Aplicación de capa de datos (.dacpac) ( se asume que ha sido creada si ya tiene una .dacpac para el Marketing almacenamiento).
• Establezca las opciones de referencia:
  • Tipo de referencia: Mismo servidor, base de datos diferente.
  • Nombre o variable de la base de datos: Use una variable SQLCMD, por ejemplo [$(MarketingWarehouseName)].
• Guarde y recompile el proyecto Sales.

En el .sqlproj archivo, debería ver una entrada similar a la siguiente:

<ItemGroup>
  <ArtifactReference Include="..\Zava.Marketing.Warehouse\bin\Debug\Zava.Marketing.Warehouse.dacpac">
    <DatabaseVariableLiteralValue>$(MarketingWarehouseName)</DatabaseVariableLiteralValue>
  </ArtifactReference>
</ItemGroup>
<ItemGroup>
  <SqlCmdVariable Include="MarketingWarehouseName">
    <DefaultValue>ZavaMarketingWarehouse</DefaultValue>
  </SqlCmdVariable>
</ItemGroup>

Paso 3: Crear una vista interalmacenes en la sección de Ventas

En el proyecto Sales, agregue una vista que lea del almacén Marketing.

-- schema/Views/dbo.CustomerEngagementFact.sql
CREATE VIEW [dbo].[CustomerEngagementFact] AS
SELECT
    s.CustomerId,
    s.TotalRevenue,
    m.LatestChannel,
    m.LastEngagementDate
FROM dbo.CustomerRevenue AS s
JOIN [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] AS m
    ON s.CustomerId = m.CustomerId;

Puntos clave:

• El nombre [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] de tres partes coincide con el patrón T-SQL que se usa para las consultas entre almacenes en el editor de Fabric SQL.
• DacFx resuelve la base de datos externa a través de la referencia de la base de datos.

Construir el proyecto para asegurarse de que no haya errores de referencia sin resolver SQL71501.

Paso 4: Publicar el almacén de marketing y luego el de Ventas

Para evitar problemas de implementación:

• Compilación y publicaciónZava.Marketing.Warehouse Primero:
  • Haga clic con el botón derecho en proyecto → Compilar.
  • Haga clic con el botón derecho en el proyecto → Publicar → elija ZavaMarketingWarehouse.
• Una vez Marketing que la implementación se realiza correctamente, compile y publiqueZava.Sales.Warehouse:
  • Haga clic con el botón derecho en proyecto → Compilar.
  • Haga clic con el botón derecho en el proyecto → Publicar → elija ZavaSalesWarehouse.

El flujo de implementación resultante es:

Zava.Marketing.Warehouse (sin dependencias externas) → Zava.Sales.Warehouse (depende de Marketing)

Ahora, cualquier consulta de T-SQL en ZavaSalesWarehouse puede usar la vista dbo.CustomerEngagementFact, que lee internamente del almacén Marketing mediante T-SQL entre almacenes.

Sigue aprendiendo

• Combina este patrón con control de versiones y orientación CI/CD en Desarrollo y despliegue y documentación de integración Fabric git.
• Amplíe el escenario de Zava Analytics para incluir entornos de desarrollo, pruebas y producción, mediante canalizaciones de implementación o CI/CD externos para orquestar el orden de publicación en varios almacenes.

Contenido relacionado

• Flujos de trabajo de desarrollo e implementación