UNIVERSIDADE ESTADUAL DE LONDRINA GUSTAVO VIEIRA LOLIS ANÁLISE DE VIABILIDADE DO USO DE BUSINESS INTELLIGENCE EM PEQUENAS EMPRESAS

Transcrição

1 UNIVERSIDADE ESTADUAL DE LONDRINA GUSTAVO VIEIRA LOLIS ANÁLISE DE VIABILIDADE DO USO DE BUSINESS INTELLIGENCE EM PEQUENAS EMPRESAS Londrina - Paraná 2007

2 GUSTAVO VIEIRA LOLIS ANÁLISE DE VIABILIDADE DO USO DE BUSINESS INTELLIGENCE EM PEQUENAS EMPRESAS Monografia apresentada ao curso de Pós- Graduação em Engenharia de Software e Banco de Dados da Universidade Estadual de Londrina, como requisito parcial à obtenção do título de especialista. Orientador: Prof. Dr. Pedro Paulo da Silva Ayrosa. Londrina - Paraná

3 GUSTAVO VIEIRA LOLIS ANÁLISE DE VIABILIDADE DO USO DE BUSINESS INTELLIGENCE EM PEQUENAS EMPRESAS Monografia apresentada ao curso de Pós- Graduação em Engenharia de Software e Banco de Dados da Universidade Estadual de Londrina, como requisito parcial à obtenção do título de especialista. Orientador: Prof. Dr. Pedro Paulo da Silva Ayrosa. COMISSÃO EXAMINADORA Londrina, de de 2007 Londrina - Paraná

4 Resumo Diante da competitiva realidade mundial dos dias atuais, onde a concorrência globalizada exige das empresas agilidade, fluidez e melhoria constante de seus processos de negócios, é preciso garantir acesso rápido ao conhecimento. Empresas hoje armazenam montanhas de dados com eficiência, mas não conseguem extrair informações a partir deles. A solução para este mal está no Business Intelligence, que pode ser definido como o processo de desenvolvimento de estruturas especiais de armazenamento de informações (Data Warehouses e Data Marts), assim como o processo de desenvolvimento de aplicações especiais de tratamento destes dados, como OLAP e Data Mining. Apesar de tais técnicas e regras já serem amplamente utilizadas pelas grandes empresas, seu uso em pequenas empresas está apenas começando. O objetivo deste trabalho é avaliar a viabilidade do uso de Business Intelligence em pequenas empresas, através de um estudo de caso onde um Data Mart de Vendas será construído tendo como base o banco de dados de uma pequena loja varejista. Palavras-chave: Business intelligence, Data warehouse, Banco de dados. 4

5 Abstract In face of the competitive reality of these days, where the globalized competition demands the companies to be more agile, spontaneous and to constantly improve their business processes, it is necessary to guarantee fast access to knowledge. The companies nowadays can efficiently store mountains of data, but cannot extract information from them. The solution to this problem is Business Intelligence, a concept that describes the development process of special information storage structures (Data Warehouses and Data Marts), likewise the development process of special applications to threat these data, e.g. OLAP and Data Mining. Despite these techniques have already been widely used in big companies, it s use in small companies is just beginning. The major objective of this work is to evaluate the viability of using Business Intelligence in small companies, through a case study where a Sales Data Mart will be developed from the database of a small retail store. Keywords: Business intelligence, Data warehouse, Database. 5

6 Sumário 1 Introdução a Inteligência em Negócios O Risco da Ignorância Dado, Informação e Conhecimento Buscando a Inteligência nos Negócios Data Warehouse Data Marts OLAP OLAP x OLTP Data Mining O Estudo de Caso A Estrutura do Trabalho Data Warehouse Fases de um projeto DW/DM Planejamento Levantamento das Necessidades Modelagem Dimensional Projeto Físico do Banco de Dados Projeto ETC Desenvolvimento de Aplicações Validação e Teste Treinamento Implantação Projeto Físico de Data Warehouse Estimativa do Tamanho do DW/DM Criação do Banco de Dados Criação de Espaços de Tabelas (Table Spaces) Criação de Tabelas Definição de Campos Chaves e Restrições Modelagem de Dados para Data Warehouse Os Problemas do Modelo Relacional Transacional Modelagem Dimensional Passos da Modelagem Dimensional Definir a Área de Negócio Definir a Granularidade Definir as Tabelas Dimensão Normalização das Tabelas Dimensão Relacionamentos de Atributos das Tabelas Dimensão Definição dos Atributos das Tabelas Fato Modelagem Dimensional Conceitos Avançados Conformidade de Dimensões Combinações de Dimensões Dimensões Especiais Dinâmica das Dimensões Pequenas Dimensões Para Auxílio de Dimensões Grandes Dimensões Degeneradas/Descaracterizadas

7 3.4.7 Dimensões Lixo (Junk) Campos Chaves de Dimensões e Fatos Agregados Estudo de Caso Motivação Questões a Serem Respondidas Desenvolvimento do Estudo de Caso Planejamento Escopo do Projeto Abordagem do Projeto Integração Arquitetura Tecnológica Levantamento das Necessidades Modelagem Dimensional A modelagem dimensional do DM de Vendas Área de Negócio e Processos-alvo do Data Mart Granularidade Definindo as Tabelas Dimensão Definindo a Tabela Fato de Vendas (TFVendas) O Projeto Físico do DM de Vendas O Projeto de ETC do Data Mart de Vendas Limpeza dos Dados Transformação/Derivação dos Dados Carga dos Dados Avaliação dos Resultados As informações realmente serão disponibilizadas mais rapidamente? Teste 1: Consulta 1 no modelo relacional puro Teste 2: Consulta 1 no modelo dimensional Teste 3: Consulta 2 no modelo relacional puro Teste 4: Consulta 2 no modelo dimensional As informações serão disponibilizadas com mais facilidade e qualidade? Consulta aos dados através do Cube Browser Integração do MSAS com o Microsoft Excel As vantagens superam os custos? Custo de Desenvolvimento Custo de Treinamento Business Intelligence é viável para a LojaX? Conclusão

8 1 Introdução a Inteligência em Negócios 1.1 O Risco da Ignorância O conhecimento é o maior bem da humanidade. Nos dias atuais, é ele quem define a vantagem, quem garante a competitividade. Entre empresas ou países, ter a melhor informação (rápida e de qualidade) é o diferencial entre sucesso e fracasso. O Japão não cresceu devido a seus recursos naturais, tampouco a Microsoft superou a IBM graças a enormes recursos financeiros. Hoje se percebe que a informação e o conhecimento se tornaram os grandes pilares do desenvolvimento de países, sociedades e empresas.(filho, 2004, p. 50) Ignorância é o maior risco para as empresas nos dias atuais. Pior que não ter nenhuma informação é ter informação incompleta, porque ao basear-se nelas para tomar decisões supõe-se um cenário irreal, do qual a verdadeira natureza da situação não é conhecida. 1.2 Dado, Informação e Conhecimento A gestão do conhecimento passa por estas três fases. As empresas possuem dados, que nada mais são que são itens que descrevem aspectos elementares de coisas, eventos, atividades e transações. São simples observações como a empresa possui seis funcionários, e um está de férias. Informação são dados organizados que possuem relevância e propósito, cuja principal origem está nos sistemas de informática implantados nas empresas. Porém, apesar da tecnologia ser usada para nesta conversão, são as pessoas que transformam dados brutos em informações passíveis de estudo.(filho, 2004, p. 64) Conhecimento é a informação processada e inserida em um contexto, contendo um significado que traduza experiência e aprendizados acumulados, aplicáveis em um problema ou atividade. 8

9 1.3 Buscando a Inteligência nos Negócios Business Intelligence (BI) pode ser definido como um conjunto de conceitos e metodologias para melhorar a tomada de decisão nos negócios através do uso de informações de qualidade (corretas e rápidas). Seu objetivo final é disponibilizar informação de diversas fontes aos tomadores de decisão das empresas, auxiliando-os a definirem estratégias que aumentem a competitividade nos negócios da empresa. O universo empresarial hoje padece de um mal clássico. Possui uma montanha de dados, mas enfrenta grande dificuldade na extração de informação a partir dela. O objetivo maior das técnicas de BI está na definição de regras e técnicas para a formatação adequada destes volumes de dados, visando transformá-los em depósitos estruturados de informações, seja qual for sua origem. (BARBIERI, 2001, p. 34) Business Intelligence busca eliminar adivinhações e ignorância nas empresas através da alavancagem e transformação de dados coletados pelas as empresas através de seus sistemas de informação, quase sempre transacionais. Os sistemas de informação transacionais constituem a base dos processos operacionais da maioria das empresas, mas infelizmente eles não foram projetados para facilitar acesso a informações gerenciais. Milhares de tabelas e relacionamentos transacionais, orientadas pelos conceitos da modelagem relacional de dados e pelas rigorosas regras de normalização (seis regras de distribuição semântica de dados por entre tabelas) se mostram eficientes ao definir estruturas capazes de serem implantadas e entendidas pelos gerenciadores de banco de dados. Esta estrutura, entretanto, se mostra inacessível aos mortais, pois esta pulverização de dados não permite aos tomadores de decisão o acesso imediato às informações. 9

10 É necessária uma re-formatação deste volume de dados, objetivando transformálos em depósitos estruturados de informações, independentemente de sua origem. E esta nova estrutura é alcançada através da modelagem dimensional dos dados, armazenada em Data Warehouses ou Data Marts. Business Intelligence é o processo de desenvolvimento destas estruturas especiais de armazenamento de informações, assim como o processo de desenvolvimento de aplicações especiais de tratamento destes dados, como OLAP e Data Mining. Business Intelligence é o meio, com informação estruturada numa ponta e o tomador de decisão na outra. 1.4 Data Warehouse Segundo W.H. Inmon, Data Warehouse é um conjunto de dados, não volátil, orientado a tópicos, integrado, que varia com o passar do tempo e que serve de suporte para o processo de tomada de decisões da gerência. (apud JÚNIOR, 2004, p. 16) De acordo com Cláudia Nolla Leitão, desde o surgimento dos bancos de dados relacionais, os analistas têm sido acostumados a modelar bancos de dados normalizados para sistemas operacionais/transacionais. Resumidamente, normalizar é decompor os dados no seu menor nível, evitando assim a redundância da informação, diminuindo o espaço necessário para armazenamento. Data Warehouse muda o paradigma no que diz respeito à modelagem de dados, já que o objetivo passa a ser o desempenho das consultas, isto é, o acesso e a recuperação dos dados. (apud HIRATOMI, 2004, p. 6) As principais características de um Data Warehouse são: Orientado por temas: a área de negócio da empresa define os temas mais importantes, que ao serem tratados no Data Warehouse, fornecerão as informações necessárias ao processo de suporte à decisão. Uma loja de 1,99 teria temas como cliente, produto, onde cada tema pode envolver várias tabelas, 10

11 como cadastro de endereços dos clientes, compras efetuadas nos últimos dois anos, etc; Integrado: no Data Warehouse não deve haver duas maneiras de se armazenar a mesma informação. Se os dados vierem de diferentes bases, eles devem ser integrados. Por exemplo, ao determinar o sexo da pessoa, podemos ter duas fontes de dados com codificação [M,F] e [H,M], respectivamente. Ao alimentar o Data Warehouse, deve-se gravar somente de uma forma, não importa se seja uma das duas anteriores ou até mesmo uma terceira forma, como [0,1]; Não Volátil: depois que os dados estão no Data Warehouse, eles são apenas lidos, nunca atualizados ou alterados, visto que este é o objetivo do DW. Exceções podem ocorrer, como dados incorretos terem sido carregados. Neste caso é melhor remover a carga errada e carregar os dados novamente do que realizar atualizações na base do DW. (JÚNIOR, 2004, p.17); Variante no tempo: esta característica é conseqüência da anterior. Uma carga no DW representa uma foto dos dados, o estado deles naquele exato momento no banco transacional. Se um dado é atualizado no banco transacional, ele é considerado um dado novo no DW. 1.5 Data Marts Data Mart (DM) é uma abordagem descentralizada de um DW, um subconjunto do mesmo. A diferença entre os dois está centrada no escopo do projeto e nos limites de suas abrangências. Enquanto a construção de um Data Warehouse pressupõe analisar todas as áreas de negócios da empresa, um Data Mart focaliza uma única área. O objetivo do Data Mart pode ser melhorar a segurança dos dados, já que se pode controlar melhor o acesso a diversos DMs do que a um DW centralizado. Ou melhorar o desempenho, já que o DM abrange somente uma área do negócio, e com isso têm-se menos dados e menos pessoas acessando-os. Mas os principais objetivos/benefícios alcançados por um DM em relação ao DW são: 11

12 Custo de construção menor; Tempo de construção menor; Entretanto existem problemas: Redundância de dados pode surgir entre diferentes Data Marts; Incompatibilidade entre DMs: se a mesma dimensão for definida com hierarquias distintas entre DMs, o que acaba gerando fatos incompatíveis também; Ilhas de informações: se o usuário não tem acesso a todos os DMs, pode estar analisando problemas da empresa sem conhecer todo o cenário; A solução para estes problemas está em definir a compatibilidade de dimensões antes de se construir os Data Marts (hierarquia, granularidade), e conseqüentemente, em definir padrões de dados fatos. Com base neste Framework é que os DMs devem ser projetados e construídos. 1.6 OLAP O processamento analítico em tempo real, mais conhecido como OLAP, referese a um conjunto de tecnologias voltadas para acesso e análise ad hoc de dados. Sendo assim, o objetivo final de uma ferramenta OLAP é transformar dados em informações capazes de dar suporte a decisões gerenciais de forma amigável e flexível ao usuário e em tempo hábil. OLAP é uma ferramenta de apoio à decisão que faz inferências em um banco de dados histórico, um DW por exemplo, e por isso é também considerada uma ferramenta de Business Intelligence. (JÚNIOR, 2004, P.26) Análise ad hoc significa fornecer total capacidade de análise de informações. Se um relatório que o usuário deseja ainda não existe, ele deve ser capaz de criá-lo com a ferramenta OLAP de forma transparente, intuitiva e flexível. O usuário deverá ser capaz de manipular os dados livremente, sem necessitar de qualquer tipo de ajuda. 12

13 A característica mais importante de uma ferramenta OLAP é permitir uma visão conceitual multidimensional dos dados de uma empresa. Os dados são modelados numa estrutura conhecida por cubo, onde cada dimensão representa temas importantes da empresa (JÚNIOR, 2004, p. 29). Figura 1.1 Cubo OLAP de 4 dimensões (JÚNIOR, 2004, p. 29). A visão multidimensional fornece a capacidade de modificar a posição de uma informação, girando o cubo conforme a necessidade, trocando linhas por colunas na tabela. Esta característica, chamada de slice and dice, permite modificar a ordem das dimensões, de maneira a facilitar a compreensão dos usuários e prover acesso flexível à informação. (OLAP COUNCIL, 1997) Gerentes devem ser capacitados a analisar dados através de qualquer dimensão, em qualquer nível de agregação, de maneira intuitiva, utilizando as funcionalidades da ferramenta. Softwares OLAP deveriam suportar estas visões de dados de um modo transparente, isolando usuários das informações provenientes de complexas sintaxes de consulta. Além disso, gerentes não precisariam entender complexos planos de tabelas, elaborar junções a tabelas de sumário. 13

14 De acordo com o Olap Council, embora sejam encontradas aplicações OLAP em diversas áreas, todas elas requerem as seguintes características (OLAP COUNCIL, 1997): Visão multidimensional de dados; Capacidade intensiva de cálculo; Time intelligence: as séries temporais de dados são definidas pela perspectiva de negócios. Ralph Kimball listou uma série de características que toda ferramenta OLAP deveria apresentar, sendo as mais importantes para este trabalho citadas aqui (apud HIRATOMI, 2004, p. 26): Rotacionamento/Visualização: cabeçalhos de linhas e colunas devem poder ser misturados em combinações arbitrárias fazendo com que os dados do relatório sejam reorganizados de uma forma que tenha mais sentido para o usuário. Além disso, a ferramenta deve ter disponível vários modos de apresentação tais como planilhas, gráficos, matrizes, etc; Drill-down, Drill-across: Drill-down e drill-across são recursos fundamentais para uma análise efetiva por parte do usuário. Fazer um drill-down significa obter mais informações sobre os dados que estão sendo apresentados, seja descendo numa hierarquia ou adicionando dimensões que complementem a análise dos dados. Drill-across é fazer com que duas ou mais tabelas de fato, que compartilham dimensões, sejam combinadas num único relatório; Browse/Pesquisa: a ferramenta deve permitir ao usuário navegar de forma intuitiva pelos dados e deve fazê-lo compreender e explorar as dimensões disponíveis; Visibilidade: tanto as tabelas de fatos e dimensões, quanto às restrições relacionadas às dimensões devem ser visualizadas de forma simples através da ferramenta OLAP. Além disso, a navegação através das dimensões deve ser intuitiva e lógica para o usuário; 14

15 Sendo assim, o objetivo final de uma ferramenta OLAP é transformar dados em informações capazes de dar suporte a decisões gerenciais de forma amigável e flexível ao usuário, utilizando-se de cálculos complexos (percentagens, alocações) em tempo hábil, pois análises de negócios e tomadas de decisões em empresas e organizações são sempre feitas em cima do fator tempo. 1.7 OLAP x OLTP Aplicações OLTP (On-Line Transactional Processing) são aplicações tradicionais, estruturadas e repetitivas, que manipulam transações curtas, atômicas e isoladas. Essas aplicações processam as tarefas do dia-a-dia de uma organização e requerem dados atualizados e detalhados. Bancos desenvolvidos para OLTP não são apropriados para Data Warehouses, pois não guardam dados históricos, não atendem satisfatoriamente a consultas e a recuperação rápida dos dados é praticamente impossível. (JÚNIOR, 2004, p.28) Em contraste, as aplicações OLAP (On-Line Analytical Processing) são desenvolvidas para apoiar os tomadores de decisão da organização, provendo acesso a dados históricos resumidos e consolidados (normalmente integrados em um DW) ao invés de registros individualmente detalhados. Seu processamento está ligado à resposta de consultas ad hoc complexas, que podem acessar milhões de registros e executar diversas varreduras, junções e agregações. O tempo de resposta dessas consultas é mais importante que o fluxo de transações processadas. As principais diferenças entre processamentos OLAP e OLTP podem ser vistas na tabela abaixo: 15

16 OLAP OLTP Relevância para dados históricos Mantém usualmente a situação corrente. Necessidade de ver o dado sob diferentes Voltado para velocidade e automação de perspectivas: aplicações dinâmicas funções repetitivas Atualizações quase inexistentes, apenas novas Atualizações em grande número inserções Baseado em dados históricos, consolidados e Baseado em transações freqüentemente totalizados Operações de agregação e cruzamentos Alto nível de detalhe Tabela 1.1 Diferenças entre OLAP e OLTP. (JÚNIOR, 2004, p. 28) 1.8 Data Mining Data Mining, ou Mineração de Dados, ou ainda Garimpagem de Dados, é a utilização de técnicas de estatística e de inteligência artificial bem estabelecidas para detectar padrões de comportamento nos depósitos de dados (Data Warehouse a Data Marts), ou seja, informações valiosas que não são óbvias para a empresa e o tomador de decisão. É uma forma de se capitalizar em cima destas informações, tentando descobrir padrões de comportamentos de clientes, ou identificando, por exemplo, estilos de ações fraudulentas em cartões de crédito. (BARBIERI, 2001, p. 178) Ao contrário das tradicionais consultas a banco de dados com SQL, ou através de ferramentas de apoio à decisão como OLAP, nas quais deve ser explicitado tudo o que se deseja obter, um algoritmo de Data Mining é capaz de descobrir informações escondidas dos usuários, informações que ele nunca pensaria em perguntar ao banco de dados. (JÚNIOR, 2004, p. 159) A mineração de dados fornece respostas interessantes e valiosas a perguntas que o usuário não fez e provavelmente nunca faria, pelo fato de não serem intuitivas. Como exemplo cita-se o clássico exemplo das fraldas e da cerveja, onde um 16

17 supermercado descobriu que nas sextas-feiras à noite, clientes que compravam fraldas também compravam cerveja, uma associação nada óbvia tampouco intuitiva. Carlos Barbieri afirma que as ferramentas de Mining estão muito mais relacionadas com tratamento especial da informação do que com estruturações de dados. Ele define três espaços de conhecimento, que podem ser vistos na figura abaixo: Figura 1.2 Visão geral dos diversos espaços de conhecimento. (BARBIERI, 2001, p. 180) Enfim, técnicas de mineração de dados buscam algo mais que a interpretação dos dados existentes, elas visam fundamentalmente realizar inferências, tentando como que adivinhar possíveis fatos e correlações não explicitadas nas montanhas de dados de um DW/DM. (BARBIERI, 2001, p. 178) 1.9 O Estudo de Caso O objetivo maior deste trabalho será um estudo de caso sobre a implantação de Business Intelligence em uma pequena empresa. Uma loja varejista de pequeno/médio porte terá seu banco de dados analisado, desde a estrutura até os dados, e dentro 17

18 deste ambiente específico (contexto econômico, de hardware e também software), um Data Mart será projetado do início, e ao final a seguinte questão será analisada: Business Intelligence é viável para pequenas empresas? 1.10 A Estrutura do Trabalho Este trabalho segue a seguinte organização: O capítulo 1 trata dos conceitos fundamentais sobre Business Intelligence, demonstrando a sua importância no atual momento; O capítulo 2 trata do planejamento (quais são as fases de um projeto de Data Warehouse) e projeto físico de um DW; O capítulo 3 aborda a modelagem de dados para Data Warehouse, apresentando conceitos básicos e avançados da modelagem dimensional; O capítulo 4 desenvolve o estudo de caso, apresentando seu escopo e contexto, o banco de dados da empresa modelo, o planejamento do Data Mart, a sua modelagem dimensional, o projeto físico e de ETC (extração, transformação e carga); O capítulo 5 avalia os resultados, propondo testes que avaliem as vantagens e desvantagens, buscando assim responder as questões propostas, de acordo com o contexto do estudo de caso; O capítulo 6 apresenta a conclusão deste trabalho. 18

19 2 Data Warehouse 2.1 Fases de um projeto DW/DM O processo de desenvolvimento de um projeto de DW/DM deverá seguir uma metodologia básica de desenvolvimento de sistemas, porém existem aspectos que o diferenciam de um projeto convencional de sistemas, aspectos que devem ser observados com cuidados cirúrgicos. (BARBIERI, 2001, p. 68) A seguir são brevemente descritos os principais passos para o projeto de DW/DM, de acordo com Barbieri. 2.2 Planejamento O planejamento de um projeto de DW divide-se nos seguintes tópicos: Definir escopo do projeto: o objetivo do DW deve estar claramente definido dentro da organização, para que o desenvolvimento não se perca em diversas bifurcações que certamente surgirão durante seu desenvolvimento. Sabendo-se o resultado esperado, pode-se verificar se o objetivo está sendo alcançado. O DW deve ter foco no negócio da empresa, onde o escopo pode ser: - Melhorar a competitividade da empresa; - Descobrir novos mercados; - Etc... Definir a abordagem do projeto: - Monolítica: maior integração em nível de projeto, do qual sairão os DM a posteriori; - Evolutiva: os DM evolutivos integrarão o DW na medida de suas implementações (disponibilidade mais imediata dos produtos requeridos); 19

20 Planejar a integração: o primeiro projeto não abordará todas as áreas/assuntos, e deve-se estabelecer uma visão que permita amarrá-las na medida de suas implementações. - Definir as principais dimensões; - Definir métricas compatíveis; - Ver semântica da dimensão para cada área de negócio (contexto); - Ver atributos e hierarquizações; Definir arquitetura tecnológica: os componentes básicos devem ser definidos antes do início do projeto, pois fatores como performance e disponibilidade, também previstos no planejamento do projeto, dependem disso. A seguir segue uma lista dos principais componentes a serem definidos: - Definir SGBD; - Definir Ferramenta OLAP/Mining; - Definir Ferramentas ETC (Extração Transformação Carga); - Definir Catálogo para Metadados; Levantamento das Necessidades Nesta etapa deverão ser identificados dois modelos: Modelo Dimensional: blocos conceituais de dados necessários ao alcance dos objetivos do sistema de suporte a decisão (BARBIERI, 2001, p. 73); Modelo Fonte dos Dados: blocos conceituais de dados existentes, com suas descrições e formas atuais de armazenamento e de uso nos sistemas, que habitam os variados ambientes operacionais ou fontes externas de dados (BARBIERI, 2001, p. 73). Este é o modelo com a fonte das informações que alimentarão o DW/DM Modelagem Dimensional É um dos fatores críticos de sucesso num projeto de DW/DM. Os detalhes da modelagem dimensional serão discutidos nos próximos capítulos. 20

21 2.2.3 Projeto Físico do Banco de Dados Definir a estrutura lógica do modelo dimensional: Tabelas Fatos; Tabelas Dimensões; Escolher o depósito das informações: SGBD Relacional; SGBD Dimensional; Esta fase requer a participação do administrador de banco de dados, que tenha pleno conhecimento sobre o funcionamento do SGBD escolhido. Seu conhecimento ajudará a criar as tabelas de forma a obter o máximo desempenho do SGBD Projeto ETC Nesta etapa deve-se definir os processos requeridos de transformação do modelo Fonte para o modelo Dimensional: Filtro de dados: evitar que dados indesejáveis sejam carregados no modelo dimensional, como valores inválidos, chaves repetidas, etc. Deve-se garantir a integridade referencial. Ex: carregar somente ordens de compra com valor maior que R$1000,00; Integração de dados: correlacionar informações existentes em fontes distintas, como banco de dados e planilhas locais; Condensação de dados: reduzir volumes de dados visando obter informações resumidas. Ex: vendas por região, ao invés de vendas por loja; Conversão de dados: transformar dados em unidades e formatos diferentes, que sejam compatíveis com o DW; Derivação de dados: definir os meios e fórmulas para produzir dados virtuais, a partir dos existentes; 21

22 2.2.5 Desenvolvimento de Aplicações O acesso aos dados deve ser facilitado ao máximo no desenvolvimento do aplicativo: Priorizar interface web: evitar problemas de instalação de aplicativo, e ao mesmo tempo garantir a disponibilidade com apenas um navegador e acesso a intranet/internet; Diversas formas de visualização: exportar dados para ferramentas que o usuário mais utiliza, como planilhas e editores de texto; Validação e Teste Fazer simulações de volume e processamento para um grupo restrito de usuários, e após análise de feed-backs, liberar para o ambiente produtivo Treinamento O grupo objeto do treinamento deverá ser formado pelos usuários voltados para atividades de negócios, além dos gerentes das áreas envolvidas (BARBIERI, 2001, p. 76) Implantação Acompanhar o uso das aplicações disponibilizadas, registrando críticas e sugestões de melhoria para as próximas versões do sistema. 2.3 Projeto Físico de Data Warehouse 22

23 Terminada a fase conceitual de definição das estruturas dimensionais, deve-se definir as estruturas lógicas (tabelas) que suportarão o projeto de DW. Aqui serão analisados os aspectos de performance e disponibilidade inerentes a implementação do DW em um SGBD relacional, já que o estudo de caso utilizará um banco deste tipo Estimativa do Tamanho do DW/DM É importante calcular o espaço necessário para suportar o DW/DM, pois sendo um banco de dados histórico, seu tamanho tende a ser muito maior que o banco do sistema operacional da empresa (a fonte dos dados), e o hardware deve estar preparado para suportar este tamanho. Já foi visto que a tabela Fato é muito maior que todas as tabelas dimensão juntas, portanto é fundamental calcular o espaço necessário para armazená-la. Os principais pontos a serem considerados são: Entender sua granularidade: qual o nível de sumarização da tabela, ela registrará as ocorrências por dia ou por mês? Por unidade federal ou região? Freqüência média de suas ocorrências: quantas transações ocorrem por cliente em um único dia? Quantas notas de venda são emitidas por loja/dia? Definir o tamanho de cada linha da tabela: soma-se o espaço ocupado pelas chaves das dimensões às métricas, como quantidade-vendida, valor-vendido, etc; Perspectiva de armazenamento: por quantos anos serão armazenados os dados? Ex: o DW armazenará somente os dados dos últimos 5 anos; Se uma linha da tabela fato ocupar 55 bytes, e a freqüência de registros for de /ano, estima-se que a tabela Fato ocupará ao final de 5 anos 1,8 GB (55 bytes x registros x 5 anos). É também importante prever o espaço das tabelas dimensão e dos índices que serão criados nelas para agilizar a consulta ao DW. Estima-se um percentual de 20 a 23

24 25% para estes componentes em relação à tabela Fato (BARBIERI, 2001, p. 150). No exemplo acima, estes componentes ocupariam aproximadamente 400 MB. Por último, mas não menos importante, deve-se considerar as particularidades do SGBD, por exemplo: quantos bytes ocupam o tipo de dados inteiro para o SGBD Oracle. Também se deve reservar espaço para área de trabalho (execução de comandos SQL, criação de índices) e considerar espaço necessário para criação de agregados Criação do Banco de Dados Deve-se avaliar o espaço líquido que os dados do DW ocuparão. É importante, por exemplo, analisar o valor padrão de bloco usado pelo SGBD: 1 bloco: estrutura recuperada numa única operação de I/O; Quanto maior o tamanho do bloco, mais dados recupera-se de uma só vez; Avalie o espaço líquido do bloco: verificar espaço reservado para estruturas internas do SGBD; Criação de Espaços de Tabelas (Table Spaces) Espaço de Tabela pode ser definido como o espaço lógico onde residem as tabelas e os índices do banco. Este espaço pode ser mapeado para vários arquivos (BARBIERI, 2001, p. 152). Recomenda-se: Armazenar dados e índices espaços físicos separados; Cuidado com valores de espaços livres deixados como padrão pelo SGBD: ao contrário de sistemas OLTP, o DW/DM é mais estático, com estratégias de atualização diferentes daqueles sistemas; Distribuir os dados em unidades independentes de armazenamento: considere o uso de algum tipo de RAID (Conjunto Redundante de Discos Independentes: 24

25 uma categoria de drives de disco que emprega dois ou mais drives em combinação para tolerância a falhas e perfomance), buscando aumentar a disponibilidade (redundância de dados) e/ou aumentar a performance nas leituras; Adotar alguma estratégia de particionamento: uma tabela com muitas colunas pode ser dividida em duas tabelas ligadas por chave comum (é chamado particionamento horizontal, e não é muito comum). Outra forma é o particionamento vertical, onde os dados de uma mesma tabela são divididos em segmentos diferentes, que podem ser manipulados de forma independente (criação de índices e reorganizações em apenas uma partição, por exemplo). O campo mais utilizado para chave de particionamento em DW é a campo data (dia, mês, ano). Os registros de venda por mês de uma tabela Fato poderiam ser divididos em 1 partição/mês, por exemplo Criação de Tabelas A criação de tabelas obedece às particularidades do SGBD escolhido. Deve-se observar: Número máximo de colunas numa tabela; Tamanho máximo (bytes) por linha numa tabela; Evitar a definição padrão de valores nulos para a tabela Fato (DEFAULT NULL); Utilize chaves artificiais: eficiência na indexação e neutralidade semântica; Definição de Campos Chaves e Restrições A principal definição de restrição é para chave primária e chaves estrangeiras. A restrição de chave primária evitará duplicações e valores nulos, além de criar um índice automático, e deve ser definida em cada tabela Dimensão. 25

26 A restrição de chave estrangeira deve ser feita nos campos chave da tabela Fato, que nada mais são do que as chaves primárias de cada dimensão com a qual a tabela se relaciona. Esta restrição garantirá a integridade referencial entre a tabela Fato e as Dimensões. 26

27 3 Modelagem de Dados para Data Warehouse 3.1 Os Problemas do Modelo Relacional Transacional A modelagem transacional busca a normalização de suas tabelas, de forma que não haja redundância de dados, atingindo assim seu principal objetivo: servir de alicerce para sistemas cuja base de dados está em constante atualização, garantindo eficiência durante tais operações e integridade aos dados do sistema. Porém, a não redundância de dados implica em um modelo: Com muitas tabelas; Muitas conexões entre elas; Constante atualização de seus dados; Estas características do modelo transacional apresentam algumas conseqüências que no contexto de Data Warehouse se tornam enormes problemas: Modelo de difícil compreensão; Baixa performance ao se fazer consultas complexas, devido a muitas conexões; Perda dos dados históricos; Como já visto, o objetivo do Data Warehouse é manter um histórico de dados, e consultá-lo freqüentemente, de forma a descobrir tantas informações quanto possível, e assim extrair conhecimento. A solução para a modelagem relacional transacional atender tais propósitos é: desnormalizar. 3.2 Modelagem Dimensional A modelagem dimensional nada mais é do que um modelo relacional não normalizado, onde a rigidez exigida pelas formas normais cede lugar à necessidade da criação de estruturas de dados mais ágeis, que possam comportar volumes de informação estratosféricos. (FILHO, 2004, p. 175) 27

28 Esta desnormalização objetiva melhorar a compreensão do modelo, aumentar sua performance em consultas e manter dados históricos. Obtêm-se menos tabelas, menos conexões entre elas, e desta forma também se alcança redundância de dados. A modelagem dimensional busca uma estrutura voltada mais para os pontos de entrada específicos, de onde se fazem os filtros (dimensões) e menos para os dados granulares (os fatos). Desta forma têm-se dois tipos básicos de entidades no modelo dimensional: fatos e dimensões. Dimensões são os pontos de entrada do modelo. Cada dimensão faz uma junção com uma tabela central (fato), que por sua vez contém os dados granulares que se deseja pesquisar. Assim tem-se um esquema estelar, com uma (às vezes mais) tabela dominante (fato), que está normalizada e que se relaciona com todas as dimensões, que são opcionalmente normalizadas. Um exemplo pode ser visto na figura abaixo: Figura 3.1 Exemplo de um modelo E/R transacional (BARBIERI, 2001, p.36). 28

29 Figura 3.2 Um modelo dimensional equivalente (BARBIERI, 2001, p.37). Carlos Barbieri apresenta uma definição mais técnica e completa acerca das tabelas Fato e Dimensão: As tabelas Fato servem para armazenar medidas numéricas associadas a eventos de negócio. Uma tabela fato contém vários fatos, correspondentes a cada uma de suas linhas. Cada fato pode armazenar uma ou mais medidas numéricas, que constituem os valores objetos da análise dimensional. Possuem como chave-primária, normalmente um campo multi-key, formado pelas chavesprimárias das dimensões que com ela se relacionam. Normalmente armazenam muito mais linhas do que as tabelas Dimensão, e merecem cuidado especial em função do seu alto volume. Contém dados normalmente aditivos (manipulados por soma, média, etc.) e relativamente estáticos. As tabelas Dimensão representam entidades de negócios e constituem as estruturas de entrada que servem para armazenar informações como tempo, geografia, produto, cliente, etc. As tabelas Dimensão têm uma relação 1:N com a tabela Fato, e possuem um número significativamente menor de linhas do que as tabelas Fato. Possuem múltiplas colunas de informação, algumas das quais representam a sua hierarquia. Apresentam sempre uma chave primária, que lhes confere unicidade, chave essa que participa da tabela Fato, como parte da sua chave múltipla. Devem ser entendidas como as tabelas que realizam os filtros de valores aplicados na manipulação dos fatos e por onde as consultas entram no ambiente de DW/DM. (BARBIERI, 2001, p. 81) A modelagem dimensional pode ser relacionada a um cubo, onde as medidas numéricas do negócio, como quantidade de vendas, valor de faturamento, etc, encontram-se dentro do cubo. Estas informações podem ser vistas através das diversas 29

30 faces do cubo, como período, produto, cliente... As faces do cubo são as dimensões, enquanto as medidas numéricas representam os fatos. (FILHO, 2004, p.176) Figura 3.3 O modelo dimensional visto como um cubo. (FILHO, 2004, p.176) 3.3 Passos da Modelagem Dimensional Definir a Área de Negócio Como qualquer outro projeto de banco de dados de um ambiente transacional, o projeto de um DW inicia-se definindo seu escopo, a área de negócios que será seu foco, como, por exemplo, clientes, vendas, finanças, etc. Uma vez determinada sua área de abrangência, definem-se também quais serão os processos-alvo do projeto: estatísticas de venda, entrega, pagamento, etc Definir a Granularidade A granularidade diz respeito ao nível de detalhamento de informação que se deseja alcançar. Quanto maior forem os níveis de hierarquia nas dimensões, maior será a granularidade. Pode-se definir um sistema que produza estatísticas de venda por 30

31 produto e por dia, ou pode-se aumentar a granularidade da dimensão TEMPO e obter estatísticas de venda por produto e por dia/hora. Os principais fatores para escolha da granularidade são o volume de dados produzido e o custo de processamento deste volume. Se por exemplo, houvesse um DW com estatísticas de vendas diárias de 5000 produtos armazenando dados por 3 anos, ele teria um total de (5000 * (3 * 365 dias)) = 5,5 milhões de registros. Se a dimensão TEMPO fosse mais detalhada, para saber a hora em que o produto foi vendido, o total de registros do DW seria (5000 * (3 * (365 dias * 8 horas))) = 43,8 milhões de registros Definir as Tabelas Dimensão O passo anterior já indica quase que totalmente o caminho para construção das tabelas dimensão. Deve-se definir as dimensões e sua granularidade de forma que tragam a qualidade e o nível de detalhe esperado ao se pesquisar as tabelas fatos. Se, por exemplo, uma empresa não tem filial, a dimensão LOJA torna-se estranha e dispensável. O próximo passo é definir a hierarquia restante das dimensões. A dimensão TEMPO, por exemplo, poderia ter a hierarquia Dia Semana Mês Trimestre Ano, enquanto que PRODUTO poderia ter Produto Categoria. Finalmente definem-se os atributos restantes, que agreguem valor ao modelo, como o atributo Estação-do-ano, ou simplesmente forneçam uma informação que poderia ser inferida de outro campo, mas que informada diretamente aumenta a performance do modelo, como uma tag para informar se aquele dia era véspera de feriado Normalização das Tabelas Dimensão 31

32 Como dito anteriormente, na modelagem dimensional a normalização das dimensões é opcional. Portanto existem duas correntes de pensamento em relação a este aspecto: Esquema Estrela ou Star Schema: recomenda a não normalização das tabelas dimensão; Esquema Flocos de Neve ou Snowflake Schema: recomenda a normalização das tabelas dimensão - forma várias camadas; Observe um DW construído segundo o esquema estrela, e o mesmo modelo seguindo o esquema Flocos de Neve: Figura 3.4: Modelagem dimensional seguindo o esquema estrela. 32

33 Figura 3.5: Modelagem dimensional seguindo o esquema flocos de neve. O esquema estrela apresenta como desvantagem a redundância nas tabelas dimensão (vários produtos pertencem a mesma categoria) enquanto que o esquema flocos de neve tem contra si o aumento de tabelas e conexões entre elas. A superioridade do esquema estrela é inquestionável, pelos aspectos de ganhos de performance, quando comparado com o esquema flocos de neve. (BARBIERI, 2001, p. 86) A redundância de informações gera um aumento de dados desprezível, visto que as tabelas dimensão têm baixo volume de dados quando comparadas às tabelas fato, enquanto que as várias junções extras utilizadas pelo esquema flocos de neve usa para recompor a informação provocam uma redução gigantesca na velocidade de recuperação da mesma Relacionamentos de Atributos das Tabelas Dimensão As tabelas dimensão normalmente não têm relacionamento entre si, são entidades independentes e distintas, como cliente, tempo, geografia. Mas dentro de uma dimensão pode haver relacionamentos entres seus atributos, de duas maneiras: 33

34 Atributos dentro da mesma dimensão possuem um relacionamento hierárquico (1:N). Exemplo: Região (1:N) Cidade (1:N) Bairro (1:N) Cliente Atributos dentro da mesma dimensão possuem relacionamentos M:N entre si. Exemplo: considere um DW para controle de vendas de livros de uma editora, onde a dimensão LIVRO tem um relacionamento M:N com autor, ou seja, um livro pode ter vários autores. Estas entidades produziriam uma tabela de relacionamento em que se informaria a porcentagem de direito de cada autor, e a dimensão LIVRO seria relacionada com a Fato do modelo (BARBIERI, 2001, p. 88) Definição dos Atributos das Tabelas Fato Com a definição das dimensões e suas granularidades, a tabela Fato já foi quase definida. Resta definir as métricas que abastecerão os processos de gerência. Existem três tipos de métricas: Aditivas: Quando os valores podem ser somados em todas as dimensões. Exemplo: suponha um DW de vendas com as dimensões LOJA, TEMPO e PRODUTO. Métricas como valor-vendido ou valor-custo sempre tem um significado interessante, não importa por qual dimensão se analisem os dados; Semi-Aditivas: Quando a sumarização do valor não tem sentido em todas as dimensões. Analisando a métrica quantidade-vendida no contexto do exemplo anterior, percebe-se que o valor seria de pouca importância ao ser sumarizado através da dimensão LOJA (somatória das quantidades vendidas de todos os produtos da loja); Não-Aditivas: quando um valor não puder ser sumarizado em nenhuma dimensão. Este é o caso de porcentagem-de-lucro ((valor-vendido - custo)/ valor-vendido) ou qualquer outro tipo de relação/razão entre métricas. (BARBIERI, 2001, p. 88); Ao escolher os atributos da tabela Fato deve-se avaliar a relação custo/benefício. A porcentagem de lucro é um atributo que pode ser calculado em tempo de 34

35 processamento, o que deixaria a consulta mais lenta, ou pode ser previamente calculado e armazenado na tabela Fato, o que aumentaria seu tamanho, e lembre-se que esta é a entidade que mais consome este recurso. 3.4 Modelagem Dimensional Conceitos Avançados Os conceitos discutidos a seguir são refinamentos da abordagem dimensional. Casos especiais e problemas freqüentemente encontrados durante a construção de um modelo dimensional têm sua solução proposta aqui Conformidade de Dimensões A conformidade de dimensões objetiva manter sentido semântico entre as dimensões, para que diferentes Data Marts possam ser cruzados, produzindo assim informações compatíveis. As dimensões devem ser documentadas em um repositório/catálogo, que funcionará como fonte única de informação e de fácil acesso aos interessados, permitindo comunicação eficiente e rastreamento de eventuais mudanças. A regra para se alcançar a conformidade é, sempre que possível, definir dimensões no maior grau de granularidade. (BARBIERI, 2001, p. 93) Alcançando-se a conformidade a mesma dimensão poderá ser usada em diferentes DMs. Um exemplo de não conformidade pode ser visto na dimensão definida abaixo: Dimensão TEMPO (ANO TRIMESTRE MÊS SEMANA - DIA) Semana não é um nível hierárquico válido porque uma semana pode começar em maio e acabar em junho. 35

36 3.4.2 Combinações de Dimensões Se duas dimensões tiverem forte coesão, ou seja, acontecerem (quase) sempre juntas, elas poderiam ser combinadas em uma única dimensão. (BARBIERI, 2001, p. 95) Por exemplo, se somente certos PRODUTOS são vendidos em certas LOJAS, isso poderia sugerir uma combinação de dimensões, desde que o número de instâncias do produto cartesiano (número de produtos vezes número de lojas) não seja muito alto Dimensões Especiais Quanto mais rica for a definição de dimensões (em relação aos seus atributos), maior a possibilidade de análises complexas. Deve-se sempre procurar enriquecer as dimensões com atributos interessantes. (BARBIERI, 2001, p. 96) Dimensões consideradas clássicas, como TEMPO, já possuem vários exemplos de atributos que a enriquecem: TAG-FINAL-SEMANA (indica se este dia é sábado ou domingo); TAG-FERIADO (indica se é feriado); Dinâmica das Dimensões O que fazer nos processos de atualizações de informações? Existem três alternativas de como o Data Warehouse manterá o históricos dos dados que foram atualizados no sistema transacional: Atualizar a informação no DW: é a solução mais simples, porém não preserva a variação histórica do dado; Criar uma nova versão da informação no DW: - Cria-se uma nova ocorrência daquela informação na dimensão, mantendo assim todo o histórico de versões; 36

37 - Controle das diversas versões: deve-se gravar a data de início de validade da versão, assim como a data de fim de validade. Um marcador informando qual a versão atual também é recomendado; Uma solução intermediária é manter somente a versão anterior da informação. Quando ocorre uma atualização, uma nova versão é inclusa, a versão atual torna-se a versão anterior e a versão anterior é excluída. Este método traz pouca consistência histórica dos dados; No caso de dimensões com alto volume e alta volatilidade (dados em constante alteração no ambiente transacional) recomenda-se a separação da informação em duas dimensões: uma contendo os dados estáticos (que quase não variam) e outra contendo os dados voláteis daquela informação. Haveria muitas versões na dimensão volátil (que varia muito) e poucas versões da dimensão estática (que pode variar de vez em quando), e com isso uma economia de espaço em banco. Porém os registros da tabela fato teriam de fazer referência às duas dimensões, e este campo a mais na maior tabela do DW pode gerar um overhead maior do que a economia proporcionada pela separação da informação em duas dimensões, exigindo uma análise cuidadosa. Exemplo: a dimensão PRODUTO possui atributos estáticos como descrição, categoria, código, etc. e atributos voláteis como preço de custo e preço de venda, que variam quase toda semana. Esta informação seria armazenada no DW da seguinte forma: 37

38 Figura 3.6 Estratégia para implementação de dimensões grandes e voláteis Pequenas Dimensões Para Auxílio de Dimensões Grandes Em (veja figura 3.6) uma abordagem deste problema foi mostrada, ligandose duas dimensões (estática e volátil) entre si. Porém se a parte volátil for repetitiva e as combinações possíveis de valores não forem muitas, como em: Figura 3.7 Exemplo de modelo com pequena dimensão (JÚNIOR, 2004, p. 55) Não é preciso ligar CLIENTE à INSTRUÇÃO, bastando somente ao fato VENDAS saber que naquele momento determinado cliente possuía determinado nível 38

39 de instrução. Com esta independência um registro em instrução pode ser reutilizado por n clientes Dimensões Degeneradas/Descaracterizadas Quando uma chave de dimensão, dentro da tabela fato do DM/DW, não possuir uma tabela de dimensão correspondente, tem-se uma dimensão degenerada. Este tipo de dimensão está normalmente relacionado com objetos do tipo evento, como notas fiscais ou uma ordem de serviço. Estas entidades são compostas de itens (itens da nota fiscal). Se a tabela Fato estiver no nível de granularidade de itens, o número da nota fiscal estará na tabela Fato para fazer o papel de alinhavador dos itens daquele documento. Porém, como a dimensão é ITEM e não existe no DW uma dimensão NOTA FISCAL, esta é considerada uma dimensão degenerada. (BARBIERI, 2001, p. 102) Figura 3.8: Dimensão degenerada (BARBIERI, 2001, p. 102) Dimensões Lixo (Junk) Dimensões lixo ou descartáveis são aquelas que não estão relacionadas diretamente com a tabela FATO, que não refletem regras macro do negócio, como PRODUTO ou CLIENTE. 39

40 Estas informações estão lá como uma dimensão porque é importante mantê-las desta forma, como por exemplo: Para ajudar a fazer filtros e melhorar a pesquisa no DW; Para ajudar a economizar espaço na tabela FATO; Campos de pequena cardinalidade, como Sexo (M, F) ou tag de contribuinte (Sim ou Não) podem ser reunidos numa única dimensão, e serem utilizados pela tabela FATO para filtros e pesquisas: (BARBIERI, 2001, p. 102) Figura 3.9: Exemplo de dimensão Junk para controle de tags. (BARBIERI, 2001, p. 103) Barbieri também apresenta um exemplo de dimensão Junk para economia de espaço na tabela FATO: 40

41 Figura 3.10: Exemplo de dimensão Junk para controle de redundância de textos. (BARBIERI, 2001, p. 104) Campos Chaves de Dimensões e Fatos A utilização de chaves artificiais (um valor numérico seqüencial) ao invés de chaves semânticas (valores naturais, com significado) nas dimensões (e conseqüentemente, nas tabelas Fato) é considerada uma regra básica em projetos DW/DM. (BARBIERI, 2001, p. 74) Diversas razões explicam esta escolha: Unicidade: a chave artificial garante que certa entidade terá valores únicos para identificá-la; Um campo chave por dimensão: chaves semânticas podem ter de usar dois ou mais campos para gerar uma identificação única da entidade, enquanto a chave artificial resolve isto com apenas um campo; 41

42 Aumento de desempenho: Com um valor inteiro ocupando apenas 4 bytes, uma chave artificial pode registrar até 2 bilhões (2 32 ) de ocorrências, mais do que suficiente para qualquer Dimensão, enquanto que uma chave semântica como NomeEcpf ocuparia muito mais que 4 bytes. Com uma chave menor, a definição de índices é mais vantajosa, com um número maior de chaves por página de índice; Maior flexibilidade do sistema: qualquer alteração nas estruturas das tabelas pode representar problemas na manutenção do projeto, e ao ter-se uma chave sem nenhum significado semântico, garante-se que ela estará imune a qualquer mudança feita na tabela; Agregados Agregados são coleções de tabelas Fato ou Dimensão com dados num estado pré-processado, facilitando assim o acesso a estes dados. Os critérios para se definir um agregado são informações muito requeridas ou muito difíceis de se obter. Suponha que num DW de uma cadeia varejista especializada em moda, a consulta mais freqüente seja o total de vendas de peças masculinas/femininas por região geográfica e por mês. As informações no DW estão armazenadas em TDLoja, TDProduto, TDDia e TFVendas, em níveis mais granulares dos que os que a consulta exige. Uma nova tabela Fato poderia ser definida, sumarizando as informações necessárias para a consulta: TFVendaRegiaoCategoriaMes (região-loja, categoria-produto, mês-venda, qtdevendida); Com esta nova tabela (agregado), o resultado da consulta seria muito mais rápido, pois os dados já foram pré-processados. Quanto menor for a cardinalidade da(s) coluna(s) escolhida(s) para compor o agregado, maior será a sumarização, e melhor será a otimização da consulta. (BARBIERI, 2001, p. 110) No exemplo acima: 42

43 5 regiões x 2 categorias x 12 meses = 120 registros; Alguns cuidados devem ser observados ao se definir agregados: O aumento da redundância dos dados, sendo necessário mais espaço para armazenamento; Nem todos os atributos da tabela granular estarão na tabela Fato, pois alguns deles não são aditivos em todas as dimensões; A precisão dos atributos aditivos deve ser maior nos agregados, para se evitar overflow em operações de adição; 43

44 4 Estudo de Caso As próximas páginas apresentarão o objetivo maior deste trabalho, um estudo de caso sobre a implantação de Business Intelligence em uma pequena empresa cujo nome não será revelado, devido à importância das informações desta que serão apresentadas aqui. A LojaX, como será referenciada daqui por diante, é uma loja varejista especializada em moda, que trabalha com confecção adulta e infantil, além de comercializar artigos de cama, mesa e banho, entre outros, como calçados e tecidos. Recentemente, seu sistema de informática, antigo e baseado em arquivos, foi substituído por um ERP que utiliza o banco de dados SQL Server Dados históricos dos últimos 6 anos foram recuperados e convertidos para este banco. Há uma pequena montanha de dados esperando para ser analisada, transformada em informação e após a devida análise dos tomadores de decisão da empresa, se tornar conhecimento. São aproximadamente registros de venda, um número ridículo se comparado a grandes empresas, que certamente vendem mais do que isso em alguns meses. Entretanto, inteligência em negócios é uma qualidade independente do tamanho do negócio. Este trabalho busca medir o valor que o Business Intelligence irá agregar a esta empresa, contra os custos de desenvolvimento e implantação que virão junto. 4.1 Motivação A motivação para realizar o projeto não parte somente do foco do cliente, que necessita ter informação precisa ao seu alcance no menor tempo possível, mas também do foco da empresa desenvolvedora do ERP. Acoplar ferramentas de Business Intelligence ao sistema irá agregar valor ao ERP. O projeto desenvolvido servirá para 44

45 outros clientes do sistema, dividindo o custo final entre eles, e multiplicando os lucros. Resumindo: Business Intelligence é um conceito em evidência (clientes pedem por isso); Seu desenvolvimento agrega valor tanto ao ERP quanto ao negócio do cliente; A solução desenvolvida é ajustável para todos os clientes do ERP; 4.2 Questões a Serem Respondidas Este trabalho desenvolverá um projeto de Data Mart seguindo as metodologias descritas nos capítulos anteriores, enfocando o fato dos clientes serem pequenas empresas, e ao final responder as seguintes questões: Business Intelligence é viável para pequenas empresas? As vantagens superam os custos? As informações realmente serão disponibilizadas mais rapidamente? Levar em conta que pequenos clientes não possuem um banco de dados tão pesado; As informações serão disponibilizadas com mais qualidade? O cliente conseguirá responder suas próprias questões (sem auxílio do fornecedor do ERP para criar um relatório, por exemplo)? Qual o custo para o cliente? Compra de ferramentas, treinamento, etc...; 4.3 Desenvolvimento do Estudo de Caso Este estudo de caso desenvolverá um Data Mart sobre Vendas. Esta área de negócio foi escolhida pelos seguintes motivos: É um tema clássico de projeto dimensional, relacionado com os primeiros sistemas desta natureza aplicados ao varejo, cujos conceitos já estão sólidos, ideal para o objetivo deste trabalho. Além disso, as dimensões aqui desenvolvidas estarão quase sempre presentes em todos os DMs futuramente desenvolvidos, como as dimensões de tempo (Dia-Mês-Ano) e espaço (Loja- Cidade-Região); 45

46 É uma área de negócio importante (se não a mais importante) para todos os clientes do ERP. No futuro outros DMs serão desenvolvidos, tendo como base os resultados deste; As metodologias descritas nos capítulos anteriores, baseadas em autores e profissionais de renome, serão utilizadas para o desenvolvimento deste projeto. Será elaborado: Um plano de desenvolvimento do DM de Vendas da LojaX; A modelagem dimensional do DM; O projeto físico do DM de Vendas; 4.4 Planejamento Escopo do Projeto O principal objetivo deste projeto é melhorar as estratégias de venda da empresa. Deve-se, a final deste projeto, permitir a LojaX reconhecer quais perfis de produtos são mais vendidos, quando eles são vendidos (dimensão temporal), onde eles são vendidos (região geográfica). Além do escopo principal, este projeto analisará, em parte, os clientes da LojaX, permitindo informar quem compra o quê e quando. Que perfil de cliente compra determinado produto, ou que perfil de produtos é mais vendido para determinados clientes. Esta análise não será tão eficiente, visto que a LojaX efetua a maioria de suas vendas sem cadastrar os clientes, não permitindo assim guardar informações importantes sobre eles, além do que este não é o escopo deste projeto Abordagem do Projeto 46

47 A abordagem deste projeto será evolutiva. Este projeto busca analisar somente uma área de negócios (vendas) e disponibilizar imediatamente o produto final (Data Mart de Vendas) ao cliente (LojaX). Outros DMs serão construídos e integrarão o DW no futuro Integração O DM de Vendas, como dito anteriormente, é um tema clássico da modelagem dimensional, estudado e esgotado ao máximo. As dimensões que serão definidas neste projeto, assim como seus atributos e métricas, baseiam-se na experiência de autores citados durante todo este trabalho. Portanto pode-se dizer que a integração com outros DMs ocorrerá sem traumas. As principais dimensões deste projeto são: TDDia: informações temporais; TDProduto: informações sobre os produtos da LojaX; TDLoja: informações sobre a LojaX (inclui informações geográficas); TDCliente: informações sobre os clientes da LojaX (inclui informações geográficas); As métricas deste projeto são: Quantidade vendida; Valor vendido (R$); Os atributos e hierarquizações serão definidos em e Arquitetura Tecnológica Os critérios utilizados para escolha da arquitetura tecnológica foram alta performance e disponibilidade, mas principalmente o custo. A LojaX, assim como a imensa maioria dos clientes do ERP, é uma pequena empresa, que não possui 47

48 condições de investir grandes quantias na compra de novas licenças de software, como ferramentas OLAP e ETC. Como o ERP é desenvolvido com o SGBD SQL Server 2000, seus clientes já compraram esta licença. Felizmente, para o cliente e para a empresa desenvolvedora do ERP, o SQL Server disponibiliza junto com seu SGBD: Ferramenta OLAP: Microsoft SQL Server 2000 Analysis Services (MSAS); Ferramenta ETC: construída através da utilização das ferramentas presentes com o SGBD: - Stored Procedures escritas com Microsoft Transact-SQL (extensão proprietária da linguagem SQL utilizada pelo SGBD Microsoft SQL Server); - Data Transformation Services (DTS): ferramenta destinada a tratamento de dados e processos de ETC em geral; - SQL Server Agent: Serviço do SQL Server que monitora o SGBD e permite agendar tarefas para serem executadas periodicamente e automaticamente; Funções de Data Mining, disponibilizadas dentro do MSAS; Isto quer dizer que todos os clientes do ERP já possuem licenças de software OLAP, ETC, e até de Data Mining, sem nenhum custo extra. O catálogo para controle de metadados do projeto será feito numa planilha Excel, visto que a empresa desenvolvedora do ERP já possui licenças Microsoft Office, além de que o tamanho deste projeto não justifica o investimento em uma ferramenta deste tipo, e as necessidades são plenamente atendidas pelo Excel. A apresentação das informações do Data Mart de Vendas também será feita utilizando o Excel, aproveitando sua integração com o MSAS, e o custo zero para o cliente. 48

49 Portanto as tecnologias escolhidas para o projeto são: SGBD: Microsoft SQL Server 2000; Ferramenta OLAP/Data Mining: MSAS; Ferramenta ETC: Transact-SQL/ DTS / SQL Server Agent; Catálogo de Metadados: Microsoft Excel 2000; Apresentação das informações: Microsoft Excel 2000; Levantamento das Necessidades Primeiramente precisamos conhecer de onde vêm os dados. O Banco de dados do ERP possui aproximadamente trezentas tabelas, porém este projeto utilizará apenas onze, e nem todos os relacionamentos entre elas serão aproveitados também. O banco possui dados históricos dos últimos seis anos, que foram convertidos recentemente durante a implantação do ERP, em substituição ao sistema antigo. A integridade do banco foi garantida durante a conversão, restando apenas alguns problemas de redundância de dados, como nomes repetidos de cidades. Estes problemas serão tratados na fase de ETC. Um diagrama simplificado das entidades que serão aproveitadas neste projeto pode ser visto abaixo: 49

50 Figura 4.1: Diagrama simplificado das tabelas do ERP necessárias para o projeto. A seguir segue uma breve descrição das tabelas e do relacionamento entre elas: ITENS: é a tabela com a descrição dos produtos vendidos pela LojaX. Possui campos como código, descrição, valor de custo, entre outros; GRUPOS1, GRUPOS2 e GRUPOS3: são tabelas que classificam os itens em categorias, que vão das mais gerais às mais específicas (GRUPOS1 à GRUPOS3). Nem todos os itens usam as três tabelas, e os relacionamentos entre elas não se aplicam a este projeto. Exemplo: O item BLUSA MALWEE 773/06 está cadastrado com: - GRUPOS1: CONFECCOES ADULTO ; 50

51 - GRUPOS2: BLUSA ; e - GRUPOS3: BLUSA MANGA CURTA ; UNIDADES: Cadastro de unidades de medidas dos itens. Um produto pode ser vendido por peça, caixa, ou até por quilo (para tecidos, por exemplo). O relacionamento com GRUPOS3 não é necessário no contexto deste projeto; NOTAS: tabela onde as notas fiscais são armazenadas, são os registros de vendas efetuadas pela loja. Possui informações como número, data de emissão, data de saída, valor total, entre outros; ITENS_NOTA: esta tabela relaciona as tabelas ITENS e NOTAS, dizendo que produtos foram comercializados em determinada nota. Possui campos como quantidade e valor total; PESSOAS: tabela com informações sobre pessoas relacionadas à empresa. No escopo deste projeto, ela trata dos clientes da LojaX, com informações sobre código, nome, sexo, estado civil, etc. Seu relacionamento com ITENS não é considerado neste projeto, mas o relacionamento com NOTAS sim, informando quem efetuou determinada compra de produtos (o dono da nota); PESSOAS_COMPLEMENTO: Informações complementares da pessoa. Nenhum campo desta tabela é utilizado no projeto, somente o relacionamento com a tabela CIDADES, e conseqüentemente UF, informando de onde é o cliente; CIDADES: tabela com cadastro de cidades; UF: tabela com cadastro de unidades federativas; SIG_FILIAIS: tabela com informações sobre a loja, tanto da matriz quanto das filiais. No caso da LojaX, não existem filiais, mas se porventura surgir alguma no futuro, o Data Mart utilizará informações vindas desta tabela como cidade e UF, para saber a origem de cada venda, por exemplo; 51

52 seguir: O modelo conceitual simplificado do Data Mart de Vendas está visualizado logo a Figura 4.2: Modelo conceitual do Data Mart de Vendas; Foram identificadas quatro dimensões e uma entidade fato: TDLoja: dimensão com informações sobre cada filial, como CNPJ, endereço, cidade, etc.; TDProduto: dimensão com informações sobre os produtos que a LojaX comercializa, como descrição, classificação, etc; TDDia: dimensão com informações temporais, dia, mês, ano, estação do ano, etc; TDCliente: dimensão com informações sobre os clientes da LojaX, como nome, data de nascimento, endereço, etc; TFVendas: entidade com as informações sobre as vendas da LojaX, como quantidade vendida, valor vendido, etc; O modelo conceitual dimensional será desenvolvido e portanto melhor descrito no capítulo Modelagem Dimensional A modelagem dimensional será vista em maior detalhe no próximo capítulo. 52

53 4.5 A modelagem dimensional do DM de Vendas Os próximos capítulos abordam os passos da modelagem dimensional, discutido no capítulo 3, aplicados a este estudo de caso Área de Negócio e Processos-alvo do Data Mart Como mencionado anteriormente, a área de negócio foco deste Data Mart é Vendas. Os processos-alvo serão as estatísticas de venda, procurando saber o volume de vendas, tanto em quantidade como em valor (R$) Granularidade A granularidade de cada entidade/tabela será discutido separadamente, mas a linha seguida por este projeto será buscar a maior granularidade possível. Com isso se garante a conformidade entre as dimensões e entre os próximos Data Marts que surgirão. O volume dos dados produzidos e seu custo de armazenamento também será analisado para cada dimensão Definindo as Tabelas Dimensão Aqui será descrito como foram construídas as dimensões deste DM, justificando cada comportamento/atributo definido nas entidades. As regras básicas seguidas neste projeto (já justificadas nos capítulos anteriores) são apresentadas a seguir: Buscar a maior granularidade possível; Dinâmica das Dimensões: criar nova versão do registro a cada atualização; Sempre utilizar chaves artificiais; Normalização: Esquema Estrela; 53

54 Estas informações serão documentadas em um arquivo Excel, em virtude da relação custo/benefício. A seguir seguem as definições de cada dimensão Dimensão Loja (TDLoja) Apesar do cliente-alvo deste projeto não possuir nenhuma filial (motivo suficiente para descartar esta dimensão), este DM visa futuramente atender a outros clientes, que possuem filiais, justificando assim a criação desta tabela. A descrição desta tabela é mostrada abaixo: Campo Bytes Descrição Origem Handle 4 Identificador ETC NHandleSIG 4 Identificador externo SIG_FILIAIS.Handle: int(4) CDsNome 50 Nome empresa SIG_FILIAIS.NOME: char(50) CDsRazao 50 Razão social SIG_FILIAIS.RAZAO: char(50) CDsReduzido 8 Nome reduzido SIG_FILIAIS.REDUZIDO: char(8) CDsEndereco 50 Endereço SIG_FILIAIS.ENDERECO: char(50) CComplemento 50 Complemento SIG_FILIAIS.COMPLEMENTO: char(50) CCEP 9 CEP SIG_FILIAIS.CEP: char(9) CFone 20 Fone SIG_FILIAIS.FONE: char(20) CFax 20 Fax SIG_FILIAIS.FAX: char(20) CCnpjCPF 20 Cnpj/CPF SIG_FILIAIS.CGC_CPF: char(20) CDsCidade 50 Cidade CIDADES.Nome: varchar(50) CUF 2 UF UF.Sigla: varchar(2) CRegiao Nordeste, Sudeste, Sul, Norte, 8 Centro-Oeste e Exterior ETC DDtIni 8 Val. Ini (YYYY-MM-AA) ETC DDtFim 8 Val. Fim (YYYY-MM-AA) ETC EStatus 1 A/I (Ativo/Inativo) ETC Tabela 4.1: Dimensão TDLoja. A primeira coluna apresenta o nome do campo na tabela. A segunda mostra quantos bytes o campo ocupa. A terceira coluna faz uma breve descrição sobre o campo. E a última coluna apresenta a origem desta informação, que pode ser o campo e a tabela do sistema ERP (NomeTabela.NomeCampo), ou pode ter sido originada dos processos de Extração-Transformação-Carga (ETC), que serão discutidos mais adiante. Este será o padrão seguido para descrever as tabelas do DM. 54

55 Os campos da dimensão Loja detalhados a seguir existem em todas as outras dimensões, com exceção da dimensão de Tempo, que em razão de não sofrer atualizações só possui o campo Handle: Handle: é o campo que identifica um registro da tabela univocamente (campo chave da tabela). É uma seqüência de números inteiros positivos (1,2,3...) sem nenhum significado semântico, por isso chamado de chave artificial; DDtIni: data início da validade do registro, informando quando o registro foi inserido no Data Mart. O registro não sofrerá atualizações. Quando esta informação tiver de ser atualizada, os campos DDtFim e Estatus serão utilizados; DDtFim: data fim da validade do registro, informando quando ele deixou de ser utilizado pelos fatos armazenados no DM; EStatus: Situação do registro no Data Mart. Ele pode estar ativo (A) ou inativo (I); Os campos DDtIni, DDtFim e EStatus foram criados em virtude da política de atualização do Data Mart: a cada atualização da informação, um novo registro é criado (com EStatus = A, DDtIni = Data Atual e DDtFim = NULO ) e o registro antigo (se houver) é aposentado (EStatus = I, DDtFim = Data Atual ). Assim se mantém o histórico dos dados Hierarquia da Dimensão TDLoja A dimensão Loja possui três atributos com relacionamento hierárquico entre si, CRegiao (1:N) CUF (1:N) CDsCidade (1:N) Loja (todos os outros atributos). Um exemplo seria: a LojaX localiza-se em Maringá, que pertence ao Paraná, que localizase na região sul Estimativa do Volume de Dados da Dimensão TDLoja Somando-se a coluna Bytes da tabela descritiva da dimensão TDLoja, verifica-se que cada registro nesta tabela ocupa 362 bytes. Supondo que haja 1 alteração por ano em cada registro (1 nova versão da informação) tem-se que ao final de seis anos esta 55

56 tabela terá apenas 6 registros da LojaX, já que não existem filiais, fazendo um total de (362 bytes x 6 anos) = 2172 bytes, ou seja, não ocupará espaço algum Dimensão Cliente (TDCliente) A dimensão cliente, como o próprio nome diz apresenta informações sobre os clientes. Sua tabela descritiva é apresentada a seguir: Campo Bytes Descrição Origem Handle 4 Identificador ETC NCodigo 4 Código PESSOAS.Codigo: int CNome 60 Nome PESSOAS.Nome: char(60) ETipo 1 F/J (Física/Jurídica) PESSOAS.Tipo: char(1) ESexo M/F/N (Masculino, Feminino, Não 1 Informado) PESSOAS.Sexo: char(9) CDsEstCivil Solteiro, Casado, Viúvo, Outros, Não 13 Informado PESSOAS.Estado_Civil: char(10) DDtNasc 8 Data de Nascimento PESSOAS.Dt_Nascimento: datetime CCnpjCPF 20 Cnpj/CPF PESSOAS.CGC_CPF: char(20) CNroRG 16 RG PESSOAS.RG: char(20) CDsCidade 50 Cidade CIDADES.Nome: varchar(50) CUF 2 UF UF.Sigla: varchar(2) CRegiao Nordeste, Sudeste, Sul, Norte, Centro- 12 Oeste e Exterior ETC DDtIni 8 Val. Ini (YYYY-MM-AA) ETC DDtFim 8 Val. Fim (YYYY-MM-AA) ETC EStatus 1 A/I (Ativo/Inativo) ETC Tabela 4.2: Dimensão TDCliente Hierarquia da Dimensão TDCliente A dimensão Cliente possui três atributos com relacionamento hierárquico entre si, CRegiao (1:N) CUF (1:N) CDsCidade (1:N) Cliente (todos os outros atributos). Um exemplo seria: o cliente José Augusto mora em Presidente Prudente, que pertence a São Paulo, que localiza-se na região sudeste Estimativa do Volume de Dados da Dimensão TDCliente 56

57 Somando-se a coluna Bytes da tabela descritiva da dimensão TDCliente, verificase que cada registro nesta tabela ocupa 208 bytes. A LojaX possui hoje em seu cadastro cerca de clientes. Supondo que haja 1 alteração por ano em cada registro (uma previsão alta, mas como não estamos considerando novos clientes, é válida), tem-se que ao final de seis anos esta tabela terá ( x 208 bytes x 6 anos) = 470,4 MB bytes, um valor irrisório para um Data Warehouse Dimensão Tempo (TDDia) A dimensão tempo apresenta um registro para cada dia do ano, durante os anos que os fatos ocorrem na LojaX. Seus campos estão descritos abaixo: Campo Bytes Descrição Origem Handle 4 Identificador - DDtCompleta 8 YYYY-MM-AA - NDia 1 Número do dia (1 até 31) - NDiaSemana Número do dia da semana (1 = Domingo até 7 = 1 Sábado) - NMes 1 Número do mês (1 até 12) - NTrimestre 1 Número do trimestre (1 até 4) - NAno 2 Número do ano (ex: 2005) - CEstacaoAno 1 Estação do ano (P/V/O/I) - BFinalSemana 1 É sábado ou domingo? (S/N) - BVespFeriado 1 É véspera de feriado? (S/N) - Tabela 4.3: Dimensão TDDia. Os dados não tem origem, pois representam datas, que serão usadas para definir quando ocorreu uma venda. Atributos que agregam valor ao modelo são os três últimos, informando a estação do ano, se o dia caiu no fim de semana, e se dia era véspera de feriado. Atributos como número do dia e número do mês servem para não termos que extrair esta informação do campo Data completa, economizando processamento, e para dar mais opções para filtros e hierarquias Hierarquia da Dimensão TDDia 57

58 A dimensão Tempo possui quatro atributos com relacionamento hierárquico entre si, NAno (1:N) NTrimestre (1:N) NMes (1:N) NDia (1:N) Data (todos os outros atributos). Para garantir a conformidade, o campo referente às estações do ano não é considerado na hierarquia, pois um trimestre (outubro novembro dezembro) está em duas estações do ano (primavera verão) Estimativa do Volume de Dados da Dimensão TDDia Somando-se a coluna Bytes da tabela descritiva da dimensão TDDia, verifica-se que cada registro nesta tabela ocupa 19 bytes. Se a LojaX decidir manter dados históricos de vendas dos últimos seis anos, teremos (19 x 365 x 6) = bytes Dimensão Produto (TDProduto) A dimensão produto descreve os itens vendidos na LojaX. Sua tabela descritiva é apresentada a seguir: Campo Bytes Descrição Origem Handle 4 Identificador - NCodigo 10 Código do produto ITENS.Codigo: char(13) CDsProduto 85 Descrição do produto ITENS.Descricao: varchar(100) + ITENS.Complemento: varchar(35) CDsUnidade 2 Sigla da unidade de medida (pç, un, kg) UNIDADES.Sigla: char(3) CDsGrupo1 50 Descrição Grupo1 GRUPOS1.Nome: varchar(50) CDsGrupo2 50 Descrição Grupo2 GRUPOS2.Nome: varchar(50) CDsGrupo3 50 Descrição Grupo3 GRUPOS3.Nome: varchar(50) DDtIni 8 Val. Ini (YYYY-MM-AA) - DDtFim 8 Val. Fim (YYYY-MM-AA) - EStatus 1 A/I (Ativo/Inativo) - Tabela 4.4: Dimensão TDProduto Hierarquia da Dimensão TDProduto A dimensão Produto possui três atributos com relacionamento hierárquico entre si, Grupos1 (1:N) Grupos2 (1:N) Grupos3 (1:N) Produto (todos os outros atributos). 58

59 Estimativa do Volume de Dados da Dimensão TDProduto Somando-se a coluna Bytes da tabela descritiva da dimensão TDProduto, verifica-se que cada registro nesta tabela ocupa 268 bytes. A LojaX possui hoje em seu cadastro cerca de produtos. Supondo que haja 1 alteração por ano em cada registro (uma previsão alta, mas como não estamos considerando novos produtos, é válida), tem-se que ao final de seis anos esta tabela terá (11556 x 268 bytes x 6 anos) = 185,78 MB bytes, um valor irrisório para um Data Warehouse Dimensão Produto Volátil (TDProdVolatil) A dimensão produto volátil tem por objetivo aplicar a técnica avançada de modelagem dimensional definida em (Estratégia para implementação de dimensões grandes e voláteis). No contexto da LojaX, o único atributo que varia com mais freqüência no cadastro de produtos é o valor de custo. Também foi mostrado que a dimensão produto não ocupará muito espaço em disco. Estes dois motivos justificariam a não implementação da dimensão produto volátil. Porém, como este DM pretende atender a outros clientes, que podem ter características diferentes (mais produtos com mais atributos voláteis), decidiu-se implementar esta dimensão. Sua tabela descritiva é apresentada a seguir: Campo Bytes Descrição Origem Handle 4 Identificador - NCustoValor 5 Valor de Custo ITENS.Custo_Valor: numeric(9) DDtIni 8 Val. Ini (YYYY-MM-AA) - DDtFim 8 Val. Fim (YYYY-MM-AA) - EStatus 1 A/I (Ativo/Inativo) - FKProd 4 Chave da dimensão TDProduto TDProduto.Handle: int Tabela 4.5: Dimensão TDProdVolatil. 59

60 Hierarquia da Dimensão TDProdVolatil entre si. A dimensão Produto Volátil não possui atributos com relacionamento hierárquico Estimativa do Volume de Dados da Dimensão TDProdVolatil Somando-se a coluna Bytes da tabela descritiva da dimensão TDProdVolatil, verifica-se que cada registro nesta tabela ocupa 30 bytes. A LojaX possui hoje em seu cadastro cerca de produtos. Supondo que cada produto da loja tenha seu valor de custo atualizado todo mês, temos 12 alterações por ano em cada registro (uma previsão alta, mas como não estamos considerando novos produtos, é válida). Portanto, ao final de seis anos esta tabela terá (11556 x 30 bytes x 6 anos x 12 meses) = 249,55 MB bytes Definindo a Tabela Fato de Vendas (TFVendas) A tabela fato já está praticamente definida (pois já definimos as dimensões). Sua descrição pode ser vista abaixo: Campo Bytes Descrição Origem FKDia 4 Chave estrangeira (FK) de TDDia TDDia.Handle: int FKProduto 4 FK de TDProduto TDProduto.Handle: int FKProdVolatil 4 FK de TDProdVolatil TDProdVolatil.Handle: int FKCliente 4 FK de TDCliente TDCliente.Handle: int FKLoja 4 FK de TDLoja TDLoja.Handle: int NNroNota 4 Número da nota fiscal NOTAS.Numero: char(6) (dimensão degenerada) NQtdeVendida 4 Quantidade vendida (em unidades) SUM(ITENS_NOTA.Quantidade) NReaisVendidos 9 Valor vendido (em reais R$) SUM(ITENS_NOTA.Total) Tabela 4.6: TFVendas. 60

61 Como se pode ver, a tabela fato reúne informações de todas as dimensões, formando assim um evento de negócio. Junto a este evento de negócio, duas medidas numéricas são armazenadas: Quantidade vendida: medida semi-aditiva que informa quantas unidades foram vendidas naquele evento de negócio; Valor vendido: medida aditiva que informa o valor vendido naquele evento de negócio; Além disso, o atributo número da nota fiscal representa uma dimensão degenerada em nosso modelo. Notas fiscais não têm uma tabela correspondente no Data Mart, mas este atributo é interessante para filtros e para agrupamentos (quantos itens foram vendidos na mesma nota, etc). Um evento de negócio armazenado pelo DM pode ser exemplificado da seguinte forma: A LojaX localizada em Maringá vendeu três meias, totalizando R$ 19,90, ao cliente José da Silva, que reside em Londrina, no dia dois de agosto de Esta é a informação que uma linha da tabela fato pode armazenar Estimativa do Volume de Dados da Tabela Fato de Vendas Esta é a mais importante estimativa de volume do Data Mart, pois como já foi visto, o volume da tabela fato é muito superior ao volume de todas a dimensões juntas. Somando-se a coluna Bytes da tabela descritiva da tabela TFVendas, verifica-se que cada registro ocupa 37 bytes. Tendo como base os registros importados (11556 produtos, clientes, 1 loja), e supondo uma previsão alta: que cada produto da LojaX seja vendido todos os dias em todas as filiais da LojaX. Assim, após seis anos, temos: (11556 produtos x 1 loja x 6 anos x 365 dias x 37 bytes) = 9361,58 MB, aproximadamente 9,3 GB, um volume baixo e barato de se manter, mesmo para pequenas empresas. 61

62 Observe que esta previsão não considerou o número da nota. Se 10 unidades de um produto forem vendidas no mesmo dia, na mesma loja, para o mesmo cliente, mas em 2 notas fiscais diferentes, dois registros serão criados em TFVendas. Isto pode ser uma questão importante a se considerar ao implantar o DM em novos clientes. No caso da LojaX, a previsão foi realmente alta, pois os registros importados dos últimos seis anos (exatamente notas fiscais) resultaram em linhas na tabela fato, que multiplicadas por 37 bytes resultou em 156 MB. 4.6 O Projeto Físico do DM de Vendas Grande parte do projeto físico do Data Mart de Vendas foi abordado no capítulo anterior. A definição dos campos chaves e a estimativa do tamanho de cada tabela já foram calculados. Aspectos particulares de cada SGBD, como definição de índices, espaços de tabelas e estratégias de particionamento não serão tratados neste trabalho, pois envolvem conhecimento/auxílio de um administrador de banco de dados, e isto foge ao escopo da monografia. Portanto, somente aspectos essenciais serão analisados aqui. Vejamos como ficaram definidas as tabelas do Data Mart de Vendas: 62

63 Figura 4.3: Estrutura lógica do DM de Vendas. Temos cada dimensão com uma chave primária artificial numérica, que juntas formam a restrição de chave primária da tabela fato (mais a chave da dimensão degenerada Nota Fiscal). Ao mesmo tempo elas são chaves estrangeiras na tabela, evitando por exemplo que um venda seja feita para um cliente que não existe na dimensão TDCliente. 4.7 O Projeto de ETC do Data Mart de Vendas 63

64 A extração, transformação e carga dos dados do modelo fonte para o modelo dimensional foram feitas através de Stored Procedures escritas na linguagem Transact- SQL do banco SQL Server. Isto foi possível porque a única fonte de alimentação do DM será o ERP, que também utiliza o SGBD SQL Server. Caso houvesse a necessidade de se integrar dados de fontes diversas, como arquivos texto e planilhas de cálculo, esta solução teria de ser repensada, mas aqui ela mostrou-se mais do que satisfatória Limpeza dos Dados A conversão do sistema antigo para o ERP envolveu grande parte dos processos iniciais de ETC. Os dados foram analisados e importados do sistema antigo para o banco de dados do ERP de forma a garantir a integridade referencial, ou seja, eliminando a possibilidade de valores inválidos, chaves duplicadas, etc. Porém, uma verificação nas tabelas mostrou que ainda restavam alguns problemas: A tabela CIDADES continha diversos registros repetidos, como CURITIBA e CURITIBANA, LONDRINA e LOMDRINA, etc. Os registros repetidos/incorretos foram eliminados e os registros de outras tabelas que apontavam para estas cidades inválidas passaram a apontar para o registro correto; A tabela PESSOAS possuía 1679 pessoas sem uma cidade relacionada a elas. Como é impossível se descobrir onde elas moravam, presumiu-se que pertenciam à mesma cidade da LojaX, e todas passaram a ter MARINGA como sua cidade; A tabela ITENS possuía 1 produto inconsistente, que não tinha qualquer tipo de descrição. Como ele não se relacionava com nenhuma outra tabela do sistema (como ITENS_NOTA), este produto foi excluído do banco; A tabela PESSOAS_COMPLEMENTO possuía 2 registros para a mesma pessoa (tabela PESSOAS). Em contato com a LojaX descobriu-se o registro correto e o outro foi excluído; 64

65 Fora estes pequenos problemas, nenhum outro foi encontrado, e a limpeza dos dados mostrou-se bem simples Transformação/Derivação dos Dados A transformação busca adequar valores normalmente aceitos no ERP (como valores Nulos) para valores que tragam significado ao registro no modelo dimensional, ou que pelo menos garanta a sua consistência. Vejamos alguns exemplos do DM de Vendas: A tabela PESSOAS armazena 57 pessoas físicas que não tem o campo sexo informado (o atributo está NULL). Por causa disso o atributo ESexo da tabela TDCliente do Data Mart passou a aceitar o valor N, de não informado. O mesmo ocorreu com o estado civil (4 pessoas físicas não tem estado civil informado atualmente); O atributo CRegiao, que aceita os valores Nordeste, Sudeste, Sul, Norte, Centro-Oeste e Exterior e que está presente nas tabelas TDCliente e TDLoja do Data Mart de Vendas, não é extraído do modelo fonte diretamente, mas sim transformado a partir do atributo Sigla da tabela UF. Se a sigla não pertencer a nenhuma unidade federativa do Brasil, a região é informada como Exterior ; Carga dos Dados Após a carga inicial dos dados, que passa todas as informações do ERP para o DM, através de Stored Procedures escritas em Transact-SQL, uma tarefa foi agendada através do serviço SQL Server Agent para executar os comandos de carga no DM todos os dias às 2h00m. Esta é uma operação que pode consumir muitos recursos do servidor, e como neste também funciona o banco de dados do ERP, optou-se por carregar os dados no Data Mart no horário em que a LojaX está fechada. 65

66 Portanto os dados presentes no Data Mart sempre estarão atualizados até o dia anterior. Durante esta atualização são carregados no Data Mart novos registros ou novas versões destes registros (caso eles já existam e tenham sofrido uma atualização no modelo fonte dos dados). Após efetuar a carga nas dimensões (TDCliente, TDProduto, TDLoja e o registro correspondente ao dia atual na tabela TDDIa) o processo de carga busca por novos eventos de negócio para carregar em TFVendas (as notas fiscais daquele dia). Além disso, precisamos atualizar de forma automática o cubo de dados que será criado dentro da ferramenta MSAS (Microsoft Analysis Services), pois é a partir dele que o usuário conseguirá de forma prática e intuitiva construir relatórios e consultas à base de dados. Neste ponto entra a integração do MSAS com o SQL Server. O processo de carga no MSAS será automatizado pela construção de um pacote DTS, onde já existe uma ação pré-definida chamada Analysis Services Processing Task. Ao escolher esta ação, basta escolhermos o cubo de dados a ser processado e o pacote está pronto. Com o pacote criado, basta criar uma tarefa para agendar a sua execução, que será feita através do Microsoft SQL Server Agent. Esta tarefa será executada às 3h00m, após a carga dos dados ter sido feita no Data Mart. 66

67 5 Avaliação dos Resultados Este capítulo busca avaliar os resultados deste trabalho. Espera-se aqui responder as questões levantadas em 4.2, e concluir se Business Intelligence é ou não é viável para pequenas empresas. A seguir são avaliadas as questões do estudo de caso. 5.1 As informações realmente serão disponibilizadas mais rapidamente? Para responder esta questão, será avaliada a performance da execução de consultas em base de dados que usem modelagem relacional pura (o banco de dados do ERP) e modelagem dimensional (o Data Mart de Vendas). As duas bases contêm informações históricas sobre as vendas da LojaX efetuadas nos últimos 6 anos. Porém, sendo a LojaX uma pequena empresa, a quantidade de registros não é grande ( notas fiscais em 6 anos) e o objetivo desta análise é descobrir se numa base deste tamanho o ganho de performance da modelagem dimensional de dados feita no Data Mart de Vendas será significativo. Nos testes, 2 consultas diferentes serão executadas. São consultas típicas em um sistema de Business Intelligence, que representam relatórios sumarizados: Consulta 1: Resultado mensal de vendas de produtos da categoria (Grupo1) "LINHA INTIMA DIA/NOITE" para clientes pessoa física do sexo feminino durante o ano de 2005; Consulta 2: Resultado mensal de vendas de produtos da categoria (Grupo1) TECIDOS, agrupados pelo Grupo2 (flanela, brim, oxford, etc.), para clientes de Maringá durante o mês de Dezembro, de 2002 a 2006; Para cada consulta, será apresentada a declaração SQL correspondente, o plano de execução e o tempo de processamento, primeiro para o modelo relacional puro e depois para o modelo dimensional. 67

68 As consultas serão executadas no SQL Server 2000, usando sempre o mesmo servidor: Processador AMD Athlon ; Memória RAM 1024 MB DDR2 533MHz; Disco rígido Samsung SATA 250 Gb 7200 rpm; Placa-mãe Asus M2N-MX; Além disso, o servidor do SQL Server 2000 será reiniciado a cada consulta, para garantir que nenhum resultado será favorecido pelo uso de planos de execução gravados em cache de memória. Cada consulta será executada três vezes, repetindo o procedimento de reiniciar o SQL Server. Os valores de tempo de processamento representarão a média das três medições Teste 1: Consulta 1 no modelo relacional puro A declaração correspondente à consulta é exibida abaixo: SELECT Month(N.DATA_EMISSAO) as MES, SUM(IA.Quantidade) AS Qtde_Vendida, SUM(IA.TOTAL) AS Reais_Vendidos FROM ITENS_NOTA IA INNER JOIN NOTAS N INNER JOIN ITENS I INNER JOIN GRUPOS1 G1 INNER JOIN PESSOAS P ON N.HANDLE = IA.NTA_HANDLE ON I.HANDLE = IA.ITE_HANDLE ON G1.HANDLE = I.GR1_HANDLE ON P.HANDLE = N.PES_HANDLE WHERE p.tipo = 'F' AND p.sexo = 'Feminino' AND year(n.data_emissao) = 2005 AND G1.NOME = 'LINHA INTIMA DIA/NOITE' GROUP BY MONTH(N.DATA_EMISSAO) ORDER BY MONTH(N.DATA_EMISSAO) Esta consulta acessa 5 tabelas, com um tempo de processamento de 1 minuto e 38 segundos. O plano de execução envolve 15 passos, sendo 5 deles pesquisas em índices (representados pela figura de organograma ): 68

69 Figura 5.1: Plano de execução da consulta 1 para o modelo relacional puro Teste 2: Consulta 1 no modelo dimensional A declaração correspondente à consulta é exibida abaixo: SELECT D.NMes as Mes, SUM(FV.NQtdeVendida) as Qtde_Vendida, SUM(FV.NReaisVendidos) as Reais_Vendidos FROM TFVendas FV INNER JOIN TDDia D ON D.HANDLE = FV.FKDia INNER JOIN TDCliente C ON C.HANDLE = FV.FKCliente INNER JOIN TDProduto P ON P.HANDLE = FV.FKProduto WHERE D.NAno = 2005 AND C.ESexo = 'F' AND C.ETipo = 'F' AND P.CDsGrupo1 = 'LINHA INTIMA DIA/NOITE' GROUP BY D.NMes ORDER BY D.Nmes Acessando 4 tabelas, a consulta levou apenas 3 segundos para ser executada. O plano de execução envolve 10 passos, sendo que 3 são pesquisas em índices. Veja a figura abaixo: 69

70 Figura 5.2: Plano de execução da consulta 1 no modelo dimensional Teste 3: Consulta 2 no modelo relacional puro A declaração da consulta é mostrada abaixo: SELECT Month(N.DATA_EMISSAO) as MES, Year(N.DATA_EMISSAO) as ANO, G2.NOME as GRUPO, SUM(IA.Quantidade) AS Qtde_Vendida, SUM(IA.TOTAL) AS Reais_Vendidos FROM ITENS_NOTA IA INNER JOIN NOTAS N ON N.HANDLE = IA.NTA_HANDLE INNER JOIN ITENS I ON I.HANDLE = IA.ITE_HANDLE INNER JOIN GRUPOS1 G1 ON G1.HANDLE = I.GR1_HANDLE INNER JOIN GRUPOS2 G2 ON G2.HANDLE = I.GR2_HANDLE INNER JOIN PESSOAS P ON P.HANDLE = N.PES_HANDLE INNER JOIN PESSOAS_COMPLEMENTO PC ON PC.PES_HANDLE = P.HANDLE INNER JOIN CIDADES C ON C.HANDLE = PC.CID_HANDLE WHERE Month(N.DATA_EMISSAO) = 12 AND year(n.data_emissao) BETWEEN 2002 AND 2006 AND G1.NOME = 'TECIDOS' AND C.NOME = 'MARINGA' GROUP BY MONTH(N.DATA_EMISSAO), YEAR(N.DATA_EMISSAO), G2.NOME ORDER BY MONTH(N.DATA_EMISSAO), YEAR(N.DATA_EMISSAO), G2.NOME A declaração SQL mostra que 8 tabelas são consultadas, levando 6 minutos e 50 segundos para ser processada. O plano de execução envolve 23 passos: 70

71 Figura 5.3: Plano de execução da consulta 2 no modelo relacional puro Teste 4: Consulta 2 no modelo dimensional A declaração desta consulta é vista logo abaixo: SELECT D.NMes as Mes, D.Ano as Ano, P.CDsGrupo2 as Grupo, SUM(FV.NQtdeVendida) as Qtde_Vendida, SUM(FV.NReaisVendidos) as Reais_Vendidos FROM TFVendas FV INNER JOIN TDDia D ON D.HANDLE = FV.FKDia INNER JOIN TDCliente C ON C.HANDLE = FV.FKCliente INNER JOIN TDProduto P ON P.HANDLE = FV.FKProduto WHERE D.NMes = 12 AND D.NAno BETWEEN 2002 AND 2006 AND P.CDsGrupo1 = 'TECIDOS' AND C.CDsCidade = 'MARINGA' GROUP BY D.NMes, D.Ano, P.CDsGrupo2 ORDER BY D.Nmes, D.Ano, P.CDsGrupo2 A consulta acessa apenas 4 tabelas, com tempo de processamento de apenas 4 segundos. O plano de execução envolve 11 passos: 71

72 Figura 5.4: Plano de execução da consulta 2 no modelo relacional dimensional. Consulta Quesito Modelo Relacional Puro Modelo Dimensional 1 Número de tabelas 5 4 Número de passos do plano 15 passos 10 passos Tempo de processamento 00:01:38 00:00:03 2 Número de tabelas 8 4 Número de passos do plano 23 passos 11 passos Tempo de processamento 00:06:50 00:00:04 Tabela 5.1: Resultados comparativos nos modelos relacional e dimensional. Como se pôde ver, a performance das consultas realizadas no modelo dimensional foram muito superiores às realizadas no modelo relacional. Este resultado já era esperado, pois o foco do modelo dimensional é a consulta aos dados, porém os testes demonstraram que mesmo numa pequena base de dados as informações serão disponibilizadas mais rapidamente, um ponto a favor para o uso de Business Intelligence em pequenas empresas. 5.2 As informações serão disponibilizadas com mais facilidade e qualidade? Como as informações serão disponibilizadas ao cliente LojaX utilizando o Data Mart de Vendas? Os dados serão disponibilizados com mais facilidade? O cliente 72

73 conseguirá responder suas questões montando ele mesmo a consulta a ser realizada no banco? Conseguirá a LojaX criar um novo relatório sem o auxílio da empresa desenvolvedora do ERP? Estas questões envolvem diretamente a capacidade da ferramenta MSAS de disponibilizar as informações do Data Mart de maneira prática e intuitiva, produzindo assim conhecimento de qualidade. E a integração com o Microsoft Excel é crucial nesta avaliação. É importante lembrar que não é a LojaX que irá montar o cubo de dados, este será disponibilizado para o cliente para que ele simplesmente consulte os dados. Por isso aqui esta será a parte do MSAS que será avaliada, juntamente com a integração com o Excel Consulta aos dados através do Cube Browser Dentro da ferramenta MSAS, o usuário do DM de Vendas poderá consultar o cubo de dados clicando com o botão direito sobre ele e acessando a opção Browser Data : 73

74 Figura 5.5: como acessar a opção Browser Data, para consultar o cubo de dados. O cubo de dados do Data Mart de Vendas será então aberto através do recurso interno do MSAS chamado Cube Browser : 74

75 Figura 5.6: Consultando os dados através do Cube Browser. Neste Browser, as dimensões listadas na parte superior (mais escura) funcionam como filtros de relatório. Para selecionar o filtro, basta clicar na combobox e escolher a opção correspondente. O relatório pode ser redefinido usando o recurso de arrastar e soltar. Veja a figura abaixo: 75

76 Figura 5.7: Outra consulta montada com o Cube Browser. Na figura acima se tem o total de unidades vendidas na primeira célula (coluna 1) para todos os produtos (exibido na linha 1, como All Produto ) para todos os clientes durante todo o período de tempo contido no Data Mart (filtros All TDCliente e All TDDia, respectivamente). Os filtros do relatório podem ser redefinidos a qualquer momento. Se o usuário quiser analisar somente o mês de janeiro de 2007, por exemplo, basta clicar sobre a 76

77 dimensão TDDia, navegar pela árvore até encontrar a opção desejada (ANO TRIMESTRE MÊS) e clicar sobre ela. Veja as figuras abaixo: Figura 5.8: Selecionando um filtro na dimensão TDDia. 77

78 Figura 5.9: Relatório atualizado após filtro na dimensão TDDia (Janeiro/2007). Caso o usuário queira informações mais específicas no relatório, basta fazer um drill-down, descendo na hierarquia do produto. Isto é feito clicando duas vezes sobre o grupo desejado: 78

79 Figura 5.10: Relatório atualizado após fazer um drill-down em acessórios. Observe que a terceira linha apresenta os totais do grupo ACESSORIOS. Para subir a hierarquia (drill-up) basta clicar 2 vezes sobre o grupo novamente Integração do MSAS com o Microsoft Excel Apesar de sua facilidade de uso e qualidade na apresentação dos dados, o MSAS não foi feito para ser utilizado pelo usuário final (apesar de ser possível trabalhar assim). O Cube Browser é um aplicativo para ajudar o desenvolvedor do Data Warehouse a visualizar os cubos durante seu trabalho, ajudando a definir melhor o Data Mart. 79

80 Como já demonstrado, um dos fatores críticos de sucesso para o desenvolvimento de uma ambiente de Business Intelligence é a forma de visualização das informações. E nada melhor para o usuário final do que ter uma ferramenta adaptável, que torne amigável a extração, manipulação e interpretação das informações, e que tenha baixo custo. Mais ainda, uma ferramenta ideal seria aquela que o usuário já conheça e saiba utilizar. E no contexto deste estudo de caso esta ferramenta é a planilha eletrônica Microsoft Excel. Em uma pesquisa da fundação Getúlio Vargas (FGV), em 2003, sobre o marketshare das planilhas eletrônicas, o Excel levou o primeiro prêmio, como a ferramenta mais usada no Brasil. (apud FILHO, 2004, p. 13) Todos os clientes do ERP (portanto futuros clientes do DM de Vendas) possuem licenças do Excel. Este por sua vez tem integração nativa com MSAS (ambos são produtos Microsoft). Resta então avaliar o quão boa é esta integração, e como os dados serão disponibilizados para o usuário final do Data Mart. No Excel, o usuário que acessa dados do MSAS verá uma tabela dinâmica ou gráfico dinâmico, que poderá ser editado conforme sua conveniência. Estas tabelas e gráficos dinâmicos vinculados ao MSAS são muito mais poderosos do que tabela/gráficos dinâmicos tradicionais, pois oferecem três grandes vantagens: (CRIVELINI, 2007, p. 24) Permitem análise de um volume de dados exponencialmente maior, pois buscam dados que estão armazenados fora do Excel (que tem um limite de linhas por planilha); Oferecem respostas mais rápidas, por trabalhar em uma arquitetura clienteservidor; Apresentam as dimensões e suas hierarquias de uma maneira extremamente intuitiva, que é característica ao ambiente OLAP; 80

81 Resta agora avaliar a integração de uma planilha Excel ao MSAS. Este processo consiste em definir uma fonte de dados para a tabela dinâmica. Vejamos os passos: 1. Especificar a criação de uma tabela dinâmica: Figura 5.11: Criando uma nova tabela dinâmica. 2. Definir que a tabela dinâmica usará uma fonte de dados externa: 81

82 Figura 5.12: Definindo a origem dos dados. 3. Detalhando a fonte de dados. Clique em Get Data : Figura 5.13: Detalhando a origem dos dados. 4. Vá até a aba OLAP Cubes e clique em New Data Source e depois OK: 82

83 Figura 5.14: Criando uma fonte de dados OLAP. 5. Informe um nome para a fonte de dados e escolha o provedor OLAP. O MSAS pode se conectar a qualquer ferramenta OLAP que suporte OLE.DB for OLAP (CRIVELINI, 2007, p. 25). Clique em Connect : Figura 5.15: Escolhendo o provedor OLAP. 6. Escolha o provedor para conexão com o servidor OLAP. O MSAS utiliza a autenticação Windows, é desnecessário informar usuário e senha para conectar: 83

84 Figura 5.16: Conexão com o servidor OLAP. 7. Escolha o banco de dados para conectar: 84

85 Figura 5.17: Conexão com o servidor OLAP. 8. Escolha o cubo a ser utilizado: Figura 5.18: Escolhendo o cubo que será consultado. 9. Clique em OK até chegar à tela abaixo. Clique em Finish : Figura 5.19: Finalizando a definição da conexão da tabela dinâmica com o MSAS. 85

86 A conexão está definida em 9 passos. Resta agora definir o layout da tabela dinâmica utilizando apenas o recurso arrastar e soltar. Vejamos alguns exemplos de como explorar as funcionalidades desta interface: 1. Arraste e solte as dimensões para criar o relatório: Figura 5.20: Esqueleto da tabela dinâmica. 86

87 Figura 5.21: Resultado após arrastar os fatos Quantidade Vendida e Valor Vendido e as dimensões TDDia e TDProduto. 2. No filtro exibido no topo do relatório (poderia ser qualquer dimensão, ou todas elas), clique na combobox para navegar na hierarquia da dimensão e escolher um novo elemento: 87

88 Figura 5.22: Seleção de um novo item de filtro na dimensão produto. 88

89 Figura 5.23: Relatório atualizado. 3. Para fazer um drill-down ou drill-up, basta clicar duas vezes sobre o elemento: 89

90 Figura 5.24: Clicando duas vezes sobre CONFECCOES ADULTO. 90

91 Figura 5.25: Fazendo um drill-down no primeiro trimestre de Clique no botão Chart Wizard dentro da janela Pivot Table para gerar um gráfico do relatório como ele se encontra no momento: 91

92 Figura 5.26: Gerando um gráfico da tabela. 92

93 Figura.5.27: Gráfico da tabela dinâmica. Com apenas 9 passos uma planilha do Excel foi integrada ao MSAS, e com apenas alguns cliques do mouse, arrastando e soltando dimensões e fatos, foi possível definir relatórios de maneira fácil e independente da ajuda de terceiros. A cada novo layout do relatório, é possível traçar um gráfico. Junte isso tudo à capacidade e qualidade da planilha eletrônica Excel (que vai muito além do que as características citadas aqui) e as possibilidades se tornam intermináveis. Portanto, quando se compara estes resultados com os relatórios gerados pelo ERP, que são fixos e nem sempre podem ser alterados (não de maneira tão fácil como a demonstrada aqui) pode-se concluir que as informações realmente serão disponibilizadas com muito mais qualidade e facilidade. 93