solução de b.i. para empresas de pequeno porte

UNIVERSIDADE FEDERAL DE MATO GROSSO CAMPUS UNIVERSITRIO DO ARAGUAIA INSTITUTO DE CINCIAS EXATAS E DA TERRA

CURSO DE CINCIA DA COMPUTAO

ESTUDO DE UMA SOLUO DE BUSINESS

INTELLIGENCE PARA UMA EMPRESA DE PEQUENO

PORTE.

FELIPE AUGUSTO CAMPOS DE OLIVEIRA

BARRA DO GARAS MT

Ano 2015

UNIVERSIDADE FEDERAL DE MATO GROSSO CAMPUS UNIVERSITRIO DO ARAGUAIA INSTITUTO DE CINCIAS EXATAS E DA TERRA

CURSO DE CINCIA DA COMPUTAO

ESTUDO DE UMA SOLUO DE BUSINESS

INTELLIGENCE PARA UMA EMPRESA DE PEQUENO

PORTE.

FELIPE AUGUSTO CAMPOS DE OLIVEIRA

Orientador: Prof. Me Anthony Ferreira La Marca

Monografia apresentada ao Instituto de Cincias Exatas

e da Terra do Campus Universitrio do Araguaia, da

Universidade Federal de Mato Grosso, como requisito

parcial para concluso do Curso de Graduao em

Cincia da Computao.

BARRA DO GARAS MT

Ano 2015

RESUMO

O comrcio varejista est em crescente evoluo em nosso pas, aumentando

significativamente a concorrncia entre os comerciantes. Este fato torna crucial as

tomadas de decises administrativas, pois investimentos errados, ou uma m poltica de

controle, pode desencadear em consequncias desastrosas. Os comrcios maiores e mais

consolidados tm polticas e infraestruturas melhores definidas (na maioria dos casos) e

esto mais preparados para esse aumento competitivo, porm as organizaes de menor

porte geralmente carecem de uma poltica administrativa mais organizada, e de

ferramentas e pessoas que auxiliem nos processos decisrios. No cenrio de

microempresas as decises geralmente so mais simples, porm com o seu crescimento

acelerado,polticas de controle comeam a ficar mais difceis de serem realizadas

manualmente, a quantidade de produtos (ou servios) muito grande, a projeo

financeira fica muito extensa, o cartel de clientes extenso, o que leva aos

administradores da empresa, a utilizar apenas informaes do cotidiano, perdendo

informaes histricas na qual forneceriam um controle mais rgido. Para resolver esse

problema, uma opo seria a contratao de funcionrios especializados nessa rea para

realizarem o trabalho de forma manual, gerando custos (financeiros, e mesmo

temporais). Outra alternativa, seria utilizar uma soluo computacional que seja capaz

de automatizar todo o processo de controle da empresa, alm de auxiliar em tomadas de

decises.Neste contexto, a proposta desse trabalho analisar uma empresa de pequeno

porte que deseja utilizar informaes histricas e atuais para polticas de controle e

tomada de decises, utilizando recursos tecnolgicos, alm de oferecer uma soluo de

BI (Business Inteligence) que se adeque a ela e ao mercado.

ABSTRACT

The retail business is in growing expansion in our country, significantly

increasing competition between traders. This fact makes crucial the administrative

decision making process, because the wrong investments, or a bad control policy, can

trigger in disastrous consequences. The larger and more established businesses have

better policies and infrastructure defined (in most cases) and are more prepared for this

increase competitive, but the smaller organizations often lack a more organized

administrative policy, tools and people to help the decision making processes. In the

micro scenario decisions generally are simpler, but with a rapid growth, control policies

start to get more difficult to be performed manually, the amount of products (or

services) is very large, the financial projection is very large, the customer cartel is

extensive, which leads to company directors, using only everyday information, losing

historical information that would provide tighter control. To resolve this problem, one

option would be to hire specialized employees in this area to do the work manually,

generating costs (financial, and even with time). Another alternative would be to use a

computational solution that is able to automate the whole process of control of the

company, and help in decision making process. In that context, the purpose of this study

is to analyze a small company that wants to use historical and current information for

control policies and decision-making, using technological resources, and offers a BI

solution (Business Intelligence) that suits her and the market.

SUMRIO

RESUMO ....................................................................................................................................... 3

ABSTRACT ................................................................................................................................... 4

SUMRIO ..................................................................................................................................... 5

LISTA DE FIGURAS ................................................................................................................... 7

LISTA DE SIGLAS E ABREVIATURAS .................................................................................. 8

1 INTRODUO .................................................................................................................. 9

1.1 OBJETIVOS .................................................................................................................. 10

1.1.1 Objetivo geral ....................................................................................................... 10

1.1.2 Objetivos especficos ............................................................................................ 10

1.2 JUSTIFICATIVA .......................................................................................................... 11

1.3 METODOLOGIA .......................................................................................................... 11

1.4 ESTRUTURA DO TRABALHO................................................................................... 11

2 BI ........................................................................................................................................ 12

2.1 CONTEXTO HISTRICO:........................................................................................... 12

3 DATA WAREHOUSE ..................................................................................................... 14

3.1 DATA WAREHOUSE NO CONTEXTO DE BI .......................................................... 14

3.2 CARACTERSTICAS DO DATA WAREHOUSE ...................................................... 15

3.3 ABORDAGEM .............................................................................................................. 16

3.4 DATA MART X DATA WAREHOUSE ...................................................................... 17

3.5 BANCO TRANSACIONAL X DATA WAREHOUSE .............................................. 17

3.6 MODELO DIMENSIONAL .......................................................................................... 18

3.7 CUSTOS DO DATA WAREHOUSE ........................................................................... 19

3.8 GRANULARIDADE ..................................................................................................... 19

3.9 TIPOS DE DATAWAREHOUSE ................................................................................. 20

3.10 ETL ........................................................................................................................... 21

4 IMPLEMENTAO ....................................................................................................... 22

4.1 LEVANTAMENTO DE REQUISITOS ........................................................................ 22

4.2 DELIMITAO DO PROTTIPO .............................................................................. 23

4.3 TECNOLOGIAS DO SISTEMA ................................................................................... 23

4.4 FONTE DE DADOS ..................................................................................................... 24

4.5 DATA MART ................................................................................................................ 24

4.6 GRANULARIDADE ..................................................................................................... 24

4.7 ETL ................................................................................................................................ 25

4.8 VISUALIZAO DE DADOS ..................................................................................... 27

4.9 APLICAO CLIENTE ............................................................................................... 29

4.10 APLICAO SERVIDOR ....................................................................................... 29

5 CONCLUSO E RESULTADOS ................................................................................... 30

5.1 LITERATURA .............................................................................................................. 30

5.2 COLETA DE REQUISITOS ......................................................................................... 30

5.3 SOLUO .................................................................................................................... 30

5.4 RESTRIES ............................................................................................................... 30

5.5 TRABALHOS FUTUROS ............................................................................................ 31

REFERNCIAS .......................................................................................................................... 32

LISTA DE FIGURAS

Figura 1 - Data Mart

Figura 2 - Fluxo de Controle

Figura 3 - Fluxo geral de dados

Figura 4 - Fluxo de dados da tabela de fatos

Figura 5 - Visualizao de dados 1

Figura 6 - Visualizao de dados 2

LISTA DE SIGLAS E ABREVIATURAS

BI Business Inteligence

DASD Direct Acess Storage Device

SGBD Sistema Gerenciador de Banco de Dados

SQL Structured Query Language

ERP Enterprise Resourse Planning

TI Tecnologia da Informao

ETL Extract Transform Load

ROI Return On Investment

PHP PHP: Hipertext Preprocessor

SSIS SQL Server Integration System

HTML HyperText Markup Language

XML eXtensible Markup Language

AJAX Asynchronous Javascript and XML

OLAP OnLine Analytical Processing

9

1 Introduo

Existem vrios desafios no mundo empresarial para o crescimento do prprio negcio,

mas para conseguir abstrair quais resultados pretende-se alcanar, deve-se ter o modelo da

organizao bem definido. No escopo desse trabalho aborda-se uma empresa de fins

lucrativos de pequeno porte.Uma empresa de pequeno porte tem um faturamento anual de at

3.600.000,00 reais (Brasil, Lei complementar N 123, de 14 de dezembro de 2006,2006), e

para Chiavenato (2011), uma empresa com fins lucrativos tem como objetivo arrecadar lucro

que mantenha a empresa em funcionamento e traga retorno de capital para os proprietrios e

acionistas.

Apesar do resultado final ser a obteno do lucro, a maneira como uma empresa

arrecada dinheiro est ligada a uma diversa gama de variveis, como preo dos produtos,

qualidade da equipe de vendas, ateno e resoluo de problemas junto ao cliente,

pagamentos, compras, controle de estoque dentre outros. So diversos fatores que culminam

em um resultado financeiro positivo para a empresa, sendo que, em uma empresa pequena

difcil de ter o tempo necessrio ou ter pessoas capacitadas para realizarem essas anlises

manuais. Geralmente so feitas anlises mais instintivas ou utilizando o achometro para a

tomada de decises.

Schuch cita que(SCHUCH, 2001,p.4) Sistemas de indicadores so o ponto de partida

para qualquer ao de melhoria empresarial. Mesmo em micro empresas, as aes so

voltadas para a melhoria segundo determinados indicadores (no limite mnimo, o lucro

lquido, mesmo no medido formalmente). A concepo de um conjunto de indicadores que

auxiliem o planejamento e o acompanhamento das aes gerenciais corresponde etapa

inicial de qualquer sistema de gesto empresarial.(...) Desde a criao dos primeiros

indicadores, na General Motors e na Du Pont, na dcada de 30 (como forma de controlar o

funcionamento de suas divises), os indicadores assumiram importncia crescente na gesto.

Outros autores suportam essa opinio:

Se o desempenho no est sendo medido, no est sendo gerenciado. (Rummler &

Brach, 1994, pg.167).

Diga-me como me medes e te direi como me comportarei. (Goldratt, 1991, pg 26).

A importncia dos indicadores grande no processo decisrio, por isso eles no

podem ser apenas nmeros, devem ser correspondentes a realidade para uma anlise precisa e

10

devem ser apresentados de uma maneira onde o usurio do sistema consiga tirar as

informaes necessrias para tomada de decises.

Os atuais executivos esperam ter informaes histricas para tomar melhores decises

e liderar suas companhias para a prxima dcada (IMHOFF; GALEMMO; JONATHAN,

2003), com essa necessidade de informaes, deve-se definir uma maneira para chegar a essas

informaes. A integrao dessas medidas, tanto a extrao, quanto o tratamento e

demonstrao pode ser resolvida em uma soluo de BI.

1.1 Objetivos

Este subcaptulo, trata dos objetivos gerais e especficos que eram pretendidos com o

trabalho

1.1.1 Objetivo geral

Propor uma soluo para tomada de decises para uma empresa de pequeno porte,

utilizando conceitos de BI.

1.1.2 Objetivos especficos

Identificar problemas de coleta de requisitos e implantao.

Montar um modelo seguindo padres tericos, fazendo modificaes devido a

limitaes tcnicas de tempo e conhecimento.

Apresentar a possibilidade de uma soluo, mesmo com recursos limitados.

Implementar uma soluo simples e vivel.

1.2 Justificativa

Este trabalho oferece um prottipo de uma soluo a uma empresa em atividade no

mercado, alm de oferecer subsdios e problemticas para solues similares.

1.3 Metodologia

A metodologia de desenvolvimento do trabalho, inclui um referencial terico com

conceitos a serem aplicados na soluo e o desenvolvimento de um prottipo, ilustrando os

passos que foram seguidos.

11

1.4 Estrutura do Trabalho

Esse trabalho foi dividido em 5 captulos. O primeiro captulo trata do problema da

tomada de decises empresariais e aponta a importncia dos indicadores para auxiliar o

processo decisrio.

O segundo captulo apresenta a conceituao do termo BI e uma introduo histrica

para demonstrar que a evoluo tecnolgica gerou um aumento exponencial de dados,

gerando dificuldades em obter informaes sem uma soluo especfica.

O terceiro captulo abrange os conceitos e tecnologias envolvidos na modelagem e na

criao de um data warehouse. O entendimento geral sobre o data warehouse muito

importante, pois abrange uma soluo analtica e como fonte de dados precisos, a utilizao

de um data warehouse universalmente aceito.

O quarto captulo demonstra os passos de implementao da soluo, com os detalhes

tcnicos, delimitaes do prottipo e problemticas para o desenvolvimento.

O quinto e ltimo captulo apresenta os resultados do prottipo, concluses sobre a

proposta inicial e possveis trabalhos futuros.

12

2 BI

BI um termo novo, que foi concebido no inicio dos anos 90 pela empresa de

consultoria Gartner Group, uma das mais renomadas mundialmente pela pesquisa de

tecnologias de tomada de decises empresariais. O termo se refere a inteligncia de negcios

que basicamente a transformao de dados de uma empresa em informaes a partir da

integrao, limpeza e demonstrao destes, alm de fazer uso dessas informaes para

auxiliar na tomada de decises empresariais (TURBAN et al., 2009). Apesar de ter um

conceito simples, houveram-se algumas razes que o tornariam importante nos modelos de

gesto atuais.

O BI tem como propsito buscar um melhor entendimento da companhia, de seus

produtos e clientes. Evoluindo seus processos para melhorar anlises e aumentando o

conhecimento adquirido, as solues de BI suportam o processo de deciso das empresas

podendo avaliar produtos, clientes, processos, potenciais mercados e diversas outras tarefas

(IMHOFF; GALEMMO; JONATHAN, 2003).

2.1 Contexto histrico:

Na dcada de 60, ocorreu a introduo de fitas magnticas para o armazenamento de

dados, tornando os computadores mais comerciais. Como as fitas s podiam ser acessadas de

maneira sequencial, implicava-se em lentido no acesso aos dados que estavam nas partes

intermediarias e finais. Porm no inicio da de dcada de 70 foi criada uma tecnologia de

acesso aos dados de forma direta, denominado DASD (Direct Acess Storage Device), que

seria o primrdio da idia dos discos rgidos. Com o conceito de acesso aleatrio aos dados

foi possvel a criao dos primeiros SGBDs (Sistema Gerenciador de Banco de Dados), na

qual permitiam gerenciar o acesso e manipular e organizar os dados (INMON, 2002).

Apesar da criao de alguns conceitos importantes, os dados no eram o foco principal

da poca, mas sim, as aplicaes. No incio dos anos 80 comeou-se a pensar nos sistemas

gerenciais de forma mais abrangente, e dessa idia, surgiram conceitos focados na

manipulao dos dados. Esta foi a poca do surgimento da administrao de dados,

modelagem de dados, engenharia da informao, anlise de dados, dentre outros. Com a

evoluo dos modelos de dados, surgiu-se o modelo relacional, na qual proporcionava mais

flexibilidade, segurana e controle aos sistemas, alm de fornecer uma linguagem padronizada

13

e eficiente denominada SQL (Structured Query Language) (LIATUTAUD; HAMMOND,

2002).

Nos anos 90, com uma grande quantidade de dados e de sistemas sendo utilizados de

maneira independente, surgiu a necessidade de integrao. Os ERPs (Enterprise Resourse

Planning), que so sistemas com o propsito de integrar todos os dados e processos em um

nico sistema, se popularizaram, principalmente pela disseminao da arquitetura cliente-

servidor, na qual valorizava a utilizao de uma rede de computadores ao invs de

mainframes, diminuindo o custo da infraestrutura, alm da importncia no controle e gesto

das empresas (LIATUTAUD; HAMMOND, 2002).

Os ERPs so ferramentas importantes de controle e de gesto corporativa, porm com

o foco na integrao de processos e de sistemas, a quantidade de dados gerados pelas

empresas eram grandes, ocasionando o problema da sobrecarga de dados, que consiste em ter

tantos dados, que fica impossvel analis-los corretamente. Apesar da integrao dos dados,

estes no estavam gerando informaes teis para auxiliar na tomada de deciso, sendo mais

utilizados na parte operacional da empresa.

No inicio do sculo XXI o problema de sobrecarga de dados comeou a afetar muitas

empresas, devido ao inevitvel crescimento do grande volume de dados, mltiplas fontes de

informao resultando em dados isolados e s vezes duplicados, alm da questo de qualidade

de dados, onde se encontravam dados desatualizados ou simplesmente errados, afetando na

deciso estratgica.

A partir desse cenrio as empresas comearam a fazer atualizaes em suas

infraestruturas e em seus processos, aumentando a competitividade no mercado. A

metodologia de solues empresariais que foi adotada para as empresas pode ser identificada

como BI, que um termo que inclui ferramentas, bancos de dados, aplicaes e metodologias,

mas resumidamente o processo de BI se baseia em utilizar dados para extrair informaes que

auxiliam no processo decisrio (TURBAN et al., 2009).

14

3 Data warehouse

Um data warehouse um banco de dados de propsito analtico que integra vrias

fontes de dados em uma unidade de uma empresa, tem como caractersticas principal gerar

uma verso nica da verdade e servir de base para sistemas de suporte a deciso (TURBAN et

al., 2009). Desta forma, antes de se pensar no desenvolvimento de um data warehouse, deve-

se pensar nos objetivos que se deseja alcanar.

O data warehouse a fundao do processo de deciso, alm de facilitar o trabalho de

um analista dessa rea por integrar os dados em apenas um ambiente e ter a granularidade

modelada voltada para anlise dos dados (INMON, 2002).

3.1 Data warehouse no contexto de BI

O BI consiste em transformar dados em informaes, e dessas, gerar inteligncia para

auxiliar na tomada de decises empresariais. Para isso, deve-se ter uma boa fonte de dados e

informaes, sendo um passo importante a se atentar no inicio de cada projeto. Pelo fato do

data warehouse se tratar de um banco analtico com dados concisos, se torna uma fonte ideal

para uma soluo em BI.

Um data warehouse um banco de dados orientado a assunto com dados confiveis e

formatados de maneira especifica para o suporte a tomada de decises (TURBAN et al.,

2009). Sabendo disso possvel entender que este seria um banco ideal para o propsito de

uma soluo de BI. As informaes usadas para tomada de deciso so tiradas de experincias

histricas e que na economia atual necessrio obter boas informaes para se ter uma

vantagem competitiva, alm de oferecer uma plataforma que implementa gerencia e entrega

informaes chave (SIMON; HAMMERGREN, 2009). Dessa forma uma boa construo de

um data warehouse o passo inicial para uma aplicao que gera inteligncia, pois se a

origem dos dados ruim de alguma forma (falta detalhes, contm informaes erradas,

difcil de se extrair os dados), o produto final ruim (no gera informaes, ou gera

informaes que no correspondem a realidade, levando a uma m inteligncia).

O data warehouse deve ser criado considerando as ferramentas que sero

implementadas com ele e os requisitos que os usurios utilizaro para ajudar a definir a

modelagem desse banco. Caso um data warehouse for implementado sem considerar o tipo de

15

soluo de BI que a organizao necessita, no importa o quo sofisticada e eficiente o data

warehouse ser, no gerar o valor de negcio esperado (SIMON; HAMMERGREN, 2009).

O data warehouse torna o custo de conseguir uma informao menor e facilita o seu

acesso (INMON, 2002). Outro fator importante a se analisar no incio do projeto a

escalabilidade do banco de dados modelado, pois ele pode sofrer futuras expanses.

Outros pontos sobre o data warehouse devem ter a devida ateno para uma boa

soluo em BI. O contedo gerado pelo data warehouse deve ser claro, os dados devem ser

intuitivos tanto para o usurio quanto para o desenvolvedor, alm das ferramentas que

acessam os dados que devem ser de fcil utilizao e eficientes (KIMBALL; ROSS, 2013).

Outro aspecto muito importante a confiabilidade dos dados. Os dados devem ser

limpos antes de serem adicionados, com uma qualidade assegurada e entregues apenas para o

consumo. A ambiguidade tambm deve ser retirada, se duas medidas tem o mesmo nome, elas

devem significar a mesma coisa, caso no signifiquem, no devem ter o mesmo nome

(KIMBALL; ROSS, 2013).

Um dos aspectos mais relevantes est no fato de que os usurios que fazem parte do

processo de deciso devem aceitar a soluo gerada pelo data warehouse atravs das

ferramentas de BI, pois no importa o quo sofisticado e eficiente seja a soluo, s ser

utilizada caso gere resultados rpidos e simples (KIMBALL; ROSS, 2013).

3.2 Caractersticas do data warehouse

Base de dados separada do sistema transacional;

Somente armazenamento de dados;

Dados integrados;

Dados limpos;

Temporal;

No voltil;

Orientado a assunto;

Metadados.

16

3.3 Abordagem

O data warehouse deve ser modelado a partir dos objetivos que a organizao tem em

utiliz-lo, alm de considerar os fins que a implementao vai proporcionar deve-se

considerar o processo que ser utilizado. Para a modelagem de um data warehouse pode-se

utilizar 3 abordagens: a abordagem top-down, a abordagem bottom-up e a hbrida.

A abordagem top-down apresentada por Bill Inmon tem como pensamento centralizar

todos os processos da empresa no menor nvel de detalhe possvel, para depois separar em

subconjuntos especficos de dados por categorias, grupos e departamentos, que so

denominados data marts. Esse processo apresenta muitas vantagens, como a integrao de

dados entre os departamentos e a visualizao de todos os processos da empresa em questo,

porm o custo financeiro e temporal de implementao elevado, pois o mapeamento inteiro

da empresa deve ser feito antes da criao do banco (INMON, 2002), o que tambm gera a

demora mesmo do prottipo inicial. Essa problemtica gerou outra vertente para a

implementao do data warehouse, a abordagem bottom-up.

Esta abordagem foi conceituada por Ralph Kimball, sendo uma tcnica de modelagem

que priorizava a construo de data marts utilizando os aspectos de negcio mais importantes

dos departamentos da empresa e depois integrando-os a um data warehouse maior caso

necessrio. Esse modelo gerou fluidez tanto para o mapeamento dos processos quanto para a

implementao, gerando uma enorme diminuio de custos.

Na medida em que os data marts aumentavam, dificultava mais a integrao do data

warehouse dentro da organizao. Apesar de cada especialista defender seu ponto,

importante considerar as caractersticas da empresa que utilizar o sistema, os custos do

projeto e os objetivos da empresa com o data warehouse em questo.

Uma alternativa adotar uma modelagem hbrida, utilizando as vantagens de ambas as

modelagens citadas acima. Nesta abordagem necessita-se ter uma viso geral da empresa para

desenvolver apenas os data marts crticos (de necessidade mais urgente da empresa), ou data

marts de departamentos integrando a outros, tudo de acordo com as necessidades, tanto finais

quanto de tempo da empresa.

17

3.4 Data Mart x Data Warehouse

Existe um argumento na comunidade de TI (Tecnologia da Informao) que diz: Os

data warehouses so extremamente caros e difceis de se implementar. De fato esse

argumento procede, porm todo o esforo gerado a longo prazo vale o investimento, pois data

marts so geralmente focados em departamentos e no representam uma viso geral da

empresa, alm de suas estruturas no serem otimizadas para as outras reas de um data

warehouse (INMON, 2002).

Apesar do mrito das palavras de Bill Inmon, deve-se considerar que para muitas

empresas o custo o mais importante e em muitos dos casos as empresas no possuem

analistas com conhecimento tcnico necessrio, tornando solues mais simples viveis,

como a implementao e implantao de um data mart.

3.5 Banco Transacional X Data Warehouse

Um dos bens mais importantes de uma organizao a informao, que geralmente

utilizada para dois propsitos, controle dos sistemas transacionais e para o processo de

deciso em bancos analticos, ou seja,os bancos transacionais so onde os dados so

armazenados e processados e os bancos analticos so a fonte de onde os dados so extrados

(KIMBALL; ROSS, 2013).

A separao do banco transacional e analtico ocorre por muitas razes, dentre elas, a

diferena entre os dados utilizados para o controle e anlise de um negcio, a tecnologia

utilizada e a comunidade de usurios entre os dois bancos serem diferentes,alm das

caractersticas de processamento de um ambiente operacional e informacional mudarem

(INMON, 2002).

Algo que deve-se atentar que a modelagem desse banco diferente do banco

transacional utilizado nos sistemas principais da empresa. Os bancos transacionais so

modelados, ou deveriam ser, de maneira normalizada, respeitando diversos padres, como

redundncia de dados, anomalias de atualizaes e separando dependncias funcionais, alm

de se preocupar com inseres, atualizaes, delees e buscas feitas pelos usurios do

sistema.

J o objetivo do data warehouse no contexto de BI, como geralmente implementado,

feito como um banco de dados analtico, onde o acesso aos dados o mais importante.

18

Assim, ter uma modelagem de-normalizada que gera redundncia de dados, reduz o tempo de

pesquisa das querys, alm de no se preocupar com inseres e atualizaes realizadas por

usurios, pois as atualizaes so feitas de maneira peridica e pr-implementada em um

processo chamado ETL (Extract Transform Load).

O processamento analtico ligado ao gerenciamento do processo de decises que

contempla um grande nmero de vises de dados procurando tendncias. Ao invs de

observar um ou dois registros, como o processamento transacional, no processamento

analtico muitos registros so acessados. Nos bancos analticos poucos ou nenhum registros

so modificados, e seu contedo frequentemente agrupado e acessado para anlise, ao

contrrio do que ocorre nos bancos transacionais (INMON, 2002).

O processo ETL onde os dados so extrados do banco transacional e de outras

fontes, transformados e armazenados na estrutura do data warehouse.

Outra diferena marcante entre os bancos transacionais e analticos a importncia da

atualizao dos dados. Como o processo analtico um agrupamento de dados para anlise de

tendncias, a atualizao de uma operao tem uma relevncia pequena em relao ao todo,

porm no processo transacional, como se opera em um registro nico, a relevncia desta

informao maior. No processamento analtico o tempo de resposta necessrio gira em torno

de meia hora a um dia, sendo desastroso em um ambiente transacional (INMON, 2002).

3.6 Modelo dimensional

Duas caractersticas muito importantes do banco so a no volatilidade dos dados, que

significa que os usurios finais s fazem consultas, e de ser um banco analtico (ou seja, para

anlise de dados). Essas caractersticas tiram muitas limitaes de modelagem que temos que

considerar em um banco tradicional.

O banco pensado a partir do contexto dos dados em um modelo dimensional, onde

se tem uma tabela principal chamada de tabela de fatos a qual contm mtricas a serem

observadas sobre um determinado ponto de vista. As tabelas que so ligadas tabela de fatos

so denominadas tabelas de dimenses, onde apresentam os filtros de pesquisa sobre as

mtricas da tabela de fatos, alm de algumas descries.

O termo fato representa uma medida de negcio, como a quantidade vendida de um

produto em cada transao ou o total de vendas em um ms (KIMBALL; ROSS, 2013).

19

Nesse modelo temos uma tabela de fatos (em cada contexto de dados), sobre o que

deve ser medido, ligada a vrias tabelas, para indicar como essas mtricas devem ser medidas.

3.7 Custos do data warehouse

Um dos pontos mais importantes da implantao de qualquer soluo nova, o custo.

Um projeto de BI tem custos em vrias reas, desde a contratao do servio, at custos de

infraestrutura com equipamentos e pessoal. Esse ponto deve ser considerado na hora da

modelagem do banco, pois a modelagem do data warehouse feita para permitir a

redundncia de dados, o que pode escalar o tamanho total do banco, que necessitaria de um

servidor que comporte esta quantidade de dados.

Os custos com servidores e licenciamento de ferramentas podem ser bastante elevados,

por isso o nvel de detalhes que se armazena um ponto critico. Para se considerar a

granularidade a ser utilizada, deve-se estar bem definido o propsito do banco e da soluo,

at o uso dos dados e mesmo os prprios usurios, que podem no utilizar recursos, que

aumentam o custo do projeto.

A justificativa de custos no feita utilizando como base o ROI (Return On

Investment), os benefcios do data warehouse devem ser conhecidos antes de sua construo

(INMON, 2002).

3.8 Granularidade

O aspecto de design mais importante que o desenvolvedor do data warehouse enfrenta

determinar a granularidade, o design correto ou errado desse aspecto, pode definir se o

projeto fluir bem ou no.Esse problema tambm afeta a eficincia da entrega de dados e os

diferentes tipos de anlises que podem ser entregues (INMON, 2002).

Granularidade um dos maiores problemas de design em um ambiente de data

warehouse, pois afeta o volume de dados e a complexidade das pesquisas no banco. Na

maioria dos casos,quando os dados chegam no data warehouse com um nvel de

granularidade muito elevado, os desenvolvedores precisam gastar muitos recursos para

quebrar os dados e extrair as informaes necessrias.Entretanto, se o nvel de granularidade

for muito baixo, gasta-se muitos recursos, limpando, filtrando e resumindo os dados, antes

destes serem armazenados no data warehouse (INMON, 2002).

20

O problema de armazenamento obvio, quando se define a granularidade do data

warehouse muito baixa, gera problemas na demonstrao dos dados e aumenta o

processamento necessrio para acess-los. Caso o nvel de granularidade seja muito alto, pode

gerar perguntas que no podem ser respondidas com as informaes armazenadas (INMON,

2002). Esse paradigma algo que se deve atentar, quando a granularidade do data warehouse

estiver sendo definida.

3.9 Tipos de data warehouse

Os tipos mais comuns de data warehouses so o relacional e o multidimensional.

Antes de ir aos detalhes tcnicos importante ressaltar uma caracterstica importante. O

desenvolvedor da soluo deve estar apto a dar o suporte a aquele tipo de banco, pois se o

desenvolvedor do data warehouse no conhecer os recursos da tecnologia, no conseguir

oferecer suporte e corrigir eventuais bugs, no importa se a tecnologia tem um desempenho

melhor em algum aspecto, o recurso estar limitado ao que o desenvolvedor pode oferecer.

Alm disso, deve ser considerado as ferramentas que devero ser utilizadas(no

desenvolvimento e implantao do sistema), pois essas podem contribuir com uma grande

parte dos custos do projeto.

Bancos relacionais so amplamente utilizados no mercado e utilizados na maioria das

metodologias clssicas,apresenta vantagens como: suporte a uma grande quantidade de dados,

uma tecnologia consolidada e capaz de suportar atualizaes de vrios processos, porm no

pode ser puramente utilizada para acesso de dados (INMON, 2002).

Bancos multidimensionais so muito discutidos no contexto de data warehouse, pois

provem uma estrutura muito flexvel de acesso aos dados, operaes de slice e dice, para

explorar relaes dinmicas entre dados resumidos e detalhados, oferecendo flexibilidade e

controle ao usurio final (INMON, 2002).

Diferenas entre um banco relacional e multidimensional, so diversas, como:

O banco relacional armazena pelo menos uma ordem de magnitude de dados a mais

que o multidimensional

O banco relacional tem um nmero limitado de flexibilidade de acesso, j o

multidimensional modelado para acessos mais imprevisveis.

21

O banco relacional tem um tempo de armazenamento que vai de 5 a 10 anos, j o

multidimensional armazena bem menos que isso.

Os bancos multidimensionais e relacionais podem ser complementados de maneira

onde o banco relacional seja o banco de longo prazo e vire a fonte de dados de curto prazo

para o banco multidimensional (INMON, 2002).

3.10 ETL

O processo de ETL um componente essencial para a criao de um data warehouse.

Esse processo se baseia na leitura dos dados, transformado-os a partir de regras e padres,

alm de inseri-los em uma base (TURBAN et al., 2009).

O processo se inicia com a extrao de dados, a extrao significa a leitura e

entendimento dos dados que sero utilizados pela ferramenta de ETL. Aps a extrao, ocorre

a manipulao dos dados, que inclui, retirar dados duplicados, limpar dados incorretos, definir

alguns valores padro, resolver erros de ortografia e formatao, dentre outros aspectos. Com

essa manipulao, o processo de ETL adiciona valor aos dados coletados, modificando-os e

melhorando-os. A parte final do processo carregar os dados dentro do modelo dimensional.

Se o processo de ETL atualizado, indexado e possui dados agregados de maneira correta, o

resultado final um data warehouse de qualidade (KIMBALL; ROSS, 2013).

22

4 Implementao

O primeiro passo para o desenvolvimento de qualquer sistema analisar as

necessidades que a soluo deve obter, para isso, temos o processo chamado de levantamento

de requisitos, na qual so analisadas quais as funcionalidades que o sistema final deve

implementar.

4.1 Levantamento de requisitos

Uma das partes mais complicadas desse projeto foi a anlise de requisitos. Essa parte

deve extrair as informaes necessrias para montar uma soluo vivel. A falta de

experincia profissional e a subjetividade da soluo levaram a dificuldades na extrao das

informaes necessrias, culminando em diversas tentativas de entrevistas, onde muitos tipos

de informaes foram coletadas de maneiras diferentes, como alguns diagramas e tabelas que

acabaram no sendo utilizadas no prottipo. Outra dificuldade foi a tentativa de desenvolver

uma soluo com conceitos administrativos um pouco mais avanados, para usurios sem o

conhecimento tcnico suficiente na utilizao da soluo. Diversas mudanas foram feitas no

escopo do projeto at alcanar um prottipo vivel, para auxiliar no processo decisrio e

apresentar uma interface amigvel para a utilizao do usurio final.

Para chegar nos requisitos, deve-se levantar algumas informaes sobre os usurios da

soluo. Os pontos mais importantes que foram considerados so:

Entender as responsabilidades no emprego, metas e objetivos.

Determinar as decises que sero melhoradas a partir da soluo gerada.

Identificar os usurios que tomam decises de grande impacto em reas

especificas(KIMBALL; ROSS, 2013).

Para a delimitao do projeto foram explorados os problemas e compra e venda de

mercadorias. Por se tratar de uma empresa de pequeno porte, as decises so tomadas por

poucas pessoas, e trs pessoas so responsveis pela parte de compras e vendas.

Seguindo esses trs pontos chaves, algumas informaes foram abstradas. A partir de

entrevistas foi identificado algumas dificuldades em informaes sobre venda e compra de

mercadorias. A gerao de relatrios com mltiplos filtros no podia ser realizada, deixando

de gerar algumas informaes especficas aos usurios, como lucro de um tipo de produto de

23

uma marca. No continha tipos de relatrios que apontavam perfis de venda por vendedor ou

cidade. A visualizao de dados atravs de nmeros, mesmo que agrupados, no apresentava

um dado de forma clara.

4.2 Delimitao do prottipo

O prottipo do sistema se delimitou a fazer uma demonstrao grfica de um relatrio

de vendas, com alguns filtros, que dariam maior flexibilidade ao usurio na obteno da

informao, alm da facilidade no seu entendimento. Apesar do relatrio utilizado ser apenas

um relatrio de vendas, as informaes geradas por ele so suficientes para definir o

desempenho de vendedores, entender a localizao do publico da empresa, alm de ajudar a

definir o mix de produto, pois a atividade que gera renda de uma empresa varejista a venda

de produtos.

4.3 Tecnologias do sistema

O sistema foi feito utilizando um banco de dados relacional do pacote Microsoft SQL

Server, que acessado em uma interface web, montada em Javascript, com acesso ao banco

feito em PHP. A utilizao do SQL Server para o banco foi feita, devido a empresa em

questo trabalhar com uma soluo em SQL Server em sua soluo transacional, alm de

contar com uma ferramenta de integrao chamada de SSIS (SQL Server Integration System),

que facilitou na transio de dados entre o banco transacional e o analtico. A utilizao da

programao web foi feita pela facilidade de acesso aos dados de qualquer dispositivo que

tenha acesso ao servidor de dados via navegador, que engloba diversos dispositivos mobile e

pode ser acessado via internet, caso a empresa se interesse em hospedar o servidor analtico.

As linguagens PHP e Javascript foram escolhidas por serem linguagens extremamente

difundidas e pelo conhecimento prvio sobre elas.

4.4 Fonte de dados

Aps definir as tecnologias a serem utilizadas foram analisados os dados disponveis

para a implementao da soluo. Apesar de vrias solues de BI utilizarem dados

descentralizados, realizando a integrao no data warehouse, o caso foi diferente por dois

motivos. Primeiro, se tratando de um prottipo de uma soluo que tem um escopo limitado, a

quantidade de dados no to diversificada, e segundo, a empresa onde foi implementada a

24

soluo tem como sistema transacional um ERP,o que basicamente junta as informaes

dentro de um mesmo banco de dados.

4.5 Data mart

Data warehouses no podem ser construdos de uma vez s devem ser modelados e

populados, um passo de cada vez. Tentar construir um data warehouse de uma vez, um

convite para o desastre (INMON, 2002). Por esse motivo, o prottipo da soluo se limitou a

um data mart, que apresenta uma viso mais focada dos dados, tentando implementar o maior

nmero de necessidades do cliente.

Um data warehouse deve ser construdo de maneira incremental, e a sua primeira

iterao, deve ser pequeno o suficiente para ser construdo e grande o suficiente para ser

significante.O data warehouse deve ser construdo em pequenas iteraes, com o feedback

contnuo entre o desenvolvedor e o analista de decises da empresa. dito que a iterao

inicial tem cerca de 50 por cento de acerto (INMON, 2002). Assim, um desenvolvimento

muito complexo seria desperdiado, lembrando que neste trabalho uma demonstrao dos

dados tambm foi implementada, o que aumentaria o tempo de construo e o feedback de

uma soluo maior.

4.6 Granularidade

A granularidade o ponto essencial para a montagem do data warehouse, pois ela

define quais informaes sero guardadas e posteriormente acessadas no banco analtico, ou

seja, defini quais informaes podero ser construdas a partir dos dados que podem ser

acessados, alm do tamanho total do banco,do processamento e do tempo necessrio para o

processo de ETL.

Os dados selecionados devem conter o maior valor prtico dentro da organizao,

observando as possveis fontes disponveis (KIMBALL; ROSS, 2013).

Na soluo implementada foi utilizada uma tabela de fatos, ligada a quatro tabelas de

dimenso, alm de uma tabela temporria que auxilia no processo de coleta de dados do

banco transacional.Foram escolhidos alguns atributos que seriam utilizados como filtros, os

atributos descritivos das tabelas de dimenso e os atributos de mensurao que ficam na

tabela de fatos, como apresentado na figura 1.

25

4.7 ETL

Aps a modelagem do data mart precisa-se popul-lo a partir dos dados utilizados no

banco transacional, utilizando a ferramenta de integrao de dados do pacote Microsoft SQL

Server, denominado SSIS. O modelo utilizado na extrao dos dados para as tabelas de

dimenses e para uma tabela temporria, no banco de anlise, se faz atravs do cruzamento

das chaves das dimenses populando a tabela de fatos. A ferramenta, contm dois fluxos

principais, um fluxo de controle, que contm a ordem de execuo do processo geral de ETL

mostrado na figura 2 e o fluxo de dados, onde ocorre a migrao de dados, demonstrado nas

figuras 3 e 4

Figura 1. Data mart

Figura 2. Fluxo de controle

Figura 3.Fluxo geral de dados

26

4.8 Visualizao dos dados

Uma soluo de BI que contm dados bem definidos, limpos e concisos, no atinge a

sua meta, se os dados no forem apresentados ao usurio final. A questo de visua

dados to importante quanto os dados em si, pois no adianta ter uma boa mensagem se ela

no for passada com sucesso.

As interfaces de usurio devem ser feitas de maneira simples e levando em

considerao o perfil cognitivo do usurio

Para essa soluo que necessitava de uma visualizao e pesquisa simples dos dados,

foi proposto uma interface de tela nica, que delimitava os filtros possveis para pesquisa. Os

filtros so apresentados em caixas de texto

"Data Incio" e "Data Fim", demonstrados na figura 5, e os filtros opcionais: "Marca","Tipo

de Produto", "Cidade" e "Vendedor", alm do

desejada. Aps o clique no b

correspondentes as selecionadas, essa interface demonstrada nas figuras 5 e 6.

Figura 4. Fluxo de dados da tabela de fatos

Visualizao dos dados


sua meta, se os dados no forem apresentados ao usurio final. A questo de visua


no for passada com sucesso.


considerao o perfil cognitivo do usurio (KIMBALL; ROSS, 2013).



filtros so apresentados em caixas de textos, contendo alguns obrigatrios como: "Operao" ,


de Produto", "Cidade" e "Vendedor", alm do radio button para colocar a visualizao

desejada. Aps o clique no boto OK, um grfico de pizza gerado com as informaes


27

Figura 4. Fluxo de dados da tabela de fatos


sua meta, se os dados no forem apresentados ao usurio final. A questo de visualizao dos





s, contendo alguns obrigatrios como: "Operao" ,


para colocar a visualizao

oto OK, um grfico de pizza gerado com as informaes


28

Figura 5: Visualizao dos dados 1.

Figura 6: Visualizao dos dados 2.

4.9 Aplicao cliente

A parte cliente da aplicao feita em Javascript e HTML (HyperText Markup

Language), onde o Javascript cria objetos XML (eXtensible Markup Language) para se

comunicar via GET com o PHP e obter respostas nesse formato. Os objetos XML, ento so

29

formatados e passados como parmetro para a biblioteca grfica do Google Charts (tambm

em Javascript), e o retorno da biblioteca um grfico exibido em AJAX

(Asynchronous Javascript and XML) para o usurio.

4.10 Aplicao servidor

A parte servidor da aplicao feita em PHP com Microsoft SQL Server, onde o PHP

recebe uma requisio em GET do cliente, com os parmetros para a pesquisa no banco.Aps

observar os parmetros passados, o PHP manda a query apropriada ao banco, e ao receber a

resposta, converte-a em XML e a devolve ao cliente.

30

5 Concluso e resultados

A implementao deste trabalho apresentou uma possvel implementao desse tipo de

soluo para empresas de pequeno porte, com a apario de alguns problemas que no

costumam ser abordados em literaturas clssicas.

5.1 Literatura

Normalmente as literaturas tradicionais tratam de solues para empresas grandes,

com times com conhecimentos tcnicos elevado, o que nem sempre o caso em solues

menores. Outro destaque que boa parte do material voltada para profissionais da rea,

utilizando uma abordagem mais prtica e menos conceitual.

5.2 Coleta de requisitos

A coleta de requisitos em empresas sem um conhecimento tcnico uma tarefa

complicada, pois deve-se propor uma soluo que melhor se encaixa para a situao,

descartando alguns conceitos que geralmente so implementados para auxiliar no processo

cognitivo do usurio em relao as informaes. Outra dificuldade nesse ponto foi a falta de

experincia profissional, que dificultou limitar um bom esquema na coleta de dados

necessrios para a soluo.

5.3 Soluo

O foco da construo da soluo foi uma implementao que demonstrasse de maneira

simples e clara as informaes que o usurio desejasse, sendo esta, atingido com algumas

delimitaes oferecidas pelo prottipo. Os dados mais importantes foram extrados e

apresentados de maneira facilmente interpretvel pelo usurio.

5.4 Restries

Algumas restries foram implementadas, como o uso do pacote Microsoft SQL

Server, que j era utilizada pela empresa, o no gasto com equipamentos de infraestrutura,

alm das definies de tempo do projeto, o que levou a uma delimitao do escopo e de

conceitos tcnicos de implementao.

31

5.5 Trabalhos futuros

Existem vrios caminhos a se abordar em trabalhos futuros, mas o mapeamento da

empresa gerando um data warehouse completo em todas reas definitivamente o caminho

que abre mais solues, pois abrange todas as possveis fontes de dados que podem ser

utilizadas para diversas outras solues, como data mining, OLAP(OnLine Analytical

Processing), dentre outras solues em BI.

32

Referncias

BRASIL. Lei Complementar n 123, de 14 de dezembro de 2006. Disponvel

em:. Acesso em 17 dez. 2014.

CHIAVENATO Idalberto. Administrao: teoria processo e prtica. 4a Ed. Rio de Janeiro:

Elsevier,2 reimpresso,2011.

GOLDRATT, Eliayhu M. A sndrome do palheiro: garimpando informaes em um

oceano de dados. 2a Ed. So Paulo: Educator, 1991.

IMHOFF, C.; GALEMMO, N.; JONATHAN, G. G. Mastering Data Warehouse Design. Indianapolis, Indiana: Wiley Publishing, Inc, 2003. p. 457

INMON, W. H. Buiding the Data Warehouse. 3. ed. [s.l.] John Wiley & Sons, Inc., 2002. p. 428

KIMBALL, R.; ROSS, M. The Data Warehouse Tollkit. 3. ed. Indianapolis, Indiana: John Wiley & Sons, Inc., 2013. p. 601

LIATUTAUD, B.; HAMMOND, M. Inteligncia em e-business: transformando informaes em conhecimento, e conhecimento em lucro. Traduo ed. [s.l.] Qualitymark Editora Ltda., 2002. p. 384

RUMMER, Geary A, BRACHE, Alan P. Melhores desempenhos das empresas: uma abordagem prtica para transformar as organizaes atravs da reengenharia.So Paulo: Makron Books, 1994.

SCHUCH, C. Tomada de deciso gerencial Um comparativo entre teoria e prticaPorto Alegre, 2001.

SIMON, A. R.; HAMMERGREN, T. C. Data Warehousing for Dummies. 2. ed. Indianapolis, Indiana: Wiley Publishing, Inc, 2009. p. 388

TURBAN, E. et al. Business Intelligence: um enfoque gerencial para a inteligncia do negcio. Traduo ed. [s.l.] Artmed Editora S.A., 2009. p. 253

RESUMOABSTRACTSUMRIORESUMO3ABSTRACT4SUMRIO5LISTA DE FIGURAS7LISTA DE SIGLAS E ABREVIATURAS81INTRODUO91.1OBJETIVOS101.1.1Objetivo geral101.1.2Objetivos especficos101.2JUSTIFICATIVA111.3METODOLOGIA111.4ESTRUTURA DO TRABALHO112BI122.1CONTEXTO HISTRICO:123DATA WAREHOUSE143.1DATA WAREHOUSE NO CONTEXTO DE BI143.2CARACTERSTICAS DO DATA WAREHOUSE153.3ABORDAGEM163.4DATA MART X DATA WAREHOUSE173.5BANCO TRANSACIONAL X DATA WAREHOUSE173.6MODELO DIMENSIONAL183.7CUSTOS DO DATA WAREHOUSE193.8GRANULARIDADE193.9TIPOS DE DATAWAREHOUSE203.10ETL214IMPLEMENTAO224.1LEVANTAMENTO DE REQUISITOS224.2DELIMITAO DO PROTTIPO234.3TECNOLOGIAS DO SISTEMA234.4FONTE DE DADOS244.5DATA MART244.6GRANULARIDADE244.7ETL254.8VISUALIZAO DE DADOS274.9APLICAO CLIENTE294.10APLICAO SERVIDOR295CONCLUSO E RESULTADOS305.1LITERATURA305.2COLETA DE REQUISITOS305.3SOLUO305.4RESTRIES305.5TRABALHOS FUTUROS31 LISTA DE FIGURAS LISTA DE SIGLAS E ABREVIATURAS 1 Introduo1.1 Objetivos 1.1.1 Objetivo geral1.1.2 Objetivos especficos

1.2 Justificativa1.3 Metodologia1.4 Estrutura do Trabalho

2 BI2.1 Contexto histrico:

3 Data warehouse3.1 Data warehouse no contexto de BI3.2 Caractersticas do data warehouse3.3 Abordagem3.4 Data Mart x Data Warehouse3.5 Banco Transacional X Data Warehouse3.6 Modelo dimensional3.7 Custos do data warehouse3.8 Granularidade3.9 Tipos de data warehouse 3.10 ETL

4 Implementao4.1 Levantamento de requisitos4.2 Delimitao do prottipo4.3 Tecnologias do sistema4.4 Fonte de dados4.5 Data mart4.6 Granularidade4.7 ETL4.8 Visualizao dos dados4.9 Aplicao cliente4.10 Aplicao servidor

5 Concluso e resultados5.1 Literatura5.2 Coleta de requisitos5.3 Soluo5.4 Restries5.5 Trabalhos futuros

Referncias

solução de b.i. para empresas de pequeno porte

Documents