Transformação do Modelo Conceitual para o Modelo Lógico

Transformações entre modelos
Níveis de Abstração
Mundo Real
Modelo de Banco
de Dados
Modelo
Conceitual
Analista
Descreve
Projeto de
Banco de
Dados
Mini-mundo
organiza idéias
(abstração da realidade)
Define
Modelo
Lógico
Modelo
Físico
BD
Unidade I
Banco de Dados I
1
Transformações entre modelos
„
Projeto de Banco de Dados
Fases:
Modelo conceitual
Esquema relacional
Tipo_Produto (Codigo, Descricao)
Modelo lógico
g
P d t (Codigo,
Produto
(C di
N
Nome,
P
Preco, C
Cod_Tipo)
d Ti )
Cod_Tipo referencia Tipo_Produto)
TIPO_PRODUTO
Banco de Dados
CODIGO
DESCRICAO
1
2
COMPUTADOR
IMPRESSORA
PRODUTO
CODIGO
DESCRICAO
1
2
3
4
DESKTOP DELL MODELO P III
NOTEBOOK TOSHIBA L 1.7
HP 692 C JATO DE TINTA
EPSON 1500 L LASER
Unidade I
PRECO COD_TIPO
2500
3500
600
1200
1
1
2
2
Modelo físico
BD
Banco de Dados I
2
Transformações entre modelos
Transformação de DER para Relacional
„
Implementação de entidades:
Î Entidade normalmente transforma-se em tabela:
„
Atributo da entidade ((“simples”):
simples ): coluna da tabela
™ Nomes: curtos, significativos, sem “brancos”, se
preciso usar abreviaturas
p
™ Abreviatura: usar mesmo princípio em todo BD
„
Atributo identificador da entidade: chave primária
Modelo conceitual
Modelo lógico
Pessoa (CodigoPess, Nome, Endereco,
DataAdm, DataNasc)
Unidade I
Banco de Dados I
3
Transformações entre modelos
Ç
PARA NOMEAR TABELAS E COLUNAS DE TABELAS
CONVENÇÕES
DURANTE A TRADUÇÃO
- usar os nomes das tabelas no singular;
- nomes de colunas extensivamente utilizados na
aplicação = devem ser o mais curtos possíveis;
- nomes de atributos compostos de diversas palavras
devem ser abreviados;
- SGBDR não aceita brancos nos nomes de colunas, se
preciso usar “underline”;
- não se inclui o nome da tabela no nome da coluna;
- a chave primária de uma tabela é uma exceção =
poderá ser uma chave estrangeira de uma outra tabela;
- abreviaturas usadas em nomes de colunas devem ser
utilizadas da mesma forma em todo o BD.
Unidade I
Banco de Dados I
4
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTOS
- As cardinalidades são os fatores determinantes;
- Três formas básicas de implementação:
- por TABELA PRÓPRIA
Ó
PARA O RELACIONAMENTO;
E1
R
E2
TRADUÇÃO
Unidade I
Banco de Dados I
5
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTO
POR TABELA PRÓPRIA
Ó
Criar uma tabela para o relacionamento com as seguintes colunas:
-os identificadores das entidades q
que participam
p
p
do relacionamento;;
-as colunas dos atributos do relacionamento.
- A chave primária será o conjunto das colunas correspondentes aos
identificadores das entidades que participam do relacionamento.
código nome
ENGENHEIRO
código
função data início
(0,n)
ATUAÇÃO
(0,n)
título
PROJETO
Engenheiro(CodigoEngenheiro,Nome_Eng)
Projeto(CodigoProjeto,Título_Proj)
Atuação(CodigoEngenheiro,CodigoProjeto,Função_Atu,DtaInic_Atu)
CodigoEngenheiro referencia Engenheiro
C di P j t referencia
CodigoProjeto
f
i Projeto
P j t
Unidade I
Banco de Dados I
6
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTOS
- por ADIÇÃO DE COLUNAS numa das tabelas que participam do
relacionamento; e
E1
R
E2
TRADUÇÃO
Unidade I
Banco de Dados I
7
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTO
POR ADIÇÃO DE COLUNAS NAS TABELAS QUE PARTICIPAM DO RELACIONAMENTO
- Só é possível quando há um relacionamento com cardinalidade máxima 1;
- Insere-se na tabela que tem o relacionamento com cardinalidade n;
- O(s) identificador(es) da outra tabela serão chave(s) estrangeira(s);
- O(s)
O( ) atributo(s)
t ib t ( ) próprios
ó i do
d relacionamento.
l i
t
código
g nome
DEPARTAMENTO
código
g
d t lotação
data
l t ã
(1,1)
LOTAÇÃO
(0,n)
nome
EMPREGADO
Departamento(CodigoDepartamento,Nome_Dep)
Empregado(CodigoEmpregado,Nome_Emp,CodigoDepartamento,Data_Lot)
CodigoDepartamento referencia Departamento
Unidade I
Banco de Dados I
8
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTOS
- por FUSÃO DAS TABELAS das entidades que participam do
relacionamento.
E1
R
E2
TRADUÇÃO
Unidade I
Banco de Dados I
9
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTO
POR FUSÃO DE TABELAS DE ENTIDADES QUE
PARTICIPAM DO RELACIONAMENTO
- Só é possível quando o relacionamento é 1:1;
- Insere-se na tabela os atributos das entidades e do próprio
relacionamento.
código nome
CONFERÊNCIA
data instalação
(1 1)
(1,1)
ORGANIZAÇÃO
(1 1)
(1,1)
endereço
COMISSÃO
Conferência(CodigoConferência,Nome_Conf,DataInstalação_Org,Endereço_Com)
Unidade I
Banco de Dados I 10
Transformações entre modelos
„
Implementação de relacionamentos (1:1) :
Î
ambas entidades com participação opcional
Modelo conceitual
Modelo lógico
Homem (IdentH, Nome)
9
Mulher (IdentM, Nome, IdentH, Data, Regime)
IdentH referencia Homem
Unidade I
Homem (IdentH, Nome)
Mulher (IdentM,
(IdentM Nome)
Casamento (IdentM, IdentH, Data, Regime)
IdentM referencia Mulher
IdentH referencia Homem
Banco de Dados I 11
Transformações entre modelos
„
Implementação de relacionamentos (1:1) :
Î
uma entidade com participação opcional e outra obrigatória
Modelo conceitual
Modelo lógico
Correntista (CodCorrent,
(CodCorrent Nome,
Nome CodCartao,
CodCartao DataExp)
9
Correntista (CodCorrent, Nome)
Cartao (CodCartao, DataExp, CodCorrent)
C dC
CodCorrent
t referencia
f
i Correntista
C
ti t
Unidade I
Banco de Dados I 12
Transformações entre modelos
„
Implementação de relacionamentos (1:1) :
Î
ambas entidades com participação obrigatória
Modelo conceitual
Correntista (CodCorrent, Nome, CodCartao, DataExp)
Unidade I
Modelo lógico
Banco de Dados I 13
Transformações entre modelos
Transformação de DER para Relacional
Tipo de
relacionamento
Relacionamentos 1:1
Unidade I
Tabela
própria
Adição de
Coluna
Fusão de
Tabelas
±
9
X
X
±
X
X
9
Alternativa preferida
p
±
X
Pode ser usada
9
9
Não usar
Banco de Dados I 14
Transformações entre modelos
„
Implementação de relacionamentos (1:N) :
Î
alternativa preferida: adição de colunas
Modelo conceitual
Modelo lógico
Financeira (CodFin, Nome)
9
Venda (IdVend, Data, CodFin, NumParc, TxJuros)
CodFin referencia Financeira
Unidade I
Financeira (CodFin, Nome)
V d (IdVend,
Venda
(IdV d Data)
D t )
Financiamento (IdVend, CodFin, NumParc, TxJuros)
IdVend referencia Venda
CodFin referencia Financeira
Banco de Dados I 15
Transformações entre modelos
„
Implementação de relacionamentos (1:N) :
Î
alternativa preferida: adição de colunas
Endereço
Número
(1, 1)
Código
(1, n)
EDIFÍCIO
APARTAMENTO
Modelo conceitual
Área
Edificio (CodigoEd,
(CodigoEd Endereco)
Apartamento (CodigoEd, NumAp, AreaAp)
Modelo lógico
CodigoEd
g
referencia Edificio
Unidade I
Banco de Dados I 16
Transformações entre modelos
Transformação de DER para Relacional
Tipo de
relacionamento
Tabela
própria
Adição de
Coluna
±
9
9
9
9
Fusão de
Tabelas
Relacionamentos 1:N
±
X
X
Unidade I
9
Alternativa preferida
±
X
Pode ser usada
X
X
X
X
Não usar
Banco de Dados I 17
Transformações entre modelos
„
Implementação de relacionamentos (N:N) :
Î criação de uma nova tabela
Modelo conceitual
Engenheiro (CodEng, Nome)
Projeto (CodProj,
(CodProj Titulo)
Atuação (CodEng, CodProj, Funcao)
Modelo lógico
CodEng referencia Engenheiro
CodProj referencia Projeto
Unidade I
Banco de Dados I 18
Transformações entre modelos
Transformação de DER para Relacional
Tipo
p de
relacionamento
Tabela
própria
Adição
ç
de
Coluna
Fusão de
Tabelas
X
X
X
X
X
X
Relacionamentos N:N
Unidade I
(0,N)
(0,N)
(0,N)
(1,N)
(1,N)
(1,N)
9
9
9
9
Alternativa preferida
±
X
Pode ser usada
Não usar
Banco de Dados I 19
Transformações entre modelos
Tipo de
relacionamento
Relacionamentos 1:1
Tipo de
relacionamento
Tabela
própria
p
p
Adição de
Coluna
Fusão de
Tabelas
±
9
X
X
Tabela
própria
X
±
Adição de
Coluna
X
9
9
Fusão de
Tabelas
Relacionamentos 1:N
±
±
Tipo de
relacionamento
X
Tabela
própria
X
9
9
9
Adição de
Coluna
9
X
X
X
Fusão de
Tabelas
X
9
Alternativa
preferida
±
Pode ser
usada
X
Não usar
Relacionamentos N:N
9
9
9
Unidade I
X
X
X
X
X
X
Banco de Dados I 20
Transformações entre modelos
„
Implementação de entidades com relacionamento identificador
Modelo conceitual
Modelo lógico
Empregado (CodigoEmp, Nome)
Dependente (CodigoEmp, NumSeq, Nome, DataNasc)
Unidade I
Banco de Dados I 21
Transformações entre modelos
„
Implementação
p
ç de entidades com relacionamento identificador
Código
GRUPO
Modelo conceitual
Nome
(1,1)
(0,n)
Número da
Empresa
EMPRESA
Nome
(1,1)
Número
sequencia
Nome
(0,n)
Número do
Empregado
(1, 1)
EMPREGADO
Nome
(0, n)
DEPENDENTE
Data
Nascimento
Modelo lógico
G
Grupo
(CodGrupo,
(C dG
N
Nome)
)
Empresa (CodGrupo, NumEmpresa, Nome)
Empregado (CodGrupo, NumEmpresa, NumEmpregado, Nome)
Dependente (CodGrupo, NumEmpresa, NumEmpregado, NumSeq, Nome, DataNasc)
Unidade I
Banco de Dados I 22
Transformações entre modelos
„
Relacionamentos de Grau maior que 02 (dois) - Ternário
Î
Î
relacionamento é transformado em entidade
usa-se as regras de implementação de entidades e
relacionamentos binários
Modelo conceitual
Unidade I
Banco de Dados I 23
Transformações entre modelos
„
Relacionamentos de Grau maior que 02 (dois):
M d l conceitual
Modelo
it l
Modelo lógico
Nome
Código
Nome
Cidade (CodCid, Nome)
Código
CIDADE
DISTRIBUIDOR
(1,1)
(1,1)
(0,n)
Produto (CodProd, Nome)
(0,n)
DISTRIBUIÇÃO
(0,n)
(1,1)
Código
PRODUTO
Distribuidor (CodDistr, Nome)
Data de Início
Distribuicao (CodCid, CodDistr, CodProd, DataIni)
CodCid referencia Cidade
CodDistr referencia Distribuidor
CodProd referencia Produto
Nome
Unidade I
Banco de Dados I 24
Transformações entre modelos
„
Implementação generalização / especialização (alternativas):
Î
Î
(1) uso de uma tabela para cada entidade
(2) uso de uma única tabela para toda hierarquia
Modelo conceitual
Modelo lógico
E
Empregado
d (CodEmp,
(C dE
N
Nome,
CIC
CIC, Ti
TipoEmp)
E )
(1)
Motorista (CodEmp, NumCartHab)
CodEmp referencia Empregado
Engenheiro (CodEmp, CREA)
CodEmp referencia Empregado
Empregado (CodEmp, Nome, CIC, TipoEmp,
(2)
NumCartHab, CREA)
Unidade I
Banco de Dados I 25
Transformações entre modelos
„
Implementação generalização / especialização:
Î uma única tabela para toda hierarquia generalização/ especialização
Modelo conceitual
Tipo de
empregado
Nome
CIC
Nome
Código
(0, n)
EMPREGADO
(1, 1)
LOTAÇÃO
DEPARTAMENTO
p
MOTORISTA
CREA
SECRETÁRIA
ENGENHEIRO
(1, n)
Carteira de
Habilitação
DOMÍNIO
(0, n)
Código
Unidade I
Nome
(0, n)
PARTICIPAÇÃO
((0,, n))
PROCESSADOR
DE TEXTO
Código
((0,, n))
PROJETO
Código
Nome
((1,, 1))
RAMO DA
ENGENHARIA
Código
Nome
Banco de Dados I 26
Transformações entre modelos
„
Implementação generalização / especialização:
Î uma única tabela para toda hierarquia generalização/ especialização
Modelo conceitual
Modelo lógico
Empregado (CodEmp, Nome, CIC, TipoEmp,
Tipo de
empregado
Nome
NumCartHab, CREA, CodDep, CodRamo )
CIC
CodDep referencia Departamento
Nome
CodRamo referencia Ramo
Código
(0, n)
EMPREGADO
(1, 1)
LOTAÇÃO
DEPARTAMENTO
Departamento (CodDep, Nome)
Ramo (CodRamo,
(CodRamo Nome)
p
CREA
Código
Projeto (CodProj, Nome)
ProcText (CodProc, Nome)
MOTORISTA
SECRETÁRIA
ENGENHEIRO
(1, n)
Carteira de
Habilitação
DOMÍNIO
(0, n)
PARTICIPAÇÃO
((0,, n))
PROCESSADOR
DE TEXTO
Dominio (CodEmp, CodProc)
CodEmp referencia Empregado
(0, n)
((0,, n))
PROJETO
((1,, 1))
RAMO DA
ENGENHARIA
CodProc referencia ProcText
Participacao (CodEmp, CodProj)
CodEmp referencia Empregado
Código
Unidade I
Nome
Código
Nome
Código
Nome
CodProjj referencia Projeto
j
Banco de Dados I 27
Transformações entre modelos
„
Implementação generalização / especialização:
Î
uma tabela para cada entidade de generalização / especialização
Modelo conceitual
Unidade I
Banco de Dados I 28
Transformações entre modelos
„
Implementação generalização / especialização:
Î
uma tabela para cada entidade de generalização / especialização
Modelo conceitual
Modelo lógico
Empregado
p g
(CodEmp,
(
p, Nome,, CIC,, Tipo,
p , CodDep)
p)
CodDep referencia Departamento
Departamento (CodDep, Nome)
Motorista (CodEmp,
(CodEmp NumCartHab)
Engenheiro (CodEmp, CREA, CodRamo)
CodRamo referencia Ramo
Ramo (CodRamo, Nome)
Projeto (CodProj, Nome)
ProcText (CodProc
(CodProc, Nome)
Dominio (CodEmp, CodProc)
CodEmp referencia Empregado
CodProc referencia ProcText
Participacao (CodEmp, CodProj)
CodEmp referencia Empregado
CodProj referencia Projeto
Unidade I
Banco de Dados I 29
Transformações entre modelos
TRADUÇÃO
Ç
DE GENERALIZAÇÃO/ESPECIALIZAÇÃO
Ç
Ç
COMPARAÇÃO DAS IMPLEMENTAÇÕES
UMA TABELA PARA TODA A HIERARQUIA
VANTAGENS
- Dados referentes a uma ocorrência de entidade genérica bem como
as ocorrências de suas especializações estão numa mesma linha;
- Chave primária da hierarquia é armazenada uma única vez.
UMA TABELA PARA CADA ENTIDADE DA HIERARQUIA
VANTAGENS
- Colunas opcionais
p
que
q aparecem
p
são apenas
p
aquelas
q
referentes a
atributos que podem ser vazios do ponto de vista da aplicação;
- Controle das colunas opcionais é feito pela aplicação com base no
valor da coluna tipo
p e não pelo
p
SGBDR.
DECISÃO
- O projetista
j ti t optará
t á pela
l mais
i adequada
d
d à sua situação.
it
ã
Unidade I
Banco de Dados I 30
Transformações entre modelos
REFINAMENTOS NO MODELO RELACIONAL
Em certas circunstâncias o projeto de BD desenvolvido pela
observação cuidadosa das regras de tradução mostradas, pode não atender
aos requisitos de performance impostos ao sistema.
ç ép
preciso buscar alternativas que
q resultem em
Diante desta situação
melhor performance, mesmo com a desobediência das regras de tradução.
Estas alternativas só devem ser adotadas em último caso,
caso pois o seu
uso indiscriminado levam a resultados piores do que o esperado.
Serão mostradas a seguir algumas destas alternativas.
Unidade I
Banco de Dados I 31
Transformações entre modelos
CIC
RELACIONAMENTOS MUTUAMENTE EXCLUSIVOS
nome
número
data
(0,n)
(0,1)
PESSOA FÍSICA
VENDA
(0 n)
(0,n)
Implementação pelas regras:
PessoaFísica(CICPessoaFisica,Nome_PF)
PessoaJurídica(CGCPessoaJuridica Nome PJ)
PessoaJurídica(CGCPessoaJuridica,Nome_PJ)
Venda(NumeroVenda,Data_Vda,CICPessoaFisica,
CGCPessoaJuridica)
CICPessoaFisica referencia PessoaFísica
CGCPessoaJuridica referencia PessoaJurídica
CGC
razão
ã social
i l
(0,1)
PESSOA JURÍDICA
Í
Alternativa:
PessoaFísica(CICPessoaFisica,Nome_PF)
PessoaJurídica(CGCPessoaJuridica,Nome_PJ)
Venda(NumeroVenda,Data_Vda,CIC/CGC,Tipo)
Unidade I
- Evita-se colunas opcionais;
- Não permite especificar ao SGBDR que
CIC/CGC é chave estrangeira.
Banco de Dados I 32
Transformações entre modelos
SIMULAÇÃO
Ç
DE ATRIBUTOS MULTI-VALORADOS
código
nome
CLIENTE
telefone(0,n)
código
nome
CLIENTE
(1,1)
Implementação pelas regras:
Cliente(CodigoCliente,Nome_Cli)
Telefone(CodigoCliente,Número_Tel)
(
g
_ )
CodigoCliente referencia Cliente
Alternativa:
Cliente(CodigoCliente,Nome_Cli,
Nro_Tel1,Nro_Tel2)
Unidade I
número
(0 )
(0,n)
TELEFONE
- Evita-se a junção;
- Pode haver coluna opcional.
p
Banco de Dados I 33
Transformações entre modelos
USO DE INFORMAÇÕES
Ç
REDUNDANTES
código
roteiro nro de reservas
VÔO
(1,1)
- O número de reservas é feito através
de uma contagem das linhas da tabela
reserva. Sob o ponto de vista de projeto, esta
é uma informação redundante.
nro
passageiro
(0 )
(0,n)
-Um atributo contendo este valor poderia
contribuir com a performance,
uma vez que não seria necessária uma
contagem em toda tabela quando se
necessitasse desta informação.
Unidade I
RESERVA
Banco de Dados I 34