Discussion :

[SBenMansour]

Bonjour,
j'ai cette situation devant moi et je voudrais bien demander vos avis concernant la modélisation :

- Un événement peut avoir plusieurs sociétés invitées ( Accounts )
- une Société ( Account ) peut bien sur assister à plusieurs événements
- Un événement a une date debut et une date fin ainsi qu'un coût total

Comme vous pouvez le constater Il y'a une relation Many to Many entre (Dim_Event) et (Dim_Accounts)
Ma question est comment modéliser cette situation dans un DW.

Ce que j'ai fait:
Insertion d'une "Table Bridge" appelée EVENT_GUEST_BRIDGE dans laquelle j'ai mis une clé pour Dim_Event et une autre clé pour Dim_Accounts.
C'est comme une table * - * générée au niveau de la BD quand on définit une relation Many to Many entre deux entités.

La table Fact_EVENT est liée à la Dim_Event et est doublement liée à la dimension temps puisque un event a une date debut et une date fin.





Pour Avoir par Exemple les pays d'où viennent les sociétés qui participent à un Event je dois Ecrire :


SELECT [FK_EVENT]
,[FK_DEBUT_EVENT]
,[FK_FIN_EVENT]
,[TotalPriceByEvent]
,C.Country
FROM [DW_CRM].[dbo].[Fact_MARKETING_EVENT] A
inner join [DW_CRM].[dbo].[EVENT_GUEST_ACCOUNT_BRIDGE] B on (A.FK_EVENT = B.FK_Event_ID)
inner join [DW_CRM].[dbo].[Dim_Accounts] C on (B.FK_Account_ID = C.Accounts_TechKey)




- Est ce que j'aurais pu par exemple opter pour une conception purement en étoile ?
quelque chose comme ça :



Je voudrais bien savoir les + et les - de chaque conception!

Merci

[nuke_y]

Je pense que vous avez 2 faits:

- le fait financier qui donne un montant pour chaque événement, et dont la clé unique fonctionnelle est l'événement et la clé unique technique est non visible sur votre modélisation

- le fait "participation à l'événement" dont la clé unique fonctionnelle est composée de:

• l'événement
• l'entreprise invitée

Donc 2 faits, modélisation forcément plus compliquée. Si votre solution de reporting est Qlikview ou Qlik Sense, c'est ultra simple, si elle basée sur une modèle relationnel ça va être plus compliqué.

La solution quick & dirty consiste à empiler les 2 faits dans 1 seule table de faits (matrice creuse).

[SBenMansour]

Je pense que vous avez 2 faits:

- le fait financier qui donne un montant pour chaque événement, et dont la clé unique fonctionnelle est l'événement et la clé unique technique est non visible sur votre modélisation

- le fait "participation à l'événement" dont la clé unique fonctionnelle est composée de:

• l'événement
• l'entreprise invitée

Donc 2 faits, modélisation forcément plus compliquée. Si votre solution de reporting est Qlikview ou Qlik Sense, c'est ultra simple, si elle basée sur une modèle relationnel ça va être plus compliqué.

La solution quick & dirty consiste à empiler les 2 faits dans 1 seule table de faits (matrice creuse).

Merci pour Votre réponse !
Mais maintenant Si je dois opter pour une seule table de fait ?

Concernant la première modélisation : est ce que je peux toujours dire que je fais de la BI et que je suis entrain de concevoir un DW parce que
c'est plus un modèle en étoile ... ( je sais que c'est un modèle en flocon mais qui n'est pas classique à cause de la table bridge * - * ) ?
Pour avoir une information je dois désormais joindre plusieurs tables et c'est ca le problème.

Mais d'un autre coté si j'opte pour la deuxième conception :

Il y'aura certainement des duplications de données : genre si à un seul événement il y'a 1000 sociétés participantes je vais trouver mille lignes dans la table fait avec les memes informations sauf la Foreign key de la société :

FK_EVT : 1 , FK_Societe : 1 , Cost : 1000
FK_EVT : 1 , FK_Societe : 2 , Cost : 1000
FK_EVT : 1 , FK_Societe : 3 , Cost : 1000
FK_EVT : 1 , FK_Societe : n , Cost : 1000 ...

chose qui va affecter l'analyse :

Exemple :

Si je veux avoir le coût total de tous les événements aux quels la société 1 a participé !

Vous voyez un peu la situation ?!

PS : Je manipule manuellement les données pour enfin faire le reporting avec d3.js ou dc.js etc ...

Merci

[nuke_y]

Vous avez besoin d'un modèle associatif, ce qui vous embête là c'est le modèle relationnel. Si vous êtes obligé d'utiliser un modèle relationnel, vous pouvez conserver votre première modélisation. Elle devrait vous permettre d'arriver à vos fins et elle ne pose pas plus de problème de théorie que ça.