Discussion :

[Shydos]

Bonjour,

J'ai un schéma qui doit correspondre au minimum à un symbole, à un symbole et un constructeur, ou à un symbole, un constructeur et une série.
J'en arrive donc à ce MCD : http://hpics.li/97471f7
Je me demandai si une association n-aire était justifié dans ce cas ou s'il était possible de la transformer en plusieurs associations binaires?

Autre problème j'ai une fonction (Alimentation, affichage, ...) qui peut à être liée à une autre fonction et dont le lien peut posséder des fichiers joints.
J'ai ce MCD : http://hpics.li/6f7c0b1
Déjà, une telle association est-elle possible? Serait-il plus judicieux de créer une table lien à part?

Merci d'avance.

[fsmrel]

Bonsoir Shydos,


Par définition, une occurrence de l’association CORRESPOND est nécessairement composée d’une référence à un schéma, un symbole, un constructeur et une série.

Selon votre MCD, un schéma est donc associé à au moins à un symbole, un constructeur et une série : si j’ai bien compris vos explications, ça ne fonctionne pas pour les deux premiers cas qui vous intéressent.



Le MCD ci-dessous est évidemment plus « encombré », mais devrait répondre à un 1er besoin (notez bien les cardinalités 1,1).


— L’entité-type SCHEMA_C est sous-type de l’entité-type SCHEMA et référence nécessairement l’entité-type SYMBOLE, mais aucune autre. On peut aménager le MCD s'il est permis qu'elle fasse facultativement référence aux autres entités-types.

— L’entité-type SCHEMA_CS est sous-type de l’entité-type SCHEMA et référence nécessairement l’entité-type SYMBOLE et l’entité-type CONSTRUCTEUR, mais pas l’entité-type SERIE. On peut aménager le MCD s'il est permis qu'elle fasse facultativement référence à cette dernière.

— L’entité-type SCHEMA_CSS est sous-type de l’entité-type SCHEMA et référence nécessairement les entités-types SYMBOLE, CONSTRUCTEUR et SERIE.






Je vais regarder la 2e partie de votre message.

[fsmrel]

Concernant votre 2e MCD :


(a) Selon ce MCD, une fonction peut jouer le rôle de « composant » en relation avec N fonctions. De même, une fonction peut jouer le rôle de « composé » en relation avec N fonctions.

(b) Toujours selon ce MCD, une paire {composant, composé} est facultativement en relation avec N fichiers.

(c) Un fichier fait référence à au moins une fonction.


Si (a) (b) et (c) sont vrais, alors votre MCD est en phase.

[Shydos]

Merci pour votre réponse rapide et clair.

Concernant le premier MCD c'est exactement ce qu'il me faut. Sinon je ne pense pas que les entités-types puisse faire facultativement référence à d'autres autres entités-types car par exemple un schéma qui ne dépend que d'un symbole ne pourra pas être le même qu'un autre schéma dépendant par exemple d'un symbole et d'un constructeur.

Quant au deuxième MCD :

(a) Selon ce MCD, une fonction peut jouer le rôle de « composant » en relation avec N fonctions. De même, une fonction peut jouer le rôle de « composé » en relation avec N fonctions.

J'ai un doute concernant cette affirmation. En faite les schéma (MCD 1) sont composés de fonctions (Affichage, alimentation, ...) liées entres elles (en série ou en parallèle) et ces liens peuvent contenir des fichiers joints (signal en sortie, tension, ...). Il s'agit d'une application graphique ou le schéma est crée en ligne et ressemblai à ça :

Le lien est en quelque sorte un "objet" à part entière et il n'existe pas de hiérarchie entre les fonctions. Les liens méritent t'ils leur propre entité?
On aurait un MCD de ce genre :

(Ici j'ai changé d'avis par rapport à la (c), un fichier joint peu ne référencer aucun lien).

(b) Toujours selon ce MCD, une paire {composant, composé} est facultativement en relation avec N fichiers.

Vrai.

(c) Un fichier fait référence à au moins une fonction.

Vrai.

[fsmrel]

Bonsoir Shydos,


Pour le moment, je ne considère pas les associations avec les fichiers (qui ne devraient pas poser de problème).

A partir de votre 1er schéma je dirai qu’il y un type de chose que je nommerai FONCTION (si ce nom n’est pas pertinent, on le changera). Ce type de chose possède certaines propriétés, dont une — multivaluée — que je nommerai POINT_ACCES (si ce nom n’est pas pertinent, on le changera), correspondant à des points de connexion entre les fonctions. Un point de connexion possède certaines propriétés, et peut être spécialisé en points de type DRAG ou point de type DROP. On doit pouvoir établir un lien entre un drag d’une fonction F1 et un drop d’une fonction F2 (distincte deF1).

Si je ne me suis pas planté :

Du point de vue de la modélisation, on peut représenter une fonction avec ses propriétés spécifiques (que je résume ci-dessous à FonctionNom). Une fonction est en plus composée de N points de connexion, et chaque point n’appartient qu’à une fonction. Ces points font l’objet de l’entité-type POINT_ACCES. En UML, on dit qu’il existe une relation de composition entre FONCTION et POINT_ACCES. En entité-association, POINT_ACCES est une entité-type faible (weak entity), et comme j’utilise l’AGL PowerAMC, je me conforme à sa façon de représenter cela : la cardinalité 1,1, est mise entre parenthèses (l’identifiant de POINT_ACCES ne se résume pas à {PointAccesId}, il est relatif à FONCTION et devient {FonctionId, PointAccesId}).

Je vais supposer que chaque point de connexion a lui aussi ses propriétés spécifiques (que je résume ci-dessous à PointDescription).


MCD (relation de composition) :





Comme les points de connexion sont de type DRAG ou DROP, on peut modéliser cela, par une relation de spécialisation (dans le style PowerAMC) :





La demi-lune marquant la spécialisation est porteuse d’une croix signifiant qu’un point ne peut pas être à la fois du type drag et drop (exclusion). Elle est soulignée pour marquer la totalité : tout point de connexion est de type drag ou drop.

Pour établir les liens :





Selon cette représentation, un point de connexion de type drag ne peut être associé qu’un seul point de connexion de type drop (et réciproquement).


Au niveau logique :

MLD





La table LIEN a notamment les propriétés suivantes :

— Une clé candidate (primaire en SQL) : {DragFonctionId, DragPointAccesId} ;

— Pour des raisons de symétrie, une autre clé candidate ( de type « unique » en SQL) : {DropFonctionId, DropPointAccesId} ;

— Une contrainte (à mettre œuvre en SQL) selon laquelle une fonction ne peut pas s’autoréférencer.


SQL

TABLE FONCTION

Code SQL :

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

1
2
3
4
5
6
CREATE TABLE FONCTION 
(
   FonctionId           INT NOT NULL,
   FonctionNom          VARCHAR(64) NOT NULL,
   CONSTRAINT FONCTION_PK PRIMARY KEY (FonctionId)
) ;

TABLE POINT_ACCES

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE POINT_ACCES 
(
   FonctionId           INT NOT NULL,
   PointAccesId         INT NOT NULL,
   PointDescription     VARCHAR(64) NOT NULL,
   CONSTRAINT POINT_ACCES_PK PRIMARY KEY (FonctionId, PointAccesId),
   CONSTRAINT POINT_ACCES_FONCTION_FK FOREIGN KEY (FonctionId)
      REFERENCES FONCTION
) ;

TABLE P_DRAG

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE P_DRAG 
(
   FonctionId           INT NOT NULL,
   PointAccesId         INT NOT NULL,
   CONSTRAINT P_DRAG_PK PRIMARY KEY (FonctionId, PointAccesId),
   CONSTRAINT P_DRAG_POINT_ACCES_FK FOREIGN KEY (FonctionId, PointAccesId)
      REFERENCES POINT_ACCES
) ;

TABLE P_DROP

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE P_DROP 
(
   FonctionId           INT NOT NULL,
   PointAccesId         INT NOT NULL,
   CONSTRAINT P_DROP_PK PRIMARY KEY (FonctionId, PointAccesId),
   CONSTRAINT P_DROP_POINT_ACCES_FK FOREIGN KEY (FonctionId, PointAccesId)
      REFERENCES POINT_ACCES
) ;

TABLE LIEN

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
CREATE TABLE LIEN 
(
   DragFonctionId       INT NOT NULL,
   DragPointAccesId     INT NOT NULL,
   DropFonctionId       INT NOT NULL,
   DropPointAccesId     INT NOT NULL,
   Observation          VARCHAR(64) NOT NULL,
   CONSTRAINT LIEN_PK PRIMARY KEY (DragFonctionId, DragPointAccesId),
   CONSTRAINT LIEN_AK UNIQUE (DropFonctionId, DropPointAccesId),
   CONSTRAINT LIEN_P_DRAG_FK FOREIGN KEY (DragFonctionId, DragPointAccesId)
      REFERENCES P_DRAG,
   CONSTRAINT LIEN_P_DROP_FK FOREIGN KEY (DropFonctionId, DropPointAccesId)
      REFERENCES P_DROP,
   CONSTRAINT LIEN_CHK01 CHECK (DragFonctionId <> DropFonctionId) 
) ;

Ne sont pas représentées les contraintes d’exclusion et de totalité.


Bien entendu, si certaines de mes suppositions ne sont pas avérées, on peut repartir sur des bases plus exactes.

[fsmrel]

Bonjour Shydos,

Alors, ce modèle ?

[Shydos]

Bonjour fsmrel,

Alors, j'ai suivi vos conseils et au point ou j'en suis j'ai ce MCD (Fusion du 1er et 2ème MCD, qui doit correspondre à l'application finale) :


J'ai changer quelques noms : Schéma -> Synoptique, Point_Acces -> Point_Connexion, ...

Pour traduire le fait qu'un synoptique est composé de fonctions, j'ai fait une relation de composition entre synoptique et fonction sur le même modèle que la relation fonction/point_connexion. On a alors la clé primaire qui découle jusqu'à la table Lien et chaque lien, point, et fonction est liée à un synoptique (ce que je souhaitai).

Sinon je ne vois pas comment intégrer les fichiers joints ici puisque les "Lien" ne sont pas encore une entité/table à part entière. Faut-il liée les "Lien" avec les fichiers joints seulement au niveau du MLP/MPD, ou existe-t'il une façon de représenter cela directement depuis le MCD.



Le MCD ci-dessus correspind à ce MPD :

Là, il se passe une chose étrange avec les clés étrangères :

synoptiqueId -> fk1
fonctionId -> fk1
pointConnexionId -> fk2 !? Pourquoi 2 ici?
Poi_synoptiqueId -> fk2
Poi_fonctionId -> fk2
Poi_pointConnexionId -> fk1 !? Et pourquoi 1 ici?

Enfin bref cela viens peut-être de PowerAMC.

[fsmrel]

Bonsoir Shydos,

je ne vois pas comment intégrer les fichiers joints ici puisque les "Lien" ne sont pas encore une entité/table à part entière. Faut-il liée les "Lien" avec les fichiers joints seulement au niveau du MLP/MPD, ou existe-t'il une façon de représenter cela directement depuis le MCD.

Avec Merise, y a pas à tortiller, il faut déguiser l'association LIEN en entité-type :

Là, il se passe une chose étrange avec les clés étrangères :

synoptiqueId -> fk1
fonctionId -> fk1
pointConnexionId -> fk2 !? Pourquoi 2 ici?
Poi_synoptiqueId -> fk2
Poi_fonctionId -> fk2
Poi_pointConnexionId -> fk1 !? Et pourquoi 1 ici?

Enfin bref cela viens peut-être de PowerAMC.

Effectivement, PowerAMC se prend un peu les pieds dans le tapis, mais on ne fait pas ici dans la modélisation lambda...


Une question : autorisez-vous que les points de connexion d’un synoptique S1 soient tricotés avec ceux d’un synoptique S2 ?

a) Si oui, la table LIEN doit ressembler à ceci :







b) Sinon, la table LIEN doit ressembler à cela, puisqu'alors DragSynoptiqueId = DropSynoptiqueId :






Si vous avez des problèmes avec PowerAMC quant à la transformation de la table LIEN, et si vous perdez du temps à fouiller dans l'aide, faites-moi signe.



En passant, n’oubliez pas de voter pour les réponses que vous jugeâtes utiles !

[Shydos]

Bonjour fsmrel,

Avec Merise, y a pas à tortiller, il faut déguiser l'association LIEN en entité-type :

D'accord, déguisons !

Effectivement, PowerAMC se prend un peu les pieds dans le tapis, mais on ne fait pas ici dans la modélisation lambda...

Le pauvre... En faite le problème venait du fait qu'il nommait les attributs venant de Point_Drag : synoptiqueId, fonctionId et Poi_pointConnexionId et ceux venant de Point_Drop : Poi_synoptiqueId, Poi_fonctionId et pointConnexionId allez savoir pourquoi

Une question : autorisez-vous que les points de connexion d’un synoptique S1 soient tricotés avec ceux d’un synoptique S2 ?

Non, les synoptiques sont indépendants, du coup je vais partir sur la solution b) :

Si vous avez des problèmes avec PowerAMC quant à la transformation de la table LIEN, et si vous perdez du temps à fouiller dans l'aide, faites-moi signe.

Euh oui, je veux bien un peu d'aide pour l'opération avec "DragSynoptiqueId = DropSynoptiqueId" parce que je m'y perd dans la doc de powerAMC

En passant, n’oubliez pas de voter pour les réponses que vous jugeâtes utiles !

Ça marche

[fsmrel]

Bonsoir Shydos,

je veux bien un peu d'aide pour l'opération avec "DragSynoptiqueId = DropSynoptiqueId" parce que je m'y perd dans la doc de powerAMC :calim2 :

Ne vous sentez pas seul, on croise nombre de concepteurs égarés dans cette jungle !

C'est pour moi l'occasion de développer cette partie, qui pourrait probablement faire l'objet d'un article, à moins que vous ne jugiez cela inutile


Bref, commençons par nous intéresser aux cycles (représentés par des flèches en rouge) qui sont la conséquence des cardinalités max à 1 portées par les pattes que l’on trouve de chaque côté de l’entité-type LIEN :






Supprimons ces cycles :







DU coup, PowerAMC a supprimé de lui-même, les colonnes devenues inutiles dans les tables P_DRAG et P_DROP. La table P_DROP comporte les noms de colonne « Colonne_4 » et » Colonne_6 » parfaitement valides, mais pas à notre goût, aussi les change-t-on respectivement en « SynoptiqueId » et « FonctionId », mais en nous assurant au préalable de leur correspondance.

Pour cela, on accède aux propriétés de la table P_DROP et on y sélectionne l’onglet « Clés » :





On double-clique sur la ligne <identifiant_1>, <IDENTIFIANT_1> , ça noircit bien :






Et ça provoque l’ouverture de la fenêtre « Propriétés de la clé » :





Fenêtre dans laquelle on clique sur l’onglet « Colonnes », ce qui permet de s’assurer de l’ordre dans lequel figurent les colonnes :





Manifestement, l’ordre est le bon et les noms « Colonne_4 » et » Colonne_6 » correspondent bien respectivement aux noms « SynoptiqueId » et « FonctionId » : allons-y pour changer les noms dans la table P_DROP :







Changeons à leur tour le nom des colonnes de la table LIEN :






Vérifions en passant la correspondance entre les noms des colonnes des tables P_DRAG et LIEN. Pour cela on double-clique sur le lien connectant les deux tables (que j'ai surchargé en rouge), ce qui provoque l’ouverture de la fenêtre « Propriétés de la référence » :






On clique sur l’onglet « Jointures », ce qui provoque l’ouverture de la fenêtre « Propriétés de la référence », où l’on constate une belle harmonie entre les noms des colonnes des deux tables :





Même chose bien sûr quant à la correspondance entre les noms des colonnes des tables P_DRAG et LIEN (mutatis mutandis comme dit l’autre).


Passons à la fusion des colonnes DragSynoptiqueId et DropSynoptiqueId.

En procédant comme ci-dessus, on ouvre la fenêtre affichant la correspondance entre les noms des tables LIEN et P_DROP :




En cliquant sur la cellule contenant le nom « DropSynoptiqueId », on fait apparaître un petit triangle noir :





On clique donc sur ce triangle, ce qui fait apparaître les noms des colonnes de la table P_DROP autorisées à remplacer DropSynoptiqueId :





On clique donc sur DragSynoptiqueId qui remplace DropSynoptiqueId :





Cette fois-ci, DragSynoptiqueId appartient non seulement à la clé étrangère faisant référence à la table P_DRAG, mais aussi à celle faisant référence à la table P_DROP. Pour éviter de loucher et pour des raisons de symétrie, vous pouvez renommer DragSynoptiqueId en DragDropSynoptiqueId ou SynoptiqueId ou autre ...

A noter que PowerAMC a vu que la colonne DropSynoptiqueId n’a plus d’utilité et l’a éliminée de lui-même.


Il ne faut pas oublier que le triplet {DragSynoptiqueId, DropFonctionId, DropPointAccesId} est clé candidate de la table LIEN. On peut agir au niveau du MCD, mais j’en profite pour montrer comment agir au niveau MLD. Comme dans le cas de la figure 3, on ouvre la fenêtre « Propriétés de la table » et on clique sur l’onglet « Clés ». On clique ensuite sur la ligne en dessous de celle qui contient la valeur <identiant_1>, ce qui donne lieu à un nom de clé candidate « clé_2 » (renommable) :




On double-clique alors sur « Cle_2 ». PowerAMC affiche un message de demande de confirmation à laquelle on répond par « Oui ». Il s’ensuit l’ouverture d’une fenêtre « Propriétés de la clé » :





On clique sur l’onglet « Colonnes », la fenêtre passe alors à l’état suivant :





L’onglet « Colonnes » étant sélectionné, on clique sur l’icône d’ajout de colonnes pour faire apparaître les noms des colonnes pouvant entrer dans la composition de la nouvelle clé candidate Cle_2 :






Reste à sélectionner ces noms :







Suite à quoi la clé candidate {DragSynoptiqueId, DropFonctionId, DropPointAccesId} de la table LIEN est symbolisée dans le MLD par le mickey <ak> (abréviation de alternate key) :





Un coup d’œil pour s’assurer que les colonnes sont dans le bon ordre dans la clé (si ça n’avait pas été le cas, on aurait toujours eu la possibilité de le reconstituer) :





Ainsi, avec quelques clics de souris on résout un problème de contrainte de chemin...

Ai-je répondu à votre interrogation ?

[Shydos]

Bonjour fsmrel,
Quel jour est t’ont déjà?

Ne vous sentez pas seul, on croise nombre de concepteurs égarés dans cette jungle !

Je veux bien vous croire

C'est pour moi l'occasion de développer cette partie, qui pourrait probablement faire l'objet d'un article, à moins que vous ne jugiez cela inutile

"Non, au contraire, je dirai que cela peut s'avérer fort utile à d'autres que moi" Didier Deschamp (la marionnette)

Ai-je répondu à votre interrogation ?

Oui parfait, d'ailleurs vous avez répondu à toutes mes interrogations je n'en trouve plus à vous soumettre...
Mon modèle est complet (pour le moment) je vais donc marquer ce post comme résolu en vous remerciant une dernière fois pour votre aide.

[fsmrel]

Bonsoir Shydos,


Je suis content d'avoir pu répondre de façon satisfaisante à vos questions, et je vous souhaite bonne route !


François