LEI - BD - Cap - 04 Modelo de Entidade Relacionamento

Licenciatura em Engenharia Informática
Bases de Dados
Concepção de Bases de Dados: Modelo de Entidade e Relacionamento
Marco Veloso – marco.veloso@estgoh.ipc.pt

Agenda
Diagramas de Entidade e Relacionamento

Participação e obrigatoriedade
Relacionamentos binários
1:1; 1:N; N;M
Relacionamentos binários múltiplos

Relacionamentos ternário
Diagrama conceptual e físico
Notação detalha para diagramas ER
Entidade; Entidade fraca, relacionamento, atributo, atributo chave,
atributo multivalor, atributo derivado, atributo composto, especialização
e generalização (relacionamento de herança)
Licenciatura em Engenharia Informática Bases de Dados

www.estgoh.ipc.pt Marco Veloso 2
Diagramas de Entidade-Relacionamento
Diagramas de Entidade-Relacionamento

Concepção de bases de dados relacionais pelo método de
Entidade-Relacionamento
Os diagramas de Entidade-Relacionamento (ER) são um método para

descrever a estrutura de dados adequada para uma aplicação de base
de dados.
A concepção de esquemas de dados através de diagramas ER é um
método do geral para o particular (top-down) e é, de longe, a abordagem
mais usada. Baseia-se nos seguintes passos principais:
1. Identificar todas as entidades e todos os relacionamentos importantes para
a situação a tratar;
2. Construir o diagrama de Entidade-Relacionamento (E-R);
3. Encontrar o conjunto de tabelas preliminares e identificar as respectivas
chaves primárias (feito normalmente de forma automática por ferramentas de
design);
4. Identificar todos os outros atributos relevantes e associá-los a uma das
tabelas preliminares já definidas, mantendo a solução normalizada.
5. Analisar se necessário o grau de normalização de algumas das tabelas
geradas e, se necessário, normalizar mais essas tabelas (ou o inverso).

Objectivo global – modelo conceptual

Diagrama de Entidade-Relacionamento
Professor Ensinar Disciplina
(NDoc, ...) (CodDisc, ...)
Entidade (usualmente um substantivo)

coisa relativa ao problema a tratar e sobre a qual há interesse em
guardar/manipular informação; uma entidade deve ter ocorrências e
deve ser possível identificar uma ocorrência de outra ocorrência.
Relacionamento (usualmente um verbo)

ligação entre entidades, caracterizado pelo Grau e Obrigatoriedade.
Atributo
propriedade de uma entidade
(em certos casos também de um relacionamento)

Diagrama de Entidade-Relacionamento
Entidade Relacionamento
Os nomes das entidades são normalmente substantivos

Os nomes dos relacionamento são verbos, pois representam acções
Tipicamente, os diagramas ER mostram os atributos das entidades,
abreviaturas a designar os tipos de dados, a chave primária, etc. A
aparência dos diagramas ER pode ser normalmente configurado nas
ferramentas de desenho de diagramas ER.
Diferentes formas de mostrar as entidades
Só mostra o nome das entidades
Mostra o nome e a chave primária
Mostra o nome e todos os atributos
Mostra o nome e todos os atributos,

indicando os que são obrigatórios
(M) e chave primária (pi)

Diferentes formas de mostrar as entidades
Mostra o nome, todos os

atributos e os tipos de
dados de cada atributo
Mostra também se cada

atributos é obrigatório ou
chave primária
Mostra também a lista de

identificadores (chaves
candidatas)


Diagrama de ocorrências
Exemplifica um relacionamento entre entidades simulando a existência

de algumas ocorrências das entidades e estabelecendo o
relacionamento entre essas ocorrências.
Professor Ensinar Disciplina

P1 D1
P2 D2
P3 D3
P4 D4

Relacionamentos
Os relacionamentos são caracterizados por:

Participação (ou obrigatoriedade)
Indica se o relacionamento é obrigatório ou não obrigatório. Por exemplo:
Neste caso uma disciplina relaciona-se de
forma obrigatória com um professor (tem de
ter sempre professor) mas o professor pode
não ter disciplina (não dá aulas).
Cardinalidade (ou grau)

Indica qual o grau do relacionamento (1:1, 1:N, N:M). Por exemplo:
Neste exemplo um professor pode dar mais de
um disciplina mas uma disciplina só é dada
por um professor.
Todas as combinações entre participação e cardinalidade são possíveis

num relacionamento.

Participação obrigatória: grau 1:1
P1 D1
P2 D2
P3 D3
Participação obrigatória de P4 D4
professor no relacionamento
(tem de dar uma disciplina)
P1 D1
P2 D2
P3 D3
D4
P1
D1
P2
D2
P3
D3
P4
P1 D1
P2 D2
P3 D3
P4 D4

Participação obrigatória: grau 1:N
D1
P1 D2
P2 D3
P3 D4
P4 D5
D1
P1 D2
P2 D3
P3 D4
D5
D1
P1 D2
P2
D3
P3 D4
D1
P1 D2
P2 D3
P3 D4
D5

Participação obrigatória: grau N:1
P1
D1
P2
D2
P3
P4 D3
D4
P5
P1
P2 D1
P3 D2
P4 D3
P5 D4
P1
D1
P2
P3 D2
P4 D3
P1
P2 D1
P3 D2
P4 D3
P5
Participação obrigatória: grau N:M
P1 D1
P2 D2
P3 D3
P4 D4
P5 D5
P1 D1
P2 D2
P3 D3
P4 D4
P5 D5
P1
P2 D1
P3 D2
P4 D3
P5 D4
P1 D1
P2 D2
P3 D3
P4 D4
P5 D5

Relacionamento binário de grau 1:1
Caso 1 (1:1) - participação obrigatória das duas entidades

Diagrama ER
Diagrama Físico
Estas duas tabelas podem (e devem) fundir-se numa única tabela

Regra 1

e participação obrigatória de ambas entidades
É apenas necessária uma tabela;
A chave primária dessa relação pode ser a chave primária

de qualquer das entidades.
Raramente se verifica. Ambas as entidades formam uma única entidade (embora
sejam distintas), gerando assim uma única tabela.

Caso 2 (1:1) - participação obrigatória de apenas uma das

entidades
(Professor tem de leccionar uma disciplina)
Diagrama ER
Diagrama Físico
São necessárias duas tabelas. A tabela Professor tem uma chave

estrangeira que a liga à tabela Disciplina
Regra 2
Relacionamento binário de grau 1:1 e participação

obrigatória de apenas uma das entidades
São necessárias duas tabelas, uma para cada entidade;
A chave primária de cada entidade serve de chave primária na

tabela correspondente;
A chave primária da entidade com participação não obrigatória

tem de ser usada como atributo na tabela correspondente à
entidade cuja participação é obrigatória (chave forasteira).

Caso 3 (1:1) - participação obrigatória de nenhuma das

entidades
Diagrama ER
Diagrama Físico

Regra 3

e participação não obrigatória de ambas entidades
São necessárias três tabelas, uma para cada entidade e a

terceira para o relacionamento;

A tabela correspondente ao relacionamento terá entre os seus

atributos as chaves primárias das duas entidades (chaves
forasteiras).

Relacionamento binário de grau 1:N
Caso 4 (1:N) - participação obrigatória do lado N

(disciplina tem de ter sempre um professor)
Diagrama ER
Diagrama Físico
São necessárias duas tabelas. A tabela Disciplina tem uma chave

estrangeira que a liga à tabela Professor
Regra 4

e participação obrigatória do lado N
São necessárias duas tabelas, uma para cada entidade;

A chave primária da entidade do lado 1 tem de ser usada como

atributo na tabela correspondente à entidade do lado N (chave
forasteira).

Caso 5 (1:N) - participação não obrigatória do lado N

Diagrama ER
Diagrama Físico

Regra 5

e participação não obrigatória do lado N
São necessárias três tabelas, uma para cada entidade e uma

terceira para o relacionamento;
A chave primária de cada entidade serve de chave primária

na tabela correspondente (a cada entidade);
A tabela relativa ao relacionamento terá de ter entre os seus

atributos as chaves primárias de cada uma das entidades
(chaves forasteiras).

Relacionamento binário de grau M:N
Caso 6 (M:N)
Diagrama ER
Diagrama Físico
Quando o grau de relacionamento binário é do tipo M:N,

independentemente do tipo de participação ser obrigatório ou não, são
sempre necessárias três tabelas.
Regra 6
Relacionamento binário de grau M:N
São sempre necessárias três tabelas, uma para cada entidade e

uma terceira para o relacionamento;

A tabela relativa ao relacionamento terá de ter entre os seus

atributos as chaves primárias de cada uma das entidades
(chaves forasteiras).


Na grande maioria dos casos, uma entidade pode ter relacionamentos

binários com diversas entidades, ou seja, relacionamentos binários
múltiplos.
Diagrama ER
Diagrama Físico

Diagrama de ocorrências em
relacionamentos binários múltiplos
Exemplo: base de dados dos docentes da escola

(Diagrama de ocorrências)
Gabinete Professor Disciplina

Silva
Gab01 PA
Sousa
Gab02 ALGA
Martins
Gab03 BD
Amaro
Gab04 EPPA
Conceição
GP

Esquema de base de dados em
relacionamentos binários múltiplos
2 tabelas 3 tabelas
1 N N M
Gab Ocupar Prof Lecionar Disc
(Codigo, ...) (NumFunc, ...) (CodDisc, ...)
Gabinete (Codigo, Tipo, Observações)

Professor (NumFunc, Nome, Grau_Académico, Categoria)
Prof_Disc (Codigo, NumFunc)
Disciplina (CodDisc, Nome, Nível, Programa)

Exemplo de um diagrama conceptual simples
PART LINEITEM
P_PART N10 <M> L_LINENUMBER N10 <M>
PARTSUPP L_QUANTITY N10,2 <M>
P_NAME VA55 <M>
P_MFGR A25 PS_AVAILQTY N10 <M> L_EXTENDEDPRICE N10,2
P_BRAND A10 PS_SUPPLYCOST N10,2 <M> L_SHIPDATE DT
P_TYPE VA25 PS_COMMENT VA199 <M> L_RECEIPTDAT DT
P_SIZE N10 L_COMMENT VA44
P_RETAILPRICE N10,2 <M> L_LINENUMBER
P_COMMENT VA23
P_PART
SUPPLIER
ORDERS
S_SUPKEY N10 <M>
S_NAME A25 <M> O_ORDERKEY N10 <M>
S_ADDRESS VA40 <M> O_TOTALPRICE N10,2 <M>
S_PHONE A15 O_ORDERDATE DT <M>
S_ACCTBALL N10,2 <M> O_COMMENT VA79
S_COMMENT VA101 O_ORDERKEY
S_SUPKEY
CUSTOMER
C_CUSTKEY N10 <M>
NATION C_NAME VA25 <M>
C_ADDRESS VA40 <M>
N_NATIONKEY N10 <M>
C_PHONE A15
N_NAME A25 <M>
C_ACCTBALL N10,2 <M>
N_COMMENT VA152
C_MKTSEGMENT A10
N_NATIONKEY C_COMMENT VA117
C_CUSTKEY
REGION
R_REGIONKEY N10 <M>
R_NAME A25 <M>
R_COMMENT VA152
R_REGIONKEY

Exemplo de um diagrama físico simples

Exemplo de um diagrama conceptual completo

Exemplo de um diagrama físico completo

Notação detalhada para diagramas ER
Notação detalhada para diagramas ER

Esquema conceptual usando diagramas ER
Objectivo
Representar o “mundo” do problema a tratar, descrevendo todos
os dados a armazenar na base de dados, os seus tipos,
relacionamentos e restrições.
Limitações
Os diagramas ER, tal como os vimos até agora, não conseguem
representar todas as situações que surgem em casos reais.
É necessário desenvolver o modelo ER

Diagramas ER: notação mais detalhada
Entidade
Entidade fraca
Relacionamento
Relacionamento identificador
Atributo
Atributo chave
Atributo multivalor
Atributo derivado
Atributo composto

Atributos
NPróprio Apelido
Nome Localizações
Sexo Morada
Número
BI
N 1
Empregado Trabalha Departamento N_Empregados
Salário
Tipos de Atributos
Simples (e.g., Salário)
Compostos (e.g., Nome)
Multivalor (e.g., Localizações)
Derivados (e.g., N_Empregados)

Atributos compostos
Um dado atributo pode ser considerado simples ou composto, dependendo

da situação a tratar e da utilização pretendida para a base de dados.
Número
Rua
NPróprio Apelido Andar
Lote
Nome
Morada
Sexo
Cidade
BI Código postal
Empregado
Salário
Um atributo composto entra na tabela correspondente à entidade com

todos os seus atributos básicos.
e.g.: Empregado ( BI, NPróprio, Apelido, Sexo, Salário, Morada )

Atributos multivalor
Localizações
DNome DNúmero
K
Departamento (DNúmero, DNome, ...)
Departamento
Loc (DNúmero, Localização)
R K A
Para cada atributo multivalor A cria-se uma tabela R contendo esse atributo.
Esta tabela conterá também o atributo (ou atributos) K que constituem a

chave primária da entidade, sendo K uma chave estrangeira de R.
A chave primária de R é a combinação de A e K.
No caso de atributo multivalor ser composto a tabela R conterá todos os

seus atributos elementares

Atributos derivados
Localizações
Número
Atributo derivado
directo
Departamento Tempo_laboração
Data_Início_activ N_Empregados Atributo derivado de outra

entidade relacionada com
Departamento
Todos os atributos derivados importantes para o problema devem ser

identificados durante a análise.
Estes atributos são posteriormente incluídos em vistas

Entidades Fracas
As entidades fracas não têm, naturalmente, atributos que possam

constituir chaves candidatas e a identificação de instâncias
específicas destas entidades depende sempre de outra entidade,
designada por entidade identificadora.
Entidade Identificadora Relacionamento Identificador Entidade Fraca

(dependent no Power Designer)
Chave parcial
Atributo ou conjunto de atributos que permitem identificar
univocamente uma ocorrência da entidade fraca para uma dada
ocorrência da entidade identificadora
(e.g., Nome é chave parcial de Dependente)
Tabelas para Entidades Fracas
Entidades Fracas
Para cada entidade fraca EF é criada uma tabela contendo todos os
atributos de EF.
Esta tabela deve incluir também, como chave estrangeira, o atributo que é
chave primária da entidade identificadora.
A chave primária da tabela da EF é a combinação de da chave parcial
da EF e do atributo que é chave primária da entidade identificadora.

Relacionamento recursivos
Diagrama ER
Um determinado empregado pode

chefiar outros empregados.
Diagrama Físico
O esquema físico corresponde à

mesma tabela à qual é acrescentada
uma chave estrangeira

Subclasses, Superclasses e Especialização
(generalização do conceito de papéis)
Especialização:
processo de definição de subclasses de uma entidade;

essa entidade (a partir da qual se definem subclasses) designa-
se por superclasse.
Há um relacionamento entre uma superclasse e as suas

subclasses
As sub-entidades herdam os atributos e os relacionamentos

da super-entidade.

Exemplo de Especialização
Predicado (atributo Tipo) Super-entidade

que identifica a que tipo
pertence cada ocorrência da
super-entidade. Relacionamento de herança.
A cruz indica que é
Este atributo pode ser mutuamente exclusivo (ou é
omitido. aluno ou professor, mas não os
dois ao mesmo tempo)
As Sub-entidades ou Sub-classes
herdam todos os atributos da
Sub-entidades superclasse;
herdam todos os relacionamentos da
superclasse
Algumas regras para inserções e apagamentos
Apagar uma ocorrência da superentidade obriga a apagá-la

automaticamente de todas as subclasses a que a ocorrência
pertence;
Inserir uma nova ocorrência numa superentidade com
especialização obrigatória obriga a inseri-la em pelo menos uma
das subclasses;
Inserir uma nova ocorrência numa superentidade com
especialização definida por predicados obriga a inserí-la em todas
as subclasses que satisfazem o predicado;
Ao inserir uma ocorrência numa superentidade com especialização
disjunta é necessário garantir que a ocorrência é apenas inserida
numa das subclasses;
(…)

Definição de tabelas para relacionamentos
do tipo Subclasse/Superclasse
Não há uma regra fixa: há um conjunto de alternativas (3);
Cabe ao projectista escolher, para cada caso, a alternativa

que produz o conjunto de tabelas mais adequado.

Alternativa A: Relacionamentos Subclasse/Superclasse
1. Uma tabela para a superclasse com os atributos

específicos da superclasse;
2. Uma tabela para cada subclasse com os atributos
específicos de cada subclasse;
3. A chave primária da superclasse fica em todas as tabelas
relativas às subclasses, onde é simultaneamente chave
forasteira e chave primária.
Usa-se geralmente quando o número de atributos específicos de cada

subclasse é grande, tendo também a superclasse bastantes
atributos.
Pode usar-se qualquer que seja o tipo de relacionamento (disjuntos ou
sobreposto) e de participação (obrigatória ou não).

Exemplo da alternativa A
O tipo de relacionamento (mutuamente

exclusivo ou não) e a participação
(obrigatória ou não) só são usados nas
verificações de integridade.

Alternativa B: Relacionamentos Subclasse/Superclasse
Alternativa
1. Uma B (regra)
tabela para cada subclasse;
2. Cada tabela contém todos os atributos da superclasse e
os atributos específicos da sua subclasse;
3. A chave primária de cada tabela é a chave primária da
superclasse.
Só se aplica em relacionamentos disjuntos com participação

obrigatória.
Neste tipo de relacionamentos esta regra deve usar-se (em vez da
alternativa A) quando o número de atributos da superentidade é
pequeno.

Exemplo da alternativa B
O conjunto de todas as ocorrências

(registos) da super-entidade
Equipamento pode obter-se pela
união das duas sub-entidades que
se constituem em tabelas.

Alternativa C: Relacionamentos Subclasse/Superclasse
1. Uma única tabela para a superclasse e para todas as

subclasses.
2. A chave primária da tabela é a chave primária da
superclasse.
Nesta alternativa a tabela contém valores nulos (não está normalizada).

Praticamente só se usa quando cada subclasse tem poucos atributos
específicos (um ou dois) e não participa noutros relacionamentos com
outras entidades.

Referências
“Bases de Dados”
Henrique Madeira
Departamento de Engenharia Informática, Universidade de Coimbra
"Database Management Systems“

Raghu Ramakrishnan, Johannes Gehrke
McGraw-Hill, ISBN: 0072465638

Bibliografia complementar
"Database Systems: The Complete Book"

Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer D. Widom
Prentice Hall, ISBN: 0131873253
“Tecnologias de Bases de Dados”

José Luis Pereira
FCA, ISBN: 9727221432


LEI - BD - Cap - 04 Modelo de Entidade Relacionamento

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

LEI - BD - Cap - 04 Modelo de Entidade Relacionamento

Enviado por

Direitos autorais:

Formatos disponíveis

Licenciatura em Engenharia Informática

Marco Veloso – marco.veloso@estgoh.ipc.pt

Diagramas de Entidade e Relacionamento

Relacionamentos binários múltiplos

Licenciatura em Engenharia Informática Bases de Dados

Licenciatura em Engenharia Informática Bases de Dados

Os diagramas de Entidade-Relacionamento (ER) são um método para

Licenciatura em Engenharia Informática Bases de Dados

Licenciatura em Engenharia Informática Bases de Dados

Professor Ensinar Disciplina

(NDoc, ...) (CodDisc, ...)

Entidade (usualmente um substantivo)

Relacionamento (usualmente um verbo)

Licenciatura em Engenharia Informática Bases de Dados

Os nomes das entidades são normalmente substantivos

Só mostra o nome das entidades

Mostra o nome e a chave primária

Mostra o nome e todos os atributos

Mostra o nome e todos os atributos,

Licenciatura em Engenharia Informática Bases de Dados

Mostra o nome, todos os

Mostra também se cada

Mostra também a lista de

Licenciatura em Engenharia Informática Bases de Dados

Licenciatura em Engenharia Informática Bases de Dados

Exemplifica um relacionamento entre entidades simulando a existência

Professor Ensinar Disciplina

Licenciatura em Engenharia Informática Bases de Dados

Os relacionamentos são caracterizados por:

Cardinalidade (ou grau)

Todas as combinações entre participação e cardinalidade são possíveis

Licenciatura em Engenharia Informática Bases de Dados

Licenciatura em Engenharia Informática Bases de Dados

Licenciatura em Engenharia Informática Bases de Dados

Licenciatura em Engenharia Informática Bases de Dados

Caso 1 (1:1) - participação obrigatória das duas entidades

Estas duas tabelas podem (e devem) fundir-se numa única tabela

Relacionamento binário de grau 1:1

É apenas necessária uma tabela;

A chave primária dessa relação pode ser a chave primária

Licenciatura em Engenharia Informática Bases de Dados

Caso 2 (1:1) - participação obrigatória de apenas uma das

São necessárias duas tabelas. A tabela Professor tem uma chave

Relacionamento binário de grau 1:1 e participação

São necessárias duas tabelas, uma para cada entidade;

A chave primária de cada entidade serve de chave primária na

A chave primária da entidade com participação não obrigatória

Licenciatura em Engenharia Informática Bases de Dados

Caso 3 (1:1) - participação obrigatória de nenhuma das

Licenciatura em Engenharia Informática Bases de Dados

Relacionamento binário de grau 1:1

São necessárias três tabelas, uma para cada entidade e a

A chave primária de cada entidade serve de chave primária na

A tabela correspondente ao relacionamento terá entre os seus

Licenciatura em Engenharia Informática Bases de Dados

Caso 4 (1:N) - participação obrigatória do lado N

São necessárias duas tabelas. A tabela Disciplina tem uma chave

Relacionamento binário de grau 1:N

São necessárias duas tabelas, uma para cada entidade;

A chave primária de cada entidade serve de chave primária na

A chave primária da entidade do lado 1 tem de ser usada como

Licenciatura em Engenharia Informática Bases de Dados

Caso 5 (1:N) - participação não obrigatória do lado N