Questão de Banco de Dados — Banco de Dados Relacionais — CESPE / CEBRASPE 2026

Relacionamento recursivo em SQL: a chave estrangeira que aponta para a própria tabela

Gabarito: letra D. A última instrução (ALTER TABLE) cria uma relação recursiva válida, pois adiciona uma coluna fk_supervisor que referencia a chave primária da própria tabela auditor, permitindo que um auditor seja supervisor de outro. Esse é o padrão clássico de relacionamento hierárquico (auto-relacionamento) em bancos de dados relacionais, e o comando ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES é a forma correta de implementá-lo.

O cerne da questão está em reconhecer que uma tabela pode ter uma chave estrangeira que referencia a si mesma — o chamado relacionamento recursivo ou auto-relacionamento. Isso é perfeitamente válido no modelo relacional e no SQL padrão. A tabela auditor tem uma chave primária (provavelmente id), e a coluna fk_supervisor armazenará o id de outro auditor, criando uma hierarquia (ex.: um auditor sênior que supervisiona vários auditores júniores). O comando ALTER TABLE é usado justamente para modificar a estrutura de uma tabela existente, e adicionar uma restrição FOREIGN KEY é uma das operações mais comuns.

Para entender por que as outras alternativas estão erradas, é preciso dominar alguns conceitos de DDL:

1. CHECK: é uma restrição que valida valores em uma coluna com base em uma condição lógica (ex.: CHECK (salario > 0)). O SQL padrão permite expressões lógicas em restrições CHECK — a alternativa A afirma o contrário, o que é falso.

2. FOREIGN KEY: é uma restrição que garante a integridade referencial, ou seja, que um valor em uma coluna exista na coluna referenciada de outra tabela (ou da mesma tabela, no caso recursivo). A alternativa B sugere que a criação de auditor falharia porque id_ug não é chave primária em unidade_gestora — mas isso não é verdade, pois uma FOREIGN KEY pode referenciar qualquer coluna com uma restrição UNIQUE ou PRIMARY KEY na tabela referenciada.

3. ALTER TABLE: é o comando DDL usado para adicionar, modificar ou remover colunas e restrições em uma tabela existente. A alternativa C afirma que o ALTER TABLE criaria uma coluna chamada fk_supervisor para armazenar a chave de relacionamento hierárquico — isso está parcialmente correto, mas a alternativa D é mais completa e precisa, pois especifica que a relação é recursiva e válida.

4. CHECK e FOREIGN KEY simultâneos: não há nenhuma proibição no SQL padrão de definir restrições CHECK e FOREIGN KEY na mesma tabela. A alternativa E afirma o contrário, o que é falso.

A pegadinha da banca está em explorar o desconhecimento sobre relacionamentos recursivos e sobre a flexibilidade das restrições de integridade. Muitos candidatos podem achar que uma FOREIGN KEY só pode referenciar outra tabela, mas ela pode referenciar a própria tabela. Além disso, a alternativa C parece plausível, mas é incompleta — ela não menciona que a relação é recursiva, que é o ponto central da questão.

Guarde a distinção entre os comandos DDL e as restrições de integridade: CREATE TABLE define a estrutura inicial, ALTER TABLE modifica a estrutura existente, e as restrições CHECK, FOREIGN KEY, PRIMARY KEY e UNIQUE garantem a validade dos dados. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que a restrição CHECK não será aplicada porque o SQL padrão não permite expressões lógicas em restrições de coluna. Isso é falso: o SQL padrão permite expressões lógicas em restrições CHECK, como CHECK (salario > 0 AND salario < 10000). A restrição CHECK é usada justamente para limitar os valores que podem ser inseridos em uma coluna com base em uma condição lógica. A alternativa confunde a capacidade do SQL com uma limitação inexistente.

Alternativa B — ❌ Incorreta

Afirma que o comando de criação de auditor será rejeitado porque id_ug não é uma chave primária em unidade_gestora. Isso é falso: uma FOREIGN KEY pode referenciar qualquer coluna que tenha uma restrição UNIQUE ou PRIMARY KEY na tabela referenciada. Não é necessário que a coluna referenciada seja a chave primária — basta que seja única. Além disso, a criação da tabela auditor não depende de id_ug ser chave primária; a restrição FOREIGN KEY apenas exige que os valores em id_ug existam na coluna referenciada de unidade_gestora.

Alternativa C — ❌ Incorreta

Afirma que o ALTER TABLE criará uma nova coluna denominada fk_supervisor para armazenar a chave de relacionamento hierárquico entre auditores. Isso está parcialmente correto, mas incompleto: a coluna fk_supervisor é criada, mas a alternativa não menciona que a relação é recursiva (a chave estrangeira referencia a própria tabela auditor). A alternativa D é mais precisa, pois especifica que a relação é recursiva e válida. A alternativa C não está errada no que afirma, mas omite o aspecto mais importante — a recursividade.

Alternativa D — ✅ Correta ⟵ GABARITO

Afirma que a última instrução (ALTER TABLE) criará uma relação recursiva válida, permitindo que um auditor seja referenciado como supervisor de outro auditor. Isso está correto: a coluna fk_supervisor é adicionada à tabela auditor e referencia a chave primária da própria tabela, criando um auto-relacionamento. Esse é o padrão para modelar hierarquias (ex.: um auditor sênior que supervisiona vários auditores júniores). O comando ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES auditor(id) é válido e cria a relação recursiva.

Alternativa E — ❌ Incorreta

Afirma que a criação da tabela auditor falhará porque não é permitido definir restrições CHECK e FOREIGN KEY simultaneamente em uma mesma tabela. Isso é falso: o SQL padrão permite definir múltiplas restrições em uma tabela, incluindo CHECK e FOREIGN KEY ao mesmo tempo. Não há nenhuma proibição nesse sentido. A alternativa confunde a capacidade do SQL com uma limitação inexistente.

Gabarito: letra D