Bonjour
J’arrive un peu tard, j’avais préparé un message, mais pris par d’autres activités j’ai oublié de l’envoyer...
Bref...
Il y a un enchaînement des actions à chercher à mettre en évidence : il faudrait qu’une boisson ne puisse être absorbée qu’à la condition que celle-ci soit présente dans une bouteille qui soit passée par l’étape de remplissage.
De même, une bouteille ne doit pouvoir être remplie qu’avec une boisson passée par le stade de la préparation d’où le diagramme où l’on doit donc essayer de représenter la chronologie imposée pour les actions à réaliser :
[FABRICANT]--0,n-------(PREPARER)-------0,n--[BOISSON] Chronologie
| |
| |
0,n |
| |
| |
(R) |
| |
| |
1,1 |
| |
| |
(REMPLIR) [
| |
| |
0,1 |
| |
| V
[BOUTEILLE]
Le dogme Merise interdit, hélas ! qu’une association soit branchée sur une autre association, c'est-à-dire qu’une triplette pour assurer la chronologie, du genre (PREPARER)—0,n--------(R)--------1,1—(REMPLIR) serait illégale. On passera donc par une vieille astuce vaseuse, vieille comme Merise elle-même, consistant à déguiser l’association PREPARER en entité-type (appelons-la PREPARATION) :
[FABRICANT]--0,n--(R1)----1,1--[PREPARATION]--1,1----(R2)-----0,n--[BOISSON]
|
|
0,n
|
|
(REMPLIR)
|
|
0,1
|
|
[BOUTEILLE]
Ainsi, un remplissage ne peut avoir lieu qu’avec une boisson déjà préparée.
Mais remplir une bouteille est une tâche à réaliser par un fabricant dont c’est le rôle exclusif :
[FABRICANT]--0,n--(R1)----1,1--[PREPARATION]--1,1----(R2)-----0,n--[BOISSON]
|
|
0,n
|
|
[REMPLISSEUR]--0,n---------------(REMPLIR)
|
|
0,1
|
|
[BOUTEILLE]
En conséquence de quoi REMPLIR devient une association ternaire, qui ici n’est pas pertinente et peut provoquer des effets secondaires, donc prudemment on déguisera REMPLIR elle aussi en entité-type (REMPLISSAGE) :
[FABRICANT]--0,n--(R1)----1,1--[PREPARATION]--1,1----(R2)-----0,n--[BOISSON]
|
|
0,n
|
|
(R3)
|
|
1,1
|
|
[REMPLISSEUR]--0,n--(R4)--1,1--[REMPLISSAGE]
|
|
1,1
|
(R5)
|
|
0,1
|
|
[BOUTEILLE]
A son tour, l’absorption d’une boisson ne peut avoir lieu que lorsque la bouteille concernée est remplie.
Un MCD pourrait être le suivant :
Remarques
— FABRICANT a été renommé en ENTREPRISE, car toutes les entreprises parties prenantes dans cette affaire ne sont pas forcément des fabricants.
— Ce MCD a été réalisé avec PowerAMC. Par convention, lorsqu’on déguise une association en entité-type, par exemple PREPARER en PREPARATION, apparaissent des cardinalités 1,1 mises entre parenthèses :
[ENTREPRISE---0,n--------(R1)---(1,1)--------[PREPARATION]
Ce qui veut dire que la pseudo entité-type PREPARATION n’a pas d’identifiant en propre, mais hérite des identifiants des entités-types qu’elle met en relation, ce qui apparaît clairement au stade du MLD (où les attributs ont parfois été renommés pour des raisons de lisibilité, par exemple EntrepriseId renommé en PreparateurId dans la table PREPARATION) :
Script de création des tables SQL :
CREATE TABLE ENTREPRISE
(
EntrepriseId INT NOT NULL,
EntrepriseNom VARCHAR(64) NOT NULL,
CONSTRAINT ENTREPRISE_PK PRIMARY KEY (EntrepriseId)
) ;
CREATE TABLE BOISSON
(
BoissonId INT NOT NULL,
BoissonLibelle VARCHAR(64) NOT NULL,
CONSTRAINT Boisson_PK PRIMARY KEY (BoissonId)
) ;
CREATE TABLE PREPARATION
(
BoissonId INT NOT NULL,
PreparateurId INT NOT NULL,
CONSTRAINT PREPARATION_PK PRIMARY KEY (BoissonId, PreparateurId),
CONSTRAINT PREPARATION_BOISSON_FK FOREIGN KEY (BoissonId)
REFERENCES BOISSON (BoissonId),
CONSTRAINT PREPARATION_ENTREPRISE_FK FOREIGN KEY (PreparateurId)
REFERENCES ENTREPRISE (EntrepriseId)
) ;
CREATE TABLE BOUTEILLE
(
BouteilleId INT NOT NULL,
FabriquantId INT NOT NULL,
CONSTRAINT BOUTEILLE_PK PRIMARY KEY (BouteilleId),
CONSTRAINT BOUTEILLE_ENTREPRISE_FK01 FOREIGN KEY (FabriquantId)
REFERENCES ENTREPRISE (EntrepriseId)
) ;
CREATE TABLE REMPLISSAGE
(
BouteilleId INT NOT NULL,
RemplisseurId INT NOT NULL,
BoissonId INT NOT NULL,
PreparateurId INT NOT NULL,
CONSTRAINT REMPLISSAGE_PK PRIMARY KEY (BouteilleId),
CONSTRAINT REMPLISSAGE_PREPARATION_FK FOREIGN KEY (BoissonId, RemplisseurId)
REFERENCES PREPARATION (BoissonId, PreparateurId),
CONSTRAINT REMPLISSAGE_BOUTEILLE_FK FOREIGN KEY (BouteilleId)
REFERENCES BOUTEILLE (BouteilleId)
) ;
CREATE TABLE PERSONNE
(
PersonneId INT NOT NULL,
PersonneNom VARCHAR(64) NOT NULL,
CONSTRAINT PERSONNE_PK PRIMARY KEY (PersonneId)
)
;
CREATE TABLE ABSORPTION
(
BouteilleId INT NOT NULL,
HebergeurId INT NOT NULL,
BuveurId INT NOT NULL,
EmployeId INT NOT NULL,
SuperviseurId INT NOT NULL,
CONSTRAINT ABSORPTION_PK PRIMARY KEY (BouteilleId),
CONSTRAINT ABSORPTION_REMPLISSAGE_FK04 FOREIGN KEY (BouteilleId)
REFERENCES REMPLISSAGE (BouteilleId),
CONSTRAINT ABSORPTION_PERSONNE_BUVEUR_FK FOREIGN KEY (BuveurId)
REFERENCES PERSONNE (PersonneId),
CONSTRAINT ABSORPTION_PERSONNE_SUPERV_FK FOREIGN KEY (SuperviseurId)
REFERENCES PERSONNE (PersonneId),
CONSTRAINT ABSORPTION_PERSONNE_EMP_FK FOREIGN KEY (EmployeId)
REFERENCES PERSONNE (PersonneId)
) ;
Il manque les contraintes d’exclusion, selon lesquelles une entreprise qui fabrique les bouteilles ne seraient pas celles qui les remplit, etc. De même la personne qui avale une boisson ne peut pas se servir elle-même, etc.
Ces contraintes font l’objet de triggers, dont la rédaction dépend du SGBD. Quel est celui-ci ?
Partager