Datawarehouse (entrepôt de données) et base de données multidimensionnelles / OLAP

[orambs]

Bonjour,
Je suis débutant j'aimerai bien savoir la différence entre datawarehowse (DWH), base de données multidimensionnelles et OLAP et si à partir de DWH on peut avoir une base multidim et comment.
j'ai lus pas mal de doc mais on dit comme quoi la conception de DWH se fait avec un modèle étoile et je trouve la même chose pour une base multidimensionnelles (faite avec un modèle étoile le même que le DWH) puis on parle des cube pour les base multidimensionnelles. Est ce que ça veut dir dans une base multidimensionnelles on stock le résultats des opérations d'agrégation sur les données de DWH ? .

MERCI BEAUCOUP PAR AVANCE

[doc malkovich]

Bonjour,
Le modèle en étoile est une méthode de conception qui permet de séparer les faits ( mesures ) et les dimensions ( axes d'analyse, typologie ). Dans un DWH sur une base de données classique on aura donc une table centrale ( les faits ) avec les tables de dimension autour. Cela permet un requêtage simple et performant, mais avec des tables à volumétrie importante il vaut mieux se tourner vers des bases MOLAP ou multidim comme tu dis, où le temps de réponse est instantané. Il s'agit dans ces bases de stocker toutes les possibilités d'agrégation possibles comme tu le pressentais.

Voilà, en gros
Après on peut aller dans le détail mais ça risque d'être plus long

[donino]

Salut,

La confusion est en effet aisée car une base multidimensionnelle est avant tout un concept, pas une technologie. Par exemple comme le souligne doc, un (datawarehouse) modélisé en étoile / flocon est une base multidimensionnelle, même si il est implémenté et requêté sous MySQL... On peut en plus utiliser en aval un SGBD-M mais c'est autre chose.

Vient donc la question du requêtage OLAP sur cette base.:

1-via les SGBD-R (relationnels): teradata, oracle, sqlserver, db2, sybase, etc. On parle alors d'outils R-OLAP, on requête en général directement sur le DWH: Microstrategy (hybride), Business Objects, Cognos etc sont utilisés pour produire les rapports. Le principal inconvénient de cette architecture est de nécessiter une forte expertise et des charges conséquentes de tuning lors de l'alimentation des données (principalement dénormalisations, tables d'aggrégats précalculées, partitionnement, indexation, création de datamarts intermédiaires, etc).

2- via les SGBD-M (Multidimensionnels stockés):Essbase, Analysis Services, Oracle express, etc. Basés principalement sur une technologies de blocs "dense" indexés, du point de vue utilisateur ils précalculent et stockent à partir du DWH tous les aggrégats et indicateurs possibles pour produire des résultats instantanés, et une navigation d'un confort incomparable. Les inconvénients sont une mauvaise résistance aux très fortes volumétries, et surtout le fait de devoir prédéfinir les axes de calculs, ce qui est gênant pour les requêtes adhoc sur des entrepôts contenant parfois plus d'un millier de tables et des dizaines de milliers de rubriques.

3-via les SGBD-V (verticaux ou vectoriels): Sybase IQ, Infobright, Qlikview, solutions "All memory" diverses. En gros ils reprennent les qualités des SGBD-R et SGBD-M en gommant les défauts, assurément l'avenir de la BI.

[asphp]

Un cube (comme Essbase) gère naturellement les stockages cartésiens sans jointures, puisqu'il ne contient pas de tables, mais des blocs de données dans un cadre matriciel multidimensionnel.

Par contre, une requête qui génère un produit cartésien est un vrai problème pour les bases de données relationnelles qui peut faire tomber le serveur

On peut toujours bricoler une base de données relationnelle (ROLAP) pour analyser les données mais elle n'est pas faite pour. La redondance des informations est ce qu'il faut éviter dans les tables, alors qu'en analyse OLAP, c'est une nécessité. Une requête sql décisionnelle peut prendre énormément de temps même avec un dataware optimisé. Les cubes fournissent des données pré-agrégées, pré-calculées et sont naturellement optimisés pour l'analyse OLAP.

Donc clairement :
=> OLTP pour la gestion des données avec une gestion optimisée des transactions (insert, update, delete, commit, ...) et des données unitaires (factures, commandes, ...)

=> OLAP pour l'analyse des données avec une gestion optimisée de l'analyse et des données agrégées, calculées, stockées (chiffre d'affaire, moyenne, ...)

Voilà 2 mondes différents. L'OLTP étant le plus étudié dans les écoles (cf dans le cours de base de données : la 3ème forme normale de la modélisation relationnelle normalisée...)