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 commencez à partir de deux projets d’entrepôt existants et configurez des dépendances unidirectionnelles entre eux à l’aide de références de base de données et, si nécessaire, des scripts de prédéploiement et de post-déploiement.

Cet article s’appuie sur les concepts du développement de projets d’entrepôt 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 de base de données 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 Kit de développement logiciel (SDK) .NET pour générer et publier des projets de base de données.
• Installez deux extensions Visual Studio Code : projets SQL Database et SQL Server (mssql).
  • Vous pouvez installer les extensions requises directement à partir de la Place de marché Visual Studio Code 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.

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 de base de données 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.
• Utilisez des scripts de prédéploiement et de post-déploiement pour les cas où les objets des deux entrepôts dépendent les uns des autres.

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.

É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 Vue:

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

• Un script post-déploiement ou
• Modèle sémantique ou rapport en aval qui joint les deux entrepôts au moment de la requête.

Utiliser des scripts de pré-déploiement et post-déploiement pour la logique inter-entrepôt sensible au déploiement

Étant donné que les déploiements d’entrepôt sont des opérations de différences de schéma complètes (pas partielles par objet), traitez soigneusement les éléments inter-entrepôts :

Si Warehouse A et Warehouse B ont besoin d’objets qui dépendent les uns des autres :

• Conservez les tables principales et les vues principales dans chaque projet d’entrepôt.
• Déplacez les vues de pont ou les objets utilitaires qui créent des cycles dans des scripts de pré-déploiement ou de post-déploiement dans un même projet.
• Vérifiez que ces scripts sont idempotents et sûrs à réexécuter.

Exemples de modèles :

• Script de prédéploiement : supprimez temporairement une vue inter-entrepôt avant d’appliquer des modifications de schéma qui l’interrompraient.
• Script de post-déploiement : recréez ou mettez à jour la vue inter-entrepôt après le déploiement des deux entrepôts.

Modèle 1 : 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 Développer des projets d’entrepôt dans 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 Projets de base de données .
• 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 :
  • Projet de base de données 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>

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

Modèle 2 : Dépendances entre entrepôts gérées via des scripts de pré-déploiement et post-déploiement

Dans certains scénarios Zava Analytics, les deux domaines peuvent avoir besoin d’objets agrégés qui dépendent les uns des autres. Par exemple:

• Le département des ventes souhaite une vue qui utilise les données des campagnes marketing afin de présenter les revenus générés par chaque campagne marketing.
• Le marketing souhaite une vue qui utilise les données de chiffre d’affaires pour améliorer l'efficacité des campagnes marketing.

Vous ne souhaitez pas que ces deux objets soient des vues standard participant au déploiement complet du modèle, car cela risque de créer une dépendance cyclique ou un ordre de déploiement fragile.

Au lieu de cela, vous :

• Conservez le modèle de base de chaque entrepôt.
• Utilisez des scripts post-déploiement dans un projet pour créer d’autres vues inter-entrepôts une fois les deux schémas en place.

Étape 1 : Ajouter des références de base de données pour la validation au moment de la compilation

Configurez des références similaires à Pattern 1, mais pour les deux projets :

• Dans Zava.Sales.Warehouse, ajoutez une référence à Marketing via [$(MarketingWarehouseName)].
• Dans Zava.Marketing.Warehouse, ajoutez éventuellement une référence à Sales via [$(SalesWarehouseName)] si vous souhaitez valider au moment de la compilation des vues inter-entrepôts utilisées dans les scripts.

Dans les .sqlproj fichiers, vous pouvez définir :

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

Étape 2 : Créer des objets principaux en tant qu’objets de projet standard

Exemple :

• Sales projet:

  • Table dbo.CustomerRevenue
  • dbo.SalesByCampaign affichage (à l’aide de tables locales uniquement)

• Marketing projet:

  • Table dbo.Campaigns
  • dbo.CampaignStats affichage (à l’aide de tables locales uniquement)

Ces objets n’utilisent pas de requêtes entre entrepôts. À l’étape suivante, nous allons introduire des références entre différents entrepôts.

Étape 3 : Ajouter un script de post-déploiement pour les vues de pont entre entrepôts

Choisissez un entrepôt pour héberger des objets passerelle ; généralement le domaine qui consomme la sortie combinée le plus intensément. Supposons que Sales soit ce domaine.

• Dans le projet Sales : cliquez avec le bouton droit sur le projet, puis Ajoutez → Script post-déploiement.
• Nommez le script PostDeployment_CrossWarehouse.sql.
• Dans le script, créez ou modifiez les vues inter-entrepôts à l’aide IF EXISTS / DROP / CREATE de modèles pour les conserver idempotentes.

Exemple de script dans Sales lequel référence Marketing des objets d’entrepôt :

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

Ici :

• Les projets de base Sales et Marketing d’entrepôt restent indépendants et déployables par eux-mêmes.
• La vue pont est créée après le déploiement du schéma via le script post-déploiement.
• Si le déploiement s’exécute plusieurs fois, il est idempotent, car le script supprime et recrée la vue de manière sécurisée.

Étape 4 : (Facultatif) Utiliser des scripts de prédéploiement pour protéger les dépendances fragiles

Dans des scénarios plus avancés, vous pouvez :

• Utilisez un script de prédéploiement pour supprimer ou désactiver des vues inter-entrepôts susceptibles de bloquer les modifications de schéma (par exemple, si vous renommez des colonnes).
• Laissez DacFx appliquer la différence de schéma.
• Utilisez le script post-déploiement pour recréer ou mettre à jour les vues inter-entrepôts.

Étape 5 : Publier l'ordre pour les dépendances gérées par script

Modèle courant pour Zava Analytics :

• Publier des projets de base :
  • Zava.Marketing.Warehouse (schéma principal)
  • Zava.Sales.Warehouse (schéma de base + script post-déploiement inter-entrepôts)
• Laissez le script de post-déploiement Sales créer les vues de pont après que son propre schéma et le schéma référencé Marketing sont déployés.

Si vous introduisez plus de deux entrepôts, répétez ce modèle en couches. Ne créez jamais de dépendances cycliques via des objets projet ordinaires.

Continuer à apprendre

• Combinez ces modèles avec le contrôle de code source et les conseils CI/CD dans le contrôle de code source avec fabric Data Warehouse et les documents d’intégration Git Fabric.
• É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.

Contenu connexe

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