O documento descreve as etapas para projeto de banco de dados, incluindo análise de requisitos, projeto conceitual, lógico e físico. A análise de requisitos envolve caracterizar os dados necessários e especificar as necessidades dos usuários. O projeto conceitual modela os dados através de um diagrama entidade-relacionamento. Os projetos lógico e físico implementam o modelo conceitual em um sistema de gerenciamento de banco de dados.

1. 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á usado projeto físico : dependente dos recursos do SGBD, cuida das formas de organização de arquivos e estruturas internas de armazenamento.

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

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

5. 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: Avalie a viabilidade técnica e de negócios do sistema proposto; Identifique as pessoas que vão ajudar a especificar os requisitos; 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) Análise de requisitos

6. Parte III Projeto Conceitual (Modelagem de Dados)

7. Projeto Conceitual 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. A ferramenta mais empregada nesta etapa é o Diagrama Entidade-Relacionamento (DER)

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. 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. Exemplo - DER

11. DER – Diagrama Entidade-Relacionamento 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. “ Como iremos projetar um sistema se não entendemos o negócio para o qual será realizado? “

12. 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); 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). DER – Diagrama Entidade-Relacionamento

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

14. 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. 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.

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

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

17. 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 .

18. 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.

19. 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.

20. 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).

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

22. Relacionamentos 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. Um relacionamento pode ter atributos. Exemplo 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. Exemplo de auto-relacionamento .

23. Exemplos ENGENHEIRO PROJETO Atuação Exemplo : Relacionamento

24. Exemplos Exemplo : Auto-relacionamento PESSOA Casamento marido esposa

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

26. Relacionamento 1:1 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. HOMEM MULHER CASADO 1 1 HOMEM MULHER CASADO 1 1 Resultado idêntico: 1:1

27. 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. 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 N 1

28. 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 ENGENHEIRO PROJETO ALOCAÇÃO N N MÉDICO PACIENTE CONSULTA N N

29. Cardinalidade de atributos 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. No caso da cardinalidade ser (1,1) ela pode ser omitida do diagrama.

30. 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). Cardinalidade de atributos CLIENTE Cod_cli Telefone (0,n) Nome

31. Atributos de relacionamento 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. Um engenheiro pode atuar em diversos projetos, exercendo diferentes funções. Em um projeto, podem atuar diversos engenheiros com funções diferentes. ENGENHEIRO PROJETO ATUAÇÃO N N Função

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

33. 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_emp nome Num_seq. nome Id = cod_emp + num_seq.

34. 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.

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

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. 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 MOTORISTA SECRETÁRIA p Indica que cliente é PF ou PJ Indica que nem todo EMP é motorista ou secretária

38. Relacionamento Ternário 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. O exemplo abaixo mostra um relacionamento ternário. PROFESSOR DISCIPLINA ALUNO N N 1 Descrição: próxima página...

39. Relacionamento Ternário 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 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.

40. Modelos equivalentes MÉDICO PACIENTE CONSULTA N N MÉDICO PACIENTE CONSULTA N N 1 1

41. Variantes da abordagem 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. Além desta notação duas famílias de notações têm importância: Engenharia da Informação (diagramação “pé-de-linha”) IDEF1X (Integration DEFinition for Information Modeling).

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

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