SQL en diagramme ER

Comment ça marche

1. 01

   Collez ou déposez votre SQL

   Des instructions CREATE TABLE, un fichier de migration ou un dump complet issu de pg_dump, mysqldump, SSMS ou sqlite3. Vous pouvez déposer plusieurs fichiers .sql à la fois : ils sont lus ensemble, jusqu’à 8 Mo au total.

2. 02

   Voyez le diagramme ER

   Chaque table devient une carte qui liste ses colonnes avec leur type et les marqueurs PK, FK et UK. Chaque clé étrangère devient un lien qui va de la colonne qui la porte à la clé qu’elle référence.

3. 03

   Ouvrez-le dans Archboard

   Enregistrez-le comme nouveau diagramme pour le réorganiser, l’annoter, partager un lien ou l’exporter en SVG et PNG. Un compte Google ou GitHub suffit pour s’inscrire.

Ce qui est dessiné à partir de votre SQL

Le diagramme est construit à partir de ces éléments des instructions CREATE TABLE :

• CREATE TABLE

  Chaque CREATE TABLE sous forme de carte au nom de la table, avec une entrée par colonne : son nom, son type et un point d’interrogation si elle accepte NULL. Les cartes affichent jusqu’à 24 colonnes, puis le nombre des colonnes restantes.

• PRIMARY KEYUNIQUE

  Les clés primaires, marquées PK sur chacune des colonnes qu’elles couvrent, même quand elles en couvrent plusieurs. Une contrainte UNIQUE, ou un index unique créé avec CREATE UNIQUE INDEX, sur une seule colonne marque cette colonne UK.

• FOREIGN KEYREFERENCESALTER TABLE

  Les clés étrangères écrites en ligne avec REFERENCES, déclarées comme contraintes de table ou ajoutées ensuite avec ALTER TABLE, chacune dessinée comme un lien entre les deux colonnes. Une clé qui pointe vers sa propre table, comme parent_id, est représentée aussi.

• CREATE SCHEMA

  Les schémas, créés avec CREATE SCHEMA ou utilisés dans des noms comme sales.orders, dessinés comme des cadres autour de leurs tables quand le SQL en utilise plusieurs. Un schéma sans table n’a pas de cadre.

• NOT NULLUNIQUE

  Des extrémités en patte de corbeau qui déduisent la relation des colonnes : une clé étrangère NOT NULL rend la relation obligatoire, une clé qui accepte NULL la rend facultative, et une clé étrangère qui est aussi unique ou primaire en fait une relation un-à-un.

Les dialectes SQL lus

PostgreSQL, MySQL et MariaDB, SQL Server et SQLite sont lus chacun avec leurs propres règles de guillemets, de commentaires et de séparateurs d’instructions : un fichier pg_dump, un mysqldump avec des blocs DELIMITER ou un script SSMS rempli de lignes GO fonctionne tel quel. Oracle est lu en partie : les tables, les clés et les clés étrangères sont dessinées, et les blocs PL/SQL terminés par une ligne ne contenant qu’une barre oblique sont ignorés. Quand les indices se contredisent, un lecteur générique prend le relais, et vous pouvez choisir le dialecte vous-même à tout moment.

Ce que le diagramme ER laisse de côté

• Les lignes de données. Les instructions INSERT, COPY et autres instructions de données sont ignorées sans être lues : un dump avec données donne le même diagramme qu’un dump du schéma seul.
• Les vues, fonctions, procédures, déclencheurs et séquences. Ils sont ignorés, et l’aperçu indique combien de chaque type ont été laissés de côté. Les vues et les déclencheurs que mysqldump écrit dans des commentaires de version sont ignorés comme des commentaires et ne sont pas comptés.
• Les valeurs par défaut, les expressions CHECK, les commentaires et les valeurs autorisées des colonnes ENUM et SET. Les colonnes n’affichent que leur nom, leur type et leurs marqueurs de clé.
• Tout ce qui vient d’un serveur en marche. L’outil lit le texte SQL que vous lui donnez et ne se connecte à aucune base de données : le nombre de lignes, la taille des tables et les plans de requête ne sont pas affichés.