Projetar Base de Dados

1. Projetar Base de Dados

2. decisões do arquiteto <<subsystem>> Analisar Serviços Projetar Serviços Arquiteto de Software Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Check List  bla bla  bla  blabla Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados

3. Objetivos desta atividade • Apresentar uma visão geral sobre tipos mais usados de banco de dados • Discutir orientações para o mapeamento objeto-relacional • Discutir formas de acesso aos dados armazenados • Aplicável tanto ao RUP como a SOA

4. Visão geral • Sistemas de banco de dados (SGBD) relacionais são a forma de armazenamento de dados mais utilizadas atualmente • Padrão estabelecido no mercado • Ferramentas de suporte (backup/replicação) • Velocidade no acesso aos dados

5. Visão geral • A mudança de paradigma de programação para a orientação a objetos gerou um série de tentativas para migração do paradigma de armazenamento de dados • Banco de dados orientado a objetos (BDOO) • Mais próximo das linguagens de programação • Banco de dados objeto-relacional (BDOR) • Extensão do modelo relacional com suporte OO

6. Banco de dados orientado a objetos • Mapeamento direto de objetos para persistência • Suporte a tipos de dados complexos • Especialização / Generalização • Tipos complexos • Comportamento de objetos • Problemas: • Falta de padronização e base formal • Tentativa de padronização: ODMG • Grande esforço tecnológico e financeiro para migração • Velocidade na recuperação da informação • Ferramentas de apoio • Backup/Replicação

7. Banco de dados objeto relacional • Pode ser visto como uma camada de abstração construída sobre a tecnologia relacional • Mantém as vantagens do modelo relacional e acrescentam características do modelo OO • Modelo eficiente (Relacional) • Modelo rico (OO) • O padrão SQL:1999 (ou SQL3) incorpora as abstrações necessárias para suporte ao modelo de dados OR

8. Classificação dos SGBDs Com Linguagem Declarativa Consultas Sem Linguagem Declarativa Dados Simples Complexos

9. Classificação dos SGBDs • Dados são registros de tamanho fixo; • - Poucas consultas pré-definidas, em geral buscas por igualdade de campos dos registros. Com Linguagem Declarativa Consultas Sem Linguagem Declarativa Dados Simples Complexos

10. Classificação dos SGBDs • Dados são linhas de tabelas cujos atributos possuem domínios simples • Flexibilidade de consultas com SQL Com Linguagem Declarativa Consultas Sem Linguagem Declarativa Dados Simples Complexos

11. Classificação dos SGBDs • Dados são objetos com estruturas complexas • Capacidade de consulta limitada, baseada em navegabilidade por objetos Com Linguagem Declarativa Consultas Sem Linguagem Declarativa Dados Simples Complexos

12. Classificação dos SGBDs • Dados são tabelas com estruturas complexas • Uso do padrão SQL estendido (SQL3) para garantir flexibilidade nas consultas Com Linguagem Declarativa Consultas Sem Linguagem Declarativa Dados Simples Complexos

13. Classificação dos SGBDs Com Linguagem Declarativa Consultas Sem Linguagem Declarativa Dados Simples Complexos

14. Tendência • As maiores empresas de desenvolvimento de SGBD’s estão investindo no SGBD Objeto-Relacional (OR) • Oracle • IBM/DB2 • PostgreSQL • Versões atuais de suas ferramentas já suportam mecanismos OR • Problemas • Devido a maior gama de tipos e estruturas de dados a performance não é a mesma de um SGBDR • Ainda não existem muitas ferramentas que suportem os modelos de dados OR

15. Tendência • O uso do modelo de dados Objeto-Relacional ainda está se difundindo • O modelo relacional ainda é o dominante no mercado

16. Considerações • Vamos assumir um SGBD relacional como meio de armazenamento • Passos para outros meios de armazenamento não estão contemplados • Sugestões para aumentar desempenho devem ser discutidas com o projetista responsável (geralmente um DBA)

17. Considerações • O diagrama de classes está no mesmo nível de abstração do esquema lógico de banco de dados, porém utilizando outro paradigma • O processo apresentado se baseia em uma série de passos a serem executados para efetuar a migração entre os paradigmas OO e relacional • Questionamentos sobre o modelo de classes (particularmente os relacionamentos) podem surgir e devem ser discutidos com os analistas

18. Requisitos Não Funcionais Modelo de Análise e Projeto Projeto de Banco de Dados Visão geral dos artefatos Projetista de Banco de Dados Projetar Base de Dados

19. Passos para Projetar base de dados • Mapear classes persistentes • Mapear relacionamentos das classes persistentes • Identificar índices • Definir restrições de integridade • Definir características de armazenamento • Criar estruturas de armazenamento • Definir forma de acesso aos dados

20. Passo 1. Mapear classes persistentes • Mapear classes em tabelas • Em geral, não é um mapemanto 1:1 • Mapear atributos em colunas • Tipos primitivos usados no diagrama de classes geralmente tem seu correspondente no BD • Identificar chaves

21. Mapear atributos em colunas • Regra geral - mapear diretamente • cada atributo transforma-se em uma coluna • Atributos complexos - como mapear?

22. Mapear atributos em colunas • Mapeamento de atributos complexos

23. Mapear atributos em colunas • Considerar também os valores máximos e mínimos para cada atributo • O atributo pode ser chave? • Preferencialmente, um único atributo para chave • Chaves devem ser estáveis! • Colunas com valores seqüenciais gerados automaticamente

24. Mapear classes em tabelas • Analisar as classes persistentes • O mapeamento dificilmente será direto • hierarquias de classes

25. Pessoa nome endereco telefone Funcionario Fornecedor salario produto dataInicio horasTrabalhadas Mapear classes em tabelas • Como mapear?

26. Mapear classes em tabelas • Estratégias de mapeamento • uma única tabela para todas as classes da hierarquia • uma tabela para cada classe da hierarquia • uma tabela para cada classe concreta da hierarquia • Devem ser levados em consideração • Espaço em disco • Facilidade no acesso aos dados • Velocidade no acesso aos dados

27. Pessoa nome endereco telefone Funcionario Fornecedor salario produto dataInicio horasTrabalhadas Pessoa Funcionario Pessoa Fornecedor pessoaID (PK) pessoaID (PK) pessoaID (PK) pessoaID (PK) nome nome nome nome endereco endereco endereco telefone endereco telefone telefone telefone produto salario produto Fornecedor Funcionario salario dataInicio pessoaID (PK,FK) pessoaID (PK,FK) dataInicio produto salario tipoDoObjeto dataInicio Mapear classes em tabelas Diagrama de classes Uma tabela para cada classe da hierarquia Uma única tabela para todas as classes da hierarquia Uma tabela para cada classe concreta da hierarquia

28. Passo 2. Mapear relacionamentos das classes persistentes • Relacionamentos 1 para 1 • Relacionamentos 1 para muitos • Relacionamentos muitos para muitos

29. Relacionamentos 1 para 1 • Como mapear?

30. Relacionamentos 1 para 1 • Chaves estrangeiras - FK (foreign key) • se as classes tiverem relacionamentos com outras classes • Fusão das tabelas • se uma das classes for não persistente • A decisão é caso-a-caso

31. Funcionario CartaoPonto pessoaID (PK) cartaoPontoID (PK) salario horasTrabalhadas dataInicio pessoaID (FK) Funcionario CartaoPonto salario horasTrabalhadas dataInicio 1 1 0..1 0..1 Funcionario pessoaID (PK) salario dataInicio horasTrabalhadas Relacionamentos 1 para 1 Mapeamento usando chaves estrangeiras Mapeamento usando fusão de tabelas

32. Relacionamentos um para muitos • Como mapear?

33. Relacionamentos um para muitos • Mapeados através de chaves estrangeiras • A chave estrangeira é inserida na tabela com multiplicidade * do relacionamento Funcionario Atividade pessoaID (PK) atividadeID (PK) salario nome dataInicio pessoaID (FK)

34. Cliente Conta clienteID (PK) contaID (PK) nome Cliente numero Conta telefone saldo nome enderecoResidencial numero telefone saldo 1..* 1..* 1..* 1..* enderecoResidencial : Endereco ClienteConta clienteID (FK) contaID (FK) Relacionamentos muitos para muitos • Precisam de uma tabela extra para representar a associação

35. Passo 3. Identificar índices • Otimização de consultas • Custo extra na inclusão, remoção e atualização de dados • Não aconselhável em tabelas pequenas

36. Que colunas indexar? • Chaves primárias são sempre indexadas • Consultas x operações de manutenção (inclusão/atualização/remoção de dados) • Analisar descrições dos casos de uso e requisitos não funcionais • freqüência das operações • requisitos de desempenho

37. Passo 4. Definir restrições de integridade • Definir restrições sobre as informações que serão armazenadas. • Definir se serão utilizados ou não os recursos do SGBD para implementação das restrições • restrições de integridade para chaves primárias e estrangeiras (usualmente criadas automaticamente) • restrições relacionadas a regras de negócio não são implementadas pelo banco automaticamente • Implementação no banco ou na aplicação (por exemplo, na fachada)? • Determinar como essas restrições serão implementadas (triggers, procedures, etc.)

38. Passo 5. Definir características de armazenamento • Definição de requisitos de espaço e organização física para o banco de dados • Densidade das informações nas páginas de disco • Localização das páginas de disco através de drivers de disco • Espaço em disco alocado para as estruturas de dados

39. Passo 6. Criar estruturas de armazenamento • Normalmente é feito por um DBA • Usar ferramenta como apoio • Envolve: • criar a base de dados, tabelas, colunas, etc. • definir índices para chaves primárias • popular tabelas de referência (ex.: estados do brasil) • ...

40. Passo 7. Definir forma de acesso aos dados • Existem 2 formas básicas para a aplicação ter acesso aos dados que estão no banco de dados • Acesso via o driver do banco de dados (JDBC) • Utilização de um framework ORM (Object Relational Mapper) para acesso a dados • As duas abordagens não invalidam a estrutura da camada de persistência modelada até agora para a aplicação • Hoje a maioria das aplicações utiliza um framework ORM para acesso aos dados

41. Acesso via o driver do banco de dados • O acesso via o driver do banco de dados exige que o desenvolvedor escreva as consultas diretamente em linguagem SQL • O código em SQL fica dentro do código da aplicação • Essa abordagem de acesso aos dados exige um re-trabalho maior se for necessária a mudança do SGBD escolhido • Todas as consultas devem ser revisadas, pois mesmo havendo um padrão, os desenvolvedores dos SGBD adicionam funções ou construções não compatíveis entre os SGBD

42. Utilizando um framework ORM • Os desenvolvedores se preocupam apenas em entender o funcionamento do framework • Todo o acesso aos dados é gerenciado pelo framework escolhido • Gerenciamento de conexão com o BD • Todas as configurações de acesso aos dados são feitas no framework • Maior controle sobre como os dados são acessados

43. Alguns exemplos de Frameworks ORM • Varia de acordo com a linguagem de programação

44. Observações • Utilizar um framework ORM é interessante para evitar muitos esforços na hora de mudar o SGBD escolhido • Deve-se levar em consideração o tempo que será gasto para a equipe aprender a usar um ORM