Bonsoir,
Envoyé par
Richard_35
Désolé, je ne connais pas Maurice Nivat
Selon Jacques Arsac (Les machines à penser) Maurice Nivat était l’un des meilleurs spécialistes mondiaux en informatique théorique il y a vingt ans. Cette formule figure dans le rapport qu’il fit au premier ministre Pierre Maurois.
Envoyé par
bergie
Ce qu'il nous faudrait serait une contrainte d'antiréflexivité
A ce sujet, au lieu de coder :
CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x <> Id_Conjoint_y)
on préfèrera coder :
CONSTRAINT MARIAGE_CK1 CHECK (Id_Conjoint_x < Id_Conjoint_y)
Sinon, on pourrait insérer des triplets fautifs :
1 2
| INSERT INTO MARIAGE VALUES (1, 2, 'd01') ;
INSERT INTO MARIAGE VALUES (2, 1, 'd02') ; |
Concernant la contrainte de monogamie, rien n’empêche de l’enfreindre. Par exemple, 2 épouse 1 à d01 et 3 le même jour :
1 2
| INSERT INTO MARIAGE VALUES (1, 2, 'd01') ;
INSERT INTO MARIAGE VALUES (2, 3, 'd01') ; |
Envoyé par
Richard_35
dans la monogamie, nous admettrons qu'une nouvelle date de mariage implique qu'il y a eu divorce précédemment.
Mais pas pour la polygamie car, des mariages successifs à différentes dates, sans divorce(s) précédent(s), est possible.
Qu’il s’agisse de divorce, d’annulation ou de décès, la monogamie impose la prise en compte d’une date de fin, car on ne peut inventer celle-ci. En relationnel, on met en oeuvre le type INTERVAL_DATE, accompagné de l’opérateur de sélection :
INTERVAL_DATE ( [deb : fin] )
deb et fin étant des expressions de type DATE.
Par ailleurs je ne vois pas en quoi on pourrait se dispenser de des intervalles de dates dans le cas de la polygamie. Autrement dit, on en revient à la séparations des données actives :
x est marié avec y depuis telle date
et des données historiques :
x a été marié avec y durant l’intervalle [di : dj].
Exemple :
1 2 3 4 5 6 7 8 9 10 11 12
| PERSONNE {PersonneId, PersonneNom, PersonneSexe, ...}
KEY {PersonneId}
ÊTRE_ACTUELLEMENT_MARIÉ {PersonneId1, PersonneId2, Depuis}
KEY {PersonneId1, PersonneId2}
FOREIGN KEY {PersonneId1} REFERENCES PERSONNE {PersonneId}
FOREIGN KEY {PersonneId2} REFERENCES PERSONNE {PersonneId}
AVOIR_ÉTÉ_MARIÉ {PersonneId1, PersonneId2, Durant}
KEY {PersonneId1, PersonneId2, Durant}
FOREIGN KEY {PersonneId1} REFERENCES PERSONNE {PersonneId}
FOREIGN KEY {PersonneId2} REFERENCES PERSONNE {PersonneId} |
L’attribut Durant est du type INTERVAL_DATE.
S’il est besoin de le rappeler, la date de début d’un intervalle ne peut pas être postérieure à la date de fin de cet intervalle.
Quelques contraintes basiques à vérifier (CONSTRAINT en Tutorial D, ASSERTION en SQL ou TRIGGER à défaut), mais hors de portée des MCD merisiens :
(C1) Si Titi et Lili sont mariés depuis la date dx (variable ÊTRE_ACTUELLEMENT_MARIÉ), Titi et Lili ont déjà pu être mariés (à l’instar du couple Burton/Taylor), mais à condition que ce fut durant une période antérieure à dx (variable AVOIR_ÉTÉ_MARIÉ).
=>
(C2) Si Titi et Lili sont mariés depuis la date dy (variable ÊTRE_ACTUELLEMENT_MARIÉ), l'historique (variable AVOIR_ÉTÉ_MARIÉ) ne peut pas faire mention du fait qu'ils ont été mariés dans l'intervalle [dx : dy-1] (En effet, ils sont alors mariés depuis la date dx).
(C3) Pour chaque paire de conjoints, chaque date de fin de l’attribut Durant de la variable AVOIR_ÉTÉ_MARIÉ doit être antérieure à chaque date de mariage en cours (attribut Depuis de la variable ÊTRE_ACTUELLEMENT_MARIÉ).
(C4) Pour chaque paire de conjoints, il ne peut y avoir deux intervalles (attribut Durant) qui se chevauchent.
(C5) Pour chaque paire de conjoints, la date de fin d’un intervalle (attribut Durant) ne peut pas être égale à la date de début - 1 d’un autre intervalle :
Si Titi et Lili ont été mariés de dx à dy et de dy+1 à dz, il n’y a qu’un seul intervalle pour exprimer ce fait, à savoir [dx : dz].
...
Partager