Discussion :

[bruno_pages]

Bonjour,

Je compte ajouter la gestion de MySQL (et peut être ensuite Oracle) dans Bouml, et ce en commençant par le MPD afin de pouvoir générer/reverser du MySQL. Je compte plus tard ajouter le MCD, et via des plug-outs ou autre moyen faciliter le passage MCD -> MPD. J'avoue que pour le moment je ne comprends pas très bien le MLD qui ne me semble être qu'un MPD en cours de construction.

Etant ignare dans ce domaine j'ai regarder les docs d'outils pour me faire une idée de la façon de représenter les choses, mais plusieurs choses restent floues.

Bien évidement une table sera supportée par une classe UML, et une colonne par un attribut. Le stéréotype <<table>> permettra de dire que la classe n'a rien à produire pour les autres langages, et de fournir des entrées de menu comme "add column" à la place de "add attribut" etc

Bien évidemment la représentation graphique d'un MPD se fera via un diagramme de classe, et, grâce au fait que l'on peut demander que le mode de représentation de certaines/toutes classes dans le diagramme ne suive pas UML mais dépend du langage, je peux avoir une représentation dédiée à MySQL.

J'hésite concernant la database elle même, je penche plus pour un artéfact que pour une classe, surtout que l'association artéfact - classes/tables sera nécessaire pour la génération de code (comme pour les autres langages), donc autant faire d'une pierre deux coups.

Comme je peux le voir dans d'autres outils une colonne intervenant dans une clef primaire sera marquée <pk> dans sa représentation dans un diagramme de classe/MPD. Si cette colonne intervient également dans une clef étrangère ou autre faut-il aussi ajouter <fk> etc pour indiquer ces cas ?

Les clefs étrangères seront bien-sûr représentées via une relation. J'ai rarement vu apparaitre dans les diagrammes le lien entre les colonnes des deux tables, et lorsque je l'ai vu c'était une indication de la forme colpa = colen où colpa est une colonne de la table enfant, moi j'aurais plutôt inverser l'ordre. Montrer ce lien entre les colonnes est-il utile ? Faut-il en montrer plus comme par exemple PowerAMC et indiquer qu'il y a cascade en modification etc ?

Enterprise Architecte utilise des opérations pour supporter les autres types de clefs, je penche plutôt pour des attributs comme pour les colonnes.

Est-il utile de montrer la définition des clefs dans la représentation graphique de la table ? Faut-il rendre leur affichage optionnel ?

Est-il utile de modéliser les vues afin de les générer/reverser ?

Merci de me donner votre avis

[fsmrel]

Bonjour Bruno,


C'est un plaisir de vous voir ici !

Pour le moment je ne comprends pas très bien le MLD qui ne me semble être qu'un MPD en cours de construction.

Vous n'avez pas tort... Le MLD est la traduction du MCD ou du DC en une structure orientée hiérarchique, liste inverse, réseau ou relationnelle. Disons que les premières structures citées répondent à des modèles (en fait à des classes de SGBD) dont l’intérêt est aujourd’hui purement historique puisqu’ils sont au relationnel ce que sont les chars à bœufs aux chars d’assaut. Les concepts pris en compte par le MLD orienté relationnel (sinon SQL) sont essentiellement ceux qu’impliquent l’algèbre relationnelle (les tables pour faire court et rester informel) : on reste donc à un niveau conceptuel.

Disons qu'à son tour, le MPD prend en compte la tuyauterie propre à chaque SGBD, c'est-à-dire fondamentalement les structures physiques indispensables pour héberger les constructions du niveau précédent et donnant lieu finalement à des fichiers : table spaces pour les tables, index pour permettre l’accès direct aux lignes des tables.

Par exemple, la norme SQL est plutôt du niveau MLD puisqu’elle ne prend pas en compte la tuyauterie (et ne s’intéresse pas à un SGBD en particulier !), mais traduit de façon plus ou moins fidèle et orthogonale les concepts du MRD (Modèle Relationnel de Données) :

— La table, qui est une approximation très relâchée (par exemple, les doublons ont droit de cité) de la variable relationnelle (relvar) du MRD.

— La colonne (l’attribut du Modèle Relationnel).

— Le type scalaire (ou domaine) de la colonne (essentiellement basique, built-in).

— Les contraintes générales telles que :

* La clé (candidate) sous la forme de clé primaire (qualificatif superflu et donc disqualifié aujourd’hui par le MRD) et de contrainte UNIQUE (clé alternative).

* La clé étrangère.

Etc.

Je regarde la suite de votre message et répondrai volontiers à vos interrogations.

[fsmrel]

Comme je peux le voir dans d'autres outils une colonne intervenant dans une clef primaire sera marquée <pk> dans sa représentation dans un diagramme de classe/MPD.

Si le MPD est orienté SQL, le concept de clé primaire est bien présent (repris du MLD), et vous pouvez effectivement faire apparaître un mickey tel que <pk> ou ou autre, mais ceci n’est pas indispensable dans la mesure où ce mickey fait double emploi avec, par exemple, le soulignement des noms des attributs participant à cette clé (ou tout autre artifice : nom des attributs en gras, etc.)

Cette représentation :




N’apporte rien par rapport à celle-ci :




Et, par exemple, Power AMC (j’utilise la V11) laisse le choix :

Si cette colonne intervient également dans une clef étrangère ou autre faut-il aussi ajouter <fk> etc pour indiquer ces cas ?

L’ajout d’un mickey <fk> est ergonomiquement parlant indispensable, à condition bien sûr qu’il ne fasse pas double emploi. Par exemple, je fulminerai si Power AMC n’affichait pas ce mickey. En revanche, avec certaines représentations (façon MS Access par exemple), cela ne sert à rien, quand les liens sont de colonne à colonne :



Dans l’exemple ci-dessus, la colonne (attribut) nommée EntrId participe à la clé primaire {EntrId} de la table ENTREPRISE, tandis que dans la table DEPARTEMENT une colonne nommée elle aussi EntrId participe à la fois à la clé primaire {EntrId, DeptId} et à la clé étrangère {EntrId} caractérisant la contrainte référentielle entre les tables ENTREPRISE et DEPARTEMENT (et traduisant manifestement une relation de composition).


La suite est dans les tuyaux. Je commencerai par commenter vos interrogations ci-dessous :

J'ai rarement vu apparaitre dans les diagrammes le lien entre les colonnes des deux tables, et lorsque je l'ai vu c'était une indication de la forme colpa = colen où colpa est une colonne de la table enfant, moi j'aurais plutôt inverser l'ordre. Montrer ce lien entre les colonnes est-il utile ? Faut-il en montrer plus comme par exemple PowerAMC et indiquer qu'il y a cascade en modification etc ?

[bruno_pages]

Bonjour,

merci pour vos réponses (en cours), cela n'étonnera personne si je dis que vous êtes l'une des personnes dont j'espérai fortement l'intervention . Mais que cela n’empêche évidemment pas d'autres personnes de répondre car mes questions portent sur des questions esthétiques et tout le monde n'a pas forcément les même goûts.

je sais déjà que ne suivrai pas la représentation à la MS Access (que je ne connaissais pas). Je n'ai pas encore décidé concernant la clef primaire (gras/souligné ou <pk>), mais pour être sure de bien vous comprendre, si je décide la représentation <pk> ainsi que <fk> et sans doute <uk> et <ak> (en plus de la relation des fk et éventuellement de l'affichage des définitions de ces clefs dans la représentation de la table), si une colonne intervient à la fois dans la clef primaire plus au moins une clef étrangère et pourquoi pas alternative (ni primaire ni étrangère ni unique) alors faudrait-il afficher <pk><fk><ak> pour cette colonne ?

si je choisi les indications <xx> elles seront probablement soumises à une option de dessin (peut être via show attribute modifiers déjà existant). Les indications de type des colonnes le seront sûrement car c'est déjà le cas pour les autres langages (show members full definition), idem pour NULL/not NULL

[CinePhil]

Bonjour Bruno.
Ravi de voir que tu n'as pas abandonné ton superbe outil de modélisation et que tu souhaites même l'enrichir d'un panier de Merise !

Normalement, on commence par le MCD, dans lequel les entités types sont traditionnellement représentées par des rectangles et les associations par des ovoïdes reliés par des traits pleins aux entités types ; sur ces traits pleins figurant les cardinlités (inversées et d'un codage légèrement différent par rapport à UML).

Puis on nous apprend en cours que le MCD se dérive en MLD, dans lequel les tables sont représentées par les mêmes rectangles que les entités types du MCD, les associations étant remplacées par des flèches, certaines associations donnant lieu de plus à la création de nouvelles tables que j'appelle des tables associatives.

Je n'ai jamais aimé cette représentation. Notamment, j'ai toujours eu une hésitation sur le sens de la flèche. Il existe d'autres représentaitons, notamment le diagramme "Entity/relationship" de MySQL Workbench que je trouve plus clair que le MLD enseigné avec la méthode Merise. D'ailleurs, ce logiciel est très complet pour MySQL. Il ne lui manque que le MCD ou le diagramme de classes selon la préférence de chacun.

Quant au MPD, il est vrai qu'il tient compte en principe des spécificités du SGBD qu'on va utiliser, notamment les types des colonnes qui n'ont pas toujours le même nom, ce qui peut poser problème quand on veut générer le code de la BDD à partir du schéma réalisé, par exemple dans Open Modelsphere.

Tu pourrais d'ailleurs jeter un oeil du côté de ce logiciel qui est un des rares à faire aussi bien du Merise que de l'UML et qui présente l'avantage d'être gratuit mais il est encore perfectible.

La tendance est quand même à prendre en compte, peut-être à tord, dès le MCD, le SGBD qui sera utilisé et de définir les types des propriétés (futures colonnes) dans les entités types. De plus, deux schémas au final suffisent à mon sens pour définir la future BDD (ou la BDD existante par rétro-ingénierie) :
- Le MCD qui décrit très bien les associations entre les entités ;
- Le diagramme Entity/Relationship, façon MySQL Workbench, qui décrit bien les futures tables de la BDD avec ses clés étrangères et ses index.

Dans le MCD, ne pas oublier la représentation des contraintes entre assoications (inclusion, exclusion, totalité) et les contraintes sur les données (CHECK, ASSERT). Les premières sont, je pense, similaire à ce que tu dois déjà utiliser pour UML et les secondes peuvent être écrites dans des notes reliées aux entités types ou aux associations.

Bon courage ! Je suis impatient de voir le résultat !

[bruno_pages]

Bonjour,

Merci de votre réponse, je comptais aussi sur vos réactions

Je vais regarder ce que proposent MySQL Workbench et Open Modelsphere.

Ne soyez quand même pas trop impatient, je débute l'étude de la chose. Comme je l'ai dis au début, la 6.0 ne gérera que le MPD, car le but est bien de générer / reverser du MySQL et non rester au niveau conceptuel. Le MCD sera disponible plus tard, mais pour le moment ce qui m’intéresse c'est seulement le MPD.