Transformações entre Modelos

Transcrição

1 Transformações entre Modelos Maria Claudia Cavalcanti IME Base Bibliog. Projeto de Banco de Dados Carlos Heuser Conceptual Database Design Batini, Ceri, Navathe Qual é o ponto de partida? Esquema Conceitual Engenharia reversa Modelagem lógica Esquema Lógico

2 Qual é o ponto de partida? Esquema ER Engenharia reversa Mapeamento ER-Relacional Esquema Relacional Mapeamento ER-Relacional Diferentes esquemas relacionais podem ser gerados Refinamentos do esquema relacional gerado são oriundos do conhecimento maior sobre a aplicação, inclusive sobre seu desempenho conhecimento da aplicação Esquema ER Refinamento do esquema relacional Esquema Relacional Mapeamento ER-Relacional

3 Mapeamento do E-R para Relacional Metodologia Eliminação dos identificadores externos; Eliminação de atributos compostos e multi-valorados; Tradução de cada entidade em uma relação; Tradução de cada relacionamento : (a) relacionamentos n:m requerem uma relação separada (b) relacionamentos 1:n, 1:1 podem ser modelados pela adição de atributos às relações já existentes. Tradução de Generalização/Especialização Eliminação de Identificadores Externos Transformá-los em identificadores internos no modelo relacional Universidade Código_Universidade Nome Cidade Universidade Código_Universidade Nome Cidade Matrícula Código_Universidade Estudante Número_Estudante Nome_Estudante Idade Estudante A chave da entidade externa foi importada para ESTUDANTE Número_Estudante Nome_Estudante Idade

4 Eliminação de Atributos Compostos Pessoa Nome Idade Endereço Rua CEP Estado Pessoa Nome Idade Rua CEP Estado Eliminação do nível intermediário Pessoa Nome Idade Endereço Detalhes são deixados para a aplicação Eliminação de Atributos Multivalorados Entidades Produto Código_Produto Códigos_de_Materiais (1,n) Preço Produto + Código_Produto Preço Introdução de nova entidade. Uma para cada atributo multi-valorado. Produto Material Código_Produto Código_de_Material

5 Instrutor (0,m) Eliminação de Atributos Multivalorados Relacionamentos Código_Instrutor Departamento Telefone Instrutor (0,m) Código_Instrutor Departamento Telefone Oferece Número_Max_Estudantes Trimestre (1,n) Oferece Número_Max_Estudantes (1,m) (1,n) Curso Número_Curso Curso + Número_Curso Oferta_de_Cursos Código_Instrutor Número_Curso Trimestre Tradução de Entidade Empregado CPF Nome Salário Empregado (CPF, Nome, Salário)

6 Tradução de Relacionamentos 1:1 Cliente tem Carregamento Nome Código_Cliente Endereço Código_Cliente Agrupando numa mesma relação CLIENTE_CARREGAMENTO (Código_Cliente, Nome, Endereço) Ambas as entidades têm o mesmo identificador E se as entidades tiverem diferentes identificadores? Tradução de Relacionamentos 1:1 CLIENTE (0,1) POSSUI CARTÃO_DE_ CRÉDITO LIMITE_CRÉDITO NÚMERO_CARTÃO NOME TIPO_CARTÃO CÓDIGO_CLIENTE Agrupando em relações distintas * CLIENTE (CÓDIGO_CLIENTE, NOME) CARTÃO_DE_CRÉDITO (TIPO_CARTÃO, NÚMERO_CARTÃO, LIMITE) POSSUI (TIPO_CARTÃO, NÚMERO_CARTÃO, CÓDIGO_CLIENTE) As entidades têm identificadores diferentes (Qual seria ainda outra alternativa neste caso?) Uma das entidades tem participação opcional

7 Tradução de Relacionamentos 1:1 DATA REGIME HOMEM (0,1) (0,1) CASAMENTO MULHER MLH_CPF NOME HOM_CPF NOME HOMEM (HOM_CPF, NOME) MULHER (MLH_CPF, NOME) * Ambas as entidades têm participação opcional CASAMENTO (HOM_CPF, MLH_CPF, DATA, REGIME) Que observação pode ser feita sobre a chave primária de CASAMENTO? Tradução de Relacionamentos 1:n CIDADE PERTINÊNCIA NOME_CIDADE POPULAÇÃO Ambas entidades têm participação obrigatória (1,n) ESTADO NOME_ESTADO GOVERNADOR POPULAÇÃO CIDADE (NOME_CIDADE, NOME_ESTADO, POPULAÇÃO) ESTADO (NOME_ESTADO, GOVERNADOR, POPULAÇÃO)

8 Tradução de Relacionamentos 1:n VENDEDOR NOME TELEFONE (1,n) PREENCHE DESCONTO (0,1) PEDIDO NÚMERO_PEDIDO DATA participação opcional VENDEDOR (NOME_VEND, TELEFONE) PEDIDO (NÚMERO_PEDIDO, DATA) PREENCHE (NÚMERO_PEDIDO, NOME_VEND, DESCONTO) Tradução de Relacionamentos n:m ESTUDANTE NÚMERO_ESTUDANTE NOME_ESTUDANTE (1,n) MATRÍCULA (1,m) CURSO SEMESTRE GRAU NÚMERO_CURSO NOME_CURSO Independe das! cardinalidades ESTUDANTE (NÚMERO_ESTUDANTE, NOME_ESTUDANTE) CURSO (NÚMERO_CURSO, NOME_CURSO) MATRÍCULA (NÚMERO_ESTUDANTE, NÚMERO_CURSO, SEMESTRE, GRAU)

9 Tradução de Relacionamentos n-ários PEÇA (1,n) COD_PEÇA DESCRIÇÃO COD_FORN NOME ENDEREÇO TELEFONE FORNECEDOR (1,n) (1,n) PROJETO COD_PROJETO NOME DATA_ABERT QTDE PEÇA (COD_PEÇA, DESCRIÇÃO) FORNECEDOR (COD_FORN, NOME, ENDEREÇO, TELEFONE) PROJETO (COD_PROJETO, NOME, DATA_ABERT) FORNECIMENTO (COD_PEÇA, COD_FORNECEDOR, COD_PROJETO, QTDE) E se um dado par peça-projeto só pudesse ser fornecido por um único fornecedor? Tradução de Auto Relacionamentos REG_EMP NOME DATA_NASC EMPREGADO É_COORDENADO É_COORDENADOR COORDENA EMPREGADO (REG_EMP, NOME, DATA_NASC) COORDENA (REG_SUB, REG_COORDENADOR) E se o relacionamento for 1:n?

10 Chaves Primárias A princípio o atributo identificador da entidade é considerado como chave primária. No entanto, atualmente, há alternativas. A escolha fica entre usar uma chave natural ou uma chave artificial Chave natural (Natural key): chave indicada a partir da análise do domínio (atributo(s) identificadores da entidade) Chave artificial (Surrogate key): chave que pode ser criada artificialmente para identificar unicamente as tuplas de uma relação, sem significado para o domínio em questão. Wieringa and De Jonge (1991) definem Surrogate Key como an object in the database itself. The surrogate is internally generated by the system and is invisible to the user or application. Chaves Primárias Surrogate keys podem também ser chamadas de Internal identifier, system-generated key, database sequence number, synthetic key, factless key, technical key, or arbitrary unique identifier. SURROGATE to put in the place of another: a : to appoint as successor, deputy, or substitute for oneself b : SUBSTITUTE

11 Chaves Primárias Chave natural (Natural key): Vantagens: identifica naturalmente a relação Buscas normalmente com base em chaves naturais Evita a criação de algo extra Exemplos: CPF, código do título de eleitor Desvantagens: Sujeita a mudanças do negócio ou domínio em questão: ao mudarem os valores da chave natural, todas as referências a cada valor da chave primária (nas demais tabelas) vão precisar ser alteradas; Exemplos: - usuário pode querer mudar de , códigoempregado uma empresa identifica seus empregados unicamente por um código, mas ao fundir-se com outra empresa passa a ter outra codificação que respeitar. Chaves Primárias Chave artificial (Surrogate key): Vantagens: Não está sujeita às mudanças de negócio: alterações na chave natural ficam restritas a uma única tabela Desvantagens: Mais um atributo Manutenção de valores únicos é uma preocupação do próprio SGBD ao gerar os números novos a cada inclusão Como não fazem parte do domínio as SK não são entendíveis pelos humanos. Tem-se que manter as chaves candidatas (alternativas) para acesso direto: busca e visualização do usuário. Qual usar?

12 Chaves Primárias Implementações de Surrogate keys Universally Unique Identifiers (UUIDs) Globally Unique Identifiers (GUIDs) Object Identifiers (OIDs) Sybase or SQL Server identity column Oracle SEQUENCE PostgreSQL serial MySQL AUTO_INCREMENT AutoNumber data type in Microsoft Access AS IDENTITY GENERATED BY DEFAULT in IBM DB2 Chaves Primárias Ao optar por usar chaves artificiais (surrogate keys) como chaves primárias, declarar chaves candidatas Estendendo a notação resumida de C. Heuser Exemplo: Empregado (IdEmp, matrícula,, idcargo, ), idcargo referencia Cargo, matricula é chave candidata (única e não nula);

13 Tradução de Hierarquias Há duas alternativas principais: Fusão: Fundir todas as entidades em uma única relação Distribuição: Uma tabela para cada entidade específica e uma tabela pra a entidade genérica Tradução de Hierarquias Fusão Chave primária fica sendo a da entidade mais genérica Incluir uma coluna tipo para manter a informação sobre a especialização Passar todos os atributos das entidades especializadas para entidade genérica Fazer o mesmo para os relacionamentos Aplicar as regras já conhecidas

14 Traduzindo Hierarquias LOTACAO PARTICIPACAO DOMINIO PERTENCE PROJETO SW DEPTO Codigo EMPREGADO Código Código Código Habilitacao Código RAMO ENGENH (1,n) MOTORISTA SECRETARIA ENGENHEIRO CREA Traduzindo Hierarquias - fusão LOTACAO PARTICIPACAO DOMINIO PERTENCE PROJETO SW DEPTO Codigo tipo EMPREGADO Código Código Código CREA Habilitacao Código RAMO ENGENH (1,n)

15 Traduzindo Hierarquias fusão EMPREGADO(codEmp,, tipo, crea, habilitacao, codramo, coddepto) codramo referencia RAMOENG coddepto referencia DEPTO DEPTO (coddepto,, desc) SW (codsw,, desc) RAMOENG(codRamo,,desc) PROJETO (codproj,, desc) DOMINIO(codSW, codemp); codsw referencia SW codemp referencia EMPREGADO PARTICIPACAO (codemp, codproj) codproj referencia PROJETO codemp referencia EMPREGADO Pergunta-se: Considerando que a especialização de Empregado é total e exclusiva, qual seria o domínio de tipo? O que seria necessário verificar para manter a integridade dos dados em relação às regras de negócio? E se a especialização fosse inclusiva? Tradução de Hierarquias - distribuição Distribuição Chave primária repete-se em cada relação Nas relações específicas, a chave primária é também chave estrangeira para a relação genérica Incluir uma coluna tipo na relação genérica para manter a informação sobre a especialização Aplicar as regras já conhecidas

16 Traduzindo Hierarquias - distribuição EMPREGADO(codEmp,, tipo, coddepto) coddepto referencia DEPTO MOTORISTA(codEmp, habilitacao) codemp referencia EMPREGADO ENGENHEIRO (codemp, CREA, codramo) codemp referencia EMPREGADO SECRETARIA (codemp) codemp referencia EMPREGADO DEPTO (coddepto,, desc) SW (codsw,, desc) RAMOENG(codRamo,,desc) PROJETO (codproj,, desc) DOMINIO(codSW, codemp); codsw referencia SW codemp referencia SECRETARIA PARTICIPACAO (codemp, codproj) codproj referencia PROJETO codemp referencia ENGENHEIRO Pergunta-se: Porque codemp, nas relações específicas, deve ser chave estrangeira para EMPREGADO? Porque é importante manter o atributo tipo na relação genérica? O que seria necessário verificar para manter a integridade dos dados em relação às regras de negócio? O que ocorre quando a especialização é total e inclusiva? Traduzindo Hierarquias Tabela única Todos os dados em uma única tabela... Não há necessidade de navegação por outras tabelas para se obter todos os dados a respeito de um empregado Economia de espaço por um lado pois a chave primária não é duplicada, mas há desperdício por outro lado com os nulos que os campos das tabelas especificas trazem Várias tabelas Conceitos explicitos em relações próprias Redução de nulos Há uma terceira alternativa? Cada caso é um caso!

17 Nomes Nomes simples e reduzidos Ex data de nascimento ---> datanasc nao usar o da tabela a não ser em campos parte de chaves primárias Ex:codigo ----> codemp Exercício projetista dealer franchise entrega 12 entidades 13 relacionamentos mes v_max configuração modelo (1,M) côr côr competidor carro carroceria mercado preço título num motor capacidade estilo

18 Exercício dealer projetista franchise entrega mes v_max configuração modelo (1,M) côr côr competidor carro carroceria mercado preço título num motor capacidade estilo Exercício dealer mes franchise modelo entrega mes modelo projetista modelo (M,N) côr modelo v_max modelo modelo competidor configuração preço Nome carro carroceria título estilo mercado mercado nummotor nummotor estilo título num motor capacidade

19 Exercício ESQUEMA FINAL: ENTREGA ( mes, modelo ) FRANCHISE ( dealer, mes, modelo ) MODELO ( modelo, projetista ) MODELO-CÔR ( modelo, cor ) CONFIGURAÇÃO ( modelo, motor, v_max ) CARROCERIA ( modelo, estilo, mercado ) MERCADO ( mercado, competidor ) MOTOR ( motor, capacidade ) CARRO ( modelo, estilo, motor, preço )