Discussion :

[Jinroh77]

Bonjour,
Je suis en train de gérer des clients contenant plusieurs niveau hiérarchiques. Un client est fils d'un autre dans un intervalle de temps.
Pour connaitre les liaison d'un niveau à l'autre, il y a une table de référence contenant l'Id du client, l'id du fils, une date de début et une de fin.
J'ai donc une dimension contenant tout ce beau monde, des hiérarchies etc.. et les champs Date début et date fin.

Ce que je cherche c'est pouvoir limiter mes recherches sur "le périmètre hiérarchique à tel date".

EDIT : A savoir que les dates de la table client sont à la journée et que je souhaite définir mon périmètre à l'année.
Dans ma dimension de temps, j'ai besoin d'une valeur par année + une valeur en cours.
Les valeurs annuelles correspondent au périmètre défini le 20 janvier de l'année ; La valeur en cours correspond à la hiérarchie actuelle.

Je dois donc construire une nouvelle dimension "Date perimetre".

Comment la définir ?


Merci pour votre aide.

[psychokwax]

Les SCDs ne se gèrent pas dans SSAS mais dans ton ETL (au chargement de ton data warehouse donc).

C'est à ce moment là que tu vas historiser les différents changements survenus sur les membres de tes dimensions et que tu vas correctement lier tes faits à la dernière version de ton membre.

Ensuite, lorsque tu vas browser ton cube, en fonction de la date à laquelle tu regarde tes données (parce qu'avec les SCDs, il intervient forcément une notion temporelle), ton cube te renverras la bonne version de ton membre.

C'est donc totalement transparent du coté SSAS.

Le nerf de la guerre est donc l'ETL.

[Jinroh77]

SSAS va automatiquement faire la liaison entre ma table de fait (dans laquelle j'aurais ma clef identity créée au moment du SCD) et le client correcte dans ma dimension ?

Mon problème, en plus de cela, est que j'ai besoin de connaitre par exemple les chiffres de 2008 selon le périmètre de 2006 ou l'inverse.

Si la gestion se fait de manière transparente, comment restreindre à la remonté particulière dont j'ai besoin ?

[psychokwax]

Bon, je sais plus trop pourquoi je te parlais de SCDs...

Ton problème est plus un problème de design qu'un problème technique. Il est difficile de repondre à ceux-ci sans connaitre le contexte et les besoins exacts (dans leur moindre détails).

[Jinroh77]

On parlait des SCD, car l'intégration des changements de hiérarchies pour les clients est gérée par une tâches SCD en SSIS.

Concernant le contexte, il s'agit d'un organisme de formation.
Pour les faits, on parle d'inscriptions, prestations, proposition etc..
Pour chacun, il y a des stagiaires qui s'inscrivent. A partir d'eux, on remonte à l'entité cliente à laquelle ils appartiennent.
Certaines de ces entités sont appelées "grands compte". Pour ces grands comptes, il y a plusieurs niveaux hiérarchiques : holding, filiale..

On retrouve alors une "Dim Grands Comptes" contenant :
-IdGrandComptes : qui n'est jamais utilisé
- IdEntiteClienteFille
- IdEntiteClienteMere
- DateDebutValidite
- DateFinValidite.

Le problème est que dans les tables de fait, on ne retrouve pas l'IdEntiteCliente, ni même l'IdGrandsComptes mais uniquement l'IdStagiaire.
C'est alors dans le dimension usage que l'on défini les liaisons référencée.

Ce que j'ai besoin, c'est alors de connaitre les CA générées par ces GrandsCompte. Cela sous SSRS en interrogeant directement le Cube en MDX, pas de SQL

En cours d'année, il arrive qu'une Entité Cliente passe d'une mère à une autre. On génère alors une nouvelle ligne dans la "Dim Grands Comptes".
Il me faut alors interroger les chiffres d'1 Grands Compte selon son périmètre (liste des entité clientes dessous) défini à telle date.

J'espère avoir donné assez d'information pour avoir un peu d'aide.
Merci beaucoup pour vos idées.

[Jinroh77]

Dans le cas de l'utilisation en SSAS d'une dimension de SCD type 2.
La clef de la dimension reste la clef "Worker Id" de cet exemple ou bien est-ce la surrogate key ?

[psychokwax]

La surrogate key...

Je vais essayer de prendre un peu de temps pour réfléchir à ton problème ce soir ou weekend...

[Jinroh77]

Merci pour la surrogate.
J'ai un autre problème que j'essaye de résoudre.


Merci beaucoup pour ton temps passé dessus.

[psychokwax]

Bon alors, j'aurais besoin d'encore un peu d'infos. Voilà ce que j'ai comprit:

1) tu as une dimension "Dim grand compte" qui est une dimension contenant une hiérarchie parent-enfant. C'est également une dimension historisée (SCD type 2).

2) tu as une dimension "Dim stagiaire" représentant les stagiaires d'un client fille (ou d'un grand compte?). C'est cette dimension qui est reliée à ta table et faits et donc, c'est également elle qui sert de dimension intermédiare pour relier ta dimension "grand compte" à ta table de faits via un dimension usage type "referenced".

Si mes déduction du point 2) sont correctes, cela signifie que lorsque tu crées une nouvelle version d'un record de ta dimension "dim grand compte", tu dois faire de même pour tous les stagiaires faisant référence à cette nouvelle version (puisque tu as une nouvelle version, tu as une sk dans ta "dim grand compte" et donc, un changement de fk de stagiaire vers "dim grand compte"). Je ne me trompe pas?

Si tout ceci est correct, cela signifie également que tu as une sk dans ta dimension "stagiaire" et c'est cette sk qui est utilisée pour lier les faits à ta dimension stagiaire.

Cela signifie qu'un fait à une date donnée est relié à une version d'un stagiaire et donc, une version d'un grand compte.

A quelle fréquence ta table de fait est-elle mise à jour?
La granularité de ta dimension de temps est la journée?

[Jinroh77]

Tout d'abord merci pour tes recherches.

En fait, par rapport au SCD, ce n'est pas exactement ça.
Il y a des tables DimEntiteClient, DImGrandComptes, DimStagiaire et la table de fait.

Le composant SCD est utilisé pour remplir les tables de Dim MAIS la SK n'est jamais utilisée Dans la table de fait, on stocke uniquement l'IdStagiaire et dans la table DimStagiaire, on trouve un IdClient.
Avec celui-ci on remonte aux tables DimClient ou DimGrandComptes.
A partir de ces tables, il y a des dim SSAS :
Stagiaire(IdStagiaire, IdClient,...)
GrandsCompte(IdGrandsComptes(Sk), IdClientFille(BK), IdClientMere(parent), IdDateDebut, IdDateFin,...)


Le SCD n'est pas vraiment utilisé actuellement en fait. Il l'est en SSIS mais pas en SSAS.

Par rapport au SCD, je me demande si c'est vraiment ce dont ils ont besoin dans la dimension.
Car d'après ce que j'ai compris, pour le SCD, on alimente la table de DIM avec la Business Key, date début, date fin, à ce moment la SK de type identity est générée.
On fait ensuite la liaison avec la table de fait pour y ajouter, non pas la Business key mais la SK que l'on met dans la table de faits. J'ai bon là ??

Ensuite, si l'on défini notre dim SSAS correcteemnt, elle va faire le lien entre la table de fait, prendre la SK et retrouvé la BK dans la dim. Comment fait-elle le lien sur la date ?????


Donc visiblement les liaison dans l'utilisation d'une dim SSAS de type SCD, sont générée automatiquement. On obtient les valides à la date du fait.

Ce dont j'ai besoin ici, est de filtrer d'un côté la date de fait et de l'autre la date de validité.

De plus, je gère également une hiérarchie dans la même dim que celle utilisée en SCD (DimGrandsComptes). Si je défini dans cette dimensions SSAS, la clef de dimension sur la SK et un membre de type parent de hiérarchie sur l'IdClientMere, il va essayer de me créer une hiérarchie entre le parent (IdClientMere) et la SK. Alors que normalement il devrait trouver l'enfant sur l'IdClientFille.

Je ne sais aps si tout est très clair.. En cas de question n'hésite pas, ça sera vraiment avec très grand plaisir Je suis en train de m'arracher les cheveux dessus.

[psychokwax]

Salut,

En ce qui concerne le principe des SCDs, tu as bon. Les champs "StartDate" et "EndDate" que tu peux trouver dans une SCDs ne servent pas à proprement parler dans le cube SSAS. Ils servent simplement dans l'ETL à connaitre la période de validité d'un record et à dertermier quelle est la dernière version d'un objet métier (identifé par sa BK). C'est celui qui n'a pas de date de fin...

Pour revenir à ton problème, je me pose la question suivante:

Est-ce que la notion de "grand compte" et la notion de "entite client", ce n'est pas un peu la même chose? Finalement, un "grand compte" est un regroupement de clients (si j'ai bien comprit) et pourrait donc, à mon sens, être incorporé à la dimension "entite client". Tu pourrais avoir alors une table "entite client" avec un structure dans ce genre là:

SK
ClientBK
Nom
...
FK_EntiteParent --> qui pointe bien sur la SK!

La notion de "grand compte" est donc incorporée aux "entité client" : un grand compte est un record qui n'a pas de parent.

Maintenant, pour gérer le fait qu'une "entite cliente" change de grand compte, tu peux utiliser véritablement le principe des SCDs (générer un record "entite client" qui aura une nouvelle sk et conservera sa BK).

Pareil pour les stagiaires. Plutôt que de pointer sur un "IdClient", ils pointeront sur la sk. Ce qui signifie que si tu génères une nouvelle version d'une "entite cliente", il faut que tu génères une nouvelle version des stagiaires appartenant à cette "entite cliente".

Comme un record de ta table de faits (avec une granularité de temps à la journée?) est lié à une version spécifique d'un stagiaire et donc une version spécifique d'une entité cliente, tu peux avoir ton périmètre à une date donnée.

Ouf, pas simple à mettre en ordre tout ça...
Est-ce que je me trompe encore?

[Jinroh77]

Salut,

En ce qui concerne le principe des SCDs, tu as bon. Les champs "StartDate" et "EndDate" que tu peux trouver dans une SCDs ne servent pas à proprement parler dans le cube SSAS. Ils servent simplement dans l'ETL à connaitre la période de validité d'un record et à dertermier quelle est la dernière version d'un objet métier (identifé par sa BK). C'est celui qui n'a pas de date de fin...

Je réponds juste rapidement à cette première partie pendant que je relie le reste quelques fois...
Si tout est défini correctement, dans le cadre d'une relation simple Fait(SK,...) --> Dim(Sk, BK, DateDebut, DateFin, Status,..), comment le moteur SSAS va réussir à faire le lien correcte de la table de dim en fonction de la date de la table de fait.
Il est bien censé faire le lien de la date de fait vers la ligne correspondante à cette date dans la dim ??

[Jinroh77]

Pour revenir à ton problème, je me pose la question suivante:
Est-ce que la notion de "grand compte" et la notion de "entite client", ce n'est pas un peu la même chose? Finalement, un "grand compte" est un regroupement de clients (si j'ai bien comprit) et pourrait donc, à mon sens, être incorporé à la dimension "entite client". Tu pourrais avoir alors une table "entite client" avec un structure dans ce genre là:

SK
ClientBK
Nom
...
FK_EntiteParent --> qui pointe bien sur la SK!

La notion de "grand compte" est donc incorporée aux "entité client" : un grand compte est un record qui n'a pas de parent.

C'est presque cela car tout les clients ne font pas partie d'un grand compte. Certains sont de simple clients, d'autres, beaucoup moins, sont de simples client. Ils ont défini cette notion à part depuis un petit moment et ne sont vraiment pas chaud pour les bouger.

Maintenant, pour gérer le fait qu'une "entite cliente" change de grand compte, tu peux utiliser véritablement le principe des SCDs (générer un record "entite client" qui aura une nouvelle sk et conservera sa BK).

Pareil pour les stagiaires. Plutôt que de pointer sur un "IdClient", ils pointeront sur la sk. Ce qui signifie que si tu génères une nouvelle version d'une "entite cliente", il faut que tu génères une nouvelle version des stagiaires appartenant à cette "entite cliente".

Comme un record de ta table de faits (avec une granularité de temps à la journée?) est lié à une version spécifique d'un stagiaire et donc une version spécifique d'une entité cliente, tu peux avoir ton périmètre à une date donnée.

Ouf, pas simple à mettre en ordre tout ça...
Est-ce que je me trompe encore?

Concernant cela, ils utilisent les tâches SSIS SCD un peu partout mais sans véritable les utiliser correctement. C'est à dire que la SK n'est jamais utilisée null part.

Plutôt que de tout leur bouger d'un coup, je préferais simplement pour le moment faire remonter la SK de la dim "Grands Comptes" (que je ne peux pas intégrer aux clients) dans ma table de fait, en plus de l'IdStagiaire déjà présent.
Cela me permettait de faire mon lien.

Maintenant concernant le SCD, si SSAS l'utilise en faisant automatiquement la liaison sur le temps ça ne m'intéresse pas.
J'ai besoin de pouvoir définir d'un côté une période de date pour mes faits et de l'autre, une date différente pour "regarder la hiérarchie fonctionnelle à cette date" (différente de celle des données).
Je me demande alors si une simple relation ne suffirait pas :
Fait : IdDate, IdStagiaire, IdClient
DimClient : IdClient
DimGrandsComptes : Id(Sk inutile), IdClientFille, IdClientMere, IdDateDebutValidite, IdDateFinValidite

Avec une liaison directe entre le fait et DimClient, ou en faisant redescendre l'IdClient, le vrai pas la SK (ni de client ni de Grands Comtpes).

Ensuite je défini d'un côté un filtre sur les dates du fait et un autre filtre sur la date de fin de validité des lignes de la DimGrandsComptes.
Cela peut se faire en MDX ? Sans qu'il mélange les 2 dates ?



Bon ça fait des posts à rallonge mais ce n'est pas forcément évidement à expliquer, et je suppose, encore moins à comprendre. En tout cas merci beaucoup pour ton attention.

[psychokwax]

Salut,

J'étais occupé à relire un document à propos des relations "many-to-many" et en parcourant un cas exposé, j'ai pensé à ton problème.

Le document est en libre téléchargement sur le net. C'est un document de Marco Russo qui se nomme "M2M Revolution".

Dans ce document, il y a un cas qui s'appelle "Multiple Hierarchies".
Je pense que tu devrais le parcourir...

[Jinroh77]

Merci pour l'information. Je vais lire cela avec attention.

Pour le moment j'ai solutionné mon problème en créant une vue dans laquelle je génère la hiérarchie.
Elle est visible dans cet autre topic.

J'ai donc abandonné l'utilisation des fonctionnalité du SCD et des SK dans mes faits.

[Jinroh77]

Bon, finalement ce n'est pas tant le pied que ce que je pensais....

J'ai donc une dimension client, avec mon IdGrandsComptesFiliale en tant que clef (valeur la plus fine) lié à celui-ci tout mes attributs dont :
DateValidite et EntiteClienteFiliale (Entite + Date = unicité de GrandCompteId).

Je duplique mes valeurs de hiérarchie pour mes 3 dates de validité. J'ai donc 3 fois exactement les même hiérarchies.
Je parcours mon cube, il m'affiche bien les même valeurs de faits pour toutes les dates de validité.

Je fais ensuite le test de supprimer une EntiteCliente sous une Holding pour 1 seule date de validité.

Lorsque je parcours mon cube en me mettant au niveau de l'entité supprimée, si je filtre selon la Date de validité supprimée, j'ai bien ma ligne qui disparait très bien.

Par contre, le total reste identique. Et si je regarde au niveau de la hoding, le total est toujours le même, quelque soit ma date de Validité sélectionnée !!!
Alors qu'en fonction du choix de l'attribut, il devrait prendre en compte ou nom la filiale dans la hiérarchie pour en faire son total....


Tout cela est bien compliqué alors qu'en T-SQL ça serait tellement simple...

Merci pour vos idées.

[Jinroh77]

Quelqu'un a une idée ???