Manager vos Foreign Keys en BI

Bon suite aux posts de Florian http://fleid.net/2011/12/13/pour-ou-contre-les-clefs-etrangeres-dans-le-datawarehouse et de moi-même http://wp.me/p2yhHc-6T sur le « contre » ou le « pour » des Foreign Keys (FKs) dans un DWH, je vous propose un Pattern pour ceux :

  • qui voudraient rester libre (voir anarchiste) et se passer de FKs lors de la phase de l’alimentation (pour faire plein de Truncate et s’affranchir des contraintes, sans jeux de mots)
  • mais qui, avec leur âme de papa, pourraient vouloir les réactiver afin d’exposer aux utilisateurs, les métadonnées « complètes » du DWH (BI Self-Service oblige) et de sécuriser les données qui ont été chargées (les équipes BI ne sont pas les seules à intervenir sur un DWH)

Merci à Florian pour cette analogie anarchiste/papa, j’adore.

Le principe est simple :

  1. designer l’entrepôt avec les FKs
  2. stocker les définitions des FKs et les supprimer les FKs avant chaque alimentation
  3. alimenter l’entrepôt
  4. recréer les FKs

Et pour cela, nous n’avons besoin que d’une table et de deux packages SSIS.

Lire la suite

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

Utilité des schémas SQL Server en BI

Je me sens bien seul ….Suis-je le seul à trouver un réel intérêt à utiliser les schémas sous SQL Server ?

J’en ai bien l’impression, j’ai beau écluser les projets MS BI je ne vois cette fonctionnalité utilisée que trop rarement.

Un Datawarehouse n’est pas seulement une grosse boite noire destinée à l’implémentation de cubes ou de rapports. Les utilisateurs avancés (analystes) doivent pouvoir aussi y accéder. Et c’est d’autant plus vrai dans le contexte actuel. Les utilisateurs BI sont soumis à différentes pressions business et se doivent d’être le plus réactif possible. C’est là tout le sujet de la BI Self-Service à mon sens. Elle permet de répondre à un besoin précis voir ponctuel dans un temps très court sans avoir à subir les contraintes de charge et de planning de l’IT.

Lire la suite