Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Do que se trata o artigo

Apresenta os fundamentos e mecanismos que cercam a tecnologia de banco de dados ativos e como estes são suportados em SGBDs comercias e de código aberto. Adicionalmente, são descritas aplicações potenciais para o emprego de tais mecanismos, bem como os desafios e limitações atuais encontrados nesta tecnologia.

Em que situação o tema útil

Na construção de sistemas de informação que desejam usufruir ou considerar a potencialidade de um SGBD ativo em gerenciar e acionar, de forma autônoma, um conjunto de regras de negócio na incidência de determinados eventos sobre seus dados, regras estas que serão compartilhadas dentre todos os sistemas de informação que acessam os referidos dados.

Resumo DevMan

Bancos de Dados Ativos atuam como gestores de regras de negócio que são compartilhadas dentre todos os sistemas de informações que os acessam. Neste artigo, esta tecnologia é conceituada, suas aplicações potenciais são definidas, bem como são delineadas as dificuldades que cercam seu projeto e monitoramento.

Historicamente, o Sistema Gerenciador de Banco de Dados – SGBD – é utilizado convencionalmente para gerir grandes coleções de dados, garantir seus respectivos relacionamentos e responder a operações de manutenção e consultas de dados provenientes de diferentes sistemas de informações ou utilitários. Dentro desta perspectiva, muitos sistemas de informação são construídos considerando o SGBD como provedor da estrutura dos dados e sua persistência, enquanto toda a responsabilidade por aspectos comportamentais e dinâmicos – o modelo comportamental –, inerentes a quaisquer processos de negócio, é construída nas linguagens de programação (veja a Nota DevMan 1).

Nota DevMan 1. Modelo Comportamental

O Modelo comportamental descreve as ações que o sistema deve realizar para responder aos eventos gerados pelos usuários.

Como um exemplo simples deste paradigma, imagine o acompanhamento dinâmico de uma situação crítica de um negócio que, costumeiramente, seria sanado por uma das duas abordagens principais em linguagem de programação: efetuar a chamada de função em diferentes pontos do sistema ou agendar a função para uma varredura periódica – similar a um mecanismo de polling – veja a Nota DevMan 2. Enquanto na primeira abordagem incorremos no problema de múltiplos locais de manutenção de código, na segunda enfrentamos o dilema da frequência de processamento que, se elevada, pode afetar o desempenho da rede e do próprio SGBD e, se baixa, pode não atender a necessidade do negócio para a tomada de uma ação.

Nota DevMan 2. Polling

Polling se refere à operação de verificar a situação de um hardware, dispositivo de rede, dados, dentre outros, de forma contínua e em curto intervalo de tempo.

Contudo, uma solução como a supracitada, alinhado ao aumento do volume e complexidade no tratamento de dados e regras de negócio, tem demonstrado resultados insatisfatórios em quesitos como a rapidez de desenvolvimento e evolução de sistemas de informação.

Estes desafios propiciaram o aumento do suporte da representação do comportamento do negócio – por meio de representação de suas regras – nos bancos de dados, fato que pode ser constatado nas áreas de banco de dados temporais, dedutivos e ativos. Este último, cerne de nossa atenção, provê facilidades e mecanismos para responder de maneira autônoma – determinar a conduta de ação – a diferentes eventos e condições sobre os dados dentro de um contexto.

O Modelo Semântico

O Banco de Dados Ativo é uma tecnologia que integra as funcionalidades convencionais dos bancos de dados aos mecanismos que o permitem a especificação, análise, execução e monitoramento de regras que asseguram um modelo comportamental, denominadas regras ativas.

Tais regras são conhecidas como regras ECA devido ao estigma do paradigma Evento-Condição-Ação – ilustrado na Figura 1 – que baliza seu princípio de funcionamento que, inclusive, é bastante intuitivo. Quando um evento que altera o estado do banco de dados ocorre – linhas acrescentadas ou modificação de uma coluna, por exemplo –, a condição de execução da regra é avaliada e, sendo verdadeira, a ação é executada.

Figura 1. Visão esquemática das regras ECA.

O processamento das regras ECA (ver Figura 2) é realizado por mecanismos que monitoram os eventos – operações sobre um esquema ou mesmo o SGBD –, e os associam as regras. Essas são avaliadas e organizadas, segundo uma política de escalonamento, para subsequente execução. Esse trabalho de orquestração leva um SGBD a experimentar um comportamento reativo capaz de incorporar a semântica das regras de negócio.

Tomando como exemplo a necessidade de manutenção do estoque de uma indústria, poderíamos criar regras ECA que monitorassem os níveis de disponibilidade das matérias primas. Na identificação de um nível baixo – o evento – de uma das matérias-primas críticas para a indústria – a condição –, a compra seria disparada automaticamente ao fornecedor sem qualquer intervenção humana – a ação.

...
Quer ler esse conteúdo completo? Tenha acesso completo