UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

Transcrição

1 UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE) COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE) Banco de Dados Sandra de Albuquerque Siebra Volume 2 Recife, 2010

2 Universidade Federal Rural de Pernambuco Reitor: Prof. Valmar Corrêa de Andrade Vice-Reitor: Prof. Reginaldo Barros Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho Pró-Reitor de Extensão: Prof. Paulo Donizeti Siepierski Pró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José Freire Pró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos Produção Gráfica e Editorial Capa e Editoração: Allyson Vila Nova, Rafael Lira, Italo Amorim e Heitor Barbosa Revisão Ortográfica: Marcelo Melo Ilustrações: Noé Aprígio, Diego Almeida e Moisés Souza Coordenação de Produção: Marizete Silva Santos

3 Sumário Apresentação... 4 Conhecendo o Volume Capítulo 4 Modelagem de Banco de Dados... 7 Modelo de Dados...7 O Modelo Entidade-Relacionamento...11 Notação de Peter Chen para Cardinalidade...21 Extensões do Modelo Entidade-Relacionamento...26 Ferramentas para Modelagem de Dados...30 Considerações Finais...33 Capítulo 5 Desenhando o MER Peculiaridades dos Modelos ER...44 Critérios para Construção do Modelo ER...47 Evitando Atributos Multivalorados...50 Criando o Diagrama ER...51 Verificação do Modelo Criado...53 Considerações Finais...61 Capítulo 6 Outras Notações para o MER Notação da Engenharia de Informações...68 Notação MERISE...71 Considerações Finais...73 Considerações Finais Conhecendo a Autora... 78

4 Apresentação Caro(a) cursista, Seja bem-vindo(a) ao segundo módulo do curso Banco de Dados! Neste segundo módulo, vamos estudar um assunto que considero um dos mais importantes para o aprendizado de Banco de Dados: a modelagem conceitual dos dados que serão armazenados. Por que ela é importante? Porque ela é o começo de tudo. Um banco de dados começa a existir na modelagem. E, se um banco de dados é modelado errado, consequentemente, você terá um banco de dados que não atenderá aos seus objetivos ou que poderá dar muito mais trabalho para armazenar e recuperar os dados armazenados da maneira apropriada, mantendo a integridade dos mesmos. ok? Assim, como esse é um assunto muito importante, procure dedicar bastante atenção e tempo ao mesmo, Bons estudos! Sandra de Albuquerque Siebra Autora 4

5 Conhecendo o Volume 2 Neste segundo volume, você irá encontrar o Módulo 2 da disciplina de Banco de Dados. Para facilitar seus estudos, veja a organização deste segundo módulo. Módulo 2 Modelagem e Projeto de Banco de Dados Carga horária do Módulo 2: 15 h/aula Objetivo do Módulo 2:» Introduzir os principais conceitos e definições relacionados à modelagem de dados.» Examinar os principais conceitos envolvidos em um projeto conceitual de BD.» Ensinar a projetar banco de dados relacionais confiáveis e eficientes. Conteúdo Programático do Módulo 2:» Modelos de Dados Conceitos; Modelos Lógicos baseados em Registros; hierárquico, rede, relacional. Modelos entidade-relacionamento e orientado a objeto.» Modelo Entidade-Relacionamento Modelagem conceitual de Dados; Diagrama Entidade-relacionamento; Reduzindo Diagramas E-R a Tabelas; Projeto de um Esquema de Bancos de Dados E-R.» Ferramenta para Modelagem de Dados. 5

6 Capítulo 4 O que vamos estudar neste capítulo? Neste capítulo, vamos estudar os seguintes temas:» Modelo de Dados.» Componentes do Modelo Entidade-Relacionamento (MER).» Ferramenta para Modelagem de Dados. Metas Após o estudo deste capítulo, esperamos que você consiga:» Identificar os principais conceitos relacionados à modelagem de dados.» Identificar e saber a utilidade de cada um dos componentes de um Modelo Entidade Relacionamento (MER).» Utilizar alguma ferramenta para a modelagem de dados. 6

7 Capítulo 4 Modelagem de Banco de Dados Vamos conversar sobre o assunto? Se você pretende desenvolver aplicações que usam banco de dados relacionais, você, com certeza, deverá possuir os conceitos básicos sobre modelagem de dados. Não importa o tamanho da sua aplicação ou a complexidade da mesma, sempre será muito importante ter bem projetado o local onde os dados serão armazenados, de forma que eles possam ser recuperados de forma fácil, íntegra e correta. É justamente o como fazer o projeto de banco de dados que veremos nesse capítulo. Lembre, esse é um dos assuntos mais importantes da nossa disciplina, logo, leia esse capítulo com mais atenção do que qualquer outro e não esqueça de praticar os conceitos que serão aprendidos. Vamos lá? Neste capítulo, vamos falar sobre modelos de dados e modelagem de dados. Aproveite bem tudo que vem pela frente! Modelo de Dados Lembra do conceito de abstração de dados que explicamos no capítulo 3, do fascículo I da disciplina? Pois são os modelos de dados as principais ferramentas que fornecem a abstração a um BD, visto que o modelo de dados representa, de forma abstrata, como aspectos do mundo real (fatos) estão relacionados, a fim de que possam ser representados no mundo computacional. Mas o que é um modelo de dados? Ele é um conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos e restrições pertinentes aos dados que serão armazenados no BD. Muitos modelos de dados também definem um conjunto de operações para especificar como recuperar e modificar a base de dados. Já o processo pelo qual você planeja ou projeta a base de dados, de forma que possa construir um banco de dados consistente, de forma a exigir menos espaço em disco e aproveitar os recursos disponíveis no SGBD é chamado modelagem de dados. Ou seja, é processo para a criação do modelo de dados. Mas por que modelar os dados? Qual o objetivo disso? É importante modelar os dados a fim de conhecer melhor as informações dos usuários e como elas se relacionam a fim de representar, da melhor forma, o ambiente observado criando, por consequência, bancos de dados mais corretos e eficientes. Um projeto mal feito pode trazer diversos problemas, tais como: o banco de dados e/ou aplicação podem não funcionar adequadamente; os dados podem não ser confiáveis ou serão inexatos e a performance do BD pode ser degradada. A modelagem de dados é uma das etapas do ciclo de Desenvolvimento de Sistemas de Banco de Dados (vide Figura 1). 7

8 Figura 1 - Ciclo de Desenvolvimento de SBDs E quais são as outras etapas? Primeiro, para poder realizar a modelagem dos dados, você precisa fazer um levantamento de requisitos. Ou seja, precisa investigar quais dados deverão fazer parte do banco de dados, a fim de representar bem o problema a ser resolvido e poder atender as necessidades de armazenamento (persistência) dos dados da aplicação. Uma vez que se saiba os dados que devem ser manipulados, você deve analisar como esses dados podem ser representados e relacionados (olhando para o mundo real) através de um modelo de dados. Esse é o papel da segunda etapa, a modelagem dos dados. Uma vez que os dados estejam modelados o banco de dados será projetado, transformando o modelo de dados criado em estruturas de mais baixo nível que possam ser criadas dentro do SGBD. Posteriormente, o BD é realmente implementado usando algum dos SGBDs disponíveis no mercado e, depois, mantido e monitorado pelo administrardor de banco de dados. Existem modelos para diferentes níveis de abstração de representação de dados. São eles: modelos conceituais (também conhecido como modelo com base em objetos), modelos lógicos (também conhecido como modelo com base em registros) e modelos físicos. Vamos descrever melhor cada um deles a seguir. Modelo Conceitual É a primeira etapa da modelagem de dados, sendo a descrição mais abstrata da realidade, modelando de forma mais natural os fatos do mundo real, suas propriedades e relacionamentos. É utilizado para entendimento, transmissão, validação de conceitos, mapeamento do ambiente e para facilitar o diálogo entre usuários e desenvolvedores. A modelagem conceitual do BD independe da sua implementação, não contendo nenhum detalhe da mesma. Assim, a modelagem conceitual é independente do SGBD utilizado para implementação do BD. De fato, o modelo conceitual registra que dados podem aparecer no banco de dados, mas não registra como estes dados estão armazenados em nível de SGBD. A modelagem conceitual dos bancos de dados relacionais é feita através da criação do modelo entidade-relacionamento (MER). No caso de bancos de dados orientados a objetos ou objeto-relacional, é usado o modelo de classes da UML (Unified Modeling Language). Modelo Lógico Representa os dados em alguma estrutura (lógica) de armazenamento de dados, que 8

9 vai depender do SGBD a ser utilizado. Ou seja, este modelo vai especificar a representação/ declaração dos dados de acordo com o SGBD escolhido, definindo assim a estrutura de registros do BD (onde cada registro define número fixo de campos (atributos) e cada campo possui tamanho fixo). Um exemplo de modelo lógico é o modelo relacional. O modelo relacional usa um conjunto de tabelas para representar tanto os dados como a relação entre eles. Cada tabela possui múltiplas colunas e cada coluna possui um nome único. Apesar de existirem outras representações de modelo lógico, nesta disciplina trataremos apenas dos modelos lógicos referentes a SGBD relacional. Modelo Físico São usados para descrever os dados no nível mais baixo, tratando de aspectos de implementação do SGBD (como indexação e estruturação de arquivos, controle de concorrência, transações, recuperação em casos de falhas, entre outros). As linguagens e notações para o modelo físico não são padronizadas e variam de produto a produto (são dependentes do SGBD). Além disso, a tendência dos produtos modernos é cada vez mais esconder o modelo físico. Atenção Os modelos físicos não são o foco desta disciplina e, por consequência, não serão tratados na mesma. Todos esses modelos, na verdade, são visões diferentes, com nível de profundidade diferente para os mesmos dados. E é importante saber que, a partir de um modelo, o modelo seguinte pode ser derivado. Para lhe dar uma ideia de como as coisas acontecem, vamos explicar o processo descrito na Figura 2. O analista (lembra das pessoas envolvidas com o sistema de banco de dados, estudados no volume I?) de banco de dados, observa a realidade (e também conversa com as pessoas que se fizerem necessárias) e, a partir do problema a ser resolvido (aplicação a ser desenvolvida), ele organiza suas ideias e cria um minimundo (que é um subconjunto da realidade contendo os dados necessários para a resolução do problema sendo tratado). O minimundo tem dados que vão ajudar a descrever o modelo conceitual (mais alto nível de abstração), o modelo lógico é especificado a partir do modelo conceitual e é implementado pelo modelo físico (que é quem realmente é usado para criar o banco de dados (BD)). Figura 2 - Relação entre os modelos de dados 9

10 Vamos descrever mais formalmente esse processo de criação do BD (que equivale ao processo de projeto do banco de dados)? Bem, podemos dizer que esse processo é composto por quatro fases (vide Figura 3). Na primeira fase, é feito o Levantamento e Análise dos Requisitos. Nessa fase são realizadas entrevistas com os potenciais utilizadores do BD, são levantados documentos importantes, pode-se olhar um sistema legado (já existente) para ver como ele funciona, tudo com o objetivo de compreender e documentar os requisitos 1 necessários para a construção do banco de dados (requisitos de BD). Lembrete 1 Um requisito consiste da definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender. Ou de uma característica, atributo, habilidade ou qualidade que um sistema (ou qualquer um de seus módulos e subrotinas) deve necessariamente prover para ser útil a seus usuários. A segunda fase é o projeto conceitual (ou modelagem) cujo objetivo é definir um modelo de dados conceitual que inclua a descrição das entidades do BD, dos atributos das entidades, dos relacionamentos entre entidades, além das possíveis restrições. Porém, evitando detalhes de implementação. Essa fase dá origem ao esquema conceitual representado pelo modelo entidade-relacionamento (que estudaremos em detalhes na próxima seção). A terceira fase é o projeto lógico (ou implementação) que objetiva mapear o modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem ao esquema lógico representado pelo modelo relacional que já é um modelo que depende do SGBD que será usado para implementar o banco de dados. A quarta e última fase é o projeto físico que objetiva mapear o modelo de dados relacional para o modelo de dados físico que tratará das estruturas em memória e organização dos arquivos do BD (arquivos de índices). Essa fase dá origem ao esquema físico que será o que realmente será implementado no BD. Figura 3 - Projeto de Esquemas de BD (Fonte: Elmasri, 1994) 10

11 Como a fase de análise de requisitos faz parte do contexto de estudo da disciplina de análise de sistemas, vamos começar a nossa explicação a partir do projeto conceitual de BD. Nesta etapa é criado o modelo entidade-relacionamento (no caso de bancos de dados relacionais foco desta disciplina) e este é justamente o assunto da próxima seção. O Modelo Entidade-Relacionamento Primeiro vamos contar a história desse modelo... O modelo entidaderelacionamento (conhecido como MER) foi originalmente definido por Peter Chen em 1976 e é baseado na teoria relacional criada em 1970 por Codd. Posteriormente, na década de 80, o MER sofreu algumas extensões para tornar-se mais preciso na representação do mundo real. Atualmente, ele é o modelo de dados conceitual mais difundido e utilizado para modelagem de bancos de dados relacionais. Para iniciar o projeto conceitual do BD, deve ter sido antes definido qual o problema a ser resolvido, ou seja, deve-se ter determinado as fronteiras que delimitam e restringem o minimundo a ser modelado e realizado a especificação desse minimundo. Tudo isso faz parte da etapa de análise dos requisitos. A partir justamente da especificação feita é que você irá extrair as informações necessárias para desenhar a primeira versão do MER. Segundo Silberschatz (1999), o MER tem por base a percepção de que o mundo real é formado por um conjunto de objetos chamados entidades e pelo conjunto dos relacionamentos entre esses objetos. Na verdade, existem três noções básicas empregadas pelo MER: conjunto de entidades, conjunto de relacionamentos e conjunto de atributos. Só para ilustrar, na Figura 4 apresentamos um micro exemplo de MER onde estão representadas as entidades cliente e conta, cada uma com seus atributos. As duas entidades se relacionam através do relacionamento cliente-conta. Figura 4 - Um pequeno exemplo de MER Só a título de curiosidade, como ficaria o microdiagrama da Figura 4 se estivessemos tratando da modelagem de um banco de dados orientado a objetos ou objeto-relacional? Como vimos, nestes tipos de bancos de dados é usado o diagrama de classes da UML para representação da modelagem conceitual. Esse diagrama consiste de uma coleção de objetos básicos agrupados em classes e nos relacionamentos entre essas classes. E cada classe possui os seus atributos (características) e métodos (operações que as classes podem 11

12 realizar). Uma versão orientada a objetos do diagrama da Figura 4 é ilustrada na Figura 5. Até que se olharmos os componentes, os dois diagramas são até um pouco parecidos, não é? Figura 5 - Exemplo de Diagrama de Classes Componentes do Modelo Entidade-Relacionamento Explicaremos, detalhadamente, a seguir, cada componente do MER. Depois, no próximo capítulo apresentaremos como você irá juntar tudo para criar um diagrama E-R. Vamos lá? Entidades O objeto básico que o MER representa é a entidade. Uma entidade é algo do mundo real que possui uma existência independente. Uma entidade pode ser um objeto com uma existência física (por exemplo, uma pessoa, um DVD, um carro ou um livro), nesse caso é chamada entidade concreta. Ou pode ser um objeto com existência conceitual (por exemplo, uma locação, um curso, um empréstimo ou um projeto), nesse caso é chamada entidade abstrata. Em outras palavras, é um objeto concreto ou abstrato da realidade modelada, sobre o qual se deseja manter informações no BD. Graficamente, entidades são representadas por um retângulo com um nome dentro (vide Figura 6). Esse nome deve vir no singular e deve ser representativo. Figura 6 - Exemplos de entidades É importante que toda entidade criada seja descrita em um dicionário de dados. Mas o que é um dicionário de dados? Ele é um documento com a explicação de todos os objetos criados no banco de dados (entidades, atributos e relacionamentos). Ele permite que os analistas obtenham informações sobre todos os objetos do modelo de forma textual, contendo explicações por vezes difíceis de incluir no diagrama. A maioria dos SGBDs atuais já fornece ferramentas para facilitar a inclusão de informações no dicionário de dados, deixando assim os objetos criados bem melhor documentados (você vai conseguir saber exatamente quem é quem e para quê serve). Nesta etapa de definição da entidades, a 12

13 informação possível de colocar no dicionário é apenas a descrição da entidade. Na Figura 7, você pode ver exemplos de como poderia ser a descrição das entidades Empregado e Encomenda em um dicionário de dados. Entidade: Empregado Encomenda Descrição: Pessoa que mantém vínculo empregatício com a Empresa através de um contrato de trabalho de acordo com a legislação trabalhista. Instrumento contratual de emissão unilateral pela empresa e aceitação, expressa ou tácita, pelo fornecedor do material. Figura 7 - Exemplo de Descrição de Entidade em um Dicionário de Dados Um conjunto de entidades é um conjunto que abrange entidades de mesmo tipo que compartilham as mesmas propriedades (atributos). Por exemplo, todos os empregados de uma empresa. Cada entidade tem propriedades particulares, chamadas atributos, que a descrevem. Ou seja, ela é representada por um conjunto de atributos. Por exemplo, uma entidade EMPREGADO pode ser descrita pelas propriedades nome, cargo que ocupa, idade e estado civil. Essas propriedades seriam os atributos da entidade EMPREGADO. Uma entidade em particular terá um valor para cada um de seus atributos. Essa entidade em particular, que tenha os atributos preenchidos com valores é chamada instância da entidade. Entidade X Instância de Entidade Para se referir a uma entidade particular fala-se em instância ou ocorrência de entidade. Uma instância é um objeto de uma entiedade com suas respectivas propriedades preenchidas com valores, distinguindo assim ela de qualquer outra instância. Vamos exemplificar: a entidade empregado descrita há pouco, possui os atributos nome, cargo que ocupa, idade e estado civil. Uma instância dessa entidade poderia ser: Maria, secretária, 31 anos, solteira. Ou seja, a instância é como se fosse um exemplo de empregado, com os atributos preenchidos com valores. Entendeu? Atributos São propriedades descritivas de cada membro/propriedade de uma entidade ou relacionamento. Em outras palavras, uma entidade sempre é representada por um conjunto de atributos. No exemplo que citamos na seção anterior, um EMPREGADO podia ser descrito pelos atributos nome, cargo que ocupa, idade e estado civil. Em algumas situações, como veremos mais a frente, relacionamentos também podem ter atributos. Cada instância de uma entidade ou relacionamento tem seu próprio valor para cada atributo. Por exemplo, o atributo nome do empregado pode ter os valores Ana, Maria, João, Igor, etc. O conjunto de valores permitidos para cada atributo é chamado de domínio (é a definição do tipo do atributo). Por exemplo: nome = texto com 60 posições conta = inteiro com 8 posições consulta = texto com 8 posições Os atributos podem ser dos seguintes tipos: simples, compostos, monovalorados, multivalorados, nulos e derivados. Simples os atributos simples não podem ser divididos, são atômicos. Por exemplo: 13

14 Salário, CPF, idade, entre outros. Compostos os atributos compostos podem ser divididos em partes (ou seja, podem ser quebrados em outros atributos mais simples/elementares). Por exemplo: endereço pode ser dividido em rua, número, bairro e CEP. O atributo NomeCliente pode se dividido em prenome, nomeintermediário e sobrenome. Atributos compostos são usados quando o usuário desejar se referir ao atributo como um todo em certas ocasiões e somente a parte dele em outras. Se o atributo composto for sempre referenciado como um todo, não existe razão para subdividi-lo em componentes elementares. Monovalorados Os atributos monovalorados possuem apenas um valor por entidade. Por exemplo: o atributo CPF de uma entidade Cliente refere-se apenas a um nº de CPF é, então, monovalorado. Outro exemplo pode ser o atributo data de nascimento. Multivalorados Atributos multivalorados podem possuir um conjunto de valores para uma única entidade. Por exemplo: na entidade do Cliente pode existir um atributo telefone e um cliente pode ter cadastrado um, nenhum ou vários telefones (ex: telefone residencial, comercial e celular). Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mínima e máxima de valores que ele pode assumir. Nulos Um atributo nulo é usado quando uma entidade não possui valor para um determinado atributo. Nulo significa que o valor do atributo é vazio (não-aplicável) ou ainda não foi informado (desconhecido). Por exemplo: Se o empregado não possui número da carteira de reservista (por ser do sexo feminino), o valor nulo é atribuído a este atributo para esta entidade, significando que o atributo não é aplicável a ele. Outro exemplo é o atributo complemento (do endereço) que, geralmente, é utilizado para colocar o número do apartamento onde alguém, tal como um cliente, mora. Porém, se a pessoa mora em casa, esse campo não é preenchido, ficando nulo. O atributo nulo pode, também, ser utilizado para denotar que o valor é desconhecido, como por exemplo, quando o cliente em um cadastro não responde o número do CEP da rua onde reside. O CEP existe e é aplicável, apenas o cliente pode não saber o CEP naquele momento (o CEP é deconhecido). Logo, nos primeiros exemplos dados aqui, o significado do uso do nulo era não aplicável e, neste último exemplo, o significado do nulo é desconhecido. Derivados O valor desse tipo de atributo pode ser derivado de outros atributos ou entidades a ele relacionados. Por exemplo: suponha que se deseje colocar na entidade cliente o atributo emprestimosrealizados, que representa o número de empréstimos tomados do banco por um cliente. Esse atributo não necessitaria ser preenchido, o valor dele poderia ser obtido contanto o número de entidades empréstimos existentes. Outro exemplo: suponha que se deseje colocar na entidade Pessoa o campo idade. Como ele está relacionado com o campo data de nascimento de uma pessoa, a idade não precisaria ser explicitamente preenchida. Seu valor poderia ser derivado da data de nascimento, fazendo a seguinte conta: data atual menos a data de nascimento. O uso de atributos derivados é uma decisão de projeto, dependendo da necessidade e do bom senso. Os atributos são representados no MER por elipses (contendo o nome dos atributos) ligadas às entidades ou relacionamentos (sim, relacionamentos também podem possuir atributos, falaremos sobre isso na próxima seção!) aos quais estes atributos pertencem. No exemplo da Figura 8, temos as entidades CLIENTE e CONTA. A entidade CLIENTE tem os atributos RG, nome, cidade e endereço e a entidade CONTA, os atributos número, saldo e data. Atributos Derivados é que possuem uma representação diferenciada, sendo representados por elipses tracejadas. E atributos multivalorados são representados por elipses duplas (uma elipse dentro da outra). 14

15 Figura 8 - Exemplo de MER com os atributos sendo representados Identificador de Entidade Identificador de entidade é um (simples) ou mais (composto) atributos cujos valores identificam unicamente uma entidade. Ou seja, o identificador deve possuir um valor único para cada entidade, não admitindo valores repetidos do atributo (ou dos atributos) que o compõem. Por convenção, o atributo identificador é representado sempre de forma diferenciada dos outros atributos. Na notação que vimos anteriormente, ele seria representado sublinhado. E na notação de Peter Chen usa-se um círculo preto para o atributo identificador e círculos brancos para o restante dos atributos. Por exemplo, na Figura 9 (lado esquerdo), vemos a entidade CLIENTE onde o atributo CPF é o identificador da entidade (como é um único atributo, é um identificador simples). E na Figura 9 (lado direito), temos que a entidade ALUNO tem os atributos código e nome, sendo que o código é o atributo identificador da entidade. Figura 9 - Exemplo de entidades com o identificador simples Na Figura 10 vemos exemplos de identificadores compostos. Um identificador composto possui dois ou mais atributos como identificadores da entidade. Em ambos os desenhos da Figura 10 está representada a entidade PRATELEIRA que tem como identificador os atributos corredor e armário e um atributo extra chamado capacidade. Figura 10 - Exemplo de entidade PRATELEIRA com identificador composto (notação convencional e notação Heuser) 15

16 Na prática, você verá que a maioria dos MER não apresenta os atributos. Por que será? Os atributos, em geral, não são representados no MER para não sobrecarregar (graficamente) a apresentação do diagrama. Isso deixa o diagrama entidade-relacionamento mais legível. Eles, geralmente, são apresentados em uma representação textual à parte do diagrama E-R. Relacionamentos São associações entre uma ou várias entidades. Em outras palavras, são funções que mapeiam um conjunto de instâncias de uma entidade em outro conjunto de instâncias de outra entidade (ou da mesma entidade, como é o caso do autorrelacionamento ). Vamos dar um exemplo: departamento emprega funcionário (vide Figura 11). Departamento e Funcionário seriam entidades ligadas através do relacionamento emprega, sendo representado na figura por um losango com o nome do relacionamento. Figura 11 - Exemplo de relacionamento Formalmente, o relacionamento é uma relação matemática com n > = 2 (onde n é o número de conjuntos entidades que fazem parte do relacionamento). Da mesma forma que temos entidades e instâncias de entidades, também temos relacionamentos e instância de relacionamentos. A instância de relacionamento se refere a um relacionamento em particular (uma ocorrência). Por exemplo, para o exemplo da figura 10: Departamento emprega Funcionário, poderíamos ter o relacionamento que associa o Departamento Financeiro ao Funcionário Igor, significando que Igor trabalha no departamento financeiro. Esse relacionamento específico seria um exemplo de instância. Como já vizualizado na Figura 11, o relacionamento é representado graficamente por um losango (com o nome do relacionamento dentro) interligando as entidades que ele relaciona. Às vezes, pode existir mais de um relacionamento entre as mesmas entidades, no entanto, eles são independentes entre si. Por exemplo, Professor leciona Curso e Professor coordena Curso (vide Figura 12) são dois relacionamentos distintos entre as duas mesmas entidades Professor e Curso. Todo relacionamento deve ter uma cardinalidade e um grau associado e pode vir a ter atributos, como veremos a seguir. 16

17 Figura 12 - Exemplo de dois relacionamentos entre as mesmas entidades Cardinalidade do Relacionamento A cardinalidade caracteriza o número mínimo e máximo de instâncias de cada entidade que podem estar associadas através do relacionamento. Dado um relacionamento R entre as entidades A e B (vide Figura 13), o grau ou cardinalidade especifica valores que vão responder às seguintes perguntas: 1. Com quantos elementos de B se relaciona cada um dos elementos de A? 2. Dado um elemento de B, com quantos elementos de A ele se relaciona? Figura 13 - Relacionamento R entre as entidades A e B Assim, as cardinalidades podem ser dos seguintes tipos:» Um para um (1:1): Uma entidade de A está associada, no máximo, a uma entidade de B, e uma entidade de B está associada a, no máximo, uma entidade de A. É como se cada instância da entidade A só encontrasse uma instância correspondente na entidade B (vide Figura 14). Por exemplo, Pessoa recebe Certidão de Óbito. Cada pessoa só pode receber uma única certidão de óbito (só se morre uma vez, não é?) e uma certidão de óbito só deve pertencer a uma única pessoa (vide Figura 15). Logo, esse relacionamento é dito um para um. 17

18 Figura 14 - Esquema de um relacionamento 1:1 Figura 15 - Exemplo de relacionamento um para um» Um para muitos (1:N): Uma entidade em A está associada a várias entidades em B. Uma entidade em B, entretanto, deve estar associada a, no máximo, uma entidade em A. É como se cada instância da entidade A encontrasse zero ou mais instâncias correspondentes na entidade B, porém, cada instância da entidade B só encontrasse uma única instância correspondente em A (vide Figura 16). Por exemplo, Empresa possui Filial. Cada empresa pode possuir zero ou mais filiais (ou seja, N filiais, porque o N significa 0, 1, 2 ou mais). Mas uma filial só pertence a uma única empresa (vide Figura 17). Figura 16 - Esquema de relacionamento 1:N 18

19 Figura 17 - Exemplo de relacionamento 1:N» Muitos para um: é o contrário da anterior. Aqui, uma entidade em A está associada a, no máximo, uma entidade em B. E uma entidade em B pode estar associada a zero, uma ou mais entidades (N entidades) em A. É como se cada instância da entidade A encontrasse apenas uma instância correspondente na entidade B. Mas, cada instância da entidade B encontrasse zero ou mais instâncias correspondentes na entidade A (vide Figura 18). Por exemplo, Aluno é orientado por Professor. Um aluno só é orientado por um professor (de repente, é regra da faculdade onde ele estuda), mas um professor pode orientar zero ou mais alunos (N alunos), conforme pode ser visto na Figura 19. Figura 18 - Esquema de relacionamento N:1 Figura 19 - Exemplo de relacionamento N:1» Muitos para Muitos (M:N): Uma entidade em A está associada a qualquer número de entidades em B e uma entidade em B está associada a um número qualquer de entidades em A. É como se cada instância da entidade A encontrasse zero, um ou mais instâncias correspondentes na entidade B. E cada instância da entidade B encontrasse zero, uma ou mais instâncias correspondentes na entidade A (vide Figura 20). Por exemplo, Aluno cursa Disciplina, um aluno cursa zero, uma ou mais disciplinas e uma disciplina é cursada por zero, um ou mais alunos (vide Figura 21). Outro exemplo é Médico consulta Paciente. Um médico consulta zero, um ou mais Pacientes. E um Paciente é consultado por zero, um ou mais médicos (por exemplo, a pessoa pode ter ido a um endocrinologista e em um cardiologista), conforme 19

20 pode ser visto no diagrama exemplo da Figura 22. Figura 20 - Esquema de relacionamento M:N Figura 21 - Exemplo de relacionamento M:N Figura 22 - Outro exemplo de relacionamento M:N O mapeamento apropriado da cardinalidade (às vezes chamada também de multiplicidade) de um relacionamento dependente da realidade a ser modelada. Não existe uma receita de bolo! Por exemplo, suponha o relacionamento Empregado trabalha em Projeto. Em uma determinada empresa poderia ser que só fosse permitido a um empregado trabalhar em um projeto por vez (Figura 23, primeira imagem). Assim o relacionameto seria de cardinalidade N:1, onde um empregado só trabalha em um projeto e um projeto pode ter N empregados (lembrando que N equivale a zero, um ou mais empregados). Porém, em outra empresa, poderia ser possível que um empregado trabalhe em N projetos. Dessa forma, o relacionamento seria de cardinalidade M:N (Figura 23, segunda imagem), onde um empregado poderia trabalhar em N projetos e um projeto poderia ter M empregados. Então, como foi dito, a definição da cardinalidade vai depender do problema sendo modelado. 20

21 Figura 23 - A cardinalidade depende da realidade sendo modelada Notação de Peter Chen para Cardinalidade A notação de Chen faz uso de dois tipos de cardinalidade: mínima e máxima. Essas cardinalidades são representadas por: (cardinalidade mínima, cardinalidade máxima). A cardinalidade mínima expressa o número mínimo de ocorrências de determinada entidade associada a uma ocorrência da entidade em questão através do relacionamento. Para fins de projeto define-se a cardinalidade mínima como 1 ou 0, onde :» 1 = associação obrigatória (indica que o relacionamento deve obrigatoriamente associar uma ocorrência de entidade a cada ocorrência da outra entidade a qual se relaciona). Também chamada de relacionamento total.» 0 = associação opcional (indica que o relacionamento não é obrigatório, ou seja, é opcional associar uma ocorrência de entidade a ocorrência da outra entidade a qual se relaciona). Também chamada de relacionamento parcial. A cardinalidade máxima expressa o número máximo de ocorrências de determinada entidade, associada a uma ocorrência da entidade em questão, através do relacionamento. Para fins de projeto defini-se como 1 ou N. Por exemplo, na Figura 24, temos o relacionamento Empregado possui Dependente. A cardinalidade (0,N) representa que um empregado pode ter 0 ou mais dependentes, sendo 0 (zero) a cardinalidade mínima e N a cardinalidade máxima. Justamente porque essa cardinalidade representa que o empregado pode não ter nenhum dependente, dizemos que a associação é opcional. Já a cardinalidade (1,1) representa que um dependente deve ter no mínimo 1 e no máximo 1 empregado ao qual está filiado. Aqui, como se for criado um dependente deve existir no mínimo 1 Empregado, dizemos que a associação é obrigatória. Não pode existir dependente sem uma associação a um empregado. Ou seja, uma ocorrência de empregado pode não estar associada a uma ocorrência de dependente ou pode estar associada a várias ocorrências dele (determinado empregado pode não possuir dependentes ou pode possuir vários). E uma ocorrência de dependente está associada a apenas uma ocorrência de empregado (cada dependente possui apenas um empregado responsável). Figura 24 - Exemplo de uso da cardinalidade na notação de Peter Chen 21

22 Grau de Relacionamento O grau de um relacionamento indica o número de entidades participantes do mesmo. Assim, o relacionamento TRABALHA da Figura 23 é de grau dois, ou seja, o relacionamento está ligado a duas entidades. Um relacionamento de grau dois é chamado binário. Um relacionamento entre três entidades é dito de grau três ou relacionamento ternário. Um exemplo desse tipo de relacionamento é o relacionamento TRABALHA da Figura 25. Cada instância de relacionamento T associa três entidades um empregado E, um projeto P e um cliente C - onde o empregado E trabalha no projeto P para o cliente C. Figura 25 - Exemplo de relacionamento ternário Quando temos relacionamentos com grau maior que dois, o conceito de cardinalidade de relacionamento é uma extensão não trivial do conceito de cardinalidade em relacionamentos binários. Ou seja, não é uma tarefa muito fácil determinar a cardinalidade. Tínhamos antes que, em um relacionamento binário R entre duas entidades A e B, a cardinalidade de A em R indica quantas ocorrências de B podem estar associadas a cada ocorrência de A. No caso de um relacionamento ternário, a cardinalidade refere-se a pares de entidades e não a uma única como no relacionamento binário. Assim, em um relacionamento R entre três entidades A, B e C, a cardinalidade de A e B dentro de R indica quantas ocorrências de C podem estar associadas a um par de ocorrências de A e B. Vamos tentar clarear com um exemplo. Na figura 26, a cardinalidade circulada 1 (também apontada pela seta) significa que cada par de ocorrências (empregado, projeto) está associado a, no máximo, um cliente. Em outras palavras, cada projeto onde estão alocados empregados só possui um cliente que é o dono (contratante) daquele projeto com aquela equipe de empregados. Já os outros dois N de cardinalidade expressam que: a um par (cliente, projeto) podem estar associados muitos empregados (N empregados), ou seja, o projeto do cliente pode ter diversos empregados alocados nele. E, finalmente, a um par (empregado, cliente) podem estar associados muitos projetos, ou seja, um empregado pode trabalhar para um cliente em vários projetos (N projetos) diferentes. Mais complicado, não é? Figura 26 - Em relacionamentos ternários, as cardinalidades são postas aos pares 22

23 A notícia boa é que podem existir tipos de relacionamento de qualquer grau, porém é muito mais frequente encontrar o tipo de relacionamento de grau dois (binário). Autorrelacionamentos Um relacionamento não associa apenas entidades diferentes. Às vezes, é necessário relacionar instâncias de uma mesma entidade, ou seja, relacionar a entidade com ela mesma. Isso é chamado autorrelacionamento ou relacionamento recursivo. Vamos dar um exemplo. Suponha o relacionamento Empregado supervisiona Empregado, significando que um supervisor também é um empregado e ele supervisiona outros empregados. Nesse caso, não seria correto usar duas entidades Empregado diferentes, porque estamos falando da mesma entidade. Dessa forma, o relacionamento seria entre a entidade Empregado e ela mesma, através do relacionamento supervisiona (vide Figura 27). Consequentemente, a entidade EMPREGADO participa duas vezes do relacionamento: uma vez no papel de supervisor e outra no papel de supervisionado. Figura 27 - Exemplo de autorrelacionamento Veja que as cardinalidades são diferentes, mas apenas com as cardinalidades não fica claro qual se refere ao supervisor e qual se refere ao supervisionado (até daria usando a lógica: Um empregado supervisor supervisiona N empregados e cada empregado tem apenas um supervisor, mas não fica explícito no diagrama). Logo, neste caso, precisamos de algo mais para identificar os relacionamentos do que apenas as cardinalidades, para não deixar dúvidas. Esse algo mais é a definição de papéis. Papel é a função que uma instância de uma entidade cumpre em uma instância de um relacionamento. Na verdade, cada tipo de entidade que participa de um tipo de relacionamento possui um papel específico no relacionamento. Em autorrelacionamentos é essencial identificar os nomes dos papéis a fim de distinguir o significado de cada participação. Já relacionamentos entre entidades diferentes, em geral, não requerem a especificação de papéis. Dessa forma, o autorrelacionamento da Figura 27, com o uso de papéis ficaria como especificado na Figura 28. Figura 28 - Autorrelacionamento usando papéis Agora, fica mais claro que cada empregado tem apenas um único supervisor e um supervisor pode supervisionar N empregados (os supervisionados). Outro exemplo de autorrelacionamento com papéis seria o apresentado na Figura 29. Nele temos Pessoa casa com Pessoa. Nesse relacionamento é necessário especificar os papéis, no caso, marido 23

24 e esposa. Supõe-se que, na nossa cultura, esse deve ser um relacionamento 1:1 J Figura 29 - Outro exemplo de autorrelacionamento com uso de papéis Relacionamentos com Atributos Assim como entidades possuem atributos, relacionamentos também podem possuir atributos. A Figura 30 mostra um DER no qual o relacionamento ATUA possui um atributo chamado função. Esse atributo função vai representar a função/papel que um empregado exerce dentro de um projeto. E por que colocar esse atributo no relacionamento e não em uma das entidades? Bem, se o atributo função ficasse na entidade EMPREGADO, o empregado, independente do projeto, exerceria sempre a mesma função, já que ele seria fixo da entidade. Logo, o atributo não poderia ficar nessa entidade, pois um empregado pode atuar em diversos projetos ao mesmo tempo, exercendo diferentes funções. E se o atributo função ficasse na entidade PROJETO, todos os empregados daquele projeto teriam a mesma função. Logo, o atributo função não pode ficar na entidade PROJETO já que, em um projeto, podem atuar diversos empregados, cada um como uma função diferente. Assim, o melhor lugar para este atributo é no relacionamento. Ou seja, cada vez que um empregado for relacionado a um projeto (momento em que a instância do relacionamento é criada), ele exercerá/atuará em uma função diferente. O mesmo Empregado pode desempenhar funções diferentes em projetos diferentes Figura 30 - Exemplo de relacionamento com atributo Outro exemplo de atributo em relacionamento pode ser visto na Figura 30. Este diagrama modela vendas em uma organização comercial. Algumas vendas são à vista, outras a prazo. Vendas a prazo são relacionadas a uma financeira, através do relacionamento FINANCIA. As vendas a prazo precisam ter informações sobre a quantidade de parcelas e 24

25 a taxa de juros que será cobrada. Onde poderiam ser colocados esses atributos? Se estes dois atributos fossem incluídos na entidade VENDA, eles deveriam ser atributos opcionais 2, já que nem toda venda é a prazo e precisa destes atributos (ocasionando em atributos sem preenchimento, ou seja, atributos nulos). Logo, a fim de explicitar o fato de os atributos Qtd_Parcelas e Tx_Juros pertencerem somente às vendas a prazo, preferimos colocá-los no relacionamento FINANCIA (vide Figura 31). Saiba Mais 2 Atributos opcionais não tem obrigatoriedade de prenchimento. Figura 31 - Outro exemplo de relacionamento com atributos Relacionamento Identificador Há casos em que o identificador de uma entidade é composto não somente por atributos da própria entidade, mas, também, por relacionamentos dos quais a entidade participa (relacionamento identificador). Um exemplo deste caso é mostrado na Figura 32. Na figura, o cliente possui dependente. Cada dependente está relacionado a exatamente um cliente. Um dependente é identificado pelo CPF do cliente ao qual ele está relacionado e por um número sequencial que o distingue dos diferentes dependentes que um mesmo cliente possa ter. Veja que, na Figura 32, o relacionamento usado como identificador é indicado por um losango com linhas duplas e a entidade que é dependente de outra (entidade fraca) também é representada com linhas duplas. Saiba Mais Figura 32 - Entidade Fraca Nesse caso, alguns autores dizem que a entidade DEPENDENTE é uma entidade fraca. O termo fraca deriva-se do fato de a entidade somente existir quando relacionada a outra entidade (denominada entidade forte 3 ), que, no caso, é a entidade CLIENTE e de usar como parte de seu identificador o identificador da entidade forte. Na verdade, o 3 Entidade forte é aquela que possui o seu próprio identificador e não depende de nenhuma outra entidade para isso. 25

26 identificador da entidade fraca é composto pelo identificador da entidade forte a qual a existência dela está associada mais algum atributo (geralmente um sequencial) da própria entidade fraca. O relacionamento que associa a entidade fraca a seu proprietário (a entidade forte) é, justamente, o relacionamento identificador (no caso da Figura 32, o relacionamento POSSUI). Atenção O termo Entidade Fraca deve ser usado com cautela, pois uma entidade fraca em um relacionamento não necessariamente é também fraca em outro relacionamento. Extensões do Modelo Entidade-Relacionamento Apesar de ser possível modelar a maioria dos bancos de dados apenas com os conceitos básicos do E-R, alguns aspectos de um banco de dados podem ser expressos de modo mais conveniente por meio de algumas extensões do modelo ER. Vamos descrever melhor essas extensões, a seguir. Especialização/Agregação Um conjunto de entidades pode conter subgrupos de entidades que são, de alguma forma, diferentes de outras entidades do conjunto. Esta diferença pode estar caracterizada por um subgrupo possuir atributos que não são compartilhados pelas demais entidades do conjunto. A especialização permite atribuir propriedades particulares a um subconjunto de entidades especializadas através da herança de propriedades (atributos) de uma entidade mais genérica. A especialização no diagrama é representada pelo triângulo. Alguns autores utilizam um triângulo rotulado de ISA (de is a em inglês, ou seja, é um(a) ). Por exemplo, na Figura 33 temos uma entidade genérica CLIENTE e duas entidades que derivam dessa entidade genérica, as entidades especializadas: P. FÍSICA e P. JURÍDICA. Qual a vantagem disso? P.FISICA e P.JURIDICA irão ter todos os atributos que a entidade CLIENTE possuir, mas podem ter atributos adicionais, diferentes entre elas. Elas são casos especializados da entidade CLIENTE. Figura 33 - Exemplo de Especialização/Generalização 26

27 O refinamento do conjunto de entidades em níveis sucessivos de subgrupos indica um processo top-down (de cima para baixo) de projeto. É esse processo que é feito pela especialização. O projeto pode ser realizado, também, de modo bottom-up (de baixo para cima), na qual vários conjuntos de entidades são sintetizados em uma entidade de alto nível, com base em atributos comuns. Esse é o processo de generalização. Assim, na prática, a generalização é simplesmente o inverso da especialização e, para efeito de representação, usa-se a mesma simbologia (um triângulo). Só que o sentido da criação é invertido. Na generalização, a entidade genérica é criada a partir dos atributos que as entidades especializadas tenham em comum. No exemplo da Figura 33, seria como se a gente olhasse para as entidades P.FISICA e P.JURÍDICA e extraísse dessas entidades os atributos que elas tivessem em comum e, a partir disso, criasse a entidade genérica CLIENTE. A generalização/especialização pode ser classificada em dois tipos, total ou parcial, de acordo com a obrigatoriedade ou não de a uma ocorrência da entidade genérica corresponder a uma ocorrência da entidade especializada. Em uma generalização/especialização total para cada ocorrência da entidade genérica existe sempre uma ocorrência em uma das entidades especializadas. Por exemplo, na Figura 34, toda ocorrência da entidade CLIENTE corresponde uma ocorrência em uma das duas especializações (P.FISICA ou P.JURÍDICA). Esse tipo de generalização/especialização é simbolizado por um t, ao lado do triângulo. Figura 34 - Exemplo de generalização/especialização total Em uma generalização/especialização parcial, nem toda ocorrência da entidade genérica possui uma ocorrência correspondente em uma entidade especializada. Por exemplo, na Figura 35, nem toda entidade FUNCIONÁRIO possui uma entidade correspondente em uma das duas especializações (ou seja, nem todo funcionário é CHEFE ou DIRETOR). Esse tipo de generalização/especialização é simbolizado por um p ao lado do triângulo. Figura 35 - Exemplo de generalização/especialização parcial 27

28 Geralmente, quando há uma especialização parcial, na entidade genérica (no caso do exemplo, em FUNCIONÁRIO) aparece um atributo que identifica o tipo de ocorrência da entidade genérica (no caso do exemplo, trata-se do atributo Tp_Func). Este atributo não é necessário no caso de especializações totais, já que a presença da ocorrência correspondente à entidade genérica em uma de suas especializações é suficiente para identificar o tipo da entidade. Herança de Atributos É uma propriedade decisiva das entidades de níveis superior e inferior criadas pela especialização e pela generalização. Através dela, nos relacionamentos de generalização e especialização, as entidades de nível inferior herdam os atributos e os relacionamentos das entidades de nível superior. Como já comentado sobre a Figura 33, as entidades especializadas P. FISICA e P.JURIDICA herdam todos os atributos e relacionamentos da entidade genérica CLIENTE, podendo ter, adicionalmente, mais algum atributo ou relacionamento próprio. Entidade Associativa (ou Agregação) Uma limitação do modelo E-R é que não é possível expressar relacionamento entre relacionamentos. Logo a entidade associativa ou agregação é usada para substituir a associação entre relacionamentos (ou seja, ela ajuda a representar um relacionamento entre relacionamentos), uma vez que faz o relacionamento passar a ser tratado como uma entidade. As notações possíveis podem ser vistas na Figura 36. Como visto na figura o relacionamento completo (relacionamento + entidades envolvidas) ou apenas o relacionamento em si é contornado por um retângulo, para representar a agregação. Figura 36 - Representação Gráfica da Agregação Vamos dar um exemplo. Suponha o relacionamento Médico consulta Paciente (vide Figura 37). Suponha, também, que seja necessário modificar este diagrama com a adição da informação de que, em cada consulta, um ou mais medicamentos podem ser prescritos ao paciente. Para tanto, dever-se-ia criar uma nova entidade chamada 28

29 MEDICAMENTO. Daí, a questão seria: com que entidade existente deve estar relacionada a nova entidade MEDICAMENTO? Se a entidade MEDICAMENTO fosse relacionada a entidade MEDICO, se teria apenas a informação de qual médico prescreveu quais medicamentos, faltando a informação do paciente para os quais os medicamentos foram prescritos. Por outro lado, se a entidade MEDICAMENTO fosse relacionada a entidade PACIENTE, ficaria faltando a informação de qual médico prescreveu o medicamento. Logo, é possível ver que o ideal é relacionar a nova entidade MEDICAMENTO ao relacionamento CONSULTA, porque é lá que estão as informações de ambos médico e paciente. Para poder fazer isso, o relacionamento CONSULTA deve ser redefinido como uma entidade associativa (para passar a ser tratado como uma entidade convencional). Graficamente, isto é indicado na Figura 37 pelo retângulo desenhado ao redor do relacionamento CONSULTA. Dessa forma, agora, sendo CONSULTA também uma entidade, é possível associá-la através do relacionamento PRESCREVE à nova entidade MEDICAMENTO. Figura 37 - Exemplo de agregação Caso não se deseje usar o conceito de entidade associativa, é possível transformar o relacionamento em entidade, a qual pode ser relacionada com as demais entidades. Por exemplo, na Figura 38, o relacionamento CONSULTA foi substituído por uma entidade de mesmo nome, que vai se relacionar com as entidades MEDICO e PACIENTE através de relacionamentos (cada consulta tem um médico e um paciente envolvidos). Devido a essa transformação é possível relacionar a entidade CONSULTA com a nova entidade MEDICAMENTO, sem problemas. 29