CIn-UFPE1 Projeto de Gerenciamento de Dados

CIn-UFPE2 Objetivos n Definir o que significa gerenciamento de dados do sistema; n Entender abordagens diferentes para gerenciamento de dados: baseado em arquivo, SGBD, SGBDOO; n Entender como padrões de projeto podem ser aplicados no projeto de gerenciamento de dados.

CIn-UFPE3 Definições n O gerenciamento de dados controla como os dados são armazenados e manipulados pelos programas do sistema. n O gerenciamento de dados permite que os usuários sejam capazes de recuperar as informações que necessitam de forma eficiente (tempo de resposta).

CIn-UFPE4 Os requisitos para persistência n Alguns dados precisam ser persistentes, outros não. n Dados persistentes devem ser armazenados entre uma execução do sistema e a próxima. n Dados não persistentes (transientes) podem ser:  resultados de consultas que são exibidas,  valores de parâmetros passados para operações,  resultados intermediários de cálculos. n Não haverá problemas se eles forem perdidos quando a execução parar.

CIn-UFPE5 Armazenamento persistente n Dados persistentes são usualmente relacionados ao negócio; ex:  nomes de clientes,  Saldo em conta corrente. n Modelados como atributos no Modelo de Classes. n Contudo, algumas vezes podem não ser relacionados com o negócio:  senhas dos usuários, níveis de acesso.

CIn-UFPE6 Tipos de Armazenamento de Dados n Sistema de Arquivos n Sistema de Gerenciamento de Banco de Dados (SGBD)

CIn-UFPE7 Sistemas de Arquivos n A solução mais simples para armazenamento persistente. n Registros no arquivo podem ter diferentes formas:  tamanho fixo  tamanha variável  cabeçalho e detalhe  dados com tags (ex: HTML, XML)

CIn-UFPE8 Organização de Arquivos n Organização seqüencial  Cada registro é escrito no arquivo em alguma ordem pré estabelecida n Organização randômica  Registros são adicionados ao arquivo através de algoritmos precisos que permitem que registros sejam escritos e lidos diretamente sem ter que ler o resto do arquivo

CIn-UFPE9 Acesso a arquivos n Acesso seqüencial n Acesso direto: Endereçamento através de hash

CIn-UFPE10 Desvantagens de Arquivos n Quando o número de aplicações cresce, o número de diferentes arquivos cresce. Alguns destes arquivos podem ter os mesmos dados para diferentes aplicações em diferentes formatos (duplicação, redundância) n Existe o risco que a atualização de dados em aplicações distintas não seja sincronizada.

CIn-UFPE11 Desvantagens de Arquivos (Cont.) n Cada aplicação deve conter seu próprio mecanismo para o armazenamento de dados no seu conjunto de arquivos. Se os dados mudam ou a maneira que eles são armazenados é alterada, então cada programa da aplicação que acessa estes dados deve ser corrigido. n Quando os requisitos de negócio mudam, os usuários podem querer acessar os dados de novas maneiras. Isto pode requerer um esforço considerável de programação.

CIn-UFPE12 Sistemas de Gerenciamento de Banco de Dados – arquitetura em três esquemas n Há bastante tempo foi identificada a importância de separar o armazenamento persistente do sistema de aplicação. Esquema Externo Esquema Conceitual Esquema Interno A visão dos dados usados pelos programas da aplicação O modelo lógico dos dados que está separado de como os dados serão usados O armazenamento físico dos dados em arquivos e índices

CIn-UFPE13 Arquitetura em três esquemas - vantagens n A aplicação focaliza em tarefas específicas do negócio; n Sistema de Gerenciamento de Banco de Dados (SGBD) focaliza na eficiência do armazenamento, da recuperação e do processamento de transação; n O esquema interno pode ser modificado sem impactar na aplicação.

CIn-UFPE14 Arquitetura em três esquemas – vantagens (cont.) n O uso do esquema conceitual pode eliminar duplicação de dados desnecessária n A integridade de dados pode ser garantida n Mudanças no esquema conceitual não devem afetar os programas de aplicação n Mudanças no esquema interno não têm impacto no esquema conceitual

CIn-UFPE15 Arquitetura em três esquemas – vantagens (cont.) n Existem ferramentas disponíveis para melhorar a performance do banco de dados n Existem facilidades para fazer o backup e a recuperação de dados n A segurança e o acesso aos dados por vários usuários simultaneamente podem ser controlados

CIn-UFPE16 Arquitetura em três esquemas - desvantagens n Existe um custo associado com a contratação de pessoas para a gerência de SGBD n Existirá um overhead no processamento da conversão de dados a partir do banco de dados para o formato requerido pelos programas de aplicação.

CIn-UFPE17 Projeto para SGBD Relacional n Banco de dados relacional guarda dados em tabelas bidimensionais n Classes podem ter estruturas complexas  objetos dentro de outros objetos n Precisa mapear as classes para tabelas no projeto das estruturas de armazenamento

CIn-UFPE18 Projeto para SGBD Relacional (cont.) n Quando o sistema requer uma instância de uma classe a partir do banco de dados, ele terá que recuperar os dados de todas as tabelas que guardam partes daquela instância de objeto e reconstruir o objeto

CIn-UFPE19 Mapeando Classes n Classes com estrutura de dados simples correspondem a tabelas. n Os identificadores dos objetos tornam-se chaves primárias. n Classes que contêm uma instância de outra classe como um atributo:  Cria-se uma tabela separada para a classe que é atributo

CIn-UFPE20 Mapeando Classes n Classes que contêm coleções  Aloca-se um identificador de objeto para a classe contida na coleção. Esta classe será representada por uma tabela.  Cria-se uma tabela separada que contém duas colunas è1o.: Guarda os identificadores dos objetos que contêm a coleção è2o.: Guarda os identificadores dos objetos que estão contidos na coleção

CIn-UFPE21 Mapeando Associações n Associações de 1 - N (um para muitos) podem ser tratadas como coleções. n Associações de M - N (muitos para muitos) tornam-se tabelas separadas.  Cria-se uma tabela que contém duas colunas.  Cada linha contém um par de identificadores de objeto, um para cada objeto que participa da associação. n Associações (um para um) são implementadas como atributos de chave estrangeira. Cada classe ganha um atributo extra que contém o identificador do objeto ao qual a classe está associada.

CIn-UFPE22 Mapeando Herança - três alternativas n Implementar apenas a superclasse como uma tabela, se as subclasses diferem das suas superclasses mais no comportamento do que nos atributos  Atributos das subclasses tornam-se atributos da tabela da superclasse e guardam-se valores nulos onde não são usados.

CIn-UFPE23 Mapeando Herança - três alternativas n Implementar apenas as subclasses como tabelas, se a superclasse for abstrata (não existirá nenhuma instância dela)  Os atributos da superclasse são armazenados em todas as tabelas das subclasses n Implementar todas as classes como tabelas separadas.  Para recuperar os dados para uma subclasse tanto a sua própria tabela como a tabela da sua superclasse devem ser acessadas.

CIn-UFPE24 SGBD Orientado a Objetos n SGBD Orientado a Objetos é essencialmente combinado com linguagem de programação OO. n É capaz de armazenar objetos com todas as suas estruturas complexas (objetos que contêm outros objetos, incluindo coleções como atributos). n Não é necessário transformar as classes do modelo de projeto

CIn-UFPE25 Banco de Dados Distribuído n Os objetos que participam de um caso de uso particular não precisam estar na mesma máquina que a interface do usuário,  eles podem estar distribuídos em diferentes máquinas n Pode-se usar, por exemplo, Remote Procedure Calls-RPC (C/C++) e Remote Method Invocation- RMI (Java).

CIn-UFPE26 Projetando Classes de Gerenciamento de Dados n Classes de gerenciamento de dados são usadas para desacoplar as aplicações do seu armazenamento. n Use classes de gerenciamento de dados sempre que:  precisar armazenar um objeto da aplicação;  precisar procurar ou recuperar objetos armazenados;  precisar ter uma interface com um SGBD não orientado a objetos

CIn-UFPE27 Camada de armazenamento de dados n Opção para concentrar operações que manipulam as tarefas de armazenamento e recuperação de objetos. Possíveis soluções:  Todos os objetos persistentes do sistema herdam métodos para armazenamento a partir de uma superclasse abstrata - PersistentObject  Introduzir classes separadas no sistema com o objetivo de lidar com o armazenamento e recuperação de outras classes (abordagem de Database broker)

CIn-UFPE28 Solução baseada na Superclasse PersistentObject n A superclasse PersistentObject encapsula os mecanismos para que um objeto de qualquer classe armazene e recupere a partir do banco de dados.  Esta superclasse implementa operações para buscar um objeto pelo seu identificador, armazenar, remover e atualizar objetos n Cada classe é responsável pelo seu próprio armazenamento, mas:  diminui a coesão das classes; èclasse deve ter conhecimento específico de tarefas de armazenamento; èisto não está relacionado com as tarefas da aplicação.

CIn-UFPE29

CIn-UFPE30 Solução baseada no Database Broker n Separa os objetos de negócio do armazenamento de dados n As classes que oferecem os serviços de armazenamento de dados ficarão num pacote separado n Para cada classe de negócio que precisa ser persistente, existirá uma classe intermediária (Database Broker) associada

CIn-UFPE31 Classe Broker n A classe Broker oferece os mecanismos para materializar objetos a partir do banco de dados e coloca-los de volta ao banco de dados

CIn-UFPE32 Database Broker n O objeto broker do banco de dados é responsável por:  “materializar” objetos,  “desmaterializar” objetos,  armazenar objetos numa cache. n A Classe de aplicação é protegida (isolada) do armazenamento. n Programas de aplicação não são afetados por mudanças na base de dados.

CIn-UFPE33 Objetos armazenados na Cache n Objetos podem ser armazenados na cache por questão de eficiência. n A cache é uma coleção mantida pelo broker do SGBD. n Quando um objeto é requisitado, primeiro ele é procurado na cache. n Se o objeto requisitado não estiver na cache ele é materializado pelo broker do SGBD a partir do banco de dados.

CIn-UFPE34 Leituras Adicionais n Rumbaugh et al. (1991) Object-Oriented Modeling and Design. Prentice-Hall. Chapter 17 - Relational Databases n Larman (1998) Applying UML and Patterns. Prentice-Hall. Chapter 38 - Frameworks, Patterns and Persistence n Coad (1997) Object Models - Strategies, Patterns and Applications. Prentice-Hall. Appendix C - Data Management