Requisitos Essenciais em Sistemas Data Warehouse

Para melhor correlacionar os requisitos do problema (especificação) com os requisitos da solução adotada (arquitetura), os seguintes conceitos devem ser investigados durante a modelagem dos requisitos de um data warehouse:

(i) Representar fatos e suas propriedades. Fatos são elementos centrais em data warehouses. Analisar os requisitos do usuário implica identificar fatos e suas propriedades por intermédio das métricas escondidas na demanda do usuário. Por exemplo, a especificação de uma aplicação data warehouse para análise da situação de hipotecas habitacionais deve considerar o fato “pagamento das prestações”, e suas propriedades discretas “montante pago” e “saldo devedor”, como requisitos essenciais do sistema. Um outro requisito determinante do potencial de suporte à decisão do data warehouse é o grau de aditividade dessas métricas, i.e., a capacidade da métrica de ser “operada” (somada, contada, extraída a média) numa dada perspectiva de análise do tomador de decisão;

Capítulo 4 – Metodologia para Definição de Requisitos em Sistemas Data Warehouse

(ii) Distinguir e conectar dimensões a fatos. Dimensões fornecem a chave para a análise estratégica das métricas de fato armazenadas no repositório de dados. Sua identificação é essencial para a correta modelagem do sistema. Muitas vezes, a análise de uma simples declaração do usuário dá margem à descoberta de um número de dimensões candidatas. Por exemplo, a sentença “analisar as vendas mensais de itens individuais em estoque por loja” claramente explicita as dimensões tempo, produto e loja, as quais estão conectadas ao fato

montante de vendas. Perceber as dimensões e fatos (e sua correta associação) inseridas nos

requisitos do usuário é um aspecto crítico na análise dos requisitos de sistemas data warehouse, bem como um ponto com forte tendência a erros de concepção.

(iii) Garantia de Agregabilidade (Summarizability). Um requisito não-funcional essencial a aplicações data warehouse é a garantia de corretude dos resultados agregados ao longo do esquema multidimensional, em qualquer combinação de dimensões e fatos associados. Essa característica é conhecida como Summarizability (LENZ e SHOSHANI, 1997), aqui referenciada como Agregabilidade. O problema está em que nem todas as possíveis agregações de métricas ao longo de dimensões fazem sentido no contexto de uma certa aplicação. Por exemplo, dada uma dimensão “mutuários”, somar valores ou extrair médias dos saldos devedores de suas hipotecas são operações bastante plausíveis; no contexto da dimensão “tempo”, porém, a soma desses valores de saldo parece sem sentido, o que não invalida que se extraiam médias e outras análises estatísticas a partir dessa métrica. Muito embora a existência de problemas de agregabilidade seja um fato, falhas desnecessárias na construção do esquema dimensional podem ser evitadas expressando-se claramente os requisitos que restringem a agregação de dados na aplicação, bem como estabelecendo-se uma conformidade entre fatos e dimensões comuns ao mesmo tempo a Data Marts e o modelo dimensional global do Data Warehouse. No contexto dessa metodologia, adotamos a abordagem de HÜSEMANN et al. (2000) para evidenciar os níveis de agregabilidade entre métricas e dimensões (vide Seção 3.6.4). A tabela contendo os níveis de classificação encontra-se descrita no corpo do artefato Especificação de Requisitos Multidimensionais (Apêndice 1);

Capítulo 4 – Metodologia para Definição de Requisitos em Sistemas Data Warehouse

(iv) Representar a integração com fontes provedoras. Em ambientes data warehouse, o dado é coletado a partir de diferentes fontes internas e/ou externas à organização. Essa atividade envolve, além de importar dados de todo o tipo de base, considerações sobre requisitos informais oriundos diretamente do negócio, que requerem a definição de ações específicas para sua inclusão no repositório (ex. importar dados de um banco de dados pessoal, geração de interfaces para alimentação de dados manual pelo cliente, leitura de planilhas e relatórios gerenciais). Entender os requisitos e procedimentos relacionados com esse processo de integração é fundamental para o projeto de um sistema data warehouse de qualidade, bem como para a segurança de que a aplicação definida não apresenta resultados inconsistentes;

(v) Acompanhamento rápido de mudanças em requisitos do usuário. Um problema comum em sistemas convencionais, acompanhar as mudanças em requisitos assume uma importância exponencial no desenvolvimento de aplicações data warehouse. Até mesmo mudanças ditas “insignificantes” podem comprometer o ciclo de alimentação do repositório e a validade dos dados derivados, afetando o potencial de suporte à decisão da aplicação. Por exemplo, uma mudança na lei de composição de um atributo de dimensão para substituir “brancos” por “zeros”, mesmo que impactando apenas os dígitos mais à esquerda e preservando o conteúdo do campo no repositório, pode implicar a revisão de todo o processo de transformação e carga dos dados;

(vi) Documentação de alta qualidade. Diferentemente de sistemas convencionais, cuja documentação muitas vezes precisa ser “concebida do zero”, data warehouses sempre envolvem desenvolvedores com o exame de documentação operacional pré-existente para definir os meios e processos para integração dos dados operacionais. A não ser por raras exceções, tal documentação legada não possui a qualidade necessária, transformando a extração dos requisitos técnicos em uma atividade custosa e propensa a falhas na interpretação (ex. a falta de manutenção da documentação pode levar à definição de regras de extração baseadas em campos cujo formato não reflete a realidade, ou que simplesmente foram exportados para outra tabela). Dessa forma, uma documentação de

Capítulo 4 – Metodologia para Definição de Requisitos em Sistemas Data Warehouse

alto nível, projetada especialmente para acomodar requisitos de suporte à decisão e disseminada entre ambos os lados (fornecedor e consumidor) provê uma interface genérica para a extração desses requisitos.