jeudi, septembre 29, 2005

Système ETL ou The Back Room

Les entreprises, aux débuts des entrepôts de données, avaient mis beaucoup d’emphase sur la présentation et l’utilisation finale d’un DW. Avec l’accroissement du volume de données elles se sont, ensuite, focalisées sur la modélisation dimensionnelle. De nos jours l’accent est plutôt mis sur les systèmes ETL.
Que ce soit un outil commercial ou développé maison, l’ETL n’est pas un simple programme d’extraction, transformation et de chargement et ne doit pas être traité de la sorte. Il s’agit plutôt d’un système complexe. D’ailleurs Kimball (2004), après dix huit mois d’études des ETL, en a définit 38 sous-systèmes et il a même statué, et pour raison, que 70% d’un projet d’entrepôt de données est dédié aux systèmes ETL.

Par le biais du présent blog nous tentons de partager notre expertise et nos connaissances des systèmes ETL. Nous étalons alors les différentes étapes de la réalisation d’un projet de système ETL, partant de la planification du projet jusqu’à l’implantation et la maintenance. On y discutera aussi du choix de l’outil, la dotation en personnel et les différentes notions ayant traits aux systèmes ETL.

Les termes Back Room (la cuisine) ou Data staging area sont souvent utilisés par l'industrie pour décrire les systèmes ETL. Le Back Room ou le staging area est utilisé pour préparer les données pour le Front Room (la salle à manger). Le terme français du back room est "zone de ravitaillement de données", selon le grand dictionnaire (www.granddictionnaire.com) ou encore "zone de transit de données". Personnellement j'utilise souvent le terme "Zone de préparation de données" .

Ce blog n'est pas complètement terminé, par contre nous n'aménageons aucun effort pour le complèter.

Pour des raisons de Copyright, nous devons mentionner que quelques passages dans ce blog ont été traduit librement par Abdel ELOMARI à partir du livre de ralph Kimball et Joe Caserta sur les systèmes ETL dont la référence est la suivante :

Kimball, R., & Caserta, J. (2004). The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering Data., Wiley.

Fil atom


Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.





mercredi, septembre 28, 2005

Back Room & Front Room


Les composantes et processus ETL

Comme nous l'avons déjà mentionné, un système décisionnel est formé de deux principales composantes le Back Room et le Front Room.

Le Back room ou encore la zone de préparation de données réalise les services suivants :
- l'extraction des données à partir des systèmes sources;
- la transformation des données ( Normalisation, standards, nettoyage, audit, Conformance...) ;
- le chargement des données que ce soit dans un DW ou dans un Data Mart; - Un service qui est plus au moins récent qui est celui de fournir de l'information aux systèmes sources ( Exemple : Selon les analyses d'habitudes d'achats effectuées dans l'entrepôt de données on communique à des systèmes temps-réels des informations utiles pour afficher des bannières de publicités qui sont susceptibles d'interesser un client en particulier... La technique utilisée pour stocker l'expérience d'achat s'appelle le Click-Stream...)

Le Front room est la composante qui permet de réaliser des services comme :
- L'analyse de données via des rapports ou des cubes (OLAP, Report ADhoc,...) ;
- le forage et l'exploration de données en utilisant des outils spécialisés ( SPPS, SAS...) ;
- les requêtes ADhoc pour retrouver une données dans le passé parmi les données historisées ( Le rôle le plus vieux d'un système décisionnel)

Cependant il ne faut pas limiter l'utilisation des outils ETL à l'alimentation des entrepôts de données, car un système ETL pourrait bien être utilisé pour intégrer les données d'applications réparties ou encore centraliser les données de différents systèmes dans une seule bases de données...


Dans la figure suivante, nous proposons une architecture qui met en évidence les deux composantes et les services fournis par chacune de ces dernières :


Figure : Architecture générale d'une solution décisionnelle.

La figure suivante présente, en plus des éléments de bases d'une solution décisionnelle, les processus élémentaires de traitement :


Figure : Eléments et processus de base d'une solution décisionnelle.

Voici une explication de chaque élément et de chaque processus :


Les systèmes opérationnels
En général les entrepôts de données sont alimentés à partir de systèmes opérationnels dans le but de transformer les données transactionnelles ( Ou opérationnelles ) d'un processus d'affaire en information qui sera utile à la prise de décision. Cependant il faut bien noter que les entrepôts de données peuvent aussi puiser leurs données dans d'autres entrepôts de données, dans un ODS, ERP ou CRM. Prenons un exemple pour mieux comprendre le besoin d'extraire les données d'un système CRM : dans chaque entrepôt de données il est fort probable qu'une table des clients existe. Dans un but d'intégration il n'est pas question de disposer de cette table autant de fois qu'il y'a d'applications dans l'entreprise. Normalement, une seule application CRM permet de gérer cette table et de fournir au autres applications une vue de cette table. Évidement on peut imaginer toute sorte de mécanisme ( Réplication , Snapshot...) pour que ces applications disposent de cette table à jour. Dans le même sens il est donc conseillé dans la cas de l'entrepôt de données d'extraire cette table du système CRM au lieu de l'extraire du système opérationnel du processus que l'on veux analyser ou étudier.
Il existe plusieurs strutures de données dans ces systèmes opérationnels, les données que l'on désire extraire peuvent donc résider dans une base de données, dans des fichiers plats, ou encore dans des systèmes patrimoniaux ( Legacy systems). On peut aussi extraire les données à partir des fichiers log du Web dans le cas des entrepôts de données d'analyse des click-stream...
Extraction
L'extraction des données est la première étape dans les systèmes ETL. Elle permet de lire les données à partir des systèmes sources. Selon la nature de ces systèmes sources ( 24/7, critique...) l'extraction peut s'avérer critique et très exigeante dans le sens ou il faut la réaliser le plus rapidement souvent et ce en exploitant au minimum les ressources du système source. En général les extractions sont lancées la nuit durant ce l'on appelle un Extract Window sur lequel on s'est mis d'accord. La complexité de l'extraction n'est pas dans le processus de lecture, mais surtout dans le respect de l'extract window. C'est pour cette raison que l'on effectue rarement des transformations lors de l'extraction d'une part. D'autre part, on essaye au maximum d'extraire seulement les données utiles ( Mise à jour ou ajoutée aprés la dernière extraction) et pour ce faire on pourrait s'entendre avec le responsable du système source pour ajouter soit un flag ou encore des dates dans chacune des tables extraites, au moins deux dates : Date de création de l'enregistrement dans la table et la date de mise à jour ( En général la plupart des systèmes sources disposent de ces deux dates ) . Par ailleurs pour ne pas perdre des données suites à des problèmes d'extraction, il est important de s'assurer que le système source ne purge pas les données avant que l'entrepôt ne les aies extraits.

Transformation
La transformation est la tâche la plus complexe et qui demande beaucoup de reflexion. Voici les grandes fonctionalités de transformation :
- Néttoyage des données
- Standardisation des données.
- Conformance des données.
... à venir

Chargement
Cette fonctionalité des systèmes ETL est une source de beaucoup de confusion, selon la situation elle permet :
1) de charger les données dans l'entrepôt de données qui est théoriquement la destination ultime des données ;
2) ou de les charger dans des cubes de données.

La réponse est différente selon le choix de votre solution BI :
- Si vous avez choisi de batir des datamarts, et de ne pas stager (Donc pas de DW comme tel) les données nous pouvons considèrer la deuxième option. Il est donc question de charger les données directement dans des cubes de données sans les stocker dans un DW. Cette approche est certainement la plus proche à celle de Ralph Kimball. Un bon exemple est l'utilisation direct des cubes de données cognos.
- Si vous avez choisi de construire un entrepôt de données avec une base de données, alors la destination ultime des données est l'entrepôt. Donc le Chargement permet de stocker ces données dans un entrepôt de données. Cette approche est proche à celle de Bill Inmon. Vous pouvez alors utiliser des focntionalités analytiques comme Oracle le permet.
- Une troisième option est c'est celle que je préconise et qui offre plusieurs avantages mais demande par contre plus d'effort. Le chargement des données se fait en deux étapes :
  • Un premier chargement des données dans un entrepôt de données.
  • Un deuxième chargement dans des cubes de données.
les avantages de cette façon de faire :
  • La possibilité de rechargement des cubes, parceque les données sont stockées dans une base de données de l'entrepôt de données.
  • La possibilité de garder les faits et les dimensions dans leur détail de grain le plus fin.
  • La possibilité de créer des agrégats...
  • Plus de flexibilité à retraiter les données, les corriger, appliquer des redressements autorisés par les gens d'affaires, tâches qui ne sont pas facile dans un médium de stockage dimensionnel. ( Je ne sais pas comment on peut retoucher les données déjà stockées dans un cube Powerplay...);
  • Ne pas avoir à charger le détail dans les cubes (Certains cubent représentent plusieurs limitations dans ce sens, il n'est donc pas facile de charger une grande quantité de données dans un Cube). On utilise les cubes pour les analyses de plus haut niveau, et quant il est question d'accèder au détail le plus fin de l'information on fait une lecture dans la BD de l'entrepôt de données.
Par contre cette approche ajoute une charge de travail trés considérable pour l'équipe de développement (Aucun impact sur les utilisateurs) :
  • Une base de données à créer et à maintenir, donc un DBA et un ADD.
  • Un exercice de reflexion sur le modèle de données du DW ( En général ROLAP).
  • Un autre excercie de reflexion sur le modèle des métadonnées (En général MOLAP)
A vous donc de choisir votre approche !
feedback

Le feedback concerne les deux aspects suivants :
- Informer le système source du résultat de l'extraction : réussite, échec, date dernière extraction, date prochaine extraction...
- Transmettre de l'information aux systèmes sources ( parfois aussi à l'ODS). L'exemple le plus citée est celui lorsque l'entrepôt de données aprés analyse des click-streams de l'expérience de navigation d'un client (Que l'on reconnait par son adresse IP) renvoit de l'information aux systèmes opérationnels dans le but d'afficher les bannières les plus appropriées !!


Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

mardi, septembre 27, 2005

Plan de projet





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

Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

lundi, septembre 26, 2005

Rôles et responsabilités





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.

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.
Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

dimanche, septembre 25, 2005

Les 38 sous-systèmes d'un système 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;

    samedi, septembre 24, 2005

    Acheter ou développer ? Guide comparatif


    Pour le choix de l'outil veuillez vous référer au lien suivant :
    http://systemeetl.blogspot.com/2005/09/choix-doutil-etl.html


    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.

    Si vous décidez d'acheter une suite, nous vous proposons le lien suivant que nous avons mis en place pour vous guider d'une façon neutre dans votre choix
    http://systemeetl.blogspot.com/2005/09/choix-doutil-etl.html

    Choix d'outil ETL




    Choix d’outil ETL ( Suites ETL)


    Avant de commencer à réaliser des preuves de concepts il est conseillé de faire des choix préliminaires.

    Choix préliminaires :Une fois que vous avez décidé d’acheter une suite ETL, une question se pose rapidement, parmi cette panoplie d'outils, lequel choisir ?. Actuellement il existe plusieurs fournisseurs de suite ETL

    Dans le domaine professionnel avant d’acheter un outil surtout quand celui-ci est dispendieux on procède à des preuves de concept. Cependant il est quasiment impossible de faire des preuves de concept de toutes les suites ETL disponibles sur le marché. On procède alors à un choix préliminaire de telle façon à garder deux ou trois suite ETL à tester . ce choix préliminaire est en général basé sur les critères suivants ;

    La catégorie de l’outil :
    Actuellement il existe trois catégories d’outils ETL :
    1. 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 ;
    2. Database-embedded : les transformations sont intégrées dans la BD ;
    3. 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.
    Sachant que le type de l’outil a un impact direct sur l’architecture technique ( Matérielle et logicielle) et les ressources humaines necessaire à la réalisation du projet, il est donc bon d’être conscient de ces trois types d’outil ETL, et décider quelle type répond le plus aux besoins.
    Le coût (ou encore le ROI)
    Le coût ne concerne pas seulement la suite en soit ( Le logiciel), mais cela prend aussi en compte les coûts des ressources humaines et matérielles. Les suites les plus complètes disposent d’un moteur qui roule sur des serveurs assez puissant ( coût du serveur) , et dont le referentiel (pour le code et pour le métadata) est stocké dans une base de données et de préférence une bonne base de données ( coût de la base de données, Oracle, DB2, SqlServer), et en plus si l’on veux le connecter avec d’autres couches applicatifs disons non-standards, il faudra aussi payer pour le connecteur. Par ailleurs les ressources humaines présentent des charges assez importantes, j’explique cela en détail un peu plus loin dans l’étude. Il faut aussi que l’outil permet un bon ROI au niveau de la productivité, la qualité des données (Une bonne décision) et la disponibilité de l’information (Une décision à temps).
    La nature et l’envergure du projet ETL.
    Par ailleurs si le projet est d’une bonne envergure, étalé sur plusieurs mois et en plusieurs étapes, une solution ETL s’impose. Cependant si le projet ETL est complexe, il faudra envisager d’acheter une suite ETL assez complète comme Informatica, Data Stage ou Data Integrator ou encore DecisionStream... Par contre si le projet est du type « Straight-forward » une solution comme OWB ou Sunopsis peut suffire.
    La culture analytique de l’entreprise
    De plus en plus il existe une sorte de fidélité et de solide partenariat entre les entreprises et les fournisseurs de solutions BI et ETL. Par exemple il y’a des entreprises qui disposent de Business Objects comme solution BI, il est donc logique d’acheter Data integrator comme outil ETL. La même chose pour Cognos, Oracle...

    Ce que disent les expertsUn autre moyen à utiliser lorsque l’on désire effectuer le choix d’un outil ETL est de se renseigner et de disposer du maximum d’informations concernant :
    - La situation financière du fournisseur;
    - sa stratégie : on voudra pas acheter le produit d’un fournisseur qui risque de faire faillite dans 6 mois;
    - sa stratégie à l’égard de la suite ETL de l’entreprise : on ne vaudra pas acheter une suite ETL si le fournisseur risque de délaisser ce produit parcequ’il ne fait plus partie de sa stratégie d’affaire;
    - Le nombre de ces clients;
    - Le nombre de ces employés;
    - Le support dans votre pays;
    - En plus les critères d’ordre technique (Extracteurs, transformateurs et chargeurs).

    Dans le but d’avoir toutes ces informations, nous conseillons de faire des recherches sur Internet, dans les revues spécialisées...Concernant l’internet le groupe Gartner est incontournable dans le milieu.

    Gartner :Gartner produit ce qu’on appelle les quadrants magiques des ETL (au moins deux fois par année). Le premier de l’année 2005 est comme suit :

    A vous de décider !

    JDNET :
    JDNET en Aout 2002 avait produit une petite étude des différentes solutions ETL. Je n’irais pas jusqu’à dire que l’étude est comparative. Par contre cette étude à le mérite de mettre en évidence le positionnement de chacune des solutions ETL. Voici le lien :
    http://solutions.journaldunet.com/0208/020827_bi_panorama1.shtml
    L’expertise
    C’est l’aspect qu’il ne faut surtout pas négliger, certains outils disposent déjà d’une grande maturité ( mais en général coûte plus chèr) , il est donc plus facile de trouver des ressources qui peuvent développer voire même gérer un projet ETL. Par contre certains outils, même s’ils présentent un bon potentiel et un bon ratio qualité/prix, il est difficile de trouver des ressources expertes !
    Les preuves de concepts
    Aprés avoir effectué les choix préliminaires, il faut absolument passer des preuves de concepts à chacune des suites choisies.

    Pour faire des bonnes preuves de concepts nous pouvons utiliser les deux outils suivants :

    Le guide comparatif :
    Un bon outil à utiliser lors des preuves de concepts est le guide suivant. L’avantage de cet outil est d’être écrit en français et qu’il prend en considération et dans le détail différents aspects techniques des systèmes ETL.

    http://www.guidescomparatifs.com/guides/iso_album/guide_etl_-_avril2004.pdf

    Exemple d’utilisation : J’avais à choisir entre OWB et DecisionStream de cognos. Ayant travaillé avec OWB, je n’avais pas besoin de preuve de concept. Par contre nous avons fait venir un technicien Cognos pour la preuve de concept de Cognos DecisionStream. J’ai alors utilisé le guide comparatif, et on a finalement opté pour DecisionStream. [A vrai dire la culture de l’entreprise favorisait l’achat de décision Stream]

    Le guide des acheteurs ETL :
    Ce guide, crée par TDWI (The Data Warehouse Institute), est sous forme d’une matrice de comparaison des différents choix ETL selon plusieurs perspectives et sous différents angles. Cette matrice est à remplir lors des preuves de concepts des outils.

    L’avantage de cette matrice est de prendre en considération plusieurs critères concernant le fournisseur ETL , à savoir sa situation financière, La stratégie de l’entreprise (On voudra pas acheter le produit d’une société qui risque de faire faillite dans 6 mois), la stratégie ETL de l’entreprise ( On ne vaudra pas acheter une suite ETL si la compagnie risque de délaisser ce produit parcequ’il ne fait plus partie de sa stratégie d’affaire) , le nombre de clients, le nombre d’employés... En plus des critères d’ordre technique (Extracteurs, transformateurs et chargeurs).

    Ce guide comparatif est en anglais seulement !
    http://www.tdwi.org/files/pub/tdwi/ETL%20Matrix.xls
    A vous de jouer !
    Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

    Conpects



    L'entrepôt de données

    Le data warehouse est le terme anglais qui veut dire entrepôt de données.

    Selon le grand dictionnaire une excellente référence qui nous donne accès à près de 3 millions de termes français et anglais du vocabulaire industriel, scientifique et commercial, dans 200 domaines d'activité :

    Un entrepôt de données est une structure informatique dans laquelle est centralisé un volume important de données consolidées à partir des différentes sources de renseignements d'une entreprise (notamment les bases de données internes) et qui est conçue de manière que les personnes intéressées aient accès rapidement à l'information stratégique dont elles ont besoin.

    En plus le grand dictionnaire précise dans le détail :
    Si, dans le passé, l'entrepôt de données servait davantage à l'archivage, aujourd'hui il est devenu une pièce maîtresse de l'informatique décisionnelle (ou informatique d'aide à la décision). Il représente l'un des éléments essentiels d'un ensemble matériel et logiciel dynamique de recherche d'informations. Dans un entrepôt de données, les données sont : sélectionnées et préparées (pour répondre aux questions vitales de l'entreprise), intégrées (à partir des différentes sources de renseignements) et datées (elles gardent la trace de leur origine). Le terme entrepôt de données, employé très fréquemment, semble vouloir supplanter ses concurrents dépôt de données et centrale de données. Bien que le terme magasin de données soit utilisé comme équivalent de data warehouse par certains auteurs, il convient mieux au concept d'« operational data store ». D'après les renseignements inscrits dans la base de données IBMOT d'IBM, Information Warehouse est une marque de commerce d'International Business Machines Corp. Le terme lui-même est pourtant répertorié comme nom commun dans plus d'un dictionnaire unilingue anglais spécialisé.


    Cette définition est tirée de celle de Bill Inmon que l'on nomme le père des entrepôts de données et l'inventeur de ce qu'on appelle EDW pour Entreprise Data warehouse ou CIF pour Corporate Information Factory . Voici la définition de Bill Inmon (traduit par Comment ça marche ) :

    Le datawarehouse est orienté sujets, cela signifie que les données collectées doivent être orientées « métier » et donc triées par thème;
    Le datawarehouse est composé de données intégrées, c'est-à-dire qu'un « nettoyage » préalable des données est nécessaire dans un souci de rationnalisation et de normalisation;
    Les données du datawarehouse sont non volatiles ce qui signifie qu'une donnée entrée dans l'entrepôt l'est pour de bon et n'a pas vocation à être supprimée ;
    Les données du datawarehouse doivent être historisées, donc datées.
    Selon moi ce qu'il faut retenir, c'est que l'entrepôt de données est avant tout un emplacement de stockage de données afin de pouvoir y accéder pour l'analyse et la prise de décision. Il est donc à ne pas confondre avec la Business intelligence.

    Le modèle dimensionnel de données

    Avant de commencer à développer des systèmes ETL, il est important de bien maîtriser un certain nombre de notions, concepts et mécanismes. Nous commençons cette liste par le modèle dimensionnel.

    En effet, les structures de données dimensionnelles sont la destination 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.

    Nous faisons ici un petit rappel du modèle dimensionnel :
    Il s'agit de la structure de données la plus utilisée et la plus appropriée aux requêtes et analyses des utilisateurs. 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.

    Nous introduisons alors les deux structures de données les plus rudimentaires du modèle dimensionnel : table de fait et table de dimension.

    Table de fait :
    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.


    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.

    Le modèle dimensionel :
    La figure suivante représente un exemple de schéma en étoile, le schéma qui est le plus adapté à la modélisation dimensionnelle. Dans cette exemple l'analyse des ventes ( table de fait des ventes) est effectuée selon les quatres axes que représentent les dimensions du schéma, à savoir les clients, les produit, le temps et les vendeurs. Un exemple du genre de question à laquelle nous serons capable de répondre en utilisant ce modèle est : "Quel le montant des ventes du produit P par le vendeur V au client C lors du mois M ?"



    Qualité de données

    Une donnée de qualité est une donneé exacte et précise donc :

     Correcte : les valeurs et les descriptions décrivent d’une façon véridique et fidèle les objets qu’elles représentent. Par exemple le nom de la ville dans laquelle un client vit actuellement s’appelle Montréal. Donc, la valeur de la donnée sur la ville du client doit être Montréal pour être correcte.

     Non ambiguë : les valeurs et les descriptions doivent avoir une seule signification. Par exemple, il existe n villes dans le monde dont le nom est Casablanca, cependant il en existe seulement une au Maroc. Par conséquent dans le but qu’une adresse soit précise et non ambiguë, il faut que celle-ci contienne et le nom de la ville, Casablanca, et le nom du Pays.

     Consistante : Les valeurs et des descriptions utilisent une convention de nomenclature unique. Par exemple la province du Québec est parfois écrite Qc, PQ,… Pour être consistant il faut utiliser une seule convention de nomenclature.

     Complète : Il existe deux aspects de la complétude :
    o IL faut s’assurer que chaque donnée obligatoire contient une valeur.
    o Il faut s’assurer, en transformant les données, de ne pas perdre des valeurs ou des enregistrements.

    L'OLAP

    En 1993, E.F Codd (1923-2003), l'inventeur des bases de données relationnelles, & associés ont publié un document de présentation technique à la demande de la compagnie Arbor Software, devenue aujourd'hui Hyperion, sous le titre 'Providing OLAP (On-Line Analytical Processing) to User-Analysts : An IT Mandate'.

    Du fait que ce document soit commandité par une compagnie privée, les règles OLAP telles que définies par E.F Codd étaient contreversées.
    Ceci nous donne un peu d'histoire sur les origines du terme OLAP.

    Revenons maintenant au terme OLAP, Mr. Nigel Pendse ( www.olapreport.com/fasmi.htm) persiste et signe que (traduction libre de son texte) :

    Ce terme ne donne ni une définition ni une description claire de ce que signifie OLAP. Il ne donne non plus aucune indication pourquoi utiliser un outil OLAP, ni si tel outil en est un outil OLAP.

    Personnellement, je ne crois pas qu'a partir d'un acronyme ou du nom d'un outil ou d'une technique on serait capable de déduire la définition, la description, l'utilisation... d'un tel outil ou technique. Prenons par exemple DataBase, tout ce qu'on peut comprendre d'un tel terme c'est qu'il s'agit d'un endroit ou l'on stocke les données, cela ne nous donne pas forcément une description de ce que c'est une base de données, ni si Excel est une base de données ou pas !

    Cependant, l'auteur (Nigel Pendse) , recapitule la définition de l'OLAP en cinq mot : Fast Analysis of Shared Multidimensional Information (FASMI) traduit en français par http://www.linux-france.org/prj/jargonf/F/FASMI.html comme suit : « Analyse Rapide d'Information Multidimensionnelle Partagée ».

    Ce qui attire mon attention dans cette définition c'est la limitation de l'OLAP au modèle Multidimensionel, alors dans la définition OLAP, en tant que On-Line Analytic Processing, aucune limite tant qu'a la modélisation des données n'est imposée. Certes actuellement la représentation la plus utilisée est le multidimensionnel, cependant dans le future ne serait-il pas envisageable d'être obligé d'utiliser autre sorte de représentation ?

    Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

    jeudi, septembre 22, 2005

    Glossaire - Décisionnel



    Petit glossaire du décisionnel

    Analyse multidimensionnelle : concept qui définit les analyses effectuées par croisement de plus de trois dimensions (ou ensemble de données du même type ou encore axes).

    Applications analytiques : applications décisionnelles prêtes à l´emploi (livrées avec un modèle de données, des requêtes préparamétrés, etc. pour l´analyse d´un domaine spécifique : CRM, budget, etc.

    Axe d´analyse : ou dimension. Les ventes d´un produit peuvent par exemple être analysées par région (axe 1), époque (axe 2), magasin (axe 3), etc.

    Balanced Scorecard : ensemble de méthodologies préconisées par Robert S. Kaplan & David Norton qui favorisent un alignement permanent de la stratégie de l´entreprise sur des objectifs financiers et non financiers. Pour en savoir plus : www.balancedscorecard.org

    Cube : Structure multidimensionnelle permettant l´analyse d´informations factuelles en les segmentant sur un ensemble d´axes d´analyses.

    Datamart : base de données, spécifique au monde décisionnel, orientée sujet ou métier. Un Datamart peut contenir des données dupliquées d´un Datawarehouse et/ou des données locales.
    Datamining : Traitement et analyse statistiques de bases de données permettant d´établir des relations et des comportements types. Avec l´analyse multidimensionnelle classique, on sait ce que l´on cherche tandis qu´avec le datamining, on ne sait pas forcément ce que l´on cherche. On essaye plutôt d´établir des corrélations entre des données afin d´en tirer des renseignements, des indicateurs, des anomalies, des correspondances, etc. qui peuvent mettre en évidence des tendances.Datawarehouse : ou entrepôt de données. Base dans laquelle les données sont centralisées et organisées pour le support d´un processus d ´aide à la décision.

    Décisionnel : Processus d´utilisation de connaissances extraites par analyse des informations et des données générées par les processus métiers de l´entreprise pour déterminer la meilleure action à entreprendre, la meilleure décision à prendre.

    Dimension : ou axe. Les ventes d´un produit peuvent par exemple être analysées par région (axe 1), époque (axe 2), magasin (axe 3), etc. Il existe plusieurs type de dimension ( Dégénérée, Junk...)

    Drill down (ou drill through) : mécanisme de navigation dans une structure multidimensionnelle permettant d´aller du plus global au plus détaillé à l´aide de requêtes de type hiérarchique.

    ETL : Extract Transform Loading. Serveur chargé d´extraire, nettoyer et transformer les données émanant de sources diverses pour ensuite les insérer dans une base de données (datawarehouse, datamart, etc.).

    Fait : Mesure, que l'on veut analyser, exemple le total des ventes. Il existe plusieurs type de faits, additive, semi-additive, de couverture...

    Indicateur : statistique, suivie au fil du temps, qui présente les tendances d´une condition ou d´un phénomène, au-delà des propriétés de la statistique elle-même. Les indicateurs permettent d´obtenir de l´information supplémentaire. Ils offrent un moyen d´évaluer les progrès en vue d´un objectif. On peut concevoir toute sortes d´indicateurs : mesure de la rentabilité, des ventes, de l´évolution des clients, etc.

    Meta-données : Les méta-données sont des informations qui renseignent sur la nature de certaines données. Les méta-données que l´on peut par exemple associer à un document sont : son titre, son auteur, sa date de création, etc. Dans le cadre du décisionnel, elles constituent une sorte de dictionnaire sur lequel le système s´appuie pour comprendre des données utilisées par les différentes applications qui alimentent le datawarehouse. Les intitulés "Client" d´un PGI et "nom" d´une application comptable peuvent contenir les mêmes informations mais le système ne peut le savoir que si un dictionnaire a été conçu pour lui indiquer qu´il s´agit de la même nature d´informations. Les méta-données englobent également l´ensemble des informations relatives à la provenance, à l´historique et aux traitements associés aux données d´un datawarehouse.

    Modèle de données : organisation des données dans une base dans une structure de tables, colonnes, champs etc. pour l´univers relationnel, autre pour les bases OLAP dont la structure est souvent propriétaire.

    Nettoyage de données : Processus visant à homogénéiser les données pour les rendre exploitables. Le nettoyage des données assure leur intégrité en éliminant les doublons, en corrigeant l´orthographe et en supprimant ou complétant les champs non renseignés. Les opérations de nettoyage peuvent également couvrir le filtrage, l´agrégation, la vérification de relations, etc.

    OLAP : On-Line Analytical Processing. Procédé permettant de pré-calculer certains croisements de données afin d´optimiser les performances de l´application décisionnelle. Des variantes de l´OLAP existent.

    HOLAP (OLAP Hybride) : mixte de SQL et d´OLAP, l´un passant le relais à l´autre en fonction des opérations effectuées.

    Pseudo OLAP : simulation d´un modèle de données OLAP sous forme d´étoile au sein d´une base SQL qui permet d´effectuer des requêtes hiérarchiques (drill down). Avantage des performances OLAP sans la volumétrie mais n´est pas adapté à tous les types de requêtes d´analyse.

    JOLAP (Java OLAP) : normalisation de l´accès aux bases multidimensionnelles en java.
    « JOlap est l'équivalent pour les bases décisionnelles comme les datawarehouse (entrepôts de données), de ce que JDBC représente depuis plus longtemps vis-à-vis des bases de données relationnelles classiques. Toutes deux basées sur le langage Java multiplates-formes, ces interfaces permettent d'effectuer divers types de traitements en ligne sur les données et les métadonnées (informations décrivant une donnée). » Journal du net

    DOLAP (Desktop OLAP) et ROLAP (Relational On Line Analytical Processing) : alternatives qui consistent à répartir les traitements des cubes créés par le moteur OLAP entre le serveur et le poste client.

    Outil de restitution : ensemble des outils (requêteurs, tableaux de bord, etc.) permettant de restituer le résultat d´une analyse.

    Qualité des données : Conformité structurelle des données à l´utilisation qu´on souhaite en faire. Améliorer la qualité peut consister par exemple en la correction des occurrences multiples d´un même objet, ou le renseignement de champs vides.

    Requêteur : Un requêteur permet à l´utilisateur final d´accéder aux données de l´entreprise de manière autonome, dans un langage proche de celui de son métier, pour effectuer des analyses, croiser des données, etc. Dans la plupart des cas aujourd´hui, ces requêteurs s´appuient sur les méta-données pour proposer à l´utilisateur final des intitulés qui correspondent aux mots qu´il utilise habituellement en lieu et place des intitulés des colonnes des bases de données, le système décisionnel se chargeant de convertir ensuite les requêtes dans un langage compris par la base de données ou le datawarehouse.Segmentation : Découpage d´une population ou d´une série de données pour identifier des sous-classes homogènes ou pertinentes, à partir d´un ou plusieurs critères (géographiques, socio-démographiques, socioculturels, comportementaux...). En marketing, la segmentation permet de décliner une offre en adaptant sa forme et son contenu au profil des différents groupes cibles, tous aussi homogènes et différents entre eux que possible.

    Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

    Dimensions - Différents types


    Les types de dimensions

    Dimension dégénérée (Degenerate dimension)
    http://kimballgroup.com/html/designtipsPDF/DesignTips2003/KimballDT46AnotherLook.pdf

    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.

    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 »…

    Junk dimension
    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 à évolution lente (Slowly changing dimension)
    Une dimension peut subir des changements de description des membres
    • Un client peut changer d’adresse, se marier, ...
    • 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
    • Écrasement de l’ancienne valeur
    • Versionnement
    • 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. L’évolution

    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 leur taille. 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). Un autre moyen plus élégant est de 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.

    Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

    dimanche, septembre 18, 2005

    Principales suites ETL



    Suites ETL :

    Dans un ordre alphabétique, nous présentons ci-dessous la liste des suites ETL (Outils ETL) offertes actuellement sur le marché. Il est à noter que la liste est loin d’être exhaustive.

     Ab Initio
     Ascential DataStage
     BusinessObjects Data Integrator
     Cognos DecisionStream
     Computer Associates Advantage Data Transformation
     CrossAccess eXadas
     Data Junction Integration Studio ( Aquired by pervasive)
     DataHabitat ZeroCode ETL
     DataMirror Transformation Server
     Embarcadero DT/Studio
     ETI (Evolutionary Technologies International)
     Hummingbird ETL
     IBM DB2 Data Warehouse Manager
     Informatica ( PowerCenter et SuperGlue)
     Information Builder iWay
     Mercator Inside Integrator (aquired by Ascential)
     Microsoft SQL Server DTS
     Oracle9i Warehouse Builder
     Sagent Data Flow Server (aquired by Group 1)
     SAS Enterprise ETL Server
     Sunopsis

    Principaux fournisseurs de solutions de data profiling :

     Ascential (ProfileStage)
     Evoke Software
     SAS
     Trillium/Harte Hanks

    Principaux fournisseurs de solutions de Data cleansing

     Ascential (acquisition of vality)
     First Logic
     Group 1
     SAS DataFlux
     Search Software America
     Trillium (acquired Harte Hanks)

    Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.

    jeudi, septembre 01, 2005

    Liens utiles

    Cognos DecisionStream ( Future Data manager )



    J'ai travaillé plusieurs années à développer les systèmes ETL en utilisant le langage Pro*C, Sql ou PL/SQL. Mais depuis quelques années nous avons décidé de s'acheter un outil ETL, et le choix s'est arrêté sur Cognos DecisionStream. Nous avons utilisé le guide comparatif déjà cité dans ce blog pour réaliser la preuve de concept.

    Cognos a décidé dans sa série 8 de changer le nom de DecisionStream qui devient Cognos Data Manager, un nom qui colle plus avec le rôle d'un tel outil dans une solution décisionnelle. http://www.intelligententerprise.com/showArticle.jhtml?articleID=166403397

    J'ai donc eu à travailler sur cette outil depuis déjà quelques années.

    Le lien suivant donne une idée sur les différentes fonctionnalités de l'outils :
    http://www.cognos.com/products/tour/decisionstream/index.html

    Avec l'achat de Cognos par IBM, l'avenir de Cognos Data Manager devient incertain, IBM dispose déjà de l'ETL Data Stage d'ascential... A suivre.

    Si vous avez des questions concernant l'outil DecisionStream ou si vous cherchez un travail (Montreal, Quebec, Canada), veuillez me contacter (abdelelomari@hotmail.com ) ou me laisser un commentaire.



    Copyright © Abdel ELOMARI 2005-2006 . Tous droits réservés.