Discussion :

[challenger84]

Bonjour,
Je dois concevoir un schéma en étoile qui doit notamment permettre l'analyse de plusieurs dossiers selon plusieurs axes d'analyses (clients, categorie_offre, etc.).

Mon problème c'est que j'avais pensé mettre dans ma table de fait les informations sur chaque dossier: numéro du dossier, intitulé, etc., avec évidemment les faits: montants demandé et montant payé.

Puis, je me suis dis qu'en fait je pourrai créer un table de dimension DOSSIER dans lequel je mettrai ces informations (numéro, libellé,etc.) et ne garder dans ma table de faits que les montants de types numériques (ce qui est plus conventionnel).

Mais dans ce cas là, il est sûr et certain que j'aurai une relation 1:1 entre ma table de fait et la dimension DOSSIER ce qui pour moi est inutile non? (un dossier est lié à un seul client et à une seule catégorie d'offre).

D'après vous quelle conception devrais-je garder ?
Je pense plus à mettre le numéro de dossier dans la table de fait et à le classer comme dimension dégénéré mais est-ce correct? Et qu'est-ce que je fait de son libellé?

[brunolf]

C'est correct, en tout cas, si on pioche dans les mêmes bouquins de Kimball, ça correspond à sa définition de la dimension dégénérée.

[Jester]

Je dirais qu'il faut garder la conception qui optimise le mieux vitesse et maintenabilité.

Je pense qu'une solution hybride est possible aussi.

Vous mettez le client (ou type client si ça existe) et la catégorie de l'offre dans les faits mais aussi dans la dimension dossier (utilisation d'un trigger pour la mise à jour). Car je doute que l'intitulé soit très utile dans une requête OLAP.

Mais bon, cela dépend des données et des requêtes.

[ygrim]

Salut à tous !
Je serais plus pour la séparation dans une dimension DOSSIER. Il faut garder à l'esprit qu'une table de faits contient des faits, des mesures. Et le libellé d'un dossier n'est pas une mesure... Cela apparait vraiment bien si tu voudra créer un cube à partir de ton modèle en étoile. Si tu mets les infos des dossiers dans la table de faits il te sera TRES difficile (requetes MDX à la pelle) de faire des croisement avec les attributs des dossiers.
En régle générale, les entités de ton business case sont des dimensions et les faits, les éléments à MESURER, donc pas de textuel

[challenger84]

Si tu mets les infos des dossiers dans la table de faits il te sera TRES difficile (requetes MDX à la pelle) de faire des croisement avec les attributs des dossiers.

Si j'adopte par exemple l'état du dossier comme dimension d'analyse est-ce là la notion de croisements avec attibuts de dossiers dont tu parles?

Parce que si les attributs des dossiers sont limités à leur intitulés je ne vois pas trop quels croisements je pourrai faire ...

[ygrim]

C'est vrai que c'est ton business case, c'est toi qui sais la pertinence de le faire ou pas. Mais j'imagine qu'il doit y avoir des attributs comme date de création, date de modification, personne qui a ouvert le dossier, etc..
Je pense qu'il y'a plus de valeur ajoutée à mettre la notion de dossier comme dimension plutot qu'attribut de fait. Si cela n'a aucun interêt, ben tu auras fait une conception claire, sinon ben c'est un bon choix

[challenger84]

Après réflexion j'ai décidé de mettre les dossiers comme dimension d'analyse pour prévoir de futures requêtes nécessitant des croisements avec ces derniers.

De toute manière je ne pense pas que cette solution ait un impact énorme sur les temps de réponse à la restitution.