Discussion :

[Helldz]

Bonjour,

J'ai fais quelques recherches mais je n'ai pas trouver de solution à mon problème.

J'ai actuellement un projet de création de datawarehouse avec par la suite la création de 3 cubes et de quelques reports.

Je suis depuis le début en autodidacte et je ne me débrouille pas trop mal mais il y a certains points que je n'arrive pas à éclaircir.

Je fais actuellement mes alimentations de table de fait comme celà :

-Source de données : base de prod
- Suite de look up pour faire correspondre les champs de la prod avec mes dimensions ex : numéro contrat(prod) = contrat_ak(dimensions)
- Look up qui me permet de vérifier si il y a eu une mise à jour depuis le dernier chargement

A l'heure actuel si il y a eu changement, j'update mais je sais qu'on ne doit pas update dans une table de fait.
Certaines de mes dimensions font une historisation et le fait d'update la table de fait ne permet pas de ressortir les anciennes valeurs.
J'ai pensé à une autre solution : Look up de recherche de modif si oui nouvelle insertion.

Cela permettrait que la table de fait contienne à la fois les enregistrements "périmé" et ceux "à jour" mais cela ne va t'il pas poser problème au niveau de l'affichage dans un tableau croisé dynamique (doublon de contrat par ex) et auquel cas la simple utilisation du flag de la dimension en filtre va t'il empêcher cela ?

J'ai fais beaucoup de blabla histoire de montrer ce qui me turlupine donc je vais faire un condenser de mes questions :

-Ma source de données est elle correct ? Une ou deux base de prod relié par un merge join qui contiennent toutes les valeurs qui me servent de buisness key que je fais correspondre avec des look up à mes dimensions.

-Ma théorie de placer un look up de recherche de modif sur les champs de la table de fait avec si oui nouvelle ligne et non pas update ?

Voilà merci d'avance pour vos réponses




J'ai relu mon message après réflexion et ça ne doit pas être bien clair, j'ai tendance à avoir du mal à m'exprimer clairement.

La source de données est une base de prod qui donc ne contient aucun historique.
Hors si je choisis tous les champs qui seront ensuite mes buisness key (code vendeur, num contrat, etc) mon look up qui me permet de dire "le code vendeur de cette table correspond à la buisness key de ma table DimVendeur et donc renvoi moi l'id" va systématiquement me renvoyé l'id de la première ligne ou ce code vendeur apparaît. Cela pose donc problème parce que dans mes dimensions j'ai une historisation.

Donc je me retrouve avec la première ligne retourné soit la première qui a été inséré et qui est donc surement en "expired", la ligne "current" qui me permettrai d'avoir des données à jour passe a la trappe : elle est dans ma dimension mais pas dans ma table de fait.

Je suis donc en train de me creuser la tête pour avoir mes lignes des dimensions dans ma table de fait mais j'ai vraiment du mal a comprendre comment je peux y parvenir, le problème doit venir de ma source de données.
Je suis surpris de voir que sur le net les infos sur ce point ce font rares.

[rw72000]

Bonjour,

Je ne comprends pas l'intérêt de l'update de la table de fait :

Si tu choisis d'historiser une table de dimension c'est pour réfléter le fait qu'au cours du temps pour une même référence business, des attributs peuvent être modifiés. Dans ce cas, tu veux que la table de fait soit reliée au membre de la dimension au moment où le fait s'est produit. Il n'y a donc pas de raison de mettre à jour.

En revanche, si ta dimension subit des corrections, il n'y a pas de raison d'historiser dans le datamart (mais plutôt en amont de celui-ci).

[Helldz]

Oui il n'y a pas d’intérêt et je dois donc changer cela.
Mon problème se situe plus sur la deuxième partie de mon premier message.

Ce que je veux obtenir c'est : en 2014 il y avait x clients qui avait x contrats, aujourd'hui il y a x clients qui ont x contrats.
Je veux pouvoir me servir de toutes les lignes de mes dimensions les historisées et les dernière en dates et je sèche sur la manière de procéder.

[rw72000]

Si j'ai bien compris : La solution consiste, au moment où tu alimentes ta table de fait, à aller récupérer l'id de dimension correspondant à ta business key à la date du fait. Ta condition de lookup doit donc contenir cette date.

[Helldz]

Si j'ai bien compris : La solution consiste, au moment où tu alimentes ta table de fait, à aller récupérer l'id de dimension correspondant à ta business key à la date du fait.

Si j'ai bien compris une alimentation de fait ce passe bien de cette manière : on fait correspondre la donnée récupéré de la base de prod par son équivalent dans la dimension et on recupere l'id correspondant.

Ta condition de lookup doit donc contenir cette date.

Le problème est un peu plus général, dans mon exemple je parle de date.

Pour mieux illustrer mon problème je vais te décrire ce qu'il m'arrive en ce moment :


Je fais un tableau croisé dynamique qui se presente de la manière suivante :



Or je suis censé obtenir celui la :


La différence s'explique par le fait que des modif sur la date ont été effectué dans la base de prod, ces modifs sont bien enregistrés dans ma dimension mais lors de l'alimentation de ma table de fait l'id renvoyé pour chaque buisness key de contrat est le premier et donc une ligne historisée : pour avoir le tableau juste il faudrait que l'id pris soit le dernier soit celui qui a son flag 'current'.

En gros cela peut se présenter comme ça :

Prod :
NumContrat DateReception
255 12/12/2014

Dimension
IDContrat NumContrat DateReception Flag
50 255 01/11/2014 Expired
51 255 12/12/2014 Current

Le numContrat est comparé et l'id renvoyé est 50 donc le contrat sera compté comme en novembre alors que la donnée juste si on veux la situation actuelle est decembre.

J'espère que tu aura un peu cerner ma question et merci de l’intérêt que tu porte à mon post.


Edit :Je viens de penser à quelques chose :

Si je truncate mes dimensions et quand je lance la première alim des dimensions et de la table de fait en mettant une contrainte sur le look up "where Flag='Current'' avec juste une sortie ole db donc sans update cela va t'il fonctionner ?
Techniquement j'aurais les premiers enregistrements, lors de la deuxième alim quand certaines lignes auront été historisées je les aurais dans mes faits et si ma condition sur le look up fonctionne comme je l’espère il va faire correspondre la ligne ayant le numContrat avec la dernière soit celle qui a le flag en current. Je fais fausse route ou l'idée n'est pas stupide ?

Edit 2 : j'ai essayé et cela ne fonctionne pas.

Edit 3 : Je viens de truncate ma dimension contrat et j'ai remplis ma dimension et ma table de fait et vu que je n'ai pas de données historisées à l'heure actuel tout les résultats sont correct. Logique vu qu'il n'y a qu'une ligne par contrat et que celle-ci est current. Donc mon problème se situe bien sur le fait que la première ligne est prise et les autres saute.

[rw72000]

Je pense qu'il faut se poser la question de la modélisation.
La date de reception est-elle un attribut de la dimension contrat ou bien une dimension à part entière reliée à la table de fait.

Ensuite effectivement, pour chaque table de dimension que tu historises, attribut par attribut, il faut se poser la question doit-il être historisé ou mis à jour en cas d'apparition d'une nouvel valeur. Ca s'appelle le SCD.

[Helldz]

La date de reception est un attribut de la dimension contrat mais je l'ai placé aussi dans ma table de fait (j'avais fais un exercice sur adventureworks je crois ou il y avait des dates dans la table de fait OrderDateKey ou un truc du genre). Concrètement je peux me servir des deux mais le truc pas mal avec la date dans les faits c'est qu'elle est directement mise en relation avec ma dimTemps et je peux donc choisir directement DateReception.Annee.

Le SCD je connais, je l'avais essayé quand j'avais créé ma dimensions contacts mais son mode de fonctionnement ligne par ligne est une catastrophe niveau performance.
Les tables ou j'historise font plus de 200k lignes avec entre 20 et 40 colonnes donc j'arrivais à des traitements de plus d'1h30.

Pour historiser j'avais trouvé une méthode plus simple : je met des look up si il y a modification d'un champ dans la ligne j'insert dans une table temp puis j'alimente ma dimension avec le contenu de la table temporaire et je truncate temp derrière.
Niveau perf c'est vraiment bien et comme ça j'historise. Alors j'historise toute la ligne mais on avait vu que ça ne posait pas trop de problèmes étant donné que le nombre de modif est faible.

[rw72000]

Pour le pb de perf du SCD, tu peux utiliser le concpet sans utiliser le composant.
Le plus performant :
-Coder un SCD toi-même en SQL
Un entre-deux :
-Utiliser le composant SSIS SCD kimball de codeplex
Le moins performant :
-Utiliser le composant SSIS built-in.

[fredinkan]

Pour le pb de perf du SCD, tu peux utiliser le concpet sans utiliser le composant.
Le plus performant :
-Coder un SCD toi-même en SQL
Un entre-deux :
-Utiliser le composant SSIS SCD kimball de codeplex
Le moins performant :
-Utiliser le composant SSIS built-in.

Hello,

Je rejoint rw72000 sur ces point, en ajoutant une possibilité entre son point 2 et 3.

Le composant SCD est certes lent lorsqu'il est utilisé sur plusieurs milliers de lignes, cependant je vois 3 points d'amélioration:
- Avoir un calcul de delta (ou passer par du change data capture (CDC)) pour limiter données entrantes. Ceci peut aussi améliorer les perf des autres points ci-dessus.
- Passer dans l'Advanced Editor et vérifier que, selon tes besoins, tu n'as pas d'options type inferred member qui sont activées
- Calculer des indexes permettant d'améliorer les performances.

Dans le cas où tu ne cherches pas à utiliser les atouts du SCD (typiquement la gestion des inferred members) et que tu ne désires qu'effectuer un "table comparison" comme il en existe sur de nombreux ETL, je te conseille de te tourner vers des composants externes ou de le faire en SQL ou via d'autres composants.