Uma visão simplista do dado para um aplicação multidimensional é que existe um grande espaço Cartesiano limitado para todas as dimensões da aplicação. Alguns podem chamar isto como um espaço de dados, enfatizando que é um conceito lógico.

Dado multidimensional é sempre esparso: célula de dados não distribuídas igualmente através dos espaços multidimensionais. Um conjunto de célula de dados é agrupado num espaço e num período de tempo quando um evento de negócio ocorre.

Encontramos as seguintes definições para denso e esparso no Dicionário Aurélio:

• Denso : Compacto, cerrado, espesso

• Esparso: Solto, disperso.

Para melhor ilustrar esta questão mostramos a seguir um exemplo de dados esparsos.

Modelo Multidimensional (Bidimensional)

Os dados no exemplo acima não deveriam ser representados pelo modelo multidimensional, porque não há inter-relacionamento entre eles, o que ocasionou a esparsividade dos dados, ou seja, a maioria das células não foram preenchidas e os dados se tornaram esparsos.

Denso é quando uma base de dados multidimensional apresenta uma percentagem relativamente alta de possíveis combinações das dimensões membros contendo dados com valores.

Esparso acontece quando uma pequena porção (arbitrariamente, menor que 0,1%) de célula de dados atualizados (com valores) estão ocupando uma estrutura multidimensional.

Uma das conseqüências de dados esparsos é a chamada "explosão" de armazenamento do banco de dados, ou seja, um imenso banco de dados multidimensional contendo poucos dados armazenados.

Desenvolvedores dos produtos multidimen-sionais conhecem a questão dos dados esparsos em ambiente multidimensional, e para isto adotam uma variedade de estratégias técnicas de como relacionar os dados esparsos mais os dados agrupados. Além de escolher entre duas principais maneiras de apresentar os dados multidimensionais para  o usuário, eles também determinam como o dado é processado e, em particular, quantos cálculos são permitidos. 

Estruturas de dados multidimensional podem apresentar seus dados para uma aplicação usando dois tipos de cubos: Hipercubos e Multicubos. Apesar de utilizar o termo cubo, que dá a impressão de trabalhar com apenas três dimensões, qualquer uma das duas arquiteturas pode trabalhar com diversas dimensões.

HIPERCUBOS

No Hipercubo, como mostra a ilustração a seguir, todos os dados aparecem logicamente como um simples cubo. Todas as múltiplas partes representadas pelo hipercubo têm idêntica dimensionalidade, isto é, cada pedaço é de igual tamanho.

No Hipercubo acima há um único cubo onde os dados são armazenados, cujas medidas são quantidade e valor, e as dimensões produtos, região e mês, proporcionando através de cada célula uma visão das vendas (valor, quantidade) por: produtos, mês e região; por produto, mês e vendedor. 

A vantagem desta abordagem é o rápido tempo de resposta, independente do número de dimensões envolvidas na consulta e a sua grande simplicidade para o usuário final. A desvantagem é de uma necessidade maior de espaço para armazenamento em disco e a maior possibilidade de ocorrência dos dados esparsos.

Nos hipercubos um dos recursos para garantir um excelente desempenho é manter os dados em “arrays” na memória. Isso acaba limitando sua capacidade a alguns gigabytes de dados.

O uso do termo hipercubo pode ser aplicado igualmente para ambos banco de dados multidimensionais e relacionais OLAP.

Aparentemente, hipercubo não é como o dado é usualmente armazenado. Existem estratégias técnicas para gerenciar eficientemente a esparsialidade. Essbase (desde a versão 4.1) é um exemplo de um produto que mais se aproxima do hipercubo. Comshare adotou a abordagem de hipercubos desde o seu System W de 1981, e tem trabalhado com Arbor  no uso do Essbase.

Muitos produtos também usam hipercubos particularmente para aplicações ROLAP que usam uma tabela Fato “Star Schema”: a qual comporta-se como um hipercubo. Na prática, entretanto, a maioria das ferramentas de consulta multidimensional acessam um hipercubo por vez. Alguns exemplos de produtos com hipercubo: Essbase (e, entretanto, Analyzer e Comshare Decision), Executive Viewer (MicroStrategy), CFO Vision (SAS), BI/Analyze (Hummingbird) e PowerPlay (Cognos).

Existe uma variante do hipercubo que é chamada de hipercubo "fringed". É um hipercubo denso, com um número pequeno de dimensões, com analise de dimensões adicional, podendo ser acrescidas para partes da estrutura. Os produtos que têm esta estrutura são Hyperion Enterprise, CLIME (PricewaterhouceCoopers) e Comshare FDC.     

MULTICUBOS

Uma outra forma de apresentar a estrutura de dados multidimensionais é chamada de estrutura multicubo. Na abordagem de multicubos, dado é segmentado em um conjunto de cubos pequenos (subcubos), cada qual é composto de um subconjunto das dimensões avaliadas, como mostrado na ilustração a seguir:

Na estrutura em Multicubos, os dados são armazenados em vários cubos, sendo que, em cada cubo, são agrupadas as dimensões que mais se relacionam. Por exemplo, nos dados das vendas podemos colocar em um cubo as dimensões produto, região e mês, em outro as dimensões produto, vendedor e região, e em outro as dimensões produto, vendedor e mês. 

As vantagens desta arquitetura são a menor utilização de espaço de armazenamento em disco, por diminuir o problema dos dados esparsos, e o melhor desempenho em consultas em um único cubo. A desvantagem ocorre quando é necessário realizar-se uma consulta em mais de um cubo. Neste caso, é exigido tanto do software como do hardware e há uma queda no desempenho proporcionando respostas um pouco mais demoradas, dependendo da consulta realizada.

Em produtos multicubos  as aplicações desenham segmentos do banco de dados como um conjunto de estruturas multidimensionais, cada qual composta de um subconjunto total do número de dimensões do banco de dados. Chamamos esta pequena estrutura de subcubos, o nome usado pelos vários produtos incluem:

•  variáveis (Express (Oracle), Pilot, Acumate (Kenan)),
  

• estruturas (Holos (Seagate)),
  

• cubos (TM1 (Applix) e Microsoft OLAP Services) e 
  

• indicadores (Media (Speedware)).
   

Fornecedores que utilizam a abordagem de multicubos enfatizam sua grande versatilidade, potencialidade e eficiência (particularmente com dados esparsos). O exemplo original de abordagem de multicubo é o produto Express (Oracle), mas outros produtos também usam modernas variantes desta abordagem.

Produtos ROLAP podem também ser considerados multicubos caso eles possam manipular tabelas fatos, cada uma com dimensionalidade diferente. Muitas empresas com produtos ROLAP têm esta capacidade, tal como Informix, Computer Associates (CA) e MicroStrategy.

É possível identificar dois tipos principais de multicubos:

• Multicubo em bloco (usado pela Business Object, Gentia, Holos (Seagate), Microsoft Analysis Services e iTM1 (Applix))
  

• Multicubo em séries (como usado pela Acumate (Kenan), Express (Oracle), Media (Speedware) e Pilot.

Media (Speedware) e Pilot).

Multicubos em bloco usam dimensões ortogonais, assim eles não têm dimensões especiais para o nível de dado. Um cubo pode consistir de um número de dimensões definidas, e ambas, medidas e tempo, são tratadas como dimensões ordinárias. Multicubos em séries tratam cada variável como um cubo em separado (muitas vezes um histórico), contendo conjuntos próprios de outras dimensões. Entretanto, estas distinções não são sólidas e firmes, e as várias implementações de multicubos não necessariamente declinam claramente para um ou outro tipo.

Os multicubos em blocos são mais flexíveis, porque eles não fazem suposição sobre dimensões e permitem que múltiplas medidas sejam manipuladas simultaneamente, mas são, muitas vezes, menos convenientes para relatórios, porque a visão multidimensional pode usualmente somente olhar para um bloco por vez (um exemplo disto pode ser visto na implementação do TM1 no APB-1 benchmark do OLAP Council). Os multicubos em séries não têm esta restrição. Microsoft Analysis Services, GentiaDB e especialmente Holos conseguem contornar o problema mostrando "join" de cubos, apresentando uma visão simples do cubo de dados que é processado e armazenado fisicamente em múltiplos cubos. Holos permite visão de visões, não aplicado a todas as partes do produto. Essbbase e suas partições transparentes é uma das menos sofisticadas versões deste conceito. 

Multicubos em séries é uma forma antiga, e somente um produto (Speedware Media/MR) cujo desenvolvimento iniciou em 1980, tem usado está abordagem.

Existe uma outra forma, o multicubo atômico, o qual foi mencionado pela primeira vez na 1ª. edição do The OLAP Report, mas parece não ter sido compreendido.  

QUAL É O MELHOR?

Tanto hipercubo como multicubo têm sido usados com sucesso. Em geral:

• Multicubos são mais eficientes e versáteis;
  

• Hipercubos são mais fáceis para entender;
  

• Usuário deve reconhecer melhor hipercubos pela sua simplicidade de uso;
  

• Profissionais com experiência em multidimensional preferem multicubos por causa da sua maior flexibilidade e pela facilidade de ajustes;
  

• Multicubos é a maneira  mais eficiente  de armazenar muitos dados esparsos podendo reduzir o efeito de explosão de valores pré-calculados em banco de dados;
  

• Produtos mais sofisticados tendem a usar multicubos; 
  

• Aplicações pré-construídas também tendem a usar multicubos permitindo que o dado estruturado possa ser melhor ajustado para as necessidades conhecidas da aplicação;
  

• No hipercubo, cada dimensão pertence a um único cubo;
  

• Em um multicubo, a dimensão pode fazer parte de múltiplos cubos.

Empresas têm introduzido produtos com a habilidade para “desacoplar” o armazenamento das camadas de processamento e apresentação. GentiaDB e HOLOS e a sua arquitetura OLAP complexa são os produtos que permitem que dados sejam armazenados fisicamente como um multicubo, mas cálculos possam ser definidos como se isto fosse um hipercubo. Esta forma permite compartilhar a simplicidade do hipercubo com o armazenamento mais afinado do multicubo. Microsoft e seu Analysis Services também têm conceito similar, com partições e cubos virtuais.

As estruturas de dados multidimensionais são sistemas proprietários que não seguem padrões, ou seja, cada desenvolvedor cria a sua própria estrutura para o banco de dados, isto é, para armazenar o cubo e usa as suas próprias ferramentas para acessá-lo, criando em alguns casos API´s para que terceiros possam ter acesso à sua estrutura multidimensional. Não têm um método de acesso padrão como a linguagem SQL, alguns até criam variantes do SQL para acessar os dados existentes no cubo.

É difícil identificar qual o melhor tipo de estrutura multidimensional e, por conseqüência, qual o melhor produto, pois os desenvolvedores usam técnicas diferentes de implementar as estruturas e sempre estão adotando soluções para resolver os problemas técnicos onde o produtos não atendem bem, visando obter melhor desempenho. Uma forma de avaliar é verificar como estão cotadas as empresas no mercado mundial de produtos OLAP, isto é, como o mercado reage com os produtos e as novas “features” que são disponibilizadas. Existem produtos que atuam melhor em determinado ramo de  atividade, ou cujas caraterísticas são mais voltadas para determinado uso, como por exemplo: em aplicações financeiras. 

Empresas surgem no mercado lançando produtos com novas características, visando melhorar o desempenho, acelerando a performance e permitindo mais flexibilidade no número de dimensões suportadas. Como exemplo disto temos o produto Query-Object (Query-Object Systems Corp.) que usa uma estrutura de índice polinomial e o HyperRoll (HyperRoll Inc.) posicionado como produto acelerador de performance para ROLAP e MOLAP.

REFERÊNCIAS

[1] BISPO, C. A. F. Uma análise da nova geração de sistemas de apoio à decisão.1998. Dissertação (Mestrado) - Universidade de São Paulo, São Carlos, 1998. Disponível em: http://cazarini.cpd.eesc.sc.usp.br/Bispo/DI. Acesso em: jun. 2001

[2] HYPERCUBES and multicubes. Disponível em: http://msdn.microsoft.com/library/psdk/ dasdk/olap3qnn.htm. Acesso em: jun. 2001

[3] RADEN, N. Data, data everywhere. Information Week, 30 Oct. 1995. Disponível em: http://www.archer-decision.com/artic2.htm. Acesso em: jun. 2001

[4] STODER, D. The missing link. Intelligent Enterprise, 16 Apr. 2001. Disponível em: http://www.intelligententerprise.com. Acesso em: jun. 2001

[5] THE OLAP REPORT. Multidimensional data structures. Disponível em: http://www.olapreport.com/MDStructures.htm. Acesso em: jun. 2001

[6] THOMSEN, E. Is there any model out there. Database Programming & Design, Sep. 1998. Disponível em: http://www.dbpd.com/Vault/9809decs.html. Acesso em: jun. 2001