5 bonnes raisons d’utiliser les Foreign Keys dans un DWH

Il s’agit là d’un sujet à controverse. Bon nombre de BI Pros estiment qu’il ne faut pas déclarer les Foreign Keys sur un entrepôt car les contraintes d’intégrités sont « sensées » être gérées dans vos lots SSIS et qu’elles ralentissent les performances lors de l’alimentation des tables de faits.

Et là je dis NON !  Quelles sont pour moi les 5 raisons principales pour lesquelles il faut déclarer des Foreign Keys :

 #5 – Les Foreign Key ne dégradent pas de façon significatives les performances d’intégration. Si tel est le cas, c’est peut-être parce que votre intégration elle-même n’est pas bonne (chargement de plusieurs millions de lignes en annule/remplace plutôt qu’en incrémental), architecture non optimisée (avez-vous partitionné vos tables de faits ? Si oui les alimentez-vous en utilisant le partition switching ?) Si toutefois, elles entravent toujours vos durées d’intégration, SSIS vous permet toujours de passer outre, il suffit de cocher la bonne case sur les composants d’insertion.

OLE_DST - Without CheckConstraints

 #4 – L’ordre d’exécution des packages SSIS doit suivre la logique du modèle (on charge d’abord les dimensions avant de s’occuper des tables de faits). Or sans contraintes d’intégrités rien n’empêche de faire une opération de nettoyage sur une dimension alors que les données de faits ont déjà été chargées. Petit rappel au passage; que vous implémentiez du Tabular ou du Multidim, un seul type de modélisation convient : l’étoile !

 #3 – Il n’est pas rare de se plugger directement sur les sources de données SQL des outils opérationnels (ERP et autres applications tierces), seulement le business n’attends pas de voir et d’avoir les impacts que des évolutions et/ou migrations peuvent avoir sur le décisionnel. Cela peut donc changer l’essence même des données et il est préférable de s’en rendre compte immédiatement par une erreur de votre chaine d’intégration plutôt que de s’en apercevoir 3 à 6 mois après et d’avoir ainsi un chantier beaucoup plus vaste (évolution de la chaîne d’intégration, correction des données dans l’entrepôt …)

 #2 – Dans un contexte de compétitivité sans cesse grandissement, la demande BI Self-Service va croitre rapidement. Or cette dernière n’est pas antinomique avec la BI Corporate. Les deux sont bel et bien complémentaires (je vous renvoie pour cela à l’excellent post de Chris Webb http://t.co/dcVphdzI ). Or la BI Self-Service va s’appuyer en grande partie sur l’entrepôt que vous aurez modélisé. Et là rien de tel que les clés étrangères pour faciliter et s’assurer de la bonne construction du modèle d’analyse (Tabular ou Multidim)

 #1 – Un entrepôt reste avant tout une base de données relationnelle, et s’administre de la même façon : plan de maintenance, de sauvegarde, d’indexation, de statistiques …. Et bien entendu des contrôles d’intégrités référentielles. Cette dernière étape est très peu utilisée sur un entrepôt et pourtant les bugs çà existent (règles de gestion omises ou non connues par le métier, cas particuliers non recettés, etc…)

 Bon j’espère vous avoir convaincu.

Gestion dynamique des partitions SQL Server

Si vous travaillez sur un entrepôt à haute volumétrie, vous serez certainement confronté à des problèmes de performances pour alimenter et requêter les tables les plus volumineuses. Pour résoudre ces problèmes vous devrez avoir recours au partitionnement (fonctionnalité disponible depuis SQL Server 2005, je le précise car il y a quelques irréductibles qui utilise « encore » du 2000).

La mise en œuvre du partitionnement n’est pas la plus complexe qui soit ; seulement le faire une fois c’est bien, mais réinventer la roue sur chaque projet ça use. Voyons comment nous pouvons industrialiser pour tous nos projets BI la création et la gestion des partitions sous SQL Server. Lire la suite