Professional Documents
Culture Documents
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......................................................................................................34
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 2 do Volume
1 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, que exija menos espaço em disco e que aproveite
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 para 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
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.
Entidades
Para se referir a uma entidade particular fala-se em instância ou ocorrência de entidade. Uma
instância é um objeto de uma entidade 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
Figura 8 - Pequeno trecho de um MER com a representação dos atributos (notação Silberschatz)
Figura 9 – Pequeno trecho de um MER com a representação dos atributos (notação Chen)
Identificador de Entidade
seria representado sublinhado. E na notação de Chen seria utilizado um círculo preto para
o atributo identificador e círculos brancos para o restante dos atributos. Por exemplo, na
Figura 10 vemos a representação nas duas notações do atributo identificador (o CPF). Esse é
um identificador simples, pois apenas um atributo faz parte dele.
Na Figura 11, vemos um exemplo (nas duas notações) de uma entidade com
identificador composto. Um identificador composto possui dois ou mais atributos fazendo
parte dele. No caso da figura, está sendo representada a entidade PRATELEIRA que tem
como identificador composto os atributos corredor e armário e um atributo extra chamado
capacidade.
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 12). 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
R entre as entidades A e B (vide Figura 14), o grau ou cardinalidade especifica valores que
vão responder às seguintes perguntas:
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 19). Por exemplo, “Um aluno é orientado por um
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
(na primeira notação N alunos), conforme pode ser visto na Figura 20.
19
Banco de Dados
» 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 21). 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 22).
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
pode ser visto no diagrama exemplo da Figura 23.
trabalha em Projeto”. Em uma determinada empresa poderia ser que só fosse permitido
a um empregado trabalhar em um projeto por vez (Figura 24, primeira imagem). Assim
o relacionameto seria de cardinalidade N:1, onde um empregado só trabalha em um
projeto e um projeto pode ter N empregados (lembrando que N equivale a zero, um ou
mais empregados). Porém, em outra empresa, poderia ser possível que um empregado
trabalhe em N projetos. Dessa forma, o relacionamento seria de cardinalidade M:N (Figura
24, segunda imagem), onde um empregado poderia trabalhar em N projetos e um projeto
poderia ter M empregados. Então, como foi dito, a definição da cardinalidade vai depender
do problema sendo modelado.
empregado pode não possuir dependentes ou pode possuir vários). E uma ocorrência de
dependente está associada a apenas uma ocorrência de empregado (cada dependente
possui apenas um empregado responsável).
Grau de Relacionamento
O grau de um relacionamento indica o número de entidades participantes do
mesmo. Assim, o relacionamento TRABALHA da Figura 24 é 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 26. 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.
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
23
Banco de Dados
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 30. Nele temos “Pessoa
casa com Pessoa”. Nesse relacionamento é necessário especificar os papéis, no caso, marido
e esposa. Supõe-se que, na nossa cultura, esse deve ser um relacionamento 1:1 J
Saiba Mais
Outro exemplo de atributo em relacionamento pode ser visto na Figura 32. 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
2
Atributos
opcionais não têm
FINANCIA. As vendas a prazo precisam ter informações sobre a quantidade de parcelas e obrigatoriedade de
a taxa de juros que será cobrada. Onde poderiam ser colocados esses atributos? Se estes preenchimento.
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
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 32).
Relacionamento Identificador
atributos da própria entidade, mas, também, por relacionamentos dos quais a entidade
participa (relacionamento identificador). Um exemplo deste caso é mostrado na Figura 33.
Na figura, o cliente possui dependente. Cada dependente está relacionado a exatamente
um cliente. Um dependente é identificado pelo CPF do cliente ao qual ele está relacionado
e por um número sequencial que o distingue dos diferentes dependentes que um mesmo
cliente possa ter. Veja que, na Figura 33, na primeira notação o relacionamento usado como
identificador é indicado por um losango com linhas duplas e a entidade que é dependente
de outra (entidade fraca) também é representada com linhas duplas. Já na segunda notação
(a notação de Chen), o relacionamento identificador é indicado apenas por uma linha mais
grossa do que as demais do diagrama, sem modificação alguma na notação da entidade
fraca Dependente (vide o segundo desenho da Figura 33).
Saiba Mais
3
Entidade forte é
aquela que possui
Figura 33 – Representação de relacionamento identificador e entidade fraca (nas duas notações).
o seu próprio
identificador e não
depende de nenhuma
outra entidade para Nesse caso, alguns autores dizem que a entidade DEPENDENTE é uma entidade
isso. 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
identificador da entidade fraca é composto pelo identificador da entidade forte a qual a
existência dela está associada mais algum atributo (geralmente um sequencial) da própria
entidade fraca. O relacionamento que associa a entidade fraca a seu proprietário (a entidade
forte) é, justamente, o que chamamos de relacionamento identificador (no caso da Figura
33, o relacionamento chamado POSSUI).
Atenção
O termo Entidade Fraca deve ser usado com cautela, pois uma entidade fraca em um
relacionamento não necessariamente é também fraca em outro relacionamento.
26
Banco de Dados
Especialização/Agregação
Importante
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 34, as entidades
especializadas P. FÍSICA e P. JURÍDICA herdam todos os atributos e relacionamentos
da entidade genérica CLIENTE, podendo ter, adicionalmente, mais algum atributo ou
relacionamento próprio.
30
Banco de Dados
BR-MODELO
31
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 41.
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
33
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
http://www.devmedia.com.br/articles/viewcomp.asp?comp=7776
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.
35
Banco de Dados
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 44, 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.
36
Banco de Dados
Aprenda Praticando
37
Banco de Dados
a) 0 e 1
b) 0 e 2
c) 1 e 1
d) 1 e 2
e) 2 e 1
Adaptado de CESGRANRIO - 2005 - MPE-RO - Analista Programador
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):
38
Banco de Dados
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
Respostas:
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
40
Banco de Dados
a) Relacionamento
b) Entidade fraca
c) Autorrelacionamento
d) Especialização/Generalização
e) Agregação
2) Considere as seguintes entidades:
EMPREGADO com atributos: CPF, RG, Nome, Dept, Cargo e Salário.
PROJETO com atributos CodProj, ProjNome, DataInício, DataTérmino e Orçamento.
a) Mostre como essas duas entidades seriam representadas em um diagrama de
ER. Assuma que você deseja representar o número de horas alocadas para um
empregado trabalhar num projeto, e mostre como isto pode ser representado
no diagrama.
b) Escolha identificadores para cada uma das entidades.
c) Fazendo as hipóteses necessárias (use sua intuição), tome uma decisão sobre
a cardinalidade do relacionamento entre as entidades, explicando o que você
pensou para escolher tal cardinalidade e acrescente os símbolos apropriados
ao diagrama.
d) Assuma que a entidade EMPREGADO é especializado em VENDEDOR e
ADMINISTRADOR. Mostre como esta especialização é representada em um
diagrama ER. Inclua alguns atributos em cada uma das subclasses.
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
41
Banco de Dados
do pessoal de apoio.
Laboratórios fazem vários testes e cada um dos testes é feito em um único laboratório.
Vamos Revisar?
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
uma pessoa não possa ser casada com ela mesma como, por exemplo, p5 ser casada com p5
(vide Figura 46), o que viola completamente a realidade.
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 50, a entidade CONSULTA foi originada
do relacionamento CONSULTA da Figura 49. E essa nova entidade é relacionada às entidades
anteriormente existentes (MEDICO e PACIENTE).
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 têm 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 que a representação criação do banco de
dados.
de um objeto está sujeita a alteração durante a modelagem (você pode mudar de ideia, à
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.
47
Banco de Dados
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 51).
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 52).
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
unanimemente aceita, é possível dar uma ideia de roteiro.
expressos por verbos. Quando isto ocorrer, em geral, une-se os nomes das entidades
para dar nome ao relacionamento. Por exemplo: cliente_conta, transação_conta.
2. Nessa identificação, procure primeiro pelas entidades. Nem todo substantivo é
entidade. Descarte aquele que só aparece uma vez na descrição do problema (não
se relacionam com nada), os que não possuem nenhuma característica descrita ou
aqueles que só servem para entendimento do problema, mas não são relevantes
para resolvê-lo.
3. A seguir, procure pelos relacionamentos. Geralmente, são indicados pelos verbos
que indicam relação entre os substantivos. Geralmente, devemos tentar formar
uma sentença do tipo “entidade verbo entidade”. Por exemplo, “Cliente possui
Conta”, “Empregado alocado Projeto”. Nessa descoberta dos relacionamento, você
deve procurar identificar se é um relacionamento binário ou ternário. 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 mínima e
máxima deles. Geralmente, haverá alguma indicação no enunciado do problema.
Ex: “um médico pode consultar vários pacientes e um paciente pode ser consultado
por vários médicos”. Isso vai indicar um relacionamento n:n entre as entidades
PACIENTE e MEDICO.
5. Na sequência, procure pelos atributos. Lembre-se, os atributos serão os elementos
que caracterizam as entidades e que são relevantes para representação do problema.
Procure, também, 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 histórico dos acontecimentos ou algo
que caracterize o relacionamento).
6. Por fim, faça uma revisão no problema e no diagrama e veja se alguma coisa pode
ser melhorada (veja os critérios do começo desse capítulo). Veja, também, se há
alguma generalização/especialização que possa ser feita.
Alguns cuidados devem ser tomados durante essa criação do DER:
» 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, a seguir, como checar cada um desses pontos.
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
assim, toda pessoa moraria o mesmo tempo no imóvel, mesmo que ele mudasse de
dono. O correto seria que o tempo de posse estivesse no relacionamento POSSE.
Dessa forma, a cada novo dono, o tempo de posse seria diferente.
b) Representar um mesmo elemento, ora como entidade, ora como atributo. Por
exemplo, na Figura 60, 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.
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.
Atenção
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á embutido. 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 68). 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 relacioná-la 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:
enquanto que CNPJ e razão social deveriam pertencer a clientes do tipo Pessoa
Jurídica. Gerando assim, a especialização.
» O atributo telefone é multivalorado e atributos multivalorados não são bem vindos
em modelagens relacionais por se ter dificuldade de implementação do mesmo.
Dessa forma, atributos multivalorados quando possuem características próprias
ou quando têm a necessidade de se relacionar com outras entidades, podem
ser transformados em entidades. Por isso, vamos supor que no nosso problema
gostaríamos de armazenar algumas informações sobre o telefone, tais como: o
DDD, o número 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.
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,
Saiba Mais 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
7
Sempre que se diagrama (é só não repetir entidades ou relacionamentos citados, ir desenhando os novos
puder ter nenhuma requisitos indicados ligando ao que já estiver desenhado). Vamos dar alguns exemplos de
ocorrência, isso
quer dizer que a como ir fazendo isso, antes de mostrar como ficaria o diagrama como um todo. Vamos ao
cardinalidade mínima primeiro parágrafo:
do relacionamento é
zero. Cada disciplina possui exatamente um, e somente um, departamento responsável,
o qual pode ser responsável por muitas disciplinas, inclusive nenhuma7.
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:
Um aluno está inscrito em exatamente um, e somente um, curso e um curso pode ter muitos
alunos inscritos, inclusive nenhum.
63
Banco de Dados
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-se que 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
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.
64
Banco de Dados
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 cartaz 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 carros: 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
Apêndice A
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 apêndice,
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 71. 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?
empregado pode ser um gerente, uma secretária ou um engenheiro. Se ele for um gerente,
ele vai gerenciar um ou mais empregados. E o empregado, por sua vez, é gerenciado ou
não por um gerente. Se o empregado for uma secretária, ele deve dominar 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 72. Já na notação
de Engenharia de Informações, ele seria representado como na Figura 73. Observe nesta
nova notação, como as entidades que fazem parte da especialização/generalização estão
agrupadas. Observe que os subtipos (especializações) gerente, secretária e engenheiro são
representados como entidades internas da classe mais genérica (empregado). Observe,
também, a forma como os relacionamentos são feitos com as entidades agrupadas.
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
É 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)
Discuta com seus colegas, seu tutor e/ou seu professor sobre as notações vista
neste apêndice. Você pode usar como guia as questões sugeridas a seguir:
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)? Qual
delas?
74
Banco de Dados
2. Qual das notações você achou mais fácil e qual delas você achou mais complicada.
Por quê?
Lembre-se, discutir sobre um tema, é uma forma de amadurecer esse tema em sua
mente, sem contar que, você pode aprender muito compartilhando informações com seus
colegas.
Atividades Práticas
Para ver se você entendeu o que foi apresentado nesse apêndice, você pode fazer
os seguintes exercícios:
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