Definição de um processo para criação de Business Intelligence
em médias empresas
Vinicius de Souza Nunes, Hélio Rubens Soares
Instituto de Informática – Centro Universitário do Triângulo (UNITRI) Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil viniciuscomputacao@yahoo.com.br, hrubens@unitri.com.br
Resumo. Business Intelligence (BI) é um processo de análise de diferentes bases de dados com o objetivo de oferecer suporte nas atividades de uma empresa para que os gestores extraiam informações para tomada de decisão. O objetivo deste artigo é descrever a tecnologia utilizada para desenvolvimento de BI demonstrando os seus conceitos, bem como as suas etapas aplicadas a um processo de ensino. Visando uma melhor apresentação dos conceitos será realizado um estudo de caso baseado em dados reais e a escolha de uma ferramenta open source.
1. Introdução
Muito se fala hoje em BI (Business Intelligence) no mundo dos negócios, cuja proposta é transformar dados em informações concretas com o objetivo de fornecer um melhor apoio para tomada de decisões em tempo ágil e de forma mais precisa.
É indispensável o uso da tecnologia neste processo e, para que isso seja implementado, são utilizadas ferramentas de alto desempenho que por sua vez possuem custos elevados para as empresas não sendo possível na maioria das vezes mensurar o retorno do alto investimento. As primeiras ferramentas de BI surgiram na década de 70 com o uso em programação linear, o que elevava ainda mais os custos do projeto [PRIMARK - 2008].
Com o surgimento dos bancos de dados relacionais, de computadores cada vez robustos, interfaces amigáveis e o conceito de cliente-servidor, várias ferramentas amigáveis foram desenvolvidas proporcionando um mercado competitivo com diversos produtos de alta qualidade [PRIMARK - 2008].
Com o mercado altamente dinâmico, competitivo e com a grande massa de dados espalhada em diversos arquivos as empresas necessitam de resposta imediata para se tornarem mais competitivas. Com esta demanda o mercado de software de BI cresceu 13.100 milhões de dólares no ano de 2013 [JORGE UTIMI - 2014].
As próximas partes do trabalho estão definidas da seguinte forma: a seção 2 apresenta os conceitos de BI bem como suas fases; a 3 analisa o processo para o desenvolvimento de um projeto de BI; a 4 demonstra o estudo de caso - baseado no processo proposto na seção 3; a 5 apresenta a conclusão do artigo e a 6 apresenta as referências bibliográficas utilizadas para o embasamento teórico deste artigo.
2. Fundamentação Teórica
A fundamentação teórica demonstra os conceitos de BI analisando cada fase juntamente com comparação de algumas ferramentas existentes no mercado.
2.1. Business Intelligence
O termo Business Intelligence (BI) ou Inteligência de Negócio surgiu na década de 80 desenvolvido por Gartner Group (consultoria de pesquisa de mercado na área de tecnologia da informação) sendo uma combinação de tecnologia que possui o propósito de realizar coleta de dados, estruturação, análise e indicadores que fornecem suporte para tomada de decisão [PRIMARK 2008].
Antes de surgir o conceito de BI, as tomadas de decisões eram baseadas em intuições não obtendo uma precisão necessária. O que as empresas necessitam são de dados gerenciáveis, dinâmicos e acessíveis.
As informações estão sendo modificadas a todo o momento e cada vez um grande volume de dados está sendo armazenado em arquivos ou bases de dados diferentes cada vez mais robustos. Assim, as empresas buscam soluções em ferramentas para se tornarem competitivas no mercado e apoiar suas decisões. BI é considerado 10% de apresentação e 90% de Integração [BARBIERI 2011].
Comercialmente falando, o BI possui objetivos de proporcionar lucro para a empresa, aumentar a carteira de clientes, propor uma melhor satisfação, fidelização e busca ainda maximizar o lucro.
2.2. Data Mart
O Data Mart é conhecido como armazém de dados, porém trabalha com volume de dados de menor proporção. Utilizado para guardar e unificar dados relativos de um departamento da empresa possui modelo dimensional, facilitando a geração de relatórios oferecendo suporte para tomada de decisão [FELIPE NERY - 2013].
Os dados desnormalizados e indexados da Data Warehouse (depósito de dados digitais) que sofrem intensa pesquisa são extraídos para o Data Mart em porções de pequenos grupos gerando um melhor desempenho em trabalhar com essas informações. Existem duas características no surgimento de um Data Mart [Felipe Nery - 2013].
1. Top-down: Quando se divide o Data Warehouse em áreas menores, gerando
pequenos bancos divididos por assunto;
2. Botton-up: Ocorre o inverso em relação ao Top-down, é criada uma base de
dados para somente um setor gerando um custo inferior de um projeto de DW completo;
2.3. Data Warehouses
Com o avanço da tecnologia da informação e a utilização de sistemas coorporativos não integrados que utilizam de banco de dados diferentes para armazenamento cada vez mais robustos, fica inviável e de difícil acesso a análise desses dados para tomada de decisão.
Os armazenamentos dos dados pelas empresas estão nos sistemas chamados OLTP (On-Line Transactional Processing), sendo aplicações que controlam o operacional da empresa como processo de vendas, emissão de nota fiscal, folha de pagamento, etc. Em 80% dos casos os dados estão armazenados de forma inadequada e isso impossibilita a realização de uma análise posteriormente ou ainda a obtenção de históricos há mais de seis meses [ROLAND BOUMAN - 2005].
Para a solução dos problemas enfrentados nas empresas, criou-se o DW nascido na década de 80, cujo mentor foi William Inmon, que concernia em uma base de dados com capacidade de armazenar dados históricos e organizados, de tal forma que possibilita utilizá-los para tomada de decisão e abastecer os Data Marts. Para realização de um projeto de Business Intelligence o Data WareHouse é fundamental [FELIPE NERY 2013].
A arquitetura do Data Warehouse é demonstrada na Figura 1 apresentando de forma sucinta uma carga de dados de vários sistemas externos.
Figura 1 . Entrada de Dados no Data Warehouse [Felipe Nery 2013]
2.4 Arquiteturas do Data Warehouses
Com sua arquitetura complexa, o Data Warehouse possui o objetivo de oferecer acesso para análise de grande volume de dados complexos, não oferece suporte necessário como em bancos de dados transacionais que inclui inserção, atualização e exclusão.
O modelo de trabalho de um DW possui algumas características que são consideradas importantes, segue [KIMBAL E CASERTA - 2004]:
Orientado ao Assunto - Modelagem orientada pelos assuntos importantes. Integrado - Padronizar os dados.
Não volátil – Operação de consulta e inserção. Variante no tempo – Histórico no tempo.
2.4.1 Arquitetura Funcional
Sua arquitetura funcional divide-se em duas grandes áreas que basicamente são: interna e externa, conforme pode-se verificar na figura 2.
Figura 2. Arquitetura Funcional do DW [Barbieri 2001]
2.5. ETL (Extract Transform Load)
ETL trabalha com filtro de informações de várias fontes externas atendendo a necessidade do negócio e oferecendo carga de dados para o Data Warehouse. O processo de ETL consiste em uma das etapas mais críticas e demoradas na construção do DW.
O processo de ETL é muito importante e deve ser trabalhado de forma minuciosa durante a extração das informações, visto que com a utilização deste os dados serão analisados para tomada de decisões e um processo errado realizado pode afetar diretamente nos negócios da empresa. Somente este processo ocupa 60% de horas no desenvolvimento de um DW e dedicação de uma equipe especializada [BARBIERI 2011].
A imagem da figura 3, apresenta um exemplo clássico de utilização do ETL.
Figura 3. Arquitetura do ETL [Devmedia 2013]
2.6. OLAP (On-Line Analytic processing)
O OLAP é um conjunto de técnicas para análise dinâmica e multidimensional que permite uma visualização dos dados de forma rápida, consistente e interativa, oferecendo apoio aos usuários finais em suas atividades [PRIMARK 2008].
O desenvolvimento na forma de tabelas cruzadas em diferentes dimensões permite uma resposta rápida e precisa ao usuário, que por sua vez pode realizar outros questionamentos obtendo o porquê dos resultados obtidos.
ROLAP (Relational On Line Analytical Processing) - Todo o processo de consulta do banco de dados relacional é feito no servidor, mantendo o cubo no seu servidor. MOLAP (Multidimensional On Line Analytical Processing) - Processo realizado em
um servidor multidimensional.
HOLAP (Hybrid On Line Analytical Processing) – Combinação de ROLAP com MOLAP.
A figura 4 ilustra uma representação de um cubo e suas dimensões de produto, região e mês.
Figura 4. Cubo OLAP [Viviane Ribeiro 2014]
2.7. Ferramentas de Business Intelligence
Devido ao crescimento e a demanda dos projetos de BI o mercado oferece algumas opções de ferramentas, desde soluções com alto custo até aplicações Open Source. Para melhor exemplificação disto, propõe-se a seguir um comparativo demonstrando algumas das ferramentas mais conhecidas.
Hyperion: Foi definida como a divisão de negócio da Oracle em sua aquisição
no ano de 2007 complementando os produtos existentes no mercado para atender a demanda de BI, formando-se o pacote chamado de Oracle Business Intelligence Enterprise Edition Plus. Trabalha-se aqui como conceito de OLAP com banco de dados relacional (Data Warehouse) utilizando o Integration Services Essbase (ETL) [ORACLE 2014].
Cognos: Foi adquirido pela IBM no valor de cinco milhões de dólares em 2011,
integrou-se com as demais ferramentas da empresa e formou um pacote de ferramentas completo para desenvolvimento de um projeto de BI. Com o seu servidor OLAP Cognos Power Play permite a criação de relatórios com bases multidimensionais [IBM 2014].
Das diversas funcionalidades existentes a que mais se destaca é a de disponibilizar relatórios pré-construídos e a integração já com conexões prontas para sistemas de ERP [IBM 2014].
QlikView: Desenvolvido pela QlikTech e comercializado pela Toccato no Brasil a
plataforma possui como diferencial o recurso associativo em memória, disponibilidade de interface para usuários acessar via telefone móvel e tecnologia point-and-click (apontar e clicar) [TOCCATO 2014].
SAP/Business Objects: Solução comercializada pela empresa SAP (Sistema,
Aplicativos e Produtos) constituída por inúmeras ferramentas separadas baseadas em tecnologias diferentes que prometem a integração no desenvolvimento de um projeto de BI. Possui integração com outros aplicativos de terceiros cujos módulos podem ser adquiridos separadamente [SAP 2014].
Pentaho: Desenvolvido pela Pentaho Inc. utilizando a linguagem JAVA. É uma
plataforma Open Source que possui várias suítes que formam um conjunto de aplicativos que são responsáveis pela execução de projetos de BI, promovendo controle de processos, visualização e segurança [PENTAHO 2014].
Além da versão Open Source a Pentaho Inc. comercializa um pacote de serviços que inclui suporte técnico com tempo de SLA (Service Level Agreement), disponibilização de correções, novas versões e algumas funcionalidades avançadas [PENTAHO DAY 2014].
As figuras 4 e 5 apresentam, na forma de gráfico, pesquisas realizadas demonstrando buscas feitas por palavras-chave referentes às ferramentas de BI descritas.
A figura 5 demostra uma pesquisa feita mundialmente que aponta para o crescimento da ferramenta Pentaho e o declínio dos demais concorrentes.
Figura 5. Gráfico de pesquisa realizado no Mundo [Google Trend]
A figura 6 apresenta uma pesquisa realizada no Brasil, demonstrando que à ferramenta Pentaho vem crescendo a cada ano.
Figura 6. Gráfico de pesquisa realizada no Brasil [Google Trend]
2.8. Trabalhos Correlatos
Nesta subseção serão apresentados alguns trabalhos com foco em BI.
Desta forma, serão citados os projetos com os seguintes temas: “Uma Solução de Business Intelligence com foco em Gerência de Projeto” e “Resultados de Business Intelligence nos indicadores de uma Telecom”.
A proposta de uma Solução de Business Intelligence com Foco em Gerência de Projeto consiste em demonstrar os conceitos básicos aplicados na gerência de projeto passando por todos os seus processos e aprofundando-se no PMBOK (Project Management Body of Knowledge).
Em sua conclusão foi apresentado um estudo de caso de uma empresa que desenvolve sistemas para gestão que buscou o diferencial em trabalhar com gerência de projeto e uma proposta futura de oferecer soluções de BI para os seus clientes.
O artigo que propõe Resultados de Business Intelligence nos Indicadores de uma Telecom apresenta os conceitos básico de BI com foco na montagem dos dashboards (apresentação visual das informações) interativos com o usuário final.
O autor apresenta alguns pontos levantados em relação às principais vantagens em implementar um projeto de BI, as fragilidades existentes, bem como os desafios propostos.
Para finalizar o estudo de caso escolhido de uma grande empresa foi realizado um levantamento muito complexo de todos os seus produtos, os projetos em andamento, evolução da telefonia no mercado e finalizando com os resultados de indicadores para os tomadores de decisões.
A seção 3 apresenta o processo proposto.
3. Processo
A seção 3 propõe um processo que consiste em demonstrar os passos (fases) para elaboração de um projeto de BI: (i) planejamento, (ii) avaliação dos BD de origem, (iii) adequação do BD de origem, (iv) definição de uma ferramenta ETL, (v) análise de volumetria, (vii) definição de ferramenta, (viii) definição do BD de destino.
3.1. Planejamento
A etapa de planejamento consiste em levantar os pontos e etapas do desenvolvimento do projeto levando em consideração o foco do negócio e atentando-se para as áreas mais críticas.
3.2. Avaliação dos BD (Bancos de Dados) de Origem
O processo de avaliação do BD de origem é definido com base nos indicadores citados no item 3.1, sendo necessário realizar uma análise dos bancos de dados das aplicações utilizadas tais como realizar um estudo com os gestores para identificar que dados serão interessantes para serem tratados no BI.
Outro processo muito importante a ser avaliado é verificar a consistência das informações armazenadas e se as bases de dados são relacionais ou não com o objetivo de avaliar se o BI conseguiria realizar todos os processos previstos, evitando problemas futuros.
Nesta atividade serão realizadas entrevistas com o DBA (Desenvolvedor de Banco de Dados) discutindo a utilização das tabelas e dos campos disponíveis no BD bem como verificar a existência de um dicionário de dados para facilitar os trabalhos futuros.
3.3. Adequação do BD (Banco de Dados) de Origem
A adequação do BD de origem consiste em realizar algumas transformações ou correções antes do processo de carga das informações no Data Warehouse. Seguem abaixo os passos propostos.
Padronizar os dados (tamanho e tipo).
Substituição de caracteres estranhos e correções de digitação. Correções de duplicidade de registros – Excluir registro duplicado.
Tratar informações de codificação de valores (H=Homem ou M=Mulher). Correções de valores nulos.
3.4. Definição de uma ferramenta ETL (Extract Transform Load)
A definição de uma ferramenta para ETL consiste em uma etapa muito importante no projeto que deve ser analisada com cautela, pois os processos realizados por ela são tão complexos que interferem diretamente nas próximas etapas.
Alguns aspectos devem ser avaliados durante a escolha da ferramenta, pois no mercado existem diversas opções com características semelhantes e tecnologias diferentes.
Por se tratar de uma aplicação que se deve comunicar com vários bancos de dados é importante oferecer suporte às múltiplas plataformas, ser compatível com os principais sistemas operacionais (Windows e Linux) bem como suportar o processo de grande volume de dados e equilíbrio com os servidores.
3.5. Análise de Volumetria
Prática que deve ser adotada no início do desenvolvimento de um projeto evitando problemas futuros e que tem uma eficiência muito importante que na maioria das vezes é ignorada.
Com o avanço da tecnologia e a grande dependência dos sistemas de gestão o volume de dados vem aumentando massivamente, sendo necessário sua disponibilidade por um longo período de tempo.
Com a utilização da análise de volumetria é possível prevenir grandes problemas futuros, economizar dinheiro, propor soluções como servidores de bancos de dados adequados, planos de backup, tráfego da rede bem como qual é a melhor solução de banco de dados. O levantamento da volumetria pode ser questionado junto ao cliente e realizado um cálculo levando em consideração os tipos de dados em cada tabela.
Usando de volumetria pode-se manipular valores de uma coluna específica, incluir arquivos de índices em cálculos de banco de dados, modificar parâmetros que está afetando o cálculo com alteração de bytes por caractere e ajustar a quantidade de sobrecarga de espaço por linha.
A definição de uma ferramenta em um projeto de business intelligence consiste em analisar que tipo de informações os gestores necessitam, as ferramentas já existentes, sua estrutura tecnológica e os recursos financeiros disponíveis para o projeto.
Para escolha de uma ferramenta de BI se faz importante avaliar a facilidade de uso, a qualidade de atendimento quando se faz necessário o uso de suporte técnico ou de consultoria, o fornecimento da segurança nos resultados a serem obtidos, o alto desempenho e a disponibilidade para um grande volume de dados.
3.7. Definição do banco de dados de destino
Sendo um dos principais pilares do BI o BD de destino deve ser projetado levando em consideração alguns fatores importantes, pois o mesmo será feito para receber grande volume de dados de várias fontes diferentes alinhados com a estrutura da empresa e de acordo com o levantamento realizado junto aos tomadores de decisões sobre quais informações serão necessárias para o projeto.
Um grande erro comum na construção e definição do banco de dados de destino é começar o trabalho pela escolha das ferramentas de front end que deve ser definida depois de realizado o escopo do projeto.
O fundamental é entender que os dados precisam ser estruturados de forma diferente do que ocorre nos sistemas transacionais, pois este trabalhará somente com carga de dados e consulta não sofrendo atualizações de dados permitindo uma análise histórica.
A seção 4 demonstra o estudo de caso baseado no processo proposto na seção 3.
4. Estudo de Caso
O estudo de caso foi realizado junto a empresa de médio porte Marlene Noivas com um faturamento anual de R$ 2.635.000,00 que possui mais de 10 anos de mercado na cidade de Uberlândia atuando no segmento de aluguel de trajes para casamentos, festas e aniversários de 15 anos.
Devido ao crescimento da empresa juntamente com a demanda de mercado veio a necessidade de informatizar seus processos adquirindo computadores, impressoras e um software de gestão. Essa mudança foi realizada no ano de 2007.
O software adquirido para a gestão, chamado Soft Noiva, vem atendendo parcialmente à demanda da empresa, pois devido às mudanças e evoluções tecnológicas no decorrer dos anos alguns processos foram modificados surgindo a necessidade da realização de estratégicas mais eficientes e tomadas de decisões mais precisas.
O cenário para realização do estudo de caso, foi definido em reuniões junto com o cliente para levantamento dos indicadores necessários para o desenvolvimento do projeto de BI.
4.1. Planejamento
A ferramenta proposta neste artigo foi o Pentaho, tratando-se de uma suíte completa, pois atendia a todas as fases de um projeto de business intelligence e principalmente por ser uma aplicação open source.
A arquitetura definida para construção do DW foi do tipo “Data Warehouse Empresarial” e multidimensional MOLAP utilizando do SGBD MYSQL devido ao fato de ser totalmente open source e compatível com Windows 7, sendo este o recurso disponível na empresa.
Para análise de volumetria a ferramenta utilizada foi o Erwin, tratando-se de um aplicativo para modelagem de DER (Diagrama de Entidade e Relacionamento) com funcionalidades de cálculo para análise de volumetria. Sua escolha foi definida levando em consideração que o DER foi modelado pela ferramenta, além de obter um amplo conhecimento da equipe a seu respeito.
4.2. Avaliação do Banco de Dados de Origem
O banco de dados de origem que será trabalhado neste estudo de caso é o Microsoft Access, sendo o mesmo utilizado no sistema de gestão da empresa de onde os dados serão extraídos.
Em reunião com o desenvolvedor do sistema e análise do banco de dados foi detectado que não existia um DER ou mesmo um dicionário de dados e a base também não estava normalizada, porém o tratamento de inserção de informações foi realizado diretamente no código fonte do sistema obtendo uma certa consistência e integridade. Neste caso, o primeiro passo foi propor em conjunto com ambas as partes o desenho do DER da aplicação para um melhor entendimento e documentação do banco.
ATENDENTES COD_AT DESC_AT DT_ADM RG CPF CNPJ CTPS ENDERECO NRO COMPL BAIRRO CEP DDDRES TELRES DDDCONT TELCONT DDDCEL TELCEL EMAIL SITE DT_CAD VALOR FLAG COD_CARGO (FK) COD_CIVIL (FK) AC_LOC COD_ACLOC OS VALOR DT_CAD DT_LOC DT_DEV ABERTO OBS PREV_DEV COD_AC (FK) ACESSORIOS COD_AC DESC_AC COR VALOR OBS DT_CAD SITUACAO STATUS COD_GRUPO (FK) COD_TAC (FK) COD_COR (FK) CARGOS COD_CARGO DESC_CARGO OBS_CARGO CIDADE COD_CIDADE NOME_CIDADE DDD SIGLA (FK) CLIENTES COD_CLI NOME_CLI DT_NASC CPF RG DT_CAD SEXO EST_CIVIL PROFISSAO ENDERECO NRO COMPL BAIRRO CEP TEL_RES DDD_RES TEL_COM DDD_COM TEL_CEL DDD_CEL EMAIL SITE OBS DIA_NASC MES_NASC ANO_NASC COMISSAO COD_LOC (FK) COMISSAO OS DTCAD FLAG CORES COD_COR DESC_COR OBS_COR EST_CIVIL COD_CIVIL DESC_CIVIL OBS_CIVIL ESTADOS SIGLA NOME AREA EVENTOS COD_EVENTO DESC_EVENTO OBS_EVENTO FORMAPAG COD_FPAG DESC_FPAG QUANT_PARC OBS COD_PARC (FK) GRUPO COD_GRUPO DESC_GRUPO OBS_GRUPO COMISSAO IMAGEM_PRODUTO COD_IMG IMG DESC_IMG PATH_IMG FILE_DESC DT_CAD COD_VEST (FK) LACTION COD_ACT DESC_ACT OBS LANCAMENTOS COD_LAN VALOR DT_PAG DT_CAD COD_LOC (FK) COD_CLI (FK) LOCACAO COD_LOC COD_AT (FK) DT_LOC FLAG STATUS OS VALOR_LOC LOCALE DTCAD SITUACAO OBS COD_EVENTO (FK) COD_CIDADE (FK) COD_CLI (FK) COD_ACLOC (FK) LUSER COD_LOG ACAO DESC_LOG DT_LOG FORM_LOG OS COD_CLI (FK) MOVCX COD_MOV TIPO DESC_MOV DT_MOV VALOR DT_CAD VALOR_SAIDA DED OS CHEQUE OBS FLAG_CAIXA VIS_OS COD_FPAG (FK) COD_TIPO (FK) PAGAMENTOS COD_PARC OS_LOCACAO NRO_PARC TIPO_PARC VAL_PARC FLAG_PAGO COD_CLI (FK) TESTECABELO COD_TESTE OS DT_TESTE STATUS DT_RET DEVOL FLAG_CONTR FLAG_CERT OBS DT_RETIRADA COD_CLI (FK) TESTECABELO_PROD COD_TESTE DT_RET DT_DEVOL DT_CAD STATUS COD_AC (FK) TIPO_AC COD_TAC DESC_TAC TIPO_MOV COD_TIPO DESC_TIPO OBS_TIPO TIPO DED USERS COD_USER NOME_USER DESC_USER SENHA DT_CAD DT_ULT CPF_USER RG_USER DDD_TEL TEL EMAIL OBS P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13 P14 P15 VESTIDOS COD_VEST DESC_VEST DT_CAD TAMAHO OBS COD_GRUPO (FK) COD_COR (FK) LUSER COD_LOG ACAO DESC_LOG DT_LOG FORM_LOG OS COD_USER (FK) COD_ACT (FK)
4.3. Adequação do Banco de Dados de Origem
A adequação dos dados de origem foi feita utilizando a ferramenta PDI (Pentaho Data Integrator) considerando que é uma solução open source que se integra com outras ferramentas e possui várias documentações para auxílio em sua utilização.
Para um melhor desempenho do SGBD (Sistema de Gerenciamento de Banco de Dados) foi proposto uma migração do sistema existente (Access) para uma solução mais robusta e com melhores recursos propondo um melhor gerenciamento. Em reunião junto com o desenvolvedor e o cliente ficou definido uma migração para o SGBD MYSQL levando em consideração uma solução open source. Esta migração de dados foi realizada pela equipe responsável pelo sistema.
A figura 8 representa a tela inicial do PDI com a montagem dos processos a serem executados no banco de dados de produção da empresa.
Figura 8. Tela inicial do processo do PDI
Nesta etapa foram levantadas as tabelas mais importantes para tratamento e extração dos dados criando um data warehouse. As tabelas serão de locação, dados dos clientes e movimentação do caixa que inclui os pagamentos das locações realizadas por um determinado cliente.
Com o PDI é possível realizar uma análise do impacto da transformação no banco de dados visualizando os processos, campos de origem e destino bem como os tipos de dados de cada um.
Neste estudo de caso do processo de ETL alguns campos não utilizados foram excluídos e algumas tratativas de tipos de dados foram redefinidas devido a mudança de SGBD.
Na execução e finalização do processo de ETL foram obtidos os seguintes resultados conforme tabela 2.
4.4. Análise de Volumetria
O cálculo de análise da volumetria do banco de dados da empresa foi realizado levando em consideração as tabelas que estão sendo utilizadas no DW.
Primeiramente foi realizado um levantamento utilizando o DER disponibilizado pelo desenvolvedor da aplicação juntamente com os recursos de volumetria do software ERwin.
Número inicial de registros para a tabela;
Volume máximo permitido de registros que a tabela é projetada para segurar; Número estimado de registros esperados durante o crescimento mensal; Segue na tabela 1 o cálculo de volumetria realizado:
Tabela 1. Resultado do Cálculo Volumetria Nome da Tabela Volume Inicial Volume Máximo Volume Mês Tamanho médio Tamanho Inicial Clientes 187 3000 50 2237 408 Kbytes Locação 55 5000 20 778 41 Kbytes Movcx 374 6000 50 981 358 Kbytes Total 809 Kbytes
Conforme tabela 1 o mensal crescimento da base de dados é de 890 kbytes/mês. Tabela 2. Resultado da Execução PDI
Nome do step Lidos Escritos Entrada Saída Erros Tempo Velocidade
Ler Dados Locação 0 55 55 0 0 0.0s 4.231 Dados Locação 55 55 0 0 0 0.1s 1.078 Ler Dados Clientes 0 187 187 0 0 0.1s 3.339 Dados Clientes 187 187 0 0 0 0.1s 2.877 Saida_Dados Clientes 187 187 0 187 0 2.0s 92
Ler Dados Movcx 0 374 374 0 0 1.4s 258
Dados Movcx 374 374 0 0 0 1.5s 258
Saida Dados Movcx 374 374 0 374 0 2.6s 144 Saida_Dados Locacao 55 55 0 55 0 1.2s 45
4.5. Definição do banco de dados de destino
A definição do banco de dados de destino para onde os dados importantes serão armazenados foi uma das questões mais discutidas junto com o cliente, levando em consideração alguns aspectos básicos descritos:
Suportar o processamento analítico on-line. Consultas otimizadas e complexas.
Custo benefício.
Requisitos de hardware.
Diante das considerações citadas foram levantados os seguintes SGBDS: Oracle, SQL Server, MYSQL. O SGBD definido foi o MYSQL, levando em consideração uma solução open source, os recursos disponíveis de uma máquina com Windows 7 com 2gb de RAM (Random-Access Memory) e o volume de dados existente.
Na figura 9 é demonstrado o DER para geração do DW de destino levando em consideração as tabelas mais importantes que são de cadastro dos clientes, locações feitas e movimentação de caixa. CLIENTES COD_CLI NOME_CLI DT_NASC CPF RG DT_CAD SEXO EST_CIVIL PROFISSAO ENDERECO NRO COMPL BAIRRO CEP TEL_RES DDD_RES TEL_COM DDD_COM TEL_CEL DDD_CEL EMAIL SITE OBS DIA_NASC MES_NASC ANO_NASC LOCACAO COD_LOC DT_LOC FLAG STATUS OS VALOR_LOC LOCALE DTCAD SITUACAO OBS COD_CLI (FK) MOVCX COD_MOV TIPO DESC_MOV DT_MOV VALOR DT_CAD VALOR_SAIDA DED OS CHEQUE OBS FLAG_CAIXA VIS_OS COD_CLI (FK)
Figure 9. DER do data warehouse de destino
4.6. Analise do processo apresentado
Aplicando o processo proposto na seção 3 no estudo de caso da seção 4 os resultados finais propostos foram satisfatórios tanto para a empresa Marlene Noivas quanto para o desenvolvedor da aplicação Soft Noiva.
Alguns problemas e dificuldades foram encontrados, o que mais se destacou foi na etapa de avaliação do banco de dados de origem, em que possível identificar a não existência do DER e propor uma nova solução que foi a documentação do banco.
No método de adequação do banco de dados de origem verificou-se o problema do SGBD existente e foi proposta uma melhor solução para atender a demanda do projeto de BI, com a finalidade de evitar futuros transtornos, tais como o de licença de uso. O ponto negativo disto foi o custo com a migração.
O processo de extração das informações necessárias foi muito importante no ponto de vista dos responsáveis pela empresa devido a possibilidade de criar uma nova base de dados somente com as informações que serão utilizadas posteriormente.
Com a utilização do método de cálculo de volumetria foi possível demonstrar aos tomadores de decisões um volume mensal do crescimento dos dados o que gerou uma grande satisfação pois com o resultado foi possível analisar futuros investimentos em novas tecnologias.
A seção 5 apresenta a conclusão do artigo e futuros trabalhos.
5. Conclusão
Através deste artigo, foram aprendidos os conceitos de Business Intelligence e pôde-se demonstrar na prática a realização de um projeto em empresa de médio porte auxiliando na tomada de decisões e obtendo um diferencial de mercado com a utilização de ferramentas open source.
Com o processo apresentado foi possível atender à demanda do cliente, identificar problemas existentes, propor novas soluções e viabilizar a utilização de um projeto de BI, pois de acordo com responsáveis, o custo foi baixo.
Com a escolha e utilização da suíte do Pentaho foi possível agregar um grande conhecimento e utilizá-las em uma empresa obtendo um resultado satisfatório junto aos responsáveis.
A sugestão para futuros trabalhos seria abordar mais sobre a utilização da ferramenta com foco em mineração de dados, montagem de dashboards (apresentação visual das informações) amigáveis customizados para o usuário final e pulverizar o processo proposto. A seção 6 apresenta as referências do artigo.
6. Referências
BARBIERI, Carlos. Business. (2011) “Intelligence: Modelagem E Qualidade”.,1ª Edição. BOUMAN, Roland e DONGEN, Jo. (2009) “Pentaho Solutions: Business Intelligence and
Data Warehousing with Pentaho and MySQL”.
LOPES, Celedo.
“Businessintelligence” .http://www.businessintelligence.com.br/portal/index.php,
Setembro. Acesso em 21, Setembro 2013.
DATA HAREHOUSE. “Monografia_MBA_180703”. Disponível em:
<http://www.datawarehouse.inf.br/Academicos/Monografia_MBA_180703.pdf, >Acessado em: 13 Setembro. 2013.
INMON, W. H. (1997) “Como construir o data warehouse”.
MACHADO, Felipe. (2013) “Tecnologia e Projeto de Data Warehouse”, 6ª edição.
MONDRIAN. “Mondrian OLAP Server”. Disponível em: <http://mondrian.pentaho.org>. Acesso em: , Agosto de 2010.
MYSQL in Data Warehousing & Business Intelligente. (2012) Disponível em http://www.mysql.com/why-mysql/data-warehouse.html, Acesso em: Fevereiro de 2014. NASCIMENTO, A. M. e REGINATO, Luciane. (2007) “Um estudo de caso envolvendo
business intelligence como instrument de apoio à controladoria”. In: Revista Contabilidade & Finanças, v. 18, p. 69-83.
PENTAHO. “Open Source BI”. Disponível em http://www.pentaho.com/about/, Acesso em : Agosto. de 2010.
PRIMAK, Fábio Vinicius. (2008) “Decisões com B.I. (Business Intelligence)”, 1ª Edição. -2008.
PULVERINI, A. S. e ROLDÁN, M. C. (2011) “Pentaho Data Integration 4 Cookbook”. 1ª Edição.
ROLDÁN, M. C. Pentaho 3.2 Data Integration. 1. ed. Birmingham, UK: Packt Publishing, 2010.
