Bonjour à tous,
je recherche un bon cours théorique sur les bases de données multidimensionnelles.
Merci beaucoup.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Cours bases de données multidimensionnelles
Bonjour à tous,
je recherche un bon cours théorique sur les bases de données multidimensionnelles.
Merci beaucoup.
Tu cherches un cours sur OLAP ?? ou sur la modélisation dimensionnelle (schémas en étoile, flocon, conception d'entrepôt de données) ?? Ce n'est pas du tout la même chose.
Pour OLAP, c'est plus des notions mathématiques : http://pagesperso-orange.fr/bernard.lupin/index.htm
Pour la conception d'entrepôts de données, la référence étant le livre de Kimball : The DataWarehouse Toolkit (disponible aussi en français chez Vuibert je crois)
Je recherche un cours mathématique sur les hypercubes et les opérations qu'on peut leur appliquer.
Merci
Mmmmmmmmmm c'est bien compliqué ce que tu cherches
Désolé mais à part les infos sur Google (wikipedia et le site en haut) je n'ai pas beaucoup d'informations sur les mechanismes internes des cubes. Mis à part le fait qu'il y ait une gestion des matrices creuses et que sa se rapproche beaucoup de l'algèbre matricielle..
J'aimerais bien qu'on m'explique en détail cette théorie des "matrices creuses".
Ca m'a l'air un peu 'fumeux' tout ça, non ?
N'est-ce pas une approche utilisée dans les algorithmes de compression des premières bases de données multidimensionnelles, Essbase en l'occurence ?
Est-ce aujourd'hui encore, d'actualité ?
Est-ce un pur concept marketing ?
???
Non non, la gestions des matrices creuses est effectivement une technique de compression de cubes (de matrices). Les cubes ont la particularité d'avoir beaucoup de "cellules" vides (pas de coisements)... On y applique cette gestion afin de minimiser l'espace que prend les matrices.
Et ce n'est pas propre à Essbase puisque c'est une des régles de CODD pour qu'un outil soit OLAP.
Mmmouais....
Désolé Ygrim, mais ton argumentation ne me convainc pas.
1°) Pour résumer, un cube n'est ni plus ni moins :
- qu'une table de faits comportant des clés les reliant aux différentes dimensions.
- des tables de dimensions.
Je ne vois pas ou se trouvent les trous la dedans ???
2°) S'il existait des "trous" pourquoi donc existerait-t'il également une problématique de complétude ?
Cette dernière peut être gérée par la mise en place de jointures externes, ou bien prise en charge par la solution de restitution
OOOOOOOOOOOOOO !Envoyé par Paul_S
Dans le point 1 tu donnes la définition d'un modèle en étoile ! C'est la représentation RELATIONNELLE d'un datamart, rien à voir avec le cube... Le cube est géré par un sgbdm alors que l'entrepôt de données est géré par un SGBDR. Après toutes les discussions qu'on a eu !!!!
Pour ton point numéro 2, la gestion des matrices creuses est un ensemble d'algorithmes et de techniques (regardes sur wikipedia) qui permet l'optimisation de l'espace en exploitant le "vide" dans les matrices. La représentation physique d'un cube dans un sgbdm m'est inconnue mais ce n'est pas comme en relationnel c'est sur. Pour MOLAP par exemple, on s'arrange pour avoir toutes les agrégations et tous les croisements possibles... Y'a de quoi optimiser non ?
Pas d'accord.
Tu fais l'amalgame entre :
- Représentation physique du cube dans le SGBD
- Ta modélisation 'logique' du cube
En fait, SGBDR ou SGBDM c'est une vue de l'esprit ! Au final, le SGBD gère des tables, qui sont toujours stockées (à peu de chose près) de la même manière. C'est la couche MDX qui fait la différence.
Rien n'est moins sur...Pour MOLAP par exemple, on s'arrange pour avoir toutes les agrégations et tous les croisements possibles...
Merci pour Essbase !
On va faire un raisonnement par l'absurde. Si les SGBDM ne sont qu'une vue de l'esprit, comment se fait-il que les performances soient au rdv contrairement au sgbr, puisque tu dis que le stockage se fait de la même manière ?
http://www.decideo.fr/HYPERION-ESSBA...eurs_a179.html
Tu fais l'amalgame entre :
- Représentation physique du cube dans le SGBD
- Ta modélisation 'logique' du cube
En fait, SGBDR ou SGBDM c'est une vue de l'esprit ! Au final, le SGBD gère des tables, qui sont toujours stockées (à peu de chose près) de la même manière. C'est la couche MDX qui fait la différence.
Rien n'est moins sur...
Quelle est la representation logique d'un cube ??? Est-ce simplement une matrice ???
Aussi je ne vois pas pourquoi il y'aura plein de zero dans cette matrice. Puisque les elements de cette matrice sont les tuples de la table de fait qui correspond au datamart utilisé pour créer le cube. Et cette table de fait possède des clès etrangères vers les tables de dimmension.
le fait est que dans un cube certaine dimensions qui se croisent n'ont pas forcément un point commun pour chaque tuple d'ou ces "trou".
le cube n'est pas logiquement crée à chaque fois a partir d'un datamart
a chaque solution sa représentation
dans ce domaine je pense que tu peux raisonnablement interroger 10 personnes et avoir 10 réponses différentes avec bien évidemment des similitudes qui vont revenir.
la représentation logique d'un cube qu'entend tu par logique ?pour moi, la représentation logique d'un cube est un cube.
Décidément, ce discours sera toujours sans fin...
Tout d'abord, l'expérience prouve qu'il convient de considérer avec beaucoup de recul les articles de ce type, et se garder de toute interprétation hasardeuse : n'importe quel éditeur peut dire qu'il a mis au point une nouvelle technique de compression, et gna gna gna..., et qu'elle optimise les temps de réponse, et qu'elle... bref c'est la meilleure.
Et loin de moi l'idée de remettre en question la technologie Essbase, qui est une belle solution certainement très performante. Ce n'est cependant qu'une annonce marketing, et comme toujours dans ce type de discours, aucun détail technique n'est apporté sur la technologie utilisée (mais aussi parce que ce n'est pas l'objet de l'annonce).
Pour répondre à la question d'Ygrim, les perf sont au RV parce que l'ensemble des n-uplets de faits sont existants pour toute combinaison des dimensions (mais certainement pas de manière exhaustive, d'ou mon interrogation sur la fameuse théorie des matrices creuses), et ce Physiquement. Ce qui n'est pas le cas dans une modélisation de type forme normale relationnelle, qui est utilisée dans les outils métier ou ERP.
Ce que je pense, c'est qu'au niveau du moteur de base de données, il existe des objets élémentaires dans les couches basses, qui sont des tables, des données, des index ... mais certainement pas des cubes !
Ces tabes sont simplement constituées différemment si elles doivent intervenir dans un contexte multidimensionnel.
Une représentation mathématique d'une matrice n*m est l'endomorphisme f tel que:
f = ∑xiei, xi=(a1,...aj,...am) 1<i<n et 1<j<m
(e1,...,en) constituent la base ou les dimensions de notre endomorphisme.
Comment peut presenter un cube de cette manière n*m*k est de maniere générale un cube à plusieurs dimensions ???
J'utilise le terme logique mais en fait je veux dire mathématique, désolé
MERCI
Est ce qu'on peut interrogé un datawarehouse directement avec SQL ???
les logiciels permettant de créer son datawarehouse sont des générateurs sql le plus souvent, il parait donc logique que l'on puissent intérroger le datawarehouse directement en SQL.
a partir du moment ou l'on a accès aux tables je dirai que oui.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager