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

Chave Primária e Chave Estrangeira em SQL

Gabarito: letra E. O script correto define id_depto como chave primária da tabela DEPARTAMENTO e id_func como chave primária de FUNCIONARIO, com id_depto como chave estrangeira em FUNCIONARIO referenciando DEPARTAMENTO(id_depto) — é a modelagem que reflete o relacionamento 1:N entre departamento e funcionário, onde a FK fica no lado N (funcionário) e aponta para a PK do lado 1 (departamento).

A chave primária (primary key) é o identificador único de cada registro em uma tabela: garante que não existam duas linhas com o mesmo valor naquele campo (ou combinação de campos) e que o valor nunca seja nulo. Já a chave estrangeira (foreign key) é o mecanismo que implementa o relacionamento entre duas tabelas: um campo (ou conjunto de campos) em uma tabela que referencia a chave primária de outra tabela, garantindo a integridade referencial — ou seja, só podem ser inseridos valores que existam na tabela referenciada.

No relacionamento entre DEPARTAMENTO e FUNCIONARIO, a cardinalidade é 1:N: um departamento pode ter vários funcionários, mas cada funcionário pertence a um único departamento. A regra de ouro da modelagem relacional é que a chave estrangeira fica sempre no lado N (muitos) do relacionamento. Assim, FUNCIONARIO deve conter a coluna id_depto como chave estrangeira, referenciando a chave primária id_depto da tabela DEPARTAMENTO. Cada tabela tem sua própria chave primária: id_depto em DEPARTAMENTO e id_func em FUNCIONARIO.

A sintaxe SQL para definir essas restrições na criação das tabelas é: PRIMARY KEY (coluna) dentro da definição da própria tabela, e FOREIGN KEY (coluna) REFERENCES tabela_referenciada (coluna_referenciada) — a FK deve apontar exatamente para a coluna que é chave primária (ou candidata) na tabela referenciada. É esse par PK/FK que permite a ligação lógica entre as tabelas e a recuperação de dados por meio de JOINs.

A pegadinha central desta questão é a direção da referência: a chave estrangeira em FUNCIONARIO deve apontar PARA DEPARTAMENTO (a tabela referenciada), nunca o contrário. As alternativas que invertem essa direção — fazendo a FK de DEPARTAMENTO apontar para FUNCIONARIO, ou referenciando colunas que não são chave primária — violam o conceito de integridade referencial. Guarde o par: tabela referenciadora (contém a FK) × tabela referenciada (contém a PK referenciada). É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Define corretamente a PK de DEPARTAMENTO (id_depto), mas erra ao declarar PRIMARY KEY (id_depto) dentro de FUNCIONARIO como se fosse a FK — além de usar FOREIGN KEY (id_func) sem referenciar a tabela correta. A FK em FUNCIONARIO deveria ser id_depto, não id_func, e a referência deveria apontar para DEPARTAMENTO(id_depto). Há também erro de sintaxe: a cláusula REFERENCES deve acompanhar a FOREIGN KEY, não a PRIMARY KEY.

Alternativa B — ❌ Incorreta

Inverte completamente a lógica: declara FOREIGN KEY (id_depto) na tabela DEPARTAMENTO (que deveria ter apenas a PK) e, em FUNCIONARIO, define FOREIGN KEY (id_func) REFERENCES DEPARTAMENTO(id_depto) — referenciando a coluna id_func (que é a PK de FUNCIONARIO) como se fosse FK para DEPARTAMENTO. A FK deve estar em FUNCIONARIO apontando para DEPARTAMENTO(id_depto), e id_func é a PK de FUNCIONARIO, não uma FK. A direção da referência está totalmente invertida.

Alternativa C — ❌ Incorreta

Erra ao definir PRIMARY KEY (nome) em DEPARTAMENTO — o atributo nome não é o identificador natural adequado (pode haver homônimos e não é a chave escolhida no script). Em FUNCIONARIO, define uma PK composta (id_func, id_depto) desnecessariamente e, pior, a FK referencia FUNCIONARIO(id_func) — uma tabela referenciando a si mesma, quando deveria referenciar DEPARTAMENTO(id_depto). A FK deve apontar para a tabela DEPARTAMENTO, não para FUNCIONARIO.

Alternativa D — ❌ Incorreta

Define PRIMARY KEY (id_depto, nome) em DEPARTAMENTO — uma PK composta desnecessária, pois id_depto já identifica unicamente cada departamento. Em FUNCIONARIO, a FK referencia DEPARTAMENTO(nome) — mas nome não é chave primária (nem candidata) de DEPARTAMENTO, violando a regra de que a FK deve referenciar uma PK ou chave candidata. A referência correta é DEPARTAMENTO(id_depto).

Alternativa E — ✅ Correta ⟵ GABARITO

Esta é a modelagem correta: DEPARTAMENTO tem PRIMARY KEY (id_depto) — cada departamento é identificado unicamente pelo seu id. FUNCIONARIO tem PRIMARY KEY (id_func) — cada funcionário é identificado unicamente pelo seu id — e FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTO(id_depto) — a FK em FUNCIONARIO aponta para a PK de DEPARTAMENTO, implementando o relacionamento 1:N (um departamento para muitos funcionários). A direção da referência está correta: a tabela referenciadora (FUNCIONARIO) contém a FK que aponta para a tabela referenciada (DEPARTAMENTO).

Gabarito: letra E