UTILIZANDO DATA MART PARA O DESENVOLVIMENTO DE BUSINESS INTELLIGENCE APLICADA A CARTEIRA DE PEDIDOS DE UMA EMPRESA DO SETOR TÊXTIL

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO UTILIZANDO DATA MART PARA O DESENVOLVIMENTO DE BUSINESS INTELLIGENCE APLICADA A CARTEIRA DE PEDIDOS DE UMA EMPRESA DO SETOR TÊXTIL ROBSON ROGÉRIO GAMBA BLUMENAU 2007 2007/1-17

ROBSON ROGÉRIO GAMBA UTILIZANDO DATA MART PARA O DESENVOLVIMENTO DE BUSINESS INTELLIGENCE APLICADA À CARTEIRA DE PEDIDOS DE UMA EMPRESA DO SETOR TÊXTIL Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação - Bacharelado. Prof. Oscar Dalfovo, Doutor Orientador BLUMENAU 2007 2007/1-17

UTILIZANDO DATA MART PARA O DESENVOLVIMENTO DE BUSINESS INTELLIGENCE APLICADA À CARTEIRA DE PEDIDOS DE UMA EMPRESA DO SETOR TÊXTIL Por ROBSON ROGÉRIO GAMBA Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Dr. Oscar Dalfovo, Orientador, FURB Prof. Alexandre R. Valdameri, M. Eng. FURB Prof. Wilson P. Carli, M. Eng. FURB Blumenau, 18 de junho de 2007

Dedico este trabalho a todos os familiares, amigos, e demais pessoas que de alguma forma contribuíram para a realização deste sonho.

AGRADECIMENTOS A Deus, pela Vida. A toda minha família, pelas oportunidades, educação, constante preocupação e apoio. Aos meus amigos, pelos momentos em que não pude estar presente. A Georgiana Ramos, pela compreensão, companheirismo e extremo carinho para com esse sonho. À A.M.C Têxtil Ltda, pelo suporte e confiança neste projeto. Ao orientador e amigo, Oscar Dalfovo, pelos momentos de conhecimento e formação e por ter acreditado na conclusão deste trabalho.

Se conheces o inimigo e te conheces a ti mesmo, não precisas de temer o resultado de cem batalhas. Se te conheces a ti mesmo, mas não conheces o inimigo, por cada vitória sofrerás também uma derrota. Se não te conheces a ti mesmo nem conheces o inimigo, perderás todas as batalhas. Sun Tzu, A Arte da Guerra

RESUMO Com as evoluções constantes do mercado as empresas, por necessidades, buscam medidas para acompanhar essas mudanças. O dinamismo e confiança no processo decisório tornaramse essenciais para a sobrevivência da empresa. O presente trabalho tem como objetivo apresentar e descrever o desenvolvimento de um Business Intelligence utilizando o Data Mart em conjunto com técnicas de cubo de decisão, sendo aplicada a carteira de pedidos da empresa A.M.C Têxtil Ltda. Foi utilizado neste trabalho a metodologia de análise orientada a objeto e desenvolvida a aplicação através do banco de dados Caché e ferramentas OLAPBrowser, buscando-se agilidade e a dinâmica necessária para processo de tomada de decisão. Palavras-chave: Data mart. Business intelligence. Cubos de decisão

ABSTRACT With the constant market evolution the companies, by necessity, search for ways to follow these changes. The dynamism and confidence in the decision making process has become essential for the survival of the company. The following paper has as objective to present and to describe the development of a Business Intelligence by means of the Data Mart along with techniques of decision cubes, being applied to the AMC Têxtil order backlog. It was used in this paper the methodology of object oriented analyses and developed the Caché database and OLAP Browser tools, searching for agility and the necessary dynamics for the process of decision taking. Keywords: Data mart. Business intelligence. Decision cubes

LISTA DE ILUSTRAÇÕES Figura 1 Dados de múltiplas fontes...21 Figura 2 Data Warehouse orientado a assunto...22 Figura 3 Integração em um DW...23 Figura 4 Não volatilidade...24 Figura 5 Variação em relação ao tempo...25 Figura 6 Star Schema...26 Figura 7 Questão da granularidade...28 Figura 8 Arquitetura Data Mart...30 Figura 9 Modelo de um cubo de decisão...34 Figura 10 Exemplo de global do Caché...37 Figura 11 Arquitetura das linguagens Caché...39 Figura 12 Exemplo de caso de uso...47 Figura 13 Diagrama de caso de uso...48 Figura 14 Arquitetura da ferramenta OLAPBrowser...50 Figura 15 Rotina de exportação de arquivos...57 Figura 16 Lógica do Schema.ini...58 Figura 17 Inicialização da carga DM...59 Figura 18 Carga incremental...60 Figura 19 Tela de configuração de exportação...60 Figura 20 Entrada de dados...61 Figura 21 Aplicação do algoritmo temporal...62 Figura 22 Permissões nos cubos de decisão...63 Figura 23 Organização dos fatos e dimensões...63 Figura 24 Geração do cubo de decisão...64 Figura 25 Abertura do cubo de decisão...65 Figura 26 Drill up...65 Figura 27 Drill down..66 Figura 28 Slice and dice...66 Figura 29 Geração de gráficos...67 Figura 30 Visibilidade...67 Figura 31 Navegação...68

Figura 32 Exportação da análise...69

LISTA DE QUADROS Quadro 1 Requisitos funcionais...45 Quadro 2 Requisitos não funcionais...45 Quadro 3 Dimensões...53 Quadros 4 Fatos...54

SUMÁRIO 1 INTRODUÇÃO...13 1.1 OBJETIVOS DO TRABALHO...15 1.2 RELEVÂNCIA DO TRABALHO...16 1.3 ESTRUTURA DO TRABALHO...16 2 FUNDAMENTAÇÃO TEÓRICA...18 2.1 BUSINESS INTELIGENCE...18 2.1.1 Data Warehouse...19 2.1.1.1 Princípios de um Data Warehouse...21 2.1.1.2 Características de um Data Warehouse...22 2.1.1.3 Star Schema...25 2.1.1.4 Snowflake Schema...27 2.1.1.5 Granularidade...27 2.1.1.6 Agregação...28 2.1.1.7 Particionamento de dados....29 2.1.1.8 Metadados...29 2.1.2 Data Mart...30 2.1.3 Data Warehouse x Data Mart...31 2.1.4 Processamento analítico on-line OLAP...31 2.1.4.1 Características das ferramentas OLAP...32 2.1.5 Cubo de decisão...33 2.1.6 Data Warehouse Dimensional...34 2.2 BANCO DE DADOS CACHÉ...36 2.2.1 Caché ObjectScript...38 2.3 A.M.C TÊXTIL LTDA...40 2.4 CARTEIRA DE PEDIDOS...41 2.5 TRABALHOS CORRELATOS...42 3 DESENVOLVIMENTO DA FERRAMENTA...44 3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO...44 3.2 ESPECIFICAÇÃO...46 3.2.1 UML Unified Modeling Language...46 3.2.1.1 Diagrama de caso de uso....46

3.2.1.2 Enterprise Architect...47 3.2.2 Ferramentas Caché...48 3.2.3 Contour OLAPBrowser...49 3.3 IMPLEMENTAÇÃO...50 3.3.1 Diagrama de caso de uso... Erro! Indicador não definido. 3.3.1.1 Descrição do diagrama...50 3.3.2 Estudo de viabilidade...51 3.3.3 Coleta de informações e documentação das análises...51 3.3.4 Métodos de trabalho e avaliação dos resultados...51 3.3.5 Fases do desenvolvimento do Data Mart...52 3.3.5.1 Identificar o assunto...52 3.3.5.2 Definição da granularidade...52 3.3.5.3 Escolha das dimensões...53 3.3.5.4 Especificar os Fatos...54 3.3.5.5 Armazenamento de dados...55 3.3.5.6 Preenchimento das tabelas dimensionais...56 3.3.5.7 Duração do banco de dados...56 3.3.5.8 Dimensões de modificação lenta...56 3.3.5.9 Intervalo de atualização de dados...56 3.3.6 Operacionalidade da implementação...57 3.4 RESULTADOS E DISCUSSÃO...69 4 CONCLUSÕES...71 4.1 EXTENSÕES...72 REFERÊNCIAS BIBLIOGRÁFICAS...73

13 1 INTRODUÇÃO O mercado vem se tornando cara vez mais dinâmico, necessitando assim que as empresas busquem ferramentas para dar-lhes diferenciais competitivos no mundo dos negócios. Com a utilização da técnica de Data Mart (DM), aliada a conceitos e ferramentas de Business Inteligence, como o cubo de decisão, é possível tornar ágil e confiável o processo de tomada de decisão. Conforme Inmon, Terdeman e Imhoff (2001) não existe uma fórmula predeterminada para transformar as informações em vantagens de mercado. Contudo, este processo requer a analise de vários fatores, como o ambiente em que a empresa está inserida, um plano de estratégia que reflita as necessidades do mercado e que os objetivos sejam claros e possíveis de serem alcançados. Em grande parte das empresas, as análises e tomadas de decisões são baseadas em relatórios estáticos derivado do próprio sistema. Quase não há possibilidade de cruzamento entre os dados, havendo uma individualização dos fatos dos diversos grupos administrativos. Isso significa que as empresas são ricas em quantidade de dados armazenados, mas pobre em dados úteis, oferecendo somente respostas sobre perguntas relativamente simples, conforme Oliveira (1998). Os métodos tradicionais de consultas estão se tornando inviáveis, sendo assim é necessário buscar novas técnicas para que as informações possam ser exploradas de forma a criar uma melhoria real e significativa no processo de tomada de decisão. Tendo como base estas dificuldades, foram criados e desenvolvidos uma série de novos conceitos e técnicas para satisfazer a necessidade dos administradores de que informações pudessem gerar novos conhecimentos além daqueles que já haviam sido adquiridos com seus relatórios do sistema. Um desses conceitos foi batizado de Data Warehouse (DW), numa tradução literal, armazém de dados. Segundo Inmon (1997), Data Warehouse é um conjunto de dados baseado em assuntos, integrado, não-volátil e variável em relação ao tempo com foco em apoio às decisões gerenciais. Os dados que lhe compõe podem ser extraídos de múltiplas fontes, tais como planilhas ou, na maioria das vezes, do próprio banco de dados operacional da organização. Esse conjunto total de dados de um DW pode ser fracionado ou operado em um nível levemente resumido que foi chamado de Data Mart (DM). Pode-se dizer que o DM é um sub-conjunto de dados de um DW, ou seja, enquanto o Data Warehouse abrange todas as

14 áreas de interesse de uma organização, o DM opera em uma área específica, como a Carteira de Pedidos, Produção ou Financeiro De acordo com Heil (2006), o DM é criado com o intuito de colecionar e organizar os dados, disponibilizando-os para fins de análise, concedendo aos tomadores de decisão a possibilidade de ter acesso rápido e confiável às informações a respeito do seu próprio negócio. Este tipo de dado armazenado em Data Marts é tecnicamente chamado de dado informacional devido ao seu propósito único de traduzir e levar as informações aos analisadores. Para que estes tipos de dados armazenados no DM sejam visualizados, são criados o que chamamos de cubos de decisão, que cubos são um conjunto de componentes de suporte a decisões que podem ser utilizados para cruzar tabelas de um banco de dados, gerando visões através de planilhas ou gráficos, conforme Dalfovo et al (2003). Sua interpretação é semelhante à manipulação de um cubo físico, onde pode-se buscar as informações num mesmo bloco, podendo analisar as suas diferentes faces. A fim de possibilitar a manipulação real dos dados, estes cubos são processados com sistemas On-line Analytical Processing (OLAP), que proporcionam qualidade e performance de recuperação e visualização das informações. Análises antes estáticas são visualizadas e estudadas de forma dinâmica permitindo criar visões que não podiam ser disponibilizadas. Novos conhecimentos estão sendo descobertos e aplicados da melhor maneira possível como forma de inteligência competitiva. Desenvolvido sobre a carteira de pedidos do grupo A.M.C Têxtil LTDA, que é atualmente considerado um dos maiores grupos têxteis do país, detentor de marcas como Colcci, Menegotti Malhas e Sommer, esta ferramenta de Data Mart / Business Inteligence está ligada diretamente ao planejamento estratégico do negócio, tornando-se assim uma importante fonte de informações de nível gerencial. A necessidade da rapidez e solidez no processo de tomada de decisão foram fatores essenciais para a elaboração do projeto, desenvolvimento e implantação de soluções como o Data Mart. A maior parte das análises para o processo de tomada de decisão da empresa são tomados com base em planilhas e gráficos que são gerados manualmente através de um processo de exportação e importação manual de dados provenientes do Enterprise Resource Planning (ERP) utilizando ferramentas não integradas ao sistema de informação atual, causando diversos problemas de compatibilidade e consistência das informações. Essa transformação dos dados está se tornando cada vez mais morosa devido ao volume e complexidade do processo, ocorrendo em certos casos de ultrapassar semanas de trabalho.

15 Este tempo que é consumido operacionalmente na confecção de relatórios externos é tirado dos administradores, restringindo o espaço de tempo de análise de casa situação. Isto significa que os responsáveis pelas tomadas de decisões estão perdendo mais tempo elaborando seus relatórios do que efetivamente analisando-os. Os dados disponíveis através da carteira de pedidos são responsáveis pela maior parte do estudo realizado pelos administradores, pois são sobre estes que as principais decisões tanto a nível operacional como gerencial são tomadas. É sobre ela que são previstas as metas e perspectivas de crescimento do negócio, toda a programação da produção industrial é elaborada dentre outros pontos que são revistos e definidos ao longo da análise dos dados disponíveis. Com os fatores expostos, é criada uma base paralela à operacional para que estes dados provenientes do ERP da empresa possam ser convertidos e armazenados em um Data Mart da carteira de pedidos que tem a função de disponibilizar uma referencia ágil e confiável para relatórios e análises gerenciais. O armazenamento destes dados no Data Mart bem como a extração dessa grande massa de informações utilizando linguagem e banco de dados Caché em conjunto com ferramentas competentes para a construção e visualização dos cubos proporciona uma perfeita integração e rapidez para disponibilizar as informações, realizar os processos de tomada de decisão e explorar novos conhecimentos, estando assim indo de encontro às necessidades e expectativas da empresa. 1.1 OBJETIVOS DO TRABALHO O objetivo geral deste trabalho é o desenvolvimento de um Bussiness Intelligence utilizando o Data Mart aplicado ao módulo de Carteira de Pedidos para auxiliar na agilidade e dar suporte à tomada de decisões da empresa. Os objetivos específicos do trabalho são: a) identificar os requisitos e informações na empresa para compor um Business Intelligence utilizando o Data Mart da carteira de pedidos da empresa do setor têxtil; b) criar configurações que permitam a exportação dos dados do DM para posterior análise com Cubos de Decisão;

16 c) disponibilizar essas informações aos usuários com a possibilidade de visualizá-las graficamente com o intuito de auxiliar os executivos no processo tomada de decisão. 1.2 RELEVÂNCIA DO TRABALHO A agilidade e versatilidade que as informações disponibilizadas pelo DM trazem para o processo de tomada de decisão é fundamental à empresa. A possibilidade de se criar relatórios dinâmicos, construir visões diferentes do negócio e enxergar tendências de mercado a partir de informações geradas pelo Business Intelligence através do Data Mart, traz um fator diferencial de reação e pró-ação em relação aos concorrentes diretos no mercado. O conhecimento que se encontra armazenado no banco de dados transacional da empresa por vezes não é explorado de forma correta. E a maneira em que estes dados são apresentados aos tomadores de decisão se torna inviável. Assim, são aplicadas novas técnicas para explorar essas informações criando-se uma melhoria real no processo de tomada de decisão. Aliado a técnica de cubo de decisão, o Data Mart vêm de encontro com as necessidades dos administradores da empresa, que buscam otimização no tempo de geração das visões e relatórios dinâmicos, resultando no ganho de tempo maior para a análise e processo de tomada de decisão. Através da utilização dessas novas técnicas, novos conhecimentos sobre a organização estão sendo aplicados da melhor maneira possível como forma de inteligência competitiva e apoio à tomada de decisão. 1.3 ESTRUTURA DO TRABALHO Este trabalho está constituído de quatro capítulos. O primeiro capítulo refere-se à introdução, objetivos e relevância do trabalho. No segundo capítulo são descritos e fundamentados teoricamente conceitos relativos a Business Intelligence, com enfoque a Data Warehouse e Data Mart. São explanados também demais conceitos como cubo de decisão e OLAP além de uma descrição sobre a empresa e

17 sua carteira de pedidos, foco desse trabalho. O terceiro capítulo trata do desenvolvimento da ferramenta, elencando e descrevendo os requisitos do problema, demonstrando as técnicas e ferramentas utilizadas e apresentando os resultados obtidos com a construção do aplicativo. No quarto capítulo são apresentadas as conclusões do trabalho, sugestões para melhoria e continuidade bem como as dificuldades e limitações da ferramenta.

18 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são resumidamente abordados conceitos de Business Intelligence Data Warehouse. Também serão explanados conceitos de Data Mart, fundamentado suas principais características e métodos de desenvolvimento. Em conjunto serão apresentados conceitos relativos a OLAP e cubos de decisão. Serão igualmente apresentadas algumas características do funcionamento do banco de dados Caché e da empresa A.M.C Têxtil Ltda bem como abordados a carteira de pedidos da empresa em questão e trabalhos correlatos ao tema. 2.1 BUSINESS INTELIGENCE O Business Intelligence (BI), ou inteligência do negócio, sempre esteve presente na vida das civilizações. Pode-se dizer que os dados como chuva e o nível dos rios eram cruzados de forma primitiva para fornecer informações relativas às colheitas ou estações do ano. Com o passar dos séculos e o surgimento das organizações e posteriormente os sistemas informatizados, o BI surgiu como o conhecemos hoje, descrito como a habilidade de acessar os dados existentes nos banco de dados operacionais das empresas e fazer a exploração das informações, que serão disponibilizadas para os analistas do negócio. Basicamente o BI consiste em coletar, organizar, analisar, compartilhar e monitorar as informações que podem oferecer o suporte necessário à tomada de decisão, segundo DwBrasil (2007). O BI é pode ser visto com um processo que destaca as informações dentro dos dados gerando conhecimento. Os envolvidos nesse processo são capazes através de ferramentas fazer buscas as informações, realizar o armazenamento de informações dando ao usuário acesso aos dados de múltiplas formas. Os sistemas Business Intteligence tem como principais características: a) a extração e integração de dados de múltiplas fontes; b) fazer o uso da experiência e estatística para analisar os dados; c) utilizar contextualização das informações para organização das views; d) trabalhar com hipóteses;

19 e) procurar relações de causa e efeito; f) ter a habilidade de transformar os dados extraídos em informações. Para desenvolver um aplicativo BI, deve ser analisado cada caso em específicos, já que as análises podem envolver uma grande massa de dados. Para ser possível construir um ambiente tecnológico em que os conceitos do BI possam ser plenamente utilizados e possibilitar rapidez e maior flexibilidade na análise uma série de ferramentas foram criadas e desenvolvidas: a) Data Warehouse; b) Data Mart; c) OLAP; d) Data Minning; e) Executive Information System - Sistema de Informação para Executivos (EIS); f) Planilhas eletrônicas; g) Cubos de decisão. 2.1.1 Data Warehouse Com o ambiente das empresas se tornando cada vez mais dinâmico, um quesito crucial para a sobrevivência do negócio é a capacidade que a organização adquire de aprender e responder as mudanças com mais rapidez do que seu concorrente. Levando em consideração os dados disponíveis nos bancos de dados das empresas, os analistas precisam saber da existência dos dados, o que eles significam no mundo real dos negócios e como eles poderão ser utilizados para resolver os problemas da organização. A necessidade de novas informações muda rapidamente. Quanto maior o porte da empresa, maior a demanda de conhecimento para que se possa dar o suporte necessário à tomada de decisão. Essas informações precisam ser disponibilizadas em espaços cada vez mais curtos de tempo com eficiência e possuir um alto grau de confiabilidade. Os recursos de dados de muitas organizações não dão o suporte necessário à demanda de informações da empresa. Eles contêm grande quantidade de dados não relevantes e a maioria dos sistemas são desenvolvidos levando os analistas a conhecimentos imediatistas e relativos a operacionalidade das empresas, não tendo capacidade de prover informações para decisões futuras e planejamentos a médio e longo prazo. De acordo com Brackett (1996) os sistemas de Data Warehouse vêm se tornando

20 importantes nas grandes companhias pela capacidade de trazer aos analistas uma grande quantidade de dados agrupados e a habilidade de sumarizar tanto em alto quanto em baixo nível analítico resolvendo os problemas de agilidade e confiabilidade nas informações. Sendo assim, o Data Warehouse, ou armazém de dados, foi criado com o intuito de organizar e armazenar os dados de tal forma a causar um impacto na maneira em que as informações são guardas e recuperadas para posterior analise nas organizações. De acordo Oliveira (1998), o DW é um banco de dados que armazena dados sobre as operações da empresa podendo ser extraídos de uma única fonte ou múltiplas, fazendo a transformação dessa massa em informações que possam ser úteis, dando suporte efetivo a tomada de decisão. Kimball (1998) apud Viegas e Silveira (2002) faz a definição de DW como um conjunto de técnicas e ferramentas que projetadas e aplicadas às necessidades específicas da empresa e aplicados aos bancos de dados permitirá que se planeje e construa um Data Warehouse. Segundo Inmon (1997), um Data Warehouse é um conjunto de dados baseado em assuntos, integrado, não-volátil, e variável em relação ao tempo, de apoio às decisões gerenciais. Somente as informações necessárias para a tomada de decisões são carregadas, vindas de bancos operacionais. Como este novo banco de dados contém apenas informações relevantes, as análises e pesquisas feitas sobre ele se tornam ágeis conseguindo responder a questões complexas do negócio. Outro ponto importante é que o DW permite que os usuários derivem informações de dados antes independentes, conforme Figura 1.

21 Fonte: Oliveira (1998, p. 4). Figura 1 Dados de múltiplas fontes 2.1.1.1 Princípios de um Data Warehouse Segundo Oliveira (1998), devem ser observados alguns aspectos, sendo tomados como princípios para a construção de um Data Warehouse: a) o DW deve oferecer acesso imediato aos dados da corporação ou organizacionais. Os envolvidos nas análises devem poder acessar esses dados de forma ágil. As ferramentas de extração de dados devem ser as mais amigáveis possíveis; b) os dados de um Data warehouse devem ser consistentes. Duas consultas se observando os mesmos filtros devem retornar o mesmo valor. Os dados devem ser compreensivelmente definidos e disponíveis; c) os dados de um DW devem poder ser separados, combinados e analisados de todas as formas possíveis; d) o DW não deve ser apenas umas massa de dados, mas sim um conjunto de ferramentas para pesquisa, análise e apresentação das informações; e) os dados podem ser gerados de uma variedade de fontes organizacionais limpas, com qualidade e recuperadas somente se servirem para uso; f) a qualidade de dados de um Data Warehouse deve servir como um direcionador

22 para a reengenharia dos negócios da empresa. Os dados não podem contém qualidade irrelevante. 2.1.1.2 Características de um Data Warehouse De acordo com Inmon (1997), os dados utilizados pelo DW devem seguir quatro características principais que devem ser aplicadas. A primeira delas prega que um Data Warehouse deve ser baseado em assuntos. Ou seja, a construção de um DW deve se guiar pelos maiores níveis de assuntos da empresa, como contabilidade, clientes e pedidos. A Figura 2, demonstra a característica de um DW de basear-se em assuntos. Fonte: Santos (2003, p. 23). Figura 2 - Data Warehouse orientado a assuntos A segunda e talvez mais importante característica, a integração, é demonstrada na Figura 3.

23 Fonte: Inmon(1997, p. 35) Figura 3 Integração em um DW Como os dados de um DW podem ser captados de múltiplas fontes, não há garantias que todos eles estejam formatados de uma maneira uniforme. Por vezes cada aplicação contém suas próprias particularidades e métodos, podendo tornar os dados incompatíveis. Esses dados devem ser filtrados e traduzidos para poder transformar a base de um DW em algo coerente e consistente. O aspecto seguinte refere-se à não-volatilidade dos bancos de dados Data Warehouse. Enquanto nos ambientes operacionais os dados sofrem constante atualização e são acessados um de cada vez, um conjunto de diferentes características são observadas no DW. A atualização de dados, por exemplo, é feita somente de tempos em tempos, além de os dados serem carregados e acessados em massa. A Figura 4, a seguir, ilustra a questão.

24 Fonte: Inmon (1997, p. 36). Figura 4 Não-Volatilidade A última característica importante de um DW trata da variação dos dados em relação ao tempo. Para um sistema operacional de dados, algo variando entre 60 dias a três meses é normal. Já para um ambiente de Data Warehouse esse horizonte pode se estender com normalidade entre 5 a 10 anos. Outro aspecto que difere o DW de um sistema operacional de dados (SOD) é a maneira de como enxergamos os valores. Enquanto em um SOD os valores somente são válidos para o momento e podem ser alterados, nos DWs os valores passam a ser instantâneos e servem para serem carregados somente em um determinado momento. Além disso a estrutura operacional de dados pode não conter informações como dia, mês e ano, fatos imprescindíveis para o Data Warehouse. A figura 5 a seguir mostra a situação da variação em relação ao tempo.

25 Fonte: Inmon (1997, p. 37). Figura 5 Variação em relação ao tempo Para a criação de um Data Warehouse, Oliveira (1998), sugere algumas atividades que resumidamente se mostram necessárias para o planejamento, análise, mineração e visualização destes dados: a) transformação nos Dados: os dados que estão armazenados nos banco de dados operacionais das empresas devem passar por uma transformação para a desnormatização dos mesmos e inseridos no Data Warehouse de acordo com as regras e necessidades definidas através das necessidades; b) analise Estatística: os dados armazenados devem ser procurados por padrões na busca de tenta localizar tendências e conhecimento para o melhor aproveitamento do DW; c) mineração dos dados: utilizando complexas pesquisas através de filtros definidos, esta técnica pode ser utilizada para a busca de variáveis que eram previamente vistas como independentes. Serve principalmente para a procura de relacionamentos de causa e efeito; d) visualização: como em muitos casos a análise pode se tornar demasiadamente complicada, a melhor maneira de se expor estes resultados é a utilização de recursos visuais como gráficos ou slides. 2.1.1.3 Star Schema O método de Star Schema ou esquema estrela foi criado para possibilitar a melhora de

26 performance de consultas aos Data Warehouses, introduzindo um novo conceito em modelagem de dados se diferenciando do modelo entidade relacionamento por permitir redundância, conforme Kimball (1998). Essa abordagem é diferenciada por encorajar o alto gral de desnormatização, com o objetivo principal de reduzir o numero de junções (joins) que estão relacionados às consultas de dados. O modelo foi assim batizado devido à semelhança do modelo dimensional com uma estrela, onde observa-se uma tabela central conhecida como tabela fato, e as outras tabelas que a rodeiam, denominadas dimensões, conforme Figura 6. A tabela fato agrega as chaves das tabelas dimensões para a caracterização dos fatos ocorridos. Ela é principalmente utilizada para fazer a métrica da performance do negócio, ou seja, possui os indicadores numéricos sobre a organização. Já as tabelas dimensões, armazenam as características de um determinado evento, contendo os seus atributos dando assim a informação adicional sobre as medidas. Assim sendo, as consultas percorrem inicialmente as tabelas dimensões e posteriormente as tabelas fatos, não necessitando percorrer todas as tabelas graças a estrutura de chaves, permitindo assim um melhor desempenho e acessos ágeis. Fonte: Adaptado pelo autor de Kimball e Ross (2002, p. 28) Figura 6 Star Schema

27 2.1.1.4 Snowflake Schema O modelo snowflake é considerado uma extenção do modelo star. Ele resulta da decomposição (normalização) de uma ou mais dimensões, formando assim, hierarquias nessas dimensões. Conforme Kimbal (1998), esse modelo é usado quando as dimensões são muito grandes que por definição são estáticas ou semi-estáticas ou ainda quando a ferramenta utilizada exigir o uso do modelo. A vantagem do seu uso está no fato de haver um diminuição no volume de dados que é trazido para a memória além da facilidade do join com a tabela normalizada, que é mais facilmente resolvido. No entanto, caso a navegação dentro da hierarquia da dimensão seja inevitável, a maior quantidade de joins torna a consulta mais complexa. 2.1.1.5 Granularidade Um dos aspectos mais importante na construção de um Data Warehouse diz respeito a granularidade. Segundo Inmon (1997), granularidade é o nível de detalhamento ou o nível que os dados estão sumarizados no banco de dados. Quanto maior for o grau de detalhamento do dado, menor será o seu grau de granularidade. Quanto menor o grau de detalhamento, maior será o seu grau de granularidade. Isso significa que se definirmos o grão em um nível muito detalhado, o usuário poderá obter as informações em qualquer nível de agregação. Por outro lado, se o nível de granularidade definida ser muito alto, o analista ficará sem a possibilidade de detalhar a fundo suas pesquisas. Além desses pontos, a escolha desses grãos é diretamente proporcional à ocupação de espaço em disco e o número de índices necessários para uma consulta no DW, conforme demonstrado na Figura 7. Escolher os níveis apropriados de granularidade é um fator fundamental para o sucesso do projeto. A melhor maneira de escolha desses níveis é o bom senso e caso necessário, criar uma base prévia do DW para que os analistas utilizem e através do retorno obtido, verificar se os níveis que foram definidos estão de acordo com as reais necessidades dos tomadores de decisão.

28 Fonte: Santos (2003, p. 25) Figura 7 Questão da granularidade 2.1.1.6 Agregação Agregação, por definição significa agrupar em hierarquias. Agregam-se coisas todo tempo em nosso dia a dia, como ruas em bairros, cidades em estados, meses em anos. A nível de dados não poderia ser diferente. Segundo Heil (2006) apud Corey e Abrahmson (1998), um dos fatores críticos das aplicações de análise de dado é o tempo de resposta das consultas. Uma maneira efeciente de se reduzir esse tempo é pré-agregar ou consolidar os dados em totais e sub-totais através das dimensões do referido assunto. O fato de as hierarquias não necessariamente fazerem parte das dimensões, em nível de negócio, elas podem ser perfeitamente agregadas, como questões de datas e localidades. Vale lembrar que se o usuário optar por fazer um drill-down na informação que está analisando, isto irá acarretar em um tempo de espera maior. Deve-se ficar atento também a cada nova cargo do Data Warehouse, que terá de realizar o recálculo de toda ou pelo menos

29 parte da tabela de agregação envolvida. 2.1.1.7 Particionamento de dados. O objetivo principal do particionamento de dados é dividir os dados em unidades físicas menores. Inmon (1997) considera que o particionamento de dados proporciona aos responsáveis pelo projeto do DW maior flexibilidade no gerenciamento dos dados. Uma das características de um DW é a de acesso flexível aos dados. Possuindo-se uma grande quantidade de dados para gerenciar pode-se encontrar algumas dificuldades como a perda de facilidade de reestruturação dos dados, questões de reorganização recuperação e manuseio se tornam proporcionalmente complicadas conforme o volume de dados. Existem duas formas de se realizar esse particionamento de dados, que nada mais é do que dividirmos dados de uma mesma estrutura em unidades menores. O primeiro deles é o particionamento em nível de sistema. Geralmente, esse particionamento é considerado até certo ponto função do sistema de gerenciamento do banco de dados e do sistema operacional. Já o particionamento no nível de aplicação é única e exclusivamente gerenciado pelo desenvolvedor do DW. Conforme Inmon (1997), como regra, se houver particionamento, ele deve ser feito no nível de aplicação por uma série de razões. A primeira delas é de que nesse nível é possível existir mais de uma definição para as unidades físicas. Ou seja, toma-se como exemplo duas unidades de anos, 1997 e 1998. Sendo assim, pode existir uma definição de dados para cada ano e elas podem ser iguais ou não. Outro fato importante do particionamento em nível de aplicação reside no fato de ela poder ser transferida de um complexo de processamento para outro sem afetar a base de dados. 2.1.1.8 Metadados De acordo com Oliveira (1998) metadados é a camada de diretório de dados onde se mantém algum tipo de dicionário de dados para prover informações sobre as estruturas de dados de um DW. Segundo Kimball e Ross (2002) metadados são todas as informações no ambiente de Data Warehouse que não são os dados propriamente ditos. Podemos encontrar metadados que

30 orientam os processos de transformação e carga, inclusive com arquivos de testes e layout de tabelas, regras de transformação e filtragem. Os metadados que dizem respeito ao DBMS contêm informações de itens como tabelas do sistema, configuração de partições, índices e privilégios. E por último são compostos (desenvolvidos) metadados das ferramentas de acesso aos dados que contém as definições comerciais das tabelas e colunas bem como os filtros destas e as especificações dos modelos. O objetivo principal da criação deste é catalogar e documentar melhor possível os pontos que cercam o DW. Embora para os projetistas e desenvolvedores do Data Warehouse considerem esse tempo como perdido, sabe-se da importante do arquivamento ordenado da documentação para um projeto como esse. 2.1.2 Data Mart De acordo com Kimball e Ross (2002) o Data Mart é uma parte do todo que compõe o Data Warehouse, ou seja, o Data Mart representa os dados de um único processo de negócio. Enquanto o DW abrange todas as grandes áreas da empresa, o DM atua como um subconjunto dos dados de um Data Warehouse, fracionado e levemente resumido. A Figura 8 ilustra a arquitetura básica envolvendo um DM. Fonte: Adaptado Heil (2006, p. 36) Figura 8 - Arquitetura Data Mart Os DM são a principal escolha das organizações em nível de suporte a tomada de decisão. Além de baixar consideravelmente o custo da construção de uma ferramenta como o

31 DW, os Data Marts são preferidos pelas unidades de negócio nas empresas que tem a possibilidade de construir seu próprio ambiente de tomada de decisão, conforme Oliveira (1998). Projetos de DW estão sendo construídos na forma de um Data Mart por etapa, reduzindo assim informações que não são úteis para a análise e conseqüentemente diminuindo o volume de dados e o tempo de resposta dessas ferramentas. 2.1.3 Data Warehouse x Data Mart Um DM é uma unidade menor de uma Data Warehouse, conforme visto no tópico 2.1.2. São demonstradas algumas diferenças entre esses dois modelos para melhor elucidação das escolhas, de acordo com Oliveira (1998) e Inmon, Tederman e Imhoff (2001): a) o volume de informações em um Data Warehouse é construído para dar suporte a informações a todas as áreas da empresa enquanto de um Data Mart é desenvolvido apenas para suprir as necessidades de informações de uma determinada área de negócios; b) os objetivos de ambos os modelos também divergem em partes. Enquanto o DW é concebido para otimizar a integração de informações de fontes de dados divergentes, o DM tem como meta principal à entrega ágil de informações aos tomadores de decisão; c) quanto ao tratamento de informações, observa-se que um DW gerencia grande quantidades de dados enquanto o DM está focado no sumário ou exemplo de informações; d) em nível de gerenciamento, o DW por suas características só deve ser gerenciado por um profissional de TI enquanto o DM pode ser gerenciado pelos gerentes de linha. 2.1.4 Processamento analítico on-line OLAP Busca-se através do DW / DM soluções para a gerência, armazenamento e métodos de lidar com os dados da organização. Porém, com o grande volume de dados extraídos e inseridos nesses sistemas, precisa-se de ferramentas que nos permitam fazer consultas mais complexas e elaboradas a respeito do negócio, como comparações, tendências, prospecções,

32 simulações de cenários para futuros imprevistos, cálculos mais complexos e análise de grande quantidade de dados históricos. Devido a falta de ferramentas no contexto Data Warehouse que pudessem fazer estas análises com grande grau de complexidade, mas que fosses ágeis o bastante para serem possíveis de serem utilizadas surgiu o conceito OLAP sigla em inglês de On-line Analytical Processing (processamento analítico on-line). De acordo com Heil (2006) as ferramentas OLAP permitem que os usuários melhorem sua compreensão em relação à empresa e muda a forma como se planeja os negócios. Permite ainda que se façam análises multidimensionais das informações, possibilitando a combinação de dimensões em qualquer ângulo de análise aumentando assim o grau de flexibilidade das análises e, portanto, um incremento na produtividade dos usuários. De acordo com Inmon, Welch e Glassey (1999), a análise multidimensional pode ser vista como a capacidade de manipular dados que já tenham sido agregados em hierarquias, permitindo que se navegue entre os níveis segmentação sem a necessidade de refazer as consultas. 2.1.4.1 Características das ferramentas OLAP Baseado em Kimball (1998), foram reunidas algumas características consideradas importantes nesse tipo de ferramenta. Apesar da busca pelo ideal, nem todas as ferramentas que foram construídas sob o conceito OLAP possuem as características dos tópicos: a) drill up: diminui o grau de detalhamento da informação, ou seja, possibilita o aumento do grau de granularidade; b) drill down: significa obter maior informações (detalhes) sobre os dados que estão sendo apresentados. Realizar esta operação significa diminuir o grau de granularidade na consulta; c) drill across: basicamente é fazer com que duas ou mais tabelas de fato que compartilham dimensões sejam combinadas num único relatório permitindo ao usuário pular um nível intermediário dentro da mesma dimensão; d) drill throught: ocorre quando se passa de uma informação contida em uma dimensão para outra; e) slice and dice: é considerado um dos principais recursos das ferramentas OLAP.

33 Essa técnica consiste na mudança de ordem das dimensões alterando por si a orientação pela qual os dados são apresentados ao usuário. Basicamente, faz a alteração das linhas por colunas e vice-versa com o intuito de facilitar a compreensão das informações; f) tratamento de exceções: é a habilidade da ferramenta de alertar o usuário a alguma falha ou situação anormal ocorrida com o conjunto de análise tais como valores nulos e demarcações de limites; g) visibilidade: a ferramenta deve apresentar se possível no mesmo espectro de analise os fatos e suas restrições bem como as dimensões disponíveis para cruzamento; h) navegação: sugere-se que a navegação seja a mais intuitiva possível, possibilitando ao usuários cruzar dimensões com poucos pulsos do mouse e compreender as dimensões analisadas; i) gráficos e rotação: a ferramenta deve permitir a reorganização da linhas e colunas, tornando a pesquisa mais legível ao usuário. As informações devem ser apresentadas de diversas formas como gráficos, planilhas ou matrizes; j) fonte de dados: trabalhar com múltiplas fontes de dados como Data Warehouse, Data Marts, bancos de dados operacionais e outras fontes externas de dados; k) combinações: analisar os dados, através de qualquer combinação possível entre os mesmos, possibilitando as mais variadas visões possíveis do negócio. 2.1.5 Cubo de decisão Segundo Inmon (1997) o Decision Cube - Cubo de Decisão, faz referência a um conjunto de componentes que provêem suporte à tomada de decisão que podem ser utilizadas para fazer o cruzamento de tabelas de um banco de dados, ou seja, análise multi-dimensional gerando novas visões de negácio através desses cruzamentos que podem inclusive ser visualizados com planilhas e gráficos. Os cubos de decisão tem a característica de trazer os dados pré agrupados e calculados, não necessitando de desnormalização no momento da visualização. Eles podem ser analisados de diversos ângulos e diferentes níveis de agregação, conforme Figura 9. A análise multidimensional faz a representação dos dados em dimensões e não em forma de tabelas. Um cubo pode suportar conceitualmente um número ilimitado de dimensões, cada uma com

34 diferentes valores. No mundo real essas dimensões são limitadas principalmente pela capacidade de hardware a qual o cubo está sendo processado. Fonte: Santos (2003, p. 29) Figura 9 Modelo de um Cubo de Decisão 2.1.6 Data Warehouse Dimensional Modelagem dimensional pode ser vista como uma técnica de criação de banco de dados simples e compreensíveis. Muitas vezes não conseguimos vislumbrar um banco de dados com três ou mais dimensões, sendo assim, podemos utilizar a modelagem dimensional para dar forma ao nosso projeto. Kimball (1998) sugere que a construção de um DW / DM é agregar as necessidades dos usuários em termos de análise aos dados que estão disponíveis para serem explorados no banco de dados operacional da empresa. O primeiro passo consiste deve se identificar o assunto o que vai integrar o Data Mart. Essa identificação é basicamente conseguida com a sensibilidade dos desenvolvedores e analistas e deve responder simultaneamente as mais importante questões de negócios e ser o mais acessível possível do ponto de vista da extração de dados. O próximo passo é considerado um dos passos mais importantes, pois é nesse momento que define-se o nível de granularidade do DM. Essa escolha afeta diretamente o nível de detalhamento das consultas dos usuários e o volume de dados que o Data Mart irá conter.

35 O processo de numero três é o de escolhas das dimensões. As dimensões são as informações que poderão ser cruzadas pelos usuários. O planejamento eficiente do grupo de dimensões pode simplificar e agilizar o uso do Data Warehouse. Na quarta etapa são especificados os fatos. A granularidade da tabela de fatos vai determinar quais fatos podem ser utilizados em um Data Mart. Os fatos podem ser adicionados à tabela de fatos no momento em que se achar necessário, desde que não afete a granularidade definida no passo dois. No quinto passo é analisada a questão do armazenamento dos dados. Kimball (1998) alerta para que sempre que for possível fazer o armazenamento dos resultados dos dados précalculados na tabelas dos fatos. Esse procedimento é realizado devido à probabilidade de erro na carga que afeta diretamente o cálculo dos dados e conseqüentemente levará o usuário final a interpretar os dados de forma inconsistente. A sexta etapa diz respeito ao preenchimento das tabelas dimensionais. Essas tabelas têm por objetivo fornecer entradas para a tabela de fatos diretamente de atributos dimensionais. Os atributos têm a função de descrever os itens de uma dimensão. A granularidade definida no passo dois para a tabela de fatos, também define a granularidade de cada tabela de dimensão. É importante frisar que os atributos textuais que forem incorporados nas dimensões não devem conter abreviaturas indecifráveis e palavras sem sentido, já que esses dados serão visualizados diretamente nos relatórios do usuário final podendo prejudicar a análise. No passo de número sete é definido a duração do banco de dados. Essa escolha esta relacionada com o período de tempo de análise da empresa. Alguns ramos de atividade podem possuir duração baixa, como de um ano. Há casos específicos que esse período pode chegar a décadas. Esse tempo deve ser definido levando em conta principalmente a opinião dos tomadores de decisão, já que estes tem o domínio do nível histórico que a organização necessita. A oitava etapa faz referência à questão das dimensões que possuem o grau de modificação lenta. Neste passo é verificada a possibilidade de valores específicos os quais dificilmente sofrem alterações passarem por atualizações. Se esta situação for constatada pode-se realizar três procedimentos fundamentais. O primeiro prega a substituição dos valores antigos pelos recém gerados, porém perdendo a capacidade de rastrear o seu passado; o segundo propõe que se adicione um registro de dados na dimensão contendo os novos valores o que possibilita um histórico tanto em nível de descrição antiga, como o da nova gerada; o terceiro sugere que se crie um novo atributo na tabela de dimensões para que se faça a

36 diferenciação do primeiro atributo como original e o novo como atual. Na nona e última etapa deverão ser definidas as questões sobre a geração dos dados do DM e a extração de dados dos sistemas operacionais da empresa. Devem ser definidos os intervalos de tempo desses dois processos. Basicamente define de quanto em quanto tempo serão feitas às atualizações de dados no DM. 2.2 BANCO DE DADOS CACHÉ As informações deste tópico relativos a dados técnicos e descrição do banco de dados e ferramentas Caché que é utilizado pela empresa tem como fonte principal Intersystems (2007) O Banco de dados Caché é considerado o único banco de dados pós-relacional do mercado. Isso quer dizer que temos combinados um banco de dados orientados a objetos, alta performance SQL, e um acesso direto a dados multidimensional poderoso onde todos podem acessar simultaneamente o mesmo dado. O Caché provê o fornecimento de níveis de performance, escalabilidade, programação rápida, e facilidade de uso inatingível pelos bancos de dados de tecnologia relacionais. Esse banco de dados oferece três opções de acesso aos dados que podem inclusive serem utilizados simultaneamente. O primeiro tipo de acesso pode ser feito através de objetos no banco de dados, o segundo utilizando o mapeamento de globais para acesso via linguagem SQL e um rápido acesso direto multidimensional o que traz como resultado uma ampla economia em tempo de desenvolvimento e processamento de informações. O Caché permite um rápido desenvolvimento de aplicações e extraordinária velocidade em processamento de transações, escabalidade maciça, e consultas em tempo-real de dados. São apresentadas algumas características do banco de dados Caché para esclarecer os conceitos relativos ao desenvolvimento, de acordo com Intersystems (2007): a) Data Engine Multidimensional: todos os dados são armazenados em arrays multidimensionais esparsos que eliminam a sobrecarga do processamento relacionado à ligação de dados que comumente ocorre nos bancos de dados relacionais. Isso permite alta performance, escalabilidade maciça e modelagem realista de dados complexos. O armazenamento de dados é mais eficiente o que consome menos espaço em disco e requer menos hardware; b) acesso a dados Objetos: os dados podem ser modelados como objetos. O Caché

37 suporta encapsulamento, heranças múltiplas, polimorfismo, objetos embutidos, referências, coleções e relações. Isso permite um rápido desenvolvimento de aplicações e modelagem intuitivade de dados; c) possui possibilidade de acesso a Dados SQL, acesso relacional à base de dados Caché. Suporta tanto Open Data Base Connectivity (ODBC) como Java Database Connectivity (JDBC) e acesso a dados multidimensionais fornecendo controle direto de estruturas multidimensionais no banco de dados Caché. Como resultado tem-se um aumento de performance das aplicações em geral; d) as linguagens de Script do Caché permitem a utilização de duas linguagens interoperacionais (Caché ObjectScript e Caché Basic) para codificação de métodos e scripts lógicos de negócios. Ambas suportam, simultaneamente, objetos, SQL e acesso a direto a dados multidimensionais, ganhando rapidez no desenvolvimento de aplicações e ênfase na flexibilidade de modelagem dos dados; e) não são requeridas declarações e definições: os arrays multidimensionais do Caché, por construção, não têm tipo, sejam eles relativos a dados ou aos subscritos. Não é requerida nenhuma declaração, definição, ou alocação de armazenamento. Os dados da global passam a existir simplesmente quando é feita a inserção dos dados. Na Figura 10 pode-se observar como esse tipo de estrutura é armazenada e acessada nesse banco de dados. Fonte: Intersystems (2007) Figura 10 Exemplo de global no Caché f) indexação transacional por bit-map: a utilização e atualização destes Bit-Maps

38 é freqüentemente mais rápida que a dos índices tradicionais e eles utilizam sofisticadas técnicas de compressão para reduzirem de forma drástica o armazenamento. O resultado apresenta Bit-Maps ultra-rápidos que freqüentemente podem ser utilizados para pesquisar milhões de registros em uma fração de segundo em um banco de dados processando transações on-line. Aplicações de Business Intelligence e Data Warehousing podem trabalhar com "dados ao vivo". Esses índices podem apresentar tempos de resposta para consultas que procuram grandes volumes de dados superiores aos demais por um fator de 100 vezes ou mais. 2.2.1 Caché ObjectScript O Servidor de Aplicações Caché oferece uma avançada capacidade de programação por objetos, fornece de maneira sofisticada um caching de dados e integra facilmente acesso a uma variedade de tecnologias e que torna possível desenvolver rapidamente aplicações de banco de dados, operá-las com alto desempenho, e dar suporte com facilidade. Mais especificamente, o Servidor de Aplicações Caché fornece a máquina virtual Caché que roda duas linguagens de scripting embutidas, o Caché ObjectScript e Basic. Em quase todos os casos, os programadores podem desenvolver aplicações mais rapidamente, e essas aplicações rodarão significativamente mais rápidas, com maior escalabilidade. Tais códigos não exigem nenhuma modificação no caso de se efetuar uma mudança de hardware ou sistema operacional já que o Caché trata automaticamente todas essas diferenças. A Figura 11 mostra como está elaborada a arquitetura da linguagem Cachê ObjectScript.