O documento discute conceitos importantes de projeto de banco de dados, incluindo: 1) As noções de entidades e relacionamentos podem ser definidas de diferentes maneiras; 2) Objetos podem ser modelados como entidades ou atributos dependendo da situação; 3) A estrutura da empresa real deve ser considerada ao projetar o banco de dados.

1. Banco de Dados I
Projeto de Banco de Dados e o
Modelo E-R – Parte 2
Fabricio Breve

2. Aspectos de projeto de entidade-
relacionamento
• As noções de um conjunto de entidades e
um conjunto de relacionamento não são
precisas, e é possível definir um conjunto
de entidades e os relacionamentos entre
eles de diversas maneiras

3. Uso de conjunto de entidades
versus atributos
• Considere o conjunto:
– Id_funcionario, nome_funcionario,
numero_telefone
• numero_telefone pode ser uma entidade com seus
próprios atributos: numero_telefone e local
(escritório, casa, etc...)
• Tratar telefone como entidade modela melhor uma
situação em que se pode querer manter
informações extras sobre o telefone
– local, tipo, pessoas que o compartilham

4. Uso de conjunto de entidades
versus atributos
• O que constitui um atributo?
• O que constitui um conjunto de entidades?
– Depende!
• Qual a estrutura da empresa real?
• Qual o significado associado?

5. Uso de conjunto de entidades versus
conjunto de relacionamentos
• Nem sempre é claro se um objeto é mais bem
expresso por um conjunto de entidades ou por
um conjunto de relacionamento
– Em nosso exemplo do banco, o empréstimo poderia
ser uma relação entre cliente e agência
• É satisfatório se um cliente puder fazer apenas um
empréstimo por agência e um empréstimo pertencer a
apenas um cliente
• Caso contrário, é problemático

6. Conjunto de relacionamentos binários
versus enários
• Alguns relacionamentos ternários são
melhor representados por dois
relacionamentos binários
– Exemplo: relacionamento ternário pais,
relacionando um filho aos seus pais

7. Convertendo relacionamentos não
binários para a forma binária
n Em geral, qualquer relacionamento não binário pode ser representado usando
relacionamentos binários criando um conjunto de entidades artificial.
l Substitua R entre os conjuntos de entidades A, B e C por um conjunto de
entidades E três conjuntos de relacionamento:
1. RA, relacionando E e A
2. RB, relacionando E e B
3. RC, relacionando E e C
l Crie um atributo identificador especial para E
l Inclua quaisquer atributos de R em E
l Para cada relacionamento (ai , bi , ci) em R,
1. crie uma nova entidade ei no conjunto de entidades E
2. inclua (ei , ai ) em RA
3. inclua (ei , bi ) em RB
4. inclua (ei , ci ) em RC

8. Cardinalidades de mapeamento afetam
o projeto ER
n Podemos tornar a data de acesso um atributo de conta, em vez de um
atributo de relacionamento, se cada conta puder ter apenas um cliente
l Ou seja, o relacionamento de conta para cliente é muitos-para-um ou,
equivalentemente, cliente para conta é um-para-muitos

9. Conjunto de Entidades Fracos
• É um conjunto de entidades que não tem atributos suficientes para
formar uma chave primária
• A existência de um conjunto de entidades fraco depende da
existência de um conjunto de entidades identificador (ou
proprietário)
– Ele precisa se relacionar com o conjunto de entidades identificador
através de um conjunto de relacionamento um-para-muitos total, do
identificador para o conjunto de entidades fraco
– Relacionamento identificador descrito usando um losango duplo
• O discriminador (ou chave parcial) de um conjunto de entidades
fraco é o conjunto de atributos que distingue entre todas as
entidades de um conjunto de entidades fraco.
• A chave primária de um conjunto de entidades fraco é formada pela
chave primária do conjunto de entidades forte em que o conjunto de
entidades fraco é dependente de existência, mais o discriminador
do conjunto de entidades fraco.

10. Conjuntos de Entidades Fracos
n Representamos um conjunto de entidades fraco por retângulos duplos.
n Sublinhamos o discriminador de um conjunto de entidades fraco com
uma linha tracejada.
n número_pagamento — discriminador do conjunto de entidades
pagamento.
n Chave primária para pagamento — (número_empréstimo,
número_pagamento)

11. Conjuntos de Entidades Fracos
n Nota: A chave primária do conjunto de entidades forte não é
explicitamente armazenada com o conjunto de entidades fraco, já
que ela está implícita no relacionamento identificador.
n Se número_empréstimo fosse explicitamente armazenado,
pagamento poderia se tornar uma entidade forte, mas, então, o
relacionamento entre pagamento e empréstimo seria duplicado
por um relacionamento implícito definido pelo atributo
número_empréstimo comum a pagamento e empréstimo.

12. Especialização
• Processo de projeto de cima para baixo: Designamos
subagrupamentos dentro de um conjunto de entidades que são
distintivos de outras entidades no conjunto.
• Esses subagrupamentos se tornam conjuntos de entidades de
nível inferior que possuem atributos ou participam em
relacionamentos que não se aplicam ao conjunto de entidades
de nível superior.
• Representada por um componente triângulo rotulado ISA (por
exemplo, cliente “é uma” pessoa).
• Herança de atributo — Um conjunto de entidades de nível
inferior herda todos os atributos e a participação de
relacionamento do conjunto de entidades de nível superior ao
qual está vinculado.

13. Exemplo de Especialização

14. Generalização
• Combina vários conjuntos de entidades que
compartilham os mesmos recursos em um
conjunto de entidades de nível superior.
• A especialização e a generalização são simples
inversões uma da outra; são representadas em
um diagrama ER da mesma maneira.
• Os termos especialização e generalização são
usados indistintamente.

15. Restrições em generalizações
• Restrição sobre que entidades podem ser membros de um
determinado conjunto de entidades de nível inferior
– Definido por condição
• Exemplo: Todos os clientes com mais de 65 anos são membros do conjunto
de entidades cidadão_senior; cidadão_senior ISA pessoa.
– Definido pelo usuário
• Restrição sobre se ou não as entidades podem pertencer a mais de
um conjunto de entidades de nível inferior dentro de uma única
generalização.
– Disjuntos
• uma entidade pode pertencer a não mais que um conjunto de entidades de
nível inferior
• Indicados no diagrama ER pela inscrição de disjunto ao lado do triângulo
ISA
– Superpostos
• um conjunto de entidades pode pertencer a mais de um conjunto de
entidades de nível inferior

16. Restrições em generalizações
• Restrição de integralidade — Especifica
se ou não uma entidade no conjunto de
entidades de nível superior precisa
pertencer a pelo menos um dos conjuntos
de entidades de nível inferior dentro de
uma generalização
– total: Uma entidade precisa pertencer a um
conjunto de entidades de nível inferior
– parcial: Uma entidade não precisa pertencer
a um conjunto de entidades de nível inferior

17. Agregação
• Considere o relacionamento ternário trabalha_em, que
vimos anteriormente
• Suponha que queremos registrar gerentes para tarefas
realizadas por um funcionário em uma agência

18. Agregação
• Os conjuntos de relacionamento trabalha_em e gerencia
representam informações superpostas
– Cada relacionamento gerencia corresponde a um relacionamento
trabalha_em
– Entretanto, alguns relacionamentos trabalha_em podem não
corresponder a nenhum relacionamentos gerencia
• Portanto, não podemos descartar o relacionamento trabalha_em
• Elimine essa redundância através da agregação
– Trate relacionamento como uma entidade abstrata
– Permite relacionamentos entre relacionamentos
– Abstração de relacionamento em nova entidade
• Sem introduzir redundância, o diagrama a seguir representa:
– Um funcionário trabalha em um cargo específico em uma agência
específica
– Um funcionário, agência ou combinação de cargos pode ter um gerente
associado

19. Agregação

20. Exemplo de
diagrama ER para
uma instituição
bancária

21. Resumo dos símbolos usados na
notação ER (Silberschatz)

22. Resumo dos símbolos (cont.)

23. Notações ER alternativas

24. Notação BRModelo
muitos-para-muitos
um-para-um
muitos-para-um
* Indicação de Cardinalidade mínima e máxima

25. Referências Bibliográficas
• SILBERSCHATZ, Abraham; KORTH,
Henry F.; SUDARSHAN, S. Sistema de
Banco de Dados. 5ª Ed. Campus, 2006
• PONTI JR, Moacir. Banco de Dados:
Introdução - Notas de Aula. 2006.