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ê inicia a partir de dois projetos de warehouse existentes e configura dependências unidirecionais entre eles usando referências de banco de dados e, quando necessário, scripts de pré-implantação e pós-implantação.

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.
• Use scripts de pré e pós-implantação para casos em que os objetos em ambos os armazéns dependem entre si.

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 script pós-implantação ou
• Um modelo semântico downstream ou um relatório que combina os dados dos dois armazéns no momento da consulta.

Usar scripts de pré e pós-implantação para lógica crítica entre data warehouses durante a implantação

Como as implantações de warehouse são operações de diferenciação de esquema completas (não implantações parciais por objeto), trate os itens entre armazéns com cuidado:

Se o Warehouse A e o Warehouse B precisarem de objetos que dependam um do outro:

• Mantenha as tabelas centrais e as visões centrais em cada projeto de armazém.
• Mova visões de ponte ou objetos utilitários que criam ciclos para scripts pré- ou pós-implantação dentro de um projeto.
• Verifique se esses scripts são idempotentes e seguros para serem executados novamente.

Padrões de exemplo:

• Script de pré-implantação: remova temporariamente uma exibição inter-armazéns antes de aplicar alterações de esquema que poderiam interrompê-la.
• Script pós-implantação: recrie ou atualize a visualização cruzada entre armazéns depois que ambos os armazéns sejam implantados.

Padrão 1: referências diretas entre armazéns por meio de referências 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.

Padrão 2: dependências entre armazéns gerenciadas por meio de scripts pré e pós-implantação

Em alguns cenários do Zava Analytics, ambos os domínios podem precisar de objetos agregados que dependam uns dos outros. Por exemplo:

• A equipe de vendas quer uma exibição que use dados de campanha de marketing para fornecer receita de vendas por campanha de marketing.
• O marketing quer uma visualização que use dados de receita de vendas para analisar a eficiência das campanhas de marketing.

Você não quer que ambos os objetos sejam visões regulares que participem da implantação total do modelo, pois há o risco de uma dependência cíclica ou de uma ordenação de implantação frágil.

Em vez disso, você:

• Mantenha o modelo principal de cada armazém independente.
• Use scripts pós-implantação em um projeto para criar mais visões entre armazéns de dados depois que ambos os esquemas estiverem configurados.

Etapa 1: Adicionar referências de banco de dados para validação em tempo de compilação

Configure referências semelhantes ao Padrão 1, mas para ambos os projetos:

• No Zava.Sales.Warehouse, adicione uma referência ao Marketing via [$(MarketingWarehouseName)].
• Em Zava.Marketing.Warehouse, opcionalmente, adicione uma referência a Vendas por meio de [$(SalesWarehouseName)] se você quiser validação em tempo de compilação de exibições entre armazéns usadas em scripts.

Nos arquivos .sqlproj, você pode configurar:

<SqlCmdVariable Include="SalesWarehouseName">
  <DefaultValue>ZavaSalesWarehouse</DefaultValue>
</SqlCmdVariable>

Etapa 2: Criar objetos principais como objetos de projeto regulares

Exemplo:

• Sales projeto:

  • dbo.CustomerRevenue tabela
  • dbo.SalesByCampaign exibição (usando apenas tabelas locais)

• Marketing projeto:

  • Tabela dbo.Campaigns
  • dbo.CampaignStats exibição (usando apenas tabelas locais)

Esses objetos não usam consultas entre data warehouses. Na próxima etapa, apresentaremos referências inter-armazéns.

Etapa 3: Adicionar um script pós-implantação para visões de interconexão entre armazéns

Escolha um armazém para hospedar objetos de ponte; normalmente, o domínio que consome mais fortemente a saída combinada. Suponha Sales que seja esse domínio.

• Sales No projeto: clique com o botão direito do mouse no projeto e Adicionar → Script Pós-Implantação.
• Nomeie o script PostDeployment_CrossWarehouse.sql.
• No script, crie ou altere as exibições entre armazéns usando IF EXISTS / DROP / CREATE padrões para mantê-las idempotentes.

Exemplo de um script em Sales que fará referência a objetos no warehouse Marketing.

-- PostDeployment_CrossWarehouse.sql

-- Ensure object can be recreated safely
IF OBJECT_ID('dbo.CampaignRevenueBridge', 'V') IS NOT NULL
    DROP VIEW [dbo].[CampaignRevenueBridge];
GO

CREATE VIEW [dbo].[CampaignRevenueBridge] AS
SELECT
    c.CampaignId,
    c.CampaignName,
    m.Channel,
    SUM(s.TotalRevenue) AS Revenue
FROM [$(MarketingWarehouseName)].[dbo].[Campaigns] AS c
JOIN [$(MarketingWarehouseName)].[dbo].[CampaignEngagement] AS m
    ON c.CampaignId = m.CampaignId
JOIN dbo.SalesByCampaign AS s
    ON s.CampaignId = c.CampaignId
GROUP BY
    c.CampaignId,
    c.CampaignName,
    m.Channel;
GO

Aqui:

• Os projetos principais Sales e Marketing de armazém permanecem independentes e implantáveis sozinhos.
• A exibição de ponte é criada após a implantação do esquema por meio de script pós-implantação.
• Se a implantação for executada várias vezes, ela será idempotente, pois o script remove e recria a exibição com segurança.

Etapa 4: (Opcional) Usar scripts de pré-implantação para proteger dependências frágeis

Em cenários mais avançados, você pode:

• Use um script de pré-implantação para remover ou desabilitar visualizações entre data warehouses que possam bloquear alterações de esquema (por exemplo, se você estiver renomeando colunas).
• Deixe o DacFx aplicar a diferença de esquema.
• Use o script pós-implantação para recriar ou atualizar as exibições entre armazéns.

Etapa 5: Publicar ordem para dependências gerenciadas por script

Um padrão comum para o Zava Analytics:

• Publicar projetos base:
  • Zava.Marketing.Warehouse (esquema principal)
  • Zava.Sales.Warehouse (esquema principal + script pós-implantação entre armazéns)
• Permita que o script de pós-implantação de Vendas crie as exibições da ponte depois que seu próprio esquema e o esquema referenciado Marketing forem implantados.

Se você introduzir mais de dois armazéns, repita esse padrão em camadas. Nunca crie dependências cíclicas por meio de objetos de projeto comuns.

Continue aprendendo

• Combine esses padrões com controle de origem e orientações de CI/CD nos documentos sobre controle de origem do Fabric Data Warehouse e integração do Git Fabric.
• 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