ChartDB – éditeur gratuit et open source de conception de bases de données

• ChartDB est un éditeur de diagrammes DB qui permet de visualiser rapidement un schéma de base de données et de le manipuler sous forme de diagramme ER, avec un focus sur la collaboration d’équipe et les migrations de schéma
• La version Cloud fonctionne dans le navigateur et met en avant l’obtention d’un diagramme en 15 secondes sans accès à la base de données
• La version Self-Hosted est proposée gratuitement en open source, adaptée aux besoins de sécurité et de personnalisation lorsque l’on doit contrôler directement les données et la configuration
• Il prend en charge l’import de schéma à partir d’une requête unique, la génération de diagrammes ER par IA, l’export SQL DDL, la synchronisation automatique, la collaboration en temps réel, la documentation embarquée et le suivi des changements
• Il peut être utilisé pour concevoir de nombreux SGBDR relationnels et entrepôts de données cloud, notamment PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, ClickHouse, CockroachDB, Oracle, Snowflake et BigQuery

---

Diagrammes de schéma DB manipulés dans le navigateur

• ChartDB est un outil qui visualise instantanément les schémas de base de données et génère des diagrammes ER
• Il est présenté comme un éditeur de diagrammes DB destiné à la collaboration d’équipe et aux migrations de schéma
• Le bouton de démarrage renvoie vers l’application ChartDB, avec la mention de démarrage gratuit et sans carte bancaire requise
• Sur GitHub, ChartDB est affiché avec +19K stars

Choix entre Cloud et Self-Hosted

• ChartDB Cloud permet de visualiser des bases de données dans le navigateur
  • Il est présenté comme adapté à la facilité d’usage et à l’accessibilité pour les équipes
  • Il est indiqué comme utilisable sans accès à la base de données
  • Il met en avant l’obtention d’un diagramme en 15 secondes
• Self-Hosted est un éditeur gratuit et open source de conception de bases de données
  • Il permet de contrôler totalement les données et la configuration
  • C’est une option adaptée aux environnements ayant des besoins en sécurité et en personnalisation
• ChartDB explique qu’il est possible de visualiser une base de données avec une « requête unique »

Flux de travail Import → Edit → Export

• Instant Import

  • Une requête unique est fournie pour chaque base de données afin d’importer l’intégralité du schéma
  • Il est indiqué que l’import du schéma peut se faire en 15 secondes

• Relational DBMS

  • MySQL, MariaDB, PostgreSQL, Microsoft SQL Server et SQLite sont mentionnés comme SGBD populaires et affichés comme pris en charge

• Export SQL

  • Le diagramme peut être téléchargé sous forme de script SQL DDL pour être exécuté dans une base de données
  • Il peut aussi être exporté en image pour être intégré à de la documentation

• Examples

  • Des exemples préconçus sont proposés pour une configuration rapide et comme référence de conception
  • Cet élément est marqué WIP

• Advanced Query Editor

  • Il fournit des fonctions d’annulation, de rétablissement, de copie, de collage et de duplication
  • Il permet d’ajouter des tables, des zones thématiques et des notes

• Beautiful Shares

  • Il permet de générer un aperçu visuel du diagramme de base de données afin de le partager avec d’autres

Fonctions de génération, partage et synchronisation des diagrammes

• ChartDB - AI Agent
  • Transforme une idée de base de données saisie dans un prompt en diagramme ER optimisé et modifiable
• Instant Import
  • Fonction permettant d’importer l’intégralité du schéma DB avec une requête unique
• Export SQL
  • Génère des scripts DDL dans le dialecte SQL souhaité
• Sync Database
  • Synchronise automatiquement la base de données en direct et le diagramme
• Real time collaboration
  • Permet d’inviter des membres de l’équipe à voir et modifier le diagramme en temps réel
• Amazing Docs
  • Génère des diagrammes intégrables et une documentation extensible personnalisable
• Keep on track
  • Suit les diff des modifications de schéma et l’historique des versions

Bases de données prises en charge

• ChartDB indique prendre en charge la conception pour les bases de données et les entrepôts de données cloud
• Les éléments indiqués comme pris en charge sont les suivants
  • PostgreSQL
  • MySQL
  • SQL Server
  • SQLite
  • MariaDB
  • ClickHouse
  • CockroachDB
  • Oracle
  • Snowflake
  • BigQuery

Questions opérationnelles visibles dans la FAQ

• La FAQ comprend une question sur le fait de savoir si ChartDB modifie la base de données
• Un élément demande s’il est possible d’intégrer un ERD live dans Notion, Miro et Confluence
• Un autre vérifie s’il est possible d’essayer gratuitement le plan ChartDB Cloud
• La FAQ inclut aussi des éléments sur la façon d’obtenir de l’aide, de synchroniser un diagramme et une base de données, ainsi que sur la disponibilité des factures et des paiements professionnels

[GN⁺]

Avis sur Hacker News

• J’ai souvent vu des équipes projet se lancer dans le développement d’une nouvelle application sans le moindre diagramme de base décrivant un aspect quelconque de la solution, y compris le modèle de données.
  Je ne sais pas ce qu’il faudrait pour qu’un simple diagramme ER devienne un standard dans la documentation de projet. Les outils ne manquent pas, mais sur le terrain ils sont très peu utilisés.
  Peut-être que, pour que les gens s’en servent, Microsoft devrait l’intégrer comme fonctionnalité d’Excel ou de PowerPoint. Un diagramme n’a pas besoin d’être complet : il suffit qu’il transmette les structures et relations essentielles dans le bon contexte. Si nécessaire, on peut créer plusieurs petits diagrammes pour une même base de données afin de documenter les exigences et la conception.

  • Quelques raisons me viennent à l’esprit. Les personnes issues des systèmes d’information de gestion (MIS) s’intéressent généralement davantage aux bases de données que celles issues de l’informatique théorique/CS, et ont tendance à partir d’un ERD avant d’aller vers le code. Côté CS, on a plutôt tendance à coder d’abord.
    Par ailleurs, UML a été quasiment une catastrophe. Depuis les années 90, il s’est imposé comme le langage de diagrammes de référence, mais il ne comportait pas de composants de base de données, et il fallait bricoler les diagrammes de classes pour les utiliser comme des ERD. UML n’est pas du code, et coder en UML est difficile, voire presque impossible. Avec un ERD, il est beaucoup plus facile de passer du code au diagramme et inversement, ce qui n’est pas le cas pour d’autres formes de codage.
    À mon avis, l’essor puis l’échec d’UML ont beaucoup contribué au fait que les développeurs ne dessinent plus de diagrammes. En plus, pour la plupart des développeurs, un outil de navigation dans le code affichant la structure du code sous forme d’arborescence dans le panneau gauche de l’éditeur suffit largement.
  • En tant que personne qui commence par les données pour comprendre un système, je suis d’accord, mais j’ai l’impression que nous ne sommes pas majoritaires. Au moins dans l’écosystème Microsoft, la montée de l’approche code first ne m’a personnellement pas réjoui.

• Avant, j’étais assez favorable à la création d’ERD, et je l’utilisais souvent comme exercice d’onboarding, même sur des bases de données de plus de 100 tables. Mais les ERD exhaustifs deviennent de plus en plus rares, et je pense que ce n’est pas grave.
  Leur coût de maintenance est élevé, donc leur valeur ne dure pas longtemps. Avoir un ERD bien tenu est agréable, mais ce n’est pas indispensable.
  Pour créer des ERD à partir du code, des outils comme dbdiagram.io ou eraser.io sont beaucoup utilisés. ERWin est en quelque sorte l’ancêtre des diagrammes UML/ERD, mais il est cher.

  • Produire ce genre de choses à la main tient presque de l’erreur. Comme tu le dis, c’est difficile à maintenir. À mon avis, toute base de données devrait générer automatiquement un diagramme, ou au moins disposer d’un outil de génération automatique.

• Je me demande pourquoi les gens utilisent ce genre d’outil. C’est pour discuter avec des managers ?
  Je pose vraiment la question. Peut-être que je devrais m’en servir moi aussi, mais je ne vois pas encore pourquoi c’est nécessaire.

  • Il faut les utiliser quand la complexité atteint un niveau où cela a du sens. Si le projet est assez mature pour que tu n’aies plus, ou ne veuilles plus avoir, tout le modèle de base de données en tête, alors il faut les utiliser.
    C’est aussi utile si plusieurs modèles existent dans différents systèmes, si tu travailles avec d’autres personnes et veux faciliter la communication autour du modèle de base de données, si tu dois l’expliquer publiquement, ou si tu veux planifier le modèle à l’avance.
    Ici, par “il faut les utiliser”, je parle du diagramme final, pas nécessairement de cet outil précis.
  • J’ai utilisé ce genre d’outil pour organiser une conception que j’avais en tête. Personnellement, j’aime bien DBML, parce qu’il est facile à mettre sous gestion de source et qu’il existe des plugins d’éditeur.
    https://dbml.dbdiagram.io/home/
  • Parce qu’« une image vaut mille mots ».
    Si vous avez déjà récupéré un projet de 80 tables sans documentation, ou tout au plus un document de 50 pages contenant un dump de schéma de base de données, vous comprenez.
    On peut dessiner les tables et relations principales sur un seul ERD (diagramme entité-relation) et les comprendre en quelques minutes, au lieu de passer des heures ou des jours sur un dump de schéma.
    Pendant la phase de conception du schéma, on peut utiliser divers éditeurs d’ERD ou des outils de diagrammes textuels comme PlantUML, MermaidJS ou DBML, et mettre la source du diagramme sous gestion de source.
    On peut aussi générer dans la CI un ERD détaillé du schéma actuel de la base de données et le relire régulièrement, afin de vérifier qu’il correspond à la conception initiale et que l’on comprend correctement le schéma actuel.
  • Cela rend beaucoup plus simple la communication avec les métiers et l’explication des contraintes techniques ou des besoins en données. C’est aussi utile pour concevoir en collaboration sur des projets complexes, et cela met clairement en évidence les endroits où nous ne satisfaisons pas les exigences de données.
  • Comme une documentation de type JavaDoc, cela donne une vue plus concise de la manière dont quelque chose fonctionne.
    Je déteste vraiment l’attitude du genre « le code se documente tout seul ! ».

• Je vois beaucoup de services similaires. Mais ce que je cherche, c’est un outil que je puisse utiliser directement ou piloter par script.
  Mon cas d’usage consiste à générer un diagramme de base de données relativement simple à partir d’une description de modèle que je possède dans le cadre d’un autre processus. J’ai les noms de tables, les noms de colonnes et les relations dans une structure en mémoire, et je voudrais dessiner un diagramme qui ressemble à un ER.
  Pour l’instant, j’envisage de générer un fichier puml avec mes données, puis d’exécuter PlantUML pour produire du png ou du svg.
  D’après mes recherches, la plupart des solutions sont des outils complets de conception de base de données avec leur propre éditeur, mais sans API ; et les outils comme celui-ci ou dbdiagram.io sont généralement uniquement en ligne, ce qui n’est pas une option pour moi. Toute recommandation serait vraiment appréciée.

  • Je me demande si tu as essayé SchemaSpy.

• J’aurais aimé que ça existe il y a 5 ans, quand j’ai commencé un projet. Je devais concevoir un schéma de base de données pour un projet full-stack utilisant Postgres, et je travaillais avec un expert d’un domaine scientifique.
  Le fait de relire les diagrammes ensemble a énormément aidé, car cet expert pouvait repérer les problèmes qui pourraient venir de besoins futurs spécifiques au domaine.
  Au cours de ce processus, nous avons eu beaucoup de réunions en tête-à-tête, et je notais, en regardant le diagramme, ce qu’il fallait modifier avant la réunion suivante.
  Avec un outil comme celui-ci, nous aurions pu modifier directement pendant les réunions et réduire fortement le nombre d’itérations. Il existait des outils comme pgAdmin, mais ils ne semblaient pas très accessibles pour une personne non technique ; celui-ci pourrait réduire les frictions.

• C’est chouette, mais le principal problème de ce type d’outil est qu’il est unidirectionnel et qu’il essaie de se poser lui-même comme autorité centrale. Or ceci est un dessin, pas une base de données.
  Je comprends pourquoi les gens les utilisent, mais je n’ai pas besoin de ce genre d’outil.
  C’est pourquoi tous ces outils proposent une fonction « exporter en SQL » tout en s’attendant à ce que toutes les modifications de la base de données soient reflétées dans le diagramme. Mais le diagramme n’est pas la base de données ; on se retrouve donc avec deux choses à gérer.

  • Dire « le diagramme n’est pas la base de données », c’est comme dire « la carte n’est pas le territoire ».
    Un diagramme est un modèle, et un modèle existe toujours, qu’il soit explicite ou seulement dans votre tête.
    Le modèle dans votre tête peut être faux, mais personne ne peut le voir pour en signaler les erreurs. Pas même vous.

• DBeaver prend aussi en charge les ERD : https://dbeaver.com/docs/dbeaver/ER-Diagrams/
  C’est interactif et modifiable. Difficile de dire que c’est « beau », mais l’ensemble du produit est FOSS et extrêmement utile pour travailler avec des bases de données.

  • J’ai eu pas mal de problèmes pour faire en sorte que les ERD dans DBeaver se comportent comme je le voulais. Pour quelqu’un comme moi, ça va : je bidouille jusqu’à ce que ça marche.
    Mais ce n’était pas le cas pour certaines personnes avec qui j’ai travaillé. En général, quand on a besoin de ce genre de chose, c’est pour collaborer sur la conception avec des gens qui ne sont pas à l’aise avec SQL, mais qui ont une connaissance métier et arrivent avec une feuille Excel de la taille d’une petite base de données.

• C’est une landing page statique ; je ne comprends pas pourquoi le scroll saccade autant.