Modelagem

2.813 visualizações

Publicada em

Publicada em: Educação
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.813
No SlideShare
0
A partir de incorporações
0
Número de incorporações
16
Ações
Compartilhamentos
0
Downloads
117
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Modelagem

  1. 1. Projeto do Banco de Dados <ul><li>1. caracterizar todos os dados necessários na perspectiva do usuário Resultado: especificação das necessidades do usuário (análise de requisitos) </li></ul><ul><li>2. transcrever as necessidades especificadas em esquema conceitual de BD. Resultado: projeto-conceitual </li></ul><ul><li>3. transporte do modelo de dados abstrato para sua implementação: </li></ul><ul><ul><li>projeto lógico :o esquema conceitual de alto nível mapeado para modelo de implementação de dados do SGBD que será usado </li></ul></ul><ul><ul><li>projeto físico : dependente dos recursos do SGBD, cuida das formas de organização de arquivos e estruturas internas de armazenamento. </li></ul></ul>
  2. 2. Etapas para o projeto de um BD Análise de requisitos Projeto Lógico Projeto Físico Projeto Conceitual (DER) As etapas não consideram ainda nenhuma característica específica de um SGBD Analista: Entrevista Necessidade do negócio Modelagem de dados Definição: entidade, atributo, relaciona- mentos. Definição de tabelas Índices, Visões Construção do BD Ling. SQL Dicionário de dados
  3. 3. Análise de requisitos <ul><li>A análise ou engenharia de requisitos é o primeiro passo do processo de software. É nesse ponto que uma declaração geral do escopo do software é refinada para constituir uma especificação completa que se torna a base de todas as atividades de engenharia de software que se seguem. </li></ul><ul><li>A análise de requisitos fornece um mecanismo adequado para entender o que o cliente deseja, analisar as necessidades, negociar uma solução razoável, especificar e validar a solução. </li></ul>
  4. 4. <ul><li>Problemas em potencial que nos ajudam a compreender por que a análise de requisitos é difícil: </li></ul><ul><ul><ul><li>Problemas de escopo  o limite do sistema é mal definido ou o cliente especifica detalhes desnecessários. </li></ul></ul></ul><ul><ul><ul><li>Problemas de entendimento  os clientes/usuários não estão completamente certos do que é necessário, têm dificuldade de comunicar as necessidades e omitem informação que acreditam ser “óbvia”. </li></ul></ul></ul><ul><ul><ul><li>Problemas de volatilidade  os requisitos mudam ao longo do tempo. </li></ul></ul></ul>Análise de requisitos
  5. 5. <ul><li>Para ajudar a contornar esses problemas, os engenheiros (analistas) de sistemas devem abordar a atividade de análise de requisitos de um modo organizado. </li></ul><ul><li>Sommerville e Sawyer (1997) sugerem os seguintes passos: </li></ul><ul><ul><ul><li>Avalie a viabilidade técnica e de negócios do sistema proposto; </li></ul></ul></ul><ul><ul><ul><li>Identifique as pessoas que vão ajudar a especificar os requisitos; </li></ul></ul></ul><ul><ul><ul><li>Defina o ambiente técnico no qual o sistema vai ser colocado; </li></ul></ul></ul><ul><ul><ul><li>Defina um ou mais métodos para o levantamento dos requisitos (entrevistas, reuniões de equipe, etc) </li></ul></ul></ul>Análise de requisitos
  6. 6. Parte III Projeto Conceitual (Modelagem de Dados)
  7. 7. Projeto Conceitual <ul><li>Pode ser considerada a fase de análise dos dados (ou requisitos) capturados na etapa anterior. </li></ul><ul><li>Nesta etapa é realizada o que se chama de modelagem conceitual: são analisados os fatos (entidades) de interesse e seus relacionamentos, juntamente com seus atributos (propriedades ) e construída uma notação gráfica (abstrata, uma representação de alto nível) para facilitar o entendimento dos dados e suas relações. </li></ul><ul><li>A ferramenta mais empregada nesta etapa é o Diagrama Entidade-Relacionamento (DER) </li></ul>
  8. 8. Os elementos da análise estruturada (revisão) DER DFD Mostra as relações entre os objetos de dados. Mostra o fluxo de dados e as transformações que são aplicadas à medida que os dados se movem da entrada para a saída.
  9. 9. Exemplo - DFD Verificar validade do pedido CLIENTES pedidos EDITORAS Livros Clientes Editoras Pedidos Pendentes Preparar requisição p/ a editora situação de crédito ordens de compra endereço detalhes de livros pedidos válidos pedidos agrupados
  10. 10. Exemplo - DER
  11. 11. DER – Diagrama Entidade-Relacionamento <ul><li>O Diagrama Entidade-Relacionamento (DER ) ou Modelo Entidade-Relacionamento (MER) foi definido por Peter Chen em 1976. </li></ul><ul><li>Peter Chen formulou a proposta do modelo E-R, baseou-se na compreensão da realidade em que se situava o problema. </li></ul><ul><li>“ Como iremos projetar um sistema se não entendemos o negócio para o qual será realizado? “ </li></ul>
  12. 12. <ul><li>Dez anos depois que Peter Chen inventou o DER, a modelagem estava se tornando amplamente utilizada; no entanto, surgiram muitas formas concorrentes, tais como: </li></ul><ul><ul><li>MER estendido, proposto por Teorey (1986); </li></ul></ul><ul><ul><li>Os europeus focaram-se no NIAM (Naturallanguage Information Analysis Method; </li></ul></ul><ul><ul><li>Nos anos 90, o setor de sistemas de informação começou a adotar duas grandes variações: IDEF1X (Bruce, 1992) e os dialetos de engenharia da informação, normalmente conhecidos como “diagramação pé-de-galinha” (Everest, 1986). </li></ul></ul>DER – Diagrama Entidade-Relacionamento
  13. 13. <ul><li>Um DER é uma representação gráfica, na forma de um diagrama, onde são utilizados inicialmente apenas 3 conceitos: </li></ul><ul><ul><ul><li>Entidade </li></ul></ul></ul><ul><ul><ul><li>Atributo </li></ul></ul></ul><ul><ul><ul><li>Relacionamento </li></ul></ul></ul>DER – Diagrama Entidade-Relacionamento
  14. 14. Entidade <ul><li>Entidade é uma “coisa” ou um “objeto” no mundo real que pode ser identificada de forma unívoca em relação a todos os outros objetos. </li></ul><ul><li>A entidade pode ser concreta (pessoa, livro), ou pode ser abstrata (empréstimo, viajem de férias ou um conceito). </li></ul><ul><li>Conjunto de entidades é um conjunto de entidades de mesmo tipo que compartilham as mesmas propriedades: os atributos. </li></ul>
  15. 15. Atributos <ul><li>Atributos = propriedades descritivas de cada ocorrência de uma entidade ou relacionamento. </li></ul><ul><li>Cada atributo possui um domínio (conjunto de valores possíveis). </li></ul><ul><li>Atributos possíveis ao conjunto de entidades clientes: nome_cliente , cnpj , end_cliente . </li></ul>
  16. 16. Atributos <ul><li>Um atributo pode ser caracterizado pelos seguintes tipos: </li></ul><ul><ul><li>simples ou compostos </li></ul></ul><ul><ul><li>monovalorados ou multivalorados </li></ul></ul><ul><ul><li>nulos </li></ul></ul>Descrição: próxima página...
  17. 17. Atributos simples ou compostos <ul><li>Atributo simples: não é dividido em partes. </li></ul><ul><li>Atributo composto pode ser dividido em partes (isto é, outros atributos). </li></ul><ul><li>Ex: nome_cliente pode ser estruturado em: </li></ul><ul><li>prenome , nome-intermediário e sobrenome . </li></ul>
  18. 18. Atributos mono ou multivalorados <ul><li>O atributo num_emprestimo de uma entidade específica refere-se apenas a um número de empréstimo. </li></ul><ul><li>O atributo número do telefone pode assumir mais de um valor, como os números de telefone de uma empresa. </li></ul>
  19. 19. Atributo nulo <ul><li>Usado quando uma entidade não possui valor para determinado atributo. </li></ul><ul><li>Ex: se um empregado em particular não possui dependentes, o valor do atributo nome_dependente para este dependente deverá ser nulo , e isto significa que este atributo “não é aplicável”. </li></ul><ul><li>Nulo também pode significar que o valor do atributo é desconhecido. </li></ul>
  20. 20. Representação gráfica CLIENTE Principais convenções: <ul><li>Nome da entidade singular e único. </li></ul><ul><li>Nome da entidade em maiúsculo. </li></ul><ul><li>Nomes dos atributos em minúsculo. </li></ul><ul><li>Cada Entidade deve ser identificada unicamente. </li></ul><ul><li>Um atributo ou conjunto de atributos que identificam a unicidade da ocorrência em uma Entidade é chamado de Identificador Único (UID). </li></ul>
  21. 21. Representação gráfica CLIENTE Cod_cli Nome End Cod_cli CLIENTE Nome End Uma entidade CHEN Uma entidade IDEF1X Método:
  22. 22. Relacionamentos <ul><li>Representam associações entre entidades. </li></ul><ul><li>Em um DER, um relacionamento é representado através de um losango , ligado por linhas aos retângulos representativos das entidades. </li></ul><ul><li>Um relacionamento pode ter atributos. </li></ul><ul><ul><li>Exemplo de relacionamento . </li></ul></ul><ul><li>Não necessariamente um relacionamento associa entidades diferentes. Um auto-relacionamento demonstra um relacionamento entre ocorrências de uma mesma entidade. Neste caso, existe o conceito de papel(função) da entidade no relacionamento. </li></ul><ul><ul><li>Exemplo de auto-relacionamento . </li></ul></ul>
  23. 23. Exemplos ENGENHEIRO PROJETO Atuação Exemplo : Relacionamento
  24. 24. Exemplos Exemplo : Auto-relacionamento PESSOA Casamento marido esposa
  25. 25. Cardinalidade de relacionamentos <ul><li>Uma propriedade importante de um relacionamento é a de quantas ocorrências de uma entidade podem estar associadas a uma determinada ocorrência através do relacionamento. </li></ul><ul><li>Há duas cardinalidades a considerar: a cardinalidade máxima e a cardinalidade mínima . </li></ul><ul><li>Classificação de relacionamentos binários: </li></ul><ul><ul><li>1:1 (um-para-um) </li></ul></ul><ul><ul><li>1:n (um-para-muitos) </li></ul></ul><ul><ul><li>n:n (muitos-para-muitos) </li></ul></ul>
  26. 26. Relacionamento 1:1 <ul><li>Neste grau de relacionamento, cada elemento de uma entidade relaciona-se com um e somente um elemento de outra entidade. </li></ul><ul><li>Devemos ler o relacionamento nos dois sentidos em que ele se efetua. Logo lemos no caso da entidade Homem e da entidade Mulher, que um Homem está casado somente com uma Mulher e uma Mulher está casada com somente um Homem. </li></ul>HOMEM MULHER CASADO 1 1 HOMEM MULHER CASADO 1 1 Resultado idêntico: 1:1
  27. 27. Relacionamento 1:n <ul><li>Um elemento da Entidade 1 relaciona-se com muitos elementos da Entidade 2, mas cada elemento da Entidade 2 somente pode estar relacionado a um elemento da Entidade 1. </li></ul><ul><li>Devemos ter como regra geral,que um relacionamento é do tipo Um-para-Muitos, quando um sentido de leitura dos fatos nos apresenta este grau de Um-para-Muitos e o sentido oposto apresenta obrigatoriamente o grau Um-para-Um. </li></ul>EMPREGADO DEPTO LOTAÇÃO N 1
  28. 28. <ul><li>Identifica-se esta cardinalidade pelo fato de que em ambos os sentidos de leitura encontramos um grau 1:n, o que caracteriza ser então um contexto geral de n:n ( Muitos-para-Muitos ). </li></ul>Relacionamento n:n ENGENHEIRO PROJETO ALOCAÇÃO N N MÉDICO PACIENTE CONSULTA N N
  29. 29. Cardinalidade de atributos <ul><li>Um atributo pode assumir uma cardinalidade, de maneira análoga a uma entidade em um relacionamento. </li></ul><ul><li>A cardinalidade de um atributo define quantos valores deste atributo podem estar associados a uma ocorrência da entidade / relacionamento a qual ele pertence. </li></ul><ul><li>No caso da cardinalidade ser (1,1) ela pode ser omitida do diagrama. </li></ul>
  30. 30. <ul><li>Assim, o exemplo abaixo expressa que nome e código são atributos obrigatórios (cardinalidade mínima “1” – cada entidade possui no mínimo um valor associado) e monovalorados (cardinalidade máxima “1” – cada entidade possui no máximo um valor associado). </li></ul><ul><li>Já o atributo telefone, é um atributo opcional (cardinalidade mínima 0) e multivalorado (cardinalidade máxima n). </li></ul>Cardinalidade de atributos CLIENTE Cod_cli Telefone (0,n) Nome
  31. 31. Atributos de relacionamento <ul><li>Assim como entidades, relacionamentos também podem possuir atributos. </li></ul><ul><li>A figura abaixo, expressa um DER no qual um relacionamento, Atuação, possui um atributo, a função que um engenheiro exerce dentro de um projeto. </li></ul><ul><ul><li>Um engenheiro pode atuar em diversos projetos, exercendo diferentes funções. </li></ul></ul><ul><ul><li>Em um projeto, podem atuar diversos engenheiros com funções diferentes. </li></ul></ul>ENGENHEIRO PROJETO ATUAÇÃO N N Função
  32. 32. Entidade Fraca <ul><li>Em geral, uma entidade possui um único atributo como identificador. </li></ul><ul><li>Em alguns casos, o identificador de uma entidade é composto por diversos atributos. </li></ul>PESSOA Codigo Nome Endereço PRATELEIRA Num_corredor Num_prateleira Capacidade
  33. 33. <ul><li>Finalmente, há casos em que o identificador de uma entidade é composto não somente por atributos da própria entidade, mas também por relacionamentos dos quais a entidade participa. </li></ul>Entidade Fraca EMPREGADO DEPENDENTE Resp. (1,1) (0,n) Cód_emp nome Num_seq. nome Id = cod_emp + num_seq.
  34. 34. Entidade Fraca <ul><li>Neste caso, a entidade DEPENDENTE é considerada uma entidade “fraca”, pois a entidade somente pode existir quando relacionada a outra entidade e de usar como parte de seu identificador, entidades relacionadas. </li></ul>
  35. 35. Especialização / Generalização <ul><li>O conceito de especialização permite atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica. </li></ul><ul><li>No DER, o símbolo para representar especialização é um triângulo. </li></ul><ul><li>A especialização mostra que a entidade cliente é dividida em dois subconjuntos, as entidades pessoa física e pessoa jurídica, cada uma com propriedades próprias. </li></ul><ul><li>Associada ao conceito de especialização está a idéia de herança de propriedades. Herdar propriedades significa que 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. </li></ul>
  36. 36. Especialização / Generalização FILIAL CLIENTE Fil-Cli (1,1) (0,n) PESSOA FÍSICA PESSOA JURÍDICA código nome cpf cnpj
  37. 37. <ul><li>A especialização pode ser classificada em dois tipos, total ou parcial , de acordo com a obrigatoriedade ou não de a cada ocorrência da entidade genérica corresponder uma ocorrência da entidade especializada. </li></ul>Especialização / Generalização CLIENTE PESSOA FÍSICA PESSOA JURÍDICA t EMPREGADO MOTORISTA SECRETÁRIA p Indica que cliente é PF ou PJ Indica que nem todo EMP é motorista ou secretária
  38. 38. Relacionamento Ternário <ul><li>Todos os exemplos até aqui mostrados são de relacionamentos binários. </li></ul><ul><li>A abordagem ER permite que sejam definidos relacionamentos de grau maior que dois. </li></ul><ul><li>O exemplo abaixo mostra um relacionamento ternário. </li></ul>PROFESSOR DISCIPLINA ALUNO N N 1 Descrição: próxima página...
  39. 39. Relacionamento Ternário <ul><li>No caso de relacionamento ternário, a cardinalidade refere-se a pares de entidades . </li></ul><ul><ul><ul><li>Separar a entidade ALUNO e analisar o par PROFESSOR / DISCIPLINA . Para cada par PROFESSOR / DISCIPLINA podemos ter de 1 até N alunos relacionados; </li></ul></ul></ul><ul><ul><ul><li>Separar a entidade PROFESSOR e analisar o par ALUNO / DISCIPLINA . Para cada par ALUNO / DISCIPLINA podemos ter 1 e somente 1 PROFESSOR relacionado; </li></ul></ul></ul><ul><ul><ul><li>Separar a entidade DISCIPLINA e analisar o par PROFESSOR / ALUNO . Para cada par PROFESSOR / ALUNO podemos ter de 1 até N DISCIPLINAS relacionadas. </li></ul></ul></ul>
  40. 40. Modelos equivalentes MÉDICO PACIENTE CONSULTA N N MÉDICO PACIENTE CONSULTA N N 1 1
  41. 41. Variantes da abordagem ER <ul><li>Atualmente observa-se uma variedade de representações gráficas que levam o título de ER. </li></ul><ul><li>A notação mais utilizada é a do tipo “Chen” pois, com algumas extensões segue a notação proposta por Peter Chen em seu primeiro artigo. </li></ul><ul><li>Além desta notação duas famílias de notações têm importância: </li></ul><ul><ul><li>Engenharia da Informação (diagramação “pé-de-linha”) </li></ul></ul><ul><ul><li>IDEF1X (Integration DEFinition for Information Modeling). </li></ul></ul>
  42. 42. Notação Engenharia da Informação DEPTO EMPREGADO LOTAÇÃO (1,1) (0,N) DEPTO EMPREGADO Tem lotado Está lotado em
  43. 43. Notação IDEF1X DEPTO EMPREGADO LOTAÇÃO 1 N Cod_cli CLIENTE Nome End Codigo RAMO_ATIV. Descrição

×