MODELAGEM CONCEITUAL DE DADOS

Unidade IV – Derivação do Modelo Lógico

Prof. Maria Teresa Marino

Licenciatura em Computação/Sistema de Informação
FEUC

Maria Teresa Marino 1

 Transformações entre modelos

Modelo ER
(Conceitual)

Ciclo de re-
Engenharia engenharia de
reversa de BD Projeto lógico
BD de BD relacional
relacional

Modelo relacional
(Lógico)

Maria Teresa Marino 2

 Projeto Lógico
Modelo ER
(Conceitual)
Conhecimento
sobre a aplicação
Transformação
ER para
relacional

Refinamento
do modelo Modelo relacional
relacional (nível lógico)

Maria Teresa Marino 3

 Transformação ER para o BD relacional

• Regras gerais
– Aplicáveis a maioria dos casos
– Há situações
• Por exigências da aplicação, outros mapeamentos são usados
– Implementados em ferramentas CASE
• Objetivos básicos
– Boa performance
– Simplificar o desenvolvimento

Maria Teresa Marino 4

 Regras gerais de tradução

• Evitar junções
• Diminuir o número de chaves
• Evitar campos opcionais

Maria Teresa Marino 5

 Junção

• Operação para buscar dados de diversas linhas

associadas pela igualdade de campos
• Exemplo:
– Buscar os dados de um empregado e os dados do seu
departamento (duas tabelas diferentes)

Maria Teresa Marino 6

 Evitar junção

• SGBD normalmente armazena os dados de uma

linha contiguamente em disco
• Junção envolve diversos acessos a disco
• Preferível
– Ter os dados necessários a uma consulta em uma única
linha

Maria Teresa Marino 7

 Chaves e índices

• Implementação eficiente do controle de chaves:

SGBD usa um índice:
– Índices tendem a ocupar espaço considerável em disco
• Inserção e remoção de entradas em um índice
– Podem exigir diversos acessos a disco
• Chaves
– Diminuir o número de chaves

Maria Teresa Marino 8

 Campos opcionais

• Campo opcional = campo que pode assumir o

valor VAZIO (NULL em SQL)
• SGBD não desperdiça espaço pelo fato de campos
de uma linha estarem vazios
• Campo opcional não tem influência na
performance
• Evitar campos opcionais
– Controle de campo opcional pode dificultar
programação

Maria Teresa Marino 9

 Passos da transformação ER para relacional

• Tradução inicial das entidades e respectivos

atributos
• Tradução de relacionamentos e respectivos
atributos
• Tradução de generalizações/especializações

Maria Teresa Marino 10

 Implementação inicial de entidades

• Cada entidade é traduzida em uma tabela

• Cada atributo da entidade define uma coluna
desta tabela
• Atributos identificadores da entidade
correspondem a chave primária da tabela
• Tradução inicial:
– Regras que seguem podem fundir tabelas

Maria Teresa Marino 11

 Implementação de entidade - exemplo

data de
código
admissão
PESSOA nome
data de endereço
nascimento

Pessoa(CodigoPess,Nome,Endereço,DataNasc, DataAdm)

Maria Teresa Marino 12

 Nome de colunas

• Referenciados freqüentemente em programas e em

outras formas de texto em computador
• Para diminuir o trabalho de programadores
– Manter os nomes de colunas curto
• SGBD relacional
– Nome de uma coluna não pode conter brancos

Maria Teresa Marino 13

 Nomes de atributos e nomes de colunas

• Não transcrever os nomes de atributos para nomes

de colunas
• Nomes de atributos compostos por diversas
palavras devem ser abreviados
• Nomes de colunas não precisam conter o nome da
tabela
– Preferível usar o nome de coluna Nome a usar os
nomes de coluna NomePess ou NomePessoa
• SQL já exige muitas vezes a forma
– Pessoa.nome

Maria Teresa Marino 14

 Nome da coluna chave primária

• Chave primária
– Pode aparecer em outras tabelas na forma de chave
estrangeira
• Recomendável
– Nome das colunas que compõem a chave primária
• Sufixados ou prefixados com o nome ou sigla da tabela na
qual aparecem como chave primária
– Exemplo:
• CodigoPess

Maria Teresa Marino 15

 Implementação de relacionamentos –
alternativas

• Tabela própria
• Adição de colunas a uma das tabelas
• Fusão de tabelas

Alternativa depende da cardinalidade

(máxima e mínima do relacionamento)

Maria Teresa Marino 16

 Implementação de relacionamentos 1:1-
ambas entidades opcionais

(0,1) (0,1)
HOMEM casamento MULHER

identidade regime identidade

nome nome
data

Maria Teresa Marino 17

 Relacionamentos 1:1 ambas entidades opcionais
adição de colunas
(0,1) (0,1)
HOMEM casamento MULHER

identidade regime identidade

nome nome
data

Mulher (IdentM,Nome,IdentH,Data,Regime)

IdentH referencia Homem

Homem (IdentH,Nome)

Maria Teresa Marino 18

 Relacionamentos 1:1 ambas entidades opcionais
tabela própria
(0,1) (0,1)
HOMEM casamento MULHER

identidade regime identidade

nome nome
data
Mulher (IdentM,Nome)
Homem (IdentH,Nome)
Casamento (IdentM,IdentH,Data,Regime)
IdentM referencia Mulher
IdentH referencia Homem

Maria Teresa Marino 19

 Relacionamentos 1:1 ambas entidades opcionais
fusão de tabelas
(0,1) (0,1)
HOMEM casamento MULHER

identidade regime identidade

nome nome
data

Casamento (IdentM,IdentH,NomeM,NomeH,Data,Regime)

Maria Teresa Marino 20

 Relacionamentos 1:1 – ambas opcionais

• Solução por fusão de tabelas é inviável

– Chave primária artificial
• Solução por adição de colunas é melhor
– Menor número de junções
– Menor número de chaves
• Solução por tabela própria aceitável

Maria Teresa Marino 21

 Relacionamento 1:1 – uma entidade
obrigatória outra opcional
(0,1) (1,1)
CORRENTISTA tem CARTÃO

código código
nome Data exp

Maria Teresa Marino 22

 Relacionamento 1:1 – obrigatória/opcional
fusão de tabelas
(0,1) (1,1)
CORRENTISTA tem CARTÃO

código código
nome Data exp

Correntista (CodCorrent,Nome,CodCartão, DataExp)

Maria Teresa Marino 23

 Relacionamento 1:1 – obrigatória/opcional
adição de colunas
(0,1) (1,1)
CORRENTISTA tem CARTÃO

código código
nome Data exp

Correntista (CodCorrent,Nome)

Cartão (CodCartão,DataExp,CodCorrent)
CodCorrent referencia Correntista

Maria Teresa Marino 24

 Relacionamento 1:1 – obrigatória/opcional
tabela própria
(0,1) (1,1)
CORRENTISTA tem CARTÃO

código código
nome Data exp

Correntista (CodCorrent,Nome)
Cartão (CodCartão,DataExp)
CartãoCorrentista (CodCartão,CodCorrent)
CodCorrent referencia Correntista
CodCartão referencia Cartão

Maria Teresa Marino 25

 Relacionamento 1:1 – opcional/obrigatória

• Solução por tabela própria é pior que a solução

por adição de colunas
– Maior número de junções
– Maior número de índices
– Nenhum tem problemas de campos opcionais

Maria Teresa Marino 26

 Relacionamento 1:1 – opcional/obrigatória

• Adição de colunas versus fusão de tabelas

– Fusão de tabelas é melhor em termos de número de
junções e número de chaves
– Adição de colunas é melhor em termos de campos
opcionais
– Fusão de tabelas é considerada a melhor solução
enquanto que adição de colunas representa uma solução
aceitável

Maria Teresa Marino 27

 Relacionamento 1:1 – ambas entidades
obrigatórias
(1,1) (1,1)
CONFERÊNCIA organização COMISSÃO

código
nome Ender
Data inst

Maria Teresa Marino 28

 Relacionamento 1:1 – entidades obrigatórias
fusão de tabelas
(1,1) (1,1)
CONFERÊNCIA organização COMISSÃO

código
nome Ender
Data inst

Conferência (CodConf,Nome, EnderComOrg,DataInstComOrg)

Maria Teresa Marino 29

 Relacionamento 1:1 – entidades obrigatórias

• Nenhuma das demais alternativas atende

plenamente
• Em ambas:
– Entidades que participam do relacionamento seriam
representadas através de duas tabelas distintas
– Estas tabelas teriam a mesma chave primária e relação
um-para-um entre suas linhas
– Maior número de junções
– Maior número de chaves primárias

Maria Teresa Marino 30

 Relacionamentos 1:n – caso 1

• A entidade que tem a cardinalidade máxima 1 é

obrigatória

(0,n) (1,1)
DEPARTAMENTO lotação EMPREGADO

código código
nome nome
Data
Lotação

Maria Teresa Marino 31

 Relacionamentos 1:n – caso 1
adição de colunas
(0,n) (1,1)
DEPARTAMENTO lotação EMPREGADO

código código
nome nome
Data
Lotação
Departamento (CodDept,Nome)

Empregado (CodEmp,Nome,CodDept,DataLota)
CodDept referencia Departamento

Maria Teresa Marino 32

 Relacionamentos 1:n – caso 1
tabela própria
(0,n) (1,1)
DEPARTAMENTO lotação EMPREGADO

código código
nome nome
Data
Lotação
Departamento (CodDept,Nome)
Empregado (CodEmp,Nome)
Lotação (CodEmp,CodDept,DataLota)
CodEmp referencia Empregado
CodDept referencia Departamento

Maria Teresa Marino 33

 Relacionamento 1:n – caso 1

• Fusão de tabelas
– Não se aplica
– Implicaria em
• redundância de dados de departamento
• Adição de colunas é melhor que tabela própria
– Menor número de chaves
– Menor número de junções
– Não há problema de campos opcionais

Maria Teresa Marino 34

 Relacionamento 1:n – caso 2

• A entidade que tem a cardinalidade máxima 0 é

opcional
(0,n) (0,1)
FINANCEIRA financiam VENDA

código taxa de código

nome juros No.parc data
elas

Maria Teresa Marino 35

 Relacionamento 1:n – caso 2
adição de colunas
(0,n) (0,1)
FINANCEIRA financiam VENDA

código taxa de código

nome juros No.parc data
elas

Fianceira (CodFinanc,Nome)

Venda (CodVenda,Data,TxJuros,NoParc,CodFinanc)
CodFinanc referencia Financeira

Maria Teresa Marino 36

 Relacionamento 1:n – caso 2
tabela própria
(0,n) (0,1)
FINANCEIRA financiam VENDA

código taxa de código

nome juros No.parc data
elas
Fianceira (CodFinanc,Nome)
Venda (CodVenda,Data)
Financiam (CodVenda,CodFinanc, TxJuros,NoParc,)
CodFinanc referencia Financeira
CodVenda referencia Venda

Maria Teresa Marino 37

 Relacionamento 1:n – caso 2

• Implementação por tabela própria também é

aceitável
– É melhor em relação a campos opcionais
– Perde em relação a número de junções e chaves

Maria Teresa Marino 38

 Relacionamento n:n
(0,n) (0,n)
ENGENHEIRO atuação PROJETO

código código
nome função título

Engenheiro (CodEng,Nome)
Projeto (CodProj,Titulo)
Atuação (CodEng, CodProj, Função)
CodEng referencia Engenheiro
CodProj referencia Projeto

Maria Teresa Marino 39

 Relacionamento grau > dois

(0,n) (0,n)
ENGENHEIRO atuação PROJETO

código Data In código

nome título
PROJETO

código
nome

Maria Teresa Marino 40

 Relacionamento grau > dois

• Não são definidas regras específicas

– O relacionamento é transformado em tabela
– São aplicadas regras de implementação dos
relacionamentos binários

Maria Teresa Marino 41

 Relacionamento grau > dois

Engenheiro (CodEng,Nome)
Projeto (CodProj,Titulo)

Função (CodFunc,Nome)
Atuação (CodEng, CodProj,CodFunc,DataIn)

CodEng referencia Engenheiro

CodProj referencia Projeto
CodFunc referencia Função

Maria Teresa Marino 42