Níveis de Abstração. Mundo Real. Transformações entre modelos. Analista. Mini-mundo. Banco de Dados I. Unidade I. Modelo de Banco de Dados.

Transcrição

1 Níveis de Abstração Mundo Real Modelo de Banco de Dados Analista Mini-mundo organiza idéias (abstração da realidade) Descreve Define Projeto de Banco de Dados Modelo Conceitual Modelo Lógico Modelo Físico BD 1

2 Fases: Projeto de Banco de Dados Modelo conceitual Esquema relacional Tipo_Produto (Codigo, Descricao) Produto (Codigo, Nome, Preco, Cod_Tipo) Cod_Tipo referencia Tipo_Produto) Modelo lógico Banco de Dados PRODUTO TIPO_PRODUTO CODIGO DESCRICAO 1 COMPUTADOR 2 IMPRESSORA Modelo físico CODIGO DESCRICAO PRECO COD_TIPO 1 DESKTOP DELL MODELO P III NOTEBOOK TOSHIBA L HP 692 C JATO DE TINTA EPSON 1500 L LASER BD 2

3 Transformação de DER para Relacional Implementação de entidades: Entidade normalmente transforma-se em tabela: Atributo da entidade ( simples ): coluna da tabela Nomes: curtos, significativos, sem brancos, se preciso usar abreviaturas 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) 3

4 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 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. 4

5 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 5

6 TRADUÇÃO DE RELACIONAMENTO POR TABELA PRÓPRIA Criar uma tabela para o relacionamento com as seguintes colunas: -os identificadores das entidades que participam 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 código título função data início ENGENHEIRO (0,n) (0,n) ATUAÇÃO PROJETO Engenheiro(CodigoEngenheiro,Nome_Eng) Projeto(CodigoProjeto,Título_Proj) Atuação(CodigoEngenheiro,CodigoProjeto,Função_Atu,DtaInic_Atu) CodigoEngenheiro referencia Engenheiro CodigoProjeto referencia Projeto 6

7 TRADUÇÃO DE RELACIONAMENTOS - por ADIÇÃO DE COLUNAS numa das tabelas que participam do relacionamento; e E1 R E2 TRADUÇÃO 7

8 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) atributo(s) t próprios do relacionamento. código nome código nome data lotação DEPARTAMENTO (1,1) LOTAÇÃO (0,n) EMPREGADO Departamento(CodigoDepartamento,Nome_Dep) Empregado(CodigoEmpregado,Nome_Emp,CodigoDepartamento,Data_Lot) CodigoDepartamento referencia Departamento 8

9 TRADUÇÃO DE RELACIONAMENTOS - por FUSÃO DAS TABELAS das entidades que participam do relacionamento. E1 R E2 TRADUÇÃO 9

10 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 data instalação endereço CONFERÊNCIA (1,1) 1) ORGANIZAÇÃO (1,1) 1) COMISSÃO Conferência(CodigoConferência,Nome_Conf,DataInstalação_Org,Endereço_Com) 10

11 Implementação de relacionamentos (1:1) : ambas entidades com participação opcional Modelo conceitual Modelo lógico Homem (IdentH, Nome) Homem (IdentH, Nome) Mulher (IdentM, Nome) Mulher (IdentM, Nome, IdentH, Data, Regime) IdentH referencia Homem Casamento (IdentM, IdentH, Data, Regime) IdentM referencia Mulher IdentH referencia Homem 11

12 Implementaçã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) Cartao (CodCartao, DataExp, CodCorrent) CodCorrent referencia Correntista t 12

13 Implementação de relacionamentos (1:1) : ambas entidades com participação obrigatória Modelo conceitual Correntista (CodCorrent, Nome, CodCartao, DataExp) Modelo lógico 13

14 Transformação de DER para Relacional Tipo de Tabela Adição de Fusão de relacionamento própria Coluna Tabelas Relacionamentos 1:1 ± X X ± X X Alternativa preferida ± Pode ser usada X Não usar 14

15 Implementação de relacionamentos (1:N) : alternativa preferida: adição de colunas Modelo conceitual Modelo lógico Financeira (CodFin, Nome) Financeira (CodFin, Nome) Venda (IdVend, d Data) Venda (IdVend, Data, CodFin, NumParc, TxJuros) CodFin referencia Financeira Financiamento (IdVend, CodFin, NumParc, TxJuros) IdVend referencia Venda CodFin referencia Financeira 15

16 Implementação de relacionamentos (1:N) : alternativa preferida: adição de colunas Endereço Número Código EDIFÍCIO (1, 1) (1, n) APARTAMENTO Modelo conceitual Área Edificio (CodigoEd, Endereco) Apartamento (CodigoEd, NumAp, AreaAp) Modelo lógico CodigoEd referencia Edificio 16

17 Transformação de DER para Relacional Tipo de Tabela Adição de Fusão de relacionamento própria Coluna Tabelas Relacionamentos 1:N ± X ± X X X X X Alternativa preferida ± Pode ser usada X Não usar 17

18 Implementação de relacionamentos (N:N) : criação de uma nova tabela Modelo conceitual Engenheiro (CodEng, Nome) Projeto (CodProj, Titulo) Atuação (CodEng, CodProj, Funcao) CodEng referencia Engenheiro CodProj referencia Projeto Modelo lógico 18

19 Transformação de DER para Relacional Tipo de Tabela Adição de Fusão de relacionamento própria Coluna Tabelas Relacionamentos N:N (0,N) (0,N) (0,N) (1,N) (1,N) (1,N) X X X X X X Alternativa preferida ± Pode ser usada X Não usar 19

20 Tipo de relacionamento Relacionamentos 1:1 Tipo de relacionamento Relacionamentos 1:N Tabela própria p Adição de Coluna Fusão de Tabelas ± X X ± Tabela Adição de Fusão de própria X Coluna X Tabelas ± X ± X X X Tipo de Tabela Adição de Fusão de relacionamento própria Coluna Tabelas Relacionamentos N:N X X Alternativa preferida ± Pode ser usada X X X Não usar X X X X 20

21 Implementação de entidades com relacionamento identificador Modelo conceitual Modelo lógico Empregado (CodigoEmp, Nome) Dependente (CodigoEmp, NumSeq, Nome, DataNasc) 21

22 Implementação de entidades com relacionamento identificador Código GRUPO Nome Modelo conceitual (1,1) (0,n) Número da Empresa EMPRESA Nome (1,1) Número sequencia Nome Número do Empregado (0,n) EMPREGADO (1, 1) (0, n) DEPENDENTE Nome Data Nascimento Modelo lógico Grupo (CodGrupo, Nome) Empresa (CodGrupo, NumEmpresa, Nome) Empregado (CodGrupo, NumEmpresa, NumEmpregado, Nome) Dependente (CodGrupo, NumEmpresa, NumEmpregado, NumSeq, Nome, DataNasc) 22

23 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 23

24 Relacionamentos de Grau maior que 02 (dois): Modelo conceitual Modelo lógico Nome Código Nome Código CIDADE (1,1) DISTRIBUIDOR (1,1) Cidade (CodCid, Nome) Distribuidor (CodDistr, Nome) (0,n) (0,n) Produto (CodProd, Nome) Código DISTRIBUIÇÃO (0,n) (1,1) PRODUTO Data de Início Distribuicao (CodCid, CodDistr, CodProd, DataIni) CodCid referencia Cidade CodDistr referencia Distribuidor CodProd referencia Produto Nome 24

25 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 Empregado (CodEmp, Nome, CIC, TipoEmp) Motorista (CodEmp, NumCartHab) CodEmp referencia Empregado Engenheiro (CodEmp, CREA) CodEmp referencia Empregado (1) Empregado (CodEmp, Nome, CIC, TipoEmp, NumCartHab, CREA) (2) 25

26 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 EMPREGADO (0, n) LOTAÇÃO (1, 1) DEPARTAMENTO p CREA Código MOTORISTA SECRETÁRIA ENGENHEIRO (1, n) (0, n) (0, n) Carteira de Habilitação DOMÍNIO PARTICIPAÇÃO (0, n) (0, n) (1, 1) PROCESSADOR DE TEXTO PROJETO RAMO DA ENGENHARIA Código Nome Código Nome Código Nome 26

27 Implementação generalização / especialização: uma única tabela para toda hierarquia generalização/ especialização Modelo conceitual Modelo lógico Tipo de empregado Empregado (CodEmp, Nome, CIC, TipoEmp, NumCartHab, CREA, CodDep, CodRamo ) Nome CIC Nome CodDep referencia Departamento Código EMPREGADO (0, n) LOTAÇÃO (1, 1) DEPARTAMENTO CodRamo referencia Ramo Departamento (CodDep, Nome) p CREA Código Ramo (CodRamo, Nome) Projeto (CodProj, Nome) MOTORISTA SECRETÁRIA ENGENHEIRO ProcText (CodProc, Nome) Carteira de Habilitação (1, n) (0, n) DOMÍNIO PARTICIPAÇÃO (0, n) (0, n) (0, n) (1, 1) Dominio (CodEmp, CodProc) CodEmp referencia Empregado CodProc referencia ProcText PROCESSADOR DE TEXTO PROJETO RAMO DA ENGENHARIA Código Nome Código Nome Código Nome Participacao (CodEmp, CodProj) CodEmp referencia Empregado CodProj referencia Projeto 27

28 Implementação generalização / especialização: uma tabela para cada entidade de generalização / especialização Modelo conceitual 28

29 Implementação generalização / especialização: uma tabela para cada entidade de generalização / especialização Modelo conceitual Modelo lógico Empregado (CodEmp, Nome, CIC, Tipo, CodDep) CodDep referencia Departamento Departamento (CodDep, Nome) Motorista (CodEmp, NumCartHab) Engenheiro (CodEmp, CREA, CodRamo) Ramo (CodRamo, Nome) Projeto (CodProj, Nome) CodRamo referencia Ramo ProcText (CodProc, Nome) Dominio (CodEmp, CodProc) CodEmp referencia Empregado CodProc referencia ProcText Participacao (CodEmp, CodProj) CodEmp referencia Empregado CodProj referencia Projeto 29

30 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 que aparecem são apenas aquelas 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 e não pelo SGBDR. DECISÃO - O projetista t optará pela mais adequada d à sua situação. 30

31 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. Diante desta situação é preciso buscar alternativas que resultem em melhor performance, mesmo com a desobediência das regras de tradução. Estas 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. 31

32 CIC RELACIONAMENTOS MUTUAMENTE EXCLUSIVOS nome número data PESSOA FÍSICA (0,1) (0,n) VENDA Implementação pelas regras: PessoaFísica(CICPessoaFisica,Nome_PF) PessoaJurídica(CGCPessoaJuridica,Nome_PJ) PJ) Venda(NumeroVenda,Data_Vda,CICPessoaFisica, CGCPessoaJuridica) CICPessoaFisica referencia PessoaFísica CGCPessoaJuridica referencia PessoaJurídica (0,n) CGC razão social (0,1) PESSOA JURÍ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. 32

33 SIMULAÇÃO DE ATRIBUTOS MULTI-VALORADOS código nome código nome CLIENTE telefone(0,n) CLIENTE (1,1) Implementação pelas regras: Cliente(CodigoCliente,Nome_Cli) Telefone(CodigoCliente,Número_Tel) CodigoCliente referencia Cliente (0,n) número Alternativa: Cliente(CodigoCliente,Nome_Cli, Nro_Tel1,Nro_Tel2) TELEFONE - Evita-se a junção; - Pode haver coluna opcional. 33

34 USO DE INFORMAÇÕES REDUNDANTES código roteiro nro de reservas (1,1) VÔO - 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. -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. nro passageiro (0,n) RESERVA 34