Metodologia para implementação de projetos de data warehouse

1. Introdução

Com o advento da computação, surgiram os primeiros programas para transformação de dados em informação. Junto vieram alguns complicadores, como: tempo de processamento, volume de dados, formas de acesso, meios físicos etc. As tecnologias evoluíram, porém o conceito permanece. Transformar dados em informação é a principal razão da existência da informática.

Os primeiros programas comerciais foram criados para auxiliar os processos organizacionais, tais como folhas de pagamento, contabilização e controles de estoque. Apesar da evolução das tecnologias estes aplicativos ainda são tão essenciais quanto os sistemas especialistas.

Com o passar do tempo muitos aplicativos foram desenvolvidos para automatizar os processos. Como conseqüência o volume de dados crescia ainda mais, dificultando a obtenção de informações para análise e tomada de decisão.

Na década de 80 surgiram os primeiros sistemas comerciais para auxílio à tomada de decisão. Tinham como objetivo resumir os dados essências e organizá-los. O crescente volume e a complexidade para obter os dados, de diferentes fontes, tornaram estes aplicativos ineficientes à medida que não disponibilizavam as informações necessárias para tomada de decisão em tempo hábil. Observa-se que não importa ter apenas os dados se a informação não está disponibilizada em momentos decisivos.

Surgiram na década seguinte os sistemas integrados (ERP) que agilizaram processos, otimizando recursos. Como promessa destes mega-sistemas, todas as informações necessárias seriam obtidas a partir deles. Porém, outros sistemas especialistas ainda permaneciam por serem estratégicos e mais eficientes. Permanecia também o problema da disponibilização da informação no momento certo. A concorrência de transações da operação das empresas com busca de informações em altos volumes de dados começaram a comprometer o ambiente. Ficando bem caracterizado a que se destinavam os sistemas integrados: otimizar as transações das empresas.

A evolução das tecnologias de busca de informação para tomada de decisão e a necessidade de organizar os dados motivaram o estudo científico do problema. Um data warehouse é um conjunto de dados baseado em assuntos, integrado, não volátil e variável em relação ao tempo, de apoio às decisões.

A integração dos dados, associadas a técnicas e ferramentas, no data warehouse proporcionam um ambiente de dados organizados por assuntos para obtenção de informações para tomada de decisão. Imagina-se então que o DW seja um ambiente onde todas as informações, para tomada de decisão, são obtidas.

Construir um DW está longe de ser uma tarefa fácil. As técnicas e as ferramentas não são suficientes para garantir o êxito na construção. É necessária uma metodologia capaz de levar à sua implementação. A tentativa de aplicar ferramentas e técnicas de desenvolvimento inadequadas conduz apenas a desperdício e confusão. Por exemplo, no mundo CASE predomina a análise baseada em requisitos. Tentar aplicar as ferramentas e técnicas CASE ao mundo do Data warehouse não é aconselhável e vice-versa. No ciclo de vida do DW predominam os dados e a informação resultante da organização da base de dados.

Mesmo considerando seu desenvolvimento em partes (Data Marts) deve-se ter a visão do todo para garantir a integração das informações. O armazém de dados (DW) não pode ser apenas um repositório, onde os dados de diferentes aplicações estão na mesma base de dados centralizada. Os dados devem estar organizados para refletir a visão do negócio de forma integrada.

A metodologia descrita a seguir tem como objetivo uma orientação para desenvolvimento evolutivo do data warehouse. Dividida em fases bem caracterizadas pelo agrupamento das principais técnicas relacionadas. Ela descreve a finalidade de cada fase, identificando os pontos críticos e descrevendo sucintamente as principais técnicas.

As fases do projeto de implementação do data warehouse, por assunto, são: levantamento de dados, modelagem de dados, extração de dados, modelagem multidimensional, análise de resultados, visões pré-definidas e segurança da informação. Além da descrição das fases do projeto também são abordadas neste trabalho as tecnologias relacionadas ao data warehouse, a infra-estrutura necessária e administração do data warehouse.

Numa definição singular, para este trabalho, o data warehouse é considerado como: o repositório de dados para tomada de decisão. 

2. Tecnologias

Em parte o data warehouse é a evolução de algumas tecnologias. Outras que surgiram em paralelo ao conceito de DW também evoluíram e possuem grandes benefícios se estiverem integradas. Também existe um grupo de tecnologias mais recente que foram influenciadas pela deficiência ou amadurecimento do conceito. A seguir são definidas algumas das técnicas e ferramentas relacionadas com o data warehouse.

Os Sistemas de Informações Gerenciais (SIGs) foram uma das primeiras tentativas de criação de um ambiente único de informações para tomada de decisão. Eles foram desenvolvidos para disponibilizar relatórios que atendessem ao corpo gerencial das organizações. Porém, estes sistemas ainda não utilizavam técnicas de organização de dados específicas que suportassem um ambiente com crescimento escalar.

Como evolução dos SIGs os Executive Information Systems (EIS) foram desenvolvidos para melhorar a interface com os executivos e solucionar alguns problemas de performance. Por meio dos EIS o analista executivo pode localizar problemas com precisão e detectar tendências que são de vital importância para a gerência. Estes sistemas também eram suportados pela tecnologia OLAP.

A tecnologia OLAP (On-Line Analytical Process) constitui um sistema de armazenamento de dados agregados. Determinadas informações são obtidas a partir de dados pré-calculados disponíveis para consulta direta, sem a necessidade da pesquisa dos dados elementares e consolidação em tempo de execução, otimizando assim o processo de consulta de dados. Estes sistemas também são conhecidos como multidimensionais ou cubos, por permitirem a consulta de informações por múltiplas visões.

O armazém de dados (DW), em si, é suportado por um Sistema Gerenciador de Banco de Dados (SGBD), onde os dados extraídos dos sistemas transacionais são armazenados. O DW também utiliza a tecnologia OLAP para permitir as consultas analíticas On-Line.

É importante contextualizar algumas tecnologias que são influenciadas ou dependentes do DW para preparação de um ambiente que suporte de forma eficaz tais tecnologias.

Atualmente os EISs, associados com o data warehouse, podem ser considerados como sistemas de BI (Business Intelligence). Outras tecnologias como Data Mining também influenciam o BI, na descoberta de conhecimento.

Obter informação de uma grande base de informações (DW) pode se tornar uma tarefa difícil, mesmo que organizada por assuntos. Explorar as informações, por meio de ferramentas analíticas, pode não ser eficaz quando não se tem a certeza do que se está procurando. A tecnologia de Data Mining, com seus algoritmos e técnicas pode ser facilitada se existir uma fonte de dados organizada. Em uma empresa que deseja analisar o conteúdo da massa de dados criada por suas atividades, um processo de unificação precisa ser efetuado de forma a possibilitar o acesso de um indivíduo (analista) às múltiplas faces desta informação. Para que o data mining seja realizado, é necessário o acesso a uma massa de dados limpa, consistente e unificada em sua linguagem e lógica. Certamente que analistas vêm realizando data mining há muitos anos, utilizando ferramentas simples e bancos de dados separados, porém a construção de um data warehouse em muito facilita o processo de mineração de dados e de decisão.

CRM é totalmente dependente de um local centralizado de dados detalhados sobre clientes, seus comportamentos e suas preferências, incluindo detalhes específicos sobre privacidade de dados: o data warehouse.

Analisar as informações contidas no data warehouse, com crescente volume de dados, pode não ser eficiente com relatórios, books, gráficos etc. São muitas informações a serem analisadas. Algumas corporações estão adotando o Balanced Scorecard (BSC) como uma metodologia de gestão, onde são definidos indicadores de performance. Para estes indicadores são definidas metas e ações dentro da organização. Sistemas de BSC disponíveis no mercado têm maior eficiência se integrados ao data warehouse, caso contrário terão que buscar os dados para os indicadores diretamente nos sistemas transacionais.

Outro sistema relacionado ao BSC é o de Performance Management (PM), também conhecido como Business (BPM), Corporate (CPM) ou Enterprise Performance Management (EPM), que definem as metas dos indicadores. Estes sistemas, muitas vezes, utilizam o histórico dos indicadores como fonte para cálculo das metas.

Fica evidente assim que a construção do data warehouse deve levar em consideração como as informações serão utilizadas e integradas a outros sistemas e processos das instituições.

A metodologia de implementação de data warehouse, por assuntos, é descrita neste trabalho pelas fases de:

     - Definição da infra-estrutura;

     - Levantamento de dados;

     - Modelagem de dados;

     - Extração de dados;

     - Modelagem multidimensional;

     - Análise de resultados;

     - Visões pré-definidas;

     - Segurança da informação;

     - Administração.

3. Infra-estrutura

A infra-estrutura deverá suportar o ambiente projetado, com alto crescimento de dados, consultas complexas e não previstas (ad-hoc), diversidade de integração, diferentes tipos de tecnologias etc. O produto final do DW serão os dados, organizados e de fácil entendimento.

As ferramentas a serem utilizadas para a construção do data warehouse sejam, talvez, uma das menores preocupações que o arquiteto tenha. Integrar os sistemas, organizar os dados e disponibilizar as informações serão preocupações constantes. Desta forma, não importa muito qual o fornecedor ou marca devemos escolher, porém algumas características devem ser levadas em consideração.

Como dito anteriormente, a principal ferramenta de um data warehouse é o Banco de dados (SGBD), onde os dados extraídos dos sistemas transacionais ficarão armazenados. Ele deverá suportar: grandes volumes de dados, alta performance para carga de dados e consulta de informações, flexibilidade para alteração de estruturas, fácil administração e operação, baixo custo por usuário, integração com diferentes plataformas e sistemas, etc. Devem-se evitar utilizar características que dificultem a migração para outra plataforma. Em longo prazo, por questões de custo, pode ser necessária uma mudança de plataforma. Com tanta integração e a utilização do DW por toda organização o custo de licença de uso, por usuário, deve ser considerado desde o início como um fator crítico. Sendo os dados o mais importante, a estrutura de organização dos dados deve ser muito bem conhecida, documentada e de fácil acesso.

Para suportar consultas complexas e não previstas (ad-hoc) é necessário que tanto dados detalhados quanto totalizadores, fórmulas e conjuntos de dados possam ser consultados com o menor tempo de resposta possível. A infra-estrutura do data warehouse deve possuir uma ferramenta que suporte este tipo de consulta. As ferramentas OLAP possuem tais características, simplificando assim o trabalho de agregação e visualização das informações.

Os conceitos de OLAP incluem a noção ou idéia de múltiplas dimensões hierárquicas e podem ser usados por qualquer um para que se pense mais claramente a respeito do mundo, seja o mundo material da escala atômica à escala galáctica, o mundo econômico dos micros agentes à macro economias, ou o mundo social dos relacionamentos interpessoais aos internacionais. Em outras palavras, mesmo sem qualquer tipo de linguagem formal, é útil apenas sermos capazes de pensar em termos de um mundo multidimensional e com múltiplos níveis, independentes da sua posição na vida.

Outras linguagens formais, incluindo Data Definition Language (DDL), Data Manipulation Language (DML), Data Representation Language (DRL) e seus analisadores associados (e compiladores opcionais), poderia ser usada para qualquer modelagem descritiva, seja ela transacional ou de suporte à tomada de decisão. Em outras palavras, a associação de OLAP com suporte à tomada de decisão é mais uma função das características físicas de otimização dos produtos OLAP do que quaisquer características inerentes das construções de linguagem do OLAP.

As camadas de produto do OLAP normalmente residem em cima dos bancos de dados relacionais e geram SQL como saída da combinação. O armazenamento e o acesso aos dados são tratados pelo banco de dados.

Produtos OLAP completos, que precisam incluir um compilador e métodos de armazenamento e acesso, são otimizados para acesso a dados e cálculos rápidos, sendo usados para a modelagem descritiva de dados, derivada de sistemas de suporte à tomada de decisão (DSS – Decision Support Systems). A fronteira entre linguagens e produtos OLAP não é demarcada com clareza.

Resumidamente, as ferramentas OLAP fazem parte da infra-estrutura do Data Warehouse para consolidação de dados (agregação), aplicação de regras de negócio, cálculos (fórmulas) e disponibilizar a visão multidimensional.

Para obter os dados do ambiente operacional para o data warehouse, podem ser utilizadas várias linguagens, formas de acesso, conectores de dados e meios físicos diferentes (discos, fitas, rede etc). À primeira vista, quando os dados são movidos do ambiente herdado para o ambiente do data warehouse, parece que nada além de simples extrações de dados de um local para o próximo está ocorrendo. Em virtude dessa enganosa simplicidade, muitas empresas começaram a construir seus data warehouses manualmente. O programador olha para a movimentação de dados do antigo ambiente operacional para o novo data warehouse e declara: "Eu posso fazer isso!" Munido de lápis e formulário de codificação, nos três primeiros minutos do projeto e desenvolvimento do data warehouse, o programador ansiosamente mergulha na criação do código.

Contudo, primeiras impressões podem ser muito enganadoras. O que em um primeiro momento parece ser nada mais do que a movimentação de dados de um local para outro transforma-se, rapidamente, em uma grande e complexa tarefa – muito maior e mais complexa do que o programador negociou.

Como veremos adiante, em detalhes, no tópico de extração de dados, são necessárias algumas técnicas para esta tarefa. É verdade que, por meio de programação, a extração de dados possa ser feita. Sendo assim a extração de dados é uma das camadas da arquitetura do data warehouse. O fato da extração de dados poder ser executada por programação não significa que seja a mais eficiente. O alto volume de dados, a diversidade de tecnologias envolvidas e a complexidade de transformações podem dificultar a manutenção dos extratores e o tempo de desenvolvimento comprometido.

Para atender a esta camada algumas empresas fornecedoras de software desenvolveram ferramentas de ETL (Extract Transform and Load), facilitando em muito a integração e operacionalização. Considerando que a fase de extração pode consumir cerca de 70% do tempo de desenvolvimento do projeto. Abrir mão de uma ferramenta de ETL pode ser um grande risco para o projeto e comprometê-lo. Investir numa ferramenta, que garanta a integração e atenda aos requisitos da extração de dados, é no mínimo aconselhável. Além disso, usualmente os fornecedores não cobram por conectores ou pontos de integração e sim como um pacote, portanto investir mais nestas ferramentas não irá aumentar os custos à medida que o data warehouse se expandir.

Para que a arquitetura do data warehouse esteja completa é necessário uma última camada. A consulta, análise e visualização das informações compõem esta camada. Apesar dos bancos de dados possuírem formas de acesso e as ferramentas OLAP visões multidimensionais, é necessário que os usuários possam acessar as informações de forma integrada ao seu ambiente de trabalho. Como requisito mínimo para a arquitetura do data warehouse deve-se considerar uma ferramenta que acesse os dados armazenados e de forma exploratória possam analisar os dados. Outra forma de acesso, de forma orientada, são os portais de informação, que são constituídos por visões pré-definidas, consultas e relatórios pré-formatados.

Nas quatro camadas descritas acima (armazenamento, extração, consolidação e análise) devemos considerar o alto volume de dados, múltiplos acessos simultâneos e alta disponibilidade. Esta preocupação garantirá a escalabilidade do ambiente do data warehouse.

Outro fator muito importante está na flexibilidade que o ambiente deve possuir para atender as constantes mudanças de visão do negócio. Uma empresa que opera com apenas um produto pode passar a comercializar outros, assim como uma empresa pode se tornar uma grande organização composta por diferentes unidades de negócio. Não é necessário que estas mudanças estejam previstas no data warehouse, porém a implementação delas não pode ser inviabilizada pela arquitetura utilizada.

Outra importante diferença entre os ambientes operacionais e de data warehouse são os padrões de utilização de hardware que ocorrem em cada ambiente. No processamento operacional há picos e platôs no processamento, mas há uma constante de utilização elevada e estável. No DW há uma utilização binária, ou seja, totalmente utilizado ou simplesmente não está. Esta diferença fundamental consiste em mais uma razão para o fato de que tentar combinar os dois ambientes na mesma máquina e ao mesmo tempo não funciona. Você pode otimizar sua máquina para o processamento operacional ou pode otimizar sua máquina para o processamento do data warehouse, mas não é possível ter ambas as situações ao mesmo tempo e no mesmo equipamento.

Esta característica de utilização determina que o ambiente deve ser completamente separado do operacional, sendo assim, todos os equipamentos devem ser separados, sem nenhum tipo de compartilhamento. Isto nos leva a crer que a utilização de rede também terá algum impacto e deve ser levada em consideração na arquitetura. O armazenamento de dados em discos externos também não deve ser compartilhado.

Considerando que os dados são históricos e não voláteis no data warehouse, podemos chegar à conclusão que as contingências podem ser reduzidas, ou seja, sem redundância de disco por exemplo. Porém, a disponibilidade do DW para tomada de decisão tende a aumentar e correr o risco de não ter a informação em tempo hábil não é compatível com este ambiente.

4. Metodologia
 

4.1. Levantamento

Sendo o data warehouse um grande repositório de dados e possuindo como origem os dados dos sistemas transacionais, podemos concluir que a principal análise deve ser feita com base no dados e não nas funções e requisitos. O sistema clássico é baseado em requisitos. Para desenvolver sistemas, primeiro é necessário entender as necessidades. Depois disso, vêm às fases de projeto e desenvolvimento. O ciclo do DW é o inverso. No DW começa pelos dados. Uma vez que os dados estejam sob controle, eles são integrados e, em seguida, testados para que se verifiquem quais distorções há neles, se houver alguma. Então, é feita a codificação de programas para os dados. Os resultados dos programas são analisados e, finalmente, os requisitos do sistema são compreendidos.

Analisar as bases de dados de grandes corporações pode não ser uma tarefa eficiente, pois nem todas possuem documentação e nem mesmo seguem os padrões de normalização de dados. Sendo assim, vasculhar as bases de dados dos sistemas transacionais sem um direcionamento prévio exigirá um esforço grande dos arquitetos do data warehouse.

A principal abordagem para construção do DW é pela implementação de Data Marts, que são assuntos específicos das áreas das empresas. Os Data Marts têm sua origem na construção de cubos, pela utilização da tecnologia OLAP. Esta abordagem é considerada por alguns autores como ineficiente por não considerar a integração com outras bases de dados dentro do data warehouse. Outra característica dos Data Marts, a ser considerada, é a implementação em partes para se chegar ao todo (Bottom-Up).

Mesmo considerando a construção do DW por partes, alguns Data Marts podem ser muito complexos. Os Data Marts podem ter como origem mais de uma base de dados e cada uma com dezenas ou centenas de tabelas. Como orientação para o trabalho de levantamento de dados outras fontes devem ser analisadas.

Analisando as principais questões, referentes ao assunto, pode-se observar que existirá a carência por algum tipo de informação específica ou que a informação atual não é confiável, conflitante com dados de outra área da empresa ou fora do tempo para tomada de decisão. Desta forma são identificados problemas analíticos que não são solucionados pelos sistemas transacionais, como exemplo a análise de comportamento dos clientes ao longo do tempo. Caso o sistema transacional tente solucionar este tipo de questão ele pode se tornar ineficaz para as transações ou gerar a informação fora do tempo.

O direcionamento para as principais questões pode ser dado pelos gestores e executivos da organização, desta forma é possível traçar um alinhamento com a visão estratégica da empresa. A equipe coordenadora do Data Warehouse deve ter acesso ao plano estratégico da empresa, bem como ter o pleno entendimento da visão da empresa.

Numa análise mais ampla devem-se revisar os processos das áreas relacionadas com o assunto, onde são observadas as regras de negócio. Estas regras podem dar origem às transformações na fase de extração de dados. Em geral as transformações podem ocorrer por questões técnicas, mudanças de formatos ou uma visão de negócio. As transformações por visão de negócio acontecem em geral por adaptação dos processos das empresas aos sistemas, normalmente em casos de implantação de ERPs.

Outra fonte que pode auxiliar nesta fase de levantamento de dados são relatórios gerenciais, que muitas vezes são improvisados em planilhas eletrônicas a partir da coleta de dados de várias fontes. É comum encontrar nestes relatórios os principais indicadores monetários e físicos (quantitativos).

A análise das bases de dados dos sistemas transacionais pode ser iniciada pela pesquisa das tabelas com maior volume de dados. Estas tabelas normalmente são referentes a eventos ou fatos que ocorrem com freqüência, indicados por campos de data ou período. Comumente estas tabelas são definidas como ordens, itens, detalhamento etc. Os atributos destas tabelas são compostos, em grande parte, por chaves estrangeiras (foreign key) e indicadores. Os indicadores são dados quantitativos, monetários, taxas e medidas. As tabelas relacionadas com a tabela de eventos (ou fatos) podem dar origem às dimensões, que são as diferentes visões que se poderá ter do assunto.

Após a análise das bases de dados, dos relatórios e reuniões de levantamento deve ser produzida uma especificação com a definição do assunto, os objetivos da análise do assunto, as principais questões, a definição das regras de negócio, os indicadores, as múltiplas visões do assunto, o mapeamento dos dados das bases de origem e a periodicidade para extração dos dados.

O mapeamento dos dados deve ser bastante detalhado para facilitar o trabalho na fase de extração de dados. Neste mapeamento de dados devem ser indicados as bases de dados, arquivos, tabelas, campos, atributos, formatos etc.

Esta especificação será utilizada durante todo o projeto do Data Mart como orientação para que os objetivos sejam atingidos. 

4.2. Modelagem

Identificados os dados que deverão ser extraídos dos sistemas transacionais pode-se iniciar a modelagem para armazenamento no data warehouse.

A modelagem para o DW tem grande influência das ferramentas OLAP que, por questões de performance e visualização das informações, dependem de um modelo estrela. Este modelo, de forma resumida apresenta os fatos ao centro e todas as dimensões relacionadas aos fatos. Existem algumas variações desse modelo como o modelo em cascata (snowflake), que para algumas tabelas de dimensões estarão relacionadas com outras tabelas. Estas tabelas relacionadas às dimensões darão origem, em grande parte, a níveis de consolidação da dimensão no modelo multidimensional, como será discutido mais adiante.

O modelo lógico para um Data Mart é bastante simples, com algumas restrições. O relacionamento dos fatos com as dimensões não poderão ter cardinalidade N para N, ou seja, um fato não pode estar relacionado com mais de um elemento de uma tabela de dimensão. Os elementos das tabelas de dimensão estarão relacionados com vários itens da tabela de fatos, caracterizando assim a necessidade de agregação.

A desnormalização de dados no data warehouse é aceita e em muitos casos indicada para solucionar problemas de performance e espaço em disco, combinando dados de várias tabelas do modelo de dados dos sistemas transacionais em uma tabela de fatos ou dimensão. É interessante observar que, no data warehouse, essas circunstâncias ocorrem regularmente em função de os dados serem baseados em parâmetros de tempo. Os dados do data warehouse sempre apresentam relevância em relação a um determinado momento, e unidades de tempo ocorrem com grande regularidade. Em um data warehouse, a criação de um array por mês, por exemplo, é algo muito natural. Outra importante técnica de projeto especialmente relevante para o ambiente de data warehouse consiste na introdução intencional de dados redundantes. Contudo, algumas ferramentas de mercado estão cada vez mais adaptadas aos conceitos de data warehouse. Tirando grande proveito do ambiente relacional, sem perder o conceito, para construir bases multidimensionais (OLAP) com maior eficiência. Sendo assim, não devemos abrir mão da desnormalização para tudo, mas sempre que necessário.

Um dos aspectos mais importante na modelagem é definir a granularidade dos dados. As bases de dados transacionais possuem muitos dados de controle das transações que talvez não sejam relevantes para tomada de decisão. A razão pela qual a granularidade é a principal questão de projeto consiste no fato de que ela afeta profundamente o volume de dados que residem no data warehouse e, ao mesmo tempo, afeta o tipo de consulta que pode ser atendida. O volume de dados contidos no data warehouse é balanceado de acordo com o nível de detalhe de uma consulta.

Outro paradigma a ser rompido em relação aos sistemas transacionais é referente à representação de acontecimentos passados. Os sistemas OLTP e data warehouse tratam o tempo de forma diferente. O melhor sistema OLTP é um status instantâneo dos negócios de uma organização, atualizado constantemente à medida que as transações são concretizadas. Os valores-chave do negócio devem mudar a cada minuto ou segundo. O status muda continuamente e os relacionamentos entre as entidades são alterados. No DW estes instantâneos serão armazenados e identificados com uma marca de tempo, onde poderemos observar as mudanças de comportamento, seja de clientes ou produtos.

Algumas dimensões no data warehouse devem ser observadas com mais atenção, pois possuem grande relevância para a integração dos dados. Quando importamos os fatos dos sistemas transacionais para o DW observamos sempre que possuem o atributo de tempo. Portanto, a dimensão de tempo terá grande importância para o modelo de dados do data warehouse. Outra característica importante é podermos definir atributos comuns para os fatos, através do tempo, como: feriados, acontecimento importante (externos ou internos da organização), dia da semana etc.

Fatos diferentes podem dar origem à outra dimensão que deve ser observada com atenção. A relação de fatos realizados com previstos ou calculados é o conceito de versão, que é representado usualmente nos data warehouses como uma dimensão de versão.

Mais recentemente, com a evolução dos conceitos de marketing, e mais especificamente do marketing de relacionamento, o cliente tem ganhado maior atenção dos analistas de data warehouse, com o intuito de atender as necessidades dos sistemas de CRM (Customer Relationship Management). Modelar os dados dos clientes de forma que seja possível observar as mudanças do mesmo, ao longo do tempo, é fundamental para atender a esta finalidade.

Diferentemente da modelagem de dados dos sistemas transacionais, com os modelos de entidade e relacionamento (MER), no data warehouse o modelo de dados físico se apresenta muito semelhante ao lógico, seguindo o conceito estrela e suas variações. Porém, a preocupação será no armazenamento, objetivando maior performance e menor custo de espaço para o armazenamento de dados.

Devemos ter maior atenção para as tabelas de fatos, pois noventa por cento dos dados de cada Data Mart serão armazenados nestas tabelas. As tabelas de fatos serão compostas por dois grupos de atributos chaves estrangeiras e indicadores. O dimensionamento correto dos tipos de dados das chaves das dimensões e dos indicadores determinará o espaço necessário para o armazenamento.

A granularidade das tabelas de fatos poderá ser reavaliada após alguns anos de dados armazenados. Na maior parte do tempo, há uma grande demanda por eficiência no armazenamento de dados e no acesso a eles bem como pela possibilidade de analisar dados em maior detalhe. (Em outras palavras, a organização quer fazer o gol e defender ao mesmo tempo!) Quando uma organização possui grandes quantidades de dados no data warehouse, faz sentido pensar em dois (ou mais) níveis de granularidade na parte detalhada do data warehouse. Deve ser observado que, efetuando este tipo de modelagem, alguma informação será perdida ao longo do tempo.

Outro aspecto a ser considerado no modelo físico é o particionamento dos dados. O particionamento permitirá o gerenciamento flexível dos dados e a distribuição de bases de dados por unidades de negócio de forma descentralizada.

Resumidamente o modelo de dados do data warehouse refletirá a organização dos fatos e dimensões na base de dados.

4.3. Extração de dados

O data warehouse é dependente dos sistemas transacionais internos ou externos das instituições. Os sistemas transacionais são a fonte de dados para o data warehouse, como a matéria-prima para a fabricação de um produto. Interligar estes ambientes tão heterogêneos, com: tecnologias diversificadas, diferentes bases de dados, formatos diferentes, conexões e distâncias; torna a fase de extração de dados a mais trabalhosa, consumindo cerca de 70% do tempo da equipe do data warehouse.

Quando a integração entre os sistemas transacionais e o DW não possui um suporte tecnológico ideal, é possível subdividir esta fase em: extração e importação dos dados. As transformações serão tratadas no momento da importação.

É possível extrair os dados dos sistemas transacionais no formato adequado para simples importação no data warehouse. Porém, esta pode não ser a estratégia mais adequada, pois as transformações possivelmente ficariam nos ambientes transacionais, tornando-os mais complexos. Outro fator é a manutenibilidade das regras de negócio que, desta forma, de nada agregará aos sistemas transacionais implementar as regras de transformação. Esta situação ainda poderá trazer problemas de performance para o ambiente transacional, com processos concorrentes entre extratores e transações ou processos operacionais.

Deve-se manter a integração entre estes ambientes a mais automática possível, evitando a manipulação de dados pelos usuários e reduzindo risco a falhas. As ferramentas de ETL (Extract Transform and Load) são de suma importância para a integração dos ambientes transacionais e o data warehouse.

Com base na especificação definida no levantamento de dados serão produzidas novas especificações de desenvolvimento: definição dos extratores e especificação das importações dos dados. Tendo estas especificações bem definidas é possível executá-las em paralelo.

As especificações dos extratores conterão a definição da seleção dos dados, critérios de seleção, formato de saída, objetos que devem ser criados, parâmetros da interface, script de teste e controles de erro.

A seleção dos dados e os critérios de seleção definirão quais os objetos, campos e tabelas, dos sistemas transacionais serão manipulados e qual a relação entre eles. Os critérios de seleção também poderão conter restrições fixas da seleção dos dados, que sejam exclusivamente referentes à complexidade de busca dos dados do sistema transacional específico, não sendo assim nenhuma transformação de dados.

O formato de saída basicamente define a ordem dos campos, largura de colunas e conversões elementares, tais como formato de data.

Os parâmetros da interface são os critérios de seleção enviados pelo processo principal de carga de dados que coordena as interfaces.

Os controles de erro são fundamentais para a integração com o ambiente do data warehouse, onde poderão ser monitoradas as falhas no processo para comunicação aos administradores dos sistemas.

O script de teste é a descrição de como a extração pode ser executada e qual o resultado esperado. Este teste permite a validação do processo independentemente da integração com o data warehouse.

Como produto das especificações de extração são produzidos alguns objetos, tais como: programas, arquivos, conectores etc. A especificação deverá conter também o local de armazenamento dos objetos.

Observa-se que as interfaces dos extratores devem ser flexíveis, permitindo assim a re-execução dos processos para correção de erros. Deve-se ter como objetivo primário na definição dos extratores que qualquer processo possa ser executado a qualquer tempo. Mesmo considerando que a definição da periodicidade de extração definida na especificação de levantamento de dados e alinhada com a necessidade da área de negócio, os extratores devem possuir a capacidade de serem executados a qualquer tempo para correção de problemas adversos.

Com a periodicidade definida, deve-se buscar o menor volume de dados possível dos sistemas transacionais. Outro importante problema diz respeito ao acesso eficiente aos dados dos sistemas existentes. Como pode o programa que varre os sistemas existentes saber se um arquivo já foi varrido anteriormente? Há uma enorme quantidade de dados no ambiente de sistemas existentes e a tentativa de efetuar varreduras completas toda vez que é feita uma varredura para o data warehouse é antieconômica e pouco realista. Há três tipos de carga que podem ser feitos do ambiente operacional para o data warehouse: o carregamento de dados históricos, o carregamento de dados de valor corrente no ambiente operacional e o carregamento de alterações do data warehouse a partir de alterações (atualizações) que tenham ocorrido no ambiente operacional desde a última atualização do data warehouse.

Para solucionar o problema do corte dos dados podem ser empregadas algumas técnicas: marcar de tempo, arquivo de log ou auditoria, arquivo delta, imagem anterior / posterior e alteração da aplicação do sistema transacional.

A performance de carga de dados estará relacionada diretamente com o volume de dados extraído do sistema transacional. Podem-se empregar técnicas de segmentação, principalmente dos fatos, para carregá-los em paralelo.

As especificações de importação de dados devem tratar de como os dados devem ser carregados no data warehouse. Este processo também contempla a coordenação dos sub-processos para carga de cada uma das interfaces das tabelas de dimensões e fatos. Esta especificação deve conter as definições do: mapeamento técnico dos dados da origem para as tabelas do data warehouse, as transformações de tipos de dados, as transformações de substituição de chaves, transformações das regras de negócio e verificação dos possíveis erros no processo de extração.

As interfaces com alto grau de acoplamento, ou seja, com tecnologias similares ao data warehouse, podem ser tratadas em apenas uma especificação.

Uma particularidade da extração dos dados é a conversão inicial dos dados dos sistemas transacionais para o data warehouse. Após o desenvolvimento dos extratores é possível iniciar a carga de dados para o data warehouse. Porém, vale avançar para as próximas fases do projeto até a análise de resultados, onde algumas validações podem ser executadas e possivelmente trará modificações para os extratores de dados. Por fim, após as modificações, os dados devem ser convertidos por períodos. Tentar trazer todos os dados de uma só vez não é recomendado, podendo causar grande impacto nos sistemas transacionais, que já estão em ambiente produtivo.

É comum verificarmos que, após a carga dos dados dos sistemas transacionais para o data warehouse, muitas informações não possuem o valor esperado. Após as primeiras cargas de dados, é necessário fazer uma análise criteriosa das informações. Muitos dados podem não estar qualificados, ou seja, os dados contidos nos sistemas transacionais não estão consistentes. Este problema de qualificação e análise dos dados é abordado com mais detalhes na fase de análise de resultados, onde o analista de suporte a decisão tem grande participação no processo.

4.4. Modelagem multidimensional

Após a carga de dados poderíamos considerar que o data warehouse está concluído. Porém, como todo sistema pressupõe a entrada, processamento e saída, devemos considerar a análise dos dados como saída primária do data warehouse.

O modelo de dados lógico e físico, descrito anteriormente, do data warehouse é constituído por uma visão multidimensional, em estrela. Porém, eles representam, respectivamente, uma visão de entendimento do negócio e como os dados estarão armazenados no DW. A modelagem multidimensional formará uma camada intermediária entre a base de dados e as ferramentas de consulta de dados, que serão definidas mais à frente.

Especificamente nesta fase será tratada a questão da utilização das ferramentas OLAP. Os principais conceitos da tecnologia OLAP são: visão multidimensional, agregação de dados, análise exploratória e cálculos. Os requisitos funcionais para OLAP possuem um formato central e periférico. Os requisitos centrais, raiz, necessários ou mínimos no lado lógico incluem suporte para múltiplas dimensões, hierarquias, fórmulas dimensionais e separação de estrutura de dados e representação. Fisicamente, o principal requisito é velocidade suficiente para oferecer suporte à análise ocasional. Qualquer linguagem ou produto que não aceite pelo menos esses requisitos não pode, com seriedade, ser classificado como oferecendo suporte a OLAP.

A característica de ser multidimensional, das ferramentas OLAP, permite que os assuntos (Data Marts) sejam analisados por diferentes visões (prismas, ângulos etc). Esta característica está intimamente ligada a análise exploratória que permite ao analista de suporte a decisão investigar os dados, adquirindo conhecimento, validando suposições, análise de tendências e confrontando diferentes aspectos do assunto, entre outras análises possíveis.

Se considerássemos uma base de dados ideal que, para qualquer consulta executada, o tempo de resposta fosse sempre imediato, uma das questões mais importantes tratadas pelas ferramentas OLAP não seria necessária. A agregação das informações, executada pelo processamento das ferramentas OLAP, disponibilizará imediatamente as informações, independente da complexidade da consulta. Se as agregações foram feitas por demanda deve ser de forma imperceptível para os analistas de suporte à decisão. De forma simplista as ferramentas OLAP devem calcular (agregar) todas as combinações e totais possíveis para que as informações sejam consultadas em tempo hábil para tomada de decisão, independente da quantidade de dados armazenada na base de dados do data warehouse.

Tecnicamente a fase de modelagem multidimensional é onde são desenvolvidos os cubos, definindo as visões multidimensionais nas ferramentas OLAP. Grande parte do trabalho, para esta fase, já foi executado na fase de modelagem, com a definição das tabelas de fatos e dimensões. Contudo, é necessário configurar a ferramenta OLAP para definir a origem dos dados para consolidação das informações. Algumas das regras de negócio, identificadas no levantamento de dados, estarão explicitadas por meio de fórmulas na estrutura dos cubos, como membros calculados.

Nesta interface entre a base de dados do data warehouse e a ferramenta OLAP é importante que ela seja flexível, permitindo a adaptação de novas regras de negócio do constante amadurecimento das organizações. Como importante recurso para comportar estas adequações os SGBDs visões (view), ou seja, consultas predefinidas que são armazenadas na estrutura do banco de dados, reduzindo assim o esforço para manutenção dos cubos.

Portanto, o modelo multidimensional deverá refletir as possíveis visões e responder a maioria das questões identificadas na fase de levantamento de dados. Permitindo assim que os analistas de suporte a decisão executem consultas analistas On-Line.

4.5. Análise de resultados

Esta fase pressupõe que as informações já estão disponíveis para análise. Não é necessário que todos os dados já tenham sido carregados para o data warehouse, mas uma parte significativa que permita a avaliação dos resultados. Neste ponto do projeto o analista de suporte a decisão tem a responsabilidade de validar as informações contidas no data warehouse. O analista deverá observar a conformidade das informações disponibilizadas com a especificação produzida na fase de levantamento de dados.

Este trabalho deverá ser o mais rigoroso possível, pois a partir das informações contidas no data warehouse e disponibilizadas elas serão usadas para a tomada de decisão. Uma informação errada pode causar mais prejuízos que a falta delas.

Neste ponto o analista de suporte a decisão, com o apoio do arquiteto do data warehouse, poderão identificar falhas no processo de extração. Também será possível qualificar as informações obtidas a partir das bases de dados dos sistemas transacionais, identificando campos que não foram preenchidos corretamente ao longo dos anos de produtividade desses sistemas. A visão macro das informações, disponibilizada pelas ferramentas OLAP, permitirá aos analistas descobrir fatos não identificáveis no ambiente transacional. Eventualmente estas análises servirão para definição de novas regras de negócios e requisitos para os sistemas transacionais, tais como a obrigatoriedade do preenchimento de determinados dados ou novas regras de integridade.

O trabalho da análise de resultados inicia um novo ciclo no desenvolvimento do Data Mart, obrigando ao arquiteto do data warehouse reavaliar os dados dos sistemas de origem, ajustar a especificação e passar pelas fases de modelagem, extração e modelagem multidimensional para que as informações sejam novamente analisados.

Garantir a confiabilidade das informações do data warehouse é uma tarefa constante, mesmo após a implementação do Data Mart. Fatos externos, adequações a legislação e mudanças organizacionais podem afetar de forma direta ou indiretamente o data warehouse. A confiabilidade das informações do data warehouse deve ser mantida realizado validações periódicas e ajustando os dados da base de dados constantemente. Caso as validações não ocorram com freqüência é comum acontecer dos usuários deixarem de consultar as informações, tomarem decisões baseadas em dados errados ou fazer com que os executivos percam a confiança nas informações de tal modo que se determine a descontinuidade do projeto todo.

O comprometimento dos executivos e analistas de suporte a decisão é fundamental para o sucesso do projeto, garantindo confiança nas informações e continuidade. 

4.6. Visões pré-definidas

Grande parte das informações já foi disponibilizada para os usuários de suporte a decisão, através da utilização das ferramentas OLAP. Porém nem todas as consultas devem ser feitas de forma exploratória, obrigando aos usuários a pesquisa desde o início.

Esta fase do projeto tratará da disponibilização de visões direcionadas e freqüentemente extraídas do DW, através de relatórios. Existem alguns grupos de relatórios que serão disponibilizados: relatórios gerenciais, consultas complexas, indicadores, consultas direcionadas etc.

Em muitos casos estes relatórios são disponibilizados por meio de portais de informação. Onde os gestores, que não dispõe de muito tempo para explorar as informações e em grande parte dependentes do trabalho dos analistas de suporte a decisão, poderão consultar as informações periodicamente e norteando sua equipe, de acordo com o alinhamento estratégico da organização.

Os relatórios gerenciais, agora obtendo os dados pelo data warehouse, com a garantia de que a informação estará disponível para tomada de decisão em tempo hábil, integrada a outras visões da empresa e a versão única da verdade. A unicidade da informação garantirá que nenhum relatório conflitante seja apresentado aos gestores.

Num ambiente integrado algumas análises podem ser feitas de forma orientada, onde os analistas de suporte a decisão e os gestores podem “navegar” entre relatórios obtendo o detalhe necessário para suas conclusões e observação de comportamento de vendas, clientes, produtos etc.

Mesmo num ambiente proporcionado pelas ferramentas OLAP algumas consultas serão muito complexas para que os analistas de suporte a decisão possam desenvolver seus relatórios sem o auxílio do arquiteto do data warehouse. Estes relatórios necessitam de profissionais tecnicamente preparados para utilização de funções específicas das linguagens de consulta de dados das ferramentas OLAP ou da utilização de ferramentas de Data Mining.

Algumas das principais questões, documentadas na especificação do levantamento de dados, poderão ser respondidas com a criação de visões pré-definidas, já que as informações estão disponíveis.

Os indicadores da empresa poderão estar disponibilizados como visões predefinidas e possivelmente alinhados com conceitos de gestão organizacionais, como Balanced Scorecard (BSC).

A camada de visões pré-definidas poderá obter as informações diretamente da base de dados do data warehouse ou pela configuração de consultas aos cubos.

4.7. Segurança da informação

Grande parte das informações disponibilizadas no data warehouse refletem as visões táticas e estratégicas das organizações, portanto nem todos poderão ter acesso a estas informações. Esta fase deve tratar de quem pode, quem deve, como pode e por onde as informações devem ser consultadas.

A política de segurança para o ambiente do data warehouse deve ser muito flexível, permitindo que pessoas com perfis macro ou mais específicos possam acessar as informações de sua responsabilidade ou interesse empresarial.

Cada um ao seu nível de decisão ou de análise deve acessar a informação, porém existirão alguns grupos específicos da organização que deverão ter acesso quase irrestrito ao data warehouse, são as áreas de: planejamento estratégico, controladoria e inteligência de marketing.

Deve-se ter muito cuidado ao disponibilizar canais externos, tais como Extranets, para consultas ao data warehouse. Estes canais, se existirem, devem ser monitorados constantemente e com altos requisitos de segurança.

Outra questão crucial para este ambiente, em relação à segurança, é garantir que as informações contidas no data warehouse caiam em mãos erradas, os concorrentes. É necessário uma política de segurança rígida para a equipe de administração e operação do data warehouse.

Por outro lado, de que adiantaria todo o esforço para construir o data warehouse se as informações ficarem confinadas no repositório de dados. Alguns analistas podem desenvolver uma visão analítica, crítica e consciente, com o acesso as informações do data warehouse. 

5. Administração

Na maior parte do tempo a administração do data warehouse estará voltada para o banco de dados, verificando a integridade, a performance e o volume de dados. Também se deve ter atenção especial para os cubos, das ferramentas OLAP. Os critérios de agregação dos dados devem ser re-analisadas de acordo com a utilização das informações pelos usuários, assim como os índices do banco de dados.

É possível utilizar a infra-estrutura do próprio data warehouse para criação de Data Marts para monitoramento do ambiente, tais como: análise de espaço em disco, tempo de carga de dados, análise de acessos dos usuários.

Nas organizações em que a informação para tomada de decisão for muito crítica para o negócio, deve-se ter grande atenção aos extratores de dados. Os processos de extração de dados devem ser monitorados continuamente, com implementação de controles de falhas. Caso ocorra algum erro nesses processos o administrador do data warehouse deve ser comunicado imediatamente para analisar o problema.

Em alguns casos, novas regras negócio podem ter sido implementadas nos sistemas transacionais, sem a comunicação para aos administradores do data warehouse. Nestes casos o administrador deverá recorrer aos analistas de suporte à decisão para reavaliação das transformações dos extratores de dados.

Todas as falhas ocorridas no ambiente do data warehouse devem ser comunicadas aos responsáveis para que nenhum informação errada seja utilizada para tomada de decisão. É válido manter uma política de comunicação para avaliação constante da equipe de administração do data warehouse.

É fundamental que o ambiente do data warehouse seja altamente padronizado, com políticas rígidas de verificação. Como o ambiente do DW tende a ser complexo, com muitas regras de negócio, objetos, ferramentas e conectores com sistemas heterogêneos, a padronização do ambiente permitirá que a manutenção seja mais eficiente.

Em alguns casos manter os padrões de desenvolvimento podem ser mais interessante que obter a melhor performance possível. Utilizar linguagens de pouco conhecimento da equipe, ou de profissionais do mercado, pode não ser uma estratégia segura para a administração do data warehouse.

O data warehouse deve possuir ao menos dois ambientes similares, um de produção e outro de desenvolvimento. Para implementações críticas é aconselhável um ambiente de validação dos desenvolvimentos e de performance. Os ambientes de validação e desenvolvimento devem ter características próximas ao de produção pois tratarão do mesmo volume de dados. Outra vantagem de possuir os ambientes similares é criar uma contingência para o ambiente de produção.

A “janela” de extração de dados dos sistemas transacionais deve ter atenção especial dos administradores. Eles devem observar a concorrência com os ambientes transacionais e garantindo que as informações sejam disponibilizadas no prazo previsto e com a periodicidade correta.

Outro aspecto importante da administração do data warehouse é a continuidade do projeto, verificando se as regras de negócio estão em constante validação pelos usuários e a documentação do projeto atualizada. A questão da revisão das regras de negócio é tão importante que outra característica dos data warehouses é possuir uma base de metadados.

Alguns papéis devem estar bem definidos para a equipe de manutenção do data warehouse. Alguns deles são: arquiteto de soluções, administrador de dados, analista de suporte a decisão, analista de negócio, administrador de banco de dados, desenvolvedores, patrocinadores do projeto. Talvez o arquiteto de soluções seja a peça fundamental para a construção e manutenção do data warehouse. Ele deverá ter a visão do todo, desde integrar os diferentes sistemas transacionais ao data warehouse a disponibilização dos dados para os analistas. O administrador de dados (AD) deve ser responsável pelos metadados, pela integração das bases de dados e organização dos dados. O AD deverá ter profundo conhecimento da modelagem, tanto lógica, física e multidimensional. O analista de suporte a decisão deverá garantir continuamente que as informações estão corretas, comunicando as mudanças das regras de negócio e a visão do negócio. Seu alinhamento com a equipe de administração do data warehouse deve ser o mais fiel possível. O administrador de banco de dados (DBA) poderá ser o mesmo do ambiente transacional, contanto que tenha disponibilidade para solucionar os problemas emergenciais e entenda perfeitamente as características dos dois ambientes. Os desenvolvedores serão responsáveis pela codificação dos extratores de dados, exigindo deles conhecimento de diferentes tecnologias para integração com sistemas transacionais, e pela programação dos relatórios e visões pré-definidas. Os patrocinadores do projeto deverão definir as prioridades, acompanhar o projeto e garantir a continuidade.

6. Conclusão

Fundamentalmente as técnicas foram essenciais para a definição da metodologia. A experiência da aplicação da metodologia também foi essencial para que ela realmente se mostrasse eficiente na implementação e na expansão de projetos de data warehouse.

Fica evidente também que os dados e, conseqüentemente, as informações devem ser armazenados e organizados de forma independente das ferramentas utilizadas. Sendo assim a metodologia se enquadra a este requisito básico do conceito de data warehouse.

Uma das questões polêmicas do conceito de data warehouse é por se tratar de um projeto utópico, pois criar uma fonte de dados única para tomada de decisão pode não se aplicar às condições da realidade. As instituições estão em constante mudança, com novas implementações de sistemas transacionais, mudanças de plataforma, métodos de trabalho diferentes e mudanças de estrutura organizacional. Porém os benefícios da implementação do data warehouse são, comprovadamente pelo mercado, inegáveis. Diz-se que um projeto de data warehouse não tem fim, pois ele está em constante evolução para acompanhar as mudanças.

Contudo a metodologia ainda requer um aperfeiçoamento, com definições mais rígidas das documentações e especificações. 

7. Lista de abreviações e siglas

BI – Business Intelligence

BSC – Balanced Scorecard

BMP – Business Performance Management

CASE – Computer Aided Sotware Engineering

CLDS – Ciclo de vida baseado em dados

CPM – Corporate Performance Management

CRM – Customer Relationshio Management

DBA – Data Base Administrator

DDL – Data Definition Language

DML – Data Manipulation Language

DRL – Data Representation Language

DSS – Decision Support Systems

EIS – Executive Information System

EPM – Enterprise Performance Management

ERP – Enterprise Resource Planning

ETL – Extract Transform and Load

MER – Modelo Entidade-Relacionamento

OLAP – On-Line Analytical Processing

OLTP – On-Line Transaction Processing

SDLC – Ciclo de vida do desenvolvimento de sistemas clássicos

SGBD – Sistema Gerenciador de Bando de Dados

SQL – Structured Query Language