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.

[fsmrel]

Bonjour valeureux Bruno et Philippe,

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 ?

Dans le diagramme ci-dessous, le schéma de la table B répond aux dépendances fonctionnelles suivantes éminemment respectables :

{A1, C1} -> {B1, B2},
{C1, B1} -> {A1, B2}.




A propos de MySQL Workbench

Pour vous faire gagner un peu de temps, si vous avez besoin de quelques éléments d’information j’en fournis passim, par exemple chez jogodepau, voire chez Lei57.

[fsmrel]

Faut-il en montrer plus comme par exemple PowerAMC et indiquer qu'il y a cascade en modification etc ?

Ce que vous nommez « cascade » est un raccourci de ce que la théorie relationnelle appelle une action compensatoire. Je cite et traduis Chris Date (voyez The Relational Database Dictionary chez Apress) :

Action compensatoire

Une mise à jour effectuée automatiquement par le système en complément d’une mise à jour initiale, l’objet étant d’éviter une violation d’intégrité qui autrement pourrait se produire. Un exemple typique est l’effet en cascade d’une opération de suppression. Une action de cette nature doit être spécifiée de façon déclarative, et les utilisateurs doivent être tenus au courant ; c'est-à-dire savoir que leurs requêtes de mise à jour sont en fait des raccourcis et complétées par un ensemble d’actions, car à défaut ils pourraient se méprendre et interpréter les résultats comme une violation du Principe d’affectation.

A propos du principe d’affectation :

Si on a affecté la valeur v à la variable V , la comparaison v = V doit donner VRAI (TRUE).

Par exemple, si en SQL, en fait d’affecter la valeur v à la variable V on affecte NULL, il s’ensuit que la comparaison v = V donne INCONNU (UNKNOWN).

[bruno_pages]

bigre diantre, je pensais que fk et autre étaient des marques, et donc que l'on avait pas fk<n>. fk1 et fk2 sont les noms des contraintes ou simplement une numérotation des fk parce qu'il y en a plusieurs ? ne peut-on rester au simple fk (sans indice) pour indiquer simplement que la colonne est associée à au moins une clef étrangère ?

merci pour les liens vers les discussions/présentation de MySQL Workbench

pour les multiplicités je pense que je ferai comme pour UML, c.a.d. n1..n2 et non les marques O et _ sur le tracé des relations

Ce que vous nommez « cascade » ...

en fait je voulais juste savoir s'il était utile de les indiquer dans le MPD comme on peut le voir à la page 186 de doc de Power AMC

A propos du principe d’affectation ...

je parlais de la description des clefs étrangères c.f. exemple Power AMC avec entre autre l'indication Col_1 = t1_Col_1

• est-il utile de montrer cette information ?
• le sens est-il pertinent ou faudrait-il plutôt t1_Col_1 = Col_1 ?
• une autre représentation serait-elle souhaitable pour afficher ces liaisons ?

De nouveau, est-il utile de montrer la définition des clefs dans la représentation graphique de la table ?
Faut-il rendre leur affichage optionnel ?
Il s'agit de l'affichage des deux dernières ligne de table1 qui pourraient être quelque chose comme :

Code :

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

1
2
3
4
5
6
7
8
9

|          table1            |          |   table2    |
|----------------------------|          |-------------|
| c1                <pk>     | ======>  |  c     <pk> |
| c2                <pk>     | 
| c3                <fk>     | 
| pk (c1, c2)                |
| fk c3_c (c3) ref table2(c) |

[fsmrel]

Bonsoir,


Je constate après coup que vous avez acquis une certaine dextérité pour fouiller dans Power AMC et certains commentaires et images ci-dessous ne vous apporteront rien, mais, le cas échéant, ça pourra toujours servir plus tard et être utile à d’autres...

Ne peut-on rester au simple fk (sans indice) pour indiquer simplement que la colonne est associée à au moins une clef étrangère ?

Je pense qu’effectivement indicer les clés étrangères n’apporte rien. Dans l’exemple ci-dessous, on voit bien qu’il y en a trois pour la table B, il suffit de compter les arcs qui partent de la table. En revanche, même en ayant indicé, inférer soi-même les correspondances entre les colonnes des tables en relation avec B, ça n’est pas forcément immédiat (pour corser, on a désormais deux clés alternatives, sinon ça ne serait pas drôle...) :




Quoi qu’il en soit, avec Power AMC et MySQL Workbench, on a toujours la possibilité d’aller voir quelles sont ces relations. Par exemple, par un clic droit sur l’arc connectant B et E, on a accès à la fenêtre qui va bien (je suis toujours avec la V11 de Power AMC) :

Clic =>



Puis (par « Jointures... ») :




Et là, on sait à quoi s’en tenir.


On peut aussi demander l’affichage des jointures (Outils > Préférences d’affichage et cocher la case Jointure) :




Au résultat :



Mais j’avoue qu’il s’agit là d’une possibilité dont je ne me sers jamais.

pour les multiplicités je pense que je ferai comme pour UML, c.a.d. n1..n2 et non les marques O et _ sur le tracé des relations

Parfait. Avec AMC, si l’on coche la case « Cardinalité » dans la fenêtre Préférences d’affichage, on obtient :



En notant que l’AGL a faux quant à la cardinalité porté par le lien entre C et X...


Actions compensatoires :

en fait je voulais juste savoir s'il était utile de les indiquer dans le MPD

Non. Pour ma part, il est rare que je les indique. Voyez par exemple ici, chez heretik25. Par ailleurs, Power AMC est verbeux ès matière : dans le cas d’heretik25, je ne m’intéresse qu’à « On Delete Cascade », car depuis toujours (du moins depuis 1988, année de l’apparition de l’intégrité référentielle avec DB2), je me limite à « On Update Restrict » puisque la modification en cascade d’une valeur de clé primaire peut avoir des conséquences désastreuses (demandez à CinePhil ce qu’il en pense...) : Power AMC pourrait offrir la possibilité de se dispenser de « On Update », au bénéfice du seul « On Delete » (cela concerne l’immense majorité des professionnels de la modélisation). Dans le cas d'heretik25, j'ai contourné le verbiage de Power AMC en détournant l'usage des rôles (prévoir ceux-ci !) et en les nommant "Cascade" ou "Restrict"...

je parlais de la description des clefs étrangères

Je pense avoir répondu ci-dessus.

De nouveau, est-il utile de montrer la définition des clefs dans la représentation graphique de la table ?

L’essentiel est de ne pas être redondant. Jusqu’ici, les mickeys <pk> <ak> et <fk> m’ont largement suffi. Grâce au cartouche du bas, Power AMC permet d’avoir en plus le nom des clés candidates (primaires et alternatives) mais sans fournir la liste des attributs dont elles sont composées (en tout cas avec la V11) : autant dire qu’en l’état, cette possibilité n’offre aucun intérêt.

Maintenant, si vous fournissiez l’ensemble des attributs pour chaque clé candidate ou étrangère, je dirais : banco ! Mais alors le soulignement et les mickeys deviendraient redondants et pourraient disparaître. En fait, pouvoir choisir entre les deux possibilités serait préférable. Mon choix personnel porterait plutôt sur votre dernière proposition, car on y appelle un chat un chat (on est près du code SQL qui ne souffre aucune ambiguïté). Pour reprendre le cas de la table B ci-dessus cela donnerait :



Mais il y a un problème, celui de l’encombrement engendré par des noms de colonne à rallonge : on risquerait d’avoir des cartouches obèses...

[bruno_pages]

Bonjour,

merci à vous deux pour toutes ces infos

je vais laisser la discussion en non résolue encore quelques jours pour laisser le temps à d'autres personnes d'exposer leur desiderata

[bruno_pages]

pour information je commence l'implémentation, je passe donc cette discussion à résolue

[fsmrel]

A bientôt donc !

Bon courage,

François

[DaizDev]

Bonjour,

Merci pour ce sujet théorique très intéressant, merci aux participants.

Pourrait-il être épinglé s'il vous plait ?

Etant moi aussi, ré-inventeur de la roue , je suis sur le développement d'un ERD sous Symfony2. J'ai prévu également une représentation graphique de l'ORM à partir de Doctrine et différents outils.

Je suis ouvert à toutes remarques, questions, idées.

Bonne continuation

[Richard_35]

Bonjour DaizDev,

Etant moi aussi, ré-inventeur de la roue , je suis sur le développement d'un ERD sous Symfony2. J'ai prévu également une représentation graphique de l'ORM à partir de Doctrine et différents outils.

==> chapeau pour le développement que tu entreprends ! .

Je suis ouvert à toutes remarques, questions, idées.

==> par contre, te greffer sur une discussion résolue n'est certainement pas le bon moyen d'obtenir la pro-activité des forumeurs !...

Sans compter le fait que la présente discussion deviendrait un capharnaüm sans nom... re-. Et que dire en cas d'arrivée d'une troisième discussion... re-re-.

Je te suggère donc d'ouvrir une discussion propre à ce sujet.

[DaizDev]

par contre, te greffer sur une discussion résolue n'est certainement pas le bon moyen d'obtenir la pro-activité des forumeurs !...

Je te suggère donc d'ouvrir une discussion propre à ce sujet.

Pas de souci, voici le lien du sujet créé http://www.developpez.net/forums/d12...2/#post6813790