Modelo Entidade-Relacionamento Estendido

Na disciplina de Programação Orientada a Objetos, vimos como alguns conceitos, como herança, trazem importantes contribuições à modelagem de dinâmicas do mundo real aos nossos programas. Agora, conheceremos o Modelo Entidade-Relacionamento Estendido (EER), que introduz alguns desses conceitos ao projeto conceitual de banco de dados.

👪 Herança

O conceito de herança, que já conhecemos do paradigma de Programação Orientada a Objetos (POO), também pode ser aplicado no contexto do Modelo Entidade-Relacionamento Estendido (MEER). Nele, a herança permite que um tipo de entidade (também chamado de supertipo) compartilhe seus atributos com outros tipos de entidade mais específicos (subtipos).

Esse recurso é útil quando há atributos ou relacionamentos comuns entre diferentes entidades, e desejamos evitar a repetição de estruturas semelhantes. Ao organizar os dados dessa forma, conseguimos uma modelagem mais clara, modular e com menor redundância.

A herança no MEER é representada por um relacionamento entre um supertipo e um ou mais subtipos, semelhante à herança de classes em linguagens de programação orientadas a objetos. Os subtipos herdam todos os atributos e relacionamentos do supertipo, podendo, ainda, ter seus próprios atributos ou se relacionar com outras entidades de maneira especializada.

Por exemplo, no caso da entidade PESSOA, podemos definir subtipos como ALUNO, PROFESSOR e TECNICO, que herdam atributos comuns de PESSOA, como nome, cpf, email, mas podem ter também seus próprios atributos exclusivos, como curso no caso de ALUNO ou departamento no caso de PROFESSOR.

Esse mecanismo traz diversas vantagens:

• Reutilização de estruturas comuns;
• Organização hierárquica das entidades;
• Facilidade de manutenção e extensão do modelo;
• Expressividade ao representar o domínio do problema.

Vale destacar que, ao contrário da herança em linguagens de programação, que pode ser usada para reaproveitamento de código e polimorfismo, no projeto de banco de dados ela é usada exclusivamente para fins de modelagem conceitual, com foco na organização lógica das entidades e seus relacionamentos.

Especialização e generalização

No livro, Elmarsi e Navathe (2011) usam alguns parágrafos para explicar a diferença entre especialização e generalização. Aqui, vou tentar resumir de forma bastante direta e didática:

A especialização ocorre quando partimos de um tipo de entidade (classe) e, depois, criamos os subtipos de entidade (análogos às subclasses de OO). Como um exemplo prático, imagine que iniciamos o projeto conceitual do banco de dados de uma universidade e entendemos que há um tipo de entidade chamado ALUNO. Conforme avançamos neste processo, percebemos que há particularidades mesmo diferentes entidades desse tipo. Por exemplo:

• o ALUNO que está em um curso de pós-graduação precisa ter um orientador durante todo o seu vínculo acadêmico, enquanto o estudante de graduação não;
• o ALUNO da graduação não pode se relacionar com uma entidade do tipo EXAME_QUALIFICACAO (uma avaliação que costuma acontecer na metade do curso de pós-graduação para avaliar a qualidade, contribuição e viabilidade do projeto).

Isso faz com que seja necessário organizar esse tipo de entidade em subtipos. Assim, ALUNO será o supertipo (ou superclasse) de ALUNO_GRADUACAO, ALUNO_POSGRAD e ALUNO_CURSOSLIVRES, por exemplo. Estas três últimas que mencionei são, portanto, subtipos (ou subclasses) especializadas a partir de ALUNO.

A generalização, por sua vez, é basicamente o processo inverso: observamos diferentes tipos de entidade que podem ser agrupados, ou melhor, generalizados. Usando o mesmo exemplo da universidade, imagine que, além do tipo de entidade ALUNO, temos também os tipos de entidade PROFESSOR, TECNICO, COLABORADOR. Ora, naturalmente, todas esses tipos de entidade possuem atributos comuns, como nome e cpf. Logo, podemos generalizar essas entidades num tipo PESSOA. Assim, o supertipo PESSOA foi generalizado a partir de ALUNO, PROFESSOR, TECNICO e COLABORADOR, que passam agora a ser subtipos de PESSOA.

⚠️ Restrições

Definição do subtipo

Ao modelarmos uma especialização no Modelo Entidade-Relacionamento Estendido (MEER), é importante compreendermos como as entidades serão atribuídas aos subtipos. Existem duas formas principais de definir os membros de um subtipo: por atributo ou pelo usuário.

Especialização definida por atributo

Uma especialização é chamada de definida por atributo quando todas as subclasses (subtipos) compartilham uma condição de membro baseada em um mesmo atributo do supertipo. Esse atributo comum é chamado de atributo de definição da especialização.

Nesse cenário, o valor desse atributo determina automaticamente a qual subtipo a entidade pertence. Por exemplo, imagine que a entidade ALUNO possui um atributo chamado tipo_vinculo, com os valores possíveis: "graduação", "pós-graduação" e "curso_livre". Com base nesse atributo, podemos especializar ALUNO nos subtipos ALUNO_GRADUACAO, ALUNO_POSGRAD e ALUNO_CURSOSLIVRES, respectivamente.

Assim, temos uma especialização definida por atributo, e o atributo tipo_vinculo aparece explicitamente ao lado do arco que liga o círculo (que representa a especialização) à superclasse, como ilustrado na Figura 8.4 do livro de Elmasri e Navathe (2011).

Toda entidade com o mesmo valor no atributo de definição é automaticamente incluída no subtipo correspondente.

Especialização definida pelo usuário

Em alguns casos, não existe um único atributo que permita determinar de forma automática a qual subtipo a entidade pertence. Nesses casos, dizemos que a especialização é definida pelo usuário.

Aqui, a atribuição de uma entidade a um subtipo é feita explicitamente, no momento em que o usuário insere ou atualiza a entidade no banco de dados. Não há, portanto, uma condição geral baseada em atributo, mas sim uma decisão caso a caso, conforme a lógica de negócio ou o controle do sistema.

Esse tipo de especialização é mais flexível, mas também exige cuidados no controle da consistência, pois a decisão de qual subtipo uma entidade pertence dependerá de ações manuais ou regras externas ao modelo conceitual.

Em resumo:

• Definida por atributo: a condição de pertencimento a cada subtipo é automática, com base em um atributo da superclasse.
• Definida pelo usuário: o pertencimento é decidido no momento da inserção, e não está vinculado diretamente a um atributo.>

Restrição de herança

No projeto conceitual de banco de dados, ao definirmos uma relação de herança entre tipos de entidade, devemos também identificarmos as restrições inerentes à herança, que podem ser de dois tipos:

• Disjunção: em uma especialização, uma entidade (objeto) só pode participar de, no máximo, um dos subtipos (subclasses). Retomando o exemplo de ALUNOque discutimos anteriormente, adotar uma disjunção neste contexto implicaria na impossibilidade de, ao mesmo tempo, um aluno estar matriculado na graduação e na pós-graduação.

  Para representarmos a disjunção no diagrama, usamos um círculo com a letra "d" minúscula dentro.

• A sobreposição (overlapping), segunda possibilidade, é o caso contrário da disjunção. Nela, uma entidade (objeto) pode participar de vários subtipos (subclasses) da relação de herança. Novamente recorrendo ao exemplo do tipo de entidade ALUNO, quando há sobreposição, um mesmo aluno pode estar matriculado tanto na graduação quanto na pós-graduação.

  Para representarmos a disjunção no diagrama, usamos um círculo com a letra "o" minúscula dentro.

Restrição de completude

Outra restrição que precisamos considerar no Modelo Entidade-Relacionamento Estendido (MEER) é a restrição de completude ou totalidade:

• Especialização total: toda entidade (objeto) do supertipo (superclasse) deve, obrigatoriamente, estar vinculado a pelo menos um subtipo (subclasse). Em analogia ao paradigma Orientado a Objeto, é como se a superclasse fosse abstrata. Naturalmente, o objeto deveria ser instanciado a partir de uma subclasse concreta.

Quando há restrição total, usa-se uma linha dupla para representar a ligação da superclasse ao círculo (que indica disjunção ou sobreposição).

• Especialização parcial: como você já deve imaginar, é o caso mais flexível, em que a participação de uma entidade em uma das subclasses é facultativa. Em relação ao paradigma orientado a objetos, neste caso, a superclasse seria concreta, o que possibilitaria a instanciação de objetos de forma direta.

No diagrama, a especialização parcial é representada apenas como um linha simples.

Hierarquias e reticulado

Elmasri e Navathe (2011) discutem também outro aspecto importante com relação à herança: a hierarquia de especialização. Esse conceito é definido pelos autores como uma restrição em que cada subclasse participa como uma subclasse em apenas um relacionamento de classe/subclasse (ou tipo/subtipo). Ou seja: cada subclasse tem apenas um elemento pai. Isso faz com que, visualmente, tenhamos uma estrutura de árvore.

Um reticulado de especialização, em contraponto, admite que uma subclasse tenha mais de um relacionamento, como podemos visualizar a partir da Figura 8.6, reproduzida a partir do livro de Elmasri e Navathe (2011).

Os autores discutem ainda que, quando uma subclasse tem mais de uma superclasse, ela é chamada de subclasse compartilhada. Isto, naturalmente, equivale ao conceito de herança múltipla.

Elmasri e Navathe (2011) reforçam que alguns modelos e linguagens não oferecem suporte à herança múltipla.

União

Você deve se lembrar que, na linguagem de programação C, temos o conceito de Union: uma estrutura similar a uma struct, porém com a particularidade de que apenas um dado seria armazenado. Ao lidarmos com o projeto conceitual de banco de dados, há casos que demandam uma saída similar.

Em banco de dados, a união é bastante oportuna quando há uma relacionamento que pode envolver um entre diferentes tipos de entidade. Elmasri e Navathe (2011) apresentam um exemplo bastante interessante e didático: um carro pode ser de propriedade de uma pessoa física, de uma empresa ou de um banco, por exemplo.

Criaremos, neste caso, um tipo de união (ou categoria) chamado PROPRIETARIO, subclasse de PESSOA, BANCO e EMPRESA, como no ilustrado na Figura a seguir.

Um tipo de união admite que cada uma de suas entidades participe apenas de um supertipo. Ou seja: uma ocorrência de proprietário deve ser ou PESSOA ou BANCO ou EMPRESA (exclusivamente).

Os autores reforçam também que uma categoria pode ser parcial ou total. Os autores explicam que a categoria pode ser:

• Total: significa que todas as instâncias das superclasses (PESSOA, EMPRESA e BANCO) participam da união. Ou seja, todo objeto dessas entidades está envolvido em um papel como PROPRIETARIO.
• Parcial: significa que apenas algumas instâncias das superclasses participam da categoria. Pode haver pessoas, empresas ou bancos que não são proprietários de carros.

O recurso de união, entretanto, não é suportado por todos os modelos de dados. Muitos SGBDs relacionais, por exemplo, exigem um mapeamento alternativo (com chaves estrangeiras ou tabelas intermediárias) para representar esse tipo de estrutura.

Elmasri e Navathe (2011) discutem ainda que a união deve ser evitada, preferindo-se o uso de especialização/generalização.