SECONDO: An Extensible DBMS Architecture and Prototype 32

O SECONDO é uma plataforma extensível de um SGBD, adequado para a construção de protótipos de pesquisa e aprendizagem de arquitecturas/implementações de sistemas de base de dados. Este não tem um modelo de dados fixo, estando acessível para a implementação de novos modelos (Gutting et., 2004).

De acordo com o mesmo artigo, o objectivo deste trabalho é fornecer uma estrutura de sistemas de base de dados genérico, que pode ser preenchida com implementações de diferentes modelos de sistemas de gestão de bases de dados. Deve ser possível implementar modelos relacionais, modelos orientados a objectos, temporais ou XML, e acomodar tipos de dados espaciais, objectos móveis, fórmulas químicas, etc. A estratégia usada para este trabalho atingir o objectivo mencionado consistiu nos seguintes pontos:

• Separar as componentes independentes do modelo de dados e os mecanismos do sistema de base de dados das partes de dados dependentes do modelo.

• Apresentar um formalismo para descrever o modelo de dados implementado, com o intuito de ser capaz de fornecer interfaces simples, entre o sistema e o conteúdo.

• Estruturar a implementação de um modelo de dados em uma colecção de módulos de álgebra, sendo que cada um fornece operações e estruturas de dados específicas.

Os trabalhos em torno do sistema decorreram ao longo de vários anos. Foram realizadas experiências e tentativas de implementação de sistemas extensíveis o que ajudou muito a projectar o sistema actual.

O sistema Gral (Gutting, 1989) retratava um SGBD extensível por tipos de dados atómicos e qualquer tipo de operações (incluindo operações de relação). No entanto o modelo de dados central era fixo não coincidindo com a ideia original do SECONDO.

A ideia original do SECONCO4 era implementar uma componente de software para análise e optimização baseada em regras, podendo ser usada com vários modelos de dados e linguagens de consulta, bem como respectiva representação (Gutting, 1993). De acordo com Almeida et al. (2006), o principal objectivo do SECONDO é fornecer uma estrutura para sistemas de bases de dados genérica que pode ser usada com implementações de dados de vários SGBD. Este sistema (Figura 16) baseia-se em três grandes componentes:

Figura 16 - Componentes SECONDO (Retirado de: (Almeida et al., 2006) p. 3)

• O Kernel SECONDO: implementa modelos de dados específicos, sendo extensível por módulos de álgebra. Este fornece processamento de consultas e análises sobre as álgebras implementadas, estando desenvolvido em cima da base de dados BerkleyDB em C++.

4 _{Para obter informação mais detalhada sobre a ideia original do SECONDO e a projecção do mesmo consultar:}

Gutting, 1993. Second-Order Signature: A Tool for Specifying Data Models, Query Processing, and Optimization,

• Optimizer: determina e proporciona a optimização de consultas, implementando a parte essencial do SQL (como por exemplo: línguas), estando desenvolvido em Prolog.

• GUI: é uma interface extensível para um sistema de gestão de base de dados extensível, onde novos tipos de dados ou modelos disponibilizam as próprias visualizações ou métodos de visualização. Disponibiliza ainda uma interface especializada para tipos de dados espaciais e objectos móveis, fornecendo uma interface de base de dados espacial bastante sofisticada, incluído animação de objectos em movimento. Está desenvolvido em Java (Gutting,2007).

Os três componentes podem ser usados de diferentes formas, juntos (Figura16) ou de forma independente. O Kernel SECONDO pode ser usado como um sistema de utilizador único ou em modo cliente-servidor. Como um sistema único, este pode ser interligado com uma interface simples (shell), ou com o optimizador. Em modo cliente-servidor, o kernel pode servir clientes que executam tanto em interface de linha de comando, como interface de utilizador.

No caso do optimizador este pode ser usado separadamente para transformar consultas SQL em planos de consulta executados no SECONDO.

Por último, a componente GUI pode ser usada de forma independente para procurar dados espaciais ou espaço-temporais que residam em arquivos (Gutting, 2007).

Kernel SECONDO

A Figura 17 ilustra os componentes que constituem o Kernel do SECONDO, apresentando a sua arquitectura.

De acordo com o estudo de Almeida et al. (2006), um modelo de dados é implementado como um conjunto de tipos de dados e operações. Estes são agrupados em álgebras.

Um módulo de álgebra fornece um conjunto de construtores tipo, que implementam uma estrutura de dados para cada um destes. Cada registo de um construtor dentro de uma álgebra necessita de um conjunto de funções de apoio.

A componente Kernel actua como gestor de base de dados (Gutting et al., 2004). Este pode avaliar um plano de consulta também denominado por consulta executável. O processamento

das consultas (Query) é realizado da seguinte forma: o Command Manager recebe uma consulta executável, analisa-a passando o resultado para o processador de consultas (Query

Processor & Catalog). Este avalia a consulta através da construção de uma árvore de

operação, percorre-a invocando operadores provenientes das álgebras existentes (Dicker e Gutting, 2000). Os objectos SECONDO são armazenados e recuperados pelo Storage

Manager na base de dados, sendo esta componente gerida pelo Catalog.

Figura 17 - Arquitectura do Kernel SECONDO (Retirado de: (Almeida et al., 2006) p. 3)

Optimizer

Segundo Gutting et al. (2004), o Optimizador (Optimizer) apresenta vários requisitos:

• Como qualquer optimizador, este precisa de encontrar rapidamente bons planos de consulta.

• Deve funcionar bem para tipos de dados não definidos (non-standard data

types) com conjuntos de operações.

• O esforço de implementação para apoiar a optimização dos dados não padronizados não deve ser esmagadora, sendo idealmente reduzida.

• Os mecanismos de extensão para o optimizador devem ser simples e compreensíveis.

• Para o ensino, é uma vantagem se o algoritmo de optimização for simples e claro e o código acessível e bem documentado.

Esta componente decompõe o problema geral em três partes, com o código completamente separado: optimização de consultas conjuntas; estimativa de selectividade e implementação de

uma linguagem de consulta. Na Figura 18 é ilustrado o funcionamento do optimizador do SECONDO para uma consulta específica.

Figura 18 - Protocolo do Optimizador SECONDO (Retirado de: (Almeida et al., 2006) p. 4)

GUI

Por fim a visualização dos dados da consulta é possível na interface gráfica do utilizador (JavaGUI). Esta componente comunica com o kernel do sistema e o optimizador via TCP/IP, sendo que esta pode ser utilizada por vários utilizadores, exibindo conjuntos de dados diferentes.

A interface do utilizador está dividida em quatro elementos (Figura 19): a área de comando (superior esquerdo), o gestor de objectos (superior direito), a área que contém o utilizador actual (baixo). Existe ainda a barra de progresso (meio) que permite visualizar objectos em movimento, sendo a animação controlada pelos botões que permitem realizar várias funções (aumentar velocidade, parar, etc.). Na área de comando, o utilizador pode introduzir consultas e comandos de controlo Javagui. Este interpreta se a consulta é executável ou se esta apresenta uma sintaxe do optimizador. Se estiver na sintaxe do optimizador, este envia a consulta para o mesmo e recebe o plano numa forma executável, sendo este enviado para o Kernel do sistema. O resultado da consulta é posteriormente entregue num formato genérco,

ao Object Manager que o armazena, seleccionando um visualizador capaz de o exibir para processamento posterior.

3. STAR: UM SISTEMA DE INFORMAÇÃO ESPAÇO-TEMPORAL