Discussion :

[abdoinfo]

Salut tout le monde,

j'ai élaboré une association ternaire entre trois classes comme la montre l'image ci-dessous,mais mon souci c'est le passage vers l'implémentation en SQL c'est à dire la génération des tables à créer dans la base de données qui reflètent cette association ternaire

Merci à vous.
voici le schéma :

[bruno_pages]

Bonjour,

vous devriez faire une recherche sous les forums modélisation et schéma

[fsmrel]

Bonsoir,


Vous avez défini des multiplicités 1 ("un et un seul"). Autrement dit, si je ne raisonne pas comme un tambour (ça m’arrive parfois...), il y a bijection entre les classes A et B. Par ailleurs, un objet de la classe C est en relation avec zéro à plusieurs objets de la classe A et zéro à plusieurs objets de la classe B.

Dans ces conditions, au niveau tabulaire (SQL), un 1er diagramme, pas génial car comportant un cycle entre A et B, pourrait être le suivant (notation IE avec Power AMC) :




Pour éliminer le cycle tout en préservant la contrainte fonctionnelle B -> A, donc sans perte de fonctionnalité, il suffit de rendre {IdB} clé alternative (mickey <ak>) de la table A :




Sachant par ailleurs que la relation C -> B est déduite par transitivité de C -> A et A -> B : elle disparaît, sinon il y a viol de la troisième forme normale (condamné par les tribunaux du Relationland) :




Du fait de la bijection, A peut absorber B (pour qu’il n’y ait pas de jaloux, on peut renommer A en AB) :

[abdoinfo]

Merci M.fsmrel pour votre réponse mais je pense que vous n'avez pas bien interprété les relations enter les classes du schéma mais celui en-dessous vous illustre bien cette fois-ci ces relations avec les commentaires suivants:

Class A :Salle
Class B: Professeur
Class C: Etudiant

[fsmrel]

Changer le nom des classes ne change rien à l’affaire. Considérons votre diagramme de classes à l’allure de catafalque :




Vu les cardinalités, on va dire :

(R1) Un professeur fait cours à au moins un étudiant,
(R2) Un professeur fait cours dans une seule classe.

De la même façon :

(R3) Une salle accueille un seul professeur,
(R4) Une salle accueille au moins un étudiant.

Et enfin :

(R5) Un étudiant suit les cours d’un seul professeur,
(R6) Un étudiant suit des cours dans une seule classe.

Au changement de nom des classes près, le résultat de la modélisation est le même que celui que je vous ai proposé, à ceci près que l’on ne cherchera pas — malgré la bijection — à fondre les classes PROFESSEUR et SALLE en une classe unique...

Si vous vous attendez à un résultat différent, alors votre diagramme de classes est à revoir (ou vos règles de lecture, d'interprétation de la ternaire à expliciter et justifier, au cas où elles diffèreraient des miennes...)

=>

Merci donc de nous proposer les règles de gestion de votre système dans le style (R1) à (R6), telles que vous les percevez.

[bruno_pages]

Considérons votre diagramme de classes à l’allure de catafalque

en fait il provient du tutoriel UML de Laurent Piechocki

abdoinfo, vous deviez (re)lire avec une grande attention les réponses de fsmrel qui n'est pas VIP pour rien

[fsmrel]

Bonjour Bruno,

Merci pour votre appréciation. Bien que vivant au Relationland , j’ai fait une lecture de la ternaire « à la Merise ». Selon vous, avec UML est-il proposé une autre interprétation ?

[bruno_pages]

Bonjour fsmrel,

Selon vous, avec UML est-il proposé une autre interprétation ?

désolé mais vu ma méconnaissance profonde concernant les BDs je ne me lancerai pas dans une tentative de génération UML -> SQL. Ce n'est pas pour rien si Bouml ne gère pas les BDs

[fsmrel]

Bonjour Bruno,


Surtout ne fuyez pas ! Loin de moi l’idée de vous infliger le pensum de la génération de la structure (disons SQL, horresco referens...) de la base de données...

Quand je parle d’interprétation, je me limite à l’adéquation du diagramme de classes initial et des règles de gestion (R1) - (R6) que j’en ai inférées et dont je ne suis pas sûr, faute d’information quant à l’interprétation exacte d’une association ternaire en UML. En fait, quand je parle d’une lecture « à la Merise » (méthode qui propose une lecture des ternaires dépourvue d'ambiguïté, voir notamment De l’autre côté de Merise d’Yves Tabourier), pour être précis il s’agit plutôt d’une lecture à la Chen (The Entity-Relationship Model -Toward a Unified View of Data). En effet, comme vous le savez, avec Merise les multiplicités (cardinalités) sont inversées :



En vertu de quoi, en première lecture, les règles deviennent les suivantes quant à la participation des acteurs :

(R1’) Un professeur fait cours à au moins un étudiant,
(R2’) Un professeur fait cours dans au moins une classe,
(R3’) Une salle accueille au moins un professeur,
(R4’) Une salle accueille au moins un étudiant,
(R5’) Un étudiant suit les cours d’un seul professeur,
(R6’) Un étudiant suit des cours dans une seule classe.

Les règles R2 et R2’ ne sont pas les mêmes, même chose pour R3 et R3’.

En deuxième lecture, il y a le risque que les étudiants suivent des cours dans des salles (ensemble S1) et que les professeurs donnent leurs cours dans des salles (ensemble S2) qui ne soient pas les mêmes (S1 ∩ S2 = ∅), d’où la nécessité d’une règle de gestion supplémentaire (R7’) pour éviter ce genre de situation, et à laquelle la mise en œuvre de la ternaire n’est, je suppose, pas étrangère (de même que la promotion de la ternaire en classe-association), sinon cette ternaire aurait été remplacée par deux binaires...

Je reformule donc ma question : dans le contexte UML, quelles sont à votre avis les règles de gestion (appelons-les R1”, etc.) que traduit la ternaire initiale ?

[bruno_pages]

Bonsoir,

les règles R1..6 que vous avez énoncé dans la réponse contenant catafalque sont la bonne interprétation pour le diagramme UML

elle sont toutes vérifiées en même temps (R1 et R2 et R3 et ... et R6), c'est exactement comme si on avait 3 relations bidirectionnelles sauf que l'on montre clairement le lien entre les instances (de même qu'une relation bidirectionnelle c'est plus que deux relations unidirectionnelles)

[fsmrel]

Merci Bruno,


Ainsi, les règles (R1) à (R6) sont en accord avec le diagramme de classes catafalque. Ça n’est pas intuitif, mais ces règles donnent lieu au diagramme « logique » suivant (qui correspond au 3e que j’avais proposé précédemment, mutatis mutandis) :



Les clés sont soulignées. Ainsi {EtudiantId} est clé de la table ETUDIANT, {ProfId} est clé de la table PROFESSEUR, {SalleId} est clé alternative de la table PROFESSEUR et clé de la table SALLE.

Pardonnez-moi certaines incongruités qui suivent :

La règle (R1) est assurée du fait de l’association 1..* entre PROFESSEUR et ETUDIANT ;
La règle (R2) est assurée par la dépendance fonctionnelle {ProfId} → {SalleId} vérifiée par la table PROFESSEUR ;
La règle (R3) est assurée par la dépendance fonctionnelle {SalleId} → {ProfId} vérifiée par la table PROFESSEUR ;
La règle (R4) est assurée du fait de l’association 1..* entre PROFESSEUR et ETUDIANT ;
La règle (R5) est assurée par la dépendance fonctionnelle {EtudiantId} → {ProfId} vérifiée par la table ETUDIANT ;
La règle (R6) est assurée par transitivité : {EtudiantId} → {ProfId} et {ProfId} → {SalleId} => {EtudiantId} → {SalleId}.

mon souci c'est le passage vers l'implémentation en SQL

La traduction en SQL du diagramme logiqe donne lieu au code 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
14
15
16
17
18
19
20
21
22
23
24
25
CREATE TABLE SALLE 
(
   SalleId              INT                  NOT NULL,
   SalleNom             VARCHAR(48)          NOT NULL,
   CONSTRAINT SALLE_PK PRIMARY KEY (SalleId)
) ;
CREATE TABLE PROFESSEUR 
(
   ProfId               INT                  NOT NULL,
   SalleId              INT                  NOT NULL,
   ProfNom              VARCHAR(48)          NOT NULL,
   CONSTRAINT PROFESSEUR_PK PRIMARY KEY (ProfId),
   CONSTRAINT PROFESSEUR_AK UNIQUE (SalleId),
   CONSTRAINT PROFESSEUR_SALLE_FK FOREIGN KEY (SalleId)
      REFERENCES SALLE (SalleId)
) ;
CREATE TABLE ETUDIANT 
(
   EtudiantId           INT                  NOT NULL,
   ProfId               INT                  NOT NULL,
   EtudiantNom          VARCHAR(48)          NOT NULL,
   CONSTRAINT ETUDIANT_PK PRIMARY KEY (EtudiantId),
   CONSTRAINT ETUDIANT_PROFESSEUR_FK FOREIGN KEY (ProfId)
      REFERENCES PROFESSEUR (ProfId) 
) ;

[sarrachikh]

Bonjour,
S'il vous qui peux m'aider pour faire une relation ternaire sous power AMC dans un diagramme des classe ,
merciiii de m'aider

[fsmrel]

Bonsoir sarrachikh,



Le plus simple est d’en passer par des relations de composition.

Par exemple :

Le développeur Raoul a utilisé le langage Java pendant 60 jours dans le cadre du développement du projet Aristote,

Le développeur Raoul a utilisé le langage C++ pendant 15 jours dans le cadre du développement du projet Aristote,

Le développeur Raoul a utilisé le langage Java pendant 40 jours dans le cadre du développement du projet Socrate,

Le développeur Raoul a utilisé le langage C# pendant 10 jours dans le cadre du développement du projet Socrate,

Le développeur Raoul a utilisé le langage C# pendant 30 jours dans le cadre du développement du projet Oiseau,

Le développeur Fernand a utilisé le langage Java pendant 10 jours dans le cadre du développement du projet Socrate,

Le développeur Fernand a utilisé le langage C++ pendant 20 jours dans le cadre du développement du projet Oiseau,

Etc.

=>

[tonton16]

Bonjour,

Dans le diagramme précédent de fsmrel, les compositions sont à l'envers, les losanges doivent être du côté de l'activité, et donc, les multiplicités sont à l'envers.

[fsmrel]

Bonjour,

Dans le diagramme précédent de fsmrel, les compositions sont à l'envers, les losanges doivent être du côté de l'activité, et donc, les multiplicités sont à l'envers.

Et pour quelle raison les losanges devraient être du côté de l’activité ?


Pour être en phase avec les exemples que j’ai donnés, une activité est l’association, « la rencontre » d’un projet, d’un développeur et d’un langage donnés, et les règles de gestion des données sont les suivantes :

(R1) Un développeur a participé à au moins une activité ;

(R2) Un projet a fait l’objet d’au moins une activité ;

(R3) Un langage a pu être utilisé pour plusieurs activités ;

(R4) Pour un projet, un développeur et un langage donnés, une activité a une durée.

(R5) Le nombre de jours consommés pour un projet est la somme des nombres de jours consommés par activité associée à ce projet.

Le MLD dérivé du diagramme de classes que j’ai proposé est le suivant :





Et le MCD merisien :






Si on applique vos recommandations, un projet est un composant d’une activité et une seule, un développeur est un composant d’une activité et une seule et un langage est un composant d’une activité et une seule :





Mais qu’un langage ne puisse être utilisé que pour une seule activité paraît hautement douteux. Pour leur part, une fois qu’ils en auront terminé, les développeurs devront changer de métier (ou de société)...


MLD correspondant :






MCD correspondant (notation Merise à la PowerAMC quant à l’identification relative) :




Est-ce bien ainsi que vous concevez les choses ?

[tonton16]

Bonjour,

On va dire que j'étais fatigué pour l'emplacement des multiplicités, je me suis mis à les lire à l'envers.
Donc votre solution est dans le bon sens, en fait, c'est le fait d'avoir 3 compositions qui me gêne.
La composition implique une relation forte entre les classes, le composite ayant droit de vie et mort sur son composant. D'ailleurs, la norme UML indique qu'un composant ne peut être relié qu'à au plus un composite, même s'il peut y avoir des exceptions.

Ma solution est de n'avoir qu'une seule composition, par exemple sur le projet :


Après, tout dépend du contexte dans lequel on se place.

Au final, pour répondre à la question initiale, je préfère éviter les associations n-aires en UML.

Enfin, dernier point, un attribut souligné dans une classe signifie que c'est une attribut de classe (static) et donc qu'il est partagé par toutes les instances, ce qui n'est pas le cas d'un identifiant qui doit être unique pour chaque instance.

[fsmrel]

Bonsoir tonton16,


Si l’on part du principe qu’un développeur et un langage ne sont pas liés à la vie à la mort à des activités dans le cadre d’un projet, et qu’en l’occurrence les relations de composition ne les concernent pas, il est incontestable que d’un point de vue sémantique, votre diagramme est celui qui est pertinent.

De mon côté, j’ai basculé vers une solution technique, « utilitaire », pour prendre en compte le problème posé initialement par abdoinfo :

Mon souci c'est le passage vers l'implémentation en SQL c'est à dire la génération des tables à créer dans la base de données qui reflètent cette association ternaire. »

J'avais donc pour objectif la génération automatique du script de création des tables SQL (au moyen de l’AGL PowerAMC pour la circonstance), sans que l’on ait à y retoucher manuellement (travail fastidieux et source d’erreurs) : définition clés primaires, de l’incontournable intégrité référentielle, etc. Ceci explique la présence d’attributs identifiants.

Maintenant, toujours avec PowerAMC, si j’utilise le diagramme suivant :



Alors il y a génération d’un MLD dans lequel les tables sont systématiquement des sacs (horresco referens!), qu’il faudra transformer soi-même en relations (au sens du modèle relationnel de données de Codd) :




Tout est à faire quant aux clés primaires, aux clés étrangères, etc., ce qui représente un surcroît de travail important.


Mais je peux aménager le diagramme utilitaire. A partir du diagramme suivant, où j’utilise un identifiant relatif pour ACTIVITE (notez que les attributs utilisés pour l’identification ne sont plus publics...) :





Alors le MLD produit par PowerAMC est le suivant :



Dans lequel ACTIVITE a pour clé la paire {ProjetId, ActiviteId} (l’identification est relative, puisqu’une clé doit être irréductible) : abdoinfo n’a pas à compléter le MLD, les tables sont bien des relations au sens de Codd, l’intégrité référentielle est en place, et de facto le script de création des tables SQL est bon.


Cette approche vous paraît-elle plus « convenable » ?

[tonton16]

Bonjour,

Cela me paraît convenable, maintenant il s'agit de savoir si abdoinfo a bien la réponse à sa question initiale.