JSON Relationship Viewer
Cartographiez les entités et références de clés étrangères dans un JSON — détectez les champs id/*_id et dessinez le graphe de relations.
JSON Document Input
Relationship Diagram (4 Entities)
root
1| _id |
|---|
| 1 |
users
2linked via _parentId → root._id
| _parentId | _id | id | name | |
|---|---|---|---|---|
| 1 | 1 | 1 | Alice | alice@example.com |
| 1 | 2 | 2 | Bob | bob@example.com |
posts
2linked via _parentId → root._id
| _parentId | _id | id | title | userId |
|---|---|---|---|---|
| 1 | 1 | 10 | Hello World | 1 |
| 1 | 2 | 11 | JSON Tools | 2 |
comments
1linked via _parentId → root._id
| _parentId | _id | id | body | postId | userId |
|---|---|---|---|---|---|
| 1 | 1 | 100 | Great article! | 10 | 2 |
Qu'est-ce que JSON Relationship Viewer ?
Le JSON Relationship Viewer exécute le même moteur de normalisation en tables que JSON to Table — chaque tableau d'objets, où qu'il soit dans le document, devient sa propre table, reliée à la table qui le contenait par une colonne `_parentId → parentTable._id` — mais affiche le résultat sous forme de diagramme entité-relation interactif plutôt que de tables littérales. Les nœuds peuvent être disposés de deux façons : une vue Schéma ERD montrant chaque table comme une carte (soit avec toutes ses lignes, soit un résumé compact « Nodes Only » de ses seuls noms de colonnes), ou une vue Graphe de nœuds montrant chaque table comme une petite pastille déplaçable étiquetée de ses comptages de lignes et de colonnes. Une flèche est dessinée d'une table vers un tableau uniquement quand ce tableau se trouve imbriqué directement dans l'un de ses propres enregistrements — le lien vient de l'endroit où le tableau vit physiquement dans le JSON, pas du nom d'un champ, donc un champ ressemblant comme `userId` sur un tableau `posts` frère d'un tableau `users` (tous deux imbriqués sous le même parent, pas l'un dans l'autre) reste une simple colonne aplatie plutôt que de devenir une relation détectée.
Comment utiliser JSON Relationship Viewer
- Collez un tableau JSON d'objets ou un objet unique dans le panneau de gauche, ou chargez l'échantillon intégré Users / Posts / Comments.
- Le diagramme se construit automatiquement — chaque tableau imbriqué d'objets devient son propre nœud, relié par une flèche vers la table dont l'enregistrement le contenait réellement.
- Utilisez les contrôles de vue en bas du canevas pour basculer entre Schéma ERD (cartes de tables complètes, ou « Nodes Only » pour les seuls noms de colonnes) et Graphe de nœuds (pastilles compactes déplaçables).
- Faites glisser un nœud pour le repositionner, cliquez sur Reset pour restaurer la disposition automatique par profondeur, et zoomez avec les contrôles à l'écran ou Ctrl/Cmd + molette.
- Cliquez sur l'icône de téléchargement d'un nœud pour exporter uniquement les lignes de cette table en CSV, ou ouvrez JSON to Table pour voir les mêmes données en tables littérales.
Exemples
Des tableaux frères ne se relient qu'à leur parent commun
Entrée
{ "users": [{ "id": 1, "name": "Alice" }], "posts": [{ "id": 10, "title": "Hi", "userId": 1 }], "comments": [{ "id": 100, "postId": 10, "userId": 1 }] }
Sortie
Quatre nœuds : root (1 ligne), users, posts et comments — chacun relié directement à root, puisque users, posts et comments sont frères plutôt qu'imbriqués les uns dans les autres. userId et postId restent des colonnes simples sur posts/comments, pas des arêtes.
Un véritable tableau un-à-plusieurs imbriqué
Entrée
{"users": [{"id": 1, "name": "Alice", "posts": [{"id": 10, "title": "Hello"}, {"id": 11, "title": "World"}]}]}
Sortie
Deux nœuds liés : users et users.posts, avec une flèche de users vers users.posts — parce que posts est imbriqué dans chaque enregistrement user, pas un tableau frère sous la même racine.
Erreurs courantes
- S'attendre à ce qu'un champ comme userId ou post_id trace une ligne de relation vers une autre table — les arêtes ne viennent que de l'imbrication physique d'un tableau dans le JSON ; un champ ressemblant sur un tableau frère n'est qu'une colonne aplatie, pas un lien détecté.
- Supposer que _id et _parentId sont des champs de vos données d'origine — ils sont synthétiques, générés par l'outil pour représenter le lien parent-enfant, exactement comme dans JSON to Table.
- Fournir un simple tableau de primitives ou un objet plat unique sans tableaux imbriqués en s'attendant à plusieurs nœuds liés — cela produit exactement un nœud (root ou records), puisqu'il n'y a rien à normaliser en table enfant.
- Passer au Graphe de nœuds en s'attendant à y voir les données de lignes — cette vue ne montre que les comptages lignes/colonnes par nœud ; passez au Schéma ERD avec « Nodes Only » désactivé pour voir le contenu complet des tables.
- Disposer les nœuds en arrangement personnalisé puis coller un document JSON différent — la disposition revient à l'arrangement automatique par profondeur dès que l'ensemble des tables détectées change.
Pourquoi utiliser cet outil
- Réutilise exactement la logique de normalisation de JSON to Table, donc le diagramme correspond toujours à ce que le même document produirait en tableurs — pas de règles de détection séparées à garder en tête.
- Deux dispositions distinctes — une vue Schéma ERD détaillée et un Graphe de nœuds compact — couvrent aussi bien la lecture attentive des champs d'une table que la vue d'ensemble d'un document à nombreuses tables liées.
- La disposition automatique positionne les nœuds par profondeur d'imbrication, et le glissement, le zoom et l'export CSV en un clic par nœud sont disponibles sans quitter le diagramme.
- Fonctionne entièrement côté client — le document visualisé n'est jamais téléversé nulle part.
- Un lien direct vers JSON to Table permet de passer du diagramme à la vue tableur littérale des mêmes données en un clic.