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
fg075132
Banca
FGV
Órgão
AL-PR
Ano
2024
Nível
Superior
Cargo
Analista Legislativo - Desenvolvedor de Sistemas

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:




Imagem da questã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, nas relações apresentadas, os atributos indicados como chaves primárias ou estrangeiras entre chaves, assinale a opção que representa um mapeamento ORM possível para as classes “Tramitação” e “Despacho”, mantendo-se a completa semântica do modelo conceitual.
  1. ATramitação ( {cod_tramitacao} <PK>, forma, regime )Despacho ( {cod_despacho} <PK>, data, andamento )
  2. BTramitação ( {cod_tramitacao} <PK>, forma, regime )Despacho ( { cod_tramitacao <FK>, cod_despacho} <PK>, data, andamento )- Restrição da tabela Despacho: cod_tramitacao REFERENCIA Tramitação(cod_tramitacao)
  3. CTramitação ( {cod_tramitacao, cod_despacho <FK> } <PK>, forma, regime )Despacho ( {cod_despacho} <PK>, data, andamento )- Restrição da tabela Tramitação: cod_despacho REFERENCIA Despacho(cod_despacho)
  4. DTramitação ( {cod_proposicao<FK>, cod_tramitacao} <PK>, forma, regime )Despacho ( { {cod_proposicao, cod_tramitacao} <FK>, cod_despacho} <PK>, data, andamento )- Restrição da tabela Tramitação: cod_proposicao REFERENCIA Proposição(cod_proposicao)- Restrição da tabela Despacho: {cod_proposicao, cod_tramitacao} REFERENCIATramitação(cod_proposicao, cod_tramitacao)
  5. ETramitação ( {cod_proposicao <FK>, cod_tramitacao} <PK>, forma, regime )Despacho ( {cod_proposicao<FK>,cod_tramitacao<FK>,cod_despacho}<PK>, data, andamento )- Restrição da tabela Tramitação: cod_proposicao REFERENCIA Proposição(cod_proposicao)- Restrições da tabela Despacho: cod_proposicao REFERENCIA Proposição(cod_proposicao), ecod_tramitacao REFERENCIA Tramitação (cod_tramitacao)
Revelar gabarito e comentário

GabaritoD — Tramitação ( {cod_proposicao<FK>, cod_tramitacao} <PK>, forma, regime ) Despacho ( { {cod_proposicao, cod_tramitacao} <FK>, cod_despacho} <PK>, data, andamento ) - Restrição da tabela Tramitação: cod_proposicao REFERENCIA Proposição(cod_proposicao) - Restrição da tabela Despacho: {cod_proposicao, cod_tramitacao} REFERENCIA Tramitação(cod_proposicao, cod_tramitacao)

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): entidades fracas e chaves compostas

Gabarito: letra D. O mapeamento correto propaga a chave primária da entidade forte (Proposição) para as entidades fracas (Tramitação e Despacho), formando chaves primárias compostas e uma cadeia de chaves estrangeiras que preserva a dependência de existência do modelo conceitual. A alternativa D é a única que representa corretamente essa estrutura hierárquica.

O mapeamento objeto-relacional (ORM) é a técnica que traduz o modelo conceitual (entidades e relacionamentos) para o modelo relacional (tabelas, chaves e restrições). O ponto central desta questão é identificar a natureza dos relacionamentos entre as classes: uma Proposição pode ter várias Tramitações, e cada Tramitação pode ter vários Despachos. Isso configura uma hierarquia de dependência, onde a existência de uma Tramitação depende da existência de uma Proposição, e a existência de um Despacho depende da existência de uma Tramitação.

No modelo relacional, entidades fracas (aquelas que não possuem existência própria) são mapeadas incluindo a chave primária da entidade forte como parte de sua própria chave primária (chave primária composta) e como chave estrangeira. Assim, a chave primária de Tramitação deve ser composta por cod_proposicao (FK) e cod_tramitacao. Da mesma forma, a chave primária de Despacho deve ser composta por cod_proposicao, cod_tramitacao (ambos FK) e cod_despacho. Essa propagação em cascata garante a integridade referencial e a unicidade dos registros, refletindo a dependência hierárquica do modelo conceitual.

Vamos analisar cada alternativa:

Critério

Alternativa D (correta)

Alternativa E (pegadinha)

Chave primária de Tramitação

{cod_proposicao (FK), cod_tramitacao}

{cod_proposicao (FK), cod_tramitacao}

Chave primária de Despacho

{cod_proposicao, cod_tramitacao (FKs), cod_despacho}

{cod_proposicao, cod_tramitacao, cod_despacho}

FK de Despacho → Tramitação

{cod_proposicao, cod_tramitacao} referenciando a chave composta de Tramitação como um todo

cod_proposicao → Proposição e cod_tramitacao → Tramitação, separadamente

Integridade referencial da cadeia

✅ Garantida (par composto validado junto)

❌ Quebrada (não garante que o par corresponda a uma tramitação existente)

Alternativa A — ❌ Incorreta

Esta alternativa mapeia Tramitação e Despacho como entidades independentes, com chaves primárias próprias (cod_tramitacao e cod_despacho) e sem nenhuma chave estrangeira. Isso ignora completamente os relacionamentos entre as classes. No modelo conceitual, Tramitação depende de Proposição, e Despacho depende de Tramitação. Sem as chaves estrangeiras, não há como representar esses relacionamentos, violando a semântica do modelo. A alternativa A trata as entidades como se fossem fortes e independentes, o que é incorreto.

Alternativa B — ❌ Incorreta

A alternativa B mapeia Tramitação com chave primária própria (cod_tramitacao) e Despacho com chave primária composta por cod_tramitacao (FK) e cod_despacho. Embora represente o relacionamento entre Tramitação e Despacho, ela não propaga a chave primária de Proposição para Tramitação. Isso significa que Tramitação é tratada como uma entidade forte, sem depender de Proposição. No modelo conceitual, Tramitação é uma entidade fraca que depende de Proposição. Portanto, a alternativa B está incompleta, pois não representa a dependência de Tramitação em relação a Proposição.

Alternativa C — ❌ Incorreta

A alternativa C mapeia Tramitação com chave primária composta por cod_tramitacao e cod_despacho (FK), e Despacho com chave primária própria (cod_despacho). Isso inverte a direção do relacionamento: a chave estrangeira cod_despacho em Tramitação indica que uma Tramitação depende de um Despacho, o que é o oposto do modelo conceitual. No modelo, um Despacho depende de uma Tramitação, não o contrário. Além disso, a alternativa C também não propaga a chave de Proposição, tratando Tramitação como entidade forte. Portanto, a alternativa C está incorreta tanto na direção do relacionamento quanto na falta de propagação da chave de Proposição.

Alternativa D — ✅ Correta ⟵ GABARITO

A alternativa D mapeia corretamente a hierarquia de dependência. Tramitação tem chave primária composta por cod_proposicao (FK) e cod_tramitacao, com restrição referenciando Proposição. Despacho tem chave primária composta por cod_proposicao, cod_tramitacao (ambos FK) e cod_despacho, com restrição referenciando Tramitação. Essa estrutura propaga a chave primária de Proposição para Tramitação e, em seguida, para Despacho, formando uma cadeia de chaves estrangeiras que preserva a dependência de existência do modelo conceitual. A chave primária composta de Despacho garante que cada despacho seja único dentro de uma tramitação específica de uma proposição específica, refletindo corretamente a semântica do modelo.

Alternativa E — ❌ Incorreta

A alternativa E mapeia Tramitação com chave primária composta por cod_proposicao (FK) e cod_tramitacao, e Despacho com chave primária composta por cod_proposicao, cod_tramitacao e cod_despacho. No entanto, as restrições da tabela Despacho referenciam Proposição e Tramitação separadamente, com cod_proposicao referenciando Proposição e cod_tramitacao referenciando Tramitação. Isso quebra a cadeia de dependência: a chave estrangeira composta {cod_proposicao, cod_tramitacao} em Despacho deveria referenciar a chave primária composta de Tramitação, que é {cod_proposicao, cod_tramitacao}. Ao referenciar separadamente, a alternativa E não garante que o par {cod_proposicao, cod_tramitacao} em Despacho corresponda a uma tramitação existente. A restrição correta é a da alternativa D, que referencia a chave composta de Tramitação como um todo.

NÃO CAIA NESSA!

A banca tenta confundir o candidato com a alternativa E, que parece correta à primeira vista, mas quebra a integridade referencial ao referenciar as chaves estrangeiras separadamente. A chave estrangeira composta deve referenciar a chave primária composta da tabela pai como um todo, não cada atributo individualmente. Fique atento a essa sutileza!

Gabarito: letra D — a única que propaga corretamente a chave de Proposição e mantém a cadeia de dependência entre as entidades fracas.

Link permanente: /questoes/fg075132