BI e tomada de decisão (1/2)

Este é um artigo introdutório sobre Business Intelligence e seu papel central na tomada de decisão em empresas modernas. Se você não é um profissional de tecnologia, tem pouco ou nenhum conhecimento sobre o tema e não tem tempo ou paciência para ler um livro de 400 páginas sobre o assunto, acreditamos que esta pode ser uma leitura interessante para você.

Introdução

“The problem is at the top; management is the problem.”

Quando o engenheiro norte-americano William Edwards Deming, um dos “pais fundadores” da Qualidade e um dos maiores pensadores da gestão em todos os tempos, emitiu essa máxima, certamente ele não tinha por objetivo culpar os executivos e demais gestores das organizações. Com efeito, devemos entender essa afirmação como um aviso acerca da importância do papel desempenhado pelos gestores nos destinos das empresas que comandam. Nesta frase, Deming nos alerta que se os gestores executam mal o seu papel, as organizações e, por tabela, os clientes, empregados e a sociedade em geral, sofrem as consequências. Podemos dizer que nesse ponto Deming não foi exatamente inovador. Trata-se, efetivamente, de uma verdade muito fácil de constatar.

Bem, e que papel desempenham os gestores? Entre todos aqueles que poderíamos enumerar, sem sombra de dúvidas, a tomada de decisão encabeça a lista das responsabilidades cruciais de um gestor. Como nos ensinou Peter Drucker:

“A tomada de decisão é apenas uma das tarefas de um executivo. Geralmente consome uma pequena fração do seu tempo. Mas, tomar as decisões importantes é tarefa específica dos executivos”.

Ao contrário do que o senso comum muitas vezes nos leva a pensar, os bons decisores não nascem prontos. A capacidade de analisar problemas, desenvolver cenários e traçar planos de ação pode e deve ser desenvolvida por um gestor. Embora dependa, como quase tudo na vida, de um pouco de experiência e intuição, a boa tomada de decisão pode ser conseguida a partir do aprendizado de um processo e técnicas específicas. Dito isso, poderíamos nos perguntar: se existem técnicas que podem ser estudadas e aprendidas por qualquer um, por que tantas decisões se mostram equivocadas? Excluído o imponderável, aquilo que seria impossível prever e considerar, para responder a essa pergunta precisamos entender um pouco melhor o processo de tomada de decisão.

O processo de tomada de decisão, racionalmente falando, pode ser decomposto nas seguintes grandes etapas:

1. Entender a situação que demanda uma decisão e definir o(s) objetivo(s)

2. Elaborar uma lista das alternativas de decisão possíveis

3. Avaliar as decisões possíveis e escolher a melhor, aquela que mais colabora para o atingimento do objetivo buscado

Cada uma dessas etapas envolve uma série de atividades, mas não vamos detalhá-las aqui. O que gostaríamos de destacar é que o tomador de decisão sempre precisará do mesmo ingrediente básico e essencial ao longo de todo o processo: informação.

Gestores precisam de informação para bem definir a situação com que estão lidando, para identificar corretamente os objetivos da decisão, para combinar idéias e encontrar todas as possíveis causas que estão na origem do problema (bom ou mau) que se deseja resolver através da decisão. Sendo assim, com informação incorreta ou incompleta, os gestores correm o risco de desenvolver um entendimento enviesado do problema, ignorar soluções possíveis e/ou escolher uma que não seja a ótima. Ou seja, por ser um elemento indispensável à boa execução de todas as etapas do processo de tomada de decisão, a ausência de boas informações representa um grande risco para os tomadores de decisão. E aqui temos a resposta à pergunta em destaque. Podemos dizer que, associado ao desconhecimento do processo apresentado acima, das diversas técnicas associadas e vieses cognitivos de diversas naturezas, o amparo da decisão em informações incorretas ou incompletas é um dos principais motivos que levam os gestores a falharem na tomada de decisão.

A tecnologia no processo de tomada de decisão

Devido ao tamanho e complexidades das organizações atuais, quase sempre é impossível para um gestor examinar as informações necessárias a uma tomada de decisão sem o apoio da tecnologia. Foi para resolver o problema de reunir e manusear tantas informações durante o processo de tomada de decisão que um tipo específico de sistema da informação surgiu: os Sistemas de Suporte a Decisão (em inglês, Decision Support Systems — DSS).

A história dos DSS começa nas décadas de 50 e 60 com os pioneiros das universidades norte-americanas Carnegie Mellon e Massachusetts Institute of Technology (MIT). Mas, é na década de 70, quando o MIT desenvolve o conceito que ficou conhecido como Sistema de Informações Executivas (em inglês, Executive Information System — EIS) que os DSS começaram a ganhar as empresas. Os EIS, membros da família dos DSS, são softwares que têm por objetivo fornecer informações gerenciais a partir de uma base de dados. Através das ferramentas de consulta dos EIS, os gestores passaram a realizar o acompanhamento diário de resultados e tabular dados de todas as áreas funcionais da empresa de uma maneira gráfica, simples e amigável.

À medida que as mudanças tecnológicas e sociais se aceleraram e começaram a desafiar até mesmos os mais consagrados modelos de negócios, os executivos e, com a disseminação da prática do empowerment, os empregados passaram a tomar decisões cada vez mais importantes e com maior frequência. Em consequência, o mercado das soluções de DSS cresceu consistentemente ano após ano com a entrada de novos players e o surgimento de ferramentas cada vez mais sofisticadas. É nesse cenário e buscando dar respostas a esses novos desafios que, no ínicio da década de 90, irromperam o conceito e as primeiras ferramentas de Business Intelligence.

Business Intelligence: Conceitos principais

O termo Business Intelligence, doravante também chamado simplesmente de BI, é utilizado para referenciar uma série de tecnologias e técnicas empregadas para extrair, transformar e analisar grandes volumes de dados com vistas a produzir conhecimento sobre o passado e o presente das operações de um negócio, além de projeções a respeito de seu futuro. Quando falamos de conhecimento, estamos nos referindo ao ambiente interno (processos, grau de utilização e desempenho dos recursos) e externo (concorrentes, mercado, clientes) do negócio. Esse conhecimento, oriundo da análise ad-hoc ou automática dos dados, soma-se à experiência e ao background dos executivos durante os processos de tomada de decisão. Dessa forma, os sistemas de BI podem também ser classificados como sistemas de suporte a decisão (DSS).

Antes de prosseguir, aproveitamos para destacar que a expressão Business Intelligence comumente é empregada como uma espécie de termo “guarda-chuva” para fazer referência a uma série de outros conceitos mais específicos, entre os quais estão Data Mining, Business Performance Management, Online Analytical Processing (OLAP), análise preditiva, entre outros. Na verdade, estes conceitos estão associados ao BI e podem ser encarados como funções, tecnologias, métodos e técnicas que dão forma e conteúdo ao que se chama, desde um ponto de vista de negócios, genericamente de Business Intelligence.

Na primeira seção desse artigo, enfatizamos a importância dos processos de tomada de decisão na gestão de negócios. Ao mesmo tempo, observamos que os métodos de tomada de decisão baseados em informações são o que temos de melhor para este fim, mesmo que estes não possam garantir que a decisão tomada seja sempre correta. Para dar contexto à miríade de conceitos associados ao termo BI, seguiremos uma linha de raciocínio que consideramos lógica e que tem nessa constatação — superiores são as decisões baseadas em informações — o seu ponto de partida.

Um breve parêntese. Embora tenha surgido no final da década de 50, em artigo de pesquisadores da IBM, foi nos anos 90 que o termo Business Intelligence ganhou maior visibilidade e se disseminou a conotação que este possui hoje. Entre os principais pensadores do BI como o conhecemos hoje destacamos os cientistas da computação norte-americanos Ralph Kimball e Bill Inmon, autores de obras obrigatórias para aqueles que desejam se especializar no tema.

Retomemos. Se uma boa decisão deve ser embasada em fatos, podemos afirmar que todo processo de implantação de uma solução de suporte a decisão, o que inclui o BI, tão logo seja concluída a etapa de identificação dos tipos de decisões que deseja suportar (o que nós consultores costumamos chamar de “Business Requirements Assessment” ou “Business Analysis”), começa pelo mapeamento das informações que a empresa possui e que poderiam ser úteis ao sistema. Sabemos que uma boa parte das informações de uma empresa está armazenada eletronicamente em sistemas de informação baseados em bancos de dados. Logo, esse mapeamento inclui um esforço significativo de especialistas de tecnologia.

Entre esses sistemas, destacamos como exemplo os ERPs e CRMs. Dentro do universo de conceitos que compõem o BI, tais sistemas são classificados como transacionais ou OLTPs (OnLine Transaction Processing), pois foram criados para suportar as transações do dia a dia. Embora possuam opções de relatórios, estes sistemas têm por finalidade principal dar agilidade e precisão à execução das diversas atividades operacionais, não se preocupando em fornecer uma visão holística e analítica da organização. Essa visão virá justamente da utilização dos sistemas de BI sobre o agrupamento desses dados em Data Marts e Data Warehouses. Vamos, então, conceituá-los.

Um Data Warehouse (DW) é um banco de dados construído especificamente para a realização de consultas e geração de relatórios utilizando grandes volumes de dados. Enquanto os bancos de dados de sistemas transacionais são modelados somente para suportar as operações cotidianas e um conjunto de relatórios limitado aos dados de suas aplicações associadas, um DW normalmente agrega dados de uma série de sistemas. Além de suportar as decisões gerenciais, um DW caracteriza-se por não-volatilidade de dados (após as cargas de dados, normalmente apenas consultas são realizadas), estrutura definida por assunto (os assuntos de negócio que se deseja enfocar determinam os objetos do banco de dados), integração (dados de diferentes sistemas são pré-processados de maneira a refletir conceitos padronizados) e dados variáveis com o tempo (aos dados de um DW está sempre associado um instante no tempo. Por sua vez, bases de dados transacionais não objetivam armazenar grandes históricos, concentrando-se, geralmente, em guardar somente as informações necessárias ao cenário atual de negócios).

Já um Data Mart (DM) pode ser definido como uma fração do DW, geralmente contendo somente os dados de interesse de um departamento ou área de negócios de uma organização. Seu maior objetivo é propiciar um ganho de agilidade a times específicos da empresa no acesso aos dados que são de seu interesse mais recorrente. Assim, com o uso de DMs, evita-se que todas as consultas e manipulações de dados (que podem ser complexas) sejam direcionadas ao DW diretamente, possibilitando uma melhor racionalização dos investimentos necessários em recursos computacionais para atender as demandas de BI e uma melhor separação de responsabilidades. Isto posto, concluímos afirmando que os DMs compartilham das mesmas propriedades de um DW, sendo construídos com os mesmos princípios. Vale destacar que os possíveis DMs de uma empresa podem se relacionar entre si.

Entendidos os conceitos de DM e DW, podemos avançar confiantes em nosso passeio pelos conceitos do BI buscando entender como são populados esses grandes bancos de dados. O processo de carga de dados de um DW merece um destaque especial porque soluções para esse fim estão presentes em todos os principais pacotes de BI do mercado. Estamos falando de Extract, Transform and Load ou, simplesmente, ETL. Durante o processo de desenvolvimento de um DW são identificadas as questões de negócios que estes irão suportar, suas estruturas e quais os sistemas serão fornecedores dos dados. O processo e tecnologias de ETL são justamente as responsáveis por mover os dados dessas diversas fontes (as bases de dados dos sistemas transacionais da organização) para estes grandes armazéns de dados que funcionam como um alicerce para as demais ferramentas de BI.

Durante a etapa de extração (Extract), as diversas fontes de dados são consultadas para captura das informações que foram identificadas como importantes para o DW. Essas fontes de dados podem ser de natureza diversa, sendo as mais comuns, como já mencionamos, os bancos de dados relacionais. As soluções de ETL fornecidas pelos grandes fornecedores são capazes de extrair dados de praticamente qualquer banco de dados do mercado, além de arquivos texto, bases hierárquicas e mesmo de sites da Internet. Sabendo que, no processo de popular o DW, as informações extraídas das diversas fontes geralmente precisam passar por uma crítica de sua qualidade, é fácil deduzir que as capacidades de parsing e manipulação de dados oferecidas por estas soluções são bastante extensas. Essas capacidades permitem que critérios definidos pelo desenvolvedor do script de extração especifiquem o que será feito com os registros lidos. Nem todos serão elegíveis para a próxima etapa do processo.

Durante a etapa de transformação (Transform), regras técnicas e de negócios são aplicadas sobre os dados capturados pelos scripts de extração nos diversos sistemas. Essas regras executam operações de limpeza, sumarização, derivação, agregação e integração sobre os dados. Vejamos o que significam essas operações:

• Limpeza (Cleansing)

Os dados que violam regras de negócio ou que foram registrados com alguma falha devem ser corrigidos antes de serem carregados no DW. Esses dados são considerados “sujos”, por isso o nome desta operação que visa garantir a integridade dos dados do DW.

• Sumarização (Summarization)

Algumas colunas das tabelas do DW podem ter sido pensadas para armazenar valores agregados (contagens, somas, médias, etc) obtidos a partir de um conjunto de dados das fontes primárias. É essa operação que permite esse tipo de transformação.

• Derivação (Derivation)

É comum que seja requerida a carga de um valor que não consta nos dados capturados durante a extração, mas seja passível de ser obtido ou calculado a partir desses dados. A derivação é uma operação que permite que lógica de programação, consulta a tabelas de apoio e cálculos matemáticos sejam utilizados para gerar novos dados.

• Agregação (Aggregation)

Algumas das tabelas do DW podem representar entidades de negócio cuja informação está dispersa em diversos sistemas fontes. A operação de agregação visa reunir essas informações para carga na etapa seguinte.

• Integração (Integration)

Muitas vezes o mesmo dado é representado de forma diferente em sistemas distintos. Um exemplo: As vendas realizadas em um período foram registradas em dólares no sistema X da matriz americana, enquanto que no sistema Y da filial brasileira as vendas foram registradas em reais. São dados semanticamente equivalentes com representações distintas e a operação de integração tem o objetivo de padronizá-las antes da carga em uma solução de BI destinada aos executivos globais da organização, por exemplo.

Como última etapa do processo ETL, a Carga (Load) é responsável por inserir os dados transformados no DW. O carregamento propriamente dito pode acontecer de acordo com diversas periodicidades. O que as determinará são, principalmente, critérios de negócio. Algumas informações precisam estar atualizadas de hora em hora, outras diariamente, enquanto algumas não fazem sentido serem carregadas todos os dias, pois o horizonte de análise utilizado é medido em semanas, meses ou, até mesmo, anos. À parte dos critérios de negócio, fatores de natureza mais técnica poderão também influenciar quando as cargas são realizadas. Carregar grandes volumes de dados durante determinados horários do dia pode deixar o DW lento para seus usuários, desse modo são privilegiados os horários de menor atividade de consulta para as cargas (à noite, normalmente). Outro ponto que merece destaque: os scripts de carga também podem realizar sumarizações. Podemos ter um script responsável por sumarizar os dados carregados de hora em hora e produzir um único registro que corresponda ao dia, outro para produzir um agregado mensal a partir dos sumários diários e assim sucessivamente. Mais uma vez os critérios de negócio e técnicos se combinam para determinar os tipos de sumarização e quando acontecem.

Nesse momento da nossa jornada já temos a infraestrutura básica das soluções de BI: DWs e DMs estruturados e repletos de dados obtidos a partir dos sistemas transacionais através de scripts de ETL. Está na hora de aprofundarmo-nos sobre as ferramentas utilizadas para investigar esses dados e obter informações úteis a partir deles.

O tipo mais simples de utilização de um pacote de BI é como ferramenta de relatórios (Reporting ou Querying). Todos os pacotes do mercado, sejam eles pagos ou gratuitos, possuem módulos com capacidade de design de relatórios. Esses módulos permitem a criação, normalmente com pouca ou nenhuma programação, de relatórios de qualquer complexidade utilizando diversos tipos de fontes de dados, incluindo, claro, o DW. Tais relatórios podem conter tabelas, gráficos de uma enormidade de tipos, textos livres, imagens, etc. Considerando exclusivamente as capacidades de geração de gráficos e tabelas, praticamente tudo que se pode produzir em um sistema de planilhas eletrônicas ou num editor de textos tradicional é possível de se conseguir também com essas ferramentas. As vantagens mais imediatas desses pacotes sobre as suítes de escritório estão relacionadas às capacidades de automatização do processo de geração, distribuição e escalabilidade desses relatórios. Enquanto a produção de um relatório num sistema de planilhas eletrônicas ou num editor de texto convencional é um processo “artesanal”, as ferramentas de reporting de um pacote de BI permitem a criação de “templates” que, de forma transparente para o usuário, leem as informações de um DW e produzem saídas em um ou mais formatos especificados. Por falar em formatos, esses podem ser praticamente qualquer um que se imagine: HTML, DOC, PDF, XLS, ODF, só para citar os mais comuns.

Como já mencionado, um importante diferencial desses pacotes é a possibilidade de se configurar uma periodicidade para a geração automática de relatórios e listas de distribuição segundo uma grande variedade de critérios. Em uma empresa que explora essas capacidades, o diretor comercial pode receber diariamente e-mails com relatórios das vendas hora a hora do dia anterior, por exemplo. Ou então receber alertas quando as vendas semanais caem abaixo da meta estipulada. Tudo isso sem que ninguém precise trabalhar na geração desses informes. Além disso, esses relatórios podem ser configurados, e via de regra o são, como páginas dinâmicas da web, o que possibilita a utilização da solução de BI como um EIS tradicional. Enfim, as possibilidades são muitas, variam de ferramenta para ferramenta, e mencionamos somente algumas delas aqui.

Um outro conceito muito poderoso encontrado no universo de BI é o Online Analytical Processing (OLAP). Através do OLAP, um conceito relacionado à interface de usuário das soluções de BI, é possível realizar análises multidimensionais sobre os dados de um DW. Mas, afinal de contas o que são “Análises Multidimensionais”? Para entender esse conceito e, consequentemente, a abordagem OLAP, precisamos voltar um pouco ao DW e à maneira como estes são modelados. Nesse retorno, entenderemos também um pouco mais sobre como um DW é estruturado.

Já afirmamos que um DW é composto de diversas tabelas estruturadas por assuntos de negócio. Essas tabelas, no jargão dos especialistas, são conhecidas como “Tabelas Fato” (Fact Tables). Uma Tabela Fato contém as métricas (medidas brutas, resultantes de medições e contagens, que são combinadas para a definição de indicadores) definidas para um processo de negócio. Associada a essas tabelas existe um conjunto de tabelas de apoio conhecidas como Tabelas Dimensão (Dimension Tables). Enquanto as Tabelas Fato contém normalmente números, as Tabelas Dimensão contém atributos que situam esses números em contextos de informação, dando sentido a eles. Um exemplo vai nos ajudar a compreender melhor esse tema que, de fato, é um pouco abstrato.

Imagine que o CEO de uma fabricante de sapatos, uma empresa familiar e de médio porte, autorizou o orçamento para implantar uma solução de BI. O contexto é de urgência, pois um conjunto de metas agressivas para o próximo biênio foi imposto pelos acionistas e o desenho da estratégia para atingí-las tem sofrido atrasos devido à necessidade de reunir e agregar alguns dados, disponíveis, mas dispersos em relatórios diferentes. Foram estabelecidos objetivos de aumento de vendas (de +20% a +30% de Unidades Vendidas, variando com a linha de produtos) e rentabilidade (+15% de Margem Líquida no resultado global), entre outros. Num momento em que a empresa está sofrendo uma forte competição de importados asiáticos, que estão entrando no mercado a preços assustadoramente baixos, atingir essas metas parece ser algo extremamente desafiador, quiçá impossível. Foi nesse cenário que o CIO conseguiu convencer o seu chefe de que uma solução de BI poderia diminuir o risco das decisões a serem tomadas para atingir as metas estipuladas pelo conselho. Mãos a obra, consultoria contratada, um dos processos que mereceu maior atenção foi, com toda razão, o de Vendas. Analisando este processo, a consultoria e os stakeholders da companhia envolvidos no projeto, depois de um intenso brainstorming sobre as questões de negócio a serem respondidas pelo futuro sistema, escolheram alguns indicadores para monitorar a sua eficiência e orientar as mudanças que certamente serão necessárias.

Para o objetivo que desejamos atingir aqui, explicar o que são fatos, dimensões e análises multidimensionais, vamos nos restringir à métrica mais simples de um processo de vendas: Unidades Vendidas. Importante destacar que a empresa fabrica sapatos esportivos e de passeio, sendo que oferece, em média, 10 modelos do primeiro tipo e 30 modelos do segundo em seu portfolio de produtos (os modelos são atualizados periodicamente segundo critérios do mercado). Seus produtos são vendidos em supermercados, lojas de departamentos e material esportivo e em sapatarias de todo o Brasil, num total de mais de 2000 postos de vendas, além da Internet.

Através de um levantamento realizado com os executivos, os analistas de negócios da consultoria identificaram que eles precisam de respostas rápidas para perguntas como:

1- Como está a tendência de vendas de nossos produtos em cidades com até 100.000 habitantes?

2- Nessas cidades, nossos tênis Sport Champion+ (o topo da gama dos produtos esportivos da empresa) são mais vendidos em lojas de material esportivos ou sapatarias?

Apresentadas essas demandas aos analistas de sistemas da consultoria, estes sugeriram que, para o assunto Vendas, o DW deveria conter uma Tabela Fato de Vendas (FAT_VENDAS) e as seguintes tabelas de Dimensões: Tempo (DIM_TEMPO), Produto (DIM_PRODUTO) e Ponto de Vendas (DIM_POSTO_VENDA). No final da modelagem, a estrutura proposta para este tema foi a mostrada abaixo:

Tabela Fato Vendas e suas dimensões associadas

Vejam que a tabela Vendas (FAT_VENDAS) contém a métrica que se deseja monitorar (Unidades Vendidas) e chaves estrangeiras para as tabelas de dimensões. Estas, por sua vez, guardam relações com outras tabelas em um desdobramento hierárquico que justifica o nome desse tipo de modelo: Snowflake Schema (“esquema floco de neve”), uma das formas de se modelar o banco de dados do DW. Aspectos técnicos a parte, examinando novamente a primeira pergunta realizada pelos executivos e o diagrama acima não fica difícil entender o porquê dessa estrutura. Vejamos:

Como estão as vendas de nossos produtos em cidades com até 100.000 habitantes?

Esta é nitidamente uma pergunta que demanda análise multidimensional, pois o que se deseja saber encontra-se no cruzamento de duas dimensões (Produto e Cidades, esta via Ponto de Venda). É esse tipo de análise que a tecnologia OLAP permite fazer, não somente para responder questões pré-determinadas, como mostrado aqui (isso os EIS e relatórios tradicionais fazem muito bem), mas, principalmente, para responder a questionamentos não previstos inicialmente. Através de operações OLAP como slicing, dicing, drill down/up e pivoting, os “cubos de dados” podem ser explorados para responder a algumas das perguntas mais criativas e inusitadas que podem ocorrer a um executivo. No exemplo específico tratado aqui, podemos ir além e afirmar que, da forma como está estruturado o assunto vendas no DW, através de uma ferramenta OLAP, os executivos poderão responder a qualquer pergunta que envolva saber as unidades vendidas para os diversos produtos da empresa (dimensão Produto), em qualquer momento do tempo (dimensão Tempo) e local (dimensão Ponto de Vendas).

Começamos a falar de OLAP mencionando que se trata de um conceito relacionado à interface de usuário e acabamos entrando em uma discussão acerca de como os dados são armazenados no DW. Talvez isso tenha gerado alguma confusão. Vamos desfazê-la então.

Como recurso de interface de usuário, as ferramentas OLAP expõem os dados de um DW de uma forma tal que o usuário pode executar uma exploração ad-hoc dos mesmos por meio de um conjunto de operações (que mencionamos acima). No slicing, por exemplo, o usuário fixa valores para uma dimensão. No case que criamos para fins de ilustração, restringir os dados analisados exclusivamente àqueles associados ao produto Sport Champion+ é um slicing (pela dimensão Produto, no caso). Se isso se parece com um filtro é porque, na prática, corresponde à seleção de um ou mais valores em uma lista (ou qualquer componente de interface equivalente), assim dizendo, é um filtro! Esse processo de “fatiar o cubo” pode envolver quantas dimensões se deseje (operação que, ao involver 2 ou mais dimensões, deixa de se chamar slicing e passa a ser conhecida como dicing). Outra operação possibilitada pelo OLAP é o drill down/up. Ainda falando do nosso case exemplo, poderíamos navegar de visualizações de unidades vendidas por trimestre até por dia. A alternância de visualização de dados mais agregados (por trimestre) para dados mais granulares (diários) corresponde a um drill down. Quando a navegação se dá no sentido inverso, da informação mais granular para a mais agregada, temos um drill up.

Por fim, importante destacar que para se conseguir a velocidade necessária para análises interativas, é comum que algumas ferramentas criem e mantenham atualizadas representações otimizadas de parte das informações do DW, os famosos cubos de dados, agrupamentos de “fatos” e suas agregações com suas dimensões associadas. Essa característica de pré-processamento de dados e criação de cubos de dados é a que define o MOLAP (Multidimensional OLAP), o tipo mais clássico de OLAP, por exemplo.

Bem… Acredito que esse artigo já vai um pouco longo. Continuarei em uma 2a parte.