Générateur de dictionnaire de données

ErdDocs génère le dictionnaire de données à partir d’un dump SQL, d’un schéma Prisma ou des modèles de votre framework. Tables, colonnes, types, valeurs par défaut, index et relations sont réunis dans un seul document de référence. Vous l’enregistrez en PDF depuis la boîte d’impression du navigateur, avec le diagramme à côté. Pas d’inscription, rien à installer. Le schéma est analysé dans le navigateur.

Votre schéma

CREATE TABLE customers (
    id          bigserial PRIMARY KEY,
    email       varchar(255) NOT NULL UNIQUE,
    full_name   varchar(120),
    created_at  timestamptz  NOT NULL DEFAULT now()
);
COMMENT ON TABLE customers IS 'Clients inscrits ; une ligne par personne';
COMMENT ON COLUMN customers.email IS 'E-mail de connexion, unique dans toute la boutique';

CREATE TABLE products (
    id        bigserial     PRIMARY KEY,
    sku       varchar(40)   NOT NULL UNIQUE,
    title     varchar(200)  NOT NULL,
    price     numeric(10,2) NOT NULL,
    stock     int           NOT NULL DEFAULT 0
);
COMMENT ON TABLE products IS 'Catalogue ; les produits supprimés gardent leur SKU';
COMMENT ON COLUMN products.stock IS 'Stock disponible, mis à jour par l’entrepôt';

CREATE TABLE orders (
    id           bigserial     PRIMARY KEY,
    customer_id  bigint        NOT NULL REFERENCES customers(id),
    status       varchar(20)   NOT NULL DEFAULT 'pending',
    total        numeric(10,2) NOT NULL,
    placed_at    timestamptz   NOT NULL DEFAULT now()
);
COMMENT ON COLUMN orders.status IS 'pending -> paid -> shipped -> done, ou cancelled';

CREATE TABLE order_items (
    order_id    bigint        NOT NULL REFERENCES orders(id),
    product_id  bigint        NOT NULL REFERENCES products(id),
    qty         int           NOT NULL,
    unit_price  numeric(10,2) NOT NULL,
    PRIMARY KEY (order_id, product_id)
);
COMMENT ON TABLE order_items IS 'Lignes de commande ; le prix est figé à l’achat';

CREATE TABLE shipments (
    id         bigserial   PRIMARY KEY,
    order_id   bigint      NOT NULL REFERENCES orders(id),
    carrier    varchar(60) NOT NULL,
    tracking   varchar(80),
    shipped_at timestamptz
);

CREATE INDEX idx_orders_customer ON orders(customer_id);
CREATE INDEX idx_shipments_order ON shipments(order_id);

CREATE TABLE customers (
    id          bigserial PRIMARY KEY,
    email       varchar(255) NOT NULL UNIQUE,
    full_name   varchar(120),
    created_at  timestamptz  NOT NULL DEFAULT now()
);
COMMENT ON TABLE customers IS 'Clients inscrits ; une ligne par personne';
COMMENT ON COLUMN customers.email IS 'E-mail de connexion, unique dans toute la boutique';

CREATE TABLE products (
    id        bigserial     PRIMARY KEY,
    sku       varchar(40)   NOT NULL UNIQUE,
    title     varchar(200)  NOT NULL,
    price     numeric(10,2) NOT NULL,
    stock     int           NOT NULL DEFAULT 0
);
COMMENT ON TABLE products IS 'Catalogue ; les produits supprimés gardent leur SKU';
COMMENT ON COLUMN products.stock IS 'Stock disponible, mis à jour par l’entrepôt';

CREATE TABLE orders (
    id           bigserial     PRIMARY KEY,
    customer_id  bigint        NOT NULL REFERENCES customers(id),
    status       varchar(20)   NOT NULL DEFAULT 'pending',
    total        numeric(10,2) NOT NULL,
    placed_at    timestamptz   NOT NULL DEFAULT now()
);
COMMENT ON COLUMN orders.status IS 'pending -> paid -> shipped -> done, ou cancelled';

CREATE TABLE order_items (
    order_id    bigint        NOT NULL REFERENCES orders(id),
    product_id  bigint        NOT NULL REFERENCES products(id),
    qty         int           NOT NULL,
    unit_price  numeric(10,2) NOT NULL,
    PRIMARY KEY (order_id, product_id)
);
COMMENT ON TABLE order_items IS 'Lignes de commande ; le prix est figé à l’achat';

CREATE TABLE shipments (
    id         bigserial   PRIMARY KEY,
    order_id   bigint      NOT NULL REFERENCES orders(id),
    carrier    varchar(60) NOT NULL,
    tracking   varchar(80),
    shipped_at timestamptz
);

CREATE INDEX idx_orders_customer ON orders(customer_id);
CREATE INDEX idx_shipments_order ON shipments(order_id);

Your diagram appears here.

Le schéma ci-dessous porte des commentaires en français. Passez à « Dictionnaire de données » pour les voir dans la colonne de description.

De la base au dictionnaire en trois étapes

01Exportez le schéma : pg_dump --schema-only mydb > schema.sql pour PostgreSQL, mysqldump --no-data mydb > schema.sql pour MySQL, ou prenez votre schema.prisma tel quel.
02Collez-le ci-dessus ou déposez le fichier sur le panneau. Le dictionnaire apparaît au fur et à mesure de la lecture du schéma.
03Cliquez sur Enregistrer en PDF : la boîte d’impression de votre navigateur produit le document. Là non plus, rien ne passe par un serveur.

Les descriptions viennent de votre schéma

Les descriptions ont déjà leur place dans les bases de données, mais on les voit rarement dans un document.

PostgreSQL : COMMENT ON TABLE orders IS '…' et COMMENT ON COLUMN orders.status IS '…'. pg_dump les exporte automatiquement avec le schéma.
MySQL : la clause COMMENT '…' sur les colonnes et les tables, dans CREATE TABLE. mysqldump la conserve.
Prisma : les commentaires de documentation /// au-dessus des modèles et des champs deviennent des descriptions dans le dictionnaire.

Tous ces commentaires alimentent la colonne Description. Si le schéma n’a pas de commentaires, la colonne n’apparaît pas. Le document n’affiche donc pas de cases vides.

Tout le reste est lu dans le DDL lui-même : les types tels qu’ils sont écrits, l’acceptation de NULL, les valeurs par défaut, les clés, les index, et les partitions regroupées sous leur table mère. Certains dumps ne déclarent aucune clé étrangère (Rails et Django le font rarement). Les relations sont alors déduites du nommage des colonnes et signalées comme telles. Un auditeur peut donc toujours distinguer les clés déclarées des clés déduites.

Qui a besoin d’un dictionnaire de données

Audits et conformité. « Envoyez-nous le dictionnaire de données » est une demande courante. ErdDocs y répond en quelques minutes à partir d’un dump de schéma collé. Le constituer à la main sur une base en service prend des jours.
Livraison au client. Les agences clôturent leurs projets par une documentation. ErdDocs la produit sous forme d’un document que le client peut imprimer et conserver.
Intégration des nouveaux. Un nouvel ingénieur lit un seul document au lieu d’interroger information_schema table par table.

Qu’est-ce qu’un dictionnaire de données ?

C’est le document qui décrit une base table par table. Pour chaque champ, il donne le nom, le type, la valeur par défaut et s’il accepte NULL. Il liste aussi les clés primaires et étrangères, les index et une description du contenu. On le demande en projet d’études, en audit et à la livraison d’un système. Celui d’ErdDocs décrit les tables telles qu’elles existent, pas les données recensées avant le MCD.

Mieux qu’un modèle Excel ou Word

Un modèle se remplit à la main et cesse de correspondre à la base dès qu’on modifie une table. Ici, il suffit de recoller le dump pour que le dictionnaire soit de nouveau à jour. Vous pouvez le régénérer à chaque livraison.

Questions fréquentes

Que contient le dictionnaire de données généré ?

ErdDocs décrit chaque table. Pour chacune, il liste les colonnes avec leur type exactement tel que déclaré, l’acceptation de NULL et la valeur par défaut. Il ajoute les clés primaires et étrangères avec les colonnes visées, les contraintes d’unicité, les index et les deux sens de chaque relation. Les commentaires de tables et de colonnes du schéma deviennent des descriptions. Les tables partitionnées n’apparaissent qu’une fois, avec leurs partitions nommées sous la table mère.

Comment générer le dictionnaire de données d’une base existante ?

Exportez le schéma en SQL, avec pg_dump --schema-only pour PostgreSQL ou mysqldump --no-data pour MySQL. Collez-le ci-dessus et passez à la vue « Dictionnaire de données ». En imprimant la page depuis le navigateur, vous obtenez le PDF. Rien à installer, et le SQL ne quitte pas votre machine.

Comment les descriptions arrivent-elles dans le dictionnaire ?

Par le schéma lui-même. Les instructions COMMENT ON TABLE et COMMENT ON COLUMN de PostgreSQL, les clauses COMMENT 'texte' de MySQL et les commentaires /// de Prisma alimentent tous la colonne Description. Si un schéma n’a aucun commentaire, ErdDocs retire entièrement cette colonne au lieu de l’imprimer vide.

C’est gratuit ?

Le diagramme affiche gratuitement jusqu’à 25 tables. Dans la version gratuite, le dictionnaire décrit entièrement les trois tables les plus reliées. Les tables suivantes apparaissent sous forme de cadres avec leur nom, à la place qu’elles occuperaient, et le reste est compté. Vous voyez ainsi exactement le document obtenu. Un paiement unique de 9 $ US débloque le dictionnaire complet et le diagramme entier, sans abonnement, sans renouvellement et sans compte.

Mon schéma est-il envoyé quelque part ?

Non. L’analyse, le diagramme et le dictionnaire se font dans le navigateur, et le PDF est produit par le navigateur lui-même à l’impression. Le schéma n’atteint jamais un serveur, car il n’y a aucun serveur où l’envoyer.

Pages liées

Dictionnaire de données pour MySQL : les particularités de mysqldump, la syntaxe COMMENT en ligne.
Dictionnaire de données pour PostgreSQL : les usages de pg_dump, COMMENT ON, les partitions.
Modèle de dictionnaire de données : les sept colonnes, un CSV à télécharger, et comment remplir chacune à la main.
Outils de documentation de base de données : un comparatif des générateurs open source, des outils orientés code et des plateformes.
Alternative à Dataedo : quand un document suffit et qu’une plateforme serait de trop.
Du SQL au diagramme entité-association : le même outil, ouvert sur la vue du diagramme.
Agent Link API : reliez n’importe quel schéma à un diagramme et un dictionnaire vivants, depuis un README ou une réponse d’IA.