Importation de bases dans un projet SSDT DB : Gérer les références circulaires

D’une manière générale, il est recommandé d’éviter au maximum les références circulaires entre bases, que ce soit sur un même serveur ou sur des serveurs liés. Par exemple, dans un contexte BI, nous avons une base de staging dans laquelle résident les données brutes et les procédures stockées utilisées, le tout étant employé pour alimenter le Datawarehouse/Datamart (DM sur le schéma).

Dans la plupart des cas, la solution ne fait que déplacer les données de la gauche vers la droite, et rares sont les cas justifiant des appels à la base de staging depuis la base de DM.

Cependant, cela peut arriver et cela va poser problème lors de l’initialisation de notre solution de projets SQL Server sous Visual Studio (SSDT DB).

Si nous pouvons facilement importer la structure d’une base dans un projet SSDT DB, l’import depuis Visual Studio ne complétera pas les références entre plusieurs bases. Pour pouvoir référencer une base depuis un premier projet, il faudra importer cette seconde base de données, builder, et la référencer dans le premier projet.

Lors du build de la solution, Visual Studio construit un fichier .dacpac par projet/base, fichier utilisé pour les références définies dans le projet. VS détermine un ordre logique de build des différents projets de votre solution en fonction des dépendances entre vos projets, ce qui proscrit évidemment les éventuelles références circulaires présente dans notre solution.

Pas la peine d’essayer de contourner le problème en utilisant, comme dans le schéma ci-contre, une troisième base de données. Si la base A fait référence à la base B faisant elle-même référence à la base C (et ainsi de suite) le projet de la base A devra obligatoirement faire référence à la base C, sous peine de ne pas builder.

Il est en revanche possible de « tricher » en utilisant des fichiers .dacpac comme références, ceux qu’on génère directement depuis SSMS:

En réalité, pas exactement ceux générés depuis SSMS, puisque cela se termine en erreur si des références circulaires existent:

Validation of the schema model for data package failed.

Error SQL71562: Procedure: [dbo].[MaProcedure] has an unresolved reference to object [DM].[dbo].[Matable].

Pour contourner le problème, il faudra construire notre fichier par ligne de commande en utilisant le sqlpackage :

C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\sqlpackage.exe" /action:Extract /OverwriteFiles:True /tf:".\ ReportServer.dacpac" /SourceConnectionString:"Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=ReportServer;Data Source=MonServeur

Pendant le processing, on peut observer un mystérieux “Resolving References…” qui n’est pas appelé avec le wizard et qui génère correctement notre dacpac contenant les références. On pourra ensuite partiellement gérer la référence circulaire en référençant le projet d’un côté et le dacpac dans l’autre sens, en préférant la version dacpac pour la base qui subira le moins de modifications.

L’inconvénient majeur de cette solution est la mise à jour « manuelle » des dacpac qui va à l’encontre de l’utilité principale d’un projet SSDT DB : l’automatisation des déploiements.

Elle a le mérite de dépanner temporairement mais, dans la mesure du possible, adaptez votre modèle pour supprimer les références circulaires.