Você está na página 1de 78

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

COORDENAO GERAL DE EDUCAO A DISTNCIA (EAD/UFRPE)

Banco de Dados

Sandra de Albuquerque Siebra

Volume 2

Recife, 2010

Universidade Federal Rural de Pernambuco Reitor: Prof. Valmar Corra de Andrade Vice-Reitor: Prof. Reginaldo Barros Pr-Reitor de Administrao: Prof. Francisco Fernando Ramos Carvalho Pr-Reitor de Extenso: Prof. Paulo Donizeti Siepierski Pr-Reitor de Pesquisa e Ps-Graduao: Prof. Fernando Jos Freire Pr-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira Pr-Reitora de Ensino de Graduao: Prof. Maria Jos de Sena Coordenao Geral de Ensino a Distncia: Prof Marizete Silva Santos

Produo Grfica e Editorial Capa e Editorao: Allyson Vila Nova, Rafael Lira, Italo Amorim e Heitor Barbosa Reviso Ortogrfica: Marcelo Melo Ilustraes: No Aprgio, Diego Almeida e Moiss Souza Coordenao de Produo: Marizete Silva Santos

Sumrio
Apresentao................................................................................................................. 4 Conhecendo o Volume 2 ................................................................................................ 5 Captulo 4 Modelagem de Banco de Dados.................................................................. 7 Modelo de Dados ............................................................................................................7 O Modelo Entidade-Relacionamento ............................................................................11 Notao de Peter Chen para Cardinalidade...................................................................21 Extenses do Modelo Entidade-Relacionamento ..........................................................26 Ferramentas para Modelagem de Dados ......................................................................30 Consideraes Finais .....................................................................................................33 Captulo 5 Desenhando o MER .................................................................................. 44 Peculiaridades dos Modelos ER .....................................................................................44 Critrios para Construo do Modelo ER ......................................................................47 Evitando Atributos Multivalorados ................................................................................50 Criando o Diagrama ER ..................................................................................................51 Verificao do Modelo Criado .......................................................................................53 Consideraes Finais .....................................................................................................61 Captulo 6 Outras Notaes para o MER .................................................................... 68 Notao da Engenharia de Informaes........................................................................68 Notao MERISE ............................................................................................................71 Consideraes Finais .....................................................................................................73 Consideraes Finais .................................................................................................... 76 Conhecendo a Autora .................................................................................................. 78

Apresentao
Caro(a) cursista, Seja bem-vindo(a) ao segundo mdulo do curso Banco de Dados! Neste segundo mdulo, vamos estudar um assunto que considero um dos mais importantes para o aprendizado de Banco de Dados: a modelagem conceitual dos dados que sero armazenados. Por que ela importante? Porque ela o comeo de tudo. Um banco de dados comea a existir na modelagem. E, se um banco de dados modelado errado, consequentemente, voc ter um banco de dados que no 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. Assim, como esse um assunto muito importante, procure dedicar bastante ateno e tempo ao mesmo, ok? Bons estudos! Sandra de Albuquerque Siebra Autora

Banco de Dados

Conhecendo o Volume 2
Neste segundo volume, voc ir encontrar o Mdulo 2 da disciplina de Banco de Dados. Para facilitar seus estudos, veja a organizao deste segundo mdulo.

Mdulo 2 Modelagem e Projeto de Banco de Dados


Carga horria do Mdulo 2: 15 h/aula Objetivo do Mdulo 2: Introduzir os principais conceitos e definies relacionados modelagem de dados. Examinar os principais conceitos envolvidos em um projeto conceitual de BD. Ensinar a projetar banco de dados relacionais confiveis e eficientes. Contedo Programtico do Mdulo 2: Modelos de Dados Conceitos; Modelos Lgicos baseados em Registros; hierrquico, 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.

Banco de Dados

Captulo 4
O que vamos estudar neste captulo?
Neste captulo, vamos estudar os seguintes temas: Modelo de Dados. Componentes do Modelo Entidade-Relacionamento (MER). Ferramenta para Modelagem de Dados.

Metas
Aps o estudo deste captulo, 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.

Banco de Dados

Captulo 4 Modelagem de Banco de


Dados
Vamos conversar sobre o assunto?
Se voc pretende desenvolver aplicaes que usam banco de dados relacionais, voc, com certeza, dever possuir os conceitos bsicos sobre modelagem de dados. No importa o tamanho da sua aplicao ou a complexidade da mesma, sempre ser muito importante ter bem projetado o local onde os dados sero armazenados, de forma que eles possam ser recuperados de forma fcil, ntegra e correta. justamente o como fazer o projeto de banco de dados que veremos nesse captulo. Lembre, esse um dos assuntos mais importantes da nossa disciplina, logo, leia esse captulo com mais ateno do que qualquer outro e no esquea de praticar os conceitos que sero aprendidos. Vamos l?

Neste captulo, vamos falar sobre modelos de dados e modelagem de dados. Aproveite bem tudo que vem pela frente!

Modelo de Dados
Lembra do conceito de abstrao de dados que explicamos no captulo 3, do fascculo I da disciplina? Pois so os modelos de dados as principais ferramentas que fornecem a abstrao a um BD, visto que o modelo de dados representa, de forma abstrata, como aspectos do mundo real (fatos) esto 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 restries pertinentes aos dados que sero armazenados no BD. Muitos modelos de dados tambm definem um conjunto de operaes 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 espao em disco e aproveitar os recursos disponveis no SGBD chamado modelagem de dados. Ou seja, processo para a criao do modelo de dados. Mas por que modelar os dados? Qual o objetivo disso? importante modelar os dados a fim de conhecer melhor as informaes dos usurios e como elas se relacionam a fim de representar, da melhor forma, o ambiente observado criando, por consequncia, bancos de dados mais corretos e eficientes. Um projeto mal feito pode trazer diversos problemas, tais como: o banco de dados e/ou aplicao podem no funcionar adequadamente; os dados podem no ser confiveis ou sero 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).

Banco de Dados

Figura 1 - Ciclo de Desenvolvimento de SBDs

E quais so as outras etapas? Primeiro, para poder realizar a modelagem dos dados, voc precisa fazer um levantamento de requisitos. Ou seja, precisa investigar quais dados devero fazer parte do banco de dados, a fim de representar bem o problema a ser resolvido e poder atender as necessidades de armazenamento (persistncia) dos dados da aplicao. 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) atravs 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 nvel que possam ser criadas dentro do SGBD. Posteriormente, o BD realmente implementado usando algum dos SGBDs disponveis no mercado e, depois, mantido e monitorado pelo administrardor de banco de dados. Existem modelos para diferentes nveis de abstrao de representao de dados. So eles: modelos conceituais (tambm conhecido como modelo com base em objetos), modelos lgicos (tambm conhecido como modelo com base em registros) e modelos fsicos. Vamos descrever melhor cada um deles a seguir.

Modelo Conceitual
a primeira etapa da modelagem de dados, sendo a descrio mais abstrata da realidade, modelando de forma mais natural os fatos do mundo real, suas propriedades e relacionamentos. utilizado para entendimento, transmisso, validao de conceitos, mapeamento do ambiente e para facilitar o dilogo entre usurios e desenvolvedores. A modelagem conceitual do BD independe da sua implementao, no contendo nenhum detalhe da mesma. Assim, a modelagem conceitual independente do SGBD utilizado para implementao do BD. De fato, o modelo conceitual registra que dados podem aparecer no banco de dados, mas no registra como estes dados esto armazenados em nvel de SGBD. A modelagem conceitual dos bancos de dados relacionais feita atravs da criao 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 Lgico
Representa os dados em alguma estrutura (lgica) de armazenamento de dados, que

Banco de Dados

vai depender do SGBD a ser utilizado. Ou seja, este modelo vai especificar a representao/ declarao dos dados de acordo com o SGBD escolhido, definindo assim a estrutura de registros do BD (onde cada registro define nmero fixo de campos (atributos) e cada campo possui tamanho fixo). Um exemplo de modelo lgico o modelo relacional. O modelo relacional usa um conjunto de tabelas para representar tanto os dados como a relao entre eles. Cada tabela possui mltiplas colunas e cada coluna possui um nome nico. Apesar de existirem outras representaes de modelo lgico, nesta disciplina trataremos apenas dos modelos lgicos referentes a SGBD relacional.

Modelo Fsico
So usados para descrever os dados no nvel mais baixo, tratando de aspectos de implementao do SGBD (como indexao e estruturao de arquivos, controle de concorrncia, transaes, recuperao em casos de falhas, entre outros). As linguagens e notaes para o modelo fsico no so padronizadas e variam de produto a produto (so dependentes do SGBD). Alm disso, a tendncia dos produtos modernos cada vez mais esconder o modelo fsico.

Ateno
Os modelos fsicos no so o foco desta disciplina e, por consequncia, no sero tratados na mesma.

Todos esses modelos, na verdade, so vises diferentes, com nvel 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 tambm conversa com as pessoas que se fizerem necessrias) e, a partir do problema a ser resolvido (aplicao a ser desenvolvida), ele organiza suas ideias e cria um minimundo (que um subconjunto da realidade contendo os dados necessrios para a resoluo do problema sendo tratado). O minimundo tem dados que vo ajudar a descrever o modelo conceitual (mais alto nvel de abstrao), o modelo lgico especificado a partir do modelo conceitual e implementado pelo modelo fsico (que quem realmente usado para criar o banco de dados (BD)).

Figura 2 - Relao entre os modelos de dados

Banco de Dados

Vamos descrever mais formalmente esse processo de criao 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 Anlise dos Requisitos. Nessa fase so realizadas entrevistas com os potenciais utilizadores do BD, so 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 requisitos1 necessrios para a construo do banco de dados (requisitos de BD).

Lembrete
1 Um requisito consiste da definio documentada de uma propriedade ou comportamento que um produto ou servio particular deve atender. Ou de uma caracterstica, atributo, habilidade ou qualidade que um sistema (ou qualquer um de seus mdulos e subrotinas) deve necessariamente prover para ser til a seus usurios.

A segunda fase o projeto conceitual (ou modelagem) cujo objetivo definir um modelo de dados conceitual que inclua a descrio das entidades do BD, dos atributos das entidades, dos relacionamentos entre entidades, alm das possveis restries. Porm, evitando detalhes de implementao. Essa fase d origem ao esquema conceitual representado pelo modelo entidade-relacionamento (que estudaremos em detalhes na prxima seo). A terceira fase o projeto lgico (ou implementao) que objetiva mapear o modelo de dados conceitual para o modelo de dados relacional. Essa fase d origem ao esquema lgico 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 fsico que objetiva mapear o modelo de dados relacional para o modelo de dados fsico que tratar das estruturas em memria e organizao dos arquivos do BD (arquivos de ndices). Essa fase d origem ao esquema fsico que ser o que realmente ser implementado no BD.

Figura 3 - Projeto de Esquemas de BD (Fonte: Elmasri, 1994)

10

Banco de Dados

Como a fase de anlise de requisitos faz parte do contexto de estudo da disciplina de anlise de sistemas, vamos comear a nossa explicao 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 prxima seo.

O Modelo Entidade-Relacionamento
Primeiro vamos contar a histria 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 dcada de 80, o MER sofreu algumas extenses para tornar-se mais preciso na representao 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 especificao desse minimundo. Tudo isso faz parte da etapa de anlise dos requisitos. A partir justamente da especificao feita que voc ir extrair as informaes necessrias para desenhar a primeira verso do MER. Segundo Silberschatz (1999), o MER tem por base a percepo de que o mundo real formado por um conjunto de objetos chamados entidades e pelo conjunto dos relacionamentos entre esses objetos. Na verdade, existem trs noes bsicas 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 esto representadas as entidades cliente e conta, cada uma com seus atributos. As duas entidades se relacionam atravs do relacionamento cliente-conta.

Figura 4 - Um pequeno exemplo de MER

S a ttulo 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 representao da modelagem conceitual. Esse diagrama consiste de uma coleo de objetos bsicos agrupados em classes e nos relacionamentos entre essas classes. E cada classe possui os seus atributos (caractersticas) e mtodos (operaes que as classes podem

11

Banco de Dados

realizar). Uma verso orientada a objetos do diagrama da Figura 4 ilustrada na Figura 5. At que se olharmos os componentes, os dois diagramas so at um pouco parecidos, no ?

Figura 5 - Exemplo de Diagrama de Classes

Componentes do Modelo Entidade-Relacionamento


Explicaremos, detalhadamente, a seguir, cada componente do MER. Depois, no prximo captulo apresentaremos como voc ir juntar tudo para criar um diagrama E-R. Vamos l?

Entidades
O objeto bsico que o MER representa a entidade. Uma entidade algo do mundo real que possui uma existncia independente. Uma entidade pode ser um objeto com uma existncia fsica (por exemplo, uma pessoa, um DVD, um carro ou um livro), nesse caso chamada entidade concreta. Ou pode ser um objeto com existncia conceitual (por exemplo, uma locao, um curso, um emprstimo 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 informaes no BD. Graficamente, entidades so representadas por um retngulo 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 dicionrio de dados. Mas o que um dicionrio de dados? Ele um documento com a explicao de todos os objetos criados no banco de dados (entidades, atributos e relacionamentos). Ele permite que os analistas obtenham informaes sobre todos os objetos do modelo de forma textual, contendo explicaes por vezes difceis de incluir no diagrama. A maioria dos SGBDs atuais j fornece ferramentas para facilitar a incluso de informaes no dicionrio de dados, deixando assim os objetos criados bem melhor documentados (voc vai conseguir saber exatamente quem quem e para qu serve). Nesta etapa de definio da entidades, a

12

Banco de Dados

informao possvel de colocar no dicionrio apenas a descrio da entidade. Na Figura 7, voc pode ver exemplos de como poderia ser a descrio das entidades Empregado e Encomenda em um dicionrio de dados.
Entidade: Empregado Pessoa que mantm vnculo Descrio: empregatcio com a Empresa atravs de um contrato de trabalho de acordo com a legislao trabalhista. Encomenda Instrumento contratual de emisso unilateral pela empresa e aceitao, expressa ou tcita, pelo fornecedor do material.

Figura 7 - Exemplo de Descrio de Entidade em um Dicionrio 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 instncia da entidade.
Entidade X Instncia de Entidade Para se referir a uma entidade particular fala-se em instncia ou ocorrncia de entidade. Uma instncia um objeto de uma entiedade com suas respectivas propriedades preenchidas com valores, distinguindo assim ela de qualquer outra instncia. Vamos exemplificar: a entidade empregado descrita h pouco, possui os atributos nome, cargo que ocupa, idade e estado civil. Uma instncia dessa entidade poderia ser: Maria, secretria, 31 anos, solteira. Ou seja, a instncia como se fosse um exemplo de empregado, com os atributos preenchidos com valores. Entendeu?

Atributos
So 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 seo anterior, um EMPREGADO podia ser descrito pelos atributos nome, cargo que ocupa, idade e estado civil. Em algumas situaes, como veremos mais a frente, relacionamentos tambm podem ter atributos. Cada instncia de uma entidade ou relacionamento tem seu prprio valor para cada atributo. Por exemplo, o atributo nome do empregado pode ter os valores Ana, Maria, Joo, Igor, etc. O conjunto de valores permitidos para cada atributo chamado de domnio ( a definio do tipo do atributo). Por exemplo: nome = texto com 60 posies conta = inteiro com 8 posies consulta = texto com 8 posies Os atributos podem ser dos seguintes tipos: simples, compostos, monovalorados, multivalorados, nulos e derivados. Simples os atributos simples no podem ser divididos, so atmicos. Por exemplo:

13

Banco de Dados

Salrio, 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: endereo pode ser dividido em rua, nmero, bairro e CEP. O atributo NomeCliente pode se dividido em prenome, nomeIntermedirio e sobrenome. Atributos compostos so usados quando o usurio desejar se referir ao atributo como um todo em certas ocasies e somente a parte dele em outras. Se o atributo composto for sempre referenciado como um todo, no existe razo 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 , ento, 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 vrios telefones (ex: telefone residencial, comercial e celular). Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mnima e mxima de valores que ele pode assumir. Nulos Um atributo nulo usado quando uma entidade no possui valor para um determinado atributo. Nulo significa que o valor do atributo vazio (no-aplicvel) ou ainda no foi informado (desconhecido). Por exemplo: Se o empregado no possui nmero da carteira de reservista (por ser do sexo feminino), o valor nulo atribudo a este atributo para esta entidade, significando que o atributo no aplicvel a ele. Outro exemplo o atributo complemento (do endereo) que, geralmente, utilizado para colocar o nmero do apartamento onde algum, tal como um cliente, mora. Porm, se a pessoa mora em casa, esse campo no preenchido, ficando nulo. O atributo nulo pode, tambm, ser utilizado para denotar que o valor desconhecido, como por exemplo, quando o cliente em um cadastro no responde o nmero do CEP da rua onde reside. O CEP existe e aplicvel, apenas o cliente pode no saber o CEP naquele momento (o CEP deconhecido). Logo, nos primeiros exemplos dados aqui, o significado do uso do nulo era no aplicvel 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 nmero de emprstimos tomados do banco por um cliente. Esse atributo no necessitaria ser preenchido, o valor dele poderia ser obtido contanto o nmero de entidades emprstimos 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 no 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 deciso de projeto, dependendo da necessidade e do bom senso. Os atributos so representados no MER por elipses (contendo o nome dos atributos) ligadas s entidades ou relacionamentos (sim, relacionamentos tambm podem possuir atributos, falaremos sobre isso na prxima seo!) 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 endereo e a entidade CONTA, os atributos nmero, saldo e data. Atributos Derivados que possuem uma representao diferenciada, sendo representados por elipses tracejadas. E atributos multivalorados so representados por elipses duplas (uma elipse dentro da outra).

14

Banco de Dados

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, no admitindo valores repetidos do atributo (ou dos atributos) que o compem. Por conveno, o atributo identificador representado sempre de forma diferenciada dos outros atributos. Na notao que vimos anteriormente, ele seria representado sublinhado. E na notao de Peter Chen usa-se um crculo preto para o atributo identificador e crculos 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 cdigo e nome, sendo que o cdigo 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 armrio e um atributo extra chamado capacidade.

Figura 10 - Exemplo de entidade PRATELEIRA com identificador composto (notao convencional e notao Heuser)

15

Banco de Dados

Na prtica, voc ver que a maioria dos MER no apresenta os atributos. Por que ser? Os atributos, em geral, no so representados no MER para no sobrecarregar (graficamente) a apresentao do diagrama. Isso deixa o diagrama entidade-relacionamento mais legvel. Eles, geralmente, so apresentados em uma representao textual parte do diagrama E-R.

Relacionamentos
So associaes entre uma ou vrias entidades. Em outras palavras, so funes que mapeiam um conjunto de instncias de uma entidade em outro conjunto de instncias de outra entidade (ou da mesma entidade, como o caso do autorrelacionamento). Vamos dar um exemplo: departamento emprega funcionrio (vide Figura 11). Departamento e Funcionrio seriam entidades ligadas atravs do relacionamento emprega, sendo representado na figura por um losango com o nome do relacionamento.

Figura 11 - Exemplo de relacionamento

Formalmente, o relacionamento uma relao matemtica com n > = 2 (onde n o nmero de conjuntos entidades que fazem parte do relacionamento). Da mesma forma que temos entidades e instncias de entidades, tambm temos relacionamentos e instncia de relacionamentos. A instncia de relacionamento se refere a um relacionamento em particular (uma ocorrncia). Por exemplo, para o exemplo da figura 10: Departamento emprega Funcionrio, poderamos ter o relacionamento que associa o Departamento Financeiro ao Funcionrio Igor, significando que Igor trabalha no departamento financeiro. Esse relacionamento especfico seria um exemplo de instncia. 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 so independentes entre si. Por exemplo, Professor leciona Curso e Professor coordena Curso (vide Figura 12) so 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

Banco de Dados

Figura 12 - Exemplo de dois relacionamentos entre as mesmas entidades

Cardinalidade do Relacionamento
A cardinalidade caracteriza o nmero mnimo e mximo de instncias de cada entidade que podem estar associadas atravs do relacionamento. Dado um relacionamento R entre as entidades A e B (vide Figura 13), o grau ou cardinalidade especifica valores que vo 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 mximo, a uma entidade de B, e uma entidade de B est associada a, no mximo, uma entidade de A. como se cada instncia da entidade A s encontrasse uma instncia correspondente na entidade B (vide Figura 14). Por exemplo, Pessoa recebe Certido de bito. Cada pessoa s pode receber uma nica certido de bito (s se morre uma vez, no ?) e uma certido de bito s deve pertencer a uma nica pessoa (vide Figura 15). Logo, esse relacionamento dito um para um.

17

Banco de Dados

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 vrias entidades em B. Uma entidade em B, entretanto, deve estar associada a, no mximo, uma entidade em A. como se cada instncia da entidade A encontrasse zero ou mais instncias correspondentes na entidade B, porm, cada instncia da entidade B s encontrasse uma nica instncia 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

Banco de Dados

Figura 17 - Exemplo de relacionamento 1:N

Muitos para um: o contrrio da anterior. Aqui, uma entidade em A est associada a, no mximo, 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 instncia da entidade A encontrasse apenas uma instncia correspondente na entidade B. Mas, cada instncia da entidade B encontrasse zero ou mais instncias 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 nmero de entidades em B e uma entidade em B est associada a um nmero qualquer de entidades em A. como se cada instncia da entidade A encontrasse zero, um ou mais instncias correspondentes na entidade B. E cada instncia da entidade B encontrasse zero, uma ou mais instncias 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 Mdico consulta Paciente. Um mdico consulta zero, um ou mais Pacientes. E um Paciente consultado por zero, um ou mais mdicos (por exemplo, a pessoa pode ter ido a um endocrinologista e em um cardiologista), conforme

19

Banco de Dados

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 tambm de multiplicidade) de um relacionamento dependente da realidade a ser modelada. No 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). Porm, em outra empresa, poderia ser possvel 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. Ento, como foi dito, a definio da cardinalidade vai depender do problema sendo modelado.

20

Banco de Dados

Figura 23 - A cardinalidade depende da realidade sendo modelada

Notao de Peter Chen para Cardinalidade


A notao de Chen faz uso de dois tipos de cardinalidade: mnima e mxima. Essas cardinalidades so representadas por: (cardinalidade mnima, cardinalidade mxima). A cardinalidade mnima expressa o nmero mnimo de ocorrncias de determinada entidade associada a uma ocorrncia da entidade em questo atravs do relacionamento. Para fins de projeto define-se a cardinalidade mnima como 1 ou 0, onde : 1 = associao obrigatria (indica que o relacionamento deve obrigatoriamente associar uma ocorrncia de entidade a cada ocorrncia da outra entidade a qual se relaciona). Tambm chamada de relacionamento total. 0 = associao opcional (indica que o relacionamento no obrigatrio, ou seja, opcional associar uma ocorrncia de entidade a ocorrncia da outra entidade a qual se relaciona). Tambm chamada de relacionamento parcial.

A cardinalidade mxima expressa o nmero mximo de ocorrncias de determinada entidade, associada a uma ocorrncia da entidade em questo, atravs 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 mnima e N a cardinalidade mxima. Justamente porque essa cardinalidade representa que o empregado pode no ter nenhum dependente, dizemos que a associao opcional. J a cardinalidade (1,1) representa que um dependente deve ter no mnimo 1 e no mximo 1 empregado ao qual est filiado. Aqui, como se for criado um dependente deve existir no mnimo 1 Empregado, dizemos que a associao obrigatria. No pode existir dependente sem uma associao a um empregado. Ou seja, uma ocorrncia de empregado pode no estar associada a uma ocorrncia de dependente ou pode estar associada a vrias ocorrncias dele (determinado empregado pode no possuir dependentes ou pode possuir vrios). E uma ocorrncia de dependente est associada a apenas uma ocorrncia de empregado (cada dependente possui apenas um empregado responsvel).

Figura 24 - Exemplo de uso da cardinalidade na notao de Peter Chen

21

Banco de Dados

Grau de Relacionamento
O grau de um relacionamento indica o nmero 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 binrio. Um relacionamento entre trs entidades dito de grau trs ou relacionamento ternrio. Um exemplo desse tipo de relacionamento o relacionamento TRABALHA da Figura 25. Cada instncia de relacionamento T associa trs 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 ternrio

Quando temos relacionamentos com grau maior que dois, o conceito de cardinalidade de relacionamento uma extenso no trivial do conceito de cardinalidade em relacionamentos binrios. Ou seja, no uma tarefa muito fcil determinar a cardinalidade. Tnhamos antes que, em um relacionamento binrio R entre duas entidades A e B, a cardinalidade de A em R indica quantas ocorrncias de B podem estar associadas a cada ocorrncia de A. No caso de um relacionamento ternrio, a cardinalidade refere-se a pares de entidades e no a uma nica como no relacionamento binrio. Assim, em um relacionamento R entre trs entidades A, B e C, a cardinalidade de A e B dentro de R indica quantas ocorrncias de C podem estar associadas a um par de ocorrncias de A e B. Vamos tentar clarear com um exemplo. Na figura 26, a cardinalidade circulada 1 (tambm apontada pela seta) significa que cada par de ocorrncias (empregado, projeto) est associado a, no mximo, um cliente. Em outras palavras, cada projeto onde esto 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 vrios projetos (N projetos) diferentes. Mais complicado, no ?

Figura 26 - Em relacionamentos ternrios, as cardinalidades so postas aos pares

22

Banco de Dados

A notcia boa que podem existir tipos de relacionamento de qualquer grau, porm muito mais frequente encontrar o tipo de relacionamento de grau dois (binrio).

Autorrelacionamentos
Um relacionamento no associa apenas entidades diferentes. s vezes, necessrio relacionar instncias 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 tambm um empregado e ele supervisiona outros empregados. Nesse caso, no 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, atravs 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 so diferentes, mas apenas com as cardinalidades no fica claro qual se refere ao supervisor e qual se refere ao supervisionado (at daria usando a lgica: Um empregado supervisor supervisiona N empregados e cada empregado tem apenas um supervisor, mas no fica explcito no diagrama). Logo, neste caso, precisamos de algo mais para identificar os relacionamentos do que apenas as cardinalidades, para no deixar dvidas. Esse algo mais a definio de papis. Papel a funo que uma instncia de uma entidade cumpre em uma instncia de um relacionamento. Na verdade, cada tipo de entidade que participa de um tipo de relacionamento possui um papel especfico no relacionamento. Em autorrelacionamentos essencial identificar os nomes dos papis a fim de distinguir o significado de cada participao. J relacionamentos entre entidades diferentes, em geral, no requerem a especificao de papis. Dessa forma, o autorrelacionamento da Figura 27, com o uso de papis ficaria como especificado na Figura 28.

Figura 28 - Autorrelacionamento usando papis

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 papis seria o apresentado na Figura 29. Nele temos Pessoa casa com Pessoa. Nesse relacionamento necessrio especificar os papis, no caso, marido

23

Banco de Dados

e esposa. Supe-se que, na nossa cultura, esse deve ser um relacionamento 1:1 J

Figura 29 - Outro exemplo de autorrelacionamento com uso de papis

Relacionamentos com Atributos


Assim como entidades possuem atributos, relacionamentos tambm podem possuir atributos. A Figura 30 mostra um DER no qual o relacionamento ATUA possui um atributo chamado funo. Esse atributo funo vai representar a funo/papel que um empregado exerce dentro de um projeto. E por que colocar esse atributo no relacionamento e no em uma das entidades? Bem, se o atributo funo ficasse na entidade EMPREGADO, o empregado, independente do projeto, exerceria sempre a mesma funo, j que ele seria fixo da entidade. Logo, o atributo no poderia ficar nessa entidade, pois um empregado pode atuar em diversos projetos ao mesmo tempo, exercendo diferentes funes. E se o atributo funo ficasse na entidade PROJETO, todos os empregados daquele projeto teriam a mesma funo. Logo, o atributo funo no pode ficar na entidade PROJETO j que, em um projeto, podem atuar diversos empregados, cada um como uma funo 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 instncia do relacionamento criada), ele exercer/atuar em uma funo diferente.
O mesmo Empregado pode desempenhar funes 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 organizao comercial. Algumas vendas so vista, outras a prazo. Vendas a prazo so relacionadas a uma financeira, atravs do relacionamento FINANCIA. As vendas a prazo precisam ter informaes sobre a quantidade de parcelas e

24

Banco de Dados

a taxa de juros que ser cobrada. Onde poderiam ser colocados esses atributos? Se estes dois atributos fossem includos na entidade VENDA, eles deveriam ser atributos opcionais2, 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
Atributos opcionais no tem obrigatoriedade de prenchimento.
2

Figura 31 - Outro exemplo de relacionamento com atributos

Relacionamento Identificador
H casos em que o identificador de uma entidade composto no somente por atributos da prpria entidade, mas, tambm, 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 nmero 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) tambm representada com linhas duplas.

Saiba Mais
3 Entidade forte aquela que possui o seu prprio identificador e no depende de nenhuma outra entidade para isso.

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 forte3), que, no caso, a entidade CLIENTE e de usar como parte de seu identificador o identificador da entidade forte. Na verdade, o

25

Banco de Dados identificador da entidade fraca composto pelo identificador da entidade forte a qual a existncia dela est associada mais algum atributo (geralmente um sequencial) da prpria entidade fraca. O relacionamento que associa a entidade fraca a seu proprietrio (a entidade forte) , justamente, o relacionamento identificador (no caso da Figura 32, o relacionamento POSSUI).

Ateno
O termo Entidade Fraca deve ser usado com cautela, pois uma entidade fraca em um relacionamento no necessariamente tambm fraca em outro relacionamento.

Extenses do Modelo Entidade-Relacionamento


Apesar de ser possvel modelar a maioria dos bancos de dados apenas com os conceitos bsicos do E-R, alguns aspectos de um banco de dados podem ser expressos de modo mais conveniente por meio de algumas extenses do modelo ER. Vamos descrever melhor essas extenses, a seguir.

Especializao/Agregao
Um conjunto de entidades pode conter subgrupos de entidades que so, de alguma forma, diferentes de outras entidades do conjunto. Esta diferena pode estar caracterizada por um subgrupo possuir atributos que no so compartilhados pelas demais entidades do conjunto. A especializao permite atribuir propriedades particulares a um subconjunto de entidades especializadas atravs da herana de propriedades (atributos) de uma entidade mais genrica. A especializao no diagrama representada pelo tringulo. Alguns autores utilizam um tringulo rotulado de ISA (de is a em ingls, ou seja, um(a)). Por exemplo, na Figura 33 temos uma entidade genrica CLIENTE e duas entidades que derivam dessa entidade genrica, as entidades especializadas: P. FSICA e P. JURDICA. Qual a vantagem disso? P.FISICA e P.JURIDICA iro ter todos os atributos que a entidade CLIENTE possuir, mas podem ter atributos adicionais, diferentes entre elas. Elas so casos especializados da entidade CLIENTE.

Figura 33 - Exemplo de Especializao/Generalizao

26

Banco de Dados

O refinamento do conjunto de entidades em nveis sucessivos de subgrupos indica um processo top-down (de cima para baixo) de projeto. esse processo que feito pela especializao. O projeto pode ser realizado, tambm, de modo bottom-up (de baixo para cima), na qual vrios conjuntos de entidades so sintetizados em uma entidade de alto nvel, com base em atributos comuns. Esse o processo de generalizao. Assim, na prtica, a generalizao simplesmente o inverso da especializao e, para efeito de representao, usa-se a mesma simbologia (um tringulo). S que o sentido da criao invertido. Na generalizao, a entidade genrica 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.JURDICA e extrasse dessas entidades os atributos que elas tivessem em comum e, a partir disso, criasse a entidade genrica CLIENTE. A generalizao/especializao pode ser classificada em dois tipos, total ou parcial, de acordo com a obrigatoriedade ou no de a uma ocorrncia da entidade genrica corresponder a uma ocorrncia da entidade especializada. Em uma generalizao/especializao total para cada ocorrncia da entidade genrica existe sempre uma ocorrncia em uma das entidades especializadas. Por exemplo, na Figura 34, toda ocorrncia da entidade CLIENTE corresponde uma ocorrncia em uma das duas especializaes (P.FISICA ou P.JURDICA). Esse tipo de generalizao/especializao simbolizado por um t, ao lado do tringulo.

Figura 34 - Exemplo de generalizao/especializao total

Em uma generalizao/especializao parcial, nem toda ocorrncia da entidade genrica possui uma ocorrncia correspondente em uma entidade especializada. Por exemplo, na Figura 35, nem toda entidade FUNCIONRIO possui uma entidade correspondente em uma das duas especializaes (ou seja, nem todo funcionrio CHEFE ou DIRETOR). Esse tipo de generalizao/especializao simbolizado por um p ao lado do tringulo.

Figura 35 - Exemplo de generalizao/especializao parcial

27

Banco de Dados

Geralmente, quando h uma especializao parcial, na entidade genrica (no caso do exemplo, em FUNCIONRIO) aparece um atributo que identifica o tipo de ocorrncia da entidade genrica (no caso do exemplo, trata-se do atributo Tp_Func). Este atributo no necessrio no caso de especializaes totais, j que a presena da ocorrncia correspondente entidade genrica em uma de suas especializaes suficiente para identificar o tipo da entidade.

Herana de Atributos
uma propriedade decisiva das entidades de nveis superior e inferior criadas pela especializao e pela generalizao. Atravs dela, nos relacionamentos de generalizao e especializao, as entidades de nvel inferior herdam os atributos e os relacionamentos das entidades de nvel superior. Como j comentado sobre a Figura 33, as entidades especializadas P. FISICA e P.JURIDICA herdam todos os atributos e relacionamentos da entidade genrica CLIENTE, podendo ter, adicionalmente, mais algum atributo ou relacionamento prprio.

Entidade Associativa (ou Agregao)


Uma limitao do modelo E-R que no possvel expressar relacionamento entre relacionamentos. Logo a entidade associativa ou agregao usada para substituir a associao 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 notaes possveis 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 retngulo, para representar a agregao.

Figura 36 - Representao Grfica da Agregao

Vamos dar um exemplo. Suponha o relacionamento Mdico consulta Paciente (vide Figura 37). Suponha, tambm, que seja necessrio modificar este diagrama com a adio da informao 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

Banco de Dados

MEDICAMENTO. Da, a questo 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 informao de qual mdico prescreveu quais medicamentos, faltando a informao do paciente para os quais os medicamentos foram prescritos. Por outro lado, se a entidade MEDICAMENTO fosse relacionada a entidade PACIENTE, ficaria faltando a informao de qual mdico prescreveu o medicamento. Logo, possvel ver que o ideal relacionar a nova entidade MEDICAMENTO ao relacionamento CONSULTA, porque l que esto as informaes de ambos mdico 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 retngulo desenhado ao redor do relacionamento CONSULTA. Dessa forma, agora, sendo CONSULTA tambm uma entidade, possvel associ-la atravs do relacionamento PRESCREVE nova entidade MEDICAMENTO.

Figura 37 - Exemplo de agregao

Caso no se deseje usar o conceito de entidade associativa, possvel transformar o relacionamento em entidade, a qual pode ser relacionada com as demais entidades. Por exemplo, na Figura 38, o relacionamento CONSULTA foi substitudo por uma entidade de mesmo nome, que vai se relacionar com as entidades MEDICO e PACIENTE atravs de relacionamentos (cada consulta tem um mdico e um paciente envolvidos). Devido a essa transformao possvel relacionar a entidade CONSULTA com a nova entidade MEDICAMENTO, sem problemas.

29

Banco de Dados

Figura 38 Forma alternativa ao uso de entidade associativa

Ferramentas para Modelagem de Dados


Para desenhar o DER e at dar apoio a fases posteriores do projeto de banco de dados, como a converso do MER para o modelo relacional (assunto do prximo captulo deste fascculo), existem diversas ferramentas de modelagem de dados. Aqui apresentaremos quatro delas, sendo duas ferramentas gratuitas e duas ferramentas pagas (estas duas ltimas consideradas as melhores pelas pessoas da rea de BD). Entre as que vamos apresentar, a primeira delas, BR-Modelo a mais simples e a que vamos adotar para uso no nosso curso. Vamos conhecer essas ferramentas?

BR-MODELO
Ela uma ferramenta freeware voltada para ensino de modelagem em banco de dados relacional, com base na notao de Peter Chen e no livro de autoria do Professor Carlos A. Heuser chamado Projeto de Bando de Dados, livro este que merece ser lido por voc. Esta ferramenta foi desenvolvida por Carlos Henrique Cndido sob a orientao do Prof. Dr. Ronaldo dos Santos Mello (UFSC), como trabalho de concluso do curso de psgraduao em banco de dados (UNVAG - MT e UFSC). Atualmente, est na verso 2.0 e possui o seu cdigo-fonte disponibilizado para quem desejar modificar a ferramenta (vide site http://sis4.com/brModelo/ ). A ferramenta simples de usar e possui uma interface amigvel (vide Figura 39) e toda a notao usada a notao do livro de Heuser.

30

Banco de Dados

Figura 39 - Tela do BR-Modelo

O software funciona como um editor grfico e possui duas funcionalidades bsicas: Construo do modelo de entidade e relacionamento e Mapeamento para o modelo relacional de banco de dados. A ferramenta d suporte para criao de elementos do MER estendido.

Maiores detalhes sobre a ferramenta e a monografia que a originou esto em: http://chcandido.tripod.com/ DBDesigner
DBDesigner uma ferramenta gratuita para projeto de banco de dados que integra a modelagem, projeto, implementao e manuteno em um mesmo ambiente. Desenvolvida pela empresa Fabulous Force Database Tools, atualmente encontra-se na verso 4 e est disponvel para download em http://fabforce.net/dbdesigner4/ para plataformas Window e Linux (disponibilizada sob a licena GLP). A interface do DBDesigner pode ser visualizada na Figura 40.

Figura 40 - Interface do DBDesigner

31

Banco de Dados

Este programa til para, ao invs de criarmos uma base de dados atravs de cdigos (implementados em linguagem apropriada), criarmos uma base de dados visualmente, com a definio de tabelas, tipos de dados e relaes entre tabelas. E, a partir do resultado final do desenho de uma base de dados, termos acesso ao cdigo que podemos utilizar para a criao da nossa base de dados. O DBDesigner direcionado para o desenvolvimento de banco de dados com o SGBD MySQL, mas tambm oferece suporte para o Ms-SQL e o Oracle.

CA ERwin Saiba Mais


Atravs da Engenharia Reversa possvel obter a partir do banco de dados criado, os diagramas que o geraram.
4

Esta a ferramenta mais utilizada no mercado, conforme informado no site do fabricante (http://erwin.com/). Atravs desta ferramenta, o desenvolvedor de um sistema de informao pode especificar os dados envolvidos, as suas relaes e os requisitos de anlise. A ferramenta permite desde a criao e manuteno da bases de dados, at o uso de mecanismos de sincronizao de dados necessrios. Alm disso, oferece recursos para realizar o processo inverso (Engenharia reversa4). O ERwin gera modelos para todos os principais bancos de dados atuais e pode ser integrado para ajudar no gerenciamento dos mesmos (para atualizao das bases de dados). A notao utilizada pelo ERwin no descende da notao original de Peter Chen, ela implementa diagramas parecidos com os utilizados na Engenharia de Software. A interface da ferramenta pode ser visualizada na Figura 41.

Figura 41 - Interface do Erwin

Sybase PowerDesigner
considerada juntamente com o Erwin, uma das ferramentas mais utilizadas e completas do mercado. Ela gera modelo conceitual, converte para modelo lgico (automaticamente, sem interveno do usurio) e trabalha com todos os principais bancos de dados disponveis empregando inclusive, tcnicas de engenharia reversa e de integridade referencial. Apesar de ser uma ferramenta paga, ela tem uma verso demo disponvel para avaliao por 15 dias no site: http://www.sybase.com.br/products/modelingdevelopment/ powerdesigner ou http://www.sybase.com. A interface da ferramenta pode ser visualizada na Figura 42.

32

Banco de Dados

Figura 42 - Interface do Powerdesigner

Consideraes Finais
Aps o levantamento de requisitos, a modelagem dos dados a primeira grande fase no projeto de banco de dados. E dentro das etapas de modelagem, a modelagem conceitual uma das mais importantes. Uma das vantagens em se trabalhar com projeto conceitual est na possibilidade de se adiar a escolha do SGBD. O projetista deve concentrar o maior esforo nesta fase do projeto, pois a passagem para as outras fases mais ou menos automtica. Outra vantagem est na possibildade de usurios no especialistas em bancos de dados darem diretamente a sua contribuio no projeto conceitual (j que ele mais fcil de ser compreendido do que os outros modelos do projeto de BD). A aproximao com o usurio final melhora bastante a qualidade do projeto.

Conhea Mais
Neste captulo o foco foi modelagem de dados. Principalmente, a modelagem conceitual. Para tanto, focamos na descrio dos elementos componentes do modelo entidade-relacionamento. Para obter mais informaes ou materiais diversificados para o que foi visto aqui, voc pode proceder a uma pesquisa usando o Google (www.google. com.br) com as palavras chaves Modelagem Conceitual + Banco de Dados ou Modelo Entidade-Relacionamento ou ainda Diagrama Entidade-Relacionamento. Voc vai ver que ir vir muito material. Entre eles: apostilas, notas de aula, reportagens, etc. Adicionalmente, voc no pode deixar de consultar o livro do professor Carlos Heuser: HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados Srie Livros Didticos, V.4. Bookman Companhia Ed., 6 Edio - 2009 Tambm qualquer outro livro de Banco de Dados ter, ao menos, um captulo dedicado a modelagem conceitual. Entre esses, podemos citar: SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.

33

Banco de Dados

ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. So Paulo: Pearson Education do Brasil, 2005. DATE, C. J. Introduo a sistemas de bancos de dados. Rio de Janeiro: Campus,

2000.
Sobre as ferramentas apresentadas, eis alguns materiais adicionais: Vdeo-aula sobre o BR-Modelo
http://blog.cidandrade.pro.br/educacao/video-aula-do-brmodelo/ Modelagem e projeto

de banco de dados com o DBDesigner (Por Willian Bolzan) partes 1 e 2


http://www.devmedia.com.br/articles/viewcomp.asp?comp=7773 http://www.devmedia.com.br/articles/viewcomp.asp?comp=7776

Voc Sabia?
Alm de definir a cardinalidade de relacionamento, alguns autores definem tambm cardinalidade para atributos. E o que isso? definir o nmero mnimo e mximo de vezes que aquele atributo pode aparecer. Veja s: Cardinalidade Mnima = 1 Atributo obrigatrio = 0 Atributo opcional Cardinalidade Mxima = 1 Atributo monovalorado = n Atributo multivalorado Vamos dar um exemplo. Na figura 43, temos o relacionamento Cliente possui Dependente, onde um cliente pode ter zero ou mais dependentes e um dependente pertence a um e apenas um cliente. Observe que DEPENDENTE uma entidade fraca e POSSUI um relacionamento identificador. A entidade CLIENTE possui o atributo CPF. Esse atributo obrigatrio (cardinalidade mnima = 1) e monovalorado (cardinalidade mxima = 1), ou seja, ele s pode assumir um nico valor (o que verdade para o nmero do CPF que sempre deve ser nico) e, tambm o atributo identificador (veja que ele est sublinhado) da entidade. J a entidade DEPENDENTE possui dois atributos: o RG, que opcional (cardinalidade mnima = 0) - porque pode ser que o dependente seja menor de idade ou ainda no tenha tirado esse documento e monovalorado (existindo, o RG tambm deve ser nico, por isso a cardinalidade mxima = 1). E o outro atributo o Telefone, que opcional (cardinalidade mnima = 0), porque pode ser que o dependente no tenha nenhum telefone, e multivalorado (cardinalidade mxima = n), porque pode ser que o dependente possa ter mais de um telefone (ex: telefone residencial e telefone celular). Os atributos identificadores da entidade DEPENDENTE so o CPF (da entidade CLIENTE, lembre que DEPENDENTE entidade fraca) e o RG.

34

Banco de Dados

Figura 43 - Exemplo de Cardinalidade em Atributos

Apesar de no ser muito utilizada a cardinalidade de atributos, til conhec-la.

Aprenda Praticando
Vamos dar uma olhada novamente em questes de concurso? Adaptado de CESPE - 2008 - STF - Analista Judicirio - Tecnologia da Informao, CESPE - 2004 - TRE-AL - Analista Judicirio - Especialidade - Anlise de Sistemas Desenvolvimento e CESPE - 2004 - Polcia Federal - Perito Criminal Federal - Informtica 1) O armazenamento e a recuperao de grandes quantidades de dados um trabalho importante e muito explorado em um sistema gerenciador de banco de dados (SGBD). Com relao aos conceitos que envolvem esse sistema, julgue os itens que se seguem com C = certo ou E = Errado. a) ( ) Dado um conjunto de relacionamentos R binrio entre os conjuntos de entidades A e B, correto afirmar que, em um mapeamento de cardinalidade muitos para muitos, uma entidade A est associada a qualquer nmero de entidades em B e uma entidade em B est associada a um nmero qualquer de entidades em A. b) ( ) As caractersticas do atributo CEP - numrico, sequencial e no repetido permitem utiliz-lo como identificador da entidade CLIENTE em um banco de dados destinado ao cadastro de clientes de uma loja. c) ( ) O modelo entidade-relacionamento permite a utilizao de atributos cujo valor derivado de outros atributos. d) ( ) O domnio de um atributo consiste no conjunto de entidades em que tal atributo utilizado. e) ( ) O diagrama ER a seguir ilustra um modelo ER. Nesse diagrama, os retngulos representam entidades, o tringulo representa o conceito de generalizao/ especializao e o losango representa um relacionamento entre entidades.

35

Banco de Dados

Adaptado de TER-RN-FCC 2005 Analista Judicirio/Analista de Sistemas 2) Em um MER, consideremos A uma entidade e K um autorrelacionamento de A. Se A representa o conjunto de cidados de um pas, onde a poligamia ilegal e K representa o relaciomaneto CASAMENTO entre cidados deste pas, podemos dizer que K um relacionamento que se enquadraria no tipo geral: a) um para um b) um para muitos c) muitos para um d) muitos para muitos e) zero para zero CESGRANRIO - 2006 - EPE - Tcnico de Nvel Superior - rea Tecnologia da Informao 3) Considere o DER a seguir. Depois, responda: quantas entidades fracas e quantas entidades fortes, respectivamente, esto presentes neste diagrama?

a) 0 e 1 b) 0 e 2 c) 1 e 1 d) 1 e 2 e) 2 e 1

36

Banco de Dados

Adaptado de CESGRANRIO - 2005 - MPE-RO - Analista Programador

4) Sobre a figura acima, que apresenta elementos utilizados em um tpico DER na qual cada tipo de elemento est identificado por um nmero, so feitas as afirmativas a seguir. I - Os elementos identificados por 1 e 3 no diagrama, respectivamente, so: Entidade e Atributo. II - O elemento identificado no diagrama pelo nmero 2 um relacionamento. III Uma entidade que tem um identificador que no depende de outras entidades chamado de entidade forte. Est(o) correta(s) a(s) afirmativa(s): a) I, apenas. b) I e II, apenas. c) I e III, apenas. d) II e III, apenas. e) I, II e III. CESGRANRIO - 2008 - Petrobrs - Tcnico em Informtica 5) Considere o seguinte enunciado: Uma empresa de gerao de energia deseja armazenar um conjunto de dados importantes sobre os tipos de energia com que trabalha e os seus campos de gerao. Assume-se que: cada campo de gerao de energia de um, e somente um, tipo de energia; pode existir mais de um campo de gerao para cada tipo de energia; podem ser previstos alguns tipos de energia para os quais ainda no existem campos de gerao. Qual diagrama de entidade relacionamento adequado para modelar o problema?

37

Banco de Dados

CESGRANRIO - 2007 - TEC - RO - Analista de Informao 6) Considere o DER (Diagrama Entidade-Relacionamento) abaixo.

incorreto afirmar que: a) idade um atributo derivado. b) emprstimo possui 2 (dois) atributos. c) telefone uma entidade fraca. d) codcliente atributo de cliente. e) codemprstimo identificador da entidade.

Respostas:
1) a) C o relacionamento M:N um relacionamento muitos para muitos e nesse caso, ambas as entidades podem estar relacionadas com qualquer quantidade de instncias de entidades do outro tipo. b) E - o CEP no poderia ser o identificador da entidade cliente. Primeiro, porque no caracteriza um cliente unicamente, mas sim um endereo. Segundo, porque pessoas que morassem na mesma rua, teriam o mesmo CEP. c) C atributo derivado existe no contexto do MER e gerado a partir do valor de outro(s) atributo(s) do modelo. d) E Domnio do atributo o conjunto de valores permitidos para cada atributo, ou seja, a definio do tipo do atributo e) C a simbologia para o DER est toda ok. 2) letra A se no pas proibida a poligamia, o relacionamento de casamento deve ser de 1:1 (um para um) 3) letra D no diagrama existe apenas uma entidade fraca (Item) e duas entidades fortes (Nota e PV) 4) letra E as trs afirmaes so verdadeiras. 5) letra D com as afirmaes feitas, vemos que CampoGeracao deve ter 1 e apenas 1

38

Banco de Dados

tipo de energia. E o tipo de energia pode ter 0 ou mais campos de gerao. 6) letra C esta a incorreta porque telefone no entidade fraca, atributo multivalorado (que pode assumir mais de um valor). Atributo multivalorado representado por elipses duplas (uma dentro da outra).

Atividades e Orientaes de Estudo


Agora vamos exercitar o que foi estudado neste captulo. Assim sendo, faa as atividades sugeridas a seguir. Lembre que exercitar vai lhe ajudar a fixar melhor o contedo estudado. E o contedo desse captulo fundamental para o captulo seguinte. Mos obra!

Atividades Prticas
Responda as questes a seguir em um documento de texto (doc) e poste as respostas no ambiente virtual, no local indicado. Esse trabalho deve ser feito individualmente. Para desenhar os diagramas que forem solicitados, voc j pode praticar o uso da ferramenta BRModelo, fazendo os diagramas nessa ferramenta. Depois, s copiar e colar os diagramas criados no documento com as respostas. Ou voc pode utilizar os prprios recursos do word para desenhar os trechos de diagrama. Essa atividade individual e far parte da sua avaliao somativa. 1) Atravs de exemplos de Diagramas ER, ilustre os conceitos a seguir do modelo ER (no precisa ser em um nico diagrama, pode ser em diagrama separados, um para cada letra a seguir): a) Relacionamento b) Entidade fraca c) Autorrelacionamento d) Especializao/Generalizao e) Agregao 2) Considere as seguintes entidades: EMPREGADO com atributos: CPF, RG, Nome, Dept, Cargo e Salrio. PROJETO com atributos CodProj, ProjNome, DataIncio, DataTrmino e Oramento. a) Mostre como essas duas entidades seriam representadas em um diagrama de ER. Assuma que voc deseja representar o nmero de horas alocadas para um empregado para trabalhar num projeto, e mostre como isto pode ser representado no diagrama. b) Escolha identificadores para cada uma das entidades. c) Fazendo as hipteses necessrias (use sua intuio), tome uma deciso sobre a cardinalidade do relacionamento entre as entidades, explicando o que voc pensou para escolher tal cardinalidade e acrescente os smbolos apropriados ao diagrama. d) Assuma que a entidade EMPREGADO especializado em VENDEDOR e ADMINISTRADOR. Mostre como esta especializao representada em um diagrama ER. Inclua alguns atributos em cada uma das subclasses.

39

Banco de Dados

Atividades de Reflexo
Para voc j ir se preparando para desenhar diversos DERs de nveis de dificuldade diferentes, o que veremos vrias dicas de como fazer isso no prximo captulo, lanamos aqui um desafio: ser que voc seria capaz de criar um diagrama E-R para um problema hospitalar? Esse diagrama simples. A ideia que voc pense no diagrama por partes e depois v juntando as coisas at formar o diagrama completo. Para facilitar, a descrio do problema est dividida em pargrafos. Tente ir analisando eles um a um e depois voc pode juntar o problema como um todo. Vamos descrio do problema? De preferncia, procure desenhar a resposta usando a ferramenta BR-Modelo, para poder ir praticando.
Hospitais so formados por um ou mais ambulatrios e cada um destes est em um nico hospital Mdicos clinicam em um nico hospital, cada hospital possui vrios mdicos Hospitais solicitam exames clnicos em vrios laboratrios, cada laboratrio pode ter solicitaes de vrios hospitais Pacientes consultam vrios mdicos e estes atendem a consulta de vrios pacientes Quando consultado o paciente recebe um diagnstico. O paciente pode ter um diagnstico diferente a cada consulta. Ambulatrios atendem vrios pacientes, enquanto estes s podem ser atendidos em um nico ambulatrio Pessoal de apoio est alocado em um ambulatrio, e cada ambulatrio conta com vrios integrantes do pessoal de apoio. Pacientes realizam vrios testes e cada teste realizado por um paciente Laboratrios fazem vrios testes e cada um dos testes feito em um nico laboratrio

Sua resposta deve ser postada no ambiente virtual, no local apropriado, em um documento de texto (voc tambm pode postar o diagrama gerado pelo BR-Modelo diretamente (arquivo gerado por ele). Essa atividade individual.

40

Banco de Dados

Minibiografia
Edgar Frank Codd

Edgar Frank Codd (Dorset, 23 de agosto de 1923 18 de abril de 2003) foi um matemtico britnico. Ele desenvolveu o modelo de banco de dados relacional, quando era pesquisador no laboratrio da IBM em San Jos. Em junho de 1970, ele publicou um artigo chamado Relational Model of Data for Large Shared Data Banks (Modelo de dados relacional para grandes bancos de dados compartilhados) que foi publicado na Revista ACM (Association for Computing Machinery) Vol. 13, No. 6, pp. 377 387. Este artigo, um desenvolvimento de um artigo interno da IBM publicado no ano anterior, demonstrou os fundamentos da teoria dos bancos de dados relacionais, usando tabelas (linhas e colunas) e operaes matemticas para recuper-las destas tabelas (UNION, SELECT, SUM etc). Devido ao interesse da IBM em preservar o faturamento trazido por produtos pr-relacionais, tais como o IMS/DB, ela no quis, inicialmente, implementar as ideias de Codd. Este ento buscou grandes clientes da IBM para mostrar-lhes as novas potencialidades de uma eventual implementao do modelo relacional. Mesmo com a presso dos clientes IBM, ela no incluiu Codd nos novos projetos sendo implementados. Devido a isso, desgostoso pela rejeio de suas ideias, Codd uniu-se a seu colega Christopher J. Date da IBM para deixar a mesma, fundando uma consultoria chamada Codd & Date. Logo aps adoeceu e teve de encerrar sua carreira, vindo a falecer no comeo do III milnio. Porm, Date continuou a obra de Codd, tornando-se autor de vrios livros importantes da rea de BD.

Vamos Revisar?
Voc estudou, neste captulo, os conceitos de modelo de dados e viu alguns dos modelos existentes: O modelo conceitual (que no tem dependncia do SGBD a ser escolhido), o modelo lgico (que j tem uma certa dependncia do SGBD escolhido) e o modelo fsico que tem completa dependncia do SGBD escolhido. Depois, foi estudado mais a fundo o modelo conceitual, atravs da apresentao dos principais componentes do modelo entidade relacionamento, um dos principais diagramas do projeto de banco de dados. Entre os componentes estudados a simbologia dos principais deles pode ser vista no Quadro 1. Alm dos smbolos, quando pensamos no MER estendido, temos ainda a simbologia apropriada para especializao/generalizao (um tringulo) e entidade associativa. No prximo captulo veremos as dicas e informaes necessrias para unir os componentes estudados nesse captulo a fim de montar diversos diagramas entidaderelacionamento de nveis de complexidade diferentes. At l!

41

Banco de Dados

Quadro 1 - Alguns dos Componentes do MER

42

Banco de Dados

Captulo 5
O que vamos estudar neste captulo?
Neste captulo, vamos estudar os seguintes temas: Como desenhar o DER. Dicas para desenhar bons diagramas. Formas de Modelar o MER.

Metas
Aps o estudo deste captulo, esperamos que voc consiga: Realizar a modelagem de dados usando o Modelo Entidade Relacionamento (MER). Utilizar uma ferramenta de modelagem de dados para desenhar o diagrama entidade-relacionamento. Praticar a criao de diagramas entidade-relacionamento.

43

Banco de Dados

Captulo 5 Desenhando o MER


Vamos conversar sobre o assunto?
Vimos no captulo anterior os componentes necessrios para desenhar o MER, que um dos principais modelos do projeto de banco de dados e faz parte da modelagem conceitual (que independente do SGBD escolhido para implementar o BD). Porm, apesar das explicaes sobre os componentes darem ideia de como os mesmos se relacionam, ainda faltaram dicas, informaes adicionais para proporcionar a criao de diagramas mais complexos. justamente isso que faremos nesse captulo, cujo foco lhe ajudar a fazer a modelagem conceitual de diversos tipos de problemas.

Neste captulo, voc vai encontrar dicas, informaes e diversos exemplos que lhe ajudaro a desenhar diagramas entidade-relacionamento. A partir daqui vamos adotar a notao de Peter Chen. Vamos l?

Peculiaridades dos Modelos ER


Vamos falar aqui de algumas peculiaridades do MER. O modelo entidade-relacionamento um modelo formal, preciso e no ambguo. Logo, diferentes leitores de um mesmo modelo ER devem sempre entender exatamente a mesma coisa. Para isso, importante que todos os envolvidos estejam treinados para perfeita compreenso do modelo ER, caso contrrio, o mesmo pode ser sub-utilizado e/ou gerar implementaes incoerentes com a realidade. Ainda assim, o MER tem poder de expresso limitado, pois este apresenta apenas algumas propriedades de um BD. Isto porque sua notao grfica pouco poderosa, fazendo com que propriedades adicionais devam ser anotadas parte. Alm disso, o MER inadequado para expressar restries de integridade (regras de negcio). Vamos dar um exemplo dessa limitao, a seguir. Por exemplo, suponha o autorrelacionamento Pessoa casa com Pessoa expresso na Figura 44. Temos que uma pessoa casa com apenas outra pessoa. E no relacionamento, uma faz o papel de marido e o outro de esposa. At a tudo bem, no ? J vimos essa explicao para o autorrelacionamento. O problema que o modelo no deixa explcita a restrio que uma pessoa s pode fazer parte de um nico relacionamento, ou seja, s pode existir um relacionamento de casamento por vez. Como assim? Sem essa restrio, uma pessoa pode estar envolvida em mais de um relacionamento do tipo casa. Por exemplo, suponha que exista um relacionamento entre a pessoa p1 e a pessoa p3 (p1 casada com p3). Pelo diagrama, nada impede que tambm exista um relacionamento entre p3 e p6 (p3 casada tambm com p6) e outro relacionamento entre p6 e p8 (p6 tambm casada com p8). Assim como, s pelo diagrama, nada impede que uma pessoa possa ser casada com ela mesma, por exemplo, p5 ser casada com p5 (vide Figura 45), o que viola completamente a realidade.

44

Banco de Dados

Figura 44 - Autorrelacionamento Pessoa Casa Pessoa

Figura 45 - Sem restries de integridade expressas no diagrama, podem haver relacionamentos inconsistentes

Vamos dar outro exemplo dessa violao. Suponha o autorrelacionamento Empregado supervisiona Empregado (vide Figura 46). S pelo diagrama no seria possvel restringir que um subalterno supervisionasse seu superior. Assim, podeira ocorrer de um empregado E1 supervisonar um empregado E3, esse mesmo empregado E3 supervisonar o empregado E5 e esse empregado E5 supervisionar o empregado E1 (vide Figura 47). Isso violaria a integridade do relacionamento, porque como o mais subalterno poderia supervisionar o superior de todos? Esses so alguns exemplos de restries que no so representadas no MER.

Figura 46 - Autorrelacionamento Empregado supervisiona Empregado

45

Banco de Dados

Figura 47 - Outro exemplo de relacionamentos sem checagem de restries

Diferentes modelos ER podem ser equivalentes. Modelos equivalentes expressam a mesma abstrao da realidade (formas diferentes de modelar, mas que possuem o mesmo significado). Para fins de projeto de BD, dois modelos ER so equivalentes se geram o mesmo esquema lgico de BD (vamos estudar sobre isso no prximo captulo). Vamos dar um exemplo. Suponha o enunciado Em uma clnica, um mdico pode consultar zero ou mais pacientes. E um paciente pode ser consultado por um ou mais mdicos. Deve ser mantido um histrico das consultas feitas pelo paciente, armazenando a data e hora em que a consulta ocorreu. Mesmo porque o mesmo paciente pode se consultar vrias vezes com o mesmo mdico. Esse enunciado poderia ser modelado de duas formas: com a consulta sendo um relacionamento (vide Figura 48) e com a consulta sendo uma entidade (vide Figura 49). Em ambos os modelos a realidade estaria correta e bem modelada, apesar dos modelos serem diferentes, pois existe uma equivalncia entre eles.

Figura 48 - Consulta modelada como um relacionamento

Figura 49 - Consulta modelada como uma entidade

46

Banco de Dados

Transformao de Relacionamento n:n em Entidade H variantes da abordagem ER, que ou excluem completamente o uso de relacionamentos n:n, ou excluem apenas os relacionamentos n:n que tm atributos. Para transformar um relacionamento n:n em uma entidade, voc deve representar o relacionamento como uma nova entidade e relacionar essa nova entidade criada s entidades que originalmente participavam do relacionamento. Por exemplo, na Figura 49, a entidade CONSULTA foi originada do relacionamento CONSULTA da Figura 48. E essa nova entidade relacionada s entidades anteriormente existentes (MEDICO e PACIENTE). A nova entidade criada ter como identificador os identificadores das entidades que originalmente participavam do relacionamento e os atributos que eram identificadores do relacionamento original (caso esse tivesse atributos identificadores). Com isso na Figura 49, veja que o atributo data/hora continua sendo atributo identificador. E quanto cardinalidade? Nos relacionamentos em que participa a cardinalidade da entidade criada sempre (1,1). Ou seja, do lado de MEDICO e PACIENTE, a cardinalidade continua fica (1,1). J as cardinalidades das entidades que eram originalmente associadas pelo relacionamento so transcritas ao novo modelo. Ou seja, as cardinalidades previamente existentes ficam perto da nova entidade criada. Assim, no exemplo, um mdico realiza 0 ou mais consultas e um paciente participa de uma ou mais consultas (para ser paciente ele tem de ter participado ao menos de uma).

Um modelo ER pode ser usado como entrada a uma ferramenta CASE5. Ou seja, a partir do desenho do MER feito em uma ferramenta CASE, pode-se gerar o modelo lgico e posteriormente, o modelo fsico do BD (ou, pelo menos, os scripts para fazer isso).

Saiba Mais
5 Ferramentas CASE (do ingls Computer-Aided Software Engineering) so ferramentas automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma ou vrias etapas do ciclo de desenvolvimento de software. No caso, ajudar no projeto e criao do banco de dados.

Critrios para Construo do Modelo ER


Para iniciar a construo do MER, geralmente, algumas dvidas surgem, tais como: qual elemento (entidade, atributo, relacionamento,...) da linguagem ER o mais apropriado para representar uma especfica abstrao da realidade? Para responder essa pergunta no se deve observar um objeto isoladamente. Deve-se procurar observar o contexto dentro do qual o objeto aparece, assim, voc ter uma ideia melhor de como represent-lo. Alm disso, o prprio desenvolvimento do modelo e o aprendizado sobre a realidade iro refinando e aperfeioando o modelo, no decorrer do tempo. Por isso, lembre-se a representao de um objeto est sujeita a alterao durante a modelagem (voc pode mudar de ideia, a medida que compreende melhor o problema). Para ajudar voc nas suas modelagens, vamos agora fornecer algumas dicas e reflexes sobre os pontos de dvida mais comuns.

Representar como Atributo ou como Entidade?


Na descrio dos problemas, pode haver ocasies onde voc ficar em dvida sobre como modelar determinado elemento. Por exemplo, como modelar a cor de um automvel? Seria melhor representar a cor como atributo ou como entidade? (vide Figura 50).

47

Banco de Dados

Figura 50 - Cor como atributo ou como entidade?

Para ajudar a decidir, vamos estabelecer alguns critrios: Se o elemento estiver vinculado a outros elementos, o elemento dever ser representado como Entidade. Vamos dar exemplos de vnculo. Suponha que voc precise saber o fabricante da cor do automvel, a cor precisaria se relacionar com outra entidade chamada Fabricante, logo, ela teria de ser representada como uma entidade. Se voc precisasse saber o cdigo da cor ou em que perodo a cor est disponvel para venda, voc precisaria que a cor fosse representada como uma entidade que teria esses atributos (cdigo e periodoDisponibilidade). Caso voc no precisasse saber nenhuma informao adicional sobre o elemento, ele deve ser representado como Atributo. Por exemplo, se voc realmente s quer saber a cor do automvel e nada mais, a cor um atributo da entidade automvel.

Representar como Atributo ou como Generalizao/Especializao?


Em alguns casos, voc vai ficar em dvida se um elemento deve ser representado como atributo ou se ele d origem a uma generalizao/especializao. Por exemplo, como modelar a funo (categoria funcional) de um empregado? (vide Figura 51).

Figura 51 - Representar como atributo ou como generalizao/especializao

Para ajudar a decidir, o critrio semelhante ao anterior: Se sabe-se que o elemento a ser especializado possui propriedades particulares ou vai precisar se relacionar com outros elementos, voc deve represent-lo como Entidade. Por exemplo, qual o CREA dos empregados que tem categoria funcional Engenheiro? Logo, precisaria haver uma especializao de EMPREGADO chamada ENGENHEIRO e esta entidade teria o atributo CREA. Outro exemplo, que, talvez, pela modelagem da sua empresa, voc precisasse saber o nmero da carteira de motorista e a data da expirao da mesma para aqueles empregado que exercessem o cargo de MOTORISTA. Nesse caso tambm, motorista deveria ser uma

48

Banco de Dados

especializao da entidade EMPREGADO. Deveria ser uma especializao porque voc no precisaria saber a carteira de motorista ou a expirao dela no caso de qualquer outra categoria funcional (para que saber esses dados de um engenheiro, por exemplo?). Caso voc no precisasse saber nenhuma informao adicional sobre o elemento, nem ele vai se relacionar com nenhuma outra entidade, ele deve ser representado como Atributo.

Essa uma forma de evitar atributos opcionais. Porque, no geral, atributos opcionais indicam subconjuntos de entidades que so modelados mais corretamente atravs de especializaes. Por exemplo, sem o uso de especializao, para saber o CRM do empregado se ele for um mdico, o CREA do empregado se ele for um engenheiro ou os dados da carteira de motorista se ele for um motorista, teramos vrios atributos opcionais na mesma entidade. Adicionalmente, ainda seria necessrio um classificador, que no caso o atributo tipo do empregado (vide Figura 52). Assim, dependendo do tipo do empregado, esse ou aquele atributo seria preenchido (atributos opcionais). Um problema com esse modelo, fora deixar vrios atributos em branco por vez, que o modelo no vai expressar as combinaes de preenchimento permitidas ou no (por exemplo, preenchendo o CRM eu no devo preencher o CREA). Assim, para ficar mais claro o preenchimento e para evitar atributos opcionais, interessante fazer uso da generalizao/ especializao. No caso do exemplo, seriam criadas as especializaes MOTORISTA, MEDICO e ENGENHEIRO (vide Figura 53).

Figura 52 - Uso de atributos opcionais e classificador

49

Banco de Dados

Figura 53 - Uso de Generalizao/Especializao

Evitando Atributos Multivalorados


A implementao direta de um atributo multivalorado uma limitao dos SGDBs relacionais6 (no possvel de ser feita diretamente). Assim, possvel representar os atributos multivalorados como entidades. E como decidir como fazer isso? Caso o atributo tenha algum vnculo com outros elementos, ele deve ser representado como entidade. Caso contrrio, como atributo. Vamos ao exemplo. Suponha uma entidade EMPREGADO que possua os atributos multivalorados lanamento do pagamento e dependente (vide Figura 54). Se for importante guardar informaes sobre os dependentes (por exemplo, a data de nascimento e o nome), esse atributo multivalorado dever ser representado como entidade. Se precisarmos saber o valor do lanamento do pagamento e de que tipo foi o lanamento, esse tambm dever ser representado como uma entidade (vide Figura 55). Agora, em alguns casos, o atributo no vai ter nenhum vnculo com nenhum outro elemento. Logo, ele pode continuar sendo representado como atributo multivalorado e ser tratado posteriormente. Por exemplo, o nmero do telefone de uma pessoa um atributo multivalorado que no tem relao com nenhum outro elemento, logo pode ser representado dessa forma (vide Figura 56).

Saiba Mais
Essa limitao no existe nos SGBDR-O (Objeto-Relacional) ou SGBDOO (Orientado a Objetos).
6

Figura 54 - Entidade com atributos multivalorados

50

Banco de Dados

Figura 55 - Atributos multivalorados representados como entidades

Figura 56 - Entidade com atributo multivalorado telefone

Criando o Diagrama ER
Aps realizar as entrevistas com o cliente e/ou usurio(s) para determinar suas necessidades de informao e, com isso, tendo definido qual o problema a ser resolvido, ento hora de comear a desenhar o diagrama ER. Apesar de no existir uma receita de bolo unanimente aceita, possvel dar uma ideia de roteiro. 1. Leia o problema (minimundo traado) vrias vezes, para compreend-lo. Depois, faa uma leitura tentando identificar entidades, relacionamentos e atributos. H alguma dica para isso? H sim. Geralmente, dado um texto descrevendo o banco de dados a ser projetado: a presena de um substantivo usualmente indica uma entidade (ex: nota fiscal, pessoa, empregado, livro, etc). A presena de um verbo uma forte indicao de um relacionamento (ex: consultar, contratar, supervisionar, etc). Um adjetivo, um complemento ou uma caracterstica de um substantivo (entidade) uma forte indicao de um atributo (ex: nome, valor, preo, cor, nmero, etc). Isto no regra, pois existem relacionamentos que no so bem expressos por verbos. Quando isto ocorrer, em geral, une-se os nomes das entidades

51

Banco de Dados

para dar nome ao relacionamento. Por exemplo: cliente_conta, transao_conta. 2. Nessa identificao, procure primeiro pelas entidades. Nem todo substantivo entidade. Descarte aquele que s aparecem uma vez na descrio do problema (no se relacionam com nada), os que no possuem nenhuma caracterstica descrita ou aqueles que s servem para entendimento do problema, mas no so relevantes para resolv-lo. 3. A seguir, procure pelos relacionamentos. Geralmente so indicados pelos verbos que indicam relao entre os substantivos. Geralmente, devemos tentar formar uma sentena do tipo entidade verbo entidade. Por exemplo, Cliente possui Conta, Empregado alocado Projeto. Nessa descoberta dos relacionamento, voc deve procurar identificar se um relacionamento binrio ou ternrio. Se existe algum relacionamento identificador (aquele entre uma entidade forte e outra fraca) e se haver relacionamento com alguma entidade associativa (para evitar relacionamento entre relacionamentos). 4. Descobertos os relacionamentos, procure determinar a cardinalidade mnima e mxima deles. Geralmente, haver alguma indicao no enunciado do problema. Ex: um mdico pode consultar vrios pacientes e um paciente pode ser consultado por vrios mdicos. Isso vai indicar um relacionamento n:n entre as entidades PACIENTE e MEDICO. 5. Na sequncia, procure pelos atributos. Lembre-se, os atributos sero os elementos que caracterizam as entidades e que so relevantes para representao do problema. Procure, tambm, entre esses atributos indicar o atributo identificador (aquele que vai servir para identificar aquela entidade unicamente). Adicionalmente, busque determinar se h algum atributo nos relacionamentos (geralmente, atributos temporais, de quando importante guardar histrico dos acontecimentos ou algo que caracterize o relacionamento). 6. Por fim, faa uma reviso no problema e no diagrama e veja se alguma coisa pode ser melhorada (veja os critrios do comeo desse captulo). Veja, tambm, se h alguma generalizao/especializao que possa ser feita. Alguns cuidados devem ser tomados durante essa criao do DER: Um atributo no pode ter outros atributos associados, de modo que se forem encontrados (em sua aplicao) significa que no se trata de um atributo, mas de uma entidade. Uma entidade que no possua, pelo menos, um atributo alm do atributo identificador ou est com sua especificao incompleta ou no se trata de uma entidade mais de um atributo. Um relacionamento uma associao entre entidades. A completa e perfeita representao de uma associao somente est correta se todas as entidades necessrias para a existncia do relacionamento esto interligadas.

importante gastar um tempo na criao do DER, porque ele ser a base para tudo que vem depois (modelagem lgica e fsica e criao do BD). Erros ocorridos nesta fase acarretam graves atrasos e aumento no custo da implementao do BD e dos sistemas que o utilizaro. Aps criada a primeira verso do DER deve-se apresent-lo ao cliente para que sejam verificados a corretude e a completude do diagrama. H tambm algumas dicas que voc pode seguir para verificar a corretude do seu diagrama. Apresentaremo-las na seo a seguir.

52

Banco de Dados

Verificao do Modelo Criado


Uma vez construdo, um modelo ER deve ser validado e verificado. A verificao o controle de qualidade para garantir um bom modelo. Um bom modelo ER deve: Ser completo Ser correto Ser livre de redundncia Refletir o Aspecto Temporal, quando necessrio Evitar entidades isoladas Vamos detalhar como checar cada ponto dessa, a seguir.

Ser Correto
O modelo deve representar, com fidelidade, a realidade e no deve conter erros de modelagem. Quando no est correto, o modelo pode apresentar dois tipos de erros: Erros sintticos - ocorrem quando os conceitos de modelagem ER no so corretamente empregados, ou seja, h erros na construo do modelo. Por exemplo, associar dois relacionamentos (vide Figura 57 os relacionamentos PRESCREVE e CONSULTA esto associados, o que seria um erro, nestes casos deveria ter sido usada uma entidade associativa) ou fazer um relacionamento entre uma entidade e apenas um atributo de outra entidade.

Figura 57 - Exemplo de erro sinttico (associao entre relacionamentos)

Erros Semnticos ocorrem quando o modelo no retrata a realidade de forma consistente. Eles so mais difceis de verificar do que os erros sintticos. Vamos dar alguns exemplos de erros semnticos.

a) Estabelecer associaes incorretas ou colocar atributos em locais que no atendam os requisitos que foram levantados com os usurios. Suponha que voc deseje modelar o seguinte problema Uma pessoa pode possuir zero ou mais imveis e um imvel pode pertencer a um ou mais pessoas. importante armazenar h quanto tempo cada pessoa possui o seu imvel, lembrando que os imveis podem ser vendidos e mudar de proprietrio. Um erro semntico seria colocar o tempo de posse na entidade imvel (vide Figura 58). Se o problema fosse modelado assim, toda pessoa moraria o mesmo tempo no imvel, mesmo que ele mudasse de dono. O correto seria que o tempo de posse estivesse no relacionamento POSSE.

53

Banco de Dados

Dessa forma, a cada novo dono, o tempo de posse seria diferente.

Figura 58 - Exemplo de Erro Semntico - Atributo no lugar errado

b) Representar um mesmo elemento, ora como entidade, ora como atributo. Por exemplo, na Figura 59, o elemento UNIDADES-FEDERAO est sendo representado como atributo da entidade VEICULO e, tambm, como uma entidade no mesmo diagrama. O correto seria escolher a melhor representao e mant-la em todo diagrama. No caso, como necessrio armazenar informaes sobre as unidades da federao (tais como sigla e nome), elas seriam melhor representadas no diagrama como entidade.

Figura 59 - Exemplo de Erro Semntico Elemento representado ora como entidade, ora como atributo

54

Banco de Dados

c) Usar o nmero incorreto de entidades em um relacionamento ou posicionar uma entidade no local errado. Geralmente, esse erro ocorre quando o problema no foi bem compreendido. Por exemplo, suponha que voc quer modelar uma locadora de DVDs. Na locadora existe, de cada filme, 1 ou mais DVDs (como se fossem cpias do mesmo filme). E cada DVD de apenas um filme. Cada um desses filmes possui uma categoria. Na Figura 60, vemos que a categoria foi inicialmente representada como uma entidade fazendo parte de um relacionamento ternrio. Essa representao estaria equivocada. Ela representaria que apenas a cada vez que um filme fosse associado a uma cpia de DVD que seria associada uma categoria a ele. Porm, isso um erro. Pois, todo filme possui uma categoria (vide a segunda representao na Figura 60), independente da quantidade de cpias de DVD existentes na locadora.

Figura 60 - Exemplo de Erro Sinttico - Entidade Mal Posicionada

Outro erro ainda poderia ser a colocao de cardinalidades erradas nos relacionamentos, tambm consequncia da m interpretao do problema.

Ser Completo
O Modelo deve expressar todos os requisitos do usurio. Ou seja, nada do que seja necessrio para resolver o problema em questo deve ser esquecido, deve deixar de ser representado no modelo. Essa verificao s pode ser feita por um especialista do domnio. Ou seja, por algum que faa parte do cliente e entenda bem do problema a ser resolvido. Por isso mesmo, importante envolver o usurio/cliente do projeto nesta etapa inicial. Adicionalmente, podemos fazer alguns questionamentos para ajudar a verificar a completude do modelo, tais como: Os dados que devem ser obtidos a partir do BD esto presentes? So possveis de serem obtidos a partir do modelo criado? Todas as consultas necessrias podero ter resposta apenas com os elementos que fazem parte do modelo criado?

55

Banco de Dados

Essas perguntas podem ajudar em uma avaliao mais geral, mas realmente, para obter uma avaliao mais precisa, necessrio o especialista do domnio.

Ser Livre de Redundncias


O Modelo ER deve ser mnimo, ou seja, no deve conter duplicidades ou redundncias. E quais tipos de redundncias seriam essas? As mais comuns de acontecerem so: Relacionamentos redundantes ocorre quando um relacionamento desnecessrio. Seu resultado pode ser obtido atravs de outroas relacionamentos. Ou seja, possvel retir-los do modelo ER, sem que haja perda de informao no BD. Por exemplo, vide a Figura 61. Existe um relacionamento entre as entidades DEPTO e MAQUINA chamado LOCALIZA DEPTO, para especificar em qual departamento a mquina est alocada. Por causa desse relacionamento, o relacionamento LOCALIZA FABR que indica em que fbrica a mquina est alocada redundante. Isso porque se se sabe em que fbrica o departamento est (relacionamento entre FABRICA e DEPTO), e se sabe em que departamento a mquina est (relacionamento entre DEPTO e MAQUINA), logo, se sabe onde a mquina est.

Figura 61 - Exemplo de relacionamento redundante

Atributos redundantes ocorre quando acabamos criando atributos desnecessrios no diagrama. Ou porque esses atributos so derivveis ou porque j esto representados de alguma forma no diagrama (por exemplo, em uma entidade relacionada). Vamos dar um exemplo. Na Figura 62, o atributo cdigo do departamento da entidade EMPREGADO redundante, porque esse cdigo poderia ser obtido na entidade DEPARTAMENTO, com a qual a entidade EMPREGADO est relacionada (vide atributo cdigo na entidade DEPARTAMENTO). Tambm, o atributo no. de empregados um atributo redundante porque ele expressa um valor

56

Banco de Dados

que pode ser derivado. Como? Contando quantos empregados esto relacionados ao departamento, seria possvel obter o nmero de empregados do departamento, no necessitando existir um atributo para esse fim.

Figura 62 - Exemplo de Atributos Redundantes

Ateno
Algumas vezes, por questes de performance, um modelo ER pode conter redundncia. a chamada redundncia controlada de dados. Nesses casos, a redundncia deve ser muito bem documentada para no parecer um erro.

Refletir Aspecto Temporal, quando Necessrio


Algumas vezes, determinadas partes do modelo podem precisar possuir uma espcie de histrico, porque certas aplicaes exigem que o BD guarde o histrico dos dados (por motivos legais, por necessidade de auditoria ou de possuir dados histricos que ajudem na tomada de deciso). Por exemplo, uma empresa pode desejar guardar um histrico do valor do salrio pago a um funcinrio no decorrer dos anos. Ou uma imobiliria pode desejar armazenar o perodo em que cada pessoa ficou em determinado imvel alugado. Para criar esse histrico, precisamos identificar os dados temporais, ou sejam, aqueles dados que mudam ao longo do tempo, de acordo com o problema a ser resolvido. Esses dados temporais podem ser: atributos ou relacionamentos. Vamos dar uma olhada e ver exemplos de cada um. Guardando histrico de atributos quando desejamos guardar o histrico de um atributo, ele deve ser transformado em entidade fraca vinculada entidade a qual pertencia, tendo como identificador um atributo do tipo data. Vamos dar um exemplo. Imagine que a empresa precisa guardar o histrico dos salrios de seus empregados. Se o salrio fosse representado apenas como um atributo da entidade EMPREGADO (Figura 63 lado esquerdo), seria guardado apenas um salrio. Se o salrio fosse atualizado, o novo valor sobreporia o valor anterior. Para que o valor anterior no fosse perdido, o salrio teria de ser transformado em uma entidade (entidade fraca com relao entidade EMPREGADO) e teria como identificador

57

Banco de Dados

(atributo com bolinha preta) a data (vide Figura 63 lado direito). Assim, cada salrio cadastrado, seria cadastrado com uma data diferente, dessa forma, o valor anterior do salrio no seria perdido.

Figura 63 - Guardando histrico do atributo salrio

Guardando histrico de relacionamentos quando desejamos guardar o histrico dos valores de um relacionamento, o relacionamento dever passar a cardinalidade n:n e um atributo data dever passar a fazer parte do identificador do relacionamento. Vamos dar o exemplo de trs casos que podem ocorrer.

Caso 1: Relacionamento 1:1 Suponha um enunciado onde, em uma empresa, cada empregado alocado em um computador e cada computador alocado, por vez, para apenas um empregado. Essa representao seria feita com a modelagem expressa na Figura 64 lado esquerdo. Ou seja, com em um relacionamento 1:1 entre as entidades EMPREGADO e COMPUTADOR. Porm, se a empresa desejasse armazenar o histrico de alocaes do computador aos empregados, seria necessrio ter um atributo data como parte do identificador do relacionamento ALOCA e, o relacionamento passaria a ser n:n. Por que mudar a cardinalidade para n:n? Porque agora seria possvel que, dependendo da data, um computador pudesse estar alocado a vrios empregados diferentes (vide Figura 64 lado direito). E um empregado pudesse estar usando computadores diferentes, dependendo da data.

Figura 64 - Guardando histrico de um relacionamento que era 1:1

58

Banco de Dados

Caso 2: Relacionamento 1:n Suponha um enunciado onde, em uma empresa, cada empregado alocado para trabalhar em um projeto e em um projeto trabalham N empregados. De cada empregado deve ser armazenado o nome do mesmo e a funo que ele desempenha no projeto. Para esse enunciado, teramos a modelagem da Figura 65 lado esquerdo, onde h as entiddades EMPREGADO e PROJETO associadas pelo relacionamento Trabalha. A entidade EMPREGADO teria dois atributos nome e funo. Essa modelagem no permite guardar o histrico de em quais projetos um empregado j trabalhou ou que funes desempenhou nesses projetos (at mesmo no mesmo projeto, porque, s vezes, em um mesmo projeto, o empregado pode desempenhar funes diferentes em pocas diferentes). Logo, se fosse necessrio armazenar esse tipo de histrico, teramos, novamente, que transformar o relacionamento em n:n e colocar um atributo data como identificador do relacionamento (vide Figura 65 lado direito). Alm disso, como agora o empregado pode trabalhar em vrios projetos ou mais de uma vez (em pocas diferentes) no mesmo projeto, o atributo funo deveria passar a ser atributo do relacionamento trabalha (e no mais da entidade EMPREGADO).

Figura 65 - Guardando histrico em um relacionamento que era 1:n

Caso 3: Relacionamento n:n Suponha um enunciado onde um aluno cursa vrias disciplinas e uma disciplina pode ser cursada por vrios alunos. Esse problema poderia ser representado pelas entidades ALUNO e DISCIPLINA, assoaciados pelo relacionamento CURSA. O relacionamento poderia at ter um atributo data para indicar quando o aluno cursou a disciplina (vide Figura 66 lado esquerdo). Porm, essa modelagem no permitiria, por exemplo, que um aluno cursasse mais de uma vez a mesma disciplina (ou seja, ele no poderia ser reprovado e repetir a disciplina). Em outras palavras, essa modelagem no permitiria guardar o histrico de um aluno com relao a uma disciplina. Para que isso se tornasse possvel, como o relacionamento j n:n, bastaria tornar o atributo data, um atributo identificador do relacionamento (vide Figura 66 lado direito).

59

Banco de Dados

Figura 66 - Guardando histrico em um relacionamento n:n

Em resumo... Para adicionar o aspecto temporal a uma modelagem, se a mesma envolve relacionamentos 1:1 ou 1:n, devemos tornar esses relacionamentos n:n e adicionar um atributo data como identificador do relacionamento. Se o relacionamento j for n:n, devemos adicionar apenas um atributo data como identificador do relacionamento.

Evitar Entidades Isoladas


Uma entidade isolada uma entidade que no apresenta nenhum relacionamento com outras entidades. A ocorrncia desse tipo de entidade, a princpio incorreta e, na prtica, em modelos rara e deve ser conferida, para verificar se no foi esquecido algum relacionamento. Uma entidade que muitas vezes aparece isolada aquela que modela a organizao na qual o sistema implementado pelo BD est embutida. Por exemplo, se se est desenvolvendo um sistema para uma empresa e se deseja armazenar os dados dessa empresa para consulta posterior, ela pode ser modelada como uma entidade isolada (vide Figura). Por que isso? Porque a empresa seria nica, seria aquela que contratou o desenvolvimento ou comprou o sistema. S ir ser cadastrada uma nica empresa por vez. Assim, no faz sentido relacionar ela no diagrama a nenhuma outra entidade, uma vez que haver uma nica incluso de dados e no ir existir mais de uma ocorrncia da entidade empresa.

Figura 67 - Exemplo de Entidade Isolada modelando a Organizao

Ateno
Outra situao que merece ser investigada o caso de entidades sem atributos. Geralmente, toda entidade deve ter, ao menos o atributo identificador.

60

Banco de Dados

Consideraes Finais
Agora que voc j aprendeu a simbologia do DER e estudou nesse captulo vrias dicas de como desenhar o MER e verificar o modelo criado, resta a voc praticar e praticar muito, lembrando sempre da importncia dessa etapa de modelagem conceitual para o projeto do banco de dados como um todo. Logo, mos obra!

Conhea Mais
As referncias para esse captulo so as mesmas do captulo anterior, pois, na verdade, continuamos no assunto modelagem conceitual. Apenas detalhamos mais como fazer essa modelagem. Agora, no esquea, um dos livros mais interessantes sobre o assunto justamente o do professor Carlos Heuser: HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados Srie Livros Didticos, V.4. Bookman Companhia Ed., 6 Edio 2009. Adicionalmente, os links a seguir podem ser teis: Modelagem de Dados - Metodologia para Modelar um Banco de Dados. http://www.virtual.epm.br/material/tis/curr-bio/bdados/teste.htm Conceitos bsicos de modelagem de dados http://www.macoratti.net/cbmd1.htm Modelagem de dados, uma viso geral http://www.plugmasters.com.br/sys/materias/94/1/Modelagem-de-Dados-1--Vis%E3o-Geral

Aprenda Praticando

1) Baseado nas recomendaes vistas neste captulo, apresente um diagrama ER que modele mais precisamente a realidade apresentada na figura a seguir. Explique no que seu diagrama mais preciso que o mostrado na figura a seguir.

Se olharmos a figura a ser avaliada veremos que ela apresenta alguns problemas de modelagem que podem ser sanados com algumas modificaes no diagrama. Vamos a esses problemas: Atributos opcionais devem ser evitados, porque, no geral, eles indicam subconjuntos de entidades que so modelados mais corretamente atravs de especializaes/generalizaes. No caso da figura, os atributos CPF, nome, sexo e

61

Banco de Dados

data de nascimento deveriam passar a pertencer a clientes do tipo Pessoa Fsica, enquanto que CNPJ e razo social deveriam pertencer a clientes do tipo Pessoa Jurdica. Gerando assim, a especializao. O atributo telefone multivalorado e atributos multivalorados no so bem vindos em modelagens relacionais por se ter dificuldade de implementao do mesmo. Dessa forma, atributos multivalorados quando possuem caractersticas prprias ou quando tm a necessidade de se relacionar com outras entidades, podem ser transformados em entidades. Por isso, vamos supor que no nosso problema gostaramos de armazenar algumas informaes sobre o telefone, tais como: o DDD, o nmero do telefone e o tipo do telefone (residencial, comercial, celular ou para recados). Dessa forma, o atributo multivalorado poderia ser tranformado em entidade. Veja na figura a seguir o diagrama resultante das melhorias feitas.

2) Crie um diagrama entidade-relacionamento para um Sistema de Controle Acadmico fictcio, a partir do problema especificado a seguir.
Sistema para controle acadmico fictcio Cada disciplina possui exatamente um, e somente um, departamento responsvel, o qual pode ser responsvel por muitas disciplinas, inclusive nenhuma. Uma disciplina pode possuir diversas disciplinas como pr-requisitos, inclusive nenhuma. Uma disciplina pode ser pr-requisito de muitas disciplinas, inclusive nenhuma. Uma disciplina pode aparecer no currculo de muitos cursos (inclusive nenhum) e um curso pode possuir muitas disciplinas em seu currculo (inclusive nenhuma) Um aluno est inscrito em exatamente um, e somente um, curso e um curso pode ter muitos alunos inscritos, inclusive nenhum.

O primeiro passo para resolver esse problema dar uma leitura do enunciado como um todo, para ter ideia do problema sendo tratado. Depois, voc vai tornar a ler mas, agora, parando em cada pargrafo e tentando desenhar o que esse pargrafo expressa em um diagrama E-R. medida que vai desenhando, voc pode ir juntando os pedaos do diagrama ( s no repetir entidades ou relacionamentos citados, ir desenhando os novos requisitos indicados ligando ao que j estiver desenhado). Vamos dar alguns exemplos de como ir fazendo isso, antes de mostrar como ficaria o diagrama como um todo. Vamos ao primeiro pargrafo:

62

Banco de Dados

Cada disciplina possui exatamente um, e somente um, departamento responsvel, o qual pode ser responsvel por muitas disciplinas, inclusive nenhuma7. Desse pargrafo podemos tirar que existem duas entidades: DEPARTAMENTO e DISCIPLINA, que esto relacionadas. Como a disciplina possui exatamente um, e somente um, departamento, a cardinalidade de DISCIPLINA para DEPARTAMENTO (1,1). Como cada departamento pode ter muitas disciplinas, inclusive nenhuma, isso j indica a cardinalidade (0,n). Dessa forma, a primeira parte do diagrama seria modelada como segue:

Saiba Mais
7 Sempre que se puder ter nenhuma ocorrncia, isso quer dizer que a cardinalidade mnima do relacionamento zero.

Vamos ao segundo pargrafo:


Uma disciplina pode possuir diversas disciplinas como pr-requisitos, inclusive nenhuma. Uma disciplina pode ser pr-requisito de muitas disciplinas, inclusive nenhuma.

Como o pr-requisito de uma disciplina tambm uma disciplina, esse pargrafo j d a indicao de que vamos precisar de um autorrelacionamento. Como a entidade DISCIPLINA j est desenhada no diagrama, o que voc vai fazer acomplar o novo componente no diagrama que temos at agora. Dessa forma, criamos o relacionamento preRequisito que tem cardinalidade (0,N). Ou seja, uma disciplina tem 0 ou mais prrequisitos e uma disciplina pode ser pr-requisito de 0 ou mais disciplinas.

Vamos ao terceiro pargrafo:


Uma disciplina pode aparecer no currculo de muitos cursos (inclusive nenhum) e um curso pode possuir muitas disciplinas em seu currculo (inclusive nenhuma)

Deste pargrafo tiramos que uma disciplina est relacionada com um curso (ou currculo do curso, se desejar). E o relacionamento, pelo enunciado (0,N) de ambos os lados (um curso pode ter zero ou mais disciplinas e uma disciplina pode fazer parte de zero ou mais cursos). Assim, ficaramos com o seguinte diagrama:

63

Banco de Dados

Finalmente, o ltimo pargrafo:


Um aluno est inscrito em exatamente um, e somente um, curso e um curso pode ter muitos alunos inscritos, inclusive nenhum.

Deste pargrafo, podemos deduzir um relacionamento entre a entidade ALUNO e a entidade CURSO. Sendo que um aluno tem um relacionamento de cardinalidade (1,1) para com o curso e o curso tem cardinalidade (0,N) para com aluno (ele pode ter zero ou mais alunos). Assim, o diagrama ficaria assim:

Claro que voc poderia dar outros nomes aos relacionamentos, visto que eles no so especificados no enunciado, mas deduzidos das relaes descritas no texto. Tambm, a forma de desenhar o diagrama poderia ser diferente (o formato do diagrama, voc poderia desenhar em outra ordem). Apenas as entidades e as cardinalidades no poderiam mudar.

Atividades e Orientaes de Estudo


Agora a sua vez de fazer as atividades! Lembre, praticar muito importante para fixar o contedo estudado!

Atividades Prticas
Resolva as atividades a seguir em um documento texto e poste o mesmo no ambiente virtual, no local indicado. Essa atividade para ser realizada em DUPLA (escolha seu companheiro de trabalho!) e far parte da avaliao somativa de vocs. Para desenhar os diagramas, procure utilizar a ferramenta BR-Modelo e copie e cole os diagramas no documento texto. Outra opo compactar o documento texto (doc) e os arquivos gerados pelo BR-Modelo (ele gera arquivos XML) e postar o arquivo compactado no ambiente virtual. Fica a critrio da equipe qual das opes utilizar. 1) Desenhe no BR-Modelo o MER para a seguinte descrio:
Uma oficina mecnica deseja criar um sistema de informao para controlar os trabalhos realizados pelos seus mecnicos. Quando um automvel chega empresa, deve ser anotado o seu modelo, ano, placa. Todo

64

Banco de Dados

automvel pertence a um cliente que possui um nome e um endereo. Os clientes podem ser pessoas fsicas ou jurdicas. Se o cliente pessoa fsica ento deve ser guardado o nmero do seu RG e seu CPF. J se ele pessoa jurdica deve ser guardado o nmero do seu CNPJ e o seu nome fantasia. O automvel ser ento consertado por um mecnico que o responsvel por este. Os mecnicos da empresa trabalham no sistema de comisso e para cada mecnico deve ser anotado o seu nmero, nome, endereo e sua especialidade. A comisso paga por cada conserto que este realiza, e para o conserto devem ser guardados sua data, sua descrio e o valor deste.

2) Usando a ferramenta BR-Modelo, faa o modelo E-R para a seguinte descrio:


Uma empresa cinematogrfica possui vrios cinemas em diversas localidades. Cada cinema possui uma identificao nica, um nome fantasia e uma capacidade de lotao. Devese saber o endereo completo do cinema, o qual inclui: rua, nmero, bairro, municpio, estado e CEP. Cada cinema possui 1 ou mais salas de exibio, das quais precisamos armazenar o nome e a capacidade (No. de pessoas). Cada filme registrado com um ttulo original, e se for filme estrangeiro, possuir tambm o ttulo em portugus e o pas de origem. Os filmes possuem uma durao, um elenco (com vrios atores), um ou mais diretores e podem ser dos mais variados gneros (ex: romance, ao, terror, etc). Os atores ou diretores de um filme podem, obviamente, trabalhar em outros filmes, assim como o diretor de um filme pode tambm ser ator neste filme ou em outros. Qualquer pessoa (ator ou diretor) possui: n de identificao, nome, nacionalidade e data de nascimento. Alguns cinemas apresentam mais de um filme em cartaz por sala, dependendo do horrio. Assim, uma sala pode ter um ou mais filmes em cartaz e um filme pode estar em cartas em uma ou mais salas. Cada vez que um filme associado a uma sala, deve ser registrado os dias e horrios de exibio desse filme.

3) Usando a ferramenta BR-Modelo, faa o modelo E-R para a seguinte descrio:


Uma locadora de carros possui vrias filiais. Cada filial possui diversos carros para alugar. Existem vrios tipos de carro: popular, luxo, utilitrio, etc. Os carros possuem cdigo (chapa do carro), modelo, ano, cor, chassis, km, valor do aluguel. Os clientes da locadora alugam carros. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguis. Para cada aluguel emitida uma nota fiscal com a quilometragem percorrida e o valor pago pelo aluguel. A locadora possui funcionrios que trabalham nas filiais. As filiais so identificadas por cdigo, nome cidade, endereo e telefones. Os clientes so identificados por cdigo, nome, cpf, telefone, endereo, cidade. E os funcionrios so identificados por cdigo, nome, endereo, telefone, cidade e funo. Voc pode acrescentar os atributos que achar necessrio.

65

Banco de Dados

4) At aqui desenhamos diagramas a partir de enunciados. Vamos fazer o contrrio agora? Ento, identifique atributos que as entidades e/ou relacionamentos podem possuir e descreva em um texto, em portugus, o modelo ER representado na figura seguir.

Vamos Revisar?
O modelo ER um modelo formal, no ambguo e muito utilizado. Mesmo assim ele ainda tem poder limitado de representao. Neste captulo voc estudou como desenhar esse modelo (com dicas de como escolher a melhor representao) e verificar a corretude do mesmo. Esse um captulo que merece ateno e seu contedo pode lhe ajudar bastante a iniciar o projeto de um banco de dados. Lembre-se que a melhor maneira de pegar o jeito para o projeto praticar, logo, no deixe de fazer todos os exerccios deste captulo.

66

Banco de Dados

Captulo 6
O que vamos estudar neste captulo?
Neste captulo, vamos estudar os seguintes temas: Notaes Alternativas para o MER.

Metas
Aps o estudo deste captulo, esperamos que voc: Conhea outras formas de desenhar o MER. Consiga desenhar ou fazer a leitura de modelos ER em diferentes notaes.

67

Banco de Dados

Captulo 6 Outras Notaes para o


MER
Vamos conversar sobre o assunto?
Voc sabia que existe mais de uma notao para o MER? Pois ! Existe sim. Na verdade, desde o surgimento do MER, vrios autores de livro fizeram uso de representaes diferentes para este modelo (diferentes graficamente e/ou semanticamente). Assim, hoje temos na literatura e na prtica uma ampla variedade de representaes para o MER. Porm, mesmo existindo variaes, importante dentro de um mesmo contexto, uma mesma empresa, usar uma representao padronizada para que as pessoas da organizao (por exemplo, analistas e programadores) possam se comunicar. Essa escolha da notao vai ser feita, muitas vezes, baseada na ferramenta CASE que for adotada para desenhar o diagrama. Isso porque cada ferramenta foca, geralmente, em apenas um tipo de notao (por exemplo, o BR-Modelo usa a notao de Peter Chen).

At agora a notao que utilizamos foi a notao de Peter Chen. Neste captulo, vamos apresentar duas outras notaes que, tambm, so bastante utilizadas: a notao Engenharia de Informaes e a notao MERISE (uma notao Europeia).

Notao da Engenharia de Informaes


Tambm conhecida como P de Galinha ou notao James Martin, sua importncia devida ao fato de ser suportada por vrias ferramentas CASE. Algumas caractersticas dessa notao so: Ela d maior nfase modelagem de dados; So permitidos apenas relacionamentos binrios; Atributos aparecem exclusivamente em entidades; Os relacionamentos passam a ser representados por uma linha, geralmente com um verbo dando o significado dos relacionamentos em ambas direes; Usa a notao grfica de cardinalidades mximas e mnimas, conforme apresentado na Figura 68.

Figura 68 - Notao de Cardinalidade Mxima e Mnima

Na Figura 69, exemplificamos o uso dessa notao. No exemplo, temos: um

68

Banco de Dados

departamento tem um e apenas um (cardinalidades mnima e mxima) funcionrio que o gerencia. Um funcionrio gerencia ZERO ou um departamento. O segundo exemplo mostra que uma diviso possui um ou mais (N) departamentos e um departamento pertence a uma e apenas uma diviso. No terceiro exemplo, um funcionrio possui ZERO ou mais dependentes e um dependente pertence a um e apenas um funcionrio. No quarto exemplo temos que um Funcionrio trabalha em um ou mais projetos e um projeto tem trabalhando nele um ou mais funcionrios. Por fim, no ltimo exemplo temos um autorrelacionamento envolvendo a entidade Funcionrio, onde um Funcionrio grencia ZERO ou mais funcionrios e um Funcionrio gerenciado por um e apenas um funcionrio.

Figura 69 - Exemplos de uso da Notao da Engenharia da Informao

Para que voc perceba melhor a diferena dessa notao para a notao de Peter Chen que vinha sendo utilizada, veja a Figura 70. Nela, temos primeiro a notao de Peter Chen para representar que um PROJETO aloca zero ou mais empregados. E um EMPREGADO est alocado em um e apenas um projeto. Logo em seguida, temos esse mesmo enunciado representado na notao da Engenharia de Informaes. Percebe a diferena?

Figura 70 - Mudanas da Notao de Peter Chen para a Engenharia de Informaes

Nesta notao tambm muda a representao para a generalizao/especializao. Ela passa passa ser representada como um subconjunto(subtipo) de entidades, em outras palavras, como um aninhamento dos smbolos de entidade. Para exemplificar, vamos supor o seguinte problema: A empresa X deseja criar um banco de dados para armazenar os dados dos seus funcionrios e seu afazeres. Nessa empresa um departamento lota zero ou mais empregados e um empregado est logado em um e apenas um departamento. O empregado pode ser um gerente, uma secretria ou um engenheiro. Se ele for um gerente, ele vai gerenciar um ou mais empregados. E o empregado por sua vez, gerenciado ou

69

Banco de Dados

no por um gerente. Se o empregado for uma secretria, ele deve domintar zero ou mais processadores de texto. E deve existir uma ou mais secretrias que dominem um processador de texto. Se o empregado for um engenheiro, ele vai participar de zero ou mais projetos. E cada projeto ter participando dele zero ou mais engenheiros. Na notao de Peter Chen, esse problema seria representado como apresentado na Figura 71. J na notao de Engenharia de Informaes, ele seria representado como na Figura 72.

Figura 71 - Problema representado na Notao de Peter Chen

Figura 72 - Problema representado na Notao da Engenharia de Informaes

Veja que na notao da Engenharia de Informaes, os subtipos (especializaes) gerente, secretria e engenheiro so representados como entidades internas da classe mais genrica (empregado).

70

Banco de Dados

Notao MERISE
MERISE uma metodologia de desenvolvimento de sistemas bastante utilizada na Frana e em outros pases europeus. Algumas diferenas dessa notao para a de Peter Chen so: Representa relacionamentos como elipses ao invs de losangos; Usa semntica participativa, ou seja, demonstra quantas ocorrncias de uma entidade participa de um relacionamento. Ou seja, ela vai indicar quantas ocorrncias da entidade. Por este motivo, as cardinalidades so expressas de lados opostos aos equivalentes na notao de Peter Chen (que usa semntica associativa).

Vamos exemplificar essas diferenas. Suponha o problema um projeto aloca zero ou mais empregados e um empregado trabalha em um e apenas um projeto por vez. Na Figura 73 vemos esse problema representado tanto na notao de Peter Chen, quanto na notao MERISE. Observe que, na notao MERISE, as cardinalidades foram invertidas. Porque ela quer representar que uma ocorrncia da entidade EMPREGADO participa no mnimo uma e no mximo uma vez do relacionamento ALOCA. E a entidade PROJETO participa zero ou mais vezes do relacionamento ALOCA. Veja que a forma de ler o problema muda. Agora pensamos em participao da entidade no relacionamento e no na associao de uma entidade com outra.

Figura 73 - Notao Peter Chen x Notao MERISE

Estratgias de Modelagem
Uma estratgia de modelagem uma sequncia de passos de transformao de modelos. Ou seja, a definio da sequncia de passos para transformar o modelo inicial no modelo final. Alguns exemplos de estratgia so: Engenharia Reversa, Bottom-up, Topdown e Inside-out. Porm, na prtica, nenhuma das estratgias propostas na literatura amplamente aceita. Geralmente, se usa a combinao de diversas estratgias de modelagem, tambm por se levar em considerao que o processo de construo de um modelo um processo incremental onde, gradualmente, o modelo vai sendo enriquecido com novos conceitos e estes vo sendo ligados aos existentes ou os conceitos existentes vo sendo aperfeioados no decorrer do tempo. Para definir qual a estratgia a usar na construo de um modelo ER, deve-se identificar qual a principal fonte de informaes para o processo de modelagem. So duas

71

Banco de Dados

as fontes de informao possveis: as descries de dados existentes e o conhecimento que pessoas possuem sobre o sistema.

Fonte de Informaes 1: Descries de Dados Existentes


a fonte utilizada quando se deseja obter um modelo de dados para um sistema de computador que j existe ou quando so utilizadas descries de documentos (fichas, documentos fiscais, comprovantes, relatrios, etc) usados em um sistema no automatizado. Nestes casos, so usadas como descrio dos dados do modelo as descries dos arquivos utilizados pelo sistema existente ou presentes nas documentaes consultadas. Com esse tipo de fonte de informao podem ser usadas as seguintes estratgias: Estratgia de Engenharia reversa onde se obtm a especificao (modelo) a partir de um produto pr-existente (um sistema). Esse processo mais fcil se for usada algum tipo de ferramentas CASE (Computer Aided Software Engineering) para ajudar. Muitas ferramentas de modelagem de dados existentes realizam esse processo de Engenharia Reversa (ex: ERWIN). Estratgia Bottom-up (de baixo para cima) esta estratgia mais usada quando no h sistema automatizado. Assim, a modelagem construda partindo de descries de dados j existentes em documentos. E a construo do modelo se d dos conceitos mais detalhados at os mais abstratos. Por exemplo, inicia-se com a definio dos principais atributos, agrega-se os atributos em entidades e, por fim, definem-se os relacionamentos e generalizaes entre as entidades.

Fonte de Informaes 2: Conhecimento que as Pessoas Possuem do Sistema


a fonte utilizada para a concepo de novos sistemas, para os quais como no h descries de dados, deve-se partir do conhecimento que as pessoas possuem do sistema sendo modelado. Com esse tipo de fonte de informao podem ser usadas as seguintes estratgias: Estratgia Top-down (de cima para baixo) - consiste em partir de conceitos mais abstratos (do topo) e ir, gradativamente, refinando-os em conceitos mais detalhados. Por exemplo, identificam-se entidades genricas, depois os atributos dessas entidades, a seguir, definem-se os relacionamentos entre as entidades identificadas, os atributos dos relacionamentos (se for o caso) e, por fim, verificase a necessidade de se criar generalizaes/especializaes. Assim, possvel perceber que essa estratgia inversa estratgia bottom-up. Uma sequncia de passos utilizada para obter um modelo atravs da estratgia top-down pode ser: 1) Constroe-se um modelo pouco detalhado, com entidades, relacionamentos, hierarquias (especializaes/generalizaes), atributos de entidades e relacionamentos (destacando os identificadores) e considerando as necessidades de levar em conta o aspecto temporal. Porm, sem o domnio dos atributos e as cardinalidades mnimas de relacionamentos (modelagem superficial). 2) Complementa-se o modelo com os domnios dos atributos e as cardinalidades mnimas dos relacionamentos (modelagem detalhada). Adicionalmente, para complementar o MER, especificam-se, textualmente, restries de integridade que no podem ser representadas por ele.

72

Banco de Dados

3) Por fim, o modelo deve ser validado com o usurio do sistema e atravs da procura de construes redundantes ou derivveis a partir de outras do modelo. Em qualquer um desses passos, possvel retornar aos passos anteriores para fazer ajustes. Estratgia Inside-out ou middle-out (de dentro para fora ou do meio para fora): parte dos conceitos considerados mais importantes (centrais, de dentro) e vai, gradativamente, adicionando conceitos perifricos a eles relacionados (ir para fora). Por exemplo, pode-se iniciar com uma entidade considerada importante (que se supe estar associada a vrias outras entidades, que se supe ser o centro do problema) e, a partir da acrescentam-se atributos a esta entidade, definem-se os relacionamentos com as entidades envolvidas, os atributos do relacionamento se for o caso, definem-se os identificadores das entidades e relacionamentos e faz-se generalizaes/especializaes. A cada nova entidade que for sendo acrescentadas essas definies so refeitas, at obter-se o modelo completo.

Consideraes Finais
Muitas vezes a escolha da notao a utilizar vai depender da escolha da ferramenta CASE que ser adotada no projeto do banco de dados. Porque, na prtica, no recomendvel realizar a modelagem e projeto do BD manualmente ou usando ferramentas de propsito geral (por exemplo, Word, PowerPoint, paint, etc). De fato, altamente recomendvel usar uma ferramenta de modelagem desde o incio. Isso, porque uma ferramenta desse tipo facilita a manuteno/atualizao do modelo de dados e, em geral, ajuda as outras etapas do projeto do BD, at mesmo a criao do modelo fisicamente no Banco de Dados. No mercado, existem vrias ferramentas8 que variam em configurao e preo (existindo tambm as gratuitas). Para escolher uma boa ferramenta, procure por aquela que tenha uma boa capacidade de edio diagramtica (facilitando o desenho do diagrama), que possua alguma forma de suporte contruo do dicionrio de dados (DD) e que mantenha esse dicionrio integrado com o modelo sendo construdo.

Saiba Mais
Apresentamos algumas dessas ferramentas no final do Captulo 4, neste mesmo volume.
8

Conhea Mais
Mais detalhes sobre o assunto apresentado nesse captulo podem ser encontrados no livro do professor Carlos Heuser: HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados Srie Livros Didticos, V.4. Bookman Companhia Ed., 6 Edio 2009. Adicionalmente, voc tambm pode consultar: CHEN, PETER PIN-SHAN, The Entity-Relationship Model Toward a unified view of data, ACM Transactions on database systems, vol. 1, n. 1, pp. 9-36, Maro 1976. COUGO, PAULO, Modelagem conceitual e projeto de bancos de dados, Rio de Janeiro: Editora Campus, 1997.

73

Banco de Dados

Voc Sabia?
O modelo entidade-relacionamento foi proposto em 1976, por Peter P. Chen, por meio da publicao inicial de um trabalho intitulado The Entity-Relationship Model: Toward the unified view of data. Dada a simplicidade da diagramao e dos conceitos envolvidos, o modelo teve ampla aceitao e passou a ser um referencial quase que definitivo para a modelagem de dados, alis, extremamente atualizada at os dias atuais.

Minibiografia
Dr. Peter Pin-Shan Chen

Dr. Peter Pin-Shan Chen recebeu seu ttulo de PHD pela universidade de Harvard. J foi professor regular e visitante no MIT, UCLA, na prpria Universidade de Harvard e, desde 1983 preenche a posio de distinto professor catedrtico em Cincia da Computao na Universidade do Estado de Louisiana. Ele o criador do modelo entidade relacionamento (MER), o qual serve de fundamentao para muitas metodologias de anlise e projeto de sistemas e para muitas ferramentas CASE para modelagem de banco de dados. O MER tambm serve como fundamentao para alguns dos trabalhos recentes de Anlise e Projeto Orientados a Objetos e Web Semntica. O artigo original de Peter Chen sobre o MER (cuja referncia est no conhea mais desse captulo) um dos artigos mais citados na rea de Computao. Este artigo foi selecionado como um dos 38 mais influentes da Cincia da Computao, de acordo com a avaliao feita por cerca de 1000 renomados professores universitrios da rea de Computao de todo o mundo (ranking disponvel em: http://bit.csc.lsu.edu/~chen/GreatPapers.html, editado por P. Laplante, West Publishing, 1996). Fonte: Site do prprio Peter Chen na Universidade de Louisiana (http://bit.csc.lsu.edu/~chen/chen.html)

Atividades e Orientaes de Estudo


Discuta no frum da semana sobre as notaes para modelagem de dados. Tenha como guia as seguintes questes: 1. Antes dessa disciplina, voc j conhecia, tinha lido sobre ou tinha utilizado alguma das notaes estudadas (Peter Chen, Engenharia de Informaes ou MERISE)? 2. Qual das notaes voc achou mais fcil e qual delas voc achou mais complicada. Por qu? Este um frum temtico, logo, ele far parte da sua avaliao somativa. Logo, no

74

Banco de Dados

deixe de participar! Alm disso, voc pode aprender muito compartilhando informaes com seus colegas.

Atividades Prticas
Resolva as atividades a seguir em um documento texto e poste o mesmo no ambiente virtual, no local indicado. Essa atividade para ser realizada em DUPLA (escolha seu companheiro de trabalho!) e far parte da avaliao somativa de vocs. 1) Escreva uma frase para representar como se leem cada um dos relacionamentos abaixo. Depois, redesenhe cada um desses relacionamentos na notao MERISE.

2) Redesenhe o diagrama abaixo na notao da Engenharia de Informaes, fazendo os ajustes necessrios.

Vamos Revisar?
Existem diversas notaes para modelagem conceitual dos dados. Entre as mais utilizadas temos a orignal de Peter Chen, a notao da Engenharia de Informaes (tambm chamada de ps de galinha ou notao James Martin) e a notao MERISE. A escolha da notao a adotar, muitas vezes, vai depender da ferramenta CASE a ser adotada para modelagem e projeto do banco de dados.

75

Banco de Dados

Consideraes Finais
Ol, cursista! Esperamos que voc tenha aproveitado este segundo mdulo da disciplina Banco de Dados. Como j foi dito anteriormente, a modelagem conceitual um dos assuntos mais importantes que vamos estudar, porque ela o comeo de tudo. Por isso, pratique muito, releia o texto e tenha certeza que est entendendo bem o assunto. No prximo mdulo, estudaremos como fazer a transformao da modelagem conceitual para a modelagem lgica. Alm disso, vamos dar uma olhada mais a fundo no modelo relacional um dos mais utilizados em todo o mundo para projeto de Banco de Dados e suas nuances. Aguardamos sua participao no prximo mdulo. At l e bons estudos! Sandra de Albuquerque Siebra Autora

76

Banco de Dados

Referncias
BATINI, C.; CERI, S.; NAVATHE, S. B. Conceptual database design: an entityrelationship approach. San Francisco: Benjamim Cummings, 1992. CHEN, PETER PIN-SHAN, The Entity-Relationship Model Toward a unified view of data, ACM Transactions on database systems, vol. 1, n. 1, pp. 9-36, Maro, 1976. COUGO, PAULO, Modelagem conceitual e projeto de bancos de dados, Rio de Janeiro: Editora Campus, 1997. DATE, C. J. Banco de dados: tpicos avanados. Rio de Janeiro : Campus, 1988. DATE, C. J. Introduo a Sistemas de Banco de Dados. Elsevier Editora, 2004. ELMASRI, Ramez;NAVATHE, Shamkant B. Sistemas de banco de dados. Traduzido por: Marilia Guimares Pinheiro et al. 4a. ed. So Paulo: Pearson Education do Brasil, 2005. HAY, D. Princpios de modelagem de dados. So Paulo: Makron Books, 1999. HEUSER, Carlos Alberto. Projeto de Bancos de Dados. 4 ed. Porto Alegre: Sagra Luzzatto, 2001. KIPPER, E.F. Engenharia de Informaes: Conceitos Tcnicas e mtodos, Sagra DCLuzzato, Porto Alegre, 1993. LAENDER, A. H. F. ; CASANOVA, M. A. ; TUCHERMAN, L. . On the Design and Maintenance of Optimized Relational Representations of Entity-Relationship Schemas. Data & Knowledge Engineering, Amsterdam, v. 11, n. 1, p. 1-20, 1993 MARTIN, James. Information Engineering: Books I, II & III. Englewood Cliffs: Prentice-Hall, 1990. Revista SQL Magazine - http://www.sqlmagazine.com.br SETZER, V. W. Banco de dados. 3.ed. So Paulo : Revista Edgard Blucher, 1989. SILBERSCHATZ, Abraham; KORTH, Henry F;SUDARSHAN, S. Sistema de banco de dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006. TARDIEU, H.; ROCHFELD, A.; COLLETI, R. Le Methode Merise: Principles et Outils. Les Editions dOrganization, Paris, 1983 TEOREY, TOBY J., FRY, JAMES P., Design of database structures, New Jersey: PrenticeHall, 1982.

77

Banco de Dados

Conhecendo a Autora
Sandra de Albuquerque Siebra Doutora em Cincia da Computao, pelo Centro de Informtica da UFPE onde trabalhou com Ambientes Virtuais de Aprendizagem e Ambientes Colaborativos em Geral. Ensinou na Faculdade Integrada do Recife (FIR) e na Universidade Catlica de Pernambuco (UNICAP), alm de ter trabalhado como gerente de projetos no Centro de Estudos e Sistemas Avanados do Recife (CESAR). Atualmente, professora da Universidade Federal Rural de Pernambuco (UFRPE). Atua na equipe de Educao a Distncia da UFRPE e no Departamento de Estatstica e Informtica (DEINFO), como professora autora de materiais didticos para cursos a distncia, j tendo tambm atuado como coordenadora de curso e professora executora de disciplinas. Tem experincia, trabalhos desenvolvidos e artigos publicados nas reas de Educao a Distncia, Interfaces Homem- Mquina, Sistemas Colaborativos, Banco de Dados, Anlise e Projeto de Sistemas Orientados a Objetos, Sistemas de Informao e Engenharia de Software. Atualmente, desenvolve pesquisas sobre contextualizao de interaes em ambientes virtuais de aprendizagem e trabalho cooperativo.

78