Discussion :

[Xtream071]

Bonjour à tous,

Je réalise actuellement un DataWarehouse et voici les notions que je dois y entrer:

• Client (avec plusieurs caractéristiques)
• Séjour (avec plusieurs caractéristiques dont le numéro, la date de début, la date de fin et le type)
• Durée du séjour
• Jours payés
• Acompte
• ...

Mon problème est au niveau du séjour, je ne sais pas si je dois le considérer comme une table de fait ou comme une dimension.

Une dimension se justifierait car j'ai besoin de ses caractéristiques ailleurs dans d'autres cubes mais en même temps, cette dimension serait un rassemblement d'autres dimensions car je me vois mal y intégrer plusieurs dimensions dates et d'autres dimensions à plusieurs attributs.

Ma question est donc : comment dois-je modéliser la notion de séjour pour obtenir une implémentation correcte?
Suis-je dans le cas d'une Factless Fact Table?

Merci d'avance

[Invité]

Bonjour,

Je dirais une Table de fait "FactSejour" et des dimensions "DimSejour", "DimCalendrier", "DimCategorieSejour" par exemple.

-FactSejour :
* DimSejourKey (reference a DimSejour)
* DateDebutSejourKey (reference a DimCalendrier)
* DimDateFinSejourKey (reference a DimCalendrier)
* DimCategorieSejourKey (reference a DimCategorieSejour)
* MeasureDureeSejour

-DimSejour :
*IdDimSejour
*NumSejour
*NomSejour

-DimCategorieSejour :
*IdCategorieSejour
*NomCategorieSejour

Voila. C'est un exemple qui devrait fonctionner, mais il y a plusieurs manières de faire.

[Xtream071]

Merci pour cette piste de réflexion.
Qu'est-ce qu'il y aurait comme autres manières de faire?

Par rapport à cette modélisation, comment réutilise-t-on les différentes dimensions se rapportant au séjour (dans un autre cube par exemple)?

[Invité]

Dans la continuité de mon exemple, tu peux :
- "Faire rentrer" la catégorie du séjour en attribut de la dimension séjour (ce qui entraine la suppression de la référence à catégorie séjour dans la table de fait)
- "Floconner" cette dimension séjour en supprimant la référence de la TF et en mettant cette référence dans la dimSejour
Après, globalement, pour répondre à ta question initiale, je pense qu'il te faut une table de fait "Séjour" où tu regroupe tes mesures liées au séjour; et une dimension Séjour où tu regroupe les attributs descriptifs du séjour.

Ta dimSejour (ou toute autre dim) peut être liée à d'autres tables de fait, indépendamment de sa liaison avec FactSejour. Concernant la réutilisation d'une dimension dans d'autres cubes, ca va dépendre de ton logiciel de création de cubes. Je pourrais te renseigner sur SQL Server Analysis Services, mais je pense qu'il vaudrait mieux poser ta question dans la section appropriée du forum pour le coup.

[Xtream071]

Si je regroupe les attributs décrivant le séjour au niveau de la dimension "DimSejour" et les mesures dans la table de faits "FactSejour", pourquoi ne pas faire ainsi?

-DimSejour :
* IdDimSejour
* NumSejour
* DateDebutSejourKey (référence à DimCalendrier)
* DateFinSejourKey (référence à DimCalendrier)
* CategorieSejourKey (référence à DimCategorieSejour)
* ...

-FactSejour :
* DimSejourKey (référence à DimSejour)
* MeasureDureeSejour
* ...

Avec ce schéma, je pourrais réutiliser la même dimension dans un autre cube avec déjà tous ses attributs sans pour autant dédoubler les informations, il me semble.
Quels sont les inconvénients de ce schéma?

[Invité]

Les date de début et de fin de séjour sont liées au Fait qu'un client ait effectué un séjour. Ce ne sont pas des attributs caractéristiques des séjours proposées par l'entreprise.

La DimSejour doit représenter un "catalogue" de séjours si tu veux; c'est un référentiel. Ainsi, si tu as - admettons - 5 séjours dans ton catalogue, tu auras 5 lignes dans ta DimSejour. Si tu as 30.000 séjours effectués par des clients, tu auras 30.000 lignes dans ta FactSejour qui pointeront chacune vers une des 5 lignes DimSejour.

Ensuite, il n'y a pas de dédoublonnage des informations avec mon modèle. En supposant que ton deuxième cube est basé sur une nouvelle table de fait, tu as juste à la connecter à ces dimensions existantes en ajoutant à cette TF les ForeignKey nécessaires.