agosto 2015 – Geek BI

Publicado em 27/08/2015 por Fábio de Salles

De Agilidade e BI

Como capturar e documentar requisitos para projetos de BI gerenciados por métodos ágeis?

Ágil, Não Rápido

Quando Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland e toda patota declararam o Manifesto Ágil, eles não estavam preocupados com a velocidade do desenvolvendo de software, mas sim com a dificuldade cada vez maior em escrever bons produtos. Até início dos anos 2000, o paradigma de desenvolvimento de software era espelhado no paradigma de construção civil: ninguém assentava um tijolo até tudo estar absolutamente calculado e verificado.

É o mesmo que dizer que Romeu e Julieta foi escrito de uma vez, em algumas semanas, depois de Shakespeare passar alguns anos detalhando os personagens e a história. Não que eu seja especialista no processo criativo shakespeareano, longe disso! O que eu quero dizer é que construir paredes e escrever algo são atividades muito diferentes. Meu melhor exemplo são meus posts como exemplo: eu reescrevo cada post – inteirinho – pelo menos uma vez.

Imagine construir e derrubar uma parede até ela ficar perfeita. Imaginou? Bom, vá além: imagine construir e demolir uma casa inteira, até ficar como você quer. Ou pior: construir e vê-la desabar sobre o próprio peso vezes sem conta, até acertar a posição das vigas e conseguir que a centésima vigésima terceira encarnação da casa não caia só porque alguém bateu a porta da frente com força.

É ruim, hein! :-P

O cerne do conceito de desenvolvimento ágil não é a velocidade, mas a melhoria contínua.

Por isso no manifesto eles dizem que vêem valor em “processos, ferramentas, documentos etc.”, mas que vêem ainda mais valor em “indivíduos, colaboração, resultados etc.” Está lá, com todas as letras: trabalhar para obter um bom resultado é o que interessa. E não adianta trabalhar a toque de caixa, fazendo tudo nas coxas, só para chegar rapidamente ao final. O que interessa é avançar, melhorando continuamente e sem comprometer o futuro com decisões apressadas ou serviço mal-feito.

Inteligência de Negócios Ágil?

E como você trabalha melhoria contínua em Inteligência de Negócios? Como casamos BI com Ágil?

Eu venho estudando essa questão, meio que sem querer, já há alguns anos. Como sempre, tudo começou porque eu queria aplicar Scrum de qualquer maneira, custasse o que custasse! Eu havia acabado de ler Agile Project Management with Scrum, do Ken Schwaber, e estava louco para pôr em prática aquelas idéias. Era tudo tão simples, tão elegante, tão poderoso que eu precisava tocar um projeto com Scrum.

Tive uma sorte danada: havia acabado de receber um projeto e ele servia como uma luva em todas aquelas idéias. Aprendi tudo de Scrum, botei em prática, e o projeto funcionou muito bem.

Quer dizer, praticamente. Algums detalhes não deram muito certo:

Automação de Testes: como você testa um ETL ou um relatório, continuamente? Como montar testes de regressão em um modelo dimensional?
Histórias: como eu transformo a necessidade do cliente em uma história, e depois mapeio isso nas atividades típicas de um projeto de BI, como desenhar o modelo dimensional, desenvolver o ETL e construir um relatório ou painel?
Refactoring: sério, refatorar um banco de dados?? Freaking how??

Ainda não encontrei uma resposta satisfatória para os testes. Já refatorar bases de dados, por incrível que pareça, é um problema que já foi resolvido: o livro Refactoring Databases disseca o assunto completamente. Estou lendo esse livro agora mas, pelo pouco que eu já li, posso dizer que ele é essencial para qualquer DBA que seja membro de uma equipe de desenvolvimento de software – ou BI – contemporânea. Leia!

Senta que Lá Vem História…

O que nos deixa no assunto deste post: levantamento de requisitos ágeis para Inteligência de Negócios.

Existem várias técnicas de levantamento de requisitos para projetos ágeis. A mais famosa, provavelmente, é o conceito de História: o cliente e a equipe de desenvolvimento constroem uma narrativa que incorpora a necessidade do cliente na forma de uma ação, de uma história. Por exemplo: “como gerente de vendas, eu quero poder ver as vendas deste mês dia-a-dia, quebradas por vendedor, produto e cliente”.

Essa foi a minha abordagem para aquele projeto. Funcionou, no sentido em que permitiu organizar o trabalho, quebrá-lo em partes e controlar a entrega. Por outro lado criou outros problemas. Exemplo? O tamanho, para começar. Quem já está acostumado com projetos de BI vê imediatamente que o cliente precisa de 1) um cubo OLAP com três dimensões, de vários níveis cada, ligadas a uma fato, tudo isso carregado por 2) um processo de ETL que leva os dados da origem a um 3) modelo dimensiona. Ou seja, uma única história dá origem a um Data Mart inteiro! É muito grande!

Outro problema é o que a própria história conta: há tantas formas de construir a apresentar esses dados que umas poucas linhas de texto é um canal muito “estreito” para enfeixar tantas possibilidades. Como adicionar detalhes? Escrevendo mais? E como fazer o cliente entender o que foi prometido e o que está sendo desenvolvido?

Eu cheguei a escrever sobre um problema relacionado à essa imprecisão: Cruel Sucesso. Para te poupar do esforço de lê-lo, resumidamente, quando você acerta na mosca, o cliente muda a demanda. Depois de algumas iterações acontecendo isso, o cliente desenvolve a sensação contrária, e passa a acreditar que o projeto nunca acerta! E, na minha opinião, isso acontece porque ele só entende claramente o que pediu quando recebe. E é neste momento que ele reavalia sua necessidade a refina. Entendeu? Não? Bom, então leia aquele post antes de continuar, hehe. :-)

Requisitos Para Gestão Ágil

Enquanto eu batia cabeça com isso eu tomei contato com outra técnica fantástica: Data Vault. Se você acompanha meu blog sabe o quanto eu sou apaixonado por DV.

De novo, louco para construir um DV e testar todas aquelas idéias, eu consegui um projeto perfeito. Não apenas pude aplicar Data Vault, mas o fiz com Scrum, o que foi duplamente satisfatório aliás. O resultado desta experiência virou o Primeiro Curso de Data Vault do Brasil. Estou evoluindo aquele material e em 2016 eu espero lançar uma versão definitiva, completa.

E foi deste material que eu puxei uma coisa muito interessante: uma técnica para levantamento de requisitos para projetos de BI. Não apenas qualquer projeto de BI, mas principalmente projetos gerenciados com alguma técnica Ágil, como Scrum ou Kanban.

Funciona assim: ao invés de escrevermos uma história, e depois quebrá-la em modelo de dados, ETL, apresentação etc., começamos anotando cruamente o que o cliente diz que precisa. Essas anotações são transformadas em protótipos que são revisados pelo cliente e ajustadas e revisadas e ajustadas etc. etc. … Em algum momento o cliente vai se dar por satisfeito e o último protótipo vira o requisito! Daí o resto é história: montar um documento que combine protótipo e a demanda do cliente em uma forma que ajuda a equipe de desenvolvimento e comunica claramente a expectativa do cliente.

4Shot Agile BI com Pentaho

Eu contei para vocês que eu comprei um apartamento? ;-) Agora eu tenho uma dívida de quarenta anos, e preciso fazer caixa. Por isso, quando uns meses atrás a 4Linux me apresentou o conceito de Shot e me perguntou se eu tinha alguma proposta, na hora eu apresentei a idéia acima.

Um Shot é um curso de curta duração (tipicamente um dia), focado sobre um único assunto e, em geral, voltado para um público específico. A 4Linux é, com certeza, o maior fornecedor de treinamentos em Software Livre e eu tenho a honra de ter produzido o treinamento Pentaho que eles oferecem (e de vez em quando ministro uma turma.)

Eu produzi um vídeo explicando melhor a idéia.

Semana que vem, dias 1, 2 e 3 de Setembro de 2015, ocorrerá a primeira turma deste Shot. As vagas são muito limitadas porque as turmas são propositalmente pequenas, de no máximo oito alunos. A idéia é oferecer um curso reforçado, intenso, e uma turma maior não permitiria isso. Também não é um assunto para principiantes. Não é nada esotérico, mas se esse vai ser seu primeiro curso em BI, bom, se prepare. ;-)

Máquina virtual pré-fabricada, pronta para os exercícios.

O curso inclui apostila e dois DVDs, com uma máquina virtual preparada para os exercícios, os exercícios resolvidos, templates, SQLs, backup de bancos e cópias de todos os softwares usados e mais alguns. E apesar de a propaganda dizer que ele é 80% prático, eu acabei fazendo um pouco mais – você não vai ter folga! Mas nem tudo será suor e teclados massacrados: como serão turmas presenciais, teremos o famoso coffee-break da 4Linux. :-)

Os leitores do blog que desejarem se inscrever terão um preço especial: R$199,00 contra R$299,00 do site. Para isso você precisa entrar em contato diretamente com Daniela Araújo (e-mail daniela.araujo@4linux.com.br) e contar que descobriu sobre o Shot no blog Geek BI.

Compre! :-D

Publicado em 05/08/2015 por Fábio de Salles

Inteligência de Negócios à Serviço da Educação

Mês passado (julho/2015) a Editora Packt conduziu uma pesquisa entre profissionais de TI para tentar entender como o conhecimento e habilidades desses profissionais influenciaram o sucesso em suas carreiras e seus salários. Receberam mais de 20.000 participações.

Isso é tanta gente que bateu todas as outras pesquisas do genêro. Para você ter uma idéia, se pegarmos só os respondentes dos Estados Unidos já dá mais participantes que a mesma pesquisa feita pela StackOverflow algum tempo antes. Uau!

E o que a Packt fez com isso? Lembre-se: eles não são uma instituição de caridade, eles querem é vender mais. ;-) Bom, eles analisaram todos esses dados e chegaram à some fascinating findings. Baseado nas conclusões das pesquisas, às quais você pode ter acesso por este link, a Packt montou pacotes de livros pensados para trazer ao leitor justamente os conhecimentos que podem gerar maior vantagem profissional nos próximos anos!

Falassério!!! Genial!!!

A empresa usa seu alcançe com leitores de todos os países e ramos da TI para pesquisar o que está fazendo diferença na vida deles. Daí estuda esses dados e monta uma campanha para ajudar seus leitores a escolher seus livros!

“Ah, Fábio, como você é inocente! Eles estão fazendo isso para ganhar mais dinheiro!”

SIM!! Ou você acha que o Pão de Açúcar faz promoção de queijos e vinhos apenas para o nosso deleite? Pense: nós, leitores, estamos ganhando com o conhecimento deles, já que nada nos impede de buscar livros de outras editoras.

A idéia não seria ruim, até, se não fosse pela segunda metade do pacote: neste link você tem acesso aos pacotes que eles montaram para vários tipos de profissionais. Por exemplo:

Aprendendo e dominando processamento de dados com Hadoop ("BigData".) — Aprendendo e dominando processamento de dados com Hadoop (“BigData”.)

Data Mining ("Data Science" - pfff, buzzwords...) com R e Python, trilha completa. — Data Mining (“Data Science” – pfff, buzzwords…) com R e Python, trilha completa.

Hoje nada é completo sem "mobile": eis um pacote para desenvolvimento Android. — Hoje nada é completo sem “mobile”: eis um pacote para desenvolvimento Android.

E como isso se isso não fosse o bastante, a Packt deu um passo além: se você quiser montar um pacote específico, que você entenda como útil na sua carreira, você pode: escolhendo qualquer conjunto de 5 livros, você paga apenas US$25,00 por eles!!

Falassério, Parte 2!!!

Ah, você não achou 5 livros? Quer um ou dois? Ou apenas um vídeo para completar seus conhecimentos? Fácil: até o final da promoção, que é em 7 de agosto, todos os livros e vídeos estão por US$10,00 cada!

É isso. Quer saber o que nossos colegas de TI estudam, e que conhecimentos eles acham que vai ser importante nos próximos anos? Acesse a pesquisa. Acha que precisa estudar um pouco mais, sobre alguma coisa? Até 7 de agosto, neste link você pode montar um pacote de até 5 livros por US$25,00 – ou comprar qualquer livro ou vídeo por US$10,00.

E qual é o meu interesse em fazer essa pusta propaganda no meu blog?

Meu amigo da Packt me pediu ajuda para divulgar a campanha. Só o afago no meu ego já seria o bastante (a Packt acha que eu sou importante? Uau!)
Francamente, é uma promoção boa demais para não divulgar. Em um país com tanta necessidade de conhecimento e educação, qualquer oportunidade de aprender a um custo menor é muito valiosa para manter segredo.

Normalmente eu ganho um livro ou dois por ajudar a divulgar uma promoção ou fazer uma resenha. Só que desta vez isso não vai me fazer diferença: eu já ganhei tantos livros em troca de resenhas e divulgação que eu simplesmente não tenho mais o que pedir…

Boas compras! :-)

Publicado em 03/08/201504/08/2015 por Fábio de Salles · 4 Comentários

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:

De uma ferramenta que permita rodar SQL contra a base e exportar o resultado para arquivos CSV;
Conhecer a base de dados, entendendo que tabelas possuem os dados que queremos, e como elas se relacionam entre si; e finalmente,
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.

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.

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.

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.

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

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.

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.

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.

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.

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:

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.

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!