MDX Para Quê?

Por que alguém precisaria aprender MDX? É o que eu pretendo justificar aqui.

Preparado?

Get set, ready, go!

M-D-OQ?

MultiDimensional Expressions é uma linguagem para construção de visões de dados multidimensionais (i.e. com cabeçalhos em linhas e colunas) inventada pela Microsoft, a partir da meta simples de levar BI para as massas.

MDX é muito parecido com SQL, no sentido de que é uma consulta que “constrói” uma “tabela”, exceto por alguns fatos:

  • O resultado tem uma forma mais semelhante a uma planilha que a uma lista;
  • O motor que trata consultas MDX não é um banco de dados relacional tradicional, mas um servidor de dados multidimensional;
  • MDX não possui uma DDL, que é um conjunto de comandos para definir estruturas de dados. Em SQL, por exemplo, CREATE TABLE é um comando DDL;
  • E não tem esses comandos justamente porque o propósito do MDX é fazer consultas, não transações. Mesmo assim, criou-se uma coisa chamada writeback, que permite escrever dados de volta para o servidor multidimensional.

Se você ainda não adivinhou, MDX é uma linguagem de consulta de cubos OLAP. Daí você entende facilmente que MDX é apenas parte de uma arquitetura maior, que engloba um servidor OLAP, ou multidimensional (do qual o Mondrian é um tipo), e algum tipo de processo de atualização de dados.

Há dois bons livros para aprender sobre OLAP e MDX:

O Problema

Vamos deixar MDX de lado um pouco, e examinar o problema desta semana. Para (não) variar, é um problema que eu vim a enfrentar ao tentar resolver uma situação muito ordinária, apresentada por um colega de trabalho.

Esse colega trabalha no marketing da empresa e fez uma pesquisa com nossos empregados. De maneira geral, a pesquisa tinha dois tipos de perguntas:

  • Perguntas com respostas únicas, como sim/não ou uma lista de opções do qual somente uma podia ser escolhida. Por exemplo, setor do empregado (uma opção de uma lista), e se conhecia a estratégia da empresa (sim ou não;)
  • Perguntas que podiam ter nenhuma resposta, uma resposta ou mais de uma resposta. Exemplos: qual é seu meio preferido de comunicação (cite até três).

Para simplificar, assuma que esses dados eram coletados em uma planilha com este layout:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

Obviamente a pesquisa era bem maior que isso, e tínhamos várias perguntas de cada tipo. O que é importante guardar aqui é que existe uma pergunta que gera uma resposta em uma única coluna, como a P1, e perguntas que geravam suas respostas em n colunas – duas, três, dez.

Como analisamos esses dados? Bom, por exemplo, podemos perguntar quantas pessoas conhecem a estratégia da empresa, que é a P1. A resposta é obtida somando-se todos os SIMs da lista de respostas. Um simples SELECT COUNT('SIM') AS conheco FROM pesquisa traria a resposta. Ou falando em termos de Excel, basta colocar uma função de contagem para totalizar a coluna da P1.

Outra pergunta pode ser: quantas pessoas têm no e-mail seu meio de comunicação preferido? A resposta, de novo, é obtida com relativa facilidade: contamos quantas vezes a expressão E-mail aparece na coluna P2.A.

Mas é claro que a realidade nunca é assim tão fácil, não é mesmo? Não teria graça, se fosse. ;-)

Suponha que nosso chefe peça o seguinte: “descubra os três meios de comunicação mais preferidos, por ordem do mais votado para o menos votado”.

Fácil? Algoritmicamente, talvez:

  1. Conte P2.A, P2.B, P2.c etc.
  2. Crie uma outra tabela, de duas colunas: opção e contagem;
  3. Insira, na primeira linha desta tabela, o rótulo “E-mail” na coluna 1, e sua contagem na coluna 2;
  4. Repita isso para todas as outras opções;
  5. Ordene esse tabela do maior para o menor, usando a coluna 2 e limitando o resultado em 3 linhas.

O resultado seria algo assim:

Meio Contagem
E-mail 10
Cartazes 7
Reuniões 2

“Ah”, pensas tu, “fácil como torcer para o Grêmio, guri!”


Estou em um treinamento de Lean Business Analysis pelo Luiz Parzianello, um porto-alegrense bah, tchê! Daí eu acabei pegando o sotaque, índio velho!


Então você pensa que é fácil?

Hahahahahaha…

Permita-me frisar:


HahahAHhAHHHaHAhAhAHAHHHahahaHAhahaha!!!….


É qualquer coisa, menos fácil. Por favor, tente essas análises:

  1. Qual é a porcentagem de empregados que conhece a estratégia e prefere e-mail?
  2. Qual é a porcentagem de cada opção, em cima do total de empregados que responderam essa pergunta?

A primeira análise é similar à inicial, mas com um filtro aplicado (conhece a estratégia = sim) antes de calcular a razão entre todos que responderam SIM para opção de e-mail pela quantidade de SIMs totais.

E a segunda? Simples:

  1. Calcular a razão entre a quantidade que respondeu “prefiro e-mail”, pela quantidade de participantes que tem pelo menos uma resposta;
  2. Calcular a razão entre a quantidade que respondeu “prefiro cartaz”, pela quantidade de participantes que tem pelo menos uma resposta;
  3. Etc.

E é claro que fica cada vez mais complicado: depois de dois dias trabalhando com Excel sem parar, o chefe olha seu relatório e diz: “excelente! agora quebra por setor!”

Vamos é querer quebrar a cabeça do pobre desafortunado que decidiu te ter na equipe, não é?


Vou tentar colocar de outra maneira: contagens simples são, como o nome implica, ações triviais. Só que, em geral, o maior valor de negócio está nas análises mais complexas, mais sofisticadas. Coisas que nem sempre podem ser respondidas com filtros e contagens.

Se meu exemplo não passou esse cenário, perdão. Esse é o cerne do problema: análises “complexas”


Trabalho de Ser Vivo de Crânio Ornado com Projeções Ósseas

Pode não ser um trampo excessivo quando temos uma pesquisa só, que por sua vez contém apenas uma pergunta deste tipo, que não tem mais que meia-dúzia de opções.

Mas, adivinha: meu colega vai fazer uma pesquisa assim uma vez a cada pelo menos dois meses! E cada uma das pesquisas do baita tem, por alto, uma meia-dúzia dessas perguntas, cada uma com quase dez opções, se não mais. E cada pesquisa atinge 10.000 empregados, com uma taxa de quantidade de respostas média em torno de 3.000. Ou seja, dos 10.000 pesquisados, em média, 3.000 respondem.

E conforme o número de variáveis sobe (gênero, setor, cidade, faixa etária, conhecimento etc. etc. etc.) sobe exponencialmente o trabalho para correlacionar uma coisa com outra.

Mas fica pior.

Uma Pergunta Múltipla Incomoda Muita Gente…

.. duas incomodam, icomodam muito maais.

Uma técnica prática para simplificar o trabalho de corno que é tabular esse tipo de dado é transpor parte da pergunta, ou desnormalizá-la. Por exemplo, a tabela do início vai de:

ID P1 P2.A P2.B P2.C
1 Sim E-mail
2 Não Cartaz Reunião
3 Sim

para:

ID P1 P2
1 Sim E-mail
2 Não Cartaz
2 Não Reunião
3 Sim

Notou o que eu fiz? Eu repliquei cada linha que tinha mais de uma resposta, e coloquei todo mundo lá.

Agora ficou mais fácil fazer uma contatem simples. Mas o que aconteceu se eu tiver DUAS perguntas de múltiplas escolhas?

ID P1 P2 P3
1 Sim E-mail Escolha X
1 Sim E-mail Escolha Y
2 Não Cartaz Escolha Y
2 Não Cartaz Escolha K
2 Não Cartaz Escolha Z
2 Não Reunião
3 Sim Escolha Y

Agora não basta mais contar cada coluna: é preciso deduplicá-las antes, e fazer as contas depois.

Uma vez a cada dois meses.

Em datasets pequenos, de coisa de 3.000 linhas… E algumas dezenas de colunas. Duas perguntas de cinco escolhas cada, as 3.000 linhas iniciais pulam para pelo menos cerca 6.000, podendo chegar – em casos extremos – a centenas de milhares de linhas… PARA SEREM TRATADAS NO EXCEL.

Não vira, né? ;-)

Operações de Conjuntos

Foi tentando resolver esse problema que a minha ficha caiu: eu vou precisar de um ETL específico para cada pergunta de resposta múltipla para colocar tudo como colunas simples, para permitir contagens simples, mas cada contagem vai ficar mais complicada ainda! É um círculo vicioso! A solução que achamos foi aplicar essa transposição coluna a coluna, uma de cada vez, e fazer análises estanques. Só depois, então, as análises de cada coluna são feitas.

MDX To The Rescue

Bom, MDX é difícil, na prática, mas na teoria, no conceito, é simples: uma expressão literal que manuseia conjuntos multidimensionais.

Falando de outra maneira, é uma linguagem que trata um problema complexo como o que eu expliquei aqui, com muito menos trabalho que toda operação manual.

Por exemplo, o caso inicial – top 3 canais – pode ser descrito como um conjunto formado pela união de três subconjuntos, que por sua vez recebeu uma ordenação com limite.


Eu voltarei ao assunto com um exemplo concreto. Por ora, por favor, tentem visualizar o que estou descrevendo.


Mas e se tivermos, por exemplo, várias perguntas de múltiplas respostas? Não tem importância: comandos MDX, que podem ficar verdadeiramente cabeludos, lidam com conjuntos de membros de uma dimensão (as opções de cada pergunta) e calculam as métricas para aqueles cruzamentos. Comandos que constroem sub-conjuntos podem ser aninhados para montar dois, três, n conjuntos e, em seguida, totalizá-los o apresentá-los como uma matriz – uma planilha.

Complexo? Sim. Pouco intuitivo? É, um pouco. Torna tudo viável? Sim!

Conclusão

Muito de análise multidimensional pode ser feito com um conjunto de dados simples e uma boa ferramenta OLAP. Porém, certos conjuntos de dados representam um desafio muito maior – que nem mesmo um bom trabalho de ETL pode simplificar. Podemos acabar mudando um problema complexo em outro, tão complexo quanto ou mais!

A linguagem MDX, e as tecnologias OLAP associado por trás, como servidor de dados multidimensional, pré-agregadores etc., são uma opção poderosa, geralmente certeira e muito pouco conhecida!

É esse cenário que eu pretendo mudar, daqui para o final do ano.

Até lá, guarde em mente que um analista de dados deve aprender MDX por dois motivos simples:

  • Permite analisar mais dados, mais rapidamente;
  • Simplifica o trabalho de responder uma pergunta a partir dos dados, tornando algo complexo em simples, e tornando em possível o im possível.

Até a próxima! ;-)

 

Anúncios

Excel vs. MDX

Não me entenda mal: não quero começar uma guerra santa entre usuários de Excel e de MDX, até porque eu provavelmente pertenceria ao exército santo do Excel.

Mas a verdade é que, quando alguém precisa tabular dados, a primeira escolha é sempre o Excel. Ele é simples e fácil de usar, e dá resultados mais ou menos intuitivos.

Neste post eu vou mostrar um caso típico de uso do Excel – comparar valores de dois períodos – e como fazer o mesmo usando MDX. Daí eu vou tirar algumas conclusões e, espero, te convencer da importância de investir no estudo de MDX.

Vamos lá.

O Problema

Eu recebi um e-mail de um ex-aluno com o seguinte problema:


(No meu cubo) tenho uma coluna de valor faturado e, estou fazendo um comparativo entre os anos de 2014 e 2015, por empresa, pois somos um grupo de empresas. A minha métrica é o valor faturado. Então, como proceder se eu tiver que dividir um valor pelo o outro?


Quantas vezes não precisamos fazer isso? Comparar um ano com outro, uma linha de produtos com outra, faturamento em estado com outro… Qual é a primeira idéia que nos ocorre para tratar esse problema?

Montar uma planilha eletrônica – um Excel. É ou não é?

Vamos fazer isso aqui: vamos pegar o problema que meu ex-aluno trouxe e resolvê-lo, primeiro no Excel e depois como uma consulta MDX.

Para facilitar a compreensão do raciocínio, eu vou alterar ligeiramente o problema trazido pelo aluno. Ao invés de considerarmos os dados da empresa dele, que são sigilosos e relativamente complexos, vamos usar o cubo de vendas da SteelWheels, que é a empresa usada na demonstração do Pentaho BA Server.

Reformulando o problema com a SteelWheels, fica:


Estou fazendo um comparativo entre os anos de 2004 e 2005, por linha de produto. A minha métrica é o valor vendido (Sales). Como proceder se eu tiver que dividir um valor (Sales em 2005) pelo o outro (Sales em 2004) para cada linha de produto?


Resolvendo com Excel

Para resolver esse problema usando uma planilha eletrônica (nome genérico do Excel, que serve para designar não apenas o Excel, mas o Calc, do LibreOffice, o Lotus 1-2-3 etc.), precisamos primeiro extrair os dados para um arquivo, que vai ser importado pelo Excel e só então aparecer como uma planilha. Normalmente, para bancos de dados relacionais, fazemos isso exportando para CSV o resultado de uma consulta SQL, e depois importando esse CSV para dentro da planilha eletrônica.

E para fazer isso nós precisamos:

  1. De uma ferramenta que permita rodar SQL contra a base e exportar o resultado para arquivos CSV;
  2. Conhecer a base de dados, entendendo que tabelas possuem os dados que queremos, e como elas se relacionam entre si; e finalmente,
  3. Saber SQL o bastante para escrever uma consulta válida.

Vamos começar por entender os dados. Eis abaixo o esquema do banco, construído no Power*Architect:

Esquema que alimenta o cubo SteelWheels Sales.
Esquema que alimenta o cubo SteelWheels Sales.

Montei esse diagrama fazendo engenharia reversa no esquema Mondrian (que por sua vez foi retirado do servidor Pentaho) e na base de dados.

Como queremos os dados das vendas feitas por ano, por linha de produto nos interessam as tabelas PRODUCTS, ORDERFACT e DIM_TIME. O SQL que retorna a lista de valores vendidos por linha de produto, por ano é:

SELECT
  PRODUCTS.PRODUCTLINE AS PRODUCTS_PRODUCTLINE,
  DIM_TIME.YEAR_ID AS DIM_TIME_YEAR_ID,
  SUM(ORDERFACT.TOTALPRICE) AS SALES
FROM PUBLIC.PRODUCTS PRODUCTS
INNER JOIN PUBLIC.ORDERFACT ORDERFACT
  ON PRODUCTS.PRODUCTCODE = ORDERFACT.PRODUCTCODE
INNER JOIN PUBLIC.DIM_TIME DIM_TIME
  ON ORDERFACT.TIME_ID = DIM_TIME.TIME_ID
GROUP BY PRODUCTS_PRODUCTLINE,
         DIM_TIME_YEAR_ID
ORDER BY DIM_TIME.YEAR_ID ASC,
PRODUCTS.PRODUCTLINE ASC`

(Eu não sou esse mago do SQL. Eu consegui essa expressão usando o SQLeonardo. E não, não existe o SheldonQL.)

O SQLeonardo já seria o bastante para exportar os dados, mas eu resolvi usar a grande dica do Rômulo, e montei uma conexão com o banco usando uma interface gráfica padrão do HSQLDB:

Conexão do cliente HSQLDB com o SampleData.
Conexão do cliente HSQLDB com o SampleData.

O HSQLDB é o banco de dados portátil, usado pelo Pentaho BA Server.


Depois da conexão feita, rodamos a consulta acima:

Resultado da consulta que traz o dados que desejamos.
Resultado da consulta que traz o dados que desejamos.

E salvamos esse resultado em formato texto:

Arquivo texto resultado do comando 'File -> Save Result'.
Arquivo texto resultado do comando ‘File -> Save Result’.

Depois de um pouco de escovação, finalmente aparece como uma planilha eletrônica:

Colocando os anos lado-a-lado na planilha.
Colocando os anos lado-a-lado na planilha.

Pronto, podemos nos dedicar a montar a resposta ao problema. Primeiro, rearranjamos a planilha para colocar os anos lado-a-lado:

Colocando os anos lado-a-lado na planilha.
Colocando os anos lado-a-lado na planilha.

Agora ficou fácil: basta calcular a razão (=divisão) entre quaisquer colunas e inserir o resultado em uma nova coluna. Do enunciado do problema sabemos que queremos a divisão de 2005 por 2004. Assim, apaguei a coluna de 2003 e coloquei uma nova coluna, 2005/2004, contendo a fórmula que divide uma pela outra. Formatei como porcentagem e finalmente temos (com destaque para a fórmula):

Calculando 2005 dividido por 2004, como uma porcentagem.
Calculando 2005 dividido por 2004, como uma porcentagem.

Voilá! Problema resolvido!

MultiDimensional eXpressions

MDX é a linguagem que a Microsoft criou para seu produto OLAP, o MS SQL Server Analysis Services, ou SSAS, como é conhecido. O SSAS é uma base multidimensional real, o que significa que ele guarda cada célula de um cubo OLAP como um registro físico, assim como um banco relacional guarda registros em disco. Em comparação, o Mondrian é um servidor OLAP, que monta o cubo em memória a partir de um banco de dados relacional tradicional, conforme processa comandos MDX. Em comum, SSAS e Mondrian têm exatamente isso: a linguagem MDX.

A meta da Microsoft com o SSAS era popularizar BI, e nisso o MDX era instrumental. A idéia por trás do MDX era viabilizar justamente o tipo de manipulação que fazemos com o outro produto da MS – o Excel – mas para grandes e complexas massas de dados. O livro Fast Track to MDX traz um histórico, simples mas muito valioso, de como o SSAS (e o MDX) nasceu e cresceu.

Resolvendo com MDX

Para resolver esse mesmo problema com MDX usamos um Pentaho BA Server (eu usei a versão 5.4, mas funciona com qualquer uma – mesmo!) Depois de subir o servidor, acessamos o endereço http://localhost:8080, fazemos login com usuário admin e senha password e criamos uma nova visão OLAP:

Abrindo uma nova visão OLAP do cubo de vendas SteelWheels.
Abrindo uma nova visão OLAP do cubo de vendas SteelWheels.

Assim que você seleciona o esquema SteelWheels e o cubo SteelWheelsSales e clica em Ok, a visão inicial do cubo se abre:

Visão inicial do cubo de vendas da SteelWheels.
Visão inicial do cubo de vendas da SteelWheels.

Usando o primeiro ícone do jPivot, Cube Navigator, e mudando o tipo de drill para Drill Replace (ícone de setas vermelhas), chegamos a uma visão análoga à da planilha:

Cubo rearranjado para mostrar a mesma visão de planilha.
Cubo rearranjado para mostrar a mesma visão de planilha.

Neste ponto, quando usamos o Excel, criamos uma nova coluna e colocamos a fórmula nela. Vamos fazer exatamente a mesma coisa aqui, mas com MDX.

Até agora manuseamos os dados em uma interface gráfica. Vamos ver o que existe de MDX por trás disso. Clicando-se no botão MDX do jPivot, vemos a consulta que construímos enquanto lapidávamos o cubo:

SELECT NON EMPTY Crossjoin( {[Measures].[Sales]},
              [Time].[All Years].Children ) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Em MDX-zês, uma “nova coluna” equivale a uma métrica calculada (bom, tecnicamente falando, é um membro calculado, mas como é um membro do conjunto de métricas, fica sendo uma métrica calculada mesmo.) Essa métrica calculada pode ser definida, em português, assim:

    COM O NOME "Razao_2005_2004" USE A FORMULA ([2005,Categoria]/[2004,Categoria]), <OPÇÕES>

O truque todo está na fórmula: pense no cubo OLAP como uma mega-planilha, na qual toda métrica pode ser referenciada com um conjunto de coordenadas, exatamente como em uma planilha Excel. A diferença é que as coordenadas não são colunas e linhas, como na fórmula da figura anterior, mas sim membros dos conjuntos das dimensões!


Outro detalhe importante: se você não explicitar uma dimensão, assume-se que a fórmula vale em todas as “coordenadas” daquela dimensão. Ainda apelando para a analogia do Excel, é como fazer referência à planilha: a menos que você indique uma célula em outra planilha, a fórmula Excel vai assumir que a coluna/linha indicada é na mesma planilha (o “membro atual”, do inglês current member – essa noção é importantíssima!!), e se você copiar essa fórmula para outra planilha, o mesmo vai continuar valendo.

Trocando o Português por MDX castiço, a fórmula fica:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"

O format_string serve para que os valores calculados apareçam como porcentagens. Sem ele ali, os valores seguiriam a formatação da métrica original.

Agora vamos colocar essa fórmula no nosso MDX anterior:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"
SELECT NON EMPTY Crossjoin({[Measures].[Sales]},
               [Time].[All Years].Children) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Se você testar essa consulta no jPivot, copiando-a e colando-a, vai ver que nada de novo aparece, mas também não dá erro. Isso acontece porque, apesar de termos definido a nova métrica, ela não está sendo usada na consulta. É preciso incluir a nova métrica na consulta para que ela apareça no cubo. Fazemos isso alterando o termo logo depois de SELECT NON EMPTY Crossjoin:

WITH MEMBER [Measures].[Razao_2005_2004] AS (
  ([Measures].[Sales],[Time].[2005],[Product].CurrentMember) / 
  ([Measures].[Sales],[Time].[2004],[Product].CurrentMember)
                                   ), format_string = "#.00%"
SELECT NON EMPTY Crossjoin(
          {[Measures].[Sales],[Measures].[Razao_2005_2004]},
           [Time].[All Years].Children ) ON COLUMNS,
NON EMPTY [Product].[All Products].Children ON ROWS
FROM [SteelWheelsSales]

Notou que o nome da nova métrica, definida no WITH MEMBER, agora aparece na consulta? Se tudo deu certo para você, seu cubo agora deve se parecer com este aqui:

Cubo com a nova métrica calculada.
Cubo com a nova métrica calculada.

Algumas coisas ficaram esquisitas: a coluna se repetiu, com o mesmo valor, para os três anos. Essa visualização é estranha, e não ajuda muito. Se você pensar um pouco, verá que a fórmula que calculamos opera sempre apenas sobre 2005 e 2004. Logo, não há sentido em mostrar o ano


Ao remover a dimensão Ano da grade OLAP, a métrica Sales passará a ser agregada para todos os anos, e não veremos mais as duas colunas para 2004 e 2005. Precisamos aprender um pouco mais de MDX para saber como mostrar a métrica Sales em 2004, em 2005 e, em uma terceira coluna, a métrica calculada – mas aí já é outra história. Entretanto, se você quiser procurar, a solução para este caso passa por NAMED SETS (NS).


Grade agora mostra só a métrica calculada.
Grade agora mostra só a métrica calculada.

Tudo isso parece um pouco confuso no início, mas eu posso dizer algumas coisas para ajudar:

  • É uma fórmula que resolve esse o problema atual, e nenhum outro. Em outras palavras, não é uma solução genérica e geral, mas sim uma bem específica;
  • Pense sempre como uma planilha Excel: para calcular a metade do valor da célula F4, você coloca “=F4/2” na célula G4. Certo? Em MDX é a mesma coisa, mas uma “célula” é o cruzamento das dimensões e uma ou mais métricas. Para calcular uma nova relação, construímos uma nova coluna, e assim por diante;
  • Logo, a solução de outros problemas demandam outras consultas MDX. Preparamos uma nova solução sempre que tivermos uma nova necessidade.

Conclusão

Meu modesto objetivo era mostrar como uma conta feita em planilha pode ser replicada com MDX. Ou seja, eu queria mostrar que MDX pode ser encarado como uma outra forma de se manusear planilhas de dados. Por favor deixe sua opinião nos comentários: eu consegui?

Se você pensar um pouco, vai ver a mesma situação acontece com bancos relacionais e SQL: em busca de uma resposta específica, podemos escrever um programa (Java, Kettle, PHP etc.) que itera sobre as linhas de uma tabela – para calcular uma média por exemplo, ou podemos tentar escrever uma consulta SQL. Em geral, a consulta SQL vai ser mais enxuta, poderosa, rápida e flexível, porque ela foi pensada para fazer bem certos tipos de trabalho.

Com MDX temos a mesma situação: podemos montar uma planilha, ou podemos escrever uma consulta MDX sobre um cubo OLAP. Em geral, MDX vai ser mais enxuto, poderoso, rápido e flexível, porque ele foi pensado para resolver problemas analíticos.

Há algumas outras coisas dignas de nota em nossa breve aventura com planilhas e OLAP:

  • Ambos os métodos partem da existência de um banco de dados pronto para consulta. Criar esse banco já é um trabalho considerável, dependendo da empresa e das complexidades (negócios, dados etc.) envolvidas;
  • Uma vez que você consiga montar esse banco, ainda precisa escrever o SQL para poder chegar à planilha;
  • Se você optar por montar um cubo OLAP, precisa mapear o banco com um esquema Mondrian, e depois construir o MDX que resolve seu problema.

Ou seja, por qualquer caminho que peguemos (MDX ou Excel), sempre vamos precisar “escrever” algo (um SQL ou um MDX), mesmo que para isso usemos uma ferramenta visual.

Bom, se pelos dois caminhos temos o mesmo trabalho, se não maior no caminho MDX, porque então vale a pena usar MDX? Porque não ficamos só com Excel?

Resposta: volume de dados e complexidade.

Veja como tínhamos poucas linhas e poucas colunas para manusear em uma planilha eletrônica. Conforme o volume de dados e a complexidade desse volume aumenta, cresce a complexidade das operações necessárias para montar a planilha. Nosso exemplo usa apenas anos e linha de produto. Como ficaria para Mês/Ano e Produto com Cliente? Com duas dimensões conseguimos “ver” a planilha numa boa, mas e com três, quatro, cinco?…

Mais ainda: para cada visão em planilha, o comando SQL precisa mudar para tratar das agregações nos níveis corretos!

O livro OLAP Solutions desenvolve esse argumento melhor, mas o ponto que eu quero destacar é que planilhas podem ser práticas e muito úteis apenas até certo ponto! A partir daí, as operações para montar e explorar as planilhas ficam sobejamente complexas.

É quando MDX passa a ser mais interessante que Excel.

Até a próxima!