Banco de Dados · FUNDATEC · 2025 | Questão sqc-qg474971

Banco de DadosDER - Diagrama de Entidade e Relacionamento

Código: qg474971
Banca: FUNDATEC
Órgão: PROCERGS
Ano: 2025
Nível: Superior

Cargo: Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft

No modelo Entidade-Relacionamento, há as entidades Aluno e Curso relacionadas por Matrícula. Cada aluno pode se matricular em vários cursos e cada curso pode ter vários alunos (N:N). Na conversão para o modelo relacional, qual é a forma correta e usual de representar esse relacionamento?

AAcrescentar, na tabela Aluno, colunas para os cursos (ou um campo que armazene todos os cursos do aluno), evitando junções frequentes.
BCriar uma tabela de junção contendo as chaves estrangeiras de Aluno e Curso; normalmente a chave primária é composta (AlunoId, CursoId) e a tabela pode ter atributos próprios da matrícula.
CRepresentar Matrícula como herança (supertipo Pessoa e subtipos), tratando a associação Aluno-Curso como especialização.
DUsar, na tabela Aluno, um campo multivalorado (lista/JSON de IDs de curso) para manter "em linha" as matrículas e reduzir joins.
E"Normalizar" removendo o relacionamento e mantendo apenas Aluno e Curso, delegando o vínculo a triggers e views calculadas.

Revelar gabarito e comentário

GabaritoB — Criar uma tabela de junção contendo as chaves estrangeiras de Aluno e Curso; normalmente a chave primária é composta (AlunoId, CursoId) e a tabela pode ter atributos próprios da matrícula.

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 relacional: relacionamento N:N

Gabarito: letra B. A forma correta e usual de representar um relacionamento muitos-para-muitos (N:N) no modelo relacional é criar uma tabela de junção (ou tabela associativa) contendo as chaves estrangeiras das duas entidades, formando uma chave primária composta. Essa tabela pode ainda incluir atributos próprios do relacionamento (como data da matrícula).

A banca testa o conhecimento da transformação do modelo conceitual (MER) para o modelo lógico (relacional). Em relacionamentos N:N, não é possível adicionar uma chave estrangeira em apenas uma das tabelas, pois isso violaria a normalização e geraria redundância. A solução padrão é a tabela de junção.

Alternativa A — ❌ Incorreta

Acrescentar colunas na tabela Aluno para os cursos (ou um campo multivalorado) fere a primeira forma normal (1FN) e introduz repetição de grupos, além de dificultar consultas e manutenção.

Alternativa B — ✅ Correta ⟵ GABARITO

Criar uma tabela de junção com chaves estrangeiras para Aluno e Curso, com chave primária composta (AlunoId, CursoId). Essa é a abordagem clássica e recomendada para relacionamentos N:N, permitindo armazenar atributos da matrícula e realizar joins eficientes.

Alternativa C — ❌ Incorreta

Representar Matrícula como herança (generalização/especialização) não se aplica. Herança é usada quando entidades compartilham atributos e relacionamentos, não para modelar associações N:N.

Alternativa D — ❌ Incorreta

Usar campo multivalorado (lista/JSON) para armazenar os IDs dos cursos em uma única coluna viola a atomicidade dos dados e dificulta consultas SQL (ex.: precisar de funções de string ou JSON). É uma prática desnormalizada e não recomendada em bancos relacionais tradicionais.

Alternativa E — ❌ Incorreta

Remover o relacionamento e delegar a lógica a triggers e views calculadas é uma abordagem artificial e não padronizada. O modelo relacional deve representar explicitamente os relacionamentos por meio de chaves estrangeiras e tabelas de junção, garantindo integridade referencial e eficiência.

PEGA ESSA DICA!

Lembre-se da regra: relacionamento 1:N → chave estrangeira na tabela do lado N. Relacionamento N:N → tabela de junção. Relacionamento 1:1 → chave estrangeira em qualquer lado (com restrição de unicidade).

Gabarito: letra B.

Link permanente: /questoes/qg474971