Discussion :

[elspliffo]

Bonjour,

nous héritons d'un datawarehouse concu par un prestataire BI, ce datawarehouse est alimenté via talend, la source étant une base mysql.
Le datawarehouse est lui aussi sous mysql.

Notre prestataire a ajouté, dans chacune des tables de fait et de dimensions du datawarehouse, des identifiants dédiés autoincrementés. Les liens entre les tables sont tous faits
via ces identifiants. D'apres lui, ces identifiants sont très utiles lorsqu'on aggrège des données de différentes sources dans une même table, ce qui me parait effectivement un bon point.

Néanmoins ces identifiants sont très contraignants :
- on ne peut pas parraléliser les chargements car les identifiants ne sont pas encore connus, le chargement doit donc être séquentiel
- si on supprime des données dans les tables (cas d'un reload complet d'une table dont les données sources ont changé), et qu'il y a d'autres tables liées, alors tous les identifiants changent et les liens sont tous cassés.

Si on gardait les identifiants (déjà uniques) de notre source de données, nous parerions à ces problèmes.

Qu'en pensez-vous ? Quelle pratique de modélisation adoptez-vous par rapport à cela ?

Merci pour votre aide !

[bstevy]

Le principe des identifiants auto incrémenté est de crée une clef technique, qui n'a aucune valeur fonctionnelle.
Si vos identifiants sont déjà comme ca, vous pourriez sans doute les utiliser, mais en théorie, c'est bien avec des nouvelles clefs qu'on fait les liens dans un dwh


Je ne comprends pas très bien votre histoire de re-chargement. De quelle table faite vous un reload ? une table du dwh ?
Dans quel cas avez vous toute une table à recharger ? Pouvez vous donner plus de détails sur ce que vous cherchez à faire à ce niveau ?




Ce que je pense qui vous bloque est que la création des id ne se fait qu'a l'insertion.
Normalement, vous devriez avoir une table associant une clef fonctionnelle est une clef technique, vous generez très rapidement tous vos nouveau identifiants, et à partir de là, le reste de vos chargements peuvent se faire en parallele...

[beeenj]

Les identifiants uniques numériques sont nécessaires et une pratique toute à fait normale. Celà permet d'accélérer les jointures entre les tables ainsi que d'utiliser des indexes plus performants.

Dans 90% des cas, j'utilisent des identifiants numériques auto-incrémentés. Cependant, j'ai certains identifiants que j'utilise tel quel depuis ma source transactionnelle (OLTP). exemple : numéro client, numéro produit. Ils sont uniques et numériques donc font l'affaire... il n'est pas nécessaire de les renuméroter. De même pour la date que j'écris au format YYYYMMDD: 20150807.


Si vous avez des identifiants uniques numériques vous pouvez les réutilisez.

Pour la parallelisation, bstevy a bien répondu.

Pour votre suppression de données, pour moi il ne faut jamais le faire. En décisionnel, on désactive des données mais ne supprime pas. J'entends par désactiver, l'utilisation d'une colonne booléenne qui a 1 pour actif et 0 pour inactif.

[elspliffo]

Bonjour,

merci pour vos retours, mes excuses pour le retour très lent ...

Si vos identifiants sont déjà comme ca, vous pourriez sans doute les utiliser, mais en théorie, c'est bien avec des nouvelles clefs qu'on fait les liens dans un dwh

Les identifiants uniques numériques sont nécessaires et une pratique toute à fait normale. Celà permet d'accélérer les jointures entre les tables ainsi que d'utiliser des indexes plus performants.

Le choix est bien là, soit on utilise des ids dédiés au datawarehouse, soit on utilise les ids de la source de données, déjà autoincrémentés et uniques.

Ce que je pense qui vous bloque est que la création des id ne se fait qu'a l'insertion.
Normalement, vous devriez avoir une table associant une clef fonctionnelle est une clef technique, vous generez très rapidement tous vos nouveau identifiants, et à partir de là, le reste de vos chargements peuvent se faire en parallele...

Ok, mais à quel moment alimentez-vous cette table ? Elle est préprovisionnée ? Vous créeriez donc une table de correspondance par table de fait ?

Je ne comprends pas très bien votre histoire de re-chargement. De quelle table faite vous un reload ? une table du dwh ?
Dans quel cas avez vous toute une table à recharger ? Pouvez vous donner plus de détails sur ce que vous cherchez à faire à ce niveau ?

On fait un reload par exemple lorsqu'on se rend compte qu'une colonne de la table a été mal alimentée pendant qq temps (bug, source de données incorrectes ...).

Merci,