Autor: Vanderlei Vilhanova Ortêncio


1. INTRODUÇÃO

Os SGBDs (Sistemas Gerenciadores de Banco de Dados) constituem-se produtos indispensáveis em qualquer ambiente de informática. Nos ambientes pequenos, muitas vezes se apresentam embutidos em algumas linguagens, como Clipper por exemplo. Nos ambientes maiores, os SGBDs têm uma personalidade mias caracterizada, passando a determinar as linguagens que o manipulam, geralmente apresentando uma linguagem mais ou menos proprietária, como ADABAS que possui integrado a linguagem NATURAL.

A maioria dos SGBDs mais completos possuem também integração com Dicionário de Dados (geralmente proprietários) que são orientados para definição dos dados em conformidade com os "maneirismos" do SGBD, apresentando os mais variados níveis de transparência em relação à implementação física dos dados bem como as estruturas internas do SGBD.

Atualmente há um predomínio do modelo Relacional, sendo que a grande maioria dos produtos alega pertencer a esta categoria, embora todos estejam muito longe de implementar os requisitos do modelo Relacional. Alguns se aproximam mais, porém, a um custo de performance muito alto, que às vezes inviabiliza o uso das vantagens do modelo.

Para complicar ainda mais este quadro, o paradigma de orientação por objetos está assumindo proporções importantes numa aceleração crescente na área de Desenvolvimento de Software. O problema é que, nos discursos de BDOO (Banco de Dados Orientado a Objetos), o modelo Relacional perde espaço para o modelo em Rede. Isto coloca um pouco de água na farofa da euforia do discurso empregado pelos defensores do modelo Relacional, cujos produtos no mercado mal cumprem parte das 12 regras (na verdade é uma dúzia de treze por causa da regra zero) há muito tempo definidas pelo seu idealizador, o Dr. Codd (dizem que a lista agora tem 24 regras ou mais). Muita água ainda vai rolar nesta discussão religiosa, principalmente porque ambos os conceitos possuem méritos próprios, suficientes para não serem negligenciados.

Mas, a despeito de toda discussão teórica, uma coisa é certa. Na hora da utilização, as nossas possibilidades se restringem aos produtos disponíveis no mercado, aos seus custos, ambientes compatíveis e obviamente os nossos requisitos. Esta verdade nos impõe a necessidade de acompanhamento constante dos produtos disponíveis para aquisição e uso. Cada linha de produto é constantemente atualizada, produzindo novas versões, até esgotarem suas possibilidades competitivas quando são então descontinuadas.

Cada fornecedor adota políticas de comercialização que influem diretamente na conformação dos produtos. Alguns tem o produto dimensionado para abranger o SGBD, linguagem de programação com editor de programas, e às vezes até o dicionário de dados. Outros modularizam tanto que até capacidades como otimização de programas ou facilidades de atualizações do B.D. "a quente" (on-line) são produtos à parte. Estas sutilezas entre muitas outras permitem os mais variados embustes nas apresentações de propostas para licitação de produtos. As comparações tornam-se impraticáveis. Propostas de SGBDs consagrados no mercado podem facilmente apresentar solução inferior a produtos bem mais simples, quando omitem algum módulo opcional que seja importante aos requerimentos do contratante.

Isto significa que para se fazer avaliação de propostas de SGBD é necessário ter ao menos uma noção de conformação dos produtos e políticas dos respectivos fornecedores. Obviamente este saber deve prescindir das informações disponibilizadas unicamente pelo fornecedor enquanto concorrente num processo de licitação.

2. JUSTIFICATIVA
Existe uma tendência de proliferação de processos de informatização no setor público, justificada pelas possibilidades tecnológicas e desejo de autonomia das instituições e apoiada em vários discursos da atualidade como descentralização, "downsizing" etc.

Este fato poderá resultar em várias bases de dados heterogêneas tanto quanto a plataforma de hardware, como aos SGBDs, Sistemas Operacionais, Redes etc.

Com isto aumenta a já indiscutível necessidade de uma administração de dados, em todos os aspectos. Não apenas no registro e gerenciamento do acervo de dados, considerados como recursos estratégicos para o processo de gestão, mas um completo mapeamento, representando o modelo conceitual dos dados da corporação, seu grau de compartilhamento, redundância, qualidade e disponibilidade.

Isto implica em uma perfeita gestão quanto à tecnologia empregada no tratamento do dado. Em um processo de licitação para aquisição de produtos em uma instalação, o SGBD deve ter um peso preponderante, uma vez que todo investimento em desenvolvimento será capitalizado nos dados que resultarem no Banco de Dados.

Com o tempo, mudam-se métodos, versões de programas, processos, versões de SGBD, e os dados permanecerão crescendo, crescendo... A decisão de se trocar um SGBD, com certeza, terá um impacto muito maior do que qualquer outro elemento da instalação.

A conversão será cara, dolorosa, traumatizante. Portanto, toda cautela e conhecimento deverão ser empregados para a aquisição deste recurso. E este conhecimento necessário transcende às teorias e aos conceitos acadêmicos. Refiro-me ao conhecimento sobre a conformação dos produtos de SGBD e demais ferramentas integradas, disponíveis e em evolução no mercado. Não apenas referente a produtos que já estejam sendo utilizados pela organização, mas através de ações de planejamento e conhecimento do mercado promover mudança de comportamento na relação com os fornecedores destas ferramentas, de uma atitude passiva em que os esforços são dispendidos nas atualizações de versões, para atitudes mais ativas.

3. PROPOSIÇÃO

O objeto desta proposta é o estabelecimento de um processo de avaliação contínua de produtos de SGBD e demais recursos a ele integrados (Linguagens, Dicionário de Dados, CASE etc) disponíveis no mercado.

Este processo tem como objetivo obter e administrar informações sobre estes produtos, mantendo-as atualizadas para subsidiar os técnicos da organização que delas necessitem.

Muitos são os meios de se obter estas informações, mas para uma estruturação imediata deste modelo proponho um conjunto de sub-processos que serão definidos a seguir:

. Participação em eventos promovidos pelo fornecedor.
. Visitas Técnicas.
. Promoção de eventos.
. Programação periódica de "Benchmark".
. Pesquisa de publicações sobre "Benchmark".

A maioria destes processos tem características essencialmente operacionais para merecerem detalhamento neste artigo, portanto vamos nos ater apenas a algumas considerações a respeito da PROGRAMAÇÃO PERIÓDICA DE BENCHMARK. Esta é a parte mais difícil e também mais importante deste trabalho. Consiste em se estabelecer um mecanismo de avaliação sistemática de produtos.

Considero relevante fazer uma reflexão sobre alguns princípios que devem ser levados em conta neste contexto.

a) A avaliação não é vinculada e nenhum processo de compra. Isto tem os seguintes desdobramentos:

. O interesse do fornecedor existe, porém há pouca disposição de investimento em esforço e custo.
. Se for muito freqüente, desestimula o fornecedor. Se muito raro, perde atualidade. Talvez um período entre seis a doze meses, ou apenas quando houver mudança substancial de versão sejam bons critérios.
. Este processo tem que se manter sempre isolado de qualquer processo de licitação.

b) Deverá haver um compromisso ético com o fornecedor, de modo que a pontuação atribuída seja restrita ao uso na empresa e ao fornecedor do produto avaliado.

Desdobramentos:

. O fornecedor certamente vai questionar os itens pontuados abaixo de suas expectativas (nunca os pontuados acima). Isto poderá ser explorado positivamente por ambas as partes:

- O fornecedor poderá esclarecer melhor sobre os fatos, com argumentação passível de ser aceita sem risco de implicações jurídicas que permeiam as avaliações entre concorrentes.
-
- As discussões propiciarão feedback aos fornecedores, apontando pontos fortes e fracos de seus produtos sem alarde.

c) As avaliações serão feitas basicamente sobre aspectos técnicos. Isto significa que os resultados, sozinhos, não podem ser empregados como orientação para aquisição. Uma avaliação para aquisição terá de levar em conta também os requisitos do contratante, que são particulares, bem como o conjunto de produtos proposto pelo fornecedor por ocasião da licitação.

d) Este processo demanda disponibilidade de equipamentos e software específicos em conformidade com os produtos e serem avaliados.

Isto deverá ser objeto de discussão interna, se haverá ambiente laboratorial disponível ou se o fornecedor deverá providenciar tudo, ou uma mistura disto.

CONCLUSÃO

A existência deste acervo de informações, além do amadurecimento cultural na área de Banco de Dados, irá apoiar as atividades de licitação para SGBD e derivados tanto para a CELEPAR como para outras organizações do Estado em caráter de consultoria. Permite também uma constante avaliação crítica sobre as soluções adotadas em processos de informatização, inferências quanto a possibilidades diferenciadas para aplicação de tecnologias de tratamento de dados e pode até promover uma maior emancipação de fornecedores, na atualização do nosso parque de software.

Como é uma atividade com resultados a médio e longo prazo, mas com pequeno investimento, convém iniciar as medidas necessárias o quanto antes. Algumas ações neste sentido têm sido empreendidas pela área de Administração de Dados atualmente em fase de estruturação na GPT.

Se você tem interesse neste assunto, entre em contato conosco pelo ramal 241. Há muito a se falar, ouvir e fazer a respeito.