Discussion :

[VITALTH]

Bonjour,
Voilà je me pose une question de conception.
Disposant d'une BDD relationnelle SQL Server avec des clés primaires de type GUID, des indexes et des contraintes de clé étrangères. Enfin bref tout ce qui fait l'identité d'une SGBDR, je souhaite réaliser un entrepôt de données à partir de cette SGBD. Mais je me posais les questions suivantes :
- Est il préférable (peut être pour des questions de performances, déboggages ou une autre raison que je ne connais pas) de passer mes clés primaires en entier auto incrémenté ? ou est il préférable de conserver les GUID ? ou il n'y a pas de préférence mais je vais me casser les dents en conversion avec mon ETL pour un gain sinon nul en tout cas très limité ?
- Est il préférable de supprimer les contraintes diverses (je dis ça parce qu'une BDD vit, ces enregistrements aussi mais dans l'entrepôt il est préférable de conserver un historique).
- Est il préférable de conserver les indexes.

Merci pour vos réponses argumentées.

[d.joubert]

Bonjour,
Voilà je me pose une question de conception.
Disposant d'une BDD relationnelle SQL Server avec des clés primaires de type GUID, des indexes et des contraintes de clé étrangères. Enfin bref tout ce qui fait l'identité d'une SGBDR, je souhaite réaliser un entrepôt de données à partir de cette SGBD. Mais je me posais les questions suivantes :
- Est il préférable (peut être pour des questions de performances, déboggages ou une autre raison que je ne connais pas) de passer mes clés primaires en entier auto incrémenté ? ou est il préférable de conserver les GUID ? ou il n'y a pas de préférence mais je vais me casser les dents en conversion avec mon ETL pour un gain sinon nul en tout cas très limité ?
- Est il préférable de supprimer les contraintes diverses (je dis ça parce qu'une BDD vit, ces enregistrements aussi mais dans l'entrepôt il est préférable de conserver un historique).
- Est il préférable de conserver les indexes.

Merci pour vos réponses argumentées.

- auto-incrément pour optimiser les requêtes (surtout par rapport à du GUID) et gérer les modifications/réaffectations de clés primaires de ton système source.
- sujet à polémique, certains consultants préconisent les clés étrangères, d'autres comme moi non en arguant sur le fait que l'ETL doit parfaitement gérer les problèmes de clés inexistantes. A toi de voir ton degré de confiance dans le développement de ton ETL.
- Les index de ton datawarehouse vont dépendre des besoins de celui-ci, et non de tes bases sources. En gros tu crées les index dont tu as besoin, ceux-ci seront peut-être équivalents à ce que tu as dans ton système source, mais pas nécessairement.

Pour toutes ces questions de modélisations, je t'invite à lire le bouquin the data warehouse toolkit de Ralph Kimball qui répondra à la majorité de tes questions

[VITALTH]

En fait c'est sur le deuxième point que je me pose le plus de questions :
Imaginons une table de vente non historisé lié à des responsables commerciaux (utilisateurs). Imaginons que le logiciel qui permet ceci permet la suppression des utilisateurs qui n'ont pas touché à des ventes depuis plus d'une année. Dans le logiciel, quand on supprime un utilisateur, on lui supprime les ventes associées. Mais ceci n'est pas grave car le logiciel en question ne gère que les ventes de l'exercice en cours (la dernière année).
Dans l'entrepôt on historise les ventes et ce dans l'objectif de faire du reporting sur plusieurs année. Dans mon exemple les responsables commerciaux ne sont pas historisé car cet axe d'analyse n'est pas pertinent. (Au pire on affecte les ventes dont les utilisateurs sont supprimés à "Unknown").
A l'origine dans la SGBD entre ventes et utilisateurs il y a une contrainte de clé étrangère mais dans mon entrepôt je n'en veux pas car l'utilisateur n'existant plus je risque de violer la clé.
Ma question reste donc ouverte : est il préférable de mettre un Null dans tous les enregistrements de l'historique qui n'ont plus d'utilisateurs (pour être plus propre) sachant que le temps de traitement risque d'être éventuellement long (dépend de l'historique) avec du dev. (même s'il y en a pas bcp) à gérer avec l'ETL ou est il préférable de laisser les valeurs de clé étrangère dans la table des ventes en supprimant la contrainte de clé étrangère dans l'entrepôt sachant que de toute façon les ventes dans le cube dans ce cas de figure ressortiront avec le membre "Unknown".

[d.joubert]

Ta dimension "Responsable commercial" doit contenir tous les membres ayant eu une vente dans ta table de faits. Tu ne peux pas les supprimer sous prétexte qu'ils n'ont pas eu de vente récemment, c'est le principe de l'historisation. Si tu fais ce que tu as dit, tu perds de l'information.
Tu peux à la rigueur adjoindre un champs statut pour dire s'ils sont oui ou non actifs.

[VITALTH]

Le problème c'est que je ne souhaite pas plutôt je ne dois pas toucher le logiciel source qui gère la SGBDR. Si celui ci permet la suppression d'utilisateur alors que d'autre enregistrements lui sont associées et bien dommage pour moi.
Le truc c'est que comme j'historise ma table de fait, je me vois mal historiser toutes les dimensions associé à cette table sous prétexte que le logiciel qui gère la SGBDR ne le fait pas. (là je ne parler que d'une table de dimension mais il peut y en avoir une 30taine ou une 40taine). Ke veux dire mon package ETL risque d'être une usine à gaz.

[d.joubert]

Je ne comprends pas ce qui te gène dans le fait d'historiser 30 ou 40 dimensions, c'est le principe même de la BI. Sinon pourquoi s'embêter à garder des données dans tes tables de faits que tu ne peux pas analyser.

Effectivement, tu risques d'avoir beaucoup de packages, mais tu ne seras pas le premier

[VITALTH]

OK Merci pour l'info.

[cedrickb]

Il n'y a pas de contre indication sur l'historisation de 30 dimensions (ou plus).
Par contre il est nécessaire de voir la pertinence de ces historisations!! Est-ce que toutes les dimensions doivent être historisées? Fonctionnellement y a t il un intérêt??

L'idée étant de pouvoir toujours alimenter ta table de fait en l'historisant tu peux utiliser des valeurs de références dans tes dimensions pour traiter ce genre de problématiques.

Par exemple:
A l'instant T
Tu as un commercial (présent donc dans ta dimension personnel)
Dans ton fait tu vas donc faire référence à l'employé en question car il existe.

A l'instant T+1
Ton commercial n'existe plus (il n'apparait plus dans ta dimension personnel)
Dans ton fait tu vas maintenant faire référence à l'enregistrement de référence de ta dimension personnel

A quoi ressemble l'enregistrement de référence?
Si ta structure est ID/NOM/PRENOM
Ton enregistrement de référence sera 1/'NON CONNU'/'Non CONNU'

Ainsi tu vas pouvoir suivre tes ventes (car elles sont réelles dans ton SI Source) et faire ressortir que la vente existe bien mais qu'elle n'est pas attaché à un employé car on a une référence à l'enregistrement de référence.

J'espère avoir été clair, c'était juste une petite précision suite à cette conversation

Et pour répondre à ça

sujet à polémique, certains consultants préconisent les clés étrangères, d'autres comme moi non en arguant sur le fait que l'ETL doit parfaitement gérer les problèmes de clés inexistantes. A toi de voir ton degré de confiance dans le développement de ton ETL.

Je fais parti de ceux qui pensent qu'il faut dénormaliser le modèle de données, et utiliser des clés primaires TECHNIQUES (auto increment), mais bien sur cela va dépendre du contexte dans lequel le DWH sera créé...

++

[d.joubert]

Nan, mais soyons sérieux.

Vous mettez un champs statut dans votre dimension Responsable Commercial, pour dire s'il est actif ou non. Mais on ne va pas s'amuser à supprimer chaque jour les membres de la dimensions ayant été supprimés la veille, ni à passer un update chaque jour sur une table de faits.

Pour le sujet sur les clés, on parlait des clés étrangères en fait. Les auto-incréments concernaient la première question.

[cedrickb]

Nan, mais soyons sérieux.

Vous mettez un champs statut dans votre dimension Responsable Commercial, pour dire s'il est actif ou non. Mais on ne va pas s'amuser à supprimer chaque jour les membres de la dimensions ayant été supprimés la veille, ni à passer un update chaque jour sur une table de faits.

=> effectivement il s'agit du choix le plus judicieux, mais il en existe d'autre qui peuvent être applicable en fonction du contexte, j'apportais juste un complément d'information.