Um analista necessita projetar um banco de dados relacional para armazenar registros referentes a colaboradores de um órgão público. Para tal projeto, o analista especificou três entidades em seu modelo relacional: PESSOA, CARGO e PROJETO. A entidade PESSOA representa pessoas físicas. Por sua vez, CARGO representa um cargo no órgão, tal que este cargo pode ser atribuído a uma ou mais pessoas físicas. E PROJETO é a representação de um projeto do órgão o qual pode estar associado a uma ou mais pessoas físicas. Podem existir casos em que pessoas físicas não estão associadas a projeto. No entanto, pessoas físicas precisam estar associadas a um único cargo. Este analista necessita avançar seu projeto de banco de dados para o modelo lógico. Dado o modelo conceitual elucubrado, a representação textual do modelo lógico condizente com o escopo apresentado é
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”.
Modelagem de dados: do conceitual ao lógico relacional
Gabarito: letra E. A representação textual do modelo lógico deve refletir as cardinalidades do enunciado: PESSOA tem relação 1:N com CARGO (cada pessoa pertence a um único cargo, mas um cargo pode ter várias pessoas) e relação N:N com PROJETO (uma pessoa pode estar em vários projetos e um projeto pode ter várias pessoas), o que exige uma tabela associativa PESSOA_PROJETO. A alternativa E é a única que coloca a chave estrangeira id_pessoa em CARGO (lado N da relação 1:N) e cria a tabela de ligação PESSOA_PROJETO para o relacionamento muitos-para-muitos.
O modelo conceitual descreve entidades e relacionamentos de forma independente de qualquer SGBD. Ao avançar para o modelo lógico relacional, cada entidade vira uma tabela, e os relacionamentos são implementados por chaves estrangeiras. A cardinalidade é o que decide onde a chave estrangeira deve ficar:
Relação 1:N (um para muitos): a chave estrangeira fica na tabela do lado N (o lado "muitos"). No caso, PESSOA é o lado N de CARGO (cada pessoa tem um cargo; um cargo pode ter várias pessoas), então id_cargo deve ser chave estrangeira em PESSOA.
Relação N:N (muitos para muitos): é necessário criar uma tabela associativa (também chamada de tabela de ligação, junção ou relacionamento), que contém as chaves estrangeiras das duas entidades participantes. No caso, PESSOA e PROJETO têm relação N:N, então é preciso criar PESSOA_PROJETO com id_pessoa e id_projeto como chaves estrangeiras.
A alternativa E é a única que atende a esses dois requisitos: id_cargo como FK em PESSOA e a tabela PESSOA_PROJETO. As demais alternativas erram ao colocar a FK no lugar errado, omitir a tabela associativa ou usar chaves incorretas.
NÃO CAIA NESSA!
A banca explora a confusão entre relação 1:N e N:N. Em uma relação 1:N, a chave estrangeira fica na tabela do lado "muitos" (PESSOA recebe id_cargo). Em uma relação N:N, é obrigatória uma tabela associativa. A alternativa D, por exemplo, cria a tabela associativa, mas erra ao colocar id_cargo como FK em PESSOA — na verdade, id_cargo deveria estar em PESSOA, e não em CARGO. A alternativa E acerta nos dois pontos.
Critério
Alternativa A
Alternativa B
Alternativa C
Alternativa D
Alternativa E
FK da relação 1:N (CARGO → PESSOA)
id_cargo em PESSOA (correto)
Nenhuma FK (incorreto)
id_cargo em PESSOA (correto)
id_cargo em PESSOA (correto)
id_cargo em PESSOA (correto)
Tabela associativa para N:N (PESSOA ↔ PROJETO)
Não (incorreto)
Não (incorreto)
Não (incorreto)
Sim (correto)
Sim (correto)
FK da relação N:N (PESSOA ↔ PROJETO)
id_projeto em PESSOA (incorreto)
Nenhuma (incorreto)
id_pessoa em PROJETO (incorreto)
id_pessoa e id_projeto em PESSOA_PROJETO (correto)
id_pessoa e id_projeto em PESSOA_PROJETO (correto)
Chave primária de PESSOA
id_pessoa (correto)
id_cliente (incorreto)
id_pessoa (correto)
id_pessoa (correto)
id_pessoa (correto)
Resultado
❌ Incorreta
❌ Incorreta
❌ Incorreta
❌ Incorreta
✅ Gabarito
Alternativa A — ❌ Incorreta
Coloca id_cargo e id_projeto como chaves estrangeiras em PESSOA. Isso representaria duas relações 1:N (PESSOA para CARGO e PESSOA para PROJETO), mas a relação entre PESSOA e PROJETO é N:N. Além disso, colocar id_projeto em PESSOA limitaria cada pessoa a um único projeto, contrariando o enunciado.
Alternativa B — ❌ Incorreta
Não há nenhuma chave estrangeira, ou seja, não há representação dos relacionamentos. Além disso, usa id_cliente como chave primária de PESSOA, o que não condiz com o contexto (não se trata de clientes).
Alternativa C — ❌ Incorreta
Coloca id_cargo como FK em PESSOA (correto para a relação 1:N), mas coloca id_pessoa como FK em PROJETO, o que representaria uma relação 1:N entre PROJETO e PESSOA (cada projeto teria uma única pessoa responsável), contrariando a relação N:N. Falta a tabela associativa.
Alternativa D — ❌ Incorreta
Cria a tabela associativa PESSOA_PROJETO (correto para a relação N:N), mas coloca id_cargo como FK em PESSOA — na verdade, id_cargo deveria estar em PESSOA, e não em CARGO. A relação 1:N entre CARGO e PESSOA exige que a FK fique na tabela PESSOA (lado N), não em CARGO.
Alternativa E — ✅ Correta ⟵ GABARITO
Representa corretamente as duas relações: id_cargo como FK em PESSOA (relação 1:N com CARGO) e a tabela associativa PESSOA_PROJETO com id_pessoa e id_projeto como FKs (relação N:N com PROJETO). A chave primária de PESSOA é id_pessoa, e a tabela associativa tem chave composta pelas duas FKs.