Olá pessoal. Na coluna desta semana vou apresentar algumas tendências na área de banco de dados. Algumas das idéias que citarei nesta coluna já existem de alguma forma nos produtos atuais, outras estão encaminhando para a implementação e algumas são puramente idéias teóricas que talvez nunca vinguem. Por isso recomendo a leitura com cuidado, pois algumas destas tendências podem ser enquadradas na área de futurologia.

Técnicas de controle de concorrências

Os bancos de dados naturalmente precisam de alguma técnica para controlar a concorrência. Desde o início desta área a técnica que mais tem sido utilizada é o lock, presente tanto no SQL Server como o Oracle. Denominada técnica pessimista, o locking permite o acesso exclusivo de recursos a somente um usuário por vez.

Porém existem outras técnicas mais interessantes, que são muito utilizadas na área de sistemas colaborativos síncronos, como aplicações groupware. Um exemplo disso é o uso do MVCC (Multi Version Concurrency Control) que já é utilizado no PostgreSQL. Nesta técnica otimista cada usuário consegue trabalhar com a sua versão do registro que posteriormente será sincronizada.

Existem também outros algoritmos que talvez sejam utilizados em banco de dados, como o OT (Operational Transformations), dOPT (distribtuted Operational Transformation) e alguns algoritmos híbridos que utilizam técnicas otimistas e pessimistas. Estes algoritmos híbridos permite o uso de locks dinâmicos, múlti-granulares, hierárquicos e síncronos. Porém estas idéias estão implementadas apenas em protótipos descritos em papers da área acadêmica.

Melhoria da tecnologia de índices

Índices são objetos extremamente importantes para o banco de dados, pois eles são os responsáveis por acelerar o tempo de execução de instruções. Apesar de termos visto muita evolução nesta área, como índices para views, uso paralelo de índices e criação de índices a partir de expressões ou de apenas alguns valores de chaves, ainda existem muitas melhorias que podem ser implementadas.

Neste sentido as pesquisas na área tem se voltado para o modo de armazenamento dos índices. Em geral os bancos de dados atuais utilizam alguma variação da estrutura de árvores binária para armazenar e percorrer os valores dos índices. Porém uma tendência forte para esta tecnologia é utilizar outra forma de armazenamento dos valores das chaves. Vejam por exemplo o Oracle: você pode especificar vários tipos de armazenamento do índices que incluem índices BITMAP, InterMEDIA/Text Indexes e outros. Em geral esta tecnologia tem sido impulsionada pelos novos tipos de dados armazenado no banco que requerem tratamento especial, como dados geográficos e dados voltados para a área de biotecnologia.

Além da nova forma de armazenamento existe também a tendência de aproveitar ambientes multi-núcleo, clusterizados, replicados, virtuais e até em grid para armazenar, alterar e consultar índices. Mais uma vez, os bancos de dados atuais ainda estão apenas engatinhando nesta área.

Evolução da linguagem SQL

Muito tem-se falado a respeito da evolução da linguagem. Apesar de tudo que tenho ouvido a respeito de mecanismos de persistência, LINQ e banco de dados relacionais orientados e objetos e outras inovações, a linguagem SQL continua firma e forte. Porém podemos classificar as tendências relacionadas à evolução da linguagem SQL em dois tipos: melhorias na linguagem em si e no modo que ela é utilizada.

A linguagem SQL, em geral, se baseia muito no padrão SQL, que vêm evoluindo. Nas últimas versões temos cada vez mais cláusulas, sintaxes, operadores e outras funcionalidades que são implementadas nos bancos dados. O Oracle, por exemplo, possui a sintaxe bem enxuta mas que pode ser estendida pelos seus vários pacotes PL/SQL. Já o SQL Server está se dirigindo para a utilização de outras linguagens dentro do banco, devido à integração com o Framework .NET, ao invés de modificar muito a linguagem SQL. Em geral, os bancos de dados de código livre apresentam a conformidade com o padrão e não possuem muita variação dele.

Aqui vale a pena citar algumas alternativas. Além da evolução do SQL, e de seus padrões irmãos voltados para OLAP, como o MDX (Multidimensional Expressions), temos outras idéias interessantes. Como exemplo de outras idéias interessantes posso citar:

• O uso de instruções parecidas com o SQL voltadas para Data Mining;

• A linguagem OSQL (Object Query Language);

• O uso de Lógica Fuzzy diretamente em consultas;

• Técnicas para a abreviação de joins e outras cláusulas que podem ser inferidas diretamente a partir do modelo de dados;

• Consultas e instruções específicas para o tratamento de dados temporais; e
• Extensões e linguagens específicas para o tratamento de dados hierárquicos, semi-estruturados, acesso a repositório de regras (como no PROLOG) e também instruções específicas para processo de ETL (Extract, Transform, Load).

Do ponto de vista de como o SQL é utilizada várias idéias novas tem aparecido ao longo dos dados. Geralmente esta tendência está relacionada com novas interfaces gráficas ou técnicas que evitam o uso direto de uma instrução SQL. Um exemplo disso é o uso do Processamento Natural de Linguagem (PNL), que permite ao usuário fazer uma perguta mais natural em vez de formatá-la em uma linguagem SQL. Outra idéia é apresentar interfaces gráficas que permitem montar a consulta SQL diretamente a partir do modelo, como na Figura 1. A tela do protótipo da Figura 1 apresenta parte do modelo de dados representado por círculos e linhas. O usuário deve clicar estes elementos, que são destacados, e a instrução SQL é montada automaticamente. Este protótipo faz parte de um artigo cujo título é "Tratamento de Herança em uma Interface Gráfica de Consulta a Banco a Dados Relacionais", escrito por Luciana M.L. Mendonça Alberto H.F. Laender.

Figura 1. Assistente visual para a construção de consultas SQL. Primeiro o modelo complemento é apresentado e depois apenas as entidades que fazem parte da consulta.

A partir deste ponto de vista a tendência á cada vez mais tornar transparente para o usuário a linguagem SQL, pois o usuário contará com uma interface gráfica mais amigável para realizar sua consulta. Apenas para citar outro exemplo que pode ser apreciado, recomendo uma vista ao site com recursos da Web 2.0 chamado ElasticList, que podem ser visto na Figura 2.

Figura 2. Interface do ElasticLinks

A idéia deste site é mostrar um conceito de filtros onde o usuário possui várias "listas elásticas". Nesta interface cada escolha de valor em uma das listas apresenta um filtro nos dados. Neste caso a base de dados consultada é aquela que armazena todos os ganhadores do prêmio Nobel. Basta selecionar o tipo de prêmio, gênero, país, década e ano para filtrar os dados, que são mostrados na parte de baixo da interface com direito à imagem dos laureados pelo prêmio de acordo com o resultado da pesquisa. Este é mais um exemplo de interface gráfica que ajuda o usuário trabalhar com os dados e evita que ele conheça a linguagem SQL. O link para o site é:

http://well-formed-data.net/experiments/elastic_lists/.

Recuperação de dados

O conceito de recuperação de dados apresenta vários desafios. A idéia aqui é permitir que a recuperação de linhas, tabelas e outros objetos do banco de dados seja como a metáfora da lixeira do Windows ou do Mac: tudo que foi jogado fora pode ser recuperado rapidamente com apenas alguns cliques.

Nesta área o Oracle está apresentando algumas idéias interessantes. A partir da versão 9i foi colocado um mecanismo chamado de Time Machine. Este mecanismo permite consultar e recuperar dados passados de uma tabela facilmente, como se houvesse uma outra tabela contendo os dados. Por exemplo, imaginem o seguinte cenário: são 11:00 da manhã na empresa e um usuário apagou registros de um pedido por engano. Como existem várias tabelas relacionadas ao pedido é preciso voltar todos os dados, inclusive chaves primárias, estrangeiras, relacionamentos, cálculos efetuados por triggers e outros, no menor tempo possível. É claro que existe o backup, mas esta solução provavelmente vai envolver uma quantidade considerável de esforço e recursos.

Para estes cenários que o Oracle implementou o recurso Time Machine, que permite voltar os dados de um terminado ponto no tempo. Mas existe muitos outros conceitos e meios por trás disso, como Snapshot Databases, Transaction Time Databases, Valid Time Database, Bitemporal Database e uma linguagem própria chamada TSQL2. Por exemplo, com a linguagem TSQL2 poderíamos utilizar instrução para indicar que desejamos os dados de um momento específico de uma determinada tabela. Os exemplos abaixo mostram como fazer isso utilizando os conceitos de schemas e operadores bitemporais do TSQL2. Estes exemplos apresentados na Listagem 1 não podem ser executados nos bancos de dados atuais, pois são apenas parte de um protótipo acadêmico proposto por pesquisadores da área.

-- Especificando o schema antes de executar a instrução
SET SCHEMA DATE "1998-01-01"
SELECT * FROM DOCTOR
WHERE Name = "Mary Brown"

-- Especificando o operador bitemporal apenas para a entidade DOCTOR
SELECT * FROM DOCTOR
WHERE SCHEMA (DOCTOR) PRECEEDS DATE "1997-06-01"

-- Especificando schema e transação junto com operadores bitemporais
SET SCHEMA VALID DATE "1998-01-01" 
AND TRANSACTION DATE "1997-01-01"
SELECT * FROM DOCTOR
WHERE VALID(DOCTOR) OVERLAPS DATE "1995-01-07"
AND TRANSACTION (DOCTOR) OVERLAPS DATE "1996-01-01"

Com estas tendências terminamos a primeira parte do artigo que aborda algumas tendências da área de banco de dados. No próximo artigo apresentaria mais algumas idéias e tendências que talvez representem as inovações futuras nos bancos de dados que utilizamos atualmente.

Um grande abraço e até a próxima pessoal.