Modelo Entidade-Associação

O que é?

O Modelo Entidade-Associação permite-nos exprimir as necessidades do domínio de uma aplicação. Ao construir um Modelo E-A, conseguimos, mais tarde, determinar de que tabelas e colunas necessitamos na nossa base de dados.

Com este modelo conseguimos exprimir:

• Entidades
  • Entidades Fracas
• Atributos de Entidades
  • Chaves Primárias
• Associações (Relações)
• Agregações
• Generalizações/Especializações

Por vezes, o modelo não é suficiente para representar todos os requisitos da nossa aplicação. Podemos, assim, recorrer também a Restrições de Integridade (Integrity Constraints), quando necessário.

Entidades e Atributos

Uma entidade pode conter vários atributos, sendo que alguns desses atributos podem ser a sua chave primária.
Dizemos que os atributos que constituem a chave primária são os atributos que caracterizam a entidade, identificando-a inequivocamente no universo.

Exemplos de entidades são Pessoa, Produto, Compra, etc.
Exemplos de atributos, no caso da entidade Pessoa, são número do cartão de cidadão, nome, sexo, data de nascimento, etc.

As entidades são representadas por um retângulo, enquanto que os atributos são representados por uma elipse. Os atributos que são chave primária distinguem-se dos restantes pelo texto a sublinhado.

Pelo menos um atributo tem de ser uma chave primária.

Associações (Relações)

Uma associação entre duas ou mais entidades representa a relação entre elas.

Como exemplo simples, podemos pensar que uma Compra contém Produtos, pelo que estão relacionados.
Podemos representar esta associação com a seguinte notação:

As associações têm normalmente um nome, único em todo o diagrama, que normalmente é um verbo.

Para além disso, não têm direção, mas podemos utilizar os símbolos > e < para desambiguar alguns casos.

Algumas associações podem também conter atributos. No entanto, é importante ter em conta que se tivermos muitos atributos numa associação, pode justificar-se a criação de uma nova entidade.

Tomemos um cenário em que temos uma relação Fornecedor-Loja e em que existe um número máximo de produtos mensais que podem ser encomendados pela loja ao fornecedor. A associação entre a entidade Fornecedor e a entidade Loja tem assim um atributo: o número máximo de produtos mensais.
Representamos uma associação com atributos das seguinte forma:

Associações Ternárias

Nada nos impede de criar associações entre três ou mais entidades. Atenção que estas podem, por vezes, ser pouco explícitas. Alternativamente, podemos criar uma agregação que, para além de ser mais explícita, nos dá maior flexibilidade a definir restrições.

Voltando ao exemplo da Compra e do Produto, tomemos outra entidade, Cliente, que passa a fazer parte da relação.

Restrições

Existem dois tipos de restrições que podemos aplicar a associações: restrições de cardinalidade e restrições de participação.

As restrições de cardinalidade referem a multiplicidade da relação, isto é, one-to-one, one-to-many ou many-to-many.

As restrições de participação indicam se é necessário a associação existir ou não.

Podemos aplicar ambas as restrições simultaneamente.

Generalizações/Especializações

Por vezes, duas entidades diferem por poucos ou até nenhum atributo. Quando isto acontece, podemos estar num caso em que conseguimos generalizar/especializar uma entidade noutras. Um exemplo fácil de perceber é o caso Professor/Aluno. Ambos têm um nome, cartão de cidadão, data de nascimento, etc. Podemos criar uma entidade Pessoa que tem duas especializações, Professor e Aluno, e que tenha também estes atributos comuns:

É de realçar que cada uma das especializações pode ter atributos adicionais. Isto é particularmente relevante quando temos atributos "opcionais": muitas vezes estes podem ser modelados mais corretamente através de uma especialização.

Agora que delimitámos o porquê de querermos criar generalizações/especializações, vamos ver algumas das suas propriedades e o que podemos fazer com elas.

Podemos, tal como nas associações, aplicar restrições às especializações:

• podemos obrigar a que exista a especialização
• podemos obrigar a que a especialização seja disjunta, isto é, que nenhum exemplar de uma entidade possa ser simultaneamente um exemplar de mais do que uma especialização (e.g., uma pessoa pode ser um Professor ou um Aluno, mas nunca os dois ao mesmo tempo).

Como nas associações, é também possível aplicar ambas as restrições simultaneamente. As bolinhas azuis nos diagramas de Venn (meramente ilustrativos; não fazem parte do Modelo E-A) indicam onde podem existir entidades dentro das especializações possíveis.

Para conseguir ilustrar tudo, vamos tomar um exemplo mais complexo. Temos um clube que contém membros. Esses membros podem ser sócios, gestores ou nenhum dos dois. Cada sócio tem um tier, consoante as quotas que paga: bronze, silver e gold. Os sócios são identificados pelo número de sócio.
Finalmente, consoante a frequência com que o membro interage com o clube, pode também ser classificado como regular ou ocasional.

Vamos então começar a modelar esta situação. Ao lado do modelo E-A, irá ser também apresentado um diagrama de Venn, de forma a clarificar o significado de cada símbolo.

O primeiro passo é criar a especialização sócio e gestor. Um membro pode não ser nenhum deles (isto é, ser apenas membro), como pode ser ambos simultaneamente.

De seguida, criamos outra especialização, a frequência. Será que faz sentido especializar tanto o sócio como gestor? NÃO! Isso resultaria em duplicação de especializações, como podemos ver abaixo. Se tivéssemos ainda mais especializações abaixo destas, criaríamos uma árvore muito grande para obtermos as combinações todas.

Como podemos resolver entre problema? É simples, criamos outra especialização ao mesmo nível daquela que já existe. Esta abordagem permite que existam as várias combinações, preservando a facilidade de leitura e simplicidade do modelo.
Sabemos que um membro tem de ser obrigatoriamente regular ou ocasional, mas não pode ser ambos simultaneamente.

Finalmente, podemos criar as especializações do tier de sócio. Como seria de esperar, estes tiers vão ser especializações de sócio. Um sócio tem obrigatoriamente um e apenas um tier.

Restrições de Integridade

Frequentemente, vamos precisar de incluir no nosso Modelo E-A certas restrições que não são representáveis graficamente. Por esta razão, as Restrições de Integridade (Integrity Constraints) são das poucas coisas que iremos representar textualmente.

É preciso ter em atenção que devemos evitar ao máximo utilizar representação textual, usando sempre que possível a representação gráfica disponível no Modelo E-A (e.g. nas multiplicidades das associações).

As restrições de integridade são indicadas no Modelo E-A com a notação (RI - X) (em inglês, (IC - X)), onde X é o número da restrição.
O texto de cada restrição deve ser claro e objetivo, utilizando vocabulário de obrigatoriedade ou proibições, sem nunca utilizar referências temporais. Quando possível, é preferível separar uma restrição de integridade complexa em várias mais simples.

Mais exemplos

Atributo único

• (IC - 1): O telemóvel de um utilizador tem de ser único.

---

Associação Recursiva

Quando temos uma associação recursiva, é útil definir restrições adicionais, como evitar associação de um exemplar a si mesmo, evitar dependências circulares ou mesmo limitar a profundidade máxima.

• (IC - 1): Uma categoria não pode ser sua sub categoria.

Entidades Fracas

Nem sempre conseguimos identificar uma entidade, isto é, por vezes, a sua chave não é suficiente para a especificar de forma unívoca no universo. Podemos ter, por exemplo, uma rua, um andar, etc. Cada um destes conceitos não pode existir sem outro (e.g. freguesia e prédio, respetivamente).

Quando criamos uma entidade fraca, temos de indicar qual é a associação que passa a identificar a entidade. É possível, também, ter entidades fracas ligadas a entidades fracas, deste que tenham uma ligação a uma entidade forte.

Modelando, por exemplo, as estradas de um distrito:

Aqui tem-se que a chave de uma estrada, o seu nome, é uma chave parcial, visto que podem existir várias estradas com o mesmo nome. Assim, o nome de uma estrada não basta para a identificar no mundo, apenas dentro de uma freguesia, onde não há estradas com nomes repetidos.

Do mesmo modo, uma freguesia só tem nome único dentro do mesmo concelho, pelo que a sua chave é também parcial, não sendo suficiente para a identificar de forma absoluta. Tem-se que a chave primária de uma freguesia é a composição do seu nome com o nome do concelho ao qual pertence. A chave de uma estrada é, analogamente, a composição do seu nome com os nomes da freguesia e do concelho onde se encontra.

Agregações

Como referido nas associações ternárias, estas nem sempre são claras nem flexíveis o suficiente. Para resolvermos este problema, podemos utilizar uma notação do Modelo E-A chamada agregação.

Com as agregações, podemos juntar associações de duas entidades e fazer com que estas se comportem como apenas uma. No geral, não se deve utilizar uma agregação em mais do que uma associação.
Isto faz com que seja possível tornar a associação opcional ou definir multiplicidades mais granularmente.

Podemos continuar a efetuar associações diretamente com entidades dentro da agregação.

Pegando num exemplo que ocorre no Fénix: agregamos a associação Disciplina/Semestre, pelo que ganhamos granularidade na associação de professores à mesma.
Podemos, como no exemplo da esquerda, permitir que uma execução de uma disciplina não tenha nenhum professor associado (embora não faça muito sentido), como também obrigar a que tenha um ou mais, como no exemplo da direita.

(atributos das entidades omitidos por brevidade)