Agregação
O Problema
O modelo ER básico não permite que um relacionamento participe diretamente de outro relacionamento. Mas há situações em que precisamos exatamente disso.
No banco da UnDF, registramos que um aluno cursou uma turma de uma disciplina com uma nota. A “turma” não é simplesmente uma entidade — é descrita por um relacionamento (ministra) entre professor e disciplina, com atributos ano, semestre e turma.
Queremos associar aluno a essa “turma” (e registrar nota e aprovado). Mas aluno seria associado ao relacionamento ministra, não a uma entidade.
Solução: Agregação
Agregação (aggregation) é uma abstração que trata um relacionamento como uma entidade de nível superior. O relacionamento (e os conjuntos de entidades que ele conecta) é “encaixotado” em uma nova entidade, que pode então participar de outros relacionamentos.
A caixa de agregação é representada no diagrama ER por um retângulo tracejado ao redor do relacionamento e das entidades que ele conecta.
Diagrama ER com Agregação: UnDF
Quando Usar Agregação
Use agregação quando:
- Um relacionamento precisa participar de outro relacionamento
- Há informação que descreve a participação de uma entidade em um relacionamento (e não em uma das entidades envolvidas)
- O relacionamento “base” deve existir independentemente da participação da entidade externa
No caso da UnDF: uma oferta de turma (ministra) pode existir mesmo sem nenhum aluno matriculado nela. Um aluno pode se matricular nessa oferta (cursa), mas a oferta preexiste. Isso justifica a separação: ministra é o relacionamento base; cursa é a agregação que conecta aluno a ele.
Conversão para Esquema Relacional
Para representar agregação em esquemas relacionais:
Cria-se um schema para o relacionamento externo contendo: - A chave primária do relacionamento agregado (como FK) - A chave primária de cada entidade adicional participante (como FK) - Os atributos próprios do relacionamento externo
O relacionamento cursa com a agregação ministra no banco da UnDF:
-- Schema do relacionamento agregado (já existente):
ministra(cod_disciplina, ano, semestre, turma, matricula_prof, horario, sala)
PK: (cod_disciplina, ano, semestre, turma)
-- Schema da agregação (relacionamento externo):
matricula_disciplina(cod_disciplina, ano, semestre, turma, cod_matricula, nota, aprovado)
PK: (cod_disciplina, ano, semestre, turma, cod_matricula)
FK: (cod_disciplina, ano, semestre, turma) → ministra(...)
FK: cod_matricula → aluno(matricula)
O schema ministra não é redundante — ele é necessário para registrar as ofertas de turmas independentemente das matrículas dos alunos.
Agregação vs. Ternário
Uma alternativa à agregação seria um relacionamento ternário entre professor, disciplina e aluno. A diferença:
| Abordagem | Semântica |
|---|---|
| Ternário (professor–disciplina–aluno) | Cada tripla (professor, disciplina, aluno) é registrada em conjunto |
| Agregação (ministra + aluno) | A oferta ministra existe independentemente; aluno se associa a ela |
A agregação é mais rica: permite registrar que uma turma foi oferecida mas não teve matriculados, ou que uma nota foi registrada para uma oferta específica de um professor específico. O ternário puro não captura a existência da oferta sem aluno.
Para Praticar
1. Identificar necessidade de agregação. Para cada situação, determine se a agregação é necessária ou se um relacionamento binário/ternário simples é suficiente:
- Registrar que um funcionário trabalha em um projeto durante um período (data início, data fim)
- Registrar que um médico avaliou o resultado de um exame feito por um paciente (onde o exame tem data, tipo e resultado)
- Registrar que um cliente comprou um produto com um desconto específico
- (a) Relacionamento binário simples
trabalha_ementrefuncionarioeprojeto, com atributosdata_inicioedata_fim. Não precisa de agregação. - (b) Agregação necessária:
avaliaentremédicoe o relacionamentofez_exame(entrepacienteetipo_exame). O exame existe independentemente da avaliação do médico. - (c) Relacionamento ternário ou binário
compraentrecliente,produtoepedido, com atributodesconto. Pode-se resolver sem agregação dependendo do modelo.
2. Conversão da agregação. Dado o cenário: alunos fazem projetos sob orientação de professores. Um projeto pode ter múltiplos alunos orientados pelo mesmo professor. Defina: (a) o relacionamento base orienta entre professor e projeto; (b) o relacionamento externo participa entre aluno e a agregação orienta (com atributo papel). Escreva os schemas relacionais.
projeto(id_projeto, titulo, data_inicio, data_fim)
PK: id_projeto
orienta(matricula_prof, id_projeto)
PK: (matricula_prof, id_projeto)
FK: matricula_prof → professor(matricula_prof)
FK: id_projeto → projeto(id_projeto)
participa(matricula_prof, id_projeto, matricula_aluno, papel)
PK: (matricula_prof, id_projeto, matricula_aluno)
FK: (matricula_prof, id_projeto) → orienta(...)
FK: matricula_aluno → aluno(matricula)
O atributo papel descreve o papel do aluno naquela orientação específica (ex.: “bolsista”, “voluntário”).
3. Armadilha: omitir a agregação. Se representarmos cursa como relacionamento ternário direto (professor, disciplina, aluno) em vez de usar agregação, que informação se perde?
Um relacionamento ternário (professor, disciplina, aluno) força que todo registro inclua um aluno — não é possível registrar que uma turma foi oferecida sem alunos matriculados.
Com a agregação (ministra existe independentemente; matricula_disciplina referencia ministra), é possível: 1. Registrar uma oferta de turma sem nenhum aluno 2. Saber exatamente em qual oferta específica (professor+disciplina+ano+semestre+turma) o aluno se matriculou, mesmo se o professor mudar entre semestres
O ternário puro perderia essas distinções.