Chaves na Modelagem de Dados: chave primária, candidata, natural e substituta

O que é uma chave (key) e por que ela importa

Em modelagem de dados, chave é um atributo (ou conjunto de atributos) capaz de identificar unicamente uma ocorrência de uma entidade. A escolha da chave afeta diretamente: integridade (evitar duplicidade), facilidade de integração entre sistemas, estabilidade do modelo ao longo do tempo e performance de consultas e índices.

Chave primária (Primary Key) e chaves candidatas

Chave primária (PK)

Chave primária é a chave escolhida para ser o identificador principal da entidade. Regras práticas:

• Unicidade: não pode haver duas linhas com o mesmo valor de PK.
• Não nula: toda ocorrência deve possuir PK.
• Estabilidade: idealmente não muda (ou muda raramente) durante o ciclo de vida do dado.
• Minimalidade: não deve conter atributos “a mais” que não sejam necessários para garantir unicidade.

Chaves candidatas

Chaves candidatas são todas as chaves possíveis que identificam unicamente a entidade e são minimais. A PK é uma das chaves candidatas escolhida como principal; as demais viram chaves alternativas (geralmente implementadas como UNIQUE no banco).

Exemplo: entidade Cliente pode ter como chaves candidatas CPF e Email (se o negócio garantir unicidade). Você escolhe uma delas como PK (ou cria uma substituta) e mantém as outras como restrições de unicidade.

Unicidade e estabilidade: critérios objetivos

Como avaliar unicidade

Unicidade não é “parece único”; é uma regra de negócio verificável. Perguntas úteis:

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

• O atributo é único por definição (ex.: CPF no Brasil)?
• Existe possibilidade de duplicidade por exceções (ex.: e-mail compartilhado)?
• O dado pode estar ausente (ex.: cliente sem e-mail)?
• O dado pode ser reciclado/reutilizado (ex.: matrícula antiga reaproveitada)?

Como avaliar estabilidade

Estabilidade é sobre probabilidade e impacto de mudança:

• O atributo pode mudar por correção (erro de digitação) ou por evento real (troca de e-mail)?
• Há dependência de regras externas (mudança de padrão, órgão, formatação)?
• Há dependência de contexto (ex.: código interno que muda após fusão de filiais)?

Quanto mais um identificador muda, mais ele “espalha” atualização em chaves estrangeiras, integrações e logs, aumentando custo e risco.

Chave natural vs chave substituta (surrogate)

Chave natural

Chave natural é formada por atributos que já existem no domínio do negócio e têm significado (ex.: CPF, CNPJ, ISBN, código de produto do fornecedor, número de série).

Vantagens:

• Facilita leitura e depuração (o ID “fala” sobre o registro).
• Evita coluna extra de ID em alguns casos.
• Integrações podem ser mais diretas quando o mesmo identificador é compartilhado entre sistemas.

Riscos:

• Pode mudar (e-mail, telefone, código de fornecedor).
• Pode ter regras complexas de validação/normalização (máscaras, zeros à esquerda, variações).
• Pode ser grande (strings longas) e impactar índices e joins.

Chave substituta (surrogate)

Chave substituta é um identificador sem significado de negócio, criado apenas para identificar (ex.: ClienteId inteiro, UUID).

Vantagens:

• Alta estabilidade: não depende de atributos que mudam.
• Performance: inteiros sequenciais tendem a ser eficientes em índices e joins.
• Isola o modelo de mudanças em regras de negócio (ex.: troca de padrão de código externo).

Riscos:

• Integrações precisam de mapeamento (o outro sistema não conhece seu ClienteId).
• Sem restrições adicionais, pode permitir duplicidade lógica (dois clientes com mesmo CPF).

Quando usar cada uma (guia prático)

Impactos em integrações e performance

Integrações

Ao escolher uma surrogate como PK, é comum precisar de identificadores de negócio para troca de dados. Boas práticas:

• Manter o identificador natural como chave alternativa (UNIQUE) quando aplicável.
• Quando há múltiplos identificadores externos, modelar explicitamente: ClienteIdentificadorExterno(ClienteId, Sistema, CodigoExterno) com UNIQUE(Sistema, CodigoExterno).
• Definir regras de normalização do identificador natural (ex.: remover máscara, padronizar case) para evitar duplicidade “invisível”.

Performance

Em geral, PKs numéricas (inteiro/long) são eficientes para índices e junções. PKs em string:

• Ocupam mais espaço em índice.
• Podem aumentar custo de comparação e cache.
• Podem fragmentar mais dependendo do padrão de inserção.

UUID é útil para geração distribuída (sem depender de sequência central), mas pode ter custo maior em armazenamento e índice. Se usar UUID, considere estratégias de UUID ordenável (quando suportado) para reduzir fragmentação.

Chaves compostas (compostas) e quando fazem sentido

Chave composta é uma PK formada por mais de um atributo. Ela é comum em:

• Entidades associativas (tabelas de ligação), como Matricula(AlunoId, TurmaId).
• Dados onde a identidade é naturalmente composta por contexto (ex.: (NumeroNota, Serie, Emissor)).

Cuidados:

• Chaves compostas “propagam” para chaves estrangeiras, aumentando largura de tabelas e complexidade de joins.
• Se algum componente for instável, toda a PK fica instável.
• Podem dificultar integrações e APIs, que preferem um identificador simples.

Alternativa comum: usar surrogate como PK e manter a combinação natural como UNIQUE.

-- Exemplo: Matricula com surrogate e unicidade natural preservada (conceitual/relacional)  MatriculaId (PK)  AlunoId (FK)  TurmaId (FK)  UNIQUE(AlunoId, TurmaId)

Critérios para evitar chaves frágeis

Chave frágil é aquela que parece única, mas na prática quebra por mudança, exceção ou falta de governança. Sinais de alerta:

• Depende de formatação (com máscara, espaços, hífens) sem regra clara de normalização.
• Depende de atributo que o usuário edita frequentemente (e-mail, nome, apelido).
• Depende de código “inteligente” (com significado embutido: ano, filial, categoria) que muda quando a regra muda.
• É gerado fora do seu controle sem garantia contratual de unicidade (código de parceiro sem SLA).
• É composto por muitos campos para “forçar” unicidade (tende a esconder problema de definição).

Critérios práticos para uma boa chave:

• Curta (especialmente se for PK física).
• Imutável ou raramente mutável.
• Sem significado de negócio quando o negócio é volátil.
• Com regra de unicidade explícita (PK/UNIQUE) e validada por dados.

Passo a passo: identificando chaves a partir de requisitos e dados de amostra

Passo 1: liste candidatos óbvios e regras declaradas

A partir dos requisitos, anote atributos que o negócio trata como identificadores: “número do documento”, “código do produto”, “matrícula”, “número do pedido”. Cada um vira um candidato inicial.

Passo 2: valide unicidade com dados de amostra

Use amostras para procurar duplicidades e nulos. Exemplo de amostra para Cliente:

Leituras:

• CPF duplicado (Ana e Bruno) indica problema: ou a amostra tem erro, ou a regra “CPF é único” não está sendo aplicada, ou há casos como dependentes/representantes. Isso precisa virar regra clara.
• Email duplicado (Carla e Daniel) mostra que e-mail não é bom candidato se o negócio não garante exclusividade.
• CPF vazio (Carla) mostra que não pode ser PK se o cadastro permitir ausência.

Passo 3: avalie estabilidade e governança

Mesmo que um atributo seja único, pergunte se ele muda. E-mail muda com frequência; CPF raramente muda, mas pode ter correções e precisa de validação/normalização (sem máscara, com dígitos verificadores).

Passo 4: decida entre natural e surrogate

Com base nos passos anteriores:

• Se existe um identificador natural único, obrigatório e estável, ele pode ser PK.
• Se há dúvidas de estabilidade/obrigatoriedade, use surrogate como PK e mantenha o natural como UNIQUE quando aplicável.

Exemplo de decisão para Cliente:

• PK: ClienteId (surrogate)
• Restrição: CPF como UNIQUE apenas se for obrigatório e garantido (ou UNIQUE condicional quando o SGBD suportar, para permitir múltiplos nulos).

Passo 5: trate casos de múltiplos identificadores externos

Exemplo: um cliente pode ter códigos em sistemas diferentes (ERP, CRM, e-commerce). Em vez de tentar escolher “o” código como PK, modele:

Cliente(ClienteId PK, Nome, ...)  ClienteCodigoExterno(ClienteId FK, Sistema, Codigo, UNIQUE(Sistema, Codigo))

Isso evita colisões entre sistemas e preserva rastreabilidade de integrações.

Exemplos práticos de escolha de chave

Exemplo 1: Produto

Requisitos: “Produto tem SKU interno, pode mudar quando há reclassificação; também pode ter EAN (código de barras), nem todo produto tem EAN (serviços).”

• SKU: pode mudar → instável.
• EAN: nem sempre existe → não obrigatório.

Escolha típica:

• PK surrogate: ProdutoId
• SKU com UNIQUE (se o negócio garantir unicidade no tempo; se pode mudar, ainda pode ser UNIQUE, mas com processo de alteração controlado)
• EAN com UNIQUE quando presente (evitar duplicidade de código de barras)

Exemplo 2: Item de Pedido (entidade associativa)

Requisitos: “Um pedido tem itens numerados por sequência (1,2,3...).”

Chave candidata natural: (PedidoId, SequenciaItem) é única dentro do pedido e costuma ser estável.

Opções:

• PK composta: (PedidoId, SequenciaItem) (boa quando o modelo é interno e você aceita FKs compostas).
• PK surrogate: PedidoItemId + UNIQUE(PedidoId, SequenciaItem) (boa quando integrações/APIs preferem um ID simples).

Exemplo 3: Endereço

Requisitos: “Cliente pode ter vários endereços; um endereço pode ser atualizado (correção de número, complemento).”

Evite chave natural baseada em campos do endereço (rua+número+CEP), pois muda e pode ter variações de escrita. Escolha típica:

• PK surrogate: EnderecoId
• FK: ClienteId
• Se precisar evitar duplicidade, use regra de negócio com normalização (ex.: hash/normalização) e UNIQUE auxiliar, mas não como PK.