Questão de Banco de Dados — Geral — FUNDATEC 2026

Chave primária e chave estrangeira em SQL

Gabarito: letra E. O script correto define PRIMARY KEY (id_depto) na tabela DEPARTAMENTO e, na tabela FUNCIONARIO, PRIMARY KEY (id_func) e FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto). A chave estrangeira em FUNCIONARIO referencia a chave primária de DEPARTAMENTO, estabelecendo o relacionamento entre as tabelas.

A questão exige o conhecimento de dois conceitos fundamentais do modelo relacional: chave primária (PRIMARY KEY) e chave estrangeira (FOREIGN KEY). A chave primária identifica de forma única cada registro de uma tabela, garantindo que não haja duplicidade e que o valor não seja nulo. A chave estrangeira, por sua vez, é uma coluna (ou conjunto de colunas) em uma tabela que referencia a chave primária de outra tabela, criando um vínculo entre os registros das duas tabelas. Esse vínculo é o que materializa os relacionamentos no banco de dados relacional.

No script apresentado, a tabela DEPARTAMENTO possui id_depto como identificador natural — é o campo que deve ser a chave primária. A tabela FUNCIONARIO possui id_func como identificador próprio e id_depto como campo que guarda a referência ao departamento do funcionário. Portanto, id_depto em FUNCIONARIO deve ser definido como chave estrangeira apontando para id_depto de DEPARTAMENTO. A sintaxe correta para isso, dentro do CREATE TABLE, é:

PRIMARY KEY (id_depto)

na tabela DEPARTAMENTO, e na tabela FUNCIONARIO:

PRIMARY KEY (id_func),
FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto)

A ordem das cláusulas dentro do CREATE TABLE não é rígida, mas a referência da chave estrangeira deve apontar para uma coluna que seja chave primária (ou que tenha restrição UNIQUE) na tabela referenciada. No caso, id_depto é a chave primária de DEPARTAMENTO, então a referência está correta.

Um erro comum é inverter os papéis: definir a chave estrangeira em DEPARTAMENTO apontando para FUNCIONARIO, ou referenciar a coluna errada (por exemplo, id_func em vez de id_depto). A banca explora exatamente essa confusão nas alternativas. Outro erro frequente é usar nome como chave primária, o que é inadequado porque nomes podem se repetir e não são identificadores estáveis.

Para fixar: a chave estrangeira sempre fica na tabela que representa o lado "muitos" do relacionamento (ou na tabela que contém a referência), e aponta para a chave primária da tabela "um". No relacionamento entre FUNCIONARIO e DEPARTAMENTO, um departamento pode ter vários funcionários, então a chave estrangeira id_depto fica em FUNCIONARIO.

Alternativa A — ❌ Incorreta

Define PRIMARY KEY (id_depto) corretamente em DEPARTAMENTO, mas em FUNCIONARIO coloca FOREIGN KEY (id_func) — o que está errado, pois id_func é a chave primária de FUNCIONARIO, não uma chave estrangeira. Além disso, a linha PRIMARY KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto) mistura duas cláusulas: a chave primária de FUNCIONARIO deveria ser id_func, e a referência estrangeira deveria ser FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto). A alternativa confunde os papéis das colunas.

Alternativa B — ❌ Incorreta

Inverte completamente os conceitos: define FOREIGN KEY (id_depto) em DEPARTAMENTO, quando id_depto é a chave primária dessa tabela. Em FUNCIONARIO, define PRIMARY KEY (id_func) (correto), mas a chave estrangeira FOREIGN KEY (id_func) REFERENCES DEPARTAMENTO(id_depto) referencia id_func — que é a chave primária de FUNCIONARIO — em vez de id_depto. A referência deveria ser FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto). A alternativa troca os papéis de chave primária e estrangeira.

Alternativa C — ❌ Incorreta

Define PRIMARY KEY (nome) em DEPARTAMENTO, o que é inadequado: nomes podem se repetir e não são identificadores únicos confiáveis. Em FUNCIONARIO, define PRIMARY KEY (id_func, id_depto) — uma chave composta desnecessária, pois id_func já é suficiente — e a chave estrangeira FOREIGN KEY (id_depto) REFERENCES FUNCIONARIO(id_func) referencia a tabela errada: deveria referenciar DEPARTAMENTO, não FUNCIONARIO. A alternativa erra tanto na escolha da chave primária quanto na referência da chave estrangeira.

Alternativa D — ❌ Incorreta

Define PRIMARY KEY (id_depto, nome) em DEPARTAMENTO — chave composta desnecessária, pois id_depto já identifica unicamente. Em FUNCIONARIO, define PRIMARY KEY (id_func) (correto), mas a chave estrangeira FOREIGN KEY (nome) REFERENCES DEPARTAMENTO(nome) referencia a coluna nome, que não é chave primária de DEPARTAMENTO (e nem deveria ser). A referência correta seria FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto). A alternativa usa a coluna errada na chave estrangeira.

Alternativa E — ✅ Correta ⟵ GABARITO

Define corretamente PRIMARY KEY (id_depto) em DEPARTAMENTO, e em FUNCIONARIO PRIMARY KEY (id_func) e FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto). A chave estrangeira id_depto em FUNCIONARIO referencia a chave primária id_depto de DEPARTAMENTO, estabelecendo o relacionamento correto entre as tabelas. É exatamente o que o script pede.

Gabarito: letra E