Discussion :

[laowantong]

Bonjour,

Je voudrais faire suite à une question de StackOverflow (https://stackoverflow.com/questions/...y-relationship) qui présente l'ERD suivant :



Attention, les cardinalités ne sont pas placées en Look Here (comme en Merise), mais en Look Across (cf. p. ex. crow's foot notation). Pour les associations binaires, on passe de l'une à l'autre en permutant simplement les cardinalités. Pour les associations n-aires, la sémantique est tout autre. Ci-dessus, de gauche à droite et de haut en bas :

1 : pour un couple (employé, site) donné, 1 seul projet possible ;
N : pour un couple (projet, site) donné, plusieurs employés possibles ;
1 : pour un couple (projet, employé) donné, 1 seul site possible.

Avec Merise, les assertions seraient plutôt du type : « pour un x donné, 1 seul / plusieurs couples (y, z) possibles ». C'est donc les références au singleton et au n-1-uplet qui sont permutées.

Ma question porte sur les trois niveaux de la modélisation :

- conceptuel : comment représenteriez-vous cet ensemble de contraintes dans un MCD Merise ?
- logique : pour les colonnes de la table Affectation, on peut aussi bien avoir (employé, site, projet) que (employé, projet, site), mais dans les deux cas on fait l'impasse sur une dépendance fonctionnelle. Peut-on faire mieux ?
- physique : comment traduiriez-vous ces contraintes lors de la création des tables ?

[escartefigue]

Vraisemblablement, les règles de gestion sont incomplètes

Je suppose qu'un employé est affecté à un projet pour une période, il peut ensuite changer de projet, un seul projet à un instant "t" pour un même employé
De la même façon, un employé est certainement affecté à un site pour une période, puis peut ensuite changer de site, un seul site à un instant "t" pour un même employé

Ce qui donne le MCD suivant selon le formalisme Merise :



Notez les flèches vers [PROJET] et [SITE] qui matérialisent les contraintes d'unicité
Notez également l'entité-type [CALENDRIER] mise entre parenthèses, ça signifie qu'elle ne deviendra pas une table, elle n'est là que pour faire participer la date à la PK des tables issues des assos ternaires


Le MLD correspondant est le suivant :




Et le DDL ici décliné pour SQL Server est le suivant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
CREATE TABLE PRO_projet(
   PRO_ident INT IDENTITY,
   PRO_code CHAR(8) NOT NULL,
   PRO_libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(PRO_ident),
   UNIQUE(PRO_code)
);
 
CREATE TABLE PER_personne(
   PER_ident INT IDENTITY,
   PER_nom VARCHAR(50) NOT NULL,
   PER_prenom VARCHAR(50) NOT NULL,
   PER_NIR CHAR(13) NOT NULL,
   PRIMARY KEY(PER_ident)
);
 
CREATE TABLE SIT_site(
   SIT_ident INT IDENTITY,
   SIT_libelle VARCHAR(50) NOT NULL,
   PRIMARY KEY(SIT_ident)
);
 
CREATE TABLE AFF_affecter(
   PER_ident INT,
   CAL_date DATE,
   AFF_dtfin DATE NOT NULL,
   PRO_ident INT NOT NULL,
   PRIMARY KEY(PER_ident, CAL_date),
   FOREIGN KEY(PER_ident) REFERENCES PER_personne(PER_ident),
   FOREIGN KEY(PRO_ident) REFERENCES PRO_projet(PRO_ident)
);
 
CREATE TABLE LOC_localiser(
   PER_ident INT,
   CAL_date DATE,
   LOC_dtfin DATE NOT NULL,
   SIT_ident INT NOT NULL,
   PRIMARY KEY(PER_ident, CAL_date),
   FOREIGN KEY(PER_ident) REFERENCES PER_personne(PER_ident),
   FOREIGN KEY(SIT_ident) REFERENCES SIT_site(SIT_ident)
);

Gràce aux contraintes matérialisées par les flêches du MCD, les attributs correspondants ont été évacués des PK des tables associatives pour garantir l'unicité du site pour un coupe (personne, date) et l'unicité du projet pour un couple (personne, date)

[laowantong]

Merci beaucoup pour cette réponse rapide, précise et détaillée.

Cependant, votre modélisation me semble autoriser la vue en extension suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
Affectations

Alice | lundi | projet 1 | lundi
Alice | mardi | projet 1 | mardi

Localisations

Alice | lundi | Paris | lundi
Alice | mardi | Lyon | mardi

En d'autres termes, Alice travaillerait sur le même projet lundi et mardi, mais sur des sites différents. Or, d'après l'énoncé : Each employee assigned to a project works at only one location for that project.

J'ai l'impression qu'il y a quelque chose que je n'ai pas compris, soit dans les règles de gestion originales, soit dans votre proposition...

[escartefigue]

En effet, mea culpa, je n'ai pas tenu compte de cette contrainte.
Mais, l'énoncé est incomplet, car on ne sait pas si à un instant "t", un employé peut travailler sur plusieurs projets. Qu'en est-il ?

[laowantong]

Désolé, je viens seulement de voir votre message.

J'aurais tendance à penser qu'à un instant t, un employé n'est pas censé travailler sur deux projets à la fois, mais en effet l'énoncé ne dit rien là-dessus. Si une modélisation en LH répondant aux règles de gestion explicites devait trancher cette question, à mon avis on ne pourrait pas lui reprocher de le faire par oui ou par non. Mais le fait que la modélisation en LA n'oblige pas à préciser de règle supplémentaire indiquerait alors que les domaines couverts par l'une et l'autre convention ne coïncident pas exactement, ce qui serait intéressant en soi.

D'après Paré, Rafael Camps. “Transforming N-ary relationships to database schemas: an old and forgotten problem.” (2002) :

LA style (Chen style) is more powerful than LH style (Merise style). All the possible FD patterns for ternary relationships can be obtained using the LA style: one LA ternary relationship plus some additional imposed binary FDs that can be seen as imposed LA binary relationships. But this would be not true for LH style.

Il est bien possible qu'on soit dans ce cas-là.

[Paprick]

Bonsoir,

Je n'ai peu de le temps de me pencher sur votre problème, mais je peux affirmer sans le moindre doute que tout SI peut être modélisé avec un schéma E/A (Merise).
Je laisse escartefigue poursuivre sa modélisation... je viendrai à la rescousse si nécessaire, mais je doute que ce soit nécessaire !