Questão de Banco de Dados — PostgreSQL — FGV 2024

Autorrelacionamento e chave estrangeira no PostgreSQL

Gabarito: letra A. O autorrelacionamento é implementado com uma coluna que referencia a própria tabela: idSupervisor INT armazena o idFuncionario do supervisor, e a FOREIGN KEY (idSupervisor) REFERENCES Funcionario (idFuncionario) garante a integridade referencial. Como nem todo funcionário tem supervisor, a coluna deve aceitar NULL (padrão quando não se usa NOT NULL), exatamente como na alternativa A.

O autorrelacionamento (ou relacionamento recursivo) ocorre quando uma entidade se relaciona consigo mesma. No modelo relacional, isso se traduz em uma tabela que possui uma chave estrangeira apontando para a sua própria chave primária. No caso, cada funcionário pode ter um supervisor, que também é um funcionário — logo, o campo idSupervisor da tabela Funcionario referencia a coluna idFuncionario da mesma tabela.

A sintaxe da FOREIGN KEY no PostgreSQL segue o padrão SQL: FOREIGN KEY (coluna_local) REFERENCES tabela_referenciada (coluna_referenciada). A coluna local é aquela que armazena o valor da chave estrangeira (no caso, idSupervisor), e a coluna referenciada é a chave primária da tabela alvo (no caso, idFuncionario). Inverter esses dois elementos — como fazem as alternativas B e D — quebra o relacionamento, pois a coluna idFuncionario (chave primária) passaria a referenciar idSupervisor, o que não faz sentido lógico.

Outro ponto crucial é a nulabilidade. O enunciado afirma que "nem todo funcionário possui supervisor". Isso significa que o campo idSupervisor deve aceitar valores nulos para funcionários que não têm supervisor. No SQL, uma coluna aceita NULL por padrão, a menos que seja declarada com NOT NULL. Portanto, declarar idSupervisor INT (sem NOT NULL) já atende ao requisito. A alternativa E, ao usar idSupervisor INT NOT NULL, obrigaria todo funcionário a ter um supervisor, contrariando o enunciado.

Por fim, o tipo de dado SERIAL (usado nas alternativas C e D) é um atalho para criar uma coluna de autoincremento, tipicamente usada em chaves primárias. Usá-lo em idSupervisor é inadequado, pois o valor do supervisor não deve ser gerado automaticamente — ele deve ser preenchido com o idFuncionario de outro registro existente. Além disso, SERIAL implica NOT NULL, o que também violaria a regra de que nem todo funcionário tem supervisor.

Guarde a estrutura correta do autorrelacionamento: coluna local (que guarda a referência) → FOREIGN KEY → coluna referenciada (chave primária da mesma tabela), com a coluna local permitindo NULL quando o relacionamento é opcional. É exatamente esse padrão que separa a alternativa correta das demais.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta é a implementação correta do autorrelacionamento. A coluna idSupervisor INT armazena o identificador do supervisor, e a FOREIGN KEY (idSupervisor) REFERENCES Funcionario (idFuncionario) garante que o valor inserido em idSupervisor exista como idFuncionario em algum registro da própria tabela. Como a coluna não é declarada com NOT NULL, ela aceita valores nulos, permitindo que funcionários sem supervisor sejam cadastrados — exatamente o que o enunciado pede.

Alternativa B — ❌ Incorreta

Aqui a FOREIGN KEY está invertida: FOREIGN KEY (idFuncionario) REFERENCES Funcionario (idSupervisor). Isso faria a chave primária idFuncionario referenciar a coluna idSupervisor, o que é logicamente incorreto — a chave primária não deve depender de outra coluna da mesma tabela, e idSupervisor não é uma chave única. O relacionamento correto exige que a coluna local (que guarda a referência) seja idSupervisor e a coluna referenciada seja idFuncionario.

Alternativa C — ❌ Incorreta

O erro está no tipo SERIAL para idSupervisor. SERIAL é um atalho para autoincremento, usado em chaves primárias, e implica NOT NULL. Isso significa que todo funcionário seria obrigado a ter um supervisor, contrariando o enunciado. Além disso, o valor do supervisor não deve ser gerado automaticamente — ele deve ser informado manualmente com o idFuncionario de outro registro.

Alternativa D — ❌ Incorreta

Esta alternativa combina dois erros: o tipo SERIAL em idSupervisor (que força NOT NULL e autoincremento) e a inversão da FOREIGN KEY (FOREIGN KEY (idFuncionario) REFERENCES Funcionario (idSupervisor)). Ambos os problemas tornam o script inválido para o autorrelacionamento descrito.

Alternativa E — ❌ Incorreta

O único erro aqui é o NOT NULL em idSupervisor INT NOT NULL. Como o enunciado afirma que "nem todo funcionário possui supervisor", a coluna deve aceitar NULL. Com NOT NULL, seria impossível cadastrar um funcionário sem supervisor, violando a regra de negócio. A estrutura da FOREIGN KEY está correta, mas a restrição de nulidade invalida a alternativa.

Gabarito: letra A