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 lagerprojekter og konfigurerer envejsafhængigheder mellem dem ved hjælp af databasereferencer.

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.
  • Opret eller udtræk et databaseprojekt for hvert lager 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.

Notat

Denne artikel fokuserer på warehouse-projekter i Visual Studio Code og hvordan du versionerer dem i Git som almindelige kodeprojekter. Fabric Git-integration for arbejdsområder og lagervarer dækkes separat i Development and Deployment ogGit-integration. Artiklen antager, at dit Fabric-arbejdsområde er deployeringsmålet, og at T-SQL-skemaet ligger i et eller flere Visual Studio Code-projekter, som du versionsstyrer i Git.

Denne artikel dækker ikke cross-warehouse-udvikling for SQL-analyse-endpointet i et Lakehouse. Lakehouse-tabeller og SQL-analyse-endpointobjekter bliver ikke sporet objekter i versionskontrol på samme måde som warehouse-projekter. Brug lagerelementer med databaseprojekter for fuld git-integration og implementeringsstøtte i Fabric native oplevelser og klientværktøjer.

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.

Tips

For hvert par lagre tegnes et simpelt pildiagram (Sales → Marketing). Hvis du finder pile, der peger i begge retninger for samme type objekt, så refaktorere designet for at genoprette en envejsafhængighed.

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 ind i en downstream semantisk model eller rapport , der forbinder de to lagre ved forespørgselstidspunktet.

Direkte krydslagerreferencer via databasereferencer

I dette mønster modellerer du envejsafhængigheder direkte i databaseprojekterne ved hjælp af 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

Hvert projekt blev oprettet eller udtrukket ved hjælp af 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 en af:
    • Databaseprojekt i nuværende arbejdsområde (Et databaseprojekt, der refereres på denne måde, skal også være åbent i Visual Studio Code), eller
    • Data-tier applikation (.dacpac) (Antager at du har bygget, hvis du har bygget .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>

Tips

Ved at bruge en SQLCMD-variabel som navnet på det fjernlager, kan du genbruge det samme projekt på tværs af alle dine miljøer, såsom Dev/Test/Prod, hvor warehouse-navnene kan være forskellige.

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

  • Last updated on