Vanskelighetsgrad II: Substansiell kompleksitet

Segundo INMON (1997), a maioria das organizações vem construindo e mantendo ambientes de “Data Warehouse” centralizado. Algumas das razões para que isso aconteça: (i) os dados armazenados no “Data Warehouse” são integrados através da organização. Existe apenas um lugar na organização (matriz, sede ou unidade organizacional de coordenação, liderança ou gestão) em que uma visão integrada é necessária; (ii) um único repositório de dados se justifica, dado o volume de dados existente no “Data Warehouse” e; (iii) ainda que os dados pudessem ser integrados, caso estivessem espalhados por diversos locais da organização, eles seriam de difícil acesso.

A arquitetura de “Data Warehouse” centralizado (single-subject warehouse), conforme proposto por THREATTE (2001) (ver figura 18), é considerada uma abordagem clássica. As pesquisas vêm indicando que essa opção é a mais apropriada e viável arquitetura para um sistema de segurança pública. Apesar disso, algumas considerações devem ser feitas em relação às características da arquitetura do “Data Warehouse” centralizado. Primeiro, a de que os usuários finais recuperam os dados dos sistemas que estão integrados, utilizando software especificamente projetado para extrair e apresentar os dados armazenados no “Data Warehouse”. Esse aspecto revela uma consideração significativa sobre a arquitetura, em relação às aplicações-cliente que permitirão o acesso aos dados pelos usuários: novas

aplicações devem ser adquiridas ou desenvolvidas para atender as necessidades de acessos aos dados pelos usuários. Isso inclui telas para realização de consultas e geração de relatórios pré- definidos ou ad-hoc. Essas aplicações, se adquiridas, podem causar substancial impacto no custo de implementação do ambiente, dado que, para cada cliente poderá ser necessária a aquisição de uma licença. A alternativa do desenvolvimento de aplicações específicas, ainda que podendo impactar menos os custos, pode gerar impacto no tempo de implementação da arquitetura, em decorrência do tempo necessário para o desenvolvimento.

FIGURA 18–“DATA WAREHOUSE”CENTRALIZADO

Fonte: Elaborado pelo autor.

2.4.5.1.1. Considerações sobre software cliente

Se a opção pela aquisição prevalecer, podem ser utilizados pacotes de software comerciais (COTS – “Commercial Off-the-Shelf”), geradores de consultas e relatórios. Essa abordagem, apesar de propiciar poder e flexibilidade na definição de uma variedade de consultas e relatórios, pode trazer o inconveniente de ter os códigos e regras de negócio operando no computador cliente, bem como de necessitar algum tipo de mudança para que seja propagada para cada estação existente na organização, requerendo ainda pessoal especializado em processamento de dados para criar as condições de flexibilidade necessárias ao pacote cliente, adequando-o à realidade da organização. Pode ainda se tornar uma alternativa cara pela provável necessidade, já considerada, de aquisição de licenças cliente para todos os usuários.

Uma solução cada vez mais utilizada pelas organizações é a geração de aplicações em “Tecnologia Web”, as quais, ao nível do cliente, utilizam o “Navegador Web” e uma tecnologia de “motor de busca” em base de dados, opção que tem demonstrado ser de rápido desenvolvimento, fácil uso e baixo custo. Essa abordagem, entretanto, algumas vezes pode sacrificar a flexibilidade na definição de consultas e relatórios. Tal solução, geralmente, utiliza o “Navegador Web” na estação cliente, e as regras de negócio e os procedimentos são executados no servidor, o que permite a manutenção centralizada de códigos e procedimentos que freqüentemente possam sofrer mudanças.

2.4.5.1.2. Atualização de dados

Uma segunda característica crítica da arquitetura de “Data Warehouse” é que os sistemas operacionais das bases de dados (sistemas legados) não são acessados diretamente. Uma cópia dos dados do sistema operacional é mantida separada, no “Data Warehouse”. São as seguintes as considerações mais significativas relativas ao acesso aos dados e transferência desses dados: (i) os dados armazenados no “Data Warehouse” não são correntes (atuais). Os dados serão atuais somente ao tempo da última atualização feita a partir de cada sistema operacional; (ii) os dados no “Data Warehouse”, nesse caso, podem não ser completos. Nem todos os dados de um sistema operacional podem ser adequadamente mapeados para um modelo de base de dados comum. Isto resulta em que alguns elementos de dados se tornem "orfãos" no Data Warehouse, ou armazenados de uma forma obscura tal que a relevância deles não fique pronta ou facilmente aparente.

2.4.5.1.3. Principais vantagens da arquitetura de “Data Warehouse” centralizado

Um modelo integrado de dados bem definido, com uma cópia completa de dados "limpos" é disponibilizada para todos os usuários para fins de consultas e obtenção de relatórios. O tempo de resposta de acesso aos dados e a disponibilidade do sistema é previsível e provê um alto nível de serviços aos usuários. Uma variedade de software comerciais (COTS) de geração de consultas e relatórios está disponível para uso pelos clientes, aumentando o poder e flexibilidade na geração de consultas e relatórios.

2.4.5.1.4. Principais desvantagens da arquitetura centralizada

Os dados representam um "instantâneo" (“snapshot” = fotografia de câmera instantânea), imagem do tempo presente, “aqui e agora”, e são válidos somente até o

momento da sua ultima atualização pelo último sistema integrado. A arquitetura não provê mecanismos para que os dados sejam transferidos de um sistema para outro, a fim de reduzir ou eliminar entradas duplicadas de dados. Essa arquitetura pode conduzir a aplicações-cliente, ou de geração de consultas e relatórios, extremamente “pesadas” e que poderão gerar sobrecarga significativa na rede de dados e no servidor do “Data Warehouse”.

2.4.6. Expansão da Arquitetura de “Data Warehouse Centralizado” – O