Discussion :

[Invité]

Bonjour à tous,

Dans mon MCD, je dois modéliser les règles suivantes :
1) Un bâtiment est nécessairement situé dans une et une seule ville.
2) Un bâtiment est nécessairement d'un et d'un seul type de bâtiment.
3) Pour chaque couple (ville, type de bâtiment), une limite max peut être définie. Cette limite indique le nombre maximum de bâtiments de ce type que la ville peut accueillir.
4) Un bâtiment ne peut exister que si sa ville et son type ont une limite définie (cf. 3)

Le premier MCD attaché (le plus simple), est fait pour répondre aux règles 1, 2 et 3.

Dans le deuxième MCD, j'ai utilisé une contrainte d'inclusion pour tenter de répondre à la 4e règle. Mais je ne sais pas du tout si c'est correct.

Voici la manière dont j'interprète cette contrainte d'inclusion :
- soit un bâtiment B1, un type_bâtiment T1 et une ville V1
- si T1 est le type de B1
- ET si V1 est la ville de B1,
- alors il existe nécessairement une limite max pour le couple (T1, V1).

Est-ce que les merisiens que vous êtes peuvent admettre cette modélisation ? Si non, avez-vous mieux à me conseiller ?

Merci.

[Richard_35]

Bonjour Kéraunos,

Il me semble que le MCD joint suffirait car il y a des cardinalités 1,1 de Batiment vers Ville et vers Type : l'inclusion de Ville et Type est donc implicite.

Mais bon, je suis loin d'être un "merisien" de naissance...

[Invité]

Bonjour Richard_35,

Merci pour ta réponse.

On pourrait toujours, pourquoi pas, accepter cette convention dans la mesure où un bâtiment définit une ville ET un type de bâtiment (dépendance fonctionnelle directe).

Mais je n'ai encore jamais vu de contraintes d'inclusion ayant pour portée (ou pour cible) autre chose qu'un ensemble d'associations (en l'occurrence, une entité).

Mais peut-être est-ce toléré ?

[Richard_35]

Il est vrai que, n'étant pas "merisien" de naissance, je m'autorise, parfois, certaines libertés... un peu limites .

Mais peut-être est-ce toléré ?

==> CinéPhil ou Fsmrel (ou d'autres) pourront sans doute répondre, s'ils sont dans le coin .

Sinon, l'association "avoir limite" étant n,n, tu peux la transformer en entité.

Ville -0,n---[Avoir limite]---0,n- Type_Batiment

donne :

Ville(IdVille, Nom, ...)
TypeBatiment(IdTypeBatiment, Nom, ...)
Ville_TypeBatiment(#IdVille, #IdTypeBatiment, limite, ...)

donc :

Ville -0,n---[Avoir limite]---1,1- Ville_TypeBatiment
TypeBatiment -0,n---[Avoir limite]---1,1- Ville_TypeBatiment

[Invité]

D'accord, transformer une association binaire NN en une entité anticipe le passage aux modèles logique et physique (cette association devenant une relation). Mais du coup, la contrainte ne s'appuie plus que sur des entités, alors qu'elle devrait s'appuyer sur des associations. En fait, dans mon message précédent, c'était à l'entité Bâtiment comme portée de la contrainte que je pensais.

[Richard_35]

Bonjour Kéraunos,,

Tu as donc le choix entre une contrainte s'appliquant entre une entité et une association ou entre deux entités.

Je suis un peu juste pour désigner "la plus proche de la loi".

[Invité]

Bonjour Richard_35,

Merci pour tes réponses.

Bon, pour l'instant, tu as cherché à optimiser ma solution (la charger le moins possible en n'utilisant que les entités et associations qui font sens). Apparemment, cette première solution semble correcte, en tout cas tu ne m'as pas dit le contraire. Etant relativement débutant en conception de modèles de données, je préfère donc rester "au plus proche de la loi" en conservant la portée composée avec des associations.

Sauf si, bien sûr, on vient m'expliquer que c'est faux.

[CinePhil]

n'étant pas "merisien" de naissance, je m'autorise, parfois, certaines libertés... un peu limites

==> CinéPhil ou Fsmrel (ou d'autres) pourront sans doute répondre, s'ils sont dans le coin

Je suis plutôt "merisien de naissance" mais comme je n'ai pas encore eu vraiment l'occasion de modéliser des contraintes dans un MCD réel de mon cru, je suis encore timide avec ces capricieuses !

(Ça fait du bien de se rajeunir de plus de 30 ans par quelques allégories ! )

intuitivement, je dirais que la représentation de kéraunos dans son premier message est bonne, ainsi que son interprétation. Mais je passe la main à fsmrel qui aura sans doute un avis plus mature sur la question.

[fsmrel]

Bonsoir kéraunos, Richard et Philippe,


A mon tour, je passerais bien la patate chaude à JPhi33 !


La contrainte de kéraunos a une bonne tête, elle est dans l’orthodoxie puisque la portée (la paire d’associations {Est, Situé dans}) a pour cible une association (A limite). Le pivot est composé des entités-types qui participent à la fois à la portée et à la cible (Ville, Type Bâtiment). La contrainte est donc conforme à la définition donnée par les experts, à l'occasion de leur réunion du 10 novembre 1990 dans les locaux de L’Afcet :




Merci à vous de revérifier...


J’avoue pour ma part ne pas être toujours dans l’orthodoxie, car je ne dispose pas d’AGL qui, tel WinDesign, force à modéliser correctement ce genre de contrainte. Je donne le mauvais exemple en prenant des libertés et des raccourcis, par exemple en prenant des entités-types pour cibles... J’essaierai de m’amender.


En tout cas, une autre façon de prendre en compte la contrainte est d’utiliser la notation E/R (anglo-saxonne). Par exemple, avec Power AMC :




Ou, même avec Merise, comme amorcé par Richard (j’ai aussi une bonne excuse, car Power AMC ne permet pas de modéliser les contraintes) :




D’où le MLD :



A suivre...

[Invité]

Merci à tous pour vos réponses. Elles m'aident à progresser et à évoluer dans mon approche de la conception.

Je réalise que penser davantage "modèle relationnel" au stade conceptuel peut amener à simplifier les choses. En l'occurrence, je ne sais pas comment implémenter physiquement les contraintes d'inclusion (j'utilise le SGBD MySQL). Si je peux éviter l'écriture de triggers (dont les erreurs sont mal gérés, apparemment, par MySQL), je suis preneur.

Pour mon problème, je vais donc opter pour la solution de Richard_35, richement illustrée par fsmrel.

Je me permets de vous en soumettre un deuxième, un peu plus dur :
Un joueur se déplace dans une ville. Il s'agit de lui permettre d'accéder à certains quartiers et, à l'intérieur de ces quartiers, de rentrer dans certaines maisons.

Règles à modéliser :
1) Un joueur a accès à un ou plusieurs quartiers.
2) Une maison est dans un et un seul quartier.
3) Un joueur peut entrer dans des maisons.
4) Les maisons dans lesquelles un joueur peut entrer sont nécessairement dans les quartiers auxquels a accès le joueur.

La première solution (image attachée) s'appuie sur une contrainte d'inclusion. A la lumière de ce qui précède dans ce sujet, je pense qu'elle est bonne.

Je cherche maintenant une alternative, sans contrainte d'inclusion. La deuxième solution n'est pas satisfaisante car la règle n°4 peut être violée. Mais je suis peut-être près du but. Auriez-vous une idée ?

Merci.

[Richard_35]

Bonjour Kéraunos,

Une solution "tordue" , sans contrainte d'inclusion (donc, collant à ce que tu demandes)...

Code :

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

1
2
3
4
5
Joueur -0,n---[Accéder]---0,n- MaisonOuQuartier -0,1---[Être maison]-----(1,1)- Maison
                                     |                                            |
                                     |                                           (X)
                                     |                                            |
                                     +-----------0,1---[Être quartier]---(1,1)- Quartier

... mais avec une contrainte d'exclusion .

Donnant :

Joueur(IdJoueur, Nom, ...)
MaisonOuQuartier(IdMaisonOuQuartier, Nom, ...)
Quartier(#IdMaisonOuQuartier, ...)
Maison(#IdMaisonOuQuartier, #IdMaisonOuQuartier_Quartier, ...)

Joueur_MaisonOuQuartier(#IdJoueur, #IdMaisonOuQuartier, ...)

MaisonOuQuartier se comportant en "distributeur de clé primaire"...

Franchement pas terrible, car c'est adapter la modélisation à une discipline "hors sujet". Mais je ne vois rien d'autre.

La problématique d'autorisation à des sous-niveaux, compte tenu d'autorisation préalable au niveau "père" est toujours la même.

[CinePhil]

Rapidement, j'aurais plutôt une approche processus avec ce genre de problématique.

1) Ton utilisateur n'a accès qu'à certains quartiers (c'est enregistré en BDD).
2) Ton utilisateur se rend dans un quartier autorisé.
3) Tu ne présentes à ton utilisateur que les maisons du quartier où il se trouve.

De toute façon, je pense que c'est le genre de processus que tu mettras en oeuvre donc la contrainte sur les données en BDD est inutile.

Le petit renfort de sécurité que tu peux faire, c'est d'utiliser l'identification relative pour les maisons par rapport au quartier. Ainsi, tu pourras toujours contrôler par une requête que la maison est bien celle d'un quartier autorisé, à plus forte raison le quartier dans lequel se trouve ton utilisateur.

[Invité]

Bonjour Richard_35 et CinePhil, merci pour vos réponses.

@Richard_35 :
Dans cette solution, plusieurs choses me titillent :
- La règle n°2 n'est pas satisfaite au niveau du MCD (ou alors je ne l'ai pas compris).
- La règle n°1 dit qu'un joueur accède à au moins un quartier (je rajoute que ce quartier n'est pas un quartier par défaut propre à tous les joueurs), et rien n'oblige à ce qu'il accède à au moins une maison. Donc l'association Accéder du MCD ne semble pas concilier les règles n°1 et n°3.
- Si je devais utiliser une contrainte d'exclusion, je la ferais porter sur les associations Etre maison et Etre quartier.
- Je ne discerne pas ce qui empêche un joueur d'accéder à une maison ne faisant pas partie des quartiers auxquels ce joueur peut accéder (règle n°4).

@CinePhil :
C'est vrai qu'en l'occurrence, avec mon exemple de jeu vidéo, on peut penser que ces contraintes sont superflues au niveau du modèle de données. Le modèle sur lequel je travaille réellement n'a rien à voir, sémantiquement. Je m'efforce juste de dépouiller mes problèmes de la complexité d'un contexte particulier. Ce qui importe ici, ce sont les règles. Pas la sémantique globale.
En réalité, il faudrait remplacer Joueur par Abonnement, Quartier par Langue et Maison par Rubrique : un abonnement a au moins une langue mais peut être multilingue ; pour chaque langue, l'application propose des rubriques propres à la langue ; un abonnement permet d'accéder à n'importe quelle rubrique au sein de celles que propose(nt) sa(ses) langue(s) ; quand l'administrateur du backoffice retire une langue à un abonnement, alors les permissions (rubriques) correspondantes sont supprimées, etc.

[fsmrel]

Bonsoir,


Au sujet du 1er problème présenté par kéraunos :

On est donc d’accord que le MLD ci-dessous résout le problème de la contrainte d’inclusion, sans avoir besoin de mettre en œuvre un quelconque trigger : les clés étrangères suffisent.




Pour le 2e problème posé, on peut à nouveau chercher une solution dans laquelle ne sont impliquées que les clés étrangères :

Renommons en ACCES_QUARTIER l’entité-type associative ACCES proposée par kéraunos. Pour varier les plaisirs, je propose cette fois-ci qu’on parte de la suggestion de CinePhil, à savoir identifier l’entité-type MAISON relativement à QUARTIER. On peut ensuite définir une entité-type associative, appelons-la ACCES_MAISON, permettant de connecter ACCES_QUARTIER et MAISON :




Le MLD correspondant est le suivant :




Où l’attribut QuartiedId figure simultanément dans les deux clés étrangères <fk1> et <fk2> (table ACCES_MAISON), ce qui permet de garantir la contrainte d'inclusion par le biais de l’intégrité référentielle.


Code SQL :

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 JOUEUR (
   JoueurId             INT                  NOT NULL,
   JoueurNom            VARCHAR(64)          NOT NULL,
   CONSTRAINT JOUEUR_PK PRIMARY KEY (JoueurId)
) ;
 
CREATE TABLE QUARTIER (
   QuartierId           INT                  NOT NULL,
   QuartierNom          VARCHAR(64)          NOT NULL,
   CONSTRAINT QUARTIER_PK PRIMARY KEY (QuartierId)
) ;
 
CREATE TABLE MAISON (
   QuartierId           INT                  NOT NULL,
   MaisonId             INT                  NOT NULL,
   MaisonAdresse        VARCHAR(64)          NOT NULL,
   CONSTRAINT MAISON_PK PRIMARY KEY  (QuartierId, MaisonId),
   CONSTRAINT MAISON_QUARTIER_FK FOREIGN KEY (QuartierId)
      REFERENCES QUARTIER (QuartierId)
) ;
 
CREATE TABLE ACCES_QUARTIER (
   JoueurId             INT                  NOT NULL,
   QuartierId           INT                  NOT NULL,
   CONSTRAINT ACCES_QUARTIER_PK PRIMARY KEY (JoueurId, QuartierId),
   CONSTRAINT ACCES_QUARTIER_JOUEUR_FK FOREIGN KEY (JoueurId)
      REFERENCES JOUEUR (JoueurId),
   CONSTRAINT ACCES_QUARTIER_QUARTIER_FK FOREIGN KEY (QuartierId)
      REFERENCES QUARTIER (QuartierId)
) ;
 
CREATE TABLE ACCES_MAISON (
   JoueurId             INT                  NOT NULL,
   QuartierId           INT                  NOT NULL,
   MaisonId             INT                  NOT NULL,
   CONSTRAINT ACCES_MAISON_PK PRIMARY KEY (JoueurId, QuartierId, MaisonId),
   CONSTRAINT ACCES_MAISON_MAISON_FK FOREIGN KEY (QuartierId, MaisonId)
      REFERENCES MAISON (QuartierId, MaisonId),
   CONSTRAINT ACCES_MAISON_ACCES_QUARTIER_FK FOREIGN KEY (JoueurId, QuartierId)
      REFERENCES ACCES_QUARTIER (JoueurId, QuartierId)
) ;

Un début de jeu d’essai :

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
INSERT INTO JOUEUR (JoueurId, JoueurNom) VALUES (1, 'Kéraunos') ;
INSERT INTO JOUEUR (JoueurId, JoueurNom) VALUES (2, 'Richard') ;
INSERT INTO JOUEUR (JoueurId, JoueurNom) VALUES (3, 'Philippe') ;
INSERT INTO JOUEUR (JoueurId, JoueurNom) VALUES (4, 'François') ;
 
INSERT INTO QUARTIER (QuartierId, QuartierNom) VALUES (1, 'Quartier I') ;
INSERT INTO QUARTIER (QuartierId, QuartierNom) VALUES (2, 'Quartier II') ;
INSERT INTO QUARTIER (QuartierId, QuartierNom) VALUES (3, 'Quartier III') ;
INSERT INTO QUARTIER (QuartierId, QuartierNom) VALUES (4, 'Quartier IV') ;
 
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (1, 1, 'Maison du pinard') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (1, 2, 'Maison du billard') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (1, 3, 'Maison blanche') ;
 
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (2, 1, 'Cabane Bambou') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (2, 2, 'Cabane au Canada') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (2, 3, 'Cabane à Mimile') ;
 
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (3, 1, 'Palais royal') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (3, 2, 'Palais des congrès') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (3, 3, 'Palais des glaces') ;
 
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (4, 1, 'Bistrot du coin') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (4, 2, 'Bistrot chez Paulo') ;
INSERT INTO MAISON (QuartierId, MaisonId, MaisonAdresse) VALUES (4, 3, 'Bistrot de la poste') ;
 
INSERT INTO ACCES_QUARTIER (JoueurId, QuartierId) VALUES (1, 1) ; -- Kéraunos / Quartier I
INSERT INTO ACCES_QUARTIER (JoueurId, QuartierId) VALUES (1, 2) ; -- Kéraunos / Quartier I
 
INSERT INTO ACCES_MAISON (JoueurId, QuartierId, MaisonId) VALUES (1, 1, 1) ; -- Kéraunos / Quartier I / Maison du pinard 
INSERT INTO ACCES_MAISON (JoueurId, QuartierId, MaisonId) VALUES (1, 2, 1) ; -- Kéraunos / Quartier II / Cabane Bambou 
 
 
SELECT '' AS JOUEUR, * FROM JOUEUR ;
SELECT '' AS QUARTIER, * FROM QUARTIER ;
SELECT '' AS MAISON, * FROM MAISON ;
SELECT '' AS ACCES_QUARTIER, * FROM ACCES_QUARTIER ;
SELECT '' AS ACCES_MAISON, * FROM ACCES_MAISON ;

Je parie une poignée de main contre une poignée de porte que vous aurez du mal à violer la contrainte selon laquelle un joueur ne peut accéder qu’aux maisons qui se situent dans un quartier qu’il a le droit de fréquenter...

[Invité]

Fsmrel, droit au but, l'art de la synthèse. Merci.

L'intégrité référentielle, c'est donc le Saint Graal que je cherchais. S'interprète-t-elle également au niveau du formalisme merisien, cette intégrité ? Si oui, en plus de mon MLD, je vais revoir mon MCD pour faire disparaître ces vilaines contraintes d'inclusion (façon de parler, hein, c'est plus ce qu'elles impliquent au niveau physique qui est vilain).

Je note que 50% des maisons auxquelles j'accède dans cette base ont un rapport avec le pinard. Super !

[fsmrel]

Bonsoir,

L'intégrité référentielle, c'est donc le Saint Graal que je cherchais.

Hum... Disons que l'intégrité référentielle permet souvent de résoudre les problèmes posés par les contraintes d’inclusion, mais elle n’est pas la panacée.

Par ailleurs, si on dérive (du moins avec Power AMC) le MCD que j’ai proposé en MLD, le résultat brut est le suivant :



On ne peut pas en vouloir à l’AGL d’avoir défini deux attributs de type Quartier pour la table ACCES_MAISON, car a priori on peut très bien lire les choses ainsi :

Un joueur peut avoir accès à certains quartiers tout en fréquentant des maisons d’autres quartiers.

Deux solutions pour garantir la contrainte d’inclusion.

1) Définir une contrainte pour la table ACCES_MAISON : QuartierId = QuartierId_2 (voyez la contrainte ACCES_MAISON_INCLUSION dans le code SQL ci-dessous) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE ACCES_MAISON (
   JoueurId             INT                  NOT NULL,
   QuartierId           INT                  NOT NULL,
   QuartierId_2         INT                  NOT NULL,
   MaisonId             INT                  NOT NULL,
   CONSTRAINT ACCES_MAISON_PK PRIMARY KEY (JoueurId, QuartierId, QuartierId_2, MaisonId),
   CONSTRAINT ACCES_MAISON_MAISON_FK FOREIGN KEY (QuartierId_2, MaisonId)
      REFERENCES MAISON (QuartierId, MaisonId),
   CONSTRAINT ACCES_MAISON_ACCES_QUARTIER_FK FOREIGN KEY (JoueurId, QuartierId)
      REFERENCES ACCES_QUARTIER (JoueurId, QuartierId),
   CONSTRAINT ACCES_MAISON_INCLUSION CHECK (QuartierId = QuartierId_2)
) ;

2) N’avoir qu’un seul attribut QuartierId.

Le bon sens conduit évidemment à retenir la 2e solution.

S'interprète-t-elle également au niveau du formalisme merisien, cette intégrité ?

On peut répondre affirmativement, car chaque clé étrangère du MLD est la traduction d’une cardinalité maximum 1 portée par une patte d’association dans le MCD. Inversement, par rétro-conception un MLD doit redonner le MCD du départ, sauf quand bien entendu on a bricolé modifié la composition des clés étrangères, comme je l’ai fait...

Si oui, en plus de mon MLD, je vais revoir mon MCD pour faire disparaître ces vilaines contraintes d'inclusion.

Vu ce qui précède, vous comprendrez qu’il faut surtout conserver les contraintes d’inclusion du MCD, qu’elles soient esthétiques ou pas, sinon il y aurait une perte dommageable au plan sémantique (cela vaut du reste pour l’exemple traitant des bâtiments et des villes)...

[Invité]

Le bon sens conduit évidemment à retenir la 2e solution.

Le bon sens sans doute, mais surtout le fait que j'utilise le SGBD MySQL, qui ne comprend pas les contraintes CHECK.

On peut répondre affirmativement [...]

Vu ce qui suit dans votre réponse, je comprends surtout qu'on peut répondre par la négative et qu'il vaut mieux conserver les contraintes d'inclusion, qui lèvent toute ambiguïté sémantique. Conseil que je vais suivre, ce qui nous donne donc le MCD attaché (les identifications relatives pour ACCES_QUARTIER n'y sont peut-être pas utiles).

Mais ma question était : si, à partir de l'entité-type ACCES_MAISON, on suit bêtement les cardinalités (1,1) (ou (0,1)) (identification relative) jusqu'à l'entité-type QUARTIER, alors, quel que soit le chemin suivi, doit-on toujours trouver la même entité QUARTIER pour une entité ACCES_MAISON donnée ? Si c'est comme cela qu'il faut lire le MCD ci-dessous, alors les contraintes d'inclusion sont superflues.


Par ailleurs, j'estime moins évident le besoin de conserver ces contraintes d'inclusion dans le MCD du premier problème (pas d'écueil sémantique, dans ce cas). Mais on peut les conserver tout de même pour la clarté qu'elles apportent.

[JPhi33]

Bonjour à tous,

A mon tour, je passerais bien la patate chaude à JPhi33 !

Concernant cette question, la modélisation de la contrainte d'inclusion est correcte sur ce schéma

et elle signifie très exactement la règle de Kéraunos

4) Un bâtiment ne peut exister que si sa ville et son type ont une limite définie

A noter que l'outil de modélisation matérialise les pivots de la contrainte (VILLE, TYPE_BATIMENT) bien que cela ne soit pas nécessaire, ces deux entités étant les pivots implicites de la contrainte.

La source et la cible des contraintes sémantiques sont des associations et non des entités. La proposition de Richard (post #2) est en contradiction avec ce principe.

[Richard_35]

Bonjour à tous,

Et merci, JPhi33, j'en prend bonne note .

[fsmrel]

Bonsoir,


Reprenons votre MCD :



Tout bon connaisseur de Merise verra tout de suite que l’entité-type ACCES_QUARTIER est une association-type déguisée pour des raisons de facilité de dérivation en MLD (en tant que DBA responsable, je plaide coupable... ) Ce MCD est donc un modèle hybride, et conceptuellement parlant il est légitime d’en revenir à un MCD non dénaturé du point de vue de la sémantique et où l’association-type doit réapparaître en lieu et place de l’entité-type. Ceci vaut d’autant lorsque l’AGL (par exemple WinDesign) sait ce qu’est une contrainte d’inclusion, et c’est tout bon s’il est en plus capable de générer le MLD que j’ai présenté. Mais, s’il génère autre chose, alors d’accord pour doubler éventuellement le MCD pur par le MCD hybride que j’ai présenté bille en tête (je prends ma casquette d’utilisateur de Power AMC, et me justifie avec plus ou moins de bonne foi, au motif que cet AGL ne permet pas de représenter une contrainte d’inclusion).

Toutes choses égales, cette remarque vaut pour le tout 1er MCD.

Accessoirement, je pense que même avec WinDesign il faudra soit produire le MLD à partir d’un MCD hybride en plus du MCD pur, soit revoir complètement le MLD directement généré à partir du MCD pur (mais cela représente en fait généralement plus de travail, notamment en ce qui concerne la modification de la constitution des clés étrangères).

J’en profite pour soumettre à votre réflexion l’exemple suivant, figurant aux pages 413-414 de l’ouvrage de D. Nanci et Bernard Espinasse Ingénierie des systèmes d’information Merise, deuxième génération (troisième édition) chez Sybex :

MCD proposé :



Contrainte :

« Pour qu’un professeur enseigne une matière à une classe donnée, il faut qu’il sache enseigner cette matière ».

MLD proposé :




Et pour implanter la contrainte, il est proposé le trigger (ORACLE) 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
CREATE TRIGGER Inclusion_Enseigner_QUALIFIER
BEFORE INSERT ON Enseigner
    ON EACH ROW
    DECLARE
        est_qualifié  number;
    BEGIN
        SELECT COUNT(*) INTO est_qualifié FROM Qualifier
        WHERE noprofesseur = :new.noprofesseur
          AND nomatiere = :new.nomatiere ;
        IF Est_qualifié = 0 THEN
            raise_application_error (-2007, 'Ce professeur n’est pas qualifié pour cette matière') ;
        END IF ;
    END ;

Pourquoi pas... Cependant, ce trigger suffit-il ? Certes non, car si l’on supprime une paire {nomatiere, noprofesseur} dans la table QUALIFIE, m’est avis que la contrainte est forcément violée, ce qui peut aussi se produire si on modifie la valeur de la paire, même chose si l’on modifie les valeurs du triplet {noclasse, noprofesseur, nomatiere} de la table ENSEIGNER : il y aura encore du pain sur la planche et de la sueur à éponger en perspective. Je ne parle même pas de la portabilité d’un SGBD à l’autre : en effet ce trigger n’est en rien compris à ce jour par MS SQL Server, pour qui il est donc bon pour la poubelle...

Vu du DBA, on peut s’en sortir à nouveau avec la seule intégrité référentielle au niveau MLD :



Ça simplifie quand même pas mal de choses, ça représente de bonnes économies en développement, en maintenance, en fiabilité, et les performances y trouveront leur compte. Merci M. le DBA...

Si c'est comme cela qu'il faut lire le MCD ci-dessous, alors les contraintes d'inclusion sont superflues.

Ça n’est pas comme cela qu’il faut lire le MCD, mais plutôt comme je l’ai écrit dans mon message précédent, à propos du MLD brut de décoffrage produit par Power AMC :

Un joueur peut avoir accès à certains quartiers et fréquenter des maisons d’autres quartiers.

Ce qui n’est quand même pas ce qu’on attend...

on suit bêtement les cardinalités (1,1) (ou (0,1)) (identification relative)

Attention, si on utilise l’identification relative, le cas (0,1) n’a pas de sens, je vous laisse réfléchir au pourquoi de la chose.