Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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, 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 denidos. Daí porque, é incorreto chamar, 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 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 modelo 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 51
Tecnologia em Análise e Desenvolvimento Desenvolvim ento de Sistemas
Fundamentos de banco de dados
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. 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 agendamentos 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 especialidade 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 nal 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.
52
Tecnologia em Análise e Desenvolvimento Desenvolvim ento de Sistemas
Fundamentos de banco de dados
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. 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 agendamentos 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 especialidade 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 nal 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.
52
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 entidades é 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 PACIENPACIENTES, 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”, determinaremos 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áfca
Um conjunto de entidades é representado gracamente por um retângulo com o nome da entidade ao meio, conforme Figura 2.1. Geralmente, esse nome é um substantivo no plural.
MÉDICOS Figura 2.1
Representação de um conjunto de entidades
53
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento Desenvolvim ento de Sistemas
2.3.2 Classifcaç Classifcação ão
O conjunto de entidades pode ser classicado em 2 tipos distindistintos: a) Entidades Fortes – que é uma entidade que tem existência
própria, ou seja, não depende de outra para existir. 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 armar 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 identicar uma entidade forte, observe se ela rerepresenta algo que será inserido de forma independente no sistema a ser desenvolvido, ou seja, verique 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;
54
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
• Identique 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 empresa 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 depender de uma única entidade forte no modelo.
2.4 Atributos Atributos de entidades Cada entidade de um conjunto de entidades possui propriedades 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 conceito de atributos. Sendo assim, os atributos representam todas as propriedades necessárias para se caracterizar uma entidade dentro de um determinado conjunto de entidades. Por exemplo, a entidade PACIENTES pode ter 55
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 qualica. 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 identicar uma entidade qualquer cujo atributo “nome” tenha o valor “Ana Pereira”, 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 qualicações da entidade correspondente a esse paciente.
2.4.1 Representação gráfca
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 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 visualizado 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 56
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
que torna o diagrama mais simples e, visualmente, limpo, porém cada analista deve desenvolver sua modelagem usando a representação gráca que mais lhe agrade e pareça clara. Note que, na representação gráca, 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, Endereço e Sexo”, ou ainda, cada paciente deverá ser caracterizado pelo seu nome, endereço e sexo. Como os atributos que estamos exemplicando 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.
2.4.2 Classifcaçã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, multivalorado, composto, calculado ou derivado e atributo identicador. A seguir detalharemos cada um desses atributos.
Atributo simples
Um atributo simples é aquele que só pode assumir um único valor, 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 possuir 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, 57
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 atributo que permite mais de um valor, isto porque existem casos de entidades, 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 diculdades 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, entre58
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
tanto, é perigoso em um projeto introduzir-se uma restrição de integridade 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 atributos. Por exemplo, é comum dizer-se que um endereço é composto de “local, CEP e cidade” e que, por sua vez, um local é composto de “logradouro, 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áca) 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 atributosfolhas 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 atributo Endereço de um determinado paciente, como um todo, subentendendo-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 59
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
valor) ou multivalorado (quando possui diversos valores). Por exemplo, cada paciente, podem ter vários endereços; nesse caso, deve-se colocar 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 identifcadores ou determinantes
Uma restrição de integridade muito comum em conjuntos de entidades, 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 identicador. 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 identicador 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 Identicador Código
60
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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” eventualmente seguido de uma qualicação. Isso porque “código” implica em alguma codicação pré-determinada. Vários atributos podem, juntos, ser determinantes para uma entidade. 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 entanto, se compormos o CPF com o RG conseguiremos determinar unicamente cada entidade. Na Figura 2.10, mostramos a notação para mais de um atrubuto identicador.
Figura 2.10
– Atributo identicador 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 denimos 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
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
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 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 entidades, 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 é claramente 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çamento 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 qualica 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 vários atributos: nome, endereço, telefone, CPF, conta bancária, etc. (SETZER, 2005). • Um atributo pode ser identicado como aquele que qualica ou caracteriza uma entidade. Por exemplo: pessoas tem cor, altura, peso, etc, ou ainda nome, CPF, dentre outros.
2.4.3 Regras/Sugestões de modelagem
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 conjunto de entidade. 3. Em um atributo composto, o nome dado ao atributo-raiz deve dar uma idéia signicativa dos elementos de sua composição 62
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
e vice-versa. Por exemplo, ao vermos os atributos rua, número bairro e CEP temos a certeza que se trata de um endereço e vice-versa.
2.5 Relacionamentos e conjuntos de relacionamentos Um relacionamento é uma associação entre duas ou mais entidades. 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édicos 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édico? 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 referê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), 63
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
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 que claro que, dados dois conjuntos de entidades como Médicos e Pacientes, elementos de um podem relacionar-se com elementos do outro. Tal conceito é o que conhecemos por relacionamento, o qual é representado gracamente 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 várias consultas realizadas pelos 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 consultados por médicos e médicos 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
• Associações, geralmente, existem para permitir ações entre as entidades. Como ações dão idéia de verbo, o nome mais adequado para um relacionamento deve ser derivado do verbo que indica a ação representada pela associação. Por exemplo, consulta, empresta, possui etc.
64
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
• Pelo fato de um relacionamento poder ser lido nos dois sentidos, ca estranha a leitura de que um paciente consulta médico. Dessa forma, podemos também colocar um substantivo (no plural) dentro do losango de forma a representar a ação do relacionamento em questão. Devido, especicamente, neste exemplo não car visível tal diferença, damos um outro exemplo na Figura 2.13(a) e 2.13(b), em que para não car 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 consulta pacientes (no sentido médico-paciente) ou paciente é consultado pelo médico (no sentido inverso).
Figura 2.13(a) – Relacionamento solicita
Figura 2.13(b) – Relacionamento solicitações
2.5.1 Classifcação
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 exemplicarmos esses dois tipos de relacionamento, con65
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 relacionamento 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 preenchido 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 relacionamento indica uma restrição de integridade quanto ao número (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 máximo, uma entidade de outro conjunto. Podemos exemplicar 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 entidades Médicos este só pode efetuar consulta em uma especialidade. A 66
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 oftamologista, 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
67
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
para um) no sentido de Médicos para Especialidades e 1:N no sentido de Especialidades para Médicos, pois o signicado é 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 relacionamentos 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 xar um pouco mais as idéias, vamos exemplicar as três multiplicidades com um caso social. Considerando os dois conjuntos de entidades Homens e Mulheres e um relacionamento Ligações asso68
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 69
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 é posicionado à 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 realizada 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 diagnóstico não podem ser modelados como relacionamentos, uma vez que 70
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
representam uma característica e não uma ação dessas entidades. Por representarem uma qualicação, tanto data quanto diagnóstico podem ser identicados 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 relacionamento 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 consulta realizada por um médico em um paciente, serve também de histórico, ou seja, com o passar do tempo o sistema modelado terá armazenado todas as consultas realizadas, com suas respectivas 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 identicados como de relacionamento também possam ser modelados numa entidade especíca.
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
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
melhor tal fato, usaremos um exemplo de um sistema de uma empresa, 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 entidades 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 conjunto, 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 denir 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
72
– Auto- relacionamento
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Dica:
• Em geral, todos os auto-relacionamentos têm papéis diferenciados. 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 conjunto de entidades por ele envolvidas. Dessa forma, o menor grau de um relacionamento no MER é o grau dois ou binário (inclusive para autorelacionamentos). 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 diante. 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 negócio, ou seja, dependendo do controle que se deseja ter sobre determinados 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édico 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 73
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
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íco, teremos que “varrer” todos os relacionamentos e cruzar as informações para se chegar a um denominador comum, o que acarretará em um custo desnecessário. Além disso, se for digitado um valor errado em um dos relacionamentos ca 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 consultados 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 vericar no relacionamento usam quais equipamentos usados pelo Dr. Barros também naquela data. Dessa forma, chegaremos ao resultado dos equipamentos medidor de pressão, termômetro e estetoscópio, 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 não poderá ser realizado.
74
Fundamentos de banco de dados
Figura 2.25
Tecnologia em Análise e Desenvolvimento de Sistemas
– 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 Figura 2.26), uma vez que este já deixaria “amarrado” o médico, o paciente 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 também estar associados a um auto relacionamento. A Figura 2.27 apresenta um exemplo de um auto-relacionamento ternário, correspondendo ao contexto de equipamentos (computadores, impressoras, etc.) que são transferidos de um setor para outro, fazendo-se necessário 75
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
armazenar, além do setor origem e destino, a data e o motivo da transferê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 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 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, 76
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
o responsável pela construção (arquiteto) deverá ter várias reuniões com esse cliente até que sejam denidos 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 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, enm tudo o que realmente seja necessário denir para dar suporte e condições de que a casa seja construída. Analogamente, o projeto de banco de dados também é feito assim. Primeiramente, deve ser feita a modelagem dos dados, na qual são denidos QUAIS os dados deverão ser armazenados no banco de dados e, posteriormente, fazemos o mapeamento para que possamos denir COMO esses dados serão armazenados (denidos o tamanho, se é um campo obrigatório ou não, se cará em uma ou mais tabelas, etc). Tal mapeamento é necessário porque o MER não dá suporte à deniçã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 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 também é mapeado 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 tenha 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.
77
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Tabela: TRANSFERENCIA
Data
Motivo
11
Codigo_Equipamento 201
01/10/07
10
202
16/11/07
Empréstimo Será usado na reunião com a direoria
Codigo_Setor
Codigo_Setor
10 20
Figura 2.28(a) – Mapeamento incorreto do atributo codigo_setor da tabela “Setores”
Tabela: TRANSFERENCIA
Codigo_Setor_Origem 10
Codigo_Setor_Destino 11
Codigo_Equipamento 201
Data
Motivo
01/10/07
20
10
202
16/11/07
Empréstimo Será usado na reunião com a direoria
Figura 2.28(b) – Mapeamento correto do atributo codigo_setor da tabela “Setores”
2.5.7 Regras/Sugestões de modelagem
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 envolvidas. 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 relacionamentos. 7. O grau mínimo permitido em um relacionamento é dois (binário). 8. Atributos identicadores não são permitidos em relaciona78
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
mentos, pois são exclusivos de entidades. 9. Todo relacionamento binário N:N possui, no mínimo, dois atributos implícitos, dados pelos identicadores 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 identicador oriundo da entidade cuja cardinalidade é 1. 12. Nunca denir um atributo em um relacionamento se este zer parte de uma entidade que não esteja envolvida no referido relacionamento.
2.6 Agregações A agregação é uma solução para a restrição do MER de não permitir 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 é equivocada, 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 integridade do modelo no que diz que só pode existir relacionamento entre entidades e não entre relacionamentos.
79
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Figura 2.29
Figura 2.30
– Médico consulta paciente e solicita exame
– 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 inconsistência uma vez que não “amarra” em qual consulta foi solicitado o exame.
80
Fundamentos de banco de dados
Figura 2.31
Tecnologia em Análise e Desenvolvimento de Sistemas
– 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 “tranformando-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 en81
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
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 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 faça o relacionamento com a entidade cuja cardinalidade é N. b) Não há muito sentido em se falar de atributos de uma agregaçã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 relacionamento (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, normalmente, com outras entidades, para isso, a linha do relacionamento 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).
82
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 colocando-se um retângulo envolvendo somente o relacionamento, conforme exemplicamos na Figura 2.33. A vantagem dessa representação é que, por ser mais compacta, não sobrecarrega tanto um diagrama quanto a anterior. Além disso, mostra explicitamente que a agregação é aplicada no relacionamento. Entretanto, muitos preferem o retângulo envolvendo também as entidades, sempre que possível, pois é mais represen-
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
tativo no fato de a agregação envolver também os conjuntos de entidades.
Figura 2.33 – Representação gráca 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 consultam 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 essas dúvidas, uma muito comum diz respeito aos auto-relacionamentos. Portanto, a seguir faremos algumas considerações de agregações envolvendo 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 versão do exemplo dado na seção 2.5.6 (Figura 2.27), em que 83
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
equipamentos são alocados em setores, tais equipamentos podem, posteriormente, serem transferidos para outros setores, 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 relacionamento “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 modelagem depende da realidade observada e de sua relevância no modelo criado.
2.6.1 Regras/Sugestões de modelagem
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. 84
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 lho, ou seja, dada uma característica dos pais, estas podem ser transmitidas aos seus lhos. Por exemplo, a cor dos olhos, altura, cor da pele, entre outras. No modelo ER há també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-lhas 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 entidadesmães que não estejam em, pelo menos, uma entidade-lha. • Especialização - dizemos que ocorre uma especialização quando 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-lha.
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.
85
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Figura 2.35 – Exemplo de Generalização
Por outro lado, a Figura 2.36 apresenta um exemplo de uma especialização, em que podemos observar que algumas entidades do conjunto do nível superior (PROFESSOR) pertencem a nenhuma entidade de nível inferior (ESPECIALISTAS, MESTRES E DOUTORES).
Figura 2.36
86
– Exemplo de uma Especialização.
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Alguns autores denem os conceitos de generalização e especialização como algo que depende do ponto de origem da modelagem, ou seja, se for identicado primeiro a entidade mais genérica e depois for percebido a necessidade de subdividir a mesma em outras categorias, diz-se que houve uma especialização, e quando se identica primeiramente as entidades especícas (lhas) para depois identicar 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íco 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 registradas (armazenadas) no sistema. Sendo assim, o relacionamento possuem liga o conjunto de entidades ESPECIALIDADES diretamente 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.
87
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Figura 2.37 – Relacionamento com a entiadade de
Figura 2.38
nível superior.
– Relacionamento especíco 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
88
entidades de nível inferior.
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
2.7.1 Restrições de herança
Restrições de herança são regras de integridade que denem 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) – dene se um membro da su-
perclasse pode participar de uma ou mais subclasse. Está subdividida em: • Disjunção (disjointness) – dene 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 membro da superclasse participa (pertence) ou a uma subclasse ou a outra nunca a ambas. A Figura 2.40 exemplica essa abstração, em que uma pessoa só pode ser do tipo Física ou Jurídica, 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
89
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Figura 2.41
– Restrição de sobreposição
Restrição de completude – dene se um membro da superclasse
pode participar ou não de uma subclasse. Está classicada em: • Total – dene que todos os membros da superclasse devem pertencer a alguma subclasse. Em outras palavras, uma restriçã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 – dene que os membros da superclasse podem ou não pertencer a alguma subclasse, ou seja, pode existir uma entidade 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 especialista, 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 dedisjunção e completude são ortogonais. Restrição por atributo – é identicada quando as entidades de
nível inferior não possuem atributos especícos, sendo necessário apenas um valor de atributo para diferenciá-las. Por exemplo, a Figura 2.42 90
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 “pessoa”, 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 car 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 atributo, em que a superclasse PESSOAS pode ser classicada 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 denido o atributo SEXO cujo valor fará com que as entidades do conjunto PESSOAS sejam denidas como HOMENS ou MULHERES.
Figura 2.42
– Exemplo 1 de herança por atributo
Figura 2.43
– Exemplo 2 de herança por atributo
91
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
Importante observarmos que no exemplo ilustrado pela Figura 2.42, temos uma especialização, pois existem outras classes denidas 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 temos uma generalização, uma vez que não existe pessoa que não seja, biologicamente, do sexo masculino (homens) ou do sexo feminino (mulheres).
Dicas gerais:
• Ao identicar uma entidade forte pergunte se ela existe por si só, em seguida verique se ela possui um atributo identicador, 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 denir tal entidade no modelo. • Ao identicar um atributo em um relacionamento que pertence a alguma entidade do diagrama que não está envolvida no relacionamento, retire o atributo e inclua a entidade no relacionamento. • Um relacionamento pode possuir atributos implícitos, os quais são oriundos dos atributos determinantes das entidades envolvidas • 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 identicar 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 herança. • Evite usar termos tais como tabelas, chave estrangeira, pois tais conceitos pertencem a outro modelo de dados (Modelo Relacional), 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 identicadas no diagrama devem ser de mais alto nível possível, uma vez que, neste nível, o importante é identicar quais os dados estão no banco de dados e não como estão no banco de dados. 92
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
• A modelagem de um sistema deve atender ao escopo principal do sistema. Por exemplo, no sistema da Clínica, embora o controle de acesso seja necessário, ele não faz parte do escopo principal que são as consultas, solicitações de exame, pacientes, médicos, 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 Clínica Médica algumas pessoas podem identicar consultas como entidade quando na verdade é um relacionamento, haja vista que a consulta 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 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 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á passar pelo processo de normalização tantos nas entidades quanto (principalmente) nos relacionamentos.
A seguir, a Figura 2.44 apresenta um diagrama completo da Clínica Salva Vidas feito mediate o software BrModelo, com algumas adaptações para atender a nomeclatura usada neste livro.
93
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
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 relacionamento com uma agregação 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 solicitações. Portanto, a leitura correta será: médicos possuem especialidades e podem (opcionalidade da agregação) consultar pacientes, a partir dessas consultas podem ou não solicitar exames. 94
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
2.8 Resumo O Modelo Entidade Relacionamento (MER), introduzido por Peter Chen em 1976, é um modelo de dados que pertence ao nível conceitual. As principais abstrações (elementos) do MER são: entidades, relacionamentos e atributos. Posteriormente foram adicionadas as abstrações de herança e agregação, no que se denominou Modelo Entidade 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.
95
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
Exercícios 1. Com base na descrição dos sistema da seção 2.2 faça a modelagem completa do mesmo. 2. Idenque no DER do estudo de caso os possíveis 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: 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 logradouros (ruas, praças, etc.); mapas e regiões de mapas; organogramas 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 genealógicas de forma que qualquer indivíduo possa obter informações sobre suas origens.
96
O sistema deverá registrar as pessoas, denidas somente como homens ou mulheres, as quais aparecem em alguma geração da arvore. 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 lhos, caso existam). Estas pessoas descendentes, da mesma forma que seus ascendentes, poderão formar outros casais e, possivelmente, outras gerações na mesma árvore.
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
Para cada pessoa, e necessário saber o sexo, a data de nascimento, 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, infantil, cinema, etc), da programação (lmes, horários, etc) e do pagamento 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 é identicado por um número e seu nome (33- HBO2, por exemplo). A programação é composta de todos os lmes que serão exibidos, além de seus horários e datas de exibição. Vale ressaltar que, um lme 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 classicam. 97
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
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 determinado 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 desta 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 é classicado 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 distribuidora é imprescindível, além de outras informações, o nome do vendedor 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 disponibilidade 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, remanescente 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.
98
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 identicado 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 setor para outro, nesse caso é necessário guardar a data de transferência, o motivo e o funcionário que efetuou tal operação. Quando um equipamento é danicado, é 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é-denidos (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 serviç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 gerentes da empresa saberem qual o técnico responsável pela manutenção, a data inicial e a data nal. 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 matrí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.
99
Tecnologia em Análise e Desenvolvimento de Sistemas
Fundamentos de banco de dados
Sistema 5: (nível avançado)
O céu é composto por moradores comuns, anjos da guarda, santos e, é claro, por Deus. Os anjos e santos desempenham funções particulares. 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 cam o dia todo ouvindo pedidos provenientes dos mortais. 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, decientes, 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 puricando, e tem a obrigação 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 nal de cada veneração, para que depois se possam validar as mesmas, já que cada morador possui uma quantidade especíca de horas para realizar tal atividade.
100
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 beaticaçã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
Fundamentos de banco de dados
Tecnologia em Análise e Desenvolvimento de Sistemas
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 algumas aulas por ele ou ajudando-o em tarefas de pesquisa que envolva determinada disciplina de interesse. A necessidade de um controle mais eciente e ecaz destes alunos determinou a visita de um Analista de Sistemas que, antes de elaborar o projeto lógico do Banco de Dados, identicou 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 também ter suas aulas ministradas por mais de um professor - orientador!). b) Após algum estudo da realidade desta instituição, percebeuse que o "fato do orientador ministrar aulas para determinada disciplina" poderia ser mais bem visto como uma aula simplesmente, 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 é 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 voluntário. 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 vários monitores!). O monitor
101