CIn-UFPE1 Projeto de Gerenciamento de Dados. CIn-UFPE2 Objetivos n Definir o que significa gerenciamento de dados do sistema; n Entender abordagens diferentes

CIn-UFPECIn-UFPE 11

Projeto de Gerenciamento de DadosProjeto de Gerenciamento de Dados

CIn-UFPECIn-UFPE 22

ObjetivosObjetivos

Definir o que significa gerenciamento de dados do sistema;

Entender abordagens diferentes para gerenciamento de dados: baseado em arquivo, SGBD, SGBDOO;

Entender como padrões de projeto podem ser aplicados no projeto de gerenciamento de dados.

CIn-UFPECIn-UFPE 33

DefiniçõesDefinições

O gerenciamento de dados controla como os dados são armazenados e manipulados pelos programas do sistema.

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-UFPECIn-UFPE 44

Os requisitos para persistênciaOs requisitos para persistência

Alguns dados precisam ser persistentes, outros não.

Dados persistentes devem ser armazenados entre uma execução do sistema e a próxima.

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ão haverá problemas se eles forem perdidos quando a execução parar.

CIn-UFPECIn-UFPE 55

Armazenamento persistenteArmazenamento persistente

Dados persistentes são usualmente relacionados ao negócio; ex: nomes de clientes, Saldo em conta corrente.

Modelados como atributos no Modelo de Classes. Contudo, algumas vezes podem não ser

relacionados com o negócio: senhas dos usuários, níveis de acesso.

CIn-UFPECIn-UFPE 66

Tipos de Armazenamento de DadosTipos de Armazenamento de Dados

Sistema de Arquivos Sistema de Gerenciamento de Banco de Dados

(SGBD)

CIn-UFPECIn-UFPE 77

Sistemas de ArquivosSistemas de Arquivos

A solução mais simples para armazenamento persistente.

Registros no arquivo podem ter diferentes formas: tamanho fixo tamanha variável cabeçalho e detalhe dados com tags (ex: HTML, XML)

CIn-UFPECIn-UFPE 88

Organização de ArquivosOrganização de Arquivos

Organização seqüencial Cada registro é escrito no arquivo em alguma ordem pré

estabelecida 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-UFPECIn-UFPE 99

Acesso a arquivosAcesso a arquivos

Acesso seqüencial Acesso direto: Endereçamento através de hash

CIn-UFPECIn-UFPE 1010

Desvantagens de ArquivosDesvantagens de Arquivos

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)

Existe o risco que a atualização de dados em aplicações distintas não seja sincronizada.


Desvantagens de Arquivos (Cont.)Desvantagens de Arquivos (Cont.)

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.

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.


Sistemas de Gerenciamento de Banco de Sistemas de Gerenciamento de Banco de Dados – arquitetura em três esquemasDados – arquitetura em três esquemas

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 usadosO armazenamento físico dos dados em arquivos e índices


Arquitetura em três esquemas - Arquitetura em três esquemas - vantagensvantagens

A aplicação focaliza em tarefas específicas do negócio;

Sistema de Gerenciamento de Banco de Dados (SGBD) focaliza na eficiência do armazenamento, da recuperação e do processamento de transação;

O esquema interno pode ser modificado sem impactar na aplicação.


Arquitetura em três esquemas – vantagens Arquitetura em três esquemas – vantagens (cont.)(cont.)

O uso do esquema conceitual pode eliminar duplicação de dados desnecessária

A integridade de dados pode ser garantida Mudanças no esquema conceitual não devem afetar

os programas de aplicação Mudanças no esquema interno não têm impacto no

esquema conceitual


Arquitetura em três esquemas – vantagens Arquitetura em três esquemas – vantagens (cont.)(cont.)

Existem ferramentas disponíveis para melhorar a performance do banco de dados

Existem facilidades para fazer o backup e a recuperação de dados

A segurança e o acesso aos dados por vários usuários simultaneamente podem ser controlados


Arquitetura em três esquemas - Arquitetura em três esquemas - desvantagensdesvantagens

Existe um custo associado com a contratação de pessoas para a gerência de SGBD

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.


Projeto para SGBD RelacionalProjeto para SGBD Relacional

Banco de dados relacional guarda dados em tabelas bidimensionais

Classes podem ter estruturas complexas objetos dentro de outros objetos

Precisa mapear as classes para tabelas no projeto das estruturas de armazenamento


Projeto para SGBD Relacional (cont.)Projeto para SGBD Relacional (cont.)

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


Mapeando ClassesMapeando Classes

Classes com estrutura de dados simples correspondem a tabelas.

Os identificadores dos objetos tornam-se chaves primárias.

Classes que contêm uma instância de outra classe como um atributo: Cria-se uma tabela separada para a classe que é

atributo


Mapeando ClassesMapeando Classes

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ção2o.: Guarda os identificadores dos objetos que

estão contidos na coleção


Mapeando AssociaçõesMapeando Associações

Associações de 1 - N (um para muitos) podem ser tratadas como coleções.

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. Associações 1 - 1 (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.


Mapeando Herança - três alternativasMapeando Herança - três alternativas

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.


Mapeando Herança - três alternativasMapeando Herança - três alternativas

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


SGBD Orientado a ObjetosSGBD Orientado a Objetos

SGBD Orientado a Objetos é essencialmente combinado com linguagem de programação OO.

É capaz de armazenar objetos com todas as suas estruturas complexas (objetos que contêm outros objetos, incluindo coleções como atributos).

Não é necessário transformar as classes do modelo de projeto


Banco de Dados DistribuídoBanco de Dados Distribuído

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

Pode-se usar, por exemplo, Remote Procedure Calls-RPC (C/C++) e Remote Method Invocation-RMI (Java).


Projetando Classes de Gerenciamento de Projetando Classes de Gerenciamento de DadosDados

Classes de gerenciamento de dados são usadas para desacoplar as aplicações do seu armazenamento.

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


Camada de armazenamento de dadosCamada de armazenamento de dados

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)


Solução baseada na Superclasse Solução baseada na Superclasse PersistentObjectPersistentObject

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

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.



Solução baseada no Database Solução baseada no Database BrokerBroker

Separa os objetos de negócio do armazenamento de dados

As classes que oferecem os serviços de armazenamento de dados ficarão num pacote separado

Para cada classe de negócio que precisa ser persistente, existirá uma classe intermediária (Database Broker) associada


Classe Classe BrokerBroker

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


DatabaseDatabase Broker Broker

O objeto broker do banco de dados é responsável por: “materializar” objetos, “desmaterializar” objetos, armazenar objetos numa cache.

A Classe de aplicação é protegida (isolada) do armazenamento.

Programas de aplicação não são afetados por mudanças na base de dados.


Objetos armazenados na Objetos armazenados na CacheCache

Objetos podem ser armazenados na cache por questão de eficiência.

A cache é uma coleção mantida pelo broker do SGBD.

Quando um objeto é requisitado, primeiro ele é procurado na cache.

Se o objeto requisitado não estiver na cache ele é materializado pelo broker do SGBD a partir do banco de dados.


Leituras AdicionaisLeituras Adicionais

Rumbaugh et al. (1991) Object-Oriented Modeling and Design. Prentice-Hall.Chapter 17 - Relational Databases

Larman (1998) Applying UML and Patterns. Prentice-Hall.Chapter 38 - Frameworks, Patterns and Persistence

Coad (1997) Object Models - Strategies, Patterns and Applications. Prentice-Hall.Appendix C - Data Management

Documents

CIn-UFPE1 Projeto de Gerenciamento de Dados. CIn-UFPE2 Objetivos n Definir o que significa gerenciamento de dados do sistema; n Entender abordagens diferentes