Escolar Documentos
Profissional Documentos
Cultura Documentos
T - TEORIA Livrobancodedadosvolume02-110216151509-Phpapp01 PDF
T - TEORIA Livrobancodedadosvolume02-110216151509-Phpapp01 PDF
Banco de Dados
Volume 2
Recife, 2010
Universidade Federal Rural de Pernambuco
Apresentação.................................................................................................................. 4
Modelo de Dados.............................................................................................................7
O Modelo Entidade-Relacionamento.............................................................................11
Considerações Finais......................................................................................................33
Considerações Finais......................................................................................................61
Notação MERISE.............................................................................................................71
Considerações Finais......................................................................................................73
Considerações Finais..................................................................................................... 76
Conhecendo a Autora................................................................................................... 78
Apresentação
Caro(a) cursista,
Seja bem-vindo(a) ao segundo módulo do curso Banco de Dados!
Neste segundo módulo, vamos estudar um assunto que considero um dos mais importantes para o
aprendizado de Banco de Dados: a modelagem conceitual dos dados que serão armazenados. Por que ela é
importante? Porque ela é o começo de tudo. Um banco de dados começa a existir na modelagem. E, se um banco de
dados é modelado errado, consequentemente, você terá um banco de dados que não atenderá aos seus objetivos
ou que poderá dar muito mais trabalho para armazenar e recuperar os dados armazenados da maneira apropriada,
mantendo a integridade dos mesmos.
Assim, como esse é um assunto muito importante, procure dedicar bastante atenção e tempo ao mesmo,
ok?
Bons estudos!
Sandra de Albuquerque Siebra
Autora
4
Banco de Dados
Conhecendo o Volume 2
Neste segundo volume, você irá encontrar o Módulo 2 da disciplina de Banco de
Dados. Para facilitar seus estudos, veja a organização deste segundo módulo.
5
Banco de Dados
Capítulo 4
» Modelo de Dados.
» Componentes do Modelo Entidade-Relacionamento (MER).
» Ferramenta para Modelagem de Dados.
Metas
6
Banco de Dados
Modelo de Dados
Lembra do conceito de abstração de dados que explicamos no capítulo 3,
do fascículo I da disciplina? Pois são os modelos de dados as principais ferramentas
que fornecem a abstração a um BD, visto que o modelo de dados representa, de forma
abstrata, como aspectos do mundo real (fatos) estão relacionados, a fim de que possam
ser representados no mundo computacional. Mas o que é um modelo de dados? Ele é um
conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de
dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos
e restrições pertinentes aos dados que serão armazenados no BD. Muitos modelos de dados
também definem um conjunto de operações para especificar como recuperar e modificar a
base de dados.
Já o processo pelo qual você planeja ou projeta a base de dados, de forma que
possa construir um banco de dados consistente, de forma a exigir menos espaço em disco
e aproveitar os recursos disponíveis no SGBD é chamado modelagem de dados. Ou seja,
é processo para a criação do modelo de dados. Mas por que modelar os dados? Qual o
objetivo disso? É importante modelar os dados a fim de conhecer melhor as informações
dos usuários e como elas se relacionam a fim de representar, da melhor forma, o ambiente
observado criando, por consequência, bancos de dados mais corretos e eficientes. Um
projeto mal feito pode trazer diversos problemas, tais como: o banco de dados e/ou
aplicação podem não funcionar adequadamente; os dados podem não ser confiáveis ou
serão inexatos e a performance do BD pode ser degradada.
A modelagem de dados é uma das etapas do ciclo de Desenvolvimento de Sistemas
de Banco de Dados (vide Figura 1).
7
Banco de Dados
E quais são as outras etapas? Primeiro, para poder realizar a modelagem dos
dados, você precisa fazer um levantamento de requisitos. Ou seja, precisa investigar quais
dados deverão fazer parte do banco de dados, a fim de representar bem o problema a ser
resolvido e poder atender as necessidades de armazenamento (persistência) dos dados da
aplicação. Uma vez que se saiba os dados que devem ser manipulados, você deve analisar
como esses dados podem ser representados e relacionados (olhando para o mundo real)
através de um modelo de dados. Esse é o papel da segunda etapa, a modelagem dos dados.
Uma vez que os dados estejam modelados o banco de dados será projetado, transformando
o modelo de dados criado em estruturas de mais baixo nível que possam ser criadas dentro
do SGBD. Posteriormente, o BD é realmente implementado usando algum dos SGBDs
disponíveis no mercado e, depois, mantido e monitorado pelo administrardor de banco de
dados.
Existem modelos para diferentes níveis de abstração de representação de dados.
São eles: modelos conceituais (também conhecido como modelo com base em objetos),
modelos lógicos (também conhecido como modelo com base em registros) e modelos
físicos. Vamos descrever melhor cada um deles a seguir.
Modelo Conceitual
Modelo Lógico
8
Banco de Dados
vai depender do SGBD a ser utilizado. Ou seja, este modelo vai especificar a representação/
declaração dos dados de acordo com o SGBD escolhido, definindo assim a estrutura de
registros do BD (onde cada registro define número fixo de campos (atributos) e cada campo
possui tamanho fixo). Um exemplo de modelo lógico é o modelo relacional. O modelo
relacional usa um conjunto de tabelas para representar tanto os dados como a relação entre
eles. Cada tabela possui múltiplas colunas e cada coluna possui um nome único. Apesar de
existirem outras representações de modelo lógico, nesta disciplina trataremos apenas dos
modelos lógicos referentes a SGBD relacional.
Modelo Físico
São usados para descrever os dados no nível mais baixo, tratando de aspectos
de implementação do SGBD (como indexação e estruturação de arquivos, controle de
concorrência, transações, recuperação em casos de falhas, entre outros). As linguagens e
notações para o modelo físico não são padronizadas e variam de produto a produto (são
dependentes do SGBD). Além disso, a tendência dos produtos modernos é cada vez mais
esconder o modelo físico.
Atenção
Os modelos físicos não são o foco desta disciplina e, por consequência, não serão tratados na
mesma.
Todos esses modelos, na verdade, são visões diferentes, com nível de profundidade
diferente para os mesmos dados. E é importante saber que, a partir de um modelo, o
modelo seguinte pode ser derivado. Para lhe dar uma ideia de como as coisas acontecem,
vamos explicar o processo descrito na Figura 2. O analista (lembra das pessoas envolvidas
com o sistema de banco de dados, estudados no volume I?) de banco de dados, observa
a realidade (e também conversa com as pessoas que se fizerem necessárias) e, a partir do
problema a ser resolvido (aplicação a ser desenvolvida), ele organiza suas ideias e cria um
minimundo (que é um subconjunto da realidade contendo os dados necessários para a
resolução do problema sendo tratado). O minimundo tem dados que vão ajudar a descrever
o modelo conceitual (mais alto nível de abstração), o modelo lógico é especificado a partir
do modelo conceitual e é implementado pelo modelo físico (que é quem realmente é usado
para criar o banco de dados (BD)).
9
Banco de Dados
10
Banco de Dados
O Modelo Entidade-Relacionamento
Primeiro vamos contar a história desse modelo... O modelo entidade-
relacionamento (conhecido como MER) foi originalmente definido por Peter Chen em 1976
e é baseado na teoria relacional criada em 1970 por Codd. Posteriormente, na década
de 80, o MER sofreu algumas extensões para tornar-se mais preciso na representação do
mundo real. Atualmente, ele é o modelo de dados conceitual mais difundido e utilizado
para modelagem de bancos de dados relacionais.
Para iniciar o projeto conceitual do BD, deve ter sido antes definido qual o problema
a ser resolvido, ou seja, deve-se ter determinado as fronteiras que delimitam e restringem
o minimundo a ser modelado e realizado a especificação desse minimundo. Tudo isso faz
parte da etapa de análise dos requisitos. A partir justamente da especificação feita é que
você irá extrair as informações necessárias para desenhar a primeira versão do MER.
Segundo Silberschatz (1999), o MER tem por base a percepção de que o mundo
real é formado por um conjunto de objetos chamados entidades e pelo conjunto dos
relacionamentos entre esses objetos. Na verdade, existem três noções básicas empregadas
pelo MER: conjunto de entidades, conjunto de relacionamentos e conjunto de atributos. Só
para ilustrar, na Figura 4 apresentamos um micro exemplo de MER onde estão representadas
as entidades cliente e conta, cada uma com seus atributos. As duas entidades se relacionam
através do relacionamento cliente-conta.
11
Banco de Dados
Entidades
12
Banco de Dados
Para se referir a uma entidade particular fala-se em instância ou ocorrência de entidade. Uma
instância é um objeto de uma entiedade com suas respectivas propriedades preenchidas com
valores, distinguindo assim ela de qualquer outra instância. Vamos exemplificar: a entidade
empregado descrita há pouco, possui os atributos nome, cargo que ocupa, idade e estado civil.
Uma instância dessa entidade poderia ser: “Maria, secretária, 31 anos, solteira”. Ou seja, a instância
é como se fosse um exemplo de empregado, com os atributos preenchidos com valores. Entendeu?
Atributos
13
Banco de Dados
14
Banco de Dados
Identificador de Entidade
15
Banco de Dados
Na prática, você verá que a maioria dos MER não apresenta os atributos. Por
que será? Os atributos, em geral, não são representados no MER para não sobrecarregar
(graficamente) a apresentação do diagrama. Isso deixa o diagrama entidade-relacionamento
mais legível. Eles, geralmente, são apresentados em uma representação textual à parte do
diagrama E-R.
Relacionamentos
São associações entre uma ou várias entidades. Em outras palavras, são funções que
mapeiam um conjunto de instâncias de uma entidade em outro conjunto de instâncias de
outra entidade (ou da mesma entidade, como é o caso do “autorrelacionamento”). Vamos
dar um exemplo: “departamento emprega funcionário” (vide Figura 11). Departamento
e Funcionário seriam entidades ligadas através do relacionamento emprega, sendo
representado na figura por um losango com o nome do relacionamento.
16
Banco de Dados
Cardinalidade do Relacionamento
17
Banco de Dados
18
Banco de Dados
» Muitos para um: é o contrário da anterior. Aqui, uma entidade em A está associada
a, no máximo, uma entidade em B. E uma entidade em B pode estar associada
a zero, uma ou mais entidades (N entidades) em A. É como se cada instância da
entidade A encontrasse apenas uma instância correspondente na entidade B. Mas,
cada instância da entidade B encontrasse zero ou mais instâncias correspondentes
na entidade A (vide Figura 18). Por exemplo, “Aluno é orientado por Professor”. Um
aluno só é orientado por um professor (de repente, é regra da faculdade onde ele
estuda), mas um professor pode orientar zero ou mais alunos (N alunos), conforme
pode ser visto na Figura 19.
» Muitos para Muitos (M:N): Uma entidade em A está associada a qualquer número
de entidades em B e uma entidade em B está associada a um número qualquer
de entidades em A. É como se cada instância da entidade A encontrasse zero, um
ou mais instâncias correspondentes na entidade B. E cada instância da entidade
B encontrasse zero, uma ou mais instâncias correspondentes na entidade A (vide
Figura 20). Por exemplo, “Aluno cursa Disciplina”, um aluno cursa zero, uma ou mais
disciplinas e uma disciplina é cursada por zero, um ou mais alunos (vide Figura 21).
Outro exemplo é “Médico consulta Paciente”. Um médico consulta zero, um ou mais
Pacientes. E um Paciente é consultado por zero, um ou mais médicos (por exemplo,
a pessoa pode ter ido a um endocrinologista e em um cardiologista), conforme
19
Banco de Dados
20
Banco de Dados
21
Banco de Dados
Grau de Relacionamento
O grau de um relacionamento indica o número de entidades participantes do
mesmo. Assim, o relacionamento TRABALHA da Figura 23 é de grau dois, ou seja, o
relacionamento está ligado a duas entidades. Um relacionamento de grau dois é chamado
binário. Um relacionamento entre três entidades é dito de grau três ou relacionamento
ternário. Um exemplo desse tipo de relacionamento é o relacionamento TRABALHA da
Figura 25. Cada instância de relacionamento T associa três entidades – um empregado E, um
projeto P e um cliente C - onde o empregado E trabalha no projeto P para o cliente C.
22
Banco de Dados
A notícia boa é que podem existir tipos de relacionamento de qualquer grau, porém
é muito mais frequente encontrar o tipo de relacionamento de grau dois (binário).
Autorrelacionamentos
Veja que as cardinalidades são diferentes, mas apenas com as cardinalidades não
fica claro qual se refere ao supervisor e qual se refere ao supervisionado (até daria usando
a lógica: Um empregado supervisor supervisiona N empregados e cada empregado tem
apenas um supervisor, mas não fica explícito no diagrama). Logo, neste caso, precisamos
de algo mais para identificar os relacionamentos do que apenas as cardinalidades, para
não deixar dúvidas. Esse algo mais é a definição de papéis. Papel é a função que uma
instância de uma entidade cumpre em uma instância de um relacionamento. Na verdade,
cada tipo de entidade que participa de um tipo de relacionamento possui um papel
específico no relacionamento. Em autorrelacionamentos é essencial identificar os nomes
dos papéis a fim de distinguir o significado de cada participação. Já relacionamentos entre
entidades diferentes, em geral, não requerem a especificação de papéis. Dessa forma, o
autorrelacionamento da Figura 27, com o uso de papéis ficaria como especificado na Figura
28.
Agora, fica mais claro que cada empregado tem apenas um único supervisor e
um supervisor pode supervisionar N empregados (os supervisionados). Outro exemplo de
autorrelacionamento com papéis seria o apresentado na Figura 29. Nele temos “Pessoa
casa com Pessoa”. Nesse relacionamento é necessário especificar os papéis, no caso, marido
23
Banco de Dados
e esposa. Supõe-se que, na nossa cultura, esse deve ser um relacionamento 1:1 J
Outro exemplo de atributo em relacionamento pode ser visto na Figura 30. Este
diagrama modela vendas em uma organização comercial. Algumas vendas são à vista, outras
a prazo. Vendas a prazo são relacionadas a uma financeira, através do relacionamento
FINANCIA. As vendas a prazo precisam ter informações sobre a quantidade de parcelas e
24
Banco de Dados
a taxa de juros que será cobrada. Onde poderiam ser colocados esses atributos? Se estes
dois atributos fossem incluídos na entidade VENDA, eles deveriam ser atributos opcionais2,
já que nem toda venda é a prazo e precisa destes atributos (ocasionando em atributos sem Saiba Mais
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 2
Atributos
opcionais não tem
relacionamento FINANCIA (vide Figura 31).
obrigatoriedade de
prenchimento.
Relacionamento Identificador
Saiba Mais
3
Entidade forte é
aquela que possui
Figura 32 - Entidade Fraca
o seu próprio
identificador e não
depende de nenhuma
Nesse caso, alguns autores dizem que a entidade DEPENDENTE é uma entidade outra entidade para
fraca. O termo “fraca” deriva-se do fato de a entidade somente existir quando relacionada isso.
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
Atenção
O termo Entidade Fraca deve ser usado com cautela, pois uma entidade fraca em um
relacionamento não necessariamente é também fraca em outro relacionamento.
Especialização/Agregação
26
Banco de Dados
27
Banco de Dados
Herança de Atributos
É uma propriedade decisiva das entidades de níveis superior e inferior criadas pela
especialização e pela generalização. Através dela, nos relacionamentos de generalização
e especialização, as entidades de nível inferior herdam os atributos e os relacionamentos
das entidades de nível superior. Como já comentado sobre a Figura 33, as entidades
especializadas P. FISICA e P.JURIDICA herdam todos os atributos e relacionamentos
da entidade genérica CLIENTE, podendo ter, adicionalmente, mais algum atributo ou
relacionamento próprio.
28
Banco de Dados
MEDICAMENTO. Daí, a questão seria: com que entidade existente deve estar relacionada a
nova entidade MEDICAMENTO?
Se a entidade MEDICAMENTO fosse relacionada a entidade MEDICO, se teria
apenas a informação de qual médico prescreveu quais medicamentos, faltando a
informação do paciente para os quais os medicamentos foram prescritos. Por outro lado,
se a entidade MEDICAMENTO fosse relacionada a entidade PACIENTE, ficaria faltando a
informação de qual médico prescreveu o medicamento. Logo, é possível ver que o ideal é
relacionar a nova entidade MEDICAMENTO ao relacionamento CONSULTA, porque é lá que
estão as informações de ambos médico e paciente. Para poder fazer isso, o relacionamento
CONSULTA deve ser redefinido como uma entidade associativa (para passar a ser tratado
como uma entidade convencional). Graficamente, isto é indicado na Figura 37 pelo retângulo
desenhado ao redor do relacionamento CONSULTA. Dessa forma, agora, sendo CONSULTA
também uma entidade, é possível associá-la através do relacionamento PRESCREVE à nova
entidade MEDICAMENTO.
29
Banco de Dados
BR-MODELO
30
Banco de Dados
DBDesigner
DBDesigner é uma ferramenta gratuita para projeto de banco de dados que integra a
modelagem, projeto, implementação e manutenção em um mesmo ambiente. Desenvolvida
pela empresa Fabulous Force Database Tools, atualmente encontra-se na versão 4 e está
disponível para download em http://fabforce.net/dbdesigner4/ para plataformas Window e
Linux (disponibilizada sob a licença GLP). A interface do DBDesigner pode ser visualizada na
Figura 40.
31
Banco de Dados
Este programa é útil para, ao invés de criarmos uma base de dados através
de códigos (implementados em linguagem apropriada), criarmos uma base de dados
visualmente, com a definição de tabelas, tipos de dados e relações entre tabelas. E, a
partir do resultado final do desenho de uma base de dados, termos acesso ao código que
podemos utilizar para a criação da nossa base de dados. O DBDesigner é direcionado para
o desenvolvimento de banco de dados com o SGBD MySQL, mas também oferece suporte
para o Ms-SQL e o Oracle.
CA ERwin
Sybase – PowerDesigner
32
Banco de Dados
Considerações Finais
Após 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 esforço nesta fase do projeto, pois a passagem para as outras fases é mais ou menos
automática. Outra vantagem está na possibildade de usuários não especialistas em bancos
de dados darem diretamente a sua contribuição no projeto conceitual (já que ele é mais
fácil de ser compreendido do que os outros modelos do projeto de BD). A aproximação com
o usuário final melhora bastante a qualidade do projeto.
Conheça Mais
33
Banco de Dados
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São
Paulo: Pearson Education do Brasil, 2005.
DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus,
2000.
Sobre as ferramentas apresentadas, eis alguns materiais adicionais:
Vídeo-aula sobre o BR-Modelo
http://www.devmedia.com.br/articles/viewcomp.asp?comp=7776
Você Sabia?
Cardinalidade Mínima
= 1 → Atributo obrigatório
= 0 → Atributo opcional
Cardinalidade Máxima
= 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 é obrigatório (cardinalidade mínima = 1) e monovalorado (cardinalidade máxima =
1), ou seja, ele só pode assumir um único valor (o que é verdade para o número do CPF que
sempre deve ser único) e, também é o atributo identificador (veja que ele está sublinhado)
da entidade. Já a entidade DEPENDENTE possui dois atributos: o RG, que é opcional
(cardinalidade mínima = 0) - porque pode ser que o dependente seja menor de idade ou
ainda não tenha tirado esse documento – e monovalorado (existindo, o RG também deve
ser único, por isso a cardinalidade máxima = 1). E o outro atributo é o Telefone, que é
opcional (cardinalidade mínima = 0), porque pode ser que o dependente não tenha nenhum
telefone, e multivalorado (cardinalidade máxima = 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 são o CPF (da entidade CLIENTE, lembre que
DEPENDENTE é entidade fraca) e o RG.
34
Banco de Dados
Aprenda Praticando
35
Banco de Dados
a) 0 e 1
b) 0 e 2
c) 1 e 1
d) 1 e 2
e) 2 e 1
36
Banco de Dados
4) Sobre a figura acima, que apresenta elementos utilizados em um típico DER na qual
cada tipo de elemento está identificado por um número, são feitas as afirmativas a
seguir.
I - Os elementos identificados por 1 e 3 no diagrama, respectivamente, são:
Entidade e Atributo.
II - O elemento identificado no diagrama pelo número 2 é um relacionamento.
III – Uma entidade que tem um identificador que não 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 - Petrobrás - Técnico em Informática
37
Banco de Dados
CESGRANRIO - 2007 - TEC - RO - Analista de Informação
Respostas:
38
Banco de Dados
Agora vamos exercitar o que foi estudado neste capítulo. Assim sendo, faça as
atividades sugeridas a seguir. Lembre que exercitar vai lhe ajudar a fixar melhor o conteúdo
estudado. E o conteúdo desse capítulo é fundamental para o capítulo seguinte. Mãos à
obra!
Atividades Práticas
39
Banco de Dados
Atividades de Reflexão
Hospitais são formados por um ou mais ambulatórios e cada um destes está em um único hospital
Hospitais solicitam exames clínicos em vários laboratórios, cada laboratório pode ter solicitações
de vários hospitais
Ambulatórios atendem vários pacientes, enquanto estes só podem ser atendidos em um único
ambulatório
Pessoal de apoio está alocado em um ambulatório, e cada ambulatório conta com vários integrantes
do pessoal de apoio.
Laboratórios fazem vários testes e cada um dos testes é feito em um único laboratório
40
Banco de Dados
Minibiografia
Edgar Frank Codd (Dorset, 23 de agosto de 1923 — 18 de abril de 2003) foi um matemático
britânico. Ele desenvolveu o modelo de banco de dados relacional, quando era pesquisador no
laboratório 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 operações matemáticas 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 não quis, inicialmente, implementar as ideias de Codd. Este então
buscou grandes clientes da IBM para mostrar-lhes as novas potencialidades de uma eventual
implementação do modelo relacional. Mesmo com a pressão dos clientes IBM, ela não incluiu
Codd nos novos projetos sendo implementados. Devido a isso, desgostoso pela rejeição 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 após adoeceu e teve de encerrar sua carreira,
vindo a falecer no começo do III milênio. Porém, Date continuou a obra de Codd, tornando-se
autor de vários livros importantes da área de BD.
Vamos Revisar?
41
Banco de Dados
42
Banco de Dados
Capítulo 5
Metas
43
Banco de Dados
Neste capítulo, você vai encontrar dicas, informações e diversos exemplos que lhe
ajudarão a desenhar diagramas entidade-relacionamento. A partir daqui vamos adotar a
notação de Peter Chen. Vamos lá?
44
Banco de Dados
45
Banco de Dados
46
Banco de Dados
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.
Um modelo ER pode ser usado como entrada a uma ferramenta CASE5. Ou seja, a
Saiba Mais
partir do desenho do MER feito em uma ferramenta CASE, pode-se gerar o modelo lógico e
posteriormente, o modelo físico do BD (ou, pelo menos, os scripts para fazer isso). 5
Ferramentas
CASE (do inglês
Computer-Aided
Critérios para Construção do Modelo ER Software Engineering)
são ferramentas
automatizadas
Para iniciar a construção do MER, geralmente, algumas dúvidas surgem, tais como: que tem como
objetivo auxiliar o
qual elemento (entidade, atributo, relacionamento,...) da linguagem ER é o mais apropriado desenvolvedor de
para representar uma específica abstração da realidade? Para responder essa pergunta não sistemas em uma ou
se deve observar um objeto isoladamente. Deve-se procurar observar o contexto dentro do várias etapas do ciclo
de desenvolvimento
qual o objeto aparece, assim, você terá uma ideia melhor de como representá-lo. Além disso, de software. No caso,
o próprio desenvolvimento do modelo e o aprendizado sobre a realidade irão refinando e ajudar no projeto e
aperfeiçoando o modelo, no decorrer do tempo. Por isso, lembre-se a representação de um criação do banco de
dados.
objeto está sujeita a alteração 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
reflexões sobre os pontos de dúvida mais comuns.
Na descrição dos problemas, pode haver ocasiões onde você ficará em dúvida sobre
como modelar determinado elemento. Por exemplo, como modelar a cor de um automóvel?
Seria melhor representar a cor como atributo ou como entidade? (vide Figura 50).
47
Banco de Dados
Em alguns casos, você vai ficar em dúvida se um elemento deve ser representado
como atributo ou se ele dá origem a uma generalização/especialização. Por exemplo, como
modelar a função (categoria funcional) de um empregado? (vide Figura 51).
48
Banco de Dados
49
Banco de Dados
50
Banco de Dados
Criando o Diagrama ER
Após realizar as entrevistas com o cliente e/ou usuário(s) para determinar suas
necessidades de informação e, com isso, tendo definido qual o problema a ser resolvido,
então é hora de começar a desenhar o diagrama ER. Apesar de não existir uma receita de
bolo unanimente aceita, é possível dar uma ideia de roteiro.
51
Banco de Dados
» Um atributo não pode ter outros atributos associados, de modo que se forem
encontrados (em sua aplicação) significa que não se trata de um atributo, mas
de uma entidade.
» Uma entidade que não possua, pelo menos, um atributo além do atributo
identificador ou está com sua especificação incompleta ou não se trata de uma
entidade mais de um atributo.
» Um relacionamento é uma associação entre entidades. A completa e perfeita
representação de uma associação somente está correta se todas as entidades
necessárias para a existência do relacionamento estão interligadas.
É importante gastar um tempo na criação do DER, porque ele será a base para tudo
que vem depois (modelagem lógica e física e criação do BD). Erros ocorridos nesta fase
acarretam graves atrasos e aumento no custo da implementação do BD e dos sistemas que
o utilizarão.
Após criada a primeira versão do DER deve-se apresentá-lo ao cliente para que
sejam verificados a corretude e a completude do diagrama. Há também algumas dicas que
você pode seguir para verificar a corretude do seu diagrama. Apresentaremo-las na seção a
seguir.
52
Banco de Dados
» Ser completo
» Ser correto
» Ser livre de redundância
» Refletir o Aspecto Temporal, quando necessário
» Evitar entidades isoladas
Vamos detalhar como checar cada ponto dessa, a seguir.
Ser Correto
O modelo deve representar, com fidelidade, a realidade e não deve conter erros de
modelagem. Quando não está correto, o modelo pode apresentar dois tipos de erros:
53
Banco de Dados
b) Representar um mesmo elemento, ora como entidade, ora como atributo. Por
exemplo, na Figura 59, o elemento UNIDADES-FEDERAÇÃO está sendo representado
como atributo da entidade VEICULO e, também, como uma entidade no mesmo
diagrama. O correto seria escolher a melhor representação e mantê-la em todo
diagrama. No caso, como é necessário armazenar informações sobre as unidades da
federação (tais como sigla e nome), elas seriam melhor representadas no diagrama
como entidade.
54
Banco de Dados
Ser Completo
» Os dados que devem ser obtidos a partir do BD estão presentes? São possíveis de
serem obtidos a partir do modelo criado?
» Todas as consultas necessárias poderão ter resposta apenas com os elementos que
fazem parte do modelo criado?
55
Banco de Dados
Essas perguntas podem ajudar em uma avaliação mais geral, mas realmente, para
obter uma avaliação mais precisa, é necessário o especialista do domínio.
56
Banco de Dados
que pode ser derivado. Como? Contando quantos empregados estão relacionados
ao departamento, seria possível obter o número de empregados do departamento,
não necessitando existir um atributo para esse fim.
Atenção
57
Banco de Dados
(atributo com bolinha preta) a data (vide Figura 63 – lado direito). Assim, cada
salário cadastrado, seria cadastrado com uma data diferente, dessa forma, o valor
anterior do salário não seria perdido.
58
Banco de Dados
59
Banco de Dados
Em resumo...
Se o relacionamento já for n:n, devemos adicionar apenas um atributo data como identificador
do relacionamento.
Uma entidade isolada é uma entidade que não apresenta nenhum relacionamento
com outras entidades. A ocorrência desse tipo de entidade, a princípio é incorreta e, na
prática, em modelos é rara e deve ser conferida, para verificar se não foi esquecido algum
relacionamento.
Uma entidade que muitas vezes aparece isolada é aquela que modela a
organização 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, não faz sentido relacionar ela no diagrama a nenhuma outra entidade, uma vez que
haverá uma única inclusão de dados e não irá existir mais de uma ocorrência da entidade
empresa.
Atenção
Outra situação que merece ser investigada é o caso de entidades sem atributos. Geralmente,
toda entidade deve ter, ao menos o atributo identificador.
60
Banco de Dados
Considerações Finais
Agora que você já aprendeu a simbologia do DER e estudou nesse capítulo várias
dicas de como desenhar o MER e verificar o modelo criado, resta a você praticar e praticar
muito, lembrando sempre da importância dessa etapa de modelagem conceitual para o
projeto do banco de dados como um todo. Logo, mãos à obra!
Conheça Mais
http://www.virtual.epm.br/material/tis/curr-bio/bdados/teste.htm
Conceitos básicos de modelagem de dados
http://www.macoratti.net/cbmd1.htm
Modelagem de dados, uma visão geral
http://www.plugmasters.com.br/sys/materias/94/1/Modelagem-de-Dados-1---
Vis%E3o-Geral
Aprenda Praticando
Se olharmos a figura a ser avaliada veremos que ela apresenta alguns problemas
de modelagem que podem ser sanados com algumas modificações no diagrama. Vamos a
esses problemas:
61
Banco de Dados
Cada disciplina possui exatamente um, e somente um, departamento responsável, o qual pode ser
responsável 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 currículo de muitos cursos (inclusive nenhum) e um curso pode
possuir muitas disciplinas em seu currículo (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 parágrafo e tentando desenhar o que esse parágrafo expressa em
um diagrama E-R. À medida que vai desenhando, você pode ir juntando os pedaços do
diagrama (é só não 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 parágrafo:
62
Banco de Dados
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 currículo de muitos cursos (inclusive nenhum) e um curso pode
possuir muitas disciplinas em seu currículo (inclusive nenhuma)
Deste parágrafo tiramos que uma disciplina está relacionada com um curso (ou
currículo 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, ficaríamos com o seguinte diagrama:
63
Banco de Dados
Um aluno está inscrito em exatamente um, e somente um, curso e um curso pode ter muitos
alunos inscritos, inclusive nenhum.
Claro que você poderia dar outros nomes aos relacionamentos, visto que eles não
são especificados no enunciado, mas deduzidos das relações descritas no texto. Também, 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 não poderiam mudar.
Agora é a sua vez de fazer as atividades! Lembre, praticar é muito importante para
fixar o conteúdo estudado!
Atividades Práticas
Uma oficina mecânica deseja criar um sistema de informação para controlar os trabalhos realizados
pelos seus mecânicos.
Quando um automóvel chega à empresa, deve ser anotado o seu modelo, ano, placa. Todo
64
Banco de Dados
automóvel pertence a um cliente que possui um nome e um endereço. Os clientes podem ser
pessoas físicas ou jurídicas. Se o cliente é pessoa física então deve ser guardado o número do seu
RG e seu CPF. Já se ele é pessoa jurídica deve ser guardado o número do seu CNPJ e o seu nome
fantasia.
O automóvel será então consertado por um mecânico que é o responsável por este. Os mecânicos
da empresa trabalham no sistema de comissão e para cada mecânico deve ser anotado o seu
número, nome, endereço e sua especialidade.
A comissão é paga por cada conserto que este realiza, e para o conserto devem ser guardados sua
data, sua descrição e o valor deste.
Cada cinema possui uma identificação única, um nome fantasia e uma capacidade de lotação. Deve-
se saber o endereço completo do cinema, o qual inclui: rua, número, bairro, município, estado e
CEP. Cada cinema possui 1 ou mais salas de exibição, das quais precisamos armazenar o nome e a
capacidade (No. de pessoas).
Cada filme é registrado com um título original, e se for filme estrangeiro, possuirá também o título
em português e o país de origem.
Os filmes possuem uma duração, um elenco (com vários atores), um ou mais diretores e podem
ser dos mais variados gêneros (ex: romance, ação, terror, etc). Os atores ou diretores de um filme
podem, obviamente, trabalhar em outros filmes, assim como o diretor de um filme pode também
ser ator neste filme ou em outros. Qualquer pessoa (ator ou diretor) possui: nº de identificação,
nome, nacionalidade e data de nascimento.
Alguns cinemas apresentam mais de um filme em cartaz por sala, dependendo do horário. 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 horários de
exibição desse filme.
Uma locadora de carros possui várias filiais. Cada filial possui diversos carros para alugar.
Existem vários tipos de carro: popular, luxo, utilitário, etc. Os carros possuem código (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 aluguéis.
Para cada aluguel é emitida uma nota fiscal com a quilometragem percorrida e o valor pago pelo
aluguel. A locadora possui funcionários que trabalham nas filiais. As filiais são identificadas por
código, nome cidade, endereço e telefones.
Os clientes são identificados por código, nome, cpf, telefone, endereço, cidade. E os funcionários
são identificados por código, nome, endereço, telefone, cidade e função. Você pode acrescentar os
atributos que achar necessário.
65
Banco de Dados
Vamos Revisar?
O modelo ER é um modelo formal, não ambíguo e muito utilizado. Mesmo assim ele
ainda tem poder limitado de representação. Neste capítulo você estudou como desenhar
esse modelo (com dicas de como escolher a melhor representação) e verificar a corretude
do mesmo. Esse é um capítulo que merece atenção e seu conteúdo 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, não deixe de fazer todos os exercícios deste capítulo.
66
Banco de Dados
Capítulo 6
Metas
67
Banco de Dados
Você sabia que existe mais de uma notação para o MER? Pois é! Existe sim. Na
verdade, desde o surgimento do MER, vários autores de livro fizeram uso de representações
diferentes para este modelo (diferentes graficamente e/ou semanticamente). Assim, hoje
temos na literatura e na prática uma ampla variedade de representações para o MER.
Porém, mesmo existindo variações, é importante dentro de um mesmo contexto, uma
mesma empresa, usar uma representação padronizada para que as pessoas da organização
(por exemplo, analistas e programadores) possam se comunicar. Essa escolha da notação
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 notação
(por exemplo, o BR-Modelo usa a notação de Peter Chen).
Até agora a notação que utilizamos foi a notação de Peter Chen. Neste capítulo,
vamos apresentar duas outras notações que, também, são bastante utilizadas: a notação
Engenharia de Informações e a notação MERISE (uma notação Europeia).
68
Banco de Dados
Para que você perceba melhor a diferença dessa notação para a notação de Peter
Chen que vinha sendo utilizada, veja a Figura 70. Nela, temos primeiro a notação 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 notação da Engenharia de Informações. Percebe a diferença?
69
Banco de Dados
não por um gerente. Se o empregado for uma secretária, ele deve domintar zero ou mais
processadores de texto. E deve existir uma ou mais secretárias 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 notação de Peter
Chen, esse problema seria representado como apresentado na Figura 71. Já na notação de
Engenharia de Informações, ele seria representado como na Figura 72.
70
Banco de Dados
Notação MERISE
MERISE é uma metodologia de desenvolvimento de sistemas bastante utilizada
na França e em outros países europeus. Algumas diferenças dessa notação para a de Peter
Chen são:
Estratégias de Modelagem
71
Banco de Dados
É a fonte utilizada para a concepção de novos sistemas, para os quais como não há
descrições de dados, deve-se partir do conhecimento que as pessoas possuem do sistema
sendo modelado. Com esse tipo de fonte de informação podem ser usadas as seguintes
estratégias:
» Estratégia 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 genéricas, 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, verifica-
se a necessidade de se criar generalizações/especializações. Assim, é possível
perceber que essa estratégia é inversa à estratégia bottom-up. Uma sequência de
passos utilizada para obter um modelo através da estratégia top-down pode ser:
1) Constroe-se um modelo pouco detalhado, com entidades, relacionamentos,
hierarquias (especializações/generalizações), atributos de entidades
e relacionamentos (destacando os identificadores) e considerando as
necessidades de levar em conta o aspecto temporal. Porém, sem o domínio
dos atributos e as cardinalidades mínimas de relacionamentos (modelagem
superficial).
2) Complementa-se o modelo com os domínios dos atributos e as cardinalidades
mínimas dos relacionamentos (modelagem detalhada). Adicionalmente, para
complementar o MER, especificam-se, textualmente, restrições de integridade
que não podem ser representadas por ele.
72
Banco de Dados
3) Por fim, o modelo deve ser validado com o usuário do sistema e através da
procura de construções redundantes ou deriváveis a partir de outras do
modelo.
Em qualquer um desses passos, é possível retornar aos passos anteriores para fazer
ajustes.
» Estratégia 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 periféricos a eles relacionados (“ir para
fora”). Por exemplo, pode-se iniciar com uma entidade considerada importante
(que se supõe estar associada a várias outras entidades, que se supõe 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
generalizações/especializações. A cada nova entidade que for sendo acrescentadas
essas definições são refeitas, até obter-se o modelo completo.
Considerações Finais
Muitas vezes a escolha da notação a utilizar vai depender da escolha da
ferramenta CASE que será adotada no projeto do banco de dados. Porque, na prática,
não é recomendável realizar a modelagem e projeto do BD manualmente ou usando
ferramentas de propósito geral (por exemplo, Word, PowerPoint, paint, etc). De fato, é
altamente recomendável usar uma ferramenta de modelagem desde o início. Isso, porque
uma ferramenta desse tipo facilita a manutenção/atualização do modelo de dados e, em
geral, ajuda as outras etapas do projeto do BD, até mesmo a criação do modelo fisicamente
no Banco de Dados. No mercado, existem várias ferramentas8 que variam em configuração
e preço (existindo também as gratuitas). Para escolher uma boa ferramenta, procure por Saiba Mais
aquela que tenha uma boa capacidade de edição diagramática (facilitando o desenho do
diagrama), que possua alguma forma de suporte à contrução do dicionário de dados (DD) e 8
Apresentamos
que mantenha esse dicionário integrado com o modelo sendo construído. algumas dessas
ferramentas no final
do Capítulo 4, neste
mesmo volume.
Conheça Mais
Mais detalhes sobre o assunto apresentado nesse capítulo podem ser encontrados
no livro do professor Carlos Heuser: HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados
– Série Livros Didáticos, V.4. Bookman Companhia Ed., 6ª Edição – 2009. Adicionalmente,
você também pode consultar:
73
Banco de Dados
Você Sabia?
O modelo entidade-relacionamento foi proposto em 1976, por Peter P. Chen, por meio da
publicação inicial de um trabalho intitulado “The Entity-Relationship Model: Toward the unified
view of data”. Dada a simplicidade da diagramação e dos conceitos envolvidos, o modelo teve
ampla aceitação e passou a ser um referencial quase que definitivo para a modelagem de dados,
aliás, extremamente atualizada até os dias atuais.
Minibiografia
Dr. Peter Pin-Shan Chen recebeu seu título de PHD pela universidade de Harvard. Já foi professor
regular e visitante no MIT, UCLA, na própria Universidade de Harvard e, desde 1983 preenche
a posição de distinto professor catedrático em Ciência da Computação na Universidade do
Estado de Louisiana. Ele é o criador do modelo entidade relacionamento (MER), o qual
serve de fundamentação para muitas metodologias de análise e projeto de sistemas e para
muitas ferramentas CASE para modelagem de banco de dados. O MER também serve como
fundamentação para alguns dos trabalhos recentes de Análise e Projeto Orientados a Objetos e
Web Semântica.
O artigo original de Peter Chen sobre o MER (cuja referência está no “conheça mais” desse
capítulo) é um dos artigos mais citados na área de Computação. Este artigo foi selecionado
como um dos 38 mais influentes da Ciência da Computação, de acordo com a avaliação feita por
cerca de 1000 renomados professores universitários da área de Computação de todo o mundo
(ranking disponível em: http://bit.csc.lsu.edu/~chen/GreatPapers.html, editado por P. Laplante,
West Publishing, 1996).
Fonte: Site do próprio Peter Chen na Universidade de Louisiana
(http://bit.csc.lsu.edu/~chen/chen.html)
1. Antes dessa disciplina, você já conhecia, tinha lido sobre ou tinha utilizado alguma
das notações estudadas (Peter Chen, Engenharia de Informações ou MERISE)?
2. Qual das notações você achou mais fácil e qual delas você achou mais complicada.
Por quê?
Este é um fórum temático, logo, ele fará parte da sua avaliação somativa. Logo, não
74
Banco de Dados
deixe de participar! Além disso, você pode aprender muito compartilhando informações
com seus colegas.
Atividades Práticas
1) Escreva uma frase para representar como se leem cada um dos relacionamentos
abaixo. Depois, redesenhe cada um desses relacionamentos na notação MERISE.
Vamos Revisar?
Existem diversas notações para modelagem conceitual dos dados. Entre as mais
utilizadas temos a orignal de Peter Chen, a notação da Engenharia de Informações (também
chamada de pés de galinha ou notação James Martin) e a notação MERISE. A escolha
da notação a adotar, muitas vezes, vai depender da ferramenta CASE a ser adotada para
modelagem e projeto do banco de dados.
75
Banco de Dados
Considerações Finais
Olá, cursista!
Esperamos que você tenha aproveitado este segundo módulo da disciplina Banco
de Dados. Como já foi dito anteriormente, a modelagem conceitual é um dos assuntos mais
importantes que vamos estudar, porque ela é o começo de tudo. Por isso, pratique muito,
releia o texto e tenha certeza que está entendendo bem o assunto.
No próximo módulo, estudaremos como fazer a transformação da modelagem
conceitual para a modelagem lógica. Além 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 participação no próximo módulo.
Até lá e bons estudos!
Sandra de Albuquerque Siebra
Autora
76
Banco de Dados
Referências
77
Banco de Dados
Conhecendo a Autora
78