Del via

Utvikle og distribuere avhengigheter på tvers av varehus

I denne artikkelen lærer du hvordan du modellerer og distribuerer avhengigheter på tvers av lagre ved hjelp av SQL-databaseprosjekter i Visual Studio Code. Du starter fra to eksisterende lagerprosjekter og konfigurerer enveisavhengigheter mellom dem ved hjelp av databasereferanser og, der nødvendig, skript før og etter distribusjon.

Denne artikkelen bygger videre på konseptene i Develop warehouse-prosjekter i Visual Studio Code og forutsetter at du allerede er komfortabel med å bygge og publisere et enkelt warehouse-prosjekt.

Forutsetninger

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

  • Opprett to Fabric Warehouses i samme arbeidsområde.
  • Lag eller hent ut et databaseprosjekt for hvert lager i Visual Studio Code.
  • Installer Visual Studio Code på arbeidsstasjonen.
  • Installer .NET SDK 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 etter «SQL Database Projects» eller «SQL Server (mssql)».
  • Lagerprosjektene validerer, bygger og kan publiseres i Visual Studio Code.

Note

Denne artikkelen fokuserer på lagerprosjekter i Visual Studio Code og hvordan du versjoner dem i Git som vanlige kodeprosjekter. Fabric Git-integrasjon for arbeidsområder og lagerelementer dekkes separat i Source Control med Fabric Data Warehouse - og Git-integrasjonsdokumentasjon. Artikkelen antar at Fabric-arbeidsområdet ditt er distribusjonsmålet, og at T-SQL-skjemaet ligger i ett eller flere Visual Studio Code-prosjekter som du versjonskontrollerer i Git.

Denne artikkelen dekker ikke tverrlagerutvikling for SQL-analyseendepunktet til et Lakehouse. Lakehouse-tabeller og SQL-endepunktobjekter er ikke sporede objekter i kildekode på samme måte som warehouse-prosjekter. Bruk Warehouse-elementer med databaseprosjekter for fullstendig git-integrasjon og distribusjonsstøtte i Fabric native opplevelser og klientverktøy.

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.
  • Bruk skript før og etter utrulling i tilfeller der objekter i begge lagrene er avhengige av hverandre.

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.

Tips

For hvert par av lagerbygninger, tegn et enkelt pildiagram (Sales → Marketing). Hvis du finner piler som peker i begge retninger for samme type objekt, må du sannsynligvis refaktorere eller flytte noe logikk inn i skript før og etter utrulling.

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

  • Et skript etter utrulling, eller
  • En nedstrøms semantisk modell eller rapport som kobler sammen de to lagrene ved spørringstidspunkt.

Bruk skript før og etter utrulling for sensitiv tverrlager-logikk for distribusjon

Siden lagerutrullinger er full schema diff-operasjoner (ikke delvise utrullinger per objekt), bør du behandle tverrlager-elementer nøye:

Hvis Warehouse A og Warehouse B begge trenger objekter som er avhengige av hverandre:

  • Behold kjernetabellene og kjernevisningene i hvert lagerprosjekt.
  • Flytt brovisninger eller verktøyobjekter som lager sykluser inn i før- eller post-distribusjonsskript i ett prosjekt.
  • Sørg for at disse skriptene er idempotente og trygge å kjøre på nytt.

Eksempelmønstre:

  • Pre-deployment script: midlertidig dropp en cross-warehouse-visning før skjemaendringer som ville ødelagt den.
  • Post-deployment script: gjenskap eller oppdater kryss-warehouse-visningen etter at begge warehouses er distribuert.

Mønster 1: 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 trinnene i Utvikle lagerprosjekter i Visual Studio Code.

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

  • I Visual Studio Code, åpne visningen Databaseprosjekter .
  • Høyreklikk på prosjektet Zava.Sales.Warehouse .
  • Velg Legg til databasereferanse....
  • Velg en av:
    • Databaseprosjekt i nåværende arbeidsområde (Et databaseprosjekt referert 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>

Tips

Ved å bruke en SQLCMD-variabel for navnet på det eksterne lageret kan du gjenbruke det samme prosjektet i alle miljøene dine, som Dev/Test/Prod, hvor warehouse-navnene kan variere.

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 Zava.Sales.Warehouselykkes, bygg og publiser:
    • 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.

Mønster 2: Kryss-lageravhengigheter håndtert via skript før og etter distribusjon

I noen Zava Analytics-scenarier kan begge domener trenge aggregerte objekter som er avhengige av hverandre. Eksempel:

  • Salg ønsker et syn som bruker data fra markedsføringskampanjer for å gi salgsinntekter per kampanje.
  • Markedsføring ønsker et syn som bruker salgsinntektsdata for å gi effektivitet i markedsføringskampanjer.

Du vil ikke at begge disse objektene skal være vanlige visninger som deltar i full modelldistribusjon, fordi det risikerer en syklisk avhengighet eller skjør distribusjonsrekkefølge.

I stedet gjør du:

  • Hold hver lagers kjernemodell uavhengig.
  • Bruk post-deploying-skript i ett prosjekt for å lage flere cross-warehouse-visninger etter at begge skjemaene er på plass.

Trinn 1: Legg til databasereferanser for validering i kompileringstid

Sett opp referanser som ligner på Pattern 1, men for begge prosjektene:

  • I Zava.Sales.Warehouse, legg til en referanse til Markedsføring via [$(MarketingWarehouseName)].
  • I Zava.Marketing.Warehouse, kan du eventuelt legge til en referanse til salg via [$(SalesWarehouseName)] hvis du vil ha kompileringstidsvalidering av krysslagervisninger brukt i skript.

I filene .sqlproj kan du sette:

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

Steg 2: Opprett kjerneobjekter som vanlige prosjektobjekter

Eksempel:

  • Sales prosjekt:

    • dbo.CustomerRevenue-tabell
    • dbo.SalesByCampaign visning (bruker kun lokale tabeller)

  • Marketing prosjekt:

    • dbo.Campaigns-tabell
    • dbo.CampaignStats visning (bruker kun lokale tabeller)

Disse objektene bruker ikke tverrlager-spørringer. I neste steg vil vi introdusere krysslagerreferanser.

Trinn 3: Legg til et post-deploying-skript for cross-warehouse-brovisninger

Velg ett lager for å huse broobjekter; typisk det domenet som bruker den samlede outputen mest. Anta Sales er det domenet.

  • I prosjektet Sales : Høyreklikk på prosjektet, og legg deretter til → Post-Deployment Script.
  • Navngi manuset PostDeployment_CrossWarehouse.sql.
  • I skriptet kan du opprette eller endre cross-warehouse-visningene ved å bruke IF EXISTS / / DROPCREATE mønstre for å holde dem idempotente.

Eksempel på et skript i Sales som refererer til Marketing warehouse-objekter:

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

Her:

  • Kjerne- Sales og Marketing lagerprosjektene forblir uavhengige og kan settes ut på egenhånd.
  • Brovisningen opprettes etter skjemautrullingen via et post-distribusjonsskript.
  • Hvis distribusjonen kjører flere ganger, er den idempotent, siden skriptet trygt dropper og gjenskaper visningen.

Trinn 4: (Valgfritt) Bruk pre-deploying-skript for å beskytte skjøre avhengigheter

I mer avanserte situasjoner kan du:

  • Bruk et pre-deploying-skript for å fjerne eller deaktivere cross-warehouse-visninger som kan blokkere skjemaendringer (for eksempel hvis du omdøper kolonner).
  • La DacFx anvende skjema-diffen.
  • Bruk post-deployment-skriptet for å gjenskape eller oppdatere cross-warehouse-visningene.

Viktig!

Forhånds- og post-distribusjonsskript kjøres som en del av distribusjonsplanen og må være:

  • Idempotent, som betyr at de er trygge å kjøre flere ganger.
  • Kompatibel med det endelige skjemaet produsert av DacFx.
  • Fri for ødeleggende endringer som strider mot polisen din BlockOnPossibleDataLoss .

Trinn 5: Publiserer rekkefølge for skriptstyrte avhengigheter

Et vanlig mønster for Zava Analytics:

  • Publiser grunnprosjekter:
    • Zava.Marketing.Warehouse (kjerneskjema)
    • Zava.Sales.Warehouse (kjerneskjema + krysslager-skript etter distribusjon)
  • La Sales post-deployment-skriptet lage brovisningene etter at sitt eget skjema og det refererte Marketing skjemaet er distribuert.

Hvis du introduserer mer enn to lagre, gjenta dette mønsteret i lag. Aldri lag sykliske avhengigheter via vanlige prosjektobjekter.

Fortsett læringen

  • Kombiner disse mønstrene med kildekode og CI/CD-veiledning i kildekode med Fabric Data Warehouse og Fabric git-integrasjonsdokumentasjon.
  • 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

  • Last updated on