Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 17 sur 17
  1. #1
    Invité
    Invité(e)

    Par défaut Outil de modélisation - Diagramme entité relation

    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 !

  2. #2
    Expert Confirmé

    Homme Profil pro Florent SIEBERT
    Administrateur de base de données
    Inscrit en
    juin 2012
    Messages
    612
    Détails du profil
    Informations personnelles :
    Nom : Homme Florent SIEBERT
    Âge : 25
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2012
    Messages : 612
    Points : 2 970
    Points
    2 970

    Par défaut

    Bonjour,

    Mysql Workbench permet un affichage comme Access

  3. #3
    Invité
    Invité(e)

    Par défaut

    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|
    |____________|                         |____________|

  4. #4
    Expert Confirmé

    Homme Profil pro Florent SIEBERT
    Administrateur de base de données
    Inscrit en
    juin 2012
    Messages
    612
    Détails du profil
    Informations personnelles :
    Nom : Homme Florent SIEBERT
    Âge : 25
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2012
    Messages : 612
    Points : 2 970
    Points
    2 970

    Par défaut

    Il y a une option

  5. #5
    Invité
    Invité(e)

    Par défaut

    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 ?

  6. #6
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

    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 !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  7. #7
    Invité
    Invité(e)

    Par défaut

    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...
    Dernière modification par Invité ; 27/08/2012 à 10h34.

  8. #8
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

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

    Bon courage !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  9. #9
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro bruno pagès
    Développeur informatique
    Inscrit en
    juin 2005
    Messages
    3 192
    Détails du profil
    Informations personnelles :
    Nom : Homme bruno pagès
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2005
    Messages : 3 192
    Points : 5 073
    Points
    5 073

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    ... 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 ?
    Bruno Pagès, auteur de Bouml, mes tutoriels sur DVP (vieux, non à jour)

  10. #10
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  11. #11
    Invité
    Invité(e)

    Par défaut

    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.

  12. #12
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  13. #13
    Invité
    Invité(e)

    Par défaut

    À 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?)

  14. #14
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  15. #15
    Invité
    Invité(e)

    Par défaut

    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.

  16. #16
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  17. #17
    Invité
    Invité(e)

    Par défaut

    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.

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •