Cardinalidade e opcionalidade na Modelagem de Dados: regras e exemplos práticos

Cardinalidade: o que ela responde no relacionamento

Cardinalidade define quantas ocorrências de uma entidade podem (ou devem) estar associadas a uma ocorrência da outra entidade em um relacionamento. Ela transforma uma frase genérica (ex.: “Cliente faz Pedido”) em uma regra verificável (ex.: “Um Cliente pode fazer de zero a muitos Pedidos; um Pedido deve ser de exatamente um Cliente”).

Para inferir cardinalidade de forma consistente, use perguntas do tipo:

• Quantos X podem estar associados a um Y?
• Quantos X devem estar associados a um Y?

Essas duas perguntas separam dois conceitos: cardinalidade máxima (podem) e cardinalidade mínima (devem), também chamada de opcionalidade.

Cardinalidade máxima (1:1, 1:N, N:N)

1:1 (um para um)

Ocorre quando, para cada ocorrência de A, existe no máximo uma ocorrência de B associada, e vice-versa.

• Pergunta: “Para um A, quantos B podem existir?” → no máximo 1
• Pergunta inversa: “Para um B, quantos A podem existir?” → no máximo 1

Exemplo típico: Pessoa e Passaporte (em um cenário onde cada passaporte pertence a uma única pessoa e cada pessoa tem no máximo um passaporte válido).

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

1:N (um para muitos)

Ocorre quando uma ocorrência de A pode se associar a várias ocorrências de B, mas cada ocorrência de B se associa a no máximo uma ocorrência de A.

• “Para um A, quantos B podem existir?” → muitos
• “Para um B, quantos A podem existir?” → no máximo 1

Exemplo típico: Cliente e Pedido (um cliente pode ter vários pedidos; um pedido é de um único cliente).

N:N (muitos para muitos)

Ocorre quando uma ocorrência de A pode se associar a várias ocorrências de B e uma ocorrência de B pode se associar a várias ocorrências de A.

• “Para um A, quantos B podem existir?” → muitos
• “Para um B, quantos A podem existir?” → muitos

Exemplo típico: Aluno e Disciplina (um aluno cursa várias disciplinas; uma disciplina tem vários alunos).

Em modelagem lógica/relacional, N:N normalmente exige uma entidade associativa (ex.: Matricula) para registrar cada associação e seus atributos (ex.: data, status, nota).

Cardinalidade mínima (opcionalidade): 0 ou 1 como ponto de partida

A cardinalidade mínima responde se a associação é obrigatória ou opcional para cada lado do relacionamento.

• Mínimo 0: participação opcional (pode existir sem se relacionar).
• Mínimo 1: participação obrigatória (não pode existir sem se relacionar).

Combine mínimo e máximo para formar intervalos comuns:

• 0..1 (opcional e no máximo um)
• 1..1 (obrigatório e exatamente um)
• 0..N (opcional e muitos)
• 1..N (obrigatório e muitos)

Como perguntar para descobrir a opcionalidade

Use perguntas “de existência”:

• “Um X pode existir sem Y?” Se sim → mínimo 0; se não → mínimo 1.
• “Um Y pode existir sem X?” (faça para o outro lado também).

Exemplo: Pedido e Cliente

• “Um pedido pode existir sem cliente?” Normalmente não → Pedido tem mínimo 1 de Cliente (pedido exige cliente).
• “Um cliente pode existir sem pedido?” Sim → Cliente tem mínimo 0 de Pedido (cliente pode nunca ter comprado).

Passo a passo prático para inferir cardinalidade e opcionalidade

Passo 1 — Fixe o relacionamento e escreva as duas perguntas de máximo

Para um relacionamento entre A e B, escreva:

• Máximo do lado B: “Para um A, quantos B podem estar associados?”
• Máximo do lado A: “Para um B, quantos A podem estar associados?”

Responda com “no máximo 1” ou “muitos”.

Passo 2 — Escreva as duas perguntas de mínimo (existência)

• Mínimo do lado B: “Um A pode existir sem B?”
• Mínimo do lado A: “Um B pode existir sem A?”

Responda com “sim” (mínimo 0) ou “não” (mínimo 1).

Passo 3 — Registre a cardinalidade em notação de intervalo

Registre para cada lado como min..max. Exemplo:

Cliente 0..N — faz — 1..1 Pedido

(Lendo: um cliente faz zero a muitos pedidos; um pedido é de exatamente um cliente.)

Passo 4 — Valide com exemplos e contraexemplos

Crie 2 ou 3 situações reais e tente “quebrar” a regra:

• Existe pedido sem cliente? (se existir, mínimo do cliente no pedido não pode ser 1)
• Existe pedido com dois clientes? (se existir, máximo do cliente no pedido não pode ser 1)

Se aparecer exceção, ela deve virar regra explícita (ou um novo relacionamento/entidade) em vez de ficar implícita.

Exemplos típicos com leitura correta (incluindo armadilhas)

Armadilha clássica: “Um pedido tem itens” vs “Um item pertence a um pedido”

Essas duas frases parecem equivalentes, mas podem induzir a erros se você não separar mínimo e máximo em cada lado.

Modelos comuns:

• Carrinho/checkout: Pedido 0..N Itens (pedido em rascunho pode estar vazio temporariamente).
• Pedido já “emitido”: Pedido 1..N Itens (regra: pedido emitido deve ter ao menos 1 item).

Perceba que a armadilha está em assumir automaticamente 1..N sem perguntar sobre o ciclo de vida do pedido.

Exemplo: Funcionário e Departamento (com opcionalidade variável)

Perguntas:

• “Para um Departamento, quantos Funcionários podem existir?” → muitos
• “Para um Funcionário, quantos Departamentos podem existir?” → normalmente 1 (lotação principal)
• “Um Funcionário pode existir sem Departamento?” → depende (admitido e ainda não alocado?)
• “Um Departamento pode existir sem Funcionários?” → sim (novo departamento)

Possíveis cardinalidades:

• Departamento 0..N — possui — 0..1 Funcionário (se funcionário pode estar sem lotação)
• Departamento 0..N — possui — 1..1 Funcionário (se todo funcionário deve ter lotação)

O ponto didático: a cardinalidade mínima costuma ser onde o negócio “muda” mais.

Exemplo: Produto e Categoria (cuidado com “pelo menos uma”)

Perguntas:

• “Um Produto pode estar em quantas Categorias?” → pode ser 1 ou muitas (marketplace costuma ser muitas)
• “Uma Categoria pode ter quantos Produtos?” → muitos
• “Um Produto pode existir sem Categoria?” → às vezes não (catálogo exige classificação), às vezes sim (produto em cadastro)

Se for N:N, registre como:

Produto 0..N — classificado_em — 0..N Categoria

Se o negócio exigir “todo produto publicado deve ter ao menos 1 categoria”, isso não é apenas cardinalidade estática: é uma regra condicionada ao estado (“publicado”). Registre como regra de negócio (ver seção de rastreabilidade).

Exemplo: Usuário e E-mail (1:1 que vira 1:N)

É comum começar com “Usuário tem um e-mail” e modelar como 1:1. Pergunte:

• “Um usuário pode ter mais de um e-mail?” (pessoal + corporativo) → se sim, vira 1:N
• “Um e-mail pode estar em mais de um usuário?” (contas compartilhadas) → se sim, vira N:N ou exige regra de unicidade

O erro típico é confundir “campo e-mail” com “entidade e-mail”. Se o negócio prevê múltiplos e-mails e verificação, trate como entidade/relacionamento com cardinalidade adequada.

Como registrar a justificativa da cardinalidade como regra de negócio rastreável

Cardinalidade não deve ficar apenas “desenhada”; ela precisa de uma justificativa textual rastreável para auditoria, evolução e alinhamento com stakeholders. Um formato simples é criar um catálogo de regras com identificador.

Modelo de registro (template)

Exemplos de regras bem escritas

• RB-REL-012 — “Um Pedido deve estar associado a exatamente um Cliente. Um Cliente pode estar associado a zero ou muitos Pedidos.”
• RB-REL-021 — “Um Item de Pedido deve pertencer a exatamente um Pedido. Um Pedido em status EMITIDO deve possuir ao menos um Item de Pedido.”

Note que a segunda regra separa: (1) cardinalidade estrutural do relacionamento (item pertence a um pedido) e (2) regra condicional de mínimo (pedido emitido não pode estar vazio). Isso evita “forçar” uma cardinalidade mínima 1 em todos os estados do pedido.

Checklist rápido de rastreabilidade

• Para cada relacionamento, existe pelo menos uma regra RB-REL-xxx descrevendo mínimo e máximo em ambos os lados.
• Se a opcionalidade depende de estado (rascunho, ativo, publicado), a condição está escrita na regra.
• Há exemplos e contraexemplos para reduzir ambiguidades.
• Se aparecer exceção frequente, ela vira regra explícita ou ajuste no modelo (não fica “combinado verbalmente”).