Utvikle og distribuere avhengigheter på tvers av varehus

I denne artikkelen lærer du hvordan du modellerer og distribuerer avhengigheter på tvers av varelager ved å bruke SQL-databaseprosjekter i Visual Studio Code. Du starter fra to eksisterende lagerprosjekter og konfigurerer enveisavhengigheter mellom dem ved å bruke databasereferanser.

Denne artikkelen bygger videre på konseptene i Utvikle lagerprosjekter i Visual Studio Code og forutsetter at du allerede er komfortabel med å bygge og publisere ett enkelt lagerprosjekt.

Forutsetninger

Før du begynner, må du sørge for at du:

• Opprett to Fabric Warehouses i samme arbeidsområde.
  • For å opprette et nytt eksempelvarehus, se Opprett et eksempelvarehus i Microsoft Fabric.
• Lag eller hent ut et databaseprosjekt for hvert lager i Visual Studio Code.
  • For å opprette et databaseprosjekt for ditt eksisterende lager eller et nytt lager, se Utvikle lagerprosjekter i Visual Studio Code.
• Installer Visual Studio Code på arbeidsstasjonen din.
• Installer SDK-en .NET for å bygge og publisere databaseprosjekter.
• Installer to Visual Studio Code utvidelser: SQL Database Projects og SQL Server (mssql).
  • Du kan installere de nødvendige utvidelsene direkte fra Visual Studio Code Marketplace ved å søke på "SQL Database Projects" eller "SQL Server (mssql)".
• Lagerprosjektene validerer, bygger og kan publiseres i Visual Studio Code.

Scenario: Zava Analytics tverrdomenelagre

Zava Analytics bruker to forretningsområder:

• Salg – kundeordrer, inntekter og pipeline-målinger.
• Markedsføring – kampanjer, kanaler og engasjementsmålinger.

Hvert domene har:

• Et tekstillager i samme arbeidsområde:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Et databaseprosjekt i Visual Studio Code:

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

For å bygge ende-til-ende ELT og rapportering, trenger hvert domene skrivebeskyttede visninger for å få tilgang til data fra det andre domenet:

• Sales Trenger markedsføringsengasjement fra kunden.
• Marketing Trenger salgsytelse per kampanje.

Du må:

• Etabler enveis avhengigheter på tvers av varehus via databasereferanser.
• Unngå sykliske avhengigheter.

Sørg for at avhengighetene mellom lagrene er enveiskjørte

For hvert par av lager, velg en retning for logisk avhengighet:

Eksempel:

• Sales Det avhenger av Marketing engasjementsdata.
• Marketing Avhenger ikke av Sales for objekter som trengs ved deployering.

I praksis:

Zava.Sales.Warehouse har en databasereferanse til Zava.Marketing.Warehouse.

• T-SQL i lageret Sales kan bruke tredelte navn som:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse refererer ikke til Sales objekter som ville tvinge frem en avhengighetssyklus ved utrullingstidspunkt.

Unngå sykliske avhengigheter

En syklisk avhengighet oppstår når Lager A og Lager B begge er avhengige av hverandre på en måte som motoren ikke kan løse i én enkelt utrulling.

Problemeksempel (ikke gjør dette):

• 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 dette anti-mønsteret:

• CustomerRollup i salg avhenger av CustomerEngagement i markedsføring.
• CampaignAttribution i markedsføring avhenger CustomerRollup av i salg.

Dette anti-mønsteret skaper en syklus: Salgsperspektiv → Markedsføringsperspektiv → Salgsperspektiv igjen.

Veiledning:

Ikke modellere gjensidige avhengigheter mellom lagre som vanlige skjema-nivåobjekter. Hvis du virkelig trenger denne typen logikk, flytt den ene siden av avhengigheten inn i en nedstrøms semantisk modell eller rapport som kobler de to lagrene sammen ved spørringstidspunktet.

Direkte tverrlagerreferanser via databasereferanser

I dette mønsteret modellerer du enveisavhengigheter direkte i databaseprosjektene ved hjelp av Database References.

Steg 1: Start med to eksisterende lagerprosjekter

Du bør allerede ha:

• Zava.Sales.Warehouse → utplassert til ZavaSalesWarehouse
• Zava.Marketing.Warehouse → utplassert til ZavaMarketingWarehouse

Hvert prosjekt ble opprettet eller hentet ut ved hjelp av stegene i Utvikle lagerprosjekter i Visual Studio Code.

Trinn 2: Legg til en databasereferanse fra salg til markedsføring

• I Visual Studio Code, åpne visningen Database Projects.
• Høyreklikk på prosjektet Zava.Sales.Warehouse .
• Velg Legg til databasereferanse....
• Velg en av:
  • Databaseprosjekt i nåværende arbeidsområde (Et databaseprosjekt som refereres til på denne måten må også være åpent i Visual Studio Code), eller
  • Data-tier applikasjon (.dacpac) (Forutsetter at du har bygget hvis du har bygget .dacpac for Marketing lageret).
• Sett referansealternativene:
  • Referansetype: Samme server, annen database.
  • Databasenavn eller variabel: Bruk for eksempel [$(MarketingWarehouseName)]en SQLCMD-variabel.
• Lagre og bygge opp salgsprosjektet på nytt.

I .sqlproj filen skal du se en oppføring som ligner:

<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: Lag en tverrlagervisning i Sales

I Sales prosjektet legg til en visning som leses fra Marketing lageret:

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

Nøkkelpunkter:

• Det tredelte navnet [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] samsvarer med T-SQL-mønsteret som brukes for cross-warehouse-spørringer i Fabric SQL-editoren.
• DacFx løser den eksterne databasen via databasereferansen.

Bygg prosjektet for å sikre at det ikke finnes SQL71501 uløste referansefeil .

Trinn 4: Publiser markedsføringslageret, deretter salg

For å unngå utrullingsproblemer:

• Bygg og publiserZava.Marketing.Warehouse første:
  • Høyreklikk prosjekt → Bygg.
  • Høyreklikk prosjekt → Publiser → velg ZavaMarketingWarehouse.
• Når Marketing utrullingen lykkes, Zava.Sales.Warehouse:
  • Høyreklikk prosjekt → Bygg.
  • Høyreklikk prosjekt → Publiser → velg ZavaSalesWarehouse.

Den resulterende distribusjonsflyten er:

Zava.Marketing.Warehouse (ingen eksterne avhengigheter) → Zava.Sales.Warehouse (avhenger av Marketing)

Nå kan enhver T-SQL-spørring bruke ZavaSalesWarehouse visningen dbo.CustomerEngagementFact , som internt leser fra Marketing lageret ved hjelp av tverrlager-T-SQL.

Fortsett læringen

• Kombiner dette mønsteret med kildekode og CI/CD-veiledning i utvikling og distribusjon samt dokumentasjon for Fabric git-integrasjon.
• Utvid Zava Analytics-scenariet til å inkludere Dev/Test/Prod-miljøer , ved å bruke distribusjonspipelines eller ekstern CI/CD for å orkestrere publiseringsordre på tvers av flere lagre.

Beslektet innhold

• Arbeidsflyter for utvikling og distribusjon