Udvikl og udrul afhængigheder på tværs af lager.

I denne artikel lærer du, hvordan du modellerer og implementerer afhængigheder på tværs af lagre ved at bruge SQL-databaseprojekter i Visual Studio Code. Du starter fra to eksisterende warehouse-projekter og konfigurerer envejsafhængigheder mellem dem ved at bruge databasereferencer og, hvor nødvendigt, scripts før og efter udrulning.

Denne artikel bygger videre på koncepterne i Udvikl lagerprojekter i Visual Studio Code og antager, at du allerede er tryg ved at bygge og udgive et enkelt lagerprojekt.

Forudsætninger

Før du begynder, skal du sørge for at:

• Opret to Fabric Warehouses i samme arbejdsområde.
  • For at oprette et nyt prøvelager, se Opret et eksempellager i Microsoft Fabric.
• Opret eller udtræk et databaseprojekt for hvert lager i Visual Studio Code.
  • For at oprette et databaseprojekt for dit eksisterende lager eller et nyt lager, se Udvikl lagerprojekter i Visual Studio Code.
• Installer Visual Studio Code på din arbejdsstation.
• Installer SDK'en .NET for at bygge og udgive databaseprojekter.
• Installer to Visual Studio Code udvidelser: SQL Database Projects og SQL Server (mssql).
  • Du kan installere de nødvendige udvidelser direkte fra Visual Studio Code marketplace ved at søge efter "SQL Database Projects" eller "SQL Server (mssql)".
• Lagerprojekterne validerer, bygger og kan publiceres i Visual Studio Code.

Scenarie: Zava Analytics tværdomænelagre, der er på tværs af domæner,

Zava Analytics bruger to forretningsdomæner:

• Salg – kundeordrer, omsætning og pipeline-målinger.
• Marketing – kampagner, kanaler og engagementmålinger.

Hvert domæne har:

• Et stoflager i samme arbejdsområde:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Et databaseprojekt i Visual Studio Code:

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

For at bygge end-to-end ELT og rapportering har hvert domæne brug for skrivebeskyttede visninger for at få adgang til data fra det andet domæne:

• Sales Kræver markedsføringsengagement fra kunden.
• Marketing Kræver salgsresultater pr. kampagne.

Du skal:

• Etabler envejs-afhængigheder på tværs af lagre via databasereferencer.
• Undgå cykliske afhængigheder.

Sørg for, at afhængighederne mellem lagre er envejsrettet

For hvert par lagre vælges en retning for logisk afhængighed:

Eksempel:

• Sales Det afhænger af Marketing engagementdata.
• Marketing afhænger ikke af Sales for objekter, der er nødvendige ved udrulning.

I praksis:

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

• T-SQL i lageret Sales kan bruge tre-delte navne som:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse refererer ikke til Sales objekter, der ville tvinge en afhængighedscyklus ved udrulning.

Undgå cykliske afhængigheder

En cyklisk afhængighed opstår, når Lager A og Lager B begge er afhængige af hinanden på en måde, som motoren ikke kan løse i én enkelt udrulning.

Problemeksempel (lad være med dette):

• ZavaSalesWarehouse.dbo.CustomerRollup udsigt:

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

  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ønster:

• CustomerRollup i salg afhænger af CustomerEngagementi marketing.
• CampaignAttribution i marketing afhænger af CustomerRollup salg .

Dette anti-mønster skaber en cyklus: Salgsvisning → Marketing-visning → Salgs-visning igen.

Vejledning:

Modeller ikke gensidige afhængigheder mellem lagre som almindelige skema-niveau objekter. Hvis du virkelig har brug for denne slags logik, så flyt den ene side af afhængigheden til:

• Et script efter udrulning, eller
• En nedstrøms semantisk model eller rapport , der forbinder de to lagre ved forespørgselstidspunktet.

Brug pre- og post-deployment-scripts til deployment-sensitiv cross-warehouse-logik

Da lagerudrulninger er fulde skema-diff-operationer (ikke delvise udrulninger pr. objekt), skal du behandle tværlager-elementer omhyggeligt:

Hvis Lager A og Lager B begge har brug for objekter, der er afhængige af hinanden:

• Behold kernetabellerne og kernevisningerne i hvert lagerprojekt.
• Flyt brovisninger eller hjælpeobjekter , der opretter cyklusser, ind i pre- eller post-deployment-scripts i ét projekt.
• Sørg for, at disse scripts er idempotente og sikre at genafspille.

Eksempelmønstre:

• Pre-deployment script: midlertidigt dropp en cross-warehouse-visning, før du anvender skemaændringer, der ville ødelægge den.
• Post-deployment script: genskab eller opdater cross-warehouse-visningen, efter begge warehouses er deployed.

For mere information og eksempler, se scripts før og efter implementering for Fabric data warehouse.

Mønster 1: Direkte kryds-lager-referencer via databasereferencer

I dette mønster modellerer du envejsafhængigheder direkte i databaseprojekterne ved at bruge Database References.

Trin 1: Start med to eksisterende lagerprojekter

Du burde allerede have:

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

Opret eller udtræk hvert projekt ved at bruge trinene i Udvikl lagerprojekter i Visual Studio Code.

Trin 2: Tilføj en databasereference fra Salg til Markedsføring

• I Visual Studio Code åbn Database Projects-visningen.
• Højreklik Zava.Sales.Warehouse på projektet.
• Vælg Tilføj databasereference....
• Vælg én af følgende indstillinger:
  • Databaseprojekt i det aktuelle arbejdsområde (åbn også det refererede databaseprojekt i Visual Studio Code), eller
  • Data-tier applikation (.dacpac) (brug denne mulighed, hvis du har bygget en .dacpac til Marketing lageret).
• Indstil referenceindstillingerne:
  • Referencetype: Samme server, anden database.
  • Databasenavn eller variabel: Brug for eksempel [$(MarketingWarehouseName)]en SQLCMD-variabel.
• Gem og genopbyg salgsprojektet.

I .sqlproj filen bør du se en post, der ligner denne:

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

Trin 3: Opret en tværlager-visning i Sales

I Sales projektet tilføjes en visning, der læses 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øglepunkter:

• Det tredelte navn [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] matcher T-SQL-mønsteret, der bruges til cross-warehouse-forespørgsler i Fabric SQL-editoren.
• DacFx løser den eksterne database via databasereferencen.

Byg projektet op, så der ikke er SQL71501 uløste referencefejl .

Trin 4: Offentliggør Marketing-lageret, derefter Salg

For at undgå udrulningsproblemer:

• Byg og udgivZava.Marketing.Warehouse første:
  • Højreklik på projekt → Build.
  • Højreklik på projekt → Publicer → vælg ZavaMarketingWarehouse.
• Når Marketing implementeringen lykkes, Zava.Sales.Warehouse:
  • Højreklik på projekt → Build.
  • Højreklik på projekt → Publicer → vælg ZavaSalesWarehouse.

Den resulterende implementeringsflow er:

Zava.Marketing.Warehouse (ingen eksterne afhængigheder) → Zava.Sales.Warehouse (afhænger af Marketing)

Nu kan enhver T-SQL-forespørgsel i ZavaSalesWarehouse bruge viewen dbo.CustomerEngagementFact , som internt læser fra Marketing lageret ved hjælp af cross-warehouse T-SQL.

Fortsæt med at lære

• Kombiner dette mønster med versionskontrol og CI/CD-vejledning i udvikling og implementering samt dokumentation for Fabric git-integration.
• Udvid Zava Analytics-scenariet til også at omfatte Dev/Test/Prod-miljøer , hvor man bruger deployment-pipelines eller ekstern CI/CD til at orkestrere publiceringsordrer på tværs af flere lagre.

Relateret indhold

• Arbejdsgange for udvikling og implementering