TCCII_Andre_2009_2

Business Intelligence: um sistema de apoio a decises gerenciais

Andr Amaral Muszinski, Silvia de Castro Bertagnolli

Faculdade de Informtica Curso de Bacharelado em Sistemas de Informao Centro Universitrio Ritter dos Reis (Uniritter) Porto Alegre RS Brasil

[email protected], [email protected]

Resumo. Os ambientes de negcios cada vez mais complexos exigem dos gestores aes mais rpidas, inovadoras e geis. Um dos maiores problemas enfrentados pelas empresas a dificuldade em realizar a anlise dos negcios e a gesto de desempenho da corporao. Este artigo descreve o desenvolvimento de uma soluo de Business Intelligence (centrada em um Data warehouse, utilizando Integrao de Dados e Processamento Analtico Online), que permite, atravs de relatrios e grficos, a visualizao de dados financeiros e estratgicos da empresa, apoiando o processo de tomada de deciso.

Abstract. The business environments increasingly complex, requires quicker, innovative and agile actions from the managers. One of the biggest problems faced by companies is the difficulty in performing business analysis and performance management of the corporation. This paper presents the development of a Business Intelligence solution (centered in a Data Warehouse, using the Data Integration and Online Analytical Processing), which allows, through reports and graphs, visualization of financial and strategic data of company, supporting the decision making process.

1. Introduo Um dos maiores problemas enfrentados pelas empresas a dificuldade em realizar a anlise dos negcios e gesto de desempenho da corporao. Hoje, estas anlises so realizadas utilizando-se planilhas eletrnicas e consultas SQL (Structured Query Language) complexas com vrios joins que so executadas nos bancos de dados transacionais, gerando lentido (e at mesmo paradas) nos sistemas. A consulta SQL gerada pela equipe de TI (Tecnologia da Informao), normalmente no atende a todas as necessidades do usurio final, fazendo com que todo o ciclo se repita (solicitar os dados, esperar, receber os dados, revisar a informao e analisar os resultados). A gerao de uma simples planilha eletrnica, para ser utilizada como ferramenta no planejamento estratgico, pode levar semanas para ser desenvolvida. Neste cenrio, um sistema computadorizado de suporte aos gestores, como o Business Intelligence (BI), permite decises melhores e mais rpidas. Uma soluo de BI centrada em Data Warehouse (DW), separada do servidor de banco de dados transacional, proporciona um repositrio central de dados, criando uma fbrica de informaes, onde relatrios, grficos e alertas de desempenho podem ser gerados diretamente pelo usurio final. Isto permite que os usurios possam acessar dados

histricos da empresa, possibilitando decises geis, anlise dos negcios, anlise de tendncias, descoberta de informaes e conhecimento. O DW um ponto-chave nesta arquitetura, pois centraliza a informao, possibilitando uma verso nica da verdade. O presente trabalho foi desenvolvido na NeoGrid Informtica, empresa especializada em solues de Business-to-Business (B2B). O projeto iniciou com a anlise dos relatrios financeiros e de desempenho, gerados pelo Administrador de Banco de Dados (DBA), solicitados pela diretoria mensalmente. O objetivo foi implementar uma soluo de BI de modo a apoiar a tomada de deciso de gerentes de negcios (nvel comercial), gerentes departamentais (nvel ttico) e diretores (nvel estratgico) da NeoGrid, utilizando dados histricos e atuais, e visualizando-os atravs de relatrios, grficos e indicadores-chave de desempenho (Key Performance Indicator - KPI) utilizando ferramentas de processamento analtico. Para tanto, foi necessrio (i) definir e implantar a arquitetura necessria para o desenvolvimento da soluo; (ii) analisar os relatrios financeiros e de desempenho gerados pelo DBA mensalmente; (iii) definir os Data Marts e relatrios necessrios; (iv) validar a implementao dos relatrios junto a gerentes de negcios, gerentes departamentais e diretores. O texto deste artigo encontra-se organizado em 5 sees, onde: a seo 2 detalha os aspectos tericos que fundamentam a soluo proposta; a seo 3 descreve a soluo implementada, bem como os diagramas e elementos que auxiliaram na modelagem; a seo 4 apresenta os resultados obtidos com a aplicao do trabalho em um estudo de caso real; e a seo 5 apresenta a concluso do trabalho.

2. Referencial Terico Este captulo apresenta os principais elementos tericos que foram utilizados para elaborar a soluo proposta.

2.1 Business Intelligence Business Intelligence (BI) um termo relativamente novo, mas certamente no um conceito novo. Este termo foi criado pelo Grupo Gartner no incio dos anos 1990 e inclui arquiteturas, ferramentas, bancos de dados, aplicaes e metodologias. O conceito simples: fazer uso de informaes j disponveis nas organizaes para ajudar os responsveis pelas tomadas de decises a adotar as melhores opes e de forma mais rpida. Os principais objetivos do BI so permitir o acesso interativo aos dados, proporcionar a manipulao destes dados e fornecer aos gestores a capacidade de realizar a anlise adequada. Ao examinarem os dados, situaes e desempenhos histricos e atuais, os tomadores de deciso conseguem uma melhor compreenso dos dados, que podem servir como base para decises melhores e mais informadas. O processo de BI baseia-se na transformao de dados em informaes (TURBAN et. al, 2009). O principal benefcio do BI para uma organizao a capacidade de fornecer informaes precisas quando necessrio, incluindo uma viso em tempo real do desempenho corporativo. Estas informaes so necessrias para todos os tipos de

decises, principalmente para o planejamento estratgico (TURBAN et. al, 2009). Seus principais benefcios compreendem: economia de tempo, verso nica da verdade, melhores estratgias e planos, melhores decises tticas, processos mais eficientes e economia de custos. As aplicaes de BI visam diminuir a diferena entre o desempenho atual de uma organizao e o desempenho desejado, expresso em sua misso, objetivos, metas e a estratgia para atingi-los. Um sistema de BI possui quatro grandes componentes, conforme descreve Turban (2009): (i) data warehouse, banco ou repositrio de dados especial preparado para dar suporte a aplicaes de tomada de deciso; (ii) anlise de negcios, corresponde a uma coleo de ferramentas para manipular e analisar os dados no DW, incluindo processamento analtico, multidimensionalidade, minerao de dados e tcnicas de anlise avanada; (iii) gesto de desempenho do negcio (Business Performance Management BPM) para monitoria e comparao do desempenho da corporao s metas estabelecidas, com a aplicao de balanced scorecards; e (iv) interface com usurio. As reas mais comuns de aplicao do BI so relatrios gerais, anlise de vendas e marketing, planejamento e previso, consolidao financeira, relatrios de desempenho, oramento e anlise de rentabilidade (JACOBSON; MISNER, 2007). Transformar dados histricos em conhecimento estratgico um dos objetivos da tecnologia da informao nas organizaes. O DW uma ferramenta que surgiu com esse propsito, trazendo a idia de centralizao das informaes, visualizao multidimensional dos dados e descoberta de padres de comportamento para dar aos administradores maior agilidade na tomada de decises (BARBALHO, 2003).

2.2 Data Warehouse Um data warehouse (DW) um conjunto de dados produzido para oferecer suporte tomada de decises. Ele um repositrio de dados atuais e histricos de possvel interesse aos gestores de toda a organizao. Os dados, normalmente, so estruturados de modo a estarem disponveis em um formato pronto para atividades de processamento analtico (processamento analtico online, minerao de dados, consultas, gerao de relatrios, outras aplicaes de suporte deciso). Portanto, um DW uma coleo de dados orientada por assunto, integrada, varivel no tempo e no-voltil, que proporciona suporte ao processo de tomada de decises da gerncia (LARSON; AGARWAL, 2006). Os DWs contm uma grande variedade de dados que apresentam uma imagem coerente das condies da empresa em um determinado ponto no tempo. A idia por trs do conceito foi criar uma infra-estrutura de banco de dados que estivesse sempre online e contivesse todas as informaes dos sistemas de processamento de transaes online (Online Transaction Processing - OLTP), incluindo dados histricos (DELANEY; AGARWAL, 2006). Porm, esta infra-estrutura seria reorganizada e estruturada de forma a oferecer rapidez e eficincia em consultas, anlises e suporte deciso. Em geral, o DW armazenado em um banco de dados separado da base operacional. Esta separao evita a perda de desempenho no processo operacional da empresa (BARBALHO, 2003). Os tomadores de deciso necessitam de informaes concisas e confiveis, sobre operaes atuais, tendncias e mudanas. As informaes de interesse para a empresa

so constantemente fragmentadas com o uso de diferentes sistemas operacionais e fontes externas, e assim os gestores tomam decises com informaes parciais, na melhor das hipteses. O DW supera este obstculo acessando, integrando e organizando os principais dados operacionais de uma forma consistente, confivel e prontamente disponvel, onde for necessrio (TURBAN et. al, 2009). Um data warehouse une bancos de dados de toda uma empresa. J um Data Mart (DM), normalmente menor e se concentra em um assunto ou departamento especfico. Um Data Mart um subconjunto de um DW, que normalmente consiste em uma nica rea temtica (ex.: marketing, vendas, operaes). Em um DM pode existir mais de um fato e a utilizao de dimenses comuns a eles (MACHADO, 2004). Os DMs so uma soluo menos cara, capazes de serem substitudos por um DW ou de complement-lo. Eles podem ser dependentes ou independentes de um DW.

2.2.1 Arquiteturas de Data Warehouse A escolha da arquitetura e sua implementao so decises gerenciais do projeto. Estes fatores esto relacionados infra-estrutura disponvel (banco de dados, ferramentas OLAP e ETL, processamento paralelo, particionamento de dados), ao ambiente de negcios (porte da empresa), escopo de abrangncia desejado, assim como a capacidade da equipe interna de TI e dos recursos disponibilizados para investimento (MACHADO, 2004). De acordo com Ballard et. al (2006), as principais arquiteturas utilizadas so:

arquitetura de Data Warehouse Empresarial (Enterprise Data Warehouse EDW) considerada a que suporta toda ou maior parte dos requisitos ou necessidades. Ela possui grande grau de acesso e a utilizao das informaes para todos os departamentos de uma empresa;

arquitetura de Data Mart Independente um DW projetado para uma unidade estratgica de negcios ou um departamento, mas cuja fonte no um EDW. Eles so fceis de construir, porm envolvem altos custos, redundncia de dados e no permitem uma viso global da empresa;

arquitetura de Data Mart Dependente (Integrados) um subconjunto criado a partir do EDW. Ele tem a vantagem de usar um modelo de dados consistente e apresentar dados de qualidade.

Cada arquitetura de DW tem aplicaes especficas para as quais sua eficincia maior (ou menor), e assim oferece os benefcios mximos para a organizao (BALLARD et. al, 2006). A deciso de qual arquitetura implementar pode causar impactos quanto ao sucesso do projeto de um DW. Diversos fatores influenciam a escolha da arquitetura e implementao, entre elas o tempo para execuo do projeto, a necessidade urgente de um DW, o retorno do investimento a ser realizado, a velocidade dos benefcios da utilizao das informaes, a limitao de recursos, a satisfao do usurio executivo, a compatibilidade com sistemas existentes e os recursos necessrios implementao de uma arquitetura (KIMBALL, 2002).

2.2.2 Tipos de Implementao Vrios tipos de implementao de arquiteturas de DW podem ser usados. Segundo Machado (2004), os tipos de implementao mais utilizadas em empresas so: top down, bottom up e uma combinao das duas. A implementao top down conhecida como padro inicial do conceito de DW. Ela requer maior planejamento e trabalho de definies conceituais de tecnologias completos antes de iniciar o projeto de DW. Neste tipo de arquitetura constri-se, em primeiro lugar, o EDW e depois se extrai os dados para os DMs (INMON, 2005). A abordagem top down, proposta por Inmon (2005), apresenta como vantagens: (i) herana de arquitetura todos os DMs originados de um DW utilizam a arquitetura e os dados do DW; (ii) viso de empreendimento o DW concentra todos os negcios da empresa; (iii) controle e centralizao de regras garante a existncia de um nico conjunto de aplicaes ETL (Extract, Transform and Load). Machado (2004) destaca as seguintes desvantagens: (i) implementao muito longa; (ii) alta taxa de risco no existem garantias para o investimento neste tipo de ambiente; (iii) expectativas relacionadas ao ambiente a demora do projeto e a falta de retorno podem induzir expectativas nos usurios. Devido ao custo e tempo necessrios em uma implementao top down, a implementao bottom up vem se tornando muito popular. O propsito construir um DW incremental a partir do desenvolvimento de DMs independentes. Ela bastante utilizada, pois possui um retorno de investimento muito rpido (KIMBALL, 2002). Kimball (2002) destaca as seguintes vantagens da abordagem bottom up: implementao rpida, retorno rpido e enfoque inicial nos principais negcios. J Machado (2004) destaca as seguintes desvantagens: (i) perigo de DMs legados: um dos maiores perigos no DW a criao de DMs independentes. A soluo pode no considerar a arquitetura de forma global. Desse modo, os DMs independentes transformam-se em DM legados, que podem inviabilizar futuras integraes; (ii) dificuldade em obter a viso do empreendimento; (iii) coordenao de mltiplas equipes e iniciativas; e (iv) procedimentos de ETL mais complexos. A implementao combinada tem o propsito de integrar a arquitetura top down com a bottom up. Nessa abordagem efetua-se a modelagem de dados do DW de viso macro, sendo o passo seguinte a implementao de partes desse modelo. Essas partes so escolhidas por processos ou atividades da rea de interesse e constituem os DMs. Cada DM pode ser gerado a partir do macromodelo de dados do DW e integrado ao modelo fsico do DW (MACHADO, 2004).

2.2.3 Modelagem dimensional O projeto de DW se baseia no conceito de modelagem dimensional (ou multidimensional), que compreende um sistema baseado em recuperao que suporta acessos com alto volume de consultas. A representao dos dados estruturada como um cubo, transmitindo a idia de mltiplas dimenses. A maior vantagem da multidimensionalidade que ela permite que os dados sejam organizados de acordo com a preferncia de cada usurio (ou rea de negcio).

Apresentaes diferentes dos mesmos dados podem ser providenciadas de modo rpido e fcil (ITALIANO; ESTEVES, 2004a). O modelo multidimensional baseado em trs tipos de estruturas (REIS; TEIXEIRA; ARAJO, 2009):

fatos a tabela de fatos a tabela central do modelo e contm os valores (numricos) que se deseja analisar, geralmente, contendo um grande volume de dados. A tabela fato possui chaves externas, que se relacionam com suas tabelas de dimenses, e campos numricos que so os valores (medidas) que sero analisados;

dimenses as tabelas de dimenses representam um aspecto do negcio que est sendo analisado. Sua chave primria serve para manter a integridade referencial na tabela fato qual est relacionada. Uma dimenso oferece ao usurio um grande nmero de combinaes e interseces para analisar os dados, possibilitando diversas formas de visualizar os dados;

medidas so atributos numricos armazenados na tabela de fatos, que representam o desempenho de um indicador em relao s dimenses que participam desse fato.

A modelagem multidimensional um processo que envolve algumas etapas cujo objetivo levantar e representar as necessidades de anlise e de informaes dos usurios de determinado departamento ou rea de negcios (REIS; TEIXEIRA; ARAJO, 2009). Para Ballard et. al (2006), existem trs tipos bsicos de modelos multidimensionais:

esquema estrela cada dimenso formada por apenas uma tabela no padronizada. O fato de suas tabelas no estarem normalizadas, resultar em uma menor quantidade de tabelas no modelo do DM, mas como conseqncia poder causar redundncia dos dados, fato caracterstico neste tipo de soluo;

esquema multi-estrela este esquema baseado no esquema estrela, com uma tabela para cada dimenso, porm existem mltiplas tabelas de fatos, unidas atravs das dimenses;

esquema floco de neve neste esquema as tabelas das dimenses esto padronizadas para eliminar a redundncia dos dados. Diferente do esquema estrela, neste esquema os dados das dimenses esto distribudos em mltiplas tabelas.

As estruturas das dimenses possuem nveis, onde cada nvel de uma dimenso deve ter correspondncia com uma coluna na tabela da dimenso. Os dados so classificados (ordenados) por grau de detalhe e so organizados em uma estrutura hierrquica (ITALIANO; ESTEVES, 2004b).

2.2.4 Integrao de dados e processos de ETL Um grande objetivo do DW integrar dados de mltiplos sistemas. A integrao de dados compreende trs grandes processos que, quando implementados corretamente,

permitem que eles sejam disponibilizados a um conjunto de ferramentas de Extrao, Transformao e Carga (ETL), anlise e ao ambiente de data warehousing (LANGIT, 2008). J os processos compreendem: (i) acesso aos dados (a capacidade de acessar e extrair dados de qualquer fonte), (ii) federao de dados (a integrao das visualizaes de negcios em diversos data stores) e (iii) captura de alteraes (com base na identificao, captura e entrega das alteraes feitas nas fontes de dados da empresa). O ETL extremamente importante na integrao de dados e tambm no DW, pois seu objetivo carregar dados integrados e limpos. Os dados usados nestes processos podem ser oriundos de qualquer fonte: uma aplicao de mainframe, uma aplicao ERP (Enterprise Resource Planning), uma ferramenta de CRM (Relationship Management), um arquivo texto, uma planilha do Excel ou at uma fila de mensagens (TURLEY; KASPRZAK; CAMERON, 2007). O processo de ETL um componente essencial de qualquer projeto centrado em dados. Langit (2008) classifica o processo em trs etapas: (i) extrao, com leitura de uma ou mais fontes de dados; (ii) transformao, onde dados anteriormente extrados so convertidos na forma em que precisam estar, para que sejam colocados em um DW ou em um banco de dados; (iii) e carga dos dados no DW. comum que as organizaes possuam sistemas transacionais desenvolvidos por diferentes equipes e, que no seu desenvolvimento, tenham adotado diferentes convenes na codificao de variveis, nomes dos atributos das tabelas, diferentes tipos de dados ou formatos de datas. Ao extrair os dados dos diferentes sistemas, deve ser definido um formato nico para o DW e realizar as transformaes necessrias em cada caso (TURLEY; KASPRZAK; CAMERON, 2007).

2.2.5 Processamento Analtico Online (OLAP) O OLAP (Online Analytical Processing) um conjunto de ferramentas e tcnicas que permite realizar a explorao dos dados de um DW, utilizando os recursos de modelagem, anlise e visualizao de grandes conjuntos de dados. O OLAP ajuda a analisar de forma mais eficiente a quantidade de dados crescente armazenados pelas organizaes transformando-os em informao (JACOBSON; MISNER, 2007). Relatrios e consultas fazem parte das atividades mais antigas de OLAP e BI. O OLAP possibilita que o usurio produza facilmente seus prprios relatrios e analise tendncias e desempenho diariamente (TURBAN et. al, 2009). Os sistemas OLAP oferecem uma alternativa aos sistemas transacionais, produzindo uma viso dos dados orientados anlise, alm de uma navegao rpida e flexvel (LARSON; AGARWAL, 2006). Um sistema OLAP apresenta as seguintes caractersticas: (i) esquema otimizado para que as consultas realizadas pelos usurios sejam retornadas rapidamente; (ii) gerao de relatrios complexos de uma forma simples; (iii) utilizao interativa com os usurios, ou seja, as consultas no necessitam estar pr-definidas; e (iv) permite a redundncia de dados para otimizao de consultas. Kimball (2002) classifica os sistemas OLAP em trs tipos: (i) OLAP multidimensional (MOLAP) implementado atravs de um DW multidimensional. Os dados so organizados em uma estrutura de cubos; (ii) OLAP relacional (ROLAP) implementado sobre um banco de dados relacional; e (iii) OLAP hbrido (HOLAP) combina atributos de MOLAP e ROLAP.

Ballard et. al (2006) destaca as principais operaes utilizadas nas ferramentas OLAP: (i) drill down e roll up - so operaes que movimentam a viso dos dados (cubo) ao longo das hierarquias de uma dimenso. O drill down ocorre quando o usurio desagrupa os dados, aumentando o nvel de detalhe da informao. O roll up (ou drill up) o contrrio. Ele ocorre quando o usurio agrupa os dados, diminuindo o nvel de detalhamento da informao; (ii) slice e dice - o slice quando um membro em particular de uma dimenso selecionado, formando uma espcie de fatia (slice) do cubo original. O dice seleciona vrios membros de vrias dimenses formando um sub-cubo. Tanto o slice quanto o dice so formas particulares de filtro; e (iii) pivot - o ngulo pelo qual os dados so visualizados. Permite a troca de linhas por colunas em uma tabela ou modificao da posio das dimenses em um grfico. A aplicao dessas operaes (vises) sobre um modelo multidimensional cria uma viso no formato cubo, conhecida como Decision Cube (BARBALHO, 2003).

3. Soluo Implementada O objetivo deste trabalho foi desenvolver uma soluo de BI, que apie a tomada de deciso de diretores e gerentes da empresa NeoGrid, atravs da visualizao de relatrios e KPIs, manipulando fatos, medidas e dimenses. O foco o desenvolvimento de um DW, composto por cubos OLAP e o acesso a relatrios via Web. Segundo Turban et. al (2009), os fatores essenciais para que um projeto deste porte seja bem-sucedido so: (i) definir claramente os objetivos, (ii) reunir apoio ao projeto junto gerncia, (iii) estabelecer cronogramas e oramentos; e (iv) administrar as expectativas. O desenvolvimento desta soluo utiliza como metodologia os passos (fases) propostos por Barbieri (2001) para a implementao de um sistema de BI: (i) planejamento, (ii) levantamento das necessidades, (iii) modelagem dimensional, (iv) projeto fsico dos bancos de dados, (v) projeto de ETL, (vi) desenvolvimento de aplicaes, (vii) teste e homologao, (viii) treinamento e (ix) implantao. As prximas sees iro apresentar cada um destes passos, de forma detalhada.

3.1 Planejamento Na etapa de planejamento o escopo do projeto deve ser definido, sempre mantendo o foco no negcio. Deve-se atentar para as reas mais crticas e que possuem necessidades mais abrangentes de informaes gerenciais (BARBIERI, 2001). Nesta etapa, tambm deve ser definida a arquitetura e o tipo de implementao que devero ser utilizados para a construo do DW. Neste momento foi definida uma arquitetura do tipo Data Warehouse Empresarial, sendo implementada utilizando tcnicas combinadas (top down e bottom up). Com relao ao mecanismo de processamento de consultas, utilizou-se um servidor de banco de dados multidimensional (MOLAP), devido ao seu melhor desempenho e a um conjunto rico e complexo de funes de anlise (CARVALHO, 2003). Assim, definiu-se o foco deste projeto, que so os dados de desempenho financeiro e estratgico da aplicao Mercador (www.mercador.com), soluo de EDI (Electronic Data Interchange) que o produto de maior faturamento da NeoGrid.

Depois de definido o escopo do projeto, foi realizada uma anlise prvia com o intuito de identificar as principais mtricas e dimenses. Posteriormente, foi realizada uma anlise da viso macro, para verificar como os projetos futuros sero integrados ao projeto inicial. A modelagem foi desenvolvida de modo a garantir que ela possa ser aproveitada em outros DMs da empresa. Outro fator importante para o sucesso da implantao do BI a definio da arquitetura tecnolgica. A arquitetura deve ser definida durante o planejamento, pois caractersticas de desempenho e disponibilidade iro definir nveis de servio e graus de compromissos variados (BARBIERI, 2001). Os componentes bsicos desta definio compreendem: (i) sistema gerenciador de banco de dados, (ii) ferramentas de desenvolvimento de sistemas OLAP, (iii) ferramentas para processos ETL (com mecanismos para transferncia de dados entre ambientes heterogneos) e (iv) um visualizador de relatrios (de preferncia que as informaes possam ser visualizadas atravs da Web) (BARBIERI, 2001). A arquitetura escolhida para este projeto foi a da plataforma Microsoft, que alm de possuir todos os requisitos de desempenho e escalabilidade, a arquitetura de BI mais utilizada (The OLAP Report, 2009). Alm disso, a NeoGrid j trabalha h mais de 10 anos com a plataforma SQL Server, alm de ser uma empresa parceira (Microsoft Partner Gold) da Microsoft. Ao concluir o planejamento foi realizado o levantamento das necessidades do DW relacionado aos setores financeiro e estratgico, conforme descreve a prxima seo.

3.2 Levantamento de necessidades A etapa de levantamento de necessidades uma das mais importantes, pois nesta fase possvel identificar e priorizar as necessidades de informao que a organizao necessita. importante o envolvimento de analistas de sistemas, usurios, equipe de tecnologia da informao e DBAs durante esta fase (BARBIERI, 2001). Diferente do desenvolvimento de sistemas tradicionais, o ciclo de desenvolvimento de um DW inicia pela anlise dos dados. Esta primeira anlise da base de dados transacional, permite que o analista obtenha um melhor entendimento das necessidades e limitaes do projeto, pois o DW um grande repositrio de dados originados destes sistemas (KIMBALL, 2002). Barbieri (2001) destaca dois modelos que devem ser utilizados durante o levantamento de necessidades: (i) o modelo Fonte das Informaes, que representa quais informaes e anlises so esperadas pelos usurios do sistema; e o (ii) modelo Fonte dos Dados, que representa as fontes de informaes e o destino delas no modelo dimensional. O objetivo destes modelos no o de definir e modelar fatos, dimenses e tabelas auxiliares, porque o foco est nos requisitos levantados. A documentao gerada durante esta fase baseada na soluo proposta por Scheeren (2009), que utiliza a UML (Unified Modeling Language) para auxiliar a modelagem de DWs. Aps algumas entrevistas com os usurios, foi detectada a necessidade de anlise do faturamento e do trfego de documentos da aplicao Mercador, que permitisse aos gestores uma viso estratgica. Conforme proposto por Scheeren (2009), o modelo

Fonte das Informaes, que descreve as necessidades levantadas pelos usurios, representado por um diagrama de caso de uso, que apresenta graficamente a especificao do projeto. Aps a definio do escopo (faturamento e trfego de documentos), foram identificados os requisitos do projeto, relacionando os tipos de anlises necessrias pelos usurios (gestores). O Apndice A ilustra os diagramas de casos de uso, relacionados, respectivamente, ao escopo de faturamento e de trfego de documentos. Alm das entrevistas com os usurios, outra fonte que auxiliou o levantamento de dados foram os relatrios gerenciais. Alguns scripts SQL, que so executados mensalmente pelo DBA, tambm foram analisados. Os resultados destas consultas so inseridos em planilhas eletrnicas e enviados aos gestores. Desse modo, estas consultas permitiram uma anlise prvia, que possibilitou identificar o foco inicial do projeto. Independente do fato que est sendo criado, ele sempre possui no mnimo quatro elementos (MACHADO, 2004): (i) onde aconteceu o fato; (ii) quando aconteceu o fato; (iii) quem executou o fato; e (iv) o que o objeto do fato. Com base nestes elementos, Machado (2004) prope a utilizao de quatro pontos cardeais para facilitar a descoberta de informaes (modelo Fonte dos Dados) levantadas pelo modelo anterior. Estes pontos cardeais so definidos pelas seguintes perguntas: Onde?, Quando?, Quem? e O qu?. Para o modelo Fonte dos dados, que representa a fonte das informaes, Scheeren (2009) tambm prope a especificao atravs da utilizao de casos de uso. Neste modelo, sistemas de origem e destino so representados por atores. Para definir o que representa cada ator, Scheeren (2009) criou os seguintes esteretipos: para sistema transacional; para arquivo de dados e para modelo dimensional. Para os pontos cardeais propostos por Machado (2004), Scheeren (2009) definiu os seguintes esteretipos para os casos de uso: , , e . No Apndice B encontram-se os modelos Fonte dos Dados das necessidades levantadas nos modelos anteriores (Apndice A). Inicialmente, os usurios propuseram uma soluo de data warehouse ativo (tempo real), porm este tipo de soluo pode gerar diferentes resultados dependendo do momento em que o relatrio ser gerado. Por este motivo, ficou definido que as cargas devem ser geradas diariamente. Outro requisito necessrio que a soluo deve estar operando no modelo 24x7, com um acordo de nvel de servio (Service Level Agreement - SLA) de 99,5% de disponibilidade. Todo o hardware e software do servidor monitorado, pois caso ocorra alguma falha ou instabilidade no sistema o responsvel pelo suporte ser acionado. Aps a finalizao do levantamento das necessidades, foi iniciada a modelagem dimensional do DW, conforme apresentada na prxima seo.

3.3 Modelagem Dimensional A etapa de modelagem dimensional considerada uma das mais importantes e um dos fatores crticos de sucesso em um projeto de DW. Ela possibilita que o usurio obtenha as informaes em uma forma muito prxima do seu entendimento, com vrias perspectivas possveis. A normalizao e a no redundncia so dispensadas na

modelagem dimensional, com o intuito de se obter estruturas mais geis. Tabelas que podero conter milhares de registros, com muitos gigabytes, ou at mesmo alguns terabytes de dados, so manipuladas (BARBIERI, 2001). A modelagem dimensional produz um modelo conceitual dimensional, formado por tabelas Fato e tabelas Dimenso. Para auxiliar a modelagem, Scheeren (2009) sugere a utilizao de diagramas de classes. Segundo Italiano e Esteves (2004b), a etapa de modelagem dimensional composta por alguns passos, cujo objetivo representar as necessidades de anlise e de informaes do usurio:

definir fatos e mtricas neste passo definido o que deve ser avaliado no DW. Definida a rea de negcios que est sendo modelada, deve ser respondida a seguinte questo: O que estamos avaliando?. A resposta desta pergunta a lista de fatos. Com isso, foi possvel identificar dois fatos: Faturamento e Trfego de Documentos. Depois de encontrar os fatos, foram identificadas as mtricas para cada fato;

definir as dimenses de negcios aps a identificao dos fatos e mtricas que sero armazenados no DW, so definidas as dimenses relacionadas s mtricas, que sero utilizadas para a avaliao dos fatos. A questo deste passo : Como as mtricas sero analisadas?;

definir a granularidade das informaes em cada dimenso aps a definio das dimenses de negcio, deve ser definido o nvel de detalhe (granularidade) mais baixo que ser avaliado. O seguinte questionamento deve ser realizado ao usurio: Qual o nvel de detalhe desejado?. Para o fato Faturamento a granularidade mensal, para o fato Trfego diria;

definir a hierarquia de agrupamento das informaes necessrio definir as possibilidades de agrupamento (sumarizao) das informaes desejadas pelo usurio, especificando estes agrupamentos em cada uma das dimenses de negcio. Este passo deve responder a seguinte questo: Como se espera agrupar ou sumarizar as informaes?. A dimenso tempo do fato Trfego possui a seguinte hierarquia: Ano Semestre Trimestre Ms Dia. Para o fato Faturamento, a dimenso tempo possui a hierarquia a seguir: Ano Semestre Trimestre Ms.

Aps a identificao de todos os elementos necessrios para a modelagem, atravs de entrevistas e anlise dos modelos Fonte das Informaes, Fonte dos Dados e Entidade-Relacionamento, foram definidos os modelos esquematizados pela Figura 1.

Figura 1: Modelos Dimensionais Faturamento e Trfego.

Conforme ilustrado na Figura 1, todos os fatos foram modelados utilizando o esquema estrela, proposto por Kimball (2002). Alm de ser o esquema de modelagem mais conhecido e utilizado em bases de dados de suporte deciso (MACHADO, 2004), ele possui excelente desempenho nas consultas, pois reduz o nmero de joins. Outra vantagem do esquema estrela a facilidade com que o usurio no tcnico consegue visualizar as anlises do negcio (MACHADO, 2004). Optou-se pela criao de um DM para cada aplicao da organizao NeoGrid. Por esse motivo, estes dois fatos sero armazenados em apenas um DM. Um importante atributo da tabela Dimenso a sua chave primria. Por questes de desempenho, no sero utilizadas chaves compostas ou concatenadas. Para cada tabela Dimenso foi definido que sua chave primria ser um nmero inteiro atribudo seqencialmente. Kimball (2002) sugere que sejam utilizadas chaves genricas (artificiais), tambm chamadas de surrogate keys. Um dos principais motivos para a criao de chaves genricas que o DW, por manter as informaes histricas, no pode ficar vulnervel a problemas de duplicao de chaves durante novas cargas de dados. Outra importante razo para o uso de chaves genricas, que em caso de alteraes de atributos nos sistemas transacionais, as chaves genricas sero a base para se manter o histrico destas alteraes no DW. A tabela Fato ser composta por mtricas e chaves para cada uma das dimenses. A chave primria da tabela Fato ser composta por atributos que correspondem a chaves estrangeiras, satisfazendo as restries impostas pela integridade de entidade (obrigatoriedade e unicidade da chave primria) e pela integridade referencial. A finalizao da modelagem dimensional a condio necessria para iniciar o projeto fsico do banco de dados, conforme apresenta a prxima seo. 3.4 Projeto Fsico dos Bancos de Dados Nesta etapa so definidas as estruturas lgicas do modelo dimensional, ou seja, so definidas as tabelas fato e de dimenses, os seus relacionamentos, os ndices, os atributos e as regras de tabelas (BARBIERI, 2001).

Para a modelagem dimensional foi utilizada a ferramenta ERwin Data Modeler. Aps a modelagem, a ferramenta permitiu a gerao automtica de um script SQL com a criao de todos os objetos do banco de dados (tabelas, ndices, constraints) do DM. A partir da modelagem realizada percebeu-se a necessidade de definir dois fatos, um para cada escopo mapeado, e para cada fato, foram definidas dimenses relacionadas com ele. O Apndice C esquematiza, respectivamente, os modelos Entidade-Relacionamento (ER) dos dois fatos propostos (Faturamento e Trfego). A soluo ser implantada no data center de Joinville, onde ser integrado ao SharePoint Server, permitindo acesso Web (interno e externo) aos relatrios. O SQL Server cria automaticamente ndices cluster para todas as chaves primrias (Primary Keys PKs) das tabelas. Os ndices no-cluster foram criados para as tabelas de dimenses que possuem campos de data e CNPJ. Durante a fase de homologao, foram gerados testes de carga, que permitiram avaliar o desempenho das consultas, percebendo-se a necessidade da criao de novos ndices.

3.5 Projeto de ETL Componente essencial de qualquer projeto centrado em dados, as tecnologias de extrao, transformao e carga (ETL) so consideradas o corao da parte tcnica do processo de data warehousing (TURBAN et. al, 2009). Durante esta etapa so definidos os processos necessrios para transformar o modelo Fonte em um modelo Dimensional (BARBIERI, 2001). Esta etapa um grande desafio para os gestores de TI, pois os processos de ETL costumam consumir cerca de 70% do tempo de um projeto (TURBAN et. al, 2009). Conforme apresentado no Trabalho de Concluso de Curso I, durante este projeto foi utilizada a ferramenta Integration Services, que faz parte do pacote SQL Server. O Integration Services a ferramenta de ETL da soluo de BI da Microsoft. Ela permite desenvolver graficamente todo o fluxo do processo (Figura 2). Alm de facilitar o desenvolvimento, permite uma melhor compreenso do processo, tornando menos complexas as futuras manutenes.

Figura 2: Processo ETL do Fato Trfego.

Todos os dados foram importados dos servidores de bancos de dados de produo (3 servidores SQL Server 2008). No foi necessria a importao de arquivos ou de qualquer outro tipo de estrutura de armazenamento. O primeiro passo foi desenvolver os processos de ETL das dimenses e, posteriormente, os processos dos fatos. A tabela de fatos referencia as tabelas de dimenses atravs de chaves estrangeiras e por este motivo deve sempre ser a ltima tabela a ser atualizada durante o processo de ETL (integridade referencial).

No desenvolvimento dos pacotes ETL, foram utilizados componentes para conexes a bancos de dados (OLE DB), execuo de scripts SQL e captura de alteraes nas fontes de dados. Na dimenso LOCALIZACAO_REMETENTE, os dados de CNPJ e razo social so monitorados na base transacional. Caso algum destes valores seja alterado, o processo realiza a atualizao destes no DW. A Figura 3 apresenta a execuo do ETL da dimenso LOCALIZACAO_REMETENTE. Foram analisados 105.404 registros, atualizados 647 membros e includos 10.529 novos registros na dimenso.

Figura 3: Subprocesso responsvel pela dimenso LOCALIZACAO_REMETENTE.

Esta etapa do projeto gerou dois pacotes de software, com dois grandes processos ETL , um para cada fato. Nenhuma informao foi sumarizada neste processo. A tabela do fato Trfego, por exemplo, possui um registro para cada registro na tabela fonte. Finalizado o desenvolvimento dos processos de extrao, transformao e carga das dimenses e fatos, foram criadas duas rotinas (uma para cada fato) responsveis pela execuo dos processos ETL e processamento dos cubos (nesta ordem). Todos os processos de ETL so executados no servidor onde est armazenado o DW. Finalizado o projeto de ETL do DW, iniciou-se o desenvolvimento dos cubos, como apresenta a prxima seo.

3.6 Desenvolvimento de Aplicaes Aps adquirir dados e informaes de diversas fontes e organiz-los em um data warehouse, iniciou-se o desenvolvimento da soluo de anlise de negcios. A anlise de negcios um conjunto de ferramentas e tcnicas que permitem reunir, armazenar, analisar e fornecer acesso aos dados, com o objetivo de ajudar os usurios a tomarem melhores decises comerciais e estratgicas (TURBAN et. al, 2009). Para realizar a anlise de negcios foram desenvolvidos os seguintes recursos: (i) gerao de cubos OLAP para permitir consultas analticas com vises multidimensionais; (ii) relatrios na Web pr-formatados com as consultas mais utilizadas; e (iii) consultas e anlise ad hoc. O primeiro passo nesta etapa foi iniciar o desenvolvimento dos dois cubos (sendo que, cada fato gerou um cubo). Atravs do Analysis Services (ferramenta para desenvolvimento OLAP da Microsoft), foram definidas as tabelas fato e suas dimenses (Figura 4). A linguagem utilizada foi a MDX (Multidimensional Expressions), linguagem criada pela Microsoft e que hoje utilizada na maioria das ferramentas OLAP. Esta linguagem uma extenso do SQL, que permite acesso s mltiplas dimenses.

Figura 4: Cubo Trfego no Analysis Services.

Com a estrutura bsica do cubo projetada, foram definidas as mtricas e as agregaes necessrias. Para cada dimenso, foram definidos os atributos que sero visualizados pelos usurios, e tambm, criadas as suas hierarquias. A tabela da dimenso TEMPO no precisou ser preenchida manualmente. O Analysis Services possui um wizard para a criao de dimenses do tipo TEMPO. Aps definir as datas inicial e final necessrias, foi gerado um script para a carga desta tabela. A hierarquia da dimenso TEMPO apresentada na Figura 5.

Figura 5: Hierarquia da dimenso TEMPO.

Durante o desenvolvimento dos cubos, tambm foram definidos e ajustados os labels dos fatos, mtricas, atributos e dimenses, alm da ordem de visualizao das informaes. Assim, estes objetos so visualizados pelo usurio final com nomes mais significativos do ponto de vista do usurio (Figura 6).

Figura 6: Atributos do usurio, hierarquia e tabela da dimenso REGIO_REMETENTE.

Inicialmente, os dados do fato Trfego (agora cubo Trfego) seriam agrupados por dia (uma nica entrada com o total e tamanho total dos documentos trafegados por parceiros comerciais durante o dia). Porm, durante o desenvolvimento, os usurios perceberam que poderiam utilizar as consultas para gerar extratos analticos do trfego dos clientes. Este processo geralmente gera uma carga excessiva no banco de dados transacional, alm de ser realizado apenas pelo DBA atravs de scripts SQL.

Aps finalizar os cubos, foi projetada a visualizao dos dados. Ela torna as aplicaes de suporte deciso mais atraentes e compreensveis aos usurios, permitindo uma melhor interpretao dos dados. As ferramentas visuais podem ajudar a identificar relaes, como por exemplo, tendncias. A visualizao de anlise de negcio atravs da Web facilita o seu uso, pois no necessria a instalao de nenhum software adicional (sem falar nas atualizaes de verses). Assim, foi criada uma srie de relatrios (utilizando a ferramenta Microsoft Reporting Services), integrados Intranet da corporao (Microsoft SharePoint), que permitem aos usurios de nvel de conhecimento (administradores de nvel mdio - decises tticas) a obteno de relatrios e realizar anlises destes. Um primeiro exemplo foi a criao de um relatrio que permitiu a anlise do volume de documentos trafegados (Figura 7), e um dashboard (Figura 8) que possibilitou um melhor acompanhamento do faturamento da empresa.

Figura 7: Relatrio atravs da Web.

Figura 8: Dashboard do faturamento atravs da Web.

Embora a interface Web seja fcil de utilizar, ela possui algumas limitaes. Todos os relatrios so pr-formatos, permitindo uma manipulao limitada das

dimenses. Apesar de o projeto priorizar o uso da Web, para o caso de anlises mais sofisticadas, so necessrias algumas ferramentas especficas, que incorporam, inclusive, mtodos e prticas diferentes (BARBIERI, 2001). Para isso, percebe-se a necessidade de utilizar alguma ferramenta que conecte a base multidimensional e permita anlises de negcios mais avanadas. As planilhas so as principais ferramentas do usurio final para a programao de aplicaes de suporte deciso (TURBAN et. al, 2009). Neste contexto, o Microsoft Excel tem sido amplamente adotado como uma ferramenta eficiente e fcil de usar para a manipulao de dados. Ele evoluiu para alm de uma simples ferramenta para clculo de dados, ao ponto de agora ser usado como uma ferramenta sofisticada e flexvel para coleta, anlise e sintetizao de dados de mltiplas fontes. Por estes motivos, o Excel uma ferramenta que se integra s principais solues de BI do mercado. Sua principal funo como ferramenta de visualizao de dados com acesso a cubos. Empresas como Microsoft, SAP, MicroStrategy e at mesmo a Oracle, disponibilizam plugins para que o Excel conecte aos seus cubos. Como uma ferramenta amplamente utilizada na NeoGrid, o Excel ser a ferramenta que ser conectada aos cubos e permitir que os diretores da empresa (administradores de nvel superior - decises estratgicas), possam realizar anlises mais avanadas (Figura 9).

Figura 9: Acesso aos cubos atravs do Excel.

Durante o desenvolvimento da aplicao, surgiu a oportunidade de realizar um teste em produo, e verificar a eficincia da soluo. O faturamento, referente aplicao Mercador, do ms de outubro havia diminudo comparado com o ms de setembro. Depois de realizada a carga dos dados de produo, foi possvel analisar os relatrios e estabelecer alguns relacionamentos. Ao contrrio do que se pensava, o aumento no volume de documentos trafegados no aumenta proporcionalmente o faturamento (o que deixou diretores e gerentes preocupados). Com os relatrios gerados (Figura 10), foi possvel analisar o faturamento dos Top 400 clientes ao longo dos ltimos 6 meses. Analisando o faturamento dos meses anteriores, foi identificado um erro operacional nas tabelas de preo e de cobrana.

Como a descoberta da informao foi rpida, aps algumas correes, foi possvel gerar as faturas novamente, sem gerar perdas para a NeoGrid. At o presente momento, no existiam maneiras de comparar (ou relacionar) o faturamento ou trfego de documentos ao longo do tempo. O ltimo relatrio deste tipo havia levado mais de dois meses para ser finalizado.

Figura 10: Relatrio de utilizao do portal Mercador.

3.7 Teste e Homologao Finalizado o desenvolvimento, a aplicao foi instalada no ambiente alpha (ambiente para produtos em fase de testes, sem acesso aos usurios finais) e entregue equipe de testes para realizar o processo de verificao. Durante os testes de processamento dos cubos, foram detectadas algumas anomalias nos dados de produo, como, por exemplo, empresas cadastradas mais de uma vez (foram encontradas empresas com at 10 cadastros). O processamento dos cubos gerava erro, pois a razo social da empresa um dos atributos das dimenses de LOCALIZACAO e ORGANIZACAO. O erro era causado pela duplicao de membros do atributo. A soluo foi desenvolver mais um passo no processo ETL para limpar estas informaes, onde foi adicionado o CNPJ da empresa razo social. Terminado o processo de verificao (e aps algumas correes de problemas detectados nos testes), o sistema foi implantado no ambiente de homologao (processo de validao). Este foi o ltimo passo antes da implantao do sistema no ambiente de produo. A equipe de homologao realizou simulaes de volume e de processamento para avaliar o impacto da soluo na produo. Foi validado tambm, o pacote de instalao da soluo.

3.8 Treinamento Aps a entrega do projeto equipe de homologao, foi realizado um workshop sobre a soluo. Participaram deste encontro o diretor da soluo de EDI, o gerente da equipe de implantao EDI e alguns colaboradores da equipe de atendimento ao cliente. O principal objetivo foi apresentar a soluo para estimular os usurios finais a participarem do processo de validao (homologao).

A participao dos usurios neste processo, alm de garantir uma melhor qualidade na entrega do projeto, possibilitou alguns ajustes (ex.: ajuste de layout de alguns relatrios, campos de texto livre que foram alterados para combos, etc.) antes de entrar em produo.

3.9 Implantao Com o produto homologado, foi iniciada a etapa de implantao do sistema no ambiente de produo. Foi selecionado, para hospedar a soluo, o servidor SQL Server responsvel pelos sistemas internos da NeoGrid (que est hospedado em um data center diferente do sistema transacional). Este servidor possui um sistema operacional Windows 2003 Enterprise 64 bits em conjunto com SQL Server 2008 Enterprise 64 bits. Este servidor est em cluster failover (1 n ativo + 1 n passivo). O cluster SQL Server j possua rotinas de manuteno e backups (em fita), no sendo necessrio a criao de novas rotinas (jobs). Com os servios necessrios instalados, foram criados monitores para verificar espao em disco, utilizao de hardware (CPU, disco, memria), nmero de transaes por segundo, nmero de usurios conectados, alm de verificar se os servios esto ativos. Com isso, pode-se gerar relatrios para calcular a disponibilidade do sistema, alm de realizar planejamento de capacidade. Aps a disponibilizao da infra-estrutura necessria, todos os pacotes ETL, cubos e relatrios foram publicados. Os processos ETL tero acesso aos bancos de dados de produo (base transacional) atravs de um VPN (Virtual Private Network) estabelecida entre os dois data centers (20Mb/s).

4. Concluses Alguns fatores foram importantes para o sucesso deste projeto, como: (i) a obteno de um patrocinador executivo, que facilitou o envolvimento de equipes e a liberao de recursos; (ii) a lembrana constante de que o objetivo aumentar a produtividade do usurio; (iii) a participao dos usurios um fator crtico para o sucesso do projeto; (iv) o envolvimento tanto de profissionais de TI, quanto analistas de negcios no projeto; e (v) a ateno que deve ser dedicada s etapas de levantamento de necessidades e modelagem dimensional. A soluo continuar evoluindo com novos dashboards e inclundo outros produtos da NeoGrid, como a Nota Fiscal Eletrnica (NF-e).

Referncias Ballard, C., Farrell, D., Gupta, A., Mazuela, C. e Vohnic, S. (2006), Dimensional

Modeling: In a Business Intelligence Environment, IBM, 645 p. Barbalho, P. (2003), Descubra o Data Warehouse: produtividade e rapidez, SQL

Magazine, Rio de Janeiro, n. 03, p. 34-38. Barbieri, C. (2001), Business Intelligence: Modelagem e Tecnologia, Axcel Books,

424p. Carvalho, B. (2003), Arquitetura de ferramentas OLAP, SQL Magazine, Rio de

Janeiro. 09, p. 12-16. Delaney, K. e Agarwal, S. (2006), Practical Business Intelligence with SQL Server

2005, Addison-Wesley Professional, 432 p. Inmon, W. H. (2005), Building the Data Warehouse, Wiley, 576 p. Italiano, I. C. e Esteves, L. A. (2004a), Modelagem de Data Warehouses e Data Marts

Parte 1, SQL Magazine, Rio de Janeiro, n. 13, p. 42-45. Italiano, I. C. e Esteves, L. A. (2004b), Modelagem de Data Warehouses e Data Marts

Parte 2, SQL Magazine, Rio de Janeiro, n. 14, p. 37-43. Jacobson, R. e Misner, S. (2007), Microsoft SQL Server Server 2005: Analysis

Services, Microsoft Press, 340 p. Kimball, R. (2002), The Data Warehouse Toolkit, Wiley, 464 p. Langit, L. (2008), Foundations of SQL Server 2005: Business Intelligence, Apress, 396

p. Larson, B. e Agarwal, S. (2006), Delivering Business Intelligence with Microsoft SQL

Server 2005, McGraw-Hill, 792 p. Machado, F. N. (2004), Tecnologia e Projeto de Data Warehouse, rica, 318 p. Reis, E., Teixeira, F. e Arajo, M. A. (2009), Implementando uma soluo de Business

Intelligence com o Microsoft SQL Server 2005 Parte 1, SQL Magazine, Rio de Janeiro, n. 59, p. 52-66.

Scheeren, J. (2009), Modelagem Visual de Data Warehouses e Data Marts, Trabalho de Concluso de Curso (Graduao em Sistemas de Informao), Centro Universitrio Ritter dos Reis, Porto Alegre.

The OLAP Report (2009), OLAP market share analysis, http://www.olapreport.com/market.htm, Junho.

Turban, E., Sharda, R., Aronson, J. e King, D. (2009), Business Intelligence: um enfoque gerencial para a inteligncia do negcio, Artmed, 254 p.

Turley, P., Kasprzak, J. e Cameron, S. (2007), Microsoft SQL Server Server 2005: Integration Services, Microsoft Press, 453 p.

Apndices

Apndice A Modelos Fonte das Informaes Faturamento e Trfego

Apndice B Modelos Fonte dos Dados Faturamento e Trfego

Apndice C - Modelos ER dos Fatos Faturamento e Trfego