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 og, der nødvendig, skript før og etter distribusjon.

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.
  • Lag eller hent ut et databaseprosjekt for hvert lager 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.

Note

Denne artikkelen fokuserer på warehouse-prosjekter i Visual Studio Code og hvordan du versjonerer dem i Git som vanlige kodeprosjekter. Fabric Git-integrasjon for arbeidsområder og lagervarer dekkes separat i Development and Deployment ogGit-integrasjon. 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-analyse-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.

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, refaktorerer du designet for å gjenopprette en enveisavhengighet.

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 pre- og post-deploying-skript for sensitiv logikk på tvers av lagre, 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.

For mer informasjon og eksempler, se Pre-deployment og post-deployment scripts for Fabric datalager.

Mønster 1: Direkte tverrlagerreferanser via databasereferanser

I dette mønsteret modellerer du enveisavhengigheter direkte i databaseprosjektene ved å bruke databasereferanser.

Steg 1: Start med to eksisterende lagerprosjekter

Du bør allerede ha:

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

Opprett eller hent ut hvert prosjekt ved å bruke 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 Database Projects.
  • Høyreklikk på prosjektet Zava.Sales.Warehouse .
  • Velg Legg til databasereferanse....
  • Velg ett av følgende alternativer:
    • Databaseprosjekt i nåværende arbeidsområde (åpne også det refererte databaseprosjektet i Visual Studio Code), eller
    • Data-tier applikasjon (.dacpac) (bruk dette alternativet hvis du har bygget en .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 som navnet på det eksterne lageret, kan du gjenbruke det samme prosjektet i alle miljøene dine, som Dev, Test og Prod.

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

  • Last updated on