Resumo TI Banco de Dados: Restrições de Chave e Unicidade

O resumo anterior tratou de integridade de entidade e integridade referencial — as duas regras que mantêm o banco consistente ao longo do tempo. Ambas dependem de um conceito que até agora foi usado sem formalizar: chave. Você já viu essa distinção na modelagem conceitual (chaves candidatas e chave primária de uma entidade) — agora ela ganha o vocabulário formal do modelo relacional (tuplas e relações) e, principalmente, sua tradução direta em SQL. Chegou a hora de fechar esse vocabulário — e é aqui que mora uma das confusões mais cobradas em prova: a diferença entre superchave, chave candidata, chave primária e chave alternativa, além da distinção prática entre a restrição PRIMARY KEY e a restrição UNIQUE.

Neste resumo, você vai entender por que toda chave candidata é uma superchave, mas nem toda superchave é uma chave candidata, o que faz uma chave ser “mínima”, e as diferenças reais entre PRIMARY KEY e UNIQUE — que vão muito além de “os dois garantem que o valor não se repete”.

🗝️ Superchave

Uma superchave é qualquer conjunto de atributos que, tomado como um todo, identifica unicamente cada tupla de uma relação. É a definição mais permissiva de “chave”: não exige que o conjunto seja o menor possível, só que funcione. Por isso, o conjunto de todos os atributos da relação é sempre uma superchave (trivialmente — como uma relação é, por definição, um conjunto de tuplas, ela nunca contém duas tuplas exatamente iguais; logo, o conjunto de todos os atributos sempre garante, por si só, a unicidade de cada tupla), mesmo carregando atributos redundantes que não contribuem em nada para a identificação.

🎯 Chave candidata

Uma chave candidata é uma superchave mínima: nenhum subconjunto próprio dela também é superchave. Em outras palavras, remover qualquer atributo da chave candidata quebra a unicidade — todo atributo ali é necessário, nenhum é redundante. Consequência direta: toda chave candidata é uma superchave, mas nem toda superchave é uma chave candidata — só as que não têm nenhum atributo dispensável ganham esse nome. Uma relação pode ter mais de uma chave candidata (ex.: CPF e matrícula, ambos identificando unicamente um Funcionário) — cada uma é, isoladamente, suficiente para identificar a tupla.

🔑 Chave primária e chave alternativa

Quando existe mais de uma chave candidata, o projetista escolhe uma delas para ser a chave primária (a identificadora oficial da relação, usada por padrão em referências de chave estrangeira). As demais chaves candidatas que não foram escolhidas continuam existindo como chaves alternativas (ou secundárias) — continuam garantindo unicidade, só não são a referência primária da relação.

⚖️ PRIMARY KEY x UNIQUE

Na prática do SQL, ambas as restrições impõem unicidade sobre o(s) atributo(s) que cobrem, mas não são intercambiáveis:

• Cardinalidade por tabela: uma tabela só pode ter uma PRIMARY KEY (simples ou composta), mas pode ter várias restrições UNIQUE — uma para cada chave alternativa que se queira proteger;
• Aceitação de NULL: PRIMARY KEY nunca aceita NULL, em nenhum de seus atributos componentes (é a integridade de entidade, vista no resumo anterior, sendo aplicada). Já uma coluna com UNIQUE pode aceitar NULL — e, no PostgreSQL, MySQL e Oracle, mais de um NULL na mesma coluna UNIQUE é permitido, porque esses SGBDs seguem o padrão ANSI SQL de tratar NULL como não igual a NULL para fins de unicidade. O SQL Server é a exceção clássica: por padrão, trata NULL como valor comparável nessa restrição, então só aceita um único NULL por coluna UNIQUE;
• Papel referencial: por convenção, é a PRIMARY KEY que chaves estrangeiras de outras relações apontam por padrão, mas uma FK também pode referenciar uma coluna com UNIQUE — o requisito de integridade referencial é que o atributo referenciado tenha alguma garantia de unicidade, não necessariamente que seja a PK.

⚠️ Pegadinhas comuns

• “Chave” sozinha, sem qualificação, costuma significar chave candidata ou primária — mas a superchave também é tecnicamente uma chave; a banca explora exatamente essa imprecisão de linguagem;
• Minimalidade é sobre a chave candidata, não sobre a chave primária escolhida: a chave primária é minimal porque foi escolhida entre as chaves candidatas, que já são minimais por definição;
• Múltiplos NULLs em coluna UNIQUE não violam a restrição no PostgreSQL, MySQL e Oracle — mas violam no SQL Server, que só aceita um único NULL por coluna UNIQUE; é uma pegadinha clássica de prova assumir o mesmo comportamento para todo SGBD;
• Uma tabela sem PK declarada ainda pode ter chaves candidatas — a ausência de PRIMARY KEY na definição do esquema não significa ausência de chave candidata na teoria, só que nenhuma foi formalmente escolhida como principal no SGBD.

🎯 Dica Final para a Prova

Monte a hierarquia mentalmente antes de responder: superchave (identifica, pode ter redundância) ⊃ chave candidata (superchave mínima, sem redundância) ⊃ chave primária (uma chave candidata escolhida). Toda chave primária é candidata, toda candidata é superchave — a implicação não vale ao contrário. E sempre que a questão comparar PK com UNIQUE, o primeiro ponto a checar é a aceitação de NULL: é o critério mais objetivo e mais cobrado dos dois.

✓ Agora que você domina os tipos de chave e a diferença entre PRIMARY KEY e UNIQUE, o próximo passo é sair do vocabulário estrutural e entrar na manipulação de dados propriamente dita: os operadores da álgebra relacional, começando por seleção e projeção.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Operadores da Álgebra Relacional – Seleção e Projeção

📘 Superchave, chave candidata, chave primária: cada uma é um subconjunto mais restrito da anterior — decorar essa hierarquia de contenção resolve a maioria das questões de múltipla escolha sobre o tema. Continue estudando!