Modéliser conformément aux règles de gestion

**catcat** · 11/12/2006, 02h28

Bonjour,

Je n'arrive pas à trouver une modélisation qui réponde au règles de gestions qui sont imposées.
Je sens bien qu'il faut ajouter des contraintes CIF, mais je ne vois pas bien comment, et je ne suis déjà pas satisfaite de ma proposition de modélisation.
Le contexte : Des élèves s'inscrivent à des modules optionnels (MO).
Voici les règles de gestions :
- Les élèves doivent choisir un et un seul module par séquence (une période de temps)
- 4 séquences successives de MO sont organisées dans lesquelles plusieurs MO fonctionnent en parallèle.
- Des thèmes décrivent les MO.
- Plusieurs MO appartiennent à un thème. Un MO est décrit par un seul thème
- Un MO peut être animé par plusieurs professeurs, dont un seul est responsable du MO

J'ai un début de modélisation que voici.

La cardinalité max sur la patte MO de la relation "choisit" ne me plait pas. car un MO accueille plusieurs élèves, mais n'existe que dans une séquence.
Cela veut sans doute dire que l'entité "séquence" doit se trouver derrière MO. Mais alors, comment appliquer la règle "un élève doit choisir un MO dans chacune des séquences".
Je suis également tentée par ce le fait de "réifier" une association MO-Séquence, ainsi :

Mais je ne sais pas si c'est "correct" et comment passer au modèle logique.

Bref, merci d'avance à tous de votre science.

Catherine

**TheLeadingEdge** · 11/12/2006, 17h21

Bonjour,

1 élève ne peut s'inscrire qu'à 1 seul module par séquence. Tu as donc effectivement 1 CIF: séquence,élève --> module.
Il te manque la relation entre module et séquence, qui n'est pas la même que la relation sequence, module, élève. Par contre il n'est pas clairement exprimé qu'1 module n'est que ds 1 séquence ?

**fsmrel** · 11/12/2006, 17h47

Bonjour Catcat,

Envoyé par Catcat

Les élèves doivent choisir un et un seul module par séquence

Je vois donc pour ma part ainsi les choses :

Il existe une relation (binaire) N,N entre Séquence et Module (appelons-la MS).

Il existe une relation (binaire) N,N entre Elève et Séquence (appelons-la ES).

Le couple {Elève, Séquence} détermine un module : {Elève, Séquence} --> Module.

En conséquence, on peut établir une contrainte d’inclusion entre ES et MS : ES < MS ("<" symbolisant l’inclusion).

Si votre AGL vous permet d’établir cette contrainte, a priori tout va bien. Sinon, de ES faites une entité-type associative connectée sur MS et tout va bien là aussi.

Le Modèle logique correspondant devrait être celui qui figure en pièce jointe.

Code SQL :

Code :

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
52
53
54
55
56
57
58
59
60
61
CREATE TABLE Module (
  idModule INTEGER NOT NULL,
  Nom CHAR NOT NULL,

  PRIMARY KEY(idModule)
);

CREATE TABLE Séquence (
  idSéquence INTEGER NOT NULL,
  Nom INTEGER NOT NULL,

  PRIMARY KEY(idSéquence)
);

CREATE TABLE Elève (
  idElève INTEGER NOT NULL,
  Nom CHAR NOT NULL,

  PRIMARY KEY(idElève)
);

CREATE TABLE MS (
  idSéquence INTEGER NOT NULL,
  idModule INTEGER NOT NULL,

  PRIMARY KEY(idSéquence, idModule),

  FOREIGN KEY(idModule)
    REFERENCES Module(idModule)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION,

  FOREIGN KEY(idSéquence)
    REFERENCES Séquence(idSéquence)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION
);

CREATE TABLE ES (
  idElève INTEGER NOT NULL,
  idSéquence INTEGER NOT NULL,
  idModule INTEGER NOT NULL,

  PRIMARY KEY(idElève, idSéquence),

  FOREIGN KEY(idElève)
    REFERENCES Elève(idElève)
      ON DELETE CASCADE
      ON UPDATE CASCADE,

  FOREIGN KEY(idSéquence)
    REFERENCES Séquence(idSéquence)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION,

  FOREIGN KEY(idSéquence, idModule)
    REFERENCES MS(idSéquence, idModule)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION
);

**catcat** · 12/12/2006, 00h08

Envoyé par TheLeadingEdge

Bonjour,

1 élève ne peut s'inscrire qu'à 1 seul module par séquence. Tu as donc effectivement 1 CIF: séquence,élève --> module.
Il te manque la relation entre module et séquence, qui n'est pas la même que la relation sequence, module, élève. Par contre il n'est pas clairement exprimé qu'1 module n'est que ds 1 séquence ?

Bonsoir TheLeadingEdge,

Merci pour cette proposition de CIF. Je ne savais pas comment l'exprimer.
Et tu as raison de dire que la règle "1 module n'est que dans une séquence" n'est pas du tout traduite par le modèle.
Aussi, la relation ternaire n'est surement pas la bonne solution.
Je continue de chercher.

**catcat** · 12/12/2006, 00h31

Envoyé par fsmrel

Bonjour Catcat,
Le couple {Elève, Séquence} détermine un module : {Elève, Séquence} --> Module.

En conséquence, on peut établir une contrainte d’inclusion entre ES et MS : ES < MS ("<" symbolisant l’inclusion).

Bonsoir fsmrel,

Merci pour cette réponse argumentée.
Elle m'a permis de comprendre plusieurs choses :
1) que je pouvais mieux exprimer les règles de gestion avec des relations binaires
2) que le fait de mettre en place la contrainte d'inclusion que vous proposez ES < MS est équivalent a faire une entité-type associative "sequence-eleve" reliée à MS.
3) et que l'on peut traduire cela au niveau logique à l'aide de la clef etrangère idModule.

J'ai encore un peu de mal à comprendre la contrainte d'inclusion. Qu'est-ce ui est inclus dans quoi ?
La solutions entité-type associative me plait bien car je la comprends mieux.
Peut-on dire que cela revient à une dépendance fonctionnelle dans laquelle Module dépend du couple séquence-élève ?
Pour la relation MS, je devrais juste modifier les cardinalités que vous proposez. En effet, ce n'est pas une relation N,N car un module ne se déroule que dans une séquence.

Un grand merci pour le temps passé qui m'a permis de bien avancer.

Catcat

**TheLeadingEdge** · 12/12/2006, 00h44

Re,

Envoyé par catcat

la relation ternaire n'est surement pas la bonne solution.

1 propriété dépend des 2 autres...La ternaire est nécessaire.

Envoyé par catcat

la règle "1 module n'est que dans une séquence" n'est pas du tout traduite par le modèle.

Elle n'est pas ds le modèle parce qu'il manque 1 relation... Mais ça, ça se règle facilement avec les bonnes cardinalités
Ce que je voulais surtout dire c'est que je ne la voyait pas non plus ds les règles de gestion !

**catcat** · 12/12/2006, 03h09

Envoyé par TheLeadingEdge

Re,

Merci beaucoup à toi, TheLeadingEdge,

Bon, si tout à l'heure je n'avais pas bien compris cette contrainte d'inclusion, je crois que ça va mieux, après quelques lectures.
En particulier ceci :
http://www.reseaucerta.org/docs/dida...deliser-ma.pdf

Alors comme c'est nouveau pour moi, je reprends ton MCD, en le commentant avec mes mots. Dis-moi si je me trompe.

La pastille I indique que
- pour qu'un élève choisisse un module, ce module doit faire partie de la séquence.
- pour q'un module soit choisi par un élève, il doit aussi faire partie de la séquence.
La CIF indique que le couple "élève-séquence" détermine le module, c'est à dire qu'un élève, pour une séquence donnée ne peut choisir qu'un module.

Question : est-ce que la CIF indique aussi qu'un élève doit choisir un module pour chacune des séquences ?

Encore merci,
Catcat

**fsmrel** · 12/12/2006, 03h12

Bonsoir Catcat,

Envoyé par Catcat

Merci pour cette réponse argumentée.
Elle m'a permis de comprendre plusieurs choses :
1) que je pouvais mieux exprimer les règles de gestion avec des relations binaires
2) que le fait de mettre en place la contrainte d'inclusion que vous proposez ES < MS est équivalent a faire une entité-type associative "sequence-eleve" reliée à MS.
3) et que l'on peut traduire cela au niveau logique à l'aide de la clef étrangère idModule.

1) Concernant le premier point : il y a surtout que lorsque vous utilisez des relations d’arité > 2, vous risquez d’être prise en flagrant délit d’infraction à la 4e et à la 5e forme normale. Ceci est un peu compliqué à faire comprendre, car il faut avoir étudié à fond la théorie de la normalisation telle que l’a exprimée Ronald Fagin en guise de prérequis (cherchez les travaux de ce garçon sur la Toile, vous serez édifiée). Disons qu’une relation ternaire est normalisée s’il n’y a aucun moyen de la décomposer en deux ou trois relations binaires.

2) Concernant le deuxième point, il n’y a pas équivalence stricto sensu, car une contrainte d’inclusion ne se résout pas toujours au niveau logique relationnel par la mise place d’une entité associative. Parfois on doit en passer par une contrainte d’intégrité (Assertion au sens du standard SQL). Je sais que ça devient un peu compliqué, mais la réalisation à ce niveau a parfois des exigences non triviales...

3) Concernant le troisième point, ça n’est pas seulement la clé étrangère idModule qui permet d’exprimer la contrainte : c’est nécessairement la clé étrangère complète, c’est-à-dire le couple {idSéquence, idModule}. En effet, les composants d’une clé étrangère doivent correspondre à ceux d’une clé candidate cible complète (en l’occurrence à ceux de la clé primaire de MS).

Envoyé par Catcat

J'ai encore un peu de mal à comprendre la contrainte d'inclusion. Qu'est-ce qui est inclus dans quoi ?

Pour compléter ce que j’ai écrit ci-dessus, chaque valeur de couple {idSéquence, IdModule} dans ES doit exister en tant que valeur de couple {idSéquence, IdModule} dans MS. Le but de la manœuvre est d’éviter qu’un élève soit associé à un module qui n’existe pas dans les séquences auxquelles on associe cet élève.

Peut-on dire que cela revient à une dépendance fonctionnelle dans laquelle Module dépend du couple séquence-élève ?

Oui et Non. Non parce que le couple {idElève, idSéquence} étant clé primaire (irréductible) de ES il existe automatiquement dans ES la DF irréductible à gauche {idElève, idSéquence} --> idModule. Oui, parce que pour que la DF existe, il a fallu tirer la relation vers MS et faire en sorte que idModule devienne attribut (non clé) de ES...

Pour la relation MS, je devrai juste modifier les cardinalités car un module se déroule dans une seule séquence.

Dans ces conditions, vous pouvez effectivement modifier la cardinalité, mais vous pouvez aussi faire l’économie de MS qui devient absorbable par Module. Dans ce cas-là, pour préserver la contrainte d’inclusion, sachant que dans ES, le couple {idSéquence, IdModule} doit rester présent, il faut qu’il soit aussi clé candidate (disons primaire) de Module pour tirer le lien qui va bien. Pour y parvenir, il suffit d’utiliser l’identification relative : au niveau conceptuel, l’identifiant de Module est relatif à celui de Séquence (et Module devient une entité-type faible par rapport à l’entité-type forte Séquence). Au niveau logique relationnel, la clé primaire de Module devient ainsi le couple {IdSéquence, idModule} : le lien de ES vers Module devient exploitable au niveau logique relationnel.

Modèle logique : cf. pièce jointe.

Code SQL :

Code :

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

CREATE TABLE Séquence (
  idSéquence INTEGER NOT NULL,
  Nom INTEGER NOT NULL,

  PRIMARY KEY(idSéquence)
);

CREATE TABLE Elève (
  idElève INTEGER NOT NULL,
  Nom CHAR NOT NULL,

  PRIMARY KEY(idElève)
);

CREATE TABLE Module (
  idSéquence INTEGER NOT NULL,
  idModule INTEGER NOT NULL,
  Nom CHAR NOT NULL,

  PRIMARY KEY(idSéquence, idModule),

  FOREIGN KEY(idSéquence)
    REFERENCES Séquence(idSéquence)
      ON DELETE CASCADE
      ON UPDATE CASCADE
);

CREATE TABLE ES (
  idElève INTEGER NOT NULL,
  idSéquence INTEGER NOT NULL,
  idModule INTEGER NOT NULL,

  PRIMARY KEY(idElève, idSéquence),

  FOREIGN KEY(idElève)
    REFERENCES Elève(idElève)
      ON DELETE CASCADE
      ON UPDATE CASCADE,

  FOREIGN KEY(idSéquence)
    REFERENCES Séquence(idSéquence)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION,

  FOREIGN KEY(idSéquence, idModule)
    REFERENCES Module(idSéquence, idModule)
      ON DELETE NO ACTION
      ON UPDATE NO ACTION
);

**catcat** · 12/12/2006, 09h46

Envoyé par fsmrel

Je sais que ça devient un peu compliqué, mais la réalisation à ce niveau a parfois des exigences non triviales...

Bonjour fsmrel,

Je vous remercie pour cette nouvelle, et longue réponse.
Je me permets de n'en citer qu'un petit extrait, pour vous dire qu'il me faut étudier en détail vos explications puis les digérer. Je ne le ferai que ce soir probablement. Car je débute et je ne vais pas très vite dans la compréhension de ces notions.
En attendant ce soir, chapeau bas pour vos contributions à l'excellente qualité de ce forum.

Catcat

Modéliser conformément aux règles de gestion

Schéma

Discussions similaires

Partager

Partager