Abr-17 Projetar Base de Dados Projetar base de dados.

Apresentação em tema: "Abr-17 Projetar Base de Dados Projetar base de dados."— Transcrição da apresentação:

1 abr-17 Projetar Base de Dados Projetar base de dados

2 Fluxo de análise e projeto
abr-17 Analisar Serviços Arquiteto de Software Projetar Serviços 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 decisões do arquiteto <<subsystem>> Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados Fluxo de análise e projeto

3 Objetivos desta atividade
abr-17 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 Projetar base de dados

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 BD Relacionais BDOR Sistemas de arquivos BDOO 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 BD Relacionais BDOR Sistemas de arquivos BDOO 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 Classificação dos SGBDs Com Linguagem Declarativa BD Relacionais BDOR Sistemas de arquivos BDOO 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 BD Relacionais BDOR Sistemas de arquivos BDOO 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 Classificação dos SGBDs Com Linguagem Declarativa BD Relacionais BDOR Sistemas de arquivos BDOO Consultas Sem Linguagem Declarativa Dados Simples Complexos

13 Classificação dos SGBDs
Com Linguagem Declarativa BD Relacionais BDOR Sistemas de arquivos BDOO 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 abr-17 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) Os passos a seguir assumem que o meio de armazenamento é um banco de dados relacional ou objeto-relacional. Os passos para armazenamento em bancos orientados a objetos seriam os mesmos, porém, com descrições diferentes. Todavia, o armazenamento em meios que não envolvem bancos de dados (como sistemas de arquivos, por exemplo) não está contemplado nesta atividade. O aparecimento de críticas ao modelo de análise e projeto (em particular ao modo como certas classes ou relacionamentos foram modelados) é normal, uma vez que esta atividade trata do acesso físico aos dados, analisando a otimização de consultas e operações (aspectos que não são considerados inteiramente pelo desenvolvedor). Se você identificar falhas nos diagramas de classes ou tiver sugestões para melhorá-los, discuta o assunto com o desenvolvedor, de modo a encontrar a melhor solução para o projeto das classes. Durante esta atividade, você deve ter sempre em mente o modelo de dados corporativo da instituição, de modo a reutilizá-lo sempre que possível. Projetar base de dados

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 Visão geral dos artefatos
abr-17 Visão geral dos artefatos Modelo de Análise e Projeto Requisitos Não Funcionais Projetista de Banco de Dados Projetar Base de Dados Projeto de Banco de Dados Projetar base de dados

19 Passos para Projetar base de dados
abr-17 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 Projetar base de dados

20 Passo 1. Mapear classes persistentes
abr-17 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 Para que as classes persistentes possam ser armazenadas, elas precisam ser mapeadas em tabelas do banco de dados. Porém, como classes e tabelas são estruturas diferentes, nem sempre o mapeamento é direto (com cada classe correspondendo a uma tabela e cada atributo a uma coluna). Projetar base de dados

21 Mapear atributos em colunas
abr-17 Mapear atributos em colunas Regra geral - mapear diretamente cada atributo transforma-se em uma coluna Atributos complexos - como mapear? Via de regra, todos os atributos persistentes de uma classe são mapeados diretamente em colunas do banco de dados. Porém, atributos compostos (que representam outros objetos) terão que ser mapeados em mais de uma coluna. Por exemplo, considere as classes Cliente e Endereco mostradas acima. Projetar base de dados

22 Mapear atributos em colunas
abr-17 Mapear atributos em colunas Mapeamento de atributos complexos A classe Endereco não é persistente por si só, mas a classe Cliente é, portanto, é necessário armazenar todos os seus atributos, inclusive enderecoResidencial. Assim, adota-se o mapeamento ilustrado acima, onde os atributos nome e telefone são mapeados diretamente em duas colunas da tabela Cliente, enquanto endereçoResidencial é mapeado em várias colunas diferentes (logradouro, numero, cidade, estado, país e CEP). Projetar base de dados

23 Mapear atributos em colunas
abr-17 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 Ao mapear os atributos em colunas considere também quais devem ser os valores máximos e mínimos para cada atributo. Além disso, analise se o atributo pode ser a chave primária (PK) de sua tabela. No exemplo acima, se o cliente possuísse um atributo cpf, este seria o candidato natural à chave primária da tabela. Se for necessário mais de um atributo para identificar uma tupla isto poderá ser feito usando-se chave semântica (chave composta) ou criando uma outra coluna com valor sequencial para chave (vários bancos podem gerenciar esses valores automaticamente). A decisão de usar um ou outro deverá ser analisada caso a caso, pois depende da estabilidade dos atributos candidatos à formação da chave semântica. Na tabela Cliente, por exemplo, foi criada a coluna clienteID para chave primária, uma vez que os demais atributos não identificam unicamente um cliente. Atributos com valores únicos são sérios candidatos a chave, porém, se houver alguma chance de mudanças em seus significados ou mesmo no tipo de dados usado para representá-los, você não deve adotá-los como chave, pois mudanças em uma chave geralmente implicam em um grande trabalho para reorganizar a base e a aplicação. Projetar base de dados

24 Mapear classes em tabelas
abr-17 Mapear classes em tabelas Analisar as classes persistentes O mapeamento dificilmente será direto hierarquias de classes Quando uma classe persistente não está relacionada com outras classes, o mapeamento é simples e direto: a classe corresponde a uma tabela do banco de dados. Porém, este geralmente não é o caso. Para classes envolvidas em hierarquias de herança, por exemplo, você precisa adotar uma das três estratégias listadas a seguir para realizar o mapeamento. Projetar base de dados

25 Mapear classes em tabelas
abr-17 Mapear classes em tabelas Como mapear? Pessoa nome endereco telefone Fornecedor produto Funcionario salario dataInicio horasTrabalhadas Projetar base de dados

26 Mapear classes em tabelas
abr-17 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 Usar uma única tabela para representar todas as classes da hierarquia. Todas as classes de uma determinada hierarquia são mapeadas para uma mesma tabela que, consequentemente, contém todos os atributos da hierarquia. Esta solução é a mais simples de implementar, pois facilita o acesso aos dados. Porém, quando a incidência de valores nulos é alta, implica em um grande desperdício de espaço na base de dados. Usar uma tabela para cada classe da hierarquia. Cada classe da hierarquia é mapeada para uma tabela diferente, contendo apenas os atributos da respectiva classe. As tabelas que representam subclasses contém colunas com referências (chaves-estrangeiras) para as respectivas superclasses, de maneira a poder acessar os atributos em comum. Esta solução é a mais natural, uma vez que suporta muito bem a adição e modificação de subclasses, além de otimizar o uso do espaço na base de dados. Entretanto, o acesso aos dados é mais difícil e o tempo para leitura e atualização é maior, uma vez que é preciso acessar mais de uma tabela para obter os dados de um determinado objeto. Usar uma tabela para cada classe concreta da hierarquia. Esta é uma solução intermediária entre as duas primeiras. Aqui, cada classe concreta da hierarquia é mapeada para uma tabela diferente, contendo seus próprios atributos e os atributos de suas superclasses abstratas. Não há desperdício de espaço e o acesso aos dados é simples e rápido, já que normalmente todos os atributos relacionados a uma determinada classe estarão em uma mesma tabela. Todavia, se for preciso modificar uma classe abstrata, as tabelas de todas as suas subclasses terão que ser modificadas também. Projetar base de dados

27 Mapear classes em tabelas
abr-17 Mapear classes em tabelas Pessoa nome endereco telefone Fornecedor produto Funcionario salario dataInicio horasTrabalhadas Diagrama de classes Uma única tabela para todas as classes da hierarquia Uma tabela para cada classe da hierarquia Uma tabela para cada classe concreta da hierarquia A figura acima ilustra como seria o mapeamento da hierarquia Pessoa-Fornecedor-Funcionário usando cada uma das alternativas apresentadas anteriormente. As colunas escolhidas para chave primária estão indicadas com PK; as chaves estrangeiras estão indicadas com FK (foreign key). Pessoa pessoaID (PK) nome endereco telefone produto salario dataInicio tipoDoObjeto Funcionario pessoaID (PK,FK) salario dataInicio Pessoa pessoaID (PK) nome endereco telefone Fornecedor produto Fornecedor pessoaID (PK) nome endereco telefone produto Funcionario salario dataInicio Projetar base de dados

28 Passo 2. Mapear relacionamentos das classes persistentes
abr-17 Relacionamentos 1 para 1 Relacionamentos 1 para muitos Relacionamentos muitos para muitos Todos os relacionamentos nos quais existe uma classe persistente envolvida também precisam ser modelados na base de dados. Considere as observações a seguir para decidir como fazer o mapeamento. Projetar base de dados

29 Relacionamentos 1 para 1 Como mapear?
abr-17 Relacionamentos 1 para 1 Como mapear? Relacionamentos 1..1 são simples, pois podem ser mapeados diretamente, usando-se chaves estrangeiras (FK – foreign key). Basta incluir em uma das tabelas a chave da outra, ou realizar uma fusão das duas tabelas, como ilustram os próximos slides. Projetar base de dados

30 Relacionamentos 1 para 1 Chaves estrangeiras - FK (foreign key)
abr-17 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 Projetar base de dados

31 Relacionamentos 1 para 1 Mapeamento usando chaves estrangeiras
abr-17 Relacionamentos 1 para 1 Funcionario pessoaID (PK) salario dataInicio CartaoPonto cartaoPontoID (PK) horasTrabalhadas pessoaID (FK) Funcionario salario dataInicio CartaoPonto horasTrabalhadas 0..1 1 Mapeamento usando chaves estrangeiras Funcionario pessoaID (PK) salario dataInicio horasTrabalhadas Quando uma das classes envolvidas no relacionamento não for persistente, recomenda-se adotar a fusão de tabelas (mapeando os atributos da classe não persistente para colunas da tabela que representa a classe persistente), uma vez que não faz sentido manter um cadastro independente (uma tabela) de itens não persistentes. Porém, se houver relacionamentos de uma das classes com outras classes do sistema, a fusão normalmente não é adotada, pois o mapeamento dos outros relacionamentos provavelmente levaria a uma duplicação de dados. Assim, a decisão de que estratégia adotar depende da aplicação e deve ser tomada caso a caso. Mapeamento usando fusão de tabelas Projetar base de dados

32 Relacionamentos um para muitos
abr-17 Relacionamentos um para muitos Como mapear? Relacionamentos 1..n têm que ser mapeados usando-se obrigatoriamente chaves estrangeiras, mesmo que uma das classes não seja persistente. A chave estrangeira é inserida sempre na tabela com multiplicidade n do relacionamento, como ilustra o exemplo a seguir. Projetar base de dados

33 Relacionamentos um para muitos
abr-17 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) Projetar base de dados

34 Relacionamentos muitos para muitos
abr-17 Precisam de uma tabela extra para representar a associação Cliente clienteID (PK) nome telefone enderecoResidencial ClienteConta clienteID (FK) contaID (FK) Conta contaID (PK) numero saldo Conta numero saldo Cliente nome telefone enderecoResidencial : Endereco 1..* Relacionamentos n..n necessitam de uma tabela extra para representar a associação, como mostra o exemplo acima. Projetar base de dados

35 Passo 3. Identificar índices
abr-17 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 Consultas aos dados do sistema podem ser otimizadas através do uso de índices. Porém, a indexação da base deve ser analisada criteriosamente, porque ela representa um custo extra na hora de inserir, atualizar e remover dados. Além disso, o uso de índices normalmente não representa ganhos significativos de desempenho em consultas a tabelas pequenas (com aproximadamente 100 linhas). Projetar base de dados

36 Que colunas indexar? Chaves primárias são sempre indexadas
abr-17 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 Além das chaves primárias, que são sempre indexadas, outras colunas também podem fazer uso de índices. Analise as descrições dos casos de uso do sistema, e identifique que dados devem ser indexados também. Lembre-se de considerar os requisitos de desempenho para consultas e atividades de inserção/atualização/remoção de dados, além da freqüência dessas operações, na hora de definir que outras colunas da base devem ser indexadas. Projetar base de dados

37 Passo 4. Definir restrições de integridade
abr-17 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.) Projetar base de dados

38 Passo 5. Definir características de armazenamento
abr-17 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 Projetar base de dados

39 Passo 6. Criar estruturas de armazenamento
abr-17 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) ... Se existir um DBA responsável pela base, as ações descritas a seguir devem ser requisitadas a ele. Neste caso, você precisa apenas contactá-lo e passar para ele as informações necessárias.Crie fisicamente as estruturas de armazenamento (base de dados, tabelas, colunas, etc.) descritas no modelo de dados da aplicação e, em seguida, defina índices para todas as chaves primárias do modelo (caso a ferramenta adotada não tenha feito isso automaticamente), pois elas são usadas freqüentemente em buscas e operações de join (junção de tabelas). Se as restrições de integridade correspondentes a chaves primárias e estrangeiras não forem geradas automaticamente, você deve criá-las de maneira a garantir a consistência dos dados armazenados na base. As restrições de integridade relacionadas a regras do negócio (como a unicidade da matrícula de um aluno em um mesmo curso, por exemplo) devem ser implementadas nos aplicativos e, opcionalmente (de forma redundante), diretamente pelo banco através de TRIGGERS e/ou CONSTRAINTS. Isto visa assegurar a consistência dos dados, quando estes forem manipulados por meios que não sejam os aplicativos. Porém, qualquer exceção ocorrida deve ser capturada pela aplicação. Caso existam tabelas de referência (tabelas que armazenam valores constantes e são muito referenciadas, como uma que armazene os estados do Brasil, por exemplo), solicite a área ao responsável pela Administração de Banco de Dados a sua criação, tendo em vista que dados desta natureza são públicos a todos os sistemas, popule-as com os valores que elas devem armazenar, de maneira que esses já possam ser utilizados em testes da aplicação. Projetar base de dados

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 Java Hibernate JDO .NET NHibernate iBATIS Python Strom Django ORM

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