Une sélection d'outils libres pour la modélisation pour les bases de données

Posté par  . Modéré par Nÿco.
Étiquettes :
0
3
août
2003
Technologie
Je vous présente deux logiciels sous licence GPL pour la conception de bases de données. Une rareté !

Le premier logiciel, devaki-nextobjects (sous licence GPL), permet de faire la modélisation avec la méthode Merise. Ce logiciel comblera-t-il le manque de logiciels de modélisation Merise sous Linux ?

Le deuxième logiciel, DBDesigner 4 (sous licence GPL) permet d'éditer, de modéliser, de concevoir visuellement des bases de données avec MySQL.

Aller plus loin

  • # bof bof bof

    Posté par  . Évalué à 4.

    dbdesigner c'est du delphi ... super c'est pas vachement libre non plus

    • [^] # Re: bof bof bof

      Posté par  (site web personnel) . Évalué à 4.

      Ca nécessite un runtime propriétaire pour tourner sous Linux ?

    • [^] # Re: bof bof bof

      Posté par  . Évalué à 9.

      Est-ce que le langage utilisé a une importance pour faire un programme libre (donc est-il obligatoire d'avoir un moyen libre de le compiler) ?

      De toute manière, il est bien indiqué que les sources se compilent avec Delphi 7 ou Kylix 3. Il n'y a donc aucun problème puisqu'il existe me semble-t'il une version "Open Edition" de Kylix pour réaliser des logiciels GPL.

      D'ailleurs le site est assez clair sur leur licence :
      DBDesigner 4 compares to products like Oracle's Designer©, IBM's Rational Rose©, Computer Associates's ERwin© and theKompany's DataArchitect© but is an Open Source Project available for Microsoft Windows© 2k/XP and Linux KDE/Gnome. It is release under the GPL.

  • # Re: Une selection d'outils libres pour la modelisation pour les bases de données

    Posté par  . Évalué à 6.

    moi, j'utilise dia en mode uml avec un outils de conversion xml->sql
    ça marche assez bien.

  • # Java Libre...

    Posté par  (site web personnel) . Évalué à 10.

    ralala ca me fait marrer la "ndm" concernant java et son coté Libre !

    Pour moi, java est comparable au développement d'un protocole "ouvert" (dans le sens que ses RFC -par exemple- sont ouvertes à tous) de type H.323 ou bien d'autres. Leurs spécifs sont cadrées par des entités bien définies qui font "autorité" sur la question. Après, rien n'est fait pour empêcher des projets comme OpenH323. Je pense que Java répond au même principe. La Libre implémentation est toujours possible. C'est en ça que l'approche effectuée avec ce genre de technologie est très positif... même s'il existe des implémentations "officielles" de cette techno non Libres.

    • [^] # Re: Java Libre...

      Posté par  . Évalué à 5.

      D'autant plus amusant que la position de la FSF est claire : "Java c'est bon, mangez en."

      Ca m'ennuie de faire suivre le troll mais bon ... Il faudra m'expliquer quelle barrière vous avez trouvé à l'utilisation de java.

      Il faut aussi absolument en faire part sur Javaweb-discuss-request@gnu.org (mot clé : subscribe). Le monde a le droit de savoir !

      M

    • [^] # Re: Java Libre...

      Posté par  (site web personnel) . Évalué à 10.

      Parfaitement. Je trouve cette attitude assez lamentable personnellement, d'autant plus qu'en ce moment on entend souvent dire de la part des modéros que LinuxFR n'est pas FreeSoftwareFR. En fait, ce qu'il faut de se demander c'est: est-ce que cette remarque peut sembler pertinente pour certains des lecteurs ?
      Je ne crois pas.

      • [^] # Re: Java Libre...

        Posté par  (site web personnel) . Évalué à 0.

        surtout quee des '''runtimes''' libres existent ...
        c'est vraiment un troll ou elle est sérieuse la NDM ?

        • [^] # il n'existe pas de JVM libre respectant les specs java, brevets et copyrights

          Posté par  . Évalué à 2.

          les normes Java telles que publiées par Sun sont très loin d'être respectées par les JVM libres atuelles. il manque d'importantes parties de la norme qui ne sont pas du tout implémentées (par exemple Swing est un truc énorme très loin d'être implémenté), sans parler des nombreuses extensions de cette norme.

          le problème se situe aussi du côté des brevets et copyrights de Sun: les APIs Java publiées par Sun sont loin d'être libres et sous une licence clairement incompatible avec la GPL http://java.sun.com/j2se/1.4.2/docs/relnotes/license.html(...) Il y'a des chances non négligeables (on n'est jamais à l'abri d'une coïncidence quand on implémente de tout petits programmes ayant des specs très précises) que leur réimplémentation puisse être en partie considérée comme du plagiat du code actuel de Sun, sans compter les nombreux brevets qu'a déposé Sun.

          l'affaire Sco est exemplaire de ce qui pourrait un jour arriver aux JVMs libres. il suffit de voir les problèmes qu'ont déjà eu des projets libres comme Jboss ou Enhydra avec Sun

          pour une distrib entièrement libre comme Debian l'affaire est réglée depuis longtemps: tous les programmes libres Java qui ont besoin d'une JVM non libre (la majorité) ne peuvent pas faire partie de Debian

          PS: c'est pas si grave, on utilisera des p2p anonymes pour s'échanger les JVMs libres sous le manteau :)

      • [^] # Re: Java Libre...

        Posté par  (site web personnel) . Évalué à 1.

        Tiens, il faudra que tu me dises quels sont les modéros qui disent ça.
        Il est néanmoins exact que les LL sous win et autres nous intéressent moins, et alors?

    • [^] # Re: Java Libre...

      Posté par  (site web personnel) . Évalué à 2.

      Marrant que tu dises ca, car je connais quelques projets parfaitement libres, comme http://arkanae.tuxfamily.org/(...) , qui n'ont pas ete inclus dans au moins la mandrake (peut etre d'autres) justement parceque java n'est pas libre...
      Maintenant, je dis ca, je dis rien....

      • [^] # Re: Java Libre...

        Posté par  . Évalué à 2.

        Peut être n'ont-ils pas été inclus parcequ'il n'existe pas à ce jour d'implémentation suffisament sérieuse et libre de Java.

        Pour inclure des applications Java, il faudrait donc inclure également dans la distribution un JRE non libre.

        BeOS le faisait il y a 20 ans !

    • [^] # Re: Java Libre...

      Posté par  (site web personnel) . Évalué à 2.

      J'ai viré la note du modérateur qui effectivement n'a pas beaucoup de sens. Il y a des implémentations de java libres, d'autres proprios, comme pour le C++, le C ou le Lisp.

  • # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

    Posté par  (site web personnel) . Évalué à 3.

    Y'a un moment où j'avais voulu écrire des "formes" MERISE pour DIA, mais c'est achtement trop compliqué pour moi. Les formes simples c'est du SVG, mais les formes avec plus d'un champ texte faut les coder en C, et moi j'y connais pas grand chose.
    Y'aurais pas quelqu'un qui aurait déjà commencé (voire terminé...) le boulot par hasard ? Parce que nextobjects ça m'a l'air quand même un peu gros si on veut juste faire un petit MCD.

    Merci

    • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

      Posté par  (site web personnel) . Évalué à 4.

      Bof ! j'écris directement le SQL, ce n'est pas bien compliqué.
      Ce n'est pas un logiciel qui évitera les mauvaises conceptions. Le rôle du concepteur est et restera infiniment plus important.

      • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

        Posté par  (site web personnel) . Évalué à 7.

        Désolé, je suis d'accord que pour un modèle simple, un papier, un crayon et un peu de réflexion suffit pour pondre le code SQL qui va bien.

        Mais pour un modèle plus complexe du type 30 tables, 30 relations et des contraintes un peu complexes (fréquent en entreprise comme modèle), un bon soft de modélisation est nécessaire, voir obligatoire pour créer le schéma.

        Je suis d'accord que rien ne remplacera jamais une bonne conception à la base, soft ou pas.

      • [^] # Re: Pour la modélisation pour les bases de données

        Posté par  . Évalué à 8.

        C'"est vrai que c'et pas compliqué, une fois qu'on a le coup de main. Mais pour de la doc, pour passer un projet/dossier il n'y a pas mieux qu'un bon MPD.
        J'ai lu un jour: "Donnez moi des specs des docs je ne lirai rien. Donnez moi un MPD et je comprendrai tout."
        Un modèle de données résume la vie et les ambitions d'un système d'information. Je travaille actuellement sur des bases DB2 quasi "fichiers textes". Tout est dans une ligne de table. Avant c'était le contraire: une SSII avec de l'ambition et des reves pleins la tete, on avait fait un schéma ultra complexes, abstrait et générique (et magnifique). Entre les deux, mon coeur balance...
        Mais quand tu parles à des gens pour qui une base c'est un fichier Excel, c'est à dire un long tableau à plat, tu regardes les petits schémas avec nostalgie...
        Soit dit en passant de voir d'aussi lourds/gros fichiers (c'est le petit nom des tables en db2) cela m'a appris la puissance de l'indexation! Indexez, indexez il en restera toujours quelque chose!
        La première fois que tu vois un fichier de 10.000.000 d'enregistrements traversé en un temps minuscule, tu pleures ta mère en pensant aux time-out sur des extractions de bases trop compliquées. C'est simple, c'est brut, ça marche... C'est passionnantet satisfaisant comme la pluie.
        Bref, un petit schéma et tu sais tout de suite où tu mets les pieds.

        • [^] # Re: Pour la modélisation pour les bases de données

          Posté par  . Évalué à 7.

          Je ne suis pas certain que des recettes "simples" et utilisées systématiquement soit la meilleure façon d'optimiser les requétes sur n'importe quelle base de données.
          L'un des ERP les plus dramatiquement lent du marché, que je ne nommerai pas, est indéxé à tout va ( au moins 12 index par table).
          Les performances sont lamentables.
          Uns base de données bien conçue facilite certainement l'optimisation mais ce n'est pas suffisant.
          Il faut consacrer pas mal de temps en plus du codage des requètes à améliorer leurs performances. Un bonne connaissance du moteur employé est évidemment nécessaire.
          Aussi, je suis plutôt circonspect quand à la résolution en amont (dès la conception) des problèmes de performance d'accès aux données.
          C'est une phase à part entière qui fait partie du développement.
          La négliger, voire ne pas la faire du tout, ce qui est le cas le plus fréquent, c'est prendre le risque de livrer un produit de faible qualité.

          • [^] # Re: Pour la modélisation pour les bases de données

            Posté par  . Évalué à 2.

            Absolument!
            D'autant que c'est un trvail ingrat au début mais vite gratifiant. Mais ça demande de remplir la base de test (=trouver un c..odeur pour faire ça). Pénible.
            Indexer n'est pas tout. Il faut tester chacun des requêtes pour voir si elle prend les bons chemins.
            Quant à connaître son optimiseur je souscris de même: tu changes l'ordre de tes arguments dans le where et un molasson qui met à plat le serveur devient un cheval de course (ça peut être de l'ordre de 1 à 1000).
            Une appli tueuse de machine peut devenir une appli normale, en changeant l'ordre des tables du from et des conditions du where.
            Ce qui d'ailleurs peut poser des pbs aux applications génériques dont on parlait plus haut, non?
            L'un va avec l'autre: optimiser la requête, optimiser la base en conséquence.

            Deux petites questions: on peut aussi bien faire booster des requêtes avec n tables bien attaquées qu'avec une seule table bien indexée ?
            Vous utilisez quoi pour optimiser vos requêtes?

            • [^] # Re: Pour la modélisation pour les bases de données

              Posté par  . Évalué à 2.

              Pour l'optimisation des requètes, il n'y a pas d'autres choix que les outils propres à chaque moteur.
              Ainsi pour les bases de données les plus utilisées, non seulement, il y a ce que l'éditeur propose mais des éditeurs tiers fabriquent également des programmes consacrés à l'analyse des performances.
              Il faut de toute façon le plan d'exécution de la requète pour savoir comment le moteur traite l'ordre sql.

          • [^] # Re: Pour la modélisation pour les bases de données

            Posté par  . Évalué à 1.

            >L'un des ERP les plus dramatiquement lent du marché, que je ne >nommerai pas, est indéxé à tout va ( au moins 12 index par table).
            Allez ! Juste la première lettre histoire de voir si je pense au même...

            • [^] # Re: Pour la modélisation pour les bases de données

              Posté par  . Évalué à 2.

              Dans la mesure où nous sommes dans une sorte de forum public et dans le contexte actuel, assez tendu en ce qui concerne la critique de produits commerciaux, je préfère rester assez évasif.

              On pourra penser que j'exerce une sorte d'autocensure. Je crois plutôt qu'il s'agit de garder hors d'atteinte des marchands sans scrupules un espace d'expression libre et d'échanges.

              Je te proposerai une énigme en disant que cet ERP est né pas très loin des bords de la Flache. (Cher Arthur Raimbaud !)

      • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

        Posté par  . Évalué à 5.

        Le meilleur outil ne remplacera jamais la compétence.

        Toutefois il permet de garder une trace propre et exploitable du travail, permet de formaliser un certain nombre de choses et surtout assure un suivi dans les évolutions d'une base.

        Quand t'as un soft qui tourne chez 300 ou 400 clients, c'est bien pratique de pouvoir retrouver ce qui a changé entre 2 versions de base.

        Ceci étant, j'avoue continuer à noter des bouts de projets et des idées sur des coins d'enveloppe.
        Mais je sais que c'est "mal" ;-)

        Je suis bien content de découvrir ces outils. J'avais cherché y'a quelques temps mais en faisant chou blanc. Si vous en connaissez d'autres dans le même style...

    • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

      Posté par  . Évalué à 7.

      Comment ca 'gros' ?

      J'interviens car j'ai fait partie de l'équipe de développement de nextobjects jusqu'à la sortie de la première beta (ya bien la moitié du code qui me concernait à l'époque), et je vous affirmer que notre ambition initiale était de permettre aux utilisateurs de faire rapidement un MCD et de transformer ce dernier en MPD. Pour avoir utiliser intensivement des outils comme PowerDesigner(PowerAMC) et WinDesign, je trouve nextObjects beaucoup plus rapide d'accès. Et je vous rappelle que c'est gratuit quand PowerDesigner frise les quelques milliers d'euros.

      Donc en plus oui nextObjects est un produit francais (merise, les américains connaissent pas) bien que l'équipe soit maintenant internationale. Et meme si je n'en fais plus partie, je suis toujours le projet.

      Quand au débat sur Java et le libre, je le trouve bien ridicule.

      Au début du projet nextObjects, nous avions l'intention de faire un produit exclusivement linux, mais on s'est vite rendu compte de la perte de temps par rapport à un langage comme Java pour ce qui est du dessin des modèles. Le java s'est donc imposé, ce qui a nous permis en plus de proposer un produit qui marche partout et donc qui occupe l'ensemble du marché. De plus le moteur de génération de code utilisé (torque de jakarta) est en java bien que la passerelle de communication entre torque et nextObjects soit basée sur XML. Quand à ceux qui prétendent modéliser leurs bases avec UML, je leur tire mon chapeau car rien ne semble plus efficace pour concevoir un modèle solide que Merise.

      Sur ce, bon débat.

      • [^] # Merise vs UML

        Posté par  . Évalué à 4.

        En ce qui concerne la modélisation d'un MCD, UMl permet de faire d'excellent modèle et de résoudre de manière élégante quelques problèmes retors que Merise ne permet pas de représenter facilement.
        Cependant Merise offre l'avantage d'être adaptable aux relationnel bien mieux qu'UML.
        Je pense que les concepteurs de Merise ont eu une approche "données".
        Alors que les concepteurs d'UML ont une approche "objet".
        Le résultat est nettement en faveur des outils bati avec Merise quand à la qualité des outils offert pour passer du moède conceptuel aux modèles physiques des données.
        Je crois que ce n'est pas Merise ou UML qui soit à incriminer mais que la culture des uns et des autres favorisent les compétences base de données pour Merise et moins pour UML.

        Personnellement, je préfère modéliser les MCD avec UML même si plus tard j'aurais sans doute quelques problèmes au moment de passer vers un modèle physique.

        • [^] # Re: Merise vs UML

          Posté par  (site web personnel) . Évalué à 4.

          La méthode MERISE est souvent raccourcie au simples modèles conceptuel et physique des *données* (oubliant en passant le modèle logique) mais il faut savoir que lla méthode est quasiment absolue puisqu'elle intègre aussi la modèlisation des *traitements* et des *flux*.
          Bref, la méthode MERISE, c'est bien, dans son ensemble, c'est très gros et quelque peu lourd. Si l'on s'intéresse juste aux données, c'est aussi très simple et ça présente des défauts, tout comme UML, lorsque l'on modèlise des relations récursives (pour les BDD géographiques par exemple, une entité ayant une relation hiérarchique avec elle même).
          Après je suis tout à fait d'accord, le goût y fait beaucoup.

      • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

        Posté par  (site web personnel) . Évalué à 2.

        Humm, euh, non, en fait je voulais juste dessiner un MCD et un MLD pour l'intégrer dans un rapport, j'ai pas besoin de toute la richesse de nextobjects ou des AGL... Ca à l'air de rien comme ça mais y'a pas de formes prédéfinies dans les outils que je connais.

        Pour ce qui est de Java et UML, on est d'accord

  • # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

    Posté par  . Évalué à 1.

    À quand un Oracle Desiner en version libre et mieux (plus ouvert) ?

    Et la disparition de MySQL au passage ?

    • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

      Posté par  (site web personnel) . Évalué à 3.

      Tu peux ne pas aimer MySQL et ne pas le considérer comme une vrai BD relationnelle, mais de là a souhaiter ça disparition...

      MySQL est parfait pour bien des choses, même avec les tables de base (MyISAM) qui ne gèrent même pas les contraintes. Ce n'est pas un hasard si cette BD est autant utilisée.
      De plus il ne faut pas oublier que MySQL est encore en plein développement ! petit à petit les lacunes se comblent...

      • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

        Posté par  . Évalué à 3.

        parfait pour bien des choses, n'exagérons rien, disons qu'avec des efforts on peu en tirer des choses.

        Mais pourquoi utiliser cette daube pas finie quand plusieurs bases plus abouties existent en libre ?

        Parceque le singe préfère la voiture rouge (et qu'il écrit ses jointures à la main comme un con du coup).

        À la limite, si la généralisation de cette bouse ne me concernait pas, j'aurais rien à dire, mais je me retrouve dans des boites où cette daube est généralisée (c'est la seule base gratuite qu'ils connaissent) et touver un hébergeur web qui propose autre chose que cette bouse relève de la mission impossible.

        En gros, elle est généralisée car elle est la plus visible et est la plus visible car elle est généralisée. Mais techniquement c'est rien qu'un truc à la traine sur une concurrence étoufée. C'est le MS des bases de données, techniquement y'a rien de des promesses dans un éventuel futur, mais le marché est trusté.

    • [^] # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

      Posté par  . Évalué à 1.

      A la limite, comme tu y vas, pourquoi pas une version libre d'oracle
      tout court. A ce moment la, pourquoi pas virer mysql ... meme si
      les cibles sont differentes

      Mmd.

  • # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

    Posté par  . Évalué à 3.

    N'empeche moi je trouve ca pas mal comme logiciel !

    Sauf que j'ai pas réussi à le faire fonctionner ... impossible d'ouvrir ma base de données ...

    Sinon, je trouve ca bien car au moins on fait un jolis schémas que l'on peux imprimer sans avoir a se taper 2 fois la structure de la base ... si vous voyez ce que je veux dire !!

  • # devaki => impossible à lancer.

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    le site est assez limité pour ce qui concerne l'installation...
    J'ai téléchargé java de chez sun, et j'obtiens ca :
    [paul@bureau devaki-nextobjects-0.3-RC4]$ ./nextobjects.sh
    Warning: Unrecognized version number 48/0 in classfile.
    Warning: Unrecognized version number 48/0 in classfile.
    Warning: Unrecognized version number 48/0 in classfile.

    Could not initialize Kaffe.
    It's likely that your CLASSPATH settings are wrong. Please make sure
    your CLASSPATH does not include any java.lang.* classes from other JVM
    vendors, such as Sun's or IBM's rt.jar (or classes.zip), BEFORE Kaffe's rt.jar.
    It should be okay to have Sun's rt.jar AFTER Kaffe's rt.jar

    The current effective classpath is `./lib/ant-1.5.2.jar:./lib/jdom-b8.jar:./lib/log4j-1.2.7.jar:./lib/torque-3.0.jar:./lib/xercesImpl-2.0.2.jar:./lib/xmlParserAPIs-2.0.2.jar:./target/*.jar:./devaki-nextobjects-0.3-RC4.jar:/home/paul/bin_perso/j2sdk_nb/j2sdk1.4.2/jre/lib/rt.jar'

    Il parle de Kaffe. Alors j'ai installé Kaffe, mais c'est pas mieux :
    [paul@bureau devaki-nextobjects-0.3-RC4]$ sh nextobjects.sh

    Could not initialize Kaffe.
    Your rt.jar version is 101.00, but this VM was compiled with version 1.07

    The current effective classpath is `./lib/ant-1.5.2.jar:./lib/jdom-b8.jar:./lib/log4j-1.2.7.jar:./lib/torque-3.0.jar:./lib/xercesImpl-2.0.2.jar:./lib/xmlParserAPIs-2.0.2.jar:./target/*.jar:./devaki-nextobjects-0.3-RC4.jar:/usr/local/kaffe/jre/lib/rt.jar'

    Et j'arrive pas à compiler Kaffe version 1.07

    Si quelqu'un a une idée/suggestion. Cet outil me semble très intéressant pour ce que je fais tous les jours ou presque...

    • [^] # Re: devaki => impossible à lancer.

      Posté par  . Évalué à 1.

      Je me plante peut-être mais on dirait q tu as java qui pointe vers kaffe.
      Il faudrait refaire les liens symbolique java javac etc etc (tout ce qui est en java* je crois ?) qui sont dans /usr/bin (which java) vers ta nouvelle jvm qui doit être... ça dépend /usr java ? Et dans ce répertoire tu retrouveras tes nouvelles applications pour compiler avec le java 1.4

  • # Re: Une sélection d'outils libres pour la modélisation pour les bases de données

    Posté par  . Évalué à 4.

    Nous avons déjà mis il y a un moment un outil (dbutils) permettant de générer
    du sql pour postgresql à partir d'un modèle xml équivalent à du EER.
    Cet outil génère également le schéma EER en dot (graphiz) pour la visualisation.
    Bien que très simple cet outil nous sert à générer nos modèles pour nos clients.
    D'autres outils (comme des sur-couches shell au commandes postgresql ou encore un serveur xml vers postgresql) sont présents dans le package.
    (cf http://www.pimentech.fr/pimentech/site/technologies/outils(...))

  • # Migration MSAccess MySQL

    Posté par  . Évalué à 1.

    J'arrive un peu tard mais est-ce qu'il existe des outils pour migrer une base MSAccess (cramoisie d'ailleurs) vers une base MySQL ?

    • [^] # Re: Migration MSAccess MySQL

      Posté par  . Évalué à 1.

      DBDesigner4 permet (d'après leur site web) de le faire. J'ai également trouvé sur leurs forums une "petite" (3.6Mo quand même ;) ) anim flash montrant la méthode à utiliser pour y arriver. L'anim se trouve à cette URL ci :
      http://www.team-noehring.de/extern/db4/db4odbc.htm(...)
      (Note : la personne ayant réalisé cette anim est allemande, du coup tous les menus présentés sont en allemand. Mais on arrive quand même à s'y retrouver. Note 2 : je n'ai pas encore testé la méthode présentée ici...)

      Attention toutefois, elle ne va pas rester définitivement là-bas, pour des raisons de limite de bande passante de l'hébergeur.

      Autrement, fabForce (créateurs de DBDesigner4) prévoient de mettre un jour en ligne un film expliquant également ce transfert.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.