Comment placer cette contrainte ?

**Merisier** · 26/09/2014, 15h03

Bonjour,

Je suis autodidacte en Merise, et je cherche à me perfectionner.

Voici la situation que je souhaite modéliser : des professeurs enseignent des matières. D'un autre côté, ils peuvent aussi animer des stages. Un stage peut être animé par un ou plusieurs professeur(s), et il porte sur une (et une seule) matière.

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
--------------                        -----------
| PROFESSEUR |                        | MATIÈRE |
|------------|  1,n               0,n |---------|
| numProf    |-------(ENSEIGNER)------| numMat  |
| nom        |                        | nomMat  |
| prénom     |                        |---------|
|------------|                           |
      |                                  | 0,n
      | 0,n                              |
      |                                  |
  (ANIMER)                               |
      |                                  |
      | 1,n                              |
      |                                  |
-------------                            |
| STAGE     |                            | 
|-----------|                            |
| numStage  |  1,1                       |
| dateStage |------(PORTER SUR)----------|
| intitulé  |
|-----------|

Pour plus de cohérence, je voudrais que le MCD comporte une contrainte indiquant qu'un professeur ne peut animer un stage que si ce stage porte sur une matière qu'il enseigne. C'est donc une inclusion (je suppose), mais je ne vois pas avec quelle notation je peux la faire figurer sur le MCD.

Merci d'avance à qui m'aidera…

**punkoff** · 26/09/2014, 16h48

Bonjour,

Est-ce que les professeurs seront amener à enseigner différentes matières dans le temps ?

Ceci implique de nouvelles matière à enseigner et, bien sur, des matières en moins à enseigner.

**Merisier** · 26/09/2014, 17h03

Envoyé par punkoff

Est-ce que les professeurs seront amener à enseigner différentes matières dans le temps ?

Dans ma façon de voir les choses, je dis qu'un professeur « enseigne » une matière pour dire qu'il est compétent pour enseigner cette matière, ce qui n'implique pas forcément qu'à un moment donné, il dispense effectivement des cours. On pourrait remplacer ENSEIGNER par POUVOIR_ENSEIGNER. Un professeur peut devenir compétent sur une nouvelle matière, mais une fois la compétence acquise, il ne peut plus la perdre.

**punkoff** · 26/09/2014, 17h23

Dans ce cas je verrai bien la liaison arrivé directement sur la relation enseigné ...

Stage-1,1-----Dispense------0,n-Enseignement

Je ne sais pas c'est merisement correct par contre.

**Merisier** · 26/09/2014, 17h43

Envoyé par punkoff

Dans ce cas je verrai bien la liaison arrivé directement sur la relation enseigné ...

Stage-1,1-----Dispense------0,n-Enseignement

Si je comprends bien, tu proposes ceci :

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
--------------                        -----------
| PROFESSEUR |                        | MATIÈRE |
|------------|  1,n               0,n |---------|
| numProf    |-------(ENSEIGNER)------| numMat  |
| nom        |          |             | nomMat  |
| prénom     |          | 0,n         |---------|
|------------|          |                 
                        |
                    (ANIMER)                                  
                        | 1,n                              
                        |
                  -------------                            
                  | STAGE     |                             
                  |-----------|                            
                  | numStage  |                       
                  | dateStage |
                  | intitulé  |
                  |-----------|

(puisqu'un stage peut être animé par plusieurs professeurs).
Avec cette modélisation, on ne sait plus sur quelle matière porte le stage. De plus, un stage peut être animé par plusieurs professeurs qui n'ont pas de matière en commun.

**Merisier** · 26/09/2014, 17h50

En fait, pour savoir sur quelle matière porte le stage, il suffit de garder l'association PORTER SUR :

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
--------------                        -----------
| PROFESSEUR |                        | MATIÈRE |
|------------|  1,n               0,n |---------|
| numProf    |-------(ENSEIGNER)------| numMat  |
| nom        |          |             | nomMat  |
| prénom     |          | 0,n         |---------|
|------------|          |                 |                 
                        |                 | 0,n
                    (ANIMER)              |                   
                        | 1,n             |                 
                        |            (PORTER SUR)
                  -------------           |                 
                  | STAGE     |           |                  
                  |-----------|   1,1     |                 
                  | numStage  |------------                       
                  | dateStage |
                  | intitulé  |
                  |-----------|

Mais la contrainte que je cherche manque toujours : on peut faire animer un stage de volley-ball par un prof d'allemand.

**fsmrel** · 26/09/2014, 22h35

Bonsoir,

Partons de la référence Afcet :

Afcet - Le formalisme de données Merise - Extensions du pouvoir d’expression - Journée d’étude organisée par le Groupe de Travail 135 « Conception des systèmes d’information » (Collège AFCET-GID) - Jeudi 15 novembre 1990, Paris.

Au vu de ce qui précède, Il est probable que la contrainte d’inclusion ci-dessous pourrait convenir, toutefois, pour s’en assurer, il faudrait disposer de WinDesign.

Comme je suis bien plus à l’aise au niveau relationnel, j’y modéliserais les choses ainsi :

Où la relvar (variable relationnelle) STAGE a pour clé la paire {NumMat, NumStage}, autrement dit un stage est une propriété multivaluée d’une matière. Au niveau Merise, cela revient à dire que l’entité-type STAGE est identifiée relativement à l’entité-type MATIERE, STAGE est une entité-type faible par rapport à l’entité-type forte MATIERE.

En tout état de cause, si le professeur P1 anime les stages S1 et S2 de la matière M1, cette dernière doit faire partie des matières que P1 enseigne : relationnellement parlant, c’est réglé car, tout comme la paire {NumMat, NumStage} de l’en-tête de la relvar ANIMER constitue une clé étrangère par rapport à la clé primaire de la relvar STAGE, la paire {NumProf, NumMat} de l’en-tête de la relvar ANIMER constitue une clé étrangère par rapport à la clé primaire de la relvar ENSEIGNER : l’attribut NumMat ne peut pas faire partie d’une clé étrangère sans faire partie de l’autre. CQFD.

Que donne la rétro conception de ce diagramme ?

Avec PowerAMC, on produit ceci :

Où les cardinalités 1,1 sont mises entre parenthèses : c’est la manière de PowerAMC de noter l’identification relative. Mais attention, si on demande à PowerAMC de produire un MLD à partir de ce MCD, il n’a pas connaissance de la contrainte comme quoi on ne peut pas faire animer un stage de volley-ball par un prof d'allemand, en conséquence de quoi il produit ceci :

A nous d’éliminer manuellement l’attribut fautif et de corriger le lien qui le porte.

N.B. Vous aurez noté que PowerAMC a fait d’ENSEIGNER une entité-type (doublement faible) et non pas une association : normal, en Merise, on n’associe pas une association à une association. C’es ballot, mais c’est ainsi, alors on déguise...

**Merisier** · 29/09/2014, 09h51

Bonjour et merci de votre réponse.

Sur le branchement d'une association sur une autre association, il m'est arrivé de rencontrer ceci :

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
------                    ------ 
| E1 |                    | E2 | 
|----| c1,c2 ------ c3,c4 |----| 
|    |-------|(A1)|-------|    | 
------       ------       ------ 
               |
               | c5,c6
               |
              (A2)
               |
               | c7,c8
               |
             ------
             | E3 |
             |----|
             |    |
             ------

avec la même signification qu'un agrégat, c'est-à-dire un synonyme de cela :

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
...................................
. ------                   ------ .
. | E1 |                   | E2 | .
. |----| c1,c2      c3,c4  |----| .
. |    |-------(A1)--------|    | .
. ------                   ------ .
...................................
                |
                | c5,c6
                |
               (A2)
                |
                | c7,c8
                |
              ------
              | E3 |
              |----|
              |    |
              ------

Après, est-ce correct ou pas, je n'en sais rien.

Je suis, bien sûr, d'accord avec vous au niveau relationnel.

Pour en revenir à la contrainte d'inclusion, il y a deux choses que je ne comprends pas dans le schéma conceptuel que vous proposez (celui avec une contrainte d'inclusion en rouge).
D'abord, j'ai un problème de notation. Il me semble qu'ANIMER devrait être inclus dans ENSEIGNER avec le pivot PORTER_SUR, ce qui donnerait ceci :

Code :

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

1
2
3
4
5
6
7
8
(ENSEIGNER)
     ^
     |
     |
    (I)-  -  -  -  -(PORTER SUR)
     |
     |
 (ANIMER)

... mais je peux me tromper.
Ensuite, en l'état, je ne suis pas sûr de voir comment traduire le schéma conceptuel en schéma relationnel. Si on prend le même avec STAGE comme entité faible, tout va bien pour moi :

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
--------------                          ------------
| PROFESSEUR |                          | MATIÈRE  |
|------------|  1,n                 0,n |----------|
| _NumProf_  |--------(ENSEIGNER)-------| _NumMat_ |
| Nom        |           ^              | NomMat   |
| Prénom     |           |              |----------|
|------------|           |                  |
      |                  |                  | 0,n
      | 0,n              |                  |
      |                  |                  |
      |                 (I)-  -  -  -  -(PORTER SUR)
      |                  |                  |
      |                  |                  | (1,1)
      |                  |                  |
      |                  |            --------------
      |                  |            | STAGE      |
      |                  |       1,n  --------------
      ---------------(ANIMER)---------| _NumStage_ |
                                      | DateStage  |
                                      | Intitulé   |
                                      --------------

Une traduction « mécanique » donne :

Code :

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

1
2
3
4
5
PROFESSEUR(_NumProf_, nom, prénom)
MATIÈRE(_NumMat_, NomMat)
STAGE(_NumMat_, _NumStage_, DateStage, Intitulé)
ENSEIGNER(_#NumProf_, _#NumMat_)
ANIMER(_#NumProf_, _#NumMat_, _#NumStage_)

où, dans ANIMER, (_#NumProf_, _#NumMat_) référence la clé primaire d'ENSEIGNER, ce qui résout le problème, comme vous l'avez expliqué.

À ce stade, il me reste quelques questions :

est-ce que la contrainte d'inclusion doit s'écrire comme je l'ai fait ci-dessus, ou ai-je mal compris cette notation ?
est-il possible de traduire le schéma conceptuel en schéma relationnel si STAGE n'est pas une entité faible, et si oui, comment ?

Pour la dernière question, il me semble qu'ANIMER perd NumMat, ce qui ne ferait aucun mal puisque ce NumMat n'apporte pas d'information. Et bien sûr, NumMat ne fait plus partie de la clé primaire de STAGE. Mais comment exprimer la contrainte d'inclusion ? J'ai l'impression qu'on se retrouverait avec une contrainte sur une jointure : pour toute instance d'ANIMER INNER JOIN STAGE ON ANIMER.NumStage = STAGE.NumStage, il faudrait qu'il existe une instance d'ENSEIGNER tel que ENSEIGNER.NumMat = STAGE.NumMat. Ceci me parait cohérent, il me semble que le problème est ainsi résolu, et ça évite une redondance d'information par rapport à la version avec STAGE comme entité faible. Est-ce correct ? Et si oui, comment faire figurer ça sur un schéma relationnel ?

**JPhi33** · 29/09/2014, 14h37

Bonjour à tous,

Envoyé par Merisier

Il me semble qu'ANIMER devrait être inclus dans ENSEIGNER avec le pivot PORTER_SUR, ce qui donnerait ceci :

Code :

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

1
2
3
4
5
6
7
8
9
(ENSEIGNER)
     ^
     |
     |
    (I)-  -  -  -  -(PORTER SUR)
     |
     |
 (ANIMER)

Je suis de cet avis. La contrainte d'inclusion ( ANIMER )----(I)--->( ENSEIGNER ) signifie qu'un stage ne peut être animé que par des professeurs sachant enseigner la matière sur laquelle porte le stage.

Petite précision : le pivot d'une contrainte n'est pas une association, c'est une entité ou un ensemble d'entités. Ici, clairement, c'est PROFESSEUR qui est le pivot de cette contrainte. Il n'est pas utile de le préciser car il est implicite (donc pas de pointillés reliant la "pastille" (I) à l'entité PROFESSEUR). En effet, le pivot est implicite lorsqu'il est réduit à l'ensemble des entités que la portée (ici, ANIMER) et la cible (ici, ENSEIGNER) ont en commun.

**fsmrel** · 30/09/2014, 03h36

Bonsoir,

A propos de l’agrégation

Envoyé par Merisier

Après, est-ce correct ou pas, je n'en sais rien.

La représentation que vous proposez est effectivement utilisée dans le contexte E/R, elle est tout à fait respectable, elle dit bien ce qu’elle veut dire, mais je ne me souviens pas de l’avoir rencontrée chez ceux qui ont fait Merise (ce qui ne m’empêche pas de l’utiliser à l’occasion, puisqu’elle permet de ne pas déguiser une association en entité-type...)

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
...................................
. ------                   ------ .
. | E1 |                   | E2 | .
. |----| c1,c2      c3,c4  |----| .
. |    |-------(A1)--------|    | .
. ------                   ------ .
...................................
                |
                | c5,c6
                |
               (A2)
                |
                | c7,c8
                |
              ------
              | E3 |
              |----|
              |    |
              ------

De temps en temps, le sujet fait surface, voyez par exemple le message de vever. Le diagramme a disparu : en attendant qu'il revienne, en voici une copie :

A propos de la contrainte d’inclusion

Je voudrais que nous soyons en phase quant aux définitions des termes avant de nous prononcer sur la pertinence de nos contraintes d’inclusion.

Dans sa définition de la contrainte d’inclusion (cf. mon 1er message) le groupe 135 ne précise pas ce qu’il entend par « relation composée » : je vais donc supposer que l’opération de composition de la théorie des ensembles convient. Informellement, étant donnés deux ensembles A et B, la composition de A et de B peut être vue comme l’opération produisant l’ensemble des éléments qui appartiennent à l’union de A et de B mais pas à leur intersection.

En considérant la relation ENSEIGNER comme un ensemble, son en-tête (l’ensemble des noms de ses attributs, y compris les attributs identifiants, même si ceux-ci ne sont qu’hérités) est aussi un ensemble, ayant pour éléments NumProf et NumMat, et on peut le représenter ainsi : {NumProf, NumMat}, les accolades étant là pour signifier qu’il s’agit bien d’un ensemble. De la même façon, l’en-tête {NumStage, NumMat} de PORTER_SUR et l’en-tête {NumProf, NumStage} de ANIMER sont des ensembles. Puisque ce sont des ensembles, on peut en faire la composition comme on l’a fait pour les ensembles A et B.

Considérons votre portée et appelons-la R : c’est la composition des ensembles ANIMER et PORTER_SUR, et conformément à la définition de la composition, R a pour en-tête {NumProf, NumMat}, l’élément commun NumStage ne devant pas en faire partie (sinon ce serait le résultat d’une jointure naturelle). Etant donné que la cible de cette portée est ENSEIGNER {NumProf, NumMat}, portée et cible ont même en-tête, en vertu de quoi on peut dire que votre contrainte d’inclusion est valide au sens du groupe 135. En français : La condition pour que le professeur P puisse animer le stage S sur lequel porte la matière M, est que M soit enseignée par P.

Qu’en est-il de la contrainte que j’ai proposée ? Elle a pour portée R la composition de ENSEIGNER {NumProf, NumMat} et ANIMER {NumProf, NumStage}, c'est-à-dire R {NumMat, NumStage}. Elle a pour cible PORTER_SUR {NumMat, NumStage} : portée et cible ayant même en-tête, on peut dire que cette contrainte d’inclusion est valide au sens du groupe 135. En français : La condition pour que le professeur P qui enseigne la matière M puisse animer le stage S est que M porte sur S.

J’ai le sentiment que tout ça se ressemble...

Reste le cas amusant où la portée serait la composition de ENSEIGNER et PORTER_SUR, avec ANIMER pour cible... Disons qu’au plan théorique, c’est valide, mais sémantiquement c’est une autre paire de manches, et du point de vue des ajouts dans les tables de la base de données ça poserait bien des problèmes : pour que le professeur P enseigne la matière M qui porte sur le stage S, il faudrait d’abord que P anime S... Ça n’est pas très pertinent et l’entonnoir n’est pas loin

Maintenant, si mon interprétation de la « composition des relations » n'est pas la bonne, alors on efface tout et on recommence...

Merisier, je ne manquerai pas de répondre aux questions que vous avez posées, mais pour le moment il se fait tard, donc à demain...

**fsmrel** · 30/09/2014, 22h18

Bonsoir,

Envoyé par Merisier

Une traduction « mécanique » donne :

Code :

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

1
2
3
4
5
PROFESSEUR(_NumProf_, nom, prénom)
MATIÈRE(_NumMat_, NomMat)
STAGE(_NumMat_, _NumStage_, DateStage, Intitulé)
ENSEIGNER(_#NumProf_, _#NumMat_)
ANIMER(_#NumProf_, _#NumMat_, _#NumStage_)

Où, dans ANIMER, (_#NumProf_, _#NumMat_) référence la clé primaire d'ENSEIGNER.

Une traduction mécanique, disons au moyen d’un AGL, peut produire ce résultat, mais à condition que cet AGL permette que l’on mette en œuvre la contrainte d’inclusion : je suppose que c’est dans les cordes de WinDesign, mais en tout cas pas dans celles de son concurrent PowerAMC, qui ne propose rien quant aux contraintes d’inclusion et génère seulement une contrainte référentielle entre ANIMER et PROFESSEUR : on retrouve alors la possibilité d’avoir un professeur d'allemand animant à tort un stage de volley-ball. A nous de remplacer manuellement la contrainte référentielle générée par celle qui va bien, c'est-à-dire entre ANIMER et ENSEIGNER.

N.B. DB-MAIN permet certaines choses en matière d’inclusion, malheureusement je n’ai pas réussi à lui proposer une portée « composée » de deux associations. Pour mémoire, voici l’exemple donné par l’AGL :

Envoyé par Merisier

est-il possible de traduire le schéma conceptuel en schéma relationnel si STAGE n'est pas une entité faible, et si oui, comment ?

Voici le diagramme, le MLD proposé par PowerAMC tout à fait logiquement, mécaniquement :

Si vous ne touchez pas au diagramme (en remplaçant manuellement la contrainte référentielle entre ANIMER et PROFESSEUR par la contrainte référentielle entre ANIMER et ENSEIGNER), pour faire respecter la contrainte d’inclusion, ça sera au moyen de l’instruction CREATE ASSERTION (proposée par la norme SQL) : vous exprimerez en SQL la règle selon laquelle, lorsqu’on effectue la projection (sur les attributs NumProf, NumMat) de la jointure naturelle des tables ANIMER et STAGE, le résultat est un sous-ensemble de ENSEIGNER.

Exemple :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE ASSERTION INCLUSION_01 CHECK
    SELECT COUNT (*)
         FROM (SELECT NumProf, NumMat
               FROM   ANIMER AS x INNER JOIN STAGE AS y ON x.NumStage = y.NumStage 
               EXCEPT
               SELECT NumProf, NumMat
               FROM   ENSEIGNER) AS z 
      = 0 ;

Le problème est que les SGBD SQL renâclent à proposer l’instruction CREATE ASSERTION, il faudra donc en passer par des triggers, sachant que leur programmation varie d’un SGBD à l’autre.

Envoyé par Merisier

comment faire figurer ça sur un schéma relationnel ?

Nonobstant le dernier diagramme ci-dessus, dans le cadre de la théorie relationnelle, ou de SQL, on n’a pas la notion de diagramme (représentation graphique), donc chacun a la liberté de se servir de ses propres mickeys, mais ça reste des mickeys... Pour ma part j’au utilisé une des notations proposées par PowerAMC.

Envoyé par Merisier

ça évite une redondance d'information par rapport à la version avec STAGE comme entité faible.

Il n’y a pas de redondance d’information : dans le diagramme ci-dessous, l’attribut NumStage n’est jamais qu’un séquenceur relatif (c'est-à-dire que ses valeurs recommencent à 1 pour chaque Matière).

Comment placer cette contrainte ?

Schéma

Discussions similaires

Partager

Partager