Historisation
Historiser, c'est garder les valeurs passées d'une information qui change, comme un prix ou une affectation. On le fait dès qu'une règle de gestion demande de retrouver la situation à une date donnée.
- historique
- date
- évolution
- prix
- affectation
- temporel
Syntaxe
Valeur écrasée : PRODUIT (ref_produit, prix) → l'ancien prix est perduEntité datée : PRODUIT (0,n) ── AVOIR ── (1,1) TARIF (date_debut, prix) (TARIF identifié relativement au produit)Lien daté : SALARIE ──┐ SERVICE ──┼── AFFECTER (date_fin) DATE ──┘ (DATE : date_debut)Exemple
Règle : « On doit savoir dans quel service travaillaitun salarié à n'importe quelle date. »SALARIE (1,n) ──┐SERVICE (0,n) ──┼── AFFECTER (date_fin)DATE (0,n) ──┘ DATE a pour identifiant date_debutOccurrences de AFFECTER : (S12, Compta, 2024-01-01, 2025-08-31) (S12, Achats, 2025-09-01, —) ← affectation en coursMLD : affecter(num_salarie, code_service, date_debut, date_fin) clé primaire = (num_salarie, code_service, date_debut)À retenir
- Le prix d'un produit s'historise avec une entité TARIF identifiée relativement au produit, de clé (ref_produit, date_debut) ; le prix en vigueur est celui dont la date de début est la plus récente.
- Au MLD, l'entité DATE réduite à son identifiant ne devient généralement pas une table : date_debut entre directement dans la clé de la table de liaison.
- Quand une valeur doit rester figée au moment du fait, recopiez-la : le prix_vente porté par CONTENIR protège les anciennes commandes d'un changement de tarif.
- Piège : garder un simple attribut prix dans PRODUIT et l'écraser à chaque hausse. Toutes les factures recalculées ensuite deviennent fausses, sans que rien ne permette de le détecter.
- N'historisez que ce qu'une règle de gestion exige : chaque historique oblige ensuite à filtrer sur une période dans toutes les requêtes.
Voir aussi
- Association porteuse d'attributsUne association peut porter des attributs qui décrivent le lien lui-même, comme la quantité d'un produit dans une commande. On les y place quand ils dépendent de toutes les entités reliées.
- Identifiant relatif (entité faible)Une entité faible n'est identifiable qu'à l'intérieur d'une autre : la chambre 12 n'est unique que dans son hôtel. Son identifiant combine son numéro local et celui de l'entité dont elle dépend.
- Association ternaireUne association ternaire relie exactement trois entités ; au-delà, on parle d'association n-aire. Elle se justifie seulement quand le fait n'a de sens qu'avec les trois entités à la fois.
- Règles de gestionLes règles de gestion sont les phrases du métier qui fixent ce que le modèle autorise : « une commande concerne un seul client ». Chaque cardinalité doit pouvoir être justifiée par l'une d'elles.