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
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 (KIMBALL; ROSS, 2013).
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 textos, contendo alguns obrigatrios como: "Operao" ,
"Data Incio" e "Data Fim", demonstrados na figura 5, e os filtros opcionais: "Marca","Tipo
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
correspondentes as selecionadas, essa interface demonstrada nas figuras 5 e 6.
27
Figura 4. Fluxo de dados da tabela de fatos
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 visualizao dos
dados to importante quanto os dados em si, pois no adianta ter uma boa mensagem se ela
As interfaces de usurio devem ser feitas de maneira simples e levando em
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
s, contendo alguns obrigatrios como: "Operao" ,
"Data Incio" e "Data Fim", demonstrados na figura 5, e os filtros opcionais: "Marca","Tipo
para colocar a visualizao
oto OK, um grfico de pizza gerado com as informaes
correspondentes as selecionadas, essa interface demonstrada nas figuras 5 e 6.
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