Développer et déployer des dépendances entre entrepôts

Dans cet article, vous allez apprendre à modéliser et déployer des dépendances entre entrepôts à l’aide de projets de base de données SQL dans Visual Studio Code. Vous partez de deux projets d’entrepôt existants et configurez des dépendances unidirectionnelles entre eux en utilisant des références de base de données.

Cet article s'appuie sur les concepts des projets Develop warehouse dans Visual Studio Code et suppose que vous êtes déjà à l'aise dans la création et la publication d'un projet d'entrepôt unique.

Prerequisites

Avant de commencer, assurez-vous de :

Créez deux entrepôts Fabric dans le même espace de travail.
- Pour créer un exemple d’entrepôt, consultez Créer un exemple d’entrepôt dans Microsoft Fabric.
Créez ou extrayez un projet database pour chaque entrepôt dans Visual Studio Code.
- Pour créer un projet de base de données pour votre entrepôt existant ou un nouvel entrepôt, consultez Développer des projets d’entrepôt dans Visual Studio Code.
Installez Visual Studio Code sur votre station de travail.
Installez le sdk .NET pour générer et publier des projets de base de données.
Installez deux extensions Visual Studio Code : SQL Database Projects et SQL Server (mssql).
- Vous pouvez installer les extensions requises directement à partir de Visual Studio Code Place de marché en recherchant « Projets SQL Database » ou « SQL Server (mssql) ».
Les projets d’entrepôt valident, créent et peuvent être publiés dans Visual Studio Code.

Note

Cet article se concentre sur les projets warehouse dans Visual Studio Code et sur la façon dont vous les versionz dans Git en tant que projets de code standard. L’intégration Fabric Git pour les espaces de travail et les articles d’entrepôt est traitée séparément dans Development and Deployment et intégration Git. L’article part du principe que votre espace de travail Fabric est la cible de déploiement et que le schéma T-SQL se trouve dans un ou plusieurs projets Visual Studio Code que vous contrôlez dans Git.

Cet article ne couvre pas le développement inter-entrepôts pour le point de terminaison d’analyse SQL d'un Lakehouse. Les tables Lakehouse et les objets de points de terminaison SQL ne sont pas des objets suivis dans le contrôle de code source de la même manière que les projets de data warehouse. Utilisez des éléments Warehouse avec des projets de base de données pour une prise en charge complète de l’intégration et du déploiement git dans les expériences natives Fabric et les outils clients.

Scénario : Entrepôts inter-domaines Zava Analytics

Zava Analytics utilise deux domaines métier :

Ventes : commandes client, chiffre d’affaires et métriques de pipeline.
Marketing : campagnes, canaux et métriques d’engagement.

Chaque domaine a :

Un entrepôt Fabric dans le même espace de travail :
- ZavaSalesWarehouse
- ZavaMarketingWarehouse
Un projet database dans Visual Studio Code :
- Zava.Sales.Warehouse
- Zava.Marketing.Warehouse

Pour créer des rapports ET ELT de bout en bout, chaque domaine a besoin d’affichages en lecture seule pour accéder aux données à partir de l’autre domaine :

Sales a besoin d’un engagement marketing par le client.
Marketing a besoin des performances des ventes par campagne.

Vous devez :

Établissez des dépendances unidirectionnelles entre entrepôts via des références de base de données.
Évitez les dépendances cycliques.

Vérifier que les dépendances entre les entrepôts sont unidirectionnelles

Pour chaque paire d’entrepôts, choisissez une direction pour la dépendance logique :

Exemple :

Sales dépend des Marketing données d’engagement.
Marketing ne dépend Sales pas des objets nécessaires au moment du déploiement.

Pratiquement:

Zava.Sales.Warehouse a une référence de base de données à Zava.Marketing.Warehouse.

T-SQL dans l’entrepôt Sales peut utiliser des noms en trois parties comme :
```
SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
```
Zava.Marketing.Warehouse ne fait pas référence à Sales des objets qui forcent un cycle de dépendance au moment du déploiement.

Conseil / Astuce

Pour chaque paire d’entrepôts, dessinez un diagramme de flèche simple (Sales → Marketing). Si vous trouvez des flèches pointant dans les deux directions pour le même type d’objet, refactorisez le design pour restaurer une dépendance unidirectionnelle.

Éviter les dépendances cycliques

Une dépendance cyclique se produit lorsque l’entrepôt A et l’entrepôt B dépendent les uns des autres d’une manière que le moteur ne peut pas résoudre dans un seul déploiement.

Exemple de problème (ne procédez pas comme suit) :

ZavaSalesWarehouse.dbo.CustomerRollup Affichage:

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

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;

Dans cet anti-pattern :

CustomerRollup dans Sales dépend CustomerEngagement de Marketing.
CampaignAttribution dans Marketing dépend CustomerRollup de Ventes.

Cet anti-modèle crée un cycle : vue Ventes → vue Marketing → vue Ventes à nouveau.

Conseils :

Ne modélisez pas les dépendances mutuelles entre les entrepôts en tant qu’objets de niveau schéma standard. Si vous avez vraiment besoin de ce type de logique, déplacez un côté de la dépendance dans un modèle sémantique ou un rapport en aval qui relie les deux entrepôts au moment de la requête.

Références inter-entrepôts directes via des références de base de données

Dans ce modèle, vous modélisez des dépendances unidirectionnelles directement dans les projets de base de données à l’aide de références de base de données.

Étape 1 : Démarrer à partir de deux projets d’entrepôt existants

Vous devez déjà avoir :

Zava.Sales.Warehouse → déployée sur ZavaSalesWarehouse
Zava.Marketing.Warehouse → déployée sur ZavaMarketingWarehouse

Chaque projet a été créé ou extrait à l’aide des étapes décrites dans Develop warehouse projects in Visual Studio Code.

Étape 2 : Ajouter une référence de base de données de Sales to Marketing

Dans Visual Studio Code, ouvrez la vue Database Projects.
Cliquez avec le bouton droit sur le Zava.Sales.Warehouse projet.
Sélectionnez Ajouter une référence de base de données....
Choisissez l’une des suivantes :
- ProjetDatabase dans l’espace de travail actuel (un projet de base de données référencé de cette façon doit également être ouvert dans Visual Studio Code) ou
- Application de la couche Données (.dacpac) ( suppose que vous avez créé si vous avez créé .dacpac pour l’entrepôt Marketing ).
Définissez les options de référence :
- Type de référence : Même serveur, base de données différente.
- Nom ou variable de la base de données : Utilisez une variable SQLCMD, par exemple [$(MarketingWarehouseName)].
Enregistrez et régénérez le projet Sales.

Dans le .sqlproj fichier, vous devez voir une entrée similaire à :

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

Conseil / Astuce

L’utilisation d’une variable SQLCMD pour le nom de l’entrepôt distant vous permet de réutiliser le même projet dans tous vos environnements, tels que Dev/Test/Prod, où les noms d’entrepôt peuvent différer.

Étape 3 : Créer une vue inter-entrepôts dans Sales

Dans le Sales projet, ajoutez une vue qui lit à partir de l’entrepôt Marketing :

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

Points clés :

Le nom [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] en trois parties correspond au modèle T-SQL utilisé pour les requêtes inter-entrepôts dans l’éditeur FABRIC SQL.
DacFx résout la base de données externe via la référence de base de données.

Générez le projet pour vous assurer qu’il n’existe aucune erreur de référence non résolue SQL71501 .

Étape 4 : Publier l’entrepôt marketing, puis les ventes

Pour éviter les problèmes de déploiement :

Générer et publierZava.Marketing.Warehouse premier:
- Cliquez avec le bouton droit sur le projet → Générer.
- Cliquez avec le bouton droit sur le projet → publier → choisissez ZavaMarketingWarehouse.
Une fois Marketing le déploiement réussi, générez et publiezZava.Sales.Warehouse :
- Cliquez avec le bouton droit sur le projet → Générer.
- Cliquez avec le bouton droit sur le projet → publier → choisissez ZavaSalesWarehouse.

Le flux de déploiement obtenu est le suivant :

Zava.Marketing.Warehouse (aucune dépendance externe) → Zava.Sales.Warehouse (dépend de Marketing)

À présent, n'importe quelle requête T-SQL dans ZavaSalesWarehouse peut utiliser la vue dbo.CustomerEngagementFact, qui, en interne, lit à partir de l’entrepôt Marketing à l’aide de T-SQL inter-entrepôts.

Continuer à apprendre

Combinez ce schéma avec le contrôle de version et les conseils CI/CD dans le développement et le déploiement ainsi que la documentation d’intégration Fabric git.
Étendre le scénario Zava Analytics pour inclure des environnements Dev/Test/Prod, à l’aide de pipelines de déploiement ou de CI/CD externes pour orchestrer l’ordre de publication sur plusieurs entrepôts.

Flux de travail de développement et de déploiement

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-07-31