Discussion :

[Jinroh77]

Bonjour,
Je viens pour une petite question de modélisation d'une base décisionnelle.

Nous parlons d'une vente d'un produit appartement à une catégorie elle même appartement à une famille (définition différente de la catégorie) qui encore une fois appartient à un groupe (déf. toujours différente).

On va donc créer une table pour chaque ensemble (produit, catégorie,...).
Dans la table de fait on ne retrouve que l'IdProduit.
Notre dsv contient bien toutes les liaisons entre les tables. On crée ensuite une dimension produit qui sera constituée, entre autres, d'une hiérarchie "tout niveau produit" dans laquelle on retrace les liens entre tout les niveaux ?
Dans l'onglet "Dimension Usage" on ne fait ensuite le lien qu'entre la table de fait et la table DimProduit, tout le reste se fait au niveau de la dimension créée ?

J'ai bon ?

[psychokwax]

Bonjour,

C'est bien ça.

C'est ta dimension "Produit" qui contiendra toute tes informations (groupe, famille, ...) et surtout "IdProduit" qui te servira à faire le lien entre la table de faits et la dimension.

[Jinroh77]

Bonjour,

C'est bien ça.

C'est ta dimension "Produit" qui contiendra toute tes informations (groupe, famille, ...) et surtout "IdProduit" qui te servira à faire le lien entre la table de faits et la dimension.

Merci, la réponse me fait d'ailleurs penser à autre chose.
Dans la table d'un niveau (produit, groupe,...) on ne conserve que l'Id de l'item de niveau supérieur ?
Pas de DimProduit(IdProduit, code, nom, Id Famille, IdGroupe, IdCategorie,..)

[ygrim]

Salut !
Désolé de jouer les troubles faits
En fait je me pose des questions sur pourquoi créer trois dimensions Produits, catégorie et famille ... Le nombre d'enregistrements est il si grand que ça ???
Je suis de ceux qui pensent qu'il ne faut faire des flocons que quand c'est necessaire !
Autre remarque : si dans ta table de fait tu n'a de référence qu'au produit, comment veux tu que les utilisateurs fassent des analyses par familles directement ??? Tu les obligent (techniquement) à passer par produit, et catégorie, non ?

[psychokwax]

Je ne comprends pas bien la question...

Mais voilà tout de même ma réponse.

Pour moi, chaque table doit contenir les informations caractérisant ce que représente la table (caractéristiques de produits dans la table "produit", caractéristiques de catégories dans la table "categorie", ...).

En plus de ça, tu dois bien sûr avoir la foreign key te permettant de faire les liens entre les tables (id_categorie dans la table "produit", id_famille dans la table "categorie", ...).

Ensuite, dans ta dimension "Produit", tu dois avoir tous les attributs donc tu as besoin pour créer tes hiérarchies nécessaires pour tes analyses (analyse par produit, catégorie de produit, catégorie de produits - produits, ...). Ces attributs peuvent venir des différents tables composant la dimension sans aucun problème.

[ygrim]

En plus de ça, tu dois bien sûr avoir la foreign key te permettant de faire les liens entre les tables (id_categorie dans la table "produit", id_famille dans la table "categorie", ...).

Pas forcément... Sinon tu va te retrouver un modèle en troisième forme normale ... Le but est de rendre le schéma le plus simple possible pour l'utilisateur ! Et pourquoi ne faire de lien qu'entre la table de produit et la table de faits ? Ça serait plus performant de faire un vrai schéma en étoile (je parle de traitement des requêtes)

[psychokwax]

Tout à fait d'accord avec toi. Dans la mesure du possible, il vaut mieux ne créer qu'une seule et unique table pour représenter une dimension.

Ma réponse se rapportait au cas d'un schéma en flocon...

[Jinroh77]

Si la table Produit ne contient que l'id du niveau supérieur (catégorie) et la catégorie ne contenant que l'IdFamille etc... via les relations défini dans la dsv on peut aller simplement du produit au différents niveau.
Il suffit ensuite de créer, dans la dimension Produit, les différentes hiérarchie, directe ou non.

L'idée du débat est vraiment de vérifier l'intérêt à faire un flocon ou pas.