Outil de modélisation - Diagramme entité relation [Résolu]

[darnold]

Bonjour,

Je ne trouve pas vraiment de rubrique adapté à cette question donc je poste ici.

Je suis a la recherche d'un outil de modélisation de base de donnée tout simple, avec une seule contrainte :
- je veux que les flèches représentant les liens entre les tables soient au niveau des champs liés, et non pas justes accrochés a un endroit au hasard sur le rectangle représentant la table.

Sa parait idiot, mais j'en ai déjà testé plein, et je n'en trouve pas qui réponde a ce critère, mis à part Access (mais ça fait vraiment sortir une usine a gaz juste pour faire un schéma (en plus il est payant)).

Merci pour votre aide !

[FSiebert]

Bonjour,

Mysql Workbench permet un affichage comme Access

[darnold]

Je viens de le tester.
Malheureusement il n'a pas l'air de répondre a ma contrainte : les liens entre tables ne sont pas accrochée au champs. Ce que je veux c'est un truc comme ça :

Code :

1
2
3
4
5
6
7
--------------                         --------------
|   TABLE1   |                         |   TABLE 2  |
|------------|                         |------------|
| ClePrimaire|---------------\         |Cleprimaire |
| champs...  |                \--------|CleEtrangère|
|____________|                         |____________|

[FSiebert]

Il y a une option

[darnold]

Je ne trouve pas cette option ! Est ce que tu n'en connais pas un autre du même genre qui ne serait pas spécifique pour mysql ?

[CinePhil]

Pourquoi avez-vous absolument besoin de cette présentation ?

Normalement, les tables sont associées entre une clé primaire et une clé étrangère. Si vous utilisez un standard de nommage pour vos colonnes, il est très facile de savoir de quelle table provient la clé étrangère. Inutile alors de s'embêter à pointer un trait vers un nom de colonne spécifique.

Exemple avec mon standard de nommage...
MCD :
personne -0,n----diriger----1,1- projet

Tables :
t_personne_prs (prs_id, prs_nom, prs_prenom...)
t_projet_prj (prj_id, prj_id_chef, prj_nom...)

=> On devine bien que le chef de projet est une personne et que la clé étrangère fait donc référence à l'identifiant d'une personne.

Il est plus important de faire un bon modèle de données qu'un beau schéma !

[darnold]

Pourquoi avez-vous absolument besoin de cette présentation ?

Normalement, les tables sont associées entre une clé primaire et une clé étrangère. Si vous utilisez un standard de nommage pour vos colonnes, il est très facile de savoir de quelle table provient la clé étrangère. Inutile alors de s'embêter à pointer un trait vers un nom de colonne spécifique.

Il est plus important de faire un bon modèle de données qu'un beau schéma !

Alors là, je suis entièrement d'accord avec vous !
Encore que... j'ai tendance à penser qu'un bon modèle de donnée sans schéma ne vaux pas grand chose. Mais là n'est pas la question.

Malheureusement on a pas toujours la chance de rejoindre un projet à sa phase de conception.

Et lorsque le projet en question est un très gros logiciel (un ERP en l’occurrence) et qu'on est amené à développer dessus, il est très utile de pouvoir se faire ses propres schémas de petites portions de la base.

Et là si vous avez directement les liens qui pointent au bon endroit, je peux vous assurez que vous gagez un temps fou lors de vos développement...

[CinePhil]

Encore un ERP avec un modèle de données bizarre ?

Bon courage !

[bruno_pages]

Envoyé par CinePhil

... Si vous utilisez un standard de nommage ...

je sort du cadre précis de cette discussion, mais les outils genre modeleur UML (au hasard ) que vous connaissez permettent-t-il d'automatiser la chose ?

dans le cas d'une colonne se serait par exemple l'ajoute en préfixe du nom de la table, et pour les clefs (non primaire) le nom de la table suivit du nom des colonnes définissant la clef permettant à ces dernières d'avoir un nom totalement calculé

ce genre d'automatisation chose serait-il intéressant à avoir tout en rendant cela paramètrable et débrayable ?

[CinePhil]

Oui ce serait intéressant.

Je crois que Open Modelsphere prévoit ce genre de truc mais je n'en suis pas sûr.

Power AMC aussi peut-être ?

MySQL Workbench a un standard de nommage par défaut mais je ne sais pas s'il est modifiable dans les options du logiciel.

[darnold]

Effectivement on sort du carde de la discussion !
Mais ça n'est pas grave puisque j'ai fini par trouver :
- MySQL Workbench dispose effectivement d'un paramétrage (globalement c'est plutôt pas mal ce truc, dommage qu'il soit autant orienté mysql).
- Visual Studio permet également de représenter des modèle de données de manière très simple et très paramétrable.

Je met donc le sujet en résolu, merci !

Concernant la petite digression de bruno_pages :

dans le cas d'une colonne se serait par exemple l'ajoute en préfixe du nom de la table, et pour les clefs (non primaire) le nom de la table suivit du nom des colonnes définissant la clef permettant à ces dernières d'avoir un nom totalement calculé

Attention tout de même a ne pas trop alourdir le nommage de tes champs !
Parfois il vaux mieux des noms simples qui veulent dire quelque chose que des noms à rallonges composés de plein de trigrammes et d'abréviation, que plus personne ne comprend à par le concepteur (lorsqu'il est encore dans la société!)

Pour moi la clé d'un modèle réussi, c'est des variables qui veulent dire quelque chose, et un bon diagramme entité relation.

[CinePhil]

Attention tout de même a ne pas trop alourdir le nommage de tes champs !
Parfois il vaux mieux des noms simples qui veulent dire quelque chose que des noms à rallonges composés de plein de trigrammes et d'abréviation,

Je suis d'accord qu'un nom entièrement codé est illisible et incompréhensible. Il paraît que le modèle de données de SAP est fait comme ça exprès pour dissuader les clients de développer des outils en interrogeant directement la BDD.

Mais un standard de nommage tel que celui de SQLPro est tout à fait compréhensible et empêche rigoureusement l'emploi accidentel de mots réservés du langage SQL ou de signes pouvant poser problèmes.

Un exemple de ce que je peux faire avec un tel standard...

À partir d'un MCD de base :
personne -0,n----travailler----0,n- projet

J'arrive aux tables suivantes :
te_personne_prs (prs_id, prs_nom, prs_prenom...)
=> table issue d'une entité (te) représentant une personne et dont les colonnes seront préfixées du code mnémotechnique prs.
te_projet_prj (prj_id, prj_nom...)
=> même principe
tj_prs_travailler_prj_ptp (ptp_id_personne, ptp_id_projet...)
=> "table de jointure" (tj) issue de l'association "travailler" du MCD entre prs, c'est à dire la table des personnes, et prj, c'est à dire la table des projets, et dont les colonnes seront préfixées du code mnémotechnique constitué des initiales des mots constituant l'association : p (personne), t (travailler), p(projet).

À force d'utiliser un tel standard, on arrive à écrire les requête sans même regarder le modèle de données.

[darnold]

À force d'utiliser un tel standard, on arrive à écrire les requête sans même regarder le modèle de données.

Pour un habitué du modèle, oui surement, mais pour les nouveau, ou ceux qui interviennent ponctuellement sur le projet, ils vont se faire des noeuds au cerveau avec votre tj_prs_travailler_prj_ptp !

Moi je serais plutôt partisant d'un truc plus simple :

personne (id,nom,prenom)
projet (id,nom)
personne_projet (id_personne,id_projet)


En ensuite préfixer dans les requêtes :

Code :

1
2
3
4
5
select prs.nom 
from personne as prs
join personne_projet prj_prj 
   on prs_prj.id_personne = prs.id

Je n'ai jamais compris l’intérêt de cette règle qui consiste a vouloir a tout prix qu'il n'y ai pas 2 noms de champs identique dans le modèle. (Je crois que c'est Merise qui veux ça?)

[CinePhil]

Moi je serais plutôt partisant d'un truc plus simple :

personne (id,nom,prenom)
projet (id,nom)
personne_projet (id_personne,id_projet)

Sauf qu'en nommant ainsi, on se retrouve vite à nommer des colonnes "date" ou "row"... ou un autre mot du langage SQL, ce qui pose des erreurs bêtes et qui font perdre du temps.

La preuve dans cette discussion de ce matin !

Je n'ai jamais compris l’intérêt de cette règle qui consiste a vouloir a tout prix qu'il n'y ai pas 2 noms de champs identique dans le modèle. (Je crois que c'est Merise qui veux ça?)

1) Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

2) Non je ne crois pas que ce soit une règle de la méthode Merise.
Le fait de préfixer permet justement de savoir sans ambiguïté d'où vient la colonne. Je ne fais pas ça du tout dans un souci de respecter cette soi-disant règle.

[darnold]

Sauf qu'en nommant ainsi, on se retrouve vite à nommer des colonnes "date" ou "row"... ou un autre mot du langage SQL, ce qui pose des erreurs bêtes et qui font perdre du temps.

C'est certain ! Après, que dire du temps perdu a essayer de comprendre les trigrammes utilisés dans une base de donnée que l'on n'a pas conçu soit-même ? (Je suis un traumatisé du trigramme )

1) Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

Non. Un tableau est composé de colonnes et de lignes. Une table est composé de champs et d'enregistrements. En fait je pense que les deux se disent, ça dépend si on fait du Merise, de l'entité-relation, du SQL Server, de l'Oracle...
Globalement, en s'en fiche, tant qu'on se comprend...

Le fait de préfixer permet justement de savoir sans ambiguïté d'où vient la colonne. Je ne fais pas ça du tout dans un souci de respecter cette soi-disant règle.

Je parle de règle car j'ai souvenir d'avoir appris cette "règle" en cour de Merise justement, mais ça remonte un peu. Bref.
Je ne suis toujours pas convaincu par son utilité car de toute façon une colonne est toujours utilisée avec sa table ! On fait un "select colonne from table", pas un "select colonne" tout court. Je ne vois pas à quel moment l’ambiguïté est possible.

[CinePhil]

Non. Un tableau est composé de colonnes et de lignes. Une table est composé de champs et d'enregistrements.

Totalement faux !

Comment ajoute t-on un "champ" à une table ?

Code :

1
2
ALTER TABLE la_table
ADD COLUMN la_colonne VARCHAR(50)

Et dans un trigger :

Code :

BEFORE INSERT FOR EACH ROW

Et FIELD ne figure pas dans les mots réservés du langage SQL !

CQFD !

Je ne suis toujours pas convaincu par son utilité car de toute façon une colonne est toujours utilisée avec sa table ! On fait un "select colonne from table", pas un "select colonne" tout court. Je ne vois pas à quel moment l’ambiguïté est possible.

Ben dès qu'il y a plusieurs tables utilisées dans la requête !
Bien entendu, il faut alors préfixer les colonnes par l'alias donné à la table mais tellement de DBA du dimanche ne le font pas !

Et encore faut-il que l'alias soit explicite donc mnémotechnique parce qu'en appelant tous ses identifiants simplement "id", si on donne des alias aux tables du genre t1, t2, t3... c'est encore une perte de temps pour savoir si c'est l'identifiant du client, de la commande, du produit, de la livraison, de la facture...

Bref, plus les noms choisis sont explicites et plus la requête sera facile à lire, à analyser, à comprendre, à débugguer.

[darnold]

Non. Un tableau est composé de colonnes et de lignes. Une table est composé de champs et d'enregistrements.
Totalement faux !

Suffit-il que ça soit écrit dans la faq de développez.net pour que ça soit vrai ? Ce vocabulaire est employé et compris par beaucoup de monde, il doit donc avoir une origine car c'est vrai qu'il n'est pas très intuitif de prime abord (par rapport a colonne et ligne). Enfin bon, la on digresse dans la digression, ce débat sur le vocabulaire n'a en fait pas beaucoup d’intérêt je trouve ^^.

Ben dès qu'il y a plusieurs tables utilisées dans la requête !
Bien entendu, il faut alors préfixer les colonnes par l'alias donné à la table mais tellement de DBA du dimanche ne le font pas !

De toute façon, quelle que soit la règle utilisée, elle n'a d'utilité que si elle est utilisée partout et par tout le monde. Mais c'est un autre sujet.

Et encore faut-il que l'alias soit explicite donc mnémotechnique parce qu'en appelant tous ses identifiants simplement "id", si on donne des alias aux tables du genre t1, t2, t3... c'est encore une perte de temps pour savoir si c'est l'identifiant du client, de la commande, du produit, de la livraison, de la facture...

Ca n'a aucun sens de choisir des alias comme ça ! (t1 t2 t3). La première chose qu'on apprend a un développeur c'est de bien choisir le nom de ses variables.