Discussion :

[paurine]

Bonjour,
mon entreprise me demande de réaliser un audit des meilleures pratiques relatives aux deux premières briques lors de la construction d'un systeme décisionnel: la collecte et le stockage.
je dois d'abord étudier les méthodes mises en oeuvre et les outils existants, ainsi qu'identifier les grandes tendances à venir sur ces composants.
Si vous pouvez m'aider ou si jamais vous avez des documents sur le sujet, je vous serai reconnaissante.
Sinon, vous pourriez peut-etre m'éclairer et m'aider à répondre à quelques questions:
-Comment aborder la construction de l'entrepot de données? Faut-il se préoccuper de l'aspect acquisition ou du stockage au démarrage du projet?
-Quelles sont les régles et les différentes approches pour modéliser le Data WareHouse?
-Comment concevoir un modèle dénormalisé pour arriver à un bon compromis entre efficacité, lisibilté et administration?
-Quelles sont les différences entre les modéles en étoiles, en flocon, en constellation? Quels criteres permettent de décider de tel ou tel modele?
-Faut-il privilégier le principe E-T-L ou E-L-T?
Merci d'avance.

[Invité]

as-tu été voir la documentation sur le site d'oracle.
De mémoire, il y un pdf sur le sujet.

[pachot]

Bonjour,

C'est très général comme question...
Ma première remarque, c'est que commencer par la collecte et le stockage n'est pas une bonne idée. Le but, ce n'est pas de stocker ou d'archiver (sinon un backup sur bande suffirait...)

Comme pour tout projet, décisionnel ou pas, on part du besoin !

Le besoin pour le décisonnel, c'est identifier (spécifier):
- les indicateurs (ou measures, ou facts): ce sont les valeurs sur lesquels vont porter l'aide à la décision: des nombres, des montants, etc
- les axes d'analyse (ou dimensions): axes temporels (dates, jour de demaine, tranches horaires, ...), axes géographiques, produits, clientes, etc...
- les niveaux de granularité: l'utilisatuer a souvent besoin d'aggrégats et non de détail.

Ensuite le modèle de donnée:
- en étoile, des dimensions pour les branches de l'étoile, et la table de faits au centre, qui ne comporte que les foreign keys sur les dimensions et les valeurs des indicateurs
- en flocon: pareil mais les dimensions ont plusieurs niveau de hierarchie (Pays>Region>Ville)
- en constellation: plusieurs tables de faits car des indicateurs ne sont pas liés, ou qui ne sont pas de la même granularité.

Le modèle en étoile c'est ce qui marche le mieux. Le flocon n'a pas trop d'interêt car la dénormalisation des dimensions ne pose pas de problème (peu de volume, et pas de mises à jour). Plutot qu'une constellation, plusieurs datamarts qui répondent chacun à un besoin. Parce que faire des jointures entre plusieurs tables de faits qui ne sont pas à la même granularité, c'est souvent se retrouver à faire des sommes fausses.

L'idée, c'est que:
- la table de fait a beaucoup d'enregistrements, mais des petits enregistrements (car que des feorign keys et des number, pas de libellés, etc.) et beaucoup de mises à jour. Donc très normalisé.
- et que les tables de dimensions sont très dénormalisées (dans le cas du modèle en étoile) donc très statiques, de gros enregistrements, mais peu nombreux.

Ensuite, tu vois comment rempir ça à partir es bases opérationneles: extraction et transformation.

Lorsqu'il y a une transformation complexe, on se retrouve souvent à charger les données telles qu'elles arrivent des applications opérationneles, dans des tables de 'staging' puis de les transformer là en base parce que la base de données permet de faire beaucoup de choses de manière performante. Donc ELT dans ce cas, ou plutot ELTL...

Enfin, il faut voir tout ce qui permet de traiter de gros volumes: partitionnement (souvent par date), index locaux, insert en direct-path ('append'). Et bien sur, les bitmap index pour toutes les foreign keys des dimensions de la table de faits.

Cordialement,
Franck.

[Waldar]

Je nuancerai les propose de pachot en soulignant qu'il existe une différence entre datawarehouse et datamart et qu'elle ne transparait pas dans sa réponse.

Ces deux notions sont souvent mélangées car elles font partie de la chaîne décisionnelle, et dans des petites sociétés on ne retrouve qu'une seule base qui tient les deux rôles.
Néanmoins il est extrèmement important de bien comprendre les différences entre ces deux bases.

Dans un datawarehouse, on collecte et on stocke le maximum d'informations "utiles". C'est un modèle relativement normalisé. Il faut procéder à certaines étapes obligatoires lors de la collecte d'informations :
1) le rapprochement des données : soit en partant d'un référentiel existant, soit en en créant un nouveau. Il faut que les données qui rentrent dans le datawarehouse fassent toujours référence à ce référentiel. On ne doit plus se poser la question de oui mais mon client existe dans le système A et pas le B alors... Dans le datawarehouse, il y a un référentiel client unique, et on utilise éventuellement des tables de transcodifications entre les clefs des systèmes applicatifs et la clef du dwh.
2) le nettoyage des données : si on attend une date et qu'on reçoit du texte, on doit rejeter la ligne. Si on doit faire correspondre un numéro mais dont on n'est pas certain de la saisie, on le recherche et si on ne le trouve pas on rejette la ligne. Si on attend un code sur 20 caractères mais qu'on en reçoit que 15, on le complète.
3) gestion des rejets : une ligne rejetée ne doit pas disparaitre du système, car on peut rejeter un client sur une adresse qui pourrait arriver deux jours plus tard, ce serait dommage. Il faut essayer automatiser le recyclage des données.
4) historisation des données : on conserve un maximum de données dans le temps. Idéalement on devrait être capable de se repositionner à une date précise, mais c'est assez couteux en terme de stockage et de développement des traitements si les données des applications sources sont mal horodatées (et après neuf ans de datawarehouse dans plusieurs entreprises, grandes ou petites, c'est toujours le cas).


Dans un datamart on retrouve une vue métier de l'entreprise, c'est un modèle plutôt dénormalisé.
On ne prend les que les données qui nous intéressent (on a rarement besoin du détail des ventes d'il y a dix ans).
Le post de pachot explique très bien ce qu'est un datamart, axé reporting et performance de restitution.

L'intérêt de séparer les deux bases DWH et DMT, c'est qu'on calcule jamais un chiffre d'affaire de la même façon entre un service commercial et un service financier.
Si par exemple vous imposez des indicateurs financiers aux commerciaux, ils ne seront pas intéressés et n'utiliseront pas la chaîne décisionnelle et continueront à produire des résultats *1.15 dans leurs incontrôlables feuilles excel .