1 Aula 02 Projeto de BD Prof. Juliano. 2 Projeto do Banco de Dados 1.caracterizar todos os dados necessários na perspectiva do usuário Resultado: especificação.

Apresentação em tema: "1 Aula 02 Projeto de BD Prof. Juliano. 2 Projeto do Banco de Dados 1.caracterizar todos os dados necessários na perspectiva do usuário Resultado: especificação."— Transcrição da apresentação:

1 1 Aula 02 Projeto de BD Prof. Juliano

2 2 Projeto do Banco de Dados 1.caracterizar todos os dados necessários na perspectiva do usuário Resultado: especificação das necessidades do usuário (análise de requisitos) 2. transcrever as necessidades especificadas em esquema conceitual de BD. Resultado: projeto- conceitual 3. transporte do modelo de dados abstrato para sua implementação: projeto lógico:o esquema conceitual de alto nível mapeado para modelo de implementação de dados do SGBD que será usadoprojeto lógico:o esquema conceitual de alto nível mapeado para modelo de implementação de dados do SGBD que será usado projeto físico: dependente dos recursos do SGBD, cuida das formas de organização de arquivos e estruturas internas de armazenamento.projeto físico: dependente dos recursos do SGBD, cuida das formas de organização de arquivos e estruturas internas de armazenamento.

3 3 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

4 4 Análise de requisitos 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. 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. 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. 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.

5 5 Problemas em potencial que nos ajudam a compreender por que a análise de requisitos é difícil: Problemas em potencial que nos ajudam a compreender por que a análise de requisitos é difícil: Problemas de escopo  o limite do sistema é mal definido ou o cliente especifica detalhes desnecessários. Problemas de escopo  o limite do sistema é mal definido ou o cliente especifica detalhes desnecessários. 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”. 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”. Problemas de volatilidade  os requisitos mudam ao longo do tempo. Problemas de volatilidade  os requisitos mudam ao longo do tempo. Análise de requisitos

6 6 Para ajudar a contornar esses problemas, os engenheiros (analistas) de sistemas devem abordar a atividade de análise de requisitos de um modo organizado. Para ajudar a contornar esses problemas, os engenheiros (analistas) de sistemas devem abordar a atividade de análise de requisitos de um modo organizado. Sommerville e Sawyer (1997) sugerem os seguintes passos: Sommerville e Sawyer (1997) sugerem os seguintes passos: Avalie a viabilidade técnica e de negócios do sistema proposto; Avalie a viabilidade técnica e de negócios do sistema proposto; Identifique as pessoas que vão ajudar a especificar os requisitos; Identifique as pessoas que vão ajudar a especificar os requisitos; Defina o ambiente técnico no qual o sistema vai ser colocado; Defina o ambiente técnico no qual o sistema vai ser colocado; Defina um ou mais métodos para o levantamento dos requisitos (entrevistas, reuniões de equipe, etc) Defina um ou mais métodos para o levantamento dos requisitos (entrevistas, reuniões de equipe, etc) Análise de requisitos

7 7 Parte III Projeto Conceitual (Modelagem de Dados)

8 8 Projeto Conceitual Pode ser considerada a fase de análise dos dados (ou requisitos) capturados na etapa anterior. Pode ser considerada a fase de análise dos dados (ou requisitos) capturados na etapa anterior. 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. 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. A ferramenta mais empregada nesta etapa é o Diagrama Entidade-Relacionamento (DER) A ferramenta mais empregada nesta etapa é o Diagrama Entidade-Relacionamento (DER)

9 9 Os elementos da análise estruturada (revisão) DERDFD 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.

10 10 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

11 11 Exemplo - DER

12 12 DER – Diagrama Entidade-Relacionamento O Diagrama Entidade-Relacionamento (DER) ou Modelo Entidade-Relacionamento (MER) foi definido por Peter Chen em 1976. O Diagrama Entidade-Relacionamento (DER) ou Modelo Entidade-Relacionamento (MER) foi definido por Peter Chen em 1976. Peter Chen formulou a proposta do modelo E-R, baseou-se na compreensão da realidade em que se situava o problema. Peter Chen formulou a proposta do modelo E-R, baseou-se na compreensão da realidade em que se situava o problema. “Como iremos projetar um sistema se não entendemos o negócio para o qual será realizado? “ “Como iremos projetar um sistema se não entendemos o negócio para o qual será realizado? “

13 13 Dez anos depois que Peter Chen inventou o DER, a modelagem estava se tornando amplamente utilizada; no entanto, surgiram muitas formas concorrentes, tais como: Dez anos depois que Peter Chen inventou o DER, a modelagem estava se tornando amplamente utilizada; no entanto, surgiram muitas formas concorrentes, tais como: MER estendido, proposto por Teorey (1986);MER estendido, proposto por Teorey (1986); Os europeus focaram-se no NIAM (Naturallanguage Information Analysis Method;Os europeus focaram-se no NIAM (Naturallanguage Information Analysis Method; 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).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). DER – Diagrama Entidade-Relacionamento

14 14 Um DER é uma representação gráfica, na forma de um diagrama, onde são utilizados inicialmente apenas 3 conceitos: Um DER é uma representação gráfica, na forma de um diagrama, onde são utilizados inicialmente apenas 3 conceitos: Entidade Entidade Atributo Atributo Relacionamento Relacionamento DER – Diagrama Entidade-Relacionamento

15 15 Entidade 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. 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. A entidade pode ser concreta (pessoa, livro), ou pode ser abstrata (empréstimo, viajem de férias ou um conceito). A entidade pode ser concreta (pessoa, livro), ou pode ser abstrata (empréstimo, viajem de férias ou um conceito). Conjunto de entidades é um conjunto de entidades de mesmo tipo que compartilham as mesmas propriedades: os atributos. Conjunto de entidades é um conjunto de entidades de mesmo tipo que compartilham as mesmas propriedades: os atributos.

16 16 Atributos Atributos = propriedades descritivas de cada ocorrência de uma entidade ou relacionamento. Atributos = propriedades descritivas de cada ocorrência de uma entidade ou relacionamento. Cada atributo possui um domínio (conjunto de valores possíveis). Cada atributo possui um domínio (conjunto de valores possíveis). Atributos possíveis ao conjunto de entidades clientes:,,. Atributos possíveis ao conjunto de entidades clientes: nome_cliente, cnpj, end_cliente.

17 17 Atributos Um atributo pode ser caracterizado pelos seguintes tipos: Um atributo pode ser caracterizado pelos seguintes tipos: simples ou compostossimples ou compostos monovalorados ou multivaloradosmonovalorados ou multivalorados nulosnulos Descrição: próxima página...

18 18 Atributos simples ou compostos   Atributo simples: não é dividido em partes.   Atributo composto pode ser dividido em partes (isto é, outros atributos). Ex: nome_cliente pode ser estruturado em: prenome, nome-intermediário e sobrenome.

19 19 Atributos mono ou multivalorados O atributo num_emprestimo de uma entidade específica refere-se apenas a um número de empréstimo. O atributo número do telefone pode assumir mais de um valor, como os números de telefone de uma empresa.

20 20 Atributo nulo Usado quando uma entidade não possui valor para determinado atributo. 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”. Nulo também pode significar que o valor do atributo é desconhecido.

21 21 Representação gráfica CLIENTE Principais convenções: Nome da entidade singular e único. Nome da entidade em maiúsculo. Nomes dos atributos em minúsculo. Cada Entidade deve ser identificada unicamente. Um atributo ou conjunto de atributos que identificam a unicidade da ocorrência em uma Entidade é chamado de Identificador Único (UID).

22 22 Representação gráfica CLIENTE Cod_cli Nome End Cod_cli CLIENTE Nome End Uma entidade CHEN Uma entidade IDEF1X Método:

23 23 Relacionamentos Representam associações entre entidades. Representam associações entre entidades. Em um DER, um relacionamento é representado através de um losango, ligado por linhas aos retângulos representativos das entidades. Em um DER, um relacionamento é representado através de um losango, ligado por linhas aos retângulos representativos das entidades. Um relacionamento pode ter atributos. Um relacionamento pode ter atributos. Exemplo de relacionamento.Exemplo de relacionamento.Exemplo de relacionamentoExemplo de relacionamento 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. 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. Exemplo de auto-relacionamento.Exemplo de auto-relacionamento.Exemplo de auto-relacionamentoExemplo de auto-relacionamento

24 24 Exemplos ENGENHEIROPROJETO Atuação Exemplo: Relacionamento

25 25 Exemplos Exemplo: Auto-relacionamento PESSOA Casamento marido esposa

26 26 Cardinalidade de relacionamentos 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. 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. Há duas cardinalidades a considerar: a cardinalidade máxima e a cardinalidade mínima. Há duas cardinalidades a considerar: a cardinalidade máxima e a cardinalidade mínima. Classificação de relacionamentos binários: Classificação de relacionamentos binários: 1:1 (um-para-um)1:1 (um-para-um) 1:n (um-para-muitos)1:n (um-para-muitos) n:n (muitos-para-muitos)n:n (muitos-para-muitos)

27 27 Relacionamento 1:1 Neste grau de relacionamento, cada elemento de uma entidade relaciona-se com um e somente um elemento de outra entidade. Neste grau de relacionamento, cada elemento de uma entidade relaciona-se com um e somente um elemento de outra entidade. 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. 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. HOMEM MULHER CASADO 1 1 HOMEM MULHER CASADO 1 1 Resultado idêntico: 1:1

28 28 Relacionamento 1:n 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. 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. 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. 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. EMPREGADO DEPTO LOTAÇÃO N1

29 29 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 (). 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). Relacionamento n:n ENGENHEIROPROJETO ALOCAÇÃO NN MÉDICO PACIENTE CONSULTA NN

30 30 Cardinalidade de atributos Um atributo pode assumir uma cardinalidade, de maneira análoga a uma entidade em um relacionamento. Um atributo pode assumir uma cardinalidade, de maneira análoga a uma entidade em um relacionamento. A cardinalidade de um atributo define quantos valores deste atributo podem estar associados a uma ocorrência da entidade / relacionamento a qual ele pertence. A cardinalidade de um atributo define quantos valores deste atributo podem estar associados a uma ocorrência da entidade / relacionamento a qual ele pertence. No caso da cardinalidade ser (1,1) ela pode ser omitida do diagrama. No caso da cardinalidade ser (1,1) ela pode ser omitida do diagrama.

31 31 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). 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). Já o atributo telefone, é um atributo opcional (cardinalidade mínima 0) e multivalorado (cardinalidade máxima n). Já o atributo telefone, é um atributo opcional (cardinalidade mínima 0) e multivalorado (cardinalidade máxima n). Cardinalidade de atributos CLIENTE Cod_cli Telefone (0,n) Nome

32 32 Atributos de relacionamento Assim como entidades, relacionamentos também podem possuir atributos. Assim como entidades, relacionamentos também podem possuir atributos. 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. 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. Um engenheiro pode atuar em diversos projetos, exercendo diferentes funções.Um engenheiro pode atuar em diversos projetos, exercendo diferentes funções. Em um projeto, podem atuar diversos engenheiros com funções diferentes.Em um projeto, podem atuar diversos engenheiros com funções diferentes. ENGENHEIROPROJETO ATUAÇÃO NN Função

33 33 Entidade Fraca Em geral, uma entidade possui um único atributo como identificador. Em geral, uma entidade possui um único atributo como identificador. Em alguns casos, o identificador de uma entidade é composto por diversos atributos. Em alguns casos, o identificador de uma entidade é composto por diversos atributos. PESSOA Codigo Nome Endereço PRATELEIRA Num_corredor Num_prateleira Capacidade

34 34 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. 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. Entidade Fraca EMPREGADO DEPENDENTE Resp. (1,1)(0,n) Cód_empnomeNum_seq. nome Id = cod_emp + num_seq.

35 35 Entidade Fraca 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. 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.

36 36 Especialização / Generalização O conceito de especialização permite atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica. O conceito de especialização permite atribuir propriedades particulares a um subconjunto das ocorrências (especializadas) de uma entidade genérica. No DER, o símbolo para representar especialização é um triângulo. No DER, o símbolo para representar especialização é um triângulo. 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. 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. 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. 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.

37 37 Especialização / Generalização FILIAL CLIENTE Fil-Cli (1,1)(0,n) PESSOA FÍSICA PESSOA JURÍDICA código nome cpfcnpj

38 38 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. 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. Especialização / Generalização CLIENTE PESSOA FÍSICA PESSOA JURÍDICA t EMPREGADO MOTORISTASECRETÁRIA p Indica que cliente é PF ou PJ Indica que nem todo EMP é motorista ou secretária

39 39 Relacionamento Ternário Todos os exemplos até aqui mostrados são de relacionamentos binários. Todos os exemplos até aqui mostrados são de relacionamentos binários. A abordagem ER permite que sejam definidos relacionamentos de grau maior que dois. A abordagem ER permite que sejam definidos relacionamentos de grau maior que dois. O exemplo abaixo mostra um relacionamento ternário. O exemplo abaixo mostra um relacionamento ternário. PROFESSOR DISCIPLINAALUNO NN 1 Descrição: próxima página...

40 40 Relacionamento Ternário No caso de relacionamento ternário, a cardinalidade refere-se a pares de entidades. No caso de relacionamento ternário, a cardinalidade refere-se a pares de entidades. Separar a entidade ALUNO e analisar o par PROFESSOR / DISCIPLINA. Para cada par PROFESSOR / DISCIPLINA podemos ter de 1 até N alunos relacionados; Separar a entidade ALUNO e analisar o par PROFESSOR / DISCIPLINA. Para cada par PROFESSOR / DISCIPLINA podemos ter de 1 até N alunos relacionados; Separar a entidade PROFESSOR e analisar o par ALUNO / DISCIPLINA. Para cada par ALUNO / DISCIPLINA podemos ter 1 e somente 1 PROFESSOR relacionado; Separar a entidade PROFESSOR e analisar o par ALUNO / DISCIPLINA. Para cada par ALUNO / DISCIPLINA podemos ter 1 e somente 1 PROFESSOR relacionado; Separar a entidade DISCIPLINA e analisar o par PROFESSOR / ALUNO. Para cada par PROFESSOR / ALUNO podemos ter de 1 até N DISCIPLINAS relacionadas. Separar a entidade DISCIPLINA e analisar o par PROFESSOR / ALUNO. Para cada par PROFESSOR / ALUNO podemos ter de 1 até N DISCIPLINAS relacionadas.

41 41 Modelos equivalentes MÉDICO PACIENTE CONSULTA NN MÉDICO PACIENTE CONSULTA N N 1 1

42 42 Variantes da abordagem ER Atualmente observa-se uma variedade de representações gráficas que levam o título de ER. Atualmente observa-se uma variedade de representações gráficas que levam o título de ER. 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. 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. Além desta notação duas famílias de notações têm importância: Além desta notação duas famílias de notações têm importância: Engenharia da Informação (diagramação “pé-de-linha”)Engenharia da Informação (diagramação “pé-de-linha”) IDEF1X (Integration DEFinition for Information Modeling).IDEF1X (Integration DEFinition for Information Modeling).

43 43 Notação Engenharia da Informação DEPTO EMPREGADO LOTAÇÃO (1,1)(0,N) DEPTO EMPREGADO Tem lotado Está lotado em

44 44 Notação IDEF1X DEPTO EMPREGADO LOTAÇÃO 1N Cod_cli CLIENTE Nome End Codigo RAMO_ATIV. Descrição