Fundamentos de Banco de Dados

Fundamentos de banco de dados
Tecnologia em Anlise e Desenvolvimento de Sistemas
CAPTULO 2
Modelo Entidade Relacionamentos

2.1 Introduo
De acordo com os nveis de abstrao vistos no Captulo 1, o nvel conceitual corresponde ao nvel em que, a partir da escolha de um modelo de dados, devemos seguir os conceitos pertinentes a realidade a ser modelada. Dessa forma, neste captulo apresentaremos, detalhadamente, 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 corresponde a um conceito usado em outro modelo de dados, no caso o Modelo Relacional, que por sua vez pertence a outro nvel denominado nvel lgico. O MER uma execelente ferramenta para se fazer a modelagem de dados de um sistema. Por pertencer ao nvel conceitual, esse modelo contempla quais os dados devero ser armazenados no banco de dados, no se preocupando como. Alm 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
51
controla atendimento de consultas e solicitaes de exames de uma Clnica, o qual est descrito como Sistema Principal na seo a seguir.
2.2 Sistema principal

Para melhor atender seus clientes, a clnica Salva Vidas deseja informatizar seus servios de forma a gerar controle sobre os agendamentos e realizao de consultas, solicitao e realizao de exames. Para isso, necessrio cadastrar os dados sobre os pacientes, exames, mdicos, especialidades dos mdicos e funcionrios, entre outros. Sobre os mdicos necessrio que o sistema armazene o CRM, nome, endereo, fones (residencial e celular) e as especialidades (note o plural) em que atuam (oftalmologista, ortopedista, etc). Cada especialidade tambm pode ter mais de um mdico atuando. Sobre os pacientes deve-se armazenar o nome, endereo formado por rua, nmero, 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 mdico. Durante uma consulta o mdico captura e repassa ao sistema os sintomas do paciente e o diagnstico e ao final desta, ele pode fazer a solicitao de um exame, para que o paciente faa. necessrio que o sistema mantenha o controle sobre qual mdico solicitou e qual realizou o exame (j que o mdico que realiza no o mesmo que solicita). Sobre a realizao do exame deve-se guardar a data da realizao e o resultado. Com base nas informaes descritas faa a modelagem de dados para o sistema. Se necessrio complemente ou incremente a descrio.
52
2.3 Conjuntos de entidades

Uma entidade uma abstrao (isto , um modelo puramente mental) de um ente existente no mundo real. Assim, uma entidade pode ser a abstrao de um ser, de um fato, de uma coisa, de um organismo social, etc. Por exemplo, com base no estudo de caso, so entidades as representaes abstratas de um mdico, de um paciente, de um exame, etc. Em outras aplicaes, so entidades as abstraes dos materiais usados por uma empresa, os departamentos e divises da mesma, os seus funcionrios, etc. (SETZER, 2005). Uma coleo de entidades que tm caractersticas 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 entidades chamado simplesmente de entidades. Porm importante esclarecer que entidade o elemento individual dentro do conjunto de entidades. Por exemplo podemos ter o conjunto de entidades PACIENTES, e dentro da mesma termos a entidade Joo, a entidade Ana, etc, ou seja, o conjunto de entidades PACIENTES contm o agrupamento dos diferentes pacientes existentes no contexto do sistema. Por representar o agrupamento de vrias coisas, determinaremos como pado para os nomes desses conjuntos sempre palavras no plural. Ressaltanto que, por questes 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 Representao grfica

Um conjunto de entidades representado graficamente por um retngulo com o nome da entidade ao meio, conforme Figura 2.1. Geralmente, esse nome um substantivo no plural.
MDICOS
Figura 2.1 Representao de um conjunto de entidades
53
2.3.2 Classificao
O conjunto de entidades pode ser classificado em 2 tipos distintos: a) Entidades Fortes que uma entidade que tem existncia prpria, ou seja, no depende de outra para existir. Sua notao dada por um retngulo com o nome ao centro, conforme Figura 2.2. b) Entidades Fracas - Ao contrrio das Entidades Fortes as Entidades Fracas no 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 representao um retngulo 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 representa 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 existncia prpria;
54
Identifique as Entidades Fracas como alguma coisa do mundo real que, para existir, depende da existncia de outra coisa. Por exemplo, um funcionrio de uma empresa pode ter dependentes para receberem benefcios. Dessa forma, ser necessrio efetuar um cadastro dos mesmos. Entretanto, caso o funcionrio seja demitido, seu cadastro ser excludo e, consequentemente, todos os dependentes cadastrados para ele tambm o sero.
2.3.3 Regras/Sugestes de modelagem

1. Nomes de conjuntos de entidades devero estar sempre no plural. 2. Um conjunto de entidades deve ser nico na modelagem, ou seja, em uma modelagem de um sistema no pode existir dois conjuntos de entidades com o mesmo nome. 3. Um conjunto de entidades fracas no pode depender de mais de uma entidade forte ou seja, a entidade fraca s pode depender de uma nica entidade forte no modelo.
2.4 Atributos de entidades

Cada entidade de um conjunto de entidades possui propriedades que a caracterizam. Por exemplo, para cada entidade do conjunto de entidades Mdicos tem-se propriedades tais como: nome, CRM, fone, entre outras. Tais caractersticas so abstradas no MER pelo conceito de atributos. Sendo assim, os atributos representam todas as propriedades necessrias para se caracterizar uma entidade dentro de um determinado conjunto de entidades. Por exemplo, a entidade PACIENTES pode ter
55
os seguintes atributos (caractersticas): nome, endereo, 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 (tambm chamado de instncia) de uma determinada entidade. Por exemplo, para o conjunto de entidade PACIENTES, podemos identificar uma entidade qualquer cujo atributo nome tenha o valor Ana Pereira, e o atributo endereo tenha o valor Rua dos Anzis, 23, e assim por diante, ou seja, o nome Ana Pereira e seus demais dados so qualificaes da entidade correspondente a esse paciente.
2.4.1 Representao grfica

Na literatura corrente, deferentes autores usam diversas formas de representar atributos. Por exemplo, Navathe (Navathe, 2007), representa 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 crculos com o nome ao lado, tambm ligados por segmentos de reta, que por sua vez ligam-se ao conjunto de entidades, conforme pode ser visualizado na Figura 2.5.
Figura 2.4 Representao de tributos dada por Navathe
Figura 2.5 Representao de tributos dada por Setzer
Neste livro seguiremos a notao dada por Setzer, por acharmos

56
que torna o diagrama mais simples e, visualmente, limpo, porm cada analista deve desenvolver sua modelagem usando a representao grfica que mais lhe agrade e parea clara. Note que, na representao grfica, 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 Pacientes tem atributos Nome, Endereo e Sexo, ou ainda, cada paciente dever ser caracterizado pelo seu nome, endereo 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 prxima seo.
2.4.2 Classificao
O exemplo de atributo usado at aqui foi do tipo mais comum, tambm chamado de atributo simples. O MER contempla 5 tipos de atributos para representar as diferentes caractersticas das entidades do mundo real. So eles: atributo simples ou monovalorado, multivalorado, 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 valor, isto , no pode assumir vrios 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, no podem ser decompostos. O mesmo ocorre com Nome e Endereo: assumimos que cada paciente tenha um nico endereo, o que um exemplo do que se denomina uma restrio de integridade dos dados, isto , uma condio que os dados devem satisfazer. Sendo assim se o cliente possuir mais de um endereo o mesmo no pode ser modelado (abstrado) como atributo simples. Alm disso, assumindo que Nome um atributo,
57
ele deve ser considerado por inteiro como um nico valor, no podendo ser decomposto em nome prprio e sobrenome, o mesmo acontecendo com Endereo em relao rua, nmero, CEP, etc.
Atributo multivalorado
O atributo multivalorado (do ingls multivalued) o tipo de atributo que permite mais de um valor, isto porque existem casos de entidades, no mundo real, que possuem alguma caracterstica para a qual possvel se determinar mais de um valor. Um exemplo tpico 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 notao para o atributo multivalorado Fones, a qual dada por um duplo crculo
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 dificuldades 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 invs de um multivalorado. A princpio, o problema parece estar resolvido, entre58
tanto, perigoso em um projeto introduzir-se uma restrio de integridade to particular, pois se as regras do negcio mudarem (isto , passar-se a cadastrar, trs ou mais telefones por pessoa), muita coisa teria que ser refeita, o que no ocorreria no caso multivalorado.
Atributo composto
O atributo composto aquele que formado por outros atributos. Por exemplo, comum dizer-se que um endereo composto de local, CEP e cidade e que, por sua vez, um local composto de logradouro, nmero e complemento. (Logradouro a nomenclatura dos Correios do Brasil, podendo ser nome de rua, praa, avenida, etc.) Isto , dado um local, ele pode ser decomposto no logradouro, no nmero e no complemento. Portanto, em comparao com o que foi dito anteriormente, um endereo pode, alm de ser visto como um atributo nico, ser formado por outros atributos. A Figura 2.7 apresenta uma notao (representao grfica) para o atributo composto, o qual representado por meio de uma estrutura em forma de rvore de dados. No exemplo, Endereo o atributo-raiz da rvore, e Rua, Num e CEP so os atributos-folhas. Os atributosfolhas no devem ser compostos.
Figura 2.7 Atributo Endereo composto de Rua, Num e CEP
Com essa representao, possvel referir-se ao valor do atributo Endereo de um determinado paciente, como um todo, subentendendo-se toda a estrutura, com seus vrios nveis, ou seja, dado o endereo de um paciente, pode-se fazer referncia ao seu CEP, Rua e Num. Um atributo composto pode ser simples (quando possui um nico
59
valor) ou multivalorado (quando possui diversos valores). Por exemplo, cada paciente, podem ter vrios endereos; nesse caso, deve-se colocar um crculo duplo no atributo raiz , no caso Endereo. A Figura 2.8 faz essa representao (note o nome agora no plural).
Figura 2.8 Atributo Multivalorado Composto Endereos
Atributos identificadores ou determinantes

Uma restrio de integridade muito comum em conjuntos de entidades, devido sua importncia em todos os modelos computacionais, um atributo monovalorado, cujo valor no 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 cdigo nico para cada paciente. Dessa forma, dado um certo valor para o cdigo de paciente, ele determinar univocamente de qual paciente se trata. Assim, o atributo cdigo representar o atributo identificador para cada entidade do conjunto de entidades pacientes. A notao usada para ilustrar tal atributo uma crculo 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 Cdigo
60
Na prtica, outros exemplos de atributos determinantes seriam o nmero de matrcula dos alunos de uma universidade, os cdigos dos materiais usados em uma empresa, os cdigos de seus produtos, etc. Em geral, denominaremos os atributos determinantes de ID eventualmente seguido de uma qualificao. Isso porque cdigo implica em alguma codificao pr-determinada. Vrios atributos podem, juntos, ser determinantes para uma entidade. Por exemplo, o documento de identidade (RG) das pessoas no Brasil no um atributo determinante, pois duas pessoas podem ter o mesmo nmero de identidade, diferenciando-se pelo Estado. No entanto, se compormos o CPF com o RG conseguiremos determinar unicamente cada entidade. Na Figura 2.10, mostramos a notao para mais de um atrubuto identificador.
Figura 2.10 Atributo identificador IdPessoa+RG
Atributo derivado
Atributo derivado, tambm 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 notao que definimos para esse tipo de atributo um asterisco (*) ao lado do nome do atributo conforme pode ser visualizado na Figura 2.11 o atributo Idade.
Figura 2.11 Atributo derivado Idade
61
Dicas Se um conjunto de entidades tem um nico atributo, provavelmente tal conjunto atributo de um outro conjunto de entidades. Mas h casos em que o contrrio no verdadeiro, isto , uma coleo de atributos que dizem respeito mesma entidade no indica que se trata dos atributos de um conjunto de entidades, e sim um atributo composto (SETZER, 2005). A escolha de se representar algo como uma entidade ou como atributo arbitrria, dependendo em geral da aplicao. Por exemplo, para uma Biblioteca, o autor de um certo livro claramente um atributo desse livro. Mas para uma editora, o autor de um livro que ela publica no simplesmente um atributo desse livro: ela encontra esse autor, combina como ser o lanamento 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 livro 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 vrios atributos: nome, endereo, telefone, CPF, conta bancria, 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 maiscula 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 conjunto de entidade. 3. Em um atributo composto, o nome dado ao atributo-raiz deve dar uma idia significativa dos elementos de sua composio
62
e vice-versa. Por exemplo, ao vermos os atributos rua, nmero bairro e CEP temos a certeza que se trata de um endereo e vice-versa.
2.5 Relacionamentos e conjuntos de relacionamentos

Um relacionamento uma associao entre duas ou mais entidades. Para esclarecer melhor vejamos o seguinte: o paciente Andr Luiz, caracterizado pelos seus atributos nome, data do nascimento, sexo, endereo e telefones. Entretanto, existem outras caractersticas que so necessrias para completar a descrio de um paciente, tais como as datas das consultas realizadas por este paciente, quais mdicos lhe atenderam, o que foi diagnosticado, etc. Nesse exemplo, esto envolvidos os conjuntos de entidades Pacientes e Mdicos. A questo onde colocaremos os dados da consulta desse paciente por qual mdico? Obviamente, no deve ser em Pacientes, pois os dados da consulta envolvem dados do mdico. Por outro lado, no cabe adicionar os dados da consulta em Mdicos, pois nesse conjunto de entidades s devem constar atributos de mdicos, e na cosulta h algo concernente aos pacientes. Portanto, sempre que se fala de uma consulta, deve-se fazer referncia tanto a um paciente, quanto a um mdico. Percebe-se, ento, que os dados referentes quela consulta devem ser colocados fora de Pacientes e de Mdicos. Sendo assim, o que necessitamos algo que represente uma associao no mundo real entre o ente-paciente, cujo nome Andr Luiz, com o ente-mdico, cujo nome Joo de Barros. Na realidade a ser modelada, devemos relacionar um elemento de um desses conjuntos (Pacientes) a um elemento do outro (Mdicos),
63
mas esse dado no pertence diretamente nem a um nem a outro. Pelo contrrio, ele decorrncia da preexistncia de ambos, e ainda do fato de mdicos consultarem pacientes. Portanto, um novo conceito introduzido, de modo que fique claro que, dados dois conjuntos de entidades como Mdicos e Pacientes, elementos de um podem relacionar-se com elementos do outro. Tal conceito o que conhecemos por relacionamento, o qual representado graficamente por meio de um losango conectando um conjunto de entidades a outro, conforme podemos ver na Figura 2.12 representando o relacionamento consulta. Ele denominado de conjunto de relacionamentos, uma vez que, na verdade, representa o conjunto das vrias consultas realizadas pelos diferentes mdicos 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 consultados por mdicos e mdicos consultam pacientes. O relacionamento representa o fato de elementos de um conjunto de entidades poderem estar conectados (relacionados, associados) a elementos do outro conjunto.
Figura 2.12 Relacionamento consulta
Dicas Associaes, geralmente, existem para permitir aes entre as entidades. Como aes do idia de verbo, o nome mais adequado para um relacionamento deve ser derivado do verbo que indica a ao representada pela associao. Por exemplo, consulta, empresta, possui etc.
64
Pelo fato de um relacionamento poder ser lido nos dois sentidos, fica estranha a leitura de que um paciente consulta mdico. Dessa forma, podemos tambm colocar um substantivo (no plural) dentro do losango de forma a representar a ao do relacionamento em questo. Devido, especificamente, neste exemplo no ficar visvel tal diferena, damos um outro exemplo na Figura 2.13(a) e 2.13(b), em que para no ficar estranha a leitura "um exame solicita mdico, trocamos a palavra solicita pelo substantivo solicitaes. Ainda pelo fato de um relacionamento poder ser lido nos dois sentidos, podemos ler, no exemplo da Figura 2.13a, mdico consulta pacientes (no sentido mdico-paciente) ou paciente consultado pelo mdico (no sentido inverso).
Figura 2.13(a) Relacionamento solicita
Figura 2.13(b) Relacionamento solicitaes
2.5.1 Classificao
Um relacionamento pode ser de 2 tipos: total ou parcial. a) Relacionamento total - Um relacionamento total aquele que exige a existncia de uma ligao 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 contrrio do relacionamento total, o relacionamento parcial no exige a existncia de uma ligao entre as entidades, ou seja, a ligao opcional. Para exemplificarmos esses dois tipos de relacionamento, con65
sideremos, ainda no cenrio da clnica, que um mdico pode ou no realizar consultas, ou seja, dado o conjunto de mdicos cadastrados podem ter casos de mdicos que nunca realizaram consultas (claro que um exemplo!), porm um paciente s pode ser cadastrado no sistema se tiver uma consulta marcada. Sendo assim, dizemos que o relacionamento no sentido de mdico para paciente parcial e de paciente para mdico total. A Figura 2.14 apresenta este exemplo, em que um crculo preenchido representa o relacionamento total do lado paciente.
Figura 2.14 Relacionamento parcial e relacionamento total.
2.5.2 Multiplicidade de relacionamentos

A multiplicidade (tambm chamada de cardinalidade) do relacionamento indica uma restrio de integridade quanto ao nmero (quantidade) 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 mximo, uma entidade de outro conjunto. Podemos exemplificar tal fato, usando nosso estudo de caso e supondo que cada mdico s pode ter uma nica especialidade e cada especialidade s pode ser de um mdico. No mundo real, como se nessa clnica s existisse um oftalmologista, um cardiologista e assim por diante. Portanto, dado um determinado mdico do conjunto de entidades Mdicos este s pode efetuar consulta em uma especialidade. A
66
Figura 2.15 ilustra em termos de conjuntos como feita essa relao e a Figura 2.16 ilustra a devida representao no MER.
Figura 2.15 Multiplicidade 1:1
Figura 2.16 Multiplicidade 1:1
Leitura do exemplo de cardinalidade 1:1: cada mdico possui uma especialidade e cada especialidade pertence a um nico mdico.
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 mdico s pode ter uma nica especialidade, porm uma especialidade pode ser de vrios mdicos, ou seja, um mdico s pode ser ou ortopedista ou oftamologista (nunca ambos), entretanto, a clnica pode ter mais de um oftamologista, mais de um ortopedista etc. A Figura 2.17 ilustra em termos de conjuntos como feita essa relao e a Figura 2.18 ilustra a devida representao 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
67
para um) no sentido de Mdicos para Especialidades e 1:N no sentido de Especialidades para Mdicos, pois o significado o mesmo.
Leitura do exemplo de cardinalidade N:1: cada mdico possui apenas uma especialidade, mas cada especialidade pode pertencer a vrios (mais de um) mdico.
Figura 2.17 Multiplicidade N:1
Figura 2.18 Multiplicidade N:1
Multiplicidade N:M
Finalmente, notamos tambm nos diagramas ER os relacionamentos sem restrio de multiplicidade: so os casos N:M (muitos para muitos). Um exemplo o da Figura 2.19, em que um mdico pode consultar vrios pacientes e um paciente (no decorrer do tempo) pode ser consultado por vrios mdicos. Para seguir os exemplos anteriores, tambm mostrado na Figura 2.20 a representao em conjuntos. S para fixar um pouco mais as idias, vamos exemplificar as trs multiplicidades com um caso social. Considerando os dois conjuntos de entidades Homens e Mulheres e um relacionamento Ligaes asso-
68
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 questes de conveno, muitas vezes usamos a notao N:N quando se trata de um relacionamento N:M.
Leitura do exemplo de cardinalidade N:M: cada mdico pode possuir vrias especialidades, e cada especialidade pode pertencer a vrios mdicos.
Figura 2.19 Multiplicidade N:M
Figura 2.20 Multiplicidade N:M
A multiplicidade pode tambm ser modelada representando os limites mnimo e mximo das associaes que cada entidade pode ter
69
com outra. A Figura 2.21 ilustra essa representao em que o limite mnimo posicionado esquerda (da vrgula) e o mximo posicionado direita.
Leitura do exemplo de cardinalidades com limites: um mdico pode ter no mnimo uma especialidade e no mximo N. Por outro lado, uma especialidade pode pertencer a, no mnimo, nenhum mdicos e no mximo um. Ressalta-se tambm que o valor N, em alguns casos, pode ser explicitado. Por exemplo, a Figura 2.22 apresenta o caso em que um mdico pode ter no mximo 3 especialidades.
Figura 2.21 Limites de cardinalidade.
Figura 2.22 Limite mximo explcito.
2.5.3 Atributos de relacionamentos

No mundo real, existem situaes para as quais necessitamos armazenar dados que, apesar de envolverem entidades, tais dados no pertenam as mesmas. Vejamos um exemplo: Para cada consulta realizada entre o mdico e o paciente necessrio saber qual a data da mesma e qual o diagnstico dado. Como podemos ver, a data e o diagnstico no podem ser modelados como relacionamentos, uma vez que
70
representam uma caracterstica e no uma ao dessas entidades. Por representarem uma qualificao, tanto data quanto diagnstico podem ser identificados como atributos. Entretanto, os mesmos no podem ser atributos nem de Pacientes nem de Mdicos, pelo fato de que data de consulta e diagnstico no so caractersticas dessas entidades. Portanto, data e diagnstico so, claramente, atributos do relacionamento consultas, j que descrevem explcitamente a data da consulta e o diagnstico dado na mesma. A Figura 2.23 apresenta este exemplo.
Figura 2.23 Atributos do relacionamento.
Dica: Os atributos data e diagnstico, alm de caracterizar cada consulta realizada por um mdico em um paciente, serve tambm de histrico, ou seja, com o passar do tempo o sistema modelado ter armazenado todas as consultas realizadas, com suas respectivas datas, diagnsticos, mdicos e pacientes. Sendo assim, supondo que voc (equivocadamente) modelasse tais atributos na entidade Pacientes, tais atributos s teriam armazenados os ltimos valores cadastrados e no o histrico ao longo do tempo, ou seja, a cada nova consulta e/ou diagnstico este sobreporiam os valores antigos. Desa forma, de acordo com a regra de negcio, pode ser que atributos identificados como de relacionamento tambm possam ser modelados numa entidade especfica.
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
71
melhor tal fato, usaremos um exemplo de um sistema de uma empresa, em que necessrio armazenar dados sobre os funcionrios e seus supervisores. Ora, um supervisor tambm um funcionrio, sendo assim, dever ser feito um relacionamento entre o conjunto de entidades Funcionrios com ele prprio. Ressaltamos que, embora a representao 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 conjunto, e no de uma entidade com ela prpria, como equivocadamente muitas pessoas dizem. Alm disso, em um auto-relacionamento de suma importncia que sejam explicitados os papis que cada entidade dever assumir. Tal importncia se d pela necessidade de se definir as cardinalidades do relacionamento. A Figura 2.24 apresenta um auto-relacionamento no conjunto de entidades Funcionrios, alm dos papis de supervisor e supervisionados, em que um supervisor pode ter N (muitos, vrios) subordinados e um funcionrio s pode ter um supervisor.
Figura 2.24 Auto- relacionamento
72
Dica: Em geral, todos os auto-relacionamentos tm papis diferenciados. Se em um projeto de modelo conceitual aparecer um auto-relacionamento sem papis 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 conjunto de entidades por ele envolvidas. Dessa forma, o menor grau de um relacionamento no MER o grau dois ou binrio (inclusive para autorelacionamentos). Alguns graus de relacionamento recebem nomes especiais, so eles: binrio para grau dois; ternrio para grau trs e quaternrio para grau quatro. A partir da, diz-se grau cinco, grau seis, e assim por diante. Os relacionamentos com grau maior que dois so chamados de relacionamentos n-rio (l-se enrios), os quais sero detalhados na prxima seo.
2.5.6 Relacionamentos n-rios

Conforme descrito na seo anterior, os relacionamento n-rios so 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 negcio, ou seja, dependendo do controle que se deseja ter sobre determinados dados podemos usar ou no 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 mdico sempre faa uso de alguma ferramenta, e que importante que o sistema fornea, alm do mdico e paciente consultado, informaes
73
sobre qual(is) o(s) equipamento(s) utilizado(s) na referida consulta. A Figura 2.25 apresenta uma soluo de modelagem para esta situao. Entretanto, considerando que um mdico efetua consulta em vrios pacientes, e que pode usar vrios equipamentos na mesma consulta, tal modelagem deixa a desejar quanto a disponibilidade de informaes, uma vez que para sabermos exatamente qual o equipamento usado por um determinado mdico em uma consulta a um paciente especfico, teremos que varrer todos os relacionamentos e cruzar as informaes para se chegar a um denominador comum, o que acarretar em um custo desnecessrio. Alm disso, se for digitado um valor errado em um dos relacionamentos fica quase impossvel fazer esse cruzamento. Em termos prticos, 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 presso, sendo que para o paciente Marcos, alm desse, usou tambm o termmetro e estetoscpio. Suponha tambm que Jos e Marcos foram tambm consultados na mesma data pelo Dr. Silveira, o qual usou os equipamentos medidor de presso e termmetro 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 satisfatrio e consistente (se que possvel) 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 mdico), em seguida verificar no relacionamento usam quais equipamentos usados pelo Dr. Barros tambm naquela data. Dessa forma, chegaremos ao resultado dos equipamentos medidor de presso, termmetro e estetoscpio, o qual dever ser cruzado com os equipamentos usados em Jos para somente assim chegarmos na resposta desejada. Entretanto, se em um do relacionamento for colocado uma data equivocada teremos tal cruzamento no poder ser realizado.
74
Figura 2.25 Trs relacionamentos binrios.
Considerando que toda vez que um mdico realiza uma consulta ele deve fazer uso de, no mnimo, um equipamento, a soluo mais correta para esta realidade seria um relacionamento ternrio (ver Figura 2.26), uma vez que este j deixaria amarrado o mdico, o paciente e o equipamento usado em um nico relacionamento. Tal soluo responderia, sem muito custo, consulta solicitada no pargrafo anterior.
Figura 2.26 Relacionamento ternrio consultam.
Importante ressaltar que os relacionamentos n-rios podem tambm estar associados a um auto relacionamento. A Figura 2.27 apresenta um exemplo de um auto-relacionamento ternrio, correspondendo ao contexto de equipamentos (computadores, impressoras, etc.) que so transferidos de um setor para outro, fazendo-se necessrio
75
armazenar, alm do setor origem e destino, a data e o motivo da transferncia. Leitura: a Figura 2.27 pode ser lida como Um equipamento pode ser transferido de um setor para vrios setores, armazenando a data e o motivo da transferncia.
Figura 2.27 Auto-relacionamento ternrio.
Sendo assim, para cada ocorrncia (instncia) de transferncia haver o cdigo do setor origem, o cdigo do setor destino, o cdigo 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 Modelo 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 Captulo 3), o qual um dos sistemas mais implementados e usados nas mais diversas reas de atuao, cujo elemento principal denominado de tabela. Fizemos esses esclarecimentos para que o leitor entenda que aps completar a modelagem de dados de um sistema, o mesmo deve ser mapeado para um modelo que permita sua implementao. Por exemplo, imagine que um cliente solicita a construo de uma casa,
76
o responsvel pela construo (arquiteto) dever ter vrias reunies com esse cliente at que sejam definidos os detalhes do que ele realmente 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 cmodos, varandas, banheiros, etc.) o projeto passa para a faze de COMO dever ser feito. Para tanto, so necessrios detalhes tais como altura, largura, comprimento de cada cmodo; tamanhos e posicionamento das janelas, portas, basculantes, enfim tudo o que realmente seja necessrio definir para dar suporte e condies de que a casa seja construda. Analogamente, o projeto de banco de dados tambm feito assim. Primeiramente, deve ser feita a modelagem dos dados, na qual so definidos QUAIS os dados devero ser armazenados no banco de dados e, posteriormente, fazemos o mapeamento para que possamos definir COMO esses dados sero armazenados (definidos o tamanho, se um campo obrigatrio ou no, se ficar em uma ou mais tabelas, etc). Tal mapeamento necessrio porque o MER no d suporte definio de detalhes como tipo e tamanho para implementao 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 Figura 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 tambm mapeado como tabela). E, conforme explicado anteriormente, a tabela Transferencia conter como atributos: cdigo do setor origem, cdigo do setor destino, cdigo do equipamento, data e motivo. E embora tenha duas vezes o atributo cdigo do setor, uma tabela no pode conter mais de um atributo com o mesmo nome. Portanto, embora oriundo da mesma chave primria 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 no 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 cdigo_setor.
77
Tabela: TRANSFERENCIA
Codigo_Setor 10 20
Codigo_Setor 11 10
Codigo_Equipamento 201 202
Data 01/10/07 16/11/07
Motivo Emprstimo Ser usado na reunio com a direoria
Figura 2.28(a) Mapeamento incorreto do atributo codigo_setor da tabela Setores
Tabela: TRANSFERENCIA
Codigo_Setor_Origem 10 20
Codigo_Setor_Destino 11 10
Codigo_Equipamento 201 202
Data 01/10/07 16/11/07
Motivo Emprstimo Ser usado na reunio 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 possvel, um substantivo derivado do verbo que indique a ao permitida pela associao entre as entidades envolvidas. 2. O nome dos conjuntos de relacionamentos deve iniciar com letra minscula e estar no plural. 3. No repetir nome de relacionamento no mesmo diagrama, pois este deve ser nico. 4. Sempre explicitar os papis de um auto-relacionamento para que se possa validar a cardinalidade. 5. Sempre explicitar as cardinalidades em um diagrama. 6. No permitido fazer relacionamento entre relacionamentos. 7. O grau mnimo permitido em um relacionamento dois (binrio). 8. Atributos identificadores no so permitidos em relaciona78
mentos, pois so exclusivos de entidades. 9. Todo relacionamento binrio N:N possui, no mnimo, dois atributos implcitos, dados pelos identificadores oriundos das entidades envolvidas. 10. Todo relacionamento n-rio possui implicitamente os atributos determinantes oriundos das entidades envolvidas. 11. Nos relacionamentos 1:N ou N:1 a entidade cuja cardinalidade 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 no esteja envolvida no referido relacionamento.
2.6 Agregaes
A agregao uma soluo para a restrio do MER de no permitir relacionamento entre relacionamentos. Para melhor entendermos esse conceito, ilustramos na Figura 2.29 a situao em que um mdico consulta um paciente e solicita exames. Tal modelagem equivocada, pois nem toda vez, em uma consulta, h solicitao de exames, e o relacionamento ternrio exige o envolvimento das trs entidades (obrigatoriedade). Dessa forma, uma outra soluo seria dada pela Figura 2.30, que embora fosse mais prxima da realidade, pois poderamos dizer que o mdico consulta o paciente e, a partir da mesma, pode solicitar exames, tal representao no permitida pela restrio de integridade do modelo no que diz que s pode existir relacionamento entre entidades e no entre relacionamentos.
79
Figura 2.29 Mdico consulta paciente e solicita exame
Figura 2.30 Relacionamento entre relacionamentos consulta e solicita
Uma forma alternativa de modelarmos essa situao tambm mostrada na Figura 2.31, mas isso pode trazer um problema de inconsistncia uma vez que no amarra em qual consulta foi solicitado o exame.
80
Figura 2.31 Relacionamentos binrios para Consulta e solicitao de exames
A Figura 2.32 apresenta agora a forma correta de modelarmos a solicitao de um exame a partir de uma consulta usando agregao, a qual criada agrupando-se o relacionamento consultas e tranformando-o em uma nova entidade.
Figura 2.32 Relacionamentos com agregao
Na prtica, em geral no necessrio dar nome para a agregao, pois basicamente ela representa o relacionamento. Sendo assim, no exemplo dado na Figura 2.32, a agregao gerada pode ser chamada de consultas (nome do relacionamento) a qual se associa com a en81
tidade EXAMES por meio do relacionamento solicitaes.
Algumas observaes gerais sobre agregaes: a) Agregaes envolvendo relacionamentos 1:N no fazem sentido, 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 faa o relacionamento com a entidade cuja cardinalidade N. b) No h muito sentido em se falar de atributos de uma agregao. Na verdade, esses atributos pertencem aos conjuntos das entidades relacionadas na agregao, mais os atributos do relacionamento que ela engloba, isto , todos os atributos de todos os conjuntos agregados. c) Nada impede de se fazer uma agregao envolvendo mais do que dois conjuntos de entidades relacionados por um relacionamento (relacionamentos com grau maior que dois), mas ressaltamos que s pode haver um relacionamento em uma agregao. d) As entidades dentro da agregao podem se relacionar, normalmente, com outras entidades, para isso, a linha do relacionamento deve ultrapassar os limites da agregao. e) O conceito de agregao uma extenso ao modelo original de Peter Chen, normalmente denominado de MERE (Modelo Entidade Relacionamento Estendido). f) Finalmente, em lugar de se representar a agregao como um retngulo envolvendo o relacionamento e os seus conjuntos de entidades, podemos usar uma notao alternativa colocando-se um retngulo envolvendo somente o relacionamento, conforme exemplificamos na Figura 2.33. A vantagem dessa representao que, por ser mais compacta, no sobrecarrega tanto um diagrama quanto a anterior. Alm disso, mostra explicitamente que a agregao aplicada no relacionamento. Entretanto, muitos preferem o retngulo envolvendo tambm as entidades, sempre que possvel, pois mais represen-
82
tativo no fato de a agregao envolver tambm os conjuntos de entidades.
Figura 2.33 Representao grfica alternativa para agregao
Leitura: A leitura de uma agregao feita de dentro pra fora, ou seja, l-se primeiro o relacionamento dentro da agregao 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: mdicos consultam pacientes e, a partir dessas consultas, podem ou no solicitar exames. Os iniciantes no uso do MER, normalmente, questionam o que se pode e o que no se pode modelar com uma agregao. Dentre essas dvidas, uma muito comum diz respeito aos auto-relacionamentos. Portanto, a seguir faremos algumas consideraes de agregaes envolvendo os mesmos. a) Uma agregao em um auto-relacionamento segue as mesmas regras de um relacionamento comum, ou seja, dependendo da cardinalidade podemos agregar ou no. Se for N:N sim, caso contrrio, na maioria das vezes no. b) Uma agregao pode ter auto-relacionamento com uma das entidades envolvidas. A Figura 2.34 apresenta uma nova verso do exemplo dado na seo 2.5.6 (Figura 2.27), em que
83
equipamentos so alocados em setores, tais equipamentos podem, posteriormente, serem transferidos para outros setores, para isso, necessrio saber, alm do setor de origem, o setor destino, a data, o motivo e o funcionrio que efetuou a transferncia. Observe que o setor origem dado no relacionamento alocados e o setor destino no relacionamento transferidos.
Figura 2.34 Uma agregao se auto-relacionando com uma das entidades por ela envolvida
Outra dvida comum, se a entidade gerada a partir de uma agregao pode ou no ter uma entidade fraca como sua dependente. Quanto a isso no h restries, enfatizamos, novamente, que a modelagem depende da realidade observada e de sua relevncia no modelo criado.

1. Evite (para no dizer nunca) projetar uma agregao de um conjunto de relacionamentos de multiplicidade 1:N ou 1:1. 2. Nunca modele atributos em uma agregao.
84
2.7 Especializaes e generalizaes de conjuntos de entidades

O conceito de generalizao e especializao muito conhecido como herana. De um modo prtico herana tudo aquilo que pode ser passado de pai para filho, ou seja, dada uma caracterstica 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 tambm o conceito de herana, em que um entidade pode herdar tanto as caractersticas quanto as associaes de uma outra entidade. Alm disso, as entidades-filhas podem possuir caractersticas (atributos) e associaes prpras. O MER usa herana atravs de dois conceitos, a saber:
Generalizao dizemos que ocorre uma generalizao quando todas as entidades de nvel superior (superclasse) pertencem a alguma entidade do nvel inferior (subclasse), ou seja, no existe qualquer entidade dentro do conjunto de entidadesmes que no estejam em, pelo menos, uma entidade-filha. Especializao - dizemos que ocorre uma especializao quando existe, pelo menos, uma entidade de nvel superior que pertence a nenhuma entidade do nvel inferior, ou seja, existe alguma entidade dentro do conjunto de entidades-mes que est em nenhuma entidade-filha.
A Figura 2.35 apresenta um exemplo de uma generalizao, em que cada entidade do conjunto de entidades pessoas ou uma pessoa fsica ou uma pessoa jurdica.
85
Figura 2.35 Exemplo de Generalizao
Por outro lado, a Figura 2.36 apresenta um exemplo de uma especializao, em que podemos observar que algumas entidades do conjunto do nvel superior (PROFESSOR) pertencem a nenhuma entidade de nvel inferior (ESPECIALISTAS, MESTRES E DOUTORES).
Figura 2.36 Exemplo de uma Especializao.
86
Alguns autores definem os conceitos de generalizao e especializao como algo que depende do ponto de origem da modelagem, ou seja, se for identificado primeiro a entidade mais genrica e depois for percebido a necessidade de subdividir a mesma em outras categorias, diz-se que houve uma especializao, e quando se identifica primeiramente as entidades especficas (filhas) para depois identificar a mais genrica (me), diz-se que se que houve uma generalizao. Outros autores defendem que no h diferena entre as duas e que, considerar uma generalizao ou especializao depende do sentido da leitura. Ou seja, de cima para baixo tem-se uma especializao e de baixo para cima uma generalizao.
Algumas observaes sobre heranas: a) A herana do MER lembra o conceito de herana do paradigma orientado a objetos. No entanto, no MER tratamos apenas dos dados no sendo considerado suas operaes (mtodos). b) Conforme dito anteriormente, as entidades de nvel inferior herdam tanto atributos quanto relacionamentos das entidades de nvel superior. Na Figura 2.37 podemos observar que todos os funcionrios da clnica (mdicos e atendentes) so lotados em setores. Dessa forma, o relacionamento lotado liga o conjunto de entidades SETORES diretamente ao conjunto de entidades de nvel superior FUNCIONRIOS, tal associao herdada por mdicos e atendentes, ou seja, tanto mdicos quanto atendentes so lotados em algum setor. c) Quando um relacionamento especfico de apenas uma das entidades de nvel infeiror, deve-se se associar apenas esta. A Figura 2.38 apresenta o exemplo em que as especialidades dos mdicos (neurologia, pediatria, etc.) devem ser registradas (armazenadas) no sistema. Sendo assim, o relacionamento possuem liga o conjunto de entidades ESPECIALIDADES diretamente ao conjunto de entidades de nvel inferior MDICOS. d) Relacionamentos entre entidades da superclasse e alguma entidade da subclasse representam auto-relacionamentos da superclasse.
87
Figura 2.37 Relacionamento com a entiadade de nvel superior.
Figura 2.38 Relacionamento especfico com entiadade de nvel inferior.
e) As entidades de nvel 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 nvel inferior.
88
2.7.1 Restries de herana

Restries de herana so regras de integridade que definem a participao dos membros da entidade de nvel superior (superclasse) nas entidades de nvel inferior (subclasses). Tais restries podem ser de trs tipos: restrio de disjuno, restrio de completude e restrio por atributo. Restrio de disjuno (disjoin) define se um membro da superclasse pode participar de uma ou mais subclasse. Est subdividida em: Disjuno (disjointness) define que um membro da superclasse s pode participar em, no mximo, uma subclasse. Em outras palavras, representa um OU EXCLUSIVO em que o membro da superclasse participa (pertence) ou a uma subclasse ou a outra nunca a ambas. A Figura 2.40 exemplifica essa abstrao, em que uma pessoa s pode ser do tipo Fsica ou Jurdica, jamais as duas. Sua notao a letra d em minsculo dentro do crculo. Sobreposio (overllaping) ao contrrio da disjuno, permite 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 notao dada pela letra o dentro do crculo.
Figura 2.40 Restrio de disjuno
89
Figura 2.41 Restrio de sobreposio
Restrio de completude define se um membro da superclasse pode participar ou no de uma subclasse. Est classificada em: Total define que todos os membros da superclasse devem pertencer a alguma subclasse. Em outras palavras, uma restrio do tipo total nada mais do que uma generalizao. Sua notao so duas retas paralelas saindo da superclasse at o crculo (ver Figuras 2.35 e 2.40). Parcial define que os membros da superclasse podem ou no pertencer a alguma subclasse, ou seja, pode existir uma entidade na superclasse que no esteja em nenhuma subclasse, o que nos faz lembrar o conceito de especializao. As Figuras 2.36 e 2.41 representam que um professor pode ser um especialista, um mestre ou um doutor. Entretanto, pode ser que tenhamos um professor qualquer que tenha ps-doutorado ou somente graduao, o qual vai estar apenas na superclasse. Sua notao uma reta saindo da superclasse at o crculo.
Vale ressaltar que a restrio de completude (total ou parcial) independente da restrio de disjuno, pois podemos ter as seguintes combinaes: parcial com sobreposio, parcial com disjuno, total com disjuno e total com sobreposio. Em suma, as retries dedisjuno e completude so ortogonais. Restrio por atributo identificada quando as entidades de nvel inferior no possuem atributos especficos, sendo necessrio apenas um valor de atributo para diferenci-las. Por exemplo, a Figura 2.42
90
apresenta um exemplo em que a classe de nvel superior PESSOA pode ser uma criana, um adolescente, um jovem ou um adulto, entretanto, qualquer um deles tero exatamente os mesmos atributos de pessoa, porm o valor do atributo faixa-etria dever ser diferente para cada um deles. Note que, o atributo cujo valor far a diferena nas entidades de nvel inferior deve ficar posicionado logo abaixo da entidade superior, e no deve aparecer como atributo da mesma. Na Figura 2.43 apresentamos outro exemplo de restrio por atributo, em que a superclasse PESSOAS pode ser classificada em HOMENS ou MULHERES. Considerando que no haver atributos para diferencilas pois tanto homens quanto mulheres possuem nome, CPF, telefone, endereo, altura, peso, etc., ento 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 herana por atributo
Figura 2.43 Exemplo 2 de herana por atributo
91
Importante observarmos que no exemplo ilustrado pela Figura 2.42, temos uma especializao, pois existem outras classes definidas por outras faixas-etrias que no esto representadas pelas subclasses (terceira idade e pr-adolescncia). J no exemplo da Figura 2.43 temos uma generalizao, uma vez que no existe pessoa que no seja, biologicamente, do sexo masculino (homens) ou do sexo feminino (mulheres).
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 prprios para caracteriza-la, se o resultado for positivo para as trs suposies, seguramente podemos definir tal entidade no modelo. Ao identificar um atributo em um relacionamento que pertence a alguma entidade do diagrama que no est envolvida no relacionamento, retire o atributo e inclua a entidade no relacionamento. Um relacionamento pode possuir atributos implcitos, os quais so oriundos dos atributos determinantes das entidades envolvidas Em uma abstrao de herana (generalizao/especializao) as entidades de nvel inferior (subclasses) herdam atributos e relacionamentos das entidades de nvel superior. Entretanto, os atributos e relacionamentos das subclasses pertencem somente a elas prprias. Se ao identificar uma herana, a leitura no puder ser feita usando o termo um ou uma ou ainda pode ser um ou pode ser uma, com certeza no estamos diante de uma herana. Evite usar termos tais como tabelas, chave estrangeira, pois tais conceitos pertencem a outro modelo de dados (Modelo Relacional), o qual pertente a um nvel mais baixo que o conceitual (nvel lgico ver seo 1.3). Alm disso, as entidades identificadas no diagrama devem ser de mais alto nvel possvel, uma vez que, neste nvel, o importante identificar quais os dados esto no banco de dados e no como esto no banco de dados.
92
A modelagem de um sistema deve atender ao escopo principal do sistema. Por exemplo, no sistema da Clnica, embora o controle de acesso seja necessrio, ele no faz parte do escopo principal que so as consultas, solicitaes de exame, pacientes, mdicos, etc. comum as pessoas confundirem as entidades do MER com tabelas do Modelo Relacional, ou ainda com classes do MOO (Modelo Orientado a Objetos). Por exemplo, no sistema da Clnica Mdica algumas pessoas podem identificar consultas como entidade quando na verdade um relacionamento, haja vista que a consulta no existe por si s, e necessrio a relao entre mdico e paciente para que ela ocorra. Sendo assim, mesmo que o relacionamento 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 nvel conceitual, no se importando com detalhes de implementao pois o DER ser mapeado para o nvel lgico (tabelas) e depois poder passar pelo processo de normalizao tantos nas entidades quanto (principalmente) nos relacionamentos.
A seguir, a Figura 2.44 apresenta um diagrama completo da Clnica Salva Vidas feito mediate o software BrModelo, com algumas adaptaes para atender a nomeclatura usada neste livro.
93
Figura 2.44 Diagrama Geral da Clca Salva Vidas
Observe, que as duas agregaes no diagarama podem parecer complexas, mas no podemos esquecer que a leitura de um relacionamento com uma agregao deve ser feita de dentro para fora. Dessa forma, devemos seguir a seguinte ordem: primeiramente, o relacionamento possuem, depois o relacionamento consultam seguido do relacionamento solicitaes. Portanto, a leitura correta ser: mdicos possuem especialidades e podem (opcionalidade da agregao) consultar pacientes, a partir dessas consultas podem ou no solicitar exames.
94
2.8 Resumo
O Modelo Entidade Relacionamento (MER), introduzido por Peter Chen em 1976, um modelo de dados que pertence ao nvel conceitual. As principais abstraes (elementos) do MER so: entidades, relacionamentos e atributos. Posteriormente foram adicionadas as abstraes de herana e agregao, no que se denominou Modelo Entidade Relacionamento Estendido (MERE). O MER representa uma forte ferramenta para modelar os dados de sistemas de informao, preocupando em mostrar quais os dados esto armazenados no banco de dados, sem considerar como esto armazenados.
95
Exerccios
1. Com base na descrio dos sistema da seo 2.2 faa a modelagem completa do mesmo. 2. Idenfique no DER do estudo de caso os possveis relacionamentos totais e parciais. 3. Quais dos casos seguintes prestam-se a ser modelados como autorelacionamento? Modele todos, e escolha atributos convenientes para os auto-relacionamentos: matrias de um curso superior e seus pr-requisitos; partes de edifcios (andares, sagues, salas, etc.), parentesco entre pessoas; captulos e sees de captulos de livros; projetos e subprojetos; pases, estados, cidades, bairros e logradouros (ruas, praas, etc.); mapas e regies de mapas; organogramas de empresas; hierarquias militar e de ordens religiosas. 4. Faa a modelagem de dados dos seguintes sistemas:
Sistema 1:
O sistema tem como objetivo principal armazenar rvores genealgicas de forma que qualquer indivduo possa obter informaes sobre suas origens. O sistema dever registrar as pessoas, definidas somente como homens ou mulheres, as quais aparecem em alguma gerao da arvore. Uma gerao um vnculo de um casal genitor heterossexual de pessoas com as vrias outras que so seus descendentes diretos (i.e., os filhos, caso existam). Estas pessoas descendentes, da mesma forma que seus ascendentes, podero formar outros casais e, possivelmente, outras geraes na mesma rvore.
96
Para cada pessoa, e necessrio saber o sexo, a data de nascimento, o nome, o sobrenome e uma coleo de caractersticas que ela possui, sendo que cada caracterstica composta por uma descrio e seu respectivo valor (por exemplo, a descrio 'cor dos olhos' e o valor 'verde'). J para o casal importante saber em que data foi selada a sua unio. O diagrama dever representar a maior quantidade possvel de informaes descritas para este sistema, usando os mecanismos de modelagem j aprendidos.
Sistema 2:
Uma empresa de TV cabo necessita informatizar alguns dos seus servios de forma a atender as seguintes necessidades: O sistema dever controlar o cadastro dos clientes, pacotes (famlia, adulto, infantil, cinema, etc), da programao (filmes, horrios, etc) e do pagamento de mensalidades. Cada pacote possui um preo e o cliente pode escolher uma combinao 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 tambm escolher a quantidade de tv's para instalao 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 nmero e seu nome (33- HBO2, por exemplo). A programao composta de todos os filmes que sero exibidos, alm de seus horrios e datas de exibio. Vale ressaltar que, um filme pode ser exibido em mais de um horrio e em vrias datas diferentes.
Sistema 3:
Uma loja de CDs deseja informatizar suas transaes de venda e de aluguel de ttulos, mantendo cadastros atualizados de clientes, balconistas, ttulos, dos distribuidores que os fornecem e dos gneros musicais em que estes se classificam.
97
Entre o cliente e o balconista, as vendas e locaes de ttulos de CD devem ser armazenadas na base de dados juntamente com a data em que houve a transao (data de venda e data de locao, respectivamente). Somente para a locao, o sistema dever tambm armazenar a data prevista para a devoluo do ttulo alugado (data de devoluo). de interesse da loja, saber, atravs das informaes armazenadas na base de dados, que balconista vendeu ou alugou determinado ttulo para qual cliente. Eventualmente, um cliente tambm pode solicitar a encomenda de um CD que no esteja disponvel na loja. As encomendas feitas desta forma so pedidas diretamente para o balconista, mas para a loja somente interessante saber qual cliente encomendou determinado ttulo e em que data (data da encomenda). Note que um cliente pode encomendar vrios ttulos e um ttulo pode ser encomendado por vrios clientes. Normalmente, o processo de encomenda seguido por uma transao de venda (mas nunca de locao), caso o(s) pedido(s) do cliente seja(m) atendido(s). Cada ttulo de CD classificado somente num gnero musical (pelo menos, aquele gnero que predomina) dentre os vrios que a base de dados mantm como disponveis na loja. Alm disso, cada ttulo de CD fornecido por apenas uma dentre as vrias distribuidoras com a qual a loja obedece a contratos de revenda. Para cada distribuidora imprescindvel, alm de outras informaes, o nome do vendedor intermedirio e dos telefones para contato. Um ttulo pode estar disponvel somente para venda ou somente para locao. E no se esquea que, somente quando da disponibilidade de um CD ser para venda, o seu preo unitrio, a quantidade de unidades vendidas no ato da transao e a sua quantidade, remanescente no estoque, so informaes importantssimas, alm do que, no caso de um ttulo disponvel exclusivamente para locao, a sua venda no permitida e vice-versa.
98
Sistema 4: (nvel avanado)

Uma empresa deseja manter o controle sobre a distribuio de equipamentos nos seus setores, bem como a manuteno dos mesmos. O sistema dever atender a seguinte descrio: O sistema dever manter cadastro dos setores, cada um identificado pelo nmero da sala, tendo tambm um nome e uma sigla. Para cada setor so alocados vrios equipamentos tais como computadores, impressoras, nobreaks, etc., os quais possuem um cdigo nico, um nome e um conjunto de caractersticas, as quais so compostas por uma descrio e seu respectivo valor (por exemplo a descrio HD e o valor 20Gb, ou a descrio RAM e o valor 128MB). Eventualmente, um equipamento pode ser transferido de um setor para outro, nesse caso necessrio guardar a data de transferncia, o motivo e o funcionrio que efetuou tal operao. Quando um equipamento danificado, necessrio que o mesmo seja enviado para manuteno, sendo que tal atividade feita por tcnicos da prpria empresa. Sobre os tcnicos, importante saber a matrcula, nome e data de admisso, bem como suas especialidades, visto que cada um deles pode ser responsvel por vrios tipos de servios. Ou seja, j existem alguns servios pr-definidos (por exemplo, insero de pente de memria, limpeza de mouse, formatao de disco, etc.) e cada tcnico pode possuir habilidade para executar um ou vrios desses servios, e o mesmo servio pode ser realizado por mais de um tcnico, desde que o mesmo tenha habilitao para isso. Portanto, quando um equipamento enviado para manuteno importante para os gerentes da empresa saberem qual o tcnico responsvel pela manuteno, a data inicial e a data final. Note que o sistema no deve permitir que um determinado tcnico faa manuteno em um servio para o qual ele no tem habilitao. Quanto aos funcionrios, o sistema dever armazenar a sua matrcula, nome, data de admisso, o setor que ele trabalha, bem como a data de nascimento e sua funo. No esquecendo, claro, suas especialidades.
99
Sistema 5: (nvel avanado)

O cu composto por moradores comuns, anjos da guarda, santos e, claro, por Deus. Os anjos e santos desempenham funes particulares. Os anjos da guarda so alocados para olharem por mortais ainda na terra. Cada mortal tem dois anjos da guarda que o guardam (no mudando nunca), e cada anjo da guarda alocado para apenas um mortal. Sendo que todos os anjos, sem exceo, devem ter sempre um mortal para guardar. Os santos ficam o dia todo ouvindo pedidos provenientes dos mortais. Ressalta-se que cada pedido caracterizado por um cdigo nico e uma descrio, e pode ser do tipo graa (por exemplo, arranjar um emprego, pagar uma dvida) ou um milagre (cura de cegos, deficientes, etc.). Os mortais fazem os pedidos de graa ou milagre direto para um ou mais santos. Porm estes so responsveis em atender somente as graas, ou seja, mesmo que os pedidos de milagre sejam encaminhados ao santos, cabe somente a Deus a deciso de realiz-los ou no, sendo que no caso de um atendimento o sistema dever armazenar a data de realizao 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 vrios santos mas realizado por apenas um. Quanto aos moradores comuns, estes passam o dia orando e se purificando, e tem a obrigao de venerar Deus por uma determinada quantia de horas por dia. Durante o restante do tempo, esses moradores descansam. importante que seja armazenada a data e a hora inicial e final de cada venerao, para que depois se possam validar as mesmas, j que cada morador possui uma quantidade especfica de horas para realizar tal atividade. Os dados que devem ser armazenados sobre os anjos so cdigo, cor das asas, nome e idade; sobre os moradores comuns: cdigo, nome, quantidade de horas que devem venerar a Deus; sobre os santos so: cdigo, nome, cor das vestes, tempo de beatificao e idade. Alm disso, um anjo sempre supervisionado por outros anjos, e tambm pode supervisionar vrios anjos. Sobre Deus no se
100
sabe muita coisa, e por isso lhe atribudo, como caracterstica, um cdigo e o nome.
Sistema 6:
Uma instituio de ensino mantm, sob seu controle, a nomeao e manuteno de alguns de seus alunos para atividade de monitoria. Esta atividade consiste em dar assistncia ao professor, ministrando algumas 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 lgico 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 atividade, 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 tambm ter suas aulas ministradas por mais de um professor - orientador!). b) Aps algum estudo da realidade desta instituio, percebeuse que o "fato do orientador ministrar aulas para determinada disciplina" poderia ser mais bem visto como uma aula simplesmente, a qual resumiria esta associao entre orientador e disciplina como uma entidade do Banco de Dados. c) Uma aula pode ou no ter alguma atividade de monitoramento realizada por um aluno-monitor. Alm disso, o monitor restrito 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 voluntrio. O monitor remunerado recebe uma bolsa mensal a qual deve ter seu registro armazenado no Banco de Dados (assuma que um monitor remunerado pode receber uma nica bolsa e que uma bolsa de monitoria pode ser destinada a vrios monitores!). O monitor
101
voluntrio, ao contrrio, no recebe nenhum dinheiro, uma vez que o seu interesse somente o certificado emitido aps a monitoria. e) Como a bolsa pode ser destinada depois para outros monitores, necessrio manter dados sobre a mesma tais como, nmero (nico), empresa que doou a bolsa, valor e data de validade. f) Tanto o monitor remunerado quanto o monitor voluntrio recebem um certificado, atestando que este participou das atividades de monitoria em determinada aula. Mas para que este documento seja emitido, um controle de frequncia 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 tambm forem eliminados.
102

Fundamentos de Banco de Dados - Aurea Melo

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fundamentos de Banco de Dados - Aurea Melo

Enviado por

Direitos autorais:

Formatos disponíveis

Tecnologia em Anlise e Desenvolvimento de Sistemas

Modelo Entidade Relacionamentos

Tecnologia em Anlise e Desenvolvimento de Sistemas