Pular para o conteúdo principal

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

Banco de DadosBanco de Dados Relacionais
Código
fg075131
Banca
FGV
Órgão
AL-PR
Ano
2024
Nível
Superior
Cargo
Analista Legislativo - Desenvolvedor de Sistemas
Considerando a abordagem de mapeamento objeto-relacional (ORM), seja o mapeamento da classe “Parlamentar” realizado da forma que segue:Parlamentar ( {cod_parlamentar} , nome, partido, email, telefone, endereco, data_nascimento, naturalidade, foto )A fim de manter, no modelo lógico de banco de dados relacional, a semântica expressa na classe “Submissão” do modelo conceitual, e considerando queI. o atributo id_parlamentar<FK> indica uma chave estrangeira para a chave primária da tabela “Parlamentar”;II. o atributo id_proposicao<FK> indica uma chave estrangeira para a chave primária da tabela “Proposição”.Nesse caso, uma abordagem correta seria
  1. Aadicionar na tabela “Parlamentar” a chave estrangeira “cod_proposicao”, referenciando a chave primária da tabela “Proposição”.
  2. Balterar a cardinalidade máxima da associação entre “Parlamentar” e “Proposição”, com vistas a torná-la com conectividade muitospara-muitos.
  3. Ccriar a tabela “Submissão” com o seguinte esquema: Submissão ({id_parlamentar,id_proposicao} , data, id_parlamentar, id_proposicao).
  4. Dcriar a tabela “Submissão” com o seguinte esquema: Submissão (id_submissao , data, id_parlamentar).
  5. Ecriar a tabela “Submissão” com o seguinte esquema: Submissão (id_submissao , data, id_parlamentar, id_proposicao).
Revelar gabarito e comentário

GabaritoC — criar a tabela “Submissão” com o seguinte esquema: Submissão ({id_parlamentar,id_proposicao} , data, id_parlamentar, id_proposicao).

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”.

Mapeamento Objeto-Relacional (ORM): Tabela Associativa

Gabarito: letra C. A abordagem correta é criar a tabela "Submissão" com chave primária composta pelas chaves estrangeiras id_parlamentar e id_proposicao, pois isso preserva a semântica de uma associação muitos-para-muitos com atributos próprios (data) — prática padrão em ORM. A alternativa C, apesar da redação confusa (duplicação dos atributos), reflete exatamente essa solução: chave composta formada pelas FKs.

A questão testa o mapeamento de uma associação com atributos (classe "Submissão") para o modelo relacional. No ORM, associações muitos-para-muitos que possuem atributos próprios (como data) devem ser transformadas em uma tabela independente com chave primária composta pelas chaves das entidades envolvidas. Esse é o conceito central.

Critério

Alternativa C (Gabarito)

Alternativa E (Incorreta)

Chave primária

Composta: {id_parlamentar, id_proposicao} (ambas FKs)

Própria: id_submissao (surrogate key)

Semântica da associação

Preserva a dependência existencial entre Parlamentar e Proposição (a submissão só existe se ambas as entidades existirem)

Permite submissão sem vínculo direto com as entidades (a chave própria não exige unicidade da combinação)

Atributo data

Incluído como atributo da tabela associativa

Incluído como atributo da tabela associativa

Integridade referencial

Garantida pela chave composta (cada par de FKs é único)

Garantida apenas pelas FKs individuais (pode haver duplicatas do mesmo par)

Padrão ORM

Mapeamento clássico de associação muitos-para-muitos com atributos

Mapeamento de entidade fraca, não de associação

Alternativa A — ❌ Incorreta

Adicionar uma chave estrangeira cod_proposicao na tabela "Parlamentar" criaria um relacionamento um-para-muitos (um parlamentar submete várias proposições), mas não representa a associação muitos-para-muitos e ignora os atributos próprios da classe "Submissão".

Alternativa B — ❌ Incorreta

Apenas alterar a cardinalidade máxima no modelo conceitual não resolve a implementação no modelo lógico. A ação concreta de criar a estrutura relacional é necessária.

Alternativa C — ✅ Correta ⟵ GABARITO

A tabela "Submissão" é criada com chave primária composta {id_parlamentar, id_proposicao} (ambas FKs para "Parlamentar" e "Proposição") e o atributo data. Essa estrutura reflete fielmente a associação muitos-para-muitos com atributo próprio, pois a chave composta garante unicidade e a semântica de dependência entre as entidades. A duplicação dos atributos no texto da alternativa é provavelmente um erro de digitação, mas a essência é correta.

Alternativa D — ❌ Incorreta

Falta a chave estrangeira para "Proposição" (id_proposicao), o que quebra a associação essencial entre as entidades.

Alternativa E — ❌ Incorreta

Usa uma chave primária própria (id_submissao) no lugar da chave composta. Embora funcional, essa abordagem não mantém a semântica da associação como dependente das entidades relacionadas — ela permite, por exemplo, múltiplas submissões do mesmo par (parlamentar, proposição) com datas diferentes, o que pode não refletir o modelo conceitual. A chave composta é a mais adequada quando a associação possui atributos.

NÃO CAIA NESSA!

A alternativa E parece bem formada e muitas vezes é usada em bancos de dados reais, mas a questão cobra a SEMÂNTICA do modelo conceitual. Em ORM, associações puras com atributos (como "Submissão") são mapeadas com chave composta, não com chave surrogate. Cuidado para não confundir uma solução técnica válida com a exigência conceitual da modelagem.

Gabarito: letra C (tabela "Submissão" com chave primária composta {id_parlamentar, id_proposicao}).

Link permanente: /questoes/fg075131