Afhankelijkheden tussen magazijnen ontwikkelen en implementeren

In dit artikel leert u hoe u afhankelijkheden tussen magazijnen modelleert en implementeert met behulp van SQL-databaseprojecten in Visual Studio Code. U begint met twee bestaande magazijnprojecten en configureert afhankelijkheden in één richting tussen deze projecten met behulp van databaseverwijzingen en, indien nodig, scripts vóór de implementatie en na de implementatie.

Dit artikel bouwt voort op de concepten in Ontwikkeling van magazijnprojecten in Visual Studio Code en gaat ervan uit dat u al vertrouwd bent met het bouwen en publiceren van één magazijnproject.

Vereiste voorwaarden

Voordat u begint, moet u het volgende doen:

  • Maak twee Fabric Warehouses in dezelfde werkruimte.
  • Maak of extraheer een databaseproject voor elk magazijn in Visual Studio Code.
  • Installeer Visual Studio Code op uw werkstation.
  • Installeer de SDK .NET om databaseprojecten te bouwen en te publiceren.
  • Installeer twee Visual Studio Code-extensies: SQL Database Projects en SQL Server (mssql).
    • U kunt de vereiste extensies rechtstreeks vanuit Visual Studio Code Marketplace installeren door te zoeken naar 'SQL Database Projects' of 'SQL Server (mssql)'.
  • De magazijnprojecten valideren, bouwen en kunnen worden gepubliceerd in Visual Studio Code.

Opmerking

Dit artikel is gericht op warehouse-projecten in Visual Studio Code en hoe u ze in Git als gewone codeprojecten verwerkt. Fabric Git-integratie voor werkruimtes en magazijnitems wordt apart behandeld in Development and Deployment en Git-integratie. Het artikel gaat ervan uit dat je Fabric-werkruimte het deployment target is en dat het T-SQL-schema in een of meer Visual Studio Code-projecten staat die je versiebeheer in Git gebruikt.

Dit artikel heeft geen betrekking op crosswarehouse-ontwikkeling voor het SQL-analyse-eindpunt van een Lakehouse. Lakehouse-tabellen en SQL Analytics-eindpuntobjecten zijn geen bijgehouden objecten in broncodebeheer op dezelfde manier als magazijnprojecten. Gebruik Magazijnitems met databaseprojecten voor volledige git-integratie en implementatieondersteuning in Fabric-native ervaringen en clienthulpprogramma's.

Scenario: Zava Analytics-magazijnen voor meerdere domeinen

Zava Analytics maakt gebruik van twee zakelijke domeinen:

  • Verkoop : klantorders, omzet en metrische pijplijngegevens.
  • Marketing : metrische gegevens over campagnes, kanalen en betrokkenheid.

Elk domein heeft:

  • Een fabricwarehouse in dezelfde werkruimte:

    • ZavaSalesWarehouse
    • ZavaMarketingWarehouse

  • Een databaseproject in Visual Studio Code:

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

Voor het bouwen van end-to-end ELT en rapportage heeft elk domein alleen-lezen-weergaven nodig voor toegang tot gegevens uit het andere domein.

  • Sales heeft marketingbetrokkenheid van de klant nodig.
  • Marketing heeft verkoopprestaties per campagne nodig.

U moet het volgende doen:

  • Stel eenrichtingskruisafhankelijkheden tussen magazijnen vast met behulp van databaseverwijzingen.
  • Vermijd cyclische afhankelijkheden.

Zorg ervoor dat afhankelijkheden tussen magazijnen in één richting zijn

Kies voor elk paar magazijnen een richting voor logische afhankelijkheid:

Voorbeeld:

  • Sales is afhankelijk van Marketing voor engagementgegevens.
  • Marketing is niet afhankelijk van Sales voor elk object dat nodig is tijdens de implementatie.

In de praktijk:

Zava.Sales.Warehouse heeft een databasereferentie naar Zava.Marketing.Warehouse.

  • T-SQL in het Sales warehouse kan driedelige namen gebruiken, zoals: 
    SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  • Zava.Marketing.Warehouse verwijst niet naar Sales objecten die tijdens de implementatie een afhankelijkheidscyclus afdwingen.

Aanbeveling

Teken voor elk paar magazijnen een eenvoudig pijldiagram (Sales → Marketing). Als je pijlen in beide richtingen ziet voor hetzelfde type object, refactoriseer dan het ontwerp om een eenrichtingsafhankelijkheid te herstellen.

Cyclische afhankelijkheden voorkomen

Een cyclische afhankelijkheid treedt op wanneer Warehouse A en Warehouse B beide afhankelijk zijn van elkaar op een manier die de engine niet kan oplossen in één implementatie.

Probleemvoorbeeld (doe dit niet):

  • ZavaSalesWarehouse.dbo.CustomerRollup bekijken: 
    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 bekijken: 
    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;

In dit antipatroon:

  • CustomerRollup in Verkoop is afhankelijk van CustomerEngagement in Marketing.
  • CampaignAttribution in Marketing is afhankelijk CustomerRollup van Verkoop.

Met dit antipatroon wordt een cyclus gemaakt: Verkoopweergave → Marketingweergave → verkoopweergave opnieuw.

Richtlijnen:

Modelleer geen wederzijdse afhankelijkheden tussen magazijnen als reguliere objecten op schemaniveau. Als u dit soort logica echt nodig hebt, verplaatst u één kant van de afhankelijkheid naar:

  • Een script na implementatie of
  • Een downstream semantisch model of rapport dat de twee magazijnen op het moment van de query koppelt.

Gebruik scripts vóór en na implementatie voor implementatiegevoelige warehouse-overstijgende logica

Omdat magazijnimplementaties volledige schema-diff-bewerkingen zijn (niet gedeeltelijke implementaties per object), behandelt u items tussen magazijnen zorgvuldig:

Als magazijn A en magazijn B beide objecten nodig hebben die afhankelijk zijn van elkaar:

  • Houd de kerntabellen en kernweergaven in elk magazijnproject.
  • Verplaats brugweergaven of hulpprogrammaobjecten die cycli maken in scripts vóór of na de implementatie in één project.
  • Zorg ervoor dat deze scripts idempotent zijn en veilig zijn om opnieuw uit te voeren.

Voorbeeldpatronen:

  • Script vóór implementatie: een crosswarehouse-weergave tijdelijk verwijderen voordat schemawijzigingen worden toegepast die het zouden breken.
  • Script na implementatie: maak de weergave voor meerdere magazijnen opnieuw of werk deze bij nadat beide magazijnen zijn geïmplementeerd.

Raadpleeg voor meer informatie en voorbeelden scripts vóór implementatie en na implementatie voor Fabric Data Warehouse.

Patroon 1: Directe kruiswarehouseverwijzingen via databaseverwijzingen

In dit patroon modelleer je eenrichtingsafhankelijkheden direct in de databaseprojecten door gebruik te maken van Database References.

Stap 1: Beginnen met twee bestaande magazijnprojecten

U moet het volgende al hebben:

  • Zava.Sales.Warehouse → geïmplementeerd in ZavaSalesWarehouse
  • Zava.Marketing.Warehouse → geïmplementeerd in ZavaMarketingWarehouse

Maak of haal elk project uit met de stappen in Ontwikkel magazijnprojecten in Visual Studio Code.

Stap 2: Een databasereferentie toevoegen van Sales to Marketing

  • Open de weergave Databaseprojecten in Visual Studio Code.
  • Klik met de rechtermuisknop op het Zava.Sales.Warehouse project.
  • Selecteer Databasereferentie toevoegen....
  • Kies een van de volgende opties:
    • Databaseproject in de huidige werkruimte (open ook het verwijzingsdatabaseproject in Visual Studio Code), of
    • Data-tier applicatie (.dacpac) (gebruik deze optie als je een .dacpac voor het Marketing magazijn hebt gebouwd).
  • Stel de referentieopties in:
    • Verwijzingstype: Dezelfde server, verschillende database.
    • Databasenaam of variabele: Gebruik bijvoorbeeld [$(MarketingWarehouseName)]een SQLCMD-variabele.
  • Sla het verkoopproject op en bouw het opnieuw.

In het .sqlproj bestand ziet u een vermelding die vergelijkbaar is met:

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

Aanbeveling

Door een SQLCMD-variabele te gebruiken voor de naam van het remote warehouse, kun je hetzelfde project hergebruiken in al je omgevingen, zoals Dev, Test en Prod.

Stap 3: Een cross-warehouse weergave maken in Sales

Voeg in het Sales project een weergave toe die wordt gelezen uit het Marketing magazijn:

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

Belangrijke punten:

  • De driedelige naam [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] komt overeen met het T-SQL-patroon dat wordt gebruikt voor crosswarehouse-query's in de Fabric SQL-editor.
  • DacFx verwijst naar de externe database via de databasereferentie.

Bouw het project om ervoor te zorgen dat er geen SQL71501 onopgeloste referentiefouten zijn.

Stap 4: Het marketingwarehouse publiceren en vervolgens Verkoop

Implementatieproblemen voorkomen:

  • Bouwen en publicerenZava.Marketing.Warehouse eerste:
    • Klik met de rechtermuisknop op project → Build.
    • Klik met de rechtermuisknop op project → Publiceren → kiezen ZavaMarketingWarehouse.
  • Zodra Marketing de implementatie is voltooid, bouwt en publiceertZava.Sales.Warehouse u het volgende:
    • Klik met de rechtermuisknop op project → Build.
    • Klik met de rechtermuisknop op project → Publiceren → kiezen ZavaSalesWarehouse.

De resulterende implementatieproces is:

Zava.Marketing.Warehouse (geen externe afhankelijkheden) → Zava.Sales.Warehouse (afhankelijk van Marketing)

Elke T-SQL-query in ZavaSalesWarehouse kan nu de dbo.CustomerEngagementFact weergave gebruiken, die intern wordt gelezen vanuit het Marketing magazijn met behulp van crosswarehouse T-SQL.

Doorgaan met leren

  • Combineer dit patroon met bronbeheer en CI/CD-begeleiding in ontwikkeling en deployment en Fabric git-integratiedocumentatie.
  • Breid het Zava Analytics-scenario uit om Dev/Test/Prod-omgevingen op te nemen, met behulp van implementatiepijplijnen of externe CI/CD om de publicatievolgorde in meerdere magazijnen te organiseren.

Verwante inhoud

  • Laatst bijgewerkt om