JSON Relationship Viewer
Mapeie entidades e referências de chave estrangeira em JSON — detecte campos id/*_id e desenhe o grafo de relacionamentos.
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 |
O que é JSON Relationship Viewer?
O JSON Relationship Viewer executa o mesmo motor de normalização de tabelas do JSON to Table — todo array de objetos em qualquer ponto do documento se torna sua própria tabela, ligada de volta à tabela que o continha por meio de uma coluna `_parentId → parentTable._id` — mas renderiza o resultado como um diagrama entidade-relacionamento interativo em vez de tabelas literais de planilha. Os nós podem ser dispostos de duas formas: uma visão de Schema ERD mostrando cada tabela como um cartão (com suas linhas completas ou um resumo compacto 'Nodes Only' apenas com os nomes das colunas), ou uma visão de Grafo Nó-Link mostrando cada tabela como uma pequena pílula arrastável rotulada com suas contagens de linhas e colunas. Uma seta é desenhada de uma tabela para um array somente quando esse array está aninhado diretamente dentro de um de seus próprios registros — o vínculo vem de onde o array fisicamente reside no JSON, não do nome de um campo, de modo que um campo como `userId` num array `posts` que é irmão de um array `users` (ambos aninhados sob o mesmo pai, não dentro um do outro) permanece uma simples coluna achatada em vez de se tornar um relacionamento detectado.
Como usar JSON Relationship Viewer
- Cole um array JSON de objetos ou um objeto único no painel esquerdo, ou carregue a amostra embutida de Users / Posts / Comments.
- O diagrama é construído automaticamente — todo array aninhado de objetos se torna seu próprio nó, conectado por uma seta de volta à tabela cujo registro de fato o continha.
- Use os controles de exibição na parte inferior da tela para alternar entre Schema ERD (cartões de tabela completos, ou 'Nodes Only' apenas com os nomes das colunas) e Grafo Nó-Link (pílulas compactas arrastáveis).
- Arraste qualquer nó para reposicioná-lo, clique em Reset para restaurar o layout automático por profundidade e faça zoom com os controles na tela ou Ctrl/Cmd + rolagem.
- Clique no ícone de download em qualquer nó para exportar apenas as linhas daquela tabela como CSV, ou abra o JSON to Table para ver os mesmos dados como tabelas literais de planilha.
Exemplos
Arrays irmãos conectam-se apenas ao pai compartilhado
Entrada
{ "users": [{ "id": 1, "name": "Alice" }], "posts": [{ "id": 10, "title": "Hi", "userId": 1 }], "comments": [{ "id": 100, "postId": 10, "userId": 1 }] }
Saída
Quatro nós: root (1 linha), users, posts e comments — cada um ligado diretamente à root, já que users, posts e comments são irmãos, e não aninhados uns dentro dos outros. userId e postId permanecem colunas simples em posts/comments, não arestas.
Um array um-para-muitos genuinamente aninhado
Entrada
{"users": [{"id": 1, "name": "Alice", "posts": [{"id": 10, "title": "Hello"}, {"id": 11, "title": "World"}]}]}
Saída
Dois nós ligados: users e users.posts, com uma seta de users para users.posts — porque posts está aninhado dentro de cada registro de user, e não é um array irmão sob a mesma raiz.
Erros comuns
- Esperar que um campo como userId ou post_id desenhe uma linha de relacionamento até outra tabela — as arestas vêm apenas de onde um array está fisicamente aninhado no JSON; um campo de aparência semelhante num array irmão é só uma coluna achatada, não um vínculo detectado.
- Assumir que _id e _parentId são campos dos seus dados originais — são sintéticos, gerados pela ferramenta para representar o vínculo pai-filho, exatamente como no JSON to Table.
- Fornecer um array simples de primitivos ou um único objeto plano sem arrays aninhados e esperar vários nós ligados — isso produz exatamente um nó (root ou records), já que não há nada a normalizar em uma tabela filha.
- Mudar para o Grafo Nó-Link e esperar ver ali os dados das linhas reais — essa visão mostra apenas as contagens de linhas/colunas por nó; mude para o Schema ERD com 'Nodes Only' desligado para ver o conteúdo completo das tabelas.
- Arrastar os nós para um layout personalizado e depois colar um documento JSON diferente — o layout volta à disposição automática por profundidade sempre que o conjunto de tabelas detectadas muda.
Por que usar esta ferramenta
- Reutiliza exatamente a lógica de normalização do JSON to Table, então o diagrama sempre corresponde ao que o mesmo documento produziria como planilhas — sem regras de detecção separadas para manter mentalmente em sincronia.
- Dois layouts distintos — uma visão detalhada de Schema ERD e um Grafo Nó-Link compacto — cobrem tanto a leitura minuciosa dos campos de uma tabela quanto a visão panorâmica de um documento com muitas tabelas ligadas.
- O layout automático posiciona os nós por profundidade de aninhamento, e arrastar, zoom e a exportação CSV com um clique por nó estão todos disponíveis sem sair do diagrama.
- Roda inteiramente no cliente — o documento que você visualiza nunca é enviado a lugar algum.
- Um link direto para o JSON to Table permite pular do diagrama para a visão literal de planilha exatamente dos mesmos dados com um clique.