Un cube de données est de façon générique un agregat de données en dimension supérieure à 2.
Pour schématiser prenons une socitété. Cette société comprend plusierus services. Chaque service a un budget qui lui est propre et qu'elle répartie dans différent centre de couts ou qu'elle investit sur différents projets. bein entendu il y a à la tête de chaque service un chef et idem à la tête de chaque projet. Tous les mois ces gens font le bilan entre ce qui a été budgeté, Ce qui a été dépensé et ce qu'il est prévu de dépenser au final. Bien entendu celà doit être remonté, par service, par projet et en global par rapport total pour que la société puisse savoir mois après mois ou elle en est.
en approche classique c'est à se taper la tête contre les murs. Il faut créer des clefs et des contraintes dans tous les sens, faire la différence entre ce qui a été alloué directement au projet et ce qui vient des services, le tout avec un suivit mensuel. Et si par malheur deux services fuisonnent ou qu'un projet passe à la trappe, il faut appeler un DBA chevronné pour réussir à recréer des données cohérentes.
Un cube va permettre d'organiser tout celà comme un seul agrégat de données. On va définir des hierarchies et c'est le cube qui va se charger de faire les opérations qui vont bien pour donner des chiffres cohérents.
On aura donc un cube "société"
Une première hiérarchie "année" portant sur toutes les années interressantes (de 2004 à 2008 par exemple)
une seconde hiérarchie "mois" avec les trimestres qui sont la somme des mois correspondant. etc.
Au final :
Année
- 2004
- 2005
- 2006
- 2007
- 2008
Mois
-1 er trimestre
-- janvier
-- février
-- mars
- 2eme trimestre
-- avril
etc.
Services
- informatique
-- administration
--- admin linux
--- admin windows
--- réseaux
--- bases de données oracle
--- bases de données DB2
--- support
etc.
Ensuite on interroge les dimensions : par exemple on peut demander pour l'année 2007 au mois de mars combien le service windows a couté. Le cube va alors chercher l'ensemble des données qui correspondent aux critères et les combine (ici ce sera une addition) pour donner le résultat souhaité.
Le requètage devient alors simplissime. Au cas ou deux services fusionnent il suffit de les déplacer en hiérarchie pour obtenir les données combinées.
exemple :
Services
- informatique
...
--- bases de données unifiées
---- bases de données oracle
---- bases de données DB2
et le cube se charge de mettre dans le nouveau service "bases de données unifiées" la somme des deux anciens services.
Une fois le travail (fastidieux, et j'en sais quelquechose) de définition des hiérarchies terminé on a alors un système de données extrèmement simple et intuitif à interroger. Les utilisateurs finaux peuvent alors créer eux mêmes leurs propres requètes et le DBA n'a qu'à surveiller la charge machine et l'occupation disque (dans un monde théorique hein...)
[^] # Re: Plusieurs hypothèses
Posté par Jerome Herman . En réponse au journal apache perd du terrain face à IIS de manière inquiétante. Évalué à 6.
Pour schématiser prenons une socitété. Cette société comprend plusierus services. Chaque service a un budget qui lui est propre et qu'elle répartie dans différent centre de couts ou qu'elle investit sur différents projets. bein entendu il y a à la tête de chaque service un chef et idem à la tête de chaque projet. Tous les mois ces gens font le bilan entre ce qui a été budgeté, Ce qui a été dépensé et ce qu'il est prévu de dépenser au final. Bien entendu celà doit être remonté, par service, par projet et en global par rapport total pour que la société puisse savoir mois après mois ou elle en est.
en approche classique c'est à se taper la tête contre les murs. Il faut créer des clefs et des contraintes dans tous les sens, faire la différence entre ce qui a été alloué directement au projet et ce qui vient des services, le tout avec un suivit mensuel. Et si par malheur deux services fuisonnent ou qu'un projet passe à la trappe, il faut appeler un DBA chevronné pour réussir à recréer des données cohérentes.
Un cube va permettre d'organiser tout celà comme un seul agrégat de données. On va définir des hierarchies et c'est le cube qui va se charger de faire les opérations qui vont bien pour donner des chiffres cohérents.
On aura donc un cube "société"
Une première hiérarchie "année" portant sur toutes les années interressantes (de 2004 à 2008 par exemple)
une seconde hiérarchie "mois" avec les trimestres qui sont la somme des mois correspondant. etc.
Au final :
Année
- 2004
- 2005
- 2006
- 2007
- 2008
Mois
-1 er trimestre
-- janvier
-- février
-- mars
- 2eme trimestre
-- avril
etc.
Services
- informatique
-- administration
--- admin linux
--- admin windows
--- réseaux
--- bases de données oracle
--- bases de données DB2
--- support
etc.
Ensuite on interroge les dimensions : par exemple on peut demander pour l'année 2007 au mois de mars combien le service windows a couté. Le cube va alors chercher l'ensemble des données qui correspondent aux critères et les combine (ici ce sera une addition) pour donner le résultat souhaité.
Le requètage devient alors simplissime. Au cas ou deux services fusionnent il suffit de les déplacer en hiérarchie pour obtenir les données combinées.
exemple :
Services
- informatique
...
--- bases de données unifiées
---- bases de données oracle
---- bases de données DB2
et le cube se charge de mettre dans le nouveau service "bases de données unifiées" la somme des deux anciens services.
Une fois le travail (fastidieux, et j'en sais quelquechose) de définition des hiérarchies terminé on a alors un système de données extrèmement simple et intuitif à interroger. Les utilisateurs finaux peuvent alors créer eux mêmes leurs propres requètes et le DBA n'a qu'à surveiller la charge machine et l'occupation disque (dans un monde théorique hein...)