Fundamentos de banco de dados - Aurea Melo

Tecnologia em Análise e Desenvolvimento de Sistemas

Fundamentos de banco de dados

51

CAPÍTULO 2

Modelo Entidade Relacionamentos

2.1 Introdução

De acordo com os níveis de abstração vistos no Capítulo 1, o ní-vel conceitual corresponde ao nível em que, a partir da escolha de um modelo de dados, devemos seguir os conceitos pertinentes a realidade a ser modelada. Dessa forma, neste capítulo apresentaremos, deta-lhadamente, o Modelo Entidade e Relacionamento (MER), o qual é um modelo conceitual de dados introduzido por Peter Chen em 1976.

Importante ressaltar que, ao se escolher um modelo de dados, devemos respeitar e seguir os conceitos por ele definidos. Daí porque, é incorreto chamar, por exemplo, entidade de tabela, pois tabela cor-responde a um conceito usado em outro modelo de dados, no caso o Modelo Relacional, que por sua vez pertence a outro nível denominado nível lógico.

O MER é uma execelente ferramenta para se fazer a modelagem de dados de um sistema. Por pertencer ao nível conceitual, esse mo-delo contempla quais os dados deverão ser armazenados no banco de dados, não se preocupando como. Além disso, uma boa modelagem usando o MER, permite ao projetista de banco de dados validar se os dados modelados atendem aos requisitos levantados.

A seguir estudaremos cada conceito desse modelo, apresentando sua palicabilidade, utilizando, como estudo de caso, um sistema que



52

controla atendimento de consultas e solicitações de exames de uma Clínica, o qual está descrito como Sistema Principal na seção a seguir.

2.2 Sistema principal

Para melhor atender seus clientes, a clínica Salva Vidas deseja informatizar seus serviços de forma a gerar controle sobre os agenda-mentos e realização de consultas, solicitação e realização de exames. Para isso, é necessário cadastrar os dados sobre os pacientes, exames, médicos, especialidades dos médicos e funcionários, entre outros.

Sobre os médicos é necessário que o sistema armazene o CRM, nome, endereço, fones (residencial e celular) e as especialidades (note o plural) em que atuam (oftalmologista, ortopedista, etc). Cada espe-cialidade também pode ter mais de um médico atuando.

Sobre os pacientes deve-se armazenar o nome, endereço formado por rua, número, CEP e bairro, fones (residencial, celular e contato). Para se consultar o paciente pode agendar a data e hora da consulta e o nome do médico. Durante uma consulta o médico captura e repassa ao sistema os sintomas do paciente e o diagnóstico e ao final desta, ele pode fazer a solicitação de um exame, para que o paciente faça. É necessário que o sistema mantenha o controle sobre qual médico solicitou e qual realizou o exame (já que o médico que realiza não é o mesmo que solicita). Sobre a realização do exame deve-se guardar a data da realização e o resultado.

Com base nas informações descritas faça a modelagem de dados para o sistema. Se necessário complemente ou incremente a descri-ção.



53

2.3 Conjuntos de entidades

Uma entidade é uma abstração (isto é, um modelo puramente mental) de um ente existente no mundo real. Assim, uma entidade pode ser a abstração de um ser, de um fato, de uma coisa, de um organismo social, etc. Por exemplo, com base no estudo de caso, são entidades as representações abstratas de um médico, de um paciente, de um exame, etc. Em outras aplicações, são entidades as abstrações dos materiais usados por uma empresa, os departamentos e divisões da mesma, os seus funcionários, etc. (SETZER, 2005).

Uma coleção de entidades que têm características semelhantes é denomida de conjunto de entidades ou tipo de entidades. Sendo assim, um conjunto de entidades somente deve representar objetos no mundo real da mesma categoria. Muitas vezes, o conjunto de en-tidades é chamado simplesmente de entidades. Porém é importante esclarecer que entidade é o elemento individual dentro do conjunto de entidades. Por exemplo podemos ter o conjunto de entidades PACIEN-TES, e dentro da mesma termos a entidade João, a entidade Ana, etc, ou seja, o conjunto de entidades PACIENTES contém o agrupamento dos diferentes pacientes existentes no contexto do sistema.

Por representar o agrupamento de várias “coisas”, determina-remos como padão para os nomes desses conjuntos sempre palavras no plural. Ressaltanto que, por questões de senso comum, usaremos o termo entidade para determinar um conjunto de entidades, embora este tenha um sentido mais amplo e completo.

2.3.1 Representação gráfica

Um conjunto de entidades é representado graficamente por um retângulo com o nome da entidade ao meio, conforme Figura 2.1. Ge-ralmente, esse nome é um substantivo no plural.

MÉDICOS

Figura 2.1 Representação de um conjunto de entidades



54

2.3.2 Classificação

O conjunto de entidades pode ser classificado em 2 tipos distin-tos:

a) Entidades Fortes – que é uma entidade que tem existência própria, ou seja, não depende de outra para existir. Sua nota-ção é dada por um retângulo com o nome ao centro, conforme Figura 2.2.

b) Entidades Fracas - Ao contrário das Entidades Fortes as Enti-dades Fracas não existem por si só, ou seja, elas dependem de uma entidade Forte para existir. Portanto, podemos afirmar que uma entidade Fraca sempre depende existencialmente de uma Entidade Forte. Sua representação é um retângulo duplo conforme mostra a Figura 2.3.

PACIENTES

Figura 2.2 – Entidade Forte Pacientes

DEPENDENTES

Figura 2.3 – Entidade Fraca Dependentes

Dicas• Para identificar uma entidade forte, observe se ela re-

presenta algo que será inserido de forma independente no sistema a ser desenvolvido, ou seja, verifique se ela “existe por si só”;

• Os nomes dos conjuntos de entidades devem ser sempre substantivos, pois aplicam-se, como dito anteriormente, a entes com existência própria;



55

• Identifique as Entidades Fracas como alguma coisa do mundo real que, para existir, depende da existência de outra coisa. Por exemplo, um funcionário de uma em-presa pode ter dependentes para receberem benefícios. Dessa forma, será necessário efetuar um cadastro dos mesmos. Entretanto, caso o funcionário seja demitido, seu cadastro será excluído e, consequentemente, todos os dependentes cadastrados para ele também o serão.

2.3.3 Regras/Sugestões de modelagem

1. Nomes de conjuntos de entidades deverão estar sempre no plural.

2. Um conjunto de entidades deve ser único na modelagem, ou seja, em uma modelagem de um sistema não pode existir dois conjuntos de entidades com o mesmo nome.

3. Um conjunto de entidades fracas não pode depender de mais de uma entidade forte ou seja, a entidade fraca só pode de-pender de uma única entidade forte no modelo.

2.4 Atributos de entidades

Cada entidade de um conjunto de entidades possui proprieda-des que a caracterizam. Por exemplo, para cada entidade do conjunto de entidades “Médicos” tem-se propriedades tais como: nome, CRM, fone, entre outras. Tais características são abstraídas no MER pelo con-ceito de atributos.

Sendo assim, os atributos representam todas as propriedades ne-cessárias para se caracterizar uma entidade dentro de um determinado conjunto de entidades. Por exemplo, a entidade PACIENTES pode ter



56

os seguintes atributos (características): nome, endereço, fone e data do nascimento. Portanto, um atributo de uma entidade pode ser visto como um dado que a qualifica.

Importante diferenciarmos atributos de valores de atributos, ou seja, um valor de atributo representa um valor real para um atributo (também chamado de instância) de uma determinada entidade. Por exemplo, para o conjunto de entidade PACIENTES, podemos identificar uma entidade qualquer cujo atributo “nome” tenha o valor “Ana Pe-reira”, e o atributo “endereço” tenha o valor “Rua dos Anzóis, 23”, e assim por diante, ou seja, o nome Ana Pereira e seus demais dados são qualificações da entidade correspondente a esse paciente.

2.4.1 Representação gráfica

Na literatura corrente, deferentes autores usam diversas formas de representar atributos. Por exemplo, Navathe (Navathe, 2007), re-presenta atributos como elipses com o nome dentro ligadas por um segmento de reta ao conjunto de entidades, conforme a Figura 2.4. Já Setzer (SETZER, 2005) representa os atributos como pequenos círculos com o nome ao lado, também ligados por segmentos de reta, que por sua vez ligam-se ao conjunto de entidades, conforme pode ser visuali-zado na Figura 2.5.

Figura 2.4 – Representação de tributos dada por Navathe

Figura 2.5 – Representação de tributos dada por Setzer

Neste livro seguiremos a notação dada por Setzer, por acharmos



57

que torna o diagrama mais simples e, visualmente, limpo, porém cada analista deve desenvolver sua modelagem usando a representação gráfica que mais lhe agrade e pareça clara.

Note que, na representação gráfica, os atributos de um conjunto de entidades (Pacientes, no caso) parecem pertencer a ele, mas na verdade eles referem-se a qualquer entidade do conjunto. A Figura 2.4 (ou 2.5) deve ser entendida, portanto, como “cada entidade de Pa-cientes tem atributos Nome, Endereço e Sexo”, ou ainda, cada pacien-te deverá ser caracterizado pelo seu nome, endereço e sexo. Como os atributos que estamos exemplificando assumem apenas um valor para cada entidade (por exemplo, Ana Pereira tem um único nome, um único sexo, etc.), o nome do atributo deve estar sempre no singular, exceto quando ele for do tipo multivalorado conforme será visto na próxima seção.


O exemplo de atributo usado até aqui foi do tipo mais comum, também chamado de atributo simples. O MER contempla 5 tipos de atributos para representar as diferentes características das entidades do mundo real. São eles: atributo simples ou monovalorado, multi-valorado, composto, calculado ou derivado e atributo identificador. A seguir detalharemos cada um desses atributos.

Atributo simples

Um atributo simples é aquele que só pode assumir um único va-lor, isto é, não pode assumir vários valores e nem pode ser decomposto em subvalores. Por exemplo, Sexo tem um só valor para cada entidade de Pacientes, o qual pode ser M ou F e que, obviamente, não podem ser decompostos. O mesmo ocorre com Nome e Endereço: assumimos que cada paciente tenha um único endereço, o que é um exemplo do que se denomina uma restrição de integridade dos dados, isto é, uma condição que os dados devem satisfazer. Sendo assim se o cliente pos-suir mais de um endereço o mesmo não pode ser modelado (abstraído) como atributo simples. Além disso, assumindo que Nome é um atributo,



58

ele deve ser considerado por inteiro como um único valor, não podendo ser decomposto em nome próprio e sobrenome, o mesmo acontecendo com Endereço em relação à rua, número, CEP, etc.

Atributo multivalorado

O atributo multivalorado (do inglês multivalued) é o tipo de atri-buto que permite mais de um valor, isto porque existem casos de enti-dades, no mundo real, que possuem alguma característica para a qual é possível se determinar mais de um valor. Um exemplo típico é o caso de telefone, pois, atualmente, a maioria das pessoas possuem mais de um telefone (um celular, um residencial, etc). Sendo assim, Para atender essa necessidade temos que modelar essa realidade usando um atributo multivalorado.

A Figura 2.6 apresenta a notação para o atributo multivalorado Fones, a qual é dada por um duplo círculo

Figura 2.6 – Atributo Multivalorado Fones

Importante ressaltar que o nome do atributo mutlivalorado deve estar no plural (Fones) para indicar que ele pode assumir mais de um valor.

Os iniciantes em modelagem de dados com MER podem ter difi-culdades em abstrair, do mundo real, esse tipo de atributo, uma vez que é mais natural (para os iniciantes) modelar cada telefone como um atributo simples (fone1, fone2 ou celular, residencial) ao invés de um multivalorado. A princípio, o problema parece estar resolvido, entre-



59

tanto, é perigoso em um projeto introduzir-se uma restrição de inte-gridade tão particular, pois se as regras do negócio mudarem (isto é, passar-se a cadastrar, três ou mais telefones por pessoa), muita coisa teria que ser refeita, o que não ocorreria no caso multivalorado.

Atributo composto

O atributo composto é aquele que é formado por outros atribu-tos. Por exemplo, é comum dizer-se que um endereço é composto de “local, CEP e cidade” e que, por sua vez, um local é composto de “lo-gradouro, número e complemento”. (“Logradouro” é a nomenclatura dos Correios do Brasil, podendo ser nome de rua, praça, avenida, etc.) Isto é, dado um local, ele pode ser decomposto no logradouro, no nú-mero e no complemento. Portanto, em comparação com o que foi dito anteriormente, um endereço pode, além de ser visto como um atributo único, ser formado por outros atributos.

A Figura 2.7 apresenta uma notação (representação gráfica) para o atributo composto, o qual é representado por meio de uma estrutura em forma de árvore de dados. No exemplo, Endereço é o atributo-raiz da árvore, e Rua, Num e CEP são os atributos-folhas. Os atributos-folhas não devem ser compostos.

Figura 2.7 – Atributo Endereço composto de Rua, Num e CEP

Com essa representação, é possível referir-se ao valor do atri-buto Endereço de um determinado paciente, como um todo, suben-tendendo-se toda a estrutura, com seus vários níveis, ou seja, dado o endereço de um paciente, pode-se fazer referência ao seu CEP, Rua e Num.

Um atributo composto pode ser simples (quando possui um único



60

valor) ou multivalorado (quando possui diversos valores). Por exemplo, cada paciente, podem ter vários endereços; nesse caso, deve-se colo-car um círculo duplo no atributo raiz , no caso Endereço. A Figura 2.8 faz essa representação (note o nome agora no plural).

Figura 2.8 – Atributo Multivalorado Composto Endereços

Atributos identificadores ou determinantes

Uma restrição de integridade muito comum em conjuntos de enti-dades, devido à sua importância em todos os modelos computacionais, é um atributo monovalorado, cujo valor não pode ser repetido, ou seja, nenhuma outra entidade do conjunto pode ter um valor que pertence a outra entidade. Em outras palavras, dado um valor para esse atributo, esse valor determina a qual entidade ele está associado. Tal atributo é denominado de atributo determinante ou atributo identificador. Por exemplo, supondo no nosso estudo de caso, que daremos um “código” único para cada paciente. Dessa forma, dado um certo valor para o código de paciente, ele determinará univocamente de qual paciente se trata. Assim, o atributo código representará o atributo identificador para cada entidade do conjunto de entidades pacientes.

A notação usada para ilustrar tal atributo é uma círculo fechado (preenchido) com uma pequena linha perpendicular a reta que liga o atributo ao conjunto de entidades, conforme podemos visualizar na Figura 2.9.

Figura 2.9 – Atributo Identificador Código



61

Na prática, outros exemplos de atributos determinantes seriam o “número de matrícula” dos alunos de uma universidade, os códigos dos materiais usados em uma empresa, os códigos de seus produtos, etc. Em geral, denominaremos os atributos determinantes de “ID” eventu-almente seguido de uma qualificação. Isso porque “código” implica em alguma codificação pré-determinada.

Vários atributos podem, juntos, ser determinantes para uma en-tidade. Por exemplo, o documento de identidade (RG) das pessoas no Brasil não é um atributo determinante, pois duas pessoas podem ter o mesmo número de identidade, diferenciando-se pelo Estado. No en-tanto, se compormos o CPF com o RG conseguiremos determinar unica-mente cada entidade. Na Figura 2.10, mostramos a notação para mais de um atrubuto identificador.

Figura 2.10 – Atributo identificador IdPessoa+RG

Atributo derivado

Atributo derivado, também conhecido como calculado, é aquele cujo valor é determinado a partir do valor de outro(s) atributo(s). Por exemplo, o valor do atributo Idade pode ser calculado (ou derivado) a partir do valor do atributo Data Nascimento (Abreviado para DataNasc).

A notação que definimos para esse tipo de atributo é um asteris-co (*) ao lado do nome do atributo conforme pode ser visualizado na Figura 2.11 o atributo Idade.

Figura 2.11 – Atributo derivado Idade



62

Dicas• Se um conjunto de entidades tem um único atributo, provavel-

mente tal conjunto é atributo de um outro conjunto de entida-des. Mas há casos em que o contrário não é verdadeiro, isto é, uma coleção de atributos que dizem respeito à mesma entidade não indica que se trata dos atributos de um conjunto de entida-des, e sim um atributo composto (SETZER, 2005).

• A escolha de se representar algo como uma entidade ou como atributo é arbitrária, dependendo em geral da aplicação. Por exemplo, para uma Biblioteca, o autor de um certo livro é clara-mente um atributo desse livro. Mas para uma editora, o autor de um livro que ela publica não é simplesmente um atributo desse livro: ela encontra esse autor, combina como será o lançamen-to do livro envia-lhe direitos autorais, etc. Em geral, para uma pessoa que compra um livro ou o empresta numa biblioteca, o autor resume-se ao nome que está impresso no livro, e qualifica esse último, isto é, comporta-se como atributo do mesmo. Para a editora o autor é um ente, que existe no mundo real, com quem ela faz contatos. Para o leitor, o atributo “autor” de um li-vro resume-se ao nome, isto é, o mais indicado seria denominar esse atributo de Nome do Autor. Já para a editora, os autores devem ser representados por meio de um conjunto de entidades Autores, com vários atributos: nome, endereço, telefone, CPF, conta bancária, etc. (SETZER, 2005).

• Um atributo pode ser identificado como aquele que qualifica ou caracteriza uma entidade. Por exemplo: pessoas tem cor, altura, peso, etc, ou ainda nome, CPF, dentre outros.


1. Os nomes dos atributos devem sempre iniciar com uma letra maiúscula e estar no singular se for um atributo simples ou no plural se for um atributo multivalorado.

2. Cada atributo deve ocorrer uma única vez em apenas um con-junto de entidade.

3. Em um atributo composto, o nome dado ao atributo-raiz deve dar uma idéia significativa dos elementos de sua composição



63

e vice-versa. Por exemplo, ao vermos os atributos rua, núme-ro bairro e CEP temos a certeza que se trata de um endereço e vice-versa.

2.5 Relacionamentos e conjuntos de relacio-namentos

Um relacionamento é uma associação entre duas ou mais enti-dades.

Para esclarecer melhor vejamos o seguinte: o paciente André Luiz, é caracterizado pelos seus atributos nome, data do nascimento, sexo, endereço e telefones. Entretanto, existem outras características que são necessárias para completar a descrição de um paciente, tais como as datas das consultas realizadas por este paciente, quais médi-cos lhe atenderam, o que foi diagnosticado, etc. Nesse exemplo, estão envolvidos os conjuntos de entidades Pacientes e Médicos. A questão é onde colocaremos os dados da consulta desse paciente por qual médi-co? Obviamente, não deve ser em Pacientes, pois os dados da consulta envolvem dados do médico. Por outro lado, não cabe adicionar os dados da consulta em Médicos, pois nesse conjunto de entidades só devem constar atributos de médicos, e na cosulta há algo concernente aos pacientes.

Portanto, sempre que se fala de uma consulta, deve-se fazer re-ferência tanto a um paciente, quanto a um médico. Percebe-se, então, que os dados referentes àquela consulta devem ser colocados fora de Pacientes e de Médicos. Sendo assim, o que necessitamos é algo que represente uma associação no mundo real entre o ente-paciente, cujo nome é André Luiz, com o ente-médico, cujo nome é João de Barros.

Na realidade a ser modelada, devemos relacionar um elemento de um desses conjuntos (Pacientes) a um elemento do outro (Médicos),



64

mas esse dado não pertence diretamente nem a um nem a outro. Pelo contrário, ele é decorrência da preexistência de ambos, e ainda do fato de médicos consultarem pacientes.

Portanto, um novo conceito é introduzido, de modo que fique claro que, dados dois conjuntos de entidades como Médicos e Pacien-tes, elementos de um podem relacionar-se com elementos do outro. Tal conceito é o que conhecemos por relacionamento, o qual é repre-sentado graficamente por meio de um losango conectando um conjun-to de entidades a outro, conforme podemos ver na Figura 2.12 repre-sentando o relacionamento consulta.

Ele é denominado de conjunto de relacionamentos, uma vez que, na verdade, representa o conjunto das várias consultas realizadas pe-los diferentes médicos nos diferentes pacientes existentes. Tal como nos conjuntos de entidades, colocamos dentro do losango o nome do relacionamento, no caso consulta, indicando que pacientes foram con-sultados por médicos e médicos consultam pacientes.

O relacionamento representa o fato de elementos de um conjun-to de entidades poderem estar conectados (relacionados, associados) a elementos do outro conjunto.

Figura 2.12 – Relacionamento consulta

Dicas• Associações, geralmente, existem para permitir ações entre as

entidades. Como ações dão idéia de verbo, o nome mais adequa-do para um relacionamento deve ser derivado do verbo que indi-ca a ação representada pela associação. Por exemplo, consulta, empresta, possui etc.



65

• Pelo fato de um relacionamento poder ser lido nos dois sentidos, fica estranha a leitura de que um paciente consulta médico. Dessa forma, podemos também colocar um substantivo (no plu-ral) dentro do losango de forma a representar a ação do relacio-namento em questão. Devido, especificamente, neste exemplo não ficar visível tal diferença, damos um outro exemplo na Fi-gura 2.13(a) e 2.13(b), em que para não ficar estranha a leitura "um exame solicita médico”, trocamos a palavra “solicita pelo substantivo “solicitações”.

• Ainda pelo fato de um relacionamento poder ser lido nos dois sentidos, podemos ler, no exemplo da Figura 2.13a, médico con-sulta pacientes (no sentido médico-paciente) ou paciente é con-sultado pelo médico (no sentido inverso).

Figura 2.13(a) – Relacionamento solicita

Figura 2.13(b) – Relacionamento solicitações


Um relacionamento pode ser de 2 tipos: total ou parcial.

a) Relacionamento total - Um relacionamento total é aquele que exige a existência de uma ligação entre as entidades envolvidas, ou seja, toda vez que houver a necessidade de se armazenar dados de uma entidade juntamente com os dados do relacionamento, este deve ser do tipo total.

b) Relacionamento parcial – Ao contrário do relacionamento to-tal, o relacionamento parcial não exige a existência de uma ligação entre as entidades, ou seja, a ligação é opcional.

Para exemplificarmos esses dois tipos de relacionamento, con-



66

sideremos, ainda no cenário da clínica, que um médico pode ou não realizar consultas, ou seja, dado o conjunto de médicos cadastrados podem ter casos de médicos que nunca realizaram consultas (claro que é um exemplo!), porém um paciente só pode ser cadastrado no sistema se tiver uma consulta marcada. Sendo assim, dizemos que o relacio-namento no sentido de médico para paciente é parcial e de paciente para médico é total.

A Figura 2.14 apresenta este exemplo, em que um círculo preen-chido representa o relacionamento total do lado paciente.

Figura 2.14 – Relacionamento parcial e relacionamento total.

2.5.2 Multiplicidade de relacionamentos

A multiplicidade (também chamada de cardinalidade) do relacio-namento indica uma restrição de integridade quanto ao número (quan-tidade) de entidades que uma entidade de um determinado conjunto pode se relacionar com outra de outro conjunto.

Multiplicidade 1:1

Diz-se que um relacionamento tem cardinalidade 1:1 (lê-se um para um) quando uma entidade de um determinado conjunto só pode se relacionar com, no máximo, uma entidade de outro conjunto. Pode-mos exemplificar tal fato, usando nosso estudo de caso e supondo que cada médico só pode ter uma única especialidade e cada especialidade só pode ser de um médico. No mundo real, é como se nessa clínica só existisse um oftalmologista, um cardiologista e assim por diante.

Portanto, dado um determinado médico do conjunto de entida-des Médicos este só pode efetuar consulta em uma especialidade. A



67

Figura 2.15 ilustra em termos de conjuntos como é feita essa relação e a Figura 2.16 ilustra a devida representação no MER.

Figura 2.15 – Multiplicidade 1:1

Figura 2.16 – Multiplicidade 1:1

Leitura do exemplo de cardinalidade 1:1: cada médico possui uma especialidade e cada especialidade pertence a um único médico.

Multiplicidade 1:N

Diz-se que um relacionamento tem cardinalidade 1:N (lê-se um para muitos) quando uma entidade de um determinado conjunto pode se relacionar com até N entidades de outro conjunto. Podemos tomar o exemplo anterior, agora supondo que cada médico só pode ter uma única especialidade, porém uma especialidade pode ser de vários mé-dicos, ou seja, um médico só pode ser ou ortopedista ou oftamologista (nunca ambos), entretanto, a clínica pode ter mais de um oftamolo-gista, mais de um ortopedista etc. A Figura 2.17 ilustra em termos de conjuntos como é feita essa relação e a Figura 2.18 ilustra a devida representação no MER.

A cardinalidade 1:N refere-se, obviamente, ao sentido em que se leem os relacionamentos. Pode-se dizer que “possuem” é N:1 (muitos



68

para um) no sentido de Médicos para Especialidades e 1:N no sentido de Especialidades para Médicos, pois o significado é o mesmo.

Leitura do exemplo de cardinalidade N:1: cada médico possui apenas uma especialidade, mas cada especialidade pode pertencer a vários (mais de um) médico.

Figura 2.17 – Multiplicidade N:1

Figura 2.18 – Multiplicidade N:1

Multiplicidade N:M

Finalmente, notamos também nos diagramas ER os relacionamen-tos sem restrição de multiplicidade: são os casos N:M (“muitos para muitos”). Um exemplo é o da Figura 2.19, em que um médico pode consultar vários pacientes e um paciente (no decorrer do tempo) pode ser consultado por vários médicos. Para seguir os exemplos anteriores, também é mostrado na Figura 2.20 a representação em conjuntos.

Só para fixar um pouco mais as idéias, vamos exemplificar as três multiplicidades com um caso social. Considerando os dois conjuntos de entidades Homens e Mulheres e um relacionamento Ligações asso-



69

ciando elementos de um com elementos do outro, temos os seguintes casos: 1:1 — monogamia; 1:N — poligamia ou poliandria (dependendo do lado 1 e do lado N); N:M — “amizade colorida”.

Por questões de convenção, muitas vezes usamos a notação N:N quando se trata de um relacionamento N:M.

Leitura do exemplo de cardinalidade N:M: cada médico pode possuir várias especialidades, e cada especialidade pode pertencer a vários médicos.

Figura 2.19 – Multiplicidade N:M

Figura 2.20 – Multiplicidade N:M

A multiplicidade pode também ser modelada representando os limites mínimo e máximo das associações que cada entidade pode ter



70

com outra. A Figura 2.21 ilustra essa representação em que o limite mínimo é posicionado à esquerda (da vírgula) e o máximo é posiciona-do à direita.

Leitura do exemplo de cardinalidades com limites: um médico pode ter no mínimo uma especialidade e no máximo N. Por outro lado, uma especialidade pode pertencer a, no mínimo, nenhum médicos e no máximo um.

Ressalta-se também que o valor N, em alguns casos, pode ser explicitado. Por exemplo, a Figura 2.22 apresenta o caso em que um médico pode ter no máximo 3 especialidades.

Figura 2.21 – Limites de cardinalidade.

Figura 2.22 – Limite máximo explícito.

2.5.3 Atributos de relacionamentos

No mundo real, existem situações para as quais necessitamos armazenar dados que, apesar de envolverem entidades, tais dados não pertençam as mesmas. Vejamos um exemplo: Para cada consulta rea-lizada entre o médico e o paciente é necessário saber qual a data da mesma e qual o diagnóstico dado. Como podemos ver, a data e o diag-nóstico não podem ser modelados como relacionamentos, uma vez que



71

representam uma característica e não uma ação dessas entidades. Por representarem uma qualificação, tanto data quanto diagnóstico podem ser identificados como atributos. Entretanto, os mesmos não podem ser atributos nem de Pacientes nem de Médicos, pelo fato de que data de consulta e diagnóstico não são características dessas entidades.

Portanto, data e diagnóstico são, claramente, atributos do re-lacionamento consultas, já que descrevem explícitamente a data da consulta e o diagnóstico dado na mesma. A Figura 2.23 apresenta este exemplo.

Figura 2.23 – Atributos do relacionamento.

Dica:

• Os atributos data e diagnóstico, além de caracterizar cada con-sulta realizada por um médico em um paciente, serve também de histórico, ou seja, com o passar do tempo o sistema modela-do terá armazenado todas as consultas realizadas, com suas res-pectivas datas, diagnósticos, médicos e pacientes. Sendo assim, supondo que você (equivocadamente) modelasse tais atributos na entidade Pacientes, tais atributos só teriam armazenados os últimos valores cadastrados e não o histórico ao longo do tempo, ou seja, a cada nova consulta e/ou diagnóstico este sobreporiam os valores antigos. Desa forma, de acordo com a regra de negó-cio, pode ser que atributos identificados como de relacionamen-to também possam ser modelados numa entidade específica.

2.5.4 Auto-relacionamento

O auto-relacionamento implica em um relacionamento de uma entidade de um conjunto com outra do mesmo conjunto. Para ilustrar



72

melhor tal fato, usaremos um exemplo de um sistema de uma em-presa, em que é necessário armazenar dados sobre os funcionários e seus supervisores. Ora, um supervisor é também um funcionário, sendo assim, deverá ser feito um relacionamento entre o conjunto de entida-des Funcionários com ele próprio.

Ressaltamos que, embora a representação do relacionamento seja no conjunto de entidades, na realidade ele está associando duas entidades dentro do conjunto, ou seja, este relacionamento é entre uma entidade de um conjunto com outra entidade do mesmo conjun-to, e não de uma entidade com ela própria, como equivocadamente muitas pessoas dizem.

Além disso, em um auto-relacionamento é de suma importância que sejam explicitados os papéis que cada entidade deverá assumir. Tal importância se dá pela necessidade de se definir as cardinalidades do relacionamento. A Figura 2.24 apresenta um auto-relacionamento no conjunto de entidades Funcionários, além dos papéis de supervisor e supervisionados, em que um supervisor pode ter N (muitos, vários) subordinados e um funcionário só pode ter um supervisor.

Figura 2.24 – Auto- relacionamento



73

Dica:

• Em geral, todos os auto-relacionamentos têm papéis diferen-ciados. Se em um projeto de modelo conceitual aparecer um auto-relacionamento sem papéis diferenciados, deve-se tomar cuidado, pois talvez haja uma falha de projeto (SETZER, 2005).

2.5.5 Grau do relacionamento

O grau de um relacionamento é dado pela quantidade de conjun-to de entidades por ele envolvidas. Dessa forma, o menor grau de um relacionamento no MER é o grau dois ou binário (inclusive para auto-relacionamentos).

Alguns graus de relacionamento recebem nomes especiais, são eles: binário para grau dois; ternário para grau três e quaternário para grau quatro. A partir daí, diz-se grau cinco, grau seis, e assim por dian-te.

Os relacionamentos com grau maior que dois são chamados de relacionamentos n-ário (lê-se “enários”), os quais serão detalhados na próxima seção.

2.5.6 Relacionamentos n-ários

Conforme descrito na seção anterior, os relacionamento n-ários são aqueles que possuem o grau maior que dois, ou seja, contemplam mais de duas entidades.

O fator determinante do grau do relacionamento é a regra de ne-gócio, ou seja, dependendo do controle que se deseja ter sobre deter-minados dados podemos usar ou não relacionamentos com grau maior que dois (n-ários). Vale ressaltar que tais relacionamentos garantem uma maior integridade dos dados conforme detalharemos a seguir.

Suponha que ao realizar uma consulta em um paciente um médi-co sempre faça uso de alguma ferramenta, e que é importante que o sistema forneça, além do médico e paciente consultado, informações



74

sobre qual(is) o(s) equipamento(s) utilizado(s) na referida consulta. A Figura 2.25 apresenta uma solução de modelagem para esta situação. Entretanto, considerando que um médico efetua consulta em vários pacientes, e que pode usar vários equipamentos na mesma consulta, tal modelagem deixa a desejar quanto a disponibilidade de informa-ções, uma vez que para sabermos exatamente qual o equipamento usado por um determinado médico em uma consulta a um paciente específico, teremos que “varrer” todos os relacionamentos e cruzar as informações para se chegar a um denominador comum, o que acarre-tará em um custo desnecessário. Além disso, se for digitado um valor errado em um dos relacionamentos fica quase impossível fazer esse cruzamento.

Em termos práticos, vejamos o seguinte: O Dr. Barros consultou no dia 14/06/2008, os pacientes Pedro, José e Marcos e usou para consultar todos os casos o equipamento medidor de pressão, sendo que para o paciente Marcos, além desse, usou também o termômetro e estetoscópio. Suponha também que José e Marcos foram também con-sultados na mesma data pelo Dr. Silveira, o qual usou os equipamentos medidor de pressão e termômetro em ambos.

Suponha agora a necessidade de uma consulta para saber qual o equipamento usado pelo Dr. Barros no paciente José? Para se obter o resultado satisfatório e consistente (se é que é possível) dessa consulta teremos que buscar a data da consulta do Dr. Barros no paciente José no relacionamento consultam, depois buscar os equipamentos usados no paciente José naquela data (o que trará os equipamentos usados pelos dois médico), em seguida verificar no relacionamento usam quais equipamentos usados pelo Dr. Barros também naquela data. Dessa for-ma, chegaremos ao resultado dos equipamentos medidor de pressão, termômetro e estetoscópio, o qual deverá ser cruzado com os equi-pamentos usados em José para somente assim chegarmos na resposta desejada. Entretanto, se em um do relacionamento for colocado uma data equivocada teremos tal cruzamento não poderá ser realizado.



75

Figura 2.25 – Três relacionamentos binários.

Considerando que toda vez que um médico realiza uma consulta ele deve fazer uso de, no mínimo, um equipamento, a solução mais correta para esta realidade seria um relacionamento ternário (ver Fi-gura 2.26), uma vez que este já deixaria “amarrado” o médico, o pa-ciente e o equipamento usado em um único relacionamento. Tal solu-ção responderia, sem muito custo, à consulta solicitada no parágrafo anterior.

Figura 2.26 – Relacionamento ternário “consultam”.

Importante ressaltar que os relacionamentos n-ários podem tam-bém estar associados a um auto relacionamento. A Figura 2.27 apre-senta um exemplo de um auto-relacionamento ternário, corresponden-do ao contexto de equipamentos (computadores, impressoras, etc.) que são transferidos de um setor para outro, fazendo-se necessário



76

armazenar, além do setor origem e destino, a data e o motivo da trans-ferência.

Leitura: a Figura 2.27 pode ser lida como Um equipamento pode ser transferido de um setor para vários setores, armazenando a data e o motivo da transferência.

Figura 2.27 – Auto-relacionamento ternário.

Sendo assim, para cada ocorrência (instância) de “transferência” haverá o código do setor origem, o código do setor destino, o código do equipamento, a data e o motivo.

Os diagramas ER representam a primeira etapa de um projeto de Banco de Dados. Sendo assim, para fazermos um projeto de BD primeiramente fazemos a modelagem dos dados cujo resultado pode ser o DER (Diagrama Entidade Relacionamentos) se for usado o Mode-lo Entidade Relacionamento ou ainda um Diagrama de Classes se for usado o Modelo Orientado a Objetos, em seguida o diagrama deve ser mapeado, ou seja, deve ser passado para outro modelo que permita que os dados modelados possam ser implementados. Geralmente, o mapeamento é feito para o Modelo Relacional (ver Capítulo 3), o qual é um dos sistemas mais implementados e usados nas mais diversas áreas de atuação, cujo elemento principal é denominado de tabela.

Fizemos esses esclarecimentos para que o leitor entenda que após completar a modelagem de dados de um sistema, o mesmo deve ser mapeado para um modelo que permita sua implementação. Por exemplo, imagine que um cliente solicita a construção de uma casa,



77

o responsável pela construção (arquiteto) deverá ter várias reuniões com esse cliente até que sejam definidos os detalhes do que ele real-mente deseja e necessita na casa. Nessa fasse, o importante é O QUE o cliente quer. Uma vez decidido sobre O QUÊ deverá conter a casa (quantos cômodos, varandas, banheiros, etc.) o projeto passa para a faze de COMO deverá ser feito. Para tanto, são necessários detalhes tais como altura, largura, comprimento de cada cômodo; tamanhos e posicionamento das janelas, portas, basculantes, enfim tudo o que realmente seja necessário definir para dar suporte e condições de que a casa seja construída.

Analogamente, o projeto de banco de dados também é feito as-sim. Primeiramente, deve ser feita a modelagem dos dados, na qual são definidos QUAIS os dados deverão ser armazenados no banco de dados e, posteriormente, fazemos o mapeamento para que possamos definir COMO esses dados serão armazenados (definidos o tamanho, se é um campo obrigatório ou não, se ficará em uma ou mais tabelas, etc). Tal mapeamento é necessário porque o MER não dá suporte à defi-nição de detalhes como tipo e tamanho para implementação do banco de dados. Dessa forma, existem regras de mapeamento que podem ser encontradas nas literaturas correntes, dentro dessa área.

Portanto, seguindo a regra de mapeamento, o diagrama da Figu-ra 2.27 seria mapeado em 3 tabelas: tabela Setores e Equipamentos (oriundas da entidade forte que é mapeada como tabela) e a tabela Transferencia (oriunda do relacionamento n-ário que também é ma-peado como tabela). E, conforme explicado anteriormente, a tabela Transferencia conterá como atributos: código do setor origem, código do setor destino, código do equipamento, data e motivo. E embora te-nha duas vezes o atributo código do setor, uma tabela não pode conter mais de um atributo com o mesmo nome. Portanto, embora oriundo da mesma chave primária na tabela setores, na tabela Transferencia o nome, de pelo menos um, deve ser mudado.

Na Figura 2.28(a) apresentamos um mapeamento feito de forma incorreta, pois não houve a troca do nome do atributo codigo_setor. Já na Figura 2.28(b) o mapeamento foi feito corretamente, alterando-se o nome do atributo código_setor.



78

Tabela: TRANSFERENCIA

Codigo_Setor Codigo_Setor Codigo_Equi-pamento Data Motivo

10 11 201 01/10/07 Empréstimo

20 10 202 16/11/07Será usado na reunião com a

direoria

Figura 2.28(a) – Mapeamento incorreto do atributo codigo_setor da tabela “Setores”

Tabela: TRANSFERENCIA

Codigo_Se-tor_Origem

Codigo_Se-tor_Destino

Codigo_Equi-pamento Data Motivo

10 11 201 01/10/07 Empréstimo

20 10 202 16/11/07Será usado na reunião com a

direoria

Figura 2.28(b) – Mapeamento correto do atributo codigo_setor da tabela “Setores”


1. Usar para o nome de um conjunto de relacionamentos, sempre que possível, um substantivo derivado do verbo que indique a ação permitida pela associação entre as entidades envolvi-das.

2. O nome dos conjuntos de relacionamentos deve iniciar com letra minúscula e estar no plural.

3. Não repetir nome de relacionamento no mesmo diagrama, pois este deve ser único.

4. Sempre explicitar os papéis de um auto-relacionamento para que se possa validar a cardinalidade.

5. Sempre explicitar as cardinalidades em um diagrama.

6. Não é permitido fazer relacionamento entre relacionamen-tos.

7. O grau mínimo permitido em um relacionamento é dois (biná-rio).

8. Atributos identificadores não são permitidos em relaciona-



79

mentos, pois são exclusivos de entidades.

9. Todo relacionamento binário N:N possui, no mínimo, dois atri-butos implícitos, dados pelos identificadores oriundos das en-tidades envolvidas.

10. Todo relacionamento n-ário possui implicitamente os atribu-tos determinantes oriundos das entidades envolvidas.

11. Nos relacionamentos 1:N ou N:1 a entidade cuja cardinalida-de é N terá implicitamente o atributo identificador oriundo da entidade cuja cardinalidade é 1.

12. Nunca definir um atributo em um relacionamento se este fizer parte de uma entidade que não esteja envolvida no refe-rido relacionamento.

2.6 Agregações

A agregação é uma solução para a restrição do MER de não permi-tir relacionamento entre relacionamentos. Para melhor entendermos esse conceito, ilustramos na Figura 2.29 a situação em que um médico consulta um paciente e solicita exames. Tal modelagem é equivoca-da, pois nem toda vez, em uma consulta, há solicitação de exames, e o relacionamento ternário exige o envolvimento das três entidades (obrigatoriedade).

Dessa forma, uma outra solução seria dada pela Figura 2.30, que embora fosse mais próxima da realidade, pois poderíamos dizer que o médico consulta o paciente e, a partir da mesma, pode solicitar exames, tal representação não é permitida pela restrição de integri-dade do modelo no que diz que só pode existir relacionamento entre entidades e não entre relacionamentos.



80

Figura 2.29 – Médico consulta paciente e solicita exame

Figura 2.30 – Relacionamento entre relacionamentos consulta e solicita

Uma forma alternativa de modelarmos essa situação também é mostrada na Figura 2.31, mas isso pode trazer um problema de incon-sistência uma vez que não “amarra” em qual consulta foi solicitado o exame.



81

Figura 2.31 – Relacionamentos binários para Consulta e solicitação de exames

A Figura 2.32 apresenta agora a forma correta de modelarmos a solicitação de um exame a partir de uma consulta usando agregação, a qual é criada agrupando-se o relacionamento consultas e “tranfor-mando-o” em uma nova entidade.

Figura 2.32 – Relacionamentos com agregação

Na prática, em geral não é necessário dar nome para a agrega-ção, pois basicamente ela representa o relacionamento. Sendo assim, no exemplo dado na Figura 2.32, a agregação gerada pode ser chamada de “consultas” (nome do relacionamento) a qual se associa com a en-



82

tidade EXAMES por meio do relacionamento “solicitações”.

Algumas observações gerais sobre agregações:

a) Agregações envolvendo relacionamentos 1:N não fazem sen-tido, pois nesse caso cada entidade do lado N já indica, por meio do relacionamento, com qual entidade do lado 1 está relacionada. Nesses casos, sugerimos que se faça o relaciona-mento com a entidade cuja cardinalidade é N.

b) Não há muito sentido em se falar de atributos de uma agre-gação. Na verdade, esses atributos pertencem aos conjuntos das entidades relacionadas na agregação, mais os atributos do relacionamento que ela engloba, isto é, todos os atributos de todos os conjuntos agregados.

c) Nada impede de se fazer uma agregação envolvendo mais do que dois conjuntos de entidades relacionados por um rela-cionamento (relacionamentos com grau maior que dois), mas ressaltamos que só pode haver um relacionamento em uma agregação.

d) As entidades dentro da agregação podem se relacionar, nor-malmente, com outras entidades, para isso, a linha do rela-cionamento deve ultrapassar os limites da agregação.

e) O conceito de agregação é uma extensão ao modelo original de Peter Chen, normalmente denominado de MERE (Modelo Entidade Relacionamento Estendido).

f) Finalmente, em lugar de se representar a agregação como um retângulo envolvendo o relacionamento e os seus conjuntos de entidades, podemos usar uma notação alternativa colocan-do-se um retângulo envolvendo somente o relacionamento, conforme exemplificamos na Figura 2.33. A vantagem dessa representação é que, por ser mais compacta, não sobrecarre-ga tanto um diagrama quanto a anterior. Além disso, mostra explicitamente que a agregação é aplicada no relacionamen-to. Entretanto, muitos preferem o retângulo envolvendo tam-bém as entidades, sempre que possível, pois é mais represen-



83

tativo no fato de a agregação envolver também os conjuntos de entidades.

Figura 2.33 – Representação gráfica alternativa para agregação

Leitura: A leitura de uma agregação é feita de “dentro pra fora”, ou seja, lê-se primeiro o relacionamento dentro da agregação para em seguida ler o que está fora da mesma. Sendo assim, no exemplo das Figuras 2.32 e 2.33 a leitura é feita da seguinte forma: médicos con-sultam pacientes e, a partir dessas consultas, podem ou não solicitar exames.

Os iniciantes no uso do MER, normalmente, questionam o que se pode e o que não se pode modelar com uma agregação. Dentre es-sas dúvidas, uma muito comum diz respeito aos auto-relacionamentos. Portanto, a seguir faremos algumas considerações de agregações en-volvendo os mesmos.

a) Uma agregação em um auto-relacionamento segue as mesmas regras de um relacionamento comum, ou seja, dependendo da cardinalidade podemos agregar ou não. Se for N:N sim, caso contrário, na maioria das vezes não.

b) Uma agregação pode ter auto-relacionamento com uma das entidades envolvidas. A Figura 2.34 apresenta uma nova ver-são do exemplo dado na seção 2.5.6 (Figura 2.27), em que



84

equipamentos são alocados em setores, tais equipamentos podem, posteriormente, serem transferidos para outros se-tores, para isso, é necessário saber, além do setor de origem, o setor destino, a data, o motivo e o funcionário que efetuou a transferência. Observe que o setor origem é dado no rela-cionamento “alocados” e o setor destino no relacionamento “transferidos”.

Figura 2.34 – Uma agregação se auto-relacionando com uma das entidades por ela envolvida

Outra dúvida comum, é se a entidade gerada a partir de uma agregação pode ou não ter uma entidade fraca como sua dependente. Quanto a isso não há restrições, enfatizamos, novamente, que a mode-lagem depende da realidade observada e de sua relevância no modelo criado.


1. Evite (para não dizer nunca) projetar uma agregação de um conjunto de relacionamentos de multiplicidade 1:N ou 1:1.

2. Nunca modele atributos em uma agregação.



85

2.7 Especializações e generalizações de con-juntos de entidades

O conceito de generalização e especialização é muito conhecido como herança. De um modo prático herança é tudo aquilo que pode ser passado de pai para filho, ou seja, dada uma característica dos pais, estas podem ser transmitidas aos seus filhos. Por exemplo, a cor dos olhos, altura, cor da pele, entre outras. No modelo ER há tam-bém o conceito de herança, em que um entidade pode herdar tanto as características quanto as associações de uma outra entidade. Além disso, as entidades-filhas podem possuir características (atributos) e associações própras.

O MER usa herança através de dois conceitos, a saber:

• Generalização – dizemos que ocorre uma generalização quando todas as entidades de nível superior (superclasse) pertencem a alguma entidade do nível inferior (subclasse), ou seja, não existe qualquer entidade dentro do conjunto de entidades-mães que não estejam em, pelo menos, uma entidade-filha.

• Especialização - dizemos que ocorre uma especialização quan-do existe, pelo menos, uma entidade de nível superior que pertence a nenhuma entidade do nível inferior, ou seja, existe alguma entidade dentro do conjunto de entidades-mães que está em nenhuma entidade-filha.

A Figura 2.35 apresenta um exemplo de uma generalização, em que cada entidade do conjunto de entidades pessoas ou é uma pessoa física ou é uma pessoa jurídica.



86

Figura 2.35 – Exemplo de Generalização

Por outro lado, a Figura 2.36 apresenta um exemplo de uma es-pecialização, em que podemos observar que algumas entidades do con-junto do nível superior (PROFESSOR) pertencem a nenhuma entidade de nível inferior (ESPECIALISTAS, MESTRES E DOUTORES).

Figura 2.36 – Exemplo de uma Especialização.



87

Alguns autores definem os conceitos de generalização e espe-cialização como algo que depende do ponto de origem da modelagem, ou seja, se for identificado primeiro a entidade mais genérica e depois for percebido a necessidade de subdividir a mesma em outras cate-gorias, diz-se que houve uma especialização, e quando se identifica primeiramente as entidades específicas (filhas) para depois identificar a mais genérica (mãe), diz-se que se que houve uma generalização. Outros autores defendem que não há diferença entre as duas e que, considerar uma generalização ou especialização depende do sentido da leitura. Ou seja, de cima para baixo tem-se uma especialização e de baixo para cima uma generalização.

Algumas observações sobre heranças:

a) A herança do MER lembra o conceito de herança do paradigma orientado a objetos. No entanto, no MER tratamos apenas dos dados não sendo considerado suas operações (métodos).

b) Conforme dito anteriormente, as entidades de nível inferior herdam tanto atributos quanto relacionamentos das entidades de nível superior. Na Figura 2.37 podemos observar que todos os funcionários da clínica (médicos e atendentes) são lotados em setores. Dessa forma, o relacionamento “lotado” liga o conjunto de entidades SETORES diretamente ao conjunto de entidades de nível superior FUNCIONÁRIOS, tal associação é herdada por médicos e atendentes, ou seja, tanto médicos quanto atendentes são lotados em algum setor.

c) Quando um relacionamento é específico de apenas uma das entidades de nível infeiror, deve-se se associar apenas esta. A Figura 2.38 apresenta o exemplo em que as especialidades dos médicos (neurologia, pediatria, etc.) devem ser registra-das (armazenadas) no sistema. Sendo assim, o relacionamento possuem liga o conjunto de entidades ESPECIALIDADES direta-mente ao conjunto de entidades de nível inferior MÉDICOS.

d) Relacionamentos entre entidades da superclasse e alguma entidade da subclasse representam auto-relacionamentos da superclasse.



88

Figura 2.37 – Relacionamento com a entiadade de nível superior.

Figura 2.38 – Relacionamento específico com entiadade de nível inferior.

e) As entidades de nível inferior podem se relacionar entre si, conforme podemos ver no relacionamento casamento entre o conjunto de entidades HOMENS e MULHERES da Figura 2.39.

Figura 2.39 – Relacionamento entre entidades de nível inferior.



89

2.7.1 Restrições de herança

Restrições de herança são regras de integridade que definem a participação dos membros da entidade de nível superior (superclasse) nas entidades de nível inferior (subclasses). Tais restrições podem ser de três tipos: restrição de disjunção, restrição de completude e restri-ção por atributo.

Restrição de disjunção (disjoin) – define se um membro da su-perclasse pode participar de uma ou mais subclasse. Está subdividida em:

• Disjunção (disjointness) – define que um membro da super-classe só pode participar em, no máximo, uma subclasse. Em outras palavras, representa um OU EXCLUSIVO em que o mem-bro da superclasse participa (pertence) ou a uma subclasse ou a outra nunca a ambas. A Figura 2.40 exemplifica essa abstra-ção, em que uma pessoa só pode ser do tipo Física ou Jurídi-ca, jamais as duas. Sua notação é a letra “d” em minúsculo dentro do círculo.

• Sobreposição (overllaping) – ao contrário da disjunção, permi-te que um membro da superclasse participe de mais de uma subclasse. Por exemplo, na Figura 2.41 um professor pode ser tanto mestre, quanto doutor e ainda especialista. A notação é dada pela letra “o” dentro do círculo.

Figura 2.40 – Restrição de disjunção



90

Figura 2.41 – Restrição de sobreposição

Restrição de completude – define se um membro da superclasse pode participar ou não de uma subclasse. Está classificada em:

• Total – define que todos os membros da superclasse devem pertencer a alguma subclasse. Em outras palavras, uma res-trição do tipo total nada mais é do que uma generalização. Sua notação são duas retas paralelas saindo da superclasse até o círculo (ver Figuras 2.35 e 2.40).

• Parcial – define que os membros da superclasse podem ou não pertencer a alguma subclasse, ou seja, pode existir uma enti-dade na superclasse que não esteja em nenhuma subclasse, o que nos faz lembrar o conceito de especialização. As Figuras 2.36 e 2.41 representam que um professor pode ser um espe-cialista, um mestre ou um doutor. Entretanto, pode ser que tenhamos um professor qualquer que tenha pós-doutorado ou somente graduação, o qual vai estar apenas na superclasse. Sua notação é uma reta saindo da superclasse até o círculo.

Vale ressaltar que a restrição de completude (total ou parcial) é independente da restrição de disjunção, pois podemos ter as seguintes combinações: parcial com sobreposição, parcial com disjunção, total com disjunção e total com sobreposição. Em suma, as retrições de-disjunção e completude são ortogonais.

Restrição por atributo – é identificada quando as entidades de nível inferior não possuem atributos específicos, sendo necessário ape-nas um valor de atributo para diferenciá-las. Por exemplo, a Figura 2.42



91

apresenta um exemplo em que a classe de nível superior PESSOA pode ser uma criança, um adolescente, um jovem ou um adulto, entretanto, qualquer um deles terão exatamente os mesmos atributos de “pes-soa”, porém o valor do atributo “faixa-etária” deverá ser diferente para cada um deles.

Note que, o atributo cujo valor fará a diferença nas entidades de nível inferior deve ficar posicionado logo abaixo da entidade superior, e não deve aparecer como atributo da mesma.

Na Figura 2.43 apresentamos outro exemplo de restrição por atri-buto, em que a superclasse PESSOAS pode ser classificada em HOMENS ou MULHERES. Considerando que não haverá atributos para diferenciá-las pois tanto homens quanto mulheres possuem nome, CPF, telefone, endereço, altura, peso, etc., então foi definido o atributo SEXO cujo valor fará com que as entidades do conjunto PESSOAS sejam definidas como HOMENS ou MULHERES.

Figura 2.42 – Exemplo 1 de herança por atributo

Figura 2.43 – Exemplo 2 de herança por atributo



92

Importante observarmos que no exemplo ilustrado pela Figura 2.42, temos uma especialização, pois existem outras classes definidas por outras faixas-etárias que não estão representadas pelas subclasses (terceira idade e pré-adolescência). Já no exemplo da Figura 2.43 te-mos uma generalização, uma vez que não existe pessoa que não seja, biologicamente, do sexo masculino (homens) ou do sexo feminino (mu-lheres).

Dicas gerais:• Ao identificar uma entidade forte pergunte se ela existe por si

só, em seguida verifique se ela possui um atributo identificador, e depois se ela possui um conjunto de atributos próprios para caracteriza-la, se o resultado for positivo para as três suposi-ções, seguramente podemos definir tal entidade no modelo.

• Ao identificar um atributo em um relacionamento que pertence a alguma entidade do diagrama que não está envolvida no rela-cionamento, retire o atributo e inclua a entidade no relaciona-mento.

• Um relacionamento pode possuir atributos implícitos, os quais são oriundos dos atributos determinantes das entidades envol-vidas

• Em uma abstração de herança (generalização/especialização) as entidades de nível inferior (subclasses) herdam atributos e relacionamentos das entidades de nível superior. Entretanto, os atributos e relacionamentos das subclasses pertencem somente a elas próprias.

• Se ao identificar uma herança, a leitura não puder ser feita usando o termo “é um” ou “é uma” ou ainda “pode ser um ”ou “pode ser uma”, com certeza não estamos diante de uma he-rança.

• Evite usar termos tais como tabelas, chave estrangeira, pois tais conceitos pertencem a outro modelo de dados (Modelo Relacio-nal), o qual pertente a um nível mais baixo que o conceitual (ní-vel lógico ver seção 1.3). Além disso, as entidades identificadas no diagrama devem ser de mais alto nível possível, uma vez que, neste nível, o importante é identificar quais os dados estão no banco de dados e não como estão no banco de dados.



93

• A modelagem de um sistema deve atender ao escopo principal do sistema. Por exemplo, no sistema da Clínica, embora o con-trole de acesso seja necessário, ele não faz parte do escopo principal que são as consultas, solicitações de exame, pacien-tes, médicos, etc.

• É comum as pessoas confundirem as entidades do MER com tabe-las do Modelo Relacional, ou ainda com classes do MOO (Modelo Orientado a Objetos). Por exemplo, no sistema da Clínica Médi-ca algumas pessoas podem identificar consultas como entidade quando na verdade é um relacionamento, haja vista que a con-sulta não existe por si só, e é necessário a relação entre médico e paciente para que ela ocorra. Sendo assim, mesmo que o rela-cionamento consultas seja mapeado para uma tabela no Modelo Relacional (ou uma classe no MOO), no MER ela é representado por um relacionamento.

• O projetista de banco de dados tem que focar o nível conceitual, não se importando com detalhes de implementação pois o DER será mapeado para o nível lógico (tabelas) e depois poderá pas-sar pelo processo de normalização tantos nas entidades quanto (principalmente) nos relacionamentos.

A seguir, a Figura 2.44 apresenta um diagrama completo da Clíni-ca Salva Vidas feito mediate o software BrModelo, com algumas adap-tações para atender a nomeclatura usada neste livro.



94

Figura 2.44 – Diagrama Geral da Clíca Salva Vidas

Observe, que as duas agregações no diagarama podem parecer complexas, mas não podemos esquecer que a leitura de um relaciona-mento com uma agregação deve ser feita de dentro para fora. Dessa forma, devemos seguir a seguinte ordem: primeiramente, o relacio-namento possuem, depois o relacionamento consultam seguido do relacionamento solicitações. Portanto, a leitura correta será: médicos possuem especialidades e podem (opcionalidade da agregação) con-sultar pacientes, a partir dessas consultas podem ou não solicitar exa-mes.



95

2.8 Resumo

O Modelo Entidade Relacionamento (MER), introduzido por Peter Chen em 1976, é um modelo de dados que pertence ao nível concei-tual.

As principais abstrações (elementos) do MER são: entidades, re-lacionamentos e atributos. Posteriormente foram adicionadas as abs-trações de herança e agregação, no que se denominou Modelo Entida-de Relacionamento Estendido (MERE).

O MER representa uma forte ferramenta para modelar os dados de sistemas de informação, preocupando em mostrar quais os dados estão armazenados no banco de dados, sem considerar como estão armazenados.



96

Exercícios

1. Com base na descrição dos sistema da seção 2.2 faça a modelagem completa do mesmo.

2. Idenfique no DER do estudo de caso os possíveis relacionamentos totais e parciais.

3. Quais dos casos seguintes prestam-se a ser modelados como auto-relacionamento? Modele todos, e escolha atributos convenientes para os auto-relacionamentos: matérias de um curso superior e seus pré-requisitos; partes de edifícios (andares, saguões, salas, etc.), parentesco entre pessoas; capítulos e seções de capítulos de livros; projetos e subprojetos; países, estados, cidades, bairros e logra-douros (ruas, praças, etc.); mapas e regiões de mapas; organogra-mas de empresas; hierarquias militar e de ordens religiosas.

4. Faça a modelagem de dados dos seguintes sistemas:

Sistema 1:

O sistema tem como objetivo principal armazenar árvores genea-lógicas de forma que qualquer indivíduo possa obter informações sobre suas origens.

O sistema deverá registrar as pessoas, definidas somente como homens ou mulheres, as quais aparecem em alguma geração da arvo-re. Uma geração é um vínculo de um casal genitor heterossexual de pessoas com as várias outras que são seus descendentes diretos (i.e., os filhos, caso existam). Estas pessoas descendentes, da mesma forma que seus ascendentes, poderão formar outros casais e, possivelmente, outras gerações na mesma árvore.



97

Para cada pessoa, e necessário saber o sexo, a data de nasci-mento, o nome, o sobrenome e uma coleção de características que ela possui, sendo que cada característica é composta por uma descrição e seu respectivo valor (por exemplo, a descrição 'cor dos olhos' e o valor 'verde'). Já para o casal é importante saber em que data foi selada a sua união.

O diagrama deverá representar a maior quantidade possível de informações descritas para este sistema, usando os mecanismos de modelagem já aprendidos.

Sistema 2:

Uma empresa de TV à cabo necessita informatizar alguns dos seus serviços de forma a atender as seguintes necessidades: O sistema deverá controlar o cadastro dos clientes, pacotes (família, adulto, in-fantil, cinema, etc), da programação (filmes, horários, etc) e do paga-mento de mensalidades.

Cada pacote possui um preço e o cliente pode escolher uma combinação dos mesmos, podendo mais tarde adicionar mais pacotes se assim o desejar. O valor de sua mensalidade corresponde ao valor total dos pacotes e seu vencimento será, todos os meses, no dia em que comprou o primeiro pacote. O cliente poderá também escolher a quantidade de tv's para instalação do cabo, e a cada 2 tv's ele paga um adicional em sua mensalidade.

Cada pacote possui um conjunto de canais exclusivos. Um canal é identificado por um número e seu nome (33- HBO2, por exemplo). A programação é composta de todos os filmes que serão exibidos, além de seus horários e datas de exibição. Vale ressaltar que, um filme pode ser exibido em mais de um horário e em várias datas diferentes.

Sistema 3:

Uma loja de CDs deseja informatizar suas transações de venda e de aluguel de títulos, mantendo cadastros atualizados de clientes, balconistas, títulos, dos distribuidores que os fornecem e dos gêneros musicais em que estes se classificam.



98

Entre o cliente e o balconista, as vendas e locações de títulos de CD devem ser armazenadas na base de dados juntamente com a data em que houve a transação (data de venda e data de locação, respectivamente). Somente para a locação, o sistema deverá também armazenar a data prevista para a devolução do título alugado (data de devolução). É de interesse da loja, saber, através das informações armazenadas na base de dados, que balconista vendeu ou alugou de-terminado título para qual cliente.

Eventualmente, um cliente também pode solicitar a encomenda de um CD que não esteja disponível na loja. As encomendas feitas des-ta forma são pedidas diretamente para o balconista, mas para a loja somente é interessante saber qual cliente encomendou determinado título e em que data (data da encomenda). Note que um cliente pode encomendar vários títulos e um título pode ser encomendado por vá-rios clientes. Normalmente, o processo de encomenda é seguido por uma transação de venda (mas nunca de locação), caso o(s) pedido(s) do cliente seja(m) atendido(s).

Cada título de CD é classificado somente num gênero musical (pelo menos, aquele gênero que predomina) dentre os vários que a base de dados mantêm como disponíveis na loja. Além disso, cada tí-tulo de CD é fornecido por apenas uma dentre as várias distribuidoras com a qual a loja obedece a contratos de revenda. Para cada distribui-dora é imprescindível, além de outras informações, o nome do vende-dor intermediário e dos telefones para contato.

Um título pode estar disponível somente para venda ou somente para locação. E não se esqueça que, somente quando da disponibili-dade de um CD ser para venda, o seu preço unitário, a quantidade de unidades vendidas no ato da transação e a sua quantidade, remanes-cente no estoque, são informações importantíssimas, além do que, no caso de um título disponível exclusivamente para locação, a sua venda não é permitida e vice-versa.



99

Sistema 4: (nível avançado)

Uma empresa deseja manter o controle sobre a distribuição de equipamentos nos seus setores, bem como a manutenção dos mesmos. O sistema deverá atender a seguinte descrição:

O sistema deverá manter cadastro dos setores, cada um identifi-cado pelo número da sala, tendo também um nome e uma sigla. Para cada setor são alocados vários equipamentos tais como computadores, impressoras, nobreaks, etc., os quais possuem um código único, um nome e um conjunto de características, as quais são compostas por uma descrição e seu respectivo valor (por exemplo a descrição “HD” e o valor “20Gb”, ou a descrição “RAM” e o valor “128MB”).

Eventualmente, um equipamento pode ser transferido de um se-tor para outro, nesse caso é necessário guardar a data de transferên-cia, o motivo e o funcionário que efetuou tal operação. Quando um equipamento é danificado, é necessário que o mesmo seja enviado para manutenção, sendo que tal atividade é feita por técnicos da pró-pria empresa. Sobre os técnicos, é importante saber a matrícula, nome e data de admissão, bem como suas especialidades, visto que cada um deles pode ser responsável por vários tipos de serviços. Ou seja, já existem alguns serviços pré-definidos (por exemplo, inserção de pente de memória, limpeza de mouse, formatação de disco, etc.) e cada técnico pode possuir habilidade para executar um ou vários desses ser-viços, e o mesmo serviço pode ser realizado por mais de um técnico, desde que o mesmo tenha habilitação para isso. Portanto, quando um equipamento é enviado para manutenção é importante para os geren-tes da empresa saberem qual o técnico responsável pela manutenção, a data inicial e a data final. Note que o sistema não deve permitir que um determinado técnico faça manutenção em um serviço para o qual ele não tem habilitação.

Quanto aos funcionários, o sistema deverá armazenar a sua ma-trícula, nome, data de admissão, o setor que ele trabalha, bem como a data de nascimento e sua função. Não esquecendo, é claro, suas especialidades.



100

Sistema 5: (nível avançado)

O céu é composto por moradores comuns, anjos da guarda, san-tos e, é claro, por Deus. Os anjos e santos desempenham funções par-ticulares. Os anjos da guarda são alocados para olharem por mortais ainda na terra. Cada mortal tem dois anjos da guarda que o guardam (não mudando nunca), e cada anjo da guarda é alocado para apenas um mortal. Sendo que todos os anjos, sem exceção, devem ter sempre um mortal para guardar.

Os santos ficam o dia todo ouvindo pedidos provenientes dos mor-tais. Ressalta-se que cada pedido é caracterizado por um código único e uma descrição, e pode ser do tipo graça (por exemplo, arranjar um emprego, pagar uma dívida) ou um milagre (cura de cegos, deficientes, etc.). Os mortais fazem os pedidos de graça ou milagre direto para um ou mais santos. Porém estes são responsáveis em atender somente as graças, ou seja, mesmo que os pedidos de milagre sejam encaminhados ao santos, cabe somente a Deus a decisão de realizá-los ou não, sendo que no caso de um atendimento o sistema deverá armazenar a data de realização do mesmo. Para cada pedido efetuado é importante saber a data em que foi realizado (caso seja), o santo que a realizou, todas as datas em que foi solicitado bem como a quantidade total de vezes em que este foi feito. Ressaltando-se que um mesmo pedido pode ser feito a vários santos mas é realizado por apenas um.

Quanto aos moradores comuns, estes passam o dia orando e se purificando, e tem a obrigação de venerar Deus por uma determinada quantia de horas por dia. Durante o restante do tempo, esses mora-dores descansam. É importante que seja armazenada a data e a hora inicial e final de cada veneração, para que depois se possam validar as mesmas, já que cada morador possui uma quantidade específica de horas para realizar tal atividade.

Os dados que devem ser armazenados sobre os anjos são có-digo, cor das asas, nome e idade; sobre os moradores comuns: có-digo, nome, quantidade de horas que devem venerar a Deus; sobre os santos são: código, nome, cor das vestes, tempo de beatificação e idade. Além disso, um anjo sempre é supervisionado por outros anjos, e também pode supervisionar vários anjos. Sobre Deus não se



101

sabe muita coisa, e por isso lhe é atribuído, como característica, um código e o nome.

Sistema 6:

Uma instituição de ensino mantém, sob seu controle, a nomeação e manutenção de alguns de seus alunos para atividade de monitoria. Esta atividade consiste em dar assistência ao professor, ministrando al-gumas aulas por ele ou ajudando-o em tarefas de pesquisa que envolva determinada disciplina de interesse.

A necessidade de um controle mais eficiente e eficaz destes alunos determinou a visita de um Analista de Sistemas que, antes de elaborar o projeto lógico do Banco de Dados, identificou os seguintes fatos:

a) Um aluno que exerce a monitoria é conhecido como monitor. Para que um monitor assuma as responsabilidades de sua ati-vidade, ele deve ter algum contato com um professor - o seu orientador - o qual pode ministrar aulas para mais de uma disciplina (neste caso, uma disciplina pode também ter suas aulas ministradas por mais de um professor - orientador!).

b) Após algum estudo da realidade desta instituição, percebeu-se que o "fato do orientador ministrar aulas para determinada disciplina" poderia ser mais bem visto como uma aula simples-mente, a qual resumiria esta associação entre orientador e disciplina como uma entidade do Banco de Dados.

c) Uma aula pode ou não ter alguma atividade de monitoramento realizada por um aluno-monitor. Além disso, o monitor é res-trito a monitorar somente uma aula, mas uma aula pode ser monitorada por mais de um monitor.

d) Sobre o aluno-monitor, é importante saber que ele pode ser monitor remunerado ou monitor voluntário. O monitor remu-nerado recebe uma bolsa mensal a qual deve ter seu registro armazenado no Banco de Dados (assuma que um monitor re-munerado pode receber uma única bolsa e que uma bolsa de monitoria pode ser destinada a vários monitores!). O monitor



102

voluntário, ao contrário, não recebe nenhum dinheiro, uma vez que o seu interesse é somente o certificado emitido após a monitoria.

e) Como a bolsa pode ser destinada depois para outros monitores, é necessário manter dados sobre a mesma tais como, número (único), empresa que doou a bolsa, valor e data de validade.

f) Tanto o monitor remunerado quanto o monitor voluntário re-cebem um certificado, atestando que este participou das ati-vidades de monitoria em determinada aula. Mas para que este documento seja emitido, um controle de frequência mensal deve ser feito para cada monitor durante todo o tempo que exerceu a monitoria, devendo ser eliminada depois do Banco de Dados quando os registros do monitor também forem eli-minados.

Documents

Fundamentos de banco de dados - Aurea Melo