IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Conception/Modélisation Discussion :

Dimension ou table de faits?


Sujet :

Conception/Modélisation

  1. #1
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2010
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : février 2010
    Messages : 18
    Points : 10
    Points
    10
    Par défaut Dimension ou table de faits?
    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

  2. #2
    Membre averti
    Homme Profil pro
    Chef de projet décisionnel
    Inscrit en
    mai 2012
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Réunion

    Informations professionnelles :
    Activité : Chef de projet décisionnel
    Secteur : Distribution

    Informations forums :
    Inscription : mai 2012
    Messages : 224
    Points : 369
    Points
    369
    Par défaut
    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.

  3. #3
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2010
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : février 2010
    Messages : 18
    Points : 10
    Points
    10
    Par défaut
    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)?

  4. #4
    Membre averti
    Homme Profil pro
    Chef de projet décisionnel
    Inscrit en
    mai 2012
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Réunion

    Informations professionnelles :
    Activité : Chef de projet décisionnel
    Secteur : Distribution

    Informations forums :
    Inscription : mai 2012
    Messages : 224
    Points : 369
    Points
    369
    Par défaut
    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.

  5. #5
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2010
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : février 2010
    Messages : 18
    Points : 10
    Points
    10
    Par défaut
    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?

  6. #6
    Membre averti
    Homme Profil pro
    Chef de projet décisionnel
    Inscrit en
    mai 2012
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Réunion

    Informations professionnelles :
    Activité : Chef de projet décisionnel
    Secteur : Distribution

    Informations forums :
    Inscription : mai 2012
    Messages : 224
    Points : 369
    Points
    369
    Par défaut
    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.

  7. #7
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2010
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : février 2010
    Messages : 18
    Points : 10
    Points
    10
    Par défaut
    Ok, je comprends maintenant beaucoup mieux le raisonnement.

    Le problème est que dans mon cas, il n'y a pas de catalogue de séjours. Ils sont tous uniques. Si on a 30.000 séjours effectués par les clients, on aura 30.000 séjours dans la dimension DimSejour.
    Mon séjour est un événement pur caractérisé par la date de début, la date de fin, le client, le type du séjour (défini en début de séjour), etc.

    Mais on a parfois besoin de ces caractéristiques dans d'autres cubes qui n'ont pas le séjour comme sujet principal, ni comme granularité.
    En sachant ça, comment puis-je faire pour garder l'information unique au niveau du séjour (donc sans devoir la répéter dans les autres tables de faits) tout en la plaçant dans d'autres cubes?

  8. #8
    Membre averti
    Homme Profil pro
    Chef de projet décisionnel
    Inscrit en
    mai 2012
    Messages
    224
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Réunion

    Informations professionnelles :
    Activité : Chef de projet décisionnel
    Secteur : Distribution

    Informations forums :
    Inscription : mai 2012
    Messages : 224
    Points : 369
    Points
    369
    Par défaut
    Ah, je n'avais pas compris que chaque séjour était unique. Ça change pas mal de choses.

    Et dans ton deuxième cube, as-tu besoin des durée de séjour, des dates début/fin dans la dimension Séjour ?

  9. #9
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2010
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : février 2010
    Messages : 18
    Points : 10
    Points
    10
    Par défaut
    Citation Envoyé par thibault974 Voir le message
    Et dans ton deuxième cube, as-tu besoin des durée de séjour, des dates début/fin dans la dimension Séjour ?
    Dans les autres cubes, je serai certainement amené à avoir besoin de tout ça, oui.

  10. #10
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2010
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : février 2010
    Messages : 18
    Points : 10
    Points
    10
    Par défaut
    Est-ce que le principe à appliquer à ce genre de cas ne serait pas de créer une table de faits FactSejour :

    -FactSejour :
    * NumSejour
    * ClientKey (référence à DimClient)
    * DateDebutSejourKey (référence à DimCalendrier)
    * DateFinSejourKey (référence à DimCalendrier)
    * CategorieSejourKey (référence à DimCategorieSejour)
    * MeasureDureeSejour
    * ...

    Et ensuite, de lier cette table de faits avec d'autres tables de faits dans les autres cubes où j'ai besoin d'informations sur le séjour?

    Si oui, comment lier correctement les tables de faits (qui n'ont pas forcément la même granularité) entre elles dans un même cube?

  11. #11
    Candidat au Club
    Homme Profil pro
    Stagiaire projet informatique
    Inscrit en
    juillet 2016
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Stagiaire projet informatique
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2016
    Messages : 10
    Points : 4
    Points
    4
    Par défaut
    Bonjour à tous,

    Je me permet de rebondir sur ce sujet, un peu ancien il est vrai, mais qui est vraiment similaire à ma problématique du moment.

    Xtream071 (Désolé mais je n'ai pas trouvé ton prénom ^^), pourrais-tu m'indiquer quelle solution tu as finalement utilisé, et si ça a fonctionné comme tu le souhaitais ?

    J'ai également une problématique à ajouter :

    Tout comme pour Xtrem071, mes séjours sont tous unique, mais en plus certains champs du séjour peuvent être modifié (plusieurs fois) en cours de séjour. Est-ce trop compliqué ou mon expérience limité ne permet pas de trouver la solution ?

    Merci d'avance pour votre aide,

    Julien

Discussions similaires

  1. cardinalite entre table de fait et dimension ?
    Par mederik dans le forum Conception/Modélisation
    Réponses: 5
    Dernier message: 29/08/2017, 11h11
  2. Requête dimensions et table de fait
    Par mrman dans le forum Oracle
    Réponses: 3
    Dernier message: 24/07/2012, 14h24
  3. Alimentation de la table de faits & dimension temps?
    Par footmaster dans le forum Alimentation
    Réponses: 4
    Dernier message: 16/02/2011, 00h53
  4. Relation entre table de fait et dimension
    Par rrbenez dans le forum Conception/Modélisation
    Réponses: 9
    Dernier message: 22/03/2009, 12h59
  5. Réponses: 2
    Dernier message: 03/02/2008, 23h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo