Transformação ER para modelo relacional

Transcrição

1 Transformação ER para modelo relacional BCD29008 Engenharia de Telecomunicações Prof. Emerson Ribeiro de Mello 04 DE SETEMBRO DE 2018

2 Revisão das aulas anteriores

3 Entidades Entidade é uma coisa ou objeto do mundo real que é distinguível de todos os outros objetos Conjunto de entidades reúne entidades do mesmo tipo que compartilham as mesmas propriedades ou atributos 1/36

4 Relacionamentos Definição matemática (teoria dos conjuntos): Produto cartesiano Dados dois conjuntos, A e B o produto cartesiano desses conjuntos (A B) é o conjunto com todos os pares de ambos conjuntos 2/36

5 Relacionamentos Definição matemática (teoria dos conjuntos): Produto cartesiano Dados dois conjuntos, A e B o produto cartesiano desses conjuntos (A B) é o conjunto com todos os pares de ambos conjuntos Relacionamento Relacionamento é um subconjunto de A B 2/36

6 Relacionamentos Relacionamento Associação entre Entidades Relacionamento: FAZ subconjunto de Aluno Curso Uma entidade pode aparecer 0, 1 ou mais vezes no relacionamento A combinação de entidades (i.e. João Tele) só pode aparecer uma única vez 3/36

7 Cardinalidade máxima de relacionamento 4/36

8 Cardinalidade máxima de relacionamento Uma entidade em Funcionário pode estar associada a no máximo uma entidade em Departamento Uma entidade em Departamento pode estar associada a muitas entidades em Funcionário 4/36

9 Identificador de entidade Conjunto de um ou mais atributos e relacionamentos cujos valores servem para distinguir uma entidade no conjunto de entidades 5/36

10 Identificador de entidade Conjunto de um ou mais atributos e relacionamentos cujos valores servem para distinguir uma entidade no conjunto de entidades Identificando entidade por meio do atributo Identificando entidade por meio do atributo e do relacionamento 5/36

11 Relacionamentos: Atributos Um engenheiro pode ter diferentes funções em diferentes projetos Taxa de juros e número de parcelas só fazem sentido para vendas parceladas 6/36

12 Identificando relacionamentos Uma ocorrência de relacionamento diferencia-se das demais ocorrências do mesmo relacionamento pelas ocorrências de entidades que dela participam Para cada par (engenheiro, projeto) há no máximo uma ocorrência do relacionamento Atuação 7/36

13 Identificando relacionamentos Uma ocorrência de relacionamento diferencia-se das demais ocorrências do mesmo relacionamento pelas ocorrências de entidades que dela participam Para cada par (engenheiro, projeto) há no máximo uma ocorrência do relacionamento Atuação Há casos onde um mesmo par de entidades pode resultar em diversas ocorrências do relacionamento O relacionamento precisa ter um atributo identificador 7/36

14 Identificando relacionamentos Nota Algumas abordagens ER não permitem usar atributos identificadores nos relacionamentos (típico em relacionamentos n:n) Solução: Relacionamentos devem ser transformados em entidades 8/36

15 Identificando relacionamentos Nota Algumas abordagens ER não permitem usar atributos identificadores nos relacionamentos (típico em relacionamentos n:n) Solução: Relacionamentos devem ser transformados em entidades 8/36

16 Transformação do modelo ER para o modelo relacional

17 ER e Relacional Modelagem ER Modelo conceitual independente do SGBD Modelagem Relacional Modelo lógico modela os dados no nível de SGBD Modelo ER pode ser implementado por diferentes modelos relacionais Diferentes modelos relacionais podem gerar desempenho, facilidades de uso e manutenção diferentes 9/36

18 Transformação entre modelo ER e relacional 10/36

19 Objetivos do projeto de BD e regras de tradução Objetivos básicos de um projeto de BD Bom desempenho nas operações de consulta e alteração Simplificar o desenvolvimento e manutenção de aplicações 11/36

20 Objetivos do projeto de BD e regras de tradução Objetivos básicos de um projeto de BD Bom desempenho nas operações de consulta e alteração Simplificar o desenvolvimento e manutenção de aplicações Regras de tradução (usadas nos próximos exemplos) Evitar junções (JOIN) ter os dados necessários a uma consulta em uma única tabela Minimizar número de chaves evitar a criação de índices pelo BD Evitar campos opcionais campos com valores NULL 11/36

21 Processo de um projeto lógico 1 Implementar entidades e respectivos atributos 2 Implementar relacionamentos e respectivos atributos 3 Implementar generalizações/especificações 12/36

22 Implementar entidades Nome da Entidade pode ser usado como nome da tabela Nome dos atributos são mapeados para nome de colunas É recomendável que o nome da chave primária tenha como sufixo o nome da tabela Aluno(idAluno, nome) 13/36

23 Relacionamento identificador Cria-se uma chave estrangeira na tabela que implementa a entidade identificada pelo relacionamento Na entidade fraca, a chave primária deve ser formada por atributos identificadores da entidade chaves estrangeiras que implementam os relacionamentos identificadores Dependente(idDependente, idempregado, Nome) 14/36

24 Relacionamento identificador Quando a entidade fraca referencia outra entidade fraca, ou seja, que também possui um relacionamento identificador, é necessário propagar por vários níveis a importação de chaves estrangeiras 15/36

25 Relacionamento identificador Grupo(idGrupo, nome) Empresa(idEmpresa, idgrupo, nome) Empregado(idEmpregado, idempresa, idgrupo, nome) Dependente(idDependente, idempregado, idempresa, idgrupo, nome) 15/36

26 Implementação de relacionamentos A cardinalidade mínima e máxima são fatores determinantes para indicar qual a tradução adequada Tabela própria Adição de colunas em uma das entidades participantes Fusão de tabelas de entidades 16/36

27 Relacionamento: Tabela própria Obrigatório quando cardinalidade n..n Chave primária formada pelas chaves primárias das entidades relacionadas + atributos identificadores do relacionamento Engenheiro(idEng, nome) Projeto(idProj, nome) Atuacao(idEng, idproj, funcao) ideng referencia Engenheiro idproj referencia Projeto 17/36

28 Relacionamento: Adição de coluna Possível quando uma das entidades possuir cardinalidade máxima 1 Inserir além dos atributos do relacionamento, as colunas identificadoras da entidade relacionada, definidas como chave estrangeira Departamento(idDepto, nome) Funcionario(idFuncionario, nome, iddepto, datalotacao) iddepto referencia Departamento 18/36

29 Relacionamento: Fusão de tabelas Possível somente quando o relacionamento é um-para-um Uma única tabela combina atributos das entidades e do relacionamento Motorista(idMotorista, nome, turno, categoriaveiculo) 19/36

30 Implementação de relacionamentos cardinalidade mínima e máxima são fatores determinantes para a tradução adequada Tipo Tabela própria Adição de Coluna Fusão Um-para-um Um-para-muitos n n n n - Muitos-para-muitos 0..n 0..n 0..n 1..n 1..n 1..n 20/36

31 Relacionamentos um-para-um: Ambas entidades com participação opcional Adição de colunas na tabela referente a qualquer uma das entidades participantes Artigo(idArtigo, titulo, data, idautor) idautor referencia Autor Autor(idAutor, nome) 21/36

32 Relacionamentos um-para-um: Ambas entidades com participação opcional + Tabela própria Artigo(idArtigo, titulo) Autor(idAutor, nome) Escrita(idArtigo,idAutor, data) idartigo referencia Artigo idautor referencia Autor 21/36

33 Relacionamentos um-para-um: Uma entidade tem participação obrigatória Fusão de tabelas Aluno(idAluno, nome, idtcc, titulo, defesa) + Adição de colunas Aluno(idAluno, nome) TCC(idTCC, titulo, defesa, idaluno) idaluno referencia Aluno 22/36

34 Relacionamentos um-para-um: Ambas entidades tem participação obrigatória Fusão de tabelas Motorista(idMotorista, nome, turno, categoriaveiculo) 23/36

35 Relacionamentos um-para-muitos: n Adição de colunas Campus(idCampus, nome) Sala(idCampus, idsala, area) idcampus referencia Campus 24/36

36 Relacionamentos um-para-muitos: n Adição de colunas Financeira(idFinanceira, nome) Venda(idVenda, data, idfinanceira, nparcelas, juros) idfinanceira referencia Financeira 25/36

37 Relacionamentos um-para-muitos: n + Tabela própria Financeira(idFinanceira, nome) Venda(idVenda, data) Financia(idVenda, idfinanceira, nparcelas, juros) idvenda referencia Venda idfinanceira referencia Financeira 26/36

38 Relacionamentos muitos-para-muitos: n n Sempre será necessário fazer com tabela própria Engenheiro(idEng, nome) Projeto(idProj, nome) Atuaç~ao(idEng, idproj, funcao) ideng referencia Engenheiro idproj referencia Projeto 27/36

39 Cardinalidade no SQL Na linguagem SQL a cardinalidade refere-se quantos valores únicos uma determinada coluna contém para um número específico de linhas Quanto mais baixa a cardinalidade, maior o número de tuplas com o mesmo valor na coluna SGBD relacionais usam a cardinalidade para determinar o plano de consulta otimizado para uma determinada consulta Conjunto ordenado de passos usado para acessar dados em BD relacional Pode-se também usar a cardinalidade para determinar se a tabela precisaria ser normalizada 28/36

40 Cardinalidade no SQL Cardinalidade alta Colunas cujo valores são únicos ou é bem incomum haver a repetição desse por diversas tuplas (Ex: idaluno) Cardinalidade normal Colunas cujos valores podem repetir, mas não é tão comum haver um grande número de repetições (Ex: coluna endereco) Cardinalidade baixa Colunas cujos valores se repetem muito constantemente (Ex: coluna sexo) id idaluno nome endereco sexo curso João Rua Abc M EngTelecom José Rua Xyz M EngTelecom Maria Rua Hee F EngTelecom Ana Rua Abc F EngTelecom João Rua Jeer M EngComputação 29/36

41 Relacionamentos de grau maior que 2 1 Relacionamento é transformado em entidade 2 Essa nova entidade é ligada por meio de relacionamento binário com cada uma das demais entidades que participavam do relacionamento 30/36

42 Relacionamentos de grau maior que 2 1 Relacionamento é transformado em entidade 2 Essa nova entidade é ligada por meio de relacionamento binário com cada uma das demais entidades que participavam do relacionamento 30/36

43 Relacionamentos de grau maior que 2 Distribuidor(idDist, nome) Cidade(idCid, nome) Produto(idProd, nome) Distribuicao(idProd, idcid, iddist, data) idprod referencia Produto idcid referencia Cidade iddist referencia Distribuidor 31/36

44 Generalização/Especialização Uma tabela para toda hierarquia Uma tabela por entidade especializada 32/36

45 Generalização/Especialização Uma tabela para toda hierarquia Funcionario(idFuncionario, nome, tipo, iddepto, CNH, CREA, idramo) iddepto referencia Departamento idramo referencia Ramo Participa(idFuncionario, idprojeto) idfuncionario referencia Funcionario idprojeto referencia Projeto 32/36

46 Generalização/Especialização Uma tabela por entidade especializada Funcionario(idFuncionario, nome, tipo, iddepto) iddepto referencia Departamento Motorista(idFuncionario, CNH) idfuncionario referencia Funcionario Engenheiro(idFuncionario, CREA, idramo) idfuncionario referencia Funcionario idramo referencia Ramo Participa(idFuncionario, idprojeto) idfuncionario referencia Engenheiro idprojeto referencia Projeto 32/36

47 Exercícios

48 Exercício 1 33/36

49 Exercício 2 34/36

50 Prática com MySQLWorkbench Prática com MySQLWorkbench 35/36

51 Aulas baseadas em HEUSER, C. A. PROJETO DE BANCO DE DADOS 6a. Edição - Editora Bookman, /36