Questão de Banco de Dados — Banco de Dados Orientado a Objetos e Objeto-Relacional — FGV 2024

Mapeamento Objeto-Relacional (ORM): Chaves e Relacionamentos

Gabarito: letra D. O mapeamento ORM correto preserva a semântica do modelo conceitual propagando 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 reflete a dependência de existência. A alternativa D é a única que faz isso corretamente, pois a tabela Tramitação recebe cod_proposicao como FK e a tabela Despacho referencia a chave composta de Tramitação.

O mapeamento objeto-relacional (ORM) é a ponte entre o paradigma orientado a objetos do modelo conceitual e o modelo relacional de tabelas. Quando uma classe é mapeada para uma tabela, cada atributo vira uma coluna, e os relacionamentos entre classes precisam ser traduzidos em chaves estrangeiras (FK). A grande questão aqui é identificar a natureza dos relacionamentos entre as entidades do diagrama: se uma entidade é fraca (não tem atributos suficientes para formar uma chave primária própria), ela depende da entidade forte para existir, e sua chave primária é composta pela chave da entidade forte mais um discriminador parcial.

No modelo conceitual, a classe Proposição é a entidade forte, com chave primária cod_proposicao. A classe Tramitação representa um histórico de andamentos de uma proposição — cada proposição pode ter várias tramitações, mas uma tramitação só existe se a proposição existir. Isso caracteriza uma entidade fraca em relação a Proposição. A classe Despacho, por sua vez, representa os despachos dados em cada tramitação — cada tramitação pode ter vários despachos, mas um despacho só existe se a tramitação existir. Despacho é, portanto, uma entidade fraca em relação a Tramitação.

A regra de ouro do mapeamento ORM para entidades fracas é: a chave primária da entidade fraca é a chave primária da entidade forte + um discriminador parcial. E a chave estrangeira que liga a entidade fraca à forte é exatamente essa chave primária da entidade forte. No caso de uma cadeia de dependência (Proposição → Tramitação → Despacho), a chave primária de Despacho deve conter a chave de Tramitação, que por sua vez já contém a chave de Proposição. Isso garante a integridade referencial e a dependência de existência.

Vamos aplicar isso ao caso concreto. A tabela Tramitação deve ter chave primária composta por cod_proposicao (FK para Proposição) e cod_tramitacao (discriminador parcial). A tabela Despacho deve ter chave primária composta por cod_proposicao, cod_tramitacao (ambos FK para Tramitação) e cod_despacho (discriminador parcial). A alternativa D é a única que segue exatamente essa estrutura, propagando a chave de Proposição através da cadeia e mantendo a semântica completa do modelo conceitual.

A pegadinha da banca está em alternativas que tratam Tramitação e Despacho como entidades fortes independentes (A, B, C) ou que quebram a cadeia de dependência (E). A chave para acertar é reconhecer a dependência de existência e a necessidade de propagar a chave primária da entidade forte para as fracas.

Alternativa A — ❌ Incorreta

Esta alternativa mapeia Tramitação e Despacho como entidades fortes independentes, cada uma com sua própria chave primária simples (cod_tramitacao e cod_despacho). Isso perde completamente a semântica do modelo conceitual: não há nenhuma referência a cod_proposicao, então não é possível saber a qual proposição uma tramitação pertence, nem a qual tramitação um despacho pertence. O relacionamento entre as classes é ignorado, o que viola a regra de que todo relacionamento deve ser representado por chaves estrangeiras.

Alternativa B — ❌ Incorreta

Aqui, Tramitação é tratada como entidade forte (chave primária cod_tramitacao), e Despacho referencia Tramitação com uma chave estrangeira cod_tramitacao. O problema é que Tramitação não referencia Proposição: não há FK para cod_proposicao, então não é possível saber a qual proposição uma tramitação pertence. Além disso, Despacho referencia apenas cod_tramitacao, mas como Tramitação não tem uma chave única que identifique a proposição, a semântica do relacionamento Proposição-Tramitação é perdida. A dependência de existência de Tramitação em relação a Proposição não é representada.

Alternativa C — ❌ Incorreta

Esta alternativa inverte a direção do relacionamento: Tramitação referencia Despacho (cod_despacho como FK), o que é semanticamente incorreto. No modelo conceitual, Despacho depende de Tramitação (uma tramitação gera despachos), não o contrário. Além disso, Tramitação é tratada como entidade forte com chave primária composta por cod_tramitacao e cod_despacho, o que é um absurdo lógico: a chave primária de Tramitação não pode depender de um atributo de Despacho, pois isso criaria uma dependência circular. A relação de dependência está invertida.

Alternativa D — ✅ Correta ⟵ GABARITO

Esta alternativa segue exatamente a regra de mapeamento para entidades fracas em cadeia. Tramitação tem chave primária composta por cod_proposicao (FK para Proposição) e cod_tramitacao (discriminador parcial). Despacho tem chave primária composta por cod_proposicao, cod_tramitacao (ambos FK para Tramitação) e cod_despacho (discriminador parcial). As restrições de integridade referencial são declaradas corretamente: cod_proposicao referencia Proposição, e o par {cod_proposicao, cod_tramitacao} referencia Tramitação. Isso preserva a dependência de existência e a semântica completa do modelo conceitual.

Alternativa E — ❌ Incorreta

Esta alternativa acerta ao propagar cod_proposicao para Tramitação e ao usar chaves compostas, mas erra na tabela Despacho: ela referencia cod_proposicao diretamente a Proposição e cod_tramitacao diretamente a Tramitação, em vez de referenciar a chave composta {cod_proposicao, cod_tramitacao} de Tramitação. Isso quebra a cadeia de dependência: um despacho poderia existir com um cod_proposicao que não corresponde ao cod_proposicao da tramitação referenciada, violando a integridade referencial e a semântica do modelo. A restrição correta é que o par {cod_proposicao, cod_tramitacao} em Despacho deve referenciar a chave composta de Tramitação, não cada atributo separadamente.

Gabarito: letra D