Discussion :

[somnambulie]

Bonjour,

Je cherche à produire un MCD représentant l'historisation des attributs d'une entités, mais également des associations entre deux entités.

Exemple fonctionnel

Sans historisation

1 enfant a :
un numéro INSEE, identifiant de l'entité enfant
un nom
un et un seul tuteur, personne adulte représenté au travers d'une entité dont l'identifiant est son NUM_SECU et qui possède un nom

Le MCD suivant me paraît correct :
ENFANT (NUM_INSEE, NOM_ENFANT)
ADULTE (NUM_SECU,NOM_ADULTE)
Il existe une association entre ENFANT et ADULTE dont les cardinalités sont 1,1 du côté enfant et 0,n du côté ADULTE.

Avec historisation
Considérons maintenant qu'un enfant a 1 et 1 seul tuteur à un instant donné, mais que nous souhaitons enregistrer l'historique des tuteurs qu'a eu un enfant, et que par ailleurs, nous souhaitons maintenir l'intégrité référentielle vers ADULTE.

Quel modèle convient ?

Merci par avance.

[Richard_35]

Bonjour Somnambulie,

C'est un débat récurrent toujours passionnant...

ENFANT :
- NUM_INSEE (PK)
- NOM_ENFANT
...

ADULTE :
- NUM_SECU (PK)
- NOM_ADULTE
...

Relation :
ENFANT (1,1)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) ADULTE
cela pourrait être, également :
ENFANT (0,1)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) ADULTE, dans le cas où l'on souhaite saisir des enfants sans, encore, de tuteur désigné.

Effectivement, en modifiant l'entité :
ENFANT :
- NUM_INSEE (PK)
- NOM_ENFANT
- NUM_SECU
...
les relations sont respectées (avec autorisation ou pas de NUM_SECU=Null).

Mais, effectivement, l'historique n'est pas stocké, du moins pas dans l'entité ENFANT. Pour cela, nous pouvons créer une entité :
HISTORIQUE :
- NUM_INSEE (PK)
- NUM_SECU (PK)
- Date_affectation
...

Relation :
ENFANT (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE ;
ADULTE (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE.
Il s'agirait donc de gérer une relation (n,n) habituelle.

L'histoire "se complique" si nous admettons qu'un même adulte peut être tuteur d'un enfant à une date donnée, que l'on désigne un autre tuteur pour l'enfant en question puis, plus tard, que l'on désigne le tuteur initial au même enfant.

Dans ce cas, comme l'indiquais fort justement Fsmrel dans un fil précédent, nous aurions :
HISTORIQUE :
- NUM_INSEE (PK)
- Date_affectation (PK)
- NUM_SECU
...

[somnambulie]

Merci pour votre réponse.

Je pense qu'au niveau physique la table ci-dessous
HISTORIQUE :
- NUM_INSEE (PK)
- Date_affectation (PK)
- NUM_SECU

est correcte.

Mais quel est le MCD associé ?

Les associations
Relation :
ENFANT (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE ;
ADULTE (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE.

Ne me semblent pas correctes puisqu'elles aboutissent à la table Historique
- NUM_INSEE (PK)
- NUM_SECU (PK)
- Date_affectation

[CinePhil]

un numéro INSEE, identifiant de l'entité enfant
dont l'identifiant est son NUM_SECU

Voilà deux exemples de mauvaises clés primaires pour des tables !
Voir l'article de SQLPro sur la définition d'une bonne clé.

Il me semble aussi que le numéro INSEE et le numéro de Sécurité Sociale sont identiques, sauf que le second n'existe qu'à partir du moment ou l'enfant entre dans la vie professionnelle.

Quant au MCD, plutôt que de faire deux associations binaires, autant faire une association ternaire :
Adulte -0,n----Tutorer----0,n- Enfant
Date -0,n------------|

Ce qui donne, en première approche, les tables suivantes :
Adulte (adu_id, adu_num_insee, adu_nom, adu_prenom...)
Enfant (enf_id, enf_num_insee, enf_nom, enf_prenom...)
Tutorer (tut_id_enfant, tut_date, tut_id_adulte)

Le problème est ici que rien n'empêche un enfant d'avoir plus d'un tuteur à une date donnée.
Comme l'a souligné Richard_35, il faut alors sortir l'identifiant du tuteur de la clé primaire :
Tutorer (tut_id_enfant, tut_date_debut, tut_id_adulte)

Par rétro-ingénierie, je pense qu'on a alors en fait ce MCD :
Enfant -0,n----Avoir----(1,1)- Tutorat -(1,1)----Débuter----0,n- Date
Adulte -0,n----Affecter----1,1----|

Traduction en français :
"Un tutorat est défini par un enfant et une date de début et un seul adulte y est affecté en tant que tuteur."
Il me semble que ça répond au besoin non ?

EDIT :
Au passage, comme Adulte et Enfant ont des attributs communs, on peut faire un héritage :
Adulte -(1,1)----Etre----0,1- Personne
Enfant -(1,1)----Etre----0,1--------|

Tables :
Personne (prs_id, prs_nom, prs_prenom, prs_num_insee...)
Adulte (adu_id_personne...)
Enfant (enf_id_personne...)

Ça ne change rien par contre aux MCD précédents définissant les associations entre les adultes et les enfants via le tutorat.

[Richard_35]

Je suis 100% d'accord avec CinePhil, concernant la pertinence des clés : je suis un adepte des clés sans signification (numéro auto, par exemple). Cette erreur a eu des conséquences visibles surprenantes.

Deux exemples :

1°/ Numéro de sécurité sociale :
l'équipe décisionnaire de l'époque a opté pour la structure de la clé suivante :
- sexe ;
- année de naissance ;
- mois de naissance ;
- département de naissance ;
- commune de naissance ;
-n° de séquence pour le quadruplé année de naissance/mois de naissance/département de naissance/commune de naissance ;
- clé de contrôle.

Hors, plusieurs doublons sont possibles, maintenant :
- écart de + de 100 ans ;
- changement de sexe ;
...
Il aurait été plus judicieux d'affecter un n° de sécurité sociale sans signification et de mettre les éléments significatifs dans la fiche de chacun : ces éléments deviennent, alors, des attributs particuliers d'un n°.


2°/ Numéro d'immatriculation des véhicules :
l'équipe décisionnaire de l'époque a opté pour la structure de la clé suivante :
- n° département ;
- 4 chiffres (devenus 3 chiffres) ;
- 2 lettres (devenues 3 lettres).
Contrairement au n° de sécurité sociale, nous nous heurtons à un problème de dépassement de capacité, raison pour laquelle "4 chiffres (devenus 3 chiffres)" et "2 lettres (devenues 3 lettres)", à cause du département.

Maintenant, ce n° se compose de :
- 2 lettres ;
- 3 chiffres ;
- 2 lettres.
==> le département (rajouté pour faire plaisir au public) ne faisant plus partie de la clé d'identification.

Donc, la clé est, maintenant, sans signification et les éléments significatifs figurent dans la fiche de chaque n° : ces éléments deviennent, alors, des attributs particuliers d'un n°.


Ceci, juste pour le fun... car le problème de Somnambulie n'est pas la pertinence des clés : cela peut le devenir, c'est vrai, mais ce n'est pas le problème actuel.


A tout à l'heure... une urgence.

[Richard_35]

Par rétro-ingénierie, je pense qu'on a alors en fait ce MCD :

Code CinePhil :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Enfant -0,n----Avoir----(1,1)- Tutorat -(1,1)----Débuter----0,n- Date
                                  |
Adulte -0,n----Affecter----1,1----|

Pour moi, c'est OK. Sauf que, dans les faits, il me semble qu'il n'y aura pas de table Date uniquement pour "faire plaisir" à la norme...

A mon sens, les relations :

• ENFANT (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE ;
• ADULTE (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE.

sont bonnes, bien que NUM_SECU de HISTORIQUE ne fasse pas partie de la PK.

[CinePhil]

Code CinePhil :
Enfant -0,n----Avoir----(1,1)- Tutorat -(1,1)----Débuter----0,n- Date
|
Adulte -0,n----Affecter----1,1----|

Pour moi, c'est OK. Sauf que, dans les faits, il me semble qu'il n'y aura pas de table Date uniquement pour "faire plaisir" à la norme...

Il n'y a effectivement pas besoin ici de faire une table de dates mais il est d'usage, lorsque la date participe à la clé primaire d'une association, de la représenter en tant qu'entité du MCD. On peut aussi, dans une représentation complète des entités avec leurs attributs, à l'aide d'un logiciel de modélisation, se contenter de mentionner l'attribut tut_date_debut dans le symbole de l'association (la patate merisienne) et de l'affecter à l'identification de l'association.

On aurait alors quelque chose, simplifié, de ce genre :
Enfant -0,n----Avoir----(1,1)- Tutorat(tut_date_debut) -1,1----Affecter----0,n- Adulte

Il m'est arrivé de représenter des cas similaires de cette manière dans ce forum mais je préfère maintenant représenter l'entité Date.

A mon sens, les relations :

• ENFANT (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE ;
• ADULTE (0,n)-----[a pour parent/tuteur]-----[est parent/tuteur de]-----(0,n) HISTORIQUE.

sont bonnes, bien que NUM_SECU de HISTORIQUE ne fasse pas partie de la PK.

Avec tes deux associations, tu as en fait ce schéma :
Enfant -0,n----Associer----0,n- Historique -0,n----Associer----0,n- Adulte

Un historique peut concerner plusieurs enfants et plusieurs adultes ?

[somnambulie]

Par rétro-ingénierie, je pense qu'on a alors en fait ce MCD :
Enfant -0,n----Avoir----(1,1)- Tutorat -(1,1)----Débuter----0,n- Date
Adulte -0,n----Affecter----1,1----|

Traduction en français :
"Un tutorat est défini par un enfant et une date de début et un seul adulte y est affecté en tant que tuteur."
Il me semble que ça répond au besoin non ?

Mais dans ce cas, on aura une table TUTORAT sans clé lors du passage au MPD ?

[CinePhil]

Mais dans ce cas, on aura une table TUTORAT sans clé lors du passage au MPD ?

Non.

Enfant -0,n----Avoir----(1,1)- Tutorat -(1,1)----Débuter----0,n- Date
Adulte -0,n----Affecter----1,1----|

Les cardinalités entre parenthèses représentent une identification relative de l'entité par rapport aux deux autres. La table Tutorat aura donc la structure donnée plus haut pour la table associative Tutorer, puisque je n'ai fait que transformer une association en entité pour qu'elle puisse à son tour être associée à une autre entité :

Tutorer (tut_id_enfant, tut_date_debut, tut_id_adulte)

Tutorat (tut_id_enfant, tut_date_debut, tut_id_adulte)

Il y a le même principe d'identification relative dans l'héritage que j'ai décrit en éditant mon message.

Adulte -(1,1)----Etre----0,1- Personne
Enfant -(1,1)----Etre----0,1--------|

Tables :
Personne (prs_id, prs_nom, prs_prenom, prs_num_insee...)
Adulte (adu_id_personne...)
Enfant (enf_id_personne...)

[Richard_35]

Euh...non.
Si j'ai bien tout compris, CinePhil appelle "TUTORAT" la table "HISTORIQUE" et il a bien raison.

[somnambulie]

Euh...non.
Si j'ai bien tout compris, CinePhil appelle "TUTORAT" la table "HISTORIQUE" et il a bien raison.

Donc j'ai un MCD avec une table sans identifiant ?
Mon commanditaire qui veut du 3NF ne va pas être content !
Et quand je passe au MPD, il n'y a pas de PK, et alors il est possible qu'à une date donnée un enfant ait plusieurs tuteurs ?

[Richard_35]

Donc j'ai un MCD avec une table sans identifiant ?

==> mais non, relis bien :
TUTORAT :
- NUM_INSEE (PK)
- Date_affectation (PK)
- NUM_SECU (FK)
...
==> identifiant unique NUM_INSEE/Date_affectation.


D'autre part :

A mon sens, les relations :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ENFANT (0,n)--[a pour parent/tuteur]--[est parent/tuteur de]--(0,n) TUTORAT ; 
ADULTE (0,n)--[a pour parent/tuteur]--[est parent/tuteur de]--(0,n) TUTORAT.

sont bonnes, bien que NUM_SECU de TUTORAT ne fasse pas partie de la PK.

[somnambulie]

==> mais non, relis bien :
TUTORAT :
- NUM_INSEE (PK)
- Date_affectation (PK)
- NUM_SECU (FK)
...
==> identifiant unique NUM_INSEE/Date_affectation.


D'autre part :

Là je suis perdu, pour moi ça c'est la description la table, et je ne vois pas comment construire le MCD qui aboutit à ce MPD. J'ai dû rater une marche.
Je mets en fichier attaché les MCD et MPD construit à partir de mon interprétation de vos directives... C'est où que je me trompe ?

MCD


MPD généré

[fsmrel]

Bonsoir,


Sur le fond, tout à fait d’accord avec vous CinePhil et Richard_35. Une petite remarque néanmoins :

Vous défendez tous deux la thèse de l’invariance et de l’absence de signification des clés primaires, ce qui est tout à votre honneur, mais la clé de la table Tutorer est-elle bien conforme à ces principes ?

Tutorer (tut_id_enfant, tut_date_debut, tut_id_adulte)

En effet, une date a une signification et peut être rectifiée par l’utilisateur si elle n’est pas la bonne...
Vous me direz qu’il y a epsilon de chances que l’attribut tut_date_debut de la table Tutorer fasse l’objet de modifications tout en servant de référence pour une autre table, aussi c’est par pure forme que je fais ce commentaire (pragmatiquement je choisirai de faire comme vous). D’un point de vue théorique, le MCD devrait néanmoins être le suivant :



D'où le MLD suivant, sans oublier de faire de la paire {EnfantId, DateDeb} une clé candidate au niveau tabulaire :




Autres remarques :

1. La date de fin du tutorat Tx (sauf pour le plus récent) est égale à la date de début - 1 du tutorat Ty qui le suit immédiatement dans le temps, ce qui sous-entend une auto-thêta-jointure pour calculer cette date de fin.
   
2. Le MCD ci-dessus et celui de CinePhil conviennent si les tutorats se suivent sans interruption, mais dans le cas contraire, il faudrait :
   
   • Soit utiliser une solution « cracra » consistant à définir le tuteur paradoxal « Pas de tuteur »,
   • Soit définir une période de tutorat (date début, date de fin), mais attention aux effets secondaires...

[Richard_35]

Bonsoir Fsmrel,

Vous défendez tous deux la thèse de l’invariance et de l’absence de signification des clés primaires, ce qui est tout à votre honneur, mais la clé de la table Tutorer est-elle bien conforme à ces principes ?
Tutorer (tut_id_enfant, tut_date_debut, tut_id_adulte)

==> oui, tu as raison. Dans le post #5, à la fin, je spécifie :

Ceci, juste pour le fun... car le problème de Somnambulie n'est pas la pertinence des clés : cela peut le devenir, c'est vrai, mais ce n'est pas le problème actuel.

Et c'est vrai. Il me semble que nous pourrons aborder cet aspect après la résolution du problème posé par Somnambulie... qui doit avoir du mal à dormir...

D'autre part, c'est à Somnambulie de voir s'il faut gérer des périodes plutôt que des dates simples : les "trous" seront alors considérés par le système comme des périodes sans tuteur, ce qui peut arriver. Mais, c'est vrai qu'il est plus "bordé" de gérer des périodes (début/fin) que des dates.

[somnambulie]

Nous pouvons dire que nous n'avons pas à gérer de trous dans les périodes de tutorat.
Posons également qu'il existe dans la table tutorat une date de fin (DateFin), alimentée lorsqu'un tutorat prend fin.

fsmrel, Je vois dans votre modèle que vous utilisez les cardinalités identifiantes entre Tutorat et Enfant.

Mes questions sont :
Cette représentation est-elle prévue dans MERISE ?
comment fait-on si l'on ne dispose pas d'outil permettant leur mise en oeuvre ?

[fsmrel]

Bonjour,

Un premier lot de réponses.

fsmrel, Je vois dans votre modèle que vous utilisez les cardinalités identifiantes entre Tutorat et Enfant.
Mes questions sont :
Cette représentation est-elle prévue dans MERISE ?

Cette représentation est effectivement prévue dans MERISE. Chaque AGL utilise sa notation. Par exemple, Power AMC enrobe les cardinalités 1,1 de parenthèses. Open ModelSphere souligne la cardinalité 1,1. Win’Design fait suivre la cardinalité 1,1 de la lettre R entre parenthèses, comme dans l’exemple ci-dessous extrait de la FAQ Merise (SALLE est une propriété multivaluée de SITE) :

comment fait-on si l'on ne dispose pas d'outil permettant leur mise en oeuvre ?

Prenons le cas de l’entité-type TUTORAT que j’ai représentée dans mon précédent message. Au niveau du MCD on ajoute une note pour signifier que l’identifiant est relatif ou bien on ajoute un mickey repris des AGL énumérés. Ensuite, on intervient manuellement au niveau du MLD pour que la clé primaire de la table TUTORAT devienne {L, A}, L représentant la liste des attributs de la clé primaire de la table ENFANT (à savoir EnfantId) et A un attribut "technique", un séquenceur de type entier (à savoir HistoRelId).


La suite va arriver.

[CinePhil]

Nous pouvons dire que nous n'avons pas à gérer de trous dans les périodes de tutorat.
Posons également qu'il existe dans la table tutorat une date de fin (DateFin), alimentée lorsqu'un tutorat prend fin.

Autre débat...

fsmrel, Je vois dans votre modèle que vous utilisez les cardinalités identifiantes entre Tutorat et Enfant.

C'est aussi ce que j'ai expliqué dans mes derniers messages avec les cardinalités entre parenthèses.

Cette représentation est-elle prévue dans MERISE ?

Je pense que oui mais il vaut mieux que ce soit fsmrel qui réponde plus sûrement à cette question.

comment fait-on si l'on ne dispose pas d'outil permettant leur mise en oeuvre ?

Vu la qualité graphique de tes MCD et MLD, je pense que ton outil doit être tout à fait capable de le faire. Quel est-il ?

[somnambulie]

Existe-t-il une référence biblio dans laquelle je peux trouver des explications complémentaires sur ces cardinalités identifiantes ?
Je me pose par exemple comme questions :
Quel est l'identifiant de l'entité TUTORAT ?
En quel forme normal aboutissons-nous lorsque l'on exploite cette notion ?

J'utilise Power AMC, mon souci est de créer un schéma indépendant des spécificités d'un outil. A mon sens un MCD devrait être compréhensible par toute personne connaissant la méthode MERISE, sans lui imposer la connaissance d'un outil en particulier. Quel est le terme adéquat pour définir cette notion de cardinalité "identifiante" dans MERISE ?

Mes connaissances de MERISE sont certainement trop anciennes et parcellaires, et je souhaite m'assurer que mon travail est conformes aux règles de l'art.

Merci pour toutes vos réponses qui me confortent dans l'idée qu'il n'existe pas de représentation valide en dehors de l'utilisation de cette notion d'association "identifiante"

[CinePhil]

Existe-t-il une référence biblio dans laquelle je peux trouver des explications complémentaires sur ces cardinalités identifiantes ?

fsmrel vient de donner deux liens dans ce message.

Je me pose par exemple comme questions :
Quel est l'identifiant de l'entité TUTORAT ?

TUTORAT étant identifié relativement à d'autres entités, n'a pas d'identifiant propre. Cependant, la table générée aura bel et bien une clé primaire ! C'est le même principe que les tables associatives : pas d'identifiant dans l'association du MCD mais identifiants générés dans la table.

En quel forme normal aboutissons-nous lorsque l'on exploite cette notion ?

Euh... là je préfère laisser fsmrel répondre...

J'utilise Power AMC, mon souci est de créer un schéma indépendant des spécificités d'un outil. A mon sens un MCD devrait être compréhensible par toute personne connaissant la méthode MERISE, sans lui imposer la connaissance d'un outil en particulier. Quel est le terme adéquat pour définir cette notion de cardinalité "identifiante" dans MERISE ?

Power AMC permet de faire des identifiants relatifs. La preuve, fsmrel le fait dans ses schémas. Comme je ne connaît pas encore cette Rolls de la modélisation, je ne peux pas te donner la méthode pour y parvenir.

Je ne sais pas quel est le vocable exact, s'il existe, dans la méthode Merise telle qu'elle a été écrite par ses auteurs mais j'utilise toujours les termes "identification relative" ou "identifiant relatif".

Mes connaissances de MERISE sont certainement trop anciennes et parcellaires, et je souhaite m'assurer que mon travail est conformes aux règles de l'art.

Avec les réponses de fsmrel encore plus que des miennes, tu peux être tranquille ! C'est l'encyclopédiste de l'algèbre relationnelle et de la modélisation des BDD !