volume 2

Prévia do material em texto

Recife, 2010
Banco de Dados
UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)
COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE)
Sandra de Albuquerque Siebra
Volume 2
Universidade Federal Rural de Pernambuco
Reitor: Prof. Valmar Corrêa de Andrade
Vice-Reitor: Prof. Reginaldo Barros
Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho
Pró-Reitor de Extensão: Prof. Paulo Donizeti Siepierski
Pró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José Freire
Pró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira
Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena
Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos
Produção Gráfica e Editorial
Capa e Editoração: Allyson Vila Nova, Rafael Lira, Italo Amorim e Heitor Barbosa
Revisão Ortográfica: Marcelo Melo
Ilustrações: Noé Aprígio, Diego Almeida e Moisés Souza
Coordenação de Produção: Marizete Silva Santos
Sumário
Apresentação ................................................................................................................. 4
Conhecendo o Volume 2 ................................................................................................ 5
Capítulo 4 – Modelagem de Banco de Dados .................................................................. 7
Modelo de Dados ............................................................................................................7
O Modelo Entidade-Relacionamento ............................................................................11
Notação de Peter Chen para Cardinalidade ...................................................................21
Extensões do Modelo Entidade-Relacionamento ..........................................................26
Ferramentas para Modelagem de Dados ......................................................................30
Considerações Finais .....................................................................................................33
Capítulo 5 – Desenhando o MER .................................................................................. 44
Peculiaridades dos Modelos ER .....................................................................................44
Critérios para Construção do Modelo ER ......................................................................47
Evitando Atributos Multivalorados ................................................................................50
Criando o Diagrama ER ..................................................................................................51
Verificação do Modelo Criado .......................................................................................53
Considerações Finais .....................................................................................................61
Capítulo 6 – Outras Notações para o MER .................................................................... 68
Notação da Engenharia de Informações ........................................................................68
Notação MERISE ............................................................................................................71
Considerações Finais .....................................................................................................73
Considerações Finais .................................................................................................... 76
Conhecendo a Autora .................................................................................................. 78
4
Apresentação
Caro(a) cursista,
Seja bem-vindo(a) ao segundo módulo do curso Banco de Dados!
Neste segundo módulo, vamos estudar um assunto que considero um dos mais importantes para o 
aprendizado de Banco de Dados: a modelagem conceitual dos dados que serão armazenados. Por que ela é 
importante? Porque ela é o começo de tudo. Um banco de dados começa a existir na modelagem. E, se um banco de 
dados é modelado errado, consequentemente, você terá um banco de dados que não atenderá aos seus objetivos 
ou que poderá dar muito mais trabalho para armazenar e recuperar os dados armazenados da maneira apropriada, 
mantendo a integridade dos mesmos.
Assim, como esse é um assunto muito importante, procure dedicar bastante atenção e tempo ao mesmo, 
ok?
Bons estudos!
Sandra de Albuquerque Siebra
Autora
5
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.
Módulo 2 – Modelagem e Projeto de Banco de Dados
Carga horária do Módulo 2: 15 h/aula
Objetivo do Módulo 2:
» Introduzir os principais conceitos e definições relacionados à modelagem de dados.
» Examinar os principais conceitos envolvidos em um projeto conceitual de BD.
» Ensinar a projetar banco de dados relacionais confiáveis e eficientes.
Conteúdo Programático do Módulo 2:
» Modelos de Dados – Conceitos; Modelos Lógicos baseados em Registros; 
hierárquico, rede, relacional. Modelos entidade-relacionamento e orientado a 
objeto.
» Modelo Entidade-Relacionamento – Modelagem conceitual de Dados; Diagrama 
Entidade-relacionamento; Reduzindo Diagramas E-R a Tabelas; Projeto de um 
Esquema de Bancos de Dados E-R.
» Ferramenta para Modelagem de Dados.
6
Banco de Dados
Capítulo 4
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar os seguintes temas:
» Modelo de Dados.
» Componentes do Modelo Entidade-Relacionamento (MER).
» Ferramenta para Modelagem de Dados.
Metas
Após o estudo deste capítulo, esperamos que você consiga:
» Identificar os principais conceitos relacionados à modelagem de dados.
» Identificar e saber a utilidade de cada um dos componentes de um Modelo Entidade 
Relacionamento (MER).
» Utilizar alguma ferramenta para a modelagem de dados.
7
Banco de Dados
Capítulo 4 – Modelagem de Banco de 
Dados
Vamos conversar sobre o assunto?
Se você pretende desenvolver aplicações que usam banco de dados relacionais, 
você, com certeza, deverá possuir os conceitos básicos sobre modelagem de dados. Não 
importa o tamanho da sua aplicação ou a complexidade da mesma, sempre será muito 
importante ter bem projetado o local onde os dados serão armazenados, de forma que eles 
possam ser recuperados de forma fácil, íntegra e correta. É justamente o “como fazer” o 
projeto de banco de dados que veremos nesse capítulo. Lembre, esse é um dos assuntos 
mais importantes da nossa disciplina, logo, leia esse capítulo com mais atenção do que 
qualquer outro e não esqueça de praticar os conceitos que serão aprendidos. Vamos lá?
Neste capítulo, vamos falar sobre modelos de dados e modelagem de dados. 
Aproveite bem tudo que vem pela frente!
Modelo de Dados
Lembra do conceito de abstração de dados que explicamos no capítulo 3, 
do fascículo I da disciplina? Pois são os modelos de dados as principais ferramentas 
que fornecem a abstração a um BD, visto que o modelo de dados representa, de forma 
abstrata, como aspectos do mundo real (fatos) estão relacionados, a fim de que possam 
ser representados no mundo computacional. Mas o que é um modelo de dados? Ele é um 
conjunto de conceitos que podem ser usados para descrever a estrutura de uma base de 
dados. Por estrutura de uma base de dados entende-se os tipos de dados, relacionamentos 
e restrições pertinentes aos dados que serão armazenados no BD. Muitos modelos de dados 
também definem um conjunto de operações para especificar como recuperar e modificar a 
base de dados.
Já o processo pelo qual você planeja ou projeta a base de dados, de forma que 
possa construir um banco de dados consistente, de forma a exigir menos espaço em disco 
e aproveitaros 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).
8
Banco de Dados
Figura 1 - Ciclo de Desenvolvimento de SBDs
E quais são as outras etapas? Primeiro, para poder realizar a modelagem dos 
dados, você precisa fazer um levantamento de requisitos. Ou seja, precisa investigar quais 
dados deverão fazer parte do banco de dados, a fim de representar bem o problema a ser 
resolvido e poder atender as necessidades de armazenamento (persistência) dos dados da 
aplicação. Uma vez que se saiba os dados que devem ser manipulados, você deve analisar 
como esses dados podem ser representados e relacionados (olhando para o mundo real) 
através de um modelo de dados. Esse é o papel da segunda etapa, a modelagem dos dados. 
Uma vez que os dados estejam modelados o banco de dados será projetado, transformando 
o modelo de dados criado em estruturas de mais baixo nível que possam ser criadas dentro 
do SGBD. Posteriormente, o BD é realmente implementado usando algum dos SGBDs 
disponíveis no mercado e, depois, mantido e monitorado pelo administrardor de banco de 
dados.
Existem modelos para diferentes níveis de abstração de representação de dados. 
São eles: modelos conceituais (também conhecido como modelo com base em objetos), 
modelos lógicos (também conhecido como modelo com base em registros) e modelos 
físicos. Vamos descrever melhor cada um deles a seguir.
Modelo Conceitual
É a primeira etapa da modelagem de dados, sendo a descrição mais abstrata da 
realidade, modelando de forma mais natural os fatos do mundo real, suas propriedades 
e relacionamentos. É utilizado para entendimento, transmissão, validação de conceitos, 
mapeamento do ambiente e para facilitar o diálogo entre usuários e desenvolvedores. A 
modelagem conceitual do BD independe da sua implementação, não contendo nenhum 
detalhe da mesma. Assim, a modelagem conceitual é independente do SGBD utilizado para 
implementação do BD. De fato, o modelo conceitual registra que dados podem aparecer no 
banco de dados, mas não registra como estes dados estão armazenados em nível de SGBD. 
A modelagem conceitual dos bancos de dados relacionais é feita através da criação 
do modelo entidade-relacionamento (MER). No caso de bancos de dados orientados a 
objetos ou objeto-relacional, é usado o modelo de classes da UML (Unified Modeling 
Language).
Modelo Lógico
Representa os dados em alguma estrutura (lógica) de armazenamento de dados, que 
9
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)).
Figura 2 - Relação entre os modelos de dados
10
Banco de Dados
Vamos descrever mais formalmente esse processo de criação do BD (que equivale 
ao processo de projeto do banco de dados)? Bem, podemos dizer que esse processo 
é composto por quatro fases (vide Figura 3). Na primeira fase, é feito o Levantamento e 
Análise dos Requisitos. Nessa fase são realizadas entrevistas com os potenciais utilizadores 
do BD, são levantados documentos importantes, pode-se olhar um sistema legado (já 
existente) para ver como ele funciona, tudo com o objetivo de compreender e documentar 
os requisitos1 necessários para a construção do banco de dados (requisitos de BD).
A segunda fase é o projeto conceitual (ou modelagem) cujo objetivo é definir um 
modelo de dados conceitual que inclua a descrição das entidades do BD, dos atributos 
das entidades, dos relacionamentos entre entidades, além das possíveis restrições. 
Porém, evitando detalhes de implementação. Essa fase dá origem ao esquema conceitual 
representado pelo modelo entidade-relacionamento (que estudaremos em detalhes na 
próxima seção).
A terceira fase é o projeto lógico (ou implementação) que objetiva mapear o 
modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem ao 
esquema lógico representado pelo modelo relacional que já é um modelo que depende do 
SGBD que será usado para implementar o banco de dados.
A quarta e última fase é o projeto físico que objetiva mapear o modelo de 
dados relacional para o modelo de dados físico que tratará das estruturas em memória e 
organização dos arquivos do BD (arquivos de índices). Essa fase dá origem ao esquema físico 
que será o que realmente será implementado no BD.
Figura 3 - Projeto de Esquemas de BD (Fonte: Elmasri, 1994)
Lembrete
1 Um requisito 
consiste da definição 
documentada de 
uma propriedade 
ou comportamento 
que um produto ou 
serviço particular 
deve atender. Ou de 
uma característica, 
atributo, habilidade 
ou qualidade que um 
sistema (ou qualquer 
um de seus módulos 
e subrotinas) deve 
necessariamente 
prover para ser útil a 
seus usuários.
11
Banco de Dados
Como a fase de análise de requisitos faz parte do contexto de estudo da disciplina 
de análise de sistemas, vamos começar a nossa explicação a partir do projeto conceitual de 
BD. Nesta etapaé criado o modelo entidade-relacionamento (no caso de bancos de dados 
relacionais – foco desta disciplina) e este é justamente o assunto da próxima seção.
O Modelo Entidade-Relacionamento
Primeiro vamos contar a história desse modelo... O modelo 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. 
Figura 4 - Um pequeno exemplo de MER
Só a título de curiosidade, como ficaria o microdiagrama da Figura 4 se estivessemos 
tratando da modelagem de um banco de dados orientado a objetos ou objeto-relacional? 
Como vimos, nestes tipos de bancos de dados é usado o diagrama de classes da UML 
para representação da modelagem conceitual. Esse diagrama consiste de uma coleção de 
objetos básicos agrupados em classes e nos relacionamentos entre essas classes. E cada 
classe possui os seus atributos (características) e métodos (operações que as classes podem 
12
Banco de Dados
realizar). Uma versão orientada a objetos do diagrama da Figura 4 é ilustrada na Figura 5. 
Até que se olharmos os componentes, os dois diagramas são até um pouco parecidos, não 
é?
Figura 5 - Exemplo de Diagrama de Classes
Componentes do Modelo Entidade-Relacionamento
Explicaremos, detalhadamente, a seguir, cada componente do MER. Depois, no 
próximo capítulo apresentaremos como você irá juntar tudo para criar um diagrama E-R. 
Vamos lá?
Entidades
O objeto básico que o MER representa é a entidade. Uma entidade é algo do 
mundo real que possui uma existência independente. Uma entidade pode ser um objeto 
com uma existência física (por exemplo, uma pessoa, um DVD, um carro ou um livro), nesse 
caso é chamada entidade concreta. Ou pode ser um objeto com existência conceitual (por 
exemplo, uma locação, um curso, um empréstimo ou um projeto), nesse caso é chamada 
entidade abstrata. Em outras palavras, é um objeto concreto ou abstrato da realidade 
modelada, sobre o qual se deseja manter informações no BD. Graficamente, entidades são 
representadas por um retângulo com um nome dentro (vide Figura 6). Esse nome deve vir 
no singular e deve ser representativo.
Figura 6 - Exemplos de entidades
É importante que toda entidade criada seja descrita em um dicionário de dados. 
Mas o que é um dicionário de dados? Ele é um documento com a explicação de todos os 
objetos criados no banco de dados (entidades, atributos e relacionamentos). Ele permite 
que os analistas obtenham informações sobre todos os objetos do modelo de forma textual, 
contendo explicações por vezes difíceis de incluir no diagrama. A maioria dos SGBDs atuais 
já fornece ferramentas para facilitar a inclusão de informações no dicionário de dados, 
deixando assim os objetos criados bem melhor documentados (você vai conseguir saber 
exatamente quem é quem e para quê serve). Nesta etapa de definição da entidades, a 
13
Banco de Dados
informação possível de colocar no dicionário é apenas a descrição da entidade. Na Figura 
7, você pode ver exemplos de como poderia ser a descrição das entidades Empregado e 
Encomenda em um dicionário de dados.
Entidade: Empregado Encomenda
Descrição:
Pessoa que mantém vínculo 
empregatício com a Empresa através de 
um contrato de trabalho de acordo com 
a legislação trabalhista.
Instrumento contratual de emissão 
unilateral pela empresa e aceitação, 
expressa ou tácita, pelo fornecedor 
do material.
Figura 7 - Exemplo de Descrição de Entidade em um Dicionário de Dados
Um conjunto de entidades é um conjunto que abrange entidades de mesmo tipo 
que compartilham as mesmas propriedades (atributos). Por exemplo, todos os empregados 
de uma empresa. 
Cada entidade tem propriedades particulares, chamadas atributos, que a 
descrevem. Ou seja, ela é representada por um conjunto de atributos. Por exemplo, uma 
entidade EMPREGADO pode ser descrita pelas propriedades nome, cargo que ocupa, idade 
e estado civil. Essas propriedades seriam os atributos da entidade EMPREGADO. Uma 
entidade em particular terá um valor para cada um de seus atributos. Essa entidade em 
particular, que tenha os atributos preenchidos com valores é chamada instância da entidade.
Entidade X Instância de Entidade
Para se referir a uma entidade particular fala-se em instância ou ocorrência de entidade. Uma 
instância é um objeto de uma entiedade com suas respectivas propriedades preenchidas com 
valores, distinguindo assim ela de qualquer outra instância. Vamos exemplificar: a entidade 
empregado descrita há pouco, possui os atributos nome, cargo que ocupa, idade e estado civil. 
Uma instância dessa entidade poderia ser: “Maria, secretária, 31 anos, solteira”. Ou seja, a instância 
é como se fosse um exemplo de empregado, com os atributos preenchidos com valores. Entendeu?
Atributos
São propriedades descritivas de cada membro/propriedade de uma entidade ou 
relacionamento. Em outras palavras, uma entidade sempre é representada por um conjunto 
de atributos. No exemplo que citamos na seção anterior, um EMPREGADO podia ser descrito 
pelos atributos nome, cargo que ocupa, idade e estado civil. Em algumas situações, como 
veremos mais a frente, relacionamentos também podem ter atributos. 
Cada instância de uma entidade ou relacionamento tem seu próprio valor para cada 
atributo. Por exemplo, o atributo nome do empregado pode ter os valores Ana, Maria, João, 
Igor, etc. O conjunto de valores permitidos para cada atributo é chamado de domínio (é a 
definição do tipo do atributo). Por exemplo: 
nome = texto com 60 posições
conta = inteiro com 8 posições
consulta = texto com 8 posições
Os atributos podem ser dos seguintes tipos: simples, compostos, monovalorados, 
multivalorados, nulos e derivados.
Simples – os atributos simples não podem ser divididos, são atômicos. Por exemplo: 
14
Banco de Dados
Salário, CPF, idade, entre outros.
Compostos – os atributos compostos podem ser divididos em partes (ou seja, 
podem ser quebrados em outros atributos mais simples/elementares). Por exemplo: 
endereço pode ser dividido em rua, número, bairro e CEP. O atributo NomeCliente pode se 
dividido em prenome, nomeIntermediário e sobrenome. Atributos compostos são usados 
quando o usuário desejar se referir ao atributo como um todo em certas ocasiões e somente 
a parte dele em outras. Se o atributo composto for sempre referenciado como um todo, não 
existe razão para subdividi-lo em componentes elementares.
Monovalorados – Os atributos monovaloradospossuem apenas um valor por 
entidade. Por exemplo: o atributo CPF de uma entidade Cliente refere-se apenas a um nº de 
CPF é, então, monovalorado. Outro exemplo pode ser o atributo data de nascimento.
Multivalorados – Atributos multivalorados podem possuir um conjunto de 
valores para uma única entidade. Por exemplo: na entidade do Cliente pode existir um 
atributo telefone e um cliente pode ter cadastrado um, nenhum ou vários telefones (ex: 
telefone residencial, comercial e celular). Atributos multivalorados podem possuir uma 
multiplicidade, indicando as quantidades mínima e máxima de valores que ele pode assumir.
Nulos – Um atributo nulo é usado quando uma entidade não possui valor para um 
determinado atributo. Nulo significa que o valor do atributo é vazio (não-aplicável) ou ainda 
não foi informado (desconhecido). Por exemplo: Se o empregado não possui número da 
carteira de reservista (por ser do sexo feminino), o valor nulo é atribuído a este atributo 
para esta entidade, significando que o atributo não é aplicável a ele. Outro exemplo é o 
atributo complemento (do endereço) que, geralmente, é utilizado para colocar o número do 
apartamento onde alguém, tal como um cliente, mora. Porém, se a pessoa mora em casa, 
esse campo não é preenchido, ficando nulo. 
O atributo nulo pode, também, ser utilizado para denotar que o valor é 
desconhecido, como por exemplo, quando o cliente em um cadastro não responde o 
número do CEP da rua onde reside. O CEP existe e é aplicável, apenas o cliente pode não 
saber o CEP naquele momento (o CEP é deconhecido). Logo, nos primeiros exemplos dados 
aqui, o significado do uso do nulo era “não aplicável” e, neste último exemplo, o significado 
do nulo é “desconhecido”.
Derivados – O valor desse tipo de atributo pode ser derivado de outros atributos 
ou entidades a ele relacionados. Por exemplo: suponha que se deseje colocar na entidade 
cliente o atributo emprestimosRealizados, que representa o número de empréstimos 
tomados do banco por um cliente. Esse atributo não necessitaria ser preenchido, o valor 
dele poderia ser obtido contanto o número de entidades empréstimos existentes. Outro 
exemplo: suponha que se deseje colocar na entidade Pessoa o campo idade. Como ele está 
relacionado com o campo data de nascimento de uma pessoa, a idade não precisaria ser 
explicitamente preenchida. Seu valor poderia ser derivado da data de nascimento, fazendo 
a seguinte conta: data atual menos a data de nascimento. O uso de atributos derivados é 
uma decisão de projeto, dependendo da necessidade e do bom senso.
Os atributos são representados no MER por elipses (contendo o nome dos 
atributos) ligadas às entidades ou relacionamentos (sim, relacionamentos também podem 
possuir atributos, falaremos sobre isso na próxima seção!) aos quais estes atributos 
pertencem. No exemplo da Figura 8, temos as entidades CLIENTE e CONTA. A entidade 
CLIENTE tem os atributos RG, nome, cidade e endereço e a entidade CONTA, os atributos 
número, saldo e data. Atributos Derivados é que possuem uma representação diferenciada, 
sendo representados por elipses tracejadas. E atributos multivalorados são representados 
por elipses duplas (uma elipse dentro da outra).
15
Banco de Dados
Figura 8 - Exemplo de MER com os atributos sendo representados
Identificador de Entidade
Identificador de entidade é um (simples) ou mais (composto) atributos cujos valores 
identificam unicamente uma entidade. Ou seja, o identificador deve possuir um valor único 
para cada entidade, não admitindo valores repetidos do atributo (ou dos atributos) que o 
compõem. 
Por convenção, o atributo identificador é representado sempre de forma 
diferenciada dos outros atributos. Na notação que vimos anteriormente, ele seria 
representado sublinhado. E na notação de Peter Chen usa-se um círculo preto para o 
atributo identificador e círculos brancos para o restante dos atributos. Por exemplo, na 
Figura 9 (lado esquerdo), vemos a entidade CLIENTE onde o atributo CPF é o identificador 
da entidade (como é um único atributo, é um identificador simples). E na Figura 9 (lado 
direito), temos que a entidade ALUNO tem os atributos código e nome, sendo que o código 
é o atributo identificador da entidade.
Figura 9 - Exemplo de entidades com o identificador simples
Na Figura 10 vemos exemplos de identificadores compostos. Um identificador 
composto possui dois ou mais atributos como identificadores da entidade. Em ambos os 
desenhos da Figura 10 está representada a entidade PRATELEIRA que tem como identificador 
os atributos corredor e armário e um atributo extra chamado capacidade.
Figura 10 - Exemplo de entidade PRATELEIRA com identificador composto 
(notação convencional e notação Heuser)
16
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.
Figura 11 - Exemplo de relacionamento
Formalmente, o relacionamento é uma relação matemática com n > = 2 (onde n é o 
número de conjuntos entidades que fazem parte do relacionamento). 
Da mesma forma que temos entidades e instâncias de entidades, também temos 
relacionamentos e instância de relacionamentos. A instância de relacionamento se refere 
a um relacionamento em particular (uma ocorrência). Por exemplo, para o exemplo da 
figura 10: “Departamento emprega Funcionário”, poderíamos ter o relacionamento que 
associa o Departamento Financeiro ao Funcionário Igor, significando que Igor trabalha no 
departamento financeiro. Esse relacionamento específico seria um exemplo de instância.
Como já vizualizado na Figura 11, o relacionamento é representado graficamente 
por um losango (com o nome do relacionamento dentro) interligando as entidades que ele 
relaciona. Às vezes, pode existir mais de um relacionamento entre as mesmas entidades, 
no entanto, eles são independentes entre si. Por exemplo, “Professor leciona Curso” e 
“Professor coordena Curso” (vide Figura 12) são dois relacionamentos distintos entre as 
duas mesmas entidades Professor e Curso.
Todo relacionamento deve ter uma cardinalidade e um grau associado e pode vir a 
ter atributos, como veremos a seguir.
17
Banco de Dados
Figura 12 - Exemplo de dois relacionamentos entre as mesmas entidades
Cardinalidade do Relacionamento
A cardinalidade caracteriza o número mínimo e máximo de instâncias de cada 
entidade que podem estar associadas através do relacionamento. Dado um relacionamento 
R entre as entidades A e B (vide Figura 13), o grau ou cardinalidade especifica valores que 
vão responder às seguintes perguntas:
1. Com quantos elementos de B se relaciona cada um dos elementos de A?
2. Dado um elemento de B, com quantos elementos de A ele se relaciona?
Figura 13 - Relacionamento R entre as entidades A e B
Assim, as cardinalidades podem ser dos seguintes tipos:
» Um para um (1:1): Uma entidade de A está associada, no máximo, a uma entidade 
de B, e uma entidade de B está associada a, no máximo, uma entidadede A. É como 
se cada instância da entidade A só encontrasse uma instância correspondente na 
entidade B (vide Figura 14). Por exemplo, “Pessoa recebe Certidão de Óbito”. Cada 
pessoa só pode receber uma única certidão de óbito (só se morre uma vez, não é?) 
e uma certidão de óbito só deve pertencer a uma única pessoa (vide Figura 15). 
Logo, esse relacionamento é dito um para um.
18
Banco de Dados
Figura 14 - Esquema de um relacionamento 1:1
Figura 15 - Exemplo de relacionamento um para um
» Um para muitos (1:N): Uma entidade em A está associada a várias entidades 
em B. Uma entidade em B, entretanto, deve estar associada a, no máximo, uma 
entidade em A. É como se cada instância da entidade A encontrasse zero ou mais 
instâncias correspondentes na entidade B, porém, cada instância da entidade 
B só encontrasse uma única instância correspondente em A (vide Figura 16). Por 
exemplo, “Empresa possui Filial”. Cada empresa pode possuir zero ou mais filiais 
(ou seja, N filiais, porque o N significa 0, 1, 2 ou mais). Mas uma filial só pertence a 
uma única empresa (vide Figura 17). 
Figura 16 - Esquema de relacionamento 1:N
19
Banco de Dados
Figura 17 - Exemplo de relacionamento 1:N
» Muitos para um: é o contrário da anterior. Aqui, uma entidade em A está associada 
a, no máximo, uma entidade em B. E uma entidade em B pode estar associada 
a zero, uma ou mais entidades (N entidades) em A. É como se cada instância da 
entidade A encontrasse apenas uma instância correspondente na entidade B. Mas, 
cada instância da entidade B encontrasse zero ou mais instâncias correspondentes 
na entidade A (vide Figura 18). Por exemplo, “Aluno é orientado por Professor”. Um 
aluno só é orientado por um professor (de repente, é regra da faculdade onde ele 
estuda), mas um professor pode orientar zero ou mais alunos (N alunos), conforme 
pode ser visto na Figura 19.
Figura 18 - Esquema de relacionamento N:1
Figura 19 - Exemplo de relacionamento N:1
» Muitos para Muitos (M:N): Uma entidade em A está associada a qualquer número 
de entidades em B e uma entidade em B está associada a um número qualquer 
de entidades em A. É como se cada instância da entidade A encontrasse zero, um 
ou mais instâncias correspondentes na entidade B. E cada instância da entidade 
B encontrasse zero, uma ou mais instâncias correspondentes na entidade A (vide 
Figura 20). Por exemplo, “Aluno cursa Disciplina”, um aluno cursa zero, uma ou mais 
disciplinas e uma disciplina é cursada por zero, um ou mais alunos (vide Figura 21). 
Outro exemplo é “Médico consulta Paciente”. Um médico consulta zero, um ou mais 
Pacientes. E um Paciente é consultado por zero, um ou mais médicos (por exemplo, 
a pessoa pode ter ido a um endocrinologista e em um cardiologista), conforme 
20
Banco de Dados
pode ser visto no diagrama exemplo da Figura 22.
 
Figura 20 - Esquema de relacionamento M:N
Figura 21 - Exemplo de relacionamento M:N
Figura 22 - Outro exemplo de relacionamento M:N
O mapeamento apropriado da cardinalidade (às vezes chamada também de 
multiplicidade) de um relacionamento dependente da realidade a ser modelada. Não existe 
uma “receita de bolo”! Por exemplo, suponha o relacionamento “Empregado trabalha em 
Projeto”. Em uma determinada empresa poderia ser que só fosse permitido a um empregado 
trabalhar em um projeto por vez (Figura 23, primeira imagem). Assim o relacionameto seria 
de cardinalidade N:1, onde um empregado só trabalha em um projeto e um projeto pode 
ter N empregados (lembrando que N equivale a zero, um ou mais empregados). Porém, 
em outra empresa, poderia ser possível que um empregado trabalhe em N projetos. Dessa 
forma, o relacionamento seria de cardinalidade M:N (Figura 23, segunda imagem), onde um 
empregado poderia trabalhar em N projetos e um projeto poderia ter M empregados. Então, 
como foi dito, a definição da cardinalidade vai depender do problema sendo modelado. 
21
Banco de Dados
Figura 23 - A cardinalidade depende da realidade sendo modelada
Notação de Peter Chen para Cardinalidade
A notação de Chen faz uso de dois tipos de cardinalidade: mínima e máxima. Essas 
cardinalidades são representadas por: (cardinalidade mínima, cardinalidade máxima).
A cardinalidade mínima expressa o número mínimo de ocorrências de determinada 
entidade associada a uma ocorrência da entidade em questão através do relacionamento. 
Para fins de projeto define-se a cardinalidade mínima como 1 ou 0, onde :
» 1 = associação obrigatória (indica que o relacionamento deve obrigatoriamente 
associar uma ocorrência de entidade a cada ocorrência da outra entidade a qual se 
relaciona). Também chamada de relacionamento total.
» 0 = associação opcional (indica que o relacionamento não é obrigatório, ou seja, 
é opcional associar uma ocorrência de entidade a ocorrência da outra entidade a 
qual se relaciona). Também chamada de relacionamento parcial.
A cardinalidade máxima expressa o número máximo de ocorrências de determinada 
entidade, associada a uma ocorrência da entidade em questão, através do relacionamento. 
Para fins de projeto defini-se como 1 ou N.
Por exemplo, na Figura 24, temos o relacionamento “Empregado possui 
Dependente”. A cardinalidade (0,N) representa que um empregado pode ter 0 ou mais 
dependentes, sendo 0 (zero) a cardinalidade mínima e N a cardinalidade máxima. 
Justamente porque essa cardinalidade representa que o empregado pode não ter nenhum 
dependente, dizemos que a associação é opcional. Já a cardinalidade (1,1) representa que 
um dependente deve ter no mínimo 1 e no máximo 1 empregado ao qual está filiado. 
Aqui, como se for criado um dependente deve existir no mínimo 1 Empregado, dizemos 
que a associação é obrigatória. Não pode existir dependente sem uma associação a um 
empregado. Ou seja, uma ocorrência de empregado pode não estar associada a uma 
ocorrência de dependente ou pode estar associada a várias ocorrências dele (determinado 
empregado pode não possuir dependentes ou pode possuir vários). E uma ocorrência de 
dependente está associada a apenas uma ocorrência de empregado (cada dependente 
possui apenas um empregado responsável).
Figura 24 - Exemplo de uso da cardinalidade na notação de Peter Chen
22
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. 
Figura 25 - Exemplo de relacionamento ternário
Quando temos relacionamentos com grau maior que dois, o conceito de 
cardinalidade de relacionamento é uma extensão não trivial do conceito de cardinalidade 
em relacionamentos binários. Ou seja, não é uma tarefa muito fácil determinar a 
cardinalidade. Tínhamos antes que, em um relacionamento binário R entre duas entidades 
A e B, a cardinalidade de A em R indica quantas ocorrências de B podem estar associadas 
a cada ocorrência de A. No caso de um relacionamento ternário, a cardinalidade refere-se 
a pares de entidades e não a uma única como no relacionamento binário. Assim, em um 
relacionamento R entre três entidades A, B e C, a cardinalidade de A e B dentro de R indica 
quantas ocorrências de C podem estar associadas a um par de ocorrências de A e B. Vamos 
tentar clarear com um exemplo. 
Na figura26, a cardinalidade circulada 1 (também apontada pela seta) significa que 
cada par de ocorrências (empregado, projeto) está associado a, no máximo, um cliente. Em 
outras palavras, cada projeto onde estão alocados empregados só possui um cliente que é o 
“dono” (contratante) daquele projeto com aquela equipe de empregados. Já os outros dois N 
de cardinalidade expressam que: a um par (cliente, projeto) podem estar associados muitos 
empregados (N empregados), ou seja, o projeto do cliente pode ter diversos empregados 
alocados nele. E, finalmente, a um par (empregado, cliente) podem estar associados muitos 
projetos, ou seja, um empregado pode trabalhar para um cliente em vários projetos (N 
projetos) diferentes. Mais complicado, não é?
Figura 26 - Em relacionamentos ternários, as cardinalidades são postas aos pares
23
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
Um relacionamento não associa apenas entidades diferentes. Às vezes, é necessário 
relacionar instâncias de uma mesma entidade, ou seja, relacionar a entidade com ela 
mesma. Isso é chamado autorrelacionamento ou relacionamento recursivo. Vamos dar um 
exemplo. Suponha o relacionamento “Empregado supervisiona Empregado”, significando 
que um supervisor também é um empregado e ele supervisiona outros empregados. Nesse 
caso, não seria correto usar duas entidades Empregado diferentes, porque estamos falando 
da mesma entidade. Dessa forma, o relacionamento seria entre a entidade Empregado e 
ela mesma, através do relacionamento supervisiona (vide Figura 27). Consequentemente, 
a entidade EMPREGADO participa duas vezes do relacionamento: uma vez no papel de 
supervisor e outra no papel de supervisionado.
Figura 27 - Exemplo de autorrelacionamento
Veja que as cardinalidades são diferentes, mas apenas com as cardinalidades não 
fica claro qual se refere ao supervisor e qual se refere ao supervisionado (até daria usando 
a lógica: Um empregado supervisor supervisiona N empregados e cada empregado tem 
apenas um supervisor, mas não fica explícito no diagrama). Logo, neste caso, precisamos 
de algo mais para identificar os relacionamentos do que apenas as cardinalidades, para 
não deixar dúvidas. Esse algo mais é a definição de papéis. Papel é a função que uma 
instância de uma entidade cumpre em uma instância de um relacionamento. Na verdade, 
cada tipo de entidade que participa de um tipo de relacionamento possui um papel 
específico no relacionamento. Em autorrelacionamentos é essencial identificar os nomes 
dos papéis a fim de distinguir o significado de cada participação. Já relacionamentos entre 
entidades diferentes, em geral, não requerem a especificação de papéis. Dessa forma, o 
autorrelacionamento da Figura 27, com o uso de papéis ficaria como especificado na Figura 
28. 
Figura 28 - Autorrelacionamento usando papéis
Agora, fica mais claro que cada empregado tem apenas um único supervisor e 
um supervisor pode supervisionar N empregados (os supervisionados). Outro exemplo de 
autorrelacionamento com papéis seria o apresentado na Figura 29. Nele temos “Pessoa 
casa com Pessoa”. Nesse relacionamento é necessário especificar os papéis, no caso, marido 
24
Banco de Dados
e esposa. Supõe-se que, na nossa cultura, esse deve ser um relacionamento 1:1 J
Figura 29 - Outro exemplo de autorrelacionamento com uso de papéis
Relacionamentos com Atributos
Assim como entidades possuem atributos, relacionamentos também podem possuir 
atributos. A Figura 30 mostra um DER no qual o relacionamento ATUA possui um atributo 
chamado função. Esse atributo função vai representar a função/papel que um empregado 
exerce dentro de um projeto. E por que colocar esse atributo no relacionamento e não em 
uma das entidades?
Bem, se o atributo função ficasse na entidade EMPREGADO, o empregado, 
independente do projeto, exerceria sempre a mesma função, já que ele seria fixo da 
entidade. Logo, o atributo não poderia ficar nessa entidade, pois um empregado pode 
atuar em diversos projetos ao mesmo tempo, exercendo diferentes funções. E se o atributo 
função ficasse na entidade PROJETO, todos os empregados daquele projeto teriam a mesma 
função. Logo, o atributo função não pode ficar na entidade PROJETO já que, em um projeto, 
podem atuar diversos empregados, cada um como uma função diferente. Assim, o melhor 
lugar para este atributo é no relacionamento. Ou seja, cada vez que um empregado for 
relacionado a um projeto (momento em que a instância do relacionamento é criada), ele 
exercerá/atuará em uma função diferente.
O mesmo Empregado pode desempenhar funções diferentes em projetos diferentes
Figura 30 - Exemplo de relacionamento com atributo
Outro exemplo de atributo em relacionamento pode ser visto na Figura 30. Este 
diagrama modela vendas em uma organização comercial. Algumas vendas são à vista, outras 
a prazo. Vendas a prazo são relacionadas a uma financeira, através do relacionamento 
FINANCIA. As vendas a prazo precisam ter informações sobre a quantidade de parcelas e 
25
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 
preenchimento, ou seja, atributos nulos). Logo, a fim de explicitar o fato de os atributos 
Qtd_Parcelas e Tx_Juros pertencerem somente às vendas a prazo, preferimos colocá-los no 
relacionamento FINANCIA (vide Figura 31).
Figura 31 - Outro exemplo de relacionamento com atributos
Relacionamento Identificador
Há casos em que o identificador de uma entidade é composto não somente por 
atributos da própria entidade, mas, também, por relacionamentos dos quais a entidade 
participa (relacionamento identificador). Um exemplo deste caso é mostrado na Figura 32. 
Na figura, o cliente possui dependente. Cada dependente está relacionado a exatamente um 
cliente. Um dependente é identificado pelo CPF do cliente ao qual ele está relacionado e por 
um número sequencial que o distingue dos diferentes dependentes que um mesmo cliente 
possa ter. Veja que, na Figura 32, o relacionamento usado como identificador é indicado 
por um losango com linhas duplas e a entidade que é dependente de outra (entidade fraca) 
também é representada com linhas duplas.
Figura 32 - Entidade Fraca
Nesse caso, alguns autores dizem que a entidade DEPENDENTE é uma entidade 
fraca. O termo “fraca” deriva-se do fato de a entidade somente existir quando relacionada 
a outra entidade (denominada entidade forte3), que, no caso, é a entidade CLIENTE e de 
usar como parte de seu identificador o identificador da entidade forte. Na verdade, o 
Saiba Mais
2 Atributos 
opcionais não tem 
obrigatoriedade de 
prenchimento.
Saiba Mais
3 Entidade forte é 
aquela que possui 
o seu próprio 
identificador e não 
depende de nenhuma 
outra entidade para 
isso.
26
Banco de Dados
identificador da entidade fraca é composto pelo identificador da entidade forte a qual a 
existência dela está associada mais algum atributo (geralmente um sequencial) da própria 
entidade fraca. O relacionamento que associa a entidade fraca a seu proprietário (a entidade 
forte) é, justamente, o relacionamento identificador (no caso da Figura 32, o relacionamento 
POSSUI).
Atenção
O termo Entidade Fraca deve ser usado com cautela, pois uma entidade fraca em um 
relacionamento não necessariamente é também fraca em outro relacionamento.
Extensões do Modelo Entidade-Relacionamento
Apesar de ser possívelmodelar a maioria dos bancos de dados apenas com os 
conceitos básicos do E-R, alguns aspectos de um banco de dados podem ser expressos de 
modo mais conveniente por meio de algumas extensões do modelo ER. Vamos descrever 
melhor essas extensões, a seguir.
Especialização/Agregação
Um conjunto de entidades pode conter subgrupos de entidades que são, de alguma 
forma, diferentes de outras entidades do conjunto. Esta diferença pode estar caracterizada 
por um subgrupo possuir atributos que não são compartilhados pelas demais entidades do 
conjunto. A especialização permite atribuir propriedades particulares a um subconjunto de 
entidades especializadas através da herança de propriedades (atributos) de uma entidade 
mais genérica. 
A especialização no diagrama é representada pelo triângulo. Alguns autores 
utilizam um triângulo rotulado de ISA (de “is a” em inglês, ou seja, “ é um(a)”). Por exemplo, 
na Figura 33 temos uma entidade genérica CLIENTE e duas entidades que derivam dessa 
entidade genérica, as entidades especializadas: P. FÍSICA e P. JURÍDICA. Qual a vantagem 
disso? P.FISICA e P.JURIDICA irão ter todos os atributos que a entidade CLIENTE possuir, 
mas podem ter atributos adicionais, diferentes entre elas. Elas são casos especializados da 
entidade CLIENTE.
Figura 33 - Exemplo de Especialização/Generalização
27
Banco de Dados
O refinamento do conjunto de entidades em níveis sucessivos de subgrupos indica 
um processo top-down (de cima para baixo) de projeto. É esse processo que é feito pela 
especialização. O projeto pode ser realizado, também, de modo bottom-up (de baixo para 
cima), na qual vários conjuntos de entidades são sintetizados em uma entidade de alto nível, 
com base em atributos comuns. Esse é o processo de generalização. Assim, na prática, a 
generalização é simplesmente o inverso da especialização e, para efeito de representação, 
usa-se a mesma simbologia (um triângulo). Só que o sentido da criação é invertido. 
Na generalização, a entidade genérica é criada a partir dos atributos que as entidades 
especializadas tenham em comum. No exemplo da Figura 33, seria como se a gente olhasse 
para as entidades P.FISICA e P.JURÍDICA e extraísse dessas entidades os atributos que elas 
tivessem em comum e, a partir disso, criasse a entidade genérica CLIENTE.
A generalização/especialização pode ser classificada em dois tipos, total ou parcial, 
de acordo com a obrigatoriedade ou não de a uma ocorrência da entidade genérica 
corresponder a uma ocorrência da entidade especializada.
Em uma generalização/especialização total para cada ocorrência da entidade 
genérica existe sempre uma ocorrência em uma das entidades especializadas. Por exemplo, 
na Figura 34, toda ocorrência da entidade CLIENTE corresponde uma ocorrência em uma 
das duas especializações (P.FISICA ou P.JURÍDICA). Esse tipo de generalização/especialização 
é simbolizado por um “t”, ao lado do triângulo.
Figura 34 - Exemplo de generalização/especialização total
Em uma generalização/especialização parcial, nem toda ocorrência da entidade 
genérica possui uma ocorrência correspondente em uma entidade especializada. 
Por exemplo, na Figura 35, nem toda entidade FUNCIONÁRIO possui uma entidade 
correspondente em uma das duas especializações (ou seja, nem todo funcionário é CHEFE 
ou DIRETOR). Esse tipo de generalização/especialização é simbolizado por um “p” ao lado 
do triângulo.
Figura 35 - Exemplo de generalização/especialização parcial
28
Banco de Dados
Geralmente, quando há uma especialização parcial, na entidade genérica (no caso 
do exemplo, em FUNCIONÁRIO) aparece um atributo que identifica o tipo de ocorrência 
da entidade genérica (no caso do exemplo, trata-se do atributo Tp_Func). Este atributo 
não é necessário no caso de especializações totais, já que a presença da ocorrência 
correspondente à entidade genérica em uma de suas especializações é suficiente para 
identificar o tipo da entidade.
Herança de Atributos
É uma propriedade decisiva das entidades de níveis superior e inferior criadas pela 
especialização e pela generalização. Através dela, nos relacionamentos de generalização 
e especialização, as entidades de nível inferior herdam os atributos e os relacionamentos 
das entidades de nível superior. Como já comentado sobre a Figura 33, as entidades 
especializadas P. FISICA e P.JURIDICA herdam todos os atributos e relacionamentos 
da entidade genérica CLIENTE, podendo ter, adicionalmente, mais algum atributo ou 
relacionamento próprio.
Entidade Associativa (ou Agregação)
Uma limitação do modelo E-R é que não é possível expressar relacionamento 
entre relacionamentos. Logo a entidade associativa ou agregação é usada para substituir 
a associação entre relacionamentos (ou seja, ela ajuda a representar um relacionamento 
entre relacionamentos), uma vez que faz o relacionamento passar a ser tratado como 
uma entidade. As notações possíveis podem ser vistas na Figura 36. Como visto na 
figura o relacionamento completo (relacionamento + entidades envolvidas) ou apenas o 
relacionamento em si é contornado por um retângulo, para representar a agregação.
Figura 36 - Representação Gráfica da Agregação
Vamos dar um exemplo. Suponha o relacionamento “Médico consulta Paciente” 
(vide Figura 37). Suponha, também, que seja necessário modificar este diagrama com 
a adição da informação de que, em cada consulta, um ou mais medicamentos podem 
ser prescritos ao paciente. Para tanto, dever-se-ia criar uma nova entidade chamada 
29
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.
Figura 37 - Exemplo de agregação
Caso não se deseje usar o conceito de entidade associativa, é possível transformar 
o relacionamento em entidade, a qual pode ser relacionada com as demais entidades. 
Por exemplo, na Figura 38, o relacionamento CONSULTA foi substituído por uma entidade 
de mesmo nome, que vai se relacionar com as entidades MEDICO e PACIENTE através 
de relacionamentos (cada consulta tem um médico e um paciente envolvidos). Devido a 
essa transformação é possível relacionar a entidade CONSULTA com a nova entidade 
MEDICAMENTO, sem problemas.
30
Banco de Dados
Figura 38 – Forma alternativa ao uso de entidade associativa
Ferramentas para Modelagem de Dados
Para desenhar o DER e até dar apoio a fases posteriores do projeto de banco 
de dados, como a conversão do MER para o modelo relacional (assunto do próximo 
capítulo deste fascículo), existem diversas ferramentas de modelagem de dados. Aqui 
apresentaremos quatro delas, sendo duas ferramentas gratuitas e duas ferramentas pagas 
(estas duas últimas consideradas as melhores pelas pessoas da área de BD). Entre as que 
vamos apresentar,a primeira delas, BR-Modelo é a mais simples e a que vamos adotar para 
uso no nosso curso. Vamos conhecer essas ferramentas?
BR-MODELO
Ela é uma ferramenta freeware voltada para ensino de modelagem em banco de 
dados relacional, com base na notação de Peter Chen e no livro de autoria do Professor 
Carlos A. Heuser chamado “Projeto de Bando de Dados”, livro este que merece ser lido por 
você. Esta ferramenta foi desenvolvida por Carlos Henrique Cândido sob a orientação do 
Prof. Dr. Ronaldo dos Santos Mello (UFSC), como trabalho de conclusão do curso de pós-
graduação em banco de dados (UNVAG - MT e UFSC). Atualmente, está na versão 2.0 e 
possui o seu código-fonte disponibilizado para quem desejar modificar a ferramenta (vide 
site http://sis4.com/brModelo/ ). A ferramenta é simples de usar e possui uma interface 
amigável (vide Figura 39) e toda a notação usada é a notação do livro de Heuser.
31
Banco de Dados
Figura 39 - Tela do BR-Modelo
O software funciona como um editor gráfico e possui duas funcionalidades básicas:
» Construção do modelo de entidade e relacionamento e
» Mapeamento para o modelo relacional de banco de dados.
A ferramenta dá suporte para criação de elementos do MER estendido.
Maiores detalhes sobre a ferramenta e a monografia que a originou estão 
em: http://chcandido.tripod.com/ 
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.
Figura 40 - Interface do DBDesigner
32
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
Esta é a ferramenta mais utilizada no mercado, conforme informado no site do 
fabricante (http://erwin.com/). Através desta ferramenta, o desenvolvedor de um sistema 
de informação pode especificar os dados envolvidos, as suas relações e os requisitos de 
análise. A ferramenta permite desde a criação e manutenção da bases de dados, até o uso 
de mecanismos de sincronização de dados necessários. Além disso, oferece recursos para 
realizar o processo inverso (Engenharia reversa4). O ERwin gera modelos para todos os 
principais bancos de dados atuais e pode ser integrado para ajudar no gerenciamento dos 
mesmos (para atualização das bases de dados).
A notação utilizada pelo ERwin não descende da notação original de Peter Chen, ela 
implementa diagramas parecidos com os utilizados na Engenharia de Software. A interface 
da ferramenta pode ser visualizada na Figura 41.
Figura 41 - Interface do Erwin
Sybase – PowerDesigner
É considerada juntamente com o Erwin, uma das ferramentas mais utilizadas 
e completas do mercado. Ela gera modelo conceitual, converte para modelo lógico 
(automaticamente, sem intervenção do usuário) e trabalha com todos os principais bancos 
de dados disponíveis empregando inclusive, técnicas de engenharia reversa e de integridade 
referencial. Apesar de ser uma ferramenta paga, ela tem uma versão demo disponível 
para avaliação por 15 dias no site: http://www.sybase.com.br/products/modelingdevelopment/
powerdesigner ou http://www.sybase.com. A interface da ferramenta pode ser visualizada na 
Figura 42.
Saiba Mais
4 Através da 
Engenharia Reversa é 
possível obter a partir 
do banco de dados 
criado, os diagramas 
que o geraram.
33
Banco de Dados
Figura 42 - Interface do Powerdesigner
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
Neste capítulo o foco foi modelagem de dados. Principalmente, a modelagem 
conceitual. Para tanto, focamos na descrição dos elementos componentes do modelo 
entidade-relacionamento. Para obter mais informações ou materiais diversificados para 
o que foi visto aqui, você pode proceder a uma pesquisa usando o Google (www.google.
com.br) com as palavras chaves “Modelagem Conceitual” + “Banco de Dados” ou “Modelo 
Entidade-Relacionamento” ou ainda “Diagrama Entidade-Relacionamento”. Você vai ver 
que irá vir muito material. Entre eles: apostilas, notas de aula, reportagens, etc. 
Adicionalmente, você não pode deixar de consultar o 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
Também qualquer outro livro de Banco de Dados terá, ao menos, um capítulo 
dedicado a modelagem conceitual. Entre esses, podemos citar:
 SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de 
dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.
34
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://blog.cidandrade.pro.br/educacao/video-aula-do-brmodelo/ Modelagem e projeto 
de banco de dados com o DBDesigner (Por Willian Bolzan) – partes 1 e 2
 http://www.devmedia.com.br/articles/viewcomp.asp?comp=7773
 http://www.devmedia.com.br/articles/viewcomp.asp?comp=7776
Você Sabia? 
Além de definir a cardinalidade de relacionamento, alguns autores definem também 
cardinalidade para atributos. E o que é isso? É definir o número mínimo e máximo de vezes 
que aquele atributo pode aparecer. Veja só: 
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.
35
Banco de Dados
Figura 43 - Exemplo de Cardinalidade em Atributos
Apesar de não ser muito utilizada a cardinalidade de atributos, é útil conhecê-la.
Aprenda Praticando
Vamos dar uma olhada novamente em questões de concurso?
Adaptado de CESPE - 2008 - STF - Analista Judiciário - Tecnologia da Informação, 
CESPE - 2004 - TRE-AL - Analista Judiciário - Especialidade - Análise de Sistemas - 
Desenvolvimento e CESPE - 2004 - Polícia Federal - Perito Criminal Federal - Informática
1) O armazenamento e a recuperação de grandes quantidades de dados é um trabalho 
importante e muito explorado em um sistema gerenciador de banco de dados 
(SGBD). Com relação aos conceitos que envolvem esse sistema, julgue os itens que 
se seguem com C = certo ou E = Errado. 
a) ( ) Dado um conjunto de relacionamentos R binário entre os conjuntos de 
entidades A e B, é correto afirmar que, em um mapeamento de cardinalidade 
muitos para muitos, uma entidade A está associada a qualquer número de 
entidades em B e uma entidade em B está associada a um número qualquer de 
entidades em A. 
b) ( ) As características do atributo CEP - numérico, sequencial e não repetido - 
permitem utilizá-lo como identificador da entidade CLIENTE em um banco de 
dados destinado ao cadastro de clientes de uma loja.
c) ( ) O modelo entidade-relacionamento permite a utilização de atributos cujo 
valor é derivado de outros atributos.
d) ( ) O domínio de um atributo consiste no conjunto de entidades em que tal 
atributo é utilizado.
e) ( ) O diagrama ER a seguir ilustra um modelo ER. Nesse diagrama, os retângulos 
representam entidades, o triângulo representa o conceito de generalização/
especialização e o losango representa um relacionamento entre entidades.
36
Banco de Dados
Adaptado de TER-RN-FCC – 2005 Analista Judiciário/Analista de Sistemas
2) Em um MER, consideremos A uma entidade e K um autorrelacionamento de A. 
Se A representa o conjunto de cidadãos de um país, onde a poligamia é ilegal e K 
representa o relaciomaneto CASAMENTO entre cidadãos deste país, podemos dizer 
que K é um relacionamento que se enquadraria no tipo geral:
a) um para um
b) um para muitos
c) muitos para um
d) muitos para muitos
e) zero para zero
CESGRANRIO - 2006 - EPE - Técnico de Nível Superior - Área Tecnologia da 
Informação 
3) Considere o DER a seguir. Depois, responda: quantas entidades fracas e quantas 
entidades fortes, respectivamente, estão presentes neste diagrama?
a) 0 e 1 
b) 0 e 2 
c) 1 e 1 
d) 1 e 2 
e) 2 e 1
37
Banco de Dados
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):
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
5) Considere o seguinte enunciado: Uma empresa de geração de energia deseja 
armazenar um conjunto de dados importantes sobre os tipos de energia com que 
trabalha e os seus campos de geração. Assume-se que: cada campo de geração de 
energia é de um, e somente um, tipo de energia; pode existir mais de um campo 
de geração para cada tipo de energia; podem ser previstos alguns tipos de energia 
para os quais ainda não existem campos de geração.
Qual diagrama de entidade relacionamento é adequado para modelar o problema?
 
 
 
 
38
Banco de Dados
 
CESGRANRIO - 2007 - TEC - RO - Analista de Informação
6) Considere o DER (Diagrama Entidade-Relacionamento) abaixo. 
É incorreto afirmar que:
a) “idade” é um atributo derivado. 
b) “empréstimo” possui 2 (dois) atributos. 
c) “telefone” é uma entidade fraca. 
d) “codcliente” é atributo de “cliente”. 
e) “codempréstimo” é identificador da entidade. 
Respostas:
1) a) C – o relacionamento M:N é um relacionamento muitos para muitos e nesse 
caso, ambas as entidades podem estar relacionadas com qualquer quantidade de 
instâncias de entidades do outro tipo.
 b) E - o CEP não poderia ser o identificador da entidade cliente. Primeiro, porque 
não caracteriza um cliente unicamente, mas sim um endereço. Segundo, porque 
pessoas que morassem na mesma rua, teriam o mesmo CEP.
 c) C – atributo derivado existe no contexto do MER e é gerado a partir do valor de 
outro(s) atributo(s) do modelo.
 d) E – Domínio do atributo é o conjunto de valores permitidos para cada atributo, 
ou seja, é a definição do tipo do atributo
 e) C – a simbologia para o DER está toda ok.
2) letra A – se no país é proibida a poligamia, o relacionamento de casamento deve ser 
de 1:1 (um para um)
3) letra D – no diagrama existe apenas uma entidade fraca (Item) e duas entidades 
fortes (Nota e PV)
4) letra E – as três afirmações são verdadeiras.
5) letra D – com as afirmações feitas, vemos que CampoGeracao deve ter 1 e apenas 1 
39
Banco de Dados
tipo de energia. E o tipo de energia pode ter 0 ou mais campos de geração.
6) letra C – esta é a incorreta porque telefone não é entidade fraca, é atributo 
multivalorado (que pode assumir mais de um valor). Atributo multivalorado é 
representado por elipses duplas (uma dentro da outra).
Atividades e Orientações de Estudo
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
Responda as questões a seguir em um documento de texto (doc) e poste as respostas 
no ambiente virtual, no local indicado. Esse trabalho deve ser feito individualmente. Para 
desenhar os diagramas que forem solicitados, você já pode praticar o uso da ferramenta BR-
Modelo, fazendo os diagramas nessa ferramenta. Depois, é só copiar e colar os diagramas 
criados no documento com as respostas. Ou você pode utilizar os próprios recursos do 
word para desenhar os trechos de diagrama. Essa atividade é individual e fará parte da sua 
avaliação somativa.
1) Através de exemplos de Diagramas ER, ilustre os conceitos a seguir do modelo ER 
(não precisa ser em um único diagrama, pode ser em diagrama separados, um para 
cada letra a seguir):
a) Relacionamento
b) Entidade fraca
c) Autorrelacionamento
d) 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úmerode horas alocadas para 
um empregado para trabalhar num projeto, e mostre como isto pode ser 
representado no diagrama.
b) Escolha identificadores para cada uma das entidades.
c) Fazendo as 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.
40
Banco de Dados
Atividades de Reflexão
Para você já ir se preparando para desenhar diversos DERs de níveis de dificuldade 
diferentes, o que veremos várias dicas de como fazer isso no próximo capítulo, lançamos 
aqui um desafio: será que você seria capaz de criar um diagrama E-R para um problema 
hospitalar? Esse diagrama é simples. A ideia é que você pense no diagrama por partes e 
depois vá juntando as coisas até formar o diagrama completo. Para facilitar, a descrição do 
problema está dividida em parágrafos. Tente ir analisando eles um a um e depois você pode 
juntar o problema como um todo. Vamos à descrição do problema? De preferência, procure 
desenhar a resposta usando a ferramenta BR-Modelo, para poder ir praticando.
Hospitais são formados por um ou mais ambulatórios e cada um destes está em um único hospital
Médicos clinicam em um único hospital, cada hospital possui vários médicos
Hospitais solicitam exames clínicos em vários laboratórios, cada laboratório pode ter solicitações 
de vários hospitais
Pacientes consultam vários médicos e estes atendem a consulta de vários pacientes
Quando é consultado o paciente recebe um diagnóstico. O paciente pode ter um diagnóstico 
diferente a cada consulta.
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.
Pacientes realizam vários testes e cada teste é realizado por um paciente
Laboratórios fazem vários testes e cada um dos testes é feito em um único laboratório
Sua resposta deve ser postada no ambiente virtual, no local apropriado, em um 
documento de texto (você também pode postar o diagrama gerado pelo BR-Modelo 
diretamente (arquivo gerado por ele). Essa atividade é individual.
41
Banco de Dados
Minibiografia
Edgar Frank Codd 
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?
Você estudou, neste capítulo, os conceitos de modelo de dados e viu alguns 
dos modelos existentes: O modelo conceitual (que não tem dependência do SGBD a ser 
escolhido), o modelo lógico (que já tem uma certa dependência do SGBD escolhido) e o 
modelo físico que tem completa dependência do SGBD escolhido. 
Depois, foi estudado mais a fundo o modelo conceitual, através da apresentação 
dos principais componentes do modelo entidade relacionamento, um dos principais 
diagramas do projeto de banco de dados. Entre os componentes estudados a simbologia 
dos principais deles pode ser vista no Quadro 1. Além dos símbolos, quando pensamos no 
MER estendido, temos ainda a simbologia apropriada para especialização/generalização 
(um triângulo) e entidade associativa.
No próximo capítulo veremos as dicas e informações necessárias para unir os 
componentes estudados nesse capítulo a fim de montar diversos diagramas entidade-
relacionamento de níveis de complexidade diferentes. Até lá!
42
Banco de Dados
Quadro 1 - Alguns dos Componentes do MER
43
Banco de Dados
Capítulo 5
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar os seguintes temas:
» Como desenhar o DER.
» Dicas para desenhar bons diagramas.
» Formas de Modelar o MER.
Metas
Após o estudo deste capítulo, esperamos que você consiga:
» Realizar a modelagem de dados usando o Modelo Entidade Relacionamento (MER).
» Utilizar uma ferramenta de modelagem de dados para desenhar o diagrama 
entidade-relacionamento.
» Praticar a criação de diagramas entidade-relacionamento.
44
Banco de Dados
Capítulo 5 – Desenhando o MER
Vamos conversar sobre o assunto?
“Vimos no capítulo anterior os componentes necessários para desenhar o MER, 
que é um dos principais modelos do projeto de banco de dados e faz parte da modelagem 
conceitual (que é independente do SGBD escolhido para implementar o BD). Porém, apesar 
das explicações sobre os componentes darem ideia de como os mesmos se relacionam, 
ainda faltaram dicas, informações adicionais para proporcionar a criação de diagramas mais 
complexos. É justamente isso que faremos nesse capítulo, cujo foco é lhe ajudar a fazer a 
modelagem conceitual de diversos tipos de problemas. ”
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á?
Peculiaridades dos Modelos ER
Vamos falar aqui de algumas peculiaridades do MER.
O modelo entidade-relacionamento é um modelo formal, preciso e não ambíguo. 
Logo, diferentes leitores de um mesmo modelo ER devem sempre entender exatamente 
a mesma coisa. Para isso, é importante que todos os envolvidos estejam treinados para 
perfeita compreensão do modelo ER, caso contrário, o mesmo pode ser sub-utilizado e/ou 
gerar implementações incoerentes com a realidade.
Ainda assim, o MER tem poder de expressão limitado, pois este apresenta apenas 
algumas propriedades de um BD. Isto porque sua notação gráfica é pouco poderosa, 
fazendo com que propriedades adicionais devam ser anotadas à parte. Além disso, o MER 
é inadequado para expressar restrições de integridade (regras de negócio). Vamos dar um 
exemplo dessa limitação, a seguir.
Por exemplo, suponha o autorrelacionamento “Pessoa casa com Pessoa” expresso 
na Figura 44. Temos que uma pessoa casa com apenas outra pessoa. E no relacionamento, 
uma faz o papel de marido e o outro de esposa. Até aí tudo bem, não é? Já vimos essa 
explicação para o autorrelacionamento. O problema é que o modelo não deixa explícita a 
restrição que uma pessoa sópode fazer parte de um único relacionamento, ou seja, só pode 
existir um relacionamento de casamento por vez. Como assim? Sem essa restrição, uma 
pessoa pode estar envolvida em mais de um relacionamento do tipo “casa”. Por exemplo, 
suponha que exista um relacionamento entre a pessoa p1 e a pessoa p3 (p1 é casada com 
p3). Pelo diagrama, nada impede que também exista um relacionamento entre p3 e p6 (p3 
é casada também com p6) e outro relacionamento entre p6 e p8 (p6 é também casada com 
p8). Assim como, só pelo diagrama, nada impede que uma pessoa possa ser casada com ela 
mesma, por exemplo, p5 ser casada com p5 (vide Figura 45), o que viola completamente a 
realidade.
45
Banco de Dados
Figura 44 - Autorrelacionamento Pessoa Casa Pessoa
Figura 45 - Sem restrições de integridade expressas no diagrama, podem haver relacionamentos 
inconsistentes
Vamos dar outro exemplo dessa violação. Suponha o autorrelacionamento 
“Empregado supervisiona Empregado” (vide Figura 46). Só pelo diagrama não seria possível 
restringir que um subalterno supervisionasse seu superior. Assim, podeira ocorrer de um 
empregado E1 supervisonar um empregado E3, esse mesmo empregado E3 supervisonar 
o empregado E5 e esse empregado E5 supervisionar o empregado E1 (vide Figura 47). 
Isso violaria a integridade do relacionamento, porque como o mais subalterno poderia 
supervisionar o superior de todos? Esses são alguns exemplos de restrições que não são 
representadas no MER.
Figura 46 - Autorrelacionamento “Empregado supervisiona Empregado”
46
Banco de Dados
Figura 47 - Outro exemplo de relacionamentos sem checagem de restrições
Diferentes modelos ER podem ser equivalentes. Modelos equivalentes expressam 
a mesma abstração da realidade (formas diferentes de modelar, mas que possuem o 
mesmo significado). Para fins de projeto de BD, dois modelos ER são equivalentes se geram 
o mesmo esquema lógico de BD (vamos estudar sobre isso no próximo capítulo). Vamos 
dar um exemplo. Suponha o enunciado “Em uma clínica, um médico pode consultar zero 
ou mais pacientes. E um paciente pode ser consultado por um ou mais médicos. Deve ser 
mantido um histórico das consultas feitas pelo paciente, armazenando a data e hora em que 
a consulta ocorreu. Mesmo porque o mesmo paciente pode se consultar várias vezes com 
o mesmo médico.” Esse enunciado poderia ser modelado de duas formas: com a consulta 
sendo um relacionamento (vide Figura 48) e com a consulta sendo uma entidade (vide 
Figura 49). Em ambos os modelos a realidade estaria correta e bem modelada, apesar dos 
modelos serem diferentes, pois existe uma equivalência entre eles.
Figura 48 - Consulta modelada como um relacionamento
Figura 49 - Consulta modelada como uma entidade
47
Banco de Dados
Transformação de Relacionamento n:n em Entidade
Há variantes da abordagem ER, que ou excluem completamente o uso de relacionamentos n:n, ou 
excluem apenas os relacionamentos n:n que têm atributos.
Para transformar um relacionamento n:n em uma entidade, você deve representar o relacionamento 
como uma nova entidade e relacionar essa nova entidade criada às entidades que originalmente 
participavam do relacionamento. Por exemplo, na Figura 49, a entidade CONSULTA foi originada 
do relacionamento CONSULTA da Figura 48. E essa nova entidade é relacionada às entidades 
anteriormente existentes (MEDICO e PACIENTE). 
A nova entidade criada terá como identificador os identificadores das entidades que originalmente 
participavam do relacionamento e os atributos que eram identificadores do relacionamento 
original (caso esse tivesse atributos identificadores). Com isso na Figura 49, veja que o atributo 
data/hora continua sendo atributo identificador. 
E quanto à cardinalidade? Nos relacionamentos em que participa a cardinalidade da entidade 
criada é sempre (1,1). Ou seja, do lado de MEDICO e PACIENTE, a cardinalidade continua fica (1,1). 
Já as cardinalidades das entidades que eram originalmente associadas pelo relacionamento são 
transcritas ao novo modelo. Ou seja, as cardinalidades previamente existentes ficam perto da nova 
entidade criada. Assim, no exemplo, um médico realiza 0 ou mais consultas e um paciente participa 
de uma ou mais consultas (para ser paciente ele tem de ter participado ao menos de uma).
Um modelo ER pode ser usado como entrada a uma ferramenta CASE5. Ou seja, a 
partir do desenho do MER feito em uma ferramenta CASE, pode-se gerar o modelo lógico e 
posteriormente, o modelo físico do BD (ou, pelo menos, os scripts para fazer isso). 
Critérios para Construção do Modelo ER
Para iniciar a construção do MER, geralmente, algumas dúvidas surgem, tais como: 
qual elemento (entidade, atributo, relacionamento,...) da linguagem ER é o mais apropriado 
para representar uma específica abstração da realidade? Para responder essa pergunta não 
se deve observar um objeto isoladamente. Deve-se procurar observar o contexto dentro do 
qual o objeto aparece, assim, você terá uma ideia melhor de como representá-lo. Além disso, 
o próprio desenvolvimento do modelo e o aprendizado sobre a realidade irão refinando e 
aperfeiçoando o modelo, no decorrer do tempo. Por isso, lembre-se a representação de um 
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. 
Representar como Atributo ou como Entidade?
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).
Saiba Mais
5 Ferramentas 
CASE (do inglês 
Computer-Aided 
Software Engineering) 
são ferramentas 
automatizadas 
que tem como 
objetivo auxiliar o 
desenvolvedor de 
sistemas em uma ou 
várias etapas do ciclo 
de desenvolvimento 
de software. No caso, 
ajudar no projeto e 
criação do banco de 
dados.
48
Banco de Dados
Figura 50 - Cor como atributo ou como entidade?
Para ajudar a decidir, vamos estabelecer alguns critérios:
» Se o elemento estiver vinculado a outros elementos, o elemento deverá ser 
representado como Entidade. Vamos dar exemplos de vínculo. Suponha que você 
precise saber o fabricante da cor do automóvel, a cor precisaria se relacionar com 
outra entidade chamada Fabricante, logo, ela teria de ser representada como uma 
entidade. Se você precisasse saber o código da cor ou em que período a cor está 
disponível para venda, você precisaria que a cor fosse representada como uma 
entidade que teria esses atributos (código e periodoDisponibilidade).
» Caso você não precisasse saber nenhuma informação adicional sobre o elemento, 
ele deve ser representado como Atributo. Por exemplo, se você realmente só quer 
saber a cor do automóvel e nada mais, a cor é um atributo da entidade automóvel.
Representar como Atributo ou como Generalização/Especialização?
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).
Figura 51 - Representar como atributo ou como generalização/especialização
Para ajudar a decidir, o critério é semelhante ao anterior:
» Se sabe-se que o elemento a ser especializado possui propriedades particulares 
ou vai precisar se relacionar com outros elementos, você deve representá-lo 
como Entidade. Por exemplo, qual o CREA dos empregados que tem categoria 
funcional Engenheiro? Logo, precisaria haver uma especialização de EMPREGADOchamada ENGENHEIRO e esta entidade teria o atributo CREA. Outro exemplo, é 
que, talvez, pela modelagem da sua empresa, você precisasse saber o número da 
carteira de motorista e a data da expiração da mesma para aqueles empregado que 
exercessem o cargo de MOTORISTA. Nesse caso também, motorista deveria ser uma 
49
Banco de Dados
especialização da entidade EMPREGADO. Deveria ser uma especialização porque 
você não precisaria saber a carteira de motorista ou a expiração dela no caso de 
qualquer outra categoria funcional (para que saber esses dados de um engenheiro, 
por exemplo?).
» Caso você não precisasse saber nenhuma informação adicional sobre o elemento, 
nem ele vai se relacionar com nenhuma outra entidade, ele deve ser representado 
como Atributo.
Essa é uma forma de evitar atributos opcionais. Porque, no geral, atributos 
opcionais indicam subconjuntos de entidades que são modelados mais corretamente 
através de especializações. Por exemplo, sem o uso de especialização, para saber o CRM 
do empregado se ele for um médico, o CREA do empregado se ele for um engenheiro ou os 
dados da carteira de motorista se ele for um motorista, teríamos vários atributos opcionais 
na mesma entidade. Adicionalmente, ainda seria necessário um classificador, que no caso é 
o atributo tipo do empregado (vide Figura 52). Assim, dependendo do tipo do empregado, 
esse ou aquele atributo seria preenchido (atributos opcionais). 
Um problema com esse modelo, fora deixar vários atributos em branco por vez, é 
que o modelo não vai expressar as combinações de preenchimento permitidas ou não (por 
exemplo, preenchendo o CRM eu não devo preencher o CREA). Assim, para ficar mais claro o 
preenchimento e para evitar atributos opcionais, é interessante fazer uso da generalização/
especialização. No caso do exemplo, seriam criadas as especializações MOTORISTA, MEDICO 
e ENGENHEIRO (vide Figura 53).
Figura 52 - Uso de atributos opcionais e classificador
50
Banco de Dados
Figura 53 - Uso de Generalização/Especialização
Evitando Atributos Multivalorados
A implementação direta de um atributo multivalorado é uma limitação dos SGDBs 
relacionais6 (não é possível de ser feita diretamente). Assim, é possível representar os 
atributos multivalorados como entidades. E como decidir como fazer isso? Caso o atributo 
tenha algum vínculo com outros elementos, ele deve ser representado como entidade. Caso 
contrário, como atributo. Vamos ao exemplo. Suponha uma entidade EMPREGADO que 
possua os atributos multivalorados lançamento do pagamento e dependente (vide Figura 
54). Se for importante guardar informações sobre os dependentes (por exemplo, a data de 
nascimento e o nome), esse atributo multivalorado deverá ser representado como entidade. 
Se precisarmos saber o valor do lançamento do pagamento e de que tipo foi o lançamento, 
esse também deverá ser representado como uma entidade (vide Figura 55). Agora, em alguns 
casos, o atributo não vai ter nenhum vínculo com nenhum outro elemento. Logo, ele pode 
continuar sendo representado como atributo multivalorado e ser tratado posteriormente. 
Por exemplo, o número do telefone de uma pessoa é um atributo multivalorado que não 
tem relação com nenhum outro elemento, logo pode ser representado dessa forma (vide 
Figura 56).
Figura 54 - Entidade com atributos multivalorados
Saiba Mais
6 Essa limitação não 
existe nos SGBDR-O 
(Objeto-Relacional) ou 
SGBDOO (Orientado a 
Objetos).
51
Banco de Dados
Figura 55 - Atributos multivalorados representados como entidades
Figura 56 - Entidade com atributo multivalorado telefone
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. 
1. Leia o problema (minimundo traçado) várias vezes, para compreendê-lo. Depois, 
faça uma leitura tentando identificar entidades, relacionamentos e atributos. Há 
alguma dica para isso? Há sim. Geralmente, dado um texto descrevendo o banco 
de dados a ser projetado: a presença de um substantivo usualmente indica uma 
entidade (ex: nota fiscal, pessoa, empregado, livro, etc). A presença de um verbo é 
uma forte indicação de um relacionamento (ex: consultar, contratar, supervisionar, 
etc). Um adjetivo, um complemento ou uma característica de um substantivo 
(entidade) é uma forte indicação de um atributo (ex: nome, valor, preço, cor, 
número, etc). Isto não é regra, pois existem relacionamentos que não são bem 
expressos por verbos. Quando isto ocorrer, em geral, une-se os nomes das entidades 
52
Banco de Dados
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ó aparecem 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 aumentono 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.
53
Banco de Dados
Verificação do Modelo Criado
Uma vez construído, um modelo ER deve ser validado e verificado. A verificação é o 
controle de qualidade para garantir um bom modelo. Um bom modelo ER deve:
» 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:
» Erros sintáticos - ocorrem quando os conceitos de modelagem ER não são 
corretamente empregados, ou seja, há erros na construção do modelo. Por exemplo, 
associar dois relacionamentos (vide Figura 57 – os relacionamentos PRESCREVE 
e CONSULTA estão associados, o que seria um erro, nestes casos deveria ter sido 
usada uma entidade associativa) ou fazer um relacionamento entre uma entidade e 
apenas um atributo de outra entidade.
Figura 57 - Exemplo de erro sintático (associação entre relacionamentos)
» Erros Semânticos – ocorrem quando o modelo não retrata a realidade de forma 
consistente. Eles são mais difíceis de verificar do que os erros sintáticos. Vamos dar 
alguns exemplos de erros semânticos. 
a) Estabelecer associações incorretas ou colocar atributos em locais que não 
atendam os requisitos que foram levantados com os usuários. Suponha que 
você deseje modelar o seguinte problema “Uma pessoa pode possuir zero ou mais 
imóveis e um imóvel pode pertencer a um ou mais pessoas. É importante armazenar 
há quanto tempo cada pessoa possui o seu imóvel, lembrando que os imóveis 
podem ser vendidos e mudar de proprietário”. Um erro semântico seria colocar o 
tempo de posse na entidade imóvel (vide Figura 58). Se o problema fosse modelado 
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. 
54
Banco de Dados
Dessa forma, a cada novo dono, o tempo de posse seria diferente.
Figura 58 - Exemplo de Erro Semântico - Atributo no lugar errado
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.
Figura 59 - Exemplo de Erro Semântico 
Elemento representado ora como entidade, ora como atributo
55
Banco de Dados
c) Usar o número incorreto de entidades em um relacionamento ou posicionar 
uma entidade no local errado. Geralmente, esse erro ocorre quando o problema 
não foi bem compreendido. Por exemplo, suponha que você quer modelar uma 
locadora de DVDs. Na locadora existe, de cada filme, 1 ou mais DVDs (como se 
fossem cópias do mesmo filme). E cada DVD é de apenas um filme. Cada um desses 
filmes possui uma categoria. Na Figura 60, vemos que a categoria foi inicialmente 
representada como uma entidade fazendo parte de um relacionamento ternário. 
Essa representação estaria equivocada. Ela representaria que apenas a cada vez 
que um filme fosse associado a uma cópia de DVD é que seria associada uma 
categoria a ele. Porém, isso é um erro. Pois, todo filme possui uma categoria (vide 
a segunda representação na Figura 60), independente da quantidade de cópias de 
DVD existentes na locadora.
Figura 60 - Exemplo de Erro Sintático - Entidade Mal Posicionada
Outro erro ainda poderia ser a colocação de cardinalidades erradas nos 
relacionamentos, também consequência da má interpretação do problema.
Ser Completo
O Modelo deve expressar todos os requisitos do usuário. Ou seja, nada do que 
seja necessário para resolver o problema em questão deve ser esquecido, deve deixar 
de ser representado no modelo. Essa verificação só pode ser feita por um especialista do 
domínio. Ou seja, por alguém que faça parte do cliente e entenda bem do problema a ser 
resolvido. Por isso mesmo, é importante envolver o usuário/cliente do projeto nesta etapa 
inicial. Adicionalmente, podemos fazer alguns questionamentos para ajudar a verificar a 
completude do modelo, tais como:
» Os dados que devem ser obtidos a partir do BD 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?
56
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.
Ser Livre de Redundâncias
O Modelo ER deve ser mínimo, ou seja, não deve conter duplicidades ou 
redundâncias. E quais tipos de redundâncias seriam essas? As mais comuns de acontecerem 
são:
» Relacionamentos redundantes – ocorre quando um relacionamento é 
desnecessário. Seu resultado pode ser obtido através de outroas relacionamentos. 
Ou seja, é possível retirá-los do modelo ER, sem que haja perda de informação no 
BD.
 Por exemplo, vide a Figura 61. Existe um relacionamento entre as entidades DEPTO 
e MAQUINA chamado LOCALIZA DEPTO, para especificar em qual departamento a 
máquina está alocada. Por causa desse relacionamento, o relacionamento LOCALIZA 
FABR que indica em que fábrica a máquina está alocada é redundante. Isso porque 
se se sabe em que fábrica o departamento está (relacionamento entre FABRICA e 
DEPTO), e se sabe em que departamento a máquina está (relacionamento entre 
DEPTO e MAQUINA), logo, se sabe onde a máquina está.
Figura 61 - Exemplo de relacionamento redundante
» Atributos redundantes – ocorre quando acabamos criando atributos 
desnecessários no diagrama. Ou porque esses atributos são deriváveis ou porque 
já estão representados de alguma forma no diagrama (por exemplo, em uma 
entidade relacionada). Vamos dar um exemplo. Na Figura 62, o atributo código do 
departamento da entidade EMPREGADO é redundante, porque esse código poderia 
ser obtido na entidade DEPARTAMENTO, com a qual a entidade EMPREGADO 
está relacionada (vide atributo código na entidade DEPARTAMENTO). Também, o 
atributo no. de empregados é um atributo redundante porque ele expressa um valor 
57
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.
Figura 62 - Exemplo de Atributos Redundantes
Atenção
Algumas vezes, por questões de performance, um modelo ER pode conter redundância. É a 
chamada “redundância controlada” de dados. Nesses casos, a redundância deve ser muito bem 
documentada para não parecer um erro.
Refletir Aspecto Temporal, quando Necessário
Algumas vezes, determinadas partes do modelo podem precisar possuir uma 
espécie de histórico, porque certas aplicações exigem que o BD guarde o histórico dos 
dados (por motivos legais, por necessidade de auditoria ou de possuir dados históricos 
que ajudem na tomada de decisão). Por exemplo, uma empresa pode desejar guardar um 
histórico do valor do salário pagoa um funcinário no decorrer dos anos. Ou uma imobiliária 
pode desejar armazenar o período em que cada pessoa ficou em determinado imóvel 
alugado. Para criar esse histórico, precisamos identificar os dados temporais, ou sejam, 
aqueles dados que mudam ao longo do tempo, de acordo com o problema a ser resolvido. 
Esses dados temporais podem ser: atributos ou relacionamentos. Vamos dar uma olhada e 
ver exemplos de cada um.
» Guardando histórico de atributos – quando desejamos guardar o histórico de 
um atributo, ele deve ser transformado em entidade fraca vinculada à entidade a 
qual pertencia, tendo como identificador um atributo do tipo data. Vamos dar um 
exemplo. Imagine que a empresa precisa guardar o histórico dos salários de seus 
empregados. Se o salário fosse representado apenas como um atributo da entidade 
EMPREGADO (Figura 63 – lado esquerdo), seria guardado apenas um salário. Se o 
salário fosse atualizado, o novo valor sobreporia o valor anterior. Para que o valor 
anterior não fosse perdido, o salário teria de ser transformado em uma entidade 
(entidade fraca com relação à entidade EMPREGADO) e teria como identificador 
58
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.
Figura 63 - Guardando histórico do atributo salário
» Guardando histórico de relacionamentos – quando desejamos guardar o 
histórico dos valores de um relacionamento, o relacionamento deverá passar a 
cardinalidade n:n e um atributo data deverá passar a fazer parte do identificador do 
relacionamento. Vamos dar o exemplo de três casos que podem ocorrer.
Caso 1: Relacionamento 1:1 – Suponha um enunciado onde, em uma empresa, 
cada empregado é alocado em um computador e cada computador é alocado, por vez, 
para apenas um empregado. Essa representação seria feita com a modelagem expressa 
na Figura 64 – lado esquerdo. Ou seja, com em um relacionamento 1:1 entre as entidades 
EMPREGADO e COMPUTADOR. Porém, se a empresa desejasse armazenar o histórico de 
alocações do computador aos empregados, seria necessário ter um atributo data como 
parte do identificador do relacionamento ALOCA e, o relacionamento passaria a ser n:n. Por 
que mudar a cardinalidade para n:n? Porque agora seria possível que, dependendo da data, 
um computador pudesse estar alocado a vários empregados diferentes (vide Figura 64 – 
lado direito). E um empregado pudesse estar usando computadores diferentes, dependendo 
da data. 
Figura 64 - Guardando histórico de um relacionamento que era 1:1
59
Banco de Dados
Caso 2: Relacionamento 1:n – Suponha um enunciado onde, em uma empresa, 
cada empregado é alocado para trabalhar em um projeto e em um projeto trabalham N 
empregados. De cada empregado deve ser armazenado o nome do mesmo e a função que 
ele desempenha no projeto. Para esse enunciado, teríamos a modelagem da Figura 65 – lado 
esquerdo, onde há as entiddades EMPREGADO e PROJETO associadas pelo relacionamento 
Trabalha. A entidade EMPREGADO teria dois atributos nome e função. Essa modelagem 
não permite guardar o histórico de em quais projetos um empregado já trabalhou ou 
que funções desempenhou nesses projetos (até mesmo no mesmo projeto, porque, às 
vezes, em um mesmo projeto, o empregado pode desempenhar funções diferentes em 
épocas diferentes). Logo, se fosse necessário armazenar esse tipo de histórico, teríamos, 
novamente, que transformar o relacionamento em n:n e colocar um atributo data como 
identificador do relacionamento (vide Figura 65 – lado direito). Além disso, como agora o 
empregado pode trabalhar em vários projetos ou mais de uma vez (em épocas diferentes) 
no mesmo projeto, o atributo função deveria passar a ser atributo do relacionamento 
trabalha (e não mais da entidade EMPREGADO).
Figura 65 - Guardando histórico em um relacionamento que era 1:n
Caso 3: Relacionamento n:n – Suponha um enunciado onde um aluno cursa várias 
disciplinas e uma disciplina pode ser cursada por vários alunos. Esse problema poderia 
ser representado pelas entidades ALUNO e DISCIPLINA, assoaciados pelo relacionamento 
CURSA. O relacionamento poderia até ter um atributo data para indicar quando o aluno 
cursou a disciplina (vide Figura 66 – lado esquerdo). Porém, essa modelagem não permitiria, 
por exemplo, que um aluno cursasse mais de uma vez a mesma disciplina (ou seja, ele não 
poderia ser reprovado e repetir a disciplina). Em outras palavras, essa modelagem não 
permitiria guardar o histórico de um aluno com relação a uma disciplina. Para que isso 
se tornasse possível, como o relacionamento já é n:n, bastaria tornar o atributo data, um 
atributo identificador do relacionamento (vide Figura 66 – lado direito). 
60
Banco de Dados
Figura 66 - Guardando histórico em um relacionamento n:n
Em resumo...
Para adicionar o aspecto temporal a uma modelagem, se a mesma envolve relacionamentos 
1:1 ou 1:n, devemos tornar esses relacionamentos n:n e adicionar um atributo data como 
identificador do relacionamento.
Se o relacionamento já for n:n, devemos adicionar apenas um atributo data como identificador 
do relacionamento.
Evitar Entidades Isoladas
Uma entidade isolada é uma entidade que 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.
Figura 67 - Exemplo de Entidade Isolada modelando a Organização
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.
61
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
As referências para esse capítulo são as mesmas do capítulo anterior, pois, na 
verdade, continuamos no assunto modelagem conceitual. Apenas detalhamos mais como 
fazer essa modelagem. Agora, não esqueça, um dos livros mais interessantes sobre o 
assunto é justamente o 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, os links a seguir podem ser úteis:
Modelagem de Dados - Metodologia para Modelar um Banco de Dados. 
 http://www.virtual.epm.br/material/tis/curr-bio/bdados/teste.htm
Conceitos 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
1) Baseado nas recomendações vistas neste capítulo, apresente um diagramaER que 
modele mais precisamente a realidade apresentada na figura a seguir. Explique no 
que seu diagrama é mais preciso que o mostrado na figura a seguir.
Se olharmos a figura a ser avaliada veremos que ela apresenta alguns problemas 
de modelagem que podem ser sanados com algumas modificações no diagrama. Vamos a 
esses problemas:
» Atributos opcionais devem ser evitados, porque, no geral, eles indicam 
subconjuntos de entidades que são modelados mais corretamente através de 
especializações/generalizações. No caso da figura, os atributos CPF, nome, sexo e 
62
Banco de Dados
data de nascimento deveriam passar a pertencer a clientes do tipo Pessoa Física, 
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.
2) Crie um diagrama entidade-relacionamento para um Sistema de Controle 
Acadêmico fictício, a partir do problema especificado a seguir.
Sistema para controle acadêmico fictício
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:
63
Banco de Dados
Cada disciplina possui exatamente um, e somente um, departamento responsável, 
o qual pode ser responsável por muitas disciplinas, inclusive nenhuma7.
Desse parágrafo podemos tirar que existem duas entidades: DEPARTAMENTO e 
DISCIPLINA, que estão relacionadas. Como a disciplina possui exatamente um, e somente 
um, departamento, a cardinalidade de DISCIPLINA para DEPARTAMENTO é (1,1). Como cada 
departamento pode ter muitas disciplinas, inclusive nenhuma, isso já indica a cardinalidade 
(0,n). Dessa forma, a primeira parte do diagrama seria modelada como segue:
Vamos ao segundo parágrafo:
Uma disciplina pode possuir diversas disciplinas como pré-requisitos, inclusive nenhuma. Uma 
disciplina pode ser pré-requisito de muitas disciplinas, inclusive nenhuma.
Como o pré-requisito de uma disciplina é também uma disciplina, esse parágrafo 
já dá a indicação de que vamos precisar de um autorrelacionamento. Como a entidade 
DISCIPLINA já está desenhada no diagrama, o que você vai fazer é acomplar o novo 
componente no diagrama que temos até agora. Dessa forma, criamos o relacionamento 
preRequisito que tem cardinalidade (0,N). Ou seja, uma disciplina tem 0 ou mais pré-
requisitos e uma disciplina pode ser pré-requisito de 0 ou mais disciplinas.
Vamos ao terceiro parágrafo:
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:
Saiba Mais
7 Sempre que se 
puder ter nenhuma 
ocorrência, isso 
quer dizer que a 
cardinalidade mínima 
do relacionamento é 
zero.
64
Banco de Dados
Finalmente, o último parágrafo:
Um aluno está inscrito em exatamente um, e somente um, curso e um curso pode ter muitos 
alunos inscritos, inclusive nenhum.
Deste parágrafo, podemos deduzir um relacionamento entre a entidade ALUNO e a 
entidade CURSO. Sendo que um aluno tem um relacionamento de cardinalidade (1,1) para 
com o curso e o curso tem cardinalidade (0,N) para com aluno (ele pode ter zero ou mais 
alunos). Assim, o diagrama ficaria assim:
Claro que você poderia dar outros nomes aos relacionamentos, visto que eles 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.
 
Atividades e Orientações de Estudo
Agora é a sua vez de fazer as atividades! Lembre, praticar é muito importante para 
fixar o conteúdo estudado!
Atividades Práticas
Resolva as atividades a seguir em um documento texto e poste o mesmo no 
ambiente virtual, no local indicado. Essa atividade é para ser realizada em DUPLA (escolha 
seu companheiro de trabalho!) e fará parte da avaliação somativa de vocês. Para desenhar 
os diagramas, procure utilizar a ferramenta BR-Modelo e copie e cole os diagramas no 
documento texto. Outra opção é compactar o documento texto (doc) e os arquivos gerados 
pelo BR-Modelo (ele gera arquivos XML) e postar o arquivo compactado no ambiente 
virtual. Fica a critério da equipe qual das opções utilizar.
1) Desenhe no BR-Modelo o MER para a seguinte descrição:
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
65
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. 
2) Usando a ferramenta BR-Modelo, faça o modelo E-R para a seguinte descrição: 
Uma empresa cinematográfica possui vários cinemas em diversas localidades. 
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 cinemapossui 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.
3) Usando a ferramenta BR-Modelo, faça o modelo E-R para a seguinte descrição:
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.
66
Banco de Dados
4) Até aqui desenhamos diagramas a partir de enunciados. Vamos fazer o contrário 
agora? Então, identifique atributos que as entidades e/ou relacionamentos podem 
possuir e descreva em um texto, em português, o modelo ER representado na figura 
seguir.
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.
67
Banco de Dados
Capítulo 6
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar os seguintes temas:
» Notações Alternativas para o MER.
Metas
Após o estudo deste capítulo, esperamos que você:
» Conheça outras formas de desenhar o MER.
» Consiga desenhar ou fazer a leitura de modelos ER em diferentes notações.
68
Banco de Dados
Capítulo 6 – Outras Notações para o 
MER
Vamos conversar sobre o assunto?
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).
Notação da Engenharia de Informações
Também conhecida como “Pé de Galinha” ou notação James Martin, sua 
importância é devida ao fato de ser suportada por várias ferramentas CASE. Algumas 
características dessa notação são:
» Ela dá maior ênfase à modelagem de dados;
» São permitidos apenas relacionamentos binários;
» Atributos aparecem exclusivamente em entidades;
» Os relacionamentos passam a ser representados por uma linha, geralmente com 
um verbo dando o significado dos relacionamentos em ambas direções;
» Usa a notação gráfica de cardinalidades máximas e mínimas, conforme apresentado 
na Figura 68. 
Figura 68 - Notação de Cardinalidade Máxima e Mínima
Na Figura 69, exemplificamos o uso dessa notação. No exemplo, temos: um 
69
Banco de Dados
departamento tem um e apenas um (cardinalidades mínima e máxima) funcionário que o 
gerencia. Um funcionário gerencia ZERO ou um departamento. O segundo exemplo mostra 
que uma divisão possui um ou mais (N) departamentos e um departamento pertence 
a uma e apenas uma divisão. No terceiro exemplo, um funcionário possui ZERO ou mais 
dependentes e um dependente pertence a um e apenas um funcionário. No quarto exemplo 
temos que um Funcionário trabalha em um ou mais projetos e um projeto tem trabalhando 
nele um ou mais funcionários. Por fim, no último exemplo temos um autorrelacionamento 
envolvendo a entidade Funcionário, onde um Funcionário grencia ZERO ou mais funcionários 
e um Funcionário é gerenciado por um e apenas um funcionário.
Figura 69 - Exemplos de uso da Notação da Engenharia da Informação
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?
Figura 70 - Mudanças da Notação de Peter Chen para a Engenharia de Informações
Nesta notação também muda a representação para a generalização/especialização. 
Ela passa passa ser representada como um subconjunto(subtipo) de entidades, em outras 
palavras, como um aninhamento dos símbolos de entidade. Para exemplificar, vamos supor 
o seguinte problema: “A empresa X deseja criar um banco de dados para armazenar os 
dados dos seus funcionários e seu afazeres. Nessa empresa um departamento lota zero 
ou mais empregados e um empregado está logado em um e apenas um departamento. O 
empregado pode ser um gerente, uma 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 
70
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.
Figura 71 - Problema representado na Notação de Peter Chen
Figura 72 - Problema representado na Notação da Engenharia de Informações
Veja que na notação da Engenhariade Informações, os subtipos (especializações) 
gerente, secretária e engenheiro são representados como entidades internas da classe mais 
genérica (empregado).
71
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:
» Representa relacionamentos como elipses ao invés de losangos;
» Usa semântica participativa, ou seja, demonstra quantas ocorrências de uma 
entidade participa de um relacionamento. Ou seja, ela vai indicar quantas 
ocorrências da entidade. Por este motivo, as cardinalidades são expressas de lados 
opostos aos equivalentes na notação de Peter Chen (que usa semântica associativa). 
Vamos exemplificar essas diferenças. Suponha o problema “um projeto aloca zero 
ou mais empregados e um empregado trabalha em um e apenas um projeto por vez”. Na 
Figura 73 vemos esse problema representado tanto na notação de Peter Chen, quanto na 
notação MERISE. Observe que, na notação MERISE, as cardinalidades foram invertidas. 
Porque ela quer representar que uma ocorrência da entidade EMPREGADO participa 
no mínimo uma e no máximo uma vez do relacionamento ALOCA. E a entidade PROJETO 
participa zero ou mais vezes do relacionamento ALOCA. Veja que a forma de ler o problema 
muda. Agora pensamos em participação da entidade no relacionamento e não na associação 
de uma entidade com outra.
Figura 73 - Notação Peter Chen x Notação MERISE
Estratégias de Modelagem
Uma estratégia de modelagem é uma sequência de passos de transformação de 
modelos. Ou seja, é a definição da sequência de passos para transformar o modelo inicial 
no modelo final. Alguns exemplos de estratégia são: Engenharia Reversa, Bottom-up, Top-
down e Inside-out. Porém, na prática, nenhuma das estratégias propostas na literatura 
é amplamente aceita. Geralmente, se usa a combinação de diversas estratégias de 
modelagem, também por se levar em consideração que o processo de construção de um 
modelo é um processo incremental onde, gradualmente, o modelo vai sendo enriquecido 
com novos conceitos e estes vão sendo ligados aos existentes ou os conceitos existentes vão 
sendo aperfeiçoados no decorrer do tempo.
Para definir qual a estratégia a usar na construção de um modelo ER, deve-se 
identificar qual é a principal fonte de informações para o processo de modelagem. São duas 
72
Banco de Dados
as fontes de informação possíveis: as descrições de dados existentes e o conhecimento que 
pessoas possuem sobre o sistema.
Fonte de Informações 1: Descrições de Dados Existentes
É a fonte utilizada quando se deseja obter um modelo de dados para um sistema 
de computador que já existe ou quando são utilizadas descrições de documentos (fichas, 
documentos fiscais, comprovantes, relatórios, etc) usados em um sistema não automatizado. 
Nestes casos, são usadas como descrição dos dados do modelo as descrições dos arquivos 
utilizados pelo sistema existente ou presentes nas documentações consultadas. Com esse 
tipo de fonte de informação podem ser usadas as seguintes estratégias:
» Estratégia de Engenharia reversa – onde se obtém a especificação (modelo) a 
partir de um produto pré-existente (um sistema). Esse processo é mais fácil se for 
usada algum tipo de ferramentas CASE (Computer Aided Software Engineering) 
para ajudar. Muitas ferramentas de modelagem de dados existentes realizam esse 
processo de Engenharia Reversa (ex: ERWIN).
» Estratégia Bottom-up (de baixo para cima) – esta estratégia é mais usada quando 
não há sistema automatizado. Assim, a modelagem é construída partindo de 
descrições de dados já existentes em documentos. E a construção do modelo se dá 
dos conceitos mais detalhados até os mais abstratos. Por exemplo, inicia-se com a 
definição dos principais atributos, agrega-se os atributos em entidades e, por fim, 
definem-se os relacionamentos e generalizações entre as entidades. 
Fonte de Informações 2: Conhecimento que as Pessoas Possuem 
do Sistema
É 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. 
73
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 
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 
que mantenha esse dicionário integrado com o modelo sendo construído.
Conheça MaisMais 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:
 CHEN, PETER PIN-SHAN, The Entity-Relationship Model – Toward a unified view of 
data, ACM Transactions on database systems, vol. 1, n. 1, pp. 9-36, Março 1976.
 COUGO, PAULO, Modelagem conceitual e projeto de bancos de dados, Rio de 
Janeiro: Editora Campus, 1997.
Saiba Mais
8 Apresentamos 
algumas dessas 
ferramentas no final 
do Capítulo 4, neste 
mesmo volume.
74
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
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)
Atividades e Orientações de Estudo
Discuta no fórum da semana sobre as notações para modelagem de dados. Tenha 
como guia as seguintes questões:
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 
75
Banco de Dados
deixe de participar! Além disso, você pode aprender muito compartilhando informações 
com seus colegas.
Atividades Práticas
Resolva as atividades a seguir em um documento texto e poste o mesmo no 
ambiente virtual, no local indicado. Essa atividade é para ser realizada em DUPLA (escolha 
seu companheiro de trabalho!) e fará parte da avaliação somativa de vocês. 
1) Escreva uma frase para representar como se leem cada um dos relacionamentos 
abaixo. Depois, redesenhe cada um desses relacionamentos na notação MERISE.
2) Redesenhe o diagrama abaixo na notação da Engenharia de Informações, fazendo 
os ajustes necessários.
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.
76
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
77
Banco de Dados
Referências
	 BATINI, C.; CERI, S.; NAVATHE, S. B. Conceptual database design: an entity-
relationship approach. San Francisco: Benjamim Cummings, 1992.
 CHEN, PETER PIN-SHAN, The Entity-Relationship Model – Toward a unified view of 
data, ACM Transactions on database systems, vol. 1, n. 1, pp. 9-36, Março, 1976.
 COUGO, PAULO, Modelagem conceitual e projeto de bancos de dados, Rio de 
Janeiro: Editora Campus, 1997.
 DATE, C. J. Banco de dados: tópicos avançados. Rio de Janeiro : Campus, 1988.
 DATE, C. J. Introdução a Sistemas de Banco de Dados. Elsevier Editora, 2004.
 ELMASRI, Ramez;NAVATHE, Shamkant B. Sistemas de banco de dados. Traduzido 
por: Marilia Guimarães Pinheiro et al. 4a. ed. São Paulo: Pearson Education do 
Brasil, 2005.
 HAY, D. Princípios de modelagem de dados. São Paulo: Makron Books, 1999.
 HEUSER, Carlos Alberto. Projeto de Bancos de Dados. 4 ed. Porto Alegre: Sagra 
Luzzatto, 2001.
 KIPPER, E.F. Engenharia de Informações: Conceitos Técnicas e métodos, Sagra DC-
Luzzato, Porto Alegre, 1993.
 LAENDER, A. H. F. ; CASANOVA, M. A. ; TUCHERMAN, L. . On the Design and 
Maintenance of Optimized Relational Representations of Entity-Relationship 
Schemas. Data & Knowledge Engineering, Amsterdam, v. 11, n. 1, p. 1-20, 1993
 MARTIN, James. Information Engineering: Books I, II & III. Englewood Cliffs: 
Prentice-Hall, 1990.
 Revista SQL Magazine - http://www.sqlmagazine.com.br
 SETZER, V. W. Banco de dados. 3.ed. São Paulo : Revista Edgard Blucher, 1989.
 SILBERSCHATZ, Abraham; KORTH, Henry F;SUDARSHAN, S. Sistema de banco de 
dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.
 TARDIEU, H.; ROCHFELD, A.; COLLETI, R. Le Methode Merise: Principles et Outils. 
Les Editions d’Organization, Paris, 1983
 TEOREY, TOBY J., FRY, JAMES P., Design of database structures, New Jersey: Prentice-
Hall, 1982.
78
Banco de Dados
Conhecendo a Autora
Sandra de Albuquerque Siebra
Doutora em Ciência da Computação, pelo Centro de Informática da UFPE onde 
trabalhou com Ambientes Virtuais de Aprendizagem e Ambientes Colaborativos em Geral. 
Ensinou na Faculdade Integrada do Recife (FIR) e na Universidade Católica de Pernambuco 
(UNICAP), além de ter trabalhado como gerente de projetos no Centro de Estudos e Sistemas 
Avançados do Recife (CESAR). Atualmente, é professora da Universidade Federal Rural de 
Pernambuco (UFRPE). Atua na equipe de Educação a Distância da UFRPE e no Departamento 
de Estatística e Informática (DEINFO), como professora autora de materiais didáticos para 
cursos a distância, já tendo também atuado como coordenadora de curso e professora 
executora de disciplinas. Tem experiência, trabalhos desenvolvidos e artigos publicados nas 
áreas de Educação a Distância, Interfaces Homem- Máquina, Sistemas Colaborativos, Banco 
de Dados, Análise e Projeto de Sistemas Orientados a Objetos, Sistemas de Informação e 
Engenharia de Software. Atualmente, desenvolve pesquisas sobre contextualização de 
interações em ambientes virtuais de aprendizageme trabalho cooperativo.