Base de données recette + historique [Résolu]

[Vilukariok]

C'est encore moi

Je voudrais préciser qu'il faut égalemment se souvenir de l'ordre dans lequel j'ai effectué mes recette. Si je reprend votre schéma:



Je m'aperçois que pour sauvegarder l'ordre d'insertion, je vais avoir besoin d'une table d'historisation de type MAILLON_HISTORIQUE.

Ou alors je peu rajouter le champ "RecettePrecedentSeq" dans la table RECETTE. Mais cela va avoir des répercutions sur les tables d'historisation.

[fsmrel]

Bonjour,

Envoyé par Vilukariok

si je veux insérer ces lignes:

Code :

Alors la clef étrangère "MAILLON_RECETTE_FK2" m'en empêchera.

La clef étrangère MAILLON_RECETTE_FK2 n’empêchera absolument rien : la table MAILLON est insensible aux ajouts (par INSERT) dans la table RECETTE. Elle ne peut rouspéter que lorsque (par DELETE ou UPDATE) vous lui supprimez sa valeur de référence dans la clé primaire de la table RECETTE.

Envoyé par Vilukariok

Donc il ne faudrait pas faire cette déclaration de "MAILLON_RECETTE_FK2"?

Malheureux ! Autant supprimer un mur porteur... Avec vous, il ne faut pas être cardiaque...

Ceci dit, quelle est votre intention ? Créer une chaîne non pas entre les paires {RecetteId, IngredientId}, mais entre les singletons {RecetteId}, c'est-à-dire indépendamment des ingrédients ?

Envoyé par Vilukariok

Je suis en train de faire une requête pour sélectionner la recette dans le bon ordre.

Évidemment, avec DB2, MS SQL Server, Oracle, etc. rien de plus simple, car on utilise alors une union récursive. Par exemple, pour afficher dans le bon ordre les maillons de la recette <'r01', 'i01'> :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
WITH CHAINE (RecetteId, IngredientId, LeMaillon, LePrecedent) AS
 -- Amoçage de la pompe
 (
  SELECT RecetteId, IngredientId, RecetteSeq, CAST('/' AS CHAR(04)) AS LePrecedent
  FROM   RECETTE AS x -- Amorçage de la pompe
  WHERE  NOT EXISTS
           (SELECT *
            FROM   MAILLON AS y
            WHERE  x.RecetteId = 'r01' AND IngredientId = 'i01'
              AND  x.RecetteId = y.RecetteId
              AND  x.IngredientId = y.IngredientId
              AND  x.RecetteSeq = y.RecetteSeq)
 
 UNION ALL  -- Partie récursive
 
 SELECT x.RecetteId, x.IngredientId, x.RecetteSeq, x.RecettePrecedentSeq
 FROM   MAILLON AS x JOIN CHAINE AS y   
          ON  x.RecetteId = y.RecetteId
          AND x.IngredientId = y.IngredientId      
          AND x.RecettePrecedentSeq = y.LeMaillon
 ) 
-- Affichage du résultat 
SELECT LeMaillon, LePrecedent
FROM   CHAINE
;

Mais si j’ai bien compris, l’union récursive n’est pas possible avec MySQL.

La représentation intervallaire selon SQLpro permet peut-être de pallier ? (Le valeureux CinePhil y fait souvent référence, mais je n’ai pas lu l’article, donc à vous de voir).


N.B. Je n'ai pas encore lu votre message de 14h27, on verra cela un peu plus tard, car d'autres tâches m'attendent.

[Vilukariok]

Diantre !

Je me suis trompé dans mon copié-collé. Je suis confus, je voulais écrire:

Il est possible d'exécuter ce code:

Code :

1
2
3
4
5
INSERT INTO MAILLON VALUES ('r01', 'i01', '002', '001') ;
INSERT INTO MAILLON VALUES ('r01', 'i01', '003', '002') ;
...
INSERT INTO MAILLON VALUES ('r01', 'i01', '150', '149') ;

Mais il n'est pas possible d'exécuter celui-ci car la "MAILLON_RECETTE_FK2" l'empêche:

Code :

1
2
3
4
5
INSERT INTO MAILLON VALUES ('r01', 'i01', '002', '001') ;
INSERT INTO MAILLON VALUES ('r01', 'i02', '003', '002') ;
...
INSERT INTO MAILLON VALUES ('r01', 'i03', '150', '149') ;

Notamment à cause de cette déclaration:

Code :

1
2
CONSTRAINT MAILLON_RECETTE_FK2 FOREIGN KEY (RecetteId, IngredientId, RecettePrecedentSeq)
      REFERENCES Recette (RecetteId, IngredientId, RecetteSeq)

Du moins c'est ce que dit mon SGBD.

[fsmrel]

Envoyé par Vilukariok

Du moins c'est ce que dit mon SGBD.

... Qui a parfaitement raison.

Jusqu’ici, on chaînait des recettes ayant même valeur pour les attributs RecetteId et IngredientId.
Dans mon exemple , je chaîne <'r01', 'i01', '001'>, <'r01', 'i01', '002'>, ... <'r01', 'i01', '150'>.

Maintenant, vous voulez chaîner des recettes ayant même valeur seulement pour l’attribut RecetteId :
<'r01', 'i01', '001'>, <'r01', 'i02', '002'>, <'r01', 'i03', '149'>, ...

Votre logique revient à considérer que l’attribut IngredientId ne fait pas partie de la clé primaire de la table RECETTE (pas plus que de celle de la table MAILLON) :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE RECETTE (
   RecetteId            CHAR(04)             NOT NULL,
   IngredientId         CHAR(04)             NOT NULL,
   RecetteSeq           CHAR(04)             NOT NULL,
   RecetteDepuis        DATETIME             NOT NULL,
   QuantiteDepuis       DATETIME             NOT NULL,
   Quantite             INT                  NOT NULL,
   CONSTRAINT RECETTE_PK PRIMARY KEY  (RecetteId, RecetteSeq),
   CONSTRAINT RECETTE_RECETTE_NOM_FK FOREIGN KEY (RecetteId)
      REFERENCES RECETTE_NOM (RecetteId),
   CONSTRAINT RECETTE_INGREDIENT_FK FOREIGN KEY (IngredientId)
      REFERENCES INGREDIENT (IngredientId)
) ;

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE MAILLON (
   RecetteId              CHAR(04)             NOT NULL,
   IngredientId           CHAR(04)             NOT NULL,
   RecetteSeq             CHAR(04)             NOT NULL,
   RecettePrecedentSeq    CHAR(04)             NOT NULL,
   CONSTRAINT MAILLON_PK PRIMARY KEY  (RecetteId, RecetteSeq),
   CONSTRAINT MAILLON_AK UNIQUE (RecetteId, RecettePrecedentSeq),
   CONSTRAINT MAILLON_RECETTE_FK1 FOREIGN KEY (RecetteId, RecetteSeq)
      REFERENCES Recette (RecetteId, RecetteSeq),
   CONSTRAINT MAILLON_RECETTE_FK2 FOREIGN KEY (RecetteId, RecettePrecedentSeq)
      REFERENCES Recette (RecetteId, RecetteSeq)
) ;

Évidemment, cela remet en cause les règles initiales.

[Vilukariok]

Bonjour,

Votre logique revient à considérer que l’attribut IngredientId ne fait pas partie de la clé primaire de la table RECETTE (pas plus que de celle de la table MAILLON) :

Effectivement!

Dans ce cas-là, son utilité dans la table Maillon est à revoir.

Le modèle va donc subir une évolution conséquente.

J'ai essayé de récapituler ces changements dans un diagramme, en respectant le cahier des charges suivant:

- Une recette est constitué d'ingrédient.
- Chaque ingrédient utilise une quantité précise de matière.
- Un même ingrédient peut être utilisé à plusieurs reprise dans une recette (peu importe la quantité).
- Il y a un ordre précis à respecter pour l'insertion de ces ingrédients.
- Il faut se souvenir précisément de la constitution de toutes les recettes (historisation).
- Et pour la base de données:

Code :

il est hors de question de modifier des tombereaux de lignes !

[Vilukariok]

Les principaux changements de ce diagramme étant:

- "IngredientId" ne fait plus parti de la clé primaire, donc il n'apparait plus dans les tables d'historisation.

- Une recette est représenté par son couple "RecetteId" et "RecetteSeq".
C'est donc ce couple qu'il faut utiliser pour l'historisation.

- L'enchainement (l'ordre) des ingrédients doit être historiser égalemment.
C'est sur ce point que je doute le plus...

En espérant ne pas avoir tout chambouler.

[Vilukariok]

Aie!

Ce Diagramme n'est pas correct.

Il y a déjà deux problèmes avec les tables d'historisation.

1) Les clés étrangères "RecetteSeq" des tables "MaillonHistorique", "RecetteHistorique" et "QuantiteHistorique" me posent problèmes lorsque je dois faire une mise à jour. Cette mise à jour s'effectue en 2 temps. Premièrement il faut insérer la ligne de la mise à jour dans les tables d'historiques (OK). Deuxièmement il faut supprimer la ligne cette ligne de "recette". Et là, le SGBD n'est pas d'accord...
Normal, il a raison.

2) Dans les tables d'historisation, je n'ai pas l'ingrédient associé à "RecetteSeq".

Je propose le diagramme suivant, et je retourne à mes tests.

[fsmrel]

Bonjour,


L'affaire se corse (chef-lieu Ajaccio).


Historisation de l’ingrédient

Si la composition d’une recette peut varier non seulement en fonction de la quantité, mais aussi de l’ingrédient, alors la table Recette devrait être dotée d’un attribut IngredientDepuis. Il faudrait en outre mettre en œuvre une table INGREDIENT_HISTORIQUE, avec les attributs suivants : id_recette, RecetteSeq, IngredientId, IngredientDurantDeb, IngredientDurantFin (la technique utilisée pour la quantité est à reprendre pour l'ingrédient, mutatis mutandis comme dirait l'autre).

Et par la même occasion, l’attribut IngredientId est à évacuer de la table RECETTE_HISTORIQUE.

Tout ceci est conforme à ce que l’on trouve dans les ouvrages de Date dont j’ai fait mention.

Table MAILLON_HISTORIQUE

La structure de cette table est conforme à l’esprit de ce qui décrit dans ces mêmes ouvrages.


Table QUANTITE_HISTORIQUE

L’attribut rec_id_recette fait double emploi avec l’attribut id_recette et doit dégager.


Définition des clés alternatives (AK)

Les attributs utilisés pour les dates de début participent aux clés primaires des tables d’historisation (citons par exemple l’attribut RecetteDurantDeb de la table RECETTE_HISTORIQUE). Pour des raisons de symétrie, de complétude, les attributs utilisés pour les dates de fin participent aux clés alternatives. Voyez le diagramme que je vous avais proposé le 21 avril (comme le temps passe...)

Pour mettre cela en œuvre, reportez-vous à la documentation en ligne de Power AMC ou bien à l’exemple que j’ai proposé ici.

[Vilukariok]

Je dirais même:
L'affaire est dans le sac (chose en sont temps) (cheveux sur la langue..)


En tout cas, mille merci fsmrel !!!


Récapitulatif:

Une "tour de contrôle" appelé "RecetteHistorique"

Trois table distinctes d'historisation car il faut historiser que ce qui doit l’être et dans mon cas il s'agit des attributs:
Ingredient, Quantite et Ordre ("Sequence").

PK: Les attributs "...DurantDeb" font parties de la clé primaire.
AK: Les attributs "...DurantFin" font parties de la clé alternative.

Tout est bien qui fini bien.
Un aperçu du résultat:



J'ai un dernier doute concernant la fameuse tour de contrôle "RecetteHistorique".
Ma question est toute simple: est ce qu'il faut renseigner cette table dès qu'une des tables d'historisation 'reçoit' un nouvel "uplets" ?

Exemple concret: Si je change la quantité d'un ingrédient. Les tables "RecetteHistorique" et "QuantiteHistorique" sont impactées ?

[fsmrel]

Envoyé par Vilukariok

cheveux sur la langue.

Tant que ça n’est pas dans la soupe (ça ne serait pas bon pour la réputation de la recette...)

Envoyé par Vilukariok

AK: Les attributs "...DurantFin" font parties de la clé alternative.

Pas vu...

Envoyé par Vilukariok

J'ai un dernier doute concernant la fameuse tour de contrôle "RecetteHistorique".
Ma question est toute simple: est ce qu'il faut renseigner cette table dès qu'une des tables d'historisation 'reçoit' un nouvel "uplets" ?

Exemple concret: Si je change la quantité d'un ingrédient. Les tables "RecetteHistorique" et "QuantiteHistorique" sont impactées ?

Selon nos conventions, changer la quantité d’un ingrédient revient à historiser l’ancienne valeur de cette quantité (accompagnée de sa période, table QUANTITE_HISTORIQUE) et mettre à jour les attributs Quantite et QuantiteDepuis (table RECETTE) en fonction de la nouvelle quantité. La table RECETTE_HISTORIQUE est totalement étrangère à cette affaire, sinon cela voudrait dire que vous historiseriez la recette elle-même : comme ça n’est pas le cas, la valeur de l’attribut RecetteDepuis (table RECETTE) resterait inchangée et elle figurerait aussi dans la table RECETTE_HISTORIQUE : il y aurait viol de la première contrainte (Requirement 1). Souvenez-vous :

Envoyé par fsmrel

Voici les règles de base de l’historisation quant aux contraintes auxquelles celle-ci doit se plier (elles font partie des "nine requirements" définis par Date, Darwen et Lorentzos) :

1) Si la base de données montre qu’il y a une recette r au jour j, elle ne doit contenir qu’un seul tuple qui exprime ce fait.
Ainsi, si la table RECETTE dit que la recette existe au jour j, la table RECETTE_HISTORIQUE doit être muette à ce sujet, tandis que si la table RECETTE_ HISTORIQUE dit que la recette existe au jour j, c’est la table RECETTE qui doit être muette.

Je n’ai pas dit que l’historisation est un sujet facile. Relisez bien ce qu’écrivent Date, Darwen et Lorentzos, qui ont permis d’éviter que la norme SQL soit entachée des erreurs contenues dans les propositions de Snodgrass (le chapitre 7 de la norme : « SQL/Temporal » a été reporté aux calendes, il y a de cela quatorze ans). Voyez le papier An Overview and Analysis of Proposals Based on the TSQL2 Approach de Darwen et Date à ce sujet.

[Vilukariok]

Je n’ai pas dit que l’historisation est un sujet facile. Relisez bien ce qu’écrivent Date, Darwen et Lorentzos, qui ont permis d’éviter que la norme SQL soit entachée des erreurs contenues dans les propositions de Snodgrass (le chapitre 7 de la norme : « SQL/Temporal » a été reporté aux calendes, il y a de cela quatorze ans). Voyez le papier An Overview and Analysis of Proposals Based on the TSQL2 Approach de Darwen et Date à ce sujet.

C'est sure, ce n'est pas un exercice facile. Mais j'y vois beaucoup plus clair grâce à vous. Je commence déjà à penser au développement de ce principe sur d'autre application.

A ce sujet là, j'ai relu notre conversation de a à z et je me permet de revenir à une des première modélisation:


La règle de gestion qui a permis d'écrire ce diagramme est la suivante:
"Une recette est défini par un l'ensemble {ingrédient, recette_nom}"
En effet il s'agit de seulement 2 paramètres dans ce cas.

Maintenant imaginons qu'il y ait une règle de gestion plus complexe, c'est à dire une règle composée d'une dizaines de paramètres.
Tous ces paramètres vont donc se transformer en attribut dans mes tables.
Cela peux donner lieux à une modélisation suivante:


Le schéma est vite devenu conséquent... et je n'ai modélisé dans ce cas que 6 paramètres... alors 10 ! Diantre!

L'idée qui me vient est de créer une table d'échange. Cette table prendrais en compte les 10 paramètres ainsi qu'un champ auto_incrementant. Cet attribut auto incrémentant serais ensuite utilisé dans toutes les tables d'historisation ainsi que dans la table courante "recette".
1) Est ce une idée aberrante?
2) Peut être existe il une règle précisant qu'il ne faut pas faire ou justement qu'il faut faire cela? (Peut-être un des "nine requirements" ?) (le livre est d'ailleurs commandé )

Si vous aviez un commentaire à faire, je suis tout ouï.

[fsmrel]

Bonjour Vilukariok,


Je vous réponds tardivement, ne m'en veuillez pas mais j’ai dû placer la discussion en priorité basse...

Envoyé par Vilukariok

L'idée qui me vient est de créer une table d'échange.

Vous me rappelez mon gamin quand il avait sept ou huit ans et qu’il disait à ses copains : « Les gars, j’ai une idée ! » Toutes les mères de famille se précipitaient pour récupérer leur progéniture avant que des événements fâcheux ne se produisent...

Envoyé par Vilukariok

Maintenant imaginons qu'il y ait une règle de gestion plus complexe, c'est à dire une règle composée d'une dizaine de paramètres.

Dans l’exemple à deux paramètres, vous dites que ceux-ci sont les suivants :

Nom de la recette et Ingrédient

Reprenons le diagramme que j’ai proposé. De ce que vous dites, je déduis que la quantité et l'ordre d'insertion ne sont pas des « paramètres » disons clés, mais des conséquences de la paire { Nom de la recette, Ingrédient}, c'est-à-dire, sous forme de dépendances fonctionnelles, dans le cas de la table RECETTE :

{RecetteId, IngredientId} → {RecetteDepuis}
{RecetteId, IngredientId} → {Quantite}
{RecetteId, IngredientId} → {QuantiteDepuis}
{RecetteId, IngredientId} → {OrdreInsertion}
{RecetteId, IngredientId} → {OrdreInsertionDepuis}

Dans le cas de votre diagramme, dans lequel l‘attribut Ordre fait (légitimement) partie de la clé :

{RecetteId, IngredientId, Ordre} → {RecetteDepuis}
{RecetteId, IngredientId, Ordre} → {Quantite}
{RecetteId, IngredientId, Ordre} → {QuantiteDepuis}

Avant de passer à dix ingrédients, voyons déjà le cas de trois ingrédients :

Nom de la recette, Ingrédient et Etape

Considérons la structure de la table RECETTE de votre diagramme. Elle évolue. Deux options :

Option 1. Soit l’étape joue le même rôle « clé » que le nom de la recette et l’ingrédient, auquel cas, dans la suite logique des choses on a les dépendances fonctionnelles suivantes :

{RecetteId, IngredientId, EtapeId, Ordre} → {RecetteDepuis}
{RecetteId, IngredientId, EtapeId, Ordre} → {Quantite}
{RecetteId, IngredientId, EtapeId, Ordre} → {QuantiteDepuis}

Option 2. Soit, si l’on se réfère à votre diagramme, l’étape joue un rôle analogue à celui de la quantité, c'est-à-dire non clé (avec mise en oeuvre au passage d’un attribut EtapeDepuis) :

{RecetteId, IngredientId, Ordre} → {RecetteDepuis}
{RecetteId, IngredientId, Ordre} → {Quantite}
{RecetteId, IngredientId, Ordre} → {QuantiteDepuis}
{RecetteId, IngredientId, Ordre} → {Etape}
{RecetteId, IngredientId, Ordre} → {EtapeDepuis}

Avec en plus la mise en oeuvre d’une table ETAPE_HISTORIQUE :

{RecetteId, IngredientId, Ordre, EtapeDurantDeb, EtapeDurantFin, Etape}

Ayant pour clés :

{RecetteId, IngredientId, Ordre, EtapeDurantDeb}
{RecetteId, IngredientId, Ordre, EtapeDurantFin}

En conséquence, la modélisation est très différente. Quelle option retient-on ?

Par ailleurs, les tables RECETTE_HISTORIQUE et QUANTITE_HISTORIQUE que vous proposez ne sont pas conformes. Prenons par exemple le cas de la table RECETTE_HISTORIQUE :

— Il manque la clé candidate {RecetteId, IngredientId, Ordre, RecetteDurantFin}
— L’attribut EtapeId ne faisant partie d’aucune clé, sa présence est illégale (ceci vaut pour ConteneurId, XId, YId).

Les mêmes remarques valent bien sûr pour la table QUANTITE_HISTORIQUE.


It’s a long way...

[Vilukariok]

Bonjour fsmrel,

Dans mon précédent message je voulais aborder le fait que ces nouveaux paramètres sont des paramètres clés. Ce qui correspond à votre "Option 1"

Option 1. Soit l’étape joue le même rôle « clé » que le nom de la recette et l’ingrédient, auquel cas, dans la suite logique des choses on a les dépendances fonctionnelles suivantes :

{RecetteId, IngredientId, EtapeId} → {RecetteDepuis}
{RecetteId, IngredientId, EtapeId} → {Quantite}
{RecetteId, IngredientId, EtapeId} → {QuantiteDepuis} *

*L'ordre est bien un paramètre à historiser comme la quantité.

Ce ne sont donc pas des valeurs à historiser.
C'est pourquoi il est important de distinguer "paramètres clés" et "paramètres non clés" dans mes applications.

Merci pour toutes vos réponses, vous m'avez bien aidé et aiguillé dans la bonne direction.
L'historisation est un système très efficace dont je vais me faire un plaisir de mettre en place dans toutes mes futures applications.
Merci

[Vilukariok]

Re bonjour,

J'ai une petite remarque sur l'historisation général:

Pour l'exemple, je me permet de reprendre votre premier MCD:



Une fois un tel système mis place, y a-t-il une méthode spécifique à faire pour historiser la table "INGREDIENT" qui elle-même permet l'historisation de "RECETTE"?

Je m'explique:
Imaginons par la suite qu'il y ait des centaines d’ingrédients inutilisés par la table active "RECETTE". Je souhaiterai historiser ces ingrédients pour alléger ma table. Il faut donc faire un historique analogue à la table "RECETTE" pour la table "INGREDIENT".

Or dans cette table, IngredientId est utilisé en clés étrangères pour l'historisation de "RECETTE". Donc je ne peux pas supprimer de ligne de "INGREDIENT"...

[fsmrel]

Bonsoir Vilukariok,

Votre « cuisine » est décidément bien raffinée, sinon compliquée...

Il y a évidemment une table INGREDIENT_HISTORIQUE à mettre en œuvre.

Maintenant, en supposant que fonctionnellement les trois tables RECETTE_HISTORIQUE, QUANTITE_HISTORIQUE et ORDRE_INSERTION_HISTORIQUE ne doivent faire référence qu’à des ingrédients non historisés, elles sont à doubler par trois tables permettant d’héberger les données qui doivent en être évacuées lors de l’historisation des ingrédients. Reste à vérifier qu’on est toujours dans les clous des Nine requirements...

[Vilukariok]

Diantre !
Vous voulez dire que je dois recréer autant de nouvelles table que de tables (belle répétition) utilisées pour l'historisation.

Dans ce style:

[fsmrel]

Bonsoir Vilukariok,


Je ne sais plus très bien où nous en sommes dans cette affaire d’historisation des recettes et il y a de quoi faire tourner la mayonnaise...

Donc back to basis, remettons les choses à plat. Reprenons l’exemple simple donné par Date, Darwen et Lorentzos dans Temporal Data and The Relational Model.

Hors historisation, on a deux tables, celle des fournisseurs sous contrat et celle des livraisons de pièces, respectivement F, et FP (j'ai francisé les noms des tables et des attributs, et je remplacerai les périodes par des dates de début et de fin) :

F (Four_No, Four_Nom, Statut, Ville)
FP (Four_No, Piece_No)

Supposons que les trois attributs Four_Nom, Statut, Ville de la table F fassent l’objet d’une historisation, on aura en conséquence trois tables supplémentaires :

F_Four_Nom_Histo (Four_No, Four_Nom_Durant_Deb, Four_Nom_Durant_Fin)
F_Statut_Histo (Four_No, Statut_Durant_Deb, Statut_Durant_Fin)
F_Ville_Histo (Four_No, Ville_Durant_Deb, Ville_Durant_Fin)

En partant du principe que, à l’image des recettes, les fournisseurs peuvent être eux aussi historisés (disparaître provisoirement ou définitivement de la table F), on aura en plus une table F_Histo pour rappeler durant quelles périodes ils furent sous contrat :

F_Histo (Four_No, F_Durant_Deb, F_Durant_Fin)

Et la structure de la table F évolue en conséquence, chaque attribut sujet à historisation étant accompagné de la date depuis laquelle sa valeur a cours :

F (Four_No, F_Depuis, Four_Nom, Four_Nom_Depuis, Statut, Statut_Depuis, Ville, Ville_Depuis)

Les tables d’historisation (c'est-à-dire F_Histo, F_Four_Nom_Histo, F_Statut_Histo, F_Ville_Histo) ne sont liées à aucune autre table par contrainte d'intégrité référentielle, mais en contrepartie, eu égard aux Nine requirements déjà mentionnés, on devra mettre en place des contraintes pour faire respecter ces requirements. Prenons par exemple le cas du statut :

Requirement R3 : Si le fournisseur Sx est sous contrat au jour j, il doit aussi avoir un statut ce jour-là.

Requirement R6 : Si le fournisseur Sx a un certain statut au jour j, il doit aussi être sous contrat ce jour-là.

Pour sa part, la table FP est une table associative (elle met en relation les fournisseurs et les types de pièces). Dans le cadre de l’historisation, sa structure évolue à l’instar de celle de la table F :

FP (Four_No, Piece_No, FP_Depuis)

Et elle donne naissance à la table d’historisation :

FP_Histo (Four_No, Piece_No, FP_Durant_Deb, FP_Durant_Fin)

La table FP est liée à la table F par intégrité référentielle. En revanche, tout comme la table F_Histo, la table FP_Histo n’est pas liée par ce genre d’intégrité, mais en contrepartie, le Requirement R9 doit être respecté :

Requirement R9 : Si le fournisseur Sx a fourni (ou peut fournir) le produit Py au jour j, il doit aussi être sous contrat ce jour-là.

Pour résumer et rester dans le cadre général fixé par Date, Darwen et Lorentzos :

Chaque table telle que F, touchée par l’historisation est doublée d’une table telle que F_Histo, dans laquelle on note la période pendant laquelle fut sous contrat chaque fournisseur, à chaque fois qu'il a été supprimé de la table. Le principe vaut pour la table FP.

Le n-uplet d’attributs composant la clé de la table F (en l'occurrence le singleton {Four_No}) est accompagné d’un attribut de type date (F_Depuis), permettant de savoir depuis quand chaque contrat est actif. Le principe vaut pour la table FP (en l'occurrence la paire {Four_No, Piece_No}, accompagnée de l'attribut FP_Depuis).

Chaque attribut candidat à l’historisation tel que Statut, est doublé d’un attribut tel que Statut_Depuis et donne lieu à une table d’historisation telle que F_Statut_Histo.

Les tables d’historisation ne sont pas concernées par l’intégrité référentielle qui est remplacée par des contraintes chargées de faire respecter les Requirements (en l’occurrence R3, R6, R9).