Classiquement pour gérer l’historisation en 1,N on fait comme dans cette exemple :
ENFANT
(1,1)
|
[a pour tuteur ] - date d'affectation
|
(1,n)
TUTEUR
On crée une 3eme entité H_ENFANT_TUTEUR :
- Id_enfanrt (PK)
- Id_tuteur
- Date_affectation (PK)
Sur mon projet (Datawarehouse façon Inmon, et pas Kimball ;-) on a cette problématique bien sûr de la relation 1,N historisée mais en plus les entités Enfant et Tuteur sont elles même historisées !!! On stocke en fait des photos de l'enfant et du tuteur ... chacune a une période de validité formée de 2 dates.
Enfant
------
Id_enfant (pk)
nom
date_debut_val (pk)
date_fin_val
idem pour le tuteur
Si je reste comme ça, avec une entité entre les deux je vais avoir une base très difficilement exploitable ... 3 historiques déconnectés, qui risquent de se chevaucher ... et les interrogation a date doive se faire avec 3 critère between sur chacune des 3 tables.
Je réfléchis donc a une autre modélisation, plus exploitable avec des surrogate key. rappel : c'est sensé être une base normalisée (c'est le socle 3NF d'un datawarehouse en fait). Au chargement une clé technique est calculée pour chaque photo de l'enfant et le tuteur. A chaque insertion d'une nouvelle ligne d'historique dans les 2 entités, j'insère aussi la correspondance dans l'asso intermediaire et ferme la correspondance précédente. J'obtiens ainsi un ensemble beaucoup plus exploitable car joignable facilement et parfaitement sur les surrogate key ...
Enfant
------
sk_enfant (ak)
Id_enfant (pk)
nom
date_debut_val (pk)
date_fin_val
H_Enfant_Tuteur
------
sk_enfant (ak)
sk_tuteur(ak)
date_debut_val (pk)
date_fin_val
Tuteur
------
sk_tuteur(ak)
Id_tuteur(pk)
nom
date_debut_val (pk)
date_fin_val
Qu'en pensez vous ?
Que dit la regle de l'art sur l'historisation totale en 3NF ?
Merci (j'espere que tout le monde me suis ;-)
Partager