fsmrel

___________________________________________________________________________________________________


(1) Rappel

Dans le billet ad-hoc, on a montré comment créer une entité-type, on va maintenant en créer une 2e et établir une association entre elles.

On avait créé l’entité-type CLIENT, on crée maintenant une entité-type COMMANDE, correspondant aux commandes des clients de Dubicobit :





N.B. Le statut de la commande ne figure pas ici, mais on pourra le définir à partir d’une association entre l’entité-type COMMANDE et une entité-type STATUT_COMMANDE ad-hoc.


(2) Création d’une association

On se sert de l’icône « Rel-type » :





Après avoir cliqué sur l’icône Rel-type, on dépose l’image d’une association (relation-type) :





On renomme l’association à sa convenance (pour cela, on utilise la boîte de propriétés) :





(3) Pattes d’association

On représente les pattes de l’association en sélectionnant l’icône ad-hoc (« Role/rel-type/link »), puis en faisant glisser le curseur (en forme de la croix) qui apparaît, depuis chaque entité-type vers l’association (ou indifféremment, de l’association vers chaque entité-type) :





Comme le rappelle nono02P, on peut créer une association et ses pattes en sélectionnant « Role/rel-type/link », puis en joignant directement les deux associations, ce qui est quand même plus simple.


Pour éviter des rafales de « Role/rel-type/link », on clique sur l’icône, elle doit alors redevenir grisâtre. Comme le rappelle encore nono02P, on ira plus vite à utiliser la touche « échap » du clavier...


(4) Cardinalités

Pour modifier une cardinalité, on la sélectionne et on clique, ce qui provoque l’ouverture de la boîte de propriétés qui va bien et qui permet de faire son choix. Par exemple, comme une commande n’est passée que par un et un seul client :





Après avoir sélectionné « 1-1 » dans la liste déroulante (et cliqué sur le bouton de validation « Save changes » ), les cardinalités sont en place :





(5) Choix de la représentation graphique des associations

Pour ceux qui, par habitude, préfèrent représenter les associations par des ovales plutôt que par des polygones :

Dans la barre de menus :

View \ Graphical settings :

Dans la boîte « Graphical settings », choisir « Rel-types\ Shape \ Round » :





Au résultat :





(6) Associations porteuses d’attributs

Merise permet qu’une association soit porteuse d’attributs, DB-MAIN aussi. On procède comme dans le cas de l’ajout d’attributs pour une entité-type :

On sélectionne l’association LIGNE_CDE, puis on clique sur l’icône « First att » (First attribute), qui est présente dans le ruban, ou bien on sert (plus volontiers) de l’icône présente au bas de la boîte « Property box » :





Comme dans les cas d’une entité-type, le fait d’avoir cliqué sur l’une ou l’autre des icônes « First att », en résulte la création d’un 1er attribut, nommé « New attribute » :





Par le biais de la boîte de propriétés, on renomme cet attribut à son gré, au besoin on en change le type, et le cas échéant on ajoute autant d’attributs que nécessaire. Pour ces différentes opérations, se reporter à l’ajout d’attributs pour une entité-type dans le billet ad-hoc.

Dans le cas présent, après avoir renommé l’attribut (Quantite en l’occurrence) et changé son type, la situation devient la suivante :





(7) Associations réflexives

La modélisation des associations réflexives ne pose pas de problème particulier. Comme avec tous les AGL, on doit veiller à nommer les rôles portés par les pattes d’association. Pour cela, on utilise la boîte de propriétés qui convient (Property box / Role).

Exemple d’une nomenclature de pièces (une pièce peut entrer en tant que composant dans la composition d’autres pièces et une pièce peut être composée d’autres pièces) :





(8) Associations ternaires

La modélisation des associations ternaires ne pose pas de problème particulier.

On établit une telle association pour savoir, par exemple, quels langages de programmation les développeurs de l'entreprise Dubicobit utilisent dans le développement des projets de la maison :





(9) Identification explicite d’une association ternaire

En Merise, l’identifiant d’une association est implicite, il est communément admis qu’il est obtenu par concaténation des identifiants des entités-types qui participent à l’association.

En conséquence, il arrive qu’on soit obligé de définir des entités-types factices, comme la célèbre entité-type DATE. Prenons l’exemple des livraisons de produits par des fournisseurs, avec les règles de gestion des données suivantes :

(RG1) A une date donnée, un fournisseur donné a pu livrer plusieurs produits ;

(RG2) A une date donnée, un produit donné a pu être livré par plusieurs fournisseurs ;

(RG3) Un fournisseur donné a pu livrer un produit donné à différentes dates, ce dont on garde la trace.

En Merise, on modélise cela ainsi :




Suite à quoi, l’identifiant implicite de l’association LIVRER est bien le triplet {ProduitId, FourniseurId, Date}. Mais, par dérivation du MCD en MLD puis en code SQL, l’entité-type DATE donnera lieu à une table DATE qui sera un véritable boulet, car pour chaque nouvelle livraison il faudra créer une ligne dans cette table inessentielle, qu’on se hâtera donc de supprimer.

Avec DB-MAIN, on procédera plutôt par identification explicite :

(a) On part du diagramme suivant, dans lequel la date de livraison est un attribut porté par l’association LIVRER, au même titre que l’attribut Quantite (cf. (6) plus haut) :





(b) On fait participer l’attribut LivraisonDate à l’identifiant de l’association LIVRER :





(c) Désormais, l’identifiant de l’association LIVRER est explicitement {LivraisonDate}, et il faut compléter, en faisant participer les entités-types FOURNISSEUR et PRODUIT. Dans la boîte de propriétés, on clique sur LivraisonDate (propriété components), ce qui fait apparaître le bouton :





En cliquant sur ce bouton, on fait apparaître la fenêtre « Multiple choice dialog » :





(d) On complète l’identifiant par transfert à gauche des éléments requis :





Le diagramme devient le suivant, dans lequel l’association LIVRER a bien pour identifiant le triplet {PRODUIT, FOURNISSEUR, LivraisonDate} :





Point ne fut besoin de mettre en œuvre une entité-type DATE.

______________________________________________________________________________