Questão de Banco de Dados — Conceitos e Fundamentos de Modelo Relacional — FGV 2024
Banco de Dados›Conceitos e Fundamentos de Modelo Relacional
Código
fg165224
Banca
FGV
Órgão
ALEP
Ano
2024
Cargo
Ana Leg ( )
Em uma Casa Legislativa, considere um cenário restrito, no qual parlamentares submetem proposições (propostas legislativas) para avaliação das instâncias do Parlamento.
O modelo de conceitual de classes a seguir modela tal situação:
Em um contexto no qual o modelo conceitual será mapeado segundo a abordagem Mapeamento Objeto-Relacional (ORM), e que a classe “Proposição” foi mapeada para um banco de dados relacional da seguinte forma:
Proposição ( {cod_proposicao} <PK>, identificacao, ementa, indexacao, tipo )
sendo o atributo “cod_proposicao” a chave primária da tabela (PK) e os demais atributos simples
Considerando a abordagem de mapeamento objeto-relacional (ORM), seja o mapeamento da classe “Parlamentar” realizado da forma que segue:
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 que
I. 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
Aadicionar na tabela “Parlamentar” a chave estrangeira “cod_proposicao”, referenciando a chave primária da tabela “Proposição”.
Balterar a cardinalidade máxima da associação entre “Parlamentar” e “Proposição”, com vistas a torná-la com conectividade muitos-para-muitos.
Ccriar a tabela “Submissão” com o seguinte esquema: Submissão ({id_parlamentar<FK>,id_proposicao<FK>} <PK>, data, id_parlamentar, id_proposicao).
Dcriar a tabela “Submissão” com o seguinte esquema: Submissão (id_submissao <PK>, data, id_parlamentar<FK>).
Ecriar a tabela “Submissão” com o seguinte esquema: Submissão (id_submissao <PK>, data, id_parlamentar<FK>, id_proposicao<FK>).
Revelar gabarito e comentário▾
GabaritoC — criar a tabela “Submissão” com o seguinte esquema: Submissão ({id_parlamentar<FK>,id_proposicao<FK>} <PK>, 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”.
Gabarito: letra C. A classe "Submissão" representa uma associação entre "Parlamentar" e "Proposição". Como um parlamentar pode submeter várias proposições e uma proposição pode ser submetida por vários parlamentares, trata-se de um relacionamento muitos-para-muitos (N:N). No modelo relacional, um relacionamento N:N é mapeado criando uma tabela associativa (ou tabela de ligação) cuja chave primária é composta pelas chaves estrangeiras que referenciam as tabelas participantes. A alternativa C é a única que cria essa tabela associativa com a chave primária composta corretamente.
O mapeamento objeto-relacional (ORM) é a técnica que traduz o modelo conceitual (classes, associações) para o modelo lógico relacional (tabelas, chaves). A regra de ouro é: a cardinalidade da associação determina onde a chave estrangeira (FK) será colocada. Em uma associação 1:N (um-para-muitos), a FK fica na tabela do lado "N" (muitos). Já em uma associação N:N (muitos-para-muitos), não é possível colocar a FK em apenas uma das tabelas sem gerar redundância ou violar a integridade — a solução é criar uma tabela associativa que registra cada par de ocorrências relacionadas.
No cenário da questão, a classe "Submissão" é a associação entre "Parlamentar" e "Proposição". A cardinalidade é N:N, pois um parlamentar pode submeter várias proposições e uma proposição pode ser submetida por vários parlamentares. Portanto, o mapeamento correto é criar a tabela "Submissão" com uma chave primária composta pelas chaves estrangeiras id_parlamentar e id_proposicao, além do atributo data (que é um atributo da associação).
A pegadinha da questão está em duas frentes: (1) confundir a cardinalidade da associação e tentar resolver com uma FK simples em uma das tabelas (alternativas A e D); (2) criar a tabela associativa com uma chave primária artificial id_submissao em vez da chave composta (alternativa E). A chave primária composta é essencial para garantir a unicidade do par (parlamentar, proposição) e refletir a semântica da associação N:N.
Guarde a regra: associação N:N → tabela associativa com PK composta pelas FKs. É exatamente esse critério que separa a alternativa correta das demais.
Critério
Alternativa C (Gabarito)
Alternativa E (Distrator)
Chave primária
Composta: {id_parlamentar, id_proposicao}
Artificial: id_submissao
Chaves estrangeiras
id_parlamentar e id_proposicao (ambas)
id_parlamentar e id_proposicao (ambas)
Garantia de unicidade do par (parlamentar, proposição)
Sim — a PK composta impede duplicidade
Não — permite submissões duplicadas do mesmo par
Fidelidade à semântica da associação N:N
Alta — reflete diretamente o par relacionado
Média — exige controle externo para evitar duplicatas
Forma canônica de mapeamento ORM para N:N
Sim — é a abordagem padrão
Não — é uma variação funcional, mas não canônica
Alternativa A — ❌ Incorreta
Adicionar a FK cod_proposicao na tabela "Parlamentar" representaria uma associação 1:N (um parlamentar teria várias proposições), mas a semântica da classe "Submissão" é N:N. Além disso, isso criaria redundância, pois uma proposição submetida por vários parlamentares exigiria repetir os dados do parlamentar em várias linhas, violando a integridade e a normalização.
Alternativa B — ❌ Incorreta
Alterar a cardinalidade máxima da associação para muitos-para-muitos não é uma ação de mapeamento — a cardinalidade é uma propriedade do modelo conceitual, definida pela regra de negócio. O mapeamento ORM deve respeitar a cardinalidade existente, não alterá-la. A solução correta é criar a tabela associativa, não mudar a semântica do relacionamento.
Alternativa C — ✅ Correta ⟵ GABARITO
Cria a tabela associativa "Submissão" com a chave primária composta {id_parlamentar, id_proposicao}, onde cada uma é uma FK referenciando as tabelas "Parlamentar" e "Proposição", respectivamente. O atributo data é um atributo da associação. Essa é a implementação canônica de um relacionamento N:N no modelo relacional.
Alternativa D — ❌ Incorreta
Cria a tabela "Submissão" com apenas uma FK (id_parlamentar), o que representaria uma associação 1:N entre "Submissão" e "Proposição" (cada submissão teria uma única proposição). Isso não reflete a cardinalidade N:N da classe "Submissão", pois uma proposição poderia ser submetida por vários parlamentares, exigindo múltiplas linhas na tabela "Submissão" com a mesma proposição — o que é possível, mas a ausência da FK id_proposicao impede registrar qual proposição foi submetida.
Alternativa E — ❌ Incorreta
Cria a tabela "Submissão" com uma chave primária artificial id_submissao e duas FKs. Embora funcione tecnicamente, não é a abordagem mais correta para mapear uma associação N:N. A chave primária composta pelas FKs é preferível porque: (1) garante a unicidade do par (parlamentar, proposição), evitando submissões duplicadas; (2) reflete diretamente a semântica da associação; (3) evita a necessidade de uma chave artificial desnecessária. A banca cobra a forma canônica de mapeamento.
Gabarito: letra C — a tabela associativa com chave primária composta pelas chaves estrangeiras é a abordagem correta para mapear a associação N:N da classe "Submissão".
