João está encarregado de criar uma tabela em PostgreSQL para gerenciar informações sobre funcionários e seus supervisores, com base na seguinte representação lógica da entidade “Funcionario”:
Para tanto, João deverá criar o “autorrelacionamento” entre funcionários e seus supervisores, considerando que nem todo funcionário possui supervisor.
Para isso, João deverá utilizar o seguinte script SQL:
ACREATE TABLE Funcionario ( idFuncionario SERIAL PRIMARY KEY, nome VARCHAR (100) NOT NULL, cargo VARCHAR (100), idSupervisor INT, FOREIGN KEY (idSupervisor) REFERENCES Funcionario (idFuncionario));
BCREATE TABLE Funcionario ( idFuncionario SERIAL PRIMARY KEY, nome VARCHAR (100) NOT NULL, cargo VARCHAR (100), idSupervisor INT, FOREIGN KEY (idFuncionario) REFERENCES Funcionario (idSupervisor));
CCREATE TABLE Funcionario ( idFuncionario SERIAL PRIMARY KEY, nome VARCHAR (100) NOT NULL, cargo VARCHAR (100), idSupervisor SERIAL, FOREIGN KEY (idSupervisor) REFERENCES Funcionario (idFuncionario));
DCREATE TABLE Funcionario ( idFuncionario SERIAL PRIMARY KEY, nome VARCHAR (100) NOT NULL, cargo VARCHAR (100), idSupervisor SERIAL, FOREIGN KEY (idFuncionario) REFERENCES Funcionario (idSupervisor));
ECREATE TABLE Funcionario ( idFuncionario SERIAL PRIMARY KEY, nome VARCHAR (100) NOT NULL, cargo VARCHAR (100), idSupervisor INT NOT NULL, FOREIGN KEY (idSupervisor) REFERENCES Funcionario (idFuncionario));
Revelar gabarito e comentário▾
GabaritoA — CREATE TABLE Funcionario (
idFuncionario SERIAL PRIMARY KEY,
nome VARCHAR (100) NOT NULL,
cargo VARCHAR (100),
idSupervisor INT,
FOREIGN KEY (idSupervisor) REFERENCES Funcionario
(idFuncionario));
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Autorrelacionamento em PostgreSQL: Chave Estrangeira Referenciando a Própria Tabela
Gabarito: letra A. O script correto cria a coluna idSupervisor INT (sem NOT NULL, pois nem todo funcionário tem supervisor) e define a FOREIGN KEY (idSupervisor) REFERENCES Funcionario(idFuncionario) — ou seja, a chave estrangeira aponta para a chave primária da mesma tabela, caracterizando o autorrelacionamento. As demais alternativas erram ao inverter a ordem da referência (B e D), usar SERIAL na coluna estrangeira (C e D) ou tornar o campo obrigatório com NOT NULL (E).
O autorrelacionamento (ou auto-relacionamento) é um conceito fundamental em modelagem de dados: ocorre quando uma entidade se relaciona consigo mesma. No modelo relacional, isso se traduz em uma tabela que possui uma chave estrangeira referenciando sua própria chave primária. No caso do enunciado, cada funcionário pode ter um supervisor, e esse supervisor também é um funcionário — logo, a coluna idSupervisor da tabela Funcionario deve referenciar a coluna idFuncionario da mesma tabela.
A sintaxe para criar essa restrição no PostgreSQL é direta: dentro do CREATE TABLE, declara-se a coluna que será a chave estrangeira e, em seguida, a cláusula FOREIGN KEY (coluna_filha) REFERENCES tabela_pai (coluna_pai). Como a tabela pai e a tabela filha são a mesma, a referência é REFERENCES Funcionario (idFuncionario). É crucial que a coluna referenciada seja a chave primária (ou uma coluna com restrição UNIQUE) da tabela — aqui, idFuncionario.
Outro ponto essencial é a opcionalidade do relacionamento. O enunciado afirma que "nem todo funcionário possui supervisor". Isso significa que a coluna idSupervisor deve aceitar valores nulos (NULL), pois um funcionário sem supervisor terá esse campo vazio. Portanto, a coluna não pode ter a restrição NOT NULL. Além disso, o tipo de dado deve ser INT (inteiro), compatível com o tipo SERIAL da chave primária — usar SERIAL na coluna estrangeira seria um erro conceitual, pois SERIAL é um tipo que gera valores automáticos, o que não faz sentido para uma chave estrangeira que deve armazenar valores já existentes na tabela.
A pegadinha central desta questão está na ordem dos argumentos da cláusula FOREIGN KEY. A sintaxe correta é FOREIGN KEY (coluna_na_tabela_atual) REFERENCES tabela_referenciada (coluna_referenciada). As alternativas B e D invertem essa ordem, escrevendo FOREIGN KEY (idFuncionario) REFERENCES Funcionario (idSupervisor), o que criaria uma referência incorreta — a chave primária apontando para a coluna de supervisor, o que não representa o relacionamento desejado e, na prática, nem seria permitido sem que idSupervisor tivesse uma restrição UNIQUE.
Guarde o critério decisivo: a coluna que recebe a referência (a chave estrangeira) é a que fica entre parênteses após FOREIGN KEY; a coluna referenciada (a chave primária da tabela pai) é a que fica entre parênteses após REFERENCES. É exatamente nessa ordem que as alternativas se dividem.
Esta é a implementação correta do autorrelacionamento. A coluna idSupervisor é declarada como INT (sem NOT NULL, permitindo que funcionários sem supervisor tenham valor nulo) e a FOREIGN KEY (idSupervisor) referencia Funcionario(idFuncionario), ou seja, a chave primária da própria tabela. A ordem está correta: a coluna local (idSupervisor) vem primeiro, e a coluna referenciada (idFuncionario) vem depois do REFERENCES.
Alternativa B — ❌ Incorreta
O erro está na inversão da ordem da referência. A cláusula FOREIGN KEY (idFuncionario) REFERENCES Funcionario (idSupervisor) faz com que a chave primária idFuncionario seja tratada como chave estrangeira apontando para idSupervisor. Isso não representa o autorrelacionamento desejado — na verdade, criaria uma dependência circular incorreta, pois idSupervisor não é uma chave única (não tem restrição UNIQUE), e a semântica do relacionamento (funcionário → supervisor) se perde.
Alternativa C — ❌ Incorreta
O erro está no uso de SERIAL para a coluna idSupervisor. SERIAL é um tipo que gera automaticamente valores sequenciais, próprio para chaves primárias. Uma chave estrangeira deve armazenar valores que já existem na tabela referenciada — não deve gerar novos valores. Além disso, a coluna idSupervisor deveria ser INT (ou tipo compatível com idFuncionario), não SERIAL. A ordem da FOREIGN KEY está correta, mas o tipo de dado invalida a alternativa.
Alternativa D — ❌ Incorreta
Acumula dois erros: (1) usa SERIAL na coluna idSupervisor, o que é inadequado para uma chave estrangeira, como explicado na alternativa C; e (2) inverte a ordem da referência, escrevendo FOREIGN KEY (idFuncionario) REFERENCES Funcionario (idSupervisor), o mesmo erro da alternativa B. Nenhum dos dois problemas isolados tornaria a alternativa correta; juntos, ela está claramente errada.
Alternativa E — ❌ Incorreta
O erro está na restrição NOT NULL aplicada à coluna idSupervisor. O enunciado afirma explicitamente que "nem todo funcionário possui supervisor", o que significa que a coluna deve aceitar valores nulos. Ao declarar idSupervisor INT NOT NULL, a alternativa impede que um funcionário seja cadastrado sem supervisor, contrariando o requisito do problema. A ordem da FOREIGN KEY está correta, mas a restrição de nulidade invalida a alternativa.
NÃO CAIA NESSA!
A banca explora a confusão entre a ordem dos argumentos da FOREIGN KEY e o tipo de dado da coluna estrangeira. O candidato apressado pode marcar a alternativa B ou D por ver a referência à própria tabela, sem notar que a coluna local e a coluna referenciada estão invertidas. Outra armadilha é o uso de SERIAL na coluna estrangeira (C e D), que parece plausível por ser um tipo "de id", mas é semanticamente errado. E a alternativa E tenta o candidato com a restrição NOT NULL, que parece "mais segura", mas contraria o requisito de opcionalidade. Com atenção à sintaxe e à semântica, essas trocas ficam evidentes.
PEGA ESSA DICA!
Para resolver questões de autorrelacionamento, siga este roteiro mental: (1) identifique a coluna que representa o relacionamento (a chave estrangeira) — ela deve ser do mesmo tipo da chave primária, mas nãoSERIAL; (2) verifique se a coluna deve aceitar NULL (se o relacionamento é opcional, não use NOT NULL); (3) confira a ordem: FOREIGN KEY (coluna_local) REFERENCES tabela (coluna_referenciada). Aplicando esses três passos, a alternativa correta se destaca naturalmente.
