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

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

3. Sumário
Apresentação................................................................................................................. 4
Conhecendo o Volume 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
4

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.
5

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.
6

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 aproveitar os recursos disponíveis no SGBD é chamado modelagem de dados. Ou seja,
é processo para a criação do modelo de dados. Mas por que modelar os dados? Qual o
objetivo disso? É importante modelar os dados a fim de conhecer melhor as informações
dos usuários e como elas se relacionam a fim de representar, da melhor forma, o ambiente
observado criando, por consequência, bancos de dados mais corretos e eficientes. Um
projeto mal feito pode trazer diversos problemas, tais como: o banco de dados e/ou
aplicação podem não funcionar adequadamente; os dados podem não ser confiáveis ou
serão inexatos e a performance do BD pode ser degradada.
A modelagem de dados é uma das etapas do ciclo de Desenvolvimento de Sistemas
de Banco de Dados (vide Figura 1).
7

8. 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
8

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
9

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
Lembrete 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.
1
Um requisito Porém, evitando detalhes de implementação. Essa fase dá origem ao esquema conceitual
consiste da definição representado pelo modelo entidade-relacionamento (que estudaremos em detalhes na
documentada de próxima seção).
uma propriedade
ou comportamento A terceira fase é o projeto lógico (ou implementação) que objetiva mapear o
que um produto ou
modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem ao
serviço particular
deve atender. Ou de esquema lógico representado pelo modelo relacional que já é um modelo que depende do
uma característica, SGBD que será usado para implementar o banco de dados.
atributo, habilidade
ou qualidade que um A quarta e última fase é o projeto físico que objetiva mapear o modelo de
sistema (ou qualquer dados relacional para o modelo de dados físico que tratará das estruturas em memória e
um de seus módulos
e subrotinas) deve
organização dos arquivos do BD (arquivos de índices). Essa fase dá origem ao esquema físico
necessariamente que será o que realmente será implementado no BD.
prover para ser útil a
seus usuários.
Figura 3 - Projeto de Esquemas de BD (Fonte: Elmasri, 1994)
10

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
11

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
12

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

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

15. 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)
15

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.
16

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 entidade de A. É como
se cada instância da entidade A só encontrasse uma instância correspondente na
entidade B (vide Figura 14). Por exemplo, “Pessoa recebe Certidão de Óbito”. Cada
pessoa só pode receber uma única certidão de óbito (só se morre uma vez, não é?)
e uma certidão de óbito só deve pertencer a uma única pessoa (vide Figura 15).
Logo, esse relacionamento é dito um para um.
17

18. 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
18

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
19

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.
20

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
21

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 figura 26, a cardinalidade circulada 1 (também apontada pela seta) significa que
cada par de ocorrências (empregado, projeto) está associado a, no máximo, um cliente. Em
outras palavras, cada projeto onde estão alocados empregados só possui um cliente que é o
“dono” (contratante) daquele projeto com aquela equipe de empregados. Já os outros dois N
de cardinalidade expressam que: a um par (cliente, projeto) podem estar associados muitos
empregados (N empregados), ou seja, o projeto do cliente pode ter diversos empregados
alocados nele. E, finalmente, a um par (empregado, cliente) podem estar associados muitos
projetos, ou seja, um empregado pode trabalhar para um cliente em vários projetos (N
projetos) diferentes. Mais complicado, não é?
Figura 26 - Em relacionamentos ternários, as cardinalidades são postas aos pares
22

23. 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
23

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
24

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

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ível modelar a maioria dos bancos de dados apenas com os
conceitos básicos do E-R, alguns aspectos de um banco de dados podem ser expressos de
modo mais conveniente por meio de algumas extensões do modelo ER. Vamos descrever
melhor essas extensões, a seguir.
Especialização/Agregação
Um conjunto de entidades pode conter subgrupos de entidades que são, de alguma
forma, diferentes de outras entidades do conjunto. Esta diferença pode estar caracterizada
por um subgrupo possuir atributos que não são compartilhados pelas demais entidades do
conjunto. A especialização permite atribuir propriedades particulares a um subconjunto de
entidades especializadas através da herança de propriedades (atributos) de uma entidade
mais genérica.
A especialização no diagrama é representada pelo triângulo. Alguns autores
utilizam um triângulo rotulado de ISA (de “is a” em inglês, ou seja, “ é um(a)”). Por exemplo,
na Figura 33 temos uma entidade genérica CLIENTE e duas entidades que derivam dessa
entidade genérica, as entidades especializadas: P. FÍSICA e P. JURÍDICA. Qual a vantagem
disso? P.FISICA e P.JURIDICA irão ter todos os atributos que a entidade CLIENTE possuir,
mas podem ter atributos adicionais, diferentes entre elas. Elas são casos especializados da
entidade CLIENTE.
Figura 33 - Exemplo de Especialização/Generalização
26

27. 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
27

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
28

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.
29

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.
30

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
31

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
Saiba Mais
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
4
Através da
Engenharia Reversa é análise. A ferramenta permite desde a criação e manutenção da bases de dados, até o uso
possível obter a partir de mecanismos de sincronização de dados necessários. Além disso, oferece recursos para
do banco de dados realizar o processo inverso (Engenharia reversa4). O ERwin gera modelos para todos os
criado, os diagramas
que o geraram.
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.
32

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.
33

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.
34

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.
35

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
36

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?
37

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
38

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úmero de horas alocadas para
um empregado para trabalhar num projeto, e mostre como isto pode ser
representado no diagrama.
b) Escolha identificadores para cada uma das entidades.
c) Fazendo as 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.
39

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.
40

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á!
41

42. Banco de Dados
Quadro 1 - Alguns dos Componentes do MER
42

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.
43

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.
44

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”
45