Capítulo 2: Modelo ER
 Conjuntos de entidades
 Conjuntos de relações
 Aspectos do desenho
 Restrições
 Chaves
 Diagrama ER
 Extensões ao modelo ER
 Desenho dum Esquema de Base de Dados ER
Database System Concepts
2.1.1
©Silberschatz, Korth and Sudarshan (Modificado)
Modelo ER
(Entidade-Relações ou Entidades-Associações)
 “Ferramenta” [Chen 76] para descrever:
 informação
 relações entre tipos de informação
 significado da informação
 (algumas formas de) restrições sobre os dados
 Construção de grafos que objectivam as características da
informação a armazenar
Database System Concepts
2.1.2
©Silberschatz, Korth and Sudarshan (Modificado)
Conjuntos de entidades
 No modelo ER, uma base de dados pode ser modelada como:
 uma colecção de entidades,
 uma colecção de relações (ou associações) entre entidades.
 Uma entidade é um objecto existente e que é distinguível de
todos os outros objectos. Eg:
 O cliente 33 do banco, que se chama João mora em Lisboa e tem o
telefone 22222
 A conta 11111 que pertence aos clientes 33 e 22 e cujo saldo é
1000 Euros
 As entidades possuem atributos
Exemplo: os clientes têm nº, nome, endereço e telefone
 Um conjunto de entidades é um conjunto de entidades do
mesmo tipo e que partilham as mesmas propriedades.
Exemplo: o conjunto de todas os clientes, o conjunto de
todas as contas, etc
Database System Concepts
2.1.3
©Silberschatz, Korth and Sudarshan (Modificado)
Atributos

Atributo: Propriedade de uma entidade. E.g.
 Nome dum cliente
 Saldo duma conta



Entidades são representadas por atributos
Conjuntos Entidades agregam entidades todas descritas pelos mesmos atributos
Cada atributo tem um domínio (conjunto de valores permitidos para o atributo).
 Domínio de “Nome”´: strings de até 50 caractéres
 Domínio de “Saldo”: números inteiros

Tipos de atributos:
 Atributo simples
 Atributo compostos: Composto por vários atributos simples
 E.g. Morada (com nome de rua, nº de porta, Localidade, CP)
 Atributos univalor e multivalor
 E.g. atributo multivalor: números de telefone
 Atributos derivados: Que podem ser calculado a partir de outros atributos
 E.g. idade, a partir da data de nascimento

Vamos fazer as coisas por forma a ter sempre atributos simples, univalor e não
derivados.
 Lá mais para a frente veremos melhor porquê!!
Database System Concepts
2.1.4
©Silberschatz, Korth and Sudarshan (Modificado)
Conjuntos de Relações
 Uma relação é uma associação entre várias entidades. E.g.:
 Associação entre a conta 1111 e o cliente 33 (um dos titulares da
conta)
 Um conjunto de relações é um conjunto de relações todas do
mesmo tipo. E.g. :
 Conjunto entre todas as associações entre contas e clientes
seus titulares (depositantes)
 Formalmente é uma relação matemática entre n  2 entidades,
cada uma pertencente a um conj. de entidades
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}
em que (e1, e2, …, en) é uma relação
 Exemplo: (conta 1111, cliente 33)
Database System Concepts
2.1.5
 depositante
©Silberschatz, Korth and Sudarshan (Modificado)
Exemplo de Relações
Conjunto Relação
33
22
11
João
Maria
Manuel
Lisboa
22222
Caparica 7111111
Almada 2910000
Entidade
9/1/99
6/3/99
6/2/99
2/2/99
Relação
11111
11112
11113
1000€
500€
1300€
Conjunto Entidade
 Uma relação pode ter atributos adicionais
 Data em que um cliente movimentou uma conta pela última vez
(data de acesso)
Database System Concepts
2.1.6
©Silberschatz, Korth and Sudarshan (Modificado)
Restrições de Mapeamento (Cardinalidades)
 Restringem o número de entidades com as quais pode estar
associada uma outra entidade num determinado conjunto de
relações.
 Para um conjunto de relações binárias a restrição de
mapeamento pode ser uma das seguintes:
 um para um (ou 1:1)
 um para muitos (ou um para vários, ou 1:N)
 muitos para um (ou vários para 1, ou N:1)
 muitos para muitos (ou vários para vários, N:M)
Database System Concepts
2.1.7
©Silberschatz, Korth and Sudarshan (Modificado)
Atributos vs relações
Em vez de:
33
22
João
Maria
Lisboa
22222
Caparica 7111111
Porque não:
33
22
João
Maria
Permitia
Lisboa
Caparica
22222
7111111
 Depende da aplicação em causa
 Há que ver, intuitivamente, caso a caso
 Só é atributo (univalor), se for 1:1
 Um cliente tem no máximo um telefone e um telefone é de um
cliente.
Database System Concepts
2.1.8
©Silberschatz, Korth and Sudarshan (Modificado)
Restrições mapeamento
 Um para um (1:1)
 Numa empresa, um empregado tem no máximo um carro, e uma
carro está no máximo atribuído a um empregado.
a1
b1
a2
b2
a3
b3
• (e1,e2)  R  (e1,e3)  R e2 = e3
• (e1,e2)  R  (e3,e2)  R e1 = e3
Database System Concepts
2.1.9
©Silberschatz, Korth and Sudarshan (Modificado)
Restrição 1:1
 Proibe que uma entidade de A
se relacione com mais do que
uma entidade de B.
 Proibe que uma entidade de B
se relacione com mais do que
uma entidade de B.
 Exemplo: Um empregado está
associado no máximo a um
carro, e um carro está
associado no máximo a um
empregado
Nota: Alguns elementos de A ou B podem não estar
relacionados com elementos do outro conjunto.
Database System Concepts
2.1.10
©Silberschatz, Korth and Sudarshan (Modificado)
Restrições mapeamento
 Um para vários (1:N)
 Uma turma tem vários alunos, mas um aluno só pertence a uma
turma
a1
b1
b2
a2
b3
• (e1,e2)  R  (e1,e3)  R e2 = e3
• Não há restrição no outro sentido
Database System Concepts
2.1.11
©Silberschatz, Korth and Sudarshan (Modificado)
Restrição N:1
 Proibe que uma entidade de A
se relacione com mais do que
uma entidade de B.
 Permite que uma entidade de B
se relacione com mais do que
uma entidade de B.
 Exemplo: Um aluno está
associado a no máximo uma
turma, mas uma turma pode
estar associada a mais que um
aluno
Nota: Alguns elementos de A ou B podem não estar
relacionados com elementos do outro conjunto.
Database System Concepts
2.1.12
©Silberschatz, Korth and Sudarshan (Modificado)
Restrições mapeamento
 Vários para vários (M:N)
 Um cliente pode ter várias contas e uma conta pode pertencer a
vários clientes
 Um livro pode ser requisitado por vários leitores, e um leitor pode
requisitar vários livros.
a1
b1
a2
b2
a3
b3
• Não há restrições em nenhum dos sentidos
Database System Concepts
2.1.13
©Silberschatz, Korth and Sudarshan (Modificado)
“Restrição” N:M
 Não impõe restrições
 Permite que uma entidade de A
se relacione com mais do que
uma entidade de B.
 Permite que uma entidade de B
se relacione com mais do que
uma entidade de B.
 Exemplo: Uma conta pode estar
associada a mais do que um
cliente, e um cliente pode ter
mais do que uma conta
associada
Nota: Alguns elementos de A ou B podem não estar
relacionados com elementos do outro conjunto.
Database System Concepts
2.1.14
©Silberschatz, Korth and Sudarshan (Modificado)
As cardinalidades afectam o desenho
 Se a a relação entre clientes e contas fosse de um para vários
(i.e. um cliente pode ter várias contas mas uma conta só pode
pertencer a um cliente) então data-de-acesso poderia ser um
atributo de conta, em vez de um atributo da relação.
Database System Concepts
2.1.15
©Silberschatz, Korth and Sudarshan (Modificado)
Chaves
 Como distinguir entre várias entidades (ou entre várias
relações) dentro dum mesmo conjunto?
 Super-chave de um conjunto de entidades é um conjunto de
um ou mais atributos cujos valores determinam
univocamente cada uma das entidades dentro do conjunto.
 A determinação unívoca, depende do contexto em causa, e
é imposta como restrição.
 O nº de cliente é super-chave em clientes
 O nº e nome também é super-chave
 Uma super-chave pode ter informação desnecessária.
 O nome é desnecessário na super-chave com o nº e nome.
Database System Concepts
2.1.16
©Silberschatz, Korth and Sudarshan (Modificado)
Chaves primárias e candidatas
 Uma chave candidata de um conjunto de entidades é uma
super-chave minimal
 O nº de cliente é minimal
 {telefone, nome} também (assumindo que podem haver várias
pessoas com o mesmo nome, com o mesmo telefone, mas
nunca com o mesmo nome e telefone)
 Chave primária é uma chave candidata designada (escolhida)
por quem projecta a base de dados para identificar as entidades
dum conjunto
 O nº de cliente é mais conveniente como chave primária por ser
mais “curta”
Database System Concepts
2.1.17
©Silberschatz, Korth and Sudarshan (Modificado)
Diagramas ER (DER)
 Permitem representar graficamente as entidades, atributos, relações,
restrições de mapeamento
 Rectângulos representam conjuntos de entidades.
 Losangos representam conjuntos de associações.
 Linhas ligam atributos aos conjuntos de entidades e conjuntos de
entidades a conjuntos de associações.
 Elipses representam atributos
 Sublinhado representa atributos constituintes da chave primária
Database System Concepts
2.1.18
©Silberschatz, Korth and Sudarshan (Modificado)
Conjs. de Relação com Atributos
Database System Concepts
2.1.19
©Silberschatz, Korth and Sudarshan (Modificado)
Restrições de Mapeamento
 As restrições de mapeamento são expressas desenhando uma
seta (), significando “um,” ou uma linha (—), significando
“muitos,” entre o conj. de relações e o conj. de entidades.
 E.g.: relação um para um:
 Um cliente está associado no máximo com um empréstimo (loan)
através da relação mutuário (borrower).
 Um empréstimo está associado no máximo com um cliente.
Database System Concepts
2.1.20
©Silberschatz, Korth and Sudarshan (Modificado)
Associações um para muitos
 Na relação um para muitos, um empréstimo está associado no
máximo com um cliente através de mutuário, enquanto que um
cliente está associado com vários empréstimos (podendo ser 0)
através de mutuário
Database System Concepts
2.1.21
©Silberschatz, Korth and Sudarshan (Modificado)
Associações muitos para muitos
 Um cliente está associado com vários empréstimos
(possivelmente 0) através de mutuário
 Um empréstimo está associado com vários clientes
(possivelmente 0) através de mutuário
Database System Concepts
2.1.22
©Silberschatz, Korth and Sudarshan (Modificado)
Papéis
 Os conjuntos de entidades participantes numa relação não são
obrigatoriamente distintos:
 As etiquetas “manager” e “worker” são designadas papéis;
especificam como as entidades employee interagem por intermédio do
conjunto de relações works-for.
 Os papéis são indicadas nos DERs anotando as linhas que ligam os
losangos aos rectângulos.
 Os papéis são opcionais, sendo utilizados para clarificar a semântica
da relação.
Database System Concepts
2.1.23
©Silberschatz, Korth and Sudarshan (Modificado)
Participação de um Conj. de Entidades
num Conj. de Relação
 Participação total (indicado por uma linha dupla): toda a entidade do
conjunto de entidades participa em pelo menos uma relação do
conjunto de relações.
 E.g. a participação de loan em borrower é total
 todo o empréstimo tem de ter um cliente associado
 Participação parcial: algumas entidades podem não participar em
qualquer relação do conjunto de relações.
 E.g. a participação de customer em borrower é parcial
Database System Concepts
2.1.24
©Silberschatz, Korth and Sudarshan (Modificado)
Conjunto de entidades fraco
 Um conjunto de entidades pode não ter atributos suficientes
para formar uma chave primária. Nesse caso é designado por
conjunto de entidades fraco.
 Exemplo: Movimentos de conta, com nº de movimento data/hora e
valor. Pode haver dois movimentos com o mesmo nº, do mesmo
valor e a mesma data/hora. Têm é que ser de contas diferentes
 A existência de um conjunto de entidades fraco depende da
existência de um conjunto de entidades dominante
 o conjunto de entidades identificador deve relacionar-se com o
conjunto de entidades fraco através de uma relação um para
muitos, total do lado do conjunto de entidades fraco.
 Exemplo: Conta é conjunto de entidades dominante de Movimentos
Database System Concepts
2.1.25
©Silberschatz, Korth and Sudarshan (Modificado)
Conjunto de entidades fraco (cont.)
 O discriminante (ou chave parcial) é o conjunto de atributos que
distingue as entidades de um conjunto fraco, associadas a uma
mesma entidade do conjunto dominante.
 Exemplo: Nº de movimento é discriminante pois, para uma mesma
conta, não pode haver dois movimentos com o mesmo nº.
 A chave primária de um conjunto de entidades fraco é
constituída pela chave primária do conjunto de entidades
dominante do qual depende e pelo discriminante do conjunto de
entidades fraco.
Database System Concepts
2.1.26
©Silberschatz, Korth and Sudarshan (Modificado)
Conjunto de Entidades Fracas (Cont.)
 Um conjunto de entidades fracas é representado por um
rectângulo duplo.
 O discriminante do conjunto de entidades fracas é sublinhado a
tracejado.
 A relação entre o conjunto fraco e o dominante é representada
por um losango duplo
Database System Concepts
2.1.27
©Silberschatz, Korth and Sudarshan (Modificado)
Conjunto de Entidades Fracas (Cont.)
 Nota: a chave primária do conjunto de entidades identificador
(ou forte) não é explicitamente representado no conjunto de
entidades fracas, dado ser implícito na associação
identificadora.
 Se loan-number fosse representado explicitamente, payment
poderia ser um conjunto de entidades fortes, mas assim a
relação entre payment e loan seria duplicada por uma
associação implícita definida pelo atributo loan-number comum a
payment e a loan
Database System Concepts
2.1.28
©Silberschatz, Korth and Sudarshan (Modificado)
Outro exemplo
 Numa operadora telefónica, um telefone é um conjunto de
entidades fortes enquanto que chamada pode ser modelada como
um conjunto de entidades fracas
 O discriminante de chamada seria data e hora
 Se modelássemos chamada como uma entidade forte teríamos de
modelar número-telefone como um atributo.
Assim a relação com telefone ficaria implícita no atributo númerotelefone
Database System Concepts
2.1.29
©Silberschatz, Korth and Sudarshan (Modificado)
Especialização/Generalização

Há entidades que são “parecidas” mas não exactamente dum mesmo conjunto.
 E.g. quer os empregados quer os clientes têm um nome, morada, telefone, etc. Mas os
empregados têm salário (e os clientes não) e os clientes tem rating de crédito (e os
empregados, enquanto tal, não).

Método de desenho descendente: designamos subgrupos dentro de um conjunto
de entidades que são distintas de outras entidades nesse conjunto
(Especialização).
 E.g. Designar subgrupo empregados e clientes dentro do conjunto mais geral de
pessoas.
 Outra maneira de ver - Método de desenho ascendente (bottom-up) – combinar num
conjunto de entidades de maior nível um certo número de conjuntos de entidades que
partilham as mesmas características

Estes subgrupos tornam-se conjuntos de entidades de menor nível que têm
atributos ou participam em relações que não se aplicam ao conjunto de entidades
de maior nível.

Desenhado por um triângulo anotado com ISA: um cliente é uma (“is a”) pessoa.

Herança de atributos – um conjunto de entidades de menor nível herda todos os
atributos e participa em todas as relações do conjunto de entidades de maior nível
ao qual está ligado.
Database System Concepts
2.1.30
©Silberschatz, Korth and Sudarshan (Modificado)
Exemplo de Especialização
Database System Concepts
2.1.31
©Silberschatz, Korth and Sudarshan (Modificado)
Restrições de Desenho para
Especialização/Generalização
 Restrição de pertença – especifica se uma entidade no conjunto
de maior nível pode ou não pertencer a mais que um conjunto
do nível inferior.
 disjuntas : só pode pertencer a um do nível inferior (anotado com a
palavra disjoint ao lado do triângulo)
 sobrepostas: pode pertencer a mais que um.
 Restrição de completude – especifica se uma entidade no
conjunto de maior nível tem ou não que pertencer a pelo menos
um dos conjuntos do nível inferior.
 total : tem de pertencer pelo menos a um (anotado com a palavra
total ao lado do triângulo)
 parcial: pode não pertencer a nenhum
Database System Concepts
2.1.32
©Silberschatz, Korth and Sudarshan (Modificado)
Agregação
 Considere:
 Um empregado pode trabalhar em vários projectos (e num projecto pode
haver vários empregados).
 Há que saber que máquinas são usadas por cada empregado em cada
projecto
 A associação com máquinas não é feita com empregados nem com
projectos. Deve é ser feita com a relação (par) empregados/projectos
 Agregação:
 Trata-se a relação como uma entidade abstracta
 Permitem-se relações entre relações (ou entre relações e entidades)
 Abstracção de uma relação numa nova entidade
Database System Concepts
2.1.33
©Silberschatz, Korth and Sudarshan (Modificado)
DER com Agregação
project
uses
tool
Database System Concepts
2.1.34
©Silberschatz, Korth and Sudarshan (Modificado)
Decisões de Desenho
 A utilização de um atributo ou conjunto de entidades para
representar um objecto.
 Se um conceito da realidade é expresso mais adequadamente
com um conjunto de entidades ou de relações.
 Utilização de um conjunto de entidades forte ou fraco.
 Utilização de especialização/generalização – contribui para a
modularidade do desenho.
 Utilização de agregação – pode tratar-se o conjunto de
entidades agregado independentemente da sua estrutura
interna.
Database System Concepts
2.1.35
©Silberschatz, Korth and Sudarshan (Modificado)
DER para um banco
Database System Concepts
2.1.36
©Silberschatz, Korth and Sudarshan (Modificado)
Sumário dos Símbolos Utilizados na
Notação ER
Database System Concepts
2.1.37
©Silberschatz, Korth and Sudarshan (Modificado)
Sumário dos Símbolos (Cont.)
Database System Concepts
2.1.38
©Silberschatz, Korth and Sudarshan (Modificado)