Relacionamentos entre Entidades

Conecte dados entre categorias

Quando você gerencia dados em planilhas, é comum copiar informações de uma aba para outra — por exemplo, copiar o nome de um cliente da planilha de Clientes para a planilha de Pedidos. Esse método funciona até que o cliente mude de nome, você precise atualizar dezenas de pedidos ou alguém digite o nome de forma diferente em cada lugar.

O ENSPACE resolve esse problema com campos de relacionamento. Em vez de copiar dados, você cria um vínculo que aponta para o registro original. Se o cliente mudar de nome, você altera apenas o cadastro dele — todos os pedidos vinculados passam a exibir o nome atualizado automaticamente.

Para configurar relacionamentos, acesse Configurações > Estrutura > Categorias, selecione a categoria e crie um campo do tipo Relacionamento Simples ou Relacionamento Múltiplo em Campos.

Como funcionam os relacionamentos no ENSPACE

Campos disponíveis

Para conectar categorias, o ENSPACE oferece dois tipos de campo:

Ambos podem ser configurados como obrigatório (o item não pode ser criado sem o vínculo) ou opcional (o vínculo pode ficar vazio).

Notação de cardinalidade

Ao longo desta página, usamos uma notação simplificada para identificar rapidamente cada cenário de relacionamento:

Por exemplo: 1:N ↔ significa "um para vários, bidirecional". Você verá essa notação nos títulos dos cenários e na tabela resumo para facilitar a localização.

Direção do relacionamento

Um relacionamento pode ser unidirecional ou bidirecional:

• Unidirecional — apenas uma categoria possui o campo de relacionamento. A outra não "sabe" do vínculo. Ex: o Pedido sabe quem é o Cliente, mas o Cliente não lista seus pedidos.
• Bidirecional — ambas as categorias possuem campos de relacionamento apontando uma para a outra. Ex: o Pedido sabe quem é o Cliente e o Cliente lista seus pedidos.

Para criar um relacionamento bidirecional, basta criar campos de relacionamento nas duas categorias.

Dependência

Quando um relacionamento é bidirecional, você pode ativar a Dependência entre os campos. A Dependência faz com que os vínculos se sincronizem automaticamente: ao vincular o Pedido ao Cliente de um lado, o campo do outro lado é atualizado sozinho. Ao remover o vínculo de um lado, o outro também é atualizado.

Sem Dependência, os campos dos dois lados funcionam de forma independente — você precisa vincular manualmente em cada categoria.

Workspace de exemplo

Para ilustrar todos os cenários de relacionamento, usaremos um workspace fictício de uma empresa de serviços com as seguintes categorias:

Cada seção abaixo explora um tipo de configuração diferente usando categorias deste mesmo workspace.

Cenários de relacionamento

Os cenários estão organizados em três grupos, do mais simples ao mais complexo:

Unidirecional (sem campo de volta)

Neste tipo de relacionamento, apenas uma categoria possui o campo de relacionamento. A outra categoria não tem nenhum campo apontando de volta — ela não "sabe" quais registros estão vinculados a ela.

Exemplos

Cenário 1 (1 →) — Relacionamento Simples unidirecional

Situação:

Cada pedido pertence a um único cliente. Ao acessar um pedido, preciso saber quem é o cliente vinculado a ele, mas, ao acessar um cliente, não preciso ver a lista de todos os seus pedidos automaticamente.

Configuração:

O que acontece na prática:

• Ao criar um pedido, o usuário seleciona o cliente relacionado a ele no campo de relacionamento.
• Na tela do pedido, é possível clicar no nome do cliente e acessar seu cadastro completo.
• Na tela do cliente, não há indicação de quais pedidos estão vinculados a ele.

Quando usar:

Quando o vínculo serve como classificação ou referência e você não precisa consultar "todos os pedidos deste cliente" a partir do cadastro do cliente. Se mais tarde essa necessidade surgir, basta adicionar um campo de volta.

Cenário 2 (N →) — Relacionamento Múltiplo unidirecional

Situação:

Cada projeto pode ter várias tags que classificam o tipo de trabalho (ex: "Urgente", "Internacional", "Recorrente"). As tags são apenas marcadores — elas não precisam saber em quais projetos estão sendo usadas.

Configuração:

O que acontece na prática:

• Ao criar ou editar um projeto, o usuário pode selecionar (neste exemplo, não é obrigatório) uma ou mais tags no campo de relacionamento.
• Na tela do projeto, todas as tags aparecem listadas.
• Na tela de uma tag, não há indicação de quais projetos a utilizam.

Quando usar:

Quando o vínculo é uma lista ou composição flexível e a categoria referenciada funciona apenas como catálogo de opções. Se o campo for obrigatório, o projeto não poderá ser criado sem pelo menos uma tag selecionada.

Bidirecional sem Dependência

Neste tipo de relacionamento, ambas as categorias possuem campos de relacionamento apontando uma para a outra. Porém, os campos funcionam de forma independente: vincular um item de um lado não atualiza automaticamente o outro lado. É necessário vincular manualmente em cada categoria.

Exemplos

Cenário 3 (1:1 ↔) — Simples ↔ Simples, sem Dependência

Situação:

Cada contrato está vinculado a um projeto, e cada projeto está vinculado a um contrato. Quero poder consultar "qual é o projeto deste contrato" e também "qual é o contrato deste projeto", mas os dois cadastros são feitos por equipes diferentes em momentos diferentes — o contrato é registrado pelo jurídico e o projeto é registrado pela operação. Cada equipe vincula do seu lado quando for conveniente.

Configuração:

O que acontece na prática:

• O jurídico cria o contrato e vincula ao projeto no campo projeto.
• A operação cria o projeto e vincula ao contrato no campo contrato.
• Se o jurídico vincular o contrato ao projeto, o campo contrato dentro do projeto não é preenchido automaticamente. A operação precisa vincular do seu lado manualmente.
• Cada equipe trabalha no seu ritmo, sem que uma dependa da outra para registrar o vínculo.

Quando usar:

Quando equipes ou processos diferentes gerenciam cada lado do vínculo de forma independente e a sincronização automática não é desejável.

Cenário 4 (1:N ↔) — Simples ↔ Múltiplo, sem Dependência

Situação:

Cada pedido está vinculado a um único cliente. Do lado do cliente, a equipe comercial registra manualmente quais pedidos pertencem a ele para acompanhamento — mas esse registro é feito pelo comercial, não automaticamente pelo sistema.

Configuração:

O que acontece na prática:

• Ao criar um pedido, o atendimento seleciona o cliente (obrigatório).
• Na tela do pedido, o cliente aparece vinculado.
• Na tela do cliente, o campo pedidos começa vazio — o comercial adiciona manualmente os pedidos conforme precisa acompanhá-los.
• Se o atendimento vincular o Pedido #001 ao Cliente João, o campo pedidos dentro do cadastro de João não é preenchido automaticamente. O comercial precisa adicionar o Pedido #001 na lista de João manualmente.

Quando usar:

Quando um lado do vínculo é preenchido no ato da criação (ex: o pedido sempre tem um cliente) mas o outro lado é curado manualmente por outra equipe ou processo.

Cenário 5 (N:N ↔) — Múltiplo ↔ Múltiplo, sem Dependência

Situação:

Cada projeto pode ter vários funcionários alocados, e cada funcionário pode registrar em quais projetos está participando. Porém, a alocação é feita pelo gerente de projeto de um lado e o funcionário registra do seu lado quais projetos está acompanhando — sem sincronização automática.

Configuração:

O que acontece na prática:

• O gerente de projeto cria o projeto e seleciona os funcionários que farão parte da equipe (obrigatório — precisa de pelo menos um).
• Cada funcionário pode registrar no seu próprio cadastro em quais projetos está participando.
• Se o gerente alocar Ana no Projeto Alpha, o campo projetos dentro do cadastro de Ana não é preenchido automaticamente. Ana precisa adicionar o Projeto Alpha na sua lista manualmente.
• As duas listas podem ficar temporariamente inconsistentes — isso é esperado neste cenário, pois cada lado é gerenciado por pessoas diferentes.

Quando usar:

Quando ambos os lados mantêm suas próprias listas de forma independente e a inconsistência temporária é aceitável. É útil quando a gestão é descentralizada — cada parte do processo registra seus vínculos no seu próprio ritmo.

Bidirecional com Dependência

Neste tipo de relacionamento, ambas as categorias possuem campos de relacionamento apontando uma para a outra e a Dependência está ativada.

Isso significa que os vínculos se sincronizam automaticamente: ao vincular um item de um lado, o campo do outro lado é atualizado sozinho. Ao remover o vínculo de um lado, o outro também é atualizado.

Criando itens quando ambos os lados são obrigatórios

Quando a Dependência está ativada e ambos os lados são obrigatórios, pode surgir a dúvida: "Se o Contrato exige um Projeto e o Projeto exige um Contrato, qual crio primeiro?"

O ENSPACE resolve isso com um atalho de criação dentro do campo de relacionamento. Na prática:

1. Você começa criando o item na primeira categoria (ex: Contrato).
2. No campo de relacionamento, o dropdown estará vazio (ainda não há projetos).
3. Na base do dropdown, há um botão de atalho para criar um novo item na categoria relacionada (Projetos).
4. Ao criar o projeto por esse atalho, o campo de relacionamento do projeto para o contrato já é preenchido automaticamente com uma pré-referência ao contrato que você está criando.

Exemplos

Cenário 6 (1:1 ↔ dep.) — Simples ↔ Simples, com Dependência

Situação:

Cada contrato está vinculado a um único projeto, e cada projeto está vinculado a um único contrato.

Quero que o vínculo seja mantido sincronizado: se o jurídico vincular o contrato ao projeto, a operação já vê o contrato no cadastro do projeto automaticamente — e vice-versa. Um contrato não pode existir sem projeto e um projeto não pode existir sem contrato.

Configuração:

O que acontece na prática:

• O jurídico cria o contrato e seleciona o projeto. Automaticamente, o campo contrato dentro do projeto é preenchido com o contrato recém-criado.
• Se a operação alterar o vínculo do lado do projeto (trocar o contrato), o campo projeto dentro do contrato antigo é limpo e o novo contrato recebe o vínculo automaticamente.
• Não é possível criar um contrato sem selecionar um projeto existente, nem criar um projeto sem selecionar um contrato existente.
• Se o contrato for excluído, ele é inativado e o campo contrato dentro do projeto perde a referência.

Quando usar:

Quando dois registros possuem uma correspondência exclusiva e o vínculo precisa ser mantido sincronizado dos dois lados. Ideal para pares inseparáveis onde a integridade é crítica.

Cenário 7 (1:N ↔ dep.) — Simples ↔ Múltiplo, com Dependência

Situação:

Cada pedido pertence a um único cliente. Do lado do cliente, todos os pedidos vinculados a ele devem ser listados automaticamente.

Quero que, ao criar um pedido e selecionar o cliente, esse pedido apareça automaticamente na lista de pedidos do cliente — sem precisar de ação manual.

Configuração:

O que acontece na prática:

• O atendimento cria o Pedido #001 e seleciona o Cliente João (obrigatório).
• Automaticamente, o Pedido #001 aparece na lista pedidos dentro do cadastro de João.
• Se o atendimento trocar o cliente do Pedido #001 de João para Maria, automaticamente o Pedido #001 sai da lista de João e entra na lista de Maria.
• Na tela do cliente, a lista de pedidos é sempre atualizada — sem intervenção manual do comercial.
• Não é possível criar um pedido sem selecionar um cliente existente.

Quando usar:

É o cenário mais comum em sistemas de gestão: um registro "filho" (pedido, contrato, chamado) pertence a um registro "pai" (cliente, empresa, departamento), e o pai precisa listar todos os seus filhos automaticamente.

A Dependência garante que a lista esteja sempre atualizada.

Cenário 8 (N:N ↔ dep.) — Múltiplo ↔ Múltiplo, com Dependência

Situação:

Cada projeto pode ter vários funcionários alocados, e cada funcionário pode estar em vários projetos simultaneamente.

Quero que a alocação seja sincronizada: se o gerente adicionar Ana ao Projeto Alpha, o Projeto Alpha deve aparecer automaticamente na lista de projetos de Ana — e vice-versa.

Configuração:

O que acontece na prática:

• O gerente cria o Projeto Alpha e seleciona Ana, Bruno e Carlos como equipe (obrigatório — precisa de pelo menos um).
• Automaticamente, o Projeto Alpha aparece na lista projetos de Ana, Bruno e Carlos.
• Se Ana for removida do Projeto Alpha pelo gerente, automaticamente o Projeto Alpha desaparece da lista de projetos de Ana.
• Se Carlos adicionar o Projeto Beta na sua própria lista de projetos, automaticamente Carlos aparece na equipe do Projeto Beta.
• As duas listas estão sempre sincronizadas — alterar de qualquer lado atualiza o outro.

Quando usar:

Quando a relação é de muitos para muitos e a consistência entre os dois lados é essencial. Ideal para alocação de equipe, matrículas em disciplinas, produtos de fornecedores — qualquer cenário onde registros de ambos os lados podem ser adicionados ou removidos livremente e o outro lado precisa refletir imediatamente.

Resumo dos cenários

Boas práticas

• Comece simples. Use relacionamento unidirecional. Adicione o campo de volta apenas quando precisar consultar o vínculo do outro lado.
• Ative Dependência com cuidado. Ela é poderosa, mas impõe regras de integridade. Use apenas quando a sincronização automática for realmente necessária.
• Pense na obrigatoriedade de cada lado separadamente. Um lado pode ser obrigatório e o outro opcional — isso é normal e esperado.
• Nunca digite o que você pode vincular. Se a informação já existe em outra categoria, use um campo de relacionamento em vez de copiar o texto manualmente.
• Uma categoria = uma entidade. Não coloque clientes e produtos na mesma categoria. Separe para poder relacionar depois.
• O nome da categoria importa. Escolha nomes claros ("Clientes", "Produtos", "Projetos") para que os vínculos façam sentido para quem preenche o formulário.
• Mais de um campo para a mesma categoria é possível, mas raro. Você pode ter dois campos de relacionamento apontando para a mesma categoria (ex: "Cliente" e "Indicador" ambos apontando para Clientes), mas isso só deve ser usado quando fizer sentido na modelagem de dados. Na maioria dos casos, um único campo é suficiente.

Perguntas frequentes