Projeto de Banco de Dados

Transcrição

1 Projeto de Banco de Dados Transparências selecionadas Autor: Prof Carlos Heuser (UFRGS) Livro: Projeto de Banco de Dados 1 Modelo de Dados - níveis de abstração modelo conceitual abstração modelo lógico modelo físico 2 1

2 Modelo conceitual Independente de tipo de SGBD Registra Estrutura dos dados podem aparecer no banco de dados Não registra Como estes dados estão armazenados a nível de SGBD 3 Modelo conceitual - diagrama ER Técnica mais difundida de modelagem conceitual Abordagem entidade-relacionamento (ER) Modelo conceitual é representado através de diagrama entidade-relacionamento (DER) 4 2

3 Diagrama entidade-relacionamento preço Produto n 1 Tipo de produto descrição código descrição código 5 Modelo lógico Nível de abstração visto pelo usuário do SGBD Dependente do tipo particular de SGBD que está sendo usado 6 3

4 Modelo lógico SGBD relacional para o exemplo TipoDeProduto CodTipoProd DescrTipoProd 1 Computador 2 Impressora Produto CodProd DescrProd PrecoProd CodTipoProd 1 PC desktop modelo X PC notebook ABC Impressora jato de tinta Impressora laser Modelo lógico para o exemplo TipoDeProduto(CodTipoProd,DescrTipoProd) Produto(CodProd,DescrProd,PrecoProd,CodTipoProd) CodTipoProd referencia TipoDeProduto 8 4

5 Modelo Físico Contém detalhes de armazenamento interno de informações Detalhes que não têm influencia sobre a programação de aplicações no SGBD influenciam a performance da aplicações Usados por profissionais que fazem sintonia de performance em banco de dados 9 Idéia fundamental do projeto de banco de dados Através da identificação das entidades que terão informações representadas no banco de dados, é possível identificar os arquivos que comporão o banco de dados 10 5

6 Modelo conceitual tem dupla interpretação modelo da organização Define as entidades da organização que tem informações armazenadas no banco de dados modelo do banco de dados Define que arquivos (tabelas) farão parte do banco de dados. 11 Projeto de BD Duas fases: 1 Modelagem conceitual 2 Projeto lógico Adequado para a construção de um novo banco de dados Caso já exista um banco de dados ou um conjunto de arquivos convencionais usar reengenharia 12 6

7 Abordagem Entidade-Relacionamento Técnica para construir modelos conceituais de bases de dados Técnica de modelagem de dados mais difundida e utilizada Criada em 1976 por Peter Chen 13 Abordagem Entidade-Relacionamento Padrão de fato para modelagem conceitual Não é única: NIAM/ORM (técnica européia da década de 70) UML (Técnica para modelos Orientados a Objetos) Técnicas de modelagem orientada a objetos (UML) baseiam-se nos conceitos da abordagem ER 14 7

8 Abordagem Entidade-Relacionamento Modelo de dados é representado através de um modelo entidade-relacionamento (modelo ER) Modelo ER é representado graficamente diagrama entidade-relacionamento (DER) 15 Conceitos centrais da abordagem ER Entidade Relacionamento Atributo Generalização/especialização Entidade associativa 16 8

9 Entidade Conjunto de objetos da realidade modelada sobre os quais deseja-se manter informações no banco de dados 17 Entidade exemplos Sistema de informações industrial produtos tipos de produtos vendas compras 18 9

10 Entidade exemplos Sistema de contas correntes clientes contas correntes cheques agências Entidade pode representar objetos concretos da realidade (uma pessoa, um automóvel) objetos abstratos (um departamento, um endereço) 19 Entidade no DER Representada através de um retângulo Retângulo contém o nome da entidade. PESSOA DEPARTAMENTO 20 10

11 Entidade e instância Para referir um objeto particular fala-se em instância ou ocorrência de entidade 21 Entidade e instância - terminologia conjunto entidade conjunto de entidades classe elemento do conjunto instância entidade instância 22 11

12 Propriedades de entidades Entidade isoladamente não informa nada É necessário atribuir propriedades às entidades Propriedades especificadas na forma de Relacionamentos Atributos Generalizações/especializações 23 Relacionamento - conceito Conjunto de associações entre entidades sobre as quais deseja-se manter informações na base de dados 24 12

13 Relacionamento no DER DEPARTAMENTO LOTAÇÃO PESSOA 25 Relacionamento e instância Relacionamento é um conjunto de associações entre instâncias de entidades Uma instância (ocorrência) é uma associação específica entre determinadas instâncias de entidade Exemplo (relacionamento LOTAÇÃO) ocorrência = par específico formado por uma ocorrência de PESSOA e uma ocorrência de DEPARTAMENTO 26 13

14 Diagrama de ocorrências p1 p2 p3 p4 p6 p7 p5 p8 entidade EMPREGADO p1,,d1 p2,d1 p4,d2 p5,d3 relacionamento LOTAÇÃO d1 d2 d3 entidade DEPARTAMENTO 27 Auto-relacionamento PESSOA marido CASAMENTO esposa 28 14

15 Papel de relacionamento Função que uma ocorrência de uma entidade cumpre em uma ocorrência de um relacionamento Relacionamento de casamento Uma ocorrência de pessoa exerce o papel de marido Uma ocorrência de pessoa exerce o papel de esposa Relacionamentos entre entidades diferentes: não é necessário indicar os papéis das entidades 29 Auto-relacionamento diagrama de ocorrências p1 p3 p6 p7 p8 p2 p4 p5 marido esposa marido esposa p1,p3 p6,p

16 Cardinalidade de relacionamentos Propriedade importante de um relacionamento Quantas ocorrências de uma entidade podem estar associadas a uma determinada ocorrência de entidade através do relacionamento Chamada de cardinalidade de uma entidade em um relacionamento duas cardinalidades máxima mínima 31 Cardinalidade máxima no DER DEPARTAMENT O 1 LOTAÇÃO n EMPREGADO 32 16

17 Cardinalidade máxima - DER DEPARTAMENT O 1 LOTAÇÃO n EMPREGAD O expressa que a uma ocorrência de EMPREGADO (entidade do lado oposto da anotação) pode estar associada ao máximo uma ( 1 ) ocorrência de DEPARTAMENTO 33 Cardinalidade máxima no DER DEPARTAMENT O 1 LOTAÇÃ O n EMPREGAD O expressa que a uma ocorrência de DEPARTAMENTO (entidade ao lado oposto da anotação) podem estar associadas muitas ( n ) ocorrências de EMPREGADO 34 17

18 Cardinalidade máxima - valores Para projeto de BD relacional não é necessário distinguir entre diferentes cardinalidades máximas > 1 Dois valores de cardinalidades máximas são usados cardinalidade máxima 1 cardinalidade máxima muitos, referida pela letra n 35 Classificação de relacionamentos Cardinalidade máxima pode ser usada para classificar relacionamentos binários Relacionamento binário é aquele cujas instâncias envolvem duas instâncias de entidades Relacionamentos binários n:n (muitos-para-muitos) 1:n (um-para-muitos) 1:1 (um-para-um) 36 18

19 Relacionamentos 1:1 PESSOA 1 1 marido esposa CASAMENTO EMPREGADO 1 ALOCAÇÃO 1 MESA 37 Relacionamentos 1:n n 1 ALUNO INSCRIÇÃO CURSO 1 n EMPREGADO DEPENDENTE EMPREGADO supervisor supervisionado 1 n SUPERVISÃO 38 19

20 Relacionamentos n:n n n ENGENHEIRO ALOCAÇÃO PROJETO n n MÉDICO CONSULTA PACIENTE n n PEÇA CAPACIDADE FORNECEDOR PRODUTO composto componente n n COMPOSIÇÃO 39 Relacionamento ternário CIDADE DISTRIBUIDOR DISTRIBUIÇÃO PRODUTO 40 20

21 Cardinalidade em relacionamento ternário CIDADE DISTRIBUIDOR n 1 DISTRIBUIÇÃO n a cardinalidade 1 refere-se a um par cidade e produto PRODUTO 41 Cardinalidade mínima Número mínimo de ocorrências de entidade que são associadas a uma ocorrência de uma entidade através de um relacionamento Para fins de projeto de BD, consideram-se apenas duas cardinalidades mínimas cardinalidade mínima 0 cardinalidade mínima 1 Denominação alternativa: cardinalidade mínima 1 = associação obrigatória cardinalidade mínima 0 = associação opcional 42 21

22 Cardinalidade mínima - DER EMPREGADO e1 e2 e3 e4 (0,1) ALOCAÇÃO (1,1) e1,m 1 e2,m 2 e3,m6 e4,m4 MESA m1 m2 m3 m4 m5 m6 43 Exemplo - entidades e relacionamentos PRÉ-REQUIS liberada liberador a DEPARTAMENTO RESPONSÁVEL DISCIPLINA (1,1) DISC-CURSO ALUNO INSCRIÇÃO (1,1) CURSO 44 22

23 Atributo Dado ou informação que é associado a cada ocorrência de uma entidade ou de um relacionamento PROJETO nome código tipo 45 Atributos com cardinalidade Cardinalidade mínima atributo obrigatório (cardinalidade mínima 1 ) cada entidade possui no mínimo um valor associado) atributo opcional (cardinalidade mínima 0 ) Cardinalidade máxima atributo monovalorado (cardinalidade máxima 1 ) cada entidade possui no máximo um valor associado) atributo multivalorado (cardinalidade máxima n) 46 23

24 Atributo com cardinalidade CLIENTE telefone código nome Atributo opcional e multi-valorado 47 Atributo em relacionamento ENGENHEIRO ATUAÇÃO PROJETO Código Nome Título Função Código 48 24

25 Atributo em relacionamento 1:n nº de parcelas FINANCEIRA (0,1) FINANCIAMENT O taxa de juros VENDA 49 Identificador de entidade Cada entidade deve possuir um identificador identificador = conjunto propriedades de uma entidade (atributos e relacionamentos) cujos valores servem para distinguir uma ocorrência da entidade das demais ocorrências da mesma entidade 50 25

26 Atributo identificador PESSOA código nome endereço PRATELEIRA capacidade número do corredor número da prateleira 51 Relacionamento identificador Entidade fraca código nome número seqüência nome (1,1) EMPREGADO DEPENDENTE 52 26

27 Relacionamento (recursão) GRUPO código identificador (1,1) EMPRESA (1,1) número da empresa FILIAL número da filial 53 Identificador de relacionamento Uma ocorrência de relacionamento diferencia-se das demais do mesmo relacionamento pelas ocorrências de entidades que dela participam. n n ENGENHEIRO ALOCAÇÃO PROJETO 54 27

28 Relacionamento com atributo identificador n n MÉDICO CONSULTA PACIENTE data/hora 55 Generalização/especialização Conceito permite atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica 56 28

29 Generalização/especialização FILIAL (1,1) CLIENTE nome código PESSOA FÍSICA PESSOA JURÍDICA CIC sexo CGC tipo de organização 57 Generalização/especialização Herança de propriedades Herdar propriedades significa cada ocorrência da entidade especializada possui além de suas próprias propriedades) também as propriedades da ocorrência da entidade genérica correspondente 58 29

30 Entidade associativa (BD1: agregado) Modificar modelo: Adicionar medicamentos prescritos em uma consulta n n MÉDICO CONSULTA PACIENTE 59 Substituindo relacionamento por entidade MÉDICO (1,1) PACIENT E (1,1) n n CONSULT A n PRESCRIÇÃ O n MEDICAMENT O 60 30

31 Entidade associativa n n MÉDICO CONSULTA PACIENTE n PRESCRIÇÃ O n MEDICAMENT O 61 Conceito Entidade Relacionamento Símbolo Símbolos DER Atributo Atributo identificador Relacionamento identificador (1,1) Generalização/ especialização Entidade associativa 62 31

32 DER de uma farmácia FORNECEDOR (1,n) FABRICANTE (1,1) (1,1) LOTE (1,n) PRODUTO MEDICAMENTO PERFUMARIA RECEITA MÉDICA (0,1) (1,n) VENDA 63 tipo de empregado nome EMPREGADO (1,n) GERÊNCIA (0,1) CIC p DER recursos humanos (1,1) LOTAÇÃO DEPARTAMENTO CREA GERENTE SECRETÁRIA ENGENHEIRO (1,n) DOMÍNIO PROCESSADOR DE TEXTOS PARTICIPAÇÃO PROJETO 64 32

33 Projeto lógico Conhecimento sobre a aplicação modelo ER (nível conceitual) Transformação ER para relacional Refinamento do modelo relacional modelo relacional (nível lógico) 1 Transformação ER para relacional Regras gerais Aplicáveis à maioria dos casos Há situações por exigências da aplicação, outros mapeamentos são usados Implementadas em ferramentas CASE Objetivos básicos: Boa performance Simplificar o desenvolvimento 2 1

34 Passos da transformação ER para relacional Tradução inicial de entidades e respectivos atributos Tradução de relacionamentos e respectivos atributos Tradução de generalizações/especializações 3 Implementação inicial de entidades Cada entidade é traduzida para 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 4 2

35 Implementação de entidade exemplo data de admissão data de nascimento PESSOA código nome endereço Pessoa (CodigoPess,Nome,Endereço,DataNasc,DataAdm) 5 Tradução de entidade relacionamento identificador código nome número seqüência nome (1,1) EMPREGADO DEPENDENTE Dependente (CodigoEmp,NoSeq,Nome) 6 3

36 Relacionamento recursão código número da empresa GRUPO (1,1) EMPRESA (1,1) nome nome Grupo (CodGrup,Nome) identificador Empresa (CodGrup,NoEmpresa,Nome) Empregado (CodGrup,NoEmpresa,NoEmpreg, Nome) Dependente (CodGrup,NoEmpresa,NoEmpreg,NoSeq, Nome) número do empregado EMPREGADO (1,1) nome número de seqüência DEPENDENTE nome 7 Nomes de colunas Referenciados freqüentemente em programas e outras formas de texto em computador Para diminuir o trabalho de programadores manter os nomes de colunas curtos. SGBD relacional nome de uma coluna não pode conter brancos 8 4

37 Nomes de atributos e nomes de colunas Não transcrever os nomes de atributos para nomes de colunas. Nomes de atributos compostos de diversas palavras devem ser abreviados Nomes de colunas não necessitam 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 forma Pessoa.Nome 9 Nome da coluna chave primária Chave primária pode aparecer em outras tabelas na forma de chave estrangeira Recomendável nomes 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 10 5

38 Implementação de relacionamento 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) 11 Tabela própria ENGENHEIRO ATUAÇÃO PROJETO Código Nome Função CódigoTítulo Engenheiro (CodEng,Nome) Projeto (CodProj,Título) Atuação (CodEng,CodProj,Função) CodEng referencia Engenheiro CodProj referencia Projeto 12 6

39 Adição de colunas (1,1) DEPARTAMENTO LOTAÇÃO EMPREGADO Código Nome Data lotação Código Nome Departamento (CodDept,Nome) Empregado (CodEmp,Nome,CodDept,DataLota) CodDept referencia Departamento 13 Fusão de tabelas (1,1) (1,1) CONFERÊNCIA ORGANIZAÇÃO COMISSÃO Código Nome Data Instalação Ender Conferência (CodConf,Nome,DataInstComOrg,EnderComOrg) 14 7

40 Implementação de relacionamentos 1:1 Tipo de relacionamento Regra de implementação Tabela Adição Fusão própria coluna tabelas (0,1) (0,1) ± (0,1) (1,1) ± (1,1) (1,1) Alternativa preferida ± Pode ser usada Não usar 15 1:1 - ambas entidades opcionais exemplo (0,1) (0,1) HOMEM CASAMENTO MULHER Identidade Nome Data Regime Identidade Nome 16 8

41 1:1 - ambas opcionais adição de colunas (0,1) (0,1) HOMEM CASAMENTO MULHER Identidade Nome Data Regime Identidade Nome Mulher (IdentM,Nome,IdentH,Data,Regime) IdentH referencia Homem Homem (IdentH,Nome) 17 1:1 - ambas opcionais tabela própria (0,1) (0,1) HOMEM CASAMENTO MULHER Identidade Nome Data Regime Identidade Nome Mulher (IdentM,Nome) Homem (IdentH,Nome) Casamento (IdentM,IdentH,Data,Regime) IdentM referencia Mulher IdentH referencia Homem 18 9

42 1:1 - ambas opcionais fusão de tabelas (0,1) (0,1) HOMEM CASAMENTO MULHER Identidade Nome Data Regime Identidade Nome Casamento (IdentM,IdentH,Data,Regime,NomeH,NomeM) 19 1:1 - ambas opcionais discussão 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 20 10

43 1:1 - Uma entidade opcional outra obrigatória (1,1) (0,1) CORRENTISTA CARTÃO MAGNÉTICO Código Nome Código Data Exp. 21 1:1 - opcional/obrigatória fusão de tabelas (1,1) (0,1) CORRENTISTA CARTÃO MAGNÉTICO Código Nome Código Data Exp. Correntista (CodCorrent,Nome,CodCartão,DataExp) 22 11

44 1:1 - opcional/obrigatória adição de colunas (1,1) (0,1) CORRENTISTA CARTÃO MAGNÉTICO Código Nome Código Data Exp. Correntista (CodCorrent,Nome) Cartão(CodCartão,DataExp,CodCorrent) CodCorrent referencia Correntista 23 1:1 - opcional/obrigatória tabela própria (1,1) (0,1) CORRENTISTA CARTÃO MAGNÉTICO Código Nome Código Data Exp. Correntista (CodCorrent,Nome) Cartão(CodCartão,DataExp) CartãoCorrentista(CodCartão,CodCorrent) CodCorrent referencia Correntista CodCartão referencia Cartão 24 12

45 1:1 - opcional/obrigatória discussão 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 têm problema de campos opcionais 25 1:1 - opcional/obrigatória discussão 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 Adicão de colunas em melhor em termos de campos opcionais Fusão de tabelas é considerada a melhor e adição de colunas é aceitável 26 13

46 1:1 - Ambas entidades tem participação obrigatória (1,1) (1,1) CONFERÊNCIA ORGANIZAÇÃO COMISSÃO Código Nome Data Instalação Ender 27 1:1 - ambas obrigatórias fusão de tabelas (1,1) (1,1) CONFERÊNCIA ORGANIZAÇÃO COMISSÃO Código Nome Data Instalação Ender Conferência (CodConf,Nome,DataInstComOrg,EnderComOrg) 28 14

47 1:1 - Ambas 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 29 Relacionamentos 1:n Tipo de relacionamento Regra de implementação Tabela Adição Fusão própria coluna tabelas (0,1) ± (0,1) (1,n) ± (1,1) (1,1) (1,n) Alternativa preferida ± Pode ser usada Não usar 30 15

48 1:n - caso 1 A entidade que tem cardinalidade máxima 1 é obrigatória (1,1) DEPARTAMENTO LOTAÇÃO EMPREGADO Código Nome Data lotação Código Nome 31 1:n - caso 1 adição de colunas (1,1) DEPARTAMENTO LOTAÇÃO EMPREGADO Código Nome Data lotação Código Nome Departamento (CodDept,Nome) Empregado (CodEmp,Nome,CodDept,DataLota) CodDept referencia Departamento 32 16

49 1:n - caso 1 tabela própria (1,1) DEPARTAMENTO LOTAÇÃO EMPREGADO Código Nome Data lotação Código Nome Departamento (CodDept,Nome) Empregado (CodEmp,Nome, Lotacao(CodEmp,CodDept,DataLota) CodDept referencia Departamento CodEmp referencia Empregado 33 1:n - caso 1 discussão Fusão de tabelas Não se aplica Implicaria em redundância de dados de departamento, ou tabela aninhada Adição de colunas é melhor que tabela própria Menor número de chaves Menor número de junções Não há o problema de campos opcionais 34 17

50 1:n - caso 2 A entidade que tem cardinalidade máxima 1 é opcional nº de parcelas (0,1) FINANCEIRA FINACIAM VENDA taxa de juros Código Nome Id Data 35 1:n - caso 2 adição de colunas nº de parcelas (0,1) FINANCEIRA FINACIAM VENDA taxa de juros Código Nome Id Data Financeira (CodFin,Nome) Venda (IdVend,Data,CodFin,NoParc,TxJuros) CodFin referencia Financeira 36 18

51 1:n - caso 2 tabela própria nº de parcelas (0,1) FINANCEIRA FINACIAM VENDA taxa de juros Código Nome Id Data Financeira (CodFin,Nome) Venda (IdVend,Data) Fianciam (IdVend,CodFin,NoParc,TxJuros) IdVend referencia Venda CodFin referencia Financeira 37 1:n - caso 2 discussão Implementação por tabela própria também é aceitável É melhor em relação a campos opcionais Perde em relação a junções e número de chaves 38 19

52 Relacionamentos n:n Tipo de relacionamento Regra de implementação Tabela Adição Fusão própria coluna tabelas (1,n) (1,n) (1,n) Alternativa preferida Não usar 39 Relacionamentos n:n ENGENHEIRO ATUAÇÃO PROJETO Código Nome Função CódigoTítulo Engenheiro (CodEng,Nome) Projeto (CodProj,Título) Atuação (CodEng,CodProj,Função) CodEng referencia Engenheiro CodProj referencia Projeto 40 20

53 Relacionamento grau > dois CIDADE DISTRIBUIDOR nome código (0,1) DISTRIBUIÇÃO nome código data de início PRODUTO código nome 41 Relacionamento grau>2 Não são definidas regras específicas O relacionamento é transformado em uma entidade São aplicadas regras de implementação relacionamentos binários 42 21

54 Relacionamento grau>2 CIDADE nome código (1,1) DISTRIBUIDOR (1,1) nome código DISTRIBUIÇÃO data de início (1,1) PRODUTO código nome 43 Relacionamento grau>2 Produto (CodProd,Nome) Cidade (CodCid,Nome) Distribuidor (CodDistr,Nome) Distribuição (CodProd,CodDistr,CodCid,DataInicio) CodProd referencia Produto CodDistr referencia Distribuidor CodCid referencia Cidade 44 22

55 Implementação generalização/especialização de Duas alternativas básicas uso de uma tabela para cada entidade uso de uma única tabela para toda hierarquia Outra alternativa (exótica) Subdivisão de entidade genérica 45 tipo de empregado nome CIC EMPREGADO código p Generalização/especialização exemplo (1,1) LOTAÇÃO DEPARTAMENT O código nome SECRETÁRIA (1,n) DOMÍNIO PROCESSADO R DE TEXTOS código nome MOTORISTA carteira de habilitação (1,1) RAMO DA ENGENHARIA CREA código nome código nome ENGENHEIRO PARTICIPAÇÃ O PROJETO 46 23

56 Uma tabela por hierarquia Todas tabelas referentes às especializações são fundidas em uma única tabela Tabela contém: Chave primária correspondente ao identificador da entidade mais genérica Caso não exista, adicionar uma coluna Tipo Uma coluna para cada atributo da entidade genérica Colunas referentes aos relacionamentos dos quais participa a entidade genérica e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade genérica segue 47 Uma tabela por hierarquia Tabela contém (continuação): Uma coluna para cada atributo de cada entidade especializada (opcional) Colunas referentes aos relacionamentos dos quais participa cada entidade especializada e que sejam implementados através da alternativa de adicionar colunas à tabela da entidade (campo opcional) 48 24

57 Uma tabela por hierarquia Emp (CódigoEmp,Tipo,Nome,CIC,CodigoDept, CartHabil,CREA,CódigoRamo) CódigoDept referencia Depto CódigoRamo referencia Ramo Depto (CódigoDept, Nome) Ramo (CódigoRamo,Nome) ProcessTexto (CódigoProc,Nome) Domínio (CódigoEmp,CódigoProc) CódigoEmp referencia Emp CódigoProc referencia ProcessTexto Projeto (CódigoProj,Nome) Participação (CódigoEmp,CodigoProj) CódigoEmp referencia Emp CódigoProj referencia Projeto 49 Uma tabela por entidade especializada Criar uma tabela para cada entidade que compõe a hierarquia Incluir a chave primária da tabela correspondente à entidade genérica, em cada tabela correspondente a uma entidade especializada 50 25

58 Emp (CódigoEmp,Tipo,Nome,CIC,CódigoDept) CódigoDept referencia Depto Motorista(CódigoEmp,CartHabil) CódigoEmp referencia Emp Engenheiro(CódigoEmp,CREA,CódigoRamo) CódigoEmp referencia Emp CódigoRamo referencia Ramo Depto (CódigoDept, Nome) Ramo (CódigoRamo,Nome) ProcessTexto (CódigoProc,Nome) Domínio (CódigoEmp,CódigoProc) CódigoEmp referencia Emp Código Proc referencia ProcessTexto Projeto (CódigoProj,Nome) Participação (CódigoEmp,CódigoProj) CódigoEmp referencia Engenheiro CódigoProj referencia Projeto Uma tabela por entidade especializada 51 Vantagens da implementação com tabela única Dados referentes à entidade genérica + dados referentes às especializações em uma única linha Minimiza junções Menor número de chaves 52 26

59 Vantagens da implementação com uma tabela por entidade especializada Colunas opcionais apenas aquelas referentes a atributos que podem ser vazios do ponto de vista da aplicação. 53 Subdivisão da entidade genérica Uma tabela para cada entidade especializada que não possua outra especialização (entidade folha da árvore) Tabela contém dados da entidade especializada + dados da entidade genérica 54 27

60 Subdivisão da entidade genérica EmpOutros (CódigoEmp,Tipo,Nome,CIC,CódigoDept) CódigoDept referencia Depto Motorista(CódigoEmp, Nome,CIC,CódigoDept,CartHabil) Engenheiro(CódigoEmp, Nome,CIC,CódigoDept, CREA,CódigoRamo) CódigoRamo referencia Ramo Depto (CódigoDept, Nome) Ramo (CódigoRamo,Nome) ProcessTexto (CódigoProc,Nome) Domínio (CódigoEmp,CódigoProc) Código Proc referencia ProcessTexto Projeto (CódigoProj,Nome) Participação (CódigoEmp,CódigoProj) CódigoProj referencia Projeto 55 Subdivisão da entidade genérica Desvantagem: Unicidade da chave primária não é garantida pelo SGBD deve ser garantida pela aplicação Não há como especificar ao SGBD restrições de integridade referenciais, que façam referência ao conjunto de empregados como um todo 56 28

61 Projeto de Banco de Dados Pessoas 1 N Possuem Automóveis Há múltiplas modelagens possíveis qual escolher? Pessomóvel (Id, Nome, Chassis, Modelo, Ano ) 1 Problemas na Concepção Redundância (espaço de armazenamento) Proprietário de diversos automóveis! Atualização inconsistente Alteração de nome em uma tupla em todas?! Anomalias de Atualização (inclusão) Pessoa que não tem automóvel; (exclusão) Perde informações da pessoa quando último carro é vendido! 2

62 Teoria da Normalização Formalismos para boa concepção de um esquema de BD relacional Sem informações redundantes Evita anomalias de atualizações Principais conceitos envolvidos Dependências funcionais (DFs) Formas normais Algoritmos de decomposição 3 Dependências Funcionais(1/8) O que são Dependências? Especificam propriedades sobre dados válidos no banco de dados Dependência de inclusão: todo aluno é uma pessoa Dependência funcional: todo empregado trabalha no máximo em um departamento 4

63 Dependências Funcionais(2/8) Utilização: Verificação de restrições de integridade Otimização de consultas Concepção de esquemas: formas normais Sejam R (A1, A2, An); X e Y subconjuntos de {A1, A2, An } 5 Dependências Funcionais(3/8) X Y X determina Y ou Y depende funcionalmente de X sse t1[x] = t2[x] t1[y] = t2[y] tuplas t1, t2 em r instância de R 6

64 Dependências Funcionais(4/8) Observações DF é assertiva para toda realização de R DF representa restrição que deve ser sempre verificada DFs fazem parte do esquema de um BD São declaradas pelo administrador do banco de dados e controladas pelo SGBD 7 Dependências Funcionais(7/8) F + : Fecho de Conjunto de DFs F: Todas DFs implicadas logicamente por F F: {A B; B C} F + : {A B; B C; A C} Sejam R (A1, A2, An); F e X {A1, A2, An } X é chave de R se X {A1, A2, An } F + e não há Y X tal que Y {A1, A2, An } F + 8

65 Dependências Funcionais(8/8) Se há mais de uma chave para R Chaves candidatas A que for escolhida é dita chave primária Conceito de super-chave: X {A1, A2, An } e X {A1, A2, An } F + Minimalidade não exigida Atributo primo: Ai {A1, A2, An }, Ai X, com X chave de R 9 Decomposição de Esquema A decomposição do esquema relacional R consiste da substituição de R por um conjunto de subesquemas { R1, R2 Rk } onde Ri R (1 i k ) R1 R2... Rk = R Obs. Os sub-esquemas Ri não precisam ser (e normalmente não o são) disjuntos! 10

66 Objetivos da Decomposição Particionar R em esquemas relacionais menores de forma a eliminar, parcial ou totalmente, as redundâncias e anomalias de atualização, com as seguintes propriedades: Os sub-esquemas contém a mesma informação que R As DFs locais aos sub-esquemas são as DFs de R mapeadas para cada Ri Restrições e informações reproduzidas integralmente! 11 Propriedades das Decomposições Decomposição sem perdas lossless join: junção das partes é equivalente ao todo! Mais do que perder informações, o que se deseja é evitar gerar informações inexistentes na relação original! Decomposição preservando as DFs As DFs válidas para R devem continuar válidas em cada Ri da decomposição 12

67 Formas Normais(1/3) Primeira Forma Normal (1FN) Uma relação R está em 1FN se todos os atributos são atômicos/indivisíveis Segunda Forma Normal (2FN) Uma relação R está em 2FN se estiver em 1FN e nenhum atributo não-primo depender funcionalmente de uma parte da chave Obs. 1FN e 2FN têm mais valor histórico (e.g modelo NF 2 ) 13 Formas Normais(2/3) Terceira Forma Normal (3FN) Uma relação R está em 3FN se estiver em 2FN e todo atributo não primo depender apenas de um atributo primo; Equivalentemente, toda DF não trivial X A de R for tal que ora X é superchave, ora A é atributo primo Teorema: Toda relação R admite uma decomposição em 3FN sem perdas e preservando as DFs 14