Você está na página 1de 58

Transformaes entre

Modelos
Disciplina: Banco de Dados
Prof. Handerson Medeiros

O qu vamos aprender hoje:


Transformaes

entre modelos

1:1

Transformaes entre
modelos

Transformaes entre
modelos

Projeto lgico

Projeto lgico

Transformao ER para
relacional
Regras

gerais:

Aplicveis maioria dos casos;


Implementadas em ferramentas CASE.
ferramentas baseadas em computadores que auxiliam atividades
de engenharia de software

situaes em que:

por exigncias da aplicao, outros mapeamentos so

usados.
Objetivos

bsicos:

Boa performance
Simplificao do desenvolvimento
7

Princpios por traz das regras


de traduo
1.
2.
3.

Evitar junes
Diminuir o nmero de chaves
Evitar campos opcionais

Juno
Juno
Operao para buscar dados de diversas

linhas associadas pela igualdade de


campos
exemplo:
buscar os dados de um empregado e os

dados de seu departamento (duas


tabelas diferentes)
9

Juno
Minimizar

junes

SGBD

relacional normalmente armazena os


dados de uma linha contiguamente em
disco.

Juno

envolve diversos acessos a disco.

Prefervel:
ter os dados necessrios a uma consulta em

uma nica linha.


10

Diminuir o nmero de
chaves
Usar

implementaes com menos


chaves.

11

Campos opcionais
Campo

opcional campo que pode


assumir o valor VAZIO (NULL em
SQL).

SGBD

relacional no desperdia
espao pelo fato de campos de uma
linha estarem vazios.
Campo opcional no tem influncia no

desempenho.
12

Campos opcionais
Evitar

campos opcionais;
Controle de campo opcional pode
complicar programao:
Verificar quais campos podem estar

vazios, quando isto depende do tipo de


linha.

13

Passos da transformao
ER para relacional
Traduo inicial de entidades e
respectivos atributos;
2. Traduo de relacionamentos e
respectivos atributos;
3. Traduo de
generalizaes/especializaes.
1.

14

Implementao inicial de
entidades
Cada

entidade traduzida para uma


tabela.
Cada atributo da entidade define
uma coluna desta tabela.
Atributos identificadores da entidade
correspondem a chave primria da
tabela.

15

Implementao inicial de
entidades

16

Implementao inicial de
entidades

17

Traduo de entidade
relacionamento identificador

18

Traduo de entidade
relacionamento identificador

19

Relacionamento identificador
recurso

20

Relacionamento identificador
recurso

21

Relacionamento identificador
recurso

22

Relacionamento identificador
recurso

23

Relacionamento identificador
recurso

24

Relacionamento identificador
recurso

25

Nomes de atributos e nomes


de colunas
Manter

os nomes de colunas curtos.

Nome

de uma coluna no pode


conter espaos.

Nomes

de atributos compostos de
diversas palavras devem ser
abreviados.
26

Nomes de atributos e nomes


de colunas
Nomes

de colunas no necessitam
conter o nome da tabela:
Prefervel usar o nome de coluna Nome

a usar os nomes de coluna NomePess


ou NomePessoa.
SQL j exige muitas vezes a forma:
Pessoa.Nome

Exceo: chave primria (ver a seguir)

27

Nome da coluna chave


primria
Chave

primria:

pode aparecer em outras tabelas na forma de

chave estrangeira.
Recomendvel:
nomes das colunas que compem a chave

primria:
Sufixados ou prefixados com o nome ou sigla da
tabela na qual aparecem como chave primria.

Exemplo
CodigoPess
28

Implementao de
relacionamento alternativas
Tabela prpria
Adio de colunas a uma das
tabelas
3. Fuso de tabelas
1.
2.

.Alternativa

depende da
cardinalidade (mxima e mnima do
relacionamento)
29

Tabela prpria

30

Implementao de
relacionamento alternativas

31

Tabela prpria

32

Adio de colunas

33

Adio de colunas

34

Adio de colunas

35

Fuso de tabelas

36

Fuso de tabelas

37

Implementao de
relacionamentos 1:1

38

1:1 Ambas entidades opcionais

39

1:1 - ambas opcionais


adio de colunas

40

1:1 - ambas opcionais


adio de colunas

41

1:1 - ambas opcionais


tabela prpria

42

1:1 - ambas opcionais


fuso de tabelas

43

1:1 - ambas opcionais


discusso
Soluo

por fuso de tabelas invivel:

Chave primria artificial.


composta por um atributo que no representa nenhuma
propriedade do negocio, geralmente um numero
seqencial criado unicamente para manter a unicidade e
identificar a instncia de uma entidade.

Soluo

por adio de colunas melhor:

Menor nmero de junes;


Menor nmero de chaves.

Soluo

por tabela prpria aceitvel.


44

1:1 - ambas opcionais

45

1:1 - uma entidade opcional,


outra obrigatria

46

1:1 - opcional/obrigatria
fuso de tabelas

47

1:1 - opcional/obrigatria
adio de colunas

48

1:1 - opcional/obrigatria
tabela prpria

49

1:1 - opcional/obrigatria
discusso
Soluo

por tabela prpria pior que


a soluo por adio de colunas:
Maior nmero de junes;
Maior nmero de ndices;
Nenhuma tem problema de campos

opcionais.

50

1:1 - opcional/obrigatria
discusso
Adio

de colunas versus fuso de


tabelas:
Fuso de tabelas melhor em termos de

nmero de junes e nmero de chaves;


Adico de colunas em melhor em termos
de campos opcionais;
Fuso de tabelas considerada a melhor
e adio de colunas aceitvel.

51

1:1 - opcional/obrigatria
tabela prpria

52

1:1 - ambas entidades


obrigatrias

53

1:1 - ambas entidades obrigatrias


fuso de tabelas

54

1:1 - ambas entidades


obrigatrias
Demais

alternativas (adio de colunas, tabela


prpria).
Nenhuma das demais alternativas atende

plenamente.
Em

ambas:

Entidades que participam do relacionamento seriam

representadas atravs de duas tabelas distintas.


Estas tabelas teriam a mesma chave primria e
relao um-para-um entre suas linhas.
Maior nmero de junes.
Maior nmero de chaves primrias
55

1:1 - ambas entidades


obrigatrias

56

Referncias

57

Dvidas

58

Você também pode gostar