Garder l'historique dans le modèle entité association

Bonsoir !

J'ai du mal à modéliser une situation dans le modèle entité association. En fait, mon club estudiantin permet à ses membres de rejoindre une structure (et d'en être les responsables) et de rejoindre des projets (et d'en être les responsables également).

Le souci c'est que chaque année, les membres peuvent rejoindre des structures et des projets différents. J'ai du mal à bien modéliser pour garder l'historique en respectant les règles de l'entité association. Je sais qu'une première solution serait de créer une entité calendrier mais comme le modèle refuse de représenter deux fois la même entité, je vais devoir la lier avec l'ensemble des association qui nécessitent la conservation d'un historique ? Ca encombre trop le modèle.

Voici un exemple :
Pièce jointe 652536

J'attends vos suggestions avec impatience ! Merci d'avance et passez une excellente soirée/journée :D

Bonsoir,

Prenons le cas de l’historisation des structures.

Dans le MCD ci-dessous, l’éticien e1 est membre de la structure s1 depuis la date d1 (attribut MembreDepuis).
Il a été membre de s1, etc. durant la période {EtreMembreDebut, EtreMembreFin}.
 

https://www.fsmwarden.com/developpez...eticiens)2.png

 


Du fait de l’utilisation relative 1,1(R), l’identifiant de l’entité-type EtreMembre est composé de la paire d’attributs {EticienId, StructureId}.
De la même façon, l’identifiant de l’entité-type EtreMembreHisto est composée du quadruplet {EticienId, StructureId, EtreMembreDebut, EtreMembreFin}.

Pour compléter avec les responsables :
 

https://www.fsmwarden.com/developpez...eticiens)3.png

 

L’identifiant de l’entité-type EtreResponsableHisto est composé du triplet {EticienId, ,EtreResponsableDebut, EtreResponsableFin}. Cette entité-type n’est pas identifiée relativement à l’entité-type Structure, l’attribut StructureId ne fait donc pas partie de EtreResponsableHisto.

Sachez que la norme SQL a automatisé l'historisation des données à l'aide du principe des "tables temporelles" qui permet de conserver le versionnement des lignes des tables temporalisées et de naviguer dans le temps.

Tout cela est décrit dans l'article suivant :
https://blog.developpez.com/sqlpro/p...r-presentation
Avec des exemples de mise en place de cet outil pour MS SQL Server.

À ce jours, les seuls SGBDR conformes à la norme SQL sur ce point sont IBM DB2 et Microsoft SQL Server (version Linux et Windows).

A +

Merci beaucoup pour vos réponses, j'y vois tout de suite plus clair ! Passez une excellente journée et merci encore :D

Bonjour,

L'éthicien je vois de quoi il s'agit, l'esthéticien également, le petit chien aussi, mais l'éticien, c'est quoi ?
Je n'ai trouvé ce terme dans aucun de mes dictionnaires habituels (CNRTL, Larousse et Robert).

Bonjour François

Citation:

---

Envoyé par fsmrel

De la même façon, l’identifiant de l’entité-type EtreMembreHisto est composée du quadruplet {EticienId, StructureId, EtreMembreDebut, EtreMembreFin}.

---

Ce quator n'est pas irreductible : vu qu'on ne peut pas être membre sur deux périodes chevauchantes, le trio {EticienId, StructureId, EtreMembreDebut} suffit comme identifiant ;)

Ave,
 

Citation:

---

Envoyé par escartefigue

Ce quator n'est pas irréductible : vu qu'on ne peut pas être membre sur deux périodes chevauchantes, le trio {EticienId, StructureId, EtreMembreDebut} suffit comme identifiant ;)

---

Exact, j’avais l’intention de modifier en ce sens, puis je suis passé aux autres discussions en attente...

Cela dit, pour des raisons évidentes de symétrie l’attribut EtreMembreFin peut réclamer être clé candidate au même titre que l’attribut EtreMembreDebut. En passant à SQL :
 
Table EtreMembre :
 

Code:

---

1 2 3 4 5 6 7

CREATE TABLE EtreMembre ( EticienId INT , StructureId SMALLINT , MembreDepuis DATE NOT NULL , CONSTRAINT EtreMembre_PK PRIMARY KEY(EticienId, StructureId) , CONSTRAINT EtreMembre_Eticien_FK FOREIGN KEY(EticienId) REFERENCES Eticien(EticienId) , CONSTRAINT EtreMembre_Structure_FK FOREIGN KEY(StructureId) REFERENCES Structure(StructureId));

---

 
Table EtreMembreHisto :
 

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE EtreMembreHisto ( EticienId INT , StructureId SMALLINT , EtreMembreDebut DATE , EtreMembreFin DATE , CONSTRAINT EtreMembreHisto_PK PRIMARY KEY(EticienId, StructureId, EtreMembreDebut) , CONSTRAINT EtreMembreHisto_AK UNIQUE (EticienId, StructureId, EtreMembreFin) , CONSTRAINT EtreMembreHisto_EtreMembre_FK FOREIGN KEY(EticienId, StructureId) REFERENCES EtreMembre(EticienId, StructureId) , CONSTRAINT EtreMembreHisto_FinSupDebut CHECK (EtreMembreFin >= EtreMembreDebut));

---

 
A noter la contrainte EtreMembreHisto_FinSupDebut, qui veut que la date de fin soit ≥ à la date de fin. :!:

Mais si on rentre dans le cycle des contraintes : non chevauchement des dates par des lignes distinctes au sein d’une même table, antériorité des dates de la table EtreMembreHisto par rapport à la date MembreDepuis portée par la table EtreMembre, etc., il reste du boulot...
Je développe ça au paragraphe 6 (Sixième forme normale) de mon article Bases de données relationnelles et normalisation, basé sur la référence Time and Relational Theory de Date, Darwen et Lorentzos.
 

https://www.fsmwarden.com/developpez...theory(50).png

 
Y a des triggers en perspective...
Si encore on disposait de l’instruction CREATE ASSERTION définie dans la norme SQL, ça serait beaucoup plus confortable, car le codage des triggers diffère d’un SGBD à l’autre. Par exemple, pour garantir l’antériorité des dates de la table EtreMembreHisto par rapport à la date MembreDepuis portée par la table EtreMembre :
 

Code:

---

1 2 3

CREATE ASSERTION Regle_01 CHECK (NOT EXISTS (SELECT * FROM EtreMembre AS x JOIN EtreMembreHisto AS y WHERE x.MembreDepuis <= y.EtreMembreFin)) ;

---

Au passage, je rappelle le principe de l’information (Information Principle) défini par Codd, père du Modèle Relationnel de Données :

The entire information content of the database at any given time is represented in one and only one way: namely, as explicit values in attribute position in tuples in relations.

Comme le rappelle Chris Date (page 63 de l’ouvrage cité), la simplicité inhérente au Modèle Relationnel de Données est une conséquence directe de ce principe. Codd a régulièrement rappelé qu’il s’agit du principe fondamental sur lequel repose le Modèle Relationnel de Données.

Quant à elle, avec ses colonnes cachées (hidden columns) la norme SQL viole le principe de l’information et se démarque de la théorie relationnelle, c’est un divorce.

Citation:

---

Envoyé par fsmrel

Exact, j’avais l’intention de modifier en ce sens, puis je suis passé aux autres discussions en attente...

Cela dit, pour des raisons évidentes de symétrie l’attribut EtreMembreFin peut réclamer être clé candidate au même titre que l’attribut EtreMembreDebut. En passant à SQL :

---

Tout à fait, même si la date de début semble plus naturelle, la date de fin (bien évidemment accompagnée de EticienId et StructureId), peut également composer l'identifiant.

Cela étant dit, je ne sais toujours pas ce qu'est un "Eticien" :weird:

Désolé pour le retard et merci à tous pour vos réponses :D

Citation:

---

Envoyé par escartefigue

Bonjour,

L'éthicien je vois de quoi il s'agit, l'esthéticien également, le petit chien aussi, mais l'éticien, c'est quoi ?
Je n'ai trouvé ce terme dans aucun de mes dictionnaires habituels (CNRTL, Larousse et Robert).

---

Un "éticien" n'est autre qu'un membre du club étudiant ETIC (que je cherche à modéliser). Vous ne risquez pas de trouver ce mot dans le dictionnaire :P