Relacionamentos na Modelagem de Dados: significado, verbos e participação

O que é um relacionamento (e o que ele não é)

Em modelagem de dados, relacionamento é um fato do negócio que conecta duas (ou mais) entidades, indicando como elas interagem. Ele responde a perguntas do tipo: “o que uma instância de A faz com uma instância de B?” ou “como A se associa a B?”.

Um relacionamento bem definido tem: significado (semântica), um verbo (ação/associação) e regras de participação (se a participação é obrigatória ou opcional para cada lado).

Evite confundir relacionamento com:

• Atributo: se a informação é apenas uma característica de uma entidade (ex.: “Cliente tem CPF”), não é relacionamento.
• Evento isolado sem persistência: se não há necessidade de registrar o vínculo entre instâncias ao longo do tempo, pode não virar relacionamento persistente.
• Processo: “Cliente paga boleto” pode ser processo; vira relacionamento se o negócio precisa registrar o vínculo “Cliente realiza Pagamento” com dados próprios (data, valor, status).

Como identificar relacionamentos a partir de frases do negócio

1) Procure verbos e locuções verbais

Frases do negócio costumam revelar relacionamentos por meio de verbos: compra, possui, solicita, pertence a, é responsável por, é alocado em.

Exemplos de frases e candidatos a relacionamento:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• “Cliente realiza pedido.” → relacionamento entre Cliente e Pedido.
• “Pedido contém itens.” → relacionamento entre Pedido e Item (ou Produto, dependendo do modelo).
• “Funcionário supervisiona funcionário.” → relacionamento recursivo em Funcionário.

2) Transforme a frase em uma estrutura sujeito–verbo–objeto

Um método prático é reescrever a frase como: Entidade A (sujeito) verbo Entidade B (objeto).

Cliente — realiza — Pedido

Se a frase tiver complementos importantes, avalie se eles viram atributos do relacionamento (ou uma entidade associativa):

Cliente — realiza — Pedido (data, canal, status)

3) Verifique se o vínculo é “registrável”

Pergunte: “o negócio precisa guardar que A se relacionou com B?”. Se sim, é um forte indício de relacionamento persistente.

• “Aluno frequenta turma” geralmente precisa ser guardado (matrícula, data, situação).
• “Usuário visualiza página” pode ser guardado ou não, dependendo de requisitos de auditoria/analytics.

4) Diferencie relação direta de classificação/pertencimento

Frases como “Produto pertence a Categoria” podem representar uma classificação. Ainda é relacionamento, mas o verbo tende a ser pertence a / é classificado em. Isso ajuda a evitar nomes genéricos como “tem”.

Nomeação semântica: escolhendo verbos que explicam o fato

Boas práticas para nomear relacionamentos

• Use verbo no presente e com significado do negócio: “realiza”, “contém”, “aprova”, “aloca”, “pertence a”.
• Evite verbos genéricos: “tem”, “possui”, “relaciona”. Prefira o que descreve o fato.
• Considere o sentido inverso também (papéis): se “Pedido contém Produto”, o inverso é “Produto compõe Pedido” (ou “Produto é incluído em Pedido”).
• Se houver ambiguidade, inclua contexto: “Usuário abre Chamado” vs “Usuário acompanha Chamado”.

Exemplos de nomeação (ruim → melhor)

Papéis das entidades no relacionamento

Em um relacionamento, cada entidade participa com um papel (role), que é a forma como ela se comporta naquele vínculo. Papéis são essenciais quando:

• o mesmo par de entidades se relaciona de mais de uma forma (ex.: “Usuário cria Documento” e “Usuário aprova Documento”);
• o relacionamento é recursivo (a entidade se relaciona consigo mesma);
• há múltiplas participações da mesma entidade em um relacionamento ternário.

Como definir papéis na prática

Use nomes que expliquem a função no vínculo:

• “Pedido contém Produto”: papéis podem ser pedido e produto (simples).
• “Usuário aprova Documento”: papéis aprovador (Usuário) e documento aprovado (Documento).
• Recursivo “Funcionário supervisiona Funcionário”: papéis supervisor e subordinado.

Participação: obrigatória vs opcional (e como descobrir)

Participação indica se uma instância de uma entidade precisa participar do relacionamento (obrigatória) ou pode não participar (opcional). Isso é uma regra de negócio, não uma preferência técnica.

Perguntas-guia para determinar participação

• Para uma instância de A existir, ela precisa estar ligada a B por esse relacionamento?
• É permitido cadastrar A sem B?
• Em algum momento do ciclo de vida, A pode ficar sem B?

Exemplos práticos

Exemplo 1: Pedido e Cliente

• “Todo Pedido é realizado por um Cliente.” → participação de Pedido no relacionamento com Cliente: obrigatória.
• “Um Cliente pode não ter Pedido.” → participação de Cliente no relacionamento com Pedido: opcional.

Exemplo 2: Funcionário e Departamento

• Se a regra for “Todo Funcionário deve estar lotado em um Departamento”: participação de Funcionário é obrigatória.
• Se existir “Funcionário em treinamento ainda sem lotação”: participação de Funcionário pode ser opcional (ou pode haver um Departamento “Treinamento”; cuidado para não mascarar regra com valores artificiais).

Exemplo 3: Produto e Categoria

• “Todo Produto deve pertencer a uma Categoria.” → Produto: obrigatória.
• “Categoria pode existir sem Produto.” → Categoria: opcional.

Armadilhas comuns ao definir participação

• Confundir “no futuro terá” com “agora é obrigatório”: “Cliente terá endereço” não implica que no cadastro inicial seja obrigatório.
• Obrigatoriedade por conveniência: tornar obrigatório para “facilitar relatório” costuma gerar dados falsos.
• Obrigatoriedade condicional: “Pedido deve ter cupom se for promocional”. Isso não é participação simples; é regra condicional que pode exigir modelagem adicional.

Passo a passo prático: do texto do negócio ao relacionamento nomeado e com participação

Cenário

Considere as frases:

• “Cliente realiza pedidos pelo site.”
• “Pedido contém produtos e informa a quantidade de cada produto.”
• “Um pedido pode ser aprovado por um funcionário.”

Passo 1: Extraia sujeito–verbo–objeto

• Cliente — realiza — Pedido
• Pedido — contém — Produto
• Funcionário — aprova — Pedido

Passo 2: Nomeie com verbo semântico e defina papéis

• realiza: Cliente (papel: cliente) e Pedido (papel: pedido)
• contém: Pedido (papel: pedido) e Produto (papel: produto)
• aprova: Funcionário (papel: aprovador) e Pedido (papel: pedido aprovado)

Passo 3: Identifique se há dados do vínculo (atributos do relacionamento)

Na frase “Pedido contém produtos e informa a quantidade de cada produto”, a quantidade não é atributo de Pedido nem de Produto isoladamente; é do vínculo “Pedido contém Produto”. Isso indica que o relacionamento precisa carregar informação própria (muitas vezes implementado como entidade associativa, mas aqui o ponto é reconhecer o dado do vínculo).

• Relacionamento: Pedido — contém — Produto
• Dado do vínculo: quantidade

Passo 4: Determine participação com perguntas-guia

• Pedido precisa de Cliente? Geralmente sim → Pedido participa de forma obrigatória em “Cliente realiza Pedido”.
• Cliente precisa de Pedido? Não → Cliente participa de forma opcional.
• Pedido precisa ser aprovado por Funcionário? Depende: se “todo pedido deve ser aprovado” → obrigatória para Pedido; se “apenas pedidos acima de valor X” → regra condicional (não é obrigatoriedade simples).

Relacionamentos recursivos (auto-relacionamento)

Um relacionamento é recursivo quando uma entidade se relaciona com ela mesma. Isso é comum em hierarquias e estruturas de rede.

Exemplos típicos

• “Funcionário supervisiona Funcionário”
• “Categoria possui subcategoria”
• “Conta transfere para Conta”

Como modelar semanticamente: papéis são obrigatórios

Sem papéis, o relacionamento fica ambíguo. Defina claramente:

Funcionário (papel: supervisor) — supervisiona — Funcionário (papel: subordinado)

Participação em recursivos: perguntas úteis

• Todo funcionário tem supervisor? Se não (ex.: diretor), então o papel “subordinado” pode ser opcional em relação ao “supervisor”.
• Um supervisor pode não ter subordinados? Sim, então o papel “supervisor” pode ser opcional em relação ao “subordinado”.

Cuidados comuns

• Evitar ciclos indevidos: em hierarquias, pode haver regra “não pode supervisionar a si mesmo” e “não pode haver cadeia circular”.
• Cardinalidade implícita: “cada funcionário tem no máximo um supervisor” é diferente de “pode ter vários supervisores”.

Relacionamentos ternários (quando 2 entidades não bastam)

Um relacionamento é ternário quando envolve três entidades no mesmo fato de negócio, e decompor em relacionamentos binários faz perder significado ou cria ambiguidades.

Como reconhecer a necessidade de ternário

Indícios práticos:

• O fato depende simultaneamente de três participantes: “X atribui Y a Z”.
• Se você separar em dois relacionamentos, não consegue garantir a combinação correta.
• Existe um dado que pertence à combinação dos três, não a pares.

Exemplo 1: Professor ministra Disciplina em Turma

Frase: “Professor ministra Disciplina para uma Turma.”

Se você separar em:

• Professor — ministra — Disciplina
• Disciplina — ocorre em — Turma

Você pode acabar permitindo combinações inválidas (um professor associado à disciplina e a disciplina associada à turma, mas não necessariamente aquele professor ministrando aquela disciplina naquela turma). O ternário preserva o fato: Professor ministra Disciplina em Turma.

Exemplo 2: Vendedor oferece Produto para Cliente (com preço negociado)

Frase: “Vendedor oferece Produto para Cliente com preço negociado.” O preço pode depender do trio (vendedor, produto, cliente). Separar em binários pode não capturar corretamente o preço por combinação.

Participação em ternários

Faça as mesmas perguntas de obrigatoriedade, mas considerando o fato completo. Ex.: “Para existir uma oferta, precisa haver vendedor, produto e cliente” → participação obrigatória dos três no relacionamento “oferece”.

Checklist de validação do relacionamento (fato do negócio e sem redundância)

Validação semântica (o relacionamento faz sentido?)

• O relacionamento pode ser expresso como uma frase clara: “A <verbo> B” (ou “A <verbo> B em C” no ternário)?
• O verbo escolhido é específico e não genérico (“tem”, “possui”)?
• Os papéis das entidades estão claros (especialmente em recursivos e quando há múltiplos relacionamentos entre as mesmas entidades)?
• O relacionamento representa algo que o negócio precisa registrar/consultar?

Validação de participação (obrigatória/opcional)

• É permitido existir A sem B (neste relacionamento)?
• É permitido existir B sem A?
• Existe obrigatoriedade condicional? Se sim, a regra foi registrada como regra de negócio (e não “forçada” como obrigatória sempre)?

Validação contra redundâncias e modelagem duplicada

• O relacionamento não está duplicando informação que já existe em outro relacionamento com o mesmo significado?
• Você não criou dois relacionamentos com verbos diferentes para o mesmo fato (sinônimos), sem necessidade?
• Se há um atributo que parece “de A”, mas varia conforme B, ele foi colocado no relacionamento (ou em estrutura associativa) em vez de duplicado em A?
• Em ternários, você evitou decompor em binários que geram combinações inválidas?
• Em recursivos, você definiu papéis e regras para evitar auto-referência e ciclos indevidos quando aplicável?