O que é multiplicidade no dia a dia
Multiplicidade é basicamente a forma como você descreve quantas entidades de um lado de um relacionamento podem estar ligadas a entidades do outro lado. Parece óbvio quando você lê numa aula, mas na prática muita gente erra isso e depois passa horas debugando queries ou modelando dados de forma inconsistente. Um produto pode ter muitas imagens. Um cliente pode fazer muitos pedidos. Um pedido pertence a um único cliente. Isso é multiplicidade. A notação mais comum usa cardinalidades como 1..1, 0..*, 1..*, que aparecem em diagramas UML, ERDs e até em frameworks ORM como Entity Framework, Django e Hibernate.
Aprenda o que é multiplicidade com exemplos reais de banco de dados
Vou direto ao ponto. Existem quatro tipos fundamentais: Um-para-um (1:1) — Um registro na tabela A corresponde a exatamente um registro na tabela B. O caso clássico é usuário e perfil. Na prática, quase nunca justifico separar essas tabelas a menos que haja uma razão clara como segurança (dados sensíveis isolados) ou escala massiva. Se você está criando uma tabela de perfil só pra dividir responsabilidades, provavelmente tá complicando demais.
Um-para-muitos (1:N) — Um registro na tabela A pode ter vários registros na tabela B, mas cada registro em B pertence a apenas um em A. Cliente para pedidos, autor para livros, departamento para funcionários. Esse é o padrão mais comum e o que mais gera confusão porque as pessoas esquecem de colocar a chave estrangeira no lado "muitos". Se você coloca a FK no lado "um", tá errado. Muitos-para-muitos (M:N) — Um registro em A pode ter vários em B, e vice-versa. Alunos e disciplinas, por exemplo. A pegadinha aqui é que bancos relacionais não suportam M:N nativamente. Você precisa de uma tabela intermediária. Já vi gente tentar armazenar IDs separados por vírgula numa coluna só. Isso quebra normalização, estraga consultas e cria dor de cabeça permanente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Nenhum (0:0 ou opcional) — Quando o relacionamento é totalmente opcional em ambos os lados. É raro acontecer no mundo real sem uma boa justificativa. Aqui vai algo que ninguém ensina direito: multiplicidade não é só sobre quantos registros existem. Ela define comportamento. Quando você mapeia 1:N num ORM, o framework decide se carrega os filhos junto com o pai (eager load) ou sob demanda (lazy load). Se você inverte a multiplicidade sem ajustar o mapeamento, o ORM vai fazer N+1 queries num estalar de dedos e seu relatório que levava 2 segundos vai levar 45.
Eu me lembro de um projeto específico em que estávamos migrando um sistema legado de Java para .NET com Entity Framework. A multiplicidade entre Processo e Anexo estava definida como 1:N, mas na vida real um processo podia não ter nenhum anexo. O ORM por padrão assumiaREQUIRED, então toda query que trazia processos fazia INNER JOIN. O resultado: processos sem anexos simplesmente desapareciam dos relatórios. O sistema inteiro mostrava dados incompletos e ninguém percebia porque os gráficos continuavam "funcionando". A solução foi mudar explicitamente a cardinalidade de saída do lado Processo para 0..* e configurar o mapeamento como LEFT OUTER JOIN. Isso corrigiu os dados, mas quebrou algumas funções que dependiam implicitamente daquela exclusão involuntária, então levou mais duas semanas de ajustes nos formulários que davam aqueles erros silenciosos. Outro problema frequente: multiplicidade ambígua em herança. Se você tem uma classe abstrata Documento com subclasses Contrato e Proposta, e ambas herdam o relacionamento com Cliente, o ORM pode não saber qual multiplicidade aplicar no polimorfismo. Eu já resolvi isso usando tabela-per-classe-hierarchy com uma coluna discriminator, mas o custo de performance em consultas com filtros cruzados pode ser alto. Depende do seu volume de dados.
Se você está usando SQL puro, multiplicidade é traduzida em constraints de chave estrangeira e índices. Sem índice na FK do lado "muitos", cada insert ou update vira uma busca linear. Em tabelas com milhões de linhas, isso transforma um insert que leva 3ms em um que leva 3 segundos. Para quem quer documentar essa definição completa, o termo o que é multiplicidade aparece em praticamente toda documentação técnica de modelagem de dados, desde o livro do Codd sobre modelos relacionais até a especificação do UML 2.5 da OMG. Mas o essencial mesmo é entender que multiplicidade não é uma conveniência de diagrama. Ela é a base de tudo que vem depois: constraints, migrações, queries, caches e até a experiência do usuário final.
