Artigo SQL Magazine 39 - Microsoft Analysis Services 2000 na prática - Parte 1 - Implementando um modelo multidimensional

Microsoft Analysis Services 2000 na prática - Parte 1

Implementando um modelo multidimensional

Já se tornou comum ouvir profissionais de TI falando em cubos e dimensões. E as ferramentas OLAP disponíveis no mercado são tão fáceis de usar que muitas vezes até os usuários finais se aventuram na criação destes objetos. Mesmo assim, é essencial que o profissional tenha um bom embasamento conceitual, de outra forma os resultados podem ser desastrosos. Ao contrário do que parece, não se trata apenas de clicar Next a cada tela dos vários assistentes que o Microsoft Analysis Services 2000 (ou simplesmente MSAS) nos oferece.

A primeira ferramenta OLAP que a Microsoft incorporou no pacote do SQL Server apareceu na versão 7 e se chamava OLAP Services. O MSAS apareceu com o SQL Server 2000, e continua disponível no SQL 2005 (na versão Express também). Este é um produto muito superior ao OLAP Services, mais estável, com muito mais recursos, além de incluir um mecanismo para Data Mining. Mas a principal vantagem competitiva do MSAS frente aos seus concorrentes OLAP permanece a mesma em todas as versões: custo zero.

O MSAS é um gerenciador de informações e oferece ao desenvolvedor uma série de recursos para auxiliar o processo de análise de dados, seja em termos de melhoria de performance, administração da base, assim como no cálculo de expressões matemáticas sofisticadas.

Se você já o utilizou alguma vez, deve ter notado que o MSAS usa um mecanismo inteiramente independente do SQL Server 2000. Existe, é claro, uma integração entre estes dois mecanismos, mas lembre-se que eles são produtos distintos.

Este artigo é o primeiro de uma série que apresentará recursos e conceitos associados ao MSAS. Ao longo da série, abordaremos soluções baseadas no MSAS que serão úteis tanto para o administrador de dados experiente quanto para o desenvolvedor iniciante no universo de Business Intelligence e OLAP. Este tipo de aplicação é a base para sistemas de apoio à tomada de decisão.

Para tanto, usaremos um modelo de negócios real, a partir do qual criaremos uma aplicação de Business Intelligence e abordaremos tópicos como a modelagem multidimensional, criação e administração de cubos, automação de processos e integração com interface para os usuários.

Neste primeiro artigo, exploramos a modelagem e criação do cubo, ou seja, a base de dados multidimensional que nossa aplicação irá usar.

Mas antes de seguirmos adiante é importante revisarmos alguns conceitos.

Conceitos importantes

Modelagem multidimensional se destina à criação de bases voltadas para a análise de dados. Portanto, o modelo criado será uma representação do modelo de negócios analisado e deverá ser implementado de tal maneira que facilite a manipulação e análise de dados por parte do usuário final. Tenha sempre isso em mente ao pensar sobre OLAP.

Não importa se o modelo será implementado em um banco de dados relacional com esquema estrela, conforme definição de Kimball, ou em um banco genuinamente multidimensional. Na realidade, o MSAS permitirá que você faça esta escolha durante a implementação dos cubos ou mesmo que a mude posteriormente, conforme sua necessidade.

A terminologia que usamos neste artigo é padrão no universo OLAP e, portanto, não a repetiremos aqui.

Modelo de negócios

Vamos considerar neste exemplo um modelo de negócios para o mercado farmacêutico, em que a força de vendas da empresa X atua em todo território nacional representando as linhas de produtos da companhia.

A empresa X pretende analisar dados históricos de demanda mensal de produtos em Valores e Quantidades, assim como o desempenho da força de vendas por categoria de produto. As análises consideram resultados mensais, o acumulado no trimestre, e no ano.

A questão aqui é que os analistas de negócio da empresa X precisam de ferramentas que lhes dêem poder de análise e facilidade de uso, já que o perfil destes usuários é, na maioria, de profissionais leigos em TI. E os próprios analistas de negócio deverão definir, construir, atualizar e distribuir seus relatórios por toda a força de vendas. Os analistas devem ter a capacidade de gerar relatórios sob demanda, ou relatórios ad hoc, como costumamos chamar no universo OLAP.

Os usuários pretendem trabalhar usando planilhas Excel e browser, que são duas interfaces “nativas” para o MSAS (veremos como isto será feito nos próximos artigos desta série).

Outra exigência aqui é a performance do sistema. Estas exigências levaram a equipe de TI da empresa X a optar pelo uso do MSAS. As duas razões principais foram:

1.      a empresa não pretendia investir em licenças para uma ferramenta pra geração de relatórios;

2.      os usuários do sistema não teriam a qualificação técnica necessária para criar relatórios usando consultas SQL.

É importante fazermos uma ressalva neste ponto. A facilidade de consulta e criação de relatórios não são, por si só, fatores que definirão se o MSAS é uma boa opção para seu projeto. Atualmente, há inúmeras opções no mercado que cumprem este papel, desde componentes (COM) gratuitos a pacotes especializados.

Performance, volume de dados, número de usuários, tráfego de rede e segurança de acesso, por exemplo, são fatores que devemos incluir entre os nossos quesitos para tomarmos uma decisão que tenha realmente uma boa relação de custo-benefício.

Retornando o nosso estudo de caso, resta-nos agora avaliar o modelo de dados que será considerado.

A empresa dispõe de uma base de dados que coleta e armazena transações de demanda. Internamente, esta base é chamada de DataWarehouse. Trata-se de uma base relacional que utiliza modelagem relacional convencional, que foi construída no SQL Server 2000.

O DataWarehouse reflete a estrutura de negócios da empresa, conforme descrevemos a seguir.

A força de vendas é organizada assim: os representantes atuam em várias micro-regiões geográficas, que são conhecidas neste mercado pelo nome de bricks. Os representantes respondem para gerentes distritais, que por sua vez respondem aos gerentes regionais, que estão separados em linhas de produtos e que, finalmente, estão sob o comando do gerente nacional de vendas. Um fator importante a ser observado é que pode haver um representante de cada linha de negócio atuando no mesmo brick.

Os produtos são analisados considerando a seguinte estrutura: a empresa trabalha com “Linhas” de produto que caracterizam as suas unidades de negócio. Cada linha incorpora uma ou mais “Categorias” de produto que representam os segmentos de mercado. Abaixo das categorias, temos as “Famílias” de produto, que são as marcas de produto. E, por fim, cada família se associa às “Apresentações” de produto, que são os produtos como os vemos nas prateleiras das farmácias (exemplo: Finasterida 1mg em caixa com 60 comprimidos).

Um diagrama simplificado correspondente a este DataWarehouse é apresentado na Figura 1. Como se pode observar, o modelo gira em torno da tabela “tblDemanda”, que contém as transações que desejamos analisar. O relacionamento desta tabela com as tabelas auxiliares considera que as transações são detalhadas por data, produto e força de vendas.

Este modelo foi adaptado para fins didáticos. Outras considerações importantes em relação ao modelo são apresentadas no artigo Mitos e Verdades sobre Modelagem Multidimensional. ...