integraÇÃo de dados de redes sociais a armazÉns de … · 2019-11-14 · com cinco dimensões...

INTEGRAÇÃO DE DADOS DE REDES SOCIAIS A

ARMAZÉNS DE DADOS

ELAINE MUNIZ BARBOSA

INTEGRAÇÃO DE DADOS DE REDES SOCIAIS A

ARMAZÉNS DE DADOS

Dissertação apresentada ao Programa dePós-Graduação em Ciência da Computaçãodo Instituto de Ciências Exatas da Univer-sidade Federal de Minas Gerais como re-quisito parcial para a obtenção do grau deMestre em Ciência da Computação.

Orientador: Clodoveu Augusto Davis Junior

Belo Horizonte

Dezembro de 2016

c© 2016, Elaine Muniz Barbosa.Todos os direitos reservados.

Muniz Barbosa, ElaineB238i Integração de dados de redes sociais a armazéns de

dados / Elaine Muniz Barbosa. — Belo Horizonte, 2016xxii, 63 f. : il. ; 29cm

Dissertação (mestrado) — Universidade Federal deMinas Gerais

Orientador: Clodoveu Augusto Davis Junior

1. Computação - Teses. 2. Armazenamento de dados.3. Mineração de dados (Computação). 4. Redes sociaisonline. 5. Inteligência competitiva (Administração).6. Dados não estruturados. I. Orientador. II. Titulo.

CDU 519.6*73(043)

Dedico este trabalho a todos que fazem parte da minha vida e me ajudaram aconquistar mais essa oportunidade de crescimento. Dedico também às pessoas queentendem o significado de liberdade como o direito de agir segundo o seu livre arbítrioe o dever de fazer algo em prol da humanidade.

vii

Agradecimentos

Inúmeros são os nomes que contribuíram para que eu chegasse até aqui. Por conveni-ência, evitarei citar nomes. Mas quando você estiver lendo isso e, de alguma forma tetocar, pode ter certeza que você faz parte dessa conquista.

Primeiramente agradeço a Deus por mais essa oportunidade de crescimento eamadurecimento em minha vida. Sem Ele eu não teria forças para concluir esse projeto.

Agradeço aos meus familiares pelo apoio e compreensão pela ausência por deixarde visitá-los nas datas comemorativas para poder terminar algum trabalho de algumadisciplina ou até para estudar para alguma prova.

Agradeço aos professores que me ajudaram a aprimorar ainda mais meus conhe-cimentos, em especial ao Prof. Clodoveu pela orientação e paciência nos momentos deindecisão.

Agradeço aos amigos de longa data e àqueles que foram surgindo ao longo dessatrajetória que estavam sempre presentes nos momentos de alegrias e desesperos.

E, para terminar, agradeço a todos do meu ambiente de trabalho que souberamentender a importância desse título na minha carreira e que direta ou indiretamenteme ajudaram a chegar onde cheguei.

ix

“O silêncio fala muito e não comete erros.Para cada sofrimento seu, para cada dor, lembre-se: você é mais forte tendo fé.

Felizes aqueles que acreditam de verdade, eles nunca estarão sozinhos.”(Autor desconhecido)

xi

Resumo

Na corrida para atender às demandas do mercado, as empresas buscam por soluçõesque as diferenciem de modo a aumentar sua competitividade. Decisões rápidas e corre-tas são fundamentais para uma empresa alcançar bons resultados. Dessa forma, quantomais dados e informações úteis uma empresa conseguir, mais competitiva ela se tor-nará. Nesse contexto, enriquecer o armazém de dados de uma empresa a partir dedados não-estruturados advindos da Web, que cada vez mais disponibiliza um grandevolume de dados para consultas e coletas, pode proporcionar maior competitividadecom informações mais detalhadas. No entanto, a integração dos dados não-estruturadosda Web com dados estruturados de um armazém de dados existente é uma atividadedesafiadora. Sendo assim, este trabalho propõe uma metodologia para integrar dadosnão-estruturados aos dados estruturados, com o objetivo de agregar valor ao armazémde dados de uma organização. Para comprovar a viabilidade da metodologia proposta,a mesma foi aplicada em um estudo de caso no contexto de um armazém de dadosvoltado para vendas online de produtos. Tal armazém de dados foi complementadocom cinco dimensões extraídas de dados não-estruturados de uma rede social. Mé-tricas foram definidas para análise, e os resultados demonstraram que é válido o usode uma metodologia no processo de integração dos dados, pois é uma forma de ori-entar ações padronizadas para a obtenção de resultados comuns na organização. Osdados coletados da Web são transformados em informações úteis com valor estratégicopara auxiliar a tomada de decisão, além de aumentar a base de conhecimento de umaorganização.

Palavras-chave: Inteligência de negócio, Armazém de dados, Integração, Dados não-estruturados.

xiii

Abstract

Organizations often look for solutions to increase their competitiveness, because theyneed to supply the market’s demands. Hence, fast and correct decisions are importantfor a company to achieve better results. A company becomes more competitive whenit has access to useful data and information. In this context, managers can improvecompetitiveness by using information that can enrich an existing data warehouse withunstructured Web data. However, integrating unstructured data from the Web tocontent structured and organized as a data warehouse is a challenge. Therefore, thiswork proposes a methodology for integrating data from informal and unstructuredsources, such as social networks, to legacy structured data, seeking to increase thevalue of a company’s data warehouse. The proposed methodology is applied in acase study, whose context is a data warehouse on sales, to verify its feasibility. Fivenew dimensions are added to the data warehouse, the contents of which are extractedfrom unstructured data gathered from Twitter. Metrics are defined for a comparativeanalysis, and results show that the proposed methodology is a valid addition to the dataintegration process, since it can focus standardized actions to get better results for thecompany. Thus, data collected from the Web are transformed in useful informationwith strategic value to help the decision making process, as well as increasing theknowledge dataset of an organization.

Keywords: Business Intelligence, Data Warehouse, Integration, Unstructured Data.

xv

Lista de Figuras

2.1 Exemplo de uma tabela fato . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Exemplo de uma tabela dimensão . . . . . . . . . . . . . . . . . . . . . . . 102.3 Tabelas fato e dimensão no modelo dimensional . . . . . . . . . . . . . . . 102.4 Elementos centrais da arquitetura de DW/BI . . . . . . . . . . . . . . . . 112.5 Documento no formato JSON . . . . . . . . . . . . . . . . . . . . . . . . . 232.6 Documento no formato JSON . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Visão geral da metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 Entrada - Processamento - Saída . . . . . . . . . . . . . . . . . . . . . . . 333.3 Exemplificando o Cubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Modelo Multidimensional . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Avaliação individual dos armazéns . . . . . . . . . . . . . . . . . . . . . . . 514.3 Avaliação da integração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4 Lugares que mais criticam os produtos . . . . . . . . . . . . . . . . . . . . 524.5 Lugares que mais elogiam os produtos . . . . . . . . . . . . . . . . . . . . 534.6 Comentários por itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.7 Itens mais criticados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.8 Itens mais elogiados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.9 Valor das vendas por lugar . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.10 Lugares com mais comentários positivos . . . . . . . . . . . . . . . . . . . 574.11 Temas mais relevantes por item . . . . . . . . . . . . . . . . . . . . . . . . 584.12 Temas mais relevantes por lugar . . . . . . . . . . . . . . . . . . . . . . . . 58

xvii

Lista de Tabelas

2.1 Comparação das características de bancos de dados tradicionais e de arma-zéns de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 MongoDB vs Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Definição de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Processamento ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Código dos dados não categorizados . . . . . . . . . . . . . . . . . . . . . . 333.5 Dimensão DIM_TEMPORAL . . . . . . . . . . . . . . . . . . . . . . . . . 353.6 Dimensão DIM_TEMPORAL_ADV . . . . . . . . . . . . . . . . . . . . . 363.7 Dimensão DIM_ESPACIAL . . . . . . . . . . . . . . . . . . . . . . . . . . 373.8 Dimensão DIM_LOCALIZACAO . . . . . . . . . . . . . . . . . . . . . . . 373.9 Dimensão DIM_TEMATICA . . . . . . . . . . . . . . . . . . . . . . . . . 383.10 Dimensão DIM_ANALISE_SENTIMENTO . . . . . . . . . . . . . . . . . 383.11 Dimensão CUBO_FATO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.12 Disponibilização da Informação . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Armazém da Microsoft (DWM) . . . . . . . . . . . . . . . . . . . . . . . . 484.2 Armazém coletado da Web (DWW) . . . . . . . . . . . . . . . . . . . . . . 494.3 Armazém integrado (DWI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

xix

Sumário

Agradecimentos ix

Resumo xiii

Abstract xv

Lista de Figuras xvii

Lista de Tabelas xix

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Conceitos e Trabalhos Relacionados 52.1 Business Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Modelo Multidimensional . . . . . . . . . . . . . . . . . . . . . 82.2.2 Arquitetura de um Armazém de Dados . . . . . . . . . . . . . . 112.2.3 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Metadados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.5 OLAP e OLTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.6 Data Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Dados Estruturados e Não Estruturados . . . . . . . . . . . . . . . . . 152.4 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 Big Data Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6.1 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

xxi

2.7 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Metodologia Proposta 273.1 Visão Geral da Metodologia . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1 Definição de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 293.1.2 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.3 Processamento ETL . . . . . . . . . . . . . . . . . . . . . . . . 313.1.4 Disponibilização da Informação . . . . . . . . . . . . . . . . . . 40

3.2 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Estudo de Caso, Resultados e Análise 434.1 Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Fonte de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Ferramentas e Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Considerações Finais e Trabalhos Futuros 59

Referências Bibliográficas 61

xxii

Capítulo 1

Introdução

Hoje em dia, as organizações detêm uma enorme quantidade de dados, sejam eles arma-zenados em bancos de dados, em formato de arquivo de texto digital ou muitas vezesainda em papel. No entanto, quando esses dados não estão integrados, contribuempouco para a geração de conhecimento. Os dados precisam ser trabalhados, contex-tualizados e gerenciados para que se possa extrair deles alguma informação útil. Essainformação vai gerar conhecimento, agregar valor e orientar a organização no processode tomada de decisão adequada.

A utilização de tecnologias facilita a manipulação de pequenos a grandes volumesde dados. O sucesso pode ser garantido pela velocidade em que as informações são as-similadas e pela rapidez em que são tomadas as decisões. Nesse contexto, as empresastêm como grande aliado o Business Intelligence (BI) ou Inteligência de Negócios que,para Barbieri [2001], é um dos principais conceitos no que diz respeito à gestão em-presarial, proporcionando benefícios e viabilizando a geração de relatórios de apoio aoprocesso decisório. A geração de informações rápidas, precisas e principalmente úteispara o processo de tomada de decisão garante uma estruturação de gestão diferenciada,resultando em vantagem competitiva sobre as demais empresas.

De acordo com Kimball & Ross [2013], as informações de uma empresa são umdos seus bens mais preciosos. Quase sempre a empresa mantém esse bem de duasformas: os sistemas transacionais e o armazém de dados. Comparado a um sistematransacional, um armazém de dados possui necessidades diferentes, clientes, estruturasdiferenciadas e periodicidade. Algumas vezes, encontra-se supostos armazéns de dadosque são meras cópias do sistema transacional armazenadas em outro disco ou outroservidor. Isso é feito para isolar o operacional da empresa e o seu armazém por razõesde desempenho. No entanto, esses dois sistemas são diferentes, e as necessidades dosusuários também são distintas.

1

2 Capítulo 1. Introdução

Singh [2001] define o termo Data warehousing (DW) como sendo o processo deintegração dos dados corporativos de uma empresa em um único repositório a partirdo qual os usuários finais podem facilmente executar consultas, gerar relatórios e fa-zer análises. O autor descreve um data warehouse como um ambiente de suporte àdecisão que alavanca dados armazenados em diferentes fontes e os organiza e entregaaos tomadores de decisões da empresa, independente da plataforma que utilizam oude seu nível de qualificação técnica. Um exemplo prático, uma rede de lojas de depar-tamento pode manter um data warehouse para armazenar os dados provenientes dasvendas possibilitando rastrear todos os produtos de sua rede, elaborando estratégiasde compras, merchandising e marketing.

Singh [2001] afirma ainda que, para serem competitivas, as empresas devem estarpreparadas para lidar com a avalanche de informações em que se baseiam para tomardecisões chave do negócio. É possível coletar e processar grandes quantidades de dadosem pouquíssimo tempo. Mas, uma vez coletados, os dados precisam ser analisados paradeterminar sua relevância. A não implementação de sistemas e métodos para realizar aanálise dos dados resultará em desvantagens no mercado para essas empresas. À medidaque uma maior quantidade de dados torna-se disponível, o processo para localizar eextrair informações úteis fica mais complexo.

A cada dia, dados não-estruturados tornam-se importantes para a competitivi-dade da empresa, como por exemplo, perfis de clientes na rede/web e a recuperaçãode temas de interesse da empresa nas mídias sociais. Novos desafios são gerados paraos negócios, como a incorporação dos dados de redes sociais e de outros dados não-estruturados no ambiente tradicional de Business Intelligence (BI). A integração dedados não-estruturados com dados estruturados pode produzir uma poderosa fonte deinformação para a tomada de decisão [González & Berbel, 2014].

Segundo Alqarni & Pardede [2012], a proliferação de dados não-estruturados temexcedido a quantidade de dados estruturados. Nos últimos anos, o volume de dados não-estruturados tem aumentado bastante, devido ao aumento no uso da Internet e o grandenúmero de indivíduos e organizações que criam e armazenam tais dados. Documentosnão-estruturados como e-mails, documentos de negócios, faturas, contratos, relatóriosde agências governamentais e comentários de clientes geralmente não são incluídos noarmazém de dados devido à natureza do formato de texto simples e à ausência de umesquema estruturado.

Considerando o contexto atual, este trabalho propõe a identificação e integraçãode novas dimensões e fatos a um armazém de dados estruturado já consolidado atravésda extração de dados não-estruturados da Web, com o intuito de agregar e enriquecero DW. Isso poderá proporcionar mais competitividade para a empresa e permitirá aos

1.1. Motivação 3

usuários do DW buscar informações mais detalhadas e realizar novos tipos de análisesa partir desses dados não-estruturados e de sua combinação com os dados tradicionais.

Um dos grandes desafios da abordagem proposta nesse trabalho é garantir quesomente dados não-estruturados úteis, ou seja, que possam agregar algum valor, sejamintegrados ao armazém de dados. Outro desafio é organizar esses dados em forma dedimensões e fatos a um DW existente.

1.1 Motivação

Não basta para as organizações armazenar os dados. É preciso tratá-los de forma queseja possível extrair deles informações úteis. Entretanto, devido ao grande volume dedados, o processo de análise torna-se impraticável para humanos, demandando novastecnologias capazes de automatizar esse processo. Paralelamente, a diversidade defontes de dados potencialmente úteis aumentou, e passou a incluir fontes que estãofora do controle direto da organização, como comentários de usuários em redes sociais.Na corrida para atender às demandas do mercado, as empresas buscam soluções queas diferenciem, aumentando a sua competitividade. Decisões rápidas e corretas sãofundamentais para a empresa alcançar bons resultados. Incluir fontes de dados querepresentem um acesso mais direto às opiniões e discussões dos consumidores ou clientestorna-se estrategicamente importante nesse contexto.

Assim, diante dos grandes desafios impostos para a automatização do processode integração e análise dos dados, aliado ao fato do crescente aumento de dados não-estruturados, é grande a necessidade de métodos que possam contribuir com o usuáriopara um tratamento efetivo do grande volume de dados provenientes de múltiplas fon-tes, e de seus tipos e formatos variados. Com a proposta deste trabalho de propormétodos para integrar dados não-estruturados a um armazém de dados, pretende-seenriquecê-lo e, consequentemente, auxiliar no processo de tomada de decisão, permi-tindo aplicar operações de análise, disponibilizadas pelas ferramentas OLAP, tambémem dados vindos de fontes não-estruturadas ou combinadas, aprimorando o processodecisório.

1.2 Objetivos

Parte dos dados de uma instituição encontra-se armazenada de maneira não-estruturada, em forma de comentários de usuários, e-mails recebidos, contratos, men-sagens em redes sociais, e outros. Este trabalho tem por objetivo geral propor mé-

4 Capítulo 1. Introdução

todos para enriquecer o DW de uma organização a partir da extração de dados não-estruturados obtidos de diversas fontes e formatos, e identificar novas dimensões etabelas de fatos a partir dos dados extraídos para agregar valor ao processo decisórioda organização.

Como parte dos objetivos específicos estão:

• Extrair dados não-estruturados da Web, por exemplo, comentários de usuários ee-mails recebidos;

• Armazenar esses dados não-estruturados em um gerenciador de banco de dadosNoSQL;

• Aplicar técnicas nos dados coletados para identificar dimensões e fatos;

• Definir métricas através dos dados extraídos conforme a estratégia da organiza-ção;

• Demonstrar a viabilidade das ideias e propostas apresentadas através de um es-tudo de caso;

• Agregar ao armazém de dados do estudo de caso as dimensões e fatos que foramidentificadas a partir de fontes não-estruturadas;

• Agregar ao armazém de dados do estudo de caso as métricas definidas;

• Analisar os resultados a partir das métricas.

A principal contribuição deste trabalho é a proposta de uma metodologia paraintegrar dados não-estruturados advindos da Web a dados estruturados de armazénsde dados, com o objetivo de enriquecê-los, agregando valor aos dados.

1.3 Organização do Trabalho

O restante deste trabalho está organizado da seguinte maneira. O Capítulo 2 apresentaos conceitos básicos utilizados na metodologia proposta e discute os trabalhos relacio-nados relevantes para este trabalho. O Capítulo 3 detalha a metodologia proposta paraintegração dos dados e enriquecimento de armazéns de dados. O Capítulo 4 apresentaum estudo de caso utilizando a metodologia proposta para análise de sua viabilidade,bem como os resultados obtidos e uma análise crítica dos resultados. O Capítulo 5apresenta considerações finais e propostas para trabalhos futuros.

Capítulo 2

Conceitos e Trabalhos Relacionados

Neste capítulo são apresentados os conceitos necessários para o entendimento do de-senvolvimento desse trabalho, bem como uma revisão dos trabalhos relacionados erelevantes que tratam da integração de dados estruturados e não-estruturados. Na me-todologia proposta nesse trabalho, um data warehouse estruturado é enriquecido comdados não-estruturados coletados das redes sociais. Esses dados integrados são anali-sados e decisões podem ser tomadas por meio das novas informações geradas. Ao finaldo capítulo, é colocado como todos esses conceitos se relacionam com a metodologiaproposta.

2.1 Business Intelligence

Business Intelligence (BI) ou Inteligência de Negócios é o resultado de um processoque começa com a coleta de dados. Esses dados são organizados e transformados eminformação que, depois de analisada e contextualizada, transforma-se em inteligência.BI é uma solução que coloca a empresa em uma posição diferenciada (privilegiada)aumentando a sua competitividade. Decisões rápidas e corretas são fundamentais paraa empresa alcançar bons resultados. Neste contexto, BI proporciona benefícios signifi-cativos na gestão da empresa viabilizando a geração de relatórios de apoio ao processodecisório. Assim, torna-se um grande aliado das empresas fortalecendo seus planosde atuação. A geração de informações rápidas, precisas e principalmente úteis parao processo de tomada de decisão garante uma estruturação de gestão diferenciada,resultando em vantagem competitiva sobre as demais empresas.

De uma forma mais ampla, BI pode ser entendida como a utilização de variadasfontes de informação para definir estratégias de competitividade nos negócios da em-presa. Também pode ser entendida como uma relação direta ao apoio e subsídio aos

5

6 Capítulo 2. Conceitos e Trabalhos Relacionados

processos de tomada de decisão baseada em dados trabalhados especificamente paraa busca de vantagens competitivas. Nessa definição, podem ser incluídos os conceitosde estruturas de dados, representadas pelos bancos de dados tradicionais, data wa-rehouse e data marts, criados com o objetivo do tratamento relacional e dimensionaldas informações, bem como as técnicas de data mining aplicadas sobre elas, buscandocorrelações e fatos escondidos [Barbieri, 2001].

Trazendo os conceitos de BI para uma situação prática, para as eleições, pormeio da análise de séries histórias de dados eleitorais, pode identificar mudanças nocomportamento dos eleitores e a equipe de campanha pode adotar estratégias de acordocom cada perfil eleitoral. Por exemplo, em 2014, ano da copa e eleições presidenciais,com dados coletados de redes sociais, foi possível prever locais de manifestações ereforçar o esquema de segurança.

2.2 Data Warehouse

Um Data Warehouse (DW) é caracterizado como uma coleção de dados orientada porassunto, integrada, não volátil, variante no tempo, que dá apoio às decisões da admi-nistração. Os data warehouses proporcionam acesso aos dados para análise complexa,descoberta de conhecimento e tomada de decisão, e são bastante distintos dos ban-cos de dados tradicionais em sua estrutura, funcionalidade, desempenho e propósito[Elmasri & Navathe, 2005]. A Tabela 2.1 apresenta uma comparação das característi-cas dos bancos de dados tradicionais e dos armazéns de dados de acordo com Rob &Coronel [2011]. As diferenças constituem bons indicadores das suas necessidades e aimportância de estarem em ambientes diferentes.

Data Warehouse é um armazém de dados históricos que funciona como ferramentaque dá suporte à tomada de decisão estratégica da empresa, tornando-se um compo-nente importante para Business Intelligence. Dentre as tecnologias envolvidas em BI,as de DW e OLAP (OnLine Analytical Processing) têm sido amplamente usadas paraidentificar, coletar, processar, integrar e analisar informação para tomada de decisão,promovendo assim a gestão de negócios. Dados armazenados em um DW usado porum sistema convencional OLAP são estruturados por natureza e, geralmente, um DWé implementado sobre um sistema gerenciador de banco de dados relacional (SGBDR).Entretanto, dados como documentos de texto, imagens e vídeos, caracterizados comosemiestruturados ou não-estruturados, também podem conter informações de grandevalor para os negócios [González & Berbel, 2014; Bonnet et al., 2011; Carniel et al.,2012; Dehdouh et al., 2014].

2.2. Data Warehouse 7

Tabela 2.1. Comparação das características de bancos de dados tradicionais ede armazéns de dados

Característica Dados operacionais Dados de suporte a decisão

Atualidade dosdados

Operações correntesDados em tempo real

Dados históricosRetrato instantâneo dos dadosda empresaComponente temporal (se-mana/mês/ano)

Granularidade Dados detalhados no nível indivisí-vel Dados resumidos

Nível de resumo Baixo; alguns resultados agregados Alto; vários níveis de agregação

Modelo de da-dos

Altamente normalizadoPrincipalmente SGBD relacional

Não normalizadoEstrutura complexaPrincipalmente em SGBD multi-dimensional, embora com algunsaspectos relacionais

Tipo de transa-ção Principalmente atualizações Principalmente consulta

Volumes detransação Alto volume de atualizações Cargas periódicas e cálculos resu-

midosVelocidade detransação As atualizações são fundamentais As recuperações são fundamen-

taisAtividade deconsulta De baixa a média Alta

Escopo da con-sulta Pequena amplitude Grande amplitude

Complexidadeda consulta De simples a média Muito complexa

Volume de da-dos Centenas de MB, até GB Centenas de GB, até TB

Desde a primeira publicação em 1996, Kimball & Ross [2013] afirmam que algunsconceitos são tão universais que ainda direcionam os requisitos fundamentais para umsistema de DW/BI. São eles:

• O sistema de DW/BI deve fazer com que as informações de uma empresa possamser facilmente acessadas. Seu conteúdo deve ser compreensível, e seus dadosdevem ser intuitivos e óbvios para o usuário da área de negócios e não apenaspara o desenvolvedor.

• O sistema de DW/BI deve apresentar as informações da empresa de modo con-sistente e os dados devem ser confiáveis. Eles devem ser obtidos cuidadosamentea partir de várias fontes na empresa, filtrados, submetidos a um controle de qua-lidade e liberados apenas quando estiverem prontos para serem usados.


• O sistema de DW/BI deve ser adaptável e flexível a mudanças, pois as necessi-dades dos usuários, as condições comerciais, os dados e a tecnologia, todos estãosujeitos às mudanças decorrentes do tempo.

• O sistema de DW/BI deve ser seguro a ponto de proteger as informações. Otesouro de informações da empresa está guardado no DW. Por isso, ele devecontrolar de modo eficaz o acesso às informações confidenciais da empresa.

• O sistema de DW/BI deve conter os dados apropriados para dar suporte à tomadade decisões.

• Para que um sistema de DW/BI seja considerado de sucesso, a comunidade denegócio deve aceitá-lo. A aceitação do DW por parte dos usuários das áreas denegócio está relacionada à simplicidade do que a qualquer outro fator.

A fim de analisar um negócio em diferentes perspectivas, o dado de um DW estáorganizado como esquema multidimensional. Um esquema multidimensional consistede tabelas fato e dimensão. Uma tabela fato é o assunto pelo qual a empresa é anali-sada, e as tabelas de dimensão são as diferentes perspectivas de análise [Thenmozhi &Vivekanandan, 2012]. Maiores detalhes são apresentados na Seção 2.2.1.

2.2.1 Modelo Multidimensional

O modelo de armazenamento multidimensional envolve dois tipos de tabelas: de dimen-são e de fatos. Uma tabela de fatos é a principal tabela de um modelo dimensional. Asmedidas numéricas de desempenho da empresa estão armazenadas nessa tabela, comoé mostrado na Figura 2.1 [Kimball & Ross, 2013]. Nessa figura, a tabela fato possuias chaves estrangeiras Data, Produto e Loja provenientes das dimensões referentes aoperíodo da venda, aos produtos e às lojas, e as métricas Quant. Vendida e Mont.Vendas em Reais, que representam a quantidade de produtos vendidos e o montantedas vendas em reais, respectivamente.

De acordo com Kimball & Ross [2013], O termo fato é usado para representaruma medida do negócio da empresa. Uma medida é dada pela interseção de todasas dimensões. Esta lista de dimensões define a granularidade da tabela fato e qual oescopo da medida. Além da interseção com tabelas de dimensões, a tabela fato arma-zena métricas e indicadores de desempenho que medem os descritivos armazenados nastabelas de dimensões. As métricas são as medidas brutas, atômicas e de simples com-posição. Valores e quantidades são exemplos de formatos das métricas, por exemplo,Quantidade de itens X. Os indicadores de desempenho são medidas calculadas e são


Figura 2.1. Exemplo de uma tabela fato

compostos pelas métricas. Estão um nível acima das métricas, pois possuem uma visãomais ampla e direcionada da realidade observada. Além disso, os indicadores avaliamo desempenho organizacional, auxiliam a análise de tendência, a melhoria contínua, aatuação proativa e dão transparência à empresa. Normalmente são expressados porpercentuais, frequência, probabilidade, por exemplo, Percentual de itens X vendidosem março de 2014.

As tabelas de dimensão sempre acompanham uma tabela de fatos. Em um mo-delo dimensional bem projetado, as tabelas de dimensão possuem muitas colunas ouatributos. Esses atributos descrevem as linhas na tabela dimensão e servem como fonteprincipal de restrições de consultas, agrupamentos e rótulos de relatórios [Elmasri &Navathe, 2005; Kimball & Ross, 2013]. A Figura 2.2 ilustra a tabela dimensão quecontém descritores textuais do produto, como por exemplo, descrição da marca, tipoda embalagem, peso do produto, dentre outros.

Os esquemas multidimensionais mais comuns são o star (estrela) e o snowflake(floco de neve). O esquema estrela consiste em uma tabela de fato com uma única tabelapara cada dimensão. O esquema snowflake é uma variação do esquema estrela no qualas tabelas de dimensão são organizadas em uma hierarquia por meio da atividade denormalização [Elmasri & Navathe, 2005].

Um exemplo do esquema estrela é ilustrado na Figura 2.3, onde a tabela fatoconsiste de medidas numéricas relacionadas às vendas e está ligada a um conjuntode tabelas dimensão - Data, Loja e Produto - preenchidas com atributos descritivos[Kimball & Ross, 2013].

Para Kimball & Ross [2013], pensar dimensionalmente é dividir o mundo emdimensões e fatos. Não importa o formato dos dados, as entidades básicas como docliente, do produto, do serviço, da localização, ou do tempo sempre são encontradas.


Figura 2.2. Exemplo de uma tabela dimensão

Figura 2.3. Tabelas fato e dimensão no modelo dimensional

Com um pouco de prática e disciplina é possível integrar as dimensões de diversasfontes de dados. Mas antes da integração, é necessário identificar as dimensões emcada fonte de dados. Este processo chamado pelos autores de “dimensionalization” éuma boa aplicação para análise de Big Data. Por exemplo, um simples Twitter como“Uau! Isso é incrível!”, não parece conter alguma dimensão que valha a pena, mascom algumas análises muitas vezes é possível obter cliente (cidadãos e/ou pacientes),localização, produto (serviço, contrato ou evento), condição de mercado, prestador de


serviço, clima, sessão, fato gerador anterior, resultado final, etc. Para ficar à frentedos grandes fluxos de dados, é necessária alguma forma de automatizar o processo de“dimensionalization”. Os dados de entrada devem ser processados quase que em temporeal, na etapa inicial da extração.

2.2.2 Arquitetura de um Armazém de Dados

Segundo Kimball & Ross [2013], há quatro componentes separados e distintos paraconsiderar no ambiente de DW/BI: sistema transacional, sistema ETL, área de apre-sentação dos dados, e aplicações de inteligência de negócio (BI). Esses componentessão ilustrados na Figura 2.4 e descritos a seguir.

Figura 2.4. Elementos centrais da arquitetura de DW/BI

Fonte: Kimball, 2013, p.19

Sistema transacional: são os sistemas que registram a captura das transaçõesdos negócios. Uma das prioridades desses sistemas é desempenho de processamento edisponibilidade.

Sistema ETL: o sistema ETL (Extract, Transformation and Load) do ambientede DW/BI consiste de uma área de trabalho, estruturas de dados instanciados e umconjunto de processos. Extração é o primeiro passo no processo de obtenção de dadospara o ambiente de DW. O processo de extração (Extracting) significa leitura e en-tendimento dos dados de origem e cópia dos dados necessários para o sistema de ETLpara posterior manipulação. Depois que os dados são extraídos para o sistema ETL,há várias transformações potenciais, como limpeza dos dados (corrigindo erros de or-tografia/digitação, resolvendo conflito de domínio, tratamento de elementos ausentes,


ou analisando formatos padronizados), combinando dados de várias fontes, retirandodados duplicados. A etapa final do processo de ETL é a estruturação física e carga dosdados nos modelos dimensionais da área de apresentação de destino.

Área de apresentação dos dados: esta área é o local onde os dados ficamorganizados, armazenados, e tornam-se disponíveis para serem consultados diretamentepelos usuários, por criadores de relatórios e por outras aplicações analíticas de BI.Kimball & Ross [2013] compartilham da opinião que os dados devem ser apresentados,armazenados e acessados em esquemas dimensionais, seja um esquema relacional emestrela ou em cubos OLAP. A indústria amadureceu a ponto que essa abordagem nãoprecisa mais ser debatida pois, concluiu-se que a modelagem dimensional é a técnicamais viável para a entrega de dados para os usuários de DW/BI.

Outro ponto defendido pelos autores sobre a área de apresentação é que ela deveconter dados atômicos detalhados. Dados atômicos são necessários para resistir a ata-ques imprevisíveis de consultas ad hoc de usuários.

Todas as estruturas dimensionais devem ser construídas usando dimensões emcomum. Essa é a base da arquitetura de barramento do DW. A adesão à arquiteturade barramento é importante para a área de apresentação pois, sem o compartilha-mento das dimensões, um modelo dimensional torna-se um aplicativo independente.Um projeto de DW/BI é levado às ruínas quando os conjuntos de dados não podem seramarrados. A área de apresentação de uma solução de DW/BI de uma grande empresaconsiste em vários modelos dimensionais com muitas das tabelas de dimensões associ-adas e compartilhadas entre tabelas de fatos. Usar a arquitetura de barramento é osegredo para a construção de sistemas de DW/BI distribuídos. Quando a arquiteturade barramento é usada como um framework, é possível desenvolver um DW empresarialcom escopo realista, descentralizado, ágil, e de maneira iterativa.

Aplicações de inteligência de negócio (BI):O termo “aplicação de BI” refere-se à variedade de recursos oferecida aos usuários de negócios para explorar a áreade apresentação e melhorar a tomada de decisão analítica. Por definição, todas asaplicações de BI consultam os dados na área de apresentação do DW/BI. A consultaé o ponto estratégico do uso dos dados para melhorar a tomada de decisão. Umaaplicação de BI pode ser tão simples quanto uma ferramenta de consulta ad hoc, e tãocomplexa quanto uma mineração de dados sofisticada ou aplicativo de modelagem.

2.2.3 Dashboard

Dashboard é o termo utilizado para definir o painel de controle ou painel de instru-mentos de um sistema, onde ficam reunidas informações sobre métricas, desempenho e


também configurações. É definido também, por Rob & Coronel [2011], como painéis demonitoramento de atividades dos negócios que utilizam tecnologias com base na webpara apresentar os principais indicadores ou informações de desempenho dos negóciosem uma visualização única e integrada, geralmente utilizando gráficos de modo claro,conciso e de fácil compreensão. Essa ferramenta mostra os gráficos gerados a partirdos dados extraídos do Data Warehouse. O usuário final monta os painéis refletindo osdados da empresa tornando mais fácil a análise das informações. Dados apresentadosem gráficos facilitam a visualização de padrões existentes e tendências que são difíceisde identificar quando a informação está em formato de texto.

2.2.4 Metadados

Metadado é o termo usado para descrever a definição dos dados armazenados no datawarehouse e é um aspecto importante deste ambiente. O metadado tem feito partedo processamento de informações há muito tempo. O metadado permite o uso maiseficiente da análise dos dados do armazém (warehouse) assumindo um novo nível deimportância pois, sem o metadado, o usuário não consegue interagir com os dados dodata warehouse, já que não consegue saber como as tabelas estão estruturadas, quaissão as definições precisas dos dados, a origem ou a idade dos dados. A importância dometadado deve-se à possibilidade de ser usado como uma descrição padrão para umagrande variedade de estruturas de dados. Os metadados funcionam como uma enciclo-pédia para o data warehouse e torna-se um fator-chave para os processos envolvidosna criação de um data warehouse e para dar suporte à necessidade do usuário final deacessar os dados [Singh, 2001; Kimball & Ross, 2013].

2.2.5 OLAP e OLTP

OLAP (Processamento Analítico Online, do inglês Online Analytical Processing) é umtermo utilizado para descrever a análise de dados complexos a partir do data warehouse.Os bancos de dados tradicionais dão apoio ao processamento online de transações (On-line Transaction Processing – OLTP) com inclusões, atualizações e exclusões, enquantotambém dão apoio às exigências das consultas de informações. Portanto, eles não po-dem ser otimizados para OLAP, DSS (Sistema de Suporte à Decisão, do inglês DecisionSupport Systems) ou Data Mining (Mineração de Dados). Contudo, os data warehousessão projetados justamente para dar apoio à extração, processamento e apresentaçãoeficiente para fins analíticos e de tomada de decisão [Elmasri & Navathe, 2005].


Juntamente ao OLAP, o OLTP é uma solução eficaz e inteligente que proporci-ona condições favoráveis ao gerenciamento empresarial, tornando pesquisas muito maisfáceis, ágeis e seguras de se fazer, permitindo que haja uma redução considerável detempo na hora de se fazer consultas aos bancos de dados. Enquanto o OLAP trabalhacom dados históricos, no sentido de analisar informações, o OLTP opera com dadosque movimentam o negócio em tempo real, suportando operações cotidianas de negócioempresariais por meio de seu processo operacional. O OLTP tem como função alimen-tar a base de dados que compõem o OLAP, que é multidimensional, já o OLTP é umaferramenta relacional, orientada para o processo, trabalhando com dados do presentee processando um registro de cada vez, não sendo multidimensional como o OLAP. Afinalidade do OLTP é fazer com que uma grande quantidade de pequenas informaçõesnão se perca, processando milhares ou milhões de informações por dia, que contém emcada uma delas uma pequena porção de dados [Elmasri & Navathe, 2005].

OLAP tradicional não foi pensado para processar grandes volumes de dados não-estruturados, e DW tradicional não foi projetado para armazená-los. O advento da Webe outras tecnologias têm aumentado o volume de dados não estruturados. Dados comotexto, imagens e vídeos caracterizados como semiestruturados ou não-estruturados,também podem conter informações de grande valor para os negócios e para o processode tomada de decisão. Relatórios, e-mails, reclamações e sugestões de clientes, vigilân-cia por vídeo, voz em chamadas de clientes podem ser usados para gerar conhecimento.Esses tipos de dados podem ser facilmente acessados e são uma fonte de informaçãoatrativa, mas o processo de extrair e pesquisar por essas informações possui maioresdesafios pois esses tipos de dados são sem-esquema, auto-descritivos e não possuem ummodelo de dados pré-definido. Eles são heterogêneos, volumosos, variáveis por naturezae possuem diferentes formatos [González & Berbel, 2014].

Por mais de uma década, OLAP e análise multidimensional têm gerado meto-dologias, ferramentas e sistemas de gerenciamento de recursos para análise de dadosnuméricos. Com a crescente disponibilidade de dados semi-estruturados, há a necessi-dade de incorporar dados de documentos ricos em texto no data warehouse e forneceruma análise multidimensional adaptada [Ravat et al., 2007].

Argumenta-se que, para fornecer uma análise multidimensional mais exaustiva,os sistemas de suporte à decisão OLAP devem proporcionar o uso de 100% dos dadosdos sistemas de informação corporativos. Mas, até agora, a estrutura OLAP não temcapacidade para lidar com a análise dos dados de documentos semi-estruturados ricosem texto. Como consequência, há a necessidade de modelos conceituais adaptados eprocessamento de agregação textual [Ravat et al., 2007].

2.3. Dados Estruturados e Não Estruturados 15

2.2.6 Data Mart

Kimball & Ross [2013] afirmam que, normalmente, refere-se à área de apresentação dedados (apresentada na Seção 2.2.2 como um dos quatro componentes importantes deum DW) como uma série de data marts integrados. Um data mart é uma parte dotodo que compõe a área de apresentação. Em sua forma mais simples, um data martrepresenta os dados de um único processo de negócio.

2.3 Dados Estruturados e Não Estruturados

Dado estruturado é o dado que é representado por números, tabelas, linhas, colunas,atributos e assim por diante. Como o nome implica, dado estruturado é geralmentedisciplinado, bem comportado, previsível e repetível. Dado textual não-estruturadoé simplesmente um conjunto de caracteres como por exemplo dados encontrados eme-mails, relatórios, documentos, registros médicos e planilhas. Este tipo de dado nãopossui formato, nem estrutura e nem há repetição.

O ambiente estruturado e o não-estruturado crescem lado a lado. O ambiente es-truturado é representado por transações, bancos de dados, registros, chaves e atributos.O ambiente não-estruturado é representado por e-mails, planilhas, registros médicos,documentos e relatórios. Mas ao mesmo tempo eles têm crescido separadamente comose esses mundos existissem em universos paralelos.

O mundo de análise e BI têm crescido em torno da informação estruturada. ComBI, existem exibições de informação, resumos, pivôs e um mundo inteiro de processa-mento analítico. Números que fazem sentido, fatos e figuras se escondem nos sistemasque rodam nas organizações.

Para a análise de texto, que é uma informação não-estruturada, não há nada tãosofisticado quanto o que há em ambientes estruturados. No mundo não-estruturado,poucas ferramentas de busca podem encontrar documentos e seu conteúdo.

Mas isso não significa que não há nada importante e nem informação útil noambiente não-estruturado. Pelo contrário, há uma riqueza de informação muito útil,no entanto não é fácil recuperar essa informação e nem manipulá-la.

Há muitas razões para o dado textual ser mais difícil de manipular do que o dadoestruturado. A principal razão é a falta de organização dos dados textuais e a falta deprevisibilidade sobre o conteúdo dos dados. Dessa forma, é difícil até para encontrá-lo.

Duas abordagens podem ser usadas para fazer análises textuais, uma de arquite-tura e outra tecnológica. A tecnológica acessa e reúne o dado textual em um ambientenão-estruturado. Quando isso acontece, o dado textual é analisado e manipulado no


ambiente não-estruturado. A outra abordagem (de arquitetura) acessa e reúne o dadotextual em um ambiente não-estruturado e então carrega o dado para o ambiente es-truturado para fazer a análise textual nele.

Pode parecer estranho ou até mesmo não-natural escolher a abordagem de acessoe coleta de dado textual no ambiente não-estruturado e então trazer o dado textualpara o ambiente estruturado para o processamento analítico. Entretanto, para Inmon& Nesavich [2007], há boas razões para fazer isso:

• O ambiente analítico já está criado no ambiente estruturado. Assim, os usuáriosjá estão treinados, a equipe de suporte já está treinada, e todas as licenças adqui-ridas, ou seja, um ambiente onde as ferramentas analíticas já estão funcionando.

• Trazendo texto não-estruturado para o ambiente estruturado, pode-se criar linksentre os dados não-estruturados e os dados estruturados já existentes, possibili-tando a análise de um DW integrado que leva em conta ambos os dados.

• Se o dado não-estruturado não é trazido para o ambiente estruturado, é necessáriorecriar uma infraestrutura analítica no ambiente não-estruturado. Se já existeuma infraestrutura analítica pronta, é aconselhável usá-la.

2.4 Big Data

Para Kimball & Ross [2013], Big Data compreende dados estruturados, semiestrutura-dos, não-estruturados e dados brutos em vários formatos diferentes e, em alguns casos,bem diferentes dos números escalares e precisos e textos armazenados nos DW nosúltimos 30 anos. Para os autores, a “grandeza” do Big Data não é a sua característicamais interessante. Muitos dados classificados como Big Data não podem ser analisadoscom uma linguagem de consulta estilo SQL. Mas o mais importante, Big Data é umamudança de paradigma na forma como pensar sobre os dados, onde coletá-los, comoanalisá-los, e o que fazer com a compreensão da análise.

O volume de informação gerado diariamente, sem limitações de edições, comerci-ais ou politicamente correto, é público e gigantesco. As pessoas expressam livrementesuas vontades, necessidades, preferências, visões de mundo, estilo de vida, sonhos e há-bitos de consumo. As redes sociais são consideradas um oceano de informação bruta,pronto para ser usado em prol da inteligência competitiva. Esse descomunal emara-nhando de informações online é o chamado Big Data.

Incorporar Big Data ao ambiente de BI tradicional desperta alguns desafios quesão considerados a seguir.

2.4. Big Data 17

• O conjunto de dados pode estar incompleto;

• Pode haver erro na comunicação entre os dados;

• A qualidade dos dados fica comprometida;

• Há muitas fontes de dados;

• A geração dos dados se dá em tempo real, dessa forma, a análise em tempo real,sendo lenta, pode ser menos útil que uma resposta de qualidade média obtidarapidamente.

No processo de projeto de um DW tradicional, a dificuldade de implementaçãoconsiste em considerar simultaneamente as diferentes fontes de dados disponíveis eos requisitos dos usuários. Com esse fenômeno caracterizado como Big Data, outrosproblemas surgem:

• A quantidade de informação envolvida;

• A variedade dos dados (dificulta gerenciamento dos dados);

• A qualidade dos dados;

• A consistência dos dados;

• A integração de dados estruturados (em BDR) com DNE (dados da Web 2.0 eBig Data) é desafiadora.

Para enfrentar esses problemas e desafios é preciso utilizar metodologias e ferra-mentas adequadas para se extrair dados relevantes que possam alavancar os negócios.Estudos preliminares mostram que as empresas coletam, processam e analisam BigData com novas tecnologias: Hadoop, Map Reduce, NoSQL. Geralmente, Hadoop eNoSQL são usados como Staging Area antes dos dados serem carregados no DW paraanálise (em BDR). Dessa forma, com Big Data Analytics, dados científicos e outrospodem analisar grandes volumes de dados que análises convencionais e/ou soluçõestradicionais de BI não podem alcançar.

Segundo Kimball & Ross [2013], Big Data traz uma série de mudanças e oportu-nidades para TI (Tecnologia da Informação) e é fácil imaginar que um novo conjuntode regras será criado. Mas, com o benefício da experiência em Big Data, muitas boaspráticas têm surgido. Muitas dessas práticas são extensões conhecidas do mundo deDW/BI, e reconhecidamente poucas são novidades e maneiras inovadoras de pensarsobre dados e a missão da TI. A explosão atual de canais de coleta de dados, novos


tipos de dados e novas oportunidades analíticas significa que a lista das boas práticascontinuará a crescer de maneiras interessantes.

Em Kimball & Ross [2013], os autores destacam como o Big Data amplia conside-ravelmente o desafio da integração. Muito dado classificado como Big Data nunca seráarmazenado em um banco de dados relacional. Em vez disso, ficará em um ambienteflexível, como por exemplo, Hadoop. Mas depois que os dados estão integrados, todasas formas de dados podem ser combinadas nas análises individuais. Por exemplo, umestudo médico pode selecionar um grupo de pacientes com determinados atributos destatus demográficos e de saúde e então combinar seus dados convencionais do DW/BIcom dados de imagem (fotografias, radiografias, eletrocardiogramas, e assim por di-ante), com dados livres em forma de texto (notas do médico), com sentimentos demídia social (opiniões dos tratamentos), de pacientes com situações semelhantes, e demédicos com pacientes semelhantes.

2.5 Big Data Analytics

Big Data Analytics é o processo analítico de volumosos e variados conjuntos de dados,por exemplo, Big Data, para descobrir padrões escondidos, correlações desconhecidas,tendências de mercado, preferências dos consumidores e outras informações úteis queajudam as tomadas de decisão das organizações.

Big Data Analytics é a nova fronteira do BI e é importante no setor industrialprivado para as empresas que precisam processar dados para fins de marketing. BigData, vem especialmente da Web, permite adotar novos modelos de negócios, dandomais vantagens do que os obtidos por empresas que dependem de modelos de negóciostradicionais. Big Data Analytics é importante também no setor público, especialmentepara serviços inteligentes envolvidos no monitoramento automático de conteúdo Web[Tria et al., 2014].

A exploração de Big Data é encorajada também pela atual tendência da admi-nistração pública em liberar Dados Abertos (Dados Públicos, Open Data), vindo deministérios, agências estatísticas, e gestores do serviço público. A grande massa de da-dos governamentais pode ser usada para monitorar o desempenho econômico de váriasagências do governo e ministérios, a fim de identificar ineficiências ou desperdício dedinheiro público [Tria et al., 2014].

Entretanto, a análise de Big Data, como acontece em BI, deve adotar um DataWarehouse que permita a extração e produção de informação útil e conhecimento paraserem usados no processo de tomada de decisão. É claro que, Big Data Warehouses

2.6. NoSQL 19

(BDWs) enfrentam novos problemas, como a escolha do modelo para representar umesquema multidimensional. Afinal, Big Data afeta também a metodologia de projetodo DW, que deve superar os limites das metodologias tradicionais [Tria et al., 2014].

Considerando este contexto, dados não estruturados têm bastante importânciae, agregar mais informação para as empresas, enriquecendo o DW atual de tal formaque possa contribuir positivamente para a competitividade da empresa, serve comomotivação para que o volume de informação gerada (Big Data) possa fazer parte doprocesso de BI da organização para que a mesma possa se beneficiar tirando proveitodessa nova tendência [Tria et al., 2014].

Segundo Barbieri [2011], nos próximos anos, os conceitos de Big Data estarãocada vez mais, permeados das diversas aplicações do mercado. O crescimento do vo-lume de informações, na proporção em que se avizinha na era do zettabytes, exigiránovas formulações nos sistemas de inteligência de negócios, com foco na rapidez deseu desenvolvimento e no desempenho que serão demandados. Uma pergunta recor-rente que aparece é se estamos com tecnologia capaz de enfrentar esses gigantescosdepósitos de informações, buscando cada vez mais rapidamente um volume maciço deinformações.

2.6 NoSQL

De acordo com Sadalage & Fowler [2013], o termo “NoSQL” está mal definido e aindanão há uma definição padrão do que NoSQL significa. O termo começou com umworkshop organizado em 2009 e geralmente é aplicado a um número de recentes ban-cos de dados não-relacionais como Cassandra1, Mongo2, Neo4J3 e Riak4. Eles adotamdados sem esquema, são executados em clusters e têm a capacidade de trocar a con-sistência tradicional por outras propriedades úteis. Os defensores de bancos de dadosNoSQL afirmam que eles podem construir sistemas com maior desempenho, com escalamuito melhor e mais fáceis de programar.

Essa categoria de banco de dados surgiu na década de 90. NoSQL, um acrônimopara Not Only SQL, uma tecnologia de armazenamento, gerenciamento e processa-mento de grandes volumes de dados. Essa tecnologia não segue o modelo relacionalde dados e promete ser eficiente, tanto no armazenamento quanto no desempenho dasconsultas. Alguns não utilizam linguagem SQL para consulta e não há necessidade de

1http://cassandra.apache.org/2http://www.mongodb.org/3http://neo4j.com/4http://basho.com/products/

http://cassandra.apache.org/

http://www.mongodb.org/

http://neo4j.com/

http://basho.com/products/


criação de esquemas rígidos para armazenamento de dados como acontece nos sistemasgerenciadores de banco de dados relacionais. NoSQL não veio substituir o modelo re-lacional, veio como uma forma de complementação para auxiliar no armazenamento erecuperação de grandes volumes de dados e/ou para resolver algum problema que sejadifícil de modelar de forma relacional [Leavitt, 2010; Queiroz et al., 2013; Moniruzza-man & Hossain, 2013].

As características mais comuns dos bancos de dados NoSQL apresentadas porSadalage & Fowler [2013] são:

• Não utilizam o modelo relacional (logo não usam a linguagem SQL);

• Funcionam bem em clusters ;

• Estão em código aberto (Open Source)

• Foram construídos para as propriedades da web do século 21;

• Não possuem esquema fixo (Schemaless). Bancos de dados sem esquema permi-tem adicionar livremente campos para registros, mas há geralmente um esquemaimplícito esperado pelos usuários dos dados.

Dependendo do modelo de dados e da estratégia utilizada no armazenamento dosdados, os bancos NoSQL são classificados em diversas categorias. As encontradascom mais frequência na literatura são: Key-value Store, Column Store, DocumentStore e Graph Database. Além dessas categorias, são encontrados também os ArrayDatabases e os Object Databases [Cattell, 2011; Leavitt, 2010; Queiroz et al., 2013;Moniruzzaman & Hossain, 2013]. A seguir, uma breve descrição das categorias dosNoSQL, apresentada em Queiroz et al. [2013].

Document Stores: Os bancos de dados orientados a documentos foram proje-tados para trabalhar com documentos semiestruturados. Geralmente esses documentossão representados utilizando-se a sintaxe do JSON (JavaScript Object Notation), umformato leve para troca de dados. Esse formato pode lidar com dados sem um esquemarígido combinado com eficientes sistemas de indexação.

Key-values Stores: Nos bancos de armazenamento baseado em pares chave-valor, a chave identifica um valor que pode ser um dado estruturado ou não. Geralmentesão utilizados de forma embarcada em dispositivos móveis e roteadores de rede, sistemasde autenticação e gerenciamento de conteúdo.

Graph Databases: Os bancos baseados em grafos são formados por vértices,arestas e propriedades. Os vértices modelam os objetos, as arestas materializam o

2.6. NoSQL 21

relacionamento entre os vértices, e as propriedades são usadas para descrever tantoatributos dos vértices quanto das arestas.

Column Store: No armazenamento orientado a colunas, dados com estruturassimilares são agrupados formando famílias de colunas, onde cada coluna recebe umnome e um valor. Grupos de colunas associados ao mesmo objeto são identificados poruma chave, e esses grupos formam uma linha. O valor é identificado pelo nome dafamília, mais a chave, mais o nome da coluna.

Array Databases: Bancos de dados matriciais armazenam os dados em matri-zes, que são estruturas de dados geográficos que representam uma partição do espaçoem células, frequentemente designadas também por pixels, de igual dimensão. Imagensde sensoriamento remoto são um exemplo de dado matricial.

Object Databases: Bancos de dados orientados a objetos armazenam e represen-tam a informação na forma de objetos da mesma forma que são usados na programaçãoorientada a objetos.

A próxima seção apresenta o MongoDB, um banco de dados orientado a docu-mentos, projetado para trabalhar com documentos semiestruturados.

2.6.1 MongoDB

O nome MongoDB deriva-se de Humongous (Gigantesco), que sugere o armazenamentoe manipulação de grandes volumes de dados. É um banco de dados composto porcoleções de documentos no formato BSON, uma versão binária dos documentos JSON.A primeira versão do MongoDB foi lançada em 2009, é uma ferramenta Open Sourcee foi desenvolvida em C++. A versão atual e utilizada nesse trabalho é a 3.0.2 5.

O MongoDB não possui log de transação, e a durabilidade é garantida pela re-plicação dos dados. Dentre os diversos recursos disponíveis, destacam-se: journalingpara garantir a durabilidade das operações de escrita; sharding que é o particionamentodos dados em vários servidores (escalabilidade horizontal); e Map Reduce onde o Mapmodifica ou filtra os valores, e o Reduce consolida o conjunto desses valores. Tambémpossui suporte geoespacial nativo e a indexação usa Hash.

O MongoDB encaixa-se na categoria Document Store. Os bancos de dados ori-entados a documentos foram projetados para trabalhar com documentos semiestrutu-rados. Geralmente esses documentos são codificados em um formato padrão de trocade dados como XML, JSON (Javascript Object Notation ou BSON (Binary JSON).Esses formatos podem lidar com dados sem um esquema rígido combinado com efici-entes sistemas de indexação. Esses bancos geralmente suportam índice secundário e

5http://www.mongodb.org/

http://www.mongodb.org/


Tabela 2.2. MongoDB vs Relacional

MongoDB RelacionalBanco de dados Banco de dadosColeções TabelasDocumentos Registros (Tuplas)Índice ÍndiceSharding Partições

vários tipos de documentos (objetos) por banco de dados e documentos aninhados oulistas. Como qualquer outro sistema NoSQL, o Document Store não fornece proprie-dades transacionais ACID (Atomicidade, Consistência, Isolamento, Durabilidade). OsDocument Stores são sem esquema, exceto para atributos (que são simplesmente umnome, e não são pré especificados), coleções (que são simplesmente um agrupamentode documentos), e os índices definidos em coleções (explicitamente definidos). Forne-cem um mecanismo para consultar coleções baseado em várias restrições de valores deatributos. Os Document Stores geralmente não fornecem locks explícitos, e têm propri-edades de concorrência e atomicidade mais fracas que os bancos de dados tradicionaiscompatíveis com ACID. Esses bancos armazenam e organizam os dados como coleçõesde documentos, ao invés de tabelas estruturadas com campos de tamanho uniformepara cada registro. Com esses bancos, usuários podem adicionar qualquer quantidadede campos de qualquer tamanho para um documento [Cattell, 2011; Leavitt, 2010;Queiroz et al., 2013; Moniruzzaman & Hossain, 2013].

A Tabela 2.2 ilustra um comparativo entre o MongoDB e o modelo relacionalapenas como auxílio para conversão de um modelo relacional ou modelagem de umnovo sistema.

De acordo com Sadalage & Fowler [2013], o MongoDB funciona da seguinte forma:cada instância do MongoDB tem vários bancos de dados, e cada banco de dados temvárias coleções. Quando comparado ao banco relacional, uma instância no MongoDBequivale a uma instância no relacional. Esquemas no banco relacional equivalem aosbancos no MongoDB. As tabelas no banco relacional equivalem às coleções no Mon-goDB. Finalmente, os documentos armazenados nessas coleções equivalem às linhasarmazenadas nas tabelas do banco relacional.

As Figuras 2.5 e 2.6, retiradas de Sadalage & Fowler [2013], ilustram exemplosde documentos que são armazenados em um banco orientado a documentos.

Quando observadas, as figuras são semelhantes, porém com nomes de atributosdiferentes. O esquema dos dados podem ser diferentes entre documentos, e esses do-cumentos podem pertencer a uma mesma coleção. Tal característica é diferente de um

2.6. NoSQL 23

Figura 2.5. Documento no formato JSON

Figura 2.6. Documento no formato JSON

SGBDR onde toda linha na tabela precisa seguir o mesmo esquema. A quantidade deatributos entre um documento e outro pode ser diferente, ao contrário de um bancorelacional onde toda coluna precisa ser definida e se não existir valor para ela, é pre-enchida com valor nulo ou vazio. No caso de documentos, não há atributo vazio. Seo atributo não é encontrado, significa que não é relevante para o documento. Docu-mentos permitem que novos atributos sejam criados sem a necessidade de defini-los oualterar o documento existente [Sadalage & Fowler, 2013].

Sadalage & Fowler [2013] apresentam alguns casos de uso adequados para usarMongoDB:

• Registro de eventos (Event Logging);

• Sistema de gerenciamento de conteúdo;

• Plataforma de blogs ;

• Análise da Web ou Análise em tempo real;

• Aplicações e-Commerce.

Nesse trabalho foram coletados dados da Web, e o MongoDB possui a caracte-rística de trabalhar com volume grande de dados não-estruturados de forma eficiente.Uma outra característica interessante, é que um documento JSON possibilita agregar


o dado, dessa forma o MongoDB se caracteriza como um modelo agregado permitindoembutir objetos (documentos) fazendo assim uma agregação natural. Essa caracte-rística coincide com o cenário de um ambiente de data warehouse que é modeladopossuindo muitas junções entre tabelas. Apesar desse trabalho não armazenar o DWno MongoDB, uma pesquisa nessa área poderia mostrar se há vantagens de se manterum DW em um banco NoSQL orientado a documentos.

2.7 Trabalhos Relacionados

A integração de dados estruturados e não-estruturados é um problema clássico queenvolve diversas áreas, e é alvo de pesquisa com diversas propostas para lidar comessa integração. Em um ambiente de DW também há a necessidade de enriquecê-locom dados advindos da Web. Sendo assim, a seguir estão relacionados os trabalhosque tratam dessa integração de dados não-estruturados e um ambiente estruturado deDW.

O trabalho de Thenmozhi & Vivekanandan [2012] propõe um framework usandoontologia para o projeto de esquema multidimensional. O framework usa uma aborda-gem híbrida onde a reconciliação de requisitos e fontes de dados é feita na fase inicial doprojeto. Até pouco tempo, abordagens usadas para projetos multidimensionais erammanuais ou automatizadas, mas que trabalhavam somente com fontes relacionais. Noentanto, como hoje um sistema de data warehouse precisa lidar com dados semiestru-turados e não-estruturados, a tarefa de projeto torna-se desafiadora. Recentemente,ontologia tem sido muito útil para projetos de integração de dados diferentes. O uso deontologia pode resolver conflitos sintáticos e semânticos que surgem a partir de fontesheterogêneas. Ontologia também fornece uma maneira para automatizar o projeto deesquema multidimensional e alimentar o data warehouse de um modo mais significativo.

O trabalho de Ravat et al. [2007] apresenta uma nova função de agregação parapalavras-chave permitindo a agregação de dado textual em ambientes OLAP como fun-ções aritméticas tradicionais fariam em dados numéricos. Ao contrário de trabalhospreviamente estabelecidos, o trabalho foca na análise sobre o texto. A abordagem tema vantagem de combinar a análise qualitativa com análise quantitativa, ou seja, a aná-lise das palavras-chave de uma publicação específica, a fim de fornecer uma visão geraldos conteúdos de publicação. Para permitir uma análise OLAP multidimensional dedocumentos, é fornecida uma função de agregação para a análise textual OLAP. Tam-bém é fornecida a adição de medidas textuais específicas, bem como uma representaçãohierárquica dos conceitos analisadas com o uso de uma ontologia.

2.7. Trabalhos Relacionados 25

O trabalho de Perez et al. [2008] fez uma revisão das tecnologias utilizadas paracombinar Data Warehouse e dados Web. Os trabalhos relevantes destacaram a difi-culdade de lidar com dados semiestruturados em DW e mostraram tecnologias XMLque foram usadas para integrar, armazenar, buscar, e recuperar dados Web para DataWarehouses. Nesse levantamento, os autores identificaram 3 diretrizes no tratamentodesse problema: 1) O uso de tecnologia XML como uma ferramenta de integração emsistemas de DW distribuídos; 2) O desenvolvimento de DWs para dados semiestrutu-rados; 3) DWs e coleções de documentos não-estruturados.

O trabalho de Alqarni & Pardede [2012] propõe uma abordagem para facilitar aintegração dos data warehouses com documentos não-estruturados. É proposto tam-bém um novo modelo de esquema XML genérico para vários tipos de documentosnão-estruturados para esta finalidade de integração. O novo esquema genérico é proje-tado em partições separadas agrupadas pelo tipo dos documentos. A fim de alcançar aintegração, foi usado um mecanismo de correspondência linguístico usando dicionárioWordNet para encontrar possíveis semelhanças entre nomes dos elementos de ambosos esquemas. O trabalho mostrou que a correspondência semântica é essencial comoum processo inicial para calcular o grau de semelhança entre um esquema de datawarehouse e um esquema genérico.

Os trabalhos analisados mostram a importância de integrar dados não-estruturados a um ambiente estruturado, no caso do estudo desse trabalho, um DW.Os autores ressaltam o grande desafio que as pessoas e as tecnologias atuais enfrentamna integração dessas informações. É destacado também importância de enriquecer umbanco de dados com informações que agreguem valor e são propostas várias formas derealizar esse processo.

Os conceitos das Seções 2.1 à 2.2.6 foram apresentados para ter maior entendi-mento das tecnologias que envolvem BI e DW, que é o objeto de pesquisa e desen-volvimento desse trabalho. A Seção 2.3 serve para esclarecer a natureza dos dadostrabalhados nesse projeto.

Um ambiente de DW armazena dados históricos, consequentemente cresce emvelocidade grande dependendo do ramo de negócio da empresa. Dessa forma, as Seções2.4 e 2.5 foram colocadas com objetivo de mostrar que há tecnologias diferenciadas paralidar com esse volume de dados.

Os dados mantidos nas redes sociais são não-estruturados, e a forma que se encon-tram armazenados são em bancos NoSQL. Os dados coletados para esse trabalho estãoarmazenados no MongoDB. Assim, as Seções 2.6 e 2.6.1 vêm explicitar esses conceitospara os leitores.

Esse trabalho também tem por objetivo integrar informações que estão na Web


(dados não-estruturados) a um DW relacional, por meio do uso de uma metodologia.Essa metodologia prevê a identificação de novas tabelas dimensões e fatos, o incrementodas dimensões que já existem e/ou identificação de novas métricas para as tabelas fatos.Com o objetivo de padronizar todo o processo de integração desses dados, esse trabalhopropõe uma metodologia que é descrita no Capítulo 3 e guiará os pesquisadores eprofissionais na busca de bons resultados.

Capítulo 3

Metodologia Proposta

Definir um processo metodológico é uma forma de orientar ações padronizadas paraa obtenção de resultados comuns na organização, visando facilitar a manutenção eformar base de conhecimento. Devido à diversidade das fontes de dados e à naturezanão-estruturada, a integração desses dados com um ambiente estruturado torna-se umatarefa difícil e desafiadora.

Vivencia-se um mundo digital conectado onde comunidades de usuários forneceminformações de maneira voluntária por meio de diversos recursos, dispositivos e ser-viços da Web. Dessa forma, é possível explorar o potencial que existe por meio daparticipação voluntária, uma vez que pode complementar a base de conhecimento deuma organização. Quanto maior essa base de conhecimento, as possibilidades de aná-lises aumentam e torna-se um diferencial no mundo de hoje. Contudo, é importanteressaltar o cuidado especial que se deve ter com os dados advindos de contribuiçãovoluntária, pois a confiabilidade e precisão dos dados ficam comprometidas, além danecessidade de um processo diferenciado para a validação da qualidade desses dados.

A metodologia descrita a seguir propõe o enriquecimento de um data warehousepor meio de um processo de integração dos dados não-estruturados e estruturados,auxiliando a tomada de decisão através da coleta, transformação e organização de dadosbrutos espalhados pela Web, transformado-os em informação útil com valor estratégico,agregando e enriquecendo o armazém de dados atual das empresas. Uma visão geral dametodologia que está dividida em quatro grandes etapas é apresentada na Seção 3.1.A partir da Seção 3.1.1, cada etapa proposta é descrita com mais detalhes. A Seção3.2 faz algumas considerações acerca dos métodos propostos.

27

28 Capítulo 3. Metodologia Proposta

Figura 3.1. Visão geral da metodologia

3.1 Visão Geral da Metodologia

A Figura 3.1 ilustra uma visão geral do que a metodologia propõe. O diagramaapresenta as etapas macro que compõem o processo de integração dos dados não-estruturados com os dados estruturados com o objetivo de enriquecer um armazémde dados. A metodologia proposta neste trabalho concentra o maior desafio na etapade identificação de novas tabelas de dimensões, novas tabelas de fatos e definição denovas métricas para serem agregadas ao armazém de dados já consolidado de umaorganização.

A etapa da integração dos dados não-estruturados e dados estruturados tambémé desafiadora, já que se tem a preocupação de gerar dados úteis que agreguem algumvalor na etapa da disponibilização da informação, onde o usuário gera relatórios edashboards e usa a informação para auxiliar a tomada de decisão.

As etapas macro estão organizadas em quatro áreas: Entrada, Preparação, Pro-cessamento e Saída. A Entrada compreende a etapa de definição dos requisitos. Nessaetapa são definidos os insumos necessários para início do processo de integração dos da-dos que envolve a definição das pessoas chave que contribuirão para o levantamento dasnecessidades estratégicas da organização, e a análise das necessidades da organização.Essa área compreende a macro etapa #1.

A Preparação compreende a definição das fontes de dados de onde a informaçãoserá coletada. Nessa fase ocorre o pré-processamento dos dados, ou seja, algumas ati-vidades são realizadas visando melhorar a qualidade dos dados. Essa área compreendea etapa #2.

O Processamento compreende a limpeza dos dados e a utilização de técnicas queauxiliarão na identificação de novas Tabelas de dimensões e fatos que enriquecerão o

3.1. Visão Geral da Metodologia 29

armazém de dados de uma empresa. Essa área compreende a macro etapa #3.A Saída compreende a disponibilização da informação processada para o gestor

da empresa para que possa fazer as análises necessárias para o processo decisório. Essaárea compreende a macro etapa #4.

As seções 3.1.1 a 3.1.4 apresentam um detalhamento de cada etapa macro. Ne-las são expostos os objetivos de cada etapa, o que é necessário ter como entrada, asprincipais atividades que são executadas, quais ferramentas são utilizadas e a saída aofinal de cada etapa.

As quatro etapas macro constituem uma visão geral de todo o processo necessáriopara a completa implementação e integração dos dados não-estruturados com dadosestruturados que a organização já possui, enriquecendo ainda mais as informações ecolaborando para uma tomada de decisão mais rápida e precisa. Também se tratade uma prática recomendada, pois quando uma metodologia é bem definida torna-seuma importante ferramenta para a conquista do sucesso pleno na implementação dasolução.

3.1.1 Definição de Requisitos

Etapa #1. Esta etapa consiste na realização de reuniões com os analistas de negócio,com os especialistas de tecnologia e com as partes interessadas para levantar as neces-sidades informacionais, e analisar as necessidades do usuário a fim de produzir umavisão geral da solução para orientar todo o processo de integração e enriquecimento doDW. Essas pessoas-chave contribuem com o levantamento das necessidades estratégi-cas da organização, entendem e conhecem os negócios da empresa, sabem dos dadosque estão alimentando o DW e conhecem toda a estrutura do ambiente. Nessa etapa éimportante adquirir o apoio total da alta gestão e promover discussões sobre diversosassuntos para levantamento dos indicadores que vão auxiliar a tomada de decisão. Asprincipais atividades são apresentadas na Tabela 3.1.

Nas reuniões, gestores podem partir do questionamento: “Quais informações ne-cessito para tomar decisões mais efetivas? ”. Dessa forma é possível levantar todas asperspectivas das necessidades estratégicas da organização. As métricas e indicadoressão estabelecidos na definição do escopo do cubo. Um exemplo de métrica seria: Quan-tidade de itens X. Um exemplo de indicador de desempenho seria: Percentual de itensX vendidos em março de 2014. Um exemplo de pergunta seria: Quantos “objetos” vi-sitaram uma determinada área durante um determinado período de tempo? Ou ainda:Retornar a distância total percorrida por pessoas europeias no Brasil durante a copado mundo de 2014.


Tabela 3.1. Definição de Requisitos

Entrada(s)Documentação que a organização possui sobre informação estraté-gicaMetadados do DW

Atividade(s)

1. Identificar as partes interessadas do processo

2. Identificar os principais beneficiados da solução

3. Identificar os especialistas em tecnologia

4. Identificar os benefícios para a organização

5. Identificar assuntos relacionados à gestão através de indica-dores

6. Reunir com as pessoas identificadas

7. Levantar as necessidades estratégicas

8. Definir perguntas

9. Definir escopo do cubo fato

10. Documentar

Ferramenta(s) ReuniõesBrainstorms

Saída(s)

Documentação contendo os envolvidos no processo e o papel decada umEscopo do cubo com as métricas e os indicadores que vão responderas perguntas

3.1.2 Coleta de Dados

Etapa #2. Esta etapa consiste no levantamento e definição das fontes dos dadosde onde serão coletados para integração no armazém de dados, por exemplo, Twitter,Facebook, Foursquare, Reclame Aqui, Bondfaro, Buscapé, Site de lojas, Ebit, etc.Nessa etapa também é necessário verificar a forma que cada fonte de dados disponibilizaos dados para definição e planejamento da estratégia da coleta desses dados. Além disso,também é necessário preparar o ambiente que armazenará os dados coletados das fontes,por exemplo, preparação de servidor com configurações mínimas exigidas, instalaçãode softwares específicos, instalação e configuração de banco de dados para armazenaros dados coletados, etc. Após a criação do repositório próprio para o armazenamento,um pré-processamento dos dados é realizado visando melhorar a qualidade dos dados.As principais atividades são apresentadas na Tabela 3.2.

Nessa etapa os dados passam por um pré-processamento como a eliminação de


Tabela 3.2. Coleta de Dados

Entrada(s) Documentação gerada na etapa #1

Atividade(s)

1. Levantar origem dos dados

2. Definir a origem dos dados

3. Verificar como os dados são disponibilizados para coleta

4. Definir estratégia da coleta dos dados

5. Planejar a coleta dos dados

6. Preparar ambiente para armazenar a coleta

a) Verificar as configurações mínimas exigidas do ambi-ente para a coleta dos dados

b) Configurar o ambiente

c) Testar previamente o ambiente

7. Coletar os dados

8. Analisar o repositório de dados criado

a) Eliminar inconsistências

9. Documentar

Ferramenta(s) Ferramentas necessárias para configuração do ambiente

Saída(s)Ambiente preparado para receber os dadosDados coletados e pré-processadosDocumentação

inconsistências. Algumas atividades são executadas visando melhorar a qualidade dosdados, por exemplo: análise do repositório criado com a finalidade de eliminar atributosdesnecessários e reduzir a dimensionalidade dos dados; limpeza dos dados visandoeliminar valores incorretos, tais como nulos e vazios. Ao final, a estrutura estarápreparada para a próxima etapa, Processamento ETL, onde acontece a execução dosprocedimentos de identificação das dimensões.

3.1.3 Processamento ETL

Etapa #3. Esta etapa consiste no uso de técnicas para identificação e criação dasdimensões temporais, espaciais e temáticas. A dimensão temporal tem por objetivoanalisar um evento ao longo do tempo ou em determinado período de tempo. Paraisso, é necessária a identificação de atributos de tempo ou períodos nos dados coleta-


Tabela 3.3. Processamento ETL

Entrada(s) Documentação gerada na etapa #2Dados coletados

Atividade(s)

1. Identificar dimensões temporais

2. Identificar dimensões espaciais

3. Identificar dimensões temáticas

4. Criar dimensões identificadas

5. Carregar dimensões identificadas

6. Classificar os dados através da técnica de análise de senti-mento

7. Criar o cubo fato com as métricas e os indicadores

8. Carregar o cubo fato

a) Definir informações que serão carregadas no cubo

b) Gerar script para auxiliar a carga ou usar ferramentade carga

9. Documentar (metadados)

Ferramenta(s)

Técnicas para identificar dimensões temporaisTécnicas para identificar dimensões espaciaisTécnicas para identificar dimensões temáticasTécnicas de análise de sentimento para classificar dado de entradaFerramenta que auxilia a carga do cubo fato

Saída(s)

DocumentaçãoDimensões temporaisDimensões espaciaisDimensões temáticasDados classificados pela técnica de análise de sentimentoCubo fato

dos. A dimensão espacial tem por objetivo analisar um evento em um determinadolugar. Para isso, é necessária a identificação de atributos que indicam a localização nosdados coletados. A dimensão temática tem por objetivo analisar um evento em umadeterminado tema ou tópico. Para isso, é necessária a identificação de atributos queatendam às necessidades estratégicas da organização e criação de dimensões temáticaspara a análise dos eventos. As principais atividades são apresentadas na Tabela 3.3.

Toda dimensão criada terá 5 registros extras com códigos para dados que nãopodem ser categorizados, como exemplificado na Tabela 3.4.


Tabela 3.4. Código dos dados não categorizados

Código Descrição0 Outros-1 Não informado-2 Não se aplica-3 Não preenchido-4 Desconhecido

Figura 3.2. Entrada - Processamento - Saída

O cubo fato também é criado e carregado nessa etapa e tem por objetivo reu-nir todos os eventos identificados nos dados de entrada possibilitando uma análise devárias perspectivas como tempo, espaço e temática. O cubo é carregado a partir dasinformações coletadas atendendo às necessidades estratégicas da organização.

Apesar do “Processamento ETL” estar representado apenas como uma etapa nodiagrama, ele é composto pelas maiores atividades envolvidas em todo o processo, alémde ser a etapa mais trabalhosa e a mais desafiadora.

Essa etapa macro está organizada em três áreas: Entrada, Processamento e Saída.A Entrada compreende os dados individuais das fontes levantadas na etapa #3. OProcessamento compreende a aplicação das técnicas para identificação das tabelas dedimensões e de fatos, como também o uso de uma ou mais técnicas de análise desentimento para classificar os dados de entrada. A saída compreende as tabelas dedimensões e as tabelas de fatos identificadas. A Figura 3.2 ilustra esse processo.

Os dados individuais de entrada para essa metodologia devem conter data, locale texto. Data é a unidade de tempo do dado de entrada que irá compor a dimensãotemporal. Local é a unidade de espaço do dado de entrada que irá compor a dimensão


espacial. Texto é a unidade de tema do dado de entrada que irá compor a dimensão te-mática. Com o texto também é possível identificar outras dimensões, como a temporalidentificando advérbios de tempo ou locuções adverbiais, como também espacial iden-tificando nomes de lugares, e também a classificação do texto como conteúdo positivo,neutro ou negativo.

As Seções 3.1.3.1 a 3.1.3.4 detalham o processo de identificação das dimensõestemporal, espacial, temática e de análise de sentimento. A Seção 3.1.3.5 descreve oprocesso da criação e da carga da tabela cubo fato.

3.1.3.1 Dimensão Temporal

Podemos ter duas dimensões temporais ao final desse processo. Uma tradicional como atributo data no formato AAAA-MM-DD (2016-07-20) e sua granularidade e outracom advérbios de tempo e locuções adverbiais. No caso dos dados coletados estarem emarquivos, identificar neles algum atributo que caracterize uma data, como por exemplo,“timestamp” ou “created_at” no JSON coletado do Twitter. A documentação da fontede dados pode auxiliar na identificação desses atributos. Com esse atributo de data,é possível carregar a dimensão DIM_TEMPORAL cuja criação possui a estruturasugerida na Tabela 3.5.

A outra dimensão sugerida é a DIM_TEMPORAL_ADV, onde sua carga con-siste na identificação de “eventos temporais” no atributo textual do dado coletado.Esses eventos temporais podem ser identificados através da aplicação de técnicas queidentificam e extraem advérbios de tempo e locuções adverbiais do dado de entrada.Alguns exemplos de advérbios de tempo e locuções adverbiais são: à noite, a qualquermomento, à tarde, afinal, agora, ainda, amanhã, amiúde, antes, antigamente, às vezes,breve, cedo, constantemente, dantes, de dia, de manhã, de noite, de quando em quando,de repente, de tempos a tempos, de tempos em tempos, de vez em quando, depois, do-ravante, em breve, enfim, enquanto isso, então, entrementes, frequentemente, hoje emdia, hoje, imediatamente, já, jamais, logo, nunca, ontem, ora, outrora, por vezes, pri-meiramente, primeiro, provisoriamente, raramente, sempre, sucessivamente, tarde. Aestrutura sugerida para criação da dimensão DIM_TEMPORAL_ADV encontra-se naTabela 3.6.

Exemplificando a dimensão adverbial, supondo que durante a análise das infor-mações, identifique-se que a maioria dos comentários sobre patins ocorre no período danoite. Dessa forma, o gestor responsável pode fazer campanhas e oferecer equipamentosde segurança noturna para esses usuários.


Tabela 3.5. Dimensão DIM_TEMPORAL

Campos Descrição

ID

Inteiro, identificador único sequencial e chave primáriaCódigo para dado não categorizado:* 0 para Outros* -1 para Não informado* -2 para Não se aplica* -3 para Não preenchido* -4 para Desconhecido

ID_AUX Inteiro formado por AAAAMMDDExemplo: 20160720

DATA Valor da dataExemplo: 20/07/2016 ou 2016-07-20

DIA_SEMANA Valor textual do dia da semanaExemplo: Quarta-feira

NUM_MES Valor numérico do mêsExemplo: 7

DES_MES Valor textual do mêsExemplo: Julho

NUM_ANO Valor numérico do anoExemplo: 2016

NUM_TRIMESTRE Valor numérico do trimestreExemplo: 3

NUM_SEMESTRE Valor numérico do semestreExemplo: 2

ID_PERIODO_DIA Identificador da dimensão DIM_PERIODO_DIAExemplo: Manhã

DATA_CARGA Data em que o registro foi carregadoExemplo: 20/07/2016 ou 2016-07-20

3.1.3.2 Dimensão Espacial

Podemos ter duas dimensões espaciais ao final desse processo. Uma tradicional comcoordenadas geográficas (longitude e latitude) e sua granularidade, e outra com nomesde lugares identificados no texto mas que não foi possível associar coordenadas paraeles. No caso dos dados coletados estarem em arquivos, identificar neles algum atributoque caracterize uma coordenada geográfica, como por exemplo, “geo” ou “coordinates”no JSON coletado do Twitter. A documentação da fonte de dados pode auxiliar naidentificação desses atributos. Com esse atributo de coordenada geográfica é possívelcarregar a dimensão DIM_ESPACIAL cuja criação possui a estrutura sugerida naTabela 3.7. Para dar carga nessa dimensão, é preciso aplicar uma técnica para convertera coordenada geográfica em localização (nome do lugar) para preencher a granularidadedefinida para a dimensão. A coordenada (GEOM) preenchida é sempre do último


Tabela 3.6. Dimensão DIM_TEMPORAL_ADV

Campos Descrição

ID


DES_ADVERBIO_TEMPO Advérbio de tempo extraído do atributo textualExemplo: À noite


item preenchido da granularidade. Por exemplo, se o bairro e localização estão nulos,significa que o GEOM está representando a cidade.

A outra dimensão espacial sugerida é a DIM_LOCALIZACAO, onde sua cargaconsiste na identificação do nome de um lugar a partir do atributo textual do dadocoletado. Esses lugares podem ser identificados através da aplicação de técnicas queidentificam e extraem nomes de lugares do dado de entrada. Essa técnica será usadaquando não for possível identificar a localização a partir do atributo GEOM. A técnicautilizada deve garantir que se trata de um lugar. A estrutura sugerida para criação dadimensão DIM_LOCALIZACAO encontra-se na Tabela 3.8.

Exemplificando a dimensão espacial, supondo que durante a análise das infor-mações, uma loja identifica comentários bons sobre um produto em um determinadolugar que ela ainda não possui filial. Dessa forma o gestor pode ampliar suas vendasem outros países,estados ou cidades. Outro exemplo seria a possibilidade de identificarregistros com focos de alguma doença num dado lugar possibilitando a aplicação demedidas preventivas ou corretivas.

3.1.3.3 Dimensão Temática

Podemos ter algumas possibilidades de dimensões temáticas ao final desse processo.Uma delas consiste em utilizar alguma técnica para extrair palavras relevantes do atri-buto textual do dado coletado e carregar a dimensão temática com esses termos. Ummesmo dado de entrada pode conter mais de um termo relevante, daí tem-se duas oumais entradas no cubo fato, uma para cada tópico relevante, ou seja, o tema identi-ficado. A estrutura sugerida para criação da dimensão temática DIM_TEMATICAencontra-se na Tabela 3.9.


Tabela 3.7. Dimensão DIM_ESPACIAL

Campos Descrição

ID


GEOMLongitude e latitudeExemplo: -19.9174937,-44.1003973 (de Belo Horizonte, ci-dade)

NOM_PAIS Nome do país identificado pelo GEOMExemplo: Brasil

NOM_ESTADO Nome do estado identificado pelo GEOMExemplo: Minas Gerais

NOM_CIDADE Nome da cidade identificada pelo GEOMExemplo: Belo Horizonte

NOM_BAIRRO Nome do bairro identificado pelo GEOMExemplo: Ouro Preto

NOM_LOCALIZACAO Nome de um lugar identificado pelo GEOMExemplo: Parque ecológico


Tabela 3.8. Dimensão DIM_LOCALIZACAO

Campos Descrição

ID


NOM_LOCALIZACAONome do lugar identificado a partir do atributo textualdo dado coletadoExemplo: Serra do Cipó


Exemplificando a dimensão temática, supondo que durante a análise das infor-mações, o gestor identifique comentários positivos sobre esportes náuticos na Lagoade Pampulha. Dessa forma, pode levar à criação de um projeto para implantaçãode alguns dos esportes mais comentados pelos usuários. Outro exemplo seria agruparpalavras que tenham significados semelhantes, que tenha alguma relação, formando


Tabela 3.9. Dimensão DIM_TEMATICA

Campos Descrição

ID


NOM_TEMATICANome da temática identificada no atributo textual dodado coletadoExemplo: Pesca, Natação


Tabela 3.10. Dimensão DIM_ANALISE_SENTIMENTO

Campos Descrição

ID

Inteiro, identificador único e chave primáriaCódigo para classificar o dado:* 1 para Positivo* 0 para Neutro* -1 para Negativo* -5 para Sem classificação

DES_ANALISEDescrição da análise de sentimento identificada no atri-buto textual do dado coletadoExemplo: Positivo, Neutro e Negativo


clusters, na intenção de identificar algum padrão.

3.1.3.4 Dimensão de Análise de Sentimento

A dimensão de análise de sentimento é criada com as classificações positivo, neutroe negativo. A ferramenta iFeel1, desenvolvida por alunos da UFMG, é utilizada paraclassificar de forma correta o conteúdo do atributo textual.

A estrutura sugerida para criação da dimensão de análise de sentimentoDIM_ANALISE_SENTIMENTO encontra-se na Tabela 3.10.

1http://blackbird.dcc.ufmg.br:1210/

http://blackbird.dcc.ufmg.br:1210/


3.1.3.5 Cubo Fato

Depois de todas as dimensões identificadas e extraídas levando em consideração aestratégia de negócio da organização, cria-se a tabela fato contendo todas as camadas,ou seja, todas as perspectivas de onde pretende-se analisar os dados. Além das camadas,o cubo deve conter métricas e indicadores, que são os atributos que permitem a análisede toda a informação. A Tabela 3.11 sugere uma estrutura para criação do cubo.

Tabela 3.11. Dimensão CUBO_FATO

Campos Descrição

ID_PRODUTO Chave estrangeira. Origem: Chave primária da dimensãoDIM_PRODUTO

ID_TEMPORAL Chave estrangeira. Origem: Chave primária da dimensãoDIM_TEMPORAL

ID_TEMPORAL_ADV Chave estrangeira. Origem: Chave primária da dimensãoDIM_TEMPORAL_ADV

ID_ESPACIAL Chave estrangeira. Origem: Chave primária da dimensãoDIM_ESPACIAL

ID_LOCALIZACAO Chave estrangeira. Origem: Chave primária da dimensãoDIM_LOCALIZACAO

ID_TEMATICA Chave estrangeira. Origem: Chave primária da dimensãoDIM_TEMATICA

ID_ANALISE_SENT Chave estrangeira. Origem: Chave primária da dimensãoDIM_ANALISE_SENTIMENTO


Métricas

Quantidade de comentáriosQuantidade de comentários positivosQuantidade de comentários neutrosQuantidade de comentários negativos

Indicadores

Percentual de itens X com comentários bons/ruins/neutrosem determinado mês/anoPercentual de comentários positivos/neutros/negativos sobreum item X em determinado mês/anoPercentual de itens X na cidade CPercentual de itens X na cidade C em determinado mês/anoPercentual de comentários positivos/neutros/negativos sobreum item X em determinada localizaçãoPercentual de uma temática T em determinada localizaçãoPercentual de comentários positivos/neutros/negativos sobreuma temática T em determinada localização


Figura 3.3. Exemplificando o Cubo

3.1.4 Disponibilização da Informação

Etapa #4. Esta etapa disponibiliza a informação estruturada para que seja possívelprocurar relações de causa e efeito. A partir das informações, é possível gerar rela-tórios, criar dashboards, fazer consultas ad-hoc e auxiliar a tomada de decisão. Nessaetapa o especialista pode fazer uso da experiência, analisar dados contextualizados,trabalhar com hipóteses, procurar relações de causa e efeito, transformar os registrosobtidos em informação útil para o conhecimento empresarial. Nessa etapa é importanteenvolver os usuários e conscientizá-los do uso correto da informação. A definição dosníveis de permissão garante que nem todos os usuários poderão ter acesso irrestrito àsinformações. A Tabela 3.12 resume as principais atividades dessa etapa.

3.2 Considerações

A aplicação dessa metodologia não está restrita à identificação das dimensões citadasnas subseções anteriores. Dependendo do negócio da empresa e das necessidades estra-tégicas da organização, outras camadas podem ser adicionadas ao modelo identificando

3.2. Considerações 41

Tabela 3.12. Disponibilização da Informação

Entrada(s) Documentação gerada da etapa #3Cubo fato

Atividade(s)

1. Disponibilizar informação para o usuário final

2. Capacitar os usuários

3. Conscientizar do uso correto da informação

4. Definir níveis de permissões de cada usuário

5. Gerar relatórios e dashboards

6. Documentar

Ferramenta(s) Ferramentas OLAP

Saída(s)

RelatóriosDashboardsResultados de consultas ad-hocDocumentação

diversas dimensões, como por exemplo, clima, economia, fenômenos sociais, ambientaisou sócio-econômicos.

O próximo capítulo apresenta a aplicação da metodologia proposta em um estudode caso com a finalidade de validar a sua viabilidade. Os resultados e a análise críticatambém estão nesse capítulo, nas Seções 4.5 e 4.6.

Capítulo 4

Estudo de Caso, Resultados eAnálise

Para analisar a viabilidade da metodologia proposta em situações reais, um estudo decaso, no contexto de um armazém de dados voltado para vendas online de produtos, foiescolhido para que a metodologia fosse aplicada. A Seção 4.1 detalha o estudo de casoproposto para validação da metodologia. A fonte de dados utilizada para enriquecero armazém do estudo de caso está detalhada na Seção 4.2. Diversas ferramentas etécnicas foram usadas para auxiliar todo o processo e são descritas na Seção 4.3. ASeção 4.4 apresenta as métricas definidas para esse estudo de caso que auxiliam naanálise dos resultados. Os resultados são apresentados na Seção 4.5 após a integraçãodos dados. Finalmente, a Seção 4.6 faz uma análise crítica de todo o processo.

4.1 Estudo de Caso

Os dados utilizados neste trabalho para compor o armazém de dados foram obtidosna página da Microsoft1. Trata-se de um Data Warehouse de exemplo cujos dadosfictícios foram direcionados para dar suporte a cenários de mineração de dados e deOLAP. Esse armazém de dados contém duas áreas de assunto: finanças e vendas, eestá estruturado com 16 tabelas de dimensões e 10 tabelas de fatos.

Para este trabalho foi construída uma view com os dados das vendas de produtosfeitas pela internet no período de dezembro de 2010 a janeiro de 2014. Essa view faza junção de uma tabela fato (FactInternetSales) com suas 9 dimensões. O modelomultidimensional pode ser observado na Figura 4.1. Esse DW simula um suposto

1https://msftdbprodsamples.codeplex.com/releases/

43

https://msftdbprodsamples.codeplex.com/releases/

44 Capítulo 4. Estudo de Caso, Resultados e Análise

Figura 4.1. Modelo Multidimensional

armazém de dados de uma empresa que deseja enriquecê-lo com dados da Web, maisespecificamente, redes sociais. A próxima seção descreve o processo da coleta dos dadosque foi direcionado tendo como base os produtos cadastrados no DW do estudo de caso.

4.2 Fonte de Dados

Os dados usados para enriquecer o DW foram coletados do Twitter 2 no período dejunho a agosto de 2016. Foram coletados 5,48GB, que compreenderam cerca de 1,1milhões de tweets. À medida que os dados eram coletados, já eram armazenados noMongoDB. Foi escrito um script em Python que usa a API disponibilizada pelo Twitterpara a coleta em tempo real dos tweets que continham um conjunto de palavras-chavedefinido.

Para direcionar a coleta do Twitter foi necessário definir um conjunto de palavras-chave. Inicialmente, como o DW armazena informações de vendas de produtos pelainternet, optou-se por gerar duas listas de palavras-chaves: uma contendo as catego-

2https://twitter.com/

https://twitter.com/

4.3. Ferramentas e Técnicas 45

rias e subcategorias dos produtos já cadastrados, e outra com os produtos vendidos.A primeira lista é composta pelas palavras, em inglês: Bikes, Components, Clothing,Accessories, Bib-Shorts, Bike Racks, Bike Stands, Bottles and Cages, Bottom Brac-kets, Brakes, Caps, Chains, Cleaners, Cranksets, Derailleurs, Fenders, Forks, Gloves,Handlebars, Headsets, Helmets, Hydration Packs, Jerseys, Lights, Locks, Mountain Bi-kes, Mountain Frames, Panniers, Pedals, Pumps, Road Bikes, Road Frames, Saddles,Shorts, Socks, Tights, Tires and Tubes, Touring Bikes, Touring Frames, Vests, Wheels.

A segunda lista é composta pelas palavras também em inglês: All-Purpose BikeStand, Bike Wash, Classic Vest, Cycling Cap, Fender Set - Mountain, Half-FingerGloves, Hitch Rack - 4-Bike, HL Mountain Tire, HL Road Tire, Hydration Pack,LL Mountain Tire, LL Road Tire, Long-Sleeve Logo Jersey, ML Mountain Tire, MLRoad Tire, Mountain Bottle Cage, Mountain Tire Tube, Mountain-100, Mountain-200, Mountain-400-W, Mountain-500, Patch kit, Racing Socks, Road Bottle Cage,Road Tire Tube, Road-150, Road-250, Road-350-W, Road-550-W, Road-650, Road-750,Short-Sleeve Classic Jersey, Sport-100, Touring Tire Tube, Touring Tire, Touring-1000, Touring-2000, Touring-3000, Water Bottle, Women Mountain Shorts.

O objetivo dessa estratégia é verificar o que os usuários das redes sociais estãocomentando sobre os produtos que a empresa trabalha com a finalidade de identificaralgum padrão e analisar o cruzamento das diversas dimensões identificadas com asdimensões que já existem no armazém de dados conforme estratégia de negócio daempresa auxiliando na tomada de decisão.

Foi realizada uma avaliação inicial nos dados coletados e foram mantidos apenasos tweets que continham o atributo das coordenadas geográficas (geo) preenchido. Ostweets cujo atributo textual (text) continha apenas links e/ou imagens foram elimi-nados e registros duplicados também foram eliminados. Ao final, sobraram cerca de4 mil tweets para compor a base de enriquecimento. O critério utilizado para usaresse conjunto de dados foi manter os tweets que continham as informações necessáriaspreenchidas para aplicação da metodologia proposta.

A Seção 4.3 apresenta as ferramentas e técnicas utilizadas no processo de coleta,limpeza e integração dos dados coletados.

4.3 Ferramentas e Técnicas

A ferramenta usada para armazenar o Data Warehouse foi o SGBD relacional daMicro-soft, o SQL Server 2014 Express Edition. Como essa versão do SQL Server é gratuita,ela apresenta as seguintes limitações: oferece suporte a um processador físico, 1GB de


memória e 10GB de armazenamento. Essa ferramenta foi instalada em uma máquinacom as seguintes configurações: Processador Intel Core i7, 16GB de RAM, 1TB de HDe sistema operacional Windows 10.

A ferramenta usada para armazenar os dados coletados da Web, os tweets,foi o MongoDB 3.2.6. Nele foram criados 2 bancos de dados, DW_tweetsGeo eDW_tweetsProdutos, e em cada banco foi criada uma coleção que continha os do-cumentos coletados.

Foi desenvolvido um script em Python3 que usa a API do Twitter4 para coletaros dados em tempo real obedecendo as palavras-chaves definidas.

A máquina onde foi instalado o MongoDB e de onde foi executado o script possuias seguintes configurações: Processador 2,3 GHz Intel Core i7, 16GB de RAM, 2 HDscom 500GB cada, sistema operacional OS X El Capitan versão 10.11.4.

As técnicas usadas na identificação das dimensões que são propostas na metodo-logia desse trabalho são apresentadas a seguir.

Localização a partir das coordenadas: Quanto à localização dos tweets com rela-ção às coordenadas contidas neles, foi usada uma API do Google5 para geocodificaçãoreversa. O retorno dessa API é um arquivo JSON com diversas informações obtidas apartir das coordenadas passadas de parâmetro, inclusive dos arredores de cada coorde-nada. Foi desenvolvido um método em Java que acessa a API e outro método que lê oarquivo Json retornado e identifica os lugares contidos nele.

Identificação de tópicos e temas relevantes: Quanto à identificação de tópicos etemas relevantes contidos nos tweets coletados, foi usada uma técnica que automatica-mente descobre tópicos contidos em documentos, a Latent Dirichlet Allocation (LDA).Blei et al. [2003] definem LDA como um modelo probabilístico gerador para coleções dedados discretos como textos e documentos. LDA é um modelo Bayesiano hierárquicode três níveis onde cada item da coleção é modelado como uma mistura finita sobre umconjunto subjacente de tópicos. Cada tópico é modelado como uma mistura infinitasobre um conjunto subjacente de probabilidades de tópicos. Nesse contexto de mode-lagem de texto, as probabilidades de tópicos fornecem uma representação explícita deum documento. O algoritmo utilizado nesse estudo de caso para identificar os tópicosmais relevantes dos tweets foi desenvolvido em Java e está disponível em Nguyen [2015].

O algoritmo LDA recebe como entrada um texto grande, e como saída retornavários tópicos relacionados ao texto. Para este trabalho, o algoritmo utilizado foi

3https://www.python.org/4https://dev.twitter.com/rest/public5https://developers.google.com/maps/

https://www.python.org/

https://dev.twitter.com/rest/public

https://developers.google.com/maps/

4.4. Métricas 47

adaptado para receber textos pequenos (característica dos tweets) e retorna apenas umúnico tópico, o mais relevante.

Análise de sentimento: Quanto à classificação dos tweets em relação à análise desentimento, foi usado o iFeel 2.06, um sistema online que implementa 19 métodosde análise de sentimento e permite aos usuários classificar facilmente um conjunto dedados com todos eles. Esse sistema foi desenvolvido por pesquisadores do DCC-UFMGutilizando a linguagem Java. As empresas estão interessadas em saber as opiniõesdos usuários em redes sociais online, pois dessa forma a classificação das opiniões emnegativa, neutra ou positiva pode ajudar a avaliar melhor as campanhas dos produtose publicidade, além do desenvolvimento de produtos inovadores.

Ferramenta OLAP: a ferramenta Tableau Desktop Professional Edition7 versão10.0.1 é utilizada para análise de dados combinando diferentes fontes de dados. Comessa ferramenta é possível responder perguntas complexas criando novos cálculos comos dados, adicionando linhas de referência e previsões e acessando resumos estatísticos.Também é possível fazer análises de tendência, regressões e correlações.

A seguir, a Seção 4.4 apresenta as métricas definidas para análise dos dados.

4.4 Métricas

A metodologia proposta prevê métricas e indicadores para conduzir a avaliação dasanálises das empresas. As métricas e os indicadores são a base para quantificar osresultados e são muito úteis para acompanhar o desempenho das organizações.

As métricas desse trabalho foram definidas partindo do pressuposto que a empresadeseja avaliar seus produtos pelo mundo através de comentários coletados em redessociais. Essa coleta dos dados é direcionada considerando os produtos que a empresatrabalha, e a partir dos resultados obtidos será possível tomar alguma medida (tomadade decisão) que possa ajudar no negócio da empresa.

Para esse trabalho, foram definidos três conjuntos de métricas: para o armazém doestudo de caso (DW da Microsoft), para os dados coletados da Web e para o armazémjá integrado com os dados da Web. Tais conjuntos foram definidos para mostrar oque se consegue extrair de cada fonte individualmente e o ganho que se tem após aintegração dessas fontes tão distintas.

No DW da Microsoft tem-se os produtos decorrentes de vendas pela internet, ovalor de cada venda, a data da venda e o lugar onde ocorreram as vendas. Já com os

6http://blackbird.dcc.ufmg.br:1210/7http://www.tableau.com/pt-br/products/desktop

http://blackbird.dcc.ufmg.br:1210/

http://www.tableau.com/pt-br/products/desktop


Tabela 4.1. Armazém da Microsoft (DWM)

Métrica Descrição OrigemValor das ven-das por mês porlugar

Montante das vendas dos produtos agru-pado por mês e por lugar

Tabelas FactInternetSa-les, DimDate e DimSa-lesTerritory

Valor das ven-das por mês porproduto

Montante das vendas dos produtos agru-pado por mês e por produto

Tabelas FactInternetSa-les, DimDate e DimPro-duct

Valor das ven-das por lugarpor produto

Montante das vendas dos produtos agru-pado por lugar e por produto

Tabelas FactInternetSa-les, DimSalesTerritory eDimProduct

dados coletados do Twitter tem-se os comentários contendo os produtos decorrentes dofiltro aplicado durante a coleta, o lugar de origem dos dados, tópicos relevantes, análisede sentimento e a data de cada comentário.

Com o armazém de dados do estudo de caso, dentre diversas informações, é possí-vel saber o valor das vendas por mês por país, o valor das vendas por mês por produtoe o valor das vendas por país por produto. Com os dados coletados da Web é possívelsaber, dentre outras informações, os comentários dos produtos por lugar, a classifica-ção do comentário como neutro, positivo ou negativo, os tópicos mais relevantes porlugar. Com a integração dos dados é possível identificar os lugares que mais criticamou elogiam os produtos, identificar os produtos menos comentados, os mais elogiados.Também é possível avaliar se o lugar com maior valor de vendas coincide com o lugarde mais comentários positivos.

As Tabelas 4.1, 4.2 e 4.3 apresentam as métricas definidas para o três conjuntos,uma breve descrição da finalidade de cada uma e a origem da informação em cadafonte de dados específica: DW da Microsoft (DWM), DW coletado da Web (DWW)ou ambas (integradas - DWI).

Essas métricas são úteis para acompanhar o desempenho da empresa e responder apergunta definida no início do processo. Nesse momento, após a avaliação das métricasos resultados são quantificados e apresentados na Seção 4.5.

4.5 Resultados

Nesta seção são apresentados os resultados obtidos a partir da aplicação da metodolo-gia proposta em um armazém de dados contendo o histórico de vendas fictícias onlinede diversos produtos. Supondo que a empresa queira avaliar seus produtos pelo mundoatravés de comentários coletados em redes sociais e que a coleta dos dados seja di-

4.5. Resultados 49

Tabela 4.2. Armazém coletado da Web (DWW)

Métrica Descrição Origem

Análise de sen-timento do pro-duto por mês

Classificação do comentário sobre o pro-duto em Neutro, Positivo ou Negativoagrupado por mês

Tabelas CUBO_FATO,DIM_ANALISE_-SENTIMENTO,DIM_PRODUTO eDIM_TEMPORAL

Análise de sen-timento do pro-duto por lugar

Classificação do comentário sobre o pro-duto em Neutro, Positivo ou Negativoagrupado por lugar

Tabelas CUBO_FATO,DIM_ANALISE_-SENTIMENTO,DIM_PRODUTO eDIM_ESPACIAL

Temas/tópicosmais relevantespor lugar

Tópicos mais relevantes identificados apartir da técnica LDA agrupados por lugar

Tabelas CUBO_FATO,DIM_TEMATICA eDIM_ESPACIAL

Produto por lu-gar

Comentários sobre produtos agrupadospor lugar

Tabelas CUBO_FATO,DIM_PRODUTO eDIM_ESPACIAL

recionada levando em consideração os produtos que a empresa trabalha, as métricasdefinidas na Seção 4.4 ajudam na análise dos dados e na tomada de decisão.

A Figura 4.2 representa o cenário que a empresa pretende avaliar, contendo o DWda Microsoft e o DW coletado das redes sociais. O DW da Microsoft está simplificadodo lado esquerdo da Figura 4.2 com a tabela Fato DWM e suas quatro dimensões.O DW coletado das redes sociais está simplificado do lado direito da mesma figuracom a tabela Fato DWW e suas cinco dimensões. A Figura também ilustra os pontospositivos e negativos de cada fonte de dados de forma independente e individual.

A Figura 4.3 representa o cenário para o que a empresa pretende avaliar, noentanto, com os armazéns integrados, representados na Figura como DWM e DWW.Os pontos positivos e negativos dessa integração são apontados na Figura 4.3.

Com a integração dos dados obtidos na Web com os dados operacionais da em-presa, vários indicadores podem ser identificados em prol do ganho de informação útilpara a empresa. Tais indicadores podem resultar em métricas que possam auxiliar ostomadores de decisão da empresa a atingir certos objetivos. Neste caso, as possíveismétricas podem ser criadas seguindo o padrão das métricas descritas na Seção 4.4,evidenciando o DW (Microsoft ou Twitter) e as tabelas utilizadas. Assim, dentre osinúmeros pontos que podem ser avaliados após a integração dos dados para auxiliar osgestores na tomada de decisão, pode-se destacar os seguintes indicadores:

• Avaliar os produtos com comentários neutros para sugerir algo para melhorar oscomentários sobre eles


Tabela 4.3. Armazém integrado (DWI)

Métrica Descrição OrigemLugares quemais criticamou elogiam osprodutose desses luga-res, analisar osprodutos maiscriticados ouelogiados

Interseção dos lugares e dos produtos doDWM e DWW e busca classificação do co-mentário no DWW

TabelasDimSalesTerritory,DIM_ESPACIAL,DimProduct,DIM_PRODUTO eDIM_ANALISE_-SENTIMENTO

Produtos menoscomentados

Interseção dos produtos do DWM e DWWe verifica a quantidade de comentáriosagrupada por produtos

Tabelas DimProduct eDIM_PRODUTO

Produtos maiscriticados ouelogiados

Interseção dos produtos do DWM e DWWe busca classificação do comentário noDWW

Tabelas DimProduct,DIM_PRODUTO eDIM_ANALISE_-SENTIMENTO

Lugar commaior valor devendas(verificar secoincide com olugar de maiscomentáriospositivos)

Interseção dos lugares e dos produtos doDWM e DWW e calcula o montante dasvendas agrupado por lugar e busca classi-ficação do comentário no DWW

Tabelas FactInternetSa-les, DimSalesTerritory,DIM_ESPACIAL,DimProduct,DIM_PRODUTO eDIM_ANALISE_-SENTIMENTO

Contrastar pro-duto, lugar e tó-pico relevante

Interseção dos lugares e dos produtos doDWM e DWW e busca o tópico relevantedo comentário no DWW

Tabelas DimSalesTerri-tory, DIM_ESPACIAL,DimProduct,DIM_PRODUTO eDIM_TEMATICA

• Identificar os lugares com maior incidência de comentários negativos para iden-tificar o problema e tomar medidas para levantar esses índices

• Identificar o período do dia com mais comentários e identificar o produto maiscomentado

• Identificar os tópicos mais relevantes dos lugares e contrastar com o que tem sidovendido nesses lugares

• Identificar o mês com o menor valor de vendas e contrastar com os comentáriosneutros e negativos

As próximas Figuras (4.4 a 4.12) apresentam os gráficos gerados a partir daintegração dos dados entre o armazém do estudo de caso e os dados coletados da rede

4.5. Resultados 51

Figura 4.2. Avaliação individual dos armazéns

Figura 4.3. Avaliação da integração

social. Os gestores da organização têm o papel de interpretar esses gráficos e tomar asmedidas que forem necessárias para alavancar os negócios da empresa.

Vale ressaltar que toda informação representada nos gráficos é resultante da in-tegração. Os produtos e os países mostrados, por exemplo, são o resultado da junção


Figura 4.4. Lugares que mais criticam os produtos

(inner join) das duas bases. Pois no DW da Microsoft há uma lista de lugares ondeocorreram vendas, entretanto, nos dados coletados não vieram informações sobre taislugares. Da mesma forma, no DW coletado há uma lista de lugares cujo o DW da Mi-crosoft não possui vendas relacionadas. O mesmo vale para os produtos dos gráficos.

As Figuras 4.4 e 4.5 mostram os lugares que mais criticam e elogiam os itensresultantes da integração entre as fontes de dados, respectivamente. A análise desentimentos nos tweets, combinada com informação de localização do usuário, permiteverificar a repercussão positiva ou negativa dos produtos. As figuras indicam que, parao conjunto completo de produtos, a maior quantidade de críticas vem dos EstadosUnidos. Ponderando esse resultado pelo número de mensagens obtidas de cada país,no entanto, verifica-se que os franceses são mais críticos que os norte-americanos.

Cada linha armazenada na tabela fato do DWW, representa um comentário pro-veniente do Twitter. Dessa forma, a Figura 4.6 mostra a quantidade de comentários poritens (da tabela Produto DWM). Nota-se que os itens menos comentados são aquelesque estão na categoria “Acessórios”, e os itens mais comentados são as “Bicicletas”.

Da mesma forma, é possível cruzar os dados dos itens (DWM) com as informa-ções provenientes da Análise de Sentimento do DWW. As Figuras 4.7 e 4.8 mostrama quantidade de comentários classificados como negativos e positivos, respectivamente.Tal classificação é consequência da utilização da técnica de análise de sentimento poritem resultante da interseção entre as fontes de dados. Os itens da categoria “Aces-

4.5. Resultados 53

Figura 4.5. Lugares que mais elogiam os produtos

sórios” não tiveram comentários negativos e pressupõe-se que não foram criticados.Apesar dos itens em “Acessórios” apresentarem uma quantidade menor de “elogios”(33), quando contrastado com o resultado da Figura 4.6, eles são os mais elogiados(22% = 33/153), contra 20% dos “Vestuários” e 21% das “Bicicletas”.

Outra possível análise é fazer a interseção dos lugares (dimensão Territorial doDWM e dimensão Espacial do DWW) com as informações temporais dos comentários(dimensões DimDate do DWM e Temporal do DWW) e a análise de sentimento dessescomentários (Análise de Sentimento do DWW) e verificar alguma relação do montantede vendas com a percepção dos usuários. As Figuras 4.9 e 4.10 apresentam essa inter-seção. A primeira figura mostra o montante das vendas tendo como referência o mês deJulho agrupado por lugar. A segunda figura mostra os comentários positivos no mesmoperíodo agrupados por lugar. Observa-se que no período analisado, a Austrália foi opaís que mais vendeu, no entanto, não haviam muitos comentários coletados, os poucosque vieram foram comentários positivos e não tiveram comentários negativos. Nestecaso, uma possível interpretação é de que as vendas não têm relação explícita com oscomentários, pois no caso da Austrália que teve o maior faturamento do período, foium dos países em que menos obtiveram comentários. Outra possível interpretação éque na internet (mais especificamente em redes sociais), as pessoas tendem a postarmais comentários negativos do que positivos (pois tendem a reclamar quando algo nãoestá bom). Porém, a confirmação de tais conjecturas demandam um estudo com dados


Figura 4.6. Comentários por itens

reais e análises mais detalhadas e aprofundadas.

A técnica de LDA foi aplicada sobre os dados coletados e o tema mais relevantede cada tweet foi identificado. Esses tópicos relevantes podem ser contrastados com ositens do DWM e com os lugares das duas bases. As Figuras 4.11 e 4.12 mostram osdois tópicos/temas mais relevantes agrupados por item e por lugar, respectivamente.O tópico mais relevante para Austrália foi “Bicicletas” e o montante da venda desseitem foi maior quando comparado às vendas de “Acessórios” e “Vestuários”.

Um fato curioso é que o tópico mais relevante na Austrália foi “Bicicletas” e acoleta se deu no inverno de lá. O tópico “Meias” foi relevante em três países queestavam no verão durante a coleta dos dados. Pensando logicamente, onde fosse invernoesperava-se comentários de vestuários de inverno (meias, por exemplo), e onde fosseverão esperava-se comentários sobre atividades em ar livre (pedalar, por exemplo). Noentanto, o resultado mostrou o contrário. Mas isso não descarta uma análise com dadosreais que pode revelar algo relevante para a tomada de decisão.

Vale lembrar que por se tratar de dados fictícios, os resultados e análises apre-sentados aqui são conjecturas. Aplicar a metodologia proposta utilizando dados reaise as técnicas sugeridas pode evidenciar bons resultados ajudando no aprimoramentodos negócios da empresa.

Depois de apresentar esses gráficos, a Seção 4.6 apresenta uma análise crítica apartir dos resultados obtidos.

4.6. Análise 55

Figura 4.7. Itens mais criticados

4.6 Análise

A metodologia propõe a integração de dados de diversas fontes, dentre elas, as en-contradas na Web, como as redes sociais. É importante destacar que trabalhar comtais tipos de dados requer cuidados extras. Pois dados recuperados de redes sociais,são dados fornecidos por contribuição/participação voluntárias. Com isso, esses dadospossuem uma confiabilidade menor, podendo ser menos precisos também. Dados dessanatureza possuem cobertura parcial e podem conter restrições.

Por se tratar de armazéns de dados, a ideia é o armazenamento histórico dosdados, dessa forma, a coleta dos dados das redes sociais torna-se uma atividade contínuae isso gera um grande volume de dados (caracterizando o Big Data). Trabalhar com BigData aumenta o desafio da integração sendo necessário o uso dos recursos fornecidospelo Big Data Analytics.

Outra preocupação do uso dessa fonte de dados para integrar aos armazéns ésobre a qualidade dos dados, pois é preciso utilizar processos diferentes e sofisticadospara a validação da qualidade desses dados.

Ao integrar dados de fontes externas ao armazém de dados estruturado, foi pos-sível agregar percepções dos usuários aos dados objetivos de vendas e faturamento.Passa-se a contar com uma maneira de perceber a aprovação ou rejeição a produ-tos, fragmentada em regiões e períodos de tempo. Usando as técnicas de análise de


Figura 4.8. Itens mais elogiados

sentimento e identificação de temas relevantes, mesmo considerando que os dados não-estruturados não garantem cobertura e qualidade uniformes, é possível acrescentarindicações para a tomada de decisão. Por exemplo, considerando os temas relevantesdestacados, pode-se direcionar certas propagandas para determinado público-alvo.

A metodologia propõe a criação de uma dimensão com os advérbios temporaispois esses advérbios possibilitam o analista dos dados identificar eventos que ocorremcom mais frequência em determinado período do dia. Criar uma dimensão com lu-gares identificados através de técnicas aplicadas a textos ajuda o analista dos dadosidentificar certos eventos em determinados lugares que antes eram desconhecidos. Acriação de uma dimensão com os tópicos relevantes identificados nas fontes de dadospode ajudar os analistas do dados a avaliarem a ocorrência de tópicos semelhantesnuma região. Com a análise de sentimento é possível classificar o dado coletado comopositivo, negativo ou neutro e ajuda o analista dos dados ter a percepção da reação daspessoas sobre determinados assuntos. A dimensão espacial identifica lugares atravésde coordenadas geográficas. Utilizar a API do Google permitiu obter a informação dosarredores do ponto coletado.

No Capítulo 5 apresentamos as considerações finais desse trabalho e sugestões detrabalhos futuros.

4.6. Análise 57

Figura 4.9. Valor das vendas por lugar

Figura 4.10. Lugares com mais comentários positivos


Figura 4.11. Temas mais relevantes por item

Figura 4.12. Temas mais relevantes por lugar

Capítulo 5

Considerações Finais e TrabalhosFuturos

As considerações finais e as contribuições desse trabalho são apresentadas neste capítulojunto das sugestões de trabalhos futuros, com o objetivo de contribuir com a evoluçãodessa área de pesquisa.

Esse trabalho propôs uma metodologia para integrar dados da Web (coletados deredes sociais, por exemplo) a armazéns de dados estruturados (provenientes de dadostransacionais de uma empresa). Essa integração visa enriquecer tais armazéns paraauxiliar e orientar o gestor no processo de tomada de decisão. Para atingir os objetivosdesse trabalho, a metodologia proposta foi aplicada em um estudo de caso para validarsua viabilidade.

Técnicas foram utilizadas para extrair informações úteis dos dados coletados paraintegrar ao armazém de dados do estudo de caso, dentre elas a análise de sentimento eLDA. Métricas foram definidas para analisar os resultados da integração. O resultadode destaque alcançado nesse trabalho foi perceber as oportunidades escondidas nosdados. A integração instiga o gestor a elaborar novas perguntas, identificar tendências,oportunidades e tomar decisões orientadas pelos dados.

Durante o desenvolvimento do trabalho foram encontradas algumas dificuldades,dentre elas a limpeza dos dados para aplicar as técnicas selecionadas e a integração deinformação útil que agregasse valor ao armazém de dados. Apesar dessas dificuldades,das limitações dos dados e da combinação de fontes tão distintas (armazém sólido eobjetivo com dados não-estruturados de contribuição voluntária), foi possível contrastaras dimensões do armazém com as dimensões identificadas enriquecendo as informaçõespara o aprimoramento da tomada de decisão.

Esse trabalho tem sua principal contribuição materializada como uma metodo-

59

60 Capítulo 5. Considerações Finais e Trabalhos Futuros

logia que foi validada através de um estudo de caso. A partir dessa metodologia épossível orientar as pessoas no processo de integração e enriquecimento de armazénsde dados estruturados.

Uma sugestão de trabalho futuro é utilizar uma técnica para encontrar algumalocalização a partir do texto coletado. Por exemplo, na frase: “Ontem fui patinar naesplanada do Mineirão”, a técnica identificaria a palavra “Mineirão” como uma locali-zação classificando-a como um estádio de futebol situado na cidade de Belo Horizonte,estado de Minas Gerais. Outra sugestão seria adicionar outras perspectivas ao arma-zém para maior enriquecimento, como por exemplo, informações de clima, economia,relevo, sócio-cultural, etc.

Outra sugestão de trabalho futuro seria aplicar a metodologia proposta utilizandodados reais. As mesmas técnicas do estudo de caso seriam utilizadas e a coleta seria bemdirecionada e definida com um período maior. Dessa forma, os ganhos reais ficariammais evidentes.

Apesar do modelo relacional ainda ser bastante usado e mais facilmente compre-endido quando comparado aos bancos NoSQL, um estudo pode ser feito para integraros dados de um armazém estruturado com dados de diversas fontes não-estruturadasem uma solução NoSQL. Pois com a tendência do crescimento do volume dos dados, émais barato implementar uma solução com escalabilidade horizontal e os BDR não sãocustomizados para serem eficientes em Cluster, ao contrário dos bancos NoSQL que jáforam projetados para trabalhar eficientemente dessa forma. Então seria interessantefazer o estudo da viabilidade de se manter um DW numa estrutura NoSQL.

Dados de fontes diferentes quando combinados e comparados de acordo com as ne-cessidades podem contar novas histórias e incentivar uma cultura de tomada de decisãoembasada nesses dados. Assim, esperamos que esse esforço possa ajudar pesquisadorese profissionais no processo de integrar e enriquecer armazéns de dados, e também ajudara promover pesquisas relevantes nessa área, com uma abordagem científica minuciosa.

Referências Bibliográficas

Alqarni, A. A. & Pardede, E. (2012). Integration of Data Warehouse and Unstruc-tured Business Documents. 2012 15th International Conference on Network-BasedInformation Systems, pp. 32--37.

Barbieri, C. (2001). BI – Business Intelligence – Modelagem & Tecnologia. Rio deJaneiro: Axcel Books do Brasil Editora.

Barbieri, C. (2011). BI2 - Business Inteligence: Modelagem & Qualidade. Rio deJaneiro: Elsevier.

Blei, D. M.; Ng, A. Y. & Jordan, M. I. (2003). Latent dirichlet allocation. J. Mach.Learn. Res., 3:993--1022.

Bonnet, L.; Laurent, A.; Sala, M.; Laurent, B. & Sicard, N. (2011). Reduce, You Say:What NoSQL Can Do for Data Aggregation and BI in Large Repositories. 2011 22ndInternational Workshop on Database and Expert Systems Applications, pp. 483--488.

Carniel, A. C.; Sá, A. A.; Brisighello, V. H. P.; Ribeiro, M. X.; Bueno, R.; Ciferri,R. R. & Ciferri, C. D. A. (2012). Query Processing over Data Warehouse usingRelational Databases and NoSQL. Informatica (CLEI), 2012 XXXVIII ConferenciaLatinoamericana En.

Cattell, R. (2011). Scalable SQL and NoSQL data stores. ACM SIGMOD Record,39(4):12--27.

Dehdouh, K.; Bentayeb, F.; Boussaid, O. & Kabachi, N. (2014). Columnar NoSQLCUBE : Agregation operator for columnar NoSQL data warehouse. Systems, Manand Cybernetics (SMC), 2014 IEEE International Conference on, pp. 3828--3833.

Elmasri, R. & Navathe, S. B. (2005). Sistemas de Banco de Dados. 4. ed. PearsonAddison Wesley.

61

62 Referências Bibliográficas

González, S. M. & Berbel, T. R. L. (2014). Considering unstructured data for OLAP :a feasibility study using a systematic review. Revista de Sistemas de Informação daFSMA 14, 14:26--35.

Inmon, W. H. & Nesavich, A. (2007). Tapping into unstructured data: integratingunstructured data and textual analytics into business intelligence. 1. ed. PearsonEducation.

Kimball, R. & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide toDimensional Modeling. 3. ed. Wiley Computer Publishing.

Leavitt, N. (2010). Will NoSQL databases live up to their promise? IEEE Computer,43(2):12--14.

Moniruzzaman, A. & Hossain, S. A. (2013). NoSQL database: New era of databasesfor big data analytics-classification, characteristics and comparison. arXiv preprintarXiv:1307.0191.

Nguyen, D. Q. (2015). jLDADMM: A Java package for the LDA and DMM topicmodels. http://jldadmm.sourceforge.net/. Acesso em: 14 set. 2016.

Perez, J.; Berlanga, R.; Aramburu, M. & Pedersen, T. (2008). Integrating Data Wa-rehouses with Web Data: A Survey. IEEE Transactions on Knowledge and DataEngineering, 20(7):940--955.

Queiroz, G. R.; Monteiro, A. M. V. & Câmara, G. (2013). Bancos de Dados Geo-gráficos e Sistemas NoSQL: onde estamos e para onde vamos. Revista Brasileira deCartografia, 65(3).

Ravat, F.; Teste, O. & Tournier, R. (2007). OLAP aggregation function for textualdata warehouse. Em International Conference on Enterprise Information Systems(ICEIS), pp. 151--156.

Rob, P. & Coronel, C. (2011). Sistemas de Banco de Dados - Projeto, Implementaçãoe Administração. Cengage Learning.

Sadalage, P. J. & Fowler, M. (2013). NoSQL Distilled: A brief guide to the emergingworld polyglot persistence. Pearson Education.

Singh, H. S. (2001). Data Warehouse Conceitos, Tecnologias, Implementação e Geren-ciamento. Makron Books.

http://jldadmm.sourceforge.net/

Referências Bibliográficas 63

Thenmozhi, M. & Vivekanandan, K. (2012). An ontology based hybrid approach toderive multidimensional schema for data warehouse. International Journal of Com-puter Applications, 54(8).

Tria, F.; Lefons, E. & Tangorra, F. (2014). Design process for Big Data Warehouses.Em Data Science and Advanced Analytics (DSAA), 2014 International Conferenceon, pp. 512--518. IEEE.