transformações entre modelos níveis de abstração · transformações entre modelos traduÇÃo...

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


3 HP 692 C JATO DE TINTA 600 24 EPSON 1500 L LASER 1200 2 BD

2


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


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.


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


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


CodigoProjeto referencia Projeto

6


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



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



TRADUÇÃO DE RELACIONAMENTOSTRADUÇÃO DE RELACIONAMENTOS- por FUSÃO DAS TABELAS das entidades que participam do

relacionamento.

E1 E2R

TRADUÇÃO



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)


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


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


CodCorrent referencia Correntista

12


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



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


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


CodFin referencia Financeira

15


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)


g

16



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


X

17


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)


CodProj referencia Projeto

18



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)


± Pode ser usada

X Não usar


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


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


X X

20


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)



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)


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


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)


Nome

24


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)


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


Código Nome Código Nome Código Nome

26


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


Código Nome Código Nome Código Nome j j

27


uma tabela para cada entidade de generalização / especializaçãouma tabela para cada entidade de generalização / especializaçãoModelo conceitual



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


CodProj referencia Projeto

29


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 ã


- O projetista optará pela mais adequada à sua situação.

30


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.



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.



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.


p

33


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.


transformações entre modelos níveis de abstração · transformações entre modelos traduÇÃo...

Documents