Star schema (Schéma en étoile)

0 comments

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

La définition

La modélisation dimensionnelle structure les données d’une façon très différente de la structure en 3FN ( 3ième forme normale) fréquemment utilisée par les modélisateurs des systèmes OLTP. La modélisation dimensionnelle produit ce qu’on appelle le modèle dimensionnel ou communément le schéma en étoile. C’est la structure de données la plus utilisée et la plus appropriée aux requêtes et analyses des utilisateurs d’entrepôts de données. Elle est simples à créer, stable et intuitivement compréhensible par les utilisateurs finaux. Le modèle dimensionnel est la fondation même de la construction des cubes OLAP.

Il consiste en une grande table de faits ( fact table) et un cercle d’autres tables qui contiennent les éléments descriptifs du fait, appelées « dimensions ». Quand illustré, le modèle ressemble à une étoile, c’est d’ailleurs l’origine du terme « En étoile ».

La figure suivante illustre le schéma en étoile (star schema) :

Star schema

Première Composantes : Table de faits.

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.

Deuxième composante : Table de dimension

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 « 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.

Types de modèles dimensionnels

0 comments

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

La figure suivante présente les différents types de modèle dimensionnel.

Différentes variations du modèle dimensionnel

Modélisation dimensionnelle

0 comments

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

La définition

La modélisation multidimensionnelle été introduite par Ralph Kimball.  Elle consiste en deux nouveaux concepts tels que les faits et les dimensions.

Chaque modèle multidimensionnel est composé d’une table  des faits qui permettent de mesurer l’activité et d’un ensemble de tables dimensionnelles qui contiennent les informations contextuelles faisant varier les mesures de l’activité en question.Chaque table de faits possède une clé qui la relie avec la clé primaire de chaque table de dimension.

Selon l’architecture de Ralph Kimball (Back Room et Front Room), les structures de données dimensionnelles sont la destination ultime des processus ETL et ces tables se positionnent à la frontière entre le Back Room et le Front Room. En général les tables dimensionnelles sont l’étape finale de stockage physique de données avant leur transfert vers l’environnement des utilisateurs finaux.

Le modèle dimensionnel est la structure de données la plus utilisée et la plus appropriée aux requêtes et analyses des utilisateurs d’entrepôts de données. Elles sont simples à créer, stables et intuitivement compréhensibles par les utilisateurs finaux. Le modèle dimensionnel est la fondation même pour la construction des cubes OLAP. Il consiste en une grande table de faits ( fact table) et un cercle d’autres tables qui contiennent les éléments descriptifs du fait, appelées « dimensions ». Quand illustré, le modèle ressemble à une étoile, c’est d’ailleurs l’origine du terme « En étoile ».

Les Quatres étapes de la modélisation dimensionnelle

Pour bien réussir le modèle dimensionnel il est nécessaire de réaliser les quatre étapes suivantes :

  1. Choisir le Processus à Modéliser : Il s’agit de choisir le processus d’affaire à étudier. Un processus une séries d’activités qui transforment des intrants en extrants en y ajoutant de la valeur et ce en faisant appel à différentes ressources humaines, matérielles et financières. Le choix du processus est en général effectué par les utilisateurs finaux ( Un logigramme ou cartographie devrait exister pour documenter le processus d’affaire en question). D’ailleurs c’est à ce stade que l’on essaye de traduire les objectifs des scorecards en KPI dans le cas des DSS d’indicateurs de gestion…
  2. Définir la granularité du processus : Il s’agit de répondre à la question : Que représente un enregistrement de la table de fait ? La granularité définit le niveau de détail contenu dans la table de fait. Voici quelques exemples : Une ligne de commande par produit, par client et par jour. Une transaction bancaire par client par type de retrait et par mois. Il s’agit de l’étape la plus critique lors de la création du modèle.
  3. Choisir les Dimensions : Dans cette étape on doit choisir les différentes dimensions qui représentent le contexte dans lequel le fait a eu lieu. Il est donc question de définir les axes d’analyse.
  4. Identifier les Faits : Pour identifier les faits, il faut répondre à la question : Qu’est ce qu’on mesure ? On peut mesurer le nombre de clients qui ont acheté de la bière, le jour J, au magasin “M”.

Dotation en personnel pour un projet BI/DW

0 comments

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

La vocation et la raison d’être d’un projet de data warehousing et de Business Intelligence est de transformer les données en information et ensuite en connaissance afin faciliter la prise de décision. Il va donc de soit que les ressources requises à la mise en place d’un tel projet soient multidisciplinaires et émanent tant de la business que des TI. Il est aussi commun qu’une seule ressource occupe plusieurs rôles au sein de l’équipe.

Il faut bien noter qu’il est difficile de cerner chacun des rôles dans le détail. La ligne de séparation est très mince et le chevauchement dans les rôles est coutume dans les projets de data warehousing. Par ailleurs, il existe deux scenarios lors de la mise en place d’une équipe du data warehousing, dépendemment de la culture BI de votre organisation :

  • Le scenario de l’utilisateur actif : L’utilisateur final peut créer ces propres solutions analytiques, ses propres rapports, il a accès à toute l’information dont il a besoin et beaucoup plus.
  • Le scenario de l’utilisateur consommateur : L’équipe BI crée les applications analytiques, les rapports et donne accès aux utilisateurs pour pouvoir effectuer des requêtes Ad-Hoc Seulement.

Et selon le contexte et la maturité BI de votre entreprise, les rôles et les responsabilités peuvent changer considérablement.

Le sponsor

Le sponsor du data warehouse est le client ultime du data warehouse et son farouche avocat. C’est la personne qui fait la promotion de la solution BI dans l’organisation, et si celle-ci est large, on peut imaginer un groupe de personnes effectuer ce rôle, on parlera alors d’une sorte de comité de coordination de la solution au complet. Il doit être au courant de tout même des lacunes de la solution, ceci vous évitera de le perdre !

Les utilisateurs :

Il s’agit des utilisateurs finaux de la solution BI. Ils doivent être impliqués le plus souvent tout au long du projet et surtout lors de la définition des besoins d’affaires. C’est eux qui vont utiliser la solution et sans leur approbation du contenu, la solution n’est en soit qu’un exercice technique voué à l’échec. Selon le premier scenario, l’utilisateur crée ses applications analytiques, ses rapports… Il doit être bien formé et disposer d’une expertise assez avancée dans le domaine.

Par contre dans le cas du deuxième scenario, l’utilisateur ne fait que consommer ce qui a été produit par l’équipe BI et c’est au développeur BI de concevoir et réaliser les applications et les rapports.

Le gestionnaire de projet :

Ce rôle est critique. La personne doit être respectée par les membres de l’exécutif de la compagnie et elle doit aussi être crédible. Ses qualités de communication et de gestion de projet sont primordiales.

C’est cette personne qui gère le projet, elle effectue toutes les tâches de planification, contrôle, organisation et de dotation en personnel. Elle effectue aussi le suivi du projet, négocie les échéanciers, le contenu et la qualité des livrables.

Analyste d’affaires :

Ce rôle permet de déterminer les besoins d’affaires et de les traduire en besoin en architecture (Portail), en données (Ad-hoc) et en analyse (Olap). En ayant une bonne connaissance des données et des affaires, il sera en mesure de traduire les besoins d’affaires en terminologie BI (Dimension, fait…) Sans pour autant être un modélisateur de données. Il devrait cependant être dans la mesure de distinguer ce que l’on doit mesurer, comment et dans quel contexte le mesurer

Développeur BI :

Si l’on est dans le premier scenario, ce rôle se restreint à la conception et la réalisation des premiers « templates » pour les applications analytiques, telles que définies par l’analyste d’affaire. On passera par contre beaucoup de temps à supporter les utilisateurs lors de la création de leurs applications analytiques et rapports…

Concernant le deuxième scenario, ce rôle s’occupe de concevoir et développer des solutions analytiques et des rapports clé en main. L’utilisateur final peut utiliser la solution et si le besoin de changer de quoi se fait sentir, une demande est faite à l’équipe BI pour réaliser le développement.

Formateur :

Le formateur doit être très intime avec les données, les applications et les outils de restitution, du fait que la communauté d’affaire n’arrive généralement pas à différencier entre ces différents livrables.

Architecte technique :

C’est le responsable de l’architecture technique et de la sécurité de tout l’environnement. il s’occupe de l’installation du matériel et du logiciel. Elle doit aussi être au courant des tendances et des meilleures pratiques sur le marché concernant les systèmes d’exploitation, les stratégies de backup… et spécialement coté back-room.

Modélisateur de données et de métadata :

En général les modélisateurs de données dans un entrepôt de données arrivent d’un environnement transactionnel ou l’on normalise tout ! Cependant afin de réussir son modèle de données destiné à une utilisation différente des OLTP, il doit maîtriser les concepts de la modélisation dimensionnelle.

Selon votre approche et la suite BI que vous avez choisie, le modélisateur de données doit aussi effectuer de la modélisation du métadata, le référentiel auquel accèdent les utilisateurs finaux, les développeurs BI. L’idéal est que la même personne fasse les deux activités. Le modélisateur de données maitrise son modèle et en connaît les lacunes, ceci lui permettra de réaliser un modèle de métadata avec beaucoup d’aisance et de facilité.

Support du Data warehouse :

Il s’agit d’un autre rôle clé dans l’équipe du projet. Cette personne s’occupe du support de tout l’environnement que ce soit le back-room ou le front room. L’idéal est une personne qui a déjà travaillé sur le projet dans le passé.

l’équipe ETL:

L’équipe ETL se compose des rôles suivants :

Gestionnaire ETL

  • Gérer quotidiennement l’équipe ETL.
  • Définir les standards et procédures de l’environnement de développement ETL (Règles de nomenclature, Meilleures pratiques…)
  • Superviser le développement, les tests et l’assurance qualité.

Architecte ETL

  • Concevoir l’architecture et l’infrastructure de l’environnement ETL.
  • Concevoir le mappage logique de données.
  • Livrer les routines ETL en production.
  • Appréhender les besoins d’affaires.
  • Connaître les systèmes source.
  • Résoudre les problèmes techniques complexes.

Développeur ETL

  • Développer les routines ETL.
  • Tester les routines ETL.
  • S’assurer que les résultats du processus ETL répondent aux besoins d’affaires (Collaboration étroite avec l’architecte ETL)

Spécialiste qualité de données

  • S’assurer de la qualité des données dans l’entrepôt de données en entier.
  • S’assurer que les règles d’affaires sont bien implantées par les processus ETL (en collaboration avec l’analyste système et l’architecte ETL)

DBA

  • Installer, configurer, migrer et maintenir la base de données.
  • Traduire le modèle logique de données en modèle physique.

Approches de mise en place d’un Data warehouse

0 comments

Posted on 11th April 2010 by ELOMARI in Data Warehousing |Gestion de projets BI/DW

, , , ,

Dans cet article nous présentons les différentes approches de mise en place d’un Datawarehouse. Il en existe plusieurs, cependant les plus utilisées sont l’approche “Top-Down” prônée par Inmon, l’approche “Bottom-up” de Kimball et l’approche “Hybride” qui dérive des deux premières approches. Par la suite nous définissons l’approche que nous avons toujours appliquée lors de la mise en place de Datawarehouse à grande envergure.

Les trois approches :

 

 

Top-DownBill Inmon et le CIF Bottom-UpRalph Kimball et le Bus Architecture Hybride
· L’emphase est mise sur le DW.· Commence par concevoir un modèle de DW au niveau de l’entreprise.

· Déploies  une architecture multi tiers composée de  staging area, le DW, et les data mart dépendants.

· Le staging area est permanent.

· Le DW est orienté entreprise; les data marts sont orientés processus.

· Le DW contient des données atomiques; Les data marts contiennent les données agrégées.

· Le DW utilise un modèle de données normalisé de toute l’entreprise; Les data marts utilise des modèles dimensionnels orientés sujet.

· Les utilisateurs peuvent effectuer des requêtes sur le DW et les data marts.

 · L’emphase est mise sur les data marts.· Commence par concevoir un modèle dimensionnel pour le data mart.

· Utilise une architecture qui consiste en un staging area et les data marts.

· Le staging area est en général non permanent, mais il peut devenir permanent pour implanter l’architecture en BUS (Dimensions et faits conformes)

· Les data marts contiennent les données atomiques et les données agrégées.

· Les data marts peuvent fournir une vue entreprise ou processus.

· Un data mart consiste en un seul star schema physique.

· Les data marts sont implantés d’une façon incrémentale et intégrée  en utilisant les dimensions conformes et les faits conformes ce qui constitue ce qu’on appelle l’architecture en BUS.

· Les utilisateurs ne peuvent effectuer des requêtes sur le staging area.

 · L’emphase est sur le DW et les data marts; utilise les deux approches “top-down” et “bottom-up”.· Commence par concevoir un modèle de données de l’entreprise en même temps que les modèles spécifiques.

· Passe  2–3 semaines à créer un modèle normalisé d’entreprise de haut niveau ; génère les modèles des premiers data marts.

· Charge les data marts avec les données atomiques en utilisant un staging area temporaire.

· Les modèles des data marts sont composés d’un ou plusieurs star schémas.

· Utilise un outil ETL pour charger les data marts et pour échanger le méta data avec ces derniers.

· Charge le DW à partir des data marts lorsqu’il y’a besoin de faire des requêtes à travers plusieurs data marts en même temps.

 

Notre approche : Agir localement et penser globalement

  • L’emphase est mise sur les Data Marts avec une vision entreprise.
  • Commence par concevoir un modèle dimensionnel pour le premier data mart.
  • Ce premier Data Mart est donc Le DW à sa première itération.
  • A la constitution du deuxième Data mart, les dimensions et les faits partagés par les deux Data Marts deviennent ce qu’on appelle des dimensions et faits conformes.
  • Déploies  une architecture multi tiers composée de  staging area, du DW, et des data mart dépendants.
  • Le staging area est  temporaire. Il est donc vidé après chaque chargement dans le DW. Il sert à réduire le temps d’extraction et à regrouper les données à transformer.
  • Les data marts contenant les données atomiques sont stockés physiquement dans le DW. Les Data Marts qui contiennent les données agrégées peuvent être stockés dans le DW pour accélérer le chargement des Cubes, sinon les Cubes en soit deviennent des Data marts.
  • Un Data Mart est un ou plusieurs schémas en étoile
  • Le DW est donc une agglomération de Data marts métiers dépendants. Le lien entre ces data marts sont les dimensions conformes et les faits conformes.
  • Les utilisateurs peuvent effectuer des analyses dans les cubes et accéder aux détails dans le DW (Tout cela devrait être transparent aux utilisateurs)

The Agile Manifesto (Le Manifeste agile)

0 comments

Posted on 11th April 2010 by ELOMARI in L'agilité appliquée à la Business Intelligence

L’approche agile est guidée par les valeurs suivantes :

  1. L’interaction avec les personnes plutôt que les processus et les outils.
  2. Un produit opérationnel plutôt qu’une documentation pléthorique.
  3. La collaboration avec le client plutôt que la négociation de contrat.
  4. La réactivité face au changement plutôt que le suivi d’un plan rigide.

et se base sur les principes ci-après :

  1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  2. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  4. Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
  5. Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  6. La méthode la plus efficace de transmettre l’information est une conversation en face à face.
  7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  8. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  9. Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
  10. La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
  11. Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
  12. À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Tout ces valeurs et principes composent ce qu’on appelle le manifeste agile (Signé en 2001, dèjà !!!!)

Limites de l’approche traditionnelle

0 comments

Posted on 11th April 2010 by ELOMARI in L'agilité appliquée à la Business Intelligence

L’approche traditionnelle ( que ce soit en “Waterfall” ou en “Cascade”) n’a pas donné les résultats escomptés surtout lorsqu’il s’agit de projets BI.

Dans une étude effectuée par L’Information Management (DMReview) en 2004, l’analyse des réponses à la question :

Quelle est la durée de mise en place de votre solution décisionnelle ?

se résume dans l’illustration suivante :



Résultat du sondage effectué par Information Management

Résultat du sondage effectué par Information Management

Ce qui explique le constat suivant :

  • Durée moyenne de mise en place :  17  Mois,  5  mois  pour   déployer la première version “fonctionnelle”
  • Coût moyen de mise en place:   $12.8M
  • Au mieux,  35% des mises en place sont une réussite.

La question qui se pose, est ce que l’approche utilisée est le seule “coupable” de toutes ces débacles ?. Bien sur que non, je pense qu’il y’a bien des cas ou cela a bien fonctionnée. Sinon l’approche “Top-Down” de Bill Inmon n’aurait pas survécu depuis le temps. Au fait, pour être raisonnable, il y’a plusieurs facteurs qui font accélèrer l’échec d’une telle initiative, celle de la mise en place d’une solution BI/DW complète. On consacrera un article (ou plusieurs) à cet effet.

Revenons un peu sur l’approche elle même. Pour ce faire je présente le schéma suivant :

Un des facteurs de l’échec de projet BI est l’incapacité à cerner tous les besoins des utilisateurs au premier coup. D’autant plus que ces besoins peuvent changer à une fréquence qui dépend de plusieurs critères, entre autres, le contexte concurrentiel, un cycle de vie de processus et de produit trés réduits… Bref, on ne peut plus demander aux utilisateurs d’être le plus exhaustif et le plus précis possible. Tout simplement le monde des affaires ne leur donne plus cette chance. Ca change tellement vite.

C’est d’ailleurs ce que l’on reproche à cette approche : Aucune interaction avec les utilisateurs avant les tests d’acceptation. On peut donc s’attendre à ce qu’ils rejettent ce qu’on leur donne, même s’il répondait “à peu prêt” à leurs besoins.

Même si on utilise les itérations, chaque itération prend “normalement” entre 6 à 9 mois, imaginez tout ce qui peut se passer pendant ce temps là.

Une alternative à cette approche est l’utilisation de l’agilité. D’ailleurs cela cadre bien, on commence depuis quelques temps à entendre parler de l’entreprise agile. Elle n’a plus le choix…l’entreprise que d’être agile !

Plan de projet

1 comment

Posted on 27th September 2009 by ELOMARI in Data Warehousing |ETL


Tout le monde, ou presque, adhère à la règle que les méthodologies de développement des systèmes décisionnels sont différentes de celles utilisées pour les autres systèmes (opérationnels par exemple). Cependant on ne donne pas encore l’importance nécessaire au volet ETL des projets décisonnel. Il est traité comme une activité, phase ou étape d’un plan de projet global alors qu’il devrait être traité comme un projet à part entière.

La figure suivante présente un bref aperçu du plan de projet ETL :

Comme on peut bien le contaster, il ne s’agit pas d’une petite application si l’on tient compte :
- du nombre de tâches;
- leurs natures;
- les ressources;
- et l’expertise requise;
- et la technologie requise.

Le besoin de traiter l’ETL comme projet à part se fait sentir que ce soit pour mettre en place un datamart ou un entreprise data warehouse.

Par ailleurs il faut noter que le projet ETL s’inscrit dans le cadre de développement de systèmes d’information et donc doit être réalisé en se basant sur une méthodologie de développement. En se basant sur le plan de projet ci-haut je suis entrain d’élaborer une méthodologie ETL de développement des systèmes ETL.

Je suis donc actuellement entrain de travailler sur :
- La description de chacune des activités du projet;
- Les rôles et responsabilités necessaires à la réalisation de chaque activité;
- Les livrables de chacune des activités du projet;
- Les estimés en temps et efforts de chacune des activités du projet;
- Les techniques de gestion utilisées pour cadrer et gérer chacune des activités(Entrevues, architecture technologique…);
- Les points de sychronisation avec la méthodologie de développement global des systèmes décicionnels ( Cycle de Vie Dimensionnel ). Ces points de synchronisation servent à placer le projet ETL dans un cadre de développement de systèmes décisionnels et non pas dans un cadre isolé !

Le plan de projet est disponible en format excel et il est à votre disposition. Donc pour plus d’information ou si vous voulez apportez votre aide, je vous invite à laisser un commentaire ou me contacter abdelelomari@hotmail.com

Rôles et responsabilités

0 comments

Posted on 26th May 2009 by ELOMARI in Data Warehousing |ETL


Si vous disposez de ressources internes qui ont la connaissance et l’expertise nécessaires, vous pouvez les intégrer à l’équipe de projet ETL et selon le besoin les former. Sinon, vous pouvez travailler avec des agences de recrutement pour trouver l’expertise appropriée requise pour construire l’équipe, Sinon vous pouvez aussi faire appel à des experts dans le domaine.

Kimball (2004) a définit huit rôles. Nous présentons les six les plus communs ainsi que leurs responsabilités dans le tableau suivant :

Gestionnaire ETL

  • Gérer quotidiennement l’équipe ETL.
  • Définir les standards et procédures de l’environnement de développement ETL (Conventions de nomenclature, Meilleures pratiques…)
  • Superviser le développement, les tests et l’assurance qualité.

Architecte ETL

  • Concevoir l’architecture et l’infrastructure de l’environnement ETL.
  • Concevoir le mappage logique de données.
  • Livrer les routines ETL en production.
  • Appréhender les besoins d’affaire.
  • Connaître les systèmes source.
  • Résoudre les problèmes techniques complexes.

Développeur ETL

  • Développer les routines ETL.
  • Tester les routines ETL.
  • S’assurer que les résultats du processus ETL répondent aux besoins d’affaire (Collaboration étroite avec l’architecte ETL)

Analyste système

  • Rassembler des besoins d’affaire.
  • Documenter les besoins d’affaire.
  • Travailler en collaboration avec toute l’équipe du DW (Non seulement celle du système ETL).

Spécialiste qualité de données

  • S’assurer de la qualité des données dans l’entrepôt de données en entier.
  • S’assurer que les règles d’affaire sont bien implantées par les processus ETL (en collaboration avec l’analyste système et l’architecte ETL)

DBA

  • Installer, configurer, migrer et maintenir la base de données.
  • Traduire le modèle logique de données en modèle physique.

Les 38 sous-systèmes d’un système ETL

1 comment

Posted on 25th September 2008 by ELOMARI in Data Warehousing |ETL


Les catégories d’outils ETL

Actuellement il existe trois catégories d’outils ETL :

  • Engine-based : les transaformations sont executées sur un serveur ETL, disposant en général d’un referentiel. Ce genre de d’outil dispose d’un moteur de transformation ;
  • Database-embedded : les transformations sont intégrées dans la BD ;
  • Code-generators : les transformations sont conçues et un code est généré. Ce code est déployabe indépendemment de la base de données.
Les 38 sous-systèmes d’un système ETL

J’ai traduis librement les 38 sous-systèmes (The 38 Subsystems of ETL) ou modules d’un système ETL tels que Ralph kimball (2004) les a définit.

Il faut bien noter qu’ils couvrent un éventail des fonctionnalités possibles qu’un système ETL devrait assurer.

Le présent travail est utile puis qu’il permet d’aider :

  • aider les personnes qui veulent développer-maison leurs systèmes ETL en utilisant un langage de programmation du fait qu’il va leur permettre de modulariser le développement tout en créant les interfaces necessaires entre les modules.
  • donner une idée claire et précise au gestionnaire de projet ETL sur la portée et les différentes fonctionnalités à mettre en place ( Si l’on désire développer-maison les processus ETL);
  • aider les personnes dans leurs choix d’un outil ou suite ETL (en plus de notre guide ) de telle façon à vérifier si la suite candidate couvrent ces fonctionnalités;

Voici donc la liste de ces 38 sous-systèmes ansi que les grandes fonctionnalités de chaque sous système :

1 – Système d’extraction – [EXTRACTION]

  • Gestionnaire de connections : Connecteurs aux différentes sources de données (ODBC, Native…) et destinations de données.
  • Mécanisme de filtre et de tri à la source : Ce module devrait permettre d’effectuer l’équivalent de l’utilisation de la clause Where dans un SQL. Formatage et conversion de données (Date, nombre…).Stockage de données dans l’environnement ETL (INSERT, UPDATE, DELETE)

2 – Système de détection des changements (Change data capture ou le CDC) CDC : [EXTRACTION]

  • Lecteur des fichiers de log de bases de données. (Sorte de log miner);
  • Comparateur d’enregistrements selon le CRC.

3 – Système d’analyse de données. [EXTRACTION, TRANSFORMATION]

  • Analyse des propriétés des colonnes.
  • Analyse de la structure des données incluant les clés étrangères, les clés primaires, les relations.
  • Analyse des règles de gestion.

4 – Système de Nettoyage de données. [TRANSFORMATION]

  • En général un système à base de dictionnaire pour analyse de noms et adresses des individus et organisations et possiblement les produits et les emplacement géographiques;
  • Déduplication des données (Le même client peut provenir de plusieurs systèmes)
    Utilisation des techniques de logique floue (peut-être vrai, probablement vrai, peut-être faux, probablement faux)
  • Utilisation des techniques de fusion (Merge).
  • Gestion des clés d’affaires au niveau des systèmes sources.

5 – Système de validation de la conformité de données. [TRANSFORMATION]

  • Identification et renforcement des attributs des dimensions conforme;
  • Identification et renforcement des attributs des faits conformes;

6 – Gestionnaire de dimension d’audit. [TRANSFORMATION]

  • Assemblage des metadata concernant le chargement de chaque table de fait dans une dimension d’audit;
  • Attachement de la dimension d’audit à la table de fait comme une dimension normale.

7 – Système de gestion de la qualité de données. [TRANSFORMATION]

  • Appliquer des tests à la volée à tous les flux de données pour déceler des problèmes de qualité de données;
  • Faire appel au système de nettoyage de données si le cas se présente;
  • Alimenter le système de gestions des erreurs;

8 – Système de gestion des erreurs. [EXTRACTION, TRANSFORMATION, CHARGEMENT]

  • Surveiller et détecter les erreurs en temps réel;
  • Automatiser la reprise après erreur ;
  • Traiter les messages reçus du système de gestion de la qualité de données.

9 – Système de gestion des clés de substitution (surrogate key). [TRANSFORMATION]

  • Produire et gérer d’une façon centralisée les clés de substitution (dimension et fait) ;
  • Être indépendant de la base de données.

10 – Gestionnaire de Slowly Changing Dimension (SCD). [TRANSFORMATION]

  • Gérer les trois types de SCD (Type1 : Écraser, Type 2 : Nouvel enregistrement, Type 3 : Nouvelle colonne)

11 – Gestionnaire des dimensions arrivant en retard. [TRANSFORMATION]

  • Insérer et mettre à jour des données associées (fait ou dimension) à une dimension que l’on reçoit en retard. Par dimension, on veut dire une un enregistrement de la dimension complète. (Ceci implique que chaque dimension dispose d’un horodate dans le système source qui décrit la date et l’heure de la création de l’enregistrement dans ce dernier).

12 – Gestionnaire de dimension à hiérarchie fixe. [TRANSFORMATION]

  • Créer et gérer les dimensions à hiérarchie fixe (Une hiérarchie fixe est une hiérarchie dont le nombre de niveau est fixe et ne change pas dans le temps d’exécution). (many-to-one).

13 – Gestionnaire de dimension à hiérarchie variable. [TRANSFORMATION]

  • Créer est gérer les dimensions à hiérarchie variables (Une hiérarchie variable est une hiérarchie dont la profondeur ou le nombre de niveaux est variable comme par exemple l’organigramme d’un entreprise.

14 – Gestionnaire de dimensions multivaluées (Brige table). [TRANSFORMATION]

  • Créer et gérer les tables associatives utilisées pour décrire les relations many-to-many entre les dimensions ou entre les faits et les dimensions. (la dimension médicament est multivaluée, car un médecin peut prescrire plusieurs médicaments lors d’une visite médicale).
  • Inclure le facteur de pondération. (Optionnel).

15 – Gestionnaire des Junk dimensions. [TRANSFORMATION]

  • Créer et gérer les junk dimension (voire différents types de dimensions).

16 – Système de chargement des tables de faits au niveau de détail le plus fin (grain) [CHARGEMENT]

  • Insérer et mettre à jour les tables de faits au niveau du grain;
  • Manipuler les indexes et les partitions;
  • Utiliser le gestionnaire des lookup. (voire sous-système 19).

17 – Système de chargement périodique des tables de fait au niveau de détail le plus fin (grain). [CHARGEMENT]

  • Insérer et mettre à jour d’une façon périodique les tables de fait dans le détail du niveau de grain.
  • Manipuler les indexes et les partitions;
  • Utiliser le gestionnaire des lookup.(voire sous-système 19).

18 – Système de chargement des tables de fait cumulatives au niveau de détail le plus fin (grain). [CHARGEMENT]

  • Mettre à jour des tables de faits cumulatives;
  • Manipuler les indexes et les partitions;
  • Utiliser le gestionnaire des lookup. (voire sous-système 19).

19 – Gestionnaire des lookup. [TRANSFORMATION]

  • Remplacer les clés d’affaires par les clés de substitution;
  • Être performant lors de la substitution (Multithreaded process)

20 – Gestionnaire des faits arrivants en retard.

  • Insérer et mettre à jour des enregistrements de fait qui arrivent en retard

21 – Gestionnaire d’agrégation.

  • Créer et maintenir des structures d’agrégation qui sont utilisées conjointement avec le mécanisme du Query-Rewrite;
  • Inclure les vues matérialisées

22 – Gestionnaire de cubes multidimensionnels.

  • Créer et gérer la fondation du schéma en étoile pour alimenter les cubes dimensionnels (Cubes OLAP);
  • Préparer les hiérarchies pour alimenter les cubes selon la suite BI utilisée.

23 – Gestionnaire des partitions en temps réel.

  • Maintenir en mémoire seulement les partitions des données des faits qui arrivent depuis la dernière mise à jour.

24 – Système de gestion des dimensions.

  • Répliquer les dimensions conformes à partir d’un emplacement centralisé vers le fournisseur des tables de fait. (Voir le sous-système 25).

25 – Système de gestion des tables de faits.

  • Utiliser les dimensions conformes transmises par le système de gestion des dimensions (24).
  • Substituer les clés étrangères;
  • Vérifier les versions des dimensions;

26 – Ordonnanceur des processus ETL.

  • Ordonnancer et lancer les processus ETL;
  • Être capable de coordonner les processus en tenant compte de différentes conditions de succès ou d’échec de processus;
  • Produire des alertes et envoyer des messages.

27 – Système de surveillance du flux des processus ETL.

  • produire des tableaux de bord et des rapports d’audit pour tous les processus ETL en exécution incluant les horodates, les nombres d’enregistrements traités, les erreurs, les actions réalisées par le moteur ETL ( rejet des enregistrements non concordant lors des lookups…).

28 – Système des recouvrement et reprise.

  • Reprendre l’exécution d’un processus au même endroit que celui-ci a planté;
  • Offrir la possibilité d’arrêter (selon une condition) un processus ETL et le ré-exécuter.

29 – Gestionnaire de parallélisme et de pipelines.

  • Offrir les avantages d’utiliser des processeurs multiples ou l’informatique en grille (Grid computing);
  • Offrir la possibilité de transmission continue de données (pipeline);
  • Offrir le parallélisme automatique et conditionnel des processus ETL.

30 – Système de gestion des erreurs.

  • Gérer les erreurs;
  • Aviser les personnes concernées;
  • Journaliser les erreurs;
  • Système de gestion des erreurs.

31 – Système de contrôle des versions.

  • Gérer les versions du projet ETL;
  • Réserver et replacer les composantes du projet ETL ( Chekc-out, ckeck-in…);
  • Comparaison des différentes versions d’un projet ETL.

32 – Système de déploiement.

  • Migration de l’environnement de développement vers celui de test et de production;
  • S’intégrer ou intégrer le système de contrôle de version pour;
  • Configurer les connexions pour la version;
  • Offrir la possibilité d’exécuter les processus ETL en mode vérification ( Check-only)

33 – Système d’analyse de correspondance et de dépendance.

  • Afficher les sources de données et les transformations subies par un élément de données spécifique (une colonne);
  • Analyser l’impact de changer un élément de données;

34 – Gestionnaire de conformité aux règles.

  • Prouver que les données et les transformations n’ont pas changé et sont conformes aux règles établies;
  • Surveiller les accès et les modifications aux données pour prouver que les données et les transformations n’ont pas changées.

35 – Système de sécurité.

  • Administrer la sécurité sur les données et les métadonnées des processus ETL;
  • Offrir la possibilité de prouver que la version d’un processus ETL n’a pas changé;
  • Afficher qui a effectué les changements.

36 – Système de sauvegarde.

  • Sauvegarder les données et les métadonnées pour le recouvrement, la sécurité et les besoins de conformité.

37 – Gestionnaire de référentiel du méta-données.

  • Collecter et maintenir les méta-données concernat le projet ETL, incluant les processus ETL, les transformations…

38 -Système de gestion de projet.

  • Surveiller toutes les activités de développement, de test du projet ETL;
« Older Entries
Newer Entries »