Le diagramme ER interactif : visualiser un schéma relationnel

Un client de base de données doit montrer les relations entre tables aussi clairement que leur contenu. Quand on découvre un schéma inconnu, lire des listes de colonnes ne suffit pas : on a besoin de voir ce qui pointe vers quoi, et comment les entités s'articulent entre elles. Le diagramme entité-relation est l'outil classique pour cette lecture, et QoreDB l'intègre directement dans le Browser.

La contrainte principale est l'honnêteté. Un diagramme ER ne doit pas inventer des relations qui n'existent pas dans la base, ni en masquer qui existent. QoreDB construit son diagramme à partir des métadonnées natives exposées par le moteur, sans heuristique magique, et laisse l'utilisateur enrichir ce graphe avec des relations virtuelles quand le schéma d'origine ne les exprime pas.

Construire le diagramme à partir des métadonnées existantes

La source de vérité, c'est le catalogue du moteur. Pour chaque table, QoreDB interroge son schéma via getTableSchema : colonnes, clé primaire, clés étrangères déclarées, index. Ces données proviennent des fonctions standard de chaque driver : information_schema et pg_catalog pour PostgreSQL, les vues équivalentes pour MySQL, les métadonnées Tiberius pour SQL Server. Aucune inférence, aucun scan de données, aucun modèle statistique pour deviner des relations manquantes.

Les tables sont chargées en parallèle par un petit pool de workers, six en simultané. Sur une base avec cent tables, ce modèle évite un chargement séquentiel tout en gardant le moteur sous une pression contrôlée. Un indicateur de progression (tables chargées sur total) donne un feedback visuel pendant l'opération, et la vue s'initialise dès que le schéma est prêt.

Un rendu SVG piloté par React

Le canevas est construit en deux couches. Les tables sont des éléments HTML positionnés en absolu, ce qui permet de garder le texte sélectionnable, la mise en forme Tailwind, et une gestion fine des événements pointeur. Les liens entre tables sont tracés en SVG sous forme de courbes de Bézier cubiques, dont les points de contrôle dépendent de la distance horizontale entre nœuds. Résultat : des connexions qui se lisent bien même quand les tables sont proches ou très éloignées.

Le layout est simple et déterministe. Les tables sont distribuées dans un maximum de quatre colonnes, chaque nouvelle table allant dans la colonne la moins remplie. Ce placement glouton produit une disposition équilibrée sans avoir besoin d'un algorithme de force physique coûteux côté navigateur. Sur les bases denses, la lisibilité est préservée par l'association zoom plus isolation plus tôt dans la navigation.

Par défaut, chaque table affiche au maximum huit colonnes, en priorisant la clé primaire, les colonnes participant à des clés étrangères sortantes, et celles référencées depuis d'autres tables. Un compteur d'overflow indique combien de colonnes supplémentaires existent, et un clic sur la table l'étend pour les montrer toutes. Cette logique est portée par la fonction buildDisplayColumns qui garde l'information structurellement importante visible sans saturer l'écran.

Isoler une table pour comprendre son voisinage

Sur un schéma de taille moyenne, la vue globale devient vite trop dense pour être exploitable. QoreDB fournit un mode d'isolation : on sélectionne une table, le diagramme ne montre plus qu'elle et les tables directement reliées par une clé étrangère entrante ou sortante. Le reste disparaît jusqu'à ce qu'on repasse en vue globale.

Ce mode est implémenté comme un filtre sur le graphe complet, pas comme un recalcul de layout. Les positions de référence restent stables d'une isolation à l'autre, l'utilisateur conserve ses repères visuels quand il bascule d'une table à ses voisines. C'est un compromis assumé : on perd en compacité au profit de la cohérence visuelle entre les vues.

Clés étrangères natives et virtuelles

Toutes les bases n'ont pas leurs relations déclarées. C'est courant dans les schémas hérités, ou dans MongoDB où la notion de clé étrangère n'existe pas au niveau du moteur. QoreDB distingue deux types d'arêtes dans le diagramme.

Les clés étrangères natives, remontées par le catalogue, sont tracées en ligne pleine. Les clés étrangères virtuelles, définies par l'utilisateur via le panneau Virtual Relations, sont tracées en pointillés violet. La différence visuelle est immédiate : on sait à tout moment si une relation est garantie par le moteur ou déclarée côté client pour faciliter la navigation.

Cette séparation est importante pour la lecture du schéma. Une relation virtuelle n'est jamais promue au rang de contrainte native. Elle reste une vue locale, persistée dans la configuration QoreDB, et n'altère en rien la base sous-jacente. Le diagramme reflète deux niveaux de réalité clairement identifiables, celui du moteur et celui du contexte d'usage.

Pan, zoom, recherche

L'interaction suit les conventions des éditeurs graphiques. Molette pour défiler, Ctrl ou Cmd combiné à la molette pour zoomer autour du curseur, clic-glisser pour déplacer la vue. Un bouton Fit recadre automatiquement sur l'ensemble du graphe, Reset revient au zoom 1:1.

La recherche par nom de table met en évidence les correspondances en atténuant l'opacité des autres, et un bouton Focus centre le diagramme sur la première table trouvée. Combinée à l'isolation, cette boîte à outils suffit pour naviguer dans un schéma de cent tables sans se perdre, en partant soit d'un nom connu, soit d'une table repérée visuellement.

Ce que ça donne en usage réel

Le flux typique sur une base inconnue est direct. On ouvre le diagramme, on laisse le chargement parallèle terminer, on utilise Fit pour avoir la vue d'ensemble. On cherche une table connue par son nom, on l'isole, on étudie ses relations entrantes et sortantes. Un clic sur une table connexe ouvre sa propre vue détaillée dans le Browser, sans perdre l'état du diagramme.

Pour les schémas MongoDB ou hérités, l'ouverture du panneau Virtual Relations permet de déclarer manuellement les liens implicites. Une fois saisis, ils apparaissent immédiatement dans le diagramme en pointillés violet et deviennent exploitables par les autres vues de QoreDB, comme le Foreign Key Peek ou le Browser.

Un outil d'analyse quotidien

Le diagramme ER de QoreDB est délibérément une vue fidèle du catalogue, pas un reverse engineering autonome. Il montre les relations que la base connaît, plus celles que l'utilisateur a déclarées explicitement, et rien d'autre. Ce choix le rend lisible, prévisible, et adapté à un usage quotidien sur des schémas réels. Pour un développeur qui arrive sur une base existante, c'est souvent le premier point d'entrée avant d'écrire la moindre requête.