Decideo - Actualités sur le Big Data, Business Intelligence, Data Science

Abonnez-vous gratuitement à Decideo !


Decideo


 
Forums, dernières contributions

Surrogate Keys ( clés de substitution ) ou clés des SO ?

 Luis Ribeiro
Lundi 3 Avril 2006

Version imprimable
[Ignorer]
Comment sont joints les faits aux dimensions dans le DW ?.
Doit on utiliser obligatoirement des clés de substitution ( surrogate keys) ou est-il admis d'utiliser les clés du Systéme Opérant ?

R. Kimball préconise que chaque occurence d'une dimension doit être identifiée par une clé de substitution : un numéro auto de 1 à n qui s'incrémente de 1 à chaque nouvelle occurence, codé sur 4 octets soit plusieurs milliards de possibilités.

La clé de substitution semble répondre à une double contrainte :

1) Optimiser jointures des requêtes.
En complément de la dénormalisation qui fusionne les données de plusieurs tables en une, ce qui permet de supprimer de fait des jointures consommatrices.
Les jointures restantes ( entre les dimensions et les faits ) sont optimisées sur 4 octets pour les rendre plus rapides que les clés des SO, qui par ailleurs doivent parfois être concaténes pour rendre une dimension unique : exemple un employé travaille dans plusieurs services dans un axe 'organisation', le matricule du salarié ne suffit pas à le rendre unique, la clé du SO deviendrait clé du service + matricule du salarié soit N octets.

Cette contrainte est-elle devenue caduque avec la puissance des machines actuelles ?

2) Permettre de prendre en compte les changements de la dimension dans le temps.
Exemple : un client change d'adresse. S'il convient de retenir ce changement, le numéro de client ( clé naturelle ) ne permet pas seul de faire référence à l'une ou l'autre adresse. Si le concepteur utilise des clés naturelles, il est alors enclin à ne retenir dans la dimension que l'adesse ACTUELLE et à placer les différentes adresses dans la (ou les ) table de fait.
Un autre exemple est la purge puis la réutilisation du numéro de client pour un nouveau client.

L'inconvénient à mon sens de la méthode de R. Kimball est qu'il devient difficile d'obtenir la liste des clients avec leur derniére adresse sans maintenir un top ou une date de validité au niveau de la dimension ( mais c'est peut-être un moindre mal ?)

Etant novice dans l'art du DW, que préconisez vous, la majorité des sociétés de service semblent modéliser en étoile et retenir les clés des SO ? Doit-on prendre R. kimball au pied de la lettre ou est-ce devenu obsoléte ?

Je vous remercie de préciser si possible la taille des DW sur lesquels vous êtes intervenus.
 Francis Incourt
Mercredi 5 Avril 2006

Version imprimable
[Ignorer]
Selon la méthode Kimball, il faut distinguer les attributs majeurs, historisés et les attributs mineurs qui feront l'objet d'une mise à jour.
Typiquement, l'adresse email, ...sont des attributs mineurs, en général.
Pour connaître la dernière version d'un client, on ajoute en général un champ de statut (Courant ou vieux) et éventuellement une 'date from' et une 'date to' .
Dans la pratique, il m'est arrivé créer 2 tables, l'une avec les attributs suivis historiquement et l'autre avec les attributs courants...

Francis Incourt


Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store