Discussion :

[HBA_BO]

I) Questions : Modélisation Datamart et développement de l'Univers BO :

- Exploitation des séries temporelles :
Je souhaite dénormaliser des attributs de type montant dans une même table de fait, de la façon suivante : "Mt1_periode1" , "Mt2_periode2", ....,"MtN_periodeN"
Plutôt que d'avoir dans cette table la clé "Période" et l'attribut "Montant" , pour des raisons de volumétrie (limiter le nb d'occurrences)

Le besoin métier exprimé par la MOA, est d'avoir une représentation du temps en tant qu'axe d'analyse (c'est à dire en clé ) à croiser avec le montant associé, la représentation est la suivante :

Axe1er Période (14 valeurs : >3jours, ...., >10A)
Montant_de_la_periode1

Axe2iéme Période (4 valeurs : 1 er trim, 2 eme , ..)
Montant_de_la_periode2

Axe3ème Période (3 valeurs)
Montant_de_la_periode3

Peut-on avoir une table dénormalisée (comme je le souhaite) et répondre favorablement à la MOA avec une représentation des objets métiers conformes à leurs besoins?

(2) Exploitation des tables hiérarchiques :
J'ai une table de référence qui est à la fois hiérarchique et pyramidale :
- Hiérarchique : l'organisation est structurée en niveau, le niveau 1 étant le sommet de la hiérarchie.
- Pyramidale : la même table comprend plusieurs organisations avec un nombre fini de niveaux qui est différent selon le type d'organisation.

Le besoin métier est de restituer un montant qui doit être agrégé à tous les niveaux et pour tous les niveaux d'organisation.

Pour répondre à ce besoin, je pensais créer une table pour chaque type d'Organisation, et de normaliser les clés qui expriment la granularité (modèle en étoile plutôt qu'en flocon, revient à mettre à plat les niveaux).

Qu'en pensez-vous?

[TheLeadingEdge]

Bonjour,

A titre perso. je te déconseille la solution multivaluée. Pour moi 1 table de faits doit être profonde, et pas large. (beaucoup de lignes, peu d'attributs).
Tes axes d'analyse ne sont ils pas des entrées dans une table des dimensions ?

Ceci dit, poser des questions concernant la modélisation dimensionnelle ds 1 forum modélisation relationnelle ne me semble pas l'endroit le plus approprié pour obtenir des réponses. Je pense que ton sujet aurait plus d'echo ds le forum générateur d'état ou tu toucherais des lecteurs ayant les mêmes intérêts que toi, ou ds le forum conception tt court. Qu'en penses-tu ?

A +

[fsmrel]

Bonsoir HBA_ORL,

Le souhait de la MOA est on ne peut plus légitime, car il exprime seulement le quoi et pas le comment.
L’approche Entité-Relation, tout comme le Modèle Relationnel évoqué par TheLeadingEdge sont certainement aptes à répondre aux voeux de la MOA, sinon cela fait 30 ans et plus que ça se saurait. Le hic est que ce sont des sanctuaires de la normalisation, ce qui a été abondamment justifié et commenté depuis leur naissance par des gens éminemment qualifiés.
Votre solution de tables dénormalisées n’est pas du ressort de Merise ou du Relationnel, nous sommes désolés, mais vous n’avez pas frappé à la bonne porte. Commencez par mettre en œuvre des entités-types normalisées, puis élaborez des agrégats rafraîchis selon la fréquence qui vous convient, le tout convenant in fine à la MOA et revenez nous voir.
Par exemple, revoyez la modélisation à la lumière du principe d’atomicité : il est évident que, pour prendre un exemple simple, je ne m'amuserais pas à associer une ligne (ou occurrence) de table pour chaque ticket de bus ou de métro vendu dans l’année par telle entreprise de transports parisienne ou autre : je mettrais en oeuvre une entité-type correspondant au nombre de tickets ayant tous la même caractéristique, de telle sorte que je sache représenter conceptuellement chaque ticket tout en divisant la volumétrie par un facteur substantiel. Mais ceci relève d’une conception générale ou détaillée préalables respectant les canons E/R et Relationnel.
Pour mémoire, les termes "hiérarchie", "pyramide", modèle "en étoile", "en flocon" sont étrangers au pays que vous venez visiter, même si nous les captons...

Sorry ans good luck for another casting in another modelling land.

[TheLeadingEdge]

Bonjour,

Qques remarques rapides pour détailler 1 peu ma 1ere réponse.

Je souhaite dénormaliser des attributs de type montant dans une même table
de fait, de la façon suivante : "Mt1_periode1" , "Mt2_periode2",
....,"MtN_periodeN"
Plutôt que d'avoir dans cette table la clé "Période" et l'attribut
"Montant" , pour des raisons de volumétrie (limiter le nb d'occurrences)

Ce que tu veux faire il me semble que ça revient à remplacer ds ta table des faits 1 clef ''période'' par 1 champ ''montant'' ?
Je ne suis pas sur que tu y gagne en volume.
De plus si tu gardes 1 dimension temps pour faire tes cumuls tu seras tt de même obligé de garder 1 clef ''periode''
Sous quelle forme sont les clefs ''périodes''? si c'est 1 date, selon son format elle peut correspondre à plusieurs dimensions de ta table 'temps'' ?
Sans dimension temps, comment fais-tu tes cumuls par période? c'est en dur? Ds ce cas il ne vaut mieux pas que tes utilisateurs changent les spec!

je pensais créer une table pour chaque type
d'Organisation, et de normaliser les clés qui expriment la granularité
(modèle en étoile plutôt qu'en flocon, revient à mettre à plat les
niveaux).

Tu pourrais aussi envisager 1 table d'assoce reliant tes tables de faits et de dimensions dans laquelle tu aurais la clef ''montant'' et les clef ''hierarchie'' avec le niveau.

A +

[ego]

As-tu trouvé une réponse à ton problème ? Que je ne comprend d'ailleurs pas du tout
Peux-tu être plus clair sur l'existant, ton modèle / sa volumétrie, et sur le besoin exact ?
Par exemple, tu parles de clé "Période", c'est quoi une Période ? Une date ou un intervalle de dates ?
Tu parles de création de schéma / tables mais dans quelle mesure cela est réellement nécessaire puisque nous ne connaissons pas bien ton besoin ?
Je suis peut être un peu naïf mais mon premier réflexe est de rechercher quelle(s) requête(s) je peux faire pour répondre à des calculs avant même de me dire que mon schéma de base n'est pas adpaté.

Si tu veux continuer à débattre du sujet ? Et s'il n'est pas trop tard...