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 Desenvolver projetos de warehouse no Visual Studio Code e pressupõe que você já esteja confortável criando e publicando um único projeto de warehouse.

Pré-requisitos

Antes de começar, certifique-se de:

• Crie dois Fabric Warehouses na mesma área de trabalho.
  • Para criar um novo armazém de exemplo, consulte Criar um warehouse de exemplo no Microsoft Fabric.
• Crie ou extraia um projeto de banco de dados para cada warehouse no 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 warehouse no Visual Studio Code.
• Instale o Visual Studio Code em sua estação de trabalho.
• Instale o SDK do .NET para criar e publicar projetos de banco de dados.
• Instale duas extensões do Visual Studio Code: Projetos do Banco de Dados SQL e SQL Server (mssql).
  • Você pode instalar as extensões necessárias diretamente no Marketplace do 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.

Observação

Este artigo se concentra em projetos de warehouse no Visual Studio Code e em como você os versão no Git como projetos de código regulares. A integração do Git do Fabric para workspaces e itens de warehouse é tratada separadamente, nos documentos Controle do Código-Fonte com o Fabric Data Warehouse e nos documentos de integração do Git. O artigo pressupõe que seu workspace do Fabric é o alvo de implantação e que o esquema T-SQL está em um ou mais projetos do Visual Studio Code controlados por versão no Git.

Este artigo não aborda o desenvolvimento inter-warehouse para o endpoint de análises SQL de um Lakehouse. As tabelas do Lakehouse e os objetos de endpoint SQL não são rastreados no controle de versão da mesma forma que os projetos de data warehouse são. Use itens do Warehouse com projetos de banco de dados para suporte completo de integração e implantação do Git em experiências nativas do Fabric e ferramentas de cliente.

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 de banco de dados no 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.

Dica

Para cada par de armazéns, desenhe um diagrama de seta simples (Sales → Marketing). Se você encontrar setas apontando em ambas as direções para o mesmo tipo de objeto, provavelmente precisará refatorar ou mover alguma lógica para scripts pré e pós-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

• No Visual Studio Code, abra o modo de exibição Projetos de Banco de Dados .
• 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:
  • O projeto de banco de dados no workspace atual (um projeto de banco de dados referenciado dessa forma 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>

Dica

Usar uma variável SQLCMD para o nome do armazém remoto permite reutilizar o mesmo projeto em todos os seus ambientes, como Desenvolvimento/Teste/Prod, em que os nomes do warehouse podem ser diferentes.

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:

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

• Marketing projeto:

  • Tabela do 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.

Importante

Os scripts pré e pós-implantação são executados como parte do plano de implantação e devem ser:

• Idempotente, ou seja, pode ser executado várias vezes com segurança.
• Compatível com o esquema final produzido pelo DacFx.
• Livre de alterações destrutivas que conflitam com sua BlockOnPossibleDataLoss política.

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 do código-fonte e diretrizes de CI/CD nos documentos de controle do código-fonte com Fabric Data Warehouse e integração do git do 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