Modélisation Cube – Exposer vos données par des vues

Analysis Services, que ce soit en mode Multidimensionnel ou Tabular, vous permet de vous connecter à votre entrepôt et d’importer les données en sélectionnant des tables, des vues ou bien des requêtes.

Certes l’utilisation de requêtes peut-être très pratique pour :

  • restreindre le périmètre des données à remonter dans le cube,
  • ajouter des colonnes calculées,
  • substituer certains libellés (en règle générale les booléens sont remplacés par des valeurs textuelles)
  • modifier certaines règles de gestions en cas de maintenance correctives afin de corriger une anomalie,
  • etc.

Cela semble tellement attractif que je n’ai pas souvenir d’avoir travaillé sur un cube dénué de requêtes nommées (sauf ceux que j’ai désignés :))

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.

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