Dimension Many to Many

[ygrim]

Bonjour à tous !
Je viens vous faire travailler les méninges avec une problématique que je vis actuellement (peut être que vous l'avez déjà rencontré, chose qui m'aiderais beaucoup !) :
Toutes les dimensions que nous créons sont de type Many to One avec la table de faits, rien de bien sorcier... Mais qu'en est t il de dimensions qui sont en Many to Many avec la table de faits ? Comment modéliser ce cas ?
Un exemple :
Imaginez une table de faits des ventes dans une librairie et une dimension Produit, qui sont des livres dans notre cas.
Nous voulons maintenant analyser les ventes par Produits et par Auteurs. Donc ajouter une dimension Auteur... Mais un livre possède un ou plusieurs auteurs !!! Ce qui fait que chaque ligne de notre table de faits devra être associée à un ou plusieurs auteurs, ce qui fausse tous les calculs précédemment définis.

J'ai vu que SSAS pouvait gérer ce type de relations, mais je voudrais une solution conceptuelle, indépendante de l'outil utilisé.

À vos claviers !

[mohamed]

Slt.

Pkoi tu ne fais pas de schéma en flocon qui va servir à gérer tes hiérarchies.
t'auras table de fait vente_livre, ta table de dimension produit qui lui est relié et la table auteur qui est liée à ta table produit afin de gérer ta hierarchie d'attribut?

Si tu veux faire de l'analyse des ventes par auteur, ton moteur utilisera alors les aggrégation nécessaire.

[ygrim]

Je vais essayer ça mais je pense que ce n'est que déplacer le problème. En effet, j'aurais une dimension Auteur reliée à ma dimension Produit par une relation Many to Many ... Donc une table de relation Auteur-Produit. En plus du fait que ce soir conceptuellement bancal. Je ne sais pas comment réagiront les analyses à partir de ce modèle. Je vais essayer quand même merci pour cette piste

[yphilogene]

La littérature présente principalement 2 solutions au problème des relations many-to-many:
- Changer la granularité de la table de faits (en y mettant l'auteur)
- Utiliser une "bridge table" (table de correspondance livres-auteurs)

Cela dit, ce sont des design patterns axés modélisation base de données, pas modélisation dimensionnelle.

Personnellement, je n'ai pas encore trouvé de modélisation dimensionnelle générale qui puisse répondre à ce cas de figure. Ce que je fais, c'est que je passe par une 2e table de faits avec la granularité livre/auteur, construit à partir de la table de fait à granularité livre. A cette nouvelle table de faits, je ne relie que la dimension Auteur, et surtout pas Livre, parce qu'aggréger suivant les livres dans cette table de faits n'a plus de sens, car pour un même livre, les montants sont répétés par auteur.

On en arrive à une constellation propre, mais avec des étoiles spécifiques au contexte d'utilisation (la spécificité étant la granularité).

Mais est-ce vraiment possible de réaliser un schéma en étoile qui s'adapte à tous les contextes? Il faudrait qu'un théorème mathématique le démontre pour que j'y crois.

[mohamed]

A mon avis il y'a beaucoup de façons de faire.

Tout ce qui est important c'est de savoir qu'il ne faut pas avoir peur de la redondance notamment dans les tables de dimension.

Ainsi dans la dimension auteur, on peut répéter 1 auteur plusieurs fois de meme que dans la table de dimension produit.

1 autre solution serait de créer une dimension supplémentaire appelé dimension "groupe de produit" et/ou "groupe d'auteurs".

Encore une fois l'essentiel c'est de ne pas trop essayer de normaliser et d'essayer le plus naturellement possible de représenter la réalité en voyant les dimensions comme axes d'analyse.

Puis ensuite là ou vient l'enjeu de la chose c'est lorsque l'on passe au serveur OLAP.C'est là que l'on s'occupe des agrégations.
On pourra par exemple avec le schéma en flocon (cf mon dernier post) définir deux hiérarchies.
1- la hiérarchie auteur-->produit
2- la hiérarchie produit-->auteur

Et à on tombe sur un sujet intéressant qui est la relation d'attribut qui est une notion très intéressante.d'ailleurs avec la version 2008 de SSAS elle a été améliorée pour permettre de le designer graphiquement.

[ygrim]

Salut tout le monde,
Merci pour vos retours !
Je pense que je vais donner un exemple pour clarifier tout ça !
Disons que nous avons une table des ventes par produit :
Produit Qte vendue
livre 1 300
livre 2 200
livre 3 100
----
total 600

Et une table de correspondance Auteur Produit :
Produit Auteur
livre 1 auteur 1
livre 1 auteur 3
livre 2 auteur 2
livre 2 auteur 1
livre 3 auteur 3

Si on fait une analyse des ventes par produit et auteur ça donnera un truc comme ça :
Produit Auteur Qte vendue
livre 1 auteur 1 300
livre 1 auteur 3 300
livre 2 auteur 2 200
livre 2 auteur 1 200
livre 3 auteur 3 100
----
Total 1100
On voit que le résultat n'est pas bon à cause de la relation many to many.
Si je fait une analyse par auteur seulement ça donnera ça :
Auteur Qte vendue
auteur 1 500 (il a participé aux livres 1 et 2)
auteur 2 200
auteur 3 400 (il a participé aux livres 3 et 1)
----
Total 1100
Le total n'est pas bon non plus !
C'est pour cela que la dimension auteur-produit ou la table de faits auteur n'est pas bonne, car les chiffres seront dupliqués par auteur alors que ce n'est pas toujours vrai.
Mohamed, j'ai lu ton post mais je ne visualise pas encore les effets de ta solution, je vais méditer la dessus

Je vous tiens au courant

Ps : le résultat à avoir dans mon exemple est :
Auteur Qte vendue
auteur 1 500
auteur 2 200
auteur 3 400
----
Total 600

[mohamed]

Si on fait une analyse des ventes par produit et auteur ça donnera un truc comme ça :
Produit Auteur Qte vendue
livre 1 auteur 1 300
livre 1 auteur 3 300
livre 2 auteur 2 200
livre 2 auteur 1 200
livre 3 auteur 3 100
----
Total 1100
On voit que le résultat n'est pas bon à cause de la relation many to many.

J'imagine alors qu'il ny' a pas de relation de hiérarchie entre livre et auteur ce qui entrainerait ce recomptage.

Je voudrais savoir avec quel outil tu les difinis (avec SSAS ou avec du SQL basic)?

[ygrim]

J'utilises SSAS, et je sais qu'il y'a une technique pour qu'il gère des dimensions de ce type "many to many", il y'a ce document qui en parle :
http://msdn2.microsoft.com/fr-fr/lib...39(en-us).aspx
Mais je voudrais, le plus possible, être indépendant de la solution technique pour ma conception.

[mohamed]

Code :

J'utilises SSAS, et je sais qu'il y'a une technique pour qu'il gère des dimensions de ce type "many to many"

Le problème est que : comment faisaient alors les anciennes versions de sql server analysis services(V7 et v 2000).

1 astuce était alors de définir un schéma en flocon et de pouvoir faire des hiérarchies dans les 2 sens. auteur-->produits et produit-->auteurs.

Même si dans le schéma sous-jacent (cf ta question ), il fallait faire un schéma avec des données redondants.

En résumé, je pense que pour la modélisation de ta base ( en étant indépendant de la technique ), tu peux définir soit un schéma en flocon avec des hiérarchies ou te lancer dans la création de nouvelles tables de dimensions nommées ("dimension de groupes").

Dans le cas du document dont tu as fait référence, l'astuce est géré du côté SSAS et non du côté de la modélisation (ce qui ne regle pas le probleme des anciennes versions de analysis services).

A+

[yphilogene]

Je connais plusieurs utilisateurs qui seraient surpris de voir 600 au lieu de 1100 pour le total du tableau par auteur. Ce n'est pas complètement faux comme total puisque ca fait la somme des montants de chaque auteur.

[ygrim]

Envoyé par yphilogene

Je connais plusieurs utilisateurs qui seraient surpris de voir 600 au lieu de 1100 pour le total du tableau par auteur. Ce n'est pas complètement faux comme total puisque ca fait la somme des montants de chaque auteur.

surtout que c'est 1100 qui est compléement faux ! On parle de quantités vendues, et il y'en a 600 dans notre cas !
Pour éviter les surprises, les métadonnées sont là ! Pour peu que l'utilisateur en soit informé...
Mohamed,
C'est une bonne idée ton schéma en flocon à double sens. Je vais voir ce que ça donne en pratique.
Ps: Kimball devrait ouvrir un compte chez developpez.com

[Paul_S]

Bonjour,

Il me semble qu'il est préférable de traiter ce genre de problématique en excluant l'OLAP.
Considérons notre situation de départ :

1°) Situation de départ
-----------------------
livre 1 auteur 1 300
livre 1 auteur 3 300
livre 2 auteur 2 200
livre 2 auteur 1 200
livre 3 auteur 3 100

Ce tableau peut 'fonctionnellement' se lire :
Le livre 1, auquel ont participé les auteurs 1 et 3, s'est vendu à 300 exemplaires. L'agrégation est un Max. Il n'y a pas de clé de répartition entre chaque auteur.


Considérons maintenant la situation après une simple permutation d'axes Livre / Auteur:

2°) Situation d'arrivée
----------------------
auteur 1 livre 1 300
auteur 1 livre 2 200
auteur 2 livre 2 200
auteur 3 livre 1 300
auteur 3 livre 3 100

Ce tableau peut 'fonctionnellement' se lire :
L'auteur 1 a co-écrit les livres 1 et 2. Il a vendu 500 ouvrages. L'agrégation dans ce cas est une sommation.

Il y a donc dualité entre deux agrégations sur une même mesure.

Par ailleurs, comment gérer le grand total ?
Dans le premier cas, avec l'agrégation Max, on obtiendrait 300 qui est une abération.
Dans le second cas, avec l'agrégation de sommation, on obtient 1100, qui est dificilement interprétable par un utilisateur, et peut induire en erreur : l'ensemble des auteurs n'a certainement pas vendu 1100 ouvrages au total.

Enfin, pour corser le tout...
Nous sommes ici en présence de deux dimensions. Imaginez l'introduction d'une troisième dimension permettant d'analyser géographiquement les ventes (par région, département, point de vente ...), et on obtient une usine à gaz, que l'utilisateur final ne peut interpréter sans décodeur !

Pour finir, il me semble qu'il est préférable de mettre en oeuvre un premier rapport présentant par exemple les ventes par ouvrage, avec une sommation en bas de page. Un hyperlien vers un second rapport permettrait de détailler par auteur, etc ... L'important de ne pas faire figurer sur un seul et même rapport les deux Axes d'analyse présentant la relation M2M.
N'oublions pas l'accessibilité et l'appropriation des users au final.

[yphilogene]

Envoyé par ygrim

Ps: Kimball devrait ouvrir un compte chez developpez.com

Mouaif, chui pas sûr. Dans Le Data warehouse, il en parle mais le chapitre en question ne répond pas à ta question qui à mon sens n'a pas de solution, en tout cas pas comme tu voudrais. Comme dit Paul_S, il faudrait qu'il y ait une intelligence fonctionnelle qui intervienne dans la génération de la requête et ça je ne vois pas trop comment on peut faire ça. Et d'ailleurs, si ça existait, on n'aurait plus de boulot .

S'il s'agit d'un rapport, il y a plein de solution pour parvenir à présenter le bon total. S'il s'agit d'un modèle de requêtes, je pense qu'il n'y a pas de solution miracle.

[ygrim]

Salut les amis !
J'ai trouvé ma réponse sous forme d'article !!! Avec des codes sources exemples en plus !
Je n'ai pas fini de le lire, mais je ne résiste pas à l'envi de partager ça avec vous !
http://www.sqlbi.eu/Default.aspx?tabid=80

[ygrim]

Solution :
Utiliser ce que Kimball appelle une "Factless fact table" ou une table de faits sans faits.
http://www.dbmsmag.com/9609d05.html
Ce que monsieur Kimball définit comme une "Kimball Rule" est que toute table de relation Many to Many (table de correspondance) est, par définition, une table de faits. À partir de là, on pourrait dire que la table (Auteur_Produit) serait une factless fact table et mon schéma en étoile deviendrait une "constellation".
Maintenant pour les analyses par Produit, par Auteur. Cela reviendrait à faire un Drill Through entre les deux étoiles pour avoir l'information désirée. Biensur ! étant dit comme ça sa parait simple mais je ne vois pas autre technologie que SSAS qui permet de faire cela en natif.

Reste que cette conception dimensionnelle se tient et répond aux exigences de Kimball

[yphilogene]

Factless table ou bridge table, l'idée est la même, ce n'est que le nom qui change.

Je ne vois pas en quoi ça résout ton problème de total.

[ygrim]

Envoyé par yphilogene

Factless table ou bridge table, l'idée est la même, ce n'est que le nom qui change.

Je ne vois pas en quoi ça résout ton problème de total.

Oui ce sont des synonymes. Je n'avais bien compris cette notion et pensait que c'était une gestion interne et totalement propriétaire de microsoft, alors que c'est un design pattern modélisé par SSAS 2k5. Utiliser la bridge table pour faire les calculs quand on utilise la dimension auteur (dans mon cas) donc pouvoir filtrer la table (contenu) par auteur mais utiliser les sommes par produits (totaux).
Comme je le dis, plus facile à dire qu'a faire, mais c'est un design pattern.

[Marie-Josee]

Je n'ai pas pris le temps de lire toute la discussion, car c'est très long.
Mais rapidement une méthode que nous employons dans notre lab pour calculer les agrégations des dimensions ayant une relation N-N avec la table de fait est d'insérer autant d'occurences de faits qu'il existe de possibilités en indiquant par contre dans un champs de mesure la fraction correspondant à ces faits afin d'y appliquer l'opérateur d'agrégation de SUM par exemple.

Ainsi le livre qui possède deux auteurs serait inséré deux fois dans la table de faits (une fois par auteur) avec une fraction de 0,5 ainsi la mesure resterait agrégative pour le nombre de livre.

[ygrim]

C'est une jolie solution !!
Ce qui me dérange un peu c'est le fait de revoir tous les calculs que l'on pourrait faire "nativement" pour leur ajouter la pondération que vous préconisez...
De plus, les traitements en background sont assez lourds si l'on veut permettre aux utilisateurs finaux de manipuler leurs données (olap).
Mais je me souviendrais de cette astuce ! Merci beaucoup !

[clementratel]

Bonjour,

Personnellement je modéliserais comme suit :
1 table de faits "un livre est vendu" avec 'livre', 'date de vente', 'prix',...
1 table de faits "un auteur écrit pour un livre" avec 'auteur', 'livre', 'date remise du manuscrit',...
1 table de dimension livre liées aux deux tables de faits
1 table de dimension auteur liée à la seconde uniquement

C'est donc la solution de la table de correspondance "livre-auteur".

L'avantage est de ne pas avoir de fait redondant, ce qui selon moi est dangereux car s'éloigne de la réalité et sera plus dur à maintenir.