Desenvolver e implementar dependências inter-armazém

Neste artigo, aprende a modelar e implementar dependências cross-warehouse usando projetos de bases de dados SQL no Visual Studio Code. Começa-se a partir de dois projetos de armazém existentes e configura-se dependências unidirecionais entre eles usando referências à base de dados e, quando necessário, scripts de pré-implementação e pós-implementação.

Este artigo baseia-se nos conceitos dos projetos de armazém Develop em Visual Studio Code e parte do princípio de que já se sente confortável em construir e publicar um único projeto de armazém.

Pré-requisitos

Antes de começar, certifique-se de que:

• Cria dois Armazéns de Tecidos no mesmo espaço de trabalho.
  • Para criar um novo depósito de exemplo, consulte Criar um depósito de exemplo no Microsoft Fabric.
• Crie ou extraia um projeto de base de dados para cada warehouse no Visual Studio Code.
  • Para criar um projeto de base de dados para o seu armazém existente ou para um novo armazém, consulte Desenvolver projetos de armazém em 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 de código do Visual Studio: Projetos de Banco de Dados SQL e SQL Server (mssql).
  • Você pode instalar as extensões necessárias diretamente de dentro do Visual Studio Code marketplace pesquisando por "Projetos de Banco de Dados SQL" ou "SQL Server (mssql)".
• Os projetos de armazém validam, constroem e podem ser publicados em Visual Studio Code.

Cenário: Armazéns interdomínio do Zava Analytics

O Zava Analytics utiliza dois domínios de negócio:

• Vendas – encomendas de clientes, receitas e métricas do pipeline.
• Marketing – campanhas, canais e métricas de envolvimento.

Cada domínio tem:

• Um Armazém de Tecidos no mesmo espaço de trabalho:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Um projeto de base de dados em Visual Studio Code:

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

Para construir ELT e relatórios de ponta a ponta, cada domínio necessita de vistas apenas de leitura para aceder a dados do outro domínio:

• Sales Precisa de envolvimento de marketing por parte do cliente.
• Marketing Precisa de desempenho de vendas por campanha.

Precisa de:

• Estabelecer dependências unidirecionais entre armazéns via referências de bases de dados.
• Evite dependências cíclicas.
• Use scripts de pré-implantação e pós-implantação para casos em que objetos em ambos os armazéns dependam um do outro.

Garantir que as dependências entre armazéns sejam unidirecionais

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

Exemplo:

• Sales depende dos dados de engajamento de Marketing.
• Marketing não depende Sales de quaisquer objetos que sejam necessários no momento da implantação.

Na prática:

Zava.Sales.Warehouse tem uma referência de base de dados a Zava.Marketing.Warehouse.

• O T-SQL no armazém de Sales pode usar nomes com três componentes, 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 implementação.

Evitar dependências cíclicas

Uma dependência cíclica ocorre quando o Armazém A e o Armazém B dependem um do outro de uma forma que o motor não consegue resolver numa única implementação.

Exemplo de problema (não faças isto):

• ZavaSalesWarehouse.dbo.CustomerRollup Veja:

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

  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 anti-padrão:

• CustomerRollup em Vendas depende de CustomerEngagement em Marketing.
• CampaignAttribution em Marketing depende de CustomerRollupVendas.

Este anti-padrão cria um ciclo: visão de vendas → visão de marketing → visão de vendas novamente.

Orientação:

Não modele dependências mútuas entre armazéns como objetos regulares ao nível do esquema. Se realmente precisas deste tipo de lógica, move um lado da dependência para:

• Um script pós-implantação, ou
• Um modelo semântico a jusante ou relatório que une os dois armazéns no momento da consulta.

Use scripts de pré e pós-implantação para lógica crucial ao processo de implementação entre armazéns.

Como as implementações em armazém são operações completas de diferença de esquema (não implementações parciais por objeto), trate cuidadosamente os itens entre armazém:

Se o Armazém A e o Armazém B precisam ambos de objetos que dependem um do outro:

• Mantém as tabelas centrais e as vistas principais em cada projeto de armazém.
• Mover vistas de ponte ou objetos utilitários que criam ciclos em scripts de pré ou pós-implementação num projeto.
• Certifica-te de que esses scripts são idempotentes e seguros para reexecutar.

Exemplos de padrões:

• Script pré-implantação: eliminar temporariamente uma vista entre armazéns antes de aplicar alterações no esquema que a possam incompatibilizar.
• Script pós-implementação: recriar ou atualizar a vista inter-armazéns após a implementação de ambos os armazéns.

Padrão 1: Referências diretas entre armazéns via referências de base de dados

Neste padrão, modelas dependências unidirecionais diretamente nos projetos de base de dados usando Referências de Base de Dados.

Passo 1: Começar a partir de dois projetos de armazém existentes

Já devias ter:

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

Cada projeto foi criado ou extraído usando os passos descritos em Desenvolver projetos de armazém no Visual Studio Code.

Passo 2: Adicionar uma referência da base de dados de Vendas para a de Marketing

• No Visual Studio Code, abra a exibição Projetos de Base de Dados.
• Clique com o botão direito do rato no Zava.Sales.Warehouse projeto.
• Selecionar Adicionar Referência de Base de Dados....
• Escolha um dos:
  • Projeto de base de dados no espaço de trabalho atual (Um projeto de base de dados referenciado desta forma também deve estar aberto no Visual Studio Code), ou
  • Aplicação no nível de dados (.dacpac) (Assume que já concluiu uma compilação .dacpac para o armazém Marketing).
• Defina as opções de referência:
  • Tipo de referência: Mesmo servidor, base de dados diferente.
  • Nome ou variável da base de dados: Use uma variável SQLCMD, por exemplo [$(MarketingWarehouseName)].
• Salve e reconstrua o projeto de Vendas.

No .sqlproj ficheiro, 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>

Passo 3: Criar uma vista inter-armazéns no sistema de Vendas

No projeto Sales, adicione uma visualização que leia do armazém 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] em três partes corresponde ao padrão T-SQL usado para consultas cross-warehouse no editor Fabric SQL.
• O DacFx resolve a base de dados externa através da referência da base de dados.

Construa o projeto para garantir que não há SQL71501 erros de referência não resolvidos .

Passo 4: Publique o armazém de Marketing e depois as Vendas

Para evitar problemas de implantação:

• Construir e publicarZava.Marketing.Warehouse Primeiro:
  • Clique com o botão direito no projeto → Build.
  • Clique com o botão direito do projeto → Publicar → escolher ZavaMarketingWarehouse.
• Quando Marketing a implementação for bem-sucedida, compilar e publicarZava.Sales.Warehouse:
  • Clique com o botão direito no projeto → Build.
  • Clique com o botão direito do projeto → Publicar → escolher ZavaSalesWarehouse.

O fluxo de implementação resultante é:

Zava.Marketing.Warehouse (sem dependências externas) → Zava.Sales.Warehouse (depende de Marketing)

Agora, qualquer consulta T-SQL em ZavaSalesWarehouse pode usar a dbo.CustomerEngagementFact view, que lê do Marketing warehouse internamente usando T-SQL entre armazéns.

Padrão 2: Dependências inter-armazém geridas através de scripts pré e pós-desdobramento

Em alguns cenários de Zava Analytics, ambos os domínios podem precisar de objetos agregados que dependem um do outro. Por exemplo:

• A equipa de vendas quer uma perspetiva que utilize dados de campanhas de marketing para fornecer a receita de vendas por campanha.
• O marketing quer uma perspetiva que utilize dados de receitas de vendas para garantir eficiência nas campanhas de marketing.

Não quer que ambos os objetos sejam visões regulares que participam na implementação completa do modelo, pois isso pode causar uma dependência cíclica ou uma ordem de implementação frágil.

Em vez disso, você:

• Mantenha o modelo central de cada armazém independente.
• Use scripts pós-implementação num projeto para criar mais vistas inter-armazém após a implementação de ambos os esquemas.

Passo 1: Adicionar referências à base de dados para validação em tempo de compilação

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

• Em Zava.Sales.Warehouse, adicione uma referência ao Marketing via [$(MarketingWarehouseName)].
• Em Zava.Marketing.Warehouse, opcionalmente adicione uma referência a Sales através de [$(SalesWarehouseName)] se quiser validação em tempo de compilação das vistas entre armazéns usadas em scripts.

Nos ficheiros .sqlproj, poderá definir:

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

Passo 2: Criar objetos centrais como objetos de projeto normais

Exemplo:

• Sales projeto:

  • Tabela dbo.CustomerRevenue
  • dbo.SalesByCampaign vista (usando apenas tabelas locais)

• Marketing projeto:

  • Tabela dbo.Campaigns
  • dbo.CampaignStats vista (usando apenas tabelas locais)

Estes objetos não utilizam consultas entre-armazéns. No próximo passo, vamos introduzir referências entre armazéns.

Passo 3: Adicionar um script para pós-implementação de vistas de interligação entre armazéns

Escolher um armazém para alojar objetos bridge; tipicamente o domínio que consome mais a saída combinada. Suponha Sales que é esse domínio.

• No Sales projeto: Clique com o botão direito no projeto, depois Adicionar → Script Pós-Implementação.
• Nomeia o script PostDeployment_CrossWarehouse.sql.
• No script, cria ou altera as vistas cross-warehouse usando IF EXISTS / DROP / CREATE padrões para as manter idempotentes.

Exemplo de um script em Sales que vai referenciar Marketing objetos de armazém:

-- 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 mantêm-se independentes e implementáveis por si só.
• A vista da ponte é criada após a implementação do esquema por meio do script pós-implantação.
• Se a implementação for executada várias vezes, é idempotente, pois o script remove e recria a vista com segurança.

Passo 4: (Opcional) Use scripts de pré-implementação para proteger dependências frágeis

Em cenários mais avançados, poderia:

• Use um script pré-implementação para eliminar ou desativar vistas cross-warehouse que possam bloquear alterações de esquema (por exemplo, se estiver a renomear colunas).
• Permita que o DacFx aplique a diferença de esquema.
• Use o script pós-implementação para recriar ou atualizar as vistas inter-armazém.

Passo 5: Publicação do pedido para dependências geridas por scripts

Um padrão comum para o Zava Analytics:

• Publicar projetos base:
  • Zava.Marketing.Warehouse (esquema principal)
  • Zava.Sales.Warehouse (esquema central + script pós-implementação entre armazéns)
• Deixe o script pós-implementação de Sales criar as vistas da ponte depois que o seu próprio esquema e o Marketing esquema referenciado forem implementados.

Caso introduza mais de dois armazéns, repita este padrão em camadas. Nunca crie dependências cíclicas através de objetos de projeto comuns.

Continue a aprender

• Combina estes padrões com controlo de versões e orientação CI/CD nos documentos sobre o controlo de versões com o Data Warehouse do Fabric e documentação de integração git.
• Estenda o cenário do Zava Analytics para incluir ambientes Dev/Test/Prod, usando pipelines de implementação ou CI/CD externo para coordenar a ordem de publicação em vários armazéns.

Conteúdo relacionado

• Fluxos de trabalho de desenvolvimento e implantação