Uma Cardinalidade Um Para Um Implica Em:

Cardinalidade Um-Para-Um no Modelagem de Dados

Quando você define uma relação um-para-um entre duas entidades, o banco de dados está basicamente dizendo que cada registro na tabela A corresponde a exatamente um registro na tabela B, e vice-versa. Na prática, isso aparece quando você divide uma entidade grande demais em duas menores, ou quando quer separar dados sensíveis ou raramente usados para outra tabela. Implica que haverá uma chave estrangeira em uma das tabelas que também funciona como chave primária, ou uma Chave estrangeira única em ambas as direções (embora esta última seja rara e muitas vezes desnecessária). Eu já vi desenvolvedores criarem triggers para manter a simetria, mas isso geralmente é overengineering — uma única FK com unique constraint resolve. O cenário mais comum que eu enfrento é quando uma tabela de usuários tem campos pessoais sensíveis (CPF, data de nascimento, endereço completo) que precisam de acesso restrito. Você move esses campos para uma tabela auxiliar e mantém um um-para-um com a tabela principal. A FK vai da tabela de dados sensíveis para a tabela de usuários, com unique constraint na FK.

Outro caso típico: tabelas com muitos NULLs. Se 80% dos registros têm um campo opcional e esse campo é pesado (um JSON grande, por exemplo), vale a pena mover para uma segunda tabela. O join é sempre um-para-um, então o custo é baixo. Uma armadilha que poucos mencionam: em alguns SGBDs, índices únicos em FKs um-para-um podem causar contention em INSERTs concorrentes. Eu já vi o PostgreSQL travar em situações onde duas transações tentavam inserir o mesmo valor na FK ao mesmo tempo. A solução foi usar advisory locks ou simplesmente aceitar a perda de concurrency em troca da integridade. Em termos de performance, o join é rápido mas não gratuito. Em tabelas com milhões de linhas, um SELECT com JOIN um-para-um pode ser até 30% mais lento que ler uma única tabela, dependendo do plano de execução. Eu sempre testo com EXPLAIN ANALYZE antes de decidir se vale a pena a separação.

Uma nuance importante: cardinalidade um-para-um não é a mesma coisa que dependência funcional total. Se a tabela B depende da tabela A mas o contrário não se aplica, você tem uma relação assimétrica — tecnicamente ainda é um-para-um, mas na prática funciona como um-para-muitos onde o "muitos" nunca passa de um. Alguns ORMss interpretam isso de formas diferentes, então verifique o mapeamento antes de confiar. Se você está usando MySQL com InnoDB, saiba que chaves estrangeiras em relações um-para-um exigem que a coluna referenciada tenha índice explícito. MySQL não cria índice automaticamente para FKs, então esqueça isso e crie o índice manualmente. Em Postgres, o comportamento é diferente — o índice é criado implicitamente. Em resumo, uma cardinalidade um-para-um implica em manutenção de integridade referencial estrita, possibilidade de otimização de Queryes específicas e, na maioria dos casos, uma simples FK com unique constraint. Não complica a modelagem, mas exige decisão consciente sobre onde colocar a FK e como lidar com operações de bulk insert.