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.

[ygrim]

Oui, tu peux créer une telle hiérarchie... Mais l'idée de faire des flocons ne doit venir qu'après avoir constaté (ou être sur) que le modèle en étoile ne convient pas.
Avec ta solution, et surtout si tu déploie en MOLAP, le temps de traitement sera ridicuement long car le moteur d'analyse essayera de faire un modèle en étoile en background, pouquoi ne pas le faire directement

[Jinroh77]

Si le moteur refait une étoile, effectivement, autant faire de l'étoile dès le début.

Donc, en fonction de la volumétrie des différents niveau, tu conseilles putôt de mettre directement dans la table de fait l'IdProduit, l'IdCategorie, IdFamille etc....
Par contre, si un produit à la possibilité de changer de catégorie etc.. cela va poser problème. Si l'on a pas besoin de conserver l'ancienne hiérarchie (ce qui n'est pas évident), il faudra faire un update sur toutes la table de fait. Ce qui est plutôt vivement déconseillé.

Si l'on souhaite conserver la hiérarchie à date, on est de toute manière obligé de passer par une table de référence ou factless Fact tables afin de stocker cet historique.

[ygrim]

Les dimensions à variations lentes sont faites pour ça !! Les SCD en anglais.
SSIS gère très bien cela

[Jinroh77]

je suis en train de regarder cette tâche. Ca à l'air efficace
D'après ce que j'en ai vu, on peut demander soit à faire un update pure, interdire le changement, ou qu'il crée une historisation de la ligne en ajoutant 2 champs de DateDebut et DateFin.
Je vais m'intéresser à cela plus en détail.
Merci pour l'info.

[ygrim]

Peut être que ça te sera utile : http://grim.developpez.com/articles/...ing-dimension/
Amuses toi !

[Jinroh77]

Merci pour ce lien, je vais lire avec attention, avec en plus
celui-ci et ça avec un package d'essai.

Par contre, une petite chose, sachant que je n'ai pas encore tout lu ; L'ajout de la DateDebut et DateFin, se fait directement dans la table de dim. Il y a donc une répétition de toutes les caractéristiques non changeante.
Exemple, une catégorie avec pas mal d'attribut dont seul l'Id de son niveau supérieur est changeant, on va répéter l'ensemble des attributs sur toutes les lignes d'historisation ?

Merci encore.

[psychokwax]

Juste en passant un petit mot sur le composant SSIS "Slowly Changing Dimension"...

Je recommande de l'utiliser sur des dimensions contenant de très petits volumes de données car il est extrêment lent! A moins d'avoir une brute de serveur de production (ce qui n'est pas toujours le cas)

Je recommande également d'implémenter le même traitement que celui généré par le composant mais par vous-même! Pour l'avoir expérimenté à de noubreuses reprises, les performances entre une implémentation custom et le composant sont le jour et la nuit!

Pour l'implémentation, voici ce que moi je fais:

* sur base de la bk, checker que si le record existe déjà.
* si non, faire une insertion
* si oui, récupérer toutes les colonnes de la version courante de l'enregistrement via un composant "lookup"
* utiliser un composant "derived column" pour remplacer les valeurs nulles des colonnes de l'enregistrement courant ainsi que les colonnes récupérées de la source par une autre valeur que null (les null, ca fait planter les comparaisons de l'étape suivante)
* utiliser un composant "conditionnal split" pour comparer une à une, les colonnes de la sources et les colonnes de l'enregistrement courant
* en cas de changement, implémenter le SCD
* si pas de changement, on ne fait rien

C'est certes plus de boulot mais je le répète, les perfs sont 1000 fois meilleures que celle du composant "SCD"...

[Jinroh77]

Merci pour la comparaison de perfs.
Et si on fait cela via une PS ?
On se crée une petite table de sas. on insert tout notre flux dans cette table. Puis via une PS, on fais la mise à jour etc.. de la table d'arrivé.
Ce n'est encore beaucoup plus rapide ?

Je dis cela car chez un précédent client, une grande partie du SSIS était traité via du code SQL ; Alors que le client actuel gère tout via des tâches SSIS.
Et bien que les volumes soit beaucoup plus petit (/100) les traitements sont relativement long (la base chez ce dernier client n'est pas extra bien faite non plus...).