Um Ministério Público Estadual mantém sistema de controle de procedimentos investigatórios, no qual um mesmo membro pode atuar em múltiplos procedimentos e cada procedimento pode ter diversos membros designados em períodos distintos, com necessidade de registrar datas de início e fim da designação. O modelo conceitual que representa corretamente essa situação é
Auma entidade fraca DESIGNACAO dependente de MEMBRO, com chave parcial composta por data_inicio e data_fim.
Bum atributo compostoperiodo_designacao armazenado na entidade PROCEDIMENTO, contendo data_inicio e data_fim para cada membro associado.
Cum relacionamento N:N entre MEMBRO e PROCEDIMENTO, contendo os atributos data_inicio e data_fim associados ao próprio relacionamento.
Ddois relacionamentos 1:N independentes entre MEMBRO e PROCEDIMENTO, cada um representando uma data distinta de início e fim da designação.
Eum atributo multivalorado datas_designacao na entidade MEMBRO, armazenando os períodos de atuação em cada procedimento.
Revelar gabarito e comentário▾
GabaritoC — um relacionamento N:N entre MEMBRO e PROCEDIMENTO, contendo os atributos data_inicio e data_fim associados ao próprio relacionamento.
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 conceitual: relacionamento N:N com atributos no relacionamento
Gabarito: letra C. A situação descrita — um membro atua em vários procedimentos e cada procedimento tem vários membros, com datas de início e fim da designação — é um relacionamento muitos-para-muitos (N:N) entre MEMBRO e PROCEDIMENTO, e os atributos data_inicio e data_fim pertencem ao relacionamento, pois descrevem a associação entre um membro específico e um procedimento específico, não a entidade em si. Essa é a modelagem correta no modelo entidade-relacionamento (MER).
No modelo entidade-relacionamento, quando temos uma associação entre duas entidades em que cada lado pode participar múltiplas vezes, temos um relacionamento N:N (muitos-para-muitos). Nesse caso, os atributos que descrevem a própria associação — como as datas de início e fim da designação — devem ser modelados como atributos do relacionamento, e não das entidades participantes. Isso porque tais atributos não são propriedades intrínsecas de MEMBRO nem de PROCEDIMENTO, mas sim da relação entre eles: um membro pode ter várias designações em procedimentos diferentes, e cada designação tem seu próprio período.
Vamos entender por que as outras alternativas estão erradas. A alternativa A propõe uma entidade fraca DESIGNACAO dependente de MEMBRO, com chave parcial composta por data_inicio e data_fim. Entidade fraca é aquela que não possui atributos suficientes para formar uma chave primária completa, dependendo de uma entidade forte para existir. Aqui, a designação não é uma entidade fraca: ela é um relacionamento entre MEMBRO e PROCEDIMENTO, e as datas não formam uma chave parcial — elas são atributos descritivos do relacionamento. Além disso, a chave parcial de uma entidade fraca seria composta por atributos da própria entidade mais a chave da entidade forte, mas data_inicio e data_fim não identificam unicamente uma designação (um membro pode ter duas designações no mesmo procedimento com o mesmo período? Possível, mas não é o critério).
A alternativa B sugere um atributo composto periodo_designacao na entidade PROCEDIMENTO, contendo data_inicio e data_fim para cada membro associado. Isso viola o princípio de que atributos de um relacionamento N:N não podem ser armazenados em uma das entidades participantes, pois geraria redundância e impossibilidade de representar corretamente múltiplas designações de membros diferentes no mesmo procedimento. Atributo composto é aquele que pode ser dividido em subpartes (ex.: endereço = rua + número + cidade), mas aqui o período não é um atributo de PROCEDIMENTO — é da associação.
A alternativa D propõe dois relacionamentos 1:N independentes entre MEMBRO e PROCEDIMENTO, cada um representando uma data distinta. Isso fragmentaria a informação: teríamos um relacionamento para data_inicio e outro para data_fim, o que não faz sentido conceitual — o período é uma unidade que deve ser armazenada junto. Além disso, a cardinalidade correta é N:N, não 1:N, pois um membro pode atuar em vários procedimentos e um procedimento pode ter vários membros.
A alternativa E sugere um atributo multivalorado datas_designacao na entidade MEMBRO, armazenando os períodos de atuação em cada procedimento. Atributo multivalorado é aquele que pode ter múltiplos valores para uma mesma instância (ex.: telefones de uma pessoa). Mas aqui precisamos associar cada período a um procedimento específico — não basta listar datas soltas; precisamos saber em qual procedimento o membro atuou em cada período. Isso exige um relacionamento, não um atributo multivalorado.
A alternativa C é a correta: um relacionamento N:N entre MEMBRO e PROCEDIMENTO, com os atributos data_inicio e data_fim associados ao próprio relacionamento. Essa é a modelagem clássica para associações com atributos próprios, como visto em questões anteriores da FCC (ex.: relacionamento N:M com atributo tipo_atuação modelado como atributo do relacionamento).
PEGA ESSA DICA!
Para identificar se um atributo pertence ao relacionamento ou à entidade, pergunte: "esse atributo descreve a entidade em si ou a associação entre duas entidades?" Se descreve a associação (como data de início/fim de uma designação, quantidade de um item em um pedido), ele é atributo do relacionamento. Em relacionamentos N:N, atributos do relacionamento são obrigatórios para evitar redundância e ambiguidade.
Critério
A – Entidade fraca DESIGNACAO
B – Atributo composto em PROCEDIMENTO
C – Relacionamento N:N com atributos (✅)
D – Dois relacionamentos 1:N
E – Atributo multivalorado em MEMBRO
Cardinalidade representada
1:N (designação dependente de MEMBRO)
Não representa N:N (um período por procedimento)
N:N correta
1:N (fragmentada)
Não representa N:N (lista sem vínculo com procedimento)
Onde ficam data_inicio/data_fim
Chave parcial da entidade fraca
Subatributos de periodo_designacao
Atributos do relacionamento
Separadas em dois relacionamentos distintos
Dentro do atributo multivalorado
Consegue registrar períodos distintos por membro/procedimento?
Parcialmente (depende de chave composta inadequada)
Não (limita a um período por procedimento)
Sim (cada par membro-procedimento tem seu período)
Não (fragmenta o período em duas relações)
Não (não associa período a procedimento específico)
Adequação ao MER
❌ Designação é relacionamento, não entidade fraca
❌ Atributo de associação colocado em entidade errada
✅ Modelagem clássica para associação com atributos
❌ Cardinalidade e semântica incorretas
❌ Atributo multivalorado não substitui relacionamento
Alternativa A — ❌ Incorreta
A entidade fraca é aquela que depende de outra para existir e usa a chave da entidade forte como parte de sua chave. Aqui, a designação é um relacionamento entre MEMBRO e PROCEDIMENTO, não uma entidade fraca. Além disso, data_inicio e data_fim não formam uma chave parcial — são atributos descritivos do relacionamento. A chave parcial de uma entidade fraca seria composta por atributos da própria entidade mais a chave da entidade forte, mas data_inicio e data_fim não identificam unicamente uma designação (um membro pode ter duas designações no mesmo procedimento com o mesmo período? Possível, mas não é o critério).
Alternativa B — ❌ Incorreta
Atributo composto é aquele que pode ser dividido em subpartes (ex.: endereço = rua + número + cidade). Mas aqui o período não é um atributo de PROCEDIMENTO — é da associação entre MEMBRO e PROCEDIMENTO. Armazenar periodo_designacao em PROCEDIMENTO não permite representar corretamente múltiplas designações de membros diferentes no mesmo procedimento, pois cada procedimento teria um único período, o que não reflete a realidade (vários membros com períodos distintos).
Alternativa C — ✅ Correta ⟵ GABARITO
Relacionamento N:N entre MEMBRO e PROCEDIMENTO, com atributos data_inicio e data_fim no relacionamento. Isso representa fielmente a situação: um membro pode atuar em vários procedimentos (N), cada procedimento pode ter vários membros (N), e as datas de início e fim são propriedades da designação (a associação entre um membro e um procedimento). Essa é a modelagem correta no MER.
Alternativa D — ❌ Incorreta
Dois relacionamentos 1:N independentes fragmentariam a informação: um para data_inicio e outro para data_fim. Isso não faz sentido conceitual — o período é uma unidade que deve ser armazenada junto. Além disso, a cardinalidade correta é N:N, não 1:N, pois um membro pode atuar em vários procedimentos e um procedimento pode ter vários membros.
Alternativa E — ❌ Incorreta
Atributo multivalorado é aquele que pode ter múltiplos valores para uma mesma instância (ex.: telefones de uma pessoa). Mas aqui precisamos associar cada período a um procedimento específico — não basta listar datas soltas; precisamos saber em qual procedimento o membro atuou em cada período. Isso exige um relacionamento, não um atributo multivalorado.