Modélisez un schéma de base de données que toute l'équipe peut vraiment lire

Un diagramme de schéma est l'un des documents les plus utiles qu'une équipe backend puisse posséder, et l'un des premiers à devenir obsolètes. Quelqu'un le dessine avant le lancement, il obtient une place d'honneur dans le wiki, puis vingt migrations plus tard il décrit une base de données qui n'existe plus.

L'autre façon d'échouer est pire : le diagramme reste techniquement à jour mais se transforme en plat de spaghettis. Les lignes de clés étrangères traversent trois tables pour en atteindre une quatrième, la cardinalité est devinée plutôt que montrée, et personne ne peut dire d'un coup d'œil si un utilisateur a plusieurs commandes ou exactement une. LetDraw est conçu pour garder les diagrammes de schéma à la fois lisibles et corrects, afin qu'ils valent la peine d'être conservés.

Des tables qui savent qu'elles sont des tables

Une table ER dans LetDraw n'est pas une boîte dans laquelle on a tapé du texte. C'est un véritable élément table avec des colonnes typées et des marqueurs de clés : la structure fait partie de la forme, ce n'est pas un dessin qu'il faut synchroniser à la main.

• Colonnes typées. Chaque ligne porte un nom et un type, si bien que id bigint se lit comme un schéma, pas comme une étiquette.
• Marqueurs de clés. Les clés primaires et étrangères sont marquées sur la colonne, et le lecteur voit les points de jointure sans avoir à les chercher.
• Modifiable sur place. Ajoutez une colonne, changez un type ou renommez un champ, et la mise en page suit. Vous modifiez un modèle, vous ne déplacez pas des rectangles.

Comme les colonnes sont structurées, les relations entre tables peuvent être dessinées correctement plutôt que décorativement. C'est là qu'intervient la cardinalité.

La cardinalité en patte d'oie, rendue nativement

Une relation entre deux tables n'est utile que si elle vous dit la forme des données. Un utilisateur pour plusieurs commandes, c'est un tout autre monde qu'un utilisateur pour une seule commande, et un diagramme qui confond les deux est pire que pas de diagramme du tout. LetDraw dessine nativement la notation en patte d'oie sur la ligne de relation, si bien que un-à-plusieurs, un-à-un et plusieurs-à-plusieurs se lisent directement sur le connecteur.

Une ligne de relation doit vous dire la forme des données, pas seulement que deux tables se touchent.

Quand vous modélisez du code plutôt que des tables, le même moteur de connecteurs dessine de vrais diagrammes de classes UML, avec des pointes de flèche creuses pour l'héritage et les autres pointes standard. Inutile de dessiner un triangle à la main en espérant qu'il tombe au bon endroit : la notation est native, et une flèche d'héritage ressemble à de l'héritage pour quiconque lit l'UML.

Des lignes de clés étrangères qui contournent vos tables

Voici le détail qui décide si un diagramme de schéma survit au-delà de dix tables. À mesure que le schéma grandit, l'approche naïve trace une ligne droite d'une clé à l'autre, et ces lignes traversent vite toutes les tables sur leur chemin. L'image devient un nœud.

LetDraw applique un routage intelligent aux connecteurs de clés étrangères : une ligne de relation traite vos tables comme des obstacles et les contourne. La jointure entre orders.user_id et users.id reste visible même quand une douzaine de tables les séparent. Le diagramme devient plus dense à mesure que votre schéma grandit, mais il ne devient pas illisible, ce qui est tout l'intérêt de le dessiner.

Partez du SQL que vous avez déjà écrit

Vous n'avez pas à placer une seule table à la main. Ouvrez la boîte de dialogue Générer à partir du code, collez vos instructions CREATE TABLE, et LetDraw construit le diagramme ER pour vous : des tables avec des colonnes typées, les clés marquées et les relations tracées à partir des clés étrangères. Voici le DDL derrière la figure ci-dessus.

CREATE TABLE users (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email       text NOT NULL UNIQUE,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE orders (
  id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id     bigint NOT NULL REFERENCES users (id),
  total_cents integer NOT NULL,
  status      text NOT NULL DEFAULT 'pending'
);
-- user_id REFERENCES users(id) becomes the crow's-foot relationship

C'est cette clause REFERENCES que LetDraw lit pour placer la ligne un-à-plusieurs, avec la patte d'oie du côté orders. À partir de là, c'est un dessin normal : vous l'affinez, puis vous le partagez.

• Réorganisez les tables, regroupez celles qui appartiennent à un même bounded context et annotez les jointures délicates
• Ajoutez des tables que le DDL n'incluait pas encore et dessinez leurs relations à la main avec les mêmes pattes d'oie
• Exportez en PNG, SVG ou PDF pour un document de conception, ou reconvertissez le diagramme en Mermaid ou D2 quand vous le voulez de nouveau sous forme de code

Pourquoi un schéma lisible vaut l'effort

Un diagramme de schéma est un contrat sur la façon dont vos données s'articulent, et il ne rapporte que si les gens lui font confiance. Les colonnes typées et les clés marquées le rendent précis ; la cardinalité en patte d'oie le rend honnête sur la forme des données ; le routage intelligent le garde lisible à mesure qu'il grandit. Générez le premier brouillon à partir du SQL que vous maintenez déjà et le coût de sa mise à jour devient quasi nul, la seule façon pour un tel diagramme de rester vivant.

Collez vos instructions CREATE TABLE et regardez le diagramme ER s'assembler tout seul, clés comprises.