UNIDADE 2

Parabéns! Você chegou na etapa 2 dessa disciplina!

Com cada vez mais dados à disposição dos tomadores de decisão, fica também mais difícil se concentrar nas informações relevantes para os problemas e principalmente apresentá-las de forma prática. O Business Intelligence ajuda os gestores nessa organização e na tomada de decisão. Como verificamos na unidade 1, Business Intelligence não é uma única ferramenta, mas diversas técnicas de extração e manipulação de dados.

Business Intelligence é uma metodologia pela qual se estabelecem ferramentas para obter, organizar, analisar e prover acesso às informações necessárias para que os tomadores de decisão das empresas analisem os fenômenos acerca de seus negócios.

É importante lembrar que uma solução de Business Intelligence por si só não traz resultados, afinal, abrir seus relatórios uma vez ou outra não significa fazer bom proveito dos dados, e muito menos que essa consulta trará ações concretas. Assim, é preciso que todos dentro da organização adotem de forma massiva sua utilização.

No artigo Um estudo de caso envolvendo Business Intelligence como instrumento de apoio à controladoria, os autores investigaram a contribuição do Business Intelligence (BI) para a área de controladoria. No estudo, os autores verificam o antes e depois da implementação do BI. Após a análise das entrevistas, dos indicadores das áreas e de seu impacto no resultado global da empresa, os autores verificaram que o BI pode auxiliar a controladoria na função de prover informações confiáveis, úteis e tempestivas ao processo decisório, por meio de sua flexibilização e dinamicidade, proporcionando, como consequência, a melhoria dos resultados das áreas organizacionais, bem como da empresa como um todo.

Vamos conhecer, então, algumas ferramentas de Business Intelligence disponíveis no mercado?

1. Board

2. Domo

3. Dundas

4. Google Data Studio

5. Looker

6. Microsoft Power BI

Toda a solução de BI inicia com os Data Warehouses. Data Warehouses são bancos de dados analíticos, projetados para armazenar os dados de fontes diversas, já transformados e preparados para a realização de consultas através de operações OLTP (On line Transaction Processing – Processamento de transação on-line).

Veja quais são as principais características de um Data Warehouse.

No webinar A importância da modelagem do Data Warehouse em um projeto de TI, o professor Fernando Hadad Zaidan trata da importância da Data Warehouse em um projeto de BI, bem como suas particularidades e possíveis estruturas e elementos.

Outro importante conceito que devemos compreender é o de modelagem de banco de dados. A modelagem multidimensional é uma técnica de modelagem de bancos de dados que se destina a apoiar as consultas realizadas pelo usuário final em um Data Warehouse. A técnica de modelagem multidimensional trata da elaboração de um projeto lógico de um banco de dados, que tem sua aplicação destinada à análise de dados. O Star Model é a estratégia de modelagem mais utilizada na construção de modelos multidimensionais para ambientes Data Warehouse. Seu objetivo é dar suporte à tomada de decisão e melhorar o desempenho das consultas em ambientes multidimensionais. Já o modelo Snowflake é muito próximo do que é conhecido da modelagem tradicional de banco de dados, uma vez que, durante sua construção, são levadas em consideração as formas normais.

Na arquitetura de um Data Warehouse, uma importante etapa é a ETL (Extrat, Transform and Load - em português, Extração, Transformação e Carga). Essa é a etapa responsável por pegar os dados da fonte, prepará-los e armazená-los em um banco de dados multidimensional

A ETL é responsável por fazer a integração entre as camadas de um Data Warehouse a partir das fontes de dados, além de tratar e armazenar esses dados em um banco de dados multidimensional no Data Warehouse. No mercado, existem diversas ferramentas que realizam o processo de ETL, cada uma com a sua particularidade. Tais ferramentas são softwares específicos, nos quais você pode identificar sua fonte provedora, selecionar os métodos de pré-processamento e transformação, posteriormente selecionando a fonte de origem (banco de dados multidimensional).

Sabemos que os dados de um Data Warehouse podem ser explorados por diversas perspectivas, ou seja, explorando a multidimensionalidade do modelo criado. O cubo de dados é uma representação abstrata da representação analítica dos dados armazenados multidimensionalmente. De modo simples, o cubo é uma metáfora visual. Os dados são vistos de acordo com as dimensões.

As fontes de dados são definidas pelo cenário de aplicação, a área de preparação definida pela ETL, que, ao fim, realiza a carga no banco de dados multidimensional. O servidor OLAP representa a camada de apresentação, fornecendo os dados através de suas operações. Uma vez feito isso, os dados já estão pré-processados, limpos e armazenados, desse modo estando prontos para que sejam consumidos pelas aplicações. As ferramentas de apresentação podem ser uma aplicação específica ou, o caso mais convencional, a utilização de uma ferramenta para a geração de dashboards.

Na próxima etapa, trataremos em detalhes sobre as ferramentas de dashbords e suas aplicações em cenário de Business Intelligence.

Bons estudos!

OBJETIVOS DE APRENDIZAGEM

A partir da perspectiva do saber fazer, neste capítulo você terá os seguintes objetivos de aprendizagem:

• saber como funciona o do processo de análise de dados, modelagem multidimensional e os tipos de modelos;

• conhecer o que é um Data Warehouse e seus elementos e o que é um cenário de Business Intelligence;

• conhecer todas as etapas de construção, desde a etapa de coleta, transformação dos dados e alimentação de um Data Warehouse;

• realizar a extração, transformação e carga e a modelagem multidimensional;

• armazenar dados em um Data Warehouse;

• realizar consultas OLAP em cenários de business intelligence.

1 - INTRODUÇÃO AO DATA WAREHOUSE E BUSINESS INTELLIGENCE

Finalizamos o capítulo anterior falando sobre Business Intelligence (BI), seu poder e possibilidades na geração de conhecimento. Business intelligence, muitas vezes, é difícil de ser compreendido, pois não se trata de uma única ferramenta, mas de diversas técnicas de extração e manipulação. Na definição que surgiu em 1989, por Howard Dresner, business intelligence é uma metodologia pela qual se estabelecem ferramentas para obter, organizar, analisar e prover acesso às informações necessárias aos tomadores de decisão das empresas para analisarem os fenômenos acerca de seus negócios, ou seja, business intelligence não é uma ferramenta, mas uma metodologia, que pode empregar uma ou diversas ferramentas de acordo com o cenário de sua aplicação.

A escolha de uma estratégia, ou de um conjunto delas, depende muito do cenário em que será aplicado e caberá ao profissional responsável conhecimento sobre o cenário e sobre as estratégias. Infelizmente, nosso livro teria que ter mais de 10.000 páginas para poder explicar todos os cenários possíveis de aplicações de dados desde cenários de venda, compra, empréstimos, financiamentos, operadoras de crédito, bolsa de valores, redes sociais, enfim, uma infinitude deles. Porém, vamos aprender a partir de agora como coletar esses dados e quais são as ferramentas para processá-los e analisá-los, permitindo a construção de fantásticos dashboards analíticos.

Vamos estudar o processo de Data Warehousing, no qual você compreenderá os principais métodos de coleta de dados, as principais estratégias de processamento, bem como o armazenamento e posterior análises multidimensionais. Uma vez realizado este processo, diversos processos de business intelligence podem ser integrados, como mineração de dados e geração de dashboards.

O processo de geração do conhecimento geralmente inicia com os bancos de dados relacionais. Estes bancos de dados estão no mercado desde os anos 1970 e têm sua eficiência inegável, principalmente, no que se refere à segurança e integridade dos dados armazenados. No entanto, a arquitetura desses bancos de dados foi projetada para a realização de transações bancárias, e mesmo que não seja um sistema bancário, diz-se que um sistema de gestão realiza uma transação, que nada mais é do que um conjunto de funções, executadas num banco de dados, que o usuário percebe como uma única ação. Por exemplo, ao realizar uma venda, nem sempre se trata de inserir um registro na tabela de venda, por exemplo, insere os registros de produtos vendidos, dá baixa no estoque e insere o valor do saldo. Todas estas funções caracterizam-se como uma única transação.

Os bancos de dados tradicionais que trabalham orientados a transações são chamados de OLTP (Online Transaction Processing – Processamento de Transações On-line), porém, conforme havíamos abordado anteriormente, o foco desta abordagem são as transações. Muitas vezes, os conceitos de Business Intelligence e Sistemas de Apoio à Decisão são confundidos com os próprios sistemas gerenciais, afinal ainda que utilizem uma arquitetura OLTP, tais sistemas permitem a extração de relatórios gerenciais: produtos mais vendidos, clientes que mais compram, saldo total. O que você precisa entender é que relatórios extraídos de sistemas de gestão não é business intelligence, relatórios são relatórios. Vamos explicar isso detalhadamente para ficar claro no decorrer deste capítulo.

Se você já teve a disciplina de banco de dados ou já estudou boas práticas, com certeza, aprendeu as formas normais e respectivamente que a normalização nos obriga a criar mais tabelas. Uma vez tendo criadas mais tabelas, isto ajuda a amplificar a garantia da integridade dos dados armazenados, no entanto há um problema: as consultas.

Uma vez que ao normalizar um banco de dados se criam diversas tabelas, as consultas mais complexas necessitam de junções. Ou seja, conectar várias tabelas para responder a estas consultas. Em um banco de dados pequeno, o aumento do tempo de execução das consultas utilizando junções pode não ser notado, no entanto, sabendo que um cenário de business intelligence irá integrar diversos setores da empresa, com um volume significativo de dados, quanto mais tabelas existirem, maior será o tempo de execução.

A partir de agora você conhecerá um pouco mais sobre a construção de um projeto de business intelligence, que acontece durante a concepção de um Data Warehouse, visto na próxima seção.

Tendências para business intelligence em 2019

Em nosso livro estamos discutindo as estratégias para construção de um business intelligence. No entanto, estamos vendo abordagens tradicionais, consolidadas pela academia e mercado. Também é importante levar em consideração o cenário de inovação tecnológica mundial e como essa inovação implica cenários de business intelligence. Para isto, nesse texto, trazemos duas abordagens, as principais estratégias (conceitos e metodologias) e as principais ferramentas.

Os últimos anos têm sido de inovações na área de análise de dados, além de aprimoramentos de produtos e serviços, levando as organizações a uma análise sobre como priorizar uma abordagem moderna de business intelligence que conduza a empresa a obter o máximo valor dos seus dados.

Pensando no quem vem pela frente, Adriano Chemin, vice-presidente da Tableau para América Latina, empresa de software para análise visual de dados, reuniu as principais tendências de business intelligence para os próximos anos, são elas:

Inteligência artificial explicável

Que a inteligência artificial (AI) veio para ficar é fato, graças ao aprendizado de máquina empresas conseguem criar clusters de comportamento, identificar tendências de mercado, avaliar riscos, tomar decisões rápidas e automatizar milhões de atividades que antes consumiam tempo e recursos. Não dá para negar que o AI abriu um mundo de possibilidades para o universo de BI, e que muitas das evoluções que estamos vendo (e que veremos nos próximos anos) foram conquistadas graças às possibilidades oferecidas pela tecnologia de AI.

Por outro lado, quanto mais dependemos da AI, maior é nossa desconfiança quanto à credibilidade das recomendações baseadas em modelos, já que grande parte das ferramentas que utilizam aprendizado de máquina não fornecem uma forma transparente de ver os algoritmos ou a lógica por trás das decisões e das recomendações. É aí que vem o AI Explicável, a prática de compreender e apresentar exibições transparentes dos modelos de aprendizado de máquina. Se é possível questionar seres humanos, por que não ter a mesma opção com o aprendizado de máquina na tomada de decisões?

A AI Explicável permite que o corpo executivo, cientistas e analistas de dados entendam e questionem a forma como o aprendizado de máquina é aplicado no dia a dia de uma empresa, gerando mais transparência e confiabilidade nos resultados.

Linguagem natural transforma a dinâmica das organizações

O processamento de linguagem natural (NLP) está quebrando paradigmas em todos os campos da tecnologia e mudando a forma como as pessoas trabalham, ouvem música, solicitam informações sobre o tempo e, cada vez mais, obtém respostas sobre um painel de dados.

A habilidade de obter respostas por meio de um comando de voz permite que pessoas com todos os níveis de conhecimento possam questionar seus dados, e ao perguntar, obter uma resposta concreta e veloz. Paralelamente, a linguagem natural está evoluindo para dar suporte à conversação analítica, ou seja, a conversa entre o ser humano e o sistema sobre seus dados. O sistema aproveita o contexto da conversa para entender a intenção por trás da consulta do usuário e promover o diálogo, criando uma experiência de conversação cada vez mais natural.

À medida que a linguagem natural evolui com o setor de BI, ela abrirá portas para a adoção de análise e ajudará a transformar ambientes de trabalho em operações autônomas e impulsionadas por dados. O NPL eleva o patamar analítico das organizações como um todo, permitindo que um CEO atarefado, ou um analista de marketing sem tanta destreza com análises numéricas obtenham as respostas que necessitam para executar seu trabalho de forma precisa.

Análise acionável: mobilidade dos dados impulsiona ações

Velocidade é palavra-chave na vida de quem trabalha com análise de dados na atualidade, seja no acesso às informações ou no tempo de resposta para executar a ação necessária, tudo precisa estar alinhado em um único fluxo de trabalho e disponível no lugar e no dispositivo que o cientista/analista de dados desejar para que ele possa agir rápido.

Pensando nisso, fornecedores de plataformas de BI oferecem análise em dispositivos móveis, análise incorporada, extensões de painel e APIs que incorporam a análise ao local onde as pessoas executam seu trabalho evitando a troca de aplicativos (ou servidores) desnecessária e melhorando o fluxo de trabalho.

A mobilidade permite, por exemplo, que o CEO de uma empresa acompanhe a evolução de seus negócios de qualquer lugar do mundo, e acione sua equipe em tempo real. A incorporação da análise em fluxos de trabalho diversos, leva ao que chamamos de análise acionável, um avanço poderoso que promete atender às necessidades analíticas dos mais diversos departamentos, e empoderar funcionários de diferentes setores por meio de dados contextualizados e sob demanda.

Storytelling é a nova linguagem dos dados

Dados são a forma mais poderosa de comunicar uma descoberta, apresentar um insight ou expor seus resultados, e nada como o storytelling para gerar aquele impacto positivo. Storytelling analítico, ou contar uma história por meio de dados, é uma das tendências mais marcantes do mundo do BI, e uma forma muito mais atraente de expor todas as etapas das suas análises de forma acionável e fácil de entender.

À medida que as empresas criam uma cultura de análise, contar histórias com dados tem ganhado novos significados. Ao invés de apresentar uma conclusão única, o storytelling promove a criação de um diálogo e contribui para uma abordagem coletiva da análise. Com o storytelling, tanto o criador do painel como o público se tornam responsáveis por chegar a uma conclusão sobre o que os dados estão dizendo – estimulando a diversidade de ideias e promovendo o trabalho coletivo ou cocriação de painéis.

Comunidade analítica

Ter uma plataforma de BI funcionando não significa extrair o máximo potencial dessa ferramenta. E por mais duro que pareça, o fato de alguém, ou um determinado departamento abrir relatórios uma vez ou outra, não significa fazer bom proveito dos dados, e muito menos que essa consulta trará ações concretas ou terá efeitos práticos. De nada adianta ter o BI dos sonhos se não houver adoção massiva da ferramenta. Em muitas empresas a adoção de uma plataforma de BI de sucesso começa com o alto escalão da empresa e com a percepção de que é preciso integrar as diferentes fontes de dados e extrair valor. E para gerar valor, nada como uma comunidade interna de usuários engajados, e métricas concretas para determinar como as pessoas estão usando a plataforma de BI para causar um impacto nos negócios.

Falando em comunidade, empresas do mundo todo já perceberam o poder da cocriação analítica, e como pessoas com um background diferente conseguem trabalhar juntas para estabelecer métricas e descobrir insights por meio dos dados. O BI de autoatendimento democratizou o acesso à informação nas empresas. Agora o desafio é fomentar comunidades engajadas, transformar informação em ação e claro, medir os resultados. E viva o trabalho em equipe.

Com cada vez mais dados à nossa disposição, é cada vez mais difícil nos concentrar nas informações relevantes para os nossos problemas e apresentá-las de forma prática. É disso que trata o Business Intelligence. Complementarmente às tendências vistas anteriormente, veremos um pouco sobre as ferramentas que estão tomando conta do mercado de business intelligence.

Board: a Board International combina três ferramentas em uma: BI, análise preditiva e gerenciamento de desempenho. Oferece módulos para finanças (planejamento, consolidação), RH (mapeamento de habilidades, planejamento de força de trabalho), marketing (análise de mídias sociais, monitoramento de lealdade e retenção), cadeia de suprimentos (otimização de entrega, gerenciamento de fornecedores), vendas (análise de cross-selling e up-selling) e TI (KPIs, níveis de serviço). A empresa é suíça, mas o software está disponível em inglês, espanhol, chinês, japonês, francês, alemão e italiano.

• Público-alvo: variado.

• Recursos notáveis: suporte a idiomas.

• Preço: a taxa de licença por usuário varia de acordo com a função.

Domo: a Domo é uma plataforma baseada na nuvem que oferece ferramentas de business intelligence adaptadas a vários setores (como serviços financeiros, assistência médica, manufatura e educação) e funções (incluindo CEOs, vendas, profissionais de BI e trabalhadores de TI). Os CIOs podem começar verificando como a Domo lida com dados da AWS, Jira, GitHub ou New Relic antes de analisar como mais de 500 outras integrações podem ajudar o restante da empresa.

• Recursos notáveis: interface móvel robusta.

• Preços: taxa de licença anual. O plano profissional limita o armazenamento de dados a 250 milhões de linhas; não há limites no plano da empresa.

Dundas BI: o Dundas BI, da Dundas Data Visualization, é mais usado para criar dashboards e scorecards, mas também pode gerar relatórios padrão e ad-hoc. A análise e a visualização são realizadas por meio de uma interface da Web que pode se adaptar às habilidades dos usuários: usuários avançados e usuários padrão veem recursos diferentes. A versão mais recente pode extrair dados do Google Analytics, Snowflake e Salesforce Pardot, entre outras fontes. O Dundas BI foi adaptado para 19 indústrias, incluindo tecnologia limpa, mineração e construção, além de serviços bancários e de saúde.

• Recursos notáveis: interface HTML5 flexível que se adapta a qualquer dispositivo.

• Preço: com base em usuários simultâneos.

Google Data Studio: sabemos que o Google está constantemente analisando a web, mas o que ele pode fazer com nossos dados corporativos? O Google Data Studio começou como uma ferramenta para dashboards e relatórios sobre dados do Google Analytics. Agora ele tem sido sobrecarregado com acesso a informações de Recrutamento, Marketing e Vendas também, por meio de conectores para a Criteo, LinkedIn, MailChimp, PayPal, Salesforce, Stripe, Twitter e qualquer coisa que você possa colocar em uma planilha ou banco de dados SQL. Naturalmente, está hospedado na nuvem e tem uma interface da web.

• Características notáveis: o preço.

• Preços: grátis.

Looker: a Looker adota uma abordagem dupla para o business intelligence: permite que os usuários explorem os dados a sua maneira, mas também trabalha com especialistas para ajudar aqueles que realmente não sabem o que estão procurando. Faz isso permitindo que outros fornecedores de software envolvam seus recursos de análise em aplicativos verticais “Powered by Looker”. A partir do início do ano que vem, ele se conectará ao serviço BQML (BigQuery Machine Learning) do Google para desenvolver modelos preditivos.

• Recursos notáveis: baseados na Web, podem acessar dados ao vivo de qualquer banco de dados SQL.

• Preço: sob demanda, varia de acordo com o número de usuários e conexões do banco de dados.

Microsoft Power BI: com o aplicativo Power BI Desktop para Windows, os usuários podem analisar e visualizar dados de fontes locais ou da nuvem, publicando seus relatórios na plataforma Power BI. A versão gratuita Author atende a usuários isolados; a versão Pro facilita a análise colaborativa, por uma taxa mensal, aproveitando o Microsoft Office365, o SharePoint e as equipes para controlar o acesso a dados brutos e aos relatórios publicados. Para empresas que desejam mais, a camada Premium possibilita a preparação de dados de autoatendimento com conectores pré-construídos para dados corporativos mantidos no Microsoft Dynamics 365, Azure SQL Data Warehouse ou fontes de terceiros, como Salesforce.

• Recursos notáveis: o aplicativo para dispositivos móveis permite a anotação na tela de toque dos relatórios.

• Preços: três níveis: Author (gratuito), Pro (US $ 9,99 por usuário por mês) e Premium (com base na capacidade).

Qlik: o objetivo da Qlik é dar a qualquer pessoa na empresa acesso a todos os dados – sujeito, é claro, às políticas corporativas de governança de dados. Pode associar determinados dados a todos os demais para facilitar a busca por conexões. O Qlik Sense, a ferramenta de autoatendimento para acessar esse recurso analítico, vem nas versões em nuvem e on-premise.

• Recursos notáveis: o Associative Engine pode analisar todos os seus dados, em tempo real.

• Preços: versões limitadas são gratuitas; as funções de colaboração custam de US$ 15 por usuário ao mês para o Qlik Sense Cloud Business.

Salesforce: o Einstein Analytics é a tentativa da Salesforce.com de melhorar o BI com a inteligência artificial. Seu objetivo é estender o acesso de autoatendimento aos dados para os usuários em toda a empresa, com uma aparência semelhante à das interfaces Reports e Dashboard. O Einstein Discovery permite que os usuários criem modelos preditivos a partir de seus dados, o que não se limita aos dados mantidos na nuvem do Salesforce: o Einstein pode extrair dados do Oracle, do SAP e de outras fontes. Existem modelos específicos para cada setor e ferramentas personalizadas para departamentos de Vendas, Marketing e TI.

• Recursos notáveis: IA para BI na própria nuvem Salesforce.

• Preço: US$ 75 por usuário ao mês para as Einstein Predictions, personalizadas para o Einstein Analytics Plus (necessário para importar dados externos).
  

SAS Visual Analytics: a abordagem do SAS Institute no BI é sua ferramenta Visual Analytics. Destina-se a destacar automaticamente as principais relações nos dados. Na versão mais recente, você pode escolher uma variável e mostrar-lhe quais elementos de seus dados a influenciam e como. Outros recursos incluem análise de sentimento para extração de dados de mídias sociais e outros textos, geração automática de gráficos, mapeamento e preparação de dados de autoatendimento. A implantação pode on-premise, em nuvens públicas ou privadas ou na plataforma Cloud Foundry como um serviço.

• Recursos notáveis: funções de análise automatizadas.

• Preços: sob demanda.

SiSense: A pilha de software de BI da SiSense cobre tudo, desde o banco de dados até ETL e Analytics, até a visualização – e afirma que seu mecanismo de banco de dados In-Chip é mais rápido até do que os bancos de dados em memória. Está disponível on-prenise ou na nuvem. Existem soluções para Finanças, Marketing, Vendas, RH e TI, bem como serviços de atendimento ao cliente e departamentos de operações e logística. O SiSense também possibilita oferecer as ferramentas de análise para usuários fora da empresa, incorporando-as em aplicativos web.

• Recursos notáveis: cliente totalmente baseado na web, incluindo a preparação de dados.

• Preços: sob demanda.

Tableau: Os recursos do Tableau incluem mapeamento e análise de pesquisas e dados de séries temporais. Seu truque mais recente é utilizar as técnicas do Processamento de Linguagem Natural para permitir que os usuários descrevam o que desejam ver, em vez de clicar e arrastar para criar consultas de fórmulas. É possível executar o software on-premiseq, escolher uma nuvem pública ou optar por tê-lo totalmente hospedado pela Tableau. Oferece versões personalizadas para mais de uma dúzia de setores, incluindo Serviços Bancários, de Saúde e Manufatura, com suporte para os departamentos Financeiro, de RH, de TI, de Marketing e de Vendas.

• Recursos notáveis: a Tableau usa PLN para permitir que os usuários digam o que desejam ver.

• Preços: cada implantação precisa de pelo menos um Tableau Creator (US $ 70 / mês); outros podem ser Viewers (de US $ 12 / mês, min. 100) ou Explorers (de US $ 35 / mês, min. 5).

FONTE: 12 principais ferramentas de Business Intelligence em 2019. Disponível em: <https://bit.ly/2PiiVX3>. Acesso em: em: 5 dez. 2018.

5 tendências de business intelligence para 2019. Disponível em: <https://bit.ly/3frb7fY>. Acesso em: 5 dez. 2018.

2 - DATA WAREHOUSE

Um Data Warehouse tem como tradução literal "Armazém de dados", pode ser compreendido como um banco de dados analítico, afinal tem como objetivo preparar uma base de dados para realização de consultas. Isto significa, que todos os processos que compõem a construção de um Data Warehouse têm um objetivo principal: realizar análises com o menor tempo possível.

Com o crescente aumento do volume das informações organizacionais armazenadas nos sistemas gerenciadores de banco de dados, os sistemas tradicionais OLTP – Online Transaction Processing (Processamento de Transações On-line) já não dispõem de suporte para retornar às consultas em um tempo hábil para a tomada de decisão. Por outro lado, são realizadas operações analíticas que permitem a exploração de dados armazenados, estes são os ambientes de Data Warehouse.

Data Warehouses, explicado de uma maneira simples, são bancos de dados analíticos, projetados para armazenar os dados de fontes diversas, já transformados e preparados para a realização de consultas através de operações OLAP (HAN; PEI; KAMBER, 2011).

Conforme vimos no capítulo anterior, a “paternidade” do conceito de Data Warehouse é dividida por Bill Inmon e Ralph Kimball, uma vez que o termo é discutido desde os anos 1970 e ainda é um dos mais ascendentes no que se refere a técnicas de Business Intelligence. Durante o livro, iremos ver os principais pontos de uma arquitetura de Data Warehouse, bem como a particularidade de cada um dos pais do conceito, complementado de perspectivas atuais.

No que se refere ao conceito de um Data Warehouse, comumente partimos da definição de Inmon (2005), que um Data Warehouse é uma coleção de dados, orientado a um assunto, integrado, com tempo variável e não volátil; e que este banco de dados é desenvolvido para suporte ao gerenciamento dos processos de tomada de decisão. Vejamos o que cada um destes itens significa de maneira detalhada:

• Orientado a assunto: uma vez notando-se a necessidade da implementação de um Data Warehouse em uma organização, este terá um tema, um objeto de análise. Um Data Warehouse é orientado a assunto pelo fato de que este sempre estará relacionado a um tema sobre o qual consultas são realizadas. Isto significa que ele sempre será direcionado a um tema, seja as vendas, financeiro, fiscal, compras.

• Integrado: no Capítulo 1, falamos sobre diversos tipos de dados (XML, JSON, CSV, SGBDR), dizemos isto porque uma das principais características de um Data Warehouse é a integração. Um Data Warehouse pode integrar vários sistemas internos que usam SGBD e ao mesmo tempo integrar com redes sociais via JSON, fazendo dessa dinâmica nas fontes de dados sua principal característica, bem como um dos principais desafios.

• Variável em relação ao tempo: o fator temporal é, na maioria dos casos, determinante na análise dos dados armazenados em um Data Warehouse. Deste modo, a cada carga de um novo conjunto de dados, este será associado com um determinado tempo. Vejamos a importância do tempo, por exemplo, em um Data Warehouse de ações na bolsa de valores se obtém os meses nos quais há uma maior queda nas ações e os meses em que há um número maior de vendas. Assim, faz-se necessário que os dados de Data Warehouse sejam armazenados em relação ao tempo.

• Não volátil: este fator também está relacionado ao tempo, uma vez que todo registro que é inserido em um Data Warehouse é associado a um tempo. Não devem haver exclusões, por isso não volátil. Isto não significa que o registro não constará como removido, mas que haverá duas ocorrências, uma primeira na data de sua inserção indicando que existiu e uma segunda indicando a data que foi removido.

Arquitetura de um Data Warehous

A arquitetura de um Data Warehouse é composta pela estratégia de coleta, pré-processamento e análise dos dados. São diversas as arquiteturas propostas na literatura, as variações acontecem principalmente pelo fato de existirem variações nas formas e formatos de dados, porém todas as arquiteturas são baseadas na principal proposta por Kimball, que é mostrada pela figura a seguir.

FIGURA 1 – ARQUITETURA DE UM DATA WAREHOUSE

FONTE: Adaptado de Kimball (2011, p.28)

Na arquitetura proposta por Kimball, o sistema é composto por quatro camadas principais: fontes de dados, área de trabalho, área de apresentação e ferramentas de acesso aos dados. Conheça o que compreende cada uma dessas camadas:

• Fontes provedoras: em um ambiente de Data Warehouse uma das características é a integração entre os dados, ou seja, os dados são oriundos de diversas fontes. Esta camada contém todos os dados possíveis de serem armazenados no Data Warehouse (relacional, orientado a objetos, não estruturados, textual, Web etc.), que possam ajudar a cumprir as tarefas de análise.

• Área de trabalho: nesta camada são realizados os processos de integração das fontes de dados, bem como as transformações necessárias para armazenar os dados de acordo com o modelo definido para Data Warehouse. Nesta camada são realizados os principais procedimentos da chamada ETL (Extract, Transform and Load), que estudaremos em detalhe neste capítulo.

• Área de apresentação de dados: esta camada trata do principal objeto deste capítulo, ou seja, um Data Warehouse em si, em que os dados já coletados e transformados serão armazenados em um banco de dados projetado a partir de um modelo multidimensional.

• Ferramentas de acesso aos dados: a quarta camada é onde as ferramentas de visualização fazendo uso de o servidor OLAP submeter requisições de acesso aos dados armazenados. No que se refere ao objetivo do nosso livro, será nesta camada que os dados estarão prontos e as ferramentas de construção de Dashboards serão conectadas aos dados permitindo a exploração e análises multidimensionais.

Todos os dados que entram no Data Warehouse são integrados, sendo que existe uma única fonte de dados para os diferentes Data Marts. Isso garante que a integridade e a consistência dos dados sejam mantidas intactas em toda a organização. A figura a seguir mostra a arquitetura típica de um Data Warehouse nesta arquitetura.

FIGURA 2 – ARQUITETURA PROPOSTA POR INMON

FONTE: Singh e Singh (1998)

Os Data Marts podem ser compreendidos como Data Warehouses setoriais em uma organização, por exemplo: venda, financeiro, fiscal, marketing. Pode-se notar que a participação dos Data Marts é mais efetiva na arquitetura de Inmon e é parte integrante de todo processo de construção.

Outro elemento diferente dos vistos anteriormente é o conceito de Staging Area, seu significado é “Área de preparação”, essa é uma etapa interessante, uma vez que facilita o processo de pré-processamento dos dados. Na Staging Area, os dados são copiados das fontes provedoras, o que facilita para que as demais tarefas os acessem.

Sobre a arquitetura proposta por Inmon, Rangarajan (2016) elenca os seguintes pontos positivos da arquitetura:

• O Data Warehouse realmente serve como fonte única de verdade para a empresa, pois é a única fonte para os Data Marts e todos os dados no Data Warehouse são integrados.

• As anomalias de atualização de dados são evitadas devido à redundância muito baixa. Isso torna o processo ETL mais fácil e menos propenso a falhas.

• Os processos de negócios podem ser compreendidos facilmente, pois o modelo lógico representa as entidades de negócios detalhadas.

• Muito flexível – à medida que os requisitos de negócios mudam ou os dados de origem são alterados, é fácil atualizar o Data Warehouse, pois uma coisa está em apenas um lugar.

• Pode lidar com necessidades de relatórios variados em toda a empresa.

Rangarajan (2016) também lista algumas das desvantagens do método Inmon:

• O modelo e a implementação podem se tornar complexos ao longo do tempo, pois envolvem mais tabelas e junções.

• Precisa de recursos que sejam especialistas em modelagem de dados e do próprio negócio.

• Esses tipos de recursos podem ser difíceis de encontrar e costumam ser caros.

• A configuração inicial e a entrega levarão mais tempo, e o gerenciamento precisa estar ciente disso.

• Mais trabalho de ETL é necessário, pois os Data Marts são construídos a partir do Data Warehouse.

• Uma equipe razoavelmente grande de especialistas precisa estar por perto para gerenciar com sucesso o ambiente.

Note que tais arquiteturas foram propostas em meados dos anos 1980 e vigoram bem até os dias atuais. Existem diversas variações, mas em sua maioria estão relacionadas ao tipo de fonte de dados (coleta da Web em tempo real, por exemplo) ou sobre novas técnicas de armazenamento (integração entre nuvem e Hadoop, por exemplo). Como o nosso objetivo é a construção de um Data Warehouse e não uma análise comparativa entre esses grandes pais da tecnologia que estamos trabalhando, vamos seguir, mas se você ficou curioso com as demais arquiteturas, características e diferenças, seguem algumas sugestões de leitura.

Complementarmente, um Data Warehouse, pela definição de Kimball e Ross (2011), é uma cópia de dados de transação (OLTP), especificamente estruturado para consulta e análise. Para fazer possível o armazenamento de dados, o esquema de dados baseia-se no modelo multidimensional, tal modelo que é de grande importância para a construção de um Data Warehouse e que vamos discutir em detalhes no próximo tópico de estudo.

2.1 MODELAGEM MULTIDIMENSIONAL

Antes de nos aprofundarmos em nosso estudo sobre a modelagem multidimensional, é importante relembrar alguns conceitos sobre a modelagem de dados relacional. Vimos anteriormente que o modelo relacional surgiu em 1970, desenvolvido pelo pesquisador da IBM, Edgar Frank Ted Codd IBM, que de maneira sucinta propôs o armazenamento de dados onde os dados seriam armazenados em tabelas que devem estar relacionadas.

No modelo relacional os dados são organizados em tabelas e cada dado armazenado tem um determinado tipo de dados associado. Por exemplo, se um dado é um nome será do tipo VARCHAR (que representa textos), se for um valor em reais R$ será do tipo DOUBLE (que representa números com casas decimais. São diversos os tipos de dados e isto pode variar da tecnologia que seu banco de dados, seja relacional ou multidimensional será implementado, para ter uma visão geral. A tabela a seguir mostra alguns desses tipos baseados no banco de dados PostgreSQL e que são comuns aos demais SGBDs também.

As ligações entre os campos são realizadas por chaves, primárias e estrangeiras, tais campos que se relacionam, ou seja, é através do relacionamento entre essas chaves que o banco de dados é considerado relacional. A figura a seguir mostra um banco de dados relacional para gerenciamento de um comércio de vendas e seu estoque.

FIGURA 3 – EXEMPLO DE BANCO DE DADOS RELACIONAL

FONTE: O autor (2018)

Na Figura 3 vemos algo sobre o conteúdo citado anteriormente, por exemplo, o campo data ser do tipo DATE, preço ser DOUBLE, nome do cliente ser VARCHAR e os IDs como inteiro. Também é possível notar que os relacionamentos são formados pela ligação entre as chaves primárias (Primary Keys – PK) e chaves estrangeiras (Foreign Keys – FK).

Mas afinal, o que o modelo relacional tem a ver com o modelo multidimensional? Toda estrutura é bem similar, o modo é a construção dos modelos. Como nosso objetivo não é construir um modelo relacional, deixamos duas sugestões de leitura para que você possa rever esses conceitos e seguir firme na modelagem.

Ainda tratando do que se refere à modelagem relacional, esta tem entre muitos objetivos armazenar os dados garantindo o maior nível de integridade possível de integridade nos dados armazenados. A principal estratégia para isto é denominada normalização. A normalização dos dados é o primeiro passo para se obter sucesso com um modelo de dados íntegro, uma vez que sendo estas normas respeitadas, as redundâncias e inconsistências poderão ser evitadas. Atualmente já são mais de 10 formas normais (FN), todas oriundas das três primeiras:

• 1FN: a primeira forma normal trata da atomicidade dos atributos, proibindo atributos compostos, multivalorados e relações aninhadas.

• 2FN: a segunda forma normal está relacionada à dependência funcional da chave primária. Para estar na segunda forma normal, a tabela deve estar na primeira forma normal e nenhum dos campos que não são chaves podem depender de apenas parte da chave primária.

• 3FN: a terceira forma normal está relacionada à chamada dependência transitiva, ou seja, um campo não deve depender de um outro campo “não chave”. Para remover a dependência transitiva, deve-se identificar os campos que são dependentes transitivos de outros campos e removê-los.

Agora encerramos os conceitos sobre a modelagem relacional e a normalização, vamos lá!

A modelagem multidimensional é uma estratégia de modelagem de dados que tem ênfase na análise dos dados, ou seja, na realização de consultas. Sendo assim, a cada momento do seu aprendizado você tem que ter em mente que a construção do modelo tem o foco na análise. Não se preocupe com a integridade e não, não se assuste! A integridade dos dados já foi garantida inicialmente pelo seu sistema transacional (OLTP) e no caso de integração de diversas fontes será responsável pela etapa de ETL (vista na continuidade).

A modelagem multidimensional é uma técnica de modelagem de bancos de dados que se destina apoiar as consultas realizadas pelo usuário final em um Data Warehouse (KIMBALL; ROSS, 2011). A técnica de modelagem multidimensional trata da elaboração de um projeto lógico de um banco de dados, que tem sua aplicação destinada à análise de dados. Utilizando a modelagem multidimensional, estabelece-se a estrutura de dados sob qual o cubo de dados será analisado.

De maneira geral, independentemente da técnica utilizada para sua construção, um modelo multidimensional é composto por três componentes principais: as tabelas de fato, as tabelas com dimensões e as métricas, sem deixar de lado os atributos comuns que também pertencerão às tabelas.

As métricas são valores, normalmente, aditivos, armazenados na tabela fato, ou seja, as métricas são as medidas brutas, atômicas e de simples composição. Em uma estrutura de Data Warehouse, são armazenados na tabela Fato e medem os descritivos armazenados nas Dimensões. Valores e quantidades são exemplos de formatos das métricas. Na sequência do nosso livro, iremos discutir sobre a criação de dashboards e extração de indicadores, que tem grande relação com as métricas, mas não são a mesma coisa. Por exemplo, uma métrica pode ser o total vendido em R$ e um indicador, o percentual dessas vendas em um determinado mês.

Segundo Elias (2011), existem diversos tipos de métricas, as métricas aditivas são aquelas que podem ser sumarizadas independentemente das dimensões utilizadas. Este tipo de métrica pode ser utilizada sem quase nenhuma restrição ou limitação e são flexíveis o suficiente para gerar informações em qualquer perspectiva. Por exemplo, métricas como quantidade e valores de determinados itens podem ser, em geral, sumarizados por data (dia, mês ou ano), local, clientes, entre outras dimensões, sem perder a consistência da informação.

As métricas semiaditivas são aquelas que podem ser sumarizadas em alguns casos. Isso porque a depender da situação empregada à métrica, ela pode perder sentido para a análise caso seja agregada. Neste caso, a sumarização só fará sentido com algumas dimensões específicas. Por exemplo, a métrica saldo bancário. O saldo é um valor que reflete a situação atual da conta, que pode ter o saldo credor ou devedor. Faria sentido, por exemplo, somar os saldos de todos os dias de um mês para uma determinada conta bancária? Claro que não, pois se um dia o saldo for de -1000 e no dia seguinte ter os mesmos -1000, a soma irá devolver um saldo negativo de -2000, o que não é verdade. No entanto, há casos em que a métrica semiaditiva adquire característica de aditiva. Se por acaso somar os saldos de várias contas bancárias em um determinado dia, poderemos ver o saldo geral, o que tem total sentido e utilidade para uma instituição bancária, por exemplo.

As métricas não aditivas são aquelas que não podem ser sumarizadas ao longo das dimensões. Essas métricas não podem ter agregações, pois perdem a veracidade do valor. Percentuais são exemplos de valores armazenados nas métricas que não permitem a sumarização. Por exemplo, não faz sentido somar o percentual de vendas de um item “A” que teve 50% de saída com um item “B” que teve 60%. A soma resultaria em um valor agregado de 110%. O que isso nos diz? Nada! Como muitas vezes as métricas semiaditivas e não aditivas são derivadas de métricas aditivas, recomendamos, se possível, que sejam armazenadas as métricas brutas para o cálculo em tempo de execução. A métrica semiaditiva saldo, por exemplo, pode ser calculada em tempo de execução com as métricas aditivas do valor de crédito e débito. Portanto, devemos ficar atentos a essas diferenças, para que no desenvolvimento do Data Warehouse possamos efetuar o tratamento adequado em cada um desses casos. Lembrando que quanto menos flexível for a utilização das métricas, mais complexo será a utilização pelos usuários, o que pode ser um fator crítico de sucesso para o projeto. Sempre que possível devemos gerar as agregações em tempo de execução para as métricas semiaditivas e não aditivas, facilitando a utilização e deixando transparente aos usuários os cálculos efetuados.

No que se refere às métricas e valores armazenados, também existe o conceito de hierarquia. Tais atributos podem ser considerados descritivos ou até mesmo formar uma hierarquia. As hierarquias são representadas pela composição de vários atributos em uma dimensão, em que cada atributo representa um nível em uma hierarquia. Um exemplo aplicável em qualquer cenário é a dimensão tempo, considerando que esta dimensão tem diversas perspectivas de análise (dia, mês, ano, semana, dia da semana, quinzena, entre outros, veremos mais a fundo adiante a dimensão Tempo). No caso da dimensão do tempo, considerando que esta dimensão tenha os atributos dia, mês e ano, estes atributos compõem uma hierarquia de tempo que permite navegar pelos níveis data -> mês -> ano. A figura a seguir mostra alguns exemplos de hierarquia.

FIGURA 4 – EXEMPLO DE HIERARQUIAS

FONTE: O autor (2018)

O modelo multidimensional, assim como no relacional, é composto por tabelas. No entanto, existe uma abordagem diferente. Uma vez que o foco é na análise, o objetivo principal das análises se transformará em uma tabela principal, denominada tabela FATO.

Para trazer sentido e valores para tabela fato e tendo como objetivo auxiliar na obtenção de valores e métricas para o objeto de análise, existem as outras tabelas, denominadas tabelas DIMENSÕES. Tanto uma tabela FATO quanto uma tabela DIMENSÃO são tabelas consideradas normais em sua construção, tendo as mesmas características do modelo relacional (campos, chaves, tipos de dados etc.), sendo que o que muda é a estratégia de modelagem.

Desde o início do nosso livro estamos falando sobre Inmon e Kimball, bem como sobre a existência de algumas divergências de abordagens. Uma delas é sobre a modelagem, cada autor propõe uma estratégia de modelagem multidimensional, sendo estas as duas principais técnicas de modelagem para cenários de Data Warehouse: Star Model e SnowFlake.

2.2 MODELO ESTRELA “STAR MODEL”

O Star Model, ou modelo estrela, é a estratégia de modelagem mais utilizada na construção de modelos multidimensionais para ambientes de Data Warehouse. Este modelo foi proposto por Ralph Kimball, com o objetivo de dar suporte à tomada de decisão e melhorar o desempenho das consultas em ambientes multidimensionais.

O modelo estrela é composto de uma tabela principal ao centro do modelo, a FATO. As demais tabelas, chamadas de DIMENSÕES, ficam dispostas ao redor da tabela principal, sendo que esta disposição forma uma estrela, daí o nome do modelo. A figura a seguir mostra um exemplo do modelo da ideia do modelo estrela.

FIGURA 5 – EXEMPLO DO MODELO ESTRELA

FONTE: O autor (2018)

O principal objetivo da modelagem em estrela é condensar os valores vindos das fontes de dados, ou seja, armazená-los no menor número de tabelas possível e esta não é uma tarefa fácil. Quando iniciamos a modelagem, sempre há a velha preocupação: a integridade dos dados. Uma vez que nesse momento nosso foco muda e se torna a análise e consultas, ao decorrer da modelagem multidimensional, você pode fazer as seguintes perguntas para auxiliar na construção do modelo:

• Quais tabelas posso juntar em apenas uma? Por exemplo, ao invés de existir a tabela bairro, cidade, estado e país, ligadas por chaves, você pode inserir todas essas informações em uma única tabela chamada localidade.

• Quais dados eu calculo que podem ser armazenados em um campo? Um exemplo disso é quando no banco transacional existe a tabela produto e a quantidade vendida, sendo que o valor total é calculado por consulta. Ao realizar o modelo estrela para este caso, será criada uma métrica na tabela fato chamada total que armazenará esse valor já calculado, o que otimizará o tempo de resposta das análises.

Realizando estas mesmas perguntas, uma possibilidade para a modelagem multidimensional, pegando como fonte de dados o modelo relacional de vendas visto anteriormente, teremos assim um modelo multidimensional para vendas. Tal modelo é mostrado pela figura a seguir mostra uma alternativa de modelagem para o mesmo sistema de vendas, note que existe uma tabela central fato e que, principalmente, o número de tabelas é reduzido, contendo no modelo o mesmo número de informação que pode ser extraído no modelo anterior.

FIGURA 6 – EXEMPLO DE MODELO MULTIDIMENSIONAL ESTRELA DE VENDAS

2.3 MODELO SNOWFLAKE

O Modelo SnowFlake é muito próximo do que é conhecido da modelagem tradicional de banco de dados, uma vez que durante sua construção são levadas em consideração as formas normais. Idealizado por Bill Inmon, este modelo contém uma tabela FATO e as tabelas DIMENSÕES. A principal característica desse modelo é que as dimensões não se comunicam apenas com a tabela fato, mas também entre as próprias dimensões. A maneira com que as tabelas são conectadas, ou seja, que elas ficam dispostas, representa um floco de neve, por isso o nome SnowFlake, que em sua tradução significa “Floco de Neve”, bem como mostra a figura a seguir.

FIGURA 7– MODELO SNOWFLAKE

FONTE: O autor (2018)

Entre as características dessa modelagem é que, conforme visto anteriormente, aplica o conceito de normalização e por isso tem diversas tabelas. Conforme vimos, o processo de normalização nos obriga a criar novos campos a cada forma normal aplicada.

Como a modelagem multidimensional é uma estratégia que objetiva otimizar o processo de recuperação de informações através de consultas, tal processo não pode utilizar um excesso de tabelas o que implicará um excesso de junções. Por isso, ao utilizar o modelo SnowFlake, o recomendado é que ao se pensar em normalização aplique no máximo a terceira forma normal.

A abordagem Inmon para a construção de um Data Warehouse começa com o modelo de dados corporativos. Esse modelo identifica as principais áreas de assunto e, o mais importante, as principais entidades com as quais a empresa opera e se preocupa, como cliente, produto, fornecedor etc.

A partir desse modelo, um modelo lógico detalhado é criado para cada entidade principal. Por exemplo, um modelo lógico será construído para o Cliente com todos os detalhes relacionados a essa entidade. Pode haver dez entidades diferentes no Cliente. Todos os detalhes, incluindo chaves de negócios, atributos, dependências, participação e relacionamentos, serão capturados no modelo lógico detalhado.

O ponto-chave a que se refere a proposta de Inmon, aqui é que a estrutura da entidade é construída na forma normalizada. A redundância de dados é evitada tanto quanto possível. Isso leva a uma identificação clara dos conceitos de negócios e evita anomalias de atualização de dados. O próximo passo é construir o modelo físico. A implementação física do Data Warehouse também é normalizada.

Esse modelo normalizado torna o carregamento dos dados menos complexo, mas o uso dessa estrutura para consulta é difícil, pois envolve muitas tabelas e junções. Então, Inmon sugere a construção de Data Marts específicos para departamentos. Os Data Marts serão projetados especificamente para finanças, vendas etc., e eles podem ter dados desnormalizados para ajudar na geração de relatórios (BRESLIN, 2004).

FIGURA 8 – INTERFACE DO SQL POWER ARCHITECT

O Power Architect assim como as demais ferramentas de modelagem de dados foi destinado à modelagem de bancos de dados relacionais, no entanto, atendem bem às demandas da modelagem multidimensional. Você pode aprender mais sobre essa ferramenta no próprio site do fabricante <http://www.bestofbi.com/page/architect-demos>. Como nosso objetivo não é amarrar o conhecimento à tecnologia, mas sim ao conceito de modelagem, é importante que você possa buscar utilizar a ferramenta que tenha maior familiaridade. Vou deixar aqui algumas outras opções de ferramentas, inclusive algumas on-line:

FIGURA 9 – MODELAGEM MULTIDIMENSIONAL DE VENDAS

3 ETL (EXTRACT, TRANSFORM AND LOAD)

É muito difícil dizer qual é a etapa mais importante, afinal quando estudamos a arquitetura de um Data Warehouse, aprendemos que existe uma conexão entre cada camada. No entanto, um forte candidato a este cargo é esta etapa chamada de ETL (Extract, Transform and Load); Extração, Transformação e Carga. De maneira sucinta, esta é a etapa responsável por pegar os dados da fonte, prepará-los e armazená-los em um banco de dados multidimensional.

FIGURA 10 – PROCESSO DE EXTRAÇÃO TRANSFORMAÇÃO E CARGA

FONTE: <https://bit.ly/33z5g5y>. Acesso em: 19 dez. 2018.

A ETL é responsável por fazer a integração entre as camadas de um Data Warehouse a partir das fontes de dados, além de tratar e armazenar estes dados em um banco de dados multidimensional no Data Warehouse. Quando dizemos que é um forte candidato a ser a etapa mais importante de um Data Warehouse, isso é dito principalmente porque essa etapa consome cerca de 80% de um projeto de implementação de um Data Warehouse que seja dedicado a etapa de ETL (NAGABHUSHANA, 2006).

Na definição de Kimball e Ross (2011), o sistema de ETL é análogo ao da cozinha de um restaurante, onde os chefes pegam matérias-primas e as transformam em deliciosas refeições para os clientes. Ou seja, essa etapa coleta e prepara os dados, ficando por conta das aplicações de Dashboards apenas servir-se de tais dados, gerando os mais diversos relatórios.

Cada etapa da ETL tem sua devida tarefa no projeto, vamos compreender melhor o que cada uma delas significa.

Extração

A extração (extract), como o nome diz, é responsável por extrair os dados das fontes, ou seja, é processo de recuperação dos dados necessários das fontes de origem. Tais fontes de dados podem ser as tabelas reais ou simplesmente cópias que foram carregadas no Data Warehouse (Staging Area).

Um ponto importante da extração é a diversidade de fontes de dados, que não são necessariamente uma fonte OLTP, podem ser documentos de texto, XML, JSON, CSV, ou, o caso mais comum, diversas fontes integradas.

A etapa de extração deve ser capaz de ler e compreender os dados da fonte e copiar apenas os dados necessários, sendo que esta etapa deve ser construída apta a coletar dados com um período de tempo definido (a cada 30 minutos, por exemplo) ou ser um mecanismo de coleta em tempo real.

Transformação

A etapa de transformação é a etapa que demanda mais esforço computacional dentro do processo de ETL, pois suas responsabilidades são diversas.

A primeira trata da integração dos dados, a extração coleta de diversas fontes coleta, mas a transformação é responsável por integrar cada campo coletado, transformando-o para um único padrão e deixando apto para armazená-lo no modelo multidimensional. Esta etapa, literalmente, transforma os dados coletados das fontes de acordo com os definidos no modelo do Data Warehouse, onde são realizados pré-processamentos, nos quais são identificados os dados duplicados, integração entre os dados, substituição de valores, limpeza de campos e toda a transformação necessária para adequar as fontes de dados.

Um exemplo de uma transformação comum realizada por processos ETL é relacionado com campos de sexo, em alguns sistemas são “M” para Masculino e “F” para Feminino, porém em outros está guardado como “H” para Masculino e “M” para Feminino, em outro ainda, podemos encontrar “1” para Masculino e “2” para Feminino, cabendo transformá-los para um único formato.

Outro exemplo, que é um caso recorrente em cenários de Data Warehouse, é o armazenamento do tempo. Cada fonte de origem pode ser armazenada de uma maneira, tendo de ser padronizadas ao serem armazenadas em um Data Warehouse, veja exemplo das datas na figura a seguir. Esse exemplo é marcante por pegar justamente a consolidação dos dados de diversas fontes, a integração entre eles, a padronização e o armazenamento em um formato diferente, o do Data Warehouse.

FIGURA 11 – TRANSFORMAÇÃO E PADRONIZAÇÃO DAS DATAS

FONTE: O autor (2018)

A etapa de transformação também é responsável por resolver desafiadores problemas oriundos das fontes de dados, como ausência de informação, valores inválidos, ausência de integridade referencial, violação de regras de negócios, cálculos inválidos, duplicação de informação, inconsistência de dados e falhas na modelagem das fontes de dados. Muitas vezes, para resolver os casos acima, será necessário incorporar métodos avançados como mineração de dados e machine learning.

Carga

Uma vez as etapas anteriores deixando os dados prontos, já coletados e transformados, a etapa de carga (load) é responsável por armazenar os dados no Data Warehouse, no banco de dados multidimensional.

Em um primeiro olhar quando se fala em Carga, parece um processo simples, pensando em inserções em um banco de dados, no entanto, é um processo um pouco mais complexo do que se imagina. Na carga, o Data Warehouse é alimentado com novos dados, de forma que as tabelas do banco de dados multidimensional sejam atualizadas para conter os novos dados.

Normalmente, o Data Warehouse é colocado off-line durante a carga de forma que nenhum usuário possa consultá-lo simultaneamente, sendo essa etapa realizada em períodos de não utilização, na madrugada, por exemplo. Como o armazenamento de dados em ambientes de Data Warehouse, normalmente, envolve grandes quantidades de dados, a etapa de carga sempre ocorre em um período regular, por exemplo, diariamente.

ETL na prática. Como funciona?

No mercado existem diversas ferramentas que realizam o processo de ETL, cada uma com a sua particularidade. Tais ferramentas são softwares específicos, nos quais você pode identificar sua fonte provedora, selecionar os métodos de pré-processamento e transformação, posteriormente selecionando a fonte de origem (banco de dados multidimensional).

Como dito anteriormente, ETL é um processo, não significa que esteja amarrado a uma ferramenta, qual será utilizada depende muito do cenário de aplicação, inclusive há muito que são desenvolvidas ferramentas exclusivas, a maioria utiliza a linguagem python para isso. No entanto, veja algumas das principais ferramentas ETL em um artigo que compara seus recursos, complementarmente em um breve texto sobre a principal ferramenta de ETL encontrada no mercado, o Pentaho Data Integration.

Uma vez feita a extração e transformação, a carga será realizada em um banco de dados Multidimensional, podendo ser explorado através de consultas OLAP e servir aplicações.

FIGURA 12 – ECOSSISTEMA PENTAHO

FONTE: O autor (2018)

O Pentaho Data Integration é parte das soluções disponibilizadas pela suíte Pentaho, possui versões Community e Enterprise, mas a diferença existente entre as versões não representa impeditivo algum para o uso da versão Community. A versão Community possui todos os recursos necessários a qualquer implementação que se deseje realizar e possui vasta disponibilidade de plugins para serem utilizados, inclusive plugins que geram a documentação de projetos, como o Kettle Cookbook. Todo o processo de extração e transformação e carga descrito neste texto foi realizado com o Pentaho Data Integration Community, versão 7.1.

O Pentaho Data Integration é o componente da suíte Pentaho usado para criar processos de extração, transformação e carga, assim alimentam o banco de dados.​ Trata-se da ferramenta mais popular e madura da suíte inteira, com seus mais de 15 anos de existência. Com o Pentaho Data Integration, é possível fazer inúmeras operações de Integração de Dados. Como por exemplo:

• Migração de dados.

• Movimentação de grandes volumes de dados.

• Transformação de dados.

• Limpeza de dados.

• Conformidade de dados.

O Spoon

O Pentaho Data Integration é formado por duas categorias de artefatos, Jobs e Transformações, e estes artefatos são construídos por meio de sua interface gráfica, o Spoon. O Spoon é a interface gráfica do Pentaho Data Integration, que facilita na concepção de rotinas e lógica ETL. A seguir, apresentamos a interface do Spoon.

FIGURA 13 – SPOON

FONTE: <https://bit.ly/34qFIXJ>. Acesso em: 22 jan. 2019.

Uma transformação registra o passo-a-passo de como a extração ou leitura de uma fonte de informação é realizada. É a transformação que opera sobre os dados. Ela pode conter:

• Leitura de dados de uma tabela, de um banco de dados.

• Seleção de campos específicos de uma tabela.

• Concatenação de valores de dois campos distintos de uma tabela.

• Divisão de valores contidos em um único campo gerando dois ou mais novos campos ou linhas.

• Merge de dados de tabelas contidas em bancos de dados diferentes.

• Merge de dados originados em tabelas, arquivos XML, TXT ou CSV, entre outras fontes de dados.

• Aplicação de expressões regulares em texto para limpeza.

O aspecto mais importante em uma transformação é que ela opera todas as etapas simultaneamente – uma transformação não tem início ou fim, ela apenas processa linhas que chegam.

Jobs

Um job é uma sequência operações. Ao contrário de uma transformação, que opera sobre as linhas de dados em paralelo, um job realiza operações completas, uma por uma. Ele permite, por exemplo, combinar transformações em uma sequência específica e, com isto, automatizar uma dada tarefa. Por sua natureza, ele não fornece muitos recursos técnicos para manusear os dados em si, deixando isto à cargo das transformações.

É possível conferir a lista completa de funcionalidades dos Jobs e Transformações que está disponível na Wiki do projeto.

Pan

O Spoon, porém, é só a interface gráfica para criar os processos de integração de dados. Ele não serve para executá-los em produção, ou seja, no ambiente sem supervisão humana. Para isso usamos outros programas, que operam em linha de comando, sem interface gráfica.

O Pan é o programa que executa transformações. Vale a pena mencionar que tanto jobs quanto transformações podem ser arquivos em um sistema de arquivos, normal, ou em um repositório em banco de dados. O Pan pode executar uma transformação a partir de qualquer uma destas origens.

Em geral, as transformações executadas pelo Pan são agendadas em modo batch, para que possam ser executadas automaticamente em intervalos regulares por alguma ferramenta de gerenciamento de tarefas como o crontab, por exemplo.

Kitchen

Enquanto o Pan executa transformações, o Kitchen executa jobs. Tal qual ocorre com o Pan, o Kitchen pode executar jobs a partir de um sistema de arquivos ou de um repositório em banco de dados.Novamente, tal qual o Pan, jobs são executados em modo batch através do agendamento no modo batch para serem executados automaticamente em intervalos regulares por alguma ferramenta de gerenciamento de tarefas como o crontab, por exemplo.

A tríade Spoon, Pan e Kitchen é o responsável pela criação e execução de artefatos criados para solucionar um problema de extração, transformação e carga de dados em um projeto de ETL com o Pentaho Data Integration.

Caso de uso

Segundo Nitin Anand, em seu artigo para o International Journal of Scientific and Research Publications:

“Um componente importante em um projeto de BI é o processo de Extrair, Transformar e Carregar (ETL). Ele descreve a coleta de dados de várias fontes (extrair), sua modificação para combinar o estado desejado (transformação) e sua importação em um banco de dados ou data warehouse (carga). Os processos de ETL são responsáveis por até 80% do esforço em projetos de BI. Um alto desempenho é, portanto, vital para poder processar grandes quantidades de dados e ter um banco de dados atualizado”.

Recentemente, enfrentamos um cenário em que precisávamos mover dados de um banco de dados Oracle para serem consumidos por um outro sistema que também utilizava Oracle como sistema de armazenamento. A necessidade de se copiar estes dados ocorria devido à natureza da aplicação destino que necessitava de intensa sumarização de dados e processamento o que não poderia ser realizado no banco de dados de origem para não comprometer o seu uso, uma vez que este possui uma natureza transacional, ou seja, é utilizado diariamente por todos os usuários da empresa em suas atividades. Sumarizar dados neste ambiente poderia implicar em prejuízo para as operações normais do dia a dia.

Neste cenário, a tarefa de transferir dados do banco de dados de origem para o destino era realizada por meio de um processo de ETL, desenvolvido em JAVA quando este sistema legado foi entregue pela primeira vez seis anos atrás. Esta solução se comunicava com os sistemas origem e destino por meio de uma API que consultava dados de um lado e escrevia do outro lado. APIs são soluções tecnológicas concebidas para transferir informação entre sistemas de forma cadenciada e em pequenas porções. Utilizar esta tecnologia para mover grande quantidade de dados pode implicar, entre outros problemas, no seguinte:

• Criação de gargalos nos sistemas de origem e destino devido à alta carga que será movimentada.

• Caso seja utilizado algum mecanismo de ESB (Enterprise Service Bus), este ambiente pode ficar sobrecarregado devido à alta volumetria de mensagens, talvez arquivos JSON, que trafegarão por este meio (middleware).

• Gestão orientada a codificação. Quando a tarefa de transformar dados ou mesmo mover entre sistemas é endereçada via aplicação desenvolvida em Java ou outra linguagem de programação, momentaneamente esta solução pode resolver o problema, mas com o passar do tempo, e à medida que novas necessidades surgem nas fontes de informação de origem, modificações necessitarão ser realizadas no código e, consequentemente, com o passar do tempo o conhecimento e esforço despendido nesta tarefa vai aumentando. A tendência de se perder em meio a essa complexidade aumenta, deixando a manutenção do legado cada vez mais custosa. Devemos sempre pensar no futuro e na manutenibilidade, que quando mal planejada pode encarecer os custos de suporte e manutenção de um software.

O cenário descrito, neste texto, trata de um sistema legado, desenvolvido sem as boas práticas de engenharia de software e que possuía uma natureza crítica. Além disso, não poderia deixar de funcionar nem por um minuto. Por esta natureza de alta criticidade, à medida que o ETL em Java falhava, cada vez mais a fragilidade do sistema destino para o usuário aumentava gerando insegurança.

Com o passar dos anos, essa solução não se mostrou eficiente o bastante e constantemente apresentava problemas, incluindo a interrupção de seu funcionamento. Partimos, então, para outras alternativas.

Para solucionar este problema, encaramos o desafio de utilizar o Pentaho Data Integration. O resultado dessa abordagem será descrito nos próximos parágrafos.

Características e particularidades do Pentaho Data Integration

O Pentaho Data Integration possui características muito particulares quando nos referimos à captura de dados em fontes de informações, sejam elas bancos de dados, arquivos TXT ou CSV, arquivos XML ou JSON ou até mesmo arquivos DBF. É possível fazer ajustes finos, inclusive com relação ao número de threads que podem ser executadas por um passo na transformação.

Outro aspecto importante e que também pode ser executado com o Pentaho Data Integration é escolher, a partir de uma fonte de dados, quais informações desejamos que sejam transferidas para o passo seguinte, ou seja, em uma tabela de um banco de dados origem, é possível selecionar os campos exatos que se deseja capturar, em uma planilha eletrônica também podemos selecionar exatamente as colunas que são necessárias.

A ferramenta é muito flexível e possibilita inúmeros arranjos para que ao final, após a cópia de dados e transformações destes, tenhamos apenas o desejado.

As integrações que podem ser realizadas com o Pentaho Data Integration incluem, entre outros recursos:

• Exportar dados para um arquivo em formato texto em uma conta do Amazon Simple Storage Service (S3).

• Conectar a um serviço JIRA e executar a extração de dados JSON sobre os resultados.

• Capturar dados da conta do Google Analytics.

• Ler e enviar mensagens binárias para uma fila de mensagens do Apache Kafka.

• Enviar mensagens para canais ou grupos no Slack.

• Ler conteúdo de textos de vários tipos de arquivos (PDF, DOC etc.), usando o Apache Tika.

Com o tempo e à medida que usamos cada vez mais o Pentaho Data Integration, as funcionalidades necessárias para a construção de transformações que geram valor ficam cada vez mais inteligíveis. Esta curva de aprendizado é crescente, mas de inclinação suave, pois essa ferramenta é muito intuitiva.

Adotar o Pentaho Data Integration gera valor a um custo comparativamente menor que o desenvolvimento de ETLs com código. Há algum tempo presenciamos um cenário onde uma solução para ler um arquivo XML e transformar o conteúdo deste arquivo em formato CSV para que pudesse ser lido por outro sistema levou cerca de três meses para ser concluído. Devido à falta de conhecimento em uma ferramenta robusta de integração de dados via ETL, o time que desenvolveu esta solução precisou passar por todas as fases de um modelo tradicional de desenvolvimento de software, em que só a fase de mapeamento das informações de entrada levou 30 dias para ser concluída. A solução, que nada mais era que um ETL, foi desenvolvida totalmente em Java por pura falta de conhecimento de ferramentas de ETL, como o Pentaho Data Integration. O valor investido nestes três meses de desenvolvimento certamente poderia ter sido investido em outras iniciativas.

Quando nos referimos a gerar valor, estamos nos referindo não apenas a satisfazer as necessidades de nosso cliente ou unidade de negócio, estamos também nos referindo a salvar recursos financeiros evitando o desperdício de implementações manuais de código para realizar tarefas de um ETL. Com investimento em um código personalizado há uma falsa impressão de redução de custos, já que o custo inicial é baixo, mas os custos com suporte e melhorias crescem à medida que as necessidades dos negócios mudam.

Mover grandes quantidades de dados por meio de código, utilizando APIs pode, entre outras situações, sobrecarregar um barramento de serviços e cedo ou tarde o histórico de desenvolvimento desta solução irá se perder ou, como ocorreu com o sistema legado mencionado neste artigo, deixar de entregar resultados e se tornar um problema para o sistema e os times de desenvolvimento e, acima de tudo, a empresa.

O uso de um ETL consolidado e largamente utilizado como o Pentaho Data Integration traz maior flexibilidade, menor tempo de desenvolvimento e melhor estruturação para tarefas como as discutidas neste artigo. Entre as principais características do Pentaho Data Integration, podemos destacar:

Abordagem orientada a modelos com o uso de metadados:

• Intuitivo com possibilidade de responder facilmente a perguntas tais como o que fazer e como fazer.

• Realizar transformações complexas com zero codificação.

• Representar graficamente fluxos de transformações de dados (transformações) e orquestração de tarefas (jobs).

• Arquitetura extensível por meio de plugins, sem contar o fato de que é Software Livre e pode ser modificado à vontade.

Não é fácil realizar experimentos com processos de desenvolvimento, mas ocasionalmente nos deparamos com o caso das duas Alemanhas, que é o mais perto que podemos chegar de um experimento de laboratório com pessoas: duas equipes completamente separadas, desenvolvendo a mesma coisa a partir do mesmo ponto inicial e condições semelhantes. As escolhas ao longo do caminho são, então, a única explicação para quaisquer diferenças de resultados. No nosso caso, a diferença é a opção de tecnologia para resolver um problema de integração de dados e os fatos claramente favorecem a ferramenta de um ETL sobre o código puro. Se ainda havia alguma dúvida acerca da vantagem em se usar uma ferramenta de ETL em relação a desenvolver a mesma operação em código, os fatos aqui descritos resolveram-na completamente: ferramentas de ETL dão resultados vastamente superiores à criação de código a um menor custo e em um menor prazo.

4 - O CUBO DE DADOS E AS CONSULTAS OLAP

Sabemos que os dados de um Data Warehouse podem ser explorados por diversas perspectivas, ou seja, explorando a multidimensionalidade do modelo criado. O cubo de dados é uma representação abstrata da representação analítica dos dados armazenados multidimensionalmente. De modo simples, o cubo é uma metáfora visual. Os dados são vistos de acordo com as dimensões.

A figura a seguir mostra o exemplo do modelo multidimensional em sua representação em forma de cubo, note que essa é uma das possíveis representações, como o cubo é uma metáfora, a figura apresenta apenas o número possível para este: três dimensões. Cada cubo representa um valor de venda, e as faces do cubo representam as dimensões de análise: produto, fornecedor e tempo.

FIGURA 14 – REPRESENTAÇÃO MULTIDIMENSIONAL NA FORMA DE UM CUBO DE DADOS

FONTE: O autor (2018)

No que se refere aos cubos, um conceito que comumente é empregado é o de cuboide. Um cuboide é uma combinação de dimensões, é uma maneira visual de compreender a análise multidimensional dos dados. No exemplo a seguir, veremos um cubo de dados que contém 4 dimensões (tempo, item, local e fornecedor) isto implica que para realizar a análise serão 16 cuboides gerados a partir dele, conforme mostra a figura a seguir.

FIGURA 15 – CUBOIDES

FONTE: Pan (2017)

Ainda segundo Pan (2017), um cuboide básico possui os dados mais detalhados, exceto os próprios dados de origem; é composto de todas as dimensões, como (tempo, item, localização, fornecedor). Por exemplo, um usuário pode explorar o cuboide base (tempo, item, localização, fornecedor) ao longo da dimensão "fornecedor" para cuboide (hora, item, local). E neste caso, o cuboide base é o cuboide parental, ou seja, que representa uma hierarquia e um cuboide 3D (tempo, item, localização) que representa uma hierarquia pai → filho.

OLAP vs OLTP na prática

As siglas OLTP e OLAP são bastante utilizadas no universo do Business Intelligence (BI), porém, ambas possuem conceitos divergentes e são aplicadas em contextos diferentes. Neste artigo entenderemos melhor cada uma.

O OLTP, do inglês “Online Transaction Processing”, é o termo usado para se referir aos sistemas transacionais, ou seja, os sistemas operacionais das organizações. São utilizados no processamento dos dados de rotina que são gerados diariamente através dos sistemas informacionais da empresa e dão suporte às funções de execução do negócio organizacional.

Já o OLAP, do inglês “Online Analytical Processing”, trata da capacidade de analisar grandes volumes de informações nas mais diversas perspectivas dentro de um Data Warehouse (DW). O OLAP também faz referência às ferramentas analíticas utilizadas no BI para a visualização das informações gerenciais e dá suporte para as funções de análises do negócio organizacional. Estes sistemas se diferenciam em outros aspectos, são eles:

QUADRO 1 – COMPARATIVO OLAP X OLTP

Os bancos de dados relacionais ainda são maioria em sistemas de informação denominados como OLTP, uma vez que têm ênfase em garantir a integridade durante as transações no uso do sistema. Uma vez que neste momento já passamos pela ETL, a partir de agora os sistemas OLTP podem fazer parte de um Data Warehouse apenas na forma de fontes de dados.

Em ambientes de Data Warehouse, nos quais se tem as análises como principal objetivo, serão realizadas operações OLAP (Online Analytical Processing – Processamento Analítico On-line). De maneira simples, OLAP é a capacidade do sistema processar os dados analiticamente, explorando a multidimensionalidade do banco de dados em que os dados estão armazenados. O foco da realização de operações OLAP é o processamento on-line de dados com foco em análise para tarefas de tomada de decisão. As análises ocorrem em um tempo mais rápido, objetivando-se atingir tempo real nas consultas, são executadas de maneira eficiente quando comparadas com as mesmas consultas executadas em um ambiente OLTP.

Os denominados Servidores OLAP, que implementam esta arquitetura, sempre empregam uma visão multidimensional dos dados, fazendo com que haja grande aplicabilidade quando integrados a bancos de dados multidimensionais. No que se refere a estas implementações, elas podem ser ROLAP, MOLAP e HOLAP. Segundo Vieira (s.d.), a definição destes servidores tem o seguinte:

ROLAP – Relational Online Analytical Processing: partindo do nome, nessa implementação, o servidor para manipular os dados será implementado utilizando um sistema gerenciador de banco de dados relacional. Durante a implementação, o servidor é constituído de uma camada de interface entre o modelo relacional e o modelo multidimensional, pois transformam as requisições multidimensionais do usuário em rotinas de acesso às tabelas, que armazenam os dados. Sua vantagem é a eficiência no armazenamento de dados esparsos e o segredo está na modelagem dos dados.

MOLAP – Multidimensional Online Analytical Processing: nessa implementação específica para a multidimensionalidade, para este fim e para isto armazenam e executam operações diretamente sobre uma matriz de dados. Se os dados não forem esparsos, esses servidores são mais eficientes em armazenamento e recuperação do que os servidores ROLAP, uma vez que sua arquitetura é projetada especificamente para este fim.

HOLAP – Hybrid Online Analytical Processing: em uma aplicação híbrida, em uma abordagem atual próxima às aplicações mobile que usam um misto de tecnologias, esta implementação utiliza uma integração entre as duas abordagens vistas anteriormente. Os servidores HOLAP adotam uma forma de armazenamento em dois níveis, um para dados densos, que são colocados em matrizes e outro para dados esparsos, que são alocados em tabelas. Ou seja, torna-se uma aplicação robusta integrando tanto matrizes quanto tabelas armazenando o modelo multidimensional, o que demanda um maior requisito de equipe para desenvolvê-lo.

DOLAP – Desktop Online Analytical Processing: esse tipo de OLAP não se refere à implementação do armazenamento, mas à distribuição de dados. Essa abordagem tem como objetivo otimizar as consultas através do armazenamento no computador do usuário. Isto não significa que não haverá um servidor que armazena os dados, mas que o computador do usuário também receberá os dados. O conjunto de dados multidimensionais deve ser criado no servidor e uma cópia é transferida para o desktop. Utilizando esta técnica é possível trazer portabilidade aos usuários OLAP, que não possuem acesso direto ao servidor, no entanto, têm que ter um cuidado com o período da análise, uma vez que o ambiente Desktop não pode ficar diferente do servidor OLAP.

Independentemente da estratégia de implementação de um servidor OLAP, a arquitetura deverá prover recursos para extrair informação e conhecimento por intermédio do modelo multidimensional. Utilizando as operações OLAP, é possível navegar pela hierarquia dos dados, explorando o cubo de dados, a multidimensionalidade e a granularidade dos dados.

Neste momento, você deve ter se perguntado o que significa granularidade. A granularidade vem realmente de grão, qual o menor grão (dado) possível de ser armazenado, o grão é o menor nível da informação e é definido de acordo com as necessidades elencadas no início do projeto. Ele é determinado para cada tabela Fato, já que normalmente as Fatos possuem informações e granularidades distintas. Segundo Elias (2014), é importante entender o relacionamento existente entre o detalhamento e a granularidade. Quando falamos de menor granularidade, ou granularidade fina, significa maior detalhamento (menor sumarização) dos dados. Maior granularidade, ou granularidade grossa, significa menor detalhamento (maior sumarização). Assim podemos notar que a granularidade e o detalhamento são inversamente proporcionais.

Tradicionalmente, os servidores permitem a exploração dos dados mediante à realização das operações OLAP e operam aumentando e diminuindo a granularidade dos dados. Tais operações são:

Slice: em português essa operação significa fatiar. Assim, retornam valores específicos de uma dimensão do cubo, pode-se dizer que fatia uma parte do cubo a ser visualizado. Pode-se dizer que seleciona uma dimensão específica de um determinado cubo e fornece um novo subcubo. A figura a seguir mostra um exemplo de uma operação Slice, onde inicialmente existem três dimensões (cidade, tempo e itens) e após a realização da operação foi aplicado um filtro de tempo selecionado apenas o bimestre Q1, sendo assim, fatiou-se mostrando apenas duas dimensões.

FIGURA 17 – OPERAÇÃO DE SLICE

FONTE: Han, Pei e Kamber (2011)

Dice: o tempo dice não tem uma tradução específica em português, mas o significado mais próximo é “parte de um cubo”. Esta operação são slices consecutivos, permitindo gerar diversos cortes no cubo, gerando um subcubo. No exemplo da figura a seguir, notamos que o círculo do meio representa um conjunto de filtros, tais filtros podem ser compreendidos como slices que em conjunto formam um dice.

FIGURA 18 – OPERAÇÃO DE DICE

FONTE: Han, Pei e Kamber (2011)

Drill-Down: este operador navega a partir de dados, obtendo um maior nível de detalhamento, aproximando-se da granularidade mínima. Ao aplicar essa operação, está descendo uma hierarquia de conceitos para uma dimensão. A figura a seguir, assim como nos exemplos anteriores, mostra um cubo inicial, quando realizada uma operação de drill-down, que expande os dados do cubo, trazendo as mesmas informações, que antes eram mostradas por bimestre, agora organizadas por meses. Pode-se dizer que a operação de drill-down expande o cubo de dados.

FIGURA 19 – OPERAÇÃO DE DRILL-DOWN

FONTE: Han, Pei e Kamber (2011)

Roll-Up: oposto do operador drill-down, sumariza as informações, diminuindo o nível de detalhes. A operação de roll-up executa a agregação em um cubo de dados. A figura seguinte mostra que a hierarquia está definida em palavras e textos. A operação de roll-up, no exemplo, agrega os dados de palavras para textos, gerando um cubo resultante com o total de ocorrências por textos, ao invés do cubo inicial que agrupava por palavra.1

FIGURA 20 – OPERAÇÃO DE ROLL-UP

FONTE: Han, Pei e Kamber (2011)

Uma vez conhecido os operadores OLAP, podemos explorar as dimensões de um Data Warehouse. Essas operações são executadas no servidor OLAP e consumidas pelas ferramentas de visualização de dados.

5 - CAMADA DE APRESENTAÇÃO DOS DADOS E FERRAMENTAS DE VISUALIZAÇÃO

Seguindo a arquitetura proposta por Kimball e até mesmo na mesma lógica de Inmon, as fontes de dados são definidas pelo cenário de aplicação, a área de preparação definido pela ETL, que ao fim realiza a carga no banco de dados multidimensional. O servidor OLAP representa a camada de apresentação, fornecendo os dados através de suas operações.

Uma vez feito isso, os dados já estão pré-processados, limpos e armazenados, deste modo estando prontos para que sejam consumidos pelas aplicações. As ferramentas de apresentação podem ser uma aplicação específica ou, o caso mais convencional, a utilização de uma ferramenta para a geração de dashboards. Tendo em vista que o objetivo do livro é a construção de dashboards, nosso próximo capítulo será dedicado a discorrer pelas ferramentas em detalhes.

CONSIDERAÇÕES FINAIS

Prezado aluno!

Chegamos ao fim do Capítulo 2, esperamos que tenha sido proveitoso para você. Este capítulo teve como foco trazer conceitos sobre Data Warehouse e lhe propiciar conhecimento para construí-lo.

Iniciamos o capítulo relembrando o conceito de business intelligence, relembrando que é uma metodologia e não uma ferramenta, apresentando assim a arquitetura de um Data Warehouse como uma das principais ferramentas.

Durante esse capítulo, você pôde aprender os conceitos essenciais de Data Warehouse, conheceu a etapa de ETL, que consome 80% do processo de Data Warehousing. Na ETL aprendeu em detalhes o que é extração, transformação e carga.

Em nosso estudo, você desmistificou um dos maiores dilemas do estudo de Data Warehouse: a diferença entre OLAP e OLTP. Nesse momento foi importante nosso aprendizado sobre modelagem multidimensional. No estudo sobre OLAP vimos os tipos de servidores e como é feita a implementação.

Durante o capítulo discutimos tópicos atuais sobre ferramentas e técnicas de coleta e processamento, que temos certeza de que serão úteis no seu dia a dia como analista de dados. Lembre-se de que tecnologia evolui diariamente, por isso nunca deixe de se atualizar sobre o que foi visto até agora.

Dito isto, você está preparado para ir à etapa final do nosso livro, que é o momento de pegar os dados gerados e apresentá-los ao gestor em forma de dashboards, que será o tema do Capítulo 3, nosso capítulo final.