Discussion :

[alicc]

En annexe, deux visions de l'analyse des cardinalités dans les ASSOC NON BINAIRES.

Le premier document est issu de Cyril Gruau, le second d'un ouvrage sur UML.
Quelle est la différence apparente ?

Dans le premier, les cardinalités sont analysées toujours par groupes de 2 entités tandis que le deuxième document plaide pour la prise en compte de la 3ème (/nième) par rapport à une occurrence des 2 (/n-1) autres.

Petit exemple : soit les entités
COMMANDES - PRODUITS - DATE
liées par une relation ternaire.

Est-ce comparable de réfléchir à la cardinalité
COMMANDE - PRODUITS sans s'occuper de DATE
par rapport à la question:
pour une occurrence COMMANDE-DATE, quelle est la cardinalité vis-à-vis de PRODUITS ?

Pour moi, il peut y avoir des différences sémantiques...
Qui a un avis ? Merci.

[fsmrel]

Bonsoir,


Dans un premier temps...

Le premier document est issu de Cyril Gruau, le second d'un ouvrage sur UML. [...] Dans le premier, les cardinalités sont analysées toujours par groupes de 2 entités

Je ne sache pas que Cyril Gruau analyse les cardinalités par groupes de deux entités-types. Il constate seulement que l’entité-type PROJECTION est cernée par trois associations-types telles que les cardinalités des pattes connectant PROJECTION et ces trois associations-types sont 1,1. De ce constat il déduit que l’entité-type PROJECTION peut à juste titre être transformée en association-type ternaire. Qui plus est, comme avec Merise une association-type peut être directement porteuse de propriétés (attributs), il n’y a aucun problème pour procéder à la transformation.

Cela dit, d’après ma propre expérience, les concepteurs modélisent d’abord l’association-type ternaire et le cas échéant, s'ils la transforment en entité-type, c'est plutôt pour des contraintes techniques (participation de l’association-type à une autre association-type) voire à l'occasion pour des motifs d’ordre émotionnels (si le chef qui n’y connaît rien mais se pique de modéliser, sent que la chose a sémantiquement une odeur d’entité-type, c’est forcément lui qui a raison).

Quoi qu’il en soit, lors de la dérivation du MCD en MLD, les quatre objets-types donnent lieu à des tables : l'alternative conceptuelle, entité-type ou association-type, n'a donc pas de conséquences à ce stade.

Une remarque concernant le MCD de Cyril Gruau :

Si l’on projette le film F1 dans la salle S1 dans le créneau C1, rien n’interdit que l’on projette aussi le film F2 dans la salle S1 dans le créneau C1. Comme le créneau C1 détermine une date (disons D1) et une heure de début de projection (disons H1), il apparaît qu’au même moment (D1, H1) on pourrait projeter les deux films F1 et F2 dans la salle S1...

Concernant la date figurant dans le document UML, ce dernier n'est pas bavard : de quelle date s'agit-il ? Celle de livraison des produits ? La réflexion a besoin de s'appuyer sur du concret...

Je vais faire dodo. A suivre...

[fsmrel]

Bonjour,


Une précision concernant le MCD de Cyril Gruau.

Comme dans le cas du diagramme de classes des commandes, il faudrait plus de précisions sur le rôle joué par la date. Dans le cas des commandes, on se perd en conjectures sur sa signification (date de livraison, date de retour de produits, ...), sur celle du verbe « demander ».

Dans le cas des projections cinématographiques, une interprétation peut être la suivante :

Citizen Kane sera projeté dans la salle Rex le mardi 25 octobre 2011 à 16 heures au tarif de 5 euros,
Citizen Kane sera projeté dans la salle Rex le mardi 25 octobre 2011 à 20 heures au tarif de 8 euros.

Et la situation peut devenir cocasse, puisque rien n’interdit de poursuivre ainsi l’interprétation :

Un singe en hiver sera projeté dans la salle Rex le mardi 25 octobre 2011 à 16 heures au tarif de 6 euros.

Maintenant, si les dates ne sont pas des dates du calendrier, mais plutôt des jours de la semaine (le lundi, le mardi, ...) et supposons qu’un film tienne l’affiche plusieurs semaines. Ce qui suit est alors plausible :

Citizen Kane pourra être projeté dans la salle Rex les mardis à 16 heures au tarif de 5 euros,
Un singe en hiver pourra être projeté dans la salle Rex les mardis à 16 heures au tarif de 6 euros.

En effet, à tour de rôle, tel mardi ça sera Citizen Kane, le mardi suivant Un singe en hiver, etc.

=>

De l’importance de fournir des exemples, car chacun interprète à sa façon un diagramme, c'est-à-dire l’abstraction. L’ambiguïté est un des maux connus dans l’élaboration des diagrammes conceptuels et des diagrammes de classes.

Ça n’est pas pour rien que dans l’ouvrage de référence sur Merise : La Méthode Merise, Tome 1, Principes et outils, les auteurs n’hésitent pas à tartiner de nombreux exemples dans l’annexe A de cet ouvrage (Exemple du Bureau d’immatriculation des véhicules), dans le genre :

« Le véhicule 100 DFZ 75 fut livré au Garage du Rond-Point le 15 février 1979, mais fut détruit le même jour. Les deux autres véhicules furent vendus à MM. Dupond et Dupont le 28 février 1979. M. Dupond mourut dans un accident avec le véhicule 102 DFZ 75 le 5 mars 1979...»

[alicc]

1. Merci pour les réponses

2. Mes conclusions :
(a) 100.000% d'accord pour condamner cette manie de mettre DATE comme attribut sans spécifier dans une phrase correcte les entités rattachées.
Bon ex : la date = la date à laquelle un client X a acheté le produit Y en provenance du fournisseur Z.
(b) Mon avis est que ce sont principalement les associations "les plus centrales" qui doivent se voir affecter les attributs de type DATE, QUANTITE, PRIX (dans les applis business, je précise). En effet, c'est là que la granularité du modèle est la plus fine et la plus intéressante (sauf si elle s'avérait inutile pour le projet).
(On pourrait penser que Cyril a ajouté la date en catastrophe. Il y a d'ailleurs une note en marge. Moi, je l'aurais mise dans l'association directement...)
(c) Souvent la date est utilisée pour garantir l'unicité de la clé composée des associations. Il me semble qu'il faudrait réfléchir plus souvent à d'autres solutions : clé arbitraire, GUID, création d'une clé différente (voir mon autre discussion ouverte à partir du même sujet)
(d) NOTE : Dans le cas des projections, DATE+SALLE devraient faire l'objet d'une contrainte d'unicité pour éviter le problème des 'doubles projections dans une même salle' par ex...

Je suis d'accord avec fmrel pour dire que dans la pratique, le problème se pose plutôt dans l'autre sens càd qu'on part d'associations ternaires ou plus tandis que l'article de Cyril explique comment 'réorganiser' un bouquet de relations binaires.

MAIS
Tout ceci ne répond pas à ma question originelle : comment interpréter les cardinalités des ASSOC > 2.

Mon opinion perso est que l'appoche du bouquin UML est meilleure, considérant toujours la question des cardinalités d'une occurrence de n-1 entités par rapport à la nième.
Tant qu'on ne 'joue' pas avec des cardinalités 0...
Car celles-ci méritent / provoquent une description séparée à elles seules.

Pourquoi mon choix ? Parce qu'il oblige à réfléchir en prenant en compte toutes les entités 'périphériques' concernées (et non 2 à 2).

?

[fsmrel]

Bonsoir,

comment interpréter les cardinalités des ASSOC > 2.
Mon opinion perso est que l'approche du bouquin UML est meilleure

Reprenons ce qu’écrit Cyril Gruau dans son article :

« La difficulté de concevoir une association ternaire (ou plus) directement est d’établir les bonnes cardinalités. Il est donc conseillé d’en passer par un schéma entités-associations dans lequel on ne trouve que des associations binaires, puis de repérer les entités remplaçables par des associations [...] »

Comme je l’ai déjà fait observer, cette approche n’est pas celle qui est habituelle et l’approche prédicative sous-tendue par l’exemple des commandes y est de facto sans objet. Dans la masse des travaux de conception auxquels j’ai participé, j’ai toujours vu les concepteurs raisonner directement en termes de relations et donc énoncer les règles de gestion sous forme prédicative. Pour reprendre spécifiquement l’exemple des projections de films (les paramètres d’un prédicat sont en l’occurrence film, salle, créneau horaire), on peut interpréter les cardinalités ainsi :

Pour une salle et un film donnés, on peut projeter selon plusieurs créneaux horaires,
Pour un film et un créneau horaire donnés, on peut projeter dans plusieurs salles,
Pour une salle et un créneau horaire donnés, on ne projette qu’un et un seul film.

Et pour cet exemple, l’approche qui a votre préférence vous permet de marquer un point : elle permet de mettre en évidence la contrainte qui veut que dans une salle donnée, à un instant donné on ne peut pas projeter plus d’un film.

Retenons donc que si l’on utilise la méthode Gruau, il faut aussi se servir de la preuve par neuf que représente la méthode qui a votre faveur.

Pour la petite histoire, en Merise la contrainte qui a été mise en évidence est modélisable au moyen d’une CIF (contrainte d’intégrité fonctionnelle, symbolisée par la flèche rouge) :



Par ailleurs, la ternaire se justifie-elle ? On doit pouvoir par exemple produire le diagramme de classes suivant :



Et si en Merise on utilise l’identification relative (symbolisée ici par la mise entre parenthèses de la cardinalité 1,1), à la représentation avec CIF on pourra préférer la représentation suivante (la ternaire disparaît là aussi) :


Le MLD dérivé de ces différents diagrammes est le suivant, où l’on voit bien que la ternaire n’y figure pas et, last but not least, que l’attribut NoFilm n’appartient pas à la clé {NoSalle, DateProjection, HeureDebut} de la table PROJECTION :

Pourquoi mon choix ? Parce qu'il oblige à réfléchir en prenant en compte toutes les entités 'périphériques' concernées (et non 2 à 2).

Certes, mais on peut raisonner en considérant simultanément les 3 entités-types SALLE, FILM, CRENEAU et laisser passer la contrainte qui veut que pour une salle et un créneau horaire donnés, il n’y ait la projection que d’un seul film. Exemple :

Un film donné peut être projeté dans plusieurs salles selon plusieurs horaires,
A une heure donnée plusieurs films peuvent être projetés dans plusieurs salles,
Dans une salle donnée, il peut y avoir plusieurs films projetés selon plusieurs horaires.

Mon avis est que ce sont principalement les associations "les plus centrales" qui doivent se voir affecter les attributs de type DATE, QUANTITE, PRIX (dans les applis business, je précise). En effet, c'est là que la granularité du modèle est la plus fine et la plus intéressante

En fait ce sont les règles de gestion des données qui imposent que les attributs figurent dans telle ou telle entité-type (ou association-type). Et surtout, c’est la normalisation (au sens coddien) qui permet de s’assurer de la qualité des structures des tables résultant du travail de modélisation (je me situe à ce propos au niveau relationnel).

[CinePhil]

Le projectionniste que je fus approuve le modèle merisien avec identification relative !

Nous parlions alors de "séance" ayant lieu tel jour à telle heure dans telle salle et projetant tel film. Une copie d'un film n'était alors diffusé que dans une seule salle mais avec les cinémas multi-salles qui ont été construits plus récemment, il était devenu possible de projeter une même copie de film dans plusieurs salles. Ainsi, lors de son inauguration, le Gaumont Labège, près de Toulouse, a diffusé le même film dans toutes les salles en même temps.

Aujourd'hui, à l'ère du numérique, le film peut encore plus facilement changer de salle d'une séance à l'autre ou être diffusé dans plusieurs salles en même temps puisqu'il est diffusé à partir d'un serveur.

Néanmoins, le concept de séance tel que je l'ai défini plus haut reste valable et le modèle proposer n'a pas à être changé puisque rien n'y interdit à un film d'être projeté plusieurs fois pour différentes projections à la même heure... mais dans différentes salles, d'où l'importance de l'identification relative.

[fsmrel]

In petto, je me disais : Mais où est donc CinePhil ?

Nous parlions alors de "séance"

Merci pour cette précision, la sémantique y trouve son compte, j’achète !

d'où l'importance de l'identification relative

Mais la représentation avec CIF est tout aussi valable, puisque le MLD produit est le même, que l’on utilise l’identification relative ou la CIF. Le choix dépend par exemple de l’outil de modélisation. Ainsi, avec WinDesign, pas de problème, les deux techniques sont possibles, par contre Power AMC et Open ModelSphere permettent d’utiliser nommément seulement l’identification relative. Si l’on fait abstraction de ces contingences bassement matérielles, je connais plus d’un concepteur penchant pour la CIF, pour des raisons disons sémantiques et/ou affectives (mise en évidence de la ternaire )...

[pachot]

Bonjour,

Les cardinalités Merise n'ont pas le même sens que les multiplicités UML.
En relation binaire, on a juste l'impression que c'est inversé. Mais en relation ternaire, on voit la différence de sens.

- la cardinalité Merise donne le nombre d'instances possibles par rapport à l'association:

Un film est concerné par plusieurs projections. Une salle est concernée par plusieurs projections, etc.

- la multiplicité UML donne le nombre d'instances de la classe par rapport aux autres classes associées. A une date donnée une commande donnée peut concerner plusieurs produits.

Dans les 2 cas, ce n'est souvent pas assez préciser toutes les dépendences fonctionelles. En Merise, on rajoute des CIF. En UML des contraintes OCL.

Et au final, dans le modèle relationnel, cela se traduira par des contraintes d'unicité sur une partie des colonnes de la table qui implémente l'association. (A condition de ne pas avoir troqué les références aux clés naturelles composites par des références à une clé de technique de remplacement)

Cordialement,
Franck.

[fsmrel]

Bonsoir,

la cardinalité Merise donne le nombre d'instances possibles par rapport à l'association.

Certes. Je cite par exemple l’ouvrage de référence La Méthode Merise, Tome 1, Principes et outils dont j’ai fait mention plus haut :

« La cardinalité-minimum est le nombre minimum de fois où chaque occurrence d’un individu-type est impliquée dans une occurrence de relation-type [...]. La cardinalité-maximum est le nombre maximum de fois où chaque occurrence d’un individu-type peut être impliquée dans une occurrence de relation-type [...] »

D'où, à l'attention de alicc :

En ce sens, s’il formule la règle suivante : « Une salle peut être impliquée plusieurs fois dans l’association-type PROJETER », celui qui est chargé de rédiger le dossier de conception se conforme à la Méthode, il est dans l’orthodoxie. Toutefois, plutôt que de différer la recherche des dépendances fonctionnelles et autres CIF, serait-il à blâmer s’il formulait directement la règle : « Pour une salle et un créneau horaire donnés, on ne projette qu’un et un seul film » ?
Cette règle peut être symbolisée sous forme de DF : SALLE X HORAIRE -> FILM, et il est implicite que la paire {SALLE, HORAIRE} ne donne pas lieu aux DF : SALLE -> HORAIRE et/ou HORAIRE -> SALLE, autrement dit les cardinalités portées par les pattes connectant PROJETER à SALLE et HORAIRE sont forcément 0,N. Mais il est vrai que la formulation de cette règle en français n’est peut-être pas à mettre entre toutes les mains, vu son caractère elliptique. Dans les dossiers de conception, il y a déjà assez comme cela de règles délicates à interpréter...

Quoi qu’il en soit, la règle est à prendre en compte au plus tôt dans le MCD. Pour mémoire, je rappelle qu’elle y est formulée sous forme de CIF (ou de DF, peu importe) :

Et au final, dans le modèle relationnel, cela se traduira par des contraintes d'unicité sur une partie des colonnes de la table qui implémente l'association.

Vous suggérez donc que le code SQL serait 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
CREATE TABLE PROJECTION 
(
   NoSalle              INT                  NOT NULL,
   DateProjection       DATE                 NOT NULL,
   HeureDebut           INT                  NOT NULL,
   NoFilm               INT                  NOT NULL,
   Tarif                INT                  NOT NULL,
   CONSTRAINT PROJECTION_PK PRIMARY KEY (NoSalle, DateProjection, HeureDebut, NoFilm),
   CONSTRAINT PROJECTION_CC UNIQUE (NoSalle, DateProjection, HeureDebut),
   CONSTRAINT PROJECTION_SALLE FOREIGN KEY (NoSalle) REFERENCES SALLE (NoSalle),
   CONSTRAINT PROJECTION_FILM FOREIGN KEY (NoFilm) REFERENCES FILM (NoFilm)
) ;

Code qui mériterait d’être sérieusement revu (rasoir d'Ockham...) puisque la clé primaire de la table serait une surclé mais pas une clé candidate. En effet, au niveau du diagramme logique, ces contraintes d’unicité font en fait directement l’objet de clés candidates, comme dans l’exemple que j’ai déjà fourni :


Le code SQL qui suit exprime bien la dépendance fonctionnelle coddienne {NoSalle, DateProjection, HeureDebut} -> {NoFilm}, exprimée par la clé primaire de la table :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE PROJECTION 
(
   NoSalle              INT                  NOT NULL,
   DateProjection       DATE                 NOT NULL,
   HeureDebut           INT                  NOT NULL,
   NoFilm               INT                  NOT NULL,
   Tarif                INT                  NOT NULL,
   CONSTRAINT PROJECTION_PK PRIMARY KEY (NoSalle, DateProjection, HeureDebut),
   CONSTRAINT PROJECTION_SALLE FOREIGN KEY (NoSalle) REFERENCES SALLE (NoSalle),
   CONSTRAINT PROJECTION_FILM FOREIGN KEY (NoFilm) REFERENCES FILM (NoFilm)
) ;

A condition de ne pas avoir troqué les références aux clés naturelles composites par des références à une clé de technique de remplacement

Pas d’accord. Du moment qu’on définit une 2e clé, les contraintes existantes ne doivent pas être évacuées. Le code SQL qui suit en tient compte :

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 TABLE PROJECTION 
(
   NoProjection         INT                  NOT NULL,
   NoSalle              INT                  NOT NULL,
   DateProjection       DATE                 NOT NULL,
   HeureDebut           INT                  NOT NULL,
   NoFilm               INT                  NOT NULL,
   Tarif                INT                  NOT NULL,
   CONSTRAINT PROJECTION_PK PRIMARY KEY (NoProjection),
   CONSTRAINT PROJECTION_AK UNIQUE (NoSalle, DateProjection, HeureDebut),
   CONSTRAINT PROJECTION_SALLE FOREIGN KEY (NoSalle) REFERENCES SALLE (NoSalle),
   CONSTRAINT PROJECTION_FILM FOREIGN KEY (NoFilm) REFERENCES FILM (NoFilm)
) ;

[pachot]

Bonjour fsmrel,

Pas d’accord. Du moment qu’on définit une 2e clé, les contraintes existantes ne doivent pas être évacuées.

Oui, bien sûr. Je ne parlais pas d'évacuer des contraintes. Je parlais de références (clés étrangères). Juste de manière théorique puisque on parlait des CIF ou OCL et de leur implémentation relationelle.
S'il y avait une table qui référencait PROJECTION, alors on aurait le choix de référencer (NoProjection) ou (NoSalle, DateProjection, HeureDebut). Et il y a des cas où l'implémentation de dépendences fonctionnelles, par des contraintes sur les tables filles, n'est possible que si on référence la clé composite.
Mais ce n'était pas lié à cet exemple, et du coup ça devient hors sujet...
Cordialement,
Franck.

[fsmrel]

Bonjour Franck,

Je ne parlais pas d'évacuer des contraintes. Je parlais de références (clés étrangères).

Faut-il interpréter la 2e phrase ainsi :

« Je parlais d’évacuer des références (clés étrangères) » ?

Si c’est le cas, je rappelle ceci : qui dit clé étrangère, dit contrainte référentielle, voyez l’ouvrage de référence An Introduction to Database Systems (8th edition), page 274 :

Referential Integrity : The database must not contain any unmatched foreign key values.

Si donc on évacue une clé étrangère on évacue une contrainte, plus précisément une contrainte référentielle, ce qui est peccamineux puisque la base de données peut être ainsi rendue incohérente.

Juste de manière théorique puisque on parlait des CIF ou OCL et de leur implémentation relationnelle.

En corollaire à ce qui précède, vous ne cherchez donc pas à concrétiser systématiquement une CIF sous forme de contrainte au stade relationnel ?

[alicc]

Bonsoir,

Par ailleurs, la ternaire se justifie-elle ? On doit pouvoir par exemple produire le diagramme de classes suivant :

Bonjour fsmrel, en dehors des divers éléments de discussion et de réponses intéressants, d'où / ou comment vous sont venues les idées "qu'on doit produire le diagramme de classes suivant: " (ce qui ne nécessite pas une ternaire)... ?
C'est un point d'inflexion dans la discussion auquel je ne m'attendais pas.

[fsmrel]

Bonsoir alicc,

en dehors des divers éléments de discussion et de réponses intéressants, d'où / ou comment vous sont venues les idées "qu'on doit produire le diagramme de classes suivant: " (ce qui ne nécessite pas une ternaire)... ?
C'est un point d'inflexion dans la discussion auquel je ne m'attendais pas.

Je ne sais pas si j’ai bien compris le pourquoi de votre interrogation. A défaut je ferai observer ceci :

Je n’ai pas écrit « on doit produire le diagramme de classes suivant » mais, nuance ! « On doit pouvoir par exemple produire le diagramme de classes suivant », « pouvoir » voulant dire « avoir la possibilité »... Autrement dit, je propose une alternative et je n’impose rien ! A chacun d’utiliser la représentation qui lui convient si choix il y a. Par exemple, CinePhil a montré sa préférence pour l’identification relative (correspondant quelque part à la relation de composition du diagramme de classes dont vous faites mention), mais s’il avait préféré conserver la ternaire avec CIF, ça n’aurait gêné personne, puisqu’au bout du compte le diagramme logique résultant est exactement le même, ce qui a quand même son importance :


Cela dit, considérons à nouveau la ternaire merisienne :

L’en-tête de l’association-type PROJETER contient l’attribut (propriété) Tarif, mais le dogme veut que les attributs DateProjection et HeureDebut en soient exclus parce qu’ils participent à l’identification de l’association-type...
Si le dogme tombait, alors on représenterait à peu de choses près le diagramme ainsi :


Il serait alors inutile d’inventer une prétendue entité-type HORAIRE de facto sans emploi. Je conserve évidemment la CIF, pour signifier que l’entité-type FILM ne participe pas à l’identifiant de l’association-type, eu égard à la contrainte d’unicité qui s’écrit sous forme de dépendance fonctionnelle :

{SALLE, HORAIRE} → FILM

Pour obtenir un diagramme équivalent, il est plus simple d’utiliser par exemple la représentation IEF (James Martin) qui ignore les ovales merisiens et les losanges à la Chen :


Le symbole « |—| » figurant sur le lien connectant SALLE et PROJETER est là pour signifier que l’identifiant de SALLE participe à l’identification de PROJETER (identification relative).

Bref, tant qu’une ternaire n’est pas strictement nécessaire, je préfère m'en passer. Disons qu’à défaut de point d’inflexion, je passe sans doute en l’occurrence par un point de rebroussement, mais une fois encore, libre à chacun de choisir sa représentation préférée, à condition que le diagramme logique qui en est dérivé soit celui qui a été présenté ci-dessus.

[alicc]

Merci fsmrel.

= = =
Chez nous, on dit "On devrait pouvoir..." car quand on doit, on doit... ;-)))
= = =

Le plus bel apport perso grâce à cette discussion, c'est la démonstration que le diagramme logique reste identique ici selon les 2 approches : identification relative ou ternaire + CIF. Très intéressant.