ETL : Acheter ou développer ? Guide comparatif

0 comments

Posted on 17th July 2011 by ELOMARI in Data Warehousing |ETL |Gestion de projets BI/DW


La réponse à la question “Acheter ou développer” est « Ça dépend ». Effectivement tout dépend de plusieurs facteurs incluant la nature et l’envergure du projet ETL ! Il est rare qu’une compagnie se lance dans l’aventure de mise en place d’un entrepôt de données si le besoin ne se fait pas sentir par les gestionnaires. De ce fait même si l’entreprise dispose de ressources compétentes pour développer les processus ETL, il est toujours avantageux de se procurer un outil et de former ces mêmes ressources dans le sens de leurs inculquer les notions qui sont propres à un entrepôt de données telles que les faits, les dimensions, l’évolution lente ( Slowly Changing Dimension), les faits qui arrivent en retard ( Late arriving fact)… et aussi de profiter des derniers progrès qu’ont connu les outils ETL.

Cependant dans un but de neutralité nous proposons ici les pour et les contre de chaque choix.

Avantages des suites ETL :
 Développement simple, rapide et moins coûteux. Les coûts de l’outil seront amortis rapidement pour les projets sophistiqués ou de grandes envergures.
 Des ressources disposant de connaissances du domaine d’affaire et n’ayant pas de grandes compétences en programmation peuvent développer avec l’outil.
 La plupart des outils ETL intègrent des référentiels de gestion du métadata, tout en permettant de synchroniser le métadata avec les systèmes sources, les bases de données de l’entrepôt et autres outils BI.
 La plupart des outils ETL permettent la génération automatique du métadata à chaque étape du processus ETL et renforce la mise en place d’une méthodologie commune de gestion de métadata qui doit être respectée par tous les développeurs.
 La plupart des outils ETL dispose de programme intégré qui permet de faciliter la documentation, la création et la gestion de changement. L’outil ETL doit bien gérer les dépendances complexes et les erreurs qui peuvent surgir en cours d’exécution.
 Le référentiel de métadata de la plupart des outils ETL peut produire automatiquement des rapports de mise en correspondance des données (data lineage, looking backward) et d’analyse de dépendance de données (looking forward).
 Les outils ETL disposent de connecteurs intégrés pour la plupart des sources de données. Ils permettent aussi d’effectuer des conversions complexes de types de données (selon la source et la destination)
 Les outils ETL offrent des mécanismes de cryptage de compression en ligne de données.
 La plupart des outils ETL offre une très bonne performance même pour une grande quantité de données. Considérer donc d’acheter un outil ETL le volume de données est grand ou encore s’il va le devenir !
 Un outil ETL peut, le cas échéant, gérer des scénarios d’équilibrage de la charge entre les serveurs.
 La plupart des outils ETL permettent d’effectuer des analyses d’impact automatique suite à un changement.
 Un outil ETL peut être complété ou amélioré en utilisant le scripting ou la programmation.

Avantages des ETL-Maison :
Les outils de tests unitaires automatique sont disponibles seulement pour les outils développé maison. Par exemple Junit .
 Les techniques de programmation orientée objet permettent de rendre consistantes la gestion des erreurs, la validation et la mise à jour du métadata.
 Il est possible de gérer manuellement le métadata dans le code et de créer des interfaces pour la gestion de ce dernier.
 Disponibilité des programmeurs dans l’entreprise.
 Un outil ETL est limité aux capacités du fournisseur.
 Un outil ETL est limité à l’outil de scripting propriétaire.
 Un outil développé maison donne une grande flexibilité si le besoin se présente. Il est possible de faire tout.

Notre expérience dans le domaine nous a démontré que même pour les projets de petite envergure, il est conseillé de développer votre système ETL en utilisant une suite ETL. Nous résumons ici les avantages d’une telle solution :

 Définir une fois, appliquer plusieurs fois (partage et réutilisation)
 L’analyse d’impact
 Le référentiel de métadata.
 L’agrégation incrémentale
 La gestion des traitements par lot.
 Connectivité simplifiée
 Traitements parallèles et équilibrage de la charge
 L’expérience et le support du fournisseur.

Pour les sociétés à petits budgets, il existe des ETL open source qui proposent des fonctionnalités trés avancés dans le domaine à savoir : Talend Open Studio, Pentaho Data Integrator…

 

Justification de projet BI

0 comments

Posted on 16th June 2011 by ELOMARI in Business Intelligence |Gestion de projets BI/DW

Lorsque Gartner a annoncé que 50% des projets décisionnels allaient échouer en 2007, lorsqu’on estime l’investissement initial de la mise en place d’une solution décisionnelle à des centaines de millier de dollars, on a grandement intérêt à disposer d’une justification solide à notre projet.

L’estimation des coûts est assez simple, on y chiffre les coûts des ressources Matérielles (Serveur ETL, MOLAP, et Portail), Humaines (internes et externes), logicielles (Suites ETL et BI, SGBD), les coûts des différentes formations et de la maintenance…Par contre la justification des gains n’est pas aussi évidente.

La technique la plus courante pour calculer les gains d’un projet est appelée ROI.

Qu’est ce que le ROI ? (source : www.12Manage.com)

La Rentabilité d’un Investissement ou Return on Investment (ROI) est une méthode d’évaluation comptable. Le ROI est un ratio de retour qui compare les résultats nets d’un projet, avec ses coûts totaux. Par exemple, si un projet a un ROI de 300%, les résultats nets dérivés de ce projet sont trois fois supérieur aux coûts prévus de mise en œuvre du projet. En tant que tels, le calcul de ROI représente la valeur relative du résultat net cumulatif du projet (résultats moins les coûts) au cours de la période analysée, divisée par tous les coûts cumulatifs du projet, et exprimée en pourcentage.

Puisque le numérateur (revenu net) est un système de mesure de performance d’entreprise peu fiable, le résultat de la formule pour le ROI doit également être peu fiable pour déterminer le succès ou la valeur de l’entreprise. Cependant la formule de ROI apparaît toujours dans beaucoup de rapports annuels…

Le ROI exagère la valeur économique

 

Le degré auquel le ROI exagère la valeur économique dépend au moins de 5 facteurs.

  • La durée la vie de projet. Si c’est plus long, l’exagération sera plus grande.
  • Politique de capitalisation. Si la fraction de l’investissement total capitalisée dans les livres est plus petite, l’exagération sera plus grande.
  • Quel taux d’amortissement est utilisé dans les livres. Les taux d’amortissement qui sont plus rapides que la méthode linéaire auront comme conséquence un ROI plus élevé.
  • Décalage entre les dépenses d’investissements et les gains en retour de ces dépenses dans les rentrés de liquidité. Si le délai est plus grand, le degré d’exagération sera également plus grand.
  • Taux de croissance de nouvel investissement. Les entreprises à croissance rapide auront un Rentabilité d’investissement inférieure.

Calcul de la rentabilité d’un investissement. Formule

Revenu Net / Valeur comptable des Actifs = ROI

Une meilleure alternative est :

Revenu Net + Intérêts (1- taux d’Impôts) / Valeur comptable des Actifs = ROI

Source ( www.12Manage.com).

Justifier le projet de DataWarehouse/Business Intelligence : Estimer les gains

Tous les experts sont d’accord que les gains de la réalisation d’un projet de Data Warehouse/Business Intelligence sont difficilement mesurables à priori. Estimer la rentabilité d’un Data Warehouse revient à répondre à des questions du genre : Que rapporte une décision prise plus rapidement parce que nous avions accès à la bonne information ? Il est difficile de répondre à cette question surtout au début du projet, par contre plaçons cette question autrement : Combien coûte de ne pas savoir cette information à ce moment bien précis ? Peut être rien, peut être aussi des milliers de Dollars !!!

La vraie question alors à se poser n’est pas combien ca va nous rapporter, mais plutôt combien nous allons perdre si nous n’avons pas de Data Warehouse en place.

Par contre, en se basant sur les études, les enquêtes et les sondages effectués pour répondre à toutes ces questions, la mise en place d’une solution décisionnelle permet de réaliser des bénéfices tangibles et intangibles tels que définis dans le tableau suivant :

Consolidation des datamarts
  • Réduction du nombre des datamart indépendants
  • Réduction des coûts matériels et logiciels
  • Efficacité opérationnelle
Economies de temps
  • Moins de temps passé par le personnel IT à extraire les données pour les utilisateurs
  • Moins de temps passé par le personnel IT à écrire des requêtes pour les utilisateurs
  • Moins de temps à rechercher les données
  • Moins de temps passé par les analystes à répondre aux demandes d’information
Une meilleure information
  • Disposer d’une information qui n’a jamais existé
  • Possibilité d’analyser les données sous différents angles
  • Possibilité de voire autrement le Business de l’entreprise
Réduction de coûts de ressources humaines
  • Redéploiement du personnel IT
  • Croissance sans recrutement
  • Utilisation du personnel opérationnel dans des tâches à forte valeur ajoutée
Amélioration de la prise de décision
  • Décision basée sur les faits et non pas sur l’intuition
  • Prise de décision rapide
  • Possibilité de trouver rapidement des alternatives
  • Pro-activité au lieu de la réactivité
Amélioration des processus d’affaires
  • Redéfinition des postes et fonctions (Jobs)
  • Economies de marché
  • Cycle d’affaire plus court
Soutien aux objectifs d’affaires stratégiques
  • Réponse rapide aux changements du marché
  • Augmentation des parts de marché
  • Introduction rapide des nouveaux produits
  • Intégration de la logistique

En résumé, Le plus gros avantage de la mise en place d’un projet DW/BI n’est pas forcément la réduction des coûts, mais plutôt l’augmentation des revenus de l’entreprise. En plus l’utilisation du ROI pour évaluer les gains s’avère très limitée (Inmon, 2000), car de toutes les façons les retours ne peuvent être connus qu’après la mise en place et l’exploitation de la solution décisionnelle.

Cycle de vie décisionnel : Phases

0 comments

Posted on 17th April 2010 by ELOMARI in Gestion de projets BI/DW

  1. Planification du projet : La planification aborde la définition et l’étendue du projet de l’entrepôt, y compris l’appréciation du niveau de maturité de l’organisation face à ce type d’approche. Elle se concentre sur les besoins en terme de ressources et de niveau de qualification, couplés aux affectations des tâches, à leurs durées et à leur séquencement.. La planification dépend bien évidemment des besoins, comme l’indique la flèche en double sens du schéma
  2. Définition des besoins : Il est essentiel de bien comprendre les utilisateurs et leurs besoins, sinon l’entrepôt deviendra rapidement un exercice vain de la part de l’équipe des concepteurs.. L’approche utilisée pour identifier les besoins analytiques diffère de manière significative de la traditionnelle analyse des besoins basée sur les données. Les besoins une fois définis constituent le point de départ de trois trajectoires parallèles que sont la technologie, les données et les interfaces utilisateurs.
  3. Modélisation dimensionnelle : C’est la définition des besoins qui détermine quelles sont les données requises pour répondre aux besoins d’analyse des utilisateurs. La conception du modèle logique de données commence par la construction d’une matrice représentant les processus métier clé et leurs dimensionalités. A partir de cette matrice, il faut effectuer une analyse plus détaillée des données du (des) système(s) source(s) opérationnels. Le résultat de cette analyse est le modèle dimensionnel. Ce modèle identifie la granularité de la table de fait, les dimensions associées avec leurs attributs et leurs hiérarchisations. Cet ensemble d’activités s’achèvera sur le développement d’une mise en correspondance des données sources et cibles dans des méta-données.
  4. Conception du modèle physique : La conception physique d’une base de données définit les structures nécessaires pour l’implémentation du modèle dimensionnel. Les éléments fondamentaux sont la détermination des règles de nommage des objets, la mise en place de l’environnement de la base de données. L’indexation primaire, les stratégies de partitionnement et les agrégations primaires sont également définies. La conception du modèle physique est fortement dépendante de la machine utilisée pour l’entrepôt.
  5. Conception et développement de la zone de préparation des données : La conception de la zone de préparation des données (staging area) constitue généralement la tache la plus sous-estimée du projet entrepôt de données. Le processus de préparation se déroule en trois phases majeures : Extraction, Transformation et le Chargement (Loading).
  6. Définition de l’architecture technique : Cette étape définit la vision globale de l’architecture technique à mettre en oeuvre. Elle nécessite la prise en compte de trois facteurs : Les besoins; L’environnement existant et les orientations techniques stratégiques planifiées. En plus de l’architecture supportant l’entrepôt, il est nécessaire de mener des réflexions sur les outils de conception de la zone de préparation des données et des outils de restitutions.
  7. Choix technologiques et mis en oeuvre : A partir de l’étude de l’architecture technique il faut sélectionner les composants spécifiques, telle plate-forme(s) matérielle(s) et logicielle(s), SGBD outils d’extraction et restitution à mettre en oeuvre. Une fois les produits évalués et sélectionnés, ceux-ci doivent être installés et testés méticuleusement afin de garantir une intégration adéquate d’un bout à l’autre de l’environnement de l’entrepôt.
  8. Développement de l’application utilisateur : Il est recommandé de définir une série d’applications standard destinées aux utilisateurs finaux, car tous n’ont pas besoin d’un accès ad hoc à l’entrepôt. Les spécifications de l’application décrivent les maquettes d’états, les critères de sélection laissés à l’utilisateur et les calculs nécessaires.
  9. Déploiement : Le déploiement est le point de convergence de la technologie, des données et des applications utilisateurs. Une planification est indispensable pour gérer le déploiement qui comprend également la formation des utilisateurs, les processus de communication, le support utilisateur, la prise en compte des demandes d’évolution et de correction.
  10. Maintenance et croissance : Après le déploiement initial de l’entrepôt, c’est sa vie qui commence. Il faut s’assurer de fournir un service de support et de formation continue. Il faut également s’assurer que les processus mis en place pour la gestion de la zone de construction vont faire fonctionner l’entrepôt en continu et efficacement. Il est également important de mesurer périodiquement les performances de l’entrepôt et de son acceptation dans l’entreprise. L’entrepôt va donc évoluer et croître et le changement doit être perçu comme un facteur de succès et non d’échec. Des processus de hiérarchisation des priorités doivent bien sur être mis en place afin de gérer les demandes des utilisateurs en termes d’évolution et de croissance.
  11. Gestion du projet : La gestion du projet garantit que les activités du cycle de vie restent sur la bonne voie et sont bien synchronisées. Cela consiste à contrôler l’état d’avancement du projet, la détection et la résolution des problèmes et le contrôle des changements afin de garantir l’accès aux objectifs du projet.

Cycle de vie décisionnel – Définition

0 comments

Posted on 17th April 2010 by ELOMARI in Gestion de projets BI/DW

Le cycle de vie logiciel, une norme IEEE !

Avant de définir le cycle de vie dimensionnel, nous allons faire un petit retour sur la notion de cycle de vie logiciel.

En général le cycle de vie définit les grandes phases par lesquelles passe une personne, un objet, un produit, etc. Par exemple le cycle de vie d’une personne peut être divisé en trois étapes : l’enfance, l’âge adulte et la vieillesse.

En particulier et dans le domaine du logiciel, le cycle du vie logiciel a été définit sur la base des processus à mettre en place pour le développement des applications logicielles jusqu’à leurs retraits.

Dans le tableau suivant, nous présentons la norme IEE 1074-1995 du  cycle de vie du logiciel :

Titre de la catégorie Processus
Choix d’un modèle de cycle de vie
  • Inventaire des modèles
  • Choix d’un modèle
Gestion de projet
  • Initiation du projet
  • Suivi et contrôle du projet
  • Gestion de la qualité du logiciel
Prédéveloppement
  • Exploration du concept
  • Définition des fonctionnalités et des besoins
Développement
  • Spécification et exigences
  • Conception
  • Implantation
Postdéveloppement
  • Installation
  • Opération et soutien
  • Maintenance
  • Retrait
Processus d’ensemble
  • Validation et vérification
  • Gestion des versions
  • Développement de la documentation
  • Formation

Le  cycle de vie dimensionnel

Il existe plusieurs approches d’implantation des systèmes d’information transactionnels à savoir :

  • L’approche dite classique (en cascade)
  • L’approche en spirale
  • L’approche en V

Cependant les experts s’accordent sur le fait que ces approches ne répondent pas parfaitement aux besoins d’implantation des systèmes décisionnel, ils ont alors définit d’autres approches telles que :

  • L’approche Top-Down de Bill Inmon
  • L’approche Bottom-Up de Ralph Kimball
  • L’approche Hybride.

L’approche Top-Down de Ralph Kimball est traduite par le cycle de vie dimensionnel dont le schéma est présenté dans la figure suivante :

Le cycle de vie dimensionnel

Qu’est ce qu’une table de faits

0 comments

Posted on 17th April 2010 by ELOMARI in Data Warehousing |Modélisation dimensionnelle

La définition

Une table de fait est une table qui contient les données observables (les faits) que l’on possède sur un sujet et que l’on veut étudier, selon divers axes d’analyse (les dimensions). les « faits », dans un entrepôt de données, sont normalement numériques, puisque d’ordre quantitatif. Il peut s’agir du montant en argent des ventes, du nombre d’unités vendues d’un produit, etc.

Les tables de faits représentent des associations dont l’existence d’une occurrence dépend de l’existence des occurrences correspondantes dans les tables dimensionnelles, c’est-à-dire la table de fait contient l’ensemble des mesures correspondant aux informations de l’activité à analyser. Mais rappelons que certaines tables de faits peuvent contenir aucun attribut et représentent que des liaisons entre tables dimensionnelles.

Tous les éléments qui pointent sur la table de faits sont liés à une sémantique exprimable par une phrase. Par conséquent, la table de faits est la matérialisation d’une association entren entités.

Structure de base d’une table de faits

Une table de faits devrait avoir la structure suivante :

Structure de base d'une table de fait

Caractéristiques d’une table de faits :

  • Une table de faits contient les valeurs numériques de ce qu’on désire mesurer;
  • Une table de fait contient les clés associées aux dimensions. Il s’agit des clés étrangères dans la table de faits;
  • En général une table de fait contient un petit nombre de colonnes;
  • Une table de fait contient plus d’enregistrements qu’une table de dimension;
  • Les informations dans une table de fait sont caractérisées par :
  • Elles sont numériques et sont utilisées pour faire des SUM, AVG…
  • Les données doivent être additives ou semi-additives;
  • Toutes les colonnes représentant les faits (mesure1, mesure2.. dans la figure 1)  dans la table de fait doivent référer et avoir un lien direct aux clés de dimensions

Types de dimensions

0 comments

Posted on 17th April 2010 by ELOMARI in Data Warehousing |Modélisation dimensionnelle

Dimension dégénérée (Degenerate dimension)

La dimension dégénérée est une clé de dimension dans la table de fait qui est en général sans attribut. Par exemple No de bon de commande, No d’interruption de service, etc. Dans le cas de numéro de l’interruption de service, les utilisateurs veulent savoir par exemple « combien de fois un client a été interrompu dans une période de temps précise».
Vu qu’il s’agit d’une seule clé de dimension, nous évitons alors de créer une table de dimension, ce qui fait que cette table de dimension a dégénéré dans la table de fait, c’est pour cette raison que cette clé est appelée « dimension dégénérée »

Dimension causale (Causal dimension)

Il s’agit d’une dimension qui provoque des faits. Un bon exemple de ce genre de dimension est la dimension « Promotion » qui en général peut provoquer des ventes. Un autre exemple dans le domaine de la distribution de l’énergie la dimension « Condition climatique » peut provoquer des « interruptions de service ». La dimension « Condition climatique » est donc une dimension causale.

Junk dimension (Fourre-tout)

La dimension de genre « Junk dimension » est une dimension qui contient toutes sorte de flags, statuts, codes qui ne font partie d’aucune dimension régulière. Dans le domaine de la distribution de l’énergie, une interruption de service peut être de type « Basse tension » ou « Moyenne tension ». Ce genre de code est donc stocké dans une table spéciale appelée « Junk dimension ».

Dimension conforme (Conformed dimension)

On parle de dimension conforme ou partagée lorsque la dimension est utilisée par les faits de plus qu’un data mart. L’exemple le plus courant est la dimension « Produit » qui est utilisée par différents data mart «Finance », « Marketing »…

Dimension à évolution lente (Slowly changing dimension)

  1. Un client peut changer d’adresse, se marier, …
  2. Un produit peut changer de noms, de formulations « Tree ’s » en « M&M », « Raider » en « Twix »,« Yaourt à la vanille en Yaourt » en « saveur Vanille »

Nous gérons la situation en choisissant entre 3 solutions :

  1. Écrasement de l’ancienne valeur
  2. Versionnement
  3. Valeur d’origine / valeur courante

Dans certain cas la transition n’est pas immédiate : il reste pendant un certain temps des anciens produits en rayon il est alors conseillé de les traiter comme deux membres différents.

Dimension à évolution rapide (Rapid changing dimension)

Une dimension à changement rapide est une dimension qui subit des changements très fréquents des attributs dont on veut préserver l’historique. Par exemple si l’on veut préserver l’historique des changements d’adresse dans la dimension client dans un pays ou 70% de la population déménage une fois par année (le premier juillet par exemple au canada), la dimension client devient dans ce cas une dimension à évolution rapide.

Mini dimension

Dans tout entrepôt de données il existe au moins une grande dimension, que ce soit en terme d’enregistrements ou d’attributs. L’exemple le plus fréquent est la dimension « client » qui peut contenir des millions d’enregistrements. Le plus souvent on gère l’évolution lente (Voir même l’évolution rapide) sur ce genre de dimension ce qui augmente encore plus leurs tailles. Un moyen de réduire la taille de ce genre de dimension est soit de recourir à la technique de « flocon de neige » si la dimension est hiérarchique (Chaque niveau hiérarchique dans une table différente) ou encore créer une mini dimension, qui contient tous les attributs sur lesquels on gère l’évolution lente. Prenons un exemple pour mieux éclaircir la notion de mini dimension :
La dimension client d’un système de distribution d’énergie contient plusieurs millions d’enregistrements, dont les attributs sont :
ID client « L’identifiant du client, surrogate key ou la clé insignifiante »
Code du client « La clé d’affaire du client, provenant du système source »
Nom du client.

Adresse du client.
Le transformateur associé. « Le transformateur électrique qui alimente le client ».
Code incidence « Le code d’incidence du client : Ma pour Majeur, Mo pour Moyen, Mi pour mineur, Ge pour Grande Entreprise ».
…

Supposons que pour des besoins d’affaires, les utilisateurs décident de préserver l’historique des changements des attributs suivants, « Le transformateur associé » et « Le code d’incidence ». Nous créons donc une mini dimension qui contient les colonnes suivantes :
ID SCD Client
Le transformateur associé
Code d’incidence
Et dans la dimension client nous ajoutons une nouvelle clé de dimension « ID SCD client » pour faire le lien entre la dimension client et la mini-dimension « SCD Client ».

Il faut bien noter que la dimension client continue de contenir tous les attributs même ceux sur lesquels nous gérons l’évolution lente.

Composantes d’une table de dimension

0 comments

Posted on 17th April 2010 by ELOMARI in Data Warehousing |Modélisation dimensionnelle

Composante 1 : surrogate key  ou clé de substitution

La Définition

Une clé de substitution (Surrogate key) est une clé non intelligente utilisée afin de substituer la clé naturelle (Business Key) qui provient des systèmes opérationnels. La clé naturelle est en général composée de plusieurs colonnes.

La clé de substitution ne doit pas être confondue avec la clé artificielle attribuée par les systèmes opérationnels. Du fait qu’il est parfois (voire même souvent) impossible de trouver une clé naturelle pour les entités telles que client, employé, alors on crée une clé artificielle dans le système opérationnel afin d’identifier d’une façon unique un élément de l’entité: client_id pour l’entité client, et emp_id pour l’entité employé. Ces clés artificielles ne doivent pas changer dans le temps pour un client par exemple !

La clé de substitution est alors utilisée dans un entrepôt de données pour remplacer et compléter la clé artificielle du système opérationnel afin de rendre un élément unique dans la dimension.

Les Fonctionnalités

  1. Remplacer la clé naturelle : Effectivement une clé de substitution remplace la clé artificielle en terme d’utilisation, ce n’est plus la clé naturelle qui sera utilisé pour faire les jointures avec les tables de faits ou les autres tables de dimension (niveaux hiérarchiques dans le cas d’une dimension en flocons de neiges);
  2. Complèter l’information :La clé de substitution n’a aucun sens en terme d’affaire, elle est utilisée dans l’entrepôt de données seulement ! et on aura toujours besoin de la clé artificielle ou naturelle dans la dimension pour pouvoir faire la correspondance entre l’élément de dimension (un client par exemple) dans l’entrepôt de données et l’élément de la table des clients dans le système opérationnel.

Les avantages

  1. Performance : Accélère l’accès aux données du moment ou l’on va utiliser un index numérique vu que le type de données de la clé de substitution est numérique.
  2. Indépendance du système source : On ne peut garantir que la clé d’affaire ne change pas dans les systèmes sources.
  3. Historique des changements et granularité infinie : Si l’on désire garder l’historique des changements de la dimension selon certains critères (SCD) nous devons gérer la clé de substitution. Nous nous retrouverons facilement avec plusieurs enregistrements de la même clé d’affaire dans la dimension.

Composantes 2 : attributs

En plus de la clé de substitution et de la clé naturelle, d’autres attributs sont ajoutés à la dimension. Ces attributs sont descriptifs et représente l’information utile sur la dimension (Le salaire d’un employé, l’adresse d’un client…).

Composantes 3: clés spéciales

Chaque table de dimension devrait contenir les colonnes suivantes :

  1. Date effective : c’est la date à la quelle l’enregistrement à été crée, de préférence dans le système d’enregistrements (System of records).
  2. Date retrait : C’est la date à laquelle l’enregistrement a été retiré du système d’enregistrements.
  3. Indicateur effectif : En général est ‘O’ si l’enregistrement est toujours actif (Date retrait non nulle), ‘N’ sinon.

D’autres colonnes peuvent être rajoutées selon le type de l’évolution lente (SCD-Slowly Changing Dimension) que l’on désire implanter. Pour le type 3, une colonne est ajoutée pour contenir la valeur avant le changement

Qu’est ce qu’une dimension

0 comments

Posted on 17th April 2010 by ELOMARI in Data Warehousing |Modélisation dimensionnelle

La définition

Une dimension est une table qui contient les axes d’analyse (les dimensions) selon lesquels on veut étudier des données observables (les faits) qui, soumises à une analyse multidimensionnelle, donnent aux utilisateurs des renseignements nécessaires à la prise de décision.

On appelle donc « dimension » un axe d’analyse. Il peut s’agir des clients ou des produits d’une entreprise, d’une période de temps comme un exercice financier, des activités menées au sein d’une société, etc.

Structure de base d’une dimension

Une dimension devrait avoir la structure suivante :

Structure de base d'une dimension

Caractéristiques d’une dimension :

  • Une table de dimension contient le détail sur les faits;
  • Une table de dimension contient les informations descriptives des valeurs numériques de la table de faits;
  • Vu que les données dans la table de dimensions sont normalisées, elle contient un plus grand nombre de colonnes;
  • Une table de dimension contient en général beaucoup moins d’enregistrement qu’une table de faits;
  • Les attributs d’une table de dimension sont souvent utilisés comme « Lignes » et « Colonne » dans un rapport ou résultat de requête. Par exemple, les attributs textuels d’un rapport proviennent souvent d’une dimension

Star ou Snowflake

0 comments

Posted on 17th April 2010 by ELOMARI in Data Warehousing |Modélisation dimensionnelle

Schéma en étoile Vs Schéma en flocons de neige.

A la question « Entre le schéma en étoile et le schéma en flocons de neige, quel est le modèle qui  présente la meilleure performance ? » une multitude de réponses existe ! Nous avons choisi celle de Mr Tom Haughey (Cliquez-ici pour accéder à la réponse en anglais) parce qu’elle permet de mettre en évidence la différence entre les deux schémas et ce en se basant sur des situations et cas réels.

Après avoir eu l’autorisation de l’auteur, nous avons traduit sa réponse comme suit :

Définition des deux modèles

Commençons tout d’abord par définir les deux modèles.

Un schéma en étoile est une structure dimensionnelle qui représente une seule table de faits entourée par un seul cercle de dimensions. Toute dimension à niveaux multiples est aplatie en une seule dimension. Le schéma en étoile est conçu pour répondre à des requêtes inhérentes à la structure dimension-fait.

Un schéma en flocons de neige est aussi une structure dans laquelle une seule table de faits est entourée par un seul cercle de dimensions. Cependant pour toute dimension à niveaux multiples au moins un niveau de dimension est géré dans une structure séparée des autres niveaux. Le schéma en flocons de neige est conçu pour répondre à des requêtes sur une dimension ayant des relations complexes entre ses niveaux. Le schéma en flocons de neige est approprié aux dimensions dont les niveaux sont reliés par des relations n à n et 1 à n.  Par ailleurs, le schéma en flocons de neige devient obligatoire pour une relation dimension-fait de n à n. Un bon exemple est la relation entre la table des clients et celle des polices d’assurance dans le domaine des assurances. Un client peut disposer de plusieurs polices d’assurance et une police d’assurance peut couvrir plusieurs clients. Les principales justifications à l’utilisation d’un schéma en étoile sont la performance et la facilité de compréhension. La simplicité est l’un des aspects attrayants du schéma en étoile. Alors que le schéma en étoile est généralement considéré comme la structure qui offre la meilleure performance, il n’est pas souvent le cas. En général, quand c’est faisable, le schéma en étoile devrait être le premier choix. Cependant quelques exceptions importantes existent. La suite de cette réponse adresse ces situations.

1 – La technologie

Certaines technologies telle que MicroStrategy requièrent un schéma en flocons de neige alors que d’autres comme Cognos requièrent le schéma en étoile. Facteur à ne pas négliger !

2 – La nature des requêtes

Certaines requêtes se prêtent mieux à la structure dimension-fait. Pas forcément toutes les requêtes mais quand c’est le cas un schéma en étoile est le meilleur choix.

3 – Besoins d’affaires spécifiques

Ils existent des besoins d’affaires qui ne peuvent tout simplement pas être structurés en schéma en étoile. La relation entre l’entité « client » et  l’entité « compte » dans le domaine bancaire, celle entre l’entité « client » et l’entité « police d’assurance » dans le domaine des assurances ne peuvent être représentées par un schéma en étoile à cause de la relation n à n qui lie ces entités. Vous n’avez pas d’autres choix raisonnables que de choisir un schéma en flocons de neige. Il existe plusieurs autres exemples analogiques. Le monde n’est pas une étoile et ne peut pas être forcé à s’y adapter !

4 – Besoin de flexibilité

Le schéma en flocons de neige devrait être utilisé lorsque l’on a besoin d’une plus grande flexibilité dans la corrélation à travers les niveaux et les composantes d’une dimension. L’avantage principal d’un flocon de neige est la plus grande flexibilité dans les données.

5 – Ratio Attributs Maître : Nombre de rangées Détail

Prenons l’exemple typique des données des « commandes » dans l’entrepôt de données. Le concepteur dimensionnel ne se poserait pas de question à aplatir la table des « commandes » et celle des « Lignes de commandes ». Cependant, considérez ce qui suit. Disons que 25 attributs communs à la commande sont dans la table des « commandes ». On vend des produits de consommation et une livraison typique contient 50 produits, on se retrouve ainsi avec 25 attributs ayant un ratio 1:50. Dans ce cas de figure, il serait excessivement encombrant d’aplatir la table des « commandes » et celle des « Lignes de commandes » pour réaliser le schéma en étoile. Dans une table de faits énorme on introduira beaucoup de redondance pour, disons, plus de 2 milliards de rangées. D’ailleurs, dans le modèle de Walmart, qui est un des plus célèbres, la table des « Commandes » n’est pas aplatie avec celle des « Lignes de commandes ». Cependant, si vous disposez d’un magasin de vidéos, avec peu d’attributs dans la transaction et un ratio moyen de 1:2, il serait mieux d’aplatir les deux tables en une seule table de fait.

6 – Gestion complexe de SCD

Prenons l’exemple de dimensions à évolution lente (Slowly Changing Dimensions). Disons que la dimension  « Employé » consiste en des données qui ne changent pas (Ou même si ça change ce n’est pas important, c à d de type 1) et d’autres données qui changent (type 2). Disons aussi que vous avez un intérêt envers les données de l’employés qui ne changent pas (Vous voulez toujours avoir la valeur courante) et non pas les données qui changent. Le modélisateur dimensionnel va donc mélanger les deux types de données en créant une dimension à évolution lente de type 2. Ce qui veut dire que le type 1 est absorbé par le type 2. J’ai travaillé sur des cas où le fait d’aplatir à causer plus de problèmes, il était mieux de scinder la dimension en deux tables « Employé » qui regroupe les attributs de type 1 et « employé historique » qui regroupe ceux de type 2.  De ce fait, quand il s’agit de cas complexe de gestion de l’évolution de dimension,  un schéma en flocons de neige est préférable.

7 – Difficulté de navigation dans les hiérarchies

Le constat que le schéma en étoile est plus compréhensible que le schéma en flocons de neige est complètement subjectif.  J’ai personnellement travaillé sur plusieurs entrepôts de données où les utilisateurs se sont plaints que dans le schéma en étoile, et parce que tout a été aplati, ils ne pouvaient pas comprendre les hiérarchies des dimensions.  C’était le cas, en particulier, quand la dimension est composée de plusieurs colonnes.

De la théorie à la pratique

Il serait profitable de passer de la théorie à la pratique en effectuant des tests. Chose faite, j’ai pris un modèle de données contenant une grande table des clients et je l’ai testé en tant que schéma en étoile et en flocons de neige. La dimension des clients est composée de plusieurs attributs.  Nous avons utilisé quelques 150 millions d’enregistrements. J’ai scindé la dimension des clients en trois tables avec des relations 1:1:1. Le schéma en flocons de neige était plus rapide. Pourquoi ? La dimension étant large (dans le sens que celle-ci contient plusieurs attributs), le SGBD pourrait traiter seulement un petit nombre d’enregistrements par page. Vu que Le SGBD utilise ce qu’on appelle « la lecture anticipée » (pre-fetch) des données, il est capable de lire moins d’enregistrements que lorsque la dimension contient moins d’attributs. Si c’est votre cas, assurez-vous donc de scinder votre table dépendamment de l’utilisation des données. Regroupez les données dans différentes tables ayant une relation 1:1:1 et qui sont utilisées conjointement.

Moralité de l’histoire !

Quelle est la moralité de l’histoire ?  Je pense qu’il faut être prudent lorsqu’il s’agit de déterminer la meilleure solution.  Un certain nombre de facteurs importants entrent en jeu et se doivent d’être considérés.

Snowflake (Schéma en flocons de neige)

0 comments

Posted on 17th April 2010 by ELOMARI in Data Warehousing |Modélisation dimensionnelle

La définition

Le schéma en flocons de neige est une variante du schéma en étoile. Dans la théorie la différence réside dans la simple normalisation des tables de dimensions. Il est donc tout simplement question de mettre les attributs de chaque niveau hiérarchique dans une table de dimension à part.

La figure suivante illustre le schéma en flocons de neige (snowflake schema) :

Snowflacke

Explication du schéma

Pour bien comprendre ce schéma, veuillez lire le schéma en étoile de la figure 1 dans l’article concernant le schéma en étoile. Retenez la liste des composantes de la dimension “Produit”. cette dimension est composée de ce qui suit :

La dimension produit

Cette dimension dispose de 3 niveaux hiérarchiques : Type Produit, Catégorie et Produit.  Le résultat du “floconage” de cette dimension nous donne le schéma suivant :

La dimension produit eclatée

Tous les attributs de chaque niveau hiérarchique se retrouvent dans une table isolée. Une table donc pour les types de produit, une autre pour les catégories de produit, et la dimension produit. La dimension produit est ce qu’on appelle la dimension ayant la granularité la plus fine. Celle ci est reliée à la dimension Type Produit via la clé étrangère “Type Produit”. La dimension “Type Produit” est à son tour reliée à la dimension “Catégorie Produit” via la clé étrangère IdCatégorie.

Veuillez bien qu’il s’agit d’un exemple simpliste, alors que dans la réalité, et surtout lors de l’implantation du concepts du SCD (Slowly changing Dimension ou Evolution Lente), les choses se compliquent plus !

“Floconner” les faits ??

Nous croyons fortement que dans des cas bien spécifiques on est obligé pour des raisons de performance, simplicité et de convivialité de normaliser la table de fait. L’exemple le plus concret est la création de deux tables de faits, une pour les commandes et l’autres pour les lignes de commandes (Cas de l’entrepôt de données de Wall Mart, lire notre article là-dessus “Star Vs Snowflake” et plus précisément le paragraphe intitulé « Ratio attributs maître / Nombre de rangées détails).

Quand utiliser un schéma en flocons de neige ?

Le choix de « snowflacker » ou pas n’est pas toujours évident, plusieurs critères sont à prendre en considération à savoir :

  • Le nombre de niveaux hiérarchiques de la dimension;
  • La gestion de l’évolution lente (SCD type 2)
  • La taille de la dimension
  • La nature de l’analyse à effectuer.
« Older Entries