[Data Warehouse] Datamart, cube : différence [Résolu]

[Pmatt]

Bonjour à tous

Je me lance dans le domaine de la Business Intelligence et veux mettre au point un petit datawarehouse pour analyser les ventes d'un petit magasin (donc à titre purement didactique pour moi)

Seulement, après quelques lectures, recherches sur le sujet je me pose des questions.

Quelles sont les différence entre un datawarehouse, un datamart et un cube?

Voici ma vision, corrigez moi si je me trompe :

• Un cube OLAP est une base de données multidimensionnelle. Or une base de données multidimensionnelle est modélisée selon une table des faits et des dimensions s'y rapportant.

• Un datamart est un petit datawarehouse qui concerne un seul thème. Mais si je veux créer un datawarehouse autour du thème des ventes, est-ce que le datamart est considéré comme datawarehouse? Le datamart est donc aussi une base multidimensionnelle donc une structure en cube?

• Le datawarehouse se compose d'un ensemble de datamart ou se décompose en un ensemble de datamarts mais est également une structure en cube

En conclusion pour le moment, ma perception des choses est la suivante

-> Datawarehouse = ensemble de cubes thématiques (datamart)
-> datamart = cube OLAP
-> cube = structure multidimensionnel stockant des données à des fin d'analyse


Merci pour vos éclaircissements qui me seront indispensables pour continuer ce projet.

Pmatt

[al1_24]

Envoyé par Pmatt

Un cube OLAP est une base de données multidimensionnelle. Or une base de données multidimensionnelle est modélisée selon une table des faits et des dimensions s'y rapportant.

Dans le cube OLAP, les cellules son précalculées.

Envoyé par Pmatt

Un datamart est un petit datawarehouse qui concerne un seul thème. Mais si je veux créer un datawarehouse autour du thème des ventes, est-ce que le datamart est considéré comme datawarehouse? Le datamart est donc aussi une base multidimensionnelle donc une structure en cube?

Au niveau de l'entrepôt de données, les faits détaillés sont conservés. Dans le datamart, un certain niveau d'agrégation a déjà été effectué et on perd le détail des faits.

Envoyé par Pmatt

Le datawarehouse se compose d'un ensemble de datamart ou se décompose en un ensemble de datamarts mais est également une structure en cube

A strictement parler, l'entrepôt de données ne comporte que les faits détaillés et les hériarchies dimensionnelles. Les cubes sont préparés à partir des données de l'entrepôt.

[GGGGG]

Envoyé par Pmatt

-> Datawarehouse = ensemble de cubes thématiques (datamart)
-> datamart = cube OLAP
-> cube = structure multidimensionnel stockant des données à des fin d'analyse

Je me permets malgré mon manque d'expérience de vous répondre.
Je pense que le cube est complémentaire au Data warehouse et au Datamart.
C'est pourquoi, je ne pense pas qu'un datamart soit un cube olap mais juste une base relationelle (la meme chose pour l'entrepot de données d'ailleurs).

[Pmatt]

Merci al1_24 et GGGGG pour vos réponses .

Donc si j'ai bien compris :

-> Le datawarehouse possède le niveau d'information le plus détaillé
-> Le datamart possèdes des données agrégées, moins détaillées

Par contre, que voulez vous dire par cellules précalculées?

Je vais construire une petite solution décisionnelle avec Analysis Services 2005, de Microsoft.

GGGGG, lorsque tu dis qu'un datamart et datawarehouse sont des bases relationelles, je suppose que tu veux parler de ROLAP ?

Donc dans mon projet en fait il serait plus approprié de parler de Cube créé par Analysis Services qui se baserait sur des vues construites par l'utilisateur mais au fond, l'information du cube serait directement tirée de la base de données relationnelle OLTP.

Bref comme vous le voyez, tout n'est pas encore clair.

Avez vous de bons liens ou livres à me conseiller sur le sujet?

Merci pour votre patience et la pertinence de vos réponses

[GGGGG]

Alors, il semble que les bases multidimensionnelles impliquent un nombre limité de ligne contrairement au base relationnelle qui peuvent en avoir une infinité ce qui justifirait que les DW sont relationels

Tu trouveras quelques infos sur ce site je pense : http://www.nodesway.com/business-int...telligence.htm

[brunolf]

houlala ... ça part un peu dans tous les sens ...


Un datawarehouse, ou entrepôt de données :

Voir wikipedia

Un datamart :

Re-voir Wikipedia

Un cube Olap ou Hypercube :

Encore un coup sur Wikipedia


Désolé de te renvoyer vers ces articles, mais ils me semblent très clair et je pense, répondent à tes questions.

Pour préciser un peu sur les cube, le concept d'OLAP est un concept "générique" qui peut être décliné différement selon les éditeurs de solutions décisionnelles.

Pour Analysis Services de microsoft, on est dans le R-OLAP : Les données sont stockées dans une base de données relationnelle.

Chez cognos, ils font plus dans le M-OLAP (je ne sais plus ce que veux dire le M)... le principe est que les données sont extraites de la base pour générer un fichier (le cube)

L'avantage du R-OLAP, c'est qu'une fois que la base est à jour, le cube est à jour ... L'avantage du M Olap, c'est une navigation plus rapide car les données sont précalculées lors de la génération du cube.

[GGGGG]

Oula, j'ai raconté des conneries ^^

Merci brunolf /me est un peu moins con

Il y a aussi le H-OLAP pour Hybride entre le R de Relationnel et le M de Multidimensionnel. Le reste de l'explication sur le wiki

[tbabulle]

Le M de M-OLAP veut dire multidimensionnelle
Le M-OLAP est un OLAP optimisé pour l'analyse multidimensionnelle.
C'est une forme d'hypercube multidimensionnel qui permet de représenter les données sous la forme d'un croisement de n dimensions, ces dimensions pouvant être plus ou moins denses, caractérisant ainsi la densité ou sparsité du cube.

Il existe également le H-OLAP, qui est un Hybride entre le M-OLAP et le R-OLAP.
La structure multidimensionnelle d'un hypercube est utilisée pour les données agrégées. Lorsque l'accès à un niveau de détail élémentaire plus fin est nécessaire, des tables relationnelles classiques sont utilisées : c'est le mécanisme du drill through.

Sinon, effectivement le DataWareHouse contient les données de détail mais aussi l'historique des données (le versionning en quelque sorte).
Le DataMart est lui, une sorte de vue sur un métier, une période, .... à un niveau soit de détail ou/et soit aggrégé. On utilisera un DM au niveau détail pour faire tourner des requêtes ou des cubes plus rapidement. En règle général, on profite du DM pour faire les 2 (vue métier avec données aggrégées par exemple).

Penser aussi au passage de vos données opérationnelles vers votre DWH, en utilisant pe-être un ODS (Operational Data Store).
C'est une base de données conçue pour centraliser les données issues de sources hétérogènes afin de faciliter leur intégration dans un DataWareHouse. L'intégration de ces données implique souvent une purge des informations redondantes. Un ODS est généralement destiné à contenir des données quotidiennes (type évènements du jour) de niveau fin.

Bon courage
Thierry Babulle
tbabulle@objectif-informatique.fr

[Pmatt]

Merci à tous pour vos réponses constructives

Bon je vais me pencher en détail ce soir sur ce que vous m'avez dit, et la voila comment je vois la fil conducteur du projet, donnez moi votre avis, si vous voulez bien

je suis dans un modèle ROLAP.

J'ai ma base de production OLTP, pour faire du décisionnel c'est pas une bonne structure, je vais donc créer une base dont la strucuture est un schéma en etoile ou en flocon (ces structures sont relationnelles si je ne me trompe).

Pour remplir cette dernière, je dois d'abord extraire l'information de la base OLTP et la transférer dans une base temporaire (data Staging) avant d'effectuer des transformation sur mon information (assignation des clés de substitution, ...)

Ensuite je charge tout cela dans ma base décisionnelle d'Analysis Services.

Pour effectuer des interrogations, j'utilise le langage MDX qui est proche du langage SQL.


Voila, vous en pensez quoi?

L'interrogation c'est de savoir s'il faut vraiment faire du data Staging avec du ROLAP et si le langage MDX est adéquat avec ce type de modèle.

Cordialement,

Matt qui vous remercie pour votre aide et qui essaie de comprendre tous ces concepts !

[brunolf]

J'en pense que tu t'approche de la vérité (sur le principe de fonctionnement en tout cas)

Je ne connais pas analysis services, donc je ne peut pas te dire s'il "cause" en mdx, en sql ou en tout autre langage ... de toute façon, ça n'a guère d'importance.

L'essentiel dans un projet décisionnel est de bien définir le besoin fonctionnel, puis de bien modèliser ton datawarehouse.

Dans le cas de l'analyse de tes ventes, si c'est un petit projet, juste pour essayer, ne t'embarque pas dans un modèle en flocon : fait au plus simple.

un bon vieux modèle en étoile sera parfait pour ton analyse :
Axe Temps
|
Axe Client - Faits (ventes) - Axe Article


Pour le reste de tes questions, je vais te faire une réponse de normand ... ça dépend : sur un petit projet, la partie "Staging" n'est pas forcément nécessaire ... a condition que tes données soient "propres"

Si tu intègre des données issues de plusieurs sources ... cette étape deviens vite nécessaire pour éviter les incohérences : tout dépend donc de tes systèmes sources.

C'est la même chose pour les clés de substitution : si tous tes référentiels sont gérés dans ton systèmes sources avec des ID numériques bien propres ... l'intéret de les substituer par d'autres clés n'a de sens que si tu veux historiser tes référentiels (par l'utilisation de surrogate keys), Sinon, ne te casse pas la tête.

Bien sûr, ces remarques sont valables pour un petit projet perso pour lequel on veut avoir un résultat rapide, si tes objectifs sont plus ambitieux ... il faut adapter ...

[Jester]

Je ne suis pas expert, mais à mon sens un/des datamarts n'ont d'intérêt que si la table correspondante dans le data warehouse a une granularité trop fine ce qui impllique que la requête sera trop lente.

Je pense qu'il faut à chaque fois voir si ajouter de la complexité est nécessaire (synchroniser le datamart, faire en sorte que le client accède au datamart pour les requêtes qui peuvent y être faites, ...).

Pour certains cas simples (une seule base OLTP petite), il n'y a pas besoin de data warehouse du tout.

[Pmatt]

Salut, merci pour vos réponses je commence à y voir plus clair et j'éspère que ce post servira à d'autres personnes.

J'ai réalisé un petit schéma sous visio, illustrant mon plan d'attaque. Vous en pensez quoi?

• Mes sources peuvent être des fichiers plats, des bdd, ...
• Il est judicieux de noter la date de dernière modification de chaque champ pour savoir lesquels ont été modifié et donc ce qu'il faut insérer dans le DW
• J'extrait les champs nécessaires de chaque source que je place dans une bdd temporaire
• J'effectue des transformation dessus, tels l'ajout de clé de substitution, la consolidation etc
• j'envoie tout ca dans mon Data Warehouse (ROLAP) qui n'est rien d'autres qu'une base relationnelle comme une autre mais modélisée différemment (flocon ou étoile)
• Ensuite, Analysis Services Intervient. Il va créér un cube selon la même architecture que le datawarehouse
• Ce cube à pour but de donner un sens multidimensionnel à la structure relationnelle du datawarehouse.
• Comme on est en ROLAP, ce cube ne contient aucune données physiques, il les puise dans la bdd relationnelle. Ce cube est mis à jour en temps réel donc.
• On peut comparer ce cube à une vue multidimensionnelle, créée par Analysis Services. Le client peut effectuer des requêtes MDX, le moteur Analysis Services les convertira en langage SQL et ira interroger le datawarehouse relationnel

Voila, je commence à être dans le bon ou je suis parti dans le mauvais chemin?

Merci pour tout !!!!

Bonne soirées les développeurs

PMatt ! -=)

[tbabulle]

Oui, oui, tu es bien parti.

Pense également que durant les étapes de transformation et de chargement, tu as besoin de controler l'intégrité de tes données, ainsi que leur qualité.
Sans doute, as tu quelques règles de gestion, que tu peux valider à ce moment-là ?

Malheureusement, l'expérience montre que les systèmes opérationnels sont souvent source de petits bugs sur les données, d'où une qualité approximative.
Je te donne un exemple :
- dans un système opérationnel, il est très possible que tu n'ais pas tous les prix d'achat (PA) de tes produits, mais par contre que tu ais tous les prix de vente(PV), sinon tu ne vends pas !
- lorsque tu vas vouloir faire la marge par produit, tu vas avoir des produits sans marge, puisque pas de PA, et cela va se voir tout de suite
- par contre si tu fais la somme des PA et la somme des PV, pour avoir la marge consolidée, bonjour les dégats, et ce n'est pas forcément évident de s'en rendre compte.

Pense donc aux règles de contrôle et d'intégrité.
Cela peut également se gérer au niveau de l'historique de tes données dans ton DWH.

A suivre ...
Bon courage

Thierry Babulle
tbabulle@objectif-informatique.fr

[Pmatt]

je prend bonne note de tes conseils, tbabulle !!

Quand on y pense, c'est tout un casse tête ce projet de datawarehouse, mais il y a moyen d'y arriver.

Pour la prochaine étape, je vais créer mon modèle dimensionnel, l'implémenter sous SQL Server et ensuite créer mon cube Analysis services basé sur ce modèle.

Par contre, pour les étapes de chargement j'ai un peu peur... je vous tient au courant.

Merci

[Pmatt]

Salut à tous

J'ai un peu avancé dans mon travail et je voudrais avoir votre avis sur ma modélisation en flocon (j'aurais pu faire en étoile, mais c'est dans l'optique d'un exercice pour me familiariser avec tout)

Voici deux images :

- Le schéma relationnel simple
- Le schéma en flocon adapté

Par rapport à ca, je me pose quelques questions :

-Est-ce que j'ai correctement transformé le relationnel en dimensionnel??

Si vous avez des suggestions ou des critiques à faire, n'éhistez pas !

-Est ce que j'ai bien fait de mettre des clés de substitution partout? En ce qui concerne les dimensions principales ca je pense que c'est bon, mais les hiérarchies c'est pas un peu absurde de leur attribuer des clés de substitution alors que elles n'ont pas d'identifiant dans le système opérationnel (ce sont des dates)... Même question pour les hiérarchies Ville, Région, Pays.. la table localisation dans la bdd à un ID donc on lui attribue une clé de substitution dans le DW, mais les hiérarchies comment leur attribue-t-on un ID dans le DW?

Et avec le modèle que j'ai designé, pourrons-nous faire des requetes du style " Dans quel région avons nous réalisé le meilleur bénéfice pour les clients agés de 35 ans sur les produits de type velo" ??


Voila, j'ai encore d'autres questions mais qui viendront par la suite du développement du projet.


Voila, j'éspère que ca vous plait de suivre ce travail.

Merci beaucoup pour les commentaires que vous apporterez !!!

Matt

[Pmatt]

Salut

Vous n'avez pas une petite idée sur la situation? J'ai en effet peur d'aller plus loin sans une confirmation ou des recommandations sur la justesse des schémas.

malgré tout je me rend compte qu'on s'éloigne un peu du sujet initial, désolé

A bientot

[Jester]

Moi je trouve que cela convient. Juste sur la dimension produit, les prix d'achat et de vente vont forcément varier avec le temps. Donc création d'un nouveau produit?

Personnellement, je le mettrais dans la table de fait.

Peut-être aussi ajouter des informations dans la dimension temps, par exemple si c'est une veille de jour férié et si c'est un jour férié. Peut-être rajouter des données orientées sur tes données, comme "période avant noel", si ça peut jouer.

[Pmatt]

Salut Jester

Merci pour ton appréciation concernant mon schéma.

Pour la dimension Produit comme tu le sais c'est ce qu'on appelle une Slowly Changing Dimension, elle peut varier au cours du temps.
Dans ce cas-là, Kimball nous donne 3 possibilités
- Ecraser l'enregistrement
- Créer un nouvel enregistrement avec une nouvelle clé de substitution
- Créer un champ "ancien" et y insérer l'ancienne valeur, mais cela n'autorise qu'a avoir 2 versions.

Ou alors le mieux serait encore comme j'ai pu le lire sur un PDF de développez.com, de mettre un champ version pour chaque produit et indiquer le numéro de version selon les mises-à-jour que l'on a effectué.

Concernant ma dimension temps, j'ai enlevé 4 champs (Annees, Semaines, Trimestres, Mois) et n'ai laissé que leur clé étrangère vu que le modèle en flocon est normalisé, on évite donc les redondances.

Je vais voir ce que je peux modifier selon tes conseils.

Encore merci et à bientot

Matt

[Jester]

En fait, il n'y a que la solution de créer une nouvelle ligne produit, les autres ne fonctionneront pas (tu finira avec un DWH trop incohérent car tu ne pourra plus calculer le même chiffre d'affaire et bénéfice que celui des faits). Et créer une nouvelle ligne produit risque de compliquer l'analyse (enfin ralentir la requête).

Ça dépend des produits, mais ils auront au moins de nouveaux prix une fois par an (pour prendre en compte l'inflation), si tu vends du pétrole ce sera quotidien. Si tu autorise à faire des rabais, promotions, ... tu aura aussi une dimension très changeante.

Moi je le mettrais dans la table de fait. Mais je n'ai plus ton contexte en tête.

le modèle en flocon est normalisé, on évite donc les redondances.

Et tu augmentes les jointures.

[tbabulle]

Bonjour,
Personnellement, je suis partisan de ne JAMAIS rien perdre.
Donc, malgré les bons conseils de ce cher Ralph, je n'écraserais pas les anciens prix.
Je pense qu'il est préférable de gérer des versions de données avec des dates de validité.
Cela permettra par exemple à une direction marketing de pouvoir revenir sur les anciens prix, et de pouvoir anticiper les inflations, d'en tirer les tendances sur les ventes, ect ect ...
De faire ce pour quoi la BI est faite à savoir de l'aide à la décision, voir de la prospective, voir (allez laissons nous aller) du datamining ....
Et puis pour une direction financière, cela permettra également de faire des comparatifs sur les CA, en pouvant isoler par exemple les réductions, car celles-ci n'apparaissent pas forcément dans les données, et ce n'est qu'en comparant prix de vente unitaire et prix moyen de vente que l'on peut les constater.
Tous ces exemples pour dire juste : GARDE TOUTES LES VERSIONS
A ton service,
Thierry
tbabulle@objectif-informatique.fr