Discussion :

[missjustme]

Bonjour !

Je suis actuellement en stage et je dois mettre en place une solution décisionnelle... Je connais les grands concepts de la chaine décisionnelle, mais seulement dans la théorie... Pourriez-vous m'éclairer un peu plus au niveau pratique ? (Désolée, je sais que mes questions sont bêtes et vraiment dignes d'une débutante...)

1) J'ai modélisé mon datawarehouse avec un schéma en étoile, et maintenant je souhaite le mettre en place sous Oracle. Comment faut-il que je m'y prenne concrètement ? Quand on dit construire un datawarehouse, est-ce que cela signifie créer les tables du modèle en étoile que j'ai fait, et ce exactement comme si je créais les tables d'une BD relationnelle sous Oracle (avec des CREATE TABLE) ?


2) Je compte utiliser KETTLE comme ETL pour alimenter mon DW. Concrètement, est-ce que si j'envoie directement les données à partir des différentes sources vers mon DW que j'aurai construit sous Oracle (cf. question 1) grâce à Kettle (avec éventuellement des transformations), c'est ce qu'il faut faire ?

3) Je voulais utiliser Mondrian pour créer mes cubes, et pour le reporting : Jfreereport, Birt ou encore IReport de Jasper (des outils open sources en gros). Est-ce que ces outils peuvent se connecter directement aux cubes créés sous Mondrian ?


Merci d'avance pour vos réponses...

@++

[al1_24]

1) J'ai modélisé mon datawarehouse avec un schéma en étoile, et maintenant je souhaite le mettre en place sous Oracle. Comment faut-il que je m'y prenne concrètement ? Quand on dit construire un datawarehouse, est-ce que cela signifie créer les tables du modèle en étoile que j'ai fait, et ce exactement comme si je créais les tables d'une BD relationnelle sous Oracle (avec des CREATE TABLE) ?

A moins que tu fasses des vues sur des données de production présentes sur la même base...

[missjustme]

A moins que tu fasses des vues sur des données de production présentes sur la même base...

Tout d'abord, merci pour ta réponse...

L'entrepot de données peut correspondre soit à des tables physiques, soit à des vues alors ?

Quels sont les intérêts de l'une et l'autre solution ?


Et est-ce que cela concerne à la fois la table des faits et les tables de dimension ?

[VinZent]

L'entrepot de données peut correspondre soit à des tables physiques, soit à des vues alors ?
Quels sont les intérêts de l'une et l'autre solution ?
Et est-ce que cela concerne à la fois la table des faits et les tables de dimension ?

Tout à fait : des tables physiques ou bien des vues. Si tu dois faire appel à des vues, je te recommande (vu que tu es sous Oracle) la mise en place de vues matérialisées (snapshots) plutôt que de simples vues. Un snapshot réunit l'avantage d'une vue (rafraichissement et recalcul) et d'une table (stockage physique). Le refresh d'un snapshot peut se faire en auto ou manuel et en différentiel ou en mode complet (voir doc).

Après tout dépend de tes besoins et contraintes. A titre d'exemple, il m'arrive souvent d'utiliser des vues matérialisées (snapshots) afin de bâtir des tables d'agrégats sur mes tables de faits. Rarement sur les dimensions à vrai dire car il me faut souvent assurer le suivi des évolutions.

L'implémentation de ton entrepôt correspond à la création de ces structures, soit par l'exécution des scripts correspondants, soit au travers de ton outil d'ETL. Après, de manière très simplifiée, arrive la phase d'alimentation initiale. Puis, juste après les alimentations récurrentes (différentielles ou complètes).
Une alimentation type correspond souvent à :

• l'alimentation primaire, qui consiste à peupler ton entrepôt avec les nouvelles données de production (capturées en différentiel incrémental),
• l'alimentation secondaire, qui consiste à bâtir les agrégats et les structures de données évoluées (enrichies, croisées ...), basées sur les données rapatriées lors de ton alimentation primaire. Ce sont ces structures de données qui seront prioritairement ouvertes aux requêtes de tes utilisateurs.

Chez certains poêtes tels que moi, on parle alors du passage d'un concept de données à celui d'information.

En espérant que cela t'apporte quelques lumières.

[missjustme]

Tout d'abord, merci beaucoup pour ta réponse !

Et puis, j'ai trouvé ça génial ce que tu as écrit sur Kettle et les autres outils de la suite Pentaho dans un autre topic... ça aussi ça va m'aider !

Tout à fait : des tables physiques ou bien des vues. Si tu dois faire appel à des vues, je te recommande (vu que tu es sous Oracle) la mise en place de vues matérialisées (snapshots) plutôt que de simples vues. Un snapshot réunit l'avantage d'une vue (rafraichissement et recalcul) et d'une table (stockage physique). Le refresh d'un snapshot peut se faire en auto ou manuel et en différentiel ou en mode complet (voir doc).

Si je crée mon entrepôt de données avec des vues matérialisées, cela veut dire que je dois quand même créer des tables physiques non ? car les vues matérialisées s'appuient sur des tables physiques il me semble... Que représentent ces tables physiques ? Des copies des tables de la base de production ? des tables créées spécifiquement pour l'entrepôt ? ... ?

Mais dans ce cas, si je dois créer et des tables, et des vues, à quoi cela sert-il de créer des vues ?

Après tout dépend de tes besoins et contraintes. A titre d'exemple, il m'arrive souvent d'utiliser des vues matérialisées (snapshots) afin de bâtir des tables d'agrégats sur mes tables de faits. Rarement sur les dimensions à vrai dire car il me faut souvent assurer le suivi des évolutions.

Qu'appelles-tu les tables d'agrégats ? Est-ce que cela correspond aux données de la table des faits mais agrégées selon une ou plusieurs dimensions ? Et dans ce cas, ces tables d'agrégats ne sont reliés à aucun modèle en fait ? Est-ce que ce sont juste des tables qui servent à accélérer l'accès à des données agrégées ?

D'après ce que je comprends, tes tables de dimension sont des tables physiques ? Et qu'entends-tu par "assurer le suivi des évolutions" ?

L'implémentation de ton entrepôt correspond à la création de ces structures, soit par l'exécution des scripts correspondants, soit au travers de ton outil d'ETL.

Un ETL permet-il de générer directement la création d'un entrepôt ? Et en particulier KETTLE ?
Moi je pensais plutot :
1) On crée l'entrepôt (sa structure physique).
2) on l'alimente grâce à l'ETL en faisant une connexion dessus.

Est-ce que c'est une vue fausse ?

Après, de manière très simplifiée, arrive la phase d'alimentation initiale. Puis, juste après les alimentations récurrentes (différentielles ou complètes).
Une alimentation type correspond souvent à :

• l'alimentation primaire, qui consiste à peupler ton entrepôt avec les nouvelles données de production (capturées en différentiel incrémental),
• l'alimentation secondaire, qui consiste à bâtir les agrégats et les structures de données évoluées (enrichies, croisées ...), basées sur les données rapatriées lors de ton alimentation primaire. Ce sont ces structures de données qui seront prioritairement ouvertes aux requêtes de tes utilisateurs.

Les structures de données dont tu parles, est-ce les cubes ?


Merci beaucoup pour tes réponses... Je me rends compte que j'ai vraiment des questions de débutant, mais on va dire qu'il y a un début à tout...

[VinZent]

Tout d'abord, merci beaucoup pour ta réponse !
Et puis, j'ai trouvé ça génial ce que tu as écrit sur Kettle et les autres outils de la suite Pentaho dans un autre topic... ça aussi ça va m'aider !

Je te remercie.

Si je crée mon entrepôt de données avec des vues matérialisées, cela veut dire que je dois quand même créer des tables physiques non ? car les vues matérialisées s'appuient sur des tables physiques il me semble... Que représentent ces tables physiques ? Des copies des tables de la base de production ? des tables créées spécifiquement pour l'entrepôt ? ... ?
Mais dans ce cas, si je dois créer et des tables, et des vues, à quoi cela sert-il de créer des vues ?

Tout dépend de l'architecture et des moyens dont tu disposes.
Disons que, d'une manière générale, un entrepôt à vocation décisionnelle se compose d'une database dédiée, située hors du contexte opérationnel et transactionnel (machine dédiée) hébergeant des tables physiques et / ou des vues matérialisées ou non.
Par ailleurs, l'on retrouve fréquement des tables physiques comme structure principale de stockage de l'information. Ces tables physiques peuvent se décomposer en deux grandes familles :

• les tables hébergeant une copie des données de production : il s'agit de la matière première de ton entrepôt, caractérisé par un historique profond.
• les tables hébergeant l'information raffinée, retravaillée, agrégée : ces tables sont attaquées par les outils de requetes ou d'analyse pilotés par les utilisateurs finaux.

Cette distinction peut se marquer fortement dès lors que l'on constitue un datawarehouse d'un coté (les données d'historique) et un ou des datamarts de l'autre (les données certifiées, nettoyées, agrégées, croisées ...). La séparation datawarehouse / datamart peut être réalisée par un simple user/schéma (Oracle) ou bien à l'aide de deux databases / machines dédiées (pour les projets d'envergure). La distinction est souvent dictée par l'aspect fonctionnel des données et informations gérées : datamart controle de gestion, datamart marketing, datamart RH ... A voir comme un partitionnement logique, mais aussi physique, de ton entrepôt.

Qu'appelles-tu les tables d'agrégats ? Est-ce que cela correspond aux données de la table des faits mais agrégées selon une ou plusieurs dimensions ? Et dans ce cas, ces tables d'agrégats ne sont reliés à aucun modèle en fait ? Est-ce que ce sont juste des tables qui servent à accélérer l'accès à des données agrégées ?

Les tables d'agrégats (ou vues matérialisées) sont des structures qui stockent des données préalablement agrégées et retraitées. Imagine une table de fait d'un entrepôt de données qui centralise les ventes quotidiennes de l'entreprise, détaillées au jour, au produit et au magasin. Une table agrégée type serait : ventes au mois et à la région. Imagine une requête de type SUM et GROUP BY ...
L'avantage des tables d'agrégats c'est que l'agrégation n'a plus à être réalisée à la volée, lors de l'analyse. Elle est déjà faite et l'information est initialement disposée sous le bon format et la bonne granularité : les performances sont meilleures.
Attention cependant de bien prévoir la granularité attendue par les utilisateurs car l'agrégation tue le détail : une fois au niveau région, je ne pourrai pas proposer le niveau magasin ou ville à mes utilisateurs, à moins de refondre la table d'agrégat ou d'en faire une autre.

D'après ce que je comprends, tes tables de dimension sont des tables physiques ? Et qu'entends-tu par "assurer le suivi des évolutions" ?

Oui, la plupart du temps.
Assurer le suivi des évolutions, pour les dimensions, revient à tracer et à historiser tout changement. Imagine une dimension produit, qui contient tous les attributs descriptifs d'un produit. Parmis ces attributs, un changement intervient : un produit voit son poids augmenté. A partir de là, il peut être nécessaire d'avoir dans l'entrepôt les deux versions du produit dans la dimension : le produit initial avec son poids initial et le produit remanié qui affiche un poids supérieur. Cela est valable aussi pour les statuts matrimoniaux, les capacités de stockage d'un hotel, les garanties couvertes par un contrat d'assurance, l'état de santé et la pathologie d'un patient ...

Un ETL permet-il de générer directement la création d'un entrepôt ? Et en particulier KETTLE ?
Moi je pensais plutot :
1) On crée l'entrepôt (sa structure physique).
2) on l'alimente grâce à l'ETL en faisant une connexion dessus.
Est-ce que c'est une vue fausse ?

Oui, tu peux directement générer la création d'un entrepôt via l'ETL. Je parle des structures de données cibles (tables, vues ...). Pour autant, rien ne vaut la réflexion et le design avant toute chose à l'aide d'un outil de modélisation (ERWin, PowerAMC ...).
Tout dépend des contraintes et de ton expérience. Pour ma part, je dois parfois passer par une phase complète de design et d'implémentation de l'entrepôt sur certains projets sensibles. Sur d'autres, plus simples et plus réduits, et où l'on voit clairement la cible à atteindre, on peut passer par un design à la volée au travers de l'outil d'ETL. Cela nécessite une bonne expérience et de la vista.

Les structures de données dont tu parles, est-ce les cubes ?

Pas à ce niveau. Par structures de données, dans cette phrase, j'entends table ou vue.

Merci beaucoup pour tes réponses... Je me rends compte que j'ai vraiment des questions de débutant, mais on va dire qu'il y a un début à tout...

Je t'en prie, j'espère que les explications sont assez claires.

[missjustme]

MERCIIIIIIII BEAUCOUP pour ton aide !!! et pour ta réactivité !!!

Tes explications m'éclairent énormément et on voit bien que tu maîtrises le sujet... C'est cool d'être tombé sur un expert du domaine...
En tout cas, de toute évidence, tu expliques les choses 100 fois mieux que mes profs...

Par contre, j'ai encore quelques petites questions si ça ne te dérange pas...

Par ailleurs, l'on retrouve fréquement des tables physiques comme structure principale de stockage de l'information. Ces tables physiques peuvent se décomposer en deux grandes familles :

• les tables hébergeant une copie des données de production : il s'agit de la matière première de ton entrepôt, caractérisé par un historique profond.
• les tables hébergeant l'information raffinée, retravaillée, agrégée : ces tables sont attaquées par les outils de requetes ou d'analyse pilotés par les utilisateurs finaux.

Cela signifie-t-il que le datawarehouse (le premier entrepot de données) ne doit pas directement être interrogé par les outils de requêtes et d'analyse ?

Cette distinction peut se marquer fortement dès lors que l'on constitue un datawarehouse d'un coté (les données d'historique) et un ou des datamarts de l'autre (les données certifiées, nettoyées, agrégées, croisées ...). La séparation datawarehouse / datamart peut être réalisée par un simple user/schéma (Oracle) ou bien à l'aide de deux databases / machines dédiées (pour les projets d'envergure).

Est-il possible de mettre le datawarehouse et les datamarts dans la même base ou est-ce que c'est contraire à une bonne architecture ?

Les tables d'agrégats (ou vues matérialisées) sont des structures qui stockent des données préalablement agrégées et retraitées.

Les tables d'agrégats, est-ce que ce sont les datamarts ?

Assurer le suivi des évolutions, pour les dimensions, revient à tracer et à historiser tout changement. Imagine une dimension produit, qui contient tous les attributs descriptifs d'un produit. Parmis ces attributs, un changement intervient : un produit voit son poids augmenté. A partir de là, il peut être nécessaire d'avoir dans l'entrepôt les deux versions du produit dans la dimension : le produit initial avec son poids initial et le produit remanié qui affiche un poids supérieur. Cela est valable aussi pour les statuts matrimoniaux, les capacités de stockage d'un hotel, les garanties couvertes par un contrat d'assurance, l'état de santé et la pathologie d'un patient ...

Et donc dans ton exemple, on aurait le même produit stocké 2 fois dans le datawarehouse, la seule différence entre les 2 enregistrements étant le poids ?


Encore merci pour tes réponses...

[VinZent]

MERCIIIIIIII BEAUCOUP pour ton aide !!! et pour ta réactivité !!!

Tes explications m'éclairent énormément et on voit bien que tu maîtrises le sujet... C'est cool d'être tombé sur un expert du domaine...
En tout cas, de toute évidence, tu expliques les choses 100 fois mieux que mes profs...
Par contre, j'ai encore quelques petites questions si ça ne te dérange pas...

Je t'en prie.
J'ai toujours voulu enseigner. Je me verrais bien le faire en DUT par exemple, mais bon, question de temps ...

Cela signifie-t-il que le datawarehouse (le premier entrepot de données) ne doit pas directement être interrogé par les outils de requêtes et d'analyse ?

Assez rarement en fait. Il faut voir cet entrepôt comme un réservoir de matière première utile à la construction des informations présentes sur le second niveau, là où réside l'information de portée analytique.
Mais là ancore, aucune règle intégriste ne doit s'imposer. Il peut être envisagé et nécessaire pour certains utilisateurs de vouloir retomber sur l'information de niveau atomique qui est stockée dans l'entrepôt. Si le besoin est là, une réponse négative n'est pas la bonne solution. On ouvre alors la fonctionnalité mais en l'encadrant de règles précises et strictement liées au besoin.

Est-il possible de mettre le datawarehouse et les datamarts dans la même base ou est-ce que c'est contraire à une bonne architecture ?

Cela est tout à fait possible et tout dépend du budget, de l'architecture, des moyens, de la politique interne et des
Généralement, cependant, le datawarehouse dispose de sa propre base ainsi que chacun des datamarts. Mais il n'est pas rare, loin de là, de rencontrer des architectures du style :

• une base hébergeant datawarehouse et datamarts, la ségrégation se faisant via un schéma ou user (type oracle),
• une serveur hébergeant datawarehouse et datamarts, la ségrégation se faisant via les bases de données (type SQL Server),
• une base hégergeant le datawarehouse et une base hébergeant les datamarts au complet ...
• un serveur pour le datawarehouse et des serveurs pour les datamarts (projets d'envergure / internationalisation ...).

Tout est possible, même si de grandes règles se sont imposées avec le temps (car ayant prouvé leur efficacité).

Les tables d'agrégats, est-ce que ce sont les datamarts ?

La place d'une table d'agrégat est effectivement plus du coté d'un datamart que du coté du datawarehouse. Par datamart, j'entends par là toute structure de données ouverte aux requête des utilisateurs (le terme datamart tend à ne plus être de mode ...).

Et donc dans ton exemple, on aurait le même produit stocké 2 fois dans le datawarehouse, la seule différence entre les 2 enregistrements étant le poids ?

Oui, chacun ayant un attribut poids différent.
Ce concept est un peu ardu et il peut se traduire de deux manière :

• un enregistrement unique du produit mais disposant d'un attribut "ancien poids" et d'un "nouveau poids"
• deux enregristremnts du même produit mais chacun disposant d'un attribut poids différent.

On touche là les trois grands types de suivi d'évolution des dimension :

• écrasement de l'ancien produit par le nouveau. Le produit, tel que vu dans la base, aura toujours l'air de n'avoir eu qu'un seul poids dans le temps,
• ajout d'un champs pour tracer le nouvel attribut poids,
• ajout d'un nouvel enregistrement du produit pour tracer le nouvel attribut poids.

Sur ce sujet, je t'aiguille vers le sujet classique des "slowly changing dimensions" dont de nombreux articles sur le web s'y consacrent. A potasser avec sérieux.

Encore merci pour tes réponses...

You're welcome.

[missjustme]

Merci beaucoup pour ces nouvelles réponses... Je commence à mieux comprendre concrètement tous ces concepts...

J'ai 3 autres questions qui me turlupinent actuellement :

1) Est-ce possible d'avoir une table de dimension qui contienne autant d'enregistrements que la table des faits ?

-> Par exemple, j'ai une dimension temps dans laquelle je souhaite garder un niveau de granularité assez élevé : jour et heure précise (heures, minutes, secondes). Cela entraine que le nombre d'enregistrements dans cette table de dimension est égal au nombre d'enregistrements de la table des faits car chacun de ceux-ci ont une date/heure différente.


2) Peut-on avoir des champs autres que des mesures dans la table des faits, c'est à dire des champs non numériques qui caractérise chaque fait ? Ou faut-il dans ce cas créer une dimension avec ces caractéristiques non numériques (sachant que dans ce cas, on aurait encore la problématique de la 1ere question : une table de dimension qui contiendrait autant d'enregistrements que la table des faits) ?

[VinZent]

1) Est-ce possible d'avoir une table de dimension qui contienne autant d'enregistrements que la table des faits ?
-> Par exemple, j'ai une dimension temps dans laquelle je souhaite garder un niveau de granularité assez élevé : jour et heure précise (heures, minutes, secondes). Cela entraine que le nombre d'enregistrements dans cette table de dimension est égal au nombre d'enregistrements de la table des faits car chacun de ceux-ci ont une date/heure différente.

En effet, tu attaques fort pour une première.
Généralement les tables de faits sont dites plus profondes que les tables de dimensions : elles contiennent largement plus de rows (j'en ai de 200 millions ...). Par contre les tables de dimensions sont dites plus larges : elles contiennent plus d'attributs descriptifs, c'est à dire plus de colonnes.
Facile à retenir : largeur vs profondeur, c'est une image parlante.

Dans ton cas, mais je ne connais pas toutes tes contraintes et ton organisation de données, je pense que tu devrais considérer la date / heure de ta table de faits comme une dimension à part entière. On appelle cela une dimension dégénérée. C'est très utile pour éviter une jointure vers une table dès lors que l'on manipule une dimension courte : dans ton cas, date / heure.
As tu besoin d'autres attributs pour ta dimension temps, tel que saison, numéro de semaine, trimestre ... ? Si oui, ma réponse sera peut être à reconsidérer

2) Peut-on avoir des champs autres que des mesures dans la table des faits, c'est à dire des champs non numériques qui caractérise chaque fait ? Ou faut-il dans ce cas créer une dimension avec ces caractéristiques non numériques (sachant que dans ce cas, on aurait encore la problématique de la 1ere question : une table de dimension qui contiendrait autant d'enregistrements que la table des faits) ?

Dès lors que tu n'as pas de cardinalité importante entre ton fait et sa dimension (relations à plusieurs) et qu'il s'agit de dimensions courtes (1 attribut), je te conseille de considérer directement les champs de la table de faits comme des dimensions dégénérées. Si chaque champs de caractéristique te permet de lier vers des attributs descriptifs nombreux ou détaillés, crée une dimension correspondante.
Là encore, ce n'est pas une règle car l'exception peut surgir à tout moment, mais c'est un principe dégagé de l'expérience.

Vu la portée de tes questions, je te conseille dès à présent de poser sur le papier un petit MPD. Ces concepts sont un peu arides à expliquer sans schéma.

[missjustme]

J'ai déjà fait un MPD de l'entrepot, mais j'ai du mal à voir si il est viable...

Voici une version très simplifié de ce MPD pour que tu comprennes (enfin j'espère) d'où viennent mes interrogations...

Toutes tes remarques sont les bienvenues car là j'ai l'impression de tourner en rond...

[VinZent]

A première vue, je dirais que ton modèle pèche par excès de zèle.
Pourquoi t'embéter à faire un star schéma alors que tes dimensions sont très réduites ?

• Utilisateur : un seul attribut
• Type commande : un seul attribut,
• Commande : 3 attributs, composés chacun d'un caractère (c'est bien cela ?)
• Temps : date + heure

Dans un cas similaire, en ce qui me concerne, je dénormaliserais toutes ces dimensions dans la table de fait, c'est à dire les traiter en tant que dimensions dégénérées.
Tes dimensions sont toutes petites, ta table de fait idem. Pourquoi s'embéter à vouloir monter à tout prix un star schéma et créer des jointures ? Faire une jointure pour assurer la liaison vers un seul attribut (même 2 ou 3) est trop cher payé. En effet, monter un modèle de données implique parfois de raisonner en terme de rapport qualité / prix.

Pars plutôt vers une structure unique, composée de :
** TEMPS_TRAITEMENT **
id,
nom_type_commande,
nom_util,
Historisé,
Expliqué,
En attente,
Date,
tmps_traitement,
tmps_consolidation,
nb_erreurs
*********************

Certes ta table sera un peu plus complexe, tu auras plus de volumétrie et de nombreuses redondances d'informations mais au final, lors des queries, les performances seront au rendez vous (car pas de jointure) et tu auras moins de structures à gérer. Pense à indexer.
En ce qui concerne la date, tu peux gérer le numéro de semaine en le stockant lui aussi dans la table ou bien en le générant à la volée lors des queries.

Tu touches là un exemple même d'implémentation pragmatique et réaliste, qui s'éloigne des templates que l'on rencontre en cours ou dans les livres.

Qu'en penses tu ?

[missjustme]

Merci beaucoup pour tous ces conseils !!!

Juste 2 ou 3 remarques :

- Je trouve ton approche tout à fait cohérente !!! Est-ce que les informations supplémentaires suivantes changeraient ta vision des choses ou est-ce que tu resterais sur la même position :

Volumétrie :

* Utilisateur : 760 enregistrements
* Type_commande : 13 enregistrements
* Commande, Temps_traitement et Temps : chacun possède 587 116 enregistrements

D'autre part :

* id_util : number
* nom_util : varchar2(50)
* id_type_cmd : number
* nom_type_cmd : varchar2(50)
* id_cmd : varchar2(40)
* Date : date

Voilà voilà...

D'autre part, qu'aurais-tu mis comme index à part sur la clef primaire ?

Dernière question : le fait de n'avoir qu'une seule table dans le modèle, est-ce que ça ne va pas poser problème pour la création de cubes ?


Merci...

[GGGGG]

Excellent le cours sur les DW et DT

J'ai toujours voulu enseigner. Je me verrais bien le faire en DUT par exemple, mais bon, question de temps ...

En DUT STID !

Merci pour ce post

[VinZent]

Volumétrie :
* Utilisateur : 760 enregistrements
* Type_commande : 13 enregistrements
* Commande, Temps_traitement et Temps : chacun possède 587 116 enregistrements

Ta volumétrie est très, très, réduite. Pas de problème de ce coté là.
En détail :

• 13 valeurs distinctes pour le type de commande, sans autre attribut, ne justifie pas de table de dimension externe.
• 760 valeurs distinctes pour les utilisateurs, c'est plus important certes, mais vu qu'il ne te faut pas d'autre attribut descriptif tel que l'age, la localisation, la date d'entrée, le sexe etc ..., là aussi je ne pense pas qu'une table de dimension externe ait une valeur ajoutée intéressante.

D'autre part, qu'aurais-tu mis comme index à part sur la clef primaire ?

La politique minimale - le minimum syndical - est une indexation sur clé primaire et clés étrangères dans le cas de tables de dimensions externes.
Pour les clés primaires, on essaie d'éviter les clés composites (constituées de plusieurs champs) lorsque cela est possible (souci de performance et de gestion), un simple integer auto incrémental est parfait dans bien des cas.
Dans ton cas, je viserai une indexation maximale, hormis les indicateurs of course. Attention cependant à bien choisir le type d'indexation :

• les attributs à valeurs distinctes nombreuses doivent disposer d'un type d'index différent des attributs à valeurs distinctes peu nombreuses (voir documentation sur les types d'indexes pour Oracle).

Dernière question : le fait de n'avoir qu'une seule table dans le modèle, est-ce que ça ne va pas poser problème pour la création de cubes ?

Non. Mais l'intérêt d'un cube, dans ton contexte, n'est pas forcément indispensable.
Avec quoi vas tu créer tes cubes ? Express ?

Merci...[/QUOTE]

[missjustme]

Mille mercis pour ces nouvelles réponses !!!

Grâce à toi, je suis en train d'apprendre plein de choses vraiment très intéressantes et de voir des aspects que je n'avais pas encore forcément abordé...

Mais l'intérêt d'un cube, dans ton contexte, n'est pas forcément indispensable.

Pourquoi un cube ne serait-il pas indispensable dans mon contexte ? Est-ce encore un concept que j'ai complètement compris de travers ?

Pour moi, un cube permet de pré-calculer les indicateurs, et ce de manière agrégée selon les dimensions... Ainsi la navigation dans le cube est possible et rapide...

Par exemple, je peux naviguer dans mon cube et afficher à l'utilisateur le nombre d'erreurs (nb_erreurs) qu'il y a eu à la date D pour le type de commande T. Et ensuite, faire un drille-down pour afficher le nombre d'erreurs qu'il y a eu à la date D mais pour chaque commande de type T. (je sais pas si c'est compréhensible...)

J'ai peut être pas très bien compris le concept...

Avec quoi vas tu créer tes cubes ? Express ?

Je comptais créer mes cubes avec Mondrian, et faire l'analyse avec JPivot... Galère n'est-ce pas...

[VinZent]

Pourquoi un cube ne serait-il pas indispensable dans mon contexte ? Est-ce encore un concept que j'ai complètement compris de travers ?

Mon propos était de dire qu'un cube est généralement employé dans le cadre d'un réel multidimensionnel.
Dans ton cas, le cube est une fioriture à vocation pédagogique. En effet, un cube ROLAP de Mondrian aura pour effet de rajouter deux couches (mondrian et jpivot) avant la livraison de l'information à tes utilisateurs. Tout serait bien plus rapide en query directe sur ta table (2 couches en moins). Il s'agit une nouvelle fois d'une réflexion de type réaliste et pragmatique, mais compte tenu de la vocation pédagogique de l'exercice, je dis ok avec plaisir.

J'ai peut être pas très bien compris le concept...

Si, tu m'as l'air au point.

Je comptais créer mes cubes avec Mondrian, et faire l'analyse avec JPivot... Galère n'est-ce pas...

Pas de galère non !
Mondrian est un ROLAP de belle facture. Je commence à le connaître par coeur. Vas faire un tour sur mon blog et tu verras ce qu'il est possible de faire avec : http://open-bi.blogspot.com

[missjustme]

Merci, merci et encore merci...

Ouf ! je n'ai plus de questions pour le moment, mais je ne t'assure pas que c'est la fin de mes soucis et interrogations... En fait, je crois que ça ne fait que commencer...

[missjustme]

J'ai une autre question qui me passe par la tête...

En réalité, le modèle simplifié que je t'ai montré ne représente qu'une partie du schéma global...

En fait, une commande est découpée en n traitements que l'on voudrait pouvoir analyser aussi (poser des indicateurs sur les traitements)... La question est donc : est-ce que cette unique table de faits "TEMPS_TRAITEMENT" de notre modèle précédent peut constituer une table de dimension pour une autre table de faits qui elle, analyserait les traitements ?

Oh la la, je sais pas si c'est compréhensible...

Merci.

[VinZent]

J'ai une autre question qui me passe par la tête...
En fait, une commande est découpée en n traitements que l'on voudrait pouvoir analyser aussi (poser des indicateurs sur les traitements)... La question est donc : est-ce que cette unique table de faits "TEMPS_TRAITEMENT" de notre modèle précédent peut constituer une table de dimension pour une autre table de faits qui elle, analyserait les traitements ?

Dans l'absolu je dirais, oui, pourquoi pas. Mais cela est aussi un peu "étrange" et nécessite un peu plus d'information pour un avis certifié et assuré.
A priori, je pense qu'il vaudrait mieux s'orienter vers la création d'une table de dimension spécialisée afin de bien séparer les deux entités :
- une table qui intervient en tant que faits dans un premier contexte,
- une table qui intervient en tant que dimension dans l'autre contexte.
Mieux vaut avoir deux objets compréhensibles et pratiques à gérer, plutôt qu'un seul, à double rôle, et qui risque tôt ou tard de proser problème (justement du fait que sa position ne soit pas tranchée).

Ce que j'ai dit est, vu le peu de connaissance que j'ai de ton modèle global, à prendre à avec des pincettes.
Pour un avis plus certifié, il me faudrait avoir ta vision globale cible.
Si tu veux, on peut déjà en parler en PM, quitte à publier après coup nos avancées sur le forum.