Desenvolver e implantar dependências entre armazéns

Neste artigo, você aprenderá a modelar e implantar dependências entre armazéns usando projetos de banco de dados SQL no Visual Studio Code. Você começa a partir de dois projetos de warehouse existentes e configura dependências unilaterais entre eles usando referências de banco de dados.

Este artigo baseia-se nos conceitos em projetos de Develop warehouse no Visual Studio Code e pressupõe que você já esteja confortável criando e publicando um único projeto de armazém.

Pré-requisitos

Antes de começar, certifique-se de:

• Crie dois Fabric Warehouses na mesma área de trabalho.
  • Para criar um novo warehouse de exemplo, consulte Criar um warehouse de exemplo em Microsoft Fabric.
• Crie ou extraia um projeto database para cada armazém em Visual Studio Code.
  • Para criar um projeto de banco de dados para seu armazém existente ou um novo armazém, consulte Desenvolver projetos de armazém no Visual Studio Code.
• Instale Visual Studio Code em sua estação de trabalho.
• Instale o SDK .NET para criar e publicar projetos de banco de dados.
• Instale duas extensões de Visual Studio Code: SQL Database Projects e SQL Server (mssql).
  • Você pode instalar as extensões necessárias diretamente de dentro do marketplace Visual Studio Code pesquisando "Projetos do Banco de Dados SQL" ou "SQL Server (mssql)".
• Os projetos do warehouse validam, criam e podem ser publicados no Visual Studio Code.

Cenário: armazéns interdomínios do Zava Analytics

O Zava Analytics usa dois domínios de negócios:

• Vendas – pedidos de clientes, receita e métricas de pipeline.
• Marketing – campanhas, canais e métricas de engajamento.

Cada domínio tem:

• Um Fabric Warehouse no mesmo ambiente de trabalho:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Um projeto database em Visual Studio Code:

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

Para criar ELT e relatórios de ponta a ponta, cada domínio precisa de visões somente leitura para acessar dados do outro domínio.

• Sales precisa de engajamento de marketing por parte do cliente.
• Marketing precisa do desempenho de vendas por campanha.

Você precisa:

• Estabeleça dependências unidirecionais entre armazéns por meio de referências de banco de dados.
• Evite dependências cíclicas.

Verifique se as dependências entre os armazéns são unidirecionais

Para cada par de armazéns, escolha uma direção para dependência lógica:

Exemplo:

• Sales depende dos dados de engajamento de Marketing.
• Marketing não depende de Sales para nenhum objeto necessário no momento da implantação.

Na prática:

Zava.Sales.Warehouse tem uma referência de banco de dados para Zava.Marketing.Warehouse.

• O T-SQL no Sales warehouse pode usar nomes de três partes como:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse não faz referência Sales a objetos que forçariam um ciclo de dependência no momento da implantação.

Evitar dependências cíclicas

Uma dependência cíclica acontece quando o Warehouse A e o Warehouse B dependem um do outro de uma maneira que o mecanismo não pode resolver em uma única implantação.

Exemplo de problema (não faça isso):

• 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;
  

Neste antipadrão:

• CustomerRollup em Vendas depende do CustomerEngagementMarketing.
• CampaignAttribution em Marketing depende de CustomerRollupVendas.

Esse antipadrão cria um ciclo: exibição de vendas → exibição de marketing → exibição de vendas novamente.

Diretrizes:

Não modele dependências mútuas entre armazéns como objetos regulares no nível do esquema. Se você realmente precisar desse tipo de lógica, mova um lado da dependência para um modelo semântico ou relatório posterior que une os dois warehouses no momento da consulta.

Referências diretas entre entrepôns via referência de banco de dados

Nesse padrão, você modela dependências unidirecionais diretamente nos projetos de banco de dados usando referências de banco de dados.

Etapa 1: Iniciar a partir de dois projetos de armazém existentes

Você já deve ter:

• Zava.Sales.Warehouse → implantado em ZavaSalesWarehouse
• Zava.Marketing.Warehouse → implantado em ZavaMarketingWarehouse

Cada projeto foi criado ou extraído usando as etapas em Desenvolver projetos de warehouse no Visual Studio Code.

Etapa 2: Adicionar uma referência de banco de dados de Vendas ao Marketing

• Em Visual Studio Code, abra a exibição Database Projects.
• Clique com o botão direito do mouse no Zava.Sales.Warehouse projeto.
• Selecione Adicionar Referência de Banco de Dados....
• Escolha um dos seguintes:
  • Database project no espaço de trabalho atual (um projeto de banco de dados que é referenciado dessa maneira também deve estar aberto no Visual Studio Code) ou
  • Aplicativo de Camada de Dados (.dacpac) (presumindo que você já tenha construído um .dacpac para o Marketing armazém de dados).
• Defina as opções de referência:
  • Tipo de referência: Mesmo servidor, banco de dados diferente.
  • Nome ou variável do banco de dados: Use uma variável SQLCMD, por exemplo [$(MarketingWarehouseName)].
• Salve e recompile o projeto Vendas.

.sqlproj No arquivo, você deverá ver uma entrada semelhante a:

<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>

Etapa 3: Criar uma exibição entre armazéns em Vendas

No projeto Sales, adicione uma visualização que leia do armazém de dados 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;

Pontos principais:

• O nome [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] de três partes corresponde ao padrão T-SQL usado para consultas entre armazéns no editor de SQL do Fabric.
• O DacFx resolve o banco de dados externo por meio da referência do banco de dados.

Crie o projeto para garantir que não haja erros de referência não resolvidos SQL71501 .

Etapa 4: Publicar o armazém de marketing e, em seguida, Vendas

Para evitar problemas de implantação:

• Compilar e publicarZava.Marketing.Warehouse primeiro:
  • Clique com o botão direito do mouse no projeto → Build.
  • Clique com o botão direito do mouse no projeto → Publicar → escolha ZavaMarketingWarehouse.
• Depois que Marketing a implantação for bem-sucedida, crie e publiqueZava.Sales.Warehouse:
  • Clique com o botão direito do mouse no projeto → Build.
  • Clique com o botão direito do mouse no projeto → Publicar → escolha ZavaSalesWarehouse.

O fluxo de implantação resultante é:

Zava.Marketing.Warehouse (nenhuma dependência externa) → Zava.Sales.Warehouse (depende de Marketing)

Agora, qualquer consulta T-SQL em ZavaSalesWarehouse pode usar a visão dbo.CustomerEngagementFact, que lê internamente do data warehouse Marketing usando T-SQL entre data warehouses.

Continue aprendendo

• Combine esse padrão com controle de versão e orientação CI/CD em Desenvolvimento e implantação e documentação de integração Fabric git.
• Estenda o cenário do Zava Analytics para incluir ambientes Dev/Test/Prod, usando pipelines de implantação ou CI/CD externo para orquestrar a ordem de publicação em vários data warehouses.

Conteúdo relacionado

• Fluxos de trabalho de desenvolvimento e implantação