Outil pour documenter un BDD ?

[nanou9999]

:
Je cherche un outil pour documenter une BDD ?
du style je lis la base et je rajoute des metadonnées sur les tables/champs dans l'outil
Merci

[qi130]

Un outil qui se connecte au SGBD et en ressort tout ce qui concerne 1 base ?

C'est du reverse-engineering, et beaucoup de softs font ça (pour ne pas dire tous!)

Regarde le post-it concernant les outils de conception/modélisation-> http://www.developpez.net/forums/viewtopic.php?t=131690

Oui il ya le top comme l'indique avec lien qi130 , Power AMC de Sybase .
Mais c'est un outil pour l'entreprise et assez onéreux...

[jmmolina]

Envoyé par nanou9999

:
Je cherche un outil pour documenter une BDD ?
du style je lis la base et je rajoute des metadonnées sur les tables/champs dans l'outil
Merci

Je recherche aussi un tel outil ou technologie afin de documenter les schémas SQL de mes bases. L'idéal serait un javadoc mais pour SQL. Jose A. Gonzalvo présente un sqldoc pour SQL Server dans l'article SqlDoc: Document your SQL Server database.

Depuis MySQL 4.1 on peut désormais utiliser l'option COMMENT lors de la création d'une table avec la commande CREATE TABLE, cependant cette fonctionnalité n'est pas souple comparé à ce que l'on peut faire avec les commentaires javadoc. Un petit exemple.

Schéma SQL commenté de la table config :

Code :

1
2
3
4
5
CREATE TABLE `config` (
  `name` varchar(255) NOT NULL DEFAULT '' COMMENT 'Nom de la configuration',
  `value` varchar(255) NOT NULL DEFAULT '' COMMENT 'Valeur de la configuration',
  PRIMARY KEY  (`config_name`)
) TYPE=MyISAM;

Ici le commentaire permet tout juste d'indiquer ce à quoi sert le champ. On ne peut pas vraiment parler de documentation. Notez aussi qu'on peut documenter la table. Mais mélanger les commandes et la documentation n'est selon moi pas la bonne méthode. Imaginez ce que serait un code Java documenté sans javadoc, avec des instructions comment dans tous les coins, mon Dieu .

En adoptant un style Javadoc on pourrait se retrouver avec un schéma SQL documenté comme ci-dessous :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
Table des configurations.
 
@champ name
Nom de la configuration.
 
@champ value
Valeur de la configuration.
*/
 
CREATE TABLE `config` (
  `name` varchar(255) NOT NULL DEFAULT '',
  `value` varchar(255) NOT NULL DEFAULT '',
  PRIMARY KEY  (`config_name`)
) TYPE=MyISAM;

Ici j'ai utilisé une nouvelle balise Javadoc que j'ai appelée champ, à prendre comme un param car après tous les champs des tables sont un peu les attributs des classes dans les langages OO.

Toutes vos remarques et suggestions sont les bienvenues.

JM

[qi130]

Je vous suggère DBDesignor de FabForce...

La description d'une table permet de :
1/ affecter un commentaire à chaque colonne
2/ commenter la table

http://www.fabforce.net/dbdesigner4/...s_ed_table.png

[jmmolina]

Envoyé par qi130

Je vous suggère DBDesignor de FabForce...

La description d'une table permet de :
1/ affecter un commentaire à chaque colonne
2/ commenter la table

http://www.fabforce.net/dbdesigner4/...s_ed_table.png

J'avais testé DBDesigner début 2003 mais sans succès vu la quantité de bogues présents à l'époque. J'espère que tout ça a été corrigé. Par contre les fonctionnalités de documentation que vous décrivez sont aussi limitées que celles de MySQL. À savoir un maigre commentaire sur une table et ses champs. Enfin c'est mieux que rien et c'est appréciable de pouvoir le faire à l'aide d'une interface aussi bien peaufiné. Déjà je vais réinstaller la dernière version pour voir si il est mieux qu'en 2003.

En tous les cas j'attends avec impatience la prochaine version, j'ai cru comprendre que le produit s'était fait racheté par MySQL [i]itself[/¡]. Ça promet .

Pour info j'utilise Poseidon for UML pour documenter mes schémas SQL. Un simple diagramme de classes et quelques stéréotypes suffisent, c'est encore loin d'être la panacée mais c'est mieux que rien .

JM

[qi130]

Certes, le produit a des défauts de jeunesse....

Cependant, il a l'énorme avantage de la gratuité

D'autre part, je soutiens que les tables systèmes d'un SGBD ne sont pas l'endroit le plus approprié pour stocker de la documentation fonctionnelle ou technique concernant un MCD.

Les facilités offertes par tel ou tel SGBD peuvent être utiles, je ne le nie pas; un DBA pouvant y trouver son compte afin de comprendre un système dont il a la charge...

Mais je crois préférable de ne pas mélanger les genres.

Concernant DBDesignor, je viens de constater qu'un fichier texte de 32k pouvait tenir dans la zone "commentaire" de l'éditeur de table.
Il est en outre possible de faire apparaître sur le dessin des zones de texte.

Tout ceci me semble amplement suffisant pour documenter un MCD. (mais d'aucuns ont peut-être des besoins plus importants ?)

[jmmolina]

Concernant la documentation d'une BDD je vous recommande les sections 4.3. Cartouche et 4.6. Documentation de l'article Normalisation des noms des objets des bases de données. J'ai contacté son auteur pour savoir ce qu'il pensait de notre affaire.