transformações entre modelos níveis de abstração · transformações entre modelos traduÇÃo...
TRANSCRIPT
Transformações entre modelos
Níveis de Abstração
Modelo de BancoMundo Real
Modelo
Modelo de Banco de Dados
Modelo ConceitualAnalista
DescreveModelo LógicoMini-mundo
Projeto de Banco de
Dados
Modelo Físico
organiza idéias(abstração da realidade)
Define
BD
Banco de Dados IUnidade I
BD
1
Transformações entre modelosFases: Projeto de Banco de Dados
Modelo conceitual
Modelo lógico
Esquema relacionalTipo_Produto (Codigo, Descricao)P d t (C di N P C d Ti )
gProduto (Codigo, Nome, Preco, Cod_Tipo)
Cod_Tipo referencia Tipo_Produto)
CODIGO DESCRICAO1 COMPUTADOR2 IMPRESSORA
TIPO_PRODUTO
Banco de Dados
Modelo físicoCODIGO DESCRICAO PRECO COD_TIPO1 DESKTOP DELL MODELO P III 2500 12 NOTEBOOK TOSHIBA L 1.7 3500 13 HP 692 C JATO DE TINTA 600 2
PRODUTO
BD
Banco de Dados IUnidade I
3 HP 692 C JATO DE TINTA 600 24 EPSON 1500 L LASER 1200 2 BD
2
Transformações entre modelos
Transformação de DER para RelacionalImplementação de entidades:
Entidade normalmente transforma-se em tabela:Atributo da entidade (“simples”): coluna da tabelaAtributo da entidade ( simples ): coluna da tabela
Nomes: curtos, significativos, sem “brancos”, se preciso usar abreviaturaspAbreviatura: usar mesmo princípio em todo BD
Atributo identificador da entidade: chave primária
Modelo conceitual
Modelo lógicoModelo lógico
Pessoa (CodigoPess, Nome, Endereco, DataAdm, DataNasc)
Banco de Dados IUnidade I 3
Transformações entre modelos
CONVENÇÕES PARA NOMEAR TABELAS E COLUNAS DE TABELAS Ç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- 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 =- 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 serabreviaturas usadas em nomes de colunas devem ser utilizadas da mesma forma em todo o BD.
Banco de Dados IUnidade I 4
Transformações entre modelosTRADUÇÃ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 E2RE1 E2R
TRADUÇÃO
Banco de Dados IUnidade I 5
Transformações entre modelosTRADUÇÃO DE RELACIONAMENTO
ÓPOR TABELA PRÓPRIACriar uma tabela para o relacionamento com as seguintes colunas:-os identificadores das entidades que participam do relacionamento;q p p ;-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 código títulofunção data início
ENGENHEIRO(0,n)
PROJETO(0,n)
ATUAÇÃO
Engenheiro(CodigoEngenheiro,Nome_Eng)Projeto(CodigoProjeto,Título_Proj)Atuação(CodigoEngenheiro,CodigoProjeto,Função_Atu,DtaInic_Atu)
CodigoEngenheiro referencia EngenheiroC di P j t f i P j t
Banco de Dados IUnidade I
CodigoProjeto referencia Projeto
6
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTOSTRADUÇÃO DE RELACIONAMENTOS- por ADIÇÃO DE COLUNAS numa das tabelas que participam do
relacionamento; e
E1 E2R
relacionamento; e
TRADUÇÃO
Banco de Dados IUnidade I 7
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTOTRADUÇÃO DE RELACIONAMENTOPOR ADIÇÃO DE COLUNAS NAS TABELAS QUE PARTICIPAM DO RELACIONAMENTO
- Só é possível quando há um relacionamento com cardinalidade máxima 1;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( ) t ib t ( ) ó i d l i t- O(s) atributo(s) próprios do relacionamento.
código nome código nomed t l t ã
DEPARTAMENTO
g
(1,1)EMPREGADO
g
(0,n)LOTAÇÃO
data lotação
DEPARTAMENTO
Departamento(CodigoDepartamento,Nome_Dep)
EMPREGADOLOTAÇÃO
Empregado(CodigoEmpregado,Nome_Emp,CodigoDepartamento,Data_Lot)CodigoDepartamento referencia Departamento
Banco de Dados IUnidade I 8
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTOSTRADUÇÃO DE RELACIONAMENTOS- por FUSÃO DAS TABELAS das entidades que participam do
relacionamento.
E1 E2R
TRADUÇÃO
Banco de Dados IUnidade I 9
Transformações entre modelos
TRADUÇÃO DE RELACIONAMENTOTRADUÇÃO DE RELACIONAMENTOPOR 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
(1 1)
nome endereço
(1 1)
data instalação
CONFERÊNCIA(1,1)
COMISSÃO(1,1)
ORGANIZAÇÃO
Conferência(CodigoConferência,Nome_Conf,DataInstalação_Org,Endereço_Com)
Banco de Dados IUnidade I 10
Transformações entre modelosImplementação de relacionamentos (1:1) :
ambas entidades com participação opcional
Modelo conceitual
Modelo lógico
Homem (IdentH, Nome)
Modelo lógico
Homem (IdentH, Nome)Mulher (IdentM Nome)
Mulher (IdentM, Nome, IdentH, Data, Regime)IdentH referencia Homem
Casamento (IdentM, IdentH, Data, Regime)
IdentH referencia Homem
Mulher (IdentM, Nome)
IdentM referencia Mulher
Banco de Dados IUnidade I
IdentH referencia Homem IdentH referencia Homem
11
Transformações entre modelosImplementação de relacionamentos (1:1) :
uma entidade com participação opcional e outra obrigatória
Modelo conceitual
Modelo lógico
Correntista (CodCorrent Nome CodCartao DataExp)Correntista (CodCorrent, Nome, CodCartao, DataExp)
Correntista (CodCorrent, Nome)
Cartao (CodCartao, DataExp, CodCorrent)C dC t f i C ti t
Banco de Dados IUnidade I
CodCorrent referencia Correntista
12
Transformações entre modelos
Implementação de relacionamentos (1:1) :Implementação de relacionamentos (1:1) : ambas entidades com participação obrigatória
Modelo conceitual
Correntista (CodCorrent, Nome, CodCartao, DataExp) Modelo lógico
Banco de Dados IUnidade I 13
Transformações entre modelos
Transformação de DER para Relacional
Tipo de Tabela Adição de Fusão deTipo de relacionamento
Tabela própria
Adição de Coluna
Fusão de Tabelas
Relacionamentos 1:1
± X
X ±X ±X X
Alternativa preferidap
± Pode ser usada
X Não usar
Banco de Dados IUnidade I
X Não usar
14
Transformações entre modelosImplementação de relacionamentos (1:N) :
alternativa preferida: adição de colunas
Modelo conceitual
Modelo lógicoModelo lógico
Financeira (CodFin, Nome) Financeira (CodFin, Nome)
V d (IdV d D t )
CodFin referencia Financeira
Venda (IdVend, Data, CodFin, NumParc, TxJuros)
Venda (IdVend, Data)
Financiamento (IdVend, CodFin, NumParc, TxJuros)IdVend referencia Venda
Banco de Dados IUnidade I
CodFin referencia Financeira
15
Transformações entre modelos
Implementação de relacionamentos (1:N) :Implementação de relacionamentos (1:N) : alternativa preferida: adição de colunas
Modelo conceitualCódigo
Endereço
EDIFÍCIO
(1, 1) (1, n)
Número
APARTAMENTO Modelo conceitualEDIFÍCIO
Área
APARTAMENTO
Área
Edificio (CodigoEd Endereco)
Modelo lógicoEdificio (CodigoEd, Endereco)
CodigoEd referencia Edificio
Apartamento (CodigoEd, NumAp, AreaAp)
Banco de Dados IUnidade I
g
16
Transformações entre modelos
Transformação de DER para Relacional
Tipo de relacionamento
Tabela própria
Adição de Coluna
Fusão de Tabelasrelacionamento própria Coluna Tabelas
± X
Relacionamentos 1:N
± X
± X
X X
X X
Alternativa preferida
X X
± Pode ser usada
X Não usar
Banco de Dados IUnidade I
X
17
Transformações entre modelos
Implementação de relacionamentos (N:N) :Implementação de relacionamentos (N:N) : criação de uma nova tabela
Modelo conceitualModelo conceitual
Engenheiro (CodEng, Nome)
Projeto (CodProj Titulo)
CodEng referencia Engenheiro
Modelo lógicoProjeto (CodProj, Titulo)
Atuação (CodEng, CodProj, Funcao)
Banco de Dados IUnidade I
CodProj referencia Projeto
18
Transformações entre modelos
Transformação de DER para Relacional
Tipo de Tabela Adição de Fusão de prelacionamento própria
çColuna Tabelas
Relacionamentos N:N
X X(0,N)(0,N)
(1,N)(0,N)X X
X X
(1,N)(0,N)
(1,N)(1,N)
Alternativa preferida
± Pode ser usada
X Não usar
Banco de Dados IUnidade I
X
19
Transformações entre modelosTipo de
relacionamentoTabela própria
Adição de Coluna
Fusão de Tabelasp p
± X
Relacionamentos 1:1
Tipo de relacionamento
Tabela própria
Adição de Coluna
Fusão de Tabelas
X ±X X
± X
Relacionamentos 1:N
Alternativa preferida
Tipo de Tabela Adição de Fusão de
± X
X X
preferida± Pode ser
usadaTipo de
relacionamentoTabela própria
Adição de Coluna
Fusão de Tabelas
X X
Relacionamentos N:N
X X X Não usar
X X
X X
Banco de Dados IUnidade I
X X
20
Transformações entre modelos
Implementação de entidades com relacionamento identificadorImplementação de entidades com relacionamento identificador
Modelo conceitual
Modelo lógico
Dependente (CodigoEmp, NumSeq, Nome, DataNasc)
Empregado (CodigoEmp, Nome)
Banco de Dados IUnidade I 21
Transformações entre modelos
Implementação de entidades com relacionamento identificadorp ç
Modelo conceitualGRUPO
(1,1)
NomeCódigo
EMPRESA
(0,n)
NomeNúmero da EMPRESA
(1,1)
NomeEmpresa
Númerosequencia Nome
EMPREGADO
(0,n)
Número doEmpregado
(1, 1) (0, n)DEPENDENTE
DataNascimento
Nome Modelo lógico
G (C dG N )Grupo (CodGrupo, Nome)
Empresa (CodGrupo, NumEmpresa, Nome)
Empregado (CodGrupo, NumEmpresa, NumEmpregado, Nome)
Banco de Dados IUnidade I
Dependente (CodGrupo, NumEmpresa, NumEmpregado, NumSeq, Nome, DataNasc)
22
Transformações entre modelosRelacionamentos de Grau maior que 02 (dois) - Ternário
relacionamento é transformado em entidadeusa-se as regras de implementação de entidades e relacionamentos bináriosrelacionamentos binários
Modelo conceitual
Banco de Dados IUnidade I 23
Transformações entre modelosRelacionamentos de Grau maior que 02 (dois):
M d l it lModelo conceitual
Modelo lógico
Cidade (CodCid, Nome)
Distribuidor (CodDistr, Nome)
Nome
DISTRIBUIDOR
Código
Código
Nome
CIDADE
Produto (CodProd, Nome)
Distribuidor (CodDistr, Nome)
Distribuicao (CodCid, CodDistr, CodProd, DataIni)Data de Início
(0,n)
(1,1)(1,1)
(0,n)
DISTRIBUIÇÃO
CodProd referencia ProdutoCodDistr referencia Distribuidor
Distribuicao (CodCid, CodDistr, CodProd, DataIni)CodCid referencia Cidade
CódigoPRODUTO
(1,1)
(0,n)
Banco de Dados IUnidade I
Nome
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 lógico
(1)E d (C dE N CIC Ti E )
Modelo conceitual
(1)Empregado (CodEmp, Nome, CIC, TipoEmp)
Motorista (CodEmp, NumCartHab)CodEmp referencia Empregado
CodEmp referencia EmpregadoEngenheiro (CodEmp, CREA)
Empregado (CodEmp, Nome, CIC, TipoEmp,NumCartHab, CREA)
(2)
Banco de Dados IUnidade I 25
Transformações entre modelosImplementação generalização / especialização:
uma única tabela para toda hierarquia generalização/ especializaçãouma única tabela para toda hierarquia generalização/ especialização
Modelo conceitual
Nome NomeCIC
Tipo deempregado
p
DEPARTAMENTOLOTAÇÃO(1, 1)(0, n)Código
EMPREGADO
p
SECRETÁRIAMOTORISTA ENGENHEIRO
CREA Código
DOMÍNIO PARTICIPAÇÃO
(1, n) (0, n)
(0, n)(0, n)
Carteira deHabilitação
(0, n)
(1, 1)
PROJETO
( , )( , )
Código Nome
PROCESSADORDE TEXTO
Código Nome
RAMO DAENGENHARIA
( , )
Código Nome
Banco de Dados IUnidade I
Código Nome Código Nome Código Nome
26
Transformações entre modelosImplementação generalização / especialização:
uma única tabela para toda hierarquia generalização/ especializaçãouma única tabela para toda hierarquia generalização/ especialização
Modelo conceitual Modelo lógico
Empregado (CodEmp, Nome, CIC, TipoEmp,NumCartHab, CREA, CodDep, CodRamo )
CodDep referencia DepartamentoNome NomeCIC
Tipo deempregado
CodRamo referencia Ramo
Departamento (CodDep, Nome)
Ramo (CodRamo Nome)p
DEPARTAMENTOLOTAÇÃO(1, 1)(0, n)Código
EMPREGADO
Ramo (CodRamo, Nome)
ProcText (CodProc, Nome)
Projeto (CodProj, Nome)
p
SECRETÁRIAMOTORISTA ENGENHEIRO
CREA Código
DOMÍNIO PARTICIPAÇÃO
(1, n) (0, n)
(0, n)(0, n)
Carteira deHabilitação
(0, n)
(1, 1)
Dominio (CodEmp, CodProc)CodEmp referencia EmpregadoCodProc referencia ProcText
PROJETO
( , )( , )
Código Nome
PROCESSADORDE TEXTO
Código Nome
RAMO DAENGENHARIA
( , )
Código Nome
Participacao (CodEmp, CodProj)CodEmp referencia EmpregadoCodProj referencia Projeto
Banco de Dados IUnidade I
Código Nome Código Nome Código Nome j j
27
Transformações entre modelosImplementação generalização / especialização:
uma tabela para cada entidade de generalização / especializaçãouma tabela para cada entidade de generalização / especializaçãoModelo conceitual
Banco de Dados IUnidade I 28
Transformações entre modelosImplementação generalização / especialização:
uma tabela para cada entidade de generalização / especializaçãouma tabela para cada entidade de generalização / especializaçãoModelo conceitual Modelo lógico
Empregado (CodEmp, Nome, CIC, Tipo, CodDep)p g ( p, , , p , p)CodDep referencia Departamento
Motorista (CodEmp NumCartHab)
Departamento (CodDep, Nome)
Motorista (CodEmp, NumCartHab)
Engenheiro (CodEmp, CREA, CodRamo)
CodRamo referencia Ramo
Ramo (CodRamo, Nome)
ProcText (CodProc Nome)
Projeto (CodProj, Nome)
ProcText (CodProc, Nome)
Dominio (CodEmp, CodProc)CodEmp referencia EmpregadoCodProc referencia ProcText
Participacao (CodEmp, CodProj)CodEmp referencia Empregado
Banco de Dados IUnidade I
CodProj referencia Projeto
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;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 HIERARQUIAUMA TABELA PARA CADA ENTIDADE DA HIERARQUIAVANTAGENS- Colunas opcionais que aparecem são apenas aquelas referentes a p q p p q
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 e não pelo SGBDR.p p
DECISÃOO j ti t t á l i d d à it ã
Banco de Dados IUnidade I
- O projetista optará pela mais adequada à sua situação.
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 atenderobservação cuidadosa das regras de tradução mostradas, pode não atender aos requisitos de performance impostos ao sistema.
Diante desta situação é preciso buscar alternativas que resultem em ç p qmelhor performance, mesmo com a desobediência das regras de tradução.
Estas alternativas só devem ser adotadas em último caso pois o seuEstas alternativas só devem ser adotadas em último caso, pois o seu uso indiscriminado levam a resultados piores do que o esperado.
Serão mostradas a seguir algumas destas alternativas.
Banco de Dados IUnidade I 31
Transformações entre modelos
RELACIONAMENTOS MUTUAMENTE EXCLUSIVOSnúmero dataCIC nome
PESSOA FÍSICA(0,1)
VENDA(0,n)
(0 n)
CGC ã i l
(0,n)Implementação pelas regras:
PessoaFísica(CICPessoaFisica,Nome_PF)PessoaJurídica(CGCPessoaJuridica Nome PJ)
Í
CGC(0,1)
razão socialPessoaJurídica(CGCPessoaJuridica,Nome_PJ)Venda(NumeroVenda,Data_Vda,CICPessoaFisica,CGCPessoaJuridica)
CICPessoaFisica referencia PessoaFísicaPESSOA JURÍDICACGCPessoaJuridica referencia PessoaJurídica
Alternativa:
PessoaFísica(CICPessoaFisica,Nome_PF)PessoaJurídica(CGCPessoaJuridica,Nome_PJ)Venda(NumeroVenda,Data_Vda,CIC/CGC,Tipo)
- Evita-se colunas opcionais;- Não permite especificar ao SGBDR que
CIC/CGC é chave estrangeira.
Banco de Dados IUnidade I 32
Transformações entre modelos
SIMULAÇÃO DE ATRIBUTOS MULTI-VALORADOSÇ
nomecódigo nomecódigo
CLIENTE CLIENTE
(1,1)telefone(0,n)
Implementação pelas regras:
(0 )número
Implementação pelas regras:
Cliente(CodigoCliente,Nome_Cli)Telefone(CodigoCliente,Número_Tel)
TELEFONE
(0,n)
Alternativa:
( g _ )CodigoCliente referencia Cliente
Alternativa:
Cliente(CodigoCliente,Nome_Cli,Nro_Tel1,Nro_Tel2)
- Evita-se a junção;- Pode haver coluna opcional.
Banco de Dados IUnidade I
p
33
Transformações entre modelos
USO DE INFORMAÇÕES REDUNDANTESÇ
roteirocódigo nro de reservas
VÔO
(1,1)
- O número de reservas é feito através
(0 )passageiro
O número de reservas é feito atravésde uma contagem das linhas da tabelareserva. Sob o ponto de vista de projeto, esta é uma informação redundante. nro
RESERVA
(0,n)-Um atributo contendo este valor poderiacontribuir com a performance,uma vez que não seria necessária umauma vez que não seria necessária umacontagem em toda tabela quando se necessitasse desta informação.
Banco de Dados IUnidade I 34