Discussion :

[mathro]

Bonjour,

j'ai un modèle relationnel composé de 4 entité: Etude, SousEtude, TâcheService et TâcheCommune.

Une instance de l'entité Etude peut être composée de 0 à n SousEtude et une instance de SousEtude appartient à une seule Etude.

Si une Etude n'est composée d'aucune SousEtude alors elle peut contenir de 0 à n TâcheService et de 0 à n TâcheCommune.
Si une Etude est composé de SousEtude, alors ses SousEtude (et pas l' Etude) qui contiennent de 0 à n TâcheService et de 0 à n TâcheCommune.

J'ai fait la modélisation suivante:
TâcheService-0,n----appartenir----0,n-Etude
TâcheCommune-0,n----appartenir -------0,n-Etude
Etude-1,1----posséder----0,n-SousEtude
TâcheService-0,n----appartenir----0,n-SousEtude
TâcheCommune-0,n----appartenir -------0,n-SousEtude

Peut-on améliorer cette modélisation?

[escartefigue]

bonjour,

Je pense que vous trouverez votre bonheur dans cette discussion

https://www.developpez.net/forums/d1...le-fermee-mcd/

[mathro]

Bonjour,

j'ai lu cette discussion et il y a une différence par rapport à mon problème, car si une Etude est composée de SousEtude elle ne peut pas contenir des TâcheService ou des TâcheCommune.

Si on garde le modèle tel qu'il est, quels sont les problèmes qu'on puisse rencontrer?

[escartefigue]

Au niveau du MCD on peut matérialiser une exclusion entre les deux relations, mais ca ne génèrera rien dans le MLD, seul le traitement pourra vérifier que la relation est faite avec la table qui va bien

[fsmrel]

Du point de vue de la seule structure des données, votre modélisation est convenable (à ceci près que dans le contexte Merise, pour signifier qu’une SousEtude appartient à une et une seule Etude, il faut que vous permutiez les cardinalités de l’association Posseder).

Je fais observer que pour éviter de garantir la contrainte par traitement pur, au stade SQL il faudra la sous-traiter au SGBD, au moyen d’un trigger (ou d’un artifice équivalent s'il existe...)

Partons du MCD suivant (réalisé avec DB-MAIN), reprenant ce que vous avez fait :

Comme le suggère escartefigue, pour s’assurer qu’une étude et une sous-étude ne violent pas la contrainte, il faut appareiller les associations ETS et SETS.

Au stade relationnel, le plus simple est alors de prévoir la présence de l’attribut EtudeId non seulement dans l’en-tête de la variable (relationnelle) ETS, mais aussi dans celui de la variable SETS :

Code Rel :

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

1
2
3
ETS {EtudeId, TacheServiceId} ;

SETS {EtudeId, SousEtudeId, TacheServiceId} ;

En procédant ainsi, dans le cadre du modèle relationnel de données, on peut définir une contrainte :

Code Rel :

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

CONSTRAINT Cx IS_EMPTY ETS {EtudeId} INTERSECT SETS {EtudeId}} ;

Mais pour parvenir à nos fins, le MCD doit être aménagé : pour que l’attribut EtudeId soit propagé jusqu’à la variable SETS, on doit mettre en œuvre l’identification relative pour l’entité-type SousEtude dans le MCD, en sorte que lors de l’étape de dérivation (automatique) du MCD en MLD puis de l’étape de production (automatique) du code (disons SQL aujourd’hui), la propagation soit effective :




Evidemment, le langage SQL (Sorry Query Language) est encore loin du modèle relationnel de données, il faudra donc en passer par une instruction CREATE ASSERTION, sans parler des SGBD prétendus « relationnels », lesquels renâclent à fournir cette instruction et ne nous permettent guère que l’emploi de triggers pour garantir la contrainte.

Pour information, voici le code SQL de déclaration des structures produit par DB-MAIN :

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
42
43
44
45
46
47
48
49
50
51
 
-- Tables Section
-- _____________ 
 
create table TacheService (
     TacheServiceId int not null,
     constraint Tache_PK primary key (TacheServiceId));
 
create table Etude (
     EtudeId int not null,
     constraint Etude_PK primary key (EtudeId));
 
create table SousEtude (
     EtudeId int not null,
     SousEtudeId int not null,
     constraint SousEtude_PK primary key (EtudeId, SousEtudeId));
 
create table ETS (
     EtudeId int not null,
     TacheServiceId int not null,
     constraint ETS_PK primary key (EtudeId, TacheServiceId));
 
create table SETS (
     EtudeId int not null,
     SousEtudeId int not null,
     TacheServiceId int not null,
     constraint SETS_PK primary key (EtudeId, SousEtudeId, TacheServiceId));
 
 
-- Constraints Section
-- ___________________ 
 
alter table SousEtude add constraint SousEtude_Etude_FK
     foreign key (EtudeId)
     references Etude (EtudeId);
 
alter table ETS add constraint ETS_Etude_FK
     foreign key (EtudeId)
     references Etude (EtudeId);
 
alter table ETS add constraint ETS_TacheService_FK
     foreign key (TacheServiceId)
     references TacheService (TacheServiceId);
 
alter table SETS add constraint SETS_SousEtude_FK
     foreign key (EtudeId, SousEtudeId)
     references SousEtude (EtudeId, SousEtudeId);
 
alter table SETS add constraint SETS_TacheService_FK
     foreign key (TacheServiceId)
     references TacheService (TacheServiceId);

Pour coder le trigger (ou autre artifice), se reporter à son SGBD favori...

[escartefigue]

Evidemment, le langage SQL (Sorry Query Language)

Amusant et adéquat en l'occurrence, mais Structured Query Language s'applique heureusement le plus souvent

Je suggérai effectivement, au travers de la référence à l'autre sujet similaire, d'identifier le sous-établissement relativement à l'établissement dont il dépend pour pouvoir mettre en œuvre la contrainte.