Discussion :

[win_ubuntu]

salut, J' ai établit un MCD pour la gestion d'état civil (actes de naissances, mariages, décès).



je vous demande de me donner vos remarques sur ce MCD. si vous avez des suggestions n'hésiter pas.
j'aimerais ajouter les contraintes suivantes:

1. Les deux personnes participantes à une mariage donnée doivent être de sexe différent.
2. même chose pour la relation parenté: un doit être mère (sexe féminin) et l'autre père doit être masculin.

[escartefigue]

Bonjour,

Concernant le mariage, vous avez ce sujet http://ineumann.developpez.com/tutor...iation-merise/ qui peut vous aider

Concernant le décès, vous pouvez directement inclure la date et le motif de décès au niveau de la personne

Concernant la parenté, la cardinalité 2,2 coté parent vous posera problème en cas d'orphelin (1 ou 2 parents inconnus)
Une alternative : créer 2 associations, une pour le père (0,1) une pour la mère (0,1)

Les contraintes que vous souhaitez ajouter ne sont pas dans l'air du temps , le mariage homosexuel est désormais légal dans de nombreux pays, il en va de même pour l'adoption par des couples homo, cela étant, s'il s'agit d'un exercice pour mettre en œuvre des contraintes, pourquoi pas. Vous pourrez créer un trigger pour le vérifier

[fsmrel]

Bonsoir,

Concernant la parenté, la cardinalité 2,2 coté parent vous posera problème en cas d'orphelin (1 ou 2 parents inconnus)
Une alternative : créer 2 associations, une pour le père (0,1) une pour la mère (0,1)

Exact. Une personne peut être née de parents inconnus. Par ailleurs, si une personne a au moins deux parents, on sera obligé de remonter dans le temps, voire très loin... On va arriver à Adam, mais nom d’une pipe ! qui sont ses parents ?

Concernant le décès, vous pouvez directement inclure la date et le motif de décès au niveau de la personne.

C’est laisser le bonhomme Null s’introduire dans la maison : la mise en oeuvre d’une entité-type DECES est préférable.

J'aimerais ajouter les contraintes suivantes:

1.Les deux personnes participantes à une mariage donnée doivent être de sexe différent.
2.même chose pour la relation parenté: un doit être mère (sexe féminin) et l'autre père doit être masculin.

Il faut donc faire le distinguo entre les hommes et les femmes, c'est-à-dire utiliser la spécialisation pour l’entité-type PERSONNE, avec contrainte d’exclusion (et de totalité : pas de sexe neutre ou autre fantaisie...)





Dans ces conditions, les époux sont forcément de sexe opposé :





La date participe à l’association MARIAGE. En effet, on part de l’hypothèse qu’une personne ne peut pas se marier deux fois le même jour. Les flèches colorées symbolisent chacune une CIF (contrainte d’intégrité fonctionnelle) :

La flèche bleue symbolise la CIF selon laquelle à une date donnée, un homme ne peut épouser qu’une seule femme (HOMME X DATE -> FEMME), tandis que (symétrie oblige...) la flèche rouge symbolise la CIF selon laquelle à une date donnée, une femme ne peut épouser qu’un seul homme (FEMME X DATE -> HOMME).

Il faudra aussi veiller (ça n’est pas pris en compte ci-dessus) à ce que quelqu’un ne se marie pas alors qu’il est déjà marié et que son conjoint est toujours vivant, ou qu’il n’y a pas eu de divorce de prononcé.


Ci-dessous, l’entité-type A_POUR_PERE signifie qu’une personne peut avoir au plus un père et qu’elle peut ne pas en avoir (association A_P_PERE). Un homme peut avoir plusieurs enfants, notamment hors mariage (association A_P_HOMME).

L’entité-type A_POUR_MERE signifie qu’une personne peut avoir au plus une mère et qu’elle peut ne pas en avoir (association A_P_MERE). Une femme peut avoir plusieurs enfants, notamment hors mariage (association A_P_FEMME).





La mise entre parenthèses des cardinalités 1,1 symbolise l’utilisation de l’identification relative (convention PowerAMC, reprise du reste par JMerise).


Version DB-MAIN :





Script SQL

CREATE TABLE PERSONNE 
(
     personne_id                INT             NOT NULL,
     personne_nom               VARCHAR(32)     NOT NULL,
     personne_prenom            VARCHAR(32)     NOT NULL,
     personne_date_naissance    DATE            NOT NULL,
     personne_lieu_naissance    VARCHAR(32)     NOT NULL,
     CONSTRAINT PERSONNE_PK PRIMARY KEY (personne_id)
) ;

CREATE TABLE HOMME 
(
     personne_id                INT             NOT NULL,
     CONSTRAINT HOMME_PK PRIMARY KEY (personne_id),
     CONSTRAINT HOMME_PERSONNE_FK FOREIGN KEY (personne_id)
     REFERENCES PERSONNE (personne_id) ON DELETE CASCADE
) ;

CREATE TABLE FEMME (
     personne_id                INT             NOT NULL,
     CONSTRAINT FEMME_PK PRIMARY KEY (personne_id),
     CONSTRAINT FEMME_PERSONNE_FK FOREIGN KEY (personne_id)
     REFERENCES PERSONNE (personne_id) ON DELETE CASCADE
) ;

CREATE TABLE A_POUR_PERE 
(
     personne_id                INT             NOT NULL,
     papa_id                    INT             NOT NULL,
     CONSTRAINT A_POUR_PERE_PK PRIMARY KEY (personne_id),
     CONSTRAINT A_POUR_PERE_PERSONNE_FK FOREIGN KEY (personne_id)
     REFERENCES PERSONNE (personne_id) ON DELETE CASCADE,
     CONSTRAINT A_POUR_PERE_HOMME_FK FOREIGN KEY (papa_id)     
     REFERENCES HOMME (personne_id)
) ;

CREATE TABLE A_POUR_MERE 
(
     personne_id                INT             NOT NULL,
     maman_id                   INT             NOT NULL,
     CONSTRAINT A_POUR_MERE_PK PRIMARY KEY (personne_id),
     CONSTRAINT A_POUR_MERE_PERSONNE_FK FOREIGN KEY (personne_id)
     REFERENCES PERSONNE (personne_id) ON DELETE CASCADE,
     CONSTRAINT A_POUR_MERE_FEMME_FK FOREIGN KEY (maman_id)     
     REFERENCES FEMME (personne_id)
) ;

CREATE TABLE MARIAGE 
(
     epoux_id                   INT             NOT NULL,
     epouse_id                  INT             NOT NULL,
     mariage_date               DATE            NOT NULL,
     mariage_lieu               VARCHAR(32)     NOT NULL,
     CONSTRAINT MARIAGE_PK PRIMARY KEY (epoux_id, mariage_date),
     CONSTRAINT MARIAGE_AK UNIQUE (epouse_id, mariage_date),
     CONSTRAINT MARIAGE_HOMME_FK FOREIGN KEY (epoux_id)   
     REFERENCES HOMME (personne_id),
     CONSTRAINT MARIAGE_FEMME_FK FOREIGN KEY (epouse_id)   
     REFERENCES FEMME (personne_id)
);

CREATE TABLE DECES 
(
     personne_id                INT             NOT NULL,
     deces_date                 DATE            NOT NULL,
     deces_cause                VARCHAR(32)     NOT NULL,
     CONSTRAINT DECES_PK PRIMARY KEY (personne_id),
     CONSTRAINT DECES_PERSONNE_FK FOREIGN KEY (personne_id)
     REFERENCES PERSONNE (personne_id)
);

La contrainte d’exclusion homme/femme n’est pas prise en compte dans le script SQL : elles devra faire l’objet d’une assertion (instruction CREATE ASSERTION) ou de triggers si le SGBD ne permet pas de coder une assertion.

_______________________________________________________

[escartefigue]

C’est laisser le bonhomme Null s’introduire dans la maison : la mise en oeuvre d’une entité-type DECES est préférable.

Certes, ce n'est pas très puriste, mais j'ai tendance à procéder ainsi quand l'entité-type en question ne possède que très peu d'attributs, et qu'on est dans le cas d'une card maxi 1 bien sur.
Cela étant, si l'on conserve l'entité type, alors il faut aussi "externaliser" la cause du décès
Le modèle devenant alors comme suit :

[win_ubuntu]

Merci infiniment pour les réponses.

Ci-dessous, l’entité-type A_POUR_PERE signifie qu’une personne peut avoir au plus un père et qu’elle peut ne pas en avoir (association A_P_PERE). Un homme peut avoir plusieurs enfants, notamment hors mariage (association A_P_HOMME).

Je ne comprend pas vraiment l'utilité de l'entité type A_POUR_PERE (et A_POUR_MERE ). où est le problème si on lie directement l'entité personne avec l'entité Home.

[fsmrel]

Bonsoir,

Je ne comprend pas vraiment l'utilité de l'entité type A_POUR_PERE (et A_POUR_MERE). où est le problème si on lie directement l'entité personne avec l'entité Home.

Certaines personnes peuvent ne pas avoir de père. Dans ces conditions, la base de données pourrait être polluée par le bonhomme Null, qui est hors-la-loi, interdit de séjour au pays des relations (Relationland), et ça fait plus de 20 ans que je me bats pour lui en interdire l’accès (pour les motifs, voyez plus loin, « A propos du bonhomme Null »).

Si on se passe du bouclier A_POUR_PERE, Null s’introduit (Albert n’a pas de papa) :

PERSONNE 

personne_id    personne_nom    papa_id    ...
p2             Albert          NULL       ...
p14            Raoul           p2         ...

Si on se sert du bouclier A_POUR_PERE, Null ne passe pas :

PERSONNE 

personne_id    personne_nom    ...
p2             Albert          ...
p14            Raoul           ...


A_POUR_PERE

personne_id    papa_id
p14            p2 

si l'on conserve l'entité type, alors il faut aussi "externaliser" la cause du décès

Il est vrai qu’il est préférable de mettre en œuvre une nomenclature des causes de décès (votre entité-type MOTIF), mais ceci est valable dans tous les cas de figure. Si on n’externalise pas le décès, c'est-à-dire si la date de décès fait l’objet d’un attribut de l’entité-type PERSONNE, en toute logique il n’en demeure pas moins qu’on devrait avoir la représentation suivante :





Dans tous les cas, au niveau SQL, Il faudra contrôler que lorsque la date de décès est valorisée, l’attribut participant à la clé étrangère référençant MOTIF l’est aussi (et, symétriquement, que si cet attribut est valorisé, alors la date de décès l’est aussi).

J’observe que dans votre diagramme, vous avez défini une entité-type DATE pour la date de décès : on ne procède ainsi que lorsque la date est partie prenante dans l’identification de l’association, ce qui n’est pas le cas ici (on ne meurt qu’une fois...), exit donc cette entité-type.


Pour l’anecdote, du point de vue sémantique, on pourrait modéliser les décès ainsi (spécialisation/héritage) :

[PERSONNE]<==================[PERSONNE_DECEDEE]

A propos du bonhomme Null


Je rappelle que Null est l’ennemi des base de données, et il ne faut pas raisonner sur un cas particulier comme celui du décès.

Plus généralement, observons que Null intervient dans le cadre d’une logique ternaire, mais il arrive que SQL l’oublie (par exemple EXISTS est traité selon la logique binaire, et peut réserver des surprises, comme je le rappelle entre autres ici.

Le biconditionnel p SI ET SEULEMENT SI p n’est plus une tautologie, l’algèbre relationnelle ne peut plus s’appuyer en aveugle sur la commutativité, l’associativité et consorts.

Null inhibe donc les optimiseurs (voyez aussi le cas de la fermeture transitive).

La jointure peu être mise en échec. Même chose pour le théorème de Heath.

La question qui sème le doute : « Null = Null » est-il vrai, faux, inconnu ?

Quelles sont les 36 significations de Null, le Fregoli ? Les gens de l’ANSI (ou de l’ISO, je ne sais plus) s’étaient doctement penché sur ce sujet il y a une trentaine d’années...

En tout cas, les gens qui font la norme SQL se sont pris les pieds dans le tapis :

« The data type boolean comprises the distinct truth values True and False. Unless prohibited by a NOT NULL constraint, the boolean data type also supports the truth value Unknown as the null value. This specification does not make a distinction between the null value of the boolean data type and the truth value Unknown that is the result of an SQL <predicate>, <search condition>, or <boolean value expression>; they may be used interchangeably to mean exactly the same thing. »

Vous avez bien lu ? Selon la norme, il revient au même de dire : « Je ne sais pas » et « Je sais que l’information est absente » ! Grave à ce niveau !

Je ne cite pas tous les risques que fait courir Null, je vous renvoie aux ouvrages de C.J. Date. Bref, NULL c’est de la dynamite. Les vieux routiers de SQL savent la manipuler, mais tout le monde n’est pas artificier. En tant que brigadier de l’armée du Relationland, je ne peux que m’opposer à sa tentative d’intrusion...

[escartefigue]

J’observe que dans votre diagramme, vous avez défini une entité-type DATE pour la date de décès : on ne procède ainsi que lorsque la date est partie prenante dans l’identification de l’association, ce qui n’est pas le cas ici (on ne meurt qu’une fois...), exit donc cette entité-type.

Tout à fait, quoi-que il existe des cas (très rares je vous l'accorde), où des personnes ont été déclarées à tort décédées et elles ont toutes les peines du monde à "revivre" administrativement parlant
Un cas a fait parler de lui récemment où père et fils, portant le même prénom, ont été inversés par l'administration au grand dam du "non mort" , qui ne pouvait plus toucher ni retraite, ni autre prestation sociale.
Cette croustillante anecdote ne change rien à l'affaire, exit la date donc

Je rappelle que Null est l’ennemi des base de données, et il ne faut pas raisonner sur un cas particulier comme celui du décès.

D'accord, mais nous sommes ici dans un cas où nous aurons au plus 2 ou 3 valeurs, et où donc, aucun index ne sera de toutes façons éligible
Quand à imaginer du delete cascade sur un motif de décès
Cela étant, un test d'existence ne peut pas être exclu, et j'avoue avoir négligé cet aspect, une petite relecture des fondamentaux est toujours utile

Plus généralement, observons que Null intervient dans le cadre d’une logique ternaire, mais il arrive que SQL l’oublie (par exemple EXISTS est traité selon la logique binaire, et peut réserver des surprises, comme je le rappelle entre autres ici.

Le choix de ce post n'est probablement pas innocent, on y retrouve un client habitué et irréductible, dont les propos pour le moins artistiques, sont parfois amusants parfois beaucoup moins

[win_ubuntu]

Certaines personnes peuvent ne pas avoir de père. Dans ces conditions, la base de données pourrait être polluée par le bonhomme Null, qui est hors-la-loi, interdit de séjour au pays des relations (Relationland), et ça fait plus de 20 ans que je me bats pour lui en interdire l’accès (pour les motifs, voyez plus loin, « A propos du bonhomme Null »).

à noter que le débarrassage du null n'est pas gratuit:

1. on augmente la taille de la base de données (l'ajout de plusieurs tables, etc).
2. on complique un peu les requêtes SQL (jointures, requêtes imbriqués).

[fsmrel]

Bonsoir,

il existe des cas (très rares je vous l'accorde), où des personnes ont été déclarées à tort décédées et elles ont toutes les peines du monde à "revivre" administrativement parlant

Exact. Et que dire des épreuve subies par les femmes des marins disparus en mer ? Un marin disparu en mer ne peut même pas être pris en compte dans le MCD présent, il est réputé être vivant, même 50 ans après... Sa femme n’aura jamais eu droit à quoi que ce soit, rien, nib, queue d’ale, nada. Ce fut le cas de la d’une amie dont le père était terre-neuvas, disparu dans les brumes de Terre-Neuve, à bord de son doris, et sa maman, même pas veuve donc, a dû de débrouiller toute seule, toute sa vie, sans aucune aide de la part de l’Etat. Une foule de femmes de terre-neuvas ont ainsi vécu dans une extrême précarité, mais qui se souvient ?

Le choix de ce post n'est probablement pas innocent, on y retrouve un client habitué et irréductible, dont les propos pour le moins artistiques, sont parfois amusants parfois beaucoup moins

J’aurais pu faire référence à un autre post, mais celui-ci est très symptomatique. Quant au client en question, disons qu’il a l’art de me les briser menu, fuyons...