Questão de Banco de Dados — SQL — INSTITUTO AOCP 2024

Integridade referencial e chaves estrangeiras em SQL

Gabarito: letra C. O comando correto é ALTER TABLE Funcionarios ADD CONSTRAINT FK_DepartamentoID FOREIGN KEY (DepartamentoID) REFERENCES Departamentos(ID) ON DELETE RESTRICT;, pois a chave estrangeira deve ser criada na tabela filha (Funcionarios), referenciando a chave primária da tabela pai (Departamentos), e a ação ON DELETE RESTRICT impede a exclusão de um departamento que possua funcionários associados. As demais alternativas erram na direção da referência, na tabela onde a constraint é aplicada ou na ação de exclusão.

A integridade referencial é um dos pilares do modelo relacional: ela garante que um valor de chave estrangeira em uma tabela (a "filha") sempre corresponda a um valor de chave primária existente na tabela referenciada (a "mãe"). No cenário descrito, Funcionarios.DepartamentoID é a chave estrangeira que aponta para Departamentos.ID. A relação é de 1:N — um departamento pode ter vários funcionários, mas cada funcionário pertence a um único departamento. A tabela que contém a chave estrangeira é a filha (Funcionarios), e a tabela referenciada é a mãe (Departamentos).

A regra de ouro para criar uma chave estrangeira é: a constraint é definida na tabela filha, na coluna que é a chave estrangeira, e faz referência à coluna de chave primária (ou única) da tabela mãe. A sintaxe é CONSTRAINT nome FOREIGN KEY (coluna_filha) REFERENCES tabela_mae (coluna_mae). No caso, a coluna DepartamentoID da tabela Funcionarios referencia a coluna ID da tabela Departamentos.

A ação ON DELETE define o que acontece com os registros da tabela filha quando um registro da tabela mãe é excluído. As opções são:

O requisito do enunciado é claro: "um departamento só possa ser deletado se não tiver nenhum funcionário associado". Isso corresponde exatamente à ação RESTRICT (ou NO ACTION), que bloqueia a exclusão quando existem registros dependentes. A ação CASCADE faria o oposto — excluiria os funcionários junto com o departamento — e SET NULL deixaria os funcionários órfãos com DepartamentoID nulo, o que também não atende ao requisito.

A pegadinha central desta questão é a direção da referência. Muitos candidatos, ao verem a necessidade de proteger a tabela Departamentos, tentam criar a constraint nela. Porém, a chave estrangeira pertence à tabela que contém a referência — Funcionarios — e é nela que a constraint deve ser adicionada. Criar a constraint em Departamentos referenciando Funcionarios inverteria o papel das tabelas e não teria o efeito desejado.

Guarde a fronteira entre tabela filha (onde a FK é criada) e tabela mãe (a referenciada), e entre as ações CASCADE, RESTRICT e SET NULL: é exatamente nesses dois eixos que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Esta alternativa erra na direção da referência. Ela tenta criar a constraint na tabela Departamentos (a tabela mãe), referenciando Funcionarios(DepartamentoID). Isso está invertido: a chave estrangeira deve ser criada na tabela filha (Funcionarios), na coluna DepartamentoID, referenciando a chave primária da tabela mãe (Departamentos.ID). Além disso, a ação ON DELETE CASCADE excluiria os departamentos e, em cascata, os funcionários — o oposto do que o enunciado pede.

Alternativa B — ❌ Incorreta

A direção da referência está correta (FK em Funcionarios referenciando Departamentos), mas a ação ON DELETE CASCADE está errada. Com CASCADE, ao excluir um departamento, todos os funcionários associados seriam excluídos automaticamente. O enunciado exige que a exclusão seja impedida quando houver funcionários, não que eles sejam deletados junto.

Alternativa C — ✅ Correta ⟵ GABARITO

Esta é a alternativa correta. A constraint é criada na tabela filha (Funcionarios), na coluna DepartamentoID, referenciando a chave primária da tabela mãe (Departamentos.ID). A ação ON DELETE RESTRICT impede a exclusão de um departamento que possua funcionários associados, exatamente como o enunciado exige. O comando tenta excluir um departamento com funcionários e o banco retorna um erro, mantendo a integridade referencial.

Alternativa D — ❌ Incorreta

Esta alternativa erra na direção da referência (constraint em Departamentos referenciando Funcionarios) e na ação (SET NULL). Mesmo que a direção estivesse correta, SET NULL definiria DepartamentoID como NULL nos funcionários do departamento excluído, o que não impede a exclusão — apenas deixa os registros órfãos com valor nulo.

Alternativa E — ❌ Incorreta

A direção da referência está correta (FK em Funcionarios referenciando Departamentos), mas a ação ON DELETE SET NULL está errada. Com SET NULL, ao excluir um departamento, o campo DepartamentoID dos funcionários associados seria definido como NULL, permitindo a exclusão. O enunciado exige que a exclusão seja bloqueada quando houver funcionários, o que só a ação RESTRICT (ou NO ACTION) faz.

Gabarito: letra C