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 envägsberoenden mellan dem genom att använda databasreferenser.

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 denna typ av logik, flytta ena sidan av beroendet till en nedströms semantisk modell eller rapport som kopplar ihop de två lagren vid frågetillfället.

Direkta korslagerreferenser via databasreferenser

I det här mönstret modellerar du enkelriktade beroenden direkt i databasprojekten med hjälp av databasreferenser.

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

Varje projekt skapades eller extraherades med hjälp av 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:
  • Database-projektet på den aktuella arbetsytan (Ett databasprojekt som refereras på det här sättet måste också vara öppet i Visual Studio Code) eller
  • Datanivåprogram (.dacpac) (Förutsätter att du har byggt det om du har byggt ett lager .dacpacMarketing).
• 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 knyter an till den externa databasen via 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