Projeto de BD

1. Projeto de BD Análise de Requisitos Especificação de requisitos Projeto Conceitual Esquema conceitual Projeto Lógico Esquema lógico Projeto Físico Esquema físico ou implementação

2. Projeto Lógico de BDOO Entidades Classes Relacionamentos Atributos Atributos Herança Herança Associação Diagrama ERModelo OO (abstração da realidade) (organização de dados)

3. Modelo ER - Conceitos • Entidade • normal, fraca ou associativa • Relacionamento • auto-relacionamento, binário ou n-ário • cardinalidades • um-para-um, um-para-muitos ou muitos-para-muitos • participação opcional ou obrigatória das entidades envolvidas • Atributo • categorias • identificador, monovalorado, multivalorado, composto, obrigatório e opcional • Generalização e Especialização • total ou parcial • exclusiva ou não-exclusiva

4. a4 (0,1) a1 a2 (0,N) a5 papel 1 a6 (0,N) (1,N) r 5 r 6 r 3 (0,3) E1 E2 r 1 a7 papel 2 (1,1) (1,N) a3 (1,1) r 2 E3 E11 (1,N) E7 E8 a11 (1,1) E4 (1,1) a8 (1,N) (1,N) r 4 p (0,1) (0,N) (0,N) a9 E10 E12 E5 E6 E9 a12 a13 a10 Modelo ER - Notação

5. CPF Empregados Empregados Nome CPF Salário Nome Salário reajustaSalário maiorSalário Mapeamento de Entidades • Entidades tornam-se classes • controle de unicidade de atributos identificadores (CPF, p.ex.) deve ser definido • Métodos relevantes a nível de instâncias e da classe podem ser previstos

6. Número Número Produto Quantidade Data (1,N) (1,1) Itens Composição Pedidos Pedidos Itens (1) (2) Pedidos Número Número Número Data Produto Data Itens: SET ( TUPLE ( Número Produto Quantidade)) Quantidade Itens * Pedido Observações: (i)‘*’ pode ser SET, BAG ou LIST (ii) (1): acesso direto a instâncias de Itens; é possível modelar relacionamentos de outras classes com Itens (2): menor número de classes; melhor representação de agregação Entidades Fracas • (1) Duas classes + atributos de referência OU • (2) Entidade fraca como atributo da classe forte

7. Relacionamentos • Análise de 3 casos • 1:1 • 1:N • M:N • Participação obrigatória/opcional da entidade no relacionamento • se o SGBDOO não dá suporte explícito a estas RIsna ODL, então • definir métodos de RI

8. Data_inst Code Nome Local Responsável Nro (1,1) (1,1) Eventos Comissões Organização Comissões (1) Eventos Eventos (2) Nro Code Code Local Nome Nome Responsável NroComissão Comissão Evento LocalComissão Data_inst ResponsávelComissão Data_instComissão Observação: atributos do relacionamento ficam em alguma das classes em (1) Relacionamentos 1:1 • (1) Duas classes + atributos de referência OU • (2) Classe única com todas as propriedades

9. (1,N) (1,1) Lotação Empregados Departamentos Codd Nome Salário Nome CPF Departamentos Empregados Codd CPF Nome Nome Empregados * Departamento Salário Relacionamentos 1:N • Duas classes + atributos de referência

10. (1,N) (1,1) Departamentos Lotação Empregados CPF Codd Nome Salário TempoServiço Nome Empregados Departamentos CPF Codd Nome Nome Lotação: TUPLE ( Departamento TempoServiço) Empregados * Salário Relacionamentos 1:N • E se existem atributos no relacionamento? ficam na • classe do lado N, definindo um atributo com domínio • Tuple

11. (1,N) (0,N) Alocação Duração Empregados Projetos Codp Nome Salário Título CPF Projetos Empregados Codp CPF Título Nome Empregados * Projetos * Duração Salário Relacionamentos M:N • Duas classes + atributos de referência

12. (1,N) (0,N) Projetos Empregados Alocação Duração CPF Codp Salário Título Período DataInício Nome Empregados CPF Projetos Nome Codp Alocações: SET( TUPLE ( Projeto DataInício Período)) Título Empregados * Duração Salário Relacionamentos M:N • E se existem atributos no relacionamento?(i) o relacionamento fica em uma das classes como um atributo complexo • menos classes; certas consultas são prejudicadas

13. (1,N) (0,N) Projetos Empregados Alocação Duração CPF Codp Salário Título DataInício Período Nome Alocações Empregados Projetos Empregado Projeto CPF Codp DataInício Título Nome Período Alocações * Alocações * Duração Salário Relacionamentos M:N • E se existem atributos no relacionamento?(ii) pode-se criar uma classe para o relacionamento, com referências bidirecionais • acesso direto a instâncias de Alocações; mais classes

14. Empregados NroHabilitação (0,1) CPF CPF Empregados Nome Nome Salário Salário NroHabilitação Endereço Telefone (0,n) Telefone: SET (inteiro) Rua Endereço: TUPLE ( Rua, Número, Cidade) Número Cidade Atributos Especiais • Atributo Opcional: • (i) atributo que pode assumir NULL • (ii) atributo obrigatório em uma subclasse da entidade (?) • Atributo Composto: atributo com domínio tuple • Atributo Multivalorado: atributo com domínio set/list

15. CPF Pessoas Nome DataNasc Área Matrícula Alunos Professores Curso Titulação Pessoas CPF Nome DataNasc Professores Alunos Área Matrícula Titulação Curso Herança • Mapeadas diretamente para hierarquias de classes

16. CPF Pessoas Nome DataNasc Área Matrícula Alunos Professores Curso Titulação Pessoas Obs.: Indicar soluções para a resolução de conflitos de herança múltipla CPF Nome DataNasc Professores Alunos Área Matrícula Titulação Curso ProfessoresAlunos Herança Não-Exclusiva

17. Escalonamento (0,N) (1,N) Projetos Empregados Alocação Período DataInício (1,1) Execução (0,N) CodT Tarefas Descrição Entidade Associativa • Segue as diretrizes para mapeamento de • relacionamentos binários • Exemplo: entidade associativa Escalonamento

18. Alocações Empregado Projeto DataInício Empregados Projetos Período CPF Codp Tarefas * Título Nome Alocações * Alocações * Duração Salário Tarefas CodT Descrição Alocação Entidade Associativa • Resultado do mapeamento de Escalonamento

19. Exercício em Grupo • Sugira mapeamentos para relacionamentos ternários do ER • considerar 4 casos: • M:N:P • 1:M:N • 1:1:N • 1:1:1 • justificar as suas sugestões