Monografia Rodrigo Moraes

FACULDADE DOM BOSCO DE PORTO ALEGRE CURSO DE SISTEMAS DE INFORMAO
RODRIGO MORAES
CONSTRUO DE DATA WAREHOUSE EM AMBIENTE HETEROGNEO: UM ESTUDO DE CASO NA REA DE TRANSPORTE DE CARGAS
Porto Alegre Dezembro/2010
RODRIGO MORAES
Trabalho de Concluso do Curso de Sistemas de Informao apresentado como requisito parcial para a obteno do grau de Bacharel em Sistemas de Informao da Faculdade Dom Bosco de Porto Alegre. Orientadora: Adriana Paula Zamin Scherer.
RODRIGO MORAES
Trabalho de Concluso do Curso de Sistemas de Informao apresentado como requisito parcial para a obteno do grau de Bacharel em Sistemas de Informao da Faculdade Dom Bosco de Porto Alegre. Orientadora: Adriana Paula Zamin Scherer.
Aprovado em: __/ __/ ____. BANCA EXAMINADORA _________________________________ Prof Msc Adriana Paula Zamin Scherer _________________________________ Prof Msc Lus Henrique Leal Ries _________________________________ Prof Msc Carlos Akcelrud Cony
Pr todo pecado sempre existe um perdo, no tem certo e nem errado todo mundo tem razo e o ponto de vista que o ponto da questo.
Raul Seixas
RESUMO
Uma grande parcela das empresas acaba adquirindo um nmero variado de ferramentas visando operacionalizar seus processos. Isto se deve, entre outros fatores, s obrigaes impostas pela legislao, aos aspectos geogrficos, e s questes financeiras. Este cenrio agrega certa dificuldade ao diagnstico empresarial, onde cabe aos gestores resumir um grande volume de dados que, muitas vezes, so provenientes de diferentes fontes operacionais. Na tentativa de solucionar estes problemas, transformando dados em informaes, e atender s necessidades dos gestores, o presente trabalho trata do tema Data Warehouse, construindo um ambiente analtico em uma empresa do ramo logstico. O Data Warehouse construdo, atravs de uma ferramenta de ETL, centralizou as informaes geradas atravs dos sistemas transacionais, construindo um Data Mart para processar as informaes relativas execuo, cobrana e rentabilidade do transporte rodovirio de cargas. Ao final deste trabalho, avaliaram-se o projeto executado, a qualidade dos dados do ambiente, bem como a satisfao dos usurios. Com base nos resultados foi verificado que o ambiente, apesar de algumas ressalvas, sagrou-se satisfatrio, prestando-se, de forma centralizada e calculada, ao diagnstico empresarial e a tomada de decises relacionadas aos servios de transporte de cargas. Palavras-chave: Data Warehouse, Diagnstico Empresarial, ETL.
ABSTRACT
A large portion of companies have a varied number of tools aiming to know their processes. This is due, among other things, the obligations imposed by legislation, geographic aspects, and financial issues. This scenario adds some difficulty to diagnose business, where managers to summarize a large volume of data that often come from different operational sources. In an attempt to solve these problems, turning data into information, and meet the needs of managers, this work deals with the topic Data Warehouse, building an analytical environment in a company's logistics branch. The Data Warehouse built through an ETL tool, that centralized information generated through transactional systems, building a Data Mart to process information relating to implementation and cost recovery from road freight. On completion of this work, we evaluated the project is executed, the data quality of the environment as well as user satisfaction. Based on the results was verified that the environment, despite some reservations,has won the good, building on a centralized basis and calculated the diagnostic business and decision making related to freight transportation services. Keywords: Data Warehouse, Diagnostic Business, ETL
LISTA DE FIGURAS
Figura 1 Estrutura do Data Warehouse ......................................................................... Figura 2 Abordagem Top Down .................................................................................... Figura 3 Abordagem Botton Up .................................................................................... Figura 4 Abordagem Intermediria ou Combinada........................................................ Figura 5 Exemplo de Granularidade............................................................................... Figura 6 Exemplo Pontos Cardeais ................................................................................ Figura 7 Modelo Estrela ................................................................................................ Figura 8 Modelo Floco de Neve (Snowflake)................................................................ Figura 9 Tela de Entrada PDI ....................................................................................... Figura 10 Interface Talend Open Studio ....................................................................... Figura 11 Ambiente Transacional................................................................................... Figura 12 Diagrama Entidade Relacionamento Transporte de Cargas........................... Figura 13 Estrutura Fonte de dados A............................................................................ Figura 14 Estrutura Fontes de dados B,C,D,E................................................................ Figura 15 TOS SQL..................................................................................................... Figura 16 Fluxo ETL......................................................................................................
19 23 25 26 27 30 32 33 41 44 51 52 55 55 56 57
Figura 17 Relatrio Rentabilidade Total........................................................................ Figura 18 Relatrio Rentabilidade Unidade................................................................... Figura 19 Relatrio Rentabilidade Evoluo.................................................................. Figura 20 Grfico Questo 1.1........................................................................................ Figura 21 Grfico Questo 1.2........................................................................................ Figura 22 Grfico Questo 1.3........................................................................................ Figura 23 Grfico Questo 1.4........................................................................................ Figura 24 Grfico Questo 1.5........................................................................................ Figura 25 Grfico Questo 1.6........................................................................................ Figura 26 Grfico Questo 1.7........................................................................................ Figura 27 Grfico Questo 2.1........................................................................................ Figura 28 Grfico Questo 2.2........................................................................................ Figura 29 Grfico Questo 2.3........................................................................................
59 60 61 72 72 73 73 74 74 75 75 76 76
LISTA DE TABELAS
Tabela 1 Caractersticas do Data Warehouse................................................................. Tabela 2 Funcionalidades PDI........................................................................................ Tabela 3 Funcionalidades TOS....................................................................................... Tabela 4 Mtricas para Exatido.................................................................................... Tabela 5 Mtricas para Completude............................................................................... Tabela 6 Mtricas para Relevncia................................................................................. Tabela 7 Mtricas para Acessibilidade........................................................................... Tabela 8 Check List Projeto............................................................................................ Tabela 9 Mtricas Gerais................................................................................................ Tabela 10 Mtricas Dimenses...................................................................................... Tabela 11 Mtricas Fato.................................................................................................
17 42 45 65 65 65 66 68 69 70 71
LISTA DE ABREVIATURAS E SIGLAS
API DM DW ERP ETL OLAP ODS PDI SAD SGBD SQL TI TOS XML CNPJ
Application Programming Interface Data Mart Data Warehouse Enterprise Resourse Planning Extract Transform Load Online Analytical Processing Operational Data Storage ou Staging Area Pentaho Data Integration Sistema de Apoio Deciso Sistema Gerenciador de Banco de Dados Structured Query Language Tecnologia da Informao Talend Open Studio Extensible Markup Language Cadastro Nacional de Pessoa Jurdica
SUMRIO
1. INTRODUO...........................................................................................................
14
2. REFERENCIAL TERICO...................................................................................... 2.1 PROCESSAMENTO ANALTICO............................................................................ 2.2 DATA WAREHOUSE.................................................................................................. 2.2.1 Conceitos................................................................................................................. 2.2.2 Componentes........................................................................................................... 2.3 PROJETO DE DATA WAREHOUSE.......................................................................... 2.3.1 Arquitetura.............................................................................................................. 2.3.1.1 Global..................................................................................................................... 2.3.1.2 Independente.......................................................................................................... 2.3.1.3 Integrada................................................................................................................ 2.3.2 Abordagem.............................................................................................................. 2.3.2.1 Abordagem Top Down.......................................................................................... 2.3.2.2 Abordagem Botton Up........................................................................................... 2.3.2.3 Intermediria ou Combinada.................................................................................
16 16 17 17 18 20 21 21 21 22 22 22 24 26
2.3.3 Granularidade......................................................................................................... 2.3.4 Modelagem............................................................................................................. 2.3.4.1 Fato....................................................................................................................... 2.3.4.2 Dimenso............................................................................................................... 2.3.4.3 Medidas ................................................................................................................ 2.3.4.4 Modelo Estrela (Star)............................................................................................ 2.3.4.5 Modelo Floco de Neve (Snowflake)...................................................................... 2.3.5 Extrao, Transformao e Carga....................................................................... 2.3.5.1 Extrao de Dados................................................................................................. 2.3.5.2 Transformao e Filtros ....................................................................................... 2.3.5.3 Carga dos Dados.................................................................................................... 2.3.5.4 Ferramentas ETL................................................................................................... 2.3.5.5 Pentaho Data Integration....................................................................................... 2.3.5.6 Talend Open Studio...............................................................................................
27 28 29 30 31 32 33 34 35 36 37 38 40 42
3. ESTUDO DE CASO.................................................................................................... 3.1 LEVANTAMENTO DE REQUISITOS..................................................................... 3.1.1 A Empresa............................................................................................................... 3.1.2 Requisitos do Data Warehouse.............................................................................. 3.1.3 Ambiente Transacional.......................................................................................... 3.2 MODELAGEM........................................................................................................... 3.3 CONSTRUO DO DATA WAREHOUSE ..............................................................
46 46 47 47 50 52 53
3.4 PROCESSO ETL......................................................................................................... 3.5 CONFECO DE RELATRIOS.............................................................................
54 58
4. VALIDAO............................................................................................................... 4.1 ITENS VALIDADOS.................................................................................................. 4.1.1 Reviso do Projeto.................................................................................................. 4.1.2 Qualidade dos Dados.............................................................................................. 4.1.3 Satisfao do Usurio............................................................................................. 4.2 RESULTADOS OBTIDOS.........................................................................................
62 62 63 64 66 67
5. DISCUSSO DE RESULTADOS.............................................................................. 5.1 REVISO DO PROJETO........................................................................................... 5.2 QUALIDADE DOS DADOS...................................................................................... 5.3 SATISFAO DO USURIO...................................................................................
78 78 79 81
6. CONCLUSO..............................................................................................................
83
14
1. INTRODUO
As empresas do ramo de transporte de cargas tm um papel fundamental para a economia do pas. Os seus servios possibilitam que a matria-prima seja entregue s indstrias e que a produo destas chegue at o consumidor. Neste sentido h milhares de transportadoras espalhadas pelo Brasil competindo por melhores fretes e menores custos. A informatizao trouxe inmeros benefcios para estas empresas, a integrao das suas unidades e a agilidade dos seus servios so alguns exemplos. Outro diferencial trazido pela era digital foi a possibilidade de rastreabilidade que auxilia clientes - relatando a situao da entrega desejada, como tambm a prpria empresa - trazendo segurana quanto ao posicionamento da carga, cumprimento de horrios e ainda descrio da rota percorrida. Hoje h grande demanda das empresas de transporte de cargas de solues SADs (Sistemas de Apio a Deciso), pois existe o desejo de que questes gerenciais possam ser respondidas atravs do histrico de dados operacionais, espalhados no ambiente da organizao, possibilitando criao de estratgias e suporte tomada de decises. Conforme Turban (2004), o processamento analtico, que inclui SAD, envolve, entre outros conceitos, a existncia de um repositrio, que d segurana e controle centralizados sobre os dados da organizao. Este repositrio nico de dados denominado Data Warehouse (conjunto de dados baseados em assuntos, integrado, no-voltil, e varivel em relao ao tempo). A integrao dos dados de diversos sistemas operacionais de uma organizao uma das etapas mais complexas na construo de um Data Warehouse (DW). Reconhecida como ETL (Extract Transform Load), essa etapa possui as tarefas de coletar informaes em diversos tipos de arquivos (como SGBDs - Sistema Gerenciador de Banco de Dados, textos, planilhas, Web Services, entre outros), padronizar os dados coletados e envi-los ao Data Warehouse. Visando suportar a demanda pelo processamento analtico no ramo de transporte de cargas, aliado a existncia de um ambiente heterogneo de informao, este trabalho realizou um estudo de caso, no qual construiu-se um Data Warehouse que, dentre suas atribuies, desejava viabilizar a tomada de decises relativas ao modelo de negcio de transporte de
15
cargas, valendo-se de uma ferramenta ETL a fim de garantir informaes objetivas, seguras e centralizadas, pois a integrao das informaes uma tarefa de elevada complexidade sendo necessrio o apoio de ferramenta especfica para viabilizar este estudo. No estudo de caso foi modelado um Data Warehouse que responda questes relativas rea comercial, envolvendo vendas, rentabilidade, fretes, entre outros assuntos do ramo de transportes de cargas, objetivando atrair a ateno da alta gerncia para a possibilidade de obter diagnstico das estratgias executadas at o momento, refletindo na melhoria dos servios. Alm deste captulo introdutrio, o presente trabalho est organizado em mais cinco captulos. O segundo captulo relaciona as principais definies envolvidas no domnio abordado, onde so discorridos conceitos, modelos e estruturas na inteno de que estes elementos suportem o desenvolvimento deste estudo. O terceiro captulo deste trabalho retrata o desenvolvimento do estudo de caso propriamente dito, onde so abordadas as etapas do projeto e as tarefas executadas. O quarto captulo trata da validao do trabalho realizado, neste sentido so apresentados os mtodos de avaliao e os resultados obtidos. J o quinto captulo realiza a discusso dos resultados obtidos no captulo anterior. Por fim, o sexto captulo apresenta as concluses finais e trabalhos futuros.
16
2. REFERENCIAL TERICO
Neste captulo so abordados tpicos importantes resultantes da pesquisa bibliogrfica sobre a temtica escolhida. Os conceitos aqui apresentados so importantes para desenvolvimento do trabalho proposto. Primeiramente relacionam-se questes sobre o processamento analtico, em seguida sero explorados os conceitos relacionados Data Warehouse e para finalizar este captulo, ser abordado o processo de ETL.
2.1 PROCESSAMENTO ANALTICO Segundo Turban (2004), o processamento de dados de uma empresa pode ser visto como analtico ou transacional. Os sistemas de processamento transacional so organizados em uma estrutura hierrquica, modelados conforme o processo de negcio que realiza o input das informaes. O conjunto destes sistemas transacionais e os bancos de dados relacionados so denominados sistemas de nvel operacional e basicamente produzem relatrios e resumos. O uso eficiente e eficaz dos dados dentro de uma empresa representa maior velocidade de reao s mudanas e s oportunidades ocorridas no ramo de negcio em que a organizao enquadra-se. Ainda conforme Turban (2004) existe uma relao entre o sucesso de uma empresa e a qualidade da gesto de seus dados, representado pela utilizao do processamento operacional em conjunto com o processamento analtico que envolve, entre outras tarefas, a anlise de dados acumulados. Para Inmon (1997) o processamento analtico o processo que atende s necessidades dos gerentes durante o processo de tomada de deciso. Geralmente conhecido como SAD ou de apoio deciso, o processamento analtico acessa uma infinidade de registros a fim de identificar tendncias. Como caractersticas do processo analtico citam-se o acesso fcil aos dados pelos usurios finais, a tomada de deciso flexvel baseada em dados precisos, realizada atravs de rpido processo e, a utilizao de um repositrio centralizador de dados conhecido como Data Warehouse ou Armazm de Dados.
17
2.2 DATA WAREHOUSE Data Warehouse ou armazm de dados foi um termo acadmico criado no final da dcada de oitenta a fim de solucionar problemas surgidos com a evoluo da arquitetura dos sistemas de apoio deciso. Esta subseco abordar os conceitos de Data Warehouse e o ambiente arquitetnico em que ele se encaixa.
2.2.1 Conceitos Inmon (1997 p.33) define Data Warehouse como um conjunto de dados baseado em assuntos, integrado, no-voltil, e varivel em relao ao tempo, de apoio s decises gerenciais. Turban (2004) relaciona, alm dessas, mais duas caractersticas como o uso de arquitetura cliente/servidor e a estrutura relacional para construo do banco de dados. A seguir a Tabela 1 descreve as principais caractersticas do Warehouse.
Tabela 1. Caractersticas do Data Warehouse. CARACTERSTICAS Organizao COMENTRIO Diferente do nvel operacional, os dados so organizados por assunto ou negcio especfico, contendo somente informao relevante para apoio deciso. Consistncia Os dados provenientes de diversos meios so formatados em um aspecto padro dentro do Data Warehouse. Variante de Tempo A estrutura de dados sempre possui referncia ao tempo, alm disso, o horizonte de tempo normalmente de 3 a 10 anos. No-Volatilidade Os dados no Data Warehouse no recebem atualizao, permitindo apenas as tarefas de carga e consulta.
18
Relacional
normalmente utilizada a abordagem relacional para estruturar o banco de dados.
Cliente/Servidor
Utiliza-se esta arquitetura a fim de fornecer maior facilidade e segurana ao acesso aos dados
Adaptado: BISPO (1998)
O objetivo do Data Warehouse criar um repositrio de dados que suporte as atividades de processamento analtico, como por exemplo, apoio deciso, sistemas de informaes executivas e outras aplicaes. Conforme Inmon (1997), em virtude de haver uma fonte nica de dados integrados, e uma vez que os dados apresentam boas condies de acesso, a tarefa do analista de SAD no ambiente de Data Warehouse incomensuravelmente mais fcil que no ambiente transacional. A maior vantagem permitir a tomada de decises baseada em fatos, reunindo informaes dispersas em diversas plataformas, transformando dados esparsos em informaes estratgicas. Um Data Warehouse fornece dados integrados e histricos. Segundo Costa (2002), estes dados servem desde a alta direo, que necessita de informaes mais resumidas, at as gerncias de baixo nvel, onde dados detalhados ajudam a observar aspectos mais operacionais da empresa. Nele, os executivos podem obter de modo imediato, respostas para perguntas que normalmente no possuem respostas em sistemas operacionais, e com isso, tomar decises com base em fatos, e no atravs de intuies ou especulaes.
2.2.2 Componentes H uma diversidade de abordagens ou arquiteturas referentes construo de um Data Warehouse. Porm, em sua maioria, elas so formadas por componentes semelhantes, a Figura 1 exibe um exemplo do ambiente analtico.
19
Figura 1 Estrutura do Data Warehouse. Adaptado: Turban (2004)
Conforme Inmon (1997), Kimball; Ross (2002), Turban (2004) e Machado (2008), possvel compor o ambiente de Data Warehouse atravs dos itens abaixo. Sistemas\Dados operacionais: Conjunto de arquivos, bases e sistemas que constituem o ambiente operacional da empresa. Geralmente estes dispositivos possuem estruturas diferentes entre si, tornando complexa a tarefa de passagem das informaes para o nvel analtico. Data Warehouse: Representa o prprio repositrio centralizador de dados, ou seja, o banco de dados ou conjunto de banco de dados que suportam as atividades analticas. Data Mart: Representa um subconjunto de dados do Data Warehouse desenhado para ser utilizado por uma rea de negcio ou departamento. A abordagem
20
incremental de DW constri o Data Warehouse aos poucos, incluindo-se os Data Marts (DM) conforme andamento do projeto. Ferramentas Extract Transform Load ou ETL: o conjunto de aplicativos que realizam a transferncia de informao operacional para o DW. Estas ferramentas efetuam trs tarefas bsicas: Extrair dados do ambiente operacional; Transformar esses dados a fim de padroniz-los e/ou particion-los; Incluir os dados conforme a estrutura do Data Warehouse. Ferramentas de Acesso a Dados: Podem ser de diversas tecnologias, porm tm o objetivo em comum de comunicar o usurio final com as informaes do Data Warehouse. Sistemas de apoio deciso, Sistemas de informaes Executivas, Relatrios, Data Mining e Anlise OLAP so alguns exemplos. Operational Data Storage (ODS) ou Staging Area: Representa um armazenamento intermedirio dos dados, anterior ao Warehouse. Esta rea concentra os dados coletados dos sistemas operacionais, que formam o ambiente heterogneo, para facilitar o processo de extrao, transformao e carga (ETL) do DW. Este no um componente obrigatrio do ambiente de Data Warehouse, porm permite que o processo de converso dos dados, oriundos do ambiente operacional, seja separado do processo de transformao, facilitando a manuteno das informaes e evitando a concorrncia com os sistemas operacionais no consumo de recursos.
2.3 PROJETO DE DATA WAREHOUSE Segundo Machado (2008), a arquitetura do Data Warehouse encontra-se em evoluo a fim de solucionar dificuldades de integrao entre os componentes do ambiente. Conforme o autor, os responsveis pelo projeto devem ter a preocupao de como integrar o Data Warehouse s diversas fontes heterogneas, aos Data Marts, ao ODS, s aplicaes servidoras, Web, ao data mining, entre outros componentes. A escolha da arquitetura e sua implementao ou abordagem so fatores importantes no desenvolvimento e execuo do projeto. Existe uma variedade de opes, porm so selecionadas conforme a adequao empresa e disponibilidade de recursos.
21
2.3.1 Arquitetura A escolha da arquitetura est baseada no conjunto de fatores relativos infra-estrutura disponvel, ao porte da empresa, ao escopo do projeto, ao nvel de capacitao dos empregados e aos recursos para investimento. A abordagem de implantao uma deciso gerencial e afeta, entre outros itens, o tempo para execuo do projeto, o retorno do investimento e a quantidade de componentes necessrios. Machado (2008) cita que a seleo da arquitetura ser determinada ou ir determinar, por exemplo, o local onde o Data Warehouse ou Data Marts estaro residindo. Abaixo seguem as arquiteturas apresentadas por Machado (2008):
2.3.1.1 Global A Arquitetura Global aquela que atende a maior parte dos requisitos de um Data Warehouse integrado, preparada para o alto nmero de acessos e utilizao das informaes por parte de todos os departamentos que compe a empresa. Fisicamente o ambiente pode estar centralizado, quando a empresa possui apenas uma sede ou distribudo, quando a organizao composta por mltiplas filiais e/ou unidades. Esta arquitetura objetiva atender as necessidades de todos os departamentos da empresa, nela os dados so extrados e carregados para o Data Warehouse atravs de processos agendados em horrios de menor fluxo de dados, ficando a tarefa de administrao do ambiente a cargo do departamento de TI (Tecnologia da Informao). A arquitetura global consome muito tempo de desenvolvimento e administrao do seu ambiente, assim torna-se alto o seu custo de implementao.
2.3.1.2 Independente Objetiva criao de ambientes isolados, especficos para atender as necessidades de cada grupo de usurios ou de cada departamento da organizao. A arquitetura implica na construo de Data Marts independentes, onde no existe conectividade entre as bases de dados departamentais.
22
A rea de TI apenas age de maneira a auxiliar a manuteno tcnica do ambiente, a extrao de dados tarefa da rea de negcio. Esta arquitetura tem um impacto bem menor nos recursos que a tcnica global citada anteriormente, resultando em uma implementao mais veloz, porm por no possuir integrao corporativa e restringir o acesso aos dados rea de negcio proprietria acaba inviabilizando uma anlise global da organizao.
2.3.1.3 Integrada Esta arquitetura tambm baseia-se na criao de Data Marts para atender as necessidades das reas de negcio, porm atentando-se para possibilidade de integrao entre os ambientes, provendo uma viso da empresa similar ao da arquitetura global. Os usurios de um determinado departamento tm acesso a base de dados de um Data Mart de outra rea de negcio. O compartilhamento de dados entre os Data Marts aumenta consideravelmente o nvel de complexidade de requisitos do ambiente, recaindo sobre o departamento de TI a responsabilidade de controle e administrao dos dados.
2.3.2 Abordagem Anteriormente foram apresentadas as arquiteturas de Data Warehouse. Machado (2008), relata que independente da arquitetura escolhida para o ambiente, possvel realizar a implementao atravs de trs abordagens: TopDown, BottomUp ou intermediria (combinao da duas anteriores). Essas tcnicas sero discutidas a seguir:
2.3.2.1 Top Down Foi o padro inicial de implantao do conceito de Data Warehouse. Nesta abordagem, primeiro modela-se e depois constri-se o DW contendo todas as informaes relativas s reas de negcio da empresa como um todo, repassando de forma gradual aos Data Marts setoriais.
23
Esta abordagem requer maior planejamento, inclusive as tecnologias devem ser definidas antes de executar o projeto. Neste sentido antes de iniciar a implantao devem ser tomadas s decises relativas aos dados como origem, estrutura, qualidade, segurana e modelagem, entre outros aspectos. O processo realizado primeiramente com a extrao, transformao e integrao das informaes do ambiente operacional para um ODS. Em seguida, os dados so carregados para o DW em um nvel alto de granularidade. A partir disso extrai-se dados do Data Warehouse para os Data Marts. Geralmente os dados esto mais sumarizados no DM, no apresentando o mesmo nvel histrico daquele encontrado na origem. A Figura 3 apresenta a disposio geral dos componentes na abordagem Top Down.
Figura 2 Abordagem Top Down Adaptado de Machado (2008)
24
A abordagem Top Down apresenta alguns benefcios como: a definio de regras de negcio antes da construo do Data Warehouse; possibilidade de uma fcil manuteno j que todos os Data Marts utilizam a arquitetura e os dados de um mesmo DW; Possibilidade de extrair informaes de toda a empresa, e em diferentes nveis de sumarizao; Garantia de um nico conjunto de aplicaes ETL, alm manuteno e monitoramento centralizados. Contudo esta abordagem possui como grande barreira o extenso trabalho inicial exigido antes que gestores possam visualizar resultados concretos, ou seja, a implementao torna-se muito longa, no havendo retorno em curto prazo, dificultando o apoio da organizao atravs das aes e recursos. Neste sentido as mudanas internas e externas tornam-se um grande risco para o projeto, pois o sucesso depender de uma equipe altamente capacitada e experiente, apta a avaliar corretamente o impacto das estratgias escolhidas.
2.3.2.2 Botton Up O objetivo dessa abordagem construir um Data Warehouse incremental a partir do desenvolvimento de Data Marts independentes. Primeiramente deve-se construir os Data Marts, atendendo as necessidades localizadas de informaes, conforme a prioridade para o negcio. Ao final deste processo o conjunto dos Data Marts ir compor o Warehouse. Esta forma de implementao vem se tornando muito popular entre os gerentes das empresas, pois, ao contrrio da abordagem Top Down, possui um retorno de investimento relativamente rpido. O processo realizado com a extrao, transformao e integrao dos dados operacionais para um ou mais Data Marts. A Figura 3 apresenta a abordagem Bottom Up.
25
Figura 3 Abordagem Botton Up Adaptado de Machado (2008)
A abordagem Botton Up apresenta algumas vantagens como: retorno rpido baseado no desenvolvimento incremental do DW atravs do desenvolvimento de Data Marts; Enfoque prioritrio, ou seja, inicialmente investe-se nas principais reas de negcio; Baixo risco de fracasso, j que o projeto evolui gradualmente. Um dos grandes problemas dessa implementao a possibilidade no haver padronizao dos Data Marts, neste sentido deve-se evitar a redundncia de dados por meio de planejamento, monitoramento e estabelecimento de regras ou metodologias de desenvolvimento. Outro fator crtico para o sucesso desta abordagem a administrao das prioridades, quais reas ou setores devem ser atendidos primeiramente pelas atividades de construo ou evoluo dos Data Marts.
26
2.3.2.3 Intermediria ou Combinada Este padro busca efetuar a modelagem dos dados atravs de viso macro da organizao, para posteriormente implementar partes deste modelo atravs de Data Marts. Neste sentido a implementao intermediria tem a tarefa de combinar a abordagem Top Down com a Bottom Up. A garantia da consistncia dos dados a principal vantagem desta tcnica, pois os Data Marts so obtidos de um nico modelo de dados possibilitando realizar o mapeamento e o controle dos dados. Esta abordagem primeiro realiza o planejamento atravs da modelagem dos processos de negcio, em seguida constri-se um DM de cada vez. Para cada Data Mart procura-se identificar a complexidade do modelo, o volume de dados e o investimento. A Figura 4 apresenta as etapas de construo de um Data Mart e como eles interagem formando o Warehouse.
Figura 4 Abordagem Intermediria ou Combinada Adaptado de Machado (2008)
27
2.3.3 Granularidade Inmon (1997) define a granularidade como nvel de detalhe ou de resumo contido nas unidades de dados existentes no Data Warehouse. Quanto mais baixo o nvel de granularidade mais detalhes dos dados, consequentemente maior volume do Warehouse. Quanto mais alto o nvel de granularidade, menos detalhes, conseqentemente menor volume do DW. A granularidade uma questo delicada no projeto, pois afeta profundamente o volume de dados residentes no Data Warehouse como tambm impacta no tipo de consulta que pode ser atendida pelo processamento analtico. O volume do Warehouse balanceado de acordo com o nvel de detalhe de uma consulta. Um nvel baixo de granularidade afeta tambm o espao ocupado pelo banco de dados, o nmero de ndices existentes e o esforo de processamento para acessar os dados. Porm, medida que o nvel de granularidade se eleva, minimiza a possibilidade de utilizao dos dados para atender uma consulta, ou seja, limita o nmero de questes satisfeitas pelo Data Warehouse. Para melhor compreenso dos aspectos citados, a Figura 5 traz um exemplo de granularidade.
Figura 5 Exemplo de Granularidade. Adaptado de Inmon (1997)
28
Observa-se que no lado esquerdo da Figura 5 h uma granularidade baixa, onde so registrados os detalhes de cada chamada telefnica feita por um cliente em um ms. O lado direito da Figura 5 apresenta um exemplo de alta granularidade, onde os dados representam as informaes resumidas referentes a um cliente em um ms. Tambm possvel comparar o volume de dados gerados por cada nvel de granularidade. Conforme o exemplo acima a alta granularidade consumiu 200 bytes com as informaes de um ms, enquanto a baixa granularidade ocupou 40 mil bytes com informaes do mesmo perodo. Segundo Machado(2008), a maioria das empresas possuem um nvel duplo de granularidade. Nessa tcnica o Data Warehouse possui uma primeira camada, chamada de nvel de dados histricos, onde encontram-se todos os detalhes provenientes do ambiente operacional. J na segunda camada estes dados so resumidos deforma apropriada para a utilizao dos analista e gerentes.
2.3.4 Modelagem Segundo Gonalves (2003), Kimball (2005) e Machado (2008), o ambiente de Data Warehouse modelado com enfoque na gesto do negcio, ao contrrio do ambiente operacional onde os sistemas transacionais so modelados com o objetivo de operacionalizar o negcio. Conforme os autores, aplicar os conceitos da Terceira Forma Normal no uma tcnica apropriada, pois agrega complexidade e reduz a velocidade das consultas, j que requerem duas ou mais junes entre tabelas, na tentativa de evitar a redundncia de dados. Conforme Gonalves (2003), o modelo multidimensional a tcnica mais utilizada atualmente para ambiente analtico. Machado (2008) define modelagem multidimensional como a tcnica de concepo e visualizao de um modelo de dados juntamente com um conjunto de medidas que descrevem aspectos comuns de negcio. Atravs dela reestrutura-se o ambiente operacional, apresentando os dados sumarizados e em vises que suportem o processo analtico. Segundo Crivelini (2006), este modelo deixa de focar a coleta de dados e concentra-se na consulta de dados. Atravs da utilizao de dimenses possvel obter visualizao dos dados de diferentes perspectivas atendendo questes complexas da gerncia. Alm disso, o modelo dimensional deve ser suficientemente simples para que os analistas de negcio
29
compreendam como us-lo, neste sentido a atualizao de at a Segunda Norma Formal reduz o nmero de tabelas facilitando enormemente a navegao e a compreenso do modelo de dados. Segundo os autores citados acima, o modelo multidimensional formado de trs elementos bsicos: Fatos, Dimenses e Medidas. A disposio ou a forma como estes elementos esto organizados pode ser designada atravs do Modelo Estrela (Star Schema) ou Modelo Floco de Neve (Snowflake). Conforme Kimball; Ross (2002), o mtodo para a modelagem dimensional pode ser dividido em quatro etapas consecutivas: a primeira etapa a escolha do processo de negcio que ser coberto pelo modelo, a seguir deve-se escolher o nvel de detalhe ou granularidade. A terceira etapa est relacionada escolha das dimenses, finalizando com escolha dos fatos.
2.3.4.1 Fato Fato uma coleo de itens de dados, representando uma transao ou um evento de negcio. Este elemento a base para anlise do processo analtico de uma empresa, dentro do banco de dados representado por valores numricos, organizados em tabelas denominadas tabelas Fato (fact tables). Segundo Machado (2008), um fato possui trs caractersticas bsicas: Varia ao longo do tempo; Possui medidas, ou seja, valores numricos de avaliao; Seu histrico pode ser mantido, crescendo ao passar do tempo. Aliado a estes itens, o autor cita uma tcnica para encontrar em um fato os fatores que o identificam e o localizam no mundo real, denominada pontos cardeais. Pontos cardeais so referncias lgicas, onde identifica-se, em um fato ocorrido, a indicao de tempo em que aconteceu, onde ocorreu, quem estava no fato e o que estava nele. Para construo de um Data Warehouse o tempo uma referncia obrigatria, a informao de tempo sempre deve estar na descrio e anlise de um fato. Alm do tempo os outros elementos de referncia, identificados com o uso da tcnica de pontos cardeais, conceituam-se como dimenses de um fato.
30
2.3.4.2 Dimenso Conforme Crivelini (2006), dimenses so os elementos ou entidades que compem um fato. Elas armazenam as classificaes para anlise do fato, ou seja, possuem todos os atributos associados a esta entidade. A Figura 6 exibe a utilizao de pontos cardeais aplicado produo genrica de uma indstria, onde se relacionam as dimenses para o fato produo.
Figura 6 Exemplo Pontos Cardeais. Adaptado de Machado (2008)
Machado (2008) afirma que a dimenso Tempo possui grande importncia para o modelo de dados de um Data Warehouse, pois relaciona-se diretamente com a granularidade do DW, estabelecendo limites do espao de tempo definido para o fato. Esta dimenso uma hierarquia de espaos de tempo, podendo possuir atributos como ano, trimestre, ms, semana, dia, entre outros. Conforme Machado (2008), as dimenses viabilizam o formato de anlise multidimensional de dados. Segundo o autor ao se construir o modelo, atravs da estrutura relacional existente no ambiente transacional, possvel optar por diversas formas de
31
organizar as dimenses, ou seja, quando no ambiente operacional determinada entidade possui nveis de hierarquia pode-se modelar de trs formas distintas: 1- Modelar uma dimenso para entidade e para cada nvel de hierarquia, ligando uma dimenso outra. Deve-se observar o nmero de junes provenientes desta escolha e o quo complicado pode ficar o ambiente do DW. 2- Modelar uma dimenso para entidade e para cada nvel de hierarquia, porm, diferentemente da opo anterior, ligar cada dimenso a tabela fato. Esta soluo permite realizar consultas relacionando nveis mais altos de hierarquia com o fato em si. 3- Modelar uma dimenso apenas, contendo como atributos as informaes da entidade e tambm as informaes de cada nvel de hierarquia, ou seja, concentram-se os atributos das hierarquias em uma s tabela. Nesta opo as informaes sobre a entidade e hierarquias esto centralizadas em uma tabela facilitando o acesso a informao.
2.3.4.3 Medidas Segundo Crivelini (2006), medidas so atributos numricos que representam um fato. A anlise destes valores exibe o desempenho de um indicador do negcio relativo s dimenses. As medidas so fundamentais na criao de fatos, pois valorizam o resultado de alguma ao ou desempenho de determinada atividade empresarial em um determinado espao de tempo. Conforme o autor, as medidas se classificam em dois tipos: valores aditivos e valores no aditivos. Valores aditivos: So valores referentes ao fato sobre os quais possvel aplicar operaes matemticas como soma, subtrao, mdia, entre outras. Valores no aditivos: So valores que representam o desempenho de algum fato, ou seja, so indicadores. Geralmente so produtos das operaes realizadas a partir de valores aditivos.
32
2.3.4.4 Modelo Estrela (Star Schema) O Modelo Estrela ou Star Schema diz respeito a como armazenar e representar dados multidimensionais em banco de dados relacionais. Conforme Gonalves (2003), nesta abordagem as instncias dos dados so armazenadas em uma tabela denominada tabela de fatos contendo o identificador da instncia, valores das dimenses descritas para cada instncia, e valores dos fatos, ou medidas, para aquela instncia. Alm disso, Ao redor da tabela fato, temos tabela de look up, que chamamos de dimenses. Todas as dimenses relacionam-se exclusivamente com a tabela fato, da a referncia da estrela. (CRIVELINI, 2006, p. 7) Conforme Crivelini (2006), em relao ao banco de dados, a tabela fato deve armazenar as medidas e os campos chaves que caracterizam o registro. Estas chaves so os elementos de juno com determinada entidade das tabelas de dimenso. Cada tabela dimenso armazena as classificaes utilizadas para analisar os fatos e mais alguns atributos destas classificaes. A tabela fato possui mltiplas junes, enquanto as tabelas de dimenses se ligam apenas por uma juno tabela central. Conforme Machado (2008) esta caracterstica faz da abordagem Estrela mais vantajosa em relao a outras abordagens j que possui um nmero reduzido de junes. A Figura 7 apresenta o exemplo de um modelo Estrela.
Figura 7 Modelo Estrela. Adaptado de Gonalves (2003)
33
Conforme pode ser observado na Figura 7, a tabela fato est no centro e possui, alm, das medidas que valorizam o fato, os campos de ligaes com cada entidade da cada tabela dimenso.
2.3.4.5 Modelo Floco de Neve (Snowflake) O modelo Floco de Neve ou Snow Flake tambm refere-se a como representar e implementar dados multidimensionais em banco de dados relacionais, segundo Gonalves (2003), esta abordagem consiste em uma extenso do modelo estrela, onde algumas tabelas de dimenses passam a ser o centro de outras estrelas, ou seja, quebra-se uma dimenso em uma hierarquia de dimenses. Segundo Machado (2008), a abordagem floco de neve o produto da aplicao da Terceira Forma Normal sobre as entidades que possuem relacionamentos muitos para um entre seus membros, formando uma hierarquia. A principal vantagem desta normalizao a reduo de dados redundantes, especialmente valores textuais acarretando economia de espao utilizado no ambiente de Data Warehouse. Conforme a Figura 8 possvel verificar um exemplo de implementao baseada na abordagem Floco de Neve.
Figura 8 Modelo Floco de Neve (Snowflake). Adaptado de Gonalves (2003)
34
Como possvel observar na Figura 8, a modelagem Floco de Neve pode gerar uma cadeia de tabelas interligadas representando as hierarquias das dimenses. Porm ressalta-se que o modelo Snowflake esteticamente semntico para visualizao de hierarquias, mas somente para isso. (MACHADO, 2008, p. 147). Esta afirmao deve-se ao fato ao nmero de junes necessrias para realizao de consultas, que, devido estrutura gerada, sempre maior que o nmero de junes provenientes da abordagem Estrela, comprometendo o desempenho do Data Warehouse.
2.3.5 Extrao, Transformao e Carga Conforme Gonalves (2003), as tarefas de extrao, limpeza, transformao e migrao de dados dos sistemas existentes na empresa para o Data Warehouse constituem servios crticos para um ambiente analtico eficaz e eficiente. O autor afirma que a identificao de fontes, a definio de regras de transformaes e a resoluo de questes envolvendo a qualidade e a integrao de dados, consomem quase que oitenta por cento do tempo do projeto. Reforando essa afirmativa: De acordo com a maioria dos profissionais, o trabalho de projeto e desenvolvimento com ETL consome de 60% a 80% de um projeto inteiro. (ECKERSON; WHITE, 2003 apud CRUZ, 2009). Existem alguns produtos no mercado com o objetivo de automatizar os processos citados anteriormente, auxiliando a detectar problemas na qualidade dos dados e a criar agendamento de extraes. Porm, conforme Gonalves (2003), o tempo destinado aos processos de ETL est vinculado ao nmero de fontes existente no ambiente operacional e a qualidade dos seus metadados (informaes sobre a organizao dos dados, facilitando o entendimento do modelo). O trabalho realizado nesta etapa de construo do Data Warehouse poder tornar-se ainda mais complexo, caso as regras de negcio tenham que ser extradas diretamente do cdigo fonte das aplicaes transacionais.
2.3.5.1 Extrao de Dados Conforme Cruz (2009), a etapa de extrao de dados composta pelas tarefas de definio de escopo do projeto, a identificao e anlise das fontes operacionais e a especificao das ferramentas responsveis por esta funo. Durante a tarefa de definio de
35
escopo os usurios envolvidos foram identificados, juntamente com a relao dos principais requisitos que o Data Warehouse dever suportar. A seguir identificam-se as fontes de dados, classificando-as em dois grupos: internas, caracterizadas pelos sistemas transacionais que controlam as operaes dirias, e externas, como dados da internet e arquivos enviados por terceiros. A existncia de diversas origens de dados cria um ambiente heterogneo agregando maior complexidade a esta tarefa. A seguir a listam-se alguns elementos que dificultam a extrao dos dados, descritos por Cielo (2002) apud Cruz (2009): Composio de um mesmo atributo no Data Warehouse por dois ou mais campos em tabelas do ambiente operacional; Carncia do modelo de dados e documentao dos sistemas transacionais, exigindo engenharia reversa para compreender as fontes de dados; Deficincia da padronizao do formato dos dados, devido existncia, no ambiente operacional, de aplicaes provenientes de diferentes fornecedores; Diversidade de tecnologias e plataformas onde esto armazenadas as bases de dados. Conforme Gonalves (2003) h vrias alternativas para extrao de dados que permitem balancear desempenho, restrio de tempo e de armazenamento, porm a caracterstica mais importante de uma ferramenta de extrao ter a capacidade de isolar somente os dados que foram inseridos ou atualizados desde a ltima extrao. Para Cruz (2009), as tcnicas que realizam o processo de captura de dados podem ser definas como estticas ou dinmicas. A tcnica de captura esttica de informaes tem o objetivo de periodicamente realizar um snapshot (coletar a situao atual dos dados em um instante de tempo) do ambiente operacional, enviado estas informaes ao ambiente do Warehouse. A carga pode ocorrer de forma completa, onde as tabelas de destino so limpas, ou seja, os dados carregados anteriormente so apagados e recria-se a tabela novamente a partir da nova carga, ou anexada, onde se deixa os registros j existentes na tabela destino. Geralmente as tarefas de coleta que utilizam esta tcnica so agendadas em horrio de menor fluxo da rede.
36
A tcnica de captura dinmica capaz de extrair somente os dados que foram inseridos e atualizados desde a ltima coleta, para isso so utilizados recursos de bancos de dados como triggers, arquivos de logs e campos data/hora (responsveis por identificar as alteraes dos registros). A grande vantagem de trabalhar esta tcnica o volume menor de dados enviado ao Data Warehouse em relao a captura esttica.
2.3.5.2 Transformao e Filtros Esta etapa tem o objetivo de realizar transformaes e limpezas das informaes, produzindo dados coerentes e padronizados. Conforme Gonalves (2003), a limpeza ou filtragem o primeiro tratamento dado s informaes depois de coletadas, segundo o autor, o objetivo deste processo garantir a integridade dos dados atravs de rotinas que tentam identificar anomalias e resolve-las, como, por exemplo, a substituio de caracteres desconhecidos, a padronizao de abreviaes, e a descoberta de violaes de integridade, entre outras rotinas. A respeito da tarefa de transformao, Gonalves (2003) afirma que podem ocorrer conflitos de modelagens. Conflitos de modelagens podem ser divididos em: Semnticos: quando mesmas entidades possuem nomes diferentes ou entidades diferentes so denominadas da mesma forma; Estruturais: relativos a conflitos de domnio de atributo, ou seja, valores ou tipos de dados diferentes para mesma entidade.
2.3.5.3 Carga dos Dados Aps a transformao dos dados realizado o processo de carga, enviando as informao base de dados do Data Warehouse. Conforme Kimball e Ross (2002), o processo de carga pode ser realizado da seguinte forma: Criar imagens de registro de carga: neste passo verifica-se se os registros transformados esto compatveis com os do Data Warehouse. Todos os registros
37
de carga devem ter a mesma estrutura que seus respectivos destinos no Data Warehouse; Criar agregaes: deve-se primeiro criar os registros agregados antes da carreglos; Generalizar chaves para registros de agregao: geram-se chaves artificiais para os registros agregados; Carga de registro com integridade referencial: os ndices so desligados na inteno de aumentar o desempenho durante a carga, porm no deve-se desligar a integridade referencial da base de dados do Data Warehouse, a fim de evitar inconsistncias; Tratar registros rejeitados: os registros que fracassaram no processo de carga devem ser analisados e seus erros corrigidos, processando-se uma carga especfica para estes dados. Construir ndices: os ndices, anteriormente desligados, so reconstrudos aps o trmino do processo de carga. Assegurar a qualidade dos dados: aps a carga e a reconstruo dos ndices, devese assegurar a qualidade dos dados atravs de relatrios e/ou grficos extrados a partir do Data warehouse. As principais dimenses devem conter valores dentro dos limites esperados, bem como ideal uma comparao entre os valores provenientes das fontes operacionais com os valores inseridos na base de dados do Warehouse.
2.3.5.4 Ferramentas ETL As ferramentas ETL so softwares voltados s tarefas de extrao, transformao e carga executadas nos dados entre a origem e o Data Warehouse. Conforme Gonalves (2003), o nmero de ferramentas disponveis no mercado est aumentando gradativamente, tornando a aquisio um processo criterioso.
38
Gonalves (2003), ressalta tambm dois pontos importantes para a escolha de uma ferramenta ETL: o primeiro est relacionado garantia da possibilidade de integrar diferentes fontes de dados existentes na organizao, j o segundo ponto que deve ser considerado para quais plataformas de hardware a ferramenta est disponvel. Tambm considera-se o custo de licenciamento um importante aspecto na seleo de uma ferramenta de integrao, o qual deve ser coberto pelos recursos disponveis para o projeto. Para auxiliar o processo de escolha sobre uma determinada ferramenta, o autor, descreve alguns recursos e funcionalidades significativos em uma ferramenta ETL: 1. Extrair dados de diversas fontes: capacidade da ferramenta de extrair informaes de diversas fontes de dados como arquivo-texto, aplicaes SAP, Oracle, MySQL, Access, PostgreSQL, entre outros; 2. Executar em ambiente multi-plataforma: capacidade da ferramenta de executar em vrias plataformas, como Windows, Linux, Solaris, entre outros; 3. Permitir processamento distribudo: capacidade da ferramenta de possuir vrios ns de processamento de maneira que um processo que exige mais seja processado no n de maior processamento; 4. Possuir alta escalabilidade: capacidade da ferramenta de manipular uma quantidade crescente de trabalho de forma uniforme; 5. Permitir compactao de dados: capacidade da ferramenta de compactar os dados, gerando assim uma maior otimizao; 6. Permitir criptografia de dados: capacidade da ferramenta de transformar os dados em uma forma ilegvel, aumentando a segurana; 7. Conter mecanismo de transmisso de dados: capacidade da ferramenta em possuir um sistema que possibilite a comunicao dos dados; 8. Permitir retransmisso de dados: capacidade de retransmitir informaes em um eventual erro; 9. Conter mdulo para administrao: capacidade da ferramenta em possuir um mdulo que administre e gerencie os processos;
39
10. Permitir gerenciamento centralizado: capacidade de gerenciar o sistema a partir de um nico mdulo; 11. Conter repositrio de metadados: capacidade da ferramenta de possuir um repositrio de metadados para auxiliar no desenvolvimento do projeto. 12. Possuir alto desempenho: capacidade da ferramenta de desempenhar as suas funes de forma eficiente; 13. Permitir agendamento de tarefas: capacidade da ferramenta em executar tarefas em um tempo pr-agendado. 14. Possuir uma arquitetura aberta: capacidade da ferramenta de permitir a reutilizao e modificao do tipo de arquitetura utilizado; 15. Disponibilizar interface grfica para montar cargas de dados: capacidade de disponibilizar uma interface grfica com o intuito de facilitar a montagem das cargas de dados; 16. Disponibilizar uma linguagem para transformao dos dados: capacidade de possuir uma linguagem de programao capaz de executar clculos e operaes complexas, auxiliando na transformao dos dados; 17. Gerar cdigo atravs de diagramas grficos: capacidade da ferramenta de gerar o cdigo atravs de diagramas criados na modelagem das transformaes; 18. Permitir importar metadados: capacidade da ferramenta de importar um repositrio de metadados.
A partir dos requisitos listados acima possvel comparar recursos e funcionalidades disponveis em ferramentas de ETL. Conforme j citado anteriormente, h disponveis, atualmente, diversas ferramentas que se propem a realizar o processo de integrao de dados. Para o escopo deste trabalho foram analisadas as principais caractersticas tcnicas das ferramentas Talend Open Studio e Pentaho Data Integration, que segundo Cielo (2010), indica serem, estas duas ferramentas, as mais utilizadas na plataforma Open Source, alm disso, possuem verses distribudas gratuitamente, tornando-se uma escolha favorvel para projetos com poucos recursos.
40
2.3.5.5 Pentaho Data Integration Pentaho Data Integration (PDI), tambm chamado de Kettle (nome original da ferramenta criada por Matt Casters, adquirida pela empresa americana Pentaho em 2006), consiste em uma ferramenta com ambiente grfico para integrao de dados, fazendo parte, atualmente, da plataforma de Business Intelligence da empresa Pentaho. PDI um aplicativo responsvel pelas tarefas de extrao, transformao e carga de dados. Segundo Pentaho (2010), esta ferramenta possui foco em metadados, sendo operada, em grande parte, graficamente, evitando que o usurio utilize linguagem de programao. As aplicaes Spoon e Chef so exemplos disso, onde a prpria ferramenta encarrega-se da gerao de codificao contribuindo para um ambiente intuitivo. Conforme Jansen (2006) apud Cruz (2009), a ferramenta PDI pode ser dividida em quatro aplicaes desenvolvidas em linguagem Java: Spoon: aplicao grfica onde se modelam o fluxo de dados e as transformaes necessrias. Desempenha as funes tpicas de fluxo de dados como a leitura, validao, refino, transformao, gravao de dados em uma variedade de diferentes fontes de dados e destinos. Pan: aplicao propicia para executar as transformaes de dados projetadas pela aplicao Spoon. Alm disso, esta aplicao pode ser agendada para ocorrer em determinado intervalo de tempo. Chef: a ferramenta para criar tarefas (jobs) que automatizam o processo de atualizao de banco de dados. Kitchen: um aplicativo que ajuda a executar um lote de tarefas agrupadas, geralmente usando um programa que torna mais fcil o controle o processamento ETL.
Segundo Pentaho (2010), a ferramenta PDI possui a capacidade de extrao de dados de uma grande variedade de fontes de dados, podendo trabalhar com as plataformas: Oracle,
41
MySQL, PostgreSQL, Firebird, SQL Server, arquivos texto e planilhas, aplicaes SAP, entre outras. Com relao ao processo de transformao dos dados, a ferramenta Pentaho Data Integration disponibiliza recursos como filtragem, agregao, ordenao, normalizao, desnormalizao, entre outros. Alm disso, pode-se utilizar comandos da linguagem JavaScript para auxiliar o processo de transformao de dados. A Figura 9 exibe a tela de abertura da ferramenta PDI.
Figura 9 Tela de Entrada PDI. Fonte: Pentaho (2010)
Conforme a Figura 9 possvel observar que tela de entrada da ferramenta Pentaho Data Integration exibe uma srie de fontes para material de apoio como: documentaes relativas usabilidade da ferramenta, atalhos para site do fornecedor e frum de discusso da comunidade de usurios da aplicao.
42
A partir da lista de requisitos e funcionalidades mais significativas em uma ferramenta ETL, organizada por Gonalves (2003), foi possvel confeccionar a Tabela 2, relacionando-se quais aspectos so atendidos pela ferramenta PDI.
Tabela 2. Funcionalidades PDI
Adaptado: Pentaho (2010).
2.3.5.6 Talend Open Studio Conforme Privati (2009), A Talend uma empresa francesa provedora de produtos de integrao de dados em formato open source, seu principal produto o Talend Open Studio, que tambm disponibilizado como componente principal no Talend On Demand e no Talend Integration Suite, estes so pacotes pagos de produtos e servios que incluem capacidades adicionais para desenvolvimento colaborativo e opes de alto desempenho. Lacy (2009), afirma que o Talend Open Studio (TOS) uma ferramenta ETL de cdigo aberto capaz de processar e consolidar dados contidos em diversas empresas e em inmeros sistemas de arquivos distintos, armazenando-os de forma centralizada no Data
43
warehouse. Privati (2009) relata que o TOS foi escrito na linguagem Java e um produto de gerao de cdigo, que utiliza a plataforma Eclipse, possibilitando gerar cdigo Java ou Perl. O cdigo gerado pode ser visualizado e executado independente de qualquer interface, permitindo que desenvolvedores utilizem conhecimento prvio nessas tecnologias e tambm possibilitando a integrao do cdigo gerado com outras aplicaes. Conforme Lacy (2009), um dos aspectos mais importantes da ferramenta TOS, sua arquitetura distribuda, diferentemente da maioria das solues para integrao de dados. possvel utilizar mltiplos servidores neste tipo de arquitetura, permitindo que a organizao explore eficientemente seus recursos de hardware, garantindo melhor desempenho. A arquitetura da ferramenta formada por: Gerenciador grco de processos ETL Repositrio de processos: mdulo adicional, disponvel na verso comercial; Monitor de processos: que possibilita visualizao do que est em execuo; Gerenciador de metadados: repositrio para reutilizao de objetos,
armazenamento de informaes sobres dados; Componentes modulares: Usando a API do sistema podem ser desenvolvidos componentes personalizados. Gerenciador grco de negcios: viso no tcnica de necessidades de fluxo de dados; A Figura 10 exibe a interface da TOS. Seguindo o padro Eclipse (plataforma com foco no desenvolvimento de aplicaes de software), a ferramenta possui uma perspectiva constituda de vrios painis.
44
Figura 10 Interface Talend Open Studio. Fonte: Talend (2010)
Conforme pode ser visto na Figura 10, o primeiro painel o Repository, local onde se encontram todos os elementos necessrios para o desenvolvimento de um projeto de integrao, como modelos de negcios, design de tarefas, contextos, metadados e documentao. O segundo painel, localizado na parte inferior esquerda, possvel visualizar o modelo de negcio ou a tarefa em edio, alm disso, a aba Code Viewer, exibe o cdigo gerado para o componente selecionado. O terceiro painel, a rea de edio grfica do TOS, onde possvel abrir e editar tanto o desenho das tarefas (Jobs) quanto os modelos de negcio. Alm de permitir mais que uma edio ao mesmo tempo, possui uma ferramenta denominada Palette, contendo os componentes grficos que auxiliam a modelagem. O quarto painel, localizado na parte inferior central, exibe inmeras abas, destacando-se a aba Problem, que exibe um log do projeto exibindo erros e alertas relativos tarefa ativa. J a aba Run job, permite ao usurio, acompanhar os detalhes da tarefa que est sendo executada. A partir da lista de requisitos e funcionalidades mais significativas em uma ferramenta ETL, organizada por Gonalves (2003), foi possvel confeccionar a Tabela 3.
45
Tabela 3. Funcionalidades TOS
Adaptado: Talend (2010).
46
3. ESTUDO DE CASO
Segundo Gil, (1996), Berto; Nakano, (2000) apud Miguel (2007), o estudo de caso uma tarefa de natureza emprica que investiga um dado fenmeno, geralmente atual, dentro de um contexto real de vida. Conforme o autor trata-se de uma anlise aprofundada de um ou mais objetos (casos), para que permita o seu amplo e detalhado conhecimento. O objetivo de um estudo de caso aprofundar o conhecimento relacionado a um problema no suficientemente esclarecido, visando estimular a compreenso, sugerir hipteses e questes ou desenvolver a teoria. A principal tendncia em todos os tipos de estudo de caso, esclarecer o motivo pelo qual uma deciso ou um conjunto de decises foram tomados, como foram implementadas e quais os resultados alcanados. O presente estudo de caso aborda o desenvolvimento de uma soluo para suporte s tarefas analticas, em uma empresa do ramo logstico, realizadas com base nos dados provenientes do seu ambiente operacional heterogneo, utilizando-se uma ferramenta ETL para manipulao e integrao de diferentes tecnologias. O desenvolvimento deste estudo se fez atravs de etapas. Neste sentido o presente captulo dividido conforme as seguintes atividades: levantamento de requisitos, modelagem do repositrio de dados, construo fsica do ambiente analtico, realizao do processo ETL, ou seja, integrao e carregamento de dados, culminando na confeco de relatrios gerenciais a fim de possibilitar a visualizao das informaes contidas no Data Warehouse.
3.1 LEVANTAMENTO DE REQUISITOS Esta fase compreende todas as tarefas relativas obteno dos requisitos do Data Warehouse que foi construdo. Segundo Pressman (2007), entender os requisitos de um problema est entre as tarefas mais difceis na construo de softwares. Conforme o autor o levantamento de requisitos constri uma ponte entre o projeto e a sua construo, fornecendo mecanismos apropriados para anlise e avaliao das necessidades do cliente. Para facilitar a etapa de levantamento dos requisitos foi necessrio executar, junto aos gestores, entrevistas orientadas ao preenchimento de um questionrio base, que se encontra no
47
Apndice A do presente trabalho. Os resultados obtidos com as entrevistas foram divididos na seguinte estrutura: informaes da empresa, requisitos do Data Warehouse, identificao das fontes de informao.
3.1.1 A Empresa Por solicitao da empresa participante deste estudo de caso, sua razo social no ser divulgada, neste sentido o presente trabalho ir referenci-la como Logstica Gluck Ltda. em homenagem a um dos gerentes participantes do estudo de caso. A Gluck Ltda uma empresa de origem familiar que atua desde a dcada de setenta no ramo logstico. Com a misso de aproximar mercados ela oferece, para todo o sul do pas e o Mercosul, servios de transporte, armazenamento e consultoria em projetos logsticos. A sede central de operaes da Gluck Ltda est situada na cidade de Porto Alegre em uma rea de aproximadamente 50.000 m. Tambm possui filial nas cidades de Salvador, Manaus, Curitiba, So Paulo, Rio de Janeiro, Itaja e Rio Grande. Alm destas, h filiais nos seguintes pases: Uruguai, Argentina e Chile, respectivamente nas cidades de Montevidu, Buenos Aires e Santiago.
3.1.2 Requisitos do Data Warehouse Conforme Ziulkoski (2003), no h literatura abundante de como realizar a coleta de requisitos para Data Warehouse, alm disso, a experincia e o conhecimento adquiridos no contexto do ambiente transacional no so adequados para o ambiente de suporte a deciso. Segundo Lambert (2003) apud Ziulkoski (2003), algumas caractersticas para o levantamento de requisitos utilizados no ambiente analtico so: Entrevistar poucos usurios: no longo prazo, o DW dever atender s necessidade de todos, mas no incio preciso comear com um conjunto reduzido de problemas a resolver, que traro rpido benefcio. Quanto mais usurios forem entrevistados, mais informaes sero necessrias e diferentes formas de organizao delas sero solicitadas, tornando o escopo do projeto muito grande e complexo. Ao contrrio do ambiente operacional, onde vrias
48
pessoas executam as mesmas operaes, no ambiente gerencial cada usurio tem sua particularidade. Evitar entrar em detalhes dos processos: a forma como os dados da organizao so processados tem pouco a dizer sobre o desempenho da organizao. O foco da anlise deve ser em cima dos indicadores da organizao e dos dados necessrios para calcul-los. Aceitar incluso de novos requisitos a qualquer momento: num ambiente de suporte a deciso, ser natural e indicativo de sucesso se os usurios comearem a pedir novas informaes a partir do seu uso do DW. medida que os usurios utilizam o DW eles percebem suas potencialidades e encontram novas possibilidades para seu uso. A equipe de desenvolvimento deve, inclusive, incentivar mudanas nos requisitos. Seguindo as caractersticas acima citadas e as orientaes de Machado (2008), os propsitos da identificao dos requisitos foram sintetizados em: entender como os gestores conduzem seu negcio, como funciona seu ambiente operacional, identificar quais reas de negcio e suas principais informaes e\ou indicadores so de interesse analtico e devem estar presentes no Data Warehouse. Segundo Miguel (2007), o servio de transporte aquele responsvel pela movimentao das cargas da origem ao destino, podendo ser realizado de diversos modos: rodovirio, martimo, ferrovirio e aerovirio. Dentro do processo produtivo, desde a compra da matria-prima at o consumo do produto acabado, noventa por cento do tempo utilizado na movimentao e no estoque do material. Apenas dez por cento so gastos na efetiva produo do produto final. Assim transportar mercadorias garantindo a integridade da carga, no prazo combinado e a baixo custo so elementos essenciais para sobrevivncia no mercado. Para este estudo de caso, o transporte rodovirio foi selecionado como rea de negcio prioritria a ser beneficiado pelo ambiente do Data Warehouse. Dentro do ambiente logstico, os fretes ou servios de transporte rodovirio se confirmam atravs de emisso de documentos especficos, dependendo do tipo de servio prestado. Os documentos, relativos atividade de transporte, emitidos pala Logstica Gluck que geram algum tipo de receita so: Conhecimento Transporte Rodovirio Nacional, Conhecimento de Transporte Rodovirio Internacional, Redespacho Rodovirio e Recibo Rodovirio.
49
O Conhecimento de Transporte o documento que formaliza o negcio entre o cliente e a empresa de transporte, sendo emitido pela transportadora. O conhecimento pode ser de mbito nacional ou internacional, variando conforme o modelo de transporte, como: ferrovirio, aquavirio, areo, dutovirio ou rodovirio. O Recibo um documento utilizado pelo transportador quando o transporte realizado dentro de um ambiente onde a legislao no obriga a emisso do conhecimento. Um exemplo da utilizao do recibo seria em fretes de curtas distncias dentro de uma cidade que desobriga a emisso do conhecimento de transporte. O Redespacho o contrato firmado entre transportadoras, em que um prestador de servio contratado por outra transportadora para efetuar o transporte de parte do trajeto. Com relao documentao, a empresa contratada deve emitir um conhecimento repassando a transportadora contratante. O principal desejo dos gestores averiguar a rentabilidade dos transportes de cargas realizados, atravs de diversos pontos de vista. A rentabilidade o valor resultante da receita bruta subtrada dos custos. A receita bruta a soma do valor total, cobrado pelo transporte de cargas, dos documentos emitidos, enquanto os custos so: impostos municipais, estaduais e federais; gastos com terceirizao de fretes, manuteno dos veculos, dirias de motoristas, entre outros. A receita e a despesa bem como a rentabilidade correspondente, formam o conjunto de indicadores selecionados para o diagnstico da rea de transporte de cargas. Segundo os gestores, o Data Warehouse deve responder as questes como: Quais os clientes de maior e menor rentabilidade, por filial, por tipo de documento, em determinado ano? Como a evoluo faturamento por cliente, por filial, por tipo de documento nos ltimos ano/trimetre? A evoluo da rentabilidade e despesa por cliente no ano? Quais clientes geram a maior despesa no ltimo ano e sua correspondente rentabilidade? Qual a rentabilidade de cada documento emitido dentro de em determinado perodo?
50
Conforme as interaes com a Logstica Gluck, os termos cliente, filial, despesa, tipo de documento so contextualizados da seguinte maneira: Cliente a pessoa fsica ou jurdica que contratou o transporte; As Filiais, tambm chamadas de unidades de negcio, so os postos avanados sobre os quais a empresa Gluck exerce sua gesto, sendo que a emisso de documentos de transporte individualizada por unidade de negcio; Tipo de despesa um cadastro identificando cada possibilidade de despesa em um transporte; Tipo de documento uma lista dos quatro documentos, j citados anteriormente: conhecimento de transporte rodovirio nacional, conhecimento de transporte rodovirio internacional, redespacho e recibo. De acordo com as questes dos gestores, verificou-se que existe a necessidade da analises em se se faz necessrio a obteno do valor do documento emitido, neste caso o Data Warehouse foi projetado para permitir este nvel de granularidade.
3.1.3 Ambiente Transacional Com base na rea de negcio analisada, ou seja, transporte de cargas, verificou-se que na Logstica Gluck Ltda os recibos so processados de forma distinta em relao aos redespachos e aos conhecimentos. No ambiente operacional existe um ERP responsvel por processar os redespachos e emitir os conhecimentos de cargas, tanto nacionais quanto internacionais, registrando as despesas relacionadas. Este sistema de arquitetura distribuda, utilizado tanto na matriz quanto em suas filiais e armazena seu volume transacional em um nico banco de dados, estabelecido no centro de processamento de dados da matriz, atravs do SGBD PostgreSQL. J os recibos rodovirios, em virtude de legislao municipal ou aquisio de filiais que j possuam algum tipo de sistema emissor, so documentos registrados em ferramentas e sistemas legados de diferentes fornecedores. A empresa Gluck planeja que no futuro todas as filiais passem a registrar os recibos rodovirios atravs do ERP principal da empresa, onde este estar preparado para atender as leis municipais vigentes. No entanto, atualmente foi possvel identificar a existncia de quatro plataformas distintas de fontes de dados: MS Access, Firebird, MS SQL Server e planilhas eletrnicas MS Excel. A Figura 11 apresenta o ambiente transacional.
51
Figura 11 Ambiente Transacional.
Conforme se observa na Figura 11, o ambiente transacional da empresa, com relao a rea de transporte rodovirio de cargas, composto por cinco bases de dados distintas. A primeira, denominada Fonte de dados A, armazena os documentos de redespacho e conhecimento. J as outras quatro fontes de dados, respectivamente denominadas como: Fonte de dados B, C, D e E, exclusivamente mantm registros relacionados ao recibo rodovirio.
3.2 MODELAGEM Optou-se por estruturar o ambiente atravs da modelagem multidimensional, pois, conforme a subseo 2.3.4 a abordagem mais adequada para o ambiente analtico j que resulta em um modelo de dados de fcil entendimento e de alto desempenho de acesso aos dados. Tambm de acordo com subseo 2.3.4, o mtodo para o desenvolvimento da modelagem multidimensional sugere que se deve escolher o processo de negcio que ser coberto pelo modelo, definir o nvel de detalhe ou granularidade, identificar as dimenses, e selecionar os fatos.
52
O transporte de cargas, com foco na rentabilidade foi o processo de negcio selecionado. Optou-se por utilizar nveis duais de granularidade para permitir a consolidao de documentos emitidos e satisfazer o desejo dos gestores da Logstica Gluck, j que, em determinados momentos, necessitam analisar os valores dos documentos emitidos. Como dimenses citam-se os clientes, as despesas e as receitas, as filiais e os modos de transporte. O fato central a execuo do transporte o qual possui as seguintes medidas: rentabilidade, receita e despesa, alm do nmero de lanamentos ou registros que foram agrupados. O esquema para a modelagem foi a Star Schema ou Estrela. A qual, conforme citado na subseco 2.3.4.4, agrega maior desempenho ao modelo e se define na existncia dos fatos de negcio como elementos centrais e suas dimenses, dispostas em torno. O resultado da modelagem pode ser observado no digrama Entidade Relacionamento da Figura 12.
Figura 12 Diagrama Entidade Relacionamento Transporte de Cargas
Na Figura 12 acima possvel observar a tabela fato denominada Fato_Transporte, contendo suas medidas e os apontamentos para as dimenses. Ao redor da tabela fato encontram-se as dimenses:
53
Dim_Financeiro: responsvel por armazenar as diferentes possibilidades de despesas e receitas;
Dim_Modal: Esta dimenso tem o objetivo de armazenar os quatro tipos possveis de documentos emitidos pela Gluck Transportes.
Dim_Cliente: Dimenso responsvel por concentrar informaes cadastrais de todos clientes que foram atendidos pelo servio de transporte de cargas;
Dim_Unidade: Dimenso que possui o cadastro de todas as unidades de negcio espalhadas por todo Brasil e Mercosul formando a rede de servios da Logstica Gluck;
Dim_Tempo: Esta entidade armazena o conjunto de hierarquias relativas s informaes do momento de registro das transaes provenientes do ambiente transacional, como ano, trimestre, ms, data, entre outras.
Atravs do diagrama de entidade relacionamento apresentado na Figura 11, foi possvel criar o banco de dados denominado DM_TransporteCargas, mais detalhes sobre a estrutura do banco de dados projetado podem ser observados no dicionrio de dado, que encontra-se no Apndice B do presente trabalho.
3.3 CONSTRUO DO DATA WAREHOUSE Nesta etapa o banco de dados foi construdo com base no modelo multidimensional elaborado na etapa anterior. As tabelas, os relacionamentos, os atributos e as regras do modelo foram criados nesta fase. O Data Warehouse foi construdo para residir fisicamente na matriz da Logstica Gluck, porm estar disponibilizado a todas as suas filiais. Para tanto se optou pela utilizao da arquitetura integrada, pois, conforme a subseco 2.3.1.3, os usurios de um determinado departamento tm acesso a base de dados de um Data Mart de outra rea de negcio. Aps a construo do Data Warehouse, todo o controle e administrao dos dados, incluindo a tarefa de ETL, ficar a cargo do departamento de TI.
54
A abordagem utilizada para o desenvolvimento do ambiente foi a Botton Up. Conforme a subseco 2.3.2.2, nesta tcnica os Data Marts so independentes, cada qual possui seu processo de construo individual, no sendo necessrio modelar todo o ambiente ou realizar o levantamento de todas as reas de interesse existentes na empresa antes de iniciar a execuo. Esta forma de implementao possui como caracterstica um rpido desenvolvimento, possibilitando maior velocidade de retorno ao investimento, sem impedir futuras incluses de outros Data Marts no ambiente analtico, tornando-se a abordagem mais adequada para o escopo do presente trabalho. O SGBD relacional PostgreSQL foi escolhido para armazenar o repositrio de dados, pois, alm da Logstica Gluck utilizar esta plataforma para outros projetos, ele licenciado de forma gratuita, reduzindo o custo do projeto. Durante a construo do ambiente, optou-se por aperfeioar as tarefas de consulta aos registros, pois segundo Machado (2008), o corao do processamento de um servidor de Data Warehouse est centrado na recuperao de informaes. Neste sentido foram criados ndices, mecanismos utilizados para tornar geis os acessos aos registros de alta seletividade, para cada chave estrangeira participante da tabela fato e, alm destes, tambm se criou ndices para as colunas ano e ms da dimenso Dim_Tempo, que so utilizados como filtros em grande parte das consultas do ambiente analtico.
3.4 PROCESSO ETL Segundo a subseco 2.3.5 deste trabalho, o processo de ETL tem a funo de identificar e extrair os dados das diversas fontes pertinentes rea de negcio escolhida, para posterior transformao e envio ao Data Warehouse. Ento com base no levantamento de requisitos e o estudo do ambiente transacional da Logstica Gluck foi possvel analisar a estrutura de cada base operacional, no que se refere ao transporte rodovirio de cargas. Sendo assim, foi necessrio identificar as tabelas de cada fonte operacional e como elas se relacionam, para posterior seleo dos dados que foram extrados para carregar o ambiente analtico. Conforme identificado na etapa de levantamento de requisitos, a Fonte de dados A utilizada por toda a empresa e armazena os dados dos documentos: redespachos rodovirios, conhecimento rodovirio nacional e conhecimento rodovirio internacional. Sua estrutura de tabelas, relacionadas aos documentos citados, apresentada na Figura 13.
55
Figura 13 Estrutura Fonte de dados A
Observa-se na Figura 13 o modelo operacional das tabelas de onde sero extrados os dados para o Data Warehouse. Completando o ambiente operacional, tambm foi realizado o mapeamento da estrutura das fontes B, C, D e E no que se refere ao transporte de cargas.
Figura 14 Estrutura Fontes de dados B,C,D,E
56
A Figura 14 ilustra o mapeamento da estrutura de tabelas das fontes de dados relativas ao armazenamento dos recibos rodovirios. Para extrao dos dados, este trabalho considerou as ferramentas ETL: PDI e TOS, realizando uma pesquisa avaliativa com base na lista de caractersticas importantes para seleo de uma ferramenta ETL, citadas por Gonalves (2003) e descritas na subseco 2.3.5.4. Ambas as ferramentas atenderam a maioria dos requisitos, inclusive os itens mais importantes para a elaborao deste estudo de caso, como: extrair dados de diversas fontes; conter mecanismos de transmisso de dados; permitir o gerenciamento centralizado; possuir uma interface grfica para montar as cargas de dados; gerar cdigo atravs de diagramas grficos e permitir utilizar comandos de linguagem de programao para manipulao e transformao dos dados. Ao contrrio do aplicativo PDI, que disponibiliza a linguagem JavaScript para transformao dos dados, O TOS permite utilizar a linguagem SQL. Como a linguagem SQL comum a todos aqueles que lidam com banco de dados relacionais, a curva de aprendizado, em relao utilizao do TOS para transformao de dados, menor. Desta forma, o aplicativo TOS foi escolhido devido ao conhecimento prvio quanto linguagem utilizada para a transformao de dados. A Figura 15 exibe a possibilidade de se trabalhar com linguagem SQL dentro da ferramenta Talend Open Studio.
Figura 15 TOS SQL
57
O Data Warehouse se beneficiou do mecanismo de Staging Area, ou seja, uma armazenagem intermediria de dados cuja funo agilizar o processo de consolidao de dados provenientes de diversas fontes, proporcionando melhor desempenho na fase de tratamento das informaes operacionais. Assim, os dados brutos foram coletados carregados primeiramente para este componente, onde ocorreram as devidas limpezas e transformaes. A transformao dos dados procurou resolver conflitos de modelagens realizando a padronizao das informaes. Aplicou-se um grande esforo nos conflitos estruturais, onde foi necessrio padronizar o formato das datas, retirar os caracteres invlidos de informaes relativas a documentos como CNPJ, transformar o valor dos conhecimentos internacionais em reais e unir informaes de clientes fsicos e jurdicos para formar-se a dimenso de clientes. Alm disso, tambm houve a necessidade de acrescentar os dados cadastrais da unidade emitente que utiliza a Fonte B - planilha eletrnica, j que a ela no possua tais informaes. Em um segundo momento, procedeu-se a agregao e o carregamento das tabelas que compe o Data Mart. As cargas incrementais, aquelas que ocorrero a cada ms, tambm utilizaro a mesma tcnica de carga em duas etapas. A Figura 16 apresenta o do processo de ETL utilizando Staging Area.
Figura 16 Fluxo ETL
58
Conforme pode ser visualizado na Figura 16, a extrao de dados ocorre das fontes operacionais para a Staging Area e desta para o Data Mart. Para esta tarefa utilizou-se o mtodo de captura dinmica citado na subseco 2.3.5.1. Esta tcnica tem o objetivo de somente extrair os dados que foram inseridos e atualizados desde a ltima coleta, para isso se valer de informaes data\hora que controlam alteraes e incluses de registros. A Staging Area possui uma coluna para identificar a fonte de origem e a data\hora de carga dos dados. A partir desta informao gravada, a prxima extrao ir capturar apenas os registros inseridos ou alterados em data\hora superior. O Carregamento do Data Mart ocorreu conforme subseco 2.3.5.3, que indica alguns procedimentos que devem ser executados durante o carregamento de um Data Warehouse. Entre os procedimentos citados, este trabalho realizou: a criao da imagem de carga; desligou os ndices da base de dados, porm, conforme indicado, no a integridade referencial. Em seguida realizou o processo de carregamento procedendo com a reativao dos ndices. Na primeira carga do ambiente, extraiu-se mais de cinco milhes de registros das fontes operacionais, estes foram agregados resultando em um milho de registros na tabela, ocupando um espao em disco de trezentos mega bytes.
3.5 CONFECO DE RELATRIOS Conforme as necessidades apontadas, na etapa inicial deste estudo de caso, foram desenvolvidos relatrios com base nas informaes provenientes do Data Warehouse. Para que assim consiga-se obter um meio simples e claro de visualizar e avaliar as informaes contidas no ambiente construdo. Os relatrios exibem informaes que atendam s necessidades dos gestores, portanto, nesta fase, podem ocorrer interaes at que o relatrio cumpra com seu objetivo. Para esta etapa a tecnologia utilizada foi Crystal Reports, ferramenta de fcil manuteno, com longa tradio no mercado de desenvolvimento de relatrios, alm disso, j utilizada no ambiente da Logstica Gluck. Em seguida esto listados os relatrios desenvolvidos: Rentabilidade_Total_Empresa: Permite a visualizao das informaes Receita, Despesa e o Percentual de rentabilidade para cada ano e trimestre. Alm disso,
59
pode-se se invocar os relatrios de clientes, Unidades ou Documentos que trazem os dados do o ano selecionado. A Figura 17 apresenta a emisso do relatrio.
Figura 17 Relatrio Rentabilidade Total
Rentabilidade_Total_Empresa_Cliente: Relatrio acessado atravs do relatrio Rentabilidade_Total_Empresa. Ele exibe a Receita, a Despesa e o Percentual de rentabilidade para cada ano dos clientes conforme ordem de seleo, ou seja, atravs deste relatrio possvel analisar os clientes de menor e maior rentabilidade dentro de um determinado ano.
60
Rentabilidade_Total_Empresa_Unidade: Relatrio acessado atravs do relatrio Rentabilidade_Total_Empresa. Ele exibe a Receita, a Despesa e o Percentual de rentabilidade para o ano selecionado das unidades de menor e maior rentabilidade conforme os critrios de seleo. Na Figura 18 possvel visualizar a emisso deste relatrio.
Figura 18 Relatrio Rentabilidade Unidade
Rentabilidade_Total_Empresa_Documento:
Relatrio
invocado
atravs
do
relatrio Rentabilidade_Total_Empresa. Ele apresenta a Receita, a Despesa e o Percentual de rentabilidade para o ano selecionado. Rentabilidade_Evolucao: Este relatrio permite que se entre com a identificao da unidade, do cliente ou do documento. Alm disso, possvel informar o ano inicial
61
e final e tambm o trimestre inicial e final. Este relatrio permite que se analise a evoluo da rentabilidade do cliente, unidade ou documento informado. Dentro dos dados exibidos possvel descer ao nvel mensal de informao. A Figura 19 apresenta a emisso do relatrio Rentabilidade_Evoluo.
Figura 19 Relatrio Rentabilidade Evoluo
Rentabilidade_Evolucao_Mes:
Relatrio
acessado
atravs
do
relatrio
Rentabilidade_Evolucao. Ele permite ver os dados mensais de Receita, Despesa e o Percentual de rentabilidade do cliente, unidade ou documento conforme ano e trimestre selecionado. Rentabilidade_Documentos_Ano_Mes: Relatrio que mostra as informaes de Receita, Despesa e o Percentual de rentabilidade para cada documento registrado dentro do perodo informado.
62
4. VALIDAO
Este captulo tem como objetivo avaliar o ambiente analtico construdo pelo presente trabalho. Desta forma, foram coletados dados para que seja verificado se o Data Warehouse resultou em um armazm de dados organizado e acessvel, com as informaes necessrias gesto do negcio em questo, suportando de forma mais calculada e precisa a tomada de deciso. Para tanto, o presente captulo compe-se de duas partes: a primeira retrata os itens a serem validados e a segunda parte descreve os resultados obtidos.
4.1 ITENS VALIDADOS A tomada de deciso segura e calculada implica na obteno de um diagnstico de qualidade sobre o negcio. Os ambientes analticos objetivam minimizar o risco e potencializar a eficcia decisria. Portanto a qualidade do Data Warehouse determinante para o cumprimento do seu papel funcional. Inmon (1997) descreve a reviso de projeto como uma das mais eficientes tcnicas para garantia da qualidade no ambiente analtico. Conforme o autor, atravs desta tcnica, erros podem ser detectados resultando na economia da quantidade de recursos, reduo da manuteno e aumento da satisfao do usurio. A reviso do projeto, proposta por Inmon, composta de cinqenta e quatro questes dispostas em formato de check-list. J para Adelman (2002), o grau de sucesso de um Data Warehouse pode ser obtido atravs da anlise de suas caractersticas implcitas e explcitas. O autor cita algumas caractersticas que podem ser avaliadas como: usabilidade, desempenho, qualidade dos dados, satisfao do usurio, custos, benefcios e disponibilidade do sistema. Neste sentido, a avaliao deste trabalho ocorreu atravs de trs perspectivas: reviso do projeto, anlise da qualidade dos dados e a coleta do nvel de satisfao do usurio. A escolha das ltimas duas se deu em virtude da relao que elas possuem com os objetivos principais do presente trabalho que so: a integrao do ambiente heterogneo e a construo de um Data Warehouse que atendesse aos requisitos da Logstica Gluck
63
Para a reviso do projeto utilizou-se uma adaptao do check-list criado por Inmon (1997), a fim de aferir o cumprimento, pelo projeto executado, dos itens importantes na construo de qualquer Data Warehouse. A anlise da qualidade dos dados foi averiguada atravs do levantamento de mtricas desenvolvidas por Costa (2006). J o nvel de satisfao do usurio foi verificado atravs da aplicao de um questionrio envolvendo afirmaes relacionadas aos requisitos iniciais, bem como a utilizao e os benefcios do ambiente construdo.
4.1.1 Reviso do Projeto Conforme j descrito anteriormente, o check-list proposto por Inmon (1997) compese de cinqenta e quatro questes. Porm, para o escopo deste trabalho, foram extradas aquelas relacionadas cobertura dos aspectos de construo do projeto de Data Warehouse. So elas: Os requisitos do usurio foram levantados? Segundo Inmon (1997), O levantamento de requisitos constitui em um exerccio saudvel que deve ser executado, pois atravs dele identifica-se a granularidade e quais processamentos precisam ser realizados em cima dos dados operacionais. Quantas reas de interesse foram identificadas no modelo de dados? Quantas foram implementadas? - Segundo Inmon (1997), o ambiente de Data Warehouse implementado no ritmo de um assunto por vez, desta forma se faz necessria esta verificao. As reas de interesse que foram identificadas foram divididas em nveis de mais baixos de detalhe? As chaves foram identificadas? Os atributos foram identificados? Segundo Inmon (1997), atravs destes itens, averiguada a existncia de um modelo de dados que funcionou como centro intelectual do ambiente. A fonte de cada atributo foi identificada? As condies sob as quais um atributo ou outro constituir a fonte foram identificadas? Caso no exista a fonte para um atributo, os valores padro foram identificados? Uma medida comum de valores de atributos foi identificada para os atributos contidos no ambiente de Data
64
Warehouse. Uma estrutura de chave comum para o ambiente foi identificada?Segundo Inmon (1997), atravs destes aspectos, constata-se o quanto a integrao do ambiente operacional foi realizada. Verificando a existncia de um projeto de ETL. A freqncia de processamento de extrao foi identificada? Como vai funcionar? Segundo Inmon (1997), a freqncia do processamento de extrao constitui um problema em funo da complexidade. A determinao de quais dados devem ser varridos pelo processo de extrao impacta na utilizao do Data Warehouse. Qual o nvel de granularidade dos dados do Data Warehouse? - Segundo Inmon (1997), esta uma das questes mais importantes, j que outros aspectos dependem do estabelecimento do nvel de granularidade. Desta forma imprescindvel que este item esteja em conformidade.
4.1.2 Qualidade dos Dados Conforme Adelman (2002), os dados existentes no Data Warehouse suportam tecnicamente a deciso e por isso, a sua qualidade determinante como forma de fomentar a confiana dos gestores. Costa (2006) relata que a gesto da qualidade das informaes deve seguir como orientao principal a adequao dos dados ao uso na tomada de decises. O autor define aspectos importantes relacionados qualidade dos dados e apresenta as possveis mtricas relacionadas. Ao ambiente desenvolvido foram aplicadas as seguintes mtricas: Exatido: A exatido corresponde ao armazenamento correto dos fatos ou valores do mundo real. Ela pode ser analisada segundo trs vetores: o nvel sinttico, o nvel semntico e o nvel de contedo. O primeiro aspecto refere-se ao tipo e domnio dos dados. O segundo aspecto ocupa-se de questes relativas integridade referencial e s regras de negcio. Por fim, o nvel de contedo consiste no armazenamento efetivo do valor real. As mtricas sobre a exatido objetivam avaliar os dados existentes no repositrio do Data Warehouse. A Tabela 4 apresenta as mtricas elaboradas por Costa (2006).
65
Tabela 4. Mtricas para Exatido
Adaptado: Costa (2006)
Completude: A completude dos dados consiste na captura dos dados do mundo real necessrios para a execuo das atividades. Assim, no pode ocorrer ausncia de valores necessrios para a tomada de deciso. A Tabela 5 apresenta as mtricas elaboradas por Costa (2006) relacionadas a completude.
Tabela 5. Mtricas para Completude
Adaptado: Costa (2006)
Relevncia: A relevncia est relacionada utilidade dos dados para tomada de deciso. Os dados devem ser aplicveis e teis, pois de outro modo, deixaria de fazer sentido possuir um Data Warehouse composto por informao irrelevante. Os dados irrelevantes so responsveis pelo desinteresse pelo sistema e na obstruo a um desempenho das consultas. A Tabela 6 apresenta as mtricas elaboradas por Costa (2006) relacionadas a relevncia.
Tabela 6. Mtricas para Relevncia
Fonte: Costa (2006)
66
Acessibilidade: A acessibilidade dos dados respeita disponibilidade destes para consulta por parte dos consumidores. Certamente, um Data Warehouse pode encontrar-se inacessvel por diferentes motivos, como as falhas do sistema ou as atualizaes dos dados. Desta forma objetiva-se minimizar a ocorrncia das falhas inesperadas e reduzir a indisponibilidade por razes de atualizaes aos dados. A Tabela 7 apresenta as mtricas elaboradas por Costa (2006) relacionadas a acessibilidade.
Tabela 7. Mtricas para Acessibilidade
Fonte: Costa (2006)
4.1.3 Satisfao do Usurio Segundo Adelman (2002), o nvel de satisfao do usurio pode ser obtido comparando as expectativas iniciais e os resultados atingidos. Neste sentido foi confeccionada uma pesquisa de campo. Atravs da utilizao de um questionrio, que encontra-se no Apndice C do presente trabalho, como instrumento para o levantamento de dados. Buscou-se indagar os gerentes sobre atendimento aos requisitos iniciais e o impacto da utilizao do Data Warehouse sobre a gesto do transporte rodovirio de cargas na Logstica Gluck. O questionrio foi aplicado aos trs gestores da Logstica Gluck Ltda. Eles possuem domnio do negcio de transporte e esto envolvidos neste estudo de caso desde seu incio. Os gestores realizaram a avaliao do ambiente construdo com relao as suas expectativas e necessidades, e o quanto aos benefcios produzidos pela utilizao das informaes extradas do Data Warehouse. O processo de coleta de dados ocorreu em duas etapas. Na primeira etapa, os gestores utilizaram o Data Warehouse durante duas semanas. Neste perodo realizaram as tarefas de anlise sobre a rentabilidade do transporte rodovirio de cargas, apoiando-se nos relatrios confeccionados na seo 3.5 do presente trabalho. A ordem de navegao entre os relatrios e as escolhas dos parmetros ficou a cargo de cada gerente, a fim de que fosse utilizado o
67
ambiente de forma natural, equiparando-se ao uso normal que o ambiente analtico teria, caso tivesse sido adquirido pela Logistica Gluck Ltda. No houve a necessidade de elaborao de guia de manuseio por dois motivos: o primeiro est relacionado ferramenta relatrio que muito comum para os gestores sendo parte do seu dia-a-dia, e o segundo motivo foi o grande desejo, por parte dos executivos, de encontrar as respostas sobre suas dvidas relacionadas rentabilidade neste novo ambiente. Aps estas duas semanas iniciou-se a segunda etapa - a coleta de dados - onde cada gestor participante recebeu uma cpia do questionrio, preenchendo-o no prazo mximo de cinco dias.
4.2 RESULTADOS OBTIDOS Nesta seo esto representados os resultados obtidos atravs dos mtodos de avaliao citados anteriormente, so eles: o conjunto de mtricas sobre os dados, o Check-list do projeto e o questionrio de satisfao do usurio. Os dados finais do Check-list e das mtricas sero apresentados em forma de tabelas, sendo que as informaes sobre as mtricas foram coletadas de forma bruta em um primeiro momento para ento se extrair os dados percentuais resultando em trs tabelas. J as respostas coletadas atravs do questionrio de satisfao foram tabuladas, sendo seus resultados apresentados em forma de grficos do tipo pizza. Os dados coletados para avaliao do projeto construdo podem ser observados na Tabela 8. As questes que estavam agrupadas foram desmembradas em itens e subitens a fim de facilitar a tabulao. A grande parte das respostas encontra-se transcrita no corpo do presente trabalho.
68
Tabela 8. Check-list Projeto
Questo
1.0 2.0 2.1 3.0 3.1 3.2 4.0 4.1 4.2 4.3 4.4 4.5 5.0 5.1 6.0 Os requisitos do usurio foram levantados? Quantas reas de interesse foram identificadas no modelo de dados? Quantas foram implementadas? As reas de interesse que foram identificadas foram divididas em nveis de mais baixos de detalhe? As chaves foram identificadas? Os atributos foram identificados? A fonte de cada atributo foi identificada? Uma medida comum de valores de atributos foi identificada para os atributos contidos no ambiente de Data Warehouse? As condies sob as quais um atributo ou outro constituir a fonte foram identificadas? Caso no exista a fonte para um atributo.os valores padro foram identificados? Uma medida comum de valores de atributos foi identificada para os atributos contidos no ambiente de Data Warehouse? Uma estrutura de chave comum para o ambiente foi identificada? A freqncia de processamento de extrao foi identificada? Como vai funcionar a extrao? Qual o nvel de granularidade dos dados do Data Warehouse?
Reposta
SIM UMA UMA SIM SIM SIM SIM SIM SIM SIM SIM SIM SIM MENSALMENTE DUAL
69
As respostas para as questes apresentadas na Tabela 8 foram obtidas atravs das atividades ocorridas durante o desenvolvimento do presente trabalho. Deste modo as questes 1.0 e 2.0 foram respondidas conforme as informaes descritas na seo 3.1, Levantamento de Requisitos. J as respostas para questo 2.1 e para questo 6.0 foram extradas da seo 3.2, Modelagem. As questes 3.0 e 3.1 foram respondidas com base nos itens descritos na seo 3.3, Construo do Data Warehouse. As atividades que ocorreram durante a etapa de ETL, seo 3.4, Processo de ETL, permitiram responder o intervalo compreendido entre a questo 3.2 e a questo 5.1. As mtricas sobre a qualidade dos dados foram divididas em trs tabelas. A Tabela 9 exibe aquelas que possuem relao geral com o Data Warehouse, j a Tabela 10 e Tabela 11 apresentam as mtricas aplicadas a cada tabela do banco de dados que compe o ambiente.
Tabela 9. Mtricas Gerais Mtricas Gerais Percentual de tempo que o Data Warehouse se encontra inopervel por falhas. Percentual de tempo que o Data Warehouse se encontra inopervel por atualizaes de dados. 0% 0,5%
Conforme pode ser observado na Tabela 9, as mtricas nela contidas tratam da inoperabilidade do Data Warehouse. Como no houve relato de falha do ambiente o percentual de tempo inopervel por alguma falha foi descrito como zero. J a inoperabilidade por atualizao dos dados foi obtida com base na previso de uso mensal, em horas, do ambiente analtico em relao ao tempo transcorrido para execuo da rotina de carga do Data Warehouse. Na Tabela 10 pode-se observar a aplicao das mtricas sobre os dados das tabelas dimenses.
70
Tabela 10. Mtricas Dimenses
Mtricas\Tabelas Percentual de linhas ou colunas que pertencem ao domnio de dados Percentual de linhas semi-vazias Percentual de linhas corretas comparadas ao valor real Percentual de colunas que nunca so resultados de respostas Porcentagem dos registros carregados com sucesso Percentual de linhas no estruturadas hierarquicamente nas dimenses Percentual de linhas que contm chaves estrangeiras nas dimenses
dim_modal dim_unidade dim_cliente dim_financeiro dim_tempo
100%
100%
100%
100%
100%
0%
16%
27%
0%
0%
100%
100%
95%
100%
100%
0%
60%
72%
20%
12%
100%
100%
100%
100%
100%
0%
0%
0%
0%
0%
0%
0%
0%
0%
0%
J a Tabela 11 exibe as mtricas aplicadas tabela fato.
71
Tabela 11. Mtricas Fato
Mtricas\Tabelas Percentual de linhas ou colunas que pertencem ao domnio de dados Percentual de linhas semi-vazias Percentual de linhas corretas comparadas ao valor real Percentual de colunas que nunca so resultados de respostas Porcentagem dos registros carregados com sucesso Percentual de linhas no estruturadas hierarquicamente nas dimenses Percentual de linhas que contm chaves estrangeiras nas dimenses
fato_transporte 100% 0% 95% 11% 100% No se aplica No se aplica
Em ambas as tabelas, Tabela 10 e Tabela 11, as mtricas foram coletadas da seguinte forma: o percentual de linhas ou colunas que pertencem ao domnio de dados foi obtido atravs da anlise do tipo de dado de cada coluna das tabelas e o tipo da correspondente informao gravada. O percentual de linhas semi-vazias foi coletado comparando-se o nmero total de registros nas tabelas e o nmero de registros que se encontram com alguma coluna vazia. O percentual de linhas corretas comparadas ao valor real foi extrado da anlise do contedo de cada coluna em relao a representao da informao no mundo real. O percentual de colunas que nunca so resultados de respostas foi obtido comparando-se o nmero total de colunas de cada tabela com a quantidade de colunas que no so utilizadas pelos relatrios confeccionados. O percentual dos registros carregados com sucesso foi alcanado atravs da verificao dos arquivos de log da ferramenta de ETL. As mtricas, o percentual de linhas no estruturadas hierarquicamente nas dimenses e o percentual de linhas que contm chaves estrangeiras nas dimenses, se aplicam somente as tabelas de dimenses. Para a primeira foi verificado o nmero de registros carregados de forma a no respeitar a hierarquia de informaes em relao ao total de registros de cada dimenso. J para obteno da segunda, verificou-se a quantidade de registros das dimenses que apontam para outra dimenso.
72
Quanto ao questionrio aplicado aos gerentes da Logstica Gluck, suas respostas foram agrupadas e tabuladas. O resultado de cada questo est representado a seguir:
1.1-O Data Warehouse, atravs de seus relatrios, permitiu que os dados das fontes operacionais pudessem ser visualizados de forma consolidada. A Figura 20 representa a opinio da amostra com relao a presente questo.
Figura 20 Grfico Questo 1.1
1.2-Foi possvel ter acesso s informaes das unidades de negcio que possuam diferentes fontes operacionais para registrar os recibos rodovirios. A Figura 21 representa a opinio da amostra com relao a presente questo.
73
1.3-O Data Warehouse proporcionou averiguar os clientes de maior e menor receita, como tambm sua evoluo ao longo de um perodo. A Figura 22 representa a opinio da amostra com relao a presente questo.
1.4-Foi possvel descobrir as unidades de negcio de maior e menor rentabilidade, possibilitando o acesso evoluo da receita ao longo dos anos. A Figura 23 representa a opinio da amostra com relao a presente questo.
74
1.5-O ambiente analtico foi capaz de exibir, atravs dos relatrios, as receitas e as despesas referentes a cada modalidade de transporte de cargas. A Figura 24 representa a opinio da amostra com relao a presente questo.
1.6-Foi possvel visualizar a receita, a rentabilidade e a despesa ao nvel do documento emitido. A Figura 25 representa a opinio da amostra com relao a presente questo.
75
1.7-A forma de visualizao das informaes do Data Warehouse, atravs dos relatrios construdos, atente a todas as necessidades de anlise da rentabilidade do transporte de cargas. A Figura 26 representa a opinio da amostra com relao a presente questo.
2.1-O ambiente construdo facilitou a anlise da rentabilidade da rea de negcio transporte rodovirio, pois se props em extrair a informao integrada. A Figura 27 representa a opinio da amostra com relao a presente questo.
76
2.2-A anlise da rentabilidade tornou-se mais eficiente e rpida em relao a como era realizada antes da existncia do ambiente analtico. A Figura 28 representa a opinio da amostra com relao a presente questo.
2.3- possvel fomentar, atravs das informaes extradas do Data Warehouse, estratgias quanto a polticas de descontos para determinados clientes ou investimento em determinadas unidades de negcio que hoje possuem baixa rentabilidade. A Figura 29 representa a opinio da amostra com relao a presente questo.
77
Alm das perguntas quantitativas, citadas anteriormente, o questionrio aplicado aos gestores da Logistica Gluck possua uma questo descritiva. A questo 2.4 tinha o seguinte enunciado: Cite alguns exemplos caso as informaes extradas do Data Warehouse possam contribuir para tomada de outras decises. Foram coletadas as seguintes respostas: A possibilidade de investimento nas operaes dos clientes mais rentveis; A verificao da necessidade de se diminuir a despesa nas unidades de maior receita.
78
5. DISCUSSO DE RESULTADOS
Este captulo tem o objetivo de discutir os resultados coletados e apresentados no captulo 4. Neste sentido divide-se em trs partes conforme as perspectivas de avaliao: Reviso do Projeto, Qualidade dos Dados e a Satisfao do Usurio.
5.1 REVISO DO PROJETO A reviso do projeto foi realizada atravs da aplicao de um check-list, descrito no captulo 4. Conforme o resultado apresentado anteriormente na Tabela 11 observa-se que o projeto realizado est em conformidade com os itens do check-list aplicado. A conformidade com a questo 1.0 indica que houve o levantamento dos requisitos junto aos usurios, demonstrando ateno s necessidades dos gestores da Logstica Gluck. Alm disso, as conformidades em relao s questes 2.0 e 2.1 mostram que houve a identificao e implementao da rea de interesse da empresa, seguindo o ritmo indicado por Inmon (1997), onde se implementa um assunto de cada vez dentro do ambiente analtico. Os resultados das questes 3.0, 3.1, 3.2, 4.5 e 6.0 tambm se mostraram conformes, assim retratam a elaborao de um modelo lgico, que suportou a construo do ambiente. Finalizando o check-list, as questes 4.0, 4.1, 4.2, 4.3, 4.4, 5.0 e 5.1 tambm atestaram conformidade, desta forma realizou-se o levantamento dos principais aspectos da etapa de ETL, o que facilitou execuo do processo de integrao. Atendendo positivamente aos aspectos expostos no Check-list, atesta-se a existncia de um projeto que contemplou as principais atividades necessrias para se projetar a construo do Data Warehouse. Desta forma verifica-se que aspectos importantes foram identificados e projetados antes da construo do ambiente analtico. E, assim, evitou-se uma srie de problemas ou dvidas que poderiam surgir durante a etapa de construo, agregando maior qualidade ao DW.
79
5.2 QUALIDADE DOS DADOS A avaliao da qualidade dos dados realizou-se atravs do levantamento de um conjunto de mtricas descritas no captulo 4. Com relao aos resultados obtidos na aplicao das mtricas gerais, observou-se, segundo a Tabela 8, um percentual baixo de inoperabilidade. Sendo que apenas 0.5% do tempo total de uso mensal estaro inoperveis, pois o tempo reservado a tarefa de carregamento do Data Warehouse. J as mtricas aplicadas s dimenses, demonstraram que grande parte dos resultados obtidos encontra-se prxima ao ideal. Porm conforme se observou na Tabela 9, as mtricas Percentual de linhas semi-vazias e Percentual colunas que nunca so resultados de respostas foram aquelas em que seus valores mais se distanciaram do ideal. Destacam-se, especialmente, as dimenses dim_unidade e dim_cliente, que alcanaram o percentual de 60% e 75%, respectivamente, no que se refere ao nmero de colunas que nunca foram usados em consultas, sendo que o valor esperado de 0 %. Este fato explica-se pelo processo de modelagem que planejou essas duas dimenses com todas as caractersticas possveis constantes no ambiente operacional, porm a maioria das informaes no so utilizadas para a extrao dos atuais relatrios. J averiguao da mtrica relacionada ao percentual de linhas semi-vazias encontrou valores distntes do ideal. Este fato deve-se s informaes incompletas relativas ao endereo provenientes das fontes de dados D e E. As mtricas aplicadas tabela fato_transporte, em sua maioria, obtiveram resultados dentro dos valores ideais. Porm, conforme se observou na Tabela 10, destacam-se as mtricas Percentual de linhas corretas comparadas ao valor real e Percentual de colunas que nunca so resultados de respostas que apresentaram valores de 95% e 11%, respectivamente. Os registros possuidores de valores no corretos em comparao ao valor do mundo real se caracterizam pela existncia de valor de receita de frete de R$ 0,01 e somam 5% dos registros totais da tabela fato_transporte. Dificilmente no mundo real um frete custaria to pouco, porm, de acordo com a Logstica Gluck isto um procedimento interno para a concesso de descontos, no qual alm de transportar, ela tambm realiza o armazenamento da mercadoria, possuindo assim um maior ganho com a segunda atividade. J em relao aos 11% obtidos na mtrica Percentual de colunas que nunca so resultados de respostas se deve a existncia da coluna quantidadelancamentos, que pode ser visualizada no Apndice
80
B do presente trabalho. Esta coluna no utilizada atualmente pelos relatrios confeccionados, porm armazena o nmero de lanamentos originrios do ambiente operacional que foram agrupados em cada registro da tabela fato_transporte. Conforme as anlises anteriores, as mtricas Percentual de colunas que nunca so resultados de respostas e Percentual de linhas semi-vazias foram aquelas que mais se distanciaram do valor ideal. Desta forma, das nove mtricas analisadas duas apresentaram sensvel variao em relao ao valor ideal. J as outras sete mtricas alcanaram o valor esperado ou obtiveram resultados prximos, demonstrando, de modo geral, a qualidade dos dados armazenados no Data Warehouse, mesmo com ressalva para o armazenamento de informaes desnecessrias.
5.3 SATISFAO DO USURIO A avaliao da satisfao do usurio realizou-se atravs da aplicao de um questionrio, o qual teve seus resultados foram apresentados no captulo 4. Este questionrio buscou averiguar se o ambiente construdo obteve sucesso em: atender aos requisitos iniciais, satisfazer as necessidades de visualizao das informaes, agregar maior poder de diagnstico e de tomada de deciso aos gestores da empresa em que se realizou este estudo de caso. O conjunto das questes 1.1 1.7 so relativas ao atendimento aos requisitos iniciais e utilizao do ambiente. J as questes 2.1 2.4 tem o propsito de avaliar o possvel impacto do Data Warehouse na Logstica Gluck. Com relao ao atendimento aos requisitos possvel observar atravs dos grficos apresentados no captulo 4 que os gestores se mostraram satisfeitos, porm com relao questo 1.6 houve uma leve insatisfao. Da amostra analisada, 33% consideram-se parcialmente satisfeitos. Isto se deve ao relatrio confeccionado para o atendimento deste requisito. O relatrio denominado
Rentabilidade_Documentos_Ano_Mes, apresentado na subseo 3.5, exibe a listagem de todos os documentos emitidos dentro de um determinado perodo, possibilitando a gerao de um grande volume de informao. Dificultando a analise gerencial. A questo 1.7 trata especificamente de avaliar a forma de visualizao das informaes. Na Figura 26, verificou-se um alto grau de insatisfao, j que do total de
81
gestores que responderam ao questionrio 33% consideraram-se parcialmente satisfeitos e 67% consideraram-se insatisfeitos. Este descontentamento se deve ao fato de que os relatrios exigem parmetros que devem ser previamente informados, dificultando a livre navegao dos gestores no que se refere a obter respostas das dvidas ocorridas durante o processo de a anlise das informaes. Conforme os grficos apresentados no captulo 4, referentes s questes relativas ao impacto positivo do Data Warehouse na Logstica Gluck, foi possvel verificar que: a questo 2.1 referente ao benefcio da anlise integrada das informaes toda a amostra considerou-se satisfeita, o mesmo comportamento pode ser averiguado no grfico referente a questo 2.3 que indagou os gestores sobre a possibilidade de se tomar alguma deciso baseando-se nas informaes extradas do ambiente analtico. Como exemplo foram citadas algumas decises possveis de serem realizadas conforme os resultados obtidos na questo 2.4, descritas no capitulo 4. Porm na questo 2.2 houve certa insatisfao da amostra. Conforme a Figura 28, 100% dos gerentes consideram-se parcialmente satisfeitos com o aumento da performance obtida nas tarefas analticas proporcionado pelo Data Warehouse. A insatisfao apresentada est diretamente relacionada ferramenta de visualizao das informaes que, como relatado anteriormente, no permitiu que os gerentes explorassem recursos dinmicos de anlise agregando maior poder e agilidade s tarefas analticas. Conforme as anlises descritas acima foram aplicadas dez questes optativas, das quais os gerentes consideraram-se satisfeitos em sete questes, parcialmente satisfeitos em duas questes e insatisfeitos apenas com uma questo. Neste sentido pode-se afirmar que houve insatisfao com relao ao uso dos relatrios, porm em ltima anlise o ambiente construdo satisfez seus usurios, j em 70% das questes obteve-se o resultado satisfatrio.
82
6. CONCLUSO
Este trabalho abordou o tema Data Warehouse, onde foi construdo um ambiente analtico com base nos registros transacionais sobre a rea de transporte rodovirio de cargas da empresa Logstica Gluck Ltda, transpondo o grande desafio de integrar informaes provenientes de um ambiente operacional heterogneo. Uma vez discutidos e analisados os resultados obtidos atravs dos instrumentos de validao do presente trabalho, conclui-se que o Data Warehouse construdo atendeu, de forma satisfatria, todos os requisitos da empresa onde ele foi aplicado. Tambm possvel afirmar que o ambiente construdo cumpriu seus objetivos de suportar e fomentar as tarefas analticas atravs de um ambiente integrado e padronizado transformando dados provenientes de inmeras fontes em informao. Porm a avaliao da qualidade dos dados identificou uma deficincia no modelo do ambiente, onde foram extradas algumas informaes que no foram utilizadas pelas consultas dos gerentes da empresa Gluck, ou seja, agregou-se um volume de informao desnecessria ao Data Warehouse. Alm disso, conclui-se que a visualizao de informaes gerenciais atravs de relatrios estticos no foi bem recebida pelos gerentes, tornando-se uma lacuna no trabalho desenvolvido. Desta forma, possvel identificar melhorias que no foram tratadas em virtude do prazo ou do escopo. Essas melhorias agregariam maior valor ao trabalho desenvolvido. Constatou-se a necessidade de no apresentar as informaes atravs de relatrios estticos e sim agregar players em que os usurios possam interagir dinamicamente tornando as tarefas analticas mais poderosas, bem como, deve-se eliminar as informaes desnecessrias do Data Warehouse. Alm disso, neste trabalho utilizou-se a abordagem incremental para a construo do Data Warehouse, desta forma sugere-se a implantao de mais reas de negcios dentro do ambiente construdo. Configurando novas possibilidades de trabalhos futuros.
83
REFERNCIAS
ADELMAN, S. Measuring the Effectiveness of Your Data Warehouse. Principal Sid Adelman & Associates. 2002. BARROS, Aidil Jesus da Silveira; LEHFELD, Neide Aparecida de Souza. Fundamentos de Metodologia Cientfica. 3 ed. So Paulo: Pearson Prentice Hall, 2007. BISPO, Carlos Alberto Ferreira. Uma Anlise da Nova Gerao de Sistemas de Apoio Deciso. So Carlos: 1998. Dissertao de Mestrado - Escola de Engenharia de So Carlos, Universidade de So Paulo. Disponvel em:
<http://www.teses.usp.br/teses/disponiveis/18/18140/tde-04042004152849/publico/dissertacao_carlos.pdf> Acesso em 03 de Abr. 2010. CIELO, Iv. ETL - Extrao, Transformao e Carga de Dados. Obtida via internet. ltimo acesso: 01 de Mai. 2010. <http://www.datawarehouse.inf.br/etl.htm> COSTA, Alexandre Manuel Pereira Mendes da. A Gesto da Qualidade dos Dados em Ambientes de Data Warehousing na Prossecuo da Excelncia da Informao. Braga: 2006. Dissertao de Mestrado Universidade do Minho. Disonvel em: < http://repositorium.sdum.uminho.pt/bitstream/1822/6760/1/2006-isserta%c3%a7%c3%a3oAlexandre-Costa-VF.pdf> Acesso 30 de Out. 2010. COSTA, Gerson Frederico da. Sistemas de Informao Baseado em Data Warehouse Aplicado na Contabilidade Gerencial. Blumenau: 2002. Trabalho de Concluso de Curso Universidade Regional de Blumenau. Disponvel em:
< http://www.classecontabil.com.br/trabalhos/TCC2002-1-37-VF-GersonFCosta.doc> Acesso em 04 de Abr. 2010.
84
CRIVELINI, Wagner. Mitos e Verdades sobre Modelagem Multidimensional. SQL Magazine. Rio de Janeiro, ano 3, 39 ed., p.6-14, 2006. CRUZ, Jivarlos Pereira Silva da. Ferramentas De Extrao E Carga (ETL): Estudo de caso comparativo. Joo Pessoa: 2009. Trabalho de Concluso de Curso Centro Universitrio de Joo Pessoa - UNIP. GONALVES, Marcio. Extrao de Dados para Data Warehouse. Rio de Janeiro: Axcel, 2003. GOMES, Ademar. Tutorial Kettle - Pentaho Data Integration. Obtida via internet. ltimo acesso: 01 de Mai. 2010. <http://www.ademargomes.com/index.php/ artigos/56-
turialkettle.html> IMASTERS, Modelo Dimensional para Data Warehouse. 2006. Disponvel em <http://imasters.uol.com.br/artigo/3836/bi/modelo_dimensional_para_data_warehouse/> Acesso em 11 de Mai. 2010 INMON, William H. Como Construir o Data Warehouse. 2. ed. Rio de Janeiro: Campus, 1997. KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Tollkit. 2. ed. New York: John Wiley & Sons, 2002. LACY, Miguel Koren OBrien. O Talento do Talend. Linux Magazine. 50 Ed. p.62-67, 2009. Obtida via internet. ltimo acesso em 12 de Mai. 2010. Disponvel em: <http://www.linuxmagazine.com.br>. MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse. 4. ed. So Paulo: rica, 2008. MIGUEL, Paulo Augusto Cauchick. Estudo de caso na engenharia de produo: estruturao e recomendaes para sua conduo. 2007, Disponvel em
<http://www.scielo.br/scielo.php?pid=S010365132007000100015&script=sci_arttext&tlng=em> Acesso em 15 de Mai. 2010.
85
PENTAHO. Pentaho Data Integration. Obtida via internet. ltimo acesso em 02 de Mai. 2010. Disponvel em: <http://pentaho.org>. PETUCO, Gelson. Data Warehouse. 2006. Disponvel em
<http://www.baguete.com.br/artigosDetalhes.php?id=154> Acesso em 01 de Abr. 2010. PRESMAN, Roger S. Engenharia de Software. 6 ed. So Paulo: McGraw-Hill, 2006. PRIVATI, Carlos Eduardo Andriotti. Talend Open Studio: Uma ferramenta open Source de integrao de dados e ETL Parte 1. SQL Magazine. Rio de Janeiro, ano 5, 71 ed., p.55-63, 2009. TALEND, Talend Open Studio. Obtida via internet. ltimo acesso em 02 de Mai. 2010. Disponvel em: <www.talend.com>. TURBAN, Efrain. Tecnologia da Informao para Gesto: Transformando os negcios na economia digital. 3. ed. Porto Alegre: Bookman, 2004. ZIULKOSKI, Lus Cludio Chaves. Coleta de Requisitos e Modelagem de Dados para Data Warehouse: um Estudo de Caso utilizando Tcnicas de Aquisio de Conhecimento. Porto Alegre: 2003. Trabalho de Concluso de Curso Universidade Federal Do Rio Grande Do Sul - UFRGS.
86
APNDICE A Questionrio base para entrevistas
Construo de Data Warehouse em ambiente Heterogneo: Estudo de Caso na rea de Transportes Rodovirios
Faculdade Dom Bosco Porto Alegre Rodrigo Moraes
LEVANTAMENTO DE REQUISITOS PARA DATA WAREHOUSE(DW)
1. Nome da empresa:
2. Gerente responsvel:
3. rea(s) de interesse (Quais assuntos devem estar dentro do ambiente do DW):
3.1. Desejos especficos (Quais perguntas ou indicadores devem ser suportados, a partir
disso ser modelado o banco de dados, na estrutura estrela):
4. Ambiente operacional (Descrever o ambiente operacional da empresa):
4.1 Detalhar as Fontes de dados (Tecnologias, sgbds, planilhas, arquivos textos, suas caractersticas)
5. Granularidade (Qual o mnimo grau de informao vai pode ser vista no DW):
6. Freqncia de Carregamento do Data Warehouse (De quanto em quanto tempo a base ser recarregada):
7. Como deseja visualizar as informaes: (Isto ser utilizado para desenvolver os

relatrios)
87
APNDICE B Dicionrio de Dados
88
APNDICE C Questionrio
Construo de Data Warehouse em ambiente Heterogneo: Estudo de Caso na rea de Transportes Rodovirios
Faculdade Dom Bosco de Porto Alegre Rodrigo Moraes
Questionrio Este questionrio visa avaliar o produto deste trabalho de concluso e no averiguar as capacidades do entrevistado. Analise as afirmaes abaixo com base na sua experincia utilizando o ambiente de Data Warehouse proposto por este TCC, em seguida marque a opo adequada na grade de resposta, marcando um X na carinha correspondente a seu grau de satisfao. A legenda encontra-se na grade de resposta. Data de Recebimento: __/__/____ Data de Entrega: __/__/____ Parte 1 Requisitos e Utilizao 1.1 O Data Warehouse, atravs de seus relatrios, permitiu que os dados das fontes operacionais pudessem ser visualizados de forma consolidada. 1.2. Foi possvel ter acesso s informaes das unidades de negcio que possuam diferentes fontes operacionais para registrar os recibos rodovirios. 1.3 O Data Warehouse proporcionou averiguar os clientes de maior e menor receita, como tambm sua evoluo ao longo de um perodo. 1.4 Foi possvel descobrir as unidades de negcio de maior e menor rentabilidade, possibilitando o
acesso evoluo da receita ao longo dos anos.
1.5 O ambiente analtico foi capaz de exibir, atravs dos relatrios, as receitas e as despesas referentes a cada modalidade de transporte de cargas. 1.6 Foi possvel visualizar a receita, a rentabilidade e a despesa ao nvel do documento emitido. 1.7 A forma de visualizao das informaes do Data Warehouse, atravs dos relatrios construdos,
atente a todas as necessidades de anlise da rentabilidade do transporte de cargas.
Parte 2 Conseqncias 2.1 O ambiente construdo facilitou a analise da rentabilidade da rea de negcio transporte rodovirio, pois se props em extrair a informao integrada.
89
2.2 A anlise da rentabilidade tornou-se mais eficiente e rpida em relao a como era realizada antes da existncia do ambiente analtico. 2.3 possvel fomentar, atravs das informaes extradas do Data Warehouse, estratgias quanto a polticas de descontos para determinados clientes ou investimento em determinadas unidades de negcio que hoje possuem baixa rentabilidade. 2.4 Cite alguns exemplos caso as informaes extradas do Data contribuir para tomada de outras decises: Warehouse possam
___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ Questionrio - Grade de Respostas

Questo Satisfeito Parcialmente Satisfeito Insatisfeito No se aplica
1.1 1.2 1.3 1.4 1.5 1.6 1.7 2.1 2.2 2.3

Monografia Rodrigo Moraes

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Monografia Rodrigo Moraes

Caricato da

Copyright:

Formati disponibili

FACULDADE DOM BOSCO DE PORTO ALEGRE CURSO DE SISTEMAS DE INFORMAO

Porto Alegre Dezembro/2010

Porto Alegre Dezembro/2010

Porto Alegre Dezembro/2010

LISTA DE ABREVIATURAS E SIGLAS

3.4 PROCESSO ETL......................................................................................................... 3.5 CONFECO DE RELATRIOS.............................................................................

normalmente utilizada a abordagem relacional para estruturar o banco de dados.

Figura 1 Estrutura do Data Warehouse. Adaptado: Turban (2004)

Figura 2 Abordagem Top Down Adaptado de Machado (2008)

Figura 3 Abordagem Botton Up Adaptado de Machado (2008)

Figura 4 Abordagem Intermediria ou Combinada Adaptado de Machado (2008)

Figura 5 Exemplo de Granularidade. Adaptado de Inmon (1997)

Figura 6 Exemplo Pontos Cardeais. Adaptado de Machado (2008)

Figura 7 Modelo Estrela. Adaptado de Gonalves (2003)

Figura 8 Modelo Floco de Neve (Snowflake). Adaptado de Gonalves (2003)

Figura 9 Tela de Entrada PDI. Fonte: Pentaho (2010)

Tabela 2. Funcionalidades PDI

Adaptado: Pentaho (2010).

Figura 10 Interface Talend Open Studio. Fonte: Talend (2010)

Tabela 3. Funcionalidades TOS

Adaptado: Talend (2010).

Figura 11 Ambiente Transacional.

Figura 12 Diagrama Entidade Relacionamento Transporte de Cargas

Dim_Financeiro: responsvel por armazenar as diferentes possibilidades de despesas e receitas;

Figura 13 Estrutura Fonte de dados A

Figura 14 Estrutura Fontes de dados B,C,D,E

Figura 15 TOS SQL

Figura 16 Fluxo ETL

Figura 17 Relatrio Rentabilidade Total

Figura 18 Relatrio Rentabilidade Unidade

Figura 19 Relatrio Rentabilidade Evoluo

Tabela 4. Mtricas para Exatido

Adaptado: Costa (2006)

Adaptado: Costa (2006)

Fonte: Costa (2006)

Fonte: Costa (2006)

Tabela 8. Check-list Projeto

Tabela 10. Mtricas Dimenses

dim_modal dim_unidade dim_cliente dim_financeiro dim_tempo

J a Tabela 11 exibe as mtricas aplicadas tabela fato.

Tabela 11. Mtricas Fato

fato_transporte 100% 0% 95% 11% 100% No se aplica No se aplica

Figura 20 Grfico Questo 1.1

Figura 21 Grfico Questo 1.2

Figura 22 Grfico Questo 1.3

Figura 23 Grfico Questo 1.4

Figura 24 Grfico Questo 1.5

Figura 25 Grfico Questo 1.6

Figura 26 Grfico Questo 1.7

Figura 27 Grfico Questo 2.1

Figura 28 Grfico Questo 2.2

Figura 29 Grfico Questo 2.3

< http://www.classecontabil.com.br/trabalhos/TCC2002-1-37-VF-GersonFCosta.doc> Acesso em 04 de Abr. 2010.

<http://www.scielo.br/scielo.php?pid=S010365132007000100015&script=sci_arttext&tlng=em> Acesso em 15 de Mai. 2010.

APNDICE A Questionrio base para entrevistas

Faculdade Dom Bosco Porto Alegre Rodrigo Moraes

LEVANTAMENTO DE REQUISITOS PARA DATA WAREHOUSE(DW)

3. rea(s) de interesse (Quais assuntos devem estar dentro do ambiente do DW):

4. Ambiente operacional (Descrever o ambiente operacional da empresa):

7. Como deseja visualizar as informaes: (Isto ser utilizado para desenvolver os

APNDICE B Dicionrio de Dados

Faculdade Dom Bosco de Porto Alegre Rodrigo Moraes

Potrebbero piacerti anche