Utveckla och implementera beroenden mellan lager

I den här artikeln får du lära dig hur du modellerar och distribuerar beroenden mellan lager med hjälp av SQL-databasprojekt i Visual Studio Code. Du börjar från två befintliga lagerprojekt och konfigurerar enkelriktade beroenden mellan dem med hjälp av databasreferenser och, vid behov, fördistribution och efterdistributionsskript.

Den här artikeln bygger på begreppen i Utveckla lagerprojekt i Visual Studio Code och förutsätter att du redan är bekväm med att skapa och publicera ett enda lagerprojekt.

Förutsättningar

Innan du börjar kontrollerar du att:

• Skapa två Fabric-lagerhus i samma arbetsyta.
  • Information om hur du skapar ett nytt exempellager finns i Skapa ett exempellager i Microsoft Fabric.
• Skapa eller extrahera ett database-projekt för varje lager i Visual Studio Code.
  • Information om hur du skapar ett databasprojekt för ditt befintliga lager eller ett nytt lager finns i Utveckla lagerprojekt i Visual Studio Code.
• Installera Visual Studio Code på din arbetsstation.
• Installera .NET SDK för att skapa och publicera databasprojekt.
• Installera två Visual Studio Code tillägg: SQL Database Projects och SQL Server (mssql).
  • Du kan installera nödvändiga tillägg direkt från Visual Studio Code Marketplace genom att söka efter "SQL Database Projects" eller "SQL Server (mssql)".
• Lagerprojekten validerar, skapar och kan publiceras i Visual Studio Code.

Scenario: Zava Analytics-lager för flera domäner

Zava Analytics använder två affärsdomäner:

• Försäljning – kundorder, intäkter och pipelinemått.
• Marknadsföring – kampanjer, kanaler och engagemangsmått.

Varje domän har:

• Ett fabriclager i samma arbetsyta:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Ett database-projekt i Visual Studio Code:

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

För att bygga fullständiga ELT- och rapporteringslösningar behöver varje domän skrivskyddade vyer för att komma åt data från den andra domänen:

• Sales behöver marknadsföringsengagemang av kunden.
• Marketing har behov av försäljningsresultat per kampanj.

Du måste:

• Upprätta envägsberoenden mellan olika lager via databasreferenser .
• Undvik cykliska beroenden.

Se till att beroenden mellan lager är enkelriktade

För varje lagerpar väljer du en riktning för logiskt beroende:

Exempel:

• Sales är beroende av Marketing för engagemangsdata.
• Marketing är inte beroende Sales av för objekt som behövs vid distributionstillfället.

I praktiken:

Zava.Sales.Warehouse har en databasreferens till Zava.Marketing.Warehouse.

• T-SQL i Sales lagret kan använda tredelade namn som:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse refererar inte till Sales objekt som skulle tvinga fram en beroendecykel vid distributionstillfället.

Undvik cykliska beroenden

Ett cykliskt beroende inträffar när både lager A och lager B är beroende av varandra på ett sätt som motorn inte kan lösa i en enda distribution.

Problemexempel (gör inte detta):

• ZavaSalesWarehouse.dbo.CustomerRollup utsikt:

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

  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;
  

I det här antimönstret:

• CustomerRollup i Försäljning beror på CustomerEngagement i Marknadsföring.
• CampaignAttribution i Marknadsföring beror på CustomerRollup i Försäljning.

Det här antimönstret skapar en cykel: Försäljningsvyn → marknadsföringsvyn → försäljningsvyn igen.

Riktlinjer:

Modellera inte ömsesidiga beroenden mellan lager som vanliga objekt på schemanivå. Om du verkligen behöver den här typen av logik flyttar du ena sidan av beroendet till:

• Ett skript efter distributionen, eller
• En nedströms semantisk modell eller rapport som ansluter till de två lagerställena vid frågetillfället.

Använd skript före och efter driftsättning för distributionskänslig logik mellan datalager

Eftersom distributioner av lager är fullständiga schema-diff-åtgärder (inte partiella distributioner per objekt) bör du noggrant behandla objekt mellan lager:

Om lager A och lager B båda behöver objekt som är beroende av varandra:

• Behåll kärntabellerna och kärnvyerna i varje lagerprojekt.
• Flytta brovyer eller hjälpobjekt som skapar cykler till för- eller efter-distributionsskript inom ett projekt.
• Se till att skripten är idempotenta och säkra att köra igen.

Exempelmönster:

• Skript före distribution: Ta tillfälligt bort en vy över flera lager innan du tillämpar schemaändringar som skulle bryta den.
• Skript efter distribution: återskapa eller uppdatera vyn mellan lager efter att båda lagerställena har distribuerats.

Mer information och exempel finns i Skript före distribution och efter distribution för Fabric Data Warehouse.

Mönster 1: Direkta referenser mellan lager via databasreferenser

I detta mönster modellerar du envägsberoenden direkt i databasprojekten genom att använda Database References.

Steg 1: Börja från två befintliga lagerprojekt

Du bör redan ha:

• Zava.Sales.Warehouse → distribueras till ZavaSalesWarehouse
• Zava.Marketing.Warehouse → distribueras till ZavaMarketingWarehouse

Skapa eller extrahera varje projekt genom att använda stegen i Utveckla lagerprojekt i Visual Studio Code.

Steg 2: Lägg till en databasreferens från Försäljning till Marknadsföring

• I Visual Studio Code öppnar du vyn Database Projects.
• Högerklicka på Zava.Sales.Warehouse projektet.
• Välj Lägg till databasreferens....
• Välj något av följande alternativ:
  • Databasprojekt i nuvarande arbetsyta (öppna även det refererade databasprojektet i Visual Studio Code), eller
  • Program på datanivå (.dacpac) (använd det här alternativet om du har skapat en .dacpac för Marketing-lagret).
• Ange referensalternativen:
  • Referenstyp: Samma server, en annan databas.
  • Databasnamn eller variabel: Använd en SQLCMD-variabel, till exempel [$(MarketingWarehouseName)].
• Spara och kompilera om säljprojektet.

.sqlproj I filen bör du se en post som liknar:

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

Steg 3: Skapa en vy över flera lager i Försäljning

Sales I projektet lägger du till en vy som läser från Marketing lagret:

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

Viktiga punkter:

• Namnet i tre delar [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] matchar T-SQL-mönstret som används för frågor över lager i Fabric SQL-redigeraren.
• DacFx identifierar den externa databasen genom databasreferensen.

Skapa projektet för att säkerställa att det inte finns några SQL71501 olösta referensfel .

Steg 4: Publicera marknadsföringsdatavarulagret, följt av försäljning

Så här undviker du distributionsproblem:

• Skapa och publiceraZava.Marketing.Warehouse första:
  • Högerklicka på projekt → Build.
  • Högerklicka på projektet → Publicera → välj ZavaMarketingWarehouse.
• När Marketing distributionen är klar skapar och publicerarZava.Sales.Warehouse du:
  • Högerklicka på projekt → Build.
  • Högerklicka på projektet → Publicera → välj ZavaSalesWarehouse.

Det resulterande distributionsflödet är:

Zava.Marketing.Warehouse (inga externa beroenden) → Zava.Sales.Warehouse (beror på Marketing)

Nu kan vilken T-SQL-fråga som helst i ZavaSalesWarehouse använda dbo.CustomerEngagementFact-vyn, som internt läser från Marketing-lagret med hjälp av T-SQL för korslager.

Fortsätt lära dig

• Kombinera detta mönster med versionskontroll och CI/CD-vägledning i utveckling och distribution samt dokumentation för Fabric-git-integration.
• Utöka Zava Analytics-scenariot till att omfatta Dev/Test/Prod-miljöer med hjälp av distributionspipelines eller extern CI/CD för att samordna publiceringsordningen i flera lager.

Relaterat innehåll

• Arbetsflöden för utveckling och distribution