Delen via

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 Warehouse-projecten ontwikkelen 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:

Opmerking

In dit artikel wordt aandacht besteed aan magazijnprojecten in Visual Studio Code en hoe u ze in Git kunt versien als reguliere codeprojecten. Fabric Git-integratie voor werkruimten en warehouse items wordt afzonderlijk behandeld in de documentatie Broncodebeheer met Fabric Data Warehouse en Git-integratie. In het artikel wordt ervan uitgegaan dat uw Fabric-werkruimte het implementatiedoel is en dat het T-SQL-schema zich bevindt in een of meer Visual Studio Code-projecten die u onder versiebeheer in Git hebt.

Dit artikel heeft geen betrekking op crosswarehouse-ontwikkeling voor het SQL-analyse-eindpunt van een Lakehouse. Lakehouse-tabellen en SQL-eindpuntobjecten worden niet op dezelfde manier gevolgd in broncodebeheer als datawarehouseprojecten. 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.
  • Gebruik pre- en post-implementatiescripts voor gevallen waarin objecten in beide magazijnen afhankelijk zijn van elkaar.

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 u pijlen vindt die in beide richtingen wijzen voor hetzelfde type object, moet u waarschijnlijk wat logica herstructureren of verplaatsen naar pre- en post-implementatiescripts.

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.

Pre- en post-implementatiescripts gebruiken voor implementatiegevoelige cross-warehouse-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.

Patroon 1: Directe kruiswarehouseverwijzingen via databaseverwijzingen

In dit patroon modelleert u afhankelijkheden in één richting rechtstreeks in de databaseprojecten met behulp van databaseverwijzingen.

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

Elk project is gemaakt of geëxtraheerd met behulp van de stappen in Warehouse-projecten ontwikkelen 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 (een databaseproject waarnaar op deze manier wordt verwezen, moet ook zijn geopend in Visual Studio Code), of
    • Data-tier-toepassing (.dacpac) (Gaat ervan uit dat u 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

Met behulp van een SQLCMD-variabele voor de naam van het externe magazijn kunt u hetzelfde project opnieuw gebruiken in al uw omgevingen, zoals Dev/Test/Prod, waarbij de namen van de magazijnnamen kunnen verschillen.

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 lost de externe database op 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.

Patroon 2: Afhankelijkheden tussen magazijnen die worden beheerd via pre- en post-implementatiescripts

In sommige Zava Analytics-scenario's hebben beide domeinen mogelijk geaggregeerde objecten nodig die afhankelijk zijn van elkaar. Voorbeeld:

  • Verkoop wil een weergave die gebruikmaakt van marketingcampagnegegevens om verkoopopbrengsten per marketingcampagne te bieden.
  • Marketing wil een weergave die gebruikmaakt van verkoopopbrengstgegevens om de efficiëntie van marketingcampagnes te bieden.

U wilt niet dat beide objecten reguliere weergaven zijn die deelnemen aan de volledige modelimplementatie, omdat dat een cyclische afhankelijkheid of een kwetsbare implementatievolgorde riskeert.

In plaats daarvan gaat u het volgende doen:

  • Houd het kernmodel van elk magazijn onafhankelijk.
  • Gebruik scripts na de implementatie in één project om meer cross-warehouse weergaven te maken nadat beide schema's zijn geïmplementeerd.

Stap 1: Databaseverwijzingen toevoegen voor compileertijdvalidatie

Stel verwijzingen in die vergelijkbaar zijn met Patroon 1, maar voor beide projecten:

  • Voeg een verwijzing naar Marketing toe in Zava.Sales.Warehouse via [$(MarketingWarehouseName)].
  • Voeg desgewenst een verwijzing naar Verkoop toe via [$(SalesWarehouseName)] als u cross-warehouse weergaven wilt valideren tijdens de compileertijd van scripts.

In de .sqlproj bestanden kunt u het volgende instellen:

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

Stap 2: Kernobjecten maken als reguliere projectobjecten

Voorbeeld:

  • Sales project:

    • dbo.CustomerRevenue-tabel
    • dbo.SalesByCampaign weergeven (alleen met lokale tabellen)

  • Marketing project:

    • dbo.Campaigns-tabel
    • dbo.CampaignStats weergeven (alleen met lokale tabellen)

Deze objecten maken geen gebruik van query's over meerdere magazijnen. In de volgende stap introduceren we kruisverwijzingen tussen magazijnen.

Stap 3: Een script na de implementatie toevoegen voor brugweergaven tussen magazijnen

Kies één magazijn om brugobjecten te hosten; doorgaans het domein dat de gecombineerde uitvoer het zwaarst verbruikt. Stel dat Sales dit domein is.

  • Klik in het Sales project met de rechtermuisknop op het project en voeg → script na implementatie toe.
  • Geef het script PostDeployment_CrossWarehouse.sqleen naam.
  • Maak of wijzig in het script de crosswarehouse-weergaven met behulp van IF EXISTS / DROP / CREATE patronen om ze idempotent te houden.

Voorbeeld van een script waarin Sales wordt verwezen naar Marketing magazijnobjecten:

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

Hier:

  • De kern Sales- en Marketing-magazijnprojecten blijven zelfstandig en zijn door zichzelf implementeerbaar.
  • De brugweergave wordt gemaakt na de schema-implementatie via een script na de implementatie.
  • Als de implementatie meerdere keren wordt uitgevoerd, is deze idempotent, omdat het script de weergave veilig opnieuw verwijdert en aanmaakt.

Stap 4: (Optioneel) Scripts vóór de implementatie gebruiken om kwetsbare afhankelijkheden te beveiligen

In meer geavanceerde scenario's kunt u het volgende doen:

  • Gebruik een script vóór de implementatie om kruiswarehouseweergaven te verwijderen of uit te schakelen die schemawijzigingen kunnen blokkeren (bijvoorbeeld als u de naam van kolommen wijzigt).
  • Laat DacFx het schemaverschil toepassen.
  • Gebruik het script na de implementatie om de cross-warehouse weergaven opnieuw te maken of bij te werken.

Belangrijk

Scripts vóór en na de implementatie worden uitgevoerd als onderdeel van het implementatieplan en moeten:

  • Idempotent, wat betekent dat ze veilig zijn om meerdere keren te worden uitgevoerd.
  • Compatibel met het uiteindelijke schema dat is geproduceerd door DacFx.
  • Vrij van destructieve wijzigingen die conflicteren met uw BlockOnPossibleDataLoss beleid.

Stap 5: De volgorde publiceren voor door scripts beheerde afhankelijkheden

Een algemeen patroon voor Zava Analytics:

  • Basisprojecten publiceren:
    • Zava.Marketing.Warehouse (kernschema)
    • Zava.Sales.Warehouse (kernschema + script over meerdere warehouses na implementatie)
  • Laat het Verkoop post-implementatiescript de brugweergaven maken nadat zijn eigen schema en het schema waarnaar wordt verwezen Marketing zijn geïmplementeerd.

Als u meer dan twee magazijnen introduceert, herhaalt u dit patroon in lagen. Maak nooit cyclische afhankelijkheden via gewone projectobjecten.

Doorgaan met leren

  • Combineer deze patronen met broncodebeheer en CI/CD-richtlijnen in broncodebeheer met Git-integratiedocumenten voor Fabric Data Warehouse en Fabric.
  • 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

  • Last updated on