Cubos Icebergue: Materialização Optimizada de Vistas 3.1 Processamento Eficiente de Estruturas Multidimensionais
3.3. Processamento de Cubos Icebergue
As tecnologias de Data Warehousing e de OLAP requerem, nos dias de hoje, vistas sumarizadas e orientadas ao negócio para uma análise rápida e eficiente no processo de tomada de decisões. Por isso, os dados são modelados multidimensionalmente. Num modelo multidimensional, perspectivas de análise como “produto” ou “clientes” descrevem assuntos de interesse; as métricas, como “total de vendas” é o alvo da análise, em termos de dimensões de negócio. As estruturas multidimensionais generalizam o operador SQL group-by [Gray et al., 1996] para processar esses operadores em todas as combinações das dimensões. Cada
group-by representa um subcubo que envolve um conjunto de agregações agrupadas pelas
mesmas dimensões. Dado um conjunto de dimensões i onde cada dimensão tem uma cardinalidade de Li, o número potencial de subcubos para o cubo de dados será de (Li + 1)i. O
86
processamento introduzido pelo operador do cubo group-by podem ser enormes, pois para i atributos base especificados, 2i group-by são calculados. Quando o operador é usado para responder a um conjunto de iceberg querys, é gerado um iceberg cube [Beyer & Ramakrishnan, 1999]. A formulação destas estruturas deve ser considerada com uma estratégia dinâmica de selecção de subcubos, a complementar com algoritmos, já discutidos, que identificam os group-by de forma estática. Dada uma função agregada, o processamento do cubo passa por calcular todos os subcubos que respondam a estas condições. Os algoritmos optimizados de selecção de subcubos exploram as vantagens do processamento paralelo de cada subcubo mais especifico através dum outro menos especifico (Top-down) ou vice-versa (Bottom-up). Os iceberg cubes foram propostos para processar apenas as agregações interessantes do ponto de vista das necessidades do negócio. Na prática, os utilizadores podem especificar condições icebergue nos valores agregados dos subcubos. Somente aqueles que satisfazem a condição, são seleccionados. Portanto, as iceberg conditions podem ser monótonas ou anti-monótonas [Beyer & Ramakrishnan, 1999]. Um constrangimento monótono indica: se um subcubo de agregações violar a condição icebergue, todos os subcubos dependentes a violarão. Este recurso é amplamente usado para filtrar (pruning) um
iceberg cube. Um iceberg cube contêm apenas as células agregadas do cubo de dados que
satisfazem uma determinada condição, conhecidas como a “ponta do icebergue”.
Figura 33. Importância da selecção de subcubos no processo de extracção de conhecimento
Este tipo de estruturas têm como objectivo identificar e calcular apenas os valores que serão os mais adequados para serem materializados e que farão sentido para as análises de suporte à decisão, ou seja, a condição agregada qualifica quais as agregações do cubo que são mais relevantes para uma determinada consulta e, portanto, as que devem ser materializadas.
87
Essencialmente, as interrogações efectuadas num iceberg cube partem da análise de um atributo (ou conjunto de atributos) de forma a obterem-se as agregações que estão acima de um determinado limiar ou patamar de suporte, face a determinadas condições (expressas em SQL por having count ou having sum, por exemplo). Estas interrogações são conhecidas como iceberg querys, porque conseguem lidar apenas com os valores que estão acima de um determinado limiar (a “ponta do icebergue”) face ao volume total do cubo de dados (o “icebergue”), utilizando menos espaço de armazenamento e, significativamente, menos tempo de processamento sobre os dados. Análogo ao problema de selecção das vistas consideradas mais adequadas para serem materializadas, a selecção dos group-by que, de facto, satisfazem a condição icebergue estabelecida são também matéria de investigação na literatura, estando na base do denominado problema de selecção de iceberg cubes. Nesse contexto, o problema é manifestado pela determinação de qual o conjunto de subcubos que satisfazem uma determinada condição agregada (logo, os mais benéficos) de modo a serem integrados numa vista a materializar. Tendo em conta o contexto de dados esparsos, a condição icebergue estabelece que uma partição deve ter pelo menos n tuplos, sendo n designado como o suporte mínimo da partição ou patamar. Veja-se o seguinte exemplo: para um cubo de três dimensões
(A, B, C) o problema pode ser representado pela seguinte interrogação:
Figura 34. Criação do iceberg cube a partir de uma iceberg query
A instrução compute cube especifica o pré-processamento do cubo iceberg_cube com as dimensões (A, B, C) e a função de agregação COUNT(*). Os tuplos de entrada encontram-se na relação R. A cláusula cube by especifica quais as agregações (group-by) que são para ser formadas por cada um dos subconjuntos das dimensões em análise. Repare que min_sup representa o patamar de suporte mínimo da partição para que uma determinada agregação possa satisfazer a condição icebergue (neste caso, sendo uma contagem, refere-se ao número
88
mínimo de tuplos que um group-by tem de ter). O resultado do processamento da interrogação pode ser usado para responder a qualquer query numa combinação de atributos das dimensões
(A, B, C) que requeiram que COUNT(*) seja ≥ que o patamar de satisfação mínimo
estabelecido. Se fosse para processar o cubo de dados na sua totalidade, cada group-by iria corresponder a um cubóide no lattice de dependências. No entanto, a condição especificada na cláusula having é conhecida como a condição icebergue, que opera, neste caso, sobre a função
COUNT(*). Note-se que o cubo icebergue processado na figura 34 pode ser usado para
responder às agregações em qualquer combinação das dimensões distinguidas pela instrução
having count(*) ≥ v onde v ≥ min_sup. Em vez do COUNT(*) podem ser usadas também
outras funções mais complexas, como por exemplo a média. Na realidade, se fosse suprimida a cláusula having do exemplo anterior, iria acabar-se por processar o cubo na sua totalidade. Naturalmente, que se o patamar definido para o cubo icebergue for 1, o resultado vai ser o cálculo integral do cubo. A tabelas 2(a) demonstra uma relação simples dos atributos de quatro dimensões de diferentes cardinalidades. Suponha-se que o patamar para satisfazer a
iceberg query indica que a combinação dos valores dos atributos devem aparecer pelo menos
em três tuplos (min_sup ≥ 3). O resultado do algoritmo icebergue é mostrado na tabela 2(b).
Tabela 3. (a) representa o cubo de dados simples e (b) o cubo icebergue derivado do primeiro
Uma abordagem “ingénua” para processar um iceberg cube seria, em primeiro lugar, calcular o subcubo na totalidade e só depois, filtrar as células que não satisfazem a condição icebergue. Contudo, esta acção continua ser proibitivamente cara devido às limitações de
89
espaço de armazenamento. Por outro lado, as abordagens optimizadas defendem que, para processar o iceberg cube directamente, não é necessário que os cubóides estejam previamente calculados (este tipo de algoritmos serão evidenciados na secção seguinte deste trabalho). Ao utilizar-se estas estruturas será possível reduzir a carga de processamento daquelas que são consideradas as agregações triviais de uma estrutura multidimensional. Recorde-se que um algoritmo de iceberg cubing é motivado pelo facto do processamento integral de uma estrutura multidimensional requer espaço de armazenamento, que é exponencial ao número de dimensões. Para um cubo de grandes dimensões, muitas vezes não é suportável o pré- processamento integral. Por isso, é necessário traçar um método para avaliar quais os fragmentos do cubo que serão mais úteis processar. Um número considerável de autores propõe várias abordagens para processar apenas um subconjunto dos group-by ao invés do cubo na sua totalidade [Baralis et al., 1997], [Shukla et al., 1998], [Gupta, H. et al., 1997], [Harinarayan et al., 1996]. Estes algoritmos permitem escolher os group-by a processar baseados em diferentes factores tais como o espaço de armazenamento disponível, o tamanho esperado dos group-by, o beneficio previsto do pré-processamento das agregações, etc. Contudo, essas soluções dependem de um critério de selecção de subcubos estático. Uma das inovações dos cubos icebergue é exactamente permitir que os utilizadores definam o critério dinamicamente (de acordo com os seus interesses analíticos) durante o processamento das agregações.