Banco de Dados I – BD I Prof. Lineu Mialaret Aula 9: Mapeamento MER – Modelo Relacional

1. Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - IFSP Campus de Caraguatatuba Tecnólogo em Análise e Desenvolvimento de Sistemas 10 Semestre de 2013 Banco de Dados I – BD I Prof. Lineu Mialaret Aula 9:Mapeamento MER – Modelo Relacional

2. Desenvolvimento de um um Aplicativo de Banco de Dados Modelo Funcional Análise Visão de Negócio Requisitos + Regras de Negócio Modelo Conceitual Mapeamento Modelo Lógico Visão de Sistema Modelo Físico Projeto BD Operacional

3. Introdução • Um Banco de Dados em conformidade com o Modelo Entidade Relacionamento - MER pode ser representado por uma coleção de tabelas no Modelo Lógico Relacional ou Modelo Relacional. • Para cada conjunto de entidades (e dependendo do tipo de conjunto de relacionamentos) há, internamente no Banco de Dados Relacional, em princípio uma tabela única, registrando o nome do conjunto de entidades (ou relacionamentos) correspondente. • Tanto o MER quanto o Modelo Relacional são abstratos, ou seja, são representações abstratas e lógicas de domínios de conhecimento, os quais podem representar empresas reais. • Como esses dois modelos empregam princípios similares, pode-se converter, de maneira adequada, o Modelo Entidade Relacionamento - MER num Modelo Relacional. • Em ferramentas CASE robustas, esse mapeamento é realizado de forma transparente ao usuário.

4. Mapeamento do MER para o Modelo Relacional • Passos gerais para o mapeamento MER - Modelo Relacional: • Identificar todas as entidades, atributos e relacionamentos para o contexto de negócio. • Construir o Modelo Entidade Relacionamento – MER. • Encontrar o conjunto de tabelas preliminares e identificar as suas respectivas chaves primárias. • Identificar todos os atributos relevantes e associá-los às tabelas preliminares já definidas. • Há uma série de regras para realizar o devido mapeamento do Modelo Entidade Relacionamento para o Modelo Relacional.

5. Diagrama de Entidade-Relacionamento Ensina • Entidade:algo relativo a um domínio de conhecimento (problema) a ser tratado e sobre a qual há um interesse em armazenar e manipular dados e informação. • Relacionamento:ligação semântica entre entidades. • Atributo:propriedade de uma entidade (em certos casos também de um relacionamento). NDoc Professor Disciplina Notação 1 (Chen) Nome CodDisc Tel PreReq Disciplina Professor CodDisc NDoc Notação 2 (EI) Ensina PreReq Nome Tel

6. Regra 0 • Mapeamento: • É necessária apenas uma tabela para representar a entidade. • A chave primária dessa entidade se torna a chave primária da tabela relacional. Conjunto de Entidades Fortes

7. Conjunto de Entidades Fortes (1) • Um conjunto de entidades fortes se transforma numa tabela no Modelo Relacional com os mesmos atributos. customer-name customer-id customer-street customer-city Jones Smith Hayes 321-12-3123 019-28-3746 677-89-9011 Main North Main Harrison Rye Harrison customer relation

8. Conjunto de Entidades Fortes (2) (a) CUSTOMER entity with simple attributes (b) CUSTOMER relation

9. Grafo de Ocorrências ou Cardinalidade • O grafo de ocorrências ou cardinalidade exemplifica os relacionamentos que ocorrem entre as entidades de conjuntos de entidades. • A associação que ocorre entre conjuntos de entidades é definida como uma participação, a qual pode ser obrigatória ou opcional. Professor Ensina Disciplina P1 • P2 • P3 • P4 • • D1 • D2 • D3 • D4 Participação obrigatória Participação opcional Professor Professor Notação Chen usada para se referir a participação.

10. Participação – Relacionamento 1:1 P1 • P2 • P3 • P4 • • D1 • D2 • D3 • D4 Professor Disciplina P1 • P2 • P3 • • D1 • D2 • D3 • D4 Professor Disciplina P1 • P2 • P3 • P4 • • D1 • D2 • D3 Professor Disciplina P1 • P2 • P3 • P4 • • D1 • D2 • D3 • D4 Disciplina Professor

11. Participação - Relacionamento 1:N • D1 • D2 • D3 • D4 • D5 P1 • P2 • P3 • P4 • Disciplina Professor • D1 • D2 • D3 • D4 • D5 P1 • P2 • P3 • Professor Disciplina • D1 • D2 • D3 • D4 P1 • P2 • P3 • Professor Disciplina • D1 • D2 • D3 • D4 • D5 P1 • P2 • P3 • Disciplina Professor

12. Participação – Relacionamento N:1 P1 • P2 • P3 • P4 • P5 • • D1 • D2 • D3 • D4 Disciplina Professor P1 • P2 • P3 • P4 • P5 • • D1 • D2 • D3 • D4 Professor Disciplina P1 • P2 • P3 • P4 • • D1 • D2 • D3 Professor Disciplina P1 • P2 • P3 • P4 • P5 • • D1 • D2 • D3 Professor Disciplina

13. Participação - Relacionamento N:M P1 • P2 • P3 • P4 • P5 • • D1 • D2 • D3 • D4 • D5 Professor Disciplina • D1 • D2 • D3 • D4 • D5 P1 • P2 • P3 • P4 • P5 • Professor Disciplina P1 • P2 • P3 • P4 • P5 • • D1 • D2 • D3 • D4 Professor Disciplina P1 • P2 • P3 • P4 • P5 • • D1 • D2 • D3 • D4 • D5 Disciplina Professor

14. Regra 1 • Mapeamento • Solução 1: • É necessária apenas uma tabela. • A chave primária dessa tabela pode ser a chave primária de qualquer uma das entidades envolvidas no relacionamento. • Solução 2: • São necessárias duas tabelas, cada uma representando uma entidade, e a chave primária de cada uma das tabelas se torna a chave estrangeira (foreign key) da outra tabela. (Isto implica que há uma navegação bidirecional. Pode ser usada uma solução que implique numa navegação parcial) Relacionamento Binário 1:1 e Participação Obrigatória de Ambas as Entidades

15. Relacionamento Binário 1:1 Participação Obrigatória das duas Entidades Ensina NDoc Professor Disciplina Nome CodDisc Tel PreReq Solução 1: ProfessorDisciplina O atributo CodDisc também poderia ser chave primária dessa tabela

16. Relacionamento Binário 1:1 Participação Obrigatória das duas Entidades Ensina Disciplina NDoc Professor Nome CodDisc Tel PreReq Solução 2: Professor Disciplina chave estrangeira chave estrangeira

17. Regra 2 • Mapeamento: • São necessárias duas tabelas, uma para cada entidade. • A chave primária de cada entidade serve de chave primária na tabela correspondente. • A chave primária da entidade com participação não obrigatória é usada como atributo (chave estrangeira) na tabela correspondente à entidade cuja participação é obrigatória. Relacionamento Binário 1:1 e Participação Obrigatória de apenas uma das Entidades

18. Relacionamento Binário 1:1 Participação Obrigatória de apenas uma das Entidades Ensina Disciplina NDoc Professor Nome CodDisc Tel PreReq ProfessorDisciplina Surgem valores nulos (Null) sempre que há uma disciplina que não tem professor. Essa solução é válida, mas não adequada

19. Relacionamento Binário 1:1 Solução: Professor Disciplina São necessárias duas tabelas: Professor (NDoc, Nome, Tel, CodDisc) Disciplina (CodDisc, PreReq) É uma chave estrangeira

20. Regra 3 • Mapeamento: • São necessárias duas tabelas, uma para cada entidade. • A chave primária de cada entidade serve de chave primária na tabela correspondente. • A chave primária de cada uma das tabelas se torna chave estrangeira (foreign key) da outra. Relacionamento Binário 1:1 e Participação Opcional de ambas Entidades

21. Relacionamento Binário 1:1 Participação Obrigatória de nenhuma das Entidades Ensina Disciplina NDoc Professor Nome CodDisc Tel PreReq ProfessorDisciplina Surgem valores nulos (Null) quer para as disciplinas que não têm professor, quer para os professores que não lecionam nenhuma disciplina. Não há como chavear a tabela.

22. Relacionamento Binário 1:1 Participação Obrigatória de nenhuma das Entidades Solução: Professor Disciplina

23. Regra 4 • Mapeamento: • São necessárias duas tabelas, uma para cada entidade. • A chave primária de cada entidade serve de chave primária na tabela correspondente. • A chave primária da entidade do lado 1 é usada como atributo (chave estrangeira) na tabela correspondente à entidade do lado N. Relacionamento Binário 1:N com Participação Obrigatória ou Opcional no lado 1 e Participação Obrigatória do lado N

24. Relacionamento Binário 1:N Participação obrigatória do lado N Ensina Disciplina NDoc Professor Nome CodDisc Tel PreReq ProfessorDisciplina Surgem valores nulos (Null) sempre que há um professor que não tem disciplina. Não há como chavear a tabela

25. Relacionamento Binário 1:N Solução: Disciplina Professor São necessárias duas relações: Professor (Ndoc, Nome, Tel) Disciplina (CodDisc, PreReq, NDoc) Chave estrangeira

26. Regra 5 Relacionamento Binário 1:N com Participação Obrigatória ou Opcional no lado 1 e Participação Opcional do lado N • Mapeamento: • São necessárias duas tabelas, uma para cada entidade. • A chave primária de cada entidade serve de chave primária na tabela correspondente. • A chave primária da entidade do lado 1 é usada como atributo (chave estrangeira) na tabela correspondente à entidade do lado N.

27. Relacionamento Binário 1:N Participação Opcional de ambos os lados Ensina Disciplina NDoc Professor Nome CodDisc Tel PreReq ProfessorDisciplina Por que a solução em uma tabela única não é viável?

28. Relacionamento Binário 1:N Solução: Disciplina Professor São necessárias duas relações: Professor (Ndoc, Nome, Tel) Disciplina (CodDisc, PreReq, NDoc) Chave estrangeira

29. Regra 6 Relacionamento Binário M:N • Mapeamento: • São necessárias três tabelas, uma para cada entidade e uma terceira para o relacionamento. • A chave primária de cada entidade serve de chave primária na tabela correspondente. • A tabela relativa ao relacionamento terá de ter entre os seus atributos chaves (que compõem a chave primária da tabela) as chaves primárias de cada uma das entidades envolvidas no relacionamento.

30. Relacionamento Binário M:N (1) Ensina Disciplina NDoc Professor Nome CodDisc Tel PreReq ProfessorDisciplina Por que a solução em uma tabela única não é viável?

31. Relacionamento Binário M:N (2) • Quando o relacionamento binário é M:N, e independentemente do tipo de participação, são sempre necessárias três tabelas. Solução: Disciplina Professor Ensina

32. Regra 7 • Mapeamento: • São sempre necessárias quatro tabelas, uma para cada entidade e uma quarta para o relacionamento. • A chave primária de cada entidade serve de chave primária na tabela correspondente. • A tabela relativa ao relacionamento terá de ter entre os seus atributos chave (que compõem a chave primária da tabela) as chaves primárias de cada uma das outras tabelas. • Em relacionamentos de grau N são necessárias N+1 tabelas, de modo inteiramente com o mapeamento de mode análogo. Relacionamento Ternário (e superior)

33. Relacionamento Ternário ou Superior (1) (a) Ternary relationship.

34. Relacionamento Ternário ou Superior (2) (b) Mapping the ternary relationship.

35. Regra 8 Atributos Multivalorados • Mapeamento: • É necessária uma tabela para a entidade (ou relacionamento) e seus atributos que não são multivalorados. • Cria-se uma nova tabela R que inclui como atributos o atributo multivalorado A mais a chave primária K da tabela que representa a entidade (ou relacionamento) que tem A como atributo. • A chave primária de R é a combinação de A e K.

36. Atributos Multivalorados (a) a) Mapping a multivalued attribute. Multivalued attribute becomes a separate relation with foreign key. (b) b) 1:M relationship between original entity and new relation.

37. Regra 9 Atributos Compostos • Mapeamento: • É necessária uma tabela para a entidade (ou relacionamento) e seus atributos que não são compostos. • Se o atributo é composto, incluir seus componentes atômicos na tabela correspondente à entidade que possui esse atributo.

38. Atributos Compostos (a) CUSTOMER entity with composite attribute (b) CUSTOMER relation with address detail Mapping a composite attribute.

39. Regra 10 Entidades Fracas • Mapeamento: • Para cada entidade fraca W relacionada com uma entidade forte E, cria-se uma tabela R e incluí-se todos os atributos simples deW como atributos de R. • Incluí-se como atributos da chave estrangeira de R os atributos que compõem a chave primária da entidade forte E. • A chave primária da tabela R é a combinação da chave primária da entidade forte E (que é chave estrangeira em W) e a chave parcial da entidade fraca W.

40. Entidades Fracas (1) a) Example of a weak entity DEPENDENT.

41. Composite primary key Entidades Fracas (2) Foreign key b) Relations resulting from weak entity.

42. Regra 11 Relacionamento Recursivo • Mapeamento: • Para relacionamentos recursivos 1:N - • Usar de uma chave estrangeira recursiva (um atributo que referencia o atributo chave da própria tabela) na mesma tabela. • Para relacionamentos recursivos M:N - • Criar duas tabelas, sendo uma para a entidade envolvida. • A outra tabela é usada para representar o relacionamento recursivo, sendo que sua chave primária possui dois atributos, ambos tomados da chave primária da entidade.

43. Relacionamento Recursivo (1) (a) EMPLOYEE entity with Manages relationship (b) EMPLOYEE relation with recursive foreign key Mapping a unary 1:N relationship.

44. Relacionamento Recursivo (2) (b) ITEM and COMPONENT relations (a) Bill-of-materials relationships (M:N) Mapping a unary M:N relationship.

45. Regra 12 Relacionamento de Herança • Mapeamento: • É criada uma tabela para o supertipo e uma tabela para cada subtipo. • Os atributos do supertipo (incluindo as suas chaves) são mapeados para uma tabela correspondente. • os atributos dos subtipos são mapeados para tabelas correspondentes aos subtipos, e a chave primária do supertipo se torna chave primária (chave estrangeira) do subtipo.

46. Relacionamento de Herança (1) Supertype/subtype relationships.

47. Relacionamento de Herança (2) Mapping Supertype/subtype relationships to relations

48. MER no PowerDesigner (1) MER no PowerDesigner com Diversos Tipos de Participações.

49. Modelo Relacional no PowerDesigner (1) Modelo Relacional no PowerDesigner Gerado do MER Anterior.

50. MER no PowerDesigner (2) MER com Herança no PowerDesigner.