Definindo a Arquitetura Multidimensional

Definido o escopo geral da aplicação, as preocupações voltaram-se para a arquitetura a ser adotada. Técnicos e clientes compartilhavam as idéias de KIMBALL (1998) de que um esquema multidimensional “estrela” com tabelas desnormalizadas proveria a eficiência necessária para as consultas à base corporativa. Contudo, todos concordavam que alguma forma de investigação era requerida para comprovar esse e outros aspectos relevantes para a definição da arquitetura do data warehouse, como indexação e interligação de tabelas.

Considerando-se o escopo estabelecido e as premissas de qualidade básicas definidas na Especificação de Requisitos Não-Funcionais para o projeto, o framework DW-ENF foi usado para investigar uma arquitetura ideal para o sistema (essa etapa teve uma forte participação do DBA Projetista). Vamos reportar essa análise do ponto de vista dos requisitos de qualidade que foram fundamentais para a definição da arquitetura multidimensional12_{, a saber: (r}

1) o tempo de resposta das consultas não deve exceder 1

minuto; (r2) o sistema deve fornecer sempre a informação mais atualizada possível; (r3) o

sistema deve permitir que os usuários naveguem entre fatos de assuntos diferentes.

Pode-se perceber a partir do framework DW-ENF que esses requisitos de qualidade estão diretamente relacionados com a performance e o potencial multidimensional esperado do sistema SAFE. Para determinar a arquitetura ótima, partiu-se então para investigar os seguintes aspectos: o tempo de resposta das consultas, a pontualidade das cargas de dados e os métodos de acesso a serem implementados. Utilizando os catálogos de tipo e métodos do framework, construímos o Gráfico de Interdependência de Softgoals (SIG) ilustrado na Figura 21.

12 _{Por restrições de espaço, atemo-nos a esse grupo de requisitos para exemplificar a contribuição do}

framework para a identificação de uma arquitetura multidimensional ideal, muito embora a investigação

prática tenha envolvido outras variantes como características relacionais do banco de dados Oracle,

Capítulo 5 – Estudo de Caso

Capítulo 5 – Estudo de Caso

Para geração do SIG, foi utilizada a ferramenta OME3 (OME3, 2000), cuja notação difere um pouco da notação original de CHUNG et al. (2000) descrita no Capítulo 2. Os símbolos especiais “W–” e “W+” indicam respectivamente que o softgoal foi “fracamente rejeitado” ou “fracamente aceito”. OME3 também utiliza as palavras HELP, MAKE, HURT e BREAK em substituição aos sinais “+”,“++”, “–” e “– –” respectivamente. As demais regras da notação original permanecem válidas.

A partir do requisito r1, assinalamos o requisito não-funcional “performance no tempo”

como crítico para o sistema, indicado pelo sinal “!” ao lado do softgoal Tempo.Consultas. Um dado importante nessa análise foi a aquisição de um servidor de dados robusto, com capacidade para armazenamento e acesso rápido a terabytes de dados, o que tornou o requisito adjacente “performance em disco” uma preocupação menor no desenvolvimento do sistema.

Ainda analisando a performance no tempo, tempo de resposta prevalece sobre tempo de processamento, pois a freqüência de carga supera o tempo para processamento dos dados em significância, o que pode ser inferido a partir do requisito r2 e das facilidades do

servidor de dados mencionado anteriormente. A criticidade do tempo de resposta é evidenciada pelo sinal “!” ao lado do softgoal que o representa.

A investigação do aspecto Tempo concentrou-se então no fator “tempo de resposta”. O SIG da Figura 21 demonstra que, para otimizar o tempo de resposta, o projetista do banco pode optar por fazer uso de quaisquer dos seguintes métodos: técnicas de Join e Indexação (O’NEIL e GRAEFE, 1995), paralelismo de processadores e/ou desnormalização. Porém, a ferramenta Microstrategy, escolhida para implementar o ambiente OLAP, controla e otimiza automaticamente join (junções) de dados. Além disso, há a expectativa de que o warehouse do projeto SAFE armazene algumas centenas de milhões de registros, o que elimina a necessidade de investimentos em processamento paralelo, mais indicado para quantidades superiores a gigabytes. Com base na argumentação anterior, o projetista pode rejeitar, respectivamente, os softgoals Técnicas de Join e Paralelismo.

Capítulo 5 – Estudo de Caso

A investigação continuou, então, com uma análise das técnicas de indexação. A Interface Web de SAFE possibilita aos usuários finais executarem tanto consultas complexas quanto outras de médio porte. Consultas complexas freqüentemente efetuam joins entre múltiplas tabelas, o que é enfatizado pela necessidade de executar operações drill across (Capítulo 4), implícita no requisito r3. Consultas de médio porte, ao contrário, retornam uma quantidade

pequena de dados a partir de poucas tabelas-fato. Os dois tipos de consulta requerem abordagens de indexação diferenciadas, indicadas pela decomposição do softgoal Indexação.Consultas em Indexação.ConsultasRegulares e Indexação.Consultas Complexas. Consultas regulares são melhor suportadas por índices do tipo B-Tree (O’NEIL e QUASS, 1997), enquanto consultas complexas requerem índices mais sofisticados como os do tipo Bitmap (CHAUDHURI e DAYAL, 1997). Ambas as técnicas foram escolhidas, então, por satisfazerem os requisitos de performance das consultas.

Por outro lado, o requisito r3 sugere fortemente a adoção de uma derivação do esquema

“estrela” conhecida como constelação (Capítulo 3), onde esquemas “estrela” individuais estão hierarquicamente interligados por dimensões comuns. As interligações entre tabelas- fato provêem a habilidade requerida pelo cliente de navegar entre assuntos diferentes, o que é indicado na Figura 21 pela interdependência fortemente positiva entre os softgoals (métodos) Constelação e Drill Across. Desnormalização, por sua vez, torna-se um softgoal elegível, na medida em que é a base para a implementação de esquemas “estrela”. Apesar de desnormalização ferir o aspecto “performance em disco”, este não é um ponto crítico do sistema, conforme visto anteriormente. Ademais, a outra escolha lógica, “Flocos de Neve”, não pode ser aceita pois fere o softgoal crítico “tempo de resposta”.

Numa última análise, o projetista é confrontado com a necessidade de processamento pontual das cargas de dados. O requisito r2 sugere a adoção de uma abordagem diária para a

carga. Essa opção, contudo, não pode ser satisfeita devido à falta de uma “janela de tempo” no ambiente de produção do SERPRO larga o suficiente para realizar a extração de dados de todas as fontes. De fato, a menor periodicidade com que os dados podem ser carregados, dentro dos limites do ambiente, é mensal. Dessa forma, uma periodicidade mensal foi aceita

Capítulo 5 – Estudo de Caso

e a restrição acordada junto ao cliente. O resultado da investigação validou as concepções iniciais de técnicos e partes interessadas sobre o esquema em “estrela” e proporcionou uma visão mais bem definida dos demais aspectos (indexação e integração de tabelas). A conclusão então alcançada foi a adoção de uma arquitetura baseada em um esquema “constelação” para facilitar operações drill-across e a implementação de tabelas desnormalizadas, índices Bitmap e B-Tree para satisfazer os requisitos de performance da aplicação. Essas conclusões foram interadas à Especificação dos Requisitos Multidimensionais, na seção 1.1 “Escopo e Diretrizes Gerais”.