UNIVERSIDADE DO SUL DE SANTA CATARINA CARLOS ROBERTO PEREIRA EDINILTON JOSÉ LUBK

Tamanho: px
Começar a partir da página:

Download "UNIVERSIDADE DO SUL DE SANTA CATARINA CARLOS ROBERTO PEREIRA EDINILTON JOSÉ LUBK"

Transcrição

1 UNIVERSIDADE DO SUL DE SANTA CATARINA CARLOS ROBERTO PEREIRA EDINILTON JOSÉ LUBK CONSTRUÇÃO DE UM SISTEMA DE BUSINESS INTELLIGENCE PARA ANÁLISE DE LOGS DE COMUNICAÇÃO Palhoça 2009

2 CARLOS ROBERTO PEREIRA EDINILTON JOSÉ LUBK CONSTRUÇÃO DE UM SISTEMA DE BUSINESS INTELLIGENCE PARA ANÁLISE DE LOGS DE COMUNICAÇÃO Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de bacharel em Sistemas de Informação. Orientador: Prof. Aran Bey Tcholakian Morales, Dr. Palhoça 2009

3 CARLOS ROBERTO PEREIRA EDINILTON JOSÉ LUBK CONSTRUÇÃO DE UM SISTEMA DE BUSINESS INTELLIGENCE PARA ANÁLISE DE LOGS DE COMUNICAÇÃO Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina. Palhoça, 16 de novembro de Professor e orientador Aran Bey Tcholakian Morales, Dr. Universidade do Sul de Santa Catarina Prof. Alexandre Vitoreti de Oliveira, Me. Universidade do Sul de Santa Catarina Marcos Antônio Silva, Me. Nexxera Tecnologia e Serviços S/A

4 RESUMO Nos dias de hoje, o bem de maior valor no mercado é a informação. Esse bem tão precioso, cujo valor cresce a cada dia, tem grande influência entre o sucesso e o fracasso em praticamente todos os aspectos de nossa vida. Tomar um remédio ao qual somos alérgicos pode nos levar a morte, a escolha errada da profissão pode nos levar a decepção, uma decisão de um governo tomada em cima de informações falsas ou imprecisas pode levar seu país a guerra, uma decisão estratégica tomada sem a informação adequada pode levar uma empresa a falência. Mesmo com um valor tão alto, muitas vezes a informação é deixada de lado devido à dificuldade em acessá-la causado pelo seu formato e modelo de arquitetura utilizado para armazenar os dados. Esse trabalho trata de transformar os dados contidos em uma arquitetura de difícil análise e armazena-los em uma arquitetura que permita a fácil leitura e interpretação dessas informações. Para isso, escolheu-se uma base de dados de comunicação e transferência de arquivos, cujos dados estão armazenados em arquivos de texto, e baseando-se nos conceitos, técnicas e ferramentas de Business Intelligence, construiu-se uma arquitetura onde os dados foram disponibilizados de forma que mesmo pessoas com pouco conhecimento técnico consigam manipular e combinar esses dados gerando planilhas e gráficos que representam as informações contidas na base original. Para isso, realizou-se uma pesquisa bibliográfica sobre o assunto e um levantamento dos dados contidos nos arquivos de log, criou-se duas bases de dados no PostgreSQL 8.4, cujas modelagens foram feitas no Enterprise Architect , sendo uma relacional e uma multidimensional. Utilizando-se o Kettle Spoon da suíte Pentanho criou-se dois scripts ETL, sendo o primeiro para carregar os dados dos arquivos de log para a base relacional e o segundo para classificar e sumarizar os dados contidos na base relacional e inseri-los na base multidimensional. Em seguida, alterou-se o exemplo de um sistema web, distribuído com o Mondrian da suíte Pentanho para que este acesse a base de dados multidimensional, exiba os dados através de um navegador web onde é possível realizar as operações OLAP com os dados exibidos. Para isso, através do Schema Workbench da suíte Pentanho, desenvolveu-se um esquema XML que contém os cubos OLAP que mapeiam os fatos, dimensões e medidas da base multidimensional. Foi feito o

5 deploy da aplicação no Tomcat e em seguida, fizeram-se algumas análises através dos relatórios e gráficos gerados pelo Mondrian, a fim de demonstrar o resultado do trabalho realizado e o valor das informações encontradas. Palavras chave: Business Intelligence, Suite Pentanho, Análise de dados.

6 ABSTRACT Nowadays, information is the most valuable thing for a company. This so-called precious good, which value rises everyday, has great influence between success and failure among every aspect of our lives. To take a drug on which we are allergic can kill us, the wrong career choice can drove ourselves to disappointment, a wrong government choice took on wrong information can lead a country to war, a strategic decision without information can bankrupt a company. Even with this high value, sometimes the information is left behind only because it is hard to access its architecture model on which data is stored. This work is about transform data hold in a hard to analyse architecture and store it in a easy to read and understand architecture. To do it so, we have chosen a communication and file transfer database, on which data are stored in as text files, and using Business Intelligence concepts, techniques and tools, we have built an architecture on which data are available in a way people with few technical knowledge can manipulate and combine these data generating spreadsheets and graphics that represents information on the original database. In order to all this, a bibliographic research was made together with a data study among log files. We also have create two databases in PostgreSQL 8.4, using Enterprise Architect for de modeling (a relational and a multidimensional model). Using Kettle Spoon of Pentaho Suite, we have built two ETL scripts, being the first one to load data from log files to relational database and the second one to classify and summarize data from relational database and transfer them to the multidimensional database. Following, we've altered a web system example which came along with Mondrian from Pentaho Suite, so it could access the multidimensional database and show them on a web browser so one can make OLAP operations on the shown data. In order to do that, through Schema Workbench from Pentaho suite, we have developed a XML schema that holds the OLAP cubes which map facts, dimensions e measures from multidimensional database. The application was deployed on Tomcat and analyzes were made through Mondrian graphics so the results could be shown and the information value could be found. Key words: Business Intelligence, Suite Pentanho, Data Analysis.

7 LISTA DE ILUSTRAÇÕES Figura 1 - Arquitetura de um sistema de BI Figura 2 - Data Warehouse orientado por assunto...24 Figura 3 - Integração dos dados no Data Warehouse...26 Figura 4 - Modelo dimensional ou multidimensional, também conhecido como Star Schema28 Figura 5 - OLAP - Operação Drill-Down...31 Figura 6 - OLAP - Operação Roll-Up Figura 7 - OLAP - Operação Slice and Dice...33 Figura 8 - OLAP - Operação Pivoting...34 Figura 9 - Arquitetura de um sistema de BI - Solução...42 Figura 10 - Base de dados ODS...44 Figura 11 - Data Mart de comunicação...47 Figura 12 - ETL1 desenvolvido no Kettle Spoom Figura 13 ETL2 desenvolvido no Kettle Spoom Figura 14 - Projeto de exemplo do Mondrian - Estrutura de diretórios Figura 15 - Diretório "queries do projeto "Mondrian" Figura 16 - Tela inicial do Pentaho Workbench...67 Figura 17 - Tela do Pentaho Workbench com cubos criados...69 Figura 18 - Página inicial do projeto rodando no Apache Tomcat...74 Figura 19 - Página com o resultado da consulta AvgConexDay...74 Figura 20 - Tabelas auxiliares criadas para ocultar o nome de clientes e usuários...75 Figura 21 - ConexoesHora - Página inicial Figura 22 - ConexoesHora Drill-Down Tempo para fato conexões...78 Figura 23 - ConexoesHora - Gráfico de Junho/2009 com medidas diárias para fato conexões...78 Figura 24 - ConexoesHora - Gráfico de conexões abortadas e senhas inválidas com medidas diárias Junho/ Figura 25 - ConexoesHora Drill-Down Usuários para fato conexões...80 Figura 26 - ConexoesHora - Gráfico de conexões com medidas por usuário Junho/ Figura 27 - ConexoesHora - Gráfico de conexões abortadas e senhas inválidas com medidas por usuário Junho/ Figura 28 - ConexoesHora Drill-Down Interfaces para fato conexões....83

8 Figura 29 - ConexoesHora - Gráfico de conexões com medidas por interface de comunicação Junho/ Figura 30 - ConexoesHora - Gráfico de conexões abortadas e senhas inválidas com medidas por interface de comunicação Junho/ Figura 31 - TransferenciaHora Drill-Down Tempo para fato transferência...85 Figura 32 - TransferenciaHora Gráfico mensal com medias diárias de bytes transmitidos, recebidos e em quarentena - Junho/ Figura 33 - TransferenciaHora Gráfico mensal com medias diárias de bytes transmitidos e em quarentena - Junho/ Figura 34 - TransferenciaHora Gráfico mensal com medias diárias de arquivos transmitidos, recebidos e em quarentena - Junho/ Figura 35 - TransferenciaHora Drill-Down Usuários para fato transferência...88 Figura 36 - TransferenciaHora Gráfico mensal do número de arquivos transmitidos, recebidos e em quarentena, para usuários do cliente Junho/ Figura 37 - TransferenciaHora Gráfico mensal da quantidade de bytes transmitidos, recebidos e em quarentena, para usuários do cliente Junho/ Figura TransferenciaHora Drill-Down Interface para fato transferência Figura 39 - TransferenciaHora Gráfico mensal do número de arquivos transmitidos, recebidos e em quarentena, por interface - Junho/ Figura 40 - TransferenciaHora Gráfico mensal do total de bytes transmitidos, recebidos e em quarentena, por interface - Junho/ Figura 41 - ConexoesDia Tela inicial da consulta de soma das conexões diárias...93 Figura 42 - ConexoesDia Drill-Down Tempo para fato conexões ao nível de mês...94 Figura 43- ConexoesDia Gráfico Primeiro Semetre 2009, de conexõe efetuadas, abortadas e tentivas com senhas inválidas...94 Figura 44 - TransferenciaDia Drill-Down Tempo para fato transferência ao nível de mês..95 Figura 45 - TransferenciaDia Gráfico semestral com medidas mensais de bytes transmitidos e em quarentena - Primeiro semestre de Figura 46 - TransferenciaDia Gráfico semestral com medidas mensais de arquivos transmitidos e em quarentena - Primeiro semestre de Figura 47 - TransferenciaDia Gráfico mensal com médias diárias de bytes transmitidos, recebidos e em quarentena - Junho/

9 LISTA DE QUADROS Quadro 1 - Passos para a construção de um Data Warehouse...22 Quadro 2 - Campos comuns para todas as operações...49 Quadro 3 - Campos exclusivos da operação de início de sessão código Quadro 4 - Campos exclusivos da operação de início de sessão código Quadro 5 - Campos exclusivos da operação de sessão abortada código Quadro 6 - Campos exclusivos da operação de transmissão código Quadro 7 - Campos exclusivos da operação de transmissão código Quadro 8 - Campos exclusivos da operação de recepção de arquivos código Quadro 9 - Campos exclusivos da operação de recepção de sinais código Quadro 10 - Campos exclusivos da operação de senha inválida código Quadro 11 - Campos exclusivos da operação de envio para a quarentena código Quadro 12 - Campos exclusivos da operação de final de sessão código Quadro 13 - Campos exclusivos da operação de final de sessão código Quadro 14 - Quantidade de registros na base ODS após a execução completa do ETL Quadro 15 - Quantidade de registros no Data Mart após a execução completa do ETL Quadro 16 - Quantidade de registros no Data Mart após serem eliminados os registros dos meses anteriores para os fatos hora Quadro 17 - Trecho do arquivo web.xml que define a conexão com a base de dados...70 Quadro 18 - Trecho do arquivo web.xml alterado para definir a conexão com o Data Mart de comunicação Quadro 19 - Dados para conexão com a base de dados do Data Mart Quadro 20 - Conteúdo do arquivo mondrian.jsp distribuído junto com o projeto de exemplo do Mondrian Quadro 21 - Conteúdo do arquivo AvgConexDay.jsp que realiza uma consulta no Data Mart de comunicação....72

10 LISTA DE SIGLAS AED Análise Exploratória de Dados BI Business Intelligence DW Data Warehouse ER Entity Relationship ERP Enterprise Resource Planning ETL Extract, Transform and Load ETC Extração, Transformação e Carga IP Internet Protocol KDD Knowledge Discovery in Databases ODS Operational Data Storage ou Staging OLAP On-line Analytical Processing OLTP On-line Transaction Processing RA Recepção Automática SQL Structured Query Language TA Transmissão Automática TR Transmissão e Recepção

11 SUMÁRIO 1. INTRODUÇÃO PROBLEMA OBJETIVOS Objetivo Geral Objetivos específicos JUSTIFICATIVA ESTRUTURA DA MONOGRAFIA REVISÃO BIBLIOGRÁFICA INTRODUÇÃO SISTEMAS DE BI (BUSINESS INTELLIGENCE) Arquitetura de um sistema de BI ETL (EXTRACT, TRANSFORM AND LOAD) DATA WAREHOUSE Modelo dimensional ANÁLISES DE DADOS OLAP (On-Line Analytical Processing) Análise Exploratória de Dados (AED) Técnicas de mineração de dados CONSIDERAÇÕES FINAIS DO CAPÍTULO MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA ETAPAS METODOLÓGICAS DELIMITAÇÕES DESENVOLVIMENTO DA SOLUÇÃO ARQUITETURA DA SOLUÇÃO ESTRUTURAS DE DADOS UTILIZADAS OLTP (Online Transaction Processing) ODS (Operational Data Storage) Data Warehouse EXTRAÇÃO TRANSFORMAÇÃO E CARGA DOS DADOS Mapeamento dos registros de log (base OLTP)...48

12 Parte fixa do registro Parte variável do registro Início de sessão (1021 e 1050) Sessão abortada (1023) Transmissão (1003 e 1004) Recepção (1051) Sinais (1013) Senha inválida (1026) Envio de arquivos para a quarentena (1020) Final de sessão (1016 e 1024) ETL1 (Extract, Transform and Load) ETL2 (Extract, Transform and Load) ANÁLISE DE DADOS A definição das ferramentas Instalando o projeto de exemplo do Mondrian Criando cubos OLAP Criação e configuração de um novo projeto no Mondrian Visualizando os cubos pelo servidor web Antes de iniciar as análises dos dados nos cubos ANÁLISE DOS DADOS ATRAVÉS DOS CUBOS OLAP Análise dos dados do cubo ConexoesHora Análise através da dimensão de tempo (ConexoesHora) Análise através da dimensão de usuários (ConexoesHora) Análise através da dimensão de interfaces de comunicação (ConexoesHora) Análise dos dados do cubo TransferenciaHora Análise através da dimensão de tempo (TransferenciaHora) Análise através da dimensão de usuários (TransferenciaHora) Análise através da dimensão de interfaces de comunicação (TransferenciaHora) Análise dos dados do cubo ConexoesDia Análise através da dimensão de tempo (ConexoesDia) Análise dos dados do cubo TransferenciaDia Análise através da dimensão de tempo (TransferenciaDia)...95

13 4.6 CONSIDERAÇÕES FINAIS CONCLUSÕES E TRABALHOS FUTUROS CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS APÊNDICES APÊNDICE A Dicionário de dados da base ODS APÊNDICE B Script SQL para a criação da base ODS APÊNDICE C Dicionário de dados da base do DataMart APÊNDICE D Script SQL para a criação da base do DataMart APÊNDICE E Componentes de update do ETL APÊNDICE F Estatísticas de execução do ETL APÊNDICE G Conteúdo do arquivo PCC_OLAP.xml que define os cubos para o Data Mart de comunicação APÊNDICE H Conteúdo dos arquivos de consulta ao Data Mart APÊNDICE I Comandos SQL executados na base de dados do Data Mart para ocultar o nome de clientes e usuários...132

14 13 1. INTRODUÇÃO Visando à necessidade expressada no dia-a-dia, na qual, alguns segmentos corporativos tomam inúmeras decisões de modo cego, onde não se tem compreensão dos riscos causados por decisões precipitadas e erradas. Realizou-se a pesquisa demonstrada abaixo para auxiliar a tomada de decisão a fim de ter fundamentos e conhecimentos necessários para realizar as decisões certas quando essas forem imprescindíveis. Da mesma forma que, quando vamos a um médico, ficamos satisfeitos quando o diagnóstico é realizado após exames detalhados de nossas condições físicas (exames de sangue, urina, raios X, etc.), os executivos necessitam, para diagnosticar e administrar as tendências de negócio, de um ambiente que lhes permita executar exames nos seus dados com a mesma capacidade de profundidade, transparência e evolução. Quando um médico, além de seus exames, analisa seu histórico pessoal e familiar, com essa análise pode diagnosticar tendências a um quadro de diabetes, problemas cardíacos, infecções respiratórias, etc. (MACHADO, 2008, p.19). Ainda, segundo Machado (2004), da mesma forma que o histórico pessoal e familiar é importante para que um médico possa identificar uma possível tendência de um paciente a desenvolver uma determinada patologia e, dessa forma, tomar as devidas precauções, o histórico de uma empresa pode ajudar seus executivos a tomar decisões que possam melhorar seu desempenho e/ou protegê-la e prepará-la para os possíveis desafios a serem enfrentados. Este trabalho visa construir uma arquitetura baseada nas técnicas e ferramentas de BI (Business Intelligence), para transformar dados operacionais brutos, contidos em arquivos de log, em informação estratégica. A arquitetura consiste na construção de um repositório de dados adequado para a transformação de dados operacionais em informações estratégicas, no desenvolvimento de sistemas de ETL (extração, transformação e carga), das bases de operação para o novo repositório de dados e, no desenvolvimento de sistemas de análises de dados, que permitirão transformar os dados brutos em informações estratégicas para o processo decisório. As definições dessa arquitetura, tanto quanto a sua forma final, como do modo como que será desenvolvida, devem respeitar as teorias e idéias de alguns dos principais autores sobre o assunto. Para isso, será realizada uma pesquisa bibliográfica com o objetivo de levantar tais teorias e idéias de modo a embasar o trabalho a ser desenvolvido.

15 PROBLEMA Há muito tempo, ouve-se falar que estamos na era da informação, e que esta é o bem mais precioso que existe. Podemos perceber isso no dia a dia com o aumento da nossa preocupação em proteger nossos dados pessoais. Sempre tentamos cada um a sua maneira, proteger dados como números de documentos, números de cartões de crédito, contas e senhas bancárias, números de telefone e, até mesmo, endereços. Agora, por que se tenta proteger essas informações? A resposta é simples. Porque se sabe o valor dessas informações. Não é muito difícil imaginar o que uma pessoa mal intencionada poderia fazer com elas. Muito mais que as pessoas, as empresas possuem uma preocupação muito maior em proteger seus dados, tanto que algumas possuem setores inteiros para cuidar da segurança dos dados. Existem, inclusive, empresas inteiras especializadas em segurança das informações. Milhões, se não bilhões de dólares, são gastos anualmente para proteger esse bem tão precioso, evitando que se caia nas mãos de pessoas mal intencionadas e, principalmente, de seus concorrentes. Agora, se essas informações da empresa são tão valiosas para pessoas mal intencionadas e para concorrentes, por que não seriam para a própria empresa? A resposta para essa pergunta é ainda mais simples. Essas informações são extremamente valiosas para a empresa, até mais do que para seus concorrentes ou para pessoas mal intencionadas. Acontece que a grande maioria das empresas possui e armazena apenas dados operacionais, que é claro, tem o seu valor. Porém é possível, através do conceito de BI (Business Intelligence), dar significado a esses dados, transformando-os em informação, armazenando de forma que possa ser acessada de forma rápida e simples, tornando-a muito mais valiosa. Com base no que foi exposto, até agora, este trabalho tem como objetivo a utilização do conceito, das técnicas e das ferramentas de BI para transformar dados operacionais, atualmente, armazenados em arquivos de texto (log), em informação relevante ao negócio da empresa e construir uma arquitetura que permita que essas informações possam ser acessadas a qualquer momento de forma rápida de simples.

16 OBJETIVOS A seguir, serão apresentados os objetivos deste trabalho Objetivo Geral Desenvolver uma arquitetura de BI que permita transformar dados operacionais contidos em arquivos de log no formato texto, em informações estratégicas que possam ser acessadas de forma rápida e simples, gerando conhecimento teórico e prático da arquitetura de sistemas de BI, de seus componentes e de suas ferramentas para aplicação em projetos futuros Objetivos específicos A) Mapear quais informações estão contidas nos arquivos de log; B) modelar e criar uma base relacional, para armazenar as informações encontradas nos arquivos de log (ODS Operational Data Storage ou Staging Area); C) criar e executar scripts para a importação dos dados dos arquivos de log na base relacional; D) modelar e criar uma base multidimensional, definindo-se quais serão as dimensões suportada e qual a granularidade dos dados; E) criação e execução dos scripts que filtrem e carregem dos dados contidos na base relacional para a base multidimensional; F) utilização de ferramentas de análises de dados nas bases criadas e a verificação e avaliação das informações encontradas; G) gerar conhecimento da arquitetura, das técnicas e das ferramentas de BI para aplicação em projetos futuros.

17 JUSTIFICATIVA Os principais fatores que levaram a escolha deste tema foram o valor que a informação tem, nos dias de hoje, em qualquer organização, o forte interesse/necessidade das organizações em implantar sistemas de BI e a existência de uma massa de dados pouco explorada que acreditamos ser uma base rica de dados de onde se pode extrair muita informação. Os arquivos a serem examinados possuem uma grande massa de dados operacionais que cumprem muito bem seu papel dentro da organização, porém qualquer análise mais profunda, em cima desses dados, é extremamente difícil devido à forma com que são armazenados. Acreditamos que, com a utilização das ferramentas e técnicas de BI, possamos extrair muitas informações importantes, hoje, escondidas atrás da estrutura de armazenamento. Com o desenvolvimento deste projeto, tais informações tornaram-se acessíveis de forma muito mais simples e que permitem uma análise detalhada de todas as informações contidas na nova base, agregando valor a essas informações ESTRUTURA DA MONOGRAFIA O trabalho está dividido em 05 capítulos, sendo que o capítulo 1 apresenta o tema, a problematização, os objetivos, a justificativa e a estrutura do trabalho. O capítulo 2 enfatiza a arquitetura dos sistemas de BI, focando os sistemas de extração, transformação e carga (ETL), o repositório de dados, do tipo Data Warehouse e as aplicações de front-end, como ferramentas OLAP, ferramentas de análise exploratória de dados e técnicas de mineração de dados. O capítulo 3 apresenta a metodologia adotada para o desenvolvimento do trabalho, o capítulo 4 aborda a modelagem e desenvolvimento do protótipo desenvolvido e o capítulo 5 apresenta as conclusões e trabalhos futuros.

18 17 2. REVISÃO BIBLIOGRÁFICA INTRODUÇÃO Neste capítulo, serão apresentados os principais conceitos, envolvendo todo o ambiente de BI, baseados nos principais autores da área, bem como algumas conclusões obtidas com o estudo desses conceitos SISTEMAS DE BI (BUSINESS INTELLIGENCE) O conceito de Business Intelligence, de forma mais ampla, pode ser entendido como a utilização de variadas fontes de informação para se definir estratégias de competitividade nos negócios da empresa. (BARBIERI, 2001 p.34). Segundo o mesmo Barbieri (2001 p.34), os Sistemas legados e os emergentes Enterprise Resource Planning [ERP], sistemas integrados corporativos, não trazem as informações gerenciais na sua forma mais palatável. Em meio à definição de Barbieri sobre BI, podemos extrair o texto a seguir no qual compreendemos o que são informações para uma empresa, quando a mesma não tem o conceito de BI junto com sua política. As informações vitais para tomadas de decisões estão escondidas em milhares de tabelas e arquivos inacessíveis aos mortais, ligadas por relacionamento e correlações transacionais, numa anatomia inadequada para os tomadores de decisão. Dessa forma, o conhecimento corporativo e as informações externas não estão prontamente disponíveis. O Jogo de palavras que melhor define essa situação é: Não se sabe o que se sabe e não se sabe o que não sabe. O objetivo maior das técnicas de BI neste contexto está exatamente 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, independente de sua origem. (BARBIERI, 2001, p.34).

19 Arquitetura de um sistema de BI A arquitetura de um sistema de BI está amplamente ligada à arquitetura do ambiente de Data Warehouse. Durante a pesquisa, foi possível encontrar uma série de arquiteturas diferentes de acordo com cada autor e cada contexto em que a arquitetura de BI estava sendo aplicada. Dessa forma, optou-se pela elaboração de uma figura, mostrando a arquitetura geral de um sistema de BI, que respeite os conceitos defendidos pelos principais autores da área e que mostre de uma forma bastante simples cada componente desse tipo de sistema. A Figura 1 mostra essa arquitetura. Figura 1 - Arquitetura de um sistema de BI. Fonte: Os Autores. Abaixo, segue uma breve descrição de cada componente mostrado na Figura 1: Dados da organização: Esse item é composto por todas as bases operacionais da organização. Esses dados, geralmente, estão armazenados em bases de dados relacionais,

20 19 porém isso não é uma regra. Esses dados podem estar armazenados nos mais diferentes formatos como, por exemplo, em arquivos no formato texto e planilhas. Normalmente, em uma mesma organização, existem várias bases de dados, de vários sistemas diferentes, sendo que, na maioria dos casos, essas bases não seguem um mesmo padrão de nomenclatura e/ou padrão de valores. Por exemplo, em uma base, podemos ter um campo chamado sexo cujos valores possíveis podem ser M ou F, em outra base, podemos ter um campo chamado cpsex cujos valores possíveis são 0 ou 1. Apesar de esses dois campos representarem a mesma informação, não há como relacioná-los. Mesmo esses dados estando armazenados em diferentes formatos e não havendo nenhuma padronização entre as diferentes bases, eles cumprem seu papel operacional dentro da empresa, porém uma análise mais profunda, relacionando essas diferentes bases, torna-se extremamente difícil. ETL (Extract, Transform and Load): O item ETL (EXTRACT, TRANSFORM AND LOAD) fala o que é ETL e de suas definições. Como mostrado na Figura 1, podemos ter duas ou até mais camadas de ETL. Essa não é a abordagem mais mencionada pelos autores pesquisados, mas, com a utilização do ODS (que será explicado em seguida), a utilização de duas camadas de ETL se faz necessária, o que tem, como conseqüência, a divisão de tarefas entre essas duas camadas e que, consequentemente, reduz a complexidade de implementação em cada uma delas. Dessa forma, a primeira camada extrai os dados das diferentes bases (internas ou externas), valida os dados, padroniza os dados e insere os registros na base da camada de ODS. A segunda camada extrai os dados já validados e padronizados de uma única base (ODS), faz a classificação, a sumarização e as demais operações necessárias e insere os dados no Data Warehouse. ODS (Operational Data Storage): Esse componente foi definido como: [...] um armazenamento intermediário dos dados, facilitando a integração dos dados do ambiente operativo antes de sua atualização no Data Warehouse. (MACHADO, 2008, p.37). Essa definição descreve perfeitamente o papel do ODS. Como já mencionado anteriormente, os dados a serem armazenados no Data Warehouse normalmente estão armazenados em diferentes bases de dados e sem nenhuma padronização entre elas, o que torna extremamente difícil a execução de operações, como: classificação, sumarização e

21 20 agrupamento. Dessa forma, o ODS terá o papel fundamental de armazenar os dados temporariamente em uma base de dados relacional padronizada, com o objetivo de facilitar o processamento desses dados para a carga no Data Warehouse. Data Warehouse: O item DATA WAREHOUSE, fala sobre os conceitos e definições de Data Warehouse. No caso da Figura 1, o Data Warehouse é composto por uma base de dados multidimensional composta por uma série de Data Marts, que poderá ser acessada por qualquer ferramenta que permita fazer consulta a banco de dados, sendo que esses dados já estão devidamente validados, organizados e sumarizados pelos processos anteriores. Data Mart: Podemos pensar em um Data Mart como sendo um pedaço de nosso Data Warehouse que representa um setor da organização ou um assunto tratado pelo Data Warehouse. Segundo Machado (2008, p.32), [...] Data Marts são as prateleira desse armazém de dados [DW], que permitem uma visão mais direcionada de um problema, funcionando como repositórios menores, orientados a áreas específicas. Front End: Esse módulo é composto pelas ferramentas de análise de dados Data Minining, descrito no item Técnicas de mineração de dados, pelo OLAP descrito no item Análise Exploratória de Dados (AED) e pelos relatórios gerados a partir desses dois itens. Essa é a parte da estrutura do Data Warehouse que vai ser apresentada aos usuários finais. Como já mencionado anteriormente, foram pesquisados diversos autores e muitas definições de estruturas de BI propostas pelos mesmos, e a escolha dessa estrutura se deu ser uma estrutura simples, que respeita as definições dos principais autores tanto no propósito quanto nos conceitos de cada componente e por estar alinhada com os propósitos deste trabalho.

22 ETL (EXTRACT, TRANSFORM AND LOAD) ETL ou da sigla, em português ETC, temos a seguinte percepção de acordo com Barbieri(2001, p.74), Nessa etapa deverão ser definidos os processos requeridos de transformação do modelo Fonte para o modelo Dimensional. Como podemos ver, Barbieri (2001) define ETL como sendo uma etapa responsável pela transferência dos dados de sua fonte original para uma base de dados multidimensional. Essa etapa é composta por vários scripts que realizam uma série de tarefas definidas pelo próprio Barbieri (2001), que têm como objetivo final a inserção dos dados extraídos de suas fontes originais em uma base multidimensional que compõe o Data Warehouse. Abaixo, podemos ver a definição de Barbieri (2001) para essas tarefas: *Filtro de Dados: Relaciona os procedimentos e condições para se eliminar os elementos de dados indesejáveis no modelo Dimensional. Por exemplo, desejamos que somente Ordens de Compra com valores totais maiores que R$1.000,00 sejam consideradas no sistema gerencial em projeto. *Integração de Dados: Define a forma de se correlacionar informações existentes em fontes distintas, e que deverão ser integradas no sistema gerencial. Suponha que alguns dados de fornecedor estejam no BD de Fornecedores corporativo da empresa, mas que algumas informações específicas, de interesse da área objeto do sistema aplicativo, estejam em planilhas locais. A integração dessas informações se torna fundamental para os requisitos do sistema e deverá ser previsto nessa fase. Outro exemplo poderia ser o caso de dados que estão codificados em um ambiente (por exemplo, o código do fornecedor embute região) e que deverão ser decodificados a fim de facilitar o seu uso, associando-se a ele uma informação explícita sobre região. *Condensação de Dados: Define forma de se reduzir volumes de dados visando obter informações resumidas e sumariadas. Normalmente, essas sumarizações acontecem nas dimensões dos dados, como tempo e geografia. Um exemplo seria a sumarização em termos semanais de dados diários de venda, ou o resumo em níveis geográficos, como por exemplo, vendas por região. *Conversão de Dados: Define os procedimentos para se transformar dados em unidades, formatos e dimensões diferentes. *Derivação de Dados: Define os meios e fórmulas para de produzir dados virtuais, a partir de dados existentes. (BARBIERI, 2001, p.75). Conforme já mencionado, Barbieri (2001) define ETL como sendo uma etapa, entretanto, dependendo da arquitetura adotada para o sistema de BI, isso pode variar, fazendose com que essa etapa seja dividida em duas ou mais etapas, cada uma responsável por executar uma ou mais tarefas. Neste trabalho, o ETL foi dividido em duas etapas, sendo a primeira descrita em ETL1 (Extract, Transform and Load), e a segunda em ETL2 (Extract,

23 22 Transform and Load). Apesar da divisão em duas etapas, todas as tarefas descritas por Barbieri (2001), foram executadas durante este trabalho DATA WAREHOUSE Para começarmos a falar sobre Data Warehouse, vamos acompanhar os nove pontos de decisão, que, de acordo com Kimball (1998), são fundamentais para elaboração de um projeto completo de banco de dados. Esses pontos são mostrados, em seguida, no Quadro 1. Número Descrição 1 Os processos e, portanto, a identidade das tabelas de fatos 2 A granularidade (nível de detalhe) de cada tabela de fatos 3 As dimensões de cada tabela de fatos 4 Os fatos, incluindo os fatos pré-calculados 5 Os atributos da dimensão com descrições completas e terminologia apropriada 6 Como rastrear dimensões de modificação lenta 7 Os agregados, dimensões heterogêneas, minidimensões, modos de consulta e outras decisões de armazenamento físico 8 A amplitude de tempo do histórico do banco de dados 9 Os intervalos em que os dados são extraídos e carregados no data warehouse Quadro 1 - Passos para a construção de um Data Warehouse Fonte: Kimball (1998, p. 162) Recomendamos que essas nove decisões sejam tomadas na ordem apresentada. Essa metodologia é do tipo top-down (de cima para baixo) [sic], porque inicia identificando os principais processos da empresa em que os dados serão coletados. (KIMBALL, 1998, p.162). O Data Warehouse é uma peça fundamental em qualquer sistema de BI, pois é nele que os dados serão armazenados para a utilização nas diversas ferramentas do sistema. Abaixo, temos algumas definições do que é um Data Warehouse, de acordo com algumas das principais autoridades no assunto:

24 23 Um data warehouse é um conjunto de dados baseados em assuntos, integrado, não volátil, e variável em relação ao tempo, de apoio a decisões gerenciais. (INMON, 1997, p.33). A arquitetura de um Data Warehouse inclui, além da estrutura de dados, mecanismos de comunicação, processamento e apresentação da informação para o usuário final. (MACHADO, 2008, p.31). Ele [Data Wharehouse] representa uma grande base de dados capaz de integrar, de forma concisa e confiável, as informações de interesse para a empresa, que se encontram espalhadas pelos sistemas operacionais e em fontes externas, para posterior utilização nos sistemas de apoio a decisão. (MACHADO, 2008, p.43). Data Warehouse, cuja tradução literal é Armazém de Dados, pode ser definido como um banco de dados, destinado a sistemas de apoio à decisão e cujos dados foram armazenados em estruturas lógicas dimensionais, possibilitando o seu processamento analítico por ferramentas especiais. (BARBIERI, 2001, p.49). Na definição de Inmon (1997), para Data Warehouse, podemos notar que ele menciona quatro características de um Data Warehouse, sendo elas a orientação por assunto, a variação em relação ao tempo, a não volatilidade e a integração. Essas características também são discutidas por Machado (2008). Abaixo, segue uma pequena explanação sobre cada uma dessas quatro características: Orientação por assunto: De acordo com Machado (2008, p. 28), [...] um Data Warehouse armazena as informações agrupadas por assunto de interesse da empresa que são mais importantes, em contraste com os sistemas operacionais que são orientados por processos, [...].

25 24 Figura 2 - Data Warehouse orientado por assunto Fonte: Machado (2008, p. 28) Como podemos perceber, existe uma diferença não muito clara no modo com que os dados são tratados em um sistema operacional e em um Data Warehouse. Enquanto uma base de dados operacional mantém os dados orientados por processos, no Data Warehouse, o foco são os assuntos de interesse da empresa, pois, em nível gerencial, esses dados são muito mais relevantes que os dados operacionais. A Figura 2 nos mostra isso com mais clareza. Por exemplo, um assunto de extrema importância, em qualquer empresa, é o assunto vendas. Isso porque o objetivo de toda empresa é vender. A informação de quanto a empresa está vendendo é de extrema importância, por exemplo, para o presidente da empresa, pois, se a empresa não vender, com toda certeza, irá falir. Assim, monitorar as vendas é um processo crítico em nível gerencial. Entretanto, os dados processuais da venda, como pedidos, notas e etc, não têm tanta importância para o nível gerencial, mas são indispensáveis em nível operacional. Os funcionários envolvidos com os processos de vendas dependem desses dados para concluir a venda. Essa diferença de abordagem deixa ainda mais claro o objetivo de um Data Warehouse de fornecer informações para o nível gerencial.

26 25 Variação em relação ao tempo: Machado (2008, p.29) afirma que Os dados de um Data Warehouse são precisos em relação ao tempo, representam resultados operacionais em determinado momento de tempo, o momento em que foram capturados. Os valores armazenados em um Data Warehouse representam o que ocorreu em um (ou em vários) ambiente operacional em uma determinada fração de tempo. O valor do ocorrido, nessa fração de tempo, não irá se alterar, porém esse valor é diferente em frações de tempos diferentes. A variação de valores entre frações de tempo é o que define essa característica de um Data Warehouse. Segundo Inmon (1997, p.36), A estrutura de chave dos dados operacionais pode conter, ou não, elementos de tempo, como ano, mês, dia, etc. A estrutura de chave do data warehouse sempre contém algum elemento de tempo. O elemento de tempo, mencionado acima por Inmon (2007), é o que irá definir o tamanho dessa fração de tempo. Não volatilidade: Segundo Machado (2008), um Data Warehouse possui apenas duas operações básicas que são a carga inicial (através da inserção dos dados no DW), e a consulta a esses dados. Já uma base de dados operacional, normalmente, possui quatro operações básicas: inserção, seleção, exclusão e alteração. À primeira vista, pode parecer que essa é uma diferença pequena, mas ela é suficiente para atribuir a característica de não volatilidade ao Data Warehouse, o que, em termos práticos, indica que, uma vez que um dado tenha sido inserido, ele não será alterado sob nenhuma circunstância até que não sejam mais úteis para a tomada de decisão. Mas o que acontece com esses dados quando eles não forem mais úteis para a tomada de decisão? Nesse caso, os dados devem ser apagados por uma rotina de limpeza, porém a operação de exclusão não é uma operação rotineira como na maioria das bases de dados operacionais, uma vez que uma informação foi inserida, em um Data Warehouse, ela somente deve ser excluída quando perder seu valor, o que não deve acontecer antes de 5 anos após sua inserção. Dessa forma, diz-se que os dados de um Data Warehouse não são voláteis.

27 26 Integração: Essa característica deve-se ao fato de que o Data Warehouse deve integrar os dados das diversas fontes de dados da organização, mesmo que não exista nenhum tipo de padronização entre as bases. Já falamos um pouco sobre esse assunto no item Arquitetura de um sistema de BI, ou seja, os dados presentes no Data Warehouse devem ser o resultado união dos dados com o mesmo significado, disponíveis nas várias bases da organização em um único campo, tendo, como conseqüência, a padronização dos valores desse campo. A Figura 3 nos mostra um exemplo clássico de integração de dados em um Data Warehouse. Figura 3 - Integração dos dados no Data Warehouse. Fonte: Machado (2008, p. 31) Modelo dimensional Como já mencionado anteriormente, existem diferenças significativas entre os dados operacionais e os dados de um Data Warehouse. Essas diferenças influenciam na forma com que os dados devem ser armazenados e, consequentemente, na modelagem da base de dados. Devido a essas diferenças, a modelagem ER (Entity Relationship), amplamente conhecida e utilizada para modelar bases de dados operacionais, não atende as necessidades

28 27 impostas pelo Data Warehouse. Para atender a essas necessidades, surgiu, então, o que se conhece como modelo dimensional, modelo multidimensional ou star schema. Segundo Goldschmidt e Passos (2005, p. 171), Existem diversas formas de modelagem física de um Data Warehouse. Uma das mais populares é a [sic] esquema estrela. Nesse esquema, a relação central de fatos é cercada por relações que correspondem às [sic] dimensões do problema. Machado (2008, p.79) define o modelo dimensional como sendo [...] uma técnica de concepção e visualização de um modelo de dados de um conjunto de medidas que descrevem aspectos comuns de negócio. O modelo dimensional, [sic] oferece clara e diretamente os elementos que se precisa para buscar as informações sobre fatos via dimensões de referências, diferindo da malha relacional, ou de rede, própria de modelos anteriores, onde [sic] não existem estruturas específicas de entrada (BARBIERI, 2001, p.35). Em vários aspectos a modelagem multidimensional é mais simples, mais expressiva e mais fácil de entender que a modelagem ER, entretanto a multidimensional é relativamente um novo conceito e ainda não tem firmeza em seus detalhes de técnicas de desenvolvimento como já tem o modele ER. (MACHADO, 2008, p. 79). No fundo, a estrutura dimensional modifica a ordem de distribuição de campos por entre as tabelas, permitindo uma formatação estrutural mais voltada para os muitos pontos de entradas específicos (as chamadas dimensões) e menos para os dados granulares em si (os chamados fatos). Isso significa que numa estrutura dimensional os dados estarão numa forma quase estelar, onde várias tabelas de entradas estarão se relacionando com algumas (poucas) tabelas de informações, criando uma notação mais sintética, legível e objetiva. (BARBIERI, 2001, p.35). Ao contrário do modelo entidade/relacionamento, o modelo dimensional é muito assimétrico. Há uma tabela dominante no centro do diagrama com múltiplas junções conectando-a às outras tabelas. Cada uma das tabelas secundárias possui apenas uma junção com a tabela central. Chamaremos a tabela central de tabela de fatos e as outras tabelas de tabelas de dimensão. (KIMBALL, 1998, p. 10). É a modelagem Dimensional de Dados, técnica de projeto que na realidade conduz os dados a uma fase, digamos cubista, onde a informação reside na interseção de várias dimensões. (BARBIERI, 2001, p.80). Segundo Barbieri (2001, p.81), O Produto final da modelagem Dimensional é a produção de um modelo conceitual dimensional, formado por tabelas Fato e tabelas Dimensão. Machado (2008, p. 79) afirma que um modelo dimensional é composto por três elementos básicos, sendo eles os fatos, as dimensões e as medidas.

29 28 A Figura 4 mostra uma ilustração de como é um modelo dimensional. Como se pode observar, ele é composto por uma (ou mais) tabela(s) fato, sendo essa(s) cercada(s) por tabelas dimensões. Por isso, esse modelo é conhecido como dimensional ou multidimensional. Outra observação que pode ser feita é que, como mencionado por Barbieri (2001, p. 35), o arranjo da tabela fato e suas dimensões lembram o formato de uma estrela e, por isso, esse modelo também é conhecido como modelo estrela ou star schema. Figura 4 - Modelo dimensional ou multidimensional, também conhecido como Star Schema Fonte: Neri (2002) apud Goldshmidt. Passos. (2005, p. 172) Após as várias definições estudadas e demonstradas acima sobre modelo dimensional e seus componentes, podemos perceber que dois desses componentes são mencionados por todos os autores, que são os denominados como tabela Fato e tabelas Dimensionais. Entretanto, há um terceiro componente descrito por Machado (2008, p. 79) que são as medidas. Esses três componentes serão explanados em seguida. Fatos: Um fato é uma coleção de itens de dados, composta de dados de medidas e de contexto. (MACHADO, 2008, p.79). Fato é tudo aquilo que pode representar um valor aditivo, ou melhor, sem academicismo, por meio de valores numéricos. (MACHADO, 2008, p.99). A tabela de fatos armazena medições numéricas do negócio. Cada uma das medições é obtida na intersecção de todas as dimensões. (KIMBALL, 1998, p.11).

30 29 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 chaves-primá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. (BARBIERI, 2001, p.81). Assim, podemos afirmar que um fato representa um assunto de interesse da organização que será objeto de análise em um sistema de BI. Em um modelo de dados, um fato é representado por uma tabela principal, cercada por tabelas auxiliares, chamadas de dimensões (que serão tratadas em seguida). Por causa dessa característica, ao olharmos a representação gráfica de uma tabela fato e de suas dimensões, temos a impressão de que se parece com uma estrela e, por isso, essa modelagem, também, é conhecida como modelo estrela (star schema). Como se pode observar, os fatos são a base de um Data Warehouse, e deve-se tomar muito cuidado na identificação dos fatos da organização que serão tratados no DW. Dimensões: As dimensões são apresentadas na Figura 4 nas pontas da estrela e ligadas a tabela fato. Conceitualmente [sic] são [dimensões] os elementos que participam de um fato, assunto de negócios. (MACHADO, 2008, p.80). As tabelas dimensionais armazenam as descrições textuais das dimensões do negócio. Cada uma dessas descrições textuais ajuda a definir um componente da respectiva dimensão. (KIMBALL, 1998, p.12). São [dimensões] as possíveis formas de visualizar os dados, ou seja, são os por dos dados: por mês, por país, por produto, por região etc.. (MACHADO, 2008, p.80). 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. 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 de sua múltipla. Devem ser entendidas como as tabelas que realizam os filtros de valores aplicados na manipulação dos dados e por onde as consultas entram no ambiente do DW/DM. (BARBIERI, 2001, p.81). Devido à grande importância das dimensões em um Data Warehouse, Machado (2008, p. 132) sugere alguns cuidados no detalhamento das dimensões. Esses cuidados são mencionados abaixo:

31 30 Remapeamento da chave para evitar a dependência da chave original. Devido à pouca duração dos registros de um OLTP em comparação com Data Warehouses, é comum reutilizar chaves. Manter a mesma chave do sistema-fonte pode ocasionar duplicidade ou inconsistências no DW. Remapear como a preocupação de reduzir chaves longas, buscando melhor performance. Gerar chaves genéricas de maneira a permitir mudanças na descrição dos itens sem haver alterações nas chaves. A solução mais comumente adotada é acrescentar dois dígitos finais indicando a versão do item. Prever chaves genéricas para descrever os fatos em tabelas de fatos agregadas (constelação). Códigos ditos inteligentes devem ser substituídos por descrições textuais, se for necessário, mantêlos associados a textos descritivos. Evite também abreviações. Por exemplo, o código SCMSB3340 deve ser associado a um texto que descreva: sapato de couro de altura média e solado de borracha, com números 33 a 40. (MACHADO, 2008, p.132). Medidas: São os valores numéricos armazenados na tabela fato. Medidas são os atributos numéricos que representam um fato, a performance de um indicador de negócios relativos às dimensões que participam desse fato. (MACHADO, 2008, p.81) ANÁLISES DE DADOS Permitir uma melhor análise de dados é o objetivo de qualquer sistema de BI. É para isso que ele serve. Todo o trabalho e demais recursos investidos na construção de implantação de um sistema de BI não teria valor algum se os dados que foram extraídos dos sistemas de OLTP e foram processados nas diversas etapas vistas até agora não pudessem ser analisados. É nessa fase que o dado se torna informação. Em seguida, serão apresentados alguns conceitos, técnicas e ferramentas referentes à análise de dados OLAP (On-Line Analytical Processing) É [OLAP] o conjunto de ferramentas que possibilita efetuar a exploração de dados de um Data Warehouse. (MACHADO, 2008, p.86).

32 31 As ferramentas OLAP são as aplicações às quais os usuários finais têm acesso para extrair os dados de suas bases e construir os relatórios capazes de responder às suas questões gerenciais. (MACHADO, 2008, p.86). Os conceitos de OLAP incluem a noção ou idéia de múltiplas dimensões hierárquicas e podem ser usados por qualquer um para que se pense mais claramente a respeito do mundo, seja o mundo material de estala atômica à escala galáctica, o mundo econômico dos micro agentes às macro economias, ou o mundo social dos relacionamentos interpessoais aos internacionais. (THOMSEN, 2002, p.5). O termo OLAP(On-line Analytical Processing), hoje, muito difundido, traduzido para Processamento Analítico On-line, representa essa característica de se trabalhar os dados, como operadores dimensionais, possibilitando uma forma múltipla e combinada de análise (THOMSEN, 2002, p.5). Abaixo, serão discutidas algumas das operações básicas que, normalmente, são executadas pelas ferramentas OLAP: Drill-Down: Segundo Machado (2008, p.87), o Drill Down ocorre quando o usuário aumenta o nível de detalhe da informação, diminuindo o nível de granularidade. Drill down can be defined as the capability to browse information, following a hierarchical structure. (FRANCOISE, REINSCHMIDT, 2000, p.13). Figura 5 - OLAP - Operação Drill-Down. Fonte: MacDonald. Rubik. (2007, p. 14). Como mostrado pela Figura 5, a operação de Drill-Down consiste em expandir os dados que estão sumarizados, de modo a exibir uma maior quantidade de detalhes. Nesse

33 32 caso, em um primeiro momento, tem-se apenas o total de candidatos e a média geral e, em seguida, temos as mesmas informações, só que por estado. Roll-Up: O Roll Up e a operação inversa ao Drill Down, sendo definido por Machado (2008, p,87), como ele [Roll Up] ocorre quando o usuário aumenta o nível de granularidade, diminuindo o nível de detalhamento da informação. Conforme citação abaixo, Francoise e Reinschmidt (2000, p.153) definem Roll- Up como sinônimo de consolidação e agregação. "Consolidação. Bases de dados Multi dimensionais geralmente possuem hierarquia, ou relacionamentos baseados em fórmulas, dos dados em cada dimensão. Consolidação envolve a computação desses relacionamentos de dados para uma ou mais dimensões, como por exemplo, somando todos os departamentos para obter todos os dados da divisão (no sentido de setor). Enquanto esses relacionamentos são normalmente somatórios, qualquer tipo de relacionamento computacional ou fórmula deve ser definido. Sinônimos: Aumento, Agregação." (FRANCOISE, REINSCHMIDT, 2000, p.153, tradução nossa). Figura 6 - OLAP - Operação Roll-Up. Fonte: MacDonald. Rubik. (2007, p. 15). Conforme mostrado pela Figura 6, a operação de Roll-Up consiste na operação inversão ao Drill-Down, onde, em um primeiro momento, têm-se as informações em um nível mais detalhado e, em seguida, essas informações são sumarizadas e apresentadas em um menor nível de detalhe.

34 33 No exemplo mostrado acima, têm-se o total de candidatos e a maior pontuação dos candidatos por estado, em seguida, essas informações são sumarizadas e é apresentado apenas o total geral. Slice and Dice: É definido por Machado (2008, p.90), como [...] operações para realizar navegação por meio dos dados na visualização de um cubo. Com relação ao significado, Machado (2008, p.90) diz Slice and dice significa em uma forma simplista a redução do escopo dos dados em análise, além de mudar a ordem das dimensões, mudando dessa forma a orientação segundo a qual os dados são visualizados. O processo de navegar, iniciado pelo usuário, através da chamada de páginas é apresentado interativamente, através da especificação de fatias via rotações e perfurações nos dois sentidos. (FRANCOISE, REINSCHMIDT, 2000, p.156, tradução nossa). Figura 7 - OLAP - Operação Slice and Dice. Fonte: MacDonald. Rubik. (2007, p. 16). Como se pode observar na Figura 7, houve uma redução no escopo dos dados que estão sendo analisados conforme mencionado por Machado (2008, p. 90). Nesse caso, em um primeiro momento temos, o número total de candidatos de sete estados e, em um segundo momento, temos as mesmas informações, porém de apenas três estados. Essa redução do escopo ou a extração de um subconjunto de dados é o que se pode definir como Slice and Dice. Pivoting: Para Machado (2008, p.93), é [pivot] o ângulo pelo qual os dados são vistos ou trocadas. Na prática, corresponde à modificação na posição das dimensões em um gráfico ou troca de linhas por colunas em uma tabela.

35 34 Figura 8 - OLAP - Operação Pivoting. Fonte: MacDonald. Rubik. (2007, p. 15). Conforme mostrado pela Figura 8, houve uma troca na posição dos campos que estão sendo visualizados. Nesse caso, apenas o ângulo pelo qual as informações são visualizadas é que foi alterado Análise Exploratória de Dados (AED) A análise exploratória de dados (AED) tem por objetivo tornar mais clara a descrição dos dados por meio da construção de indicadores, sua distribuição, comparação e análises. AED consiste em resumir e organizar os dados coletados através de tabelas, gráficos ou medidas numéricas e, a partir dos dados resumidos, procurar alguma regularidade ou padrão nas observações (interpretar os dados). A AED envolve visualização gráfica dos dados, indicadores e índices, além da procura de boas descrições de dados, a fim de ajudar ao analista a desenvolver algumas hipóteses sobre o assunto e modelos apropriados para tais dados, o que contribui para identificar padrões, comportamentos, relações e dependências. Algumas das técnicas utilizadas pela AED são: estatística descritiva; comportamento individual das variáveis; relacionamento entre variáveis.

36 35 A estatística é um conjunto de técnicas que permite, de forma sistemática, organizar, descrever, analisar e interpretar dados oriundos de estudos ou experimentos, realizados em qualquer área do conhecimento. A estatística descritiva é a etapa inicial da análise utilizada para descrever e resumir os dados através do uso de certas medidas-síntese, que tornem possível a interpretação de resultados. As principais funções da estatística descritiva são: coleta de dados, organização e classificação desses dados, apresentação, através de gráficos e tabelas, cálculo de coeficientes (estatísticos), que permitem descrever, resumidamente, os fenômenos Técnicas de mineração de dados Extração de Conhecimento de Cases de Dados é o processo de identificação de padrões válidos, novos, potencialmente úteis e compreensíveis embutidos nos dados. (FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996a apud REZENDE et al, 2003, p. 309). [...], surge uma nova área denominada Descoberta de Conhecimento em Bases de Dados (Knowledge Discovery in Databases KDD), que vem despertando grande interesse junto às comunidades científica e industrial. A expressão, Mineração de Dados, mais popular, é, na realidade, uma das etapas da Descoberta de Conhecimento em Bases de Dados. (GOLDSCHIMIDT; PASSOS, 2005, p. 2). Segundo Carvalho (2001, p.27), Tanto nos data warehouse empresariais quanto em pequenos bancos de dados pessoais, os dados a serem utilizados no datamining precisam ser preparados.. demonstradas abaixo: E essa preparação anunciada por Carvalho acontece conforme as etapas Como primeira etapa da preparação dos dados, temos a seleção. Nem todo o data warehouse precisa ser vasculhado pelas ferramentas do datamining. Em muitas situações, o fenômeno estudado está registrado apenas em uma parte da grande massa de dados existente, enquanto em outros casos nem todos os campos de informação de cada registro precisam ser considerados. Tanto a limitação da massa de dados a ser explorada quanto a redução do número de variáveis consideradas na análise são fatores importantes, pois tornam o processo de mineração de dados mais eficiente e eficaz. Estes dois processos são realizados com base no sentimento do analista ou em técnicas estatísticas. (CARVALHO, 2001, p.27). Para segunda etapa de preparação de dados, podemos observar o seguinte conceito sobre a denominada complementação:

37 36 Em qualquer massa de dados, é extremamente comum a existência de elementos ausentes por falha de digitação, erros de preenchimento de formulários, ou mesmo porque os registros pertencem a empresas ou épocas diferentes nas quais aquele dado em específico não era questionado ou considerado importante. No entanto, para a utilização de certas ferramentas do datamining, precisamos de registros com todos os dados (variáveis do problema) devidamente valorados, não se admitindo campos em branco. Para complementarmos os dados, podemos simplesmente assumir que um valor padrão, definido a priori, será considerado para fins de análise de ferramenta de datamining. (CARVALHO, 2001, p.27,28). seguinte conceito: Chegamos à terceira etapa da preparação, eliminação de registros, e abstraímos o Finalmente, a etapa de preparação dos dados pode ainda contar com processos de eliminação de registros cujos dados pareçam errados ou não representativos do fenômeno em questão, além da eliminação de ruído que de alguma forma tenha sido adicionado ao dado. Estes processos são realizados por técnicas específicas de Estatística ou Inteligência Artificial, de novo, em um datamining prévio ao datamining final e desejado. (CARVALHO, 2001, p.28). Após listarmos as etapas necessárias para preparação de dados propostas por Carvalho, vamos citar o protocolo de implantação proposto por ele: Inicialmente, a primeira etapa de nosso protocolo é definir com precisão o problema a ser estudado ou o objetivo a ser alcançado. Esta etapa tem profundas conseqüências metodológicas, pois se o problema a ser estudado é bem conhecido em suas relações, a metodologias será a modelagem de dados. Por outro lado, se pouco se sabe sobre o problema, mas tem-se um sentimento de suas relações, a metodologia apropriada é a testagem de hipótese. Finalmente se nada se sabe sobre o problema ou mesmo não se tem problema, a metodologia correta é descoberta não supervisionada de conhecimento. (CARVALHO, 2001, p.28,29). Carvalho, temos: Continuando o entendimento sobre as fases do protocolo mencionado por Em sequência, a segunda fase, a descoberta das relações por uso das técnicas de datamining, tem conseqüências importantes, pois aqui se requer conhecimento razoável das técnicas (classificação, estimação, previsão, etc.) aplicáveis e das ferramentas (redes neuronais artificiais, árvore de decisão, algoritmo genéticos, etc.) capazes de executá-las. Após a escolha da técnica e da ferramenta em função do problema estudado, é preciso realizar a etapa operacional de preparação de dados, selecionando-os, escolhendo as variáveis importantes, complementando-os e eliminando aqueles dados considerados espúrios. Só após estas etapas, inicia-se a aplicação do datamining propriamente dito e cujo resultado é a geração de um conjunto de relações novas descobertas mecanicamente. (CARVALHO, 2001, p.29). É preciso, agora, que uma equipe de analistas humanos estude as novas relações e separe aquelas que fazem sentido. É nesta hora que o datamining é reduzido a mero

38 37 instrumento, enquanto a inteligência humana continua suprema no processo decisório. (CARVALHO, 2001, p.29). E, ao fim das etapas expressadas, temos a seguinte citação: Finalmente, faz necessária a etapa de avaliação na qual os resultados da aplicação, ou explicação, das novas relações escolhidas são contrapostos aos objetivos iniciais da primeira etapa. (CARVALHO, 2001, p.29). Com relação às técnicas de Análise Exploratória de Dados, Barbieri (2001) cita cinco delas que serão abordadas em seguida. Árvore de Decisão: A árvore de decisão é uma técnica que, a partir de uma massa de dados, cria e organiza regras de classificação e decisão em formato de diagrama de árvores, que irão classificar suas observações ou predizer resultados futuros. (BARBIERI, 2001, p.190). Análise de Conglomerados: O objetivo da Análise de Conglomerados é identificar a existência de diferentes grupos dentre de um conjunto de dados e, constatada esta existência, agrupar os elementos estudados de acordo com as semelhanças entre si, considerando-se as características analisadas. (BARBIERI, 2001, p.196). Redes Neurais: Essa não é exatamente uma técnica estatística, mas sim um recurso matemático/computacional que pode ser usado na aplicação destas. (BARBIERI, 2001, p.189). As Redes Neurais são uma tecnologia cada vez mais usada em Data Mining. Sua grande vantagem está basicamente em sua habilidade de aprendizagem a partir das experiências, não ficando restritas a uma ordem seqüencial pré-fixada. Elas consistem em algoritmos e procedimentos computacionais que imitam a capacidade de aprendizagem do cérebro. (BARBIERI, 2001, p.199). Análise de Regressão: A Análise de Regressão processa as informações de uma base e dados de maneira a determinar um modelo (uma equação) que representa o relacionamento existente entre as variáveis em estudo. Os principais objetivos da análise de regressão são: sumarização dos dados, predição, controle e estimação. Uma só análise pode atender a mais de um objetivo ao mesmo tempo. (BARBIERI, 2001, p.204). Séries Temporais: Séries Temporais é uma técnica estatística utilizada principalmente no cálculo de previsão de um conjunto de observação, dados seus valores ao longo do tempo. O que faz esta técnica tão especial é a possibilidade de considerar, na analise, a sazonalidade ou ciclos intrínsecos ao processo, utilizando-os na predicação de

39 38 valores futuros de série em questão ou na investigação de seu mecanismo gerador. (BARBIERI, 2001, p.208) CONSIDERAÇÕES FINAIS DO CAPÍTULO O próximo capítulo tratará da elaboração de uma proposta de solução para o problema apresentado no item 1.1, que atende ao objetivo geral deste trabalho descrito no item Objetivo Geral, aos objetivos específicos definidos no item Objetivos específicos e que siga as idéias dos autores da área sobre cada assunto estudado na revisão bibliográfica apresentada neste capítulo.

40 39 3. MÉTODO CARACTERIZAÇÃO DO TIPO DE PESQUISA Do ponto de vista da natureza, este trabalho pode ser considerado como uma pesquisa aplicada, pois tem como objetivo gerar conhecimento dirigido à solução de um problema específico através do desenvolvimento prático de toda uma arquitetura de BI. Do ponto de vista da forma de abordagem, este trabalho se classifica como uma pesquisa quantitativa, pois procura traduzir os fatos ocorridos em um ambiente de produção em números e a utilização de técnicas de estatísticas para a análise de identificação de tendências. Do ponto de vista de seus objetivos, este trabalho se classifica como uma pesquisa exploratória, pois visa a uma maior compreensão dos problemas e demais fatos ocorridos em um ambiente de produção através da análise de dados, bem como uma pesquisa bibliográfica das definições e conceitos que envolvem a área, escritos pelos principais autores no assunto. Do ponto de vista dos procedimentos técnicos, este trabalho pode ser classificado de duas formas: Primeiro, como uma pesquisa bibliográfica, pois como já mencionado anteriormente, envolve uma pesquisa dos conceitos, definições e idéias dos principais autores na área. Segundo, como um estudo de caso, pois busca fazer uma análise mais profunda em um conjunto restrito de dados de forma a detalhar ao máximo as tendências e comportamentos encontrados ETAPAS METODOLÓGICAS Este trabalho divide-se nas seguintes atividades e etapas:

41 40 A. marco teórico do trabalho, que consiste na definição do problema, a revisão bibliográfica dos itens de conhecimento abordados e da solução proposta. Esta atividade foi dividida nas seguintes etapas: 1. elaboração do capítulo 1, em que se definem itens como a introdução, problema a ser resolvido, os objetivos e a justificativa que levaram à criação deste trabalho; 2. a realização de uma pesquisa bibliográfica em que foram levantados os conceitos e as idéias dos principais autores nos assuntos que envolvem este trabalho, sendo que o resultado desta pesquisa se encontrará no capítulo 2; 3. a elaboração de uma proposta de solução para o problema proposto e a definição das delimitações do projeto, que são apresentados como parte do capítulo 3. B. desenvolvimento da arquitetura de BI proposta, que consiste na definição do modelo dimensional lógico e físico ao ambiente de carga, extração e transformação, e ao ambiente de análises de dados. Esta atividade foi dividida nas seguintes etapas: 1. o mapeamento dos arquivos de log que compõem a base de dados que contêm os dados que serão objeto de análise deste trabalho, documentando-se o resultado dessa análise; 2. realizar um estudo para a definição do período de dados que serão analisados, visando a prever o tamanho das bases de dados a serem criadas, bem como o tempo que os dados permanecerão disponíveis, caso esse sistema seja colocado em produção; 3. a modelagem e posterior criação de uma base de dados relacional (ODS), para armazenamento temporário dos dados levantados no item anterior; 4. a partir do mapeamento dos arquivos de log e da criação da base de dados temporária, criar os scripts de carga e exclusão, na base, de backup dos arquivos originais e execução dos scripts de carga; 5. realização de um estudo para definir o período de dados que será mantido na base de dados;

42 41 6. modelar e, posteriormente, criar uma base de dados multidimensional para o Data Warehouse, levando-se em consideração todas as regras de modelagem dimensional e de construção de um Data Warehouse; 7. criação e execução dos scripts de carga dos dados da base temporária (ODS), para a base de dados do Data Wharehouse, a execução desses scripts e a criação dos scripts de exclusão desses dados. C. análises de dados sobre os dados carregados no repositório, que consiste na escolha dos métodos de análises, na interpretação dos resultados a nas conclusões de tais análises. Esta atividade foi dividiaa nas seguintes etapas: 1. aealizar um estudo de ferramentas, técnicas e algoritmos de OLAP e Data Mining a serem aplicados nos dados presentes no Data Warehouse; 2. aplicação das ferramentas, técnicas e algoritmos levantados no passo anterior e a geração de relatórios; 3. análise, apresentação e interpretação dos resultados DELIMITAÇÕES Neste trabalho será construído um sistema de BI para análise de logs de transmissão. Para este trabalho, apesar de existirem outras fontes de dados, os arquivos de log serão a única fonte utilizada, sendo que o período de logs a serem analisados será de seis meses. Com relação às ferramentas, a definição de quais serão utilizadas ainda será definida, no entanto, tem-se como objetivo a utilização de duas ferramentas para a execução de cada tarefa, de forma a ter-se um comparativo entre prós e contras dos recursos disponibilizados por cada ferramenta.

43 42 4. DESENVOLVIMENTO DA SOLUÇÃO Este capítulo trata da solução desenvolvida para resolver o problema descrito no item 1.1 e atingir os objetivos descritos nos itens Objetivo Geral e Objetivos específicos ARQUITETURA DA SOLUÇÃO Durante a pesquisa, foi possível encontrar uma série de arquiteturas diferentes, de acordo com cada autor e com cada contexto em que a arquitetura de BI estava sendo aplicada. Dessa forma, para este trabalho, optou-se pela elaboração de uma arquitetura própria que é mostrada na Figura 9. Figura 9 - Arquitetura de um sistema de BI - Solução Fonte: Os autores. individualmente. Nos itens a seguir, cada componente da Figura 9 acima será descrito

44 ESTRUTURAS DE DADOS UTILIZADAS deste trabalho. Aqui, serão apresentadas as estruturas de dados utilizadas no desenvolvimento OLTP (Online Transaction Processing) Para este trabalho, nossa base OLTP serão arquivos de textos que contêm registros das comunicações efetuadas. Esses registros são gerados por uma única aplicação, porém, como existem outras aplicações que também geram o mesmo tipo de informação, está sendo considerada a possibilidade de, posteriormente, incluir os registros destas aplicações em nossa arquitetura de BI. Por causa disso, a figura mostra o item Fontes de dados futuras, como parte de nosso OLTP. Para este trabalho, foi necessário realizar um levantamento dos registros encontrados nos arquivos de log, bem como sua relevância e quais informações estão presentes em cada um desses registros. Esse levantamento é apresentado no item Mapeamento dos registros de log (base OLTP) ODS (Operational Data Storage) Aqui, o ODS é uma base de dados relacional, que tem como objetivo armazenar, temporariamente, os registros de log tratados pela primeira camada de ETL ( ETL1 (Extract, Transform and Load)). Nesse ponto, o único tratamento recebido pelos registros são os descritos na especificação da primeira camada de ETL. Essa base é considerada temporária por seus únicos objetivos que são o de integrar dados de várias fontes (isso pensando no futuro, pois, para este trabalho, temos

45 44 apenas uma fonte de dados), e facilitar o trabalho da segunda camada de ETL2 que será descrita no item ETL2 (Extract, Transform and Load), sendo que seus dados serão excluídos assim que a mesma estiver concluída. Figura 10 - Base de dados ODS Fonte: Os autores A Figura 10 mostra a imagem da modelagem ER da base de dados desenvolvida para ser o ODS mostrado na Figura 9. Como se pode observar, apesar de se ter utilizado os conceitos da modelagem relacional (ER), a imagem do modelo desta base lembra o modelo estrela apresentado no item Modelo dimensional. Isso ocorre porque coincidentemente ela possui uma tabela

46 45 central (Operações), que é rodeada pelas tabelas que armazenam os detalhes de cada operação, porém trata-se de uma base relacional e não multi-dimensional. Como já mencionado anteriormente, existe uma série de operações que são registrados nos arquivos de log (nossa base OLTP), porém, para este trabalho foram consideradas somente as operações mais relevantes, sendo que a lista das operações escolhidas está descrita no item Mapeamento dos registros de log (base OLTP) Cada operação selecionada é representada por uma tabela de detalhes, sendo que todos os dados comuns a todas as operações (descritos no item Parte fixa do registro ), são armazenados na tabela Operações, exceto pelos dados de clientes e usuários que ficam em uma tabela separada. Ao observar a Figura 10, pode-se notar um quadro de observações em que consta o código para a criação de um índice e de uma view, ambos para a tabela de operações. Esses dois itens foram criados para acelerar a execução do segundo nível de ETL, descrito em ETL2 (Extract, Transform and Load). O dicionário de dados dessa base encontra-se em APÊNDICE A Dicionário de dados da base ODS e o script para sua criação em APÊNDICE B Script SQL para a criação da base ODS Data Warehouse O item DATA WAREHOUSE, fala sobre os conceitos e definições de Data Warehouse. Nesse caso, o Data Warehouse é composto por um backup dos arquivos de log originais e de uma base de dados multi-dimensional, mostrada na Figura 11, que poderá ser acessada por qualquer ferramenta que permita fazer consulta a banco de dados, sendo que esses dados já estão devidamente validados, organizados e sumarizados pelos processos anteriores. Para este trabalho, foram identificados dois fatos, o fato transferência, que ocorre cada vez que um arquivo é trocado entre os usuários do sistema, e o fato conexões, que ocorre cada vez que uma nova conexão é estabelecida ou quando há uma tentativa de se estabelecer uma conexão.

47 46 Para facilitar a análise e devido ao número elevado de registros, esses dois fatos foram divididos em dois níveis de granularidade com relação ao tempo, quando no primeiro nível, os dados serão sumarizados por dia e, no segundo nível, por hora. Os fatos do primeiro nível (diário) são representados na Figura 11 pelas tabelas Fato_Transferencia_Dia [sic] e Fato_Conexoes_Dia [sic], sendo que essas tabelas contêm os dados referentes aos seis messes de log que fazem parte do escopo deste trabalho. Nesse nível, serão feitas análises de escopo diário durante um determinado mês e sua relação com dados diários de outros meses, bem como, análises de escopo mensal. Nas análises desse nível, também, será prevista a inclusão de análises anuais, prevendo uma possível continuidade da carga e evolução do sistema. Esse nível de granularidade possui sua própria dimensão tempo, representada pela tabela Dimensao_Tempo_Dia [sic]. Os fatos do segundo nível (hora) são representados na Figura 11 pelas tabelas Fato_Transferencia_Hora [sic] e Fato_Conexoes_Hora [sic], sendo que, pelo maior número de registros, essas tabelas contêm os dados de log referentes, apenas, ao mês mais atual que faz parte do escopo deste trabalho, que nesse caso é o mês de junho de Nesse nível de granularidade serão realizadas análises das operações em cada hora do dia e comparações dos dados de cada horário entre os dias do mês em questão. A exemplo do nível de granularidade diário, esse nível, também, possui uma dimensão de tempo própria, que é representada pela tabela Dimensao_Tempo_Hora [sic]. Como mencionado acima, cada nível de granularidade possui duas tabelas fatos e cada nível possui sua própria tabela de dimensão tempo, sendo que as demais dimensões, Dimensao_Usuario [sic], Dimensao_Interface [sic] e Dimensao_Produto [sic] são compartilhadas pelos dois níveis de granularidade, sendo que as duas primeiras dimensões são compartilhadas pelas quatro tabelas fato e a Dimensao_Produto [sic] pelas tabelas Fato_Transferencia_Dia [sic] e Fato_Transferencia_Hora [sic]. O motivo para a Dimensao_Produto [sic] ser compartilhada apenas pelas tabelas fato de transferência é que o produto é determinado pelo nome e conteúdo do arquivo e dessa forma não é possível estabelecer um produto no momento da conexão. Além disso, em uma mesma conexão pode haver a transferência de arquivos de mais de um produto, o que também impossibilita a atribuição de um produto para a conexão. Outra observação importante a ser feita, com relação a Dimensao_Produto [sic], é que a definição de a qual produto um determinado arquivo pertence depende de uma série de regras de negócio e de processos que não estão inclusos neste trabalho. Dessa forma, a Dimensao_Produto [sic] foi inserida na modelagem, apenas, para indicar que, futuramente,

48 47 pode-se adicionar tais regras e processos no sistema tornando a identificação do produto ao qual o arquivo pertence possível. Assim, essa tabela terá apenas um registro de produto denominado Produto1. Figura 11 - Data Mart de comunicação Fonte: Os autores. Apesar da maioria dos autores tratar o Data Warehouse como sendo um conjunto de bases de dados, para este trabalho optou-se por considerar os backups dos arquivos originais como parte integrante do Data Warehouse. Essa decisão foi tomada, dada à importância dessa fonte de dados que, fazendo uma analogia com a medicina, pode-se considerar como a célula tronco do sistema de BI. Hoje, mesmo sem nenhuma garantia de que terão alguma doença em que a célula tronco será necessária, muitas pessoas pagam para que o cordão umbilical de seus filhos seja congelado e armazenado em local seguro, pois, caso necessitem desse material, será de suma importância, compensando, assim, o custo do investimento feito inicialmente. Da mesma forma em um sistema de BI, uma vez que os dados estiverem disponíveis no Data Mart e passado o prazo em que são úteis aos sistemas de OLTP,

49 48 dificilmente, serão úteis, porém, como defendido por vários autores, o período de armazenamento dos dados de um Data Warehouse fica entre 5 e 10 anos, e, como tudo que envolve tecnologia, evolui muito rapidamente, não será nenhuma surpresa se nesse período surgir alguma nova técnica de análise de dados que possa ser considerada uma vantagem competitiva e que necessite dos dados originais. Assim, caso essa técnica realmente surja, o fato de se ter os arquivos originais pode nos dar uma vantagem de 5 a 10 anos sobre os concorrentes, compensando o custo do armazenamento desses dados. Os backups não estarão disponíveis para consulta e estarão armazenados em mídias alternativas e mais baratas, sendo que o acesso a eles se dará em situações extremas, quando os dados contidos no modelo dimensional não forem suficientes EXTRAÇÃO TRANSFORMAÇÃO E CARGA DOS DADOS Neste item será, apresentado tudo o que foi desenvolvido para transformar os dados brutos da base OLTP em dados sumarizados e inseridos no Data Mart de comunicação Mapeamento dos registros de log (base OLTP) Cada registro (linha) nos arquivos de log a serem analisados é composto por duas partes distintas, sendo a primeira parte composta por campos de tamanho fixo, comuns a todos os registros, e a segunda parte composta por campos separados por vírgula, em que a quantidade de campos é variável de acordo com o tipo do registro. Todo registro termina com uma quebra de linha, e, portanto, está correto dizer que cada linha do arquivo corresponde a um registro. Como já mencionado anteriormente, existe uma série de operações que são registrados nos arquivos de log (nossa base OLTP), porém, para este trabalho, foram consideradas somente as operações consideradas mais relevantes, sendo elas os inícios e finais de sessão, as sessões abortadas, as transmissões e recepções de arquivos, as sessões abortadas, os sinais enviados pelo sistema operacional e recebidos pelo processo de

50 49 comunicação, as tentativas de conexão com senha inválida e os envios de arquivos para a quarentena (área temporária que tem como função armazenar arquivos que tiveram algum problema em seu processamento e na espera por uma intervenção humana) Parte fixa do registro Esta primeira parte do registro é composta por campos de tamanho fixo, cuja estrutura é comum a todos os registros, independente da operação que foi registrada. Abaixo, segue um melhor detalhamento de cada campo que compõe essa primeira parte do registro de log: Nome do campo Timestamp PID Código da operação Nome usuário do Descrição Indica a data e hora em que o evento representado pelo registro ocorreu. O valor deste campo representa a quantidade de segundos passados a partir de 01/01/1998, sendo apresentado em hexadecimal nos oito primeiros caracteres do registro. Identificador do processo que executou a operação representada pelo registro. Contém quatro caracteres representados em hexadecimal. Representa o código da operação que foi executada e é através desse campo que se pode prever quais campos variáveis o registro contém. O detalhamento dos campos variáveis para cada operação será apresentado em seguida. Contém o nome do usuário que executou a operação. Este campo possui tamanho variável e seu final é determinado por uma vírgula. Pode também conter o nome do cliente e, nesse caso, o nome do cliente é separado do nome do usuário por um ponto, sendo que o nome do cliente estará sempre à esquerda. A única exceção a essa regra é o registro de código 1020 (Arquivo enviado a quarentena), cuja especificação será descrita mais adiante. Apesar desse campo não ter um tamanho fixo, ele foi apresentado aqui porque sua posição inicial é comum a todos os registros. Quadro 2 - Campos comuns para todas as operações. Fonte: Os autores.

51 Parte variável do registro A segunda parte do registro é composta por campos de tamanho variável, separados por vírgula, em que a quantidade de campos, suas posições e quais campos estão presentes no registro varia de acordo com o tipo do registro que foi definido no campo Código da operação na parte fixa do registro. Os itens, a seguir, darão um melhor detalhamento de cada campo que compõe essa segunda parte do registro de log de acordo com cada operação Início de sessão (1021 e 1050) Esta operação ocorre cada vez que um usuário é autenticado com sucesso no sistema, sendo que esta operação é representada por dois códigos distintos, sendo eles o 1021 e o 1050, sendo que a diferença entre eles se resume na quantidade de campos presentes nos registros de cada tipo, devido às várias versões do protocolo de comunicação em operação atualmente. A seguir, mostra-se uma descrição dos campos presentes em cada um dos códigos que representa esta operação: Operação 1021: Nome do campo Operação Interface Origem Descrição Operações que serão executadas durante a comunicação, que pode ser TA para transmissão automática, RA para recepção automática, ou TR para transmissão e recepção. Identifica a o endereço utilizado pelo cliente para conectar-se com o servidor. Esse endereço é composto por um endereço IP ou por um domínio, e a porta de comunicação que o servidor está ouvindo. Identifica o endereço IP do computador do cliente que está estabelecendo a conexão. Quadro 3 - Campos exclusivos da operação de início de sessão código Fonte: Os autores. Operação 1050:

52 51 Nome do campo Origem Descrição Identifica o endereço IP do computador do cliente que está estabelecendo a conexão. Quadro 4 - Campos exclusivos da operação de início de sessão código Fonte: Os autores Sessão abortada (1023) Esta operação ocorre cada vez que ocorre algum problema que aborta a comunicação e é representada pelo código Geralmente, esse tipo de problema ocorre quando há uma queda na comunicação, quando o computador do cliente trava ou quando a comunicação é cancelada pelo cliente. O Quadro 5 mostra a lista de campos pertencentes a esta operação e sua descrição. Nome do campo Qualidade da comunicação Descrição Define a qualidade da comunicação. Este campo contém primeiro um percentual que define a qualidade da comunicação, seguido pelos campos de AK, NAK e timeouts conforme descrito no código Quadro 5 - Campos exclusivos da operação de sessão abortada código Fonte: Os autores Transmissão (1003 e 1004) Esta operação ocorre cada vez que um arquivo é transmitido com sucesso no sentido cliente para o servidor e é representada pelos códigos 1003 e A seguir, mostra-se uma descrição dos campos presentes em cada um dos códigos que representa esta operação: Operação 1003: Nome do campo Usuário destino Descrição Usuário para o qual foi transmitido o arquivo. Normalmente, o nome do cliente não está presente neste campo, porque na grande maioria dos casos só existe transmissão entre usuários do mesmo cliente e, dessa forma, o nome do cliente já foi especificado no campo usuário de

53 52 Nome do arquivo na origem Tamanho do arquivo Nome do arquivo de destino origem. Contém o nome original do arquivo que foi transmitido, sendo que este pode ter sido renomeado após a transmissão. Tamanho do arquivo em bytes Contém o nome completo com o qual o arquivo foi armazenado no servidor. Caso o arquivo não seja renomeado durante a transmissão, esse campo terá como valor o path do diretório onde o arquivo será armazenado mais o mesmo valor do campo Nome do arquivo na origem. Quadro 6 - Campos exclusivos da operação de transmissão código Fonte: Os autores. Operação 1004: Nome do campo Usuário destino Nome do arquivo na origem Nome do arquivo de destino Tamanho do arquivo Path parcial do arquivo Descrição Usuário para o qual foi transmitido o arquivo. Normalmente, o nome do cliente não está presente neste campo, porque na grande maioria dos casos só existe transmissão entre usuários do mesmo cliente. Assim, o nome do cliente já foi especificado no campo usuário de origem, caso contrário, o nome do cliente é separado do nome do usuário por um ponto, sendo que o nome do cliente estará sempre à esquerda. Contém o nome original do arquivo que foi transmitido, sendo que esse pode ser renomeado após a transmissão. Contém o nome com o qual o arquivo será armazenado no servidor. Caso o arquivo não seja renomeado durante a transmissão, esse campo terá o mesmo valor do campo Nome do arquivo na origem. Tamanho do arquivo em bytes. Contém o diretório em que o arquivo foi armazenado no servidor a partir do diretório home do serviço, mais o nome do arquivo de destino, contido no campo Nome do arquivo de destino. Quadro 7 - Campos exclusivos da operação de transmissão código Fonte: Os autores Recepção (1051) Esta operação é representada pelo código 1051 e ocorre cada vez que um arquivo é recebido com sucesso pelo usuário cliente, ou seja, o arquivo foi transmitido do servidor para o cliente. O Quadro 8 mostra a lista de campos pertencentes a esta operação, e sua descrição.

54 53 Nome do campo Nome do arquivo Tamanho do arquivo Usuário origem Descrição Identifica o nome do arquivo que foi recebido. Esse nome representa o nome com que o arquivo foi armazenado no servidor, porém, esse arquivo pode ser renomeado na ponta do cliente após a recepção. Representa o tamanho do arquivo em bytes. Contém o nome do usuário que enviou o arquivo. Normalmente o nome do cliente não está presente neste campo porque na grande maioria dos casos só existe transmissão entre usuários do mesmo cliente. Sendo assim, o nome do cliente já foi especificado no campo usuário de origem, caso contrário, o nome do cliente é separado do nome do usuário por um ponto, sendo que o nome do cliente estará sempre à esquerda. Quadro 8 - Campos exclusivos da operação de recepção de arquivos código 1051 Fonte: Os autores Sinais (1013) Esta operação é representada pelo código 1013 e ocorre cada vez que o processo no servidor que está tratando da comunicação recebe um sinal do sistema operacional. Em linux, esses sinais estão definidos no arquivo signal.h. O Quadro 9 mostra a lista de campos pertencentes a esta operação, e sua descrição. Nome do campo Sinal Descrição Sinal do sistema, recebido pelo processo que executou a operação. Quadro 9 - Campos exclusivos da operação de recepção de sinais código Fonte: Os autores Senha inválida (1026) Esta operação é representada pelo código 1026 e ocorre sempre que o usuário erra a senha ao tentar conectar-se ao sistema. O Quadro 10 mostra a lista de campos pertencentes a esta operação e sua descrição. Nome do campo Origem Descrição Identifica o endereço IP do computador do cliente que está estabelecendo a conexão. Quadro 10 - Campos exclusivos da operação de senha inválida código Fonte: Os autores.

55 Envio de arquivos para a quarentena (1020) Esta operação é representada pelo código 1020 e ocorre quando um arquivo foi transmitido do cliente para o servidor, mas ocorreu algum problema que impediu que esse arquivo fosse entregue ao destinatário (usuário destino), o que faz com que o arquivo seja enviado a uma área separada para que possa ser analisado. Existe uma série de problemas que podem gerar esse tipo de comportamento, como, por exemplo, a transmissão de um arquivo para um usuário inexistente. O Quadro 11 mostra a lista de campos pertencentes a essa operação e sua descrição. Nome do campo Usuário destino Nome do arquivo Tamanho do arquivo Nome do arquivo na quarentena Motivo Descrição Usuário para o qual foi transmitido o arquivo. Normalmente, o nome do cliente está presente neste campo. Esse é o único registro em que o nome do cliente está no usuário de destino, sendo que o padrão de nomes se mantém sendo primeiro o nome do cliente seguido por um ponto e pelo nome do usuário. Nome do arquivo que foi enviado para a quarentena. Tamanho do arquivo em bytes. Contém o nome completo do arquivo após ser armazenado na quarentena. Esse nome é composto pelo diretório da quarentena seguido pelo nome do arquivo, um $, o nome do cliente e do usuário que transmitiu o arquivo, separados por um ponto e, finalmente, um ponto e alguns caracteres aleatórios que servem para evitar que um arquivo seja sobrescrito. Uma string que descreve o motivo pelo qual o arquivo foi enviado a quarentena. Quadro 11 - Campos exclusivos da operação de envio para a quarentena código Fonte: Os autores Final de sessão (1016 e 1024) Esta operação ocorre sempre que uma conexão foi finalizada com sucesso e é representada pelos códigos 1016 e 1024 A seguir, mostra-se uma descrição dos campos presentes em cada um dos códigos que representa esta operação: Operação 1016:

56 55 Nome do campo AK NAK Timeouts Interface Descrição Quantidade confirmações de pacotes recebidas pelo servidor. Quantidade de confirmações de pacotes com problema, recebidas pelo servidor. Quantidade de timeouts de pacotes ocorridos durante a comunicação. Identifica a o endereço utilizado pelo cliente para conectar-se com o servidor. Esse endereço é composto por um endereço IP ou por um domínio e, opcionalmente, a porta de comunicação que o servidor está ouvindo. Quadro 12 - Campos exclusivos da operação de final de sessão código Fonte: Os autores. Operação 1024: Nome do campo Qualidade de comunicação Interface Descrição Define a qualidade da comunicação. Esse campo contém primeiro um percentual que define a qualidade da comunicação, seguido pelos campos de AK, NAK e timeouts conforme descrito no código Identifica a o endereço utilizado pelo cliente para conectar-se com o servidor. Esse endereço é composto por um endereço IP ou por um domínio e, a porta de comunicação que o servidor está ouvindo. Quadro 13 - Campos exclusivos da operação de final de sessão código Fonte: Os autores ETL1 (Extract, Transform and Load) Esta primeira camada de ETL é responsável pelas seguintes operações: 1. leitura dos arquivos de log (OLTP): Como já mencionado, os arquivos de origem estão no formato texto e cada linha representa um registro. Esses registros devem ser lidos e tratados; 2. quebra dos registros em campos: Cada registro encontrado no arquivo de log pode ser dividido em duas partes, sendo que cada uma dessas partes possui vários campos. A descrição do formato dos registros, bem como de cada campo que o compõe, encontra-se no item Mapeamento dos registros de log (base OLTP) ; 3. tratamento e validação dos registros: Como mencionado no item Mapeamento dos registros de log (base OLTP), os campos da primeira

57 56 parte de cada registro está em hexadecimal, sendo, então, necessária (ou pelo menos aconselhável) a conversão desses campos para o sistema decimal de modo a facilitar a leitura e análise. Além disso, o campo timestamp precisa ser convertido para o sistema adotado pelos computadores que conta o tempo a partir de 01/01/1970, para facilitar as análises que serão feitas posteriormente. Já a segunda parte do registro necessita de uma série de validações que vão depender do código da operação, porém, em geral, essas validações ficaram restritas a tipagem da informação contida no campo. Um outro cuidado que precisa ser tomando, nesse momento, refere-se à integridade do registro, sendo necessária uma verificação para checar se o arquivo não está quebrado e se possui todos os campos que deveria; 4. inserção dos registros na base de dados: Após a extração do registro e sua validação, conforme descrito acima, ele deve ser inserido em uma base de dados relacional, que representará o ODS do sistema. Essa base é mostrada no item ODS (Operational Data Storage) ; 5. backup dos arquivos originais: Deve ser feito um backup de todos os arquivos de log utilizados nessa carga. Os procedimentos de backup já existem no ambiente atual de produção, porém devem ser considerados como parte do Data Warehouse de modo a agregar valor e importância a essa informação.

58 57 Figura 12 - ETL1 desenvolvido no Kettle Spoom Fonte: Os autores. A Figura 12, mostra a solução construída para o ETL1. Essa solução foi desenvolvida na ferramenta Spoon da Pentaho Corporation. Como se pode observar, a transformação foi desenhada de modo a lembrar a figura de uma árvore, de onde os dados brutos são extraídos do solo (nesse caso dos arquivos de logs que contêm a base OLTP), são transmitidos e processados no interior da planta até

59 58 se transformar no fruto, que, nesse caso, é o registro gravado com sucesso na base ODS. Outro detalhe importante é que o caule é responsável pelo processamento da parte fixa do registro ( Parte fixa do registro) e a copa pela parte variável ( Parte variável do registro). A transformação começa pelo componente Transf de entrada, que é responsável por ler os registros dos arquivos de log, e uma cópia de cada registro é encaminhada para os componentes Elimina operações e Monta nome arquivo. O componente Monta nome arquivo é a base do ramo que faz o backup do arquivo original lido pelo componente Transf de entrada em outro diretório. Já o componente, Elimina operações, é responsável por selecionar os registros que serão processados ou não. Caso o registro não deva ser processado, ele será encaminhado para o componente chamado Limbo, responsável por eliminar os registros indesejados. Essa seleção é feita pelo código do registro e é especificada no item Mapeamento dos registros de log (base OLTP). Outro ponto importante localiza-se onde está o componente Sequencia cd_operacao [sic]. Esse componente se conecta na base de dados e busca o valor da sequence qual código com que a operação será armazenada na base. Esse código é a chave primária da tabela Operacoes" [sic] e será usado como chave estrangeira nas demais tabelas. Além disso, esse componente divide o processamento em dois ramos, em que uma cópia do registro é enviada ao ramo que irá gravar o registro na tabela de operações e outra para o componente Swith Operações, que é a base da copa. O componente Swith Operações recebe todos os registros vindos do caule e os distribui de forma que cada registro seja processado por seu ramo. Além disso, ele, também, está ligado ao componente Limbo Operações, que foi colocado, apenas, para não quebrar a semântica do componente Swith Operações, que possui uma propriedade para se definir um caminho padrão. Para executar essa transformação, basta configurar os arquivos a serem processados no componente Transf de entrada e clicar no botão Run. O Quadro 14 mostra a quantidade de resgistros contidos em cada tabela da base relacional após o termino da importação dos dados da base ODS. A carga dos dados foi feita em pequenas partes, e os logs de execução não foram adicionados a este trabalho devido ao seu tamanho e ao fato de agregarem pouco valor.

60 59 Nome da tabela Quantidade de registros Usuarios [sic] Sessoes_Abortadas [sic] Sinais Inicios_Sessao [sic] Finais_Sessao [sic] Senhas_Invalidas [sic] 2747 Quarentena Transmissoes [sic] Recepcoes [sic] Operacoes [sic] Quadro 14 - Quantidade de registros na base ODS após a execução completa do ETL1. Fonte: Os autores ETL2 (Extract, Transform and Load) Essa camada de ETL tem por objetivo classificar e sumarizar os dados presentes no ODS e inseri-los no Data Mart de comunicação no Data Warehouse. Neste ponto, deve-se considerar que os dados contidos no ODS estão íntegros cabendo, então, a essa camada a tradução dos dados contidos na base relacional (ODS), para a base multi-dimensional de comunicação (Data Mart), levando-se em consideração a granularidade do Data Mart, e, também, que o período de tempo de cada amostra será de 1 hora para as tabelas fato hora e de 1 dia para as tabelas fato dia. A Figura 13 mostra a transformação desenvolvida e executada para a carga no Data Mart. Como se pode observar, a transformação começa pelo componente Tabela operações. Esse componente é responsável por selecionar todos os registros da tabela de operações da base de dados ODS, mostrada na Figura 10, ordenado pelos campos ano, mes [sic], dia, hora, minuto e segundo. Após a leitura inicial da base ODS, uma série de passos é executada para processar os registros e efetuar a carga nas dimensões, sendo que o final dessa serie de passos é marcada pelo componente Busca cd_tempo_hora e por uma nota com a observação Aqui termina a carga das dimensões. Quando um registro chega a esse ponto, todos os dados das

61 60 dimensões referentes a esse registro já estão devidamente cadastrados na base de dados do Data Mart, que foi mostrada na Figura 11. Figura 13 ETL2 desenvolvido no Kettle Spoom Fonte: Os autores. Após a carga das dimensões, o componente Elimina campos elimina os campos que não são mais necessários e distribui os registros para dois componentes, o Fatos Hora e o Fatos Dia, dividindo o processamento em duas linhas distintas, sendo a da esquerda representada pelo componente Fatos Hora, responsável pela carga nas tabelas fato com granularidade de tempo em horas. Já o lado direito, representado pelo componente Fatos Dia é responsável pela carga nas tabelas fato com granularidade de tempo em dias. O componente Fatos Hora, que, como já mencionado, representa o início do processo que dá carga das tabelas fato com granularidade de tempo em horas (Fato_Transferencia_Hora [sic] e Fato_Conexoes_Hora [sic]), é um componente de switch,

62 61 responsável por determinar o caminho a ser seguido pelo registro. Isso é feito pelo campo operacao" [sic], que representa o campo operacao [sic] da tabela de operações da base de dados ODS. Esse campo determina que tipo de operação o registro representa e, baseado nessa informação, o componente Fatos Hora define três possíveis caminhos a serem seguidos. Caso o registro seja identificado como sendo um registro de início de sessão, sessão abortada ou senha inválida, ele será direcionado ao componente Conexões hora, que representa o início do processo que dá a carga na tabela Fato_Conexoes_Hora. Caso o registro seja identificado como um registro de transmissão, recepção ou arquivo em quarentena, ele será direcionado para o componente Insere fato hora, que representa o início do processo que dá a carga na tabela Fato_Transferencia_Hora. E, caso o registro seja identificado como um registro de qualquer outra operação, ele é encaminhado para o componente Limbo para ser descartado. Da mesma forma, o componente Fatos Dia desempenha o mesmo papel que o componente Fatos Hora, porém, também como já mencionado, ele representa o início do processo que dá carga nas tabelas fato com granularidade de tempo em dias (Fato_Transferencia_Dia [sic] e Fato_Conexoes_Dia [sic]). O componente Fatos Dia, também, é um componente de switch que segue as mesmas regras de direcionamento que o componente Fatos Hora, porém direcionando para os componentes à direita. Um fato importante a ser mencionado é que, neste ponto, o conceito de não volatilidade do Data Warehouse, defendido por Machado (2008) e mencionado no item DATA WAREHOUSE, foi intencionalmente quebrado. Esse conceito diz que um Data Warehouse possui apenas duas operações básicas que são a carga através da inserção dos dados, e a consulta aos mesmos, eliminando, dessa forma, qualquer alteração nos dados já inseridos. Existe um componente de inserção de registro para cada tabela fato ( Insere registro conexao hora [sic], Insere fato hora, Insere registro conexao dia [sic], e Insere fato dia), porém esses componentes inserem apenas registros com medidas com valores zerados, sendo que os valores das medidas são inseridos através de componentes de update presentes nas pontas dos processos de carga, sendo que cada componente é responsável por incrementar apenas uma medida para as tabelas fato de conexão e duas para as tabelas fato de transferência. A inserção do registro com as medidas zeradas através dos componentes de inserção é necessária, pois caso seja executado um update cujas condições da clausura where não sejam satisfeitas, nenhum registro será alterado ou inserido. A decisão de implementar o ETL2 dessa forma, deu-se pelo elevado número de registros a serem processados, o que dificultaria a sumarização desses registros em memória.

63 62 Assim, optou-se por incrementar as medidas nas tabelas fato a medida com que os registros são processados, o que acaba transferindo o processamento para o banco de dados. O detalhamento dos componentes que fazem os updates das medidas, nas tabelas fato, pode ser encontrado em APÊNDICE E Componentes de update do ETL2. A execução da carga dos dados da base ODS para o Data Mart foi executada várias vezes até que todos os problemas na transformação fossem encontrados e corrigidos, sendo que cada execução demorou cerca de 14 horas para ser concluída. Os dados estatísticos de cada componente gerados na carga final estão em APÊNDICE F Estatísticas de execução do ETL2. O log gerado, durante a transformação, não foi incluído neste trabalho devido ao seu tamanho e por agregar pouco valor a este. Apesar de como especificado no item Data Warehouse, existirem dois níveis de granularidade de tempo e que para os fatos com granularidade de tempo diário o período de dados analisados seria de seis meses e para os fatos com granularidade de tempo por hora o período seria de um mês, durante a carga, foram processados os dados de seis meses para ambas as granularidades. Vários motivos levaram a essa decisão, dentre eles estão o fato de que, dessa forma, toda a transformação seria testada, a validação dos dados através da comparação das somas dos valores inseridos em ambas as tabelas fatos (isso é possível, pois apesar da diferença entre o nível de granularidade a soma dos valores tem que ser igual), o monitoramento da performance, etc... Nome da tabela Quantidade de registros Dimensao_Usuario [sic] 5596 Dimensao_Produto [sic] 1 Dimensao_Interface [sic] 21 Dimensao_Tempo_Hora [sic] 4297 Dimensao_Tempo_Dia [sic] 181 Fato_Conexoes_Hora [sic] Fato_Conexoes_Dia [sic] Fato_Transferencia_Hora [sic] Fato_Transferencia_Dia [sic] Quadro 15 - Quantidade de registros no Data Mart após a execução completa do ETL2. Fonte: Os autores. O Quadro 15 mostra a quantidade de registros em cada tabela do Data Mart após a execução completa do ETL2.

64 63 Nome da tabela Quantidade de registros Dimensao_Usuario [sic] 5596 Dimensao_Produto [sic] 1 Dimensao_Interface [sic] 21 Dimensao_Tempo_Hora [sic] 715 Dimensao_Tempo_Dia [sic] 181 Fato_Conexoes_Hora [sic] Fato_Conexoes_Dia [sic] Fato_Transferencia_Hora [sic] Fato_Transferencia_Dia [sic] Quadro 16 - Quantidade de registros no Data Mart após serem eliminados os registros dos meses anteriores para os fatos hora. Fonte: Os autores. Após a validação dos dados, através da comparação da soma das medidas entre os fatos dos dois níveis de granularidade tempo, os dados das tabelas Dimensao_Tempo_Hora [sic], Fato_Conexoes_Hora [sic] e Fato_Transferencia_Hora [sic], referentes aos meses anteriores a junho de 2009, foram excluídos. O resultado pode ser visto no Quadro ANÁLISE DE DADOS Este módulo trata da implementação do OLAP descrito no item OLAP (On-Line Analytical Processing), na execução das operações descritas, neste mesmo item e na análise dos relatórios gerados a partir destes. Adicionalmente, durante a pesquisa bibliográfica, foram pesquisados os itens Análise Exploratória de Dados (AED) e Técnicas de mineração de dados. A pesquisa feita sobre esses itens teve como único objetivo o aumento de conhecimento sobre tais assuntos e, dessa forma, a implementação dos mesmos não faz parte deste trabalho.

65 A definição das ferramentas A Pentaho Corporation é uma empresa que desenvolve soluções open source na área de Business Intelligence, sendo que algumas das ferramentas desenvolvidas por ela são distribuídas à comunidade gratuitamente. Um bom exemplo disso é a ferramenta de ETL Spoon Kettle utilizada no desenvolvimento dos ETLs descritos em ETL1 (Extract, Transform and Load) e ETL2 (Extract, Transform and Load). Seguindo essa mesma linha, utilizou-se o Mondrian OLAP System da Pentaho para o desenvolvimento do sistema OLAP para apresentação e análise dos dados contidos no Data Mart. A definição dos cubos OLAP no Mondrian é feita através de um arquivo XML. Para facilitar a escrita deste arquivo, foi utilizada a ferramenta Pentaho Workbench, que nada mais é do que uma interface que auxilia na criação dos cubos Instalando o projeto de exemplo do Mondrian Antes de qualquer coisa, é necessário verificar se o Apache Tomcat está instalado no comutador onde o projeto irá rodar. Caso não esteja, será necessário instalá-lo. Para isso, primeiramente, deve-se fazer o download a partir do site executar o aplicativo instalador e seguir as instruções como em qualquer aplicativo Windows. Os detalhes da instalação do Tomcat não serão abordados neste trabalho e deste ponto em diante será considerado que o Tomcat versão está instalado e rodando perfeitamente na porta O próximo passo é fazer o download do Mondrian que está disponível em sendo que o download, também, pode ser acessado pela página do próprio Mondrian que é Além do link para download, o site do Mondrian oferece uma série de informações e documentação sobre tudo que envolve a ferramenta, porém, aqui, somente serão abordados os recursos que fazem parte do escopo deste trabalho. No site de download, estão disponíveis várias versões do Mondrian, sendo que a utilizada, neste trabalho, é a versão

66 65 Após fazer o download do arquivo zip, que contém o Mondrian, será necessário descompactá-lo em algum diretório. Após fazer isso, uma série de arquivos e diretórios estará no diretório de destino, porém, apenas, o arquivo mondrian.war que está em {diretório_destino}\mondrian \lib nos interessa, pois esse é arquivo que contém o projeto de exemplo do Mondrian. Para instalar esse projeto, basta copiar o arquivo para o diretório webapps do Tomcat, porém, para facilitar a edição dos arquivos do projeto, ao invés de apenas copiar o arquivo, deve-se descompactá-lo, colocando seu conteúdo no diretório webapps/mondrian. Após fazer isso, uma estrutura igual à mostrada na Figura 14 será criada. Figura 14 - Projeto de exemplo do Mondrian - Estrutura de diretórios. Fonte: Os autores.

67 66 O funcionamento deste projeto de exemplo é relativamente simples. Os arquivos index.html e index.jsp são a porta de entrada da aplicação. Eles mostram os links que irão chamar o arquivo testpage.jsp passando como parâmetro a query a ser executada. Por exemplo, o código do primeiro link apresentado é <li><a href="testpage.jsp?query=mondrian">jpivot pivot table</a></li>. Ao clicar neste link, o arquivo testpage.jsp será chamado e este irá carregar o arquivo referente a query, que, neste caso, está em..\webapps\mondrian\web-inf\queries, sendo que o conteúdo desse diretório é mostrado na Figura 15. Figura 15 - Diretório "queries do projeto "Mondrian". Fonte: Os autores. Como se pode observar na Figura 15, existe uma série de arquivos jsp e um xml. No caso dos jsps, cada um deles representa uma consulta que pode ser feita. No link especificado anteriormente, pode-se observar que o parâmetro query=mondrian é passado para a página testpage.jsp. Isso faz com que a consulta contida no arquivo mondrian.jsp seja executada. Já no caso do arquivo xml, ele contém os cubos OLAP da aplicação. Apesar de esta aplicação estar instalada, ela ainda não está funcionando, sendo, ainda, necessária à criação de um banco de dados e que o acesso a este seja configurado corretamente. No caso deste exemplo, ele foi preparado para executar consultas na base FoodMart que pode ser encontrada em mondrian \demo no arquivo baixado do site do Mondrian. Por não fazer parte do escopo deste trabalho, os detalhes de como configurar o acesso à base FoodMart não serão especificados aqui. Tais informações podem ser encontradas em No entanto, o

68 67 item "4.4.4 Criação e configuração de um novo projeto no Mondrian detalha os procedimentos para configurar o acesso à base de dados do Data Mart em Postgres Criando cubos OLAP Conforme já mencionado anteriormente no item A definição das ferramentas, para a criação do arquivo XML, foi utilizada a ferramenta Pentaho Workbench, sendo que a versão utilizada foi a A Figura 16 mostra a tela inicial do Pentaho Workbench. Figura 16 - Tela inicial do Pentaho Workbench Fonte: Os autores. O arquivo XML, gerado pelo Workbench e utilizado pelo Mondrian, define um schema e, dentro dele, são definidos os cubos OLAP, sendo que dentro de um mesmo schema podem haver um ou mais cubos..

69 68 Um cubo faz o mapeamento do relacionamento de uma tabela fato com suas dimensões e suas medidas e, assim, um cubo precisa ter uma tabela fato, uma ou mais dimensões, uma ou mais medidas e é identificado por um nome. Dentro do cubo são criadas as dimensões do mesmo. Cada dimensão possui um nome que a identifica e uma ou mais hierarquias, sendo que essas possuem níveis que representam campos da tabela dimensão e que serão apresentados no momento da visualização dos dados. Um fato interessante sobre as dimensões é que elas podem ser de dois tipos, StandardDimension ou TimeDimension. A diferença entre as duas está no tipo de nível hierárquico suportado. Enquanto uma dimensão do tipo StandardDimension precisa ser do tipo Regular, que aceita dados como String, Integer, Boolean e etc, uma dimensão do tipo TimeDimension aceita níveis apenas dos tipos TimeYears, TimeQuarters, TimeMonths, TimeWeeks e TimeDays. Por esse motivo, ao mapear a tabela Dimensao_Tempo_Dia [sic], utilizaram-se dimensões do tipo TimeDimension, atribuindo aos níveis o tipo correto correspondente ao tipo de informação que eles representam e, ao mapear a tabela Dimensao_Tempo_Hora [sic], utilizaram-se dimensões do tipo StandardDimension, atribuindo aos níveis o tipo Integer. As medidas são outro componente de um cubo. Elas representam os valores das tabelas fato que serão analisados. Cada medida possui um nome, um tipo e um agregador que define a função que irá gerar o valor apresentado e que pode ser sum, count, min, max, avg, distinct count ou distinct-count.

70 69 Figura 17 - Tela do Pentaho Workbench com cubos criados Fonte: Os autores. Para este trabalho foram definidos quatro cubos, sendo um para cada tabela fato do Data Mart de comunicação, sendo que cada cubo mapeia todas as dimensões possíveis para cada tabela, bem como todas as medidas com os agregadores sum e avg. A Figura 17 mostra a tela do Workbench com os cubos criados, e o conteúdo do arquivo PCC_OLAP.xml está em APÊNDICE G Conteúdo do arquivo PCC_OLAP.xml que define os cubos para o Data Mart de comunicação Criação e configuração de um novo projeto no Mondrian Este item mostra como foi feita a configuração do Mondrian para mostrar os dados do Data Mart de comunicação definido em Data Warehouse com os cubos criados e

71 70 especificados em Criando cubos OLAP. Para isso, levou-se em consideração que a base de dados com o Data Mart de comunicação está criada, populada e acessível. O projeto PCC, criado para este trabalho, é todo baseado no projeto apresentado em Instalando o projeto de exemplo do Mondrian, então, começou-se pela criação do diretório PCC dentro do diretório webapps do Tomcat. Em seguida, foi feita uma cópia de todo o conteúdo do diretório Mondrian cujo conteúdo é descrito em Instalando o projeto de exemplo do Mondrian para o diretório PCC. Neste ponto, já temos nossa aplicação instalada, porém, ainda, sem funcionar. Como o banco de dados utilizado, neste trabalho, é o Postgres, é necessário colocar o arquivo de driver JDBC (postgresql jdbc4.jar), disponível em dentro do diretório PCC\WEB-INF\lib. Em seguida, o conteúdo do diretório PCC\WEB-INF\queries foi apagado e o arquivo PCC_OLAP.xml descrito em Criando cubos OLAP foi copiado para este diretório. Após o arquivo de driver JDBC e o arquivo PCC_OLAP.xml estarem no lugar correto, é hora de configurar a conexão com o banco de dados. Essa conexão é configurada em dois lugares, no arquivo web.xml no diretório PCC\WEB-INF e em cada arquivo de query que estarão junto com o arquivo PCC_OLAP.xml no diretório PCC\WEB- INF\queries. Começando pelo arquivo web.xml, ao abrir o arquivo, deve-se procurar pelo trecho de código mostrado no Quadro 17: <servlet> <servlet-name>mdxqueryservlet</servlet-name> <servlet-class>mondrian.web.servlet.mdxqueryservlet</servlet-class> <init-param> <param-name>connectstring</param-name> </init-param> </servlet> Quadro 17 - Trecho do arquivo web.xml que define a conexão com a base de dados. Fonte: Projeto de exemplo do Mondrian. Após encontrar o trecho de código acima, deve-se alterar o valor da tag paramvalue do parâmetro connectstring com os dados do Quadro 19 de modo com que o código fique da seguinte forma: <servlet> <servlet-name>mdxqueryservlet</servlet-name> <servlet-class>mondrian.web.servlet.mdxqueryservlet</servlet-class>

72 71 <init-param> <param-name>connectstring</param-name> <paramvalue>jdbc=jdbc:postgresql://localhost/pcc_dw?user=postgres;password=unisul123 ;Catalog=/WEB- INF/queries/PCC_OLAP.xml;JdbcDrivers=org.postgresql.Driver</param-value> </init-param> </servlet> Quadro 18 - Trecho do arquivo web.xml alterado para definir a conexão com o Data Mart de comunicação. Fonte: Os autores. Driver JDBC Endereço do servidor Base de dados Usuário Senha Catálogo (arquivo com os cubos) Dados de conexão com o banco de dados org.postgresql.driver localhost PCC_DW postgres unisul123 Quadro 19 - Dados para conexão com a base de dados do Data Mart. Fonte: Os autores. /WEB-INF/queries/PCC_OLAP.xml Após o web.xml estar configurado corretamente, é hora de criar os arquivos de consulta ao banco de dados do Data Mart que ficam junto com o arquivo XML que define os cubos (PCC_OLAP.xml), dentro do diretório PCC\WEB-INF\queries. Para a criação desses arquivos, foi usado o arquivo mondrian.jsp, mencionado em Instalando o projeto de exemplo do Mondrian, cujo conteúdo é mostrado abaixo: page session="true" contenttype="text/html; charset=iso " %> taglib uri="http://www.tonbeller.com/jpivot" prefix="jp" %> taglib prefix="c" uri="http://java.sun.com/jstl/core" %> <%-- uses a datasource --%> <%-- jp:mondrianquery id="query01" datasource="jdbc/mondrianfoodmart" cataloguri="/web-inf/demo/foodmart.xml" --%> <%-- uses mysql --%> <%-- jp:mondrianquery id="query01" jdbcdriver="com.mysql.jdbc.driver" jdbcurl="jdbc:mysql://localhost/foodmart" cataloguri="/web- INF/queries/FoodMart.xml"--%> <%-- uses a role defined in FoodMart.xml --%> <%-- jp:mondrianquery role="california manager" id="query01" jdbcdriver="sun.jdbc.odbc.jdbcodbcdriver" jdbcurl="jdbc:odbc:mondrianfoodmart" cataloguri="/web-inf/queries/foodmart.xml" --%> <jp:mondrianquery id="query01" jdbcdriver="org.postgresql.driver" jdbcurl="jdbc:postgresql://localhost/foodmart?user=postgres&password=unisul123" cataloguri="/web-inf/queries/foodmart.xml"> select

73 72 {[Measures].[Unit Sales], [Measures].[Store Cost], [Measures].[Store Sales]} on columns, {([Promotion Media].[All Media], [Product].[All Products])} ON rows from Sales where ([Time].[1997]) </jp:mondrianquery> <c:set var="title01" scope="session">test Query uses Mondrian OLAP</c:set> Quadro 20 - Conteúdo do arquivo mondrian.jsp distribuído junto com o projeto de exemplo do Mondrian. Fonte: Projeto de exemplo do Mondrian. Com base no conteúdo do arquivo mondrian.jsp, foi criado o arquivo AvgConexDay.jsp, cujo conteúdo é mostrado no Quadro 21. page session="true" contenttype="text/html; charset=iso " %> taglib uri="http://www.tonbeller.com/jpivot" prefix="jp" %> taglib prefix="c" uri="http://java.sun.com/jstl/core" %> <jp:mondrianquery id="query01" jdbcdriver="org.postgresql.driver" jdbcurl="jdbc:postgresql://localhost/pcc_dw?user=postgres&password=unisul123" cataloguri="/web-inf/queries/pcc_olap.xml"> select NON EMPTY {[Measures].[Media_Conexoes], [Measures].[Media_Abortadas], [Measures].[Media_Senhas_Invalidas]} on columns, NON EMPTY {([Dimensao_Tempo], [Dimensao_Usuario], [Dimensao_Interface])} on rows from [ConexoesDia] </jp:mondrianquery> <c:set var="title01" scope="session">pcc OLAP - Média das conexoes diárias</c:set> Quadro 21 - Conteúdo do arquivo AvgConexDay.jsp que realiza uma consulta no Data Mart de comunicação. Fonte: Os autores. Ao observar o conteúdo apresentado no Quadro 21, pode-se ver a tag jp:mondrianquery. Ela é o principal componente desse arquivo, pois é ela que define qual consulta será feita e em qual base de dados. A primeira propriedade dessa tag é a propriedade id, que, nesse caso, obrigatoriamente precisa ser query01, porque o arquivo testpage.jsp, mencionado em Instalando o projeto de exemplo do Mondrian espera por uma tag com esse id. Após o parâmetro id. pode-se observar os parâmetros jdbcdriver, jdbcurl e cataloguri que devem ser configurados com as informações do Quadro 19. Após serem criados os arquivos de consulta, é necessário adicionar as chamadas para os mesmos nos arquivos PCC\index.html e PCC\index.jsp como mostrado na seguinte linha: diárias</a></li> <li><a href="testpage.jsp?query=avgconexday">média de conexões

74 73 Deve-se adicionar uma chamada para cada arquivo de consulta criado. Uma vez feitas todas as configurações descritas acima, basta dar um reload na aplicação e ela estará funcionando. Para finalizar este item, uma lista com todos os arquivos de consulta criados e seu conteúdo está em APÊNDICE H Conteúdo dos arquivos de consulta ao Data Mart Visualizando os cubos pelo servidor web Conforme já mencionado anteriormente, após serem realizadas as configurações, de acordo com o item Criação e configuração de um novo projeto no Mondrian, a aplicação já está funcionando e já pode ser acessada. Para acessar a aplicação, basta abrir um navegador web e digitar o endereço do local em que ela foi disponibilizada. Como durante a elaboração deste trabalho a instalação dos do Tomcat foi feita na máquina local, o endereço é Após acessar à aplicação será exibida a página mostrada na Figura 18, em que é possível ver que, como mencionado em Criação e configuração de um novo projeto no Mondrian, existe um link para cada arquivo de consulta mostrado em APÊNDICE H Conteúdo dos arquivos de consulta ao Data Mart.

75 74 Figura 18 - Página inicial do projeto rodando no Apache Tomcat. Fonte: Os autores. Cada link, apresentado na Figura 18, irá executar um consulta na base de dados do Data Mart. Por exemplo, ao clicar no quarto link, Média de conexões diárias, a consulta AvgConexDay, usada como exemplo, em Visualizando os cubos pelo servidor web é executada, a página mostrada pela Figura 19 é apresentada. Figura 19 - Página com o resultado da consulta AvgConexDay. Fonte: Os autores.

76 75 Além da tabela com o resultado da consulta, a página mostrada pela Figura 3 apresenta uma barra de ferramentas que permite que sejam executadas uma série de operações, como a apresentação e configuração de gráficos, a classificação, exportação e impressão dos resultados, a edição da query MDX, a execução das operações de OLAP, descritas em OLAP (On-Line Analytical Processing) etc. O detalhamento de cada uma dessas operações não faz parte do escopo deste trabalho, mas algumas delas serão utilizadas e, consequentemente, descritas posteriormente Antes de iniciar as análises dos dados nos cubos Com os dados devidamente carregados na base pelos processos de ETL e com a aplicação configurada como descrito anteriormente, o sistema já está funcionando corretamente, sendo, então, possível realizar as operações OLAP e as análises desejadas. Porém, como este trabalho é de domínio publico e os dados carregados no Data Mart são dados reais de produção, cria-se um problema com relação à identidade dos clientes e usuários. Para solucionar esse problema, sem alterar os dados originais, criaram-se as tabelas, mostradas na Figura 20, na base de dados do Data Mart.. Figura 20 - Tabelas auxiliares criadas para ocultar o nome de clientes e usuários Fonte: Os autores. Depois das tabelas criadas, foi feita a importação de todos os clientes da Dimensao_Usuario [sic] para a tabela Cliente, e de todos os usuários para a tabela Usuario". Em seguida, foram executados updates nas duas tabelas trocando os nomes dos

77 76 clientes pela concatenação da palavra CLIENTE e o código do cliente na base, e o nome dos usuários pela concatenação da palavra USUARIO e o código do usuário na base. Após a criação das tabelas e dos updates, a view dimensao_usuario_view [sic] foi criada com estrutura idêntica a da Dimensao_Usuario [sic], porém acessando os dados das tabelas mostradas na Figura 20. Além disso, foi necessário alterar todas as referências da tabela Dimensao_Usuario [sic] para a view dimensao_usuario_view [sic] no arquivo PCC_OLAP.xml. Os comandos SQL executados, na base de dados do Data Mart, estão em APÊNDICE I Comandos SQL executados na base de dados do Data Mart para ocultar o nome de clientes e usuários. Pelas diferenças no conteúdo do arquivo PCC_OLAP.xml serem mínimas, as alteração não foram adicionadas nos apêndices deste trabalho, lembrando, ainda, que estas alterações não fazem parte do projeto original e que só foram feitas para que o resultado das análises que serão feitas, posteriormente, pudessem ser publicadas. 4.5 ANÁLISE DOS DADOS ATRAVÉS DOS CUBOS OLAP Aqui, foram realizadas algumas análises simples dos dados contidos na base do Data Mart, utilizando-se dos cubos montados anteriormente e dos recursos OLAP oferecidos pelo Mondrian, lembrando que as operações OLAP estão descritas em OLAP (On- Line Analytical Processing) Análise dos dados do cubo ConexoesHora O cubo ConexoesHora [sic] tem como tabela fato a tabela Fato_Conexoes_Hora [sic], e como já mencionado anteriormente em ETL2 (Extract, Transform and Load), esta tabela tem granularidade de tempo de um hora e armazena registros apenas do mês mais recente, que, no escopo de tempo deste trabalho, é representado pelo mês de junho/2009.

78 77 Figura 21 - ConexoesHora - Página inicial. Fonte: Os autores. A Figura 21 mostra a página inicial da consulta que retorna a soma das medidas selecionadas. Nela são apresentadas a quantidade de conexões estabelecidas, a quantidade de conexões abortadas e a quantidade de tentativas de se estabelecer uma conexão com uma senha inválida durante todos os meses (que neste caso significa apenas o mês de junho/2009), feita por qualquer usuário em qualquer interface. Nos itens a seguir, serão mostradas algumas das consultas possíveis de serem feitas no sistema Análise através da dimensão de tempo (ConexoesHora) Em termos de análise, os valores mostrados pela Figura 21 não têm grande valor, porém, se refinarmos nossa consulta aplicando um Drill-Down na dimensão tempo e eliminarmos as dimensões de usuário e interface, temos como resultado os dados apresentados na Figura 22, em que se têm as mesmas medidas, porém sumarizadas por dia. Além da análise que pode ser feita com a Figura 22, pode-se utilizar a ferramenta de configuração e geração de gráficos para auxiliar em uma melhor compreensão dos dados.

79 78 Figura 22 - ConexoesHora Drill-Down Tempo para fato conexões. Fonte: Os autores. Figura 23 - ConexoesHora - Gráfico de Junho/2009 com medidas diárias para fato conexões Fonte: Os autores.

80 79 A Figura 23 mostra um gráfico do tipo Stacked Vertical Bar 3D com os dados da Figura 22, em que facilmente nota-se que a quantidade de conexões abortadas e de senhas inválidas são muito menores que a quantidade de conexões estabalecidas, porém, justamente pela diferença entre os valores das medidas ser tão grande, fica impossível estabelecer a relação entre as ocorrências de conexões abortadas e de tentativas de senhas inválidas. Assim, para auxiliar nessa questão que ainda não está clara, pode-se utilizar o mesmo recurso utilizado para eliminar as dimensões de usuário e interface, para eliminar a medida de quantidade de conexões e gerar um novo gráfico. Feito isso, tem-se um gráfico com as mesmas características que o apresentado na Figura 23, porém apresentando somente as medidas de conexões abortadas e tentativas de senhas inválidas. Com o gráfico apresentado na Figura 24, fica muito mais fácil se ter uma idéia da relação entre essas duas medidas, em que se vê claramente que houve muito mais incendências de sessões abortadas do que de tentativas de conexão com senhas inválidas. Outro dado interessante que se pode observar, no gráfico apresentado na Figura 24, é que, em alguns dias, durante o mês de junho, não houve nenhuma tentativa de conexão com senhas inválidas. Além disso, pode-se observar, também, em quantos e quais dias isso ocorreu. Voltando ao gráfico apresentado na Figura 23, nota-se que a quantidade de operações, realizadas durante o mês, tendeu a obedecer um padrão composto por grupos de sete dias, e em que os dias em que houve um menor número de operações corresponde aos finais de semana, e os picos com relacção ao número de operações tendeu a ser maior no meio da semana. Figura 24 - ConexoesHora - Gráfico de conexões abortadas e senhas inválidas com medidas diárias Junho/2009. Fonte: Os autores.

81 80 Apesar das análises demostradas até este ponto terem como granularidade de tempo igual a um dia, é possível realizar mais um Drill-Down na dimensão de tempo para que os dados sejam exibidos com granularidade de tempo de uma hora. Porém, optou-se por incluir neste item apenas os dados com granularidade de tempo de um dia, por estes apresentarem um volume bastante superior em relação aos dados com granularidade de tempo de uma hora Análise através da dimensão de usuários (ConexoesHora) A Figura 25, mostra os dados de um Drill-Down seguido de um Slice and Dice executados na dimensão de usuários, além da exclusão das dimensões de tempo e interface. Como descrito em Antes de iniciar as análises dos dados nos cubos, os nomes de clientes e usuários foram mascarados de forma a ocultar sua identidade. Figura 25 - ConexoesHora Drill-Down Usuários para fato conexões. Fonte: Os autores. O cliente CLIENTE305 foi escolhido aleatóriamente na base de dados do Data Mart e seus dados e de seus seis usuários são exibidos na Figura 25, sendo possível notar que o USUARIO23 foi responsável pela grande maioria das conexões estabelecidas com sucesso. Além disso, é possível notar que, o número de conexões estabelecidas com sucesso é bem maior que o número de conexões abortadas, e que este é bem maior que o número de

82 81 tentativas de conexão com senhas inválidas, independente do usuário. Tais constatações podem ser observadas com maior clareza no gráfico mostrado na Figura 26. Figura 26 - ConexoesHora - Gráfico de conexões com medidas por usuário Junho/2009. Fonte: Os autores. Figura 27 - ConexoesHora - Gráfico de conexões abortadas e senhas inválidas com medidas por usuário Junho/2009. Fonte: Os autores. O gráfico mostrado na Figura 26 mostra a real proporção da quantidade de conexões estabelecidas entre o USUARIO23 e os demais, bem como da quantidade de

83 82 conexões estabelecidas em relação às demais operações, porém, a diferença entre a quantidade de conexões abortadas e, a quantidade de tentativas de estabelecer uma conexão com uma senha inválida não fica clara. Para que essa diferença fique clara, a medida Conexões foi excluída para a geração do gráfico mostrado na Figura 27. Nele essa diferença fica bastante clara. As análises feitas mostram que, durante o mês de Junho/2009, o CLIENTE305 não enfrentou grandes problemas ao estabelecer conexões com o servidor, pois, a quantidade de conexões abortadas e, a quantidade de tentativas de estabelecer uma conexão com uma senha inválida, foram pequenas em relação a quantidade de conexões estabelecidas, sendo que tais falhas são consideradas normais devido a uma série de fatores, como por exemplo, uma queda de sinal ou um erro do usuário ao digitar a senha. Apesar disso, essas informações devem ser monitoradas, pois, além de mostrar a evolução nas comunicações feitas pelo cliente, um aumento do número de conexões abortadas em relação à quantidade de conexões estabelecidas, pode indicar que, o cliente está enfrentando algum problema fora do comum ao realizar uma conexão, e um aumento no número de tentativas de conexão com senha inválida pode indicar uma tentativa de fraude Análise através da dimensão de interfaces de comunicação (ConexoesHora) Como já mencionado anteriormente, uma interface de comunicação é a porta por onde serão feitas as comunicações. A informação de quanto é trafegado em cada interface, é especialmente importante para o setor de infraestrutura em TI da empresa, pois, através da interface é possível identificar qual tipo de protocolo e, qual linha de comunicação o cliente está usando. A empresa conta com ferramentas de monitoramento de tráfego, porém, como algumas dessas interfaces também são utilizadas por outros sistemas, a análise feita neste item, torna-se extremamente valiosa, pois, define exatamente o volume de dados trafegado por este sistema em cada uma das interfaces, sendo possível ainda, combinar esses dados com as demais dimensões. A Figura 28, mostra os totais de conexões estabelecidas, de conexões abortadas e de tentativas de conexão com senhas inválidas, em cada interface, durante o mês junho/2009, sendo que tais dados foram extraídos da tabela fato Fato_Conexoes_Hora [sic].

84 83 Figura 28 - ConexoesHora Drill-Down Interfaces para fato conexões. Fonte: Os autores. Figura 29 - ConexoesHora - Gráfico de conexões com medidas por interface de comunicação Junho/2009. Fonte: Os autores.

85 84 Já na Figura 28, é possível notar que a grande maioria das tentativas de conexão ocorreu com sucesso e, qual interface recebeu o maior número de conexões, porém, o gráfico exibido na Figura 29, nos dá a real dimensão dessa diferença. Figura 30 - ConexoesHora - Gráfico de conexões abortadas e senhas inválidas com medidas por interface de comunicação Junho/2009. Fonte: Os autores. Como já ocorrido anteriormente, a Figura 29, deixa claro a diferença entre a quantidade de conexões estabelecidas com sucesso e as demais medidas, porém, não deixa clara a diferença existente entre a quantidade de conexões abortadas e, a quantidade de tentativas de conexões com senha inválida. Essa diferença pode ser vista na Figura Análise dos dados do cubo TransferenciaHora Da mesma forma que a tabela Fato_Conexoes_Hora [sic], a tabela Fato_Transferencia_Hora [sic], também, possui granularidade de tempo em horas.

86 85 Em seguida, são apresentadas algumas análises dos dados contidos na tabela fato Fato_Conexoes_Hora Análise através da dimensão de tempo (TransferenciaHora) A Figura 31 mostra o resultado da consulta que retorna a soma das medidas da tabela Fato_Transferencia_Hora [sic], já com a operação de Drill-Down na dimensão de tempo para o nível de dias e eliminando as dimensões de usuários, interface e produtos. A Figura 32 mostra um gráfico que representa os valores de bytes transmitidos, recebidos e em quarentena dos dados mostrados na Figura 31. Com ele, fica fácil perceber que, durante o mês de junho de 2009, a operação com maior volume de dados é a operação de transmissão, seguido pela operacção de recepção e, por último, o envio de dados a quarentena, lembrando que esses dados se referem à soma do tamanho dos arquivos processados, e não a quantidade de arquivos. Figura 31 - TransferenciaHora Drill-Down Tempo para fato transferência. Fonte: Os autores.

87 86 Figura 32 - TransferenciaHora Gráfico mensal com medias diárias de bytes transmitidos, recebidos e em quarentena - Junho/2009. Fonte: Os autores. Um outro dado que deve ser levado em consideração é que o envio de um arquivo para a quarentena ocorre somente no processo de transmissão. Dessa forma, uma análise interessante a ser feita é a da relação entre o volume de dados transmitidos e os enviados a quarentena. O gráfico mostrando, essa relação, é exibido na Figura 33. Figura 33 - TransferenciaHora Gráfico mensal com medias diárias de bytes transmitidos e em quarentena - Junho/2009. Fonte: Os autores. Um fato que chama a atenção, ao se observar os gráficos exibidos na Figura 32 e na Figura 33, é o volume de dados enviados a quarentena em relação ao volume transmitidos no dia 08/06/2009. Uma diferença tão grande, em ralação há outros dias, pode indicar que,

88 87 nesse dia, houve algum problema no ambiente de produção. Porém, como já mencionado, esses dois gráficos mostram o volume dos arquivos envolvidos na operação. Para se ter certeza, deve-se analisar a quantidade de arquivos enviados para a quarentena em relação à quantidade de arquivos transmitidos. Esses dados são mostrados na Figura 34. Figura 34 - TransferenciaHora Gráfico mensal com medias diárias de arquivos transmitidos, recebidos e em quarentena - Junho/2009. Fonte: Os autores. Ao observar o gráfico, mostrado na Figura 34, pode-se ver que a quantidade de arquivos em cada operação, incluindo a quantidade de arquivos enviados a quarentena, no dia 28/06/2009, está em linha com os dias 1, 15, 22 e 29 do mesmo mês e ano, dias em que o volume de operações realizadas é bastente semelhante. Dessa forma, pode-se, praticamente, descartar a possibilidade de algum problema na produção, pois os dados indicam apenas que, no dia 08/06/2009, a média do tamanho dos arquivos enviados a quarentena é bem maior que a média dos arquivos transmitidos com sucesso Análise através da dimensão de usuários (TransferenciaHora) A Figura 35 mostra os dados de um Drill-Down seguido de um Slice and Dice executados na dimensão de usuários, além da exclusão das dimensões de tempo e interface. Como já mencionado anteriormente, pelos dados desta análise fazerem parte de uma

89 88 ambiente de produção real, o nome dos clientes foram ocultados, conforme especificado em Antes de iniciar as análises dos dados nos cubos. Figura 35 - TransferenciaHora Drill-Down Usuários para fato transferência. Fonte: Os autores. Na Figura 35, é possível ver os dados do cliente CLIENTE305, o mesmo escolhido em Análise através da dimensão de usuários (ConexoesHora). Esses dados podem ser divididos em duas categorias distintas, sendo a quantidade de arquivos (Arquivos transmitidos, Arquivos recebidos e Arquivos quarentena), e a quatidade de bytes (Bytes transmitidos, Bytes recebidos e Bytes quarentena). Figura 36 - TransferenciaHora Gráfico mensal do número de arquivos transmitidos, recebidos e em quarentena, para usuários do cliente Junho/2009. Fonte: Os autores.

90 89 Devido ao fato de que os valores contidos na categoria de quantidade de arquivos serem muito inferiores aos valores contidos na categoria quantidade de bytes, essa divisão permite que seja feita uma análise mais clara da diferença entre as operações realizadas. A Figura 36, mostra um gráfico referente aos dados da categoria de quantidade de arquivos. Nela é possível perceber que, a quantidade de arquivos enviados para a quarentena é bem inferior a quantidade de arquivos das demais operações. Outro fato interessante é que, enquanto a quantidade de arquivos transmitidos pelos três usuários que mais transmitem arquivos (USUARIO1039, USUARIO23 e USUARIO2721), ser muito parecida, o usuário USUARIO23, recebeu uma quantidade de arquivos muito superior aos demais. Essa diferença é normal e depende dos produtos utilizados pelo usuário e, consequentemente, dos processos associados a ele. Figura 37 - TransferenciaHora Gráfico mensal da quantidade de bytes transmitidos, recebidos e em quarentena, para usuários do cliente Junho/2009. Fonte: Os autores. A Figura 37, mostra os dados da categoria quantidade de bytes. Essa catagoria contém o total de bytes transmitidos, recebidos e enviados a quarentena por cada usuário, sendo que, esses totais são obtidos através da soma do tamanho dos arquivos mostrados na Figura 36. Como se pode perceber fácilmente, somente o usuário USUARIO23, demonstra o mesmo padrão, tanto no gráfico mostrado na Figura 36, quanto no mostrado na Figura 37, ficando entre os três usuários que transmitiram o maior volume de dados e, sendo o que recebeu o maior volume de dados. Já o usuário USUARIO2771, que na Figura 36, aparece

91 90 como um dos três usuários que transmitiram o maior número de arquivos, na Figura 37 é possível notar que, o volume trafegado é bem inferior que aos usuários com grande volume de transmissão, e sendo assim, se pode concluir que usuário USUARIO2771 transmitiu uma grande quantidade de arquivos, com tamanho inferior aos dos demais usuários. Por outro lado, o usuário USUARIO429, transmitiu uma pequena quantidade de arquivos em relação aos demais usuários, porém, o volume em bytes transmitidos foi o maior dentre todos os usuários do cliente CLIENTE305, sendo possível concluir que, o tamanho dos arquivos transmitidos por esse usuário foi maior que os arquivos transmitidos pelos demais usuários. Com essas informações, é possível estabelecer padrões e monitorar cada usuário, a fim de detectar alguma mudança de comportamento e, quando necessário, entrar em contato com o mesmo para verificar se está ocorrendo algum problema Análise através da dimensão de interfaces de comunicação (TransferenciaHora) A Figura 38, mostra os dados de um Drill-Down, seguido de um Slice and Dice executados na dimensão de interfaces, além da exclusão das dimensões de tempo, usuário e produto. Nela é mostrado o volume de dados trafegado em cada interface de comunicação, sendo que, como já mencionado anteriormente, essas informações são extremamente importantes para a área de infraestrutura. Figura TransferenciaHora Drill-Down Interface para fato transferência. Fonte: Os autores.

92 91 Figura 39 - TransferenciaHora Gráfico mensal do número de arquivos transmitidos, recebidos e em quarentena, por interface - Junho/2009. Fonte: Os Autores. A Figura 39, mostra um gráfico com a quantidade de arquivos transmitidos em cada inteface. Nesse gráfico é possível notar que, com relação ao número de arquivos transmitidos, as interfaces :7700 e rvs se destacam das demais. Além disso, outras quatro interfaces se destacam apesar da quantidade de arquivos transmitidos ser bem inferior as duas em destaque. Com relação à quantidade de arquivos recebidos, nota-se que, apenas três interfaces se destacam, sendo elas a :7700, a Desconhecida e a nexxera.skyline.com.br:7700, sendo elas as responsáveis pelo recebimento de grande maioria do total de arquivos recebidos. Já ao se analizar a quantidade de arquivos enviados a quarentena, nota-se que, a quantidade de arquivos enviados a quarentena é bem inferior a quantidade de arquivos transmitidos e a quantidade de arquivos recebidos. Além disso, notase que, a maioria dos arquivos enviados a quarentena fazem parte da interface Desconhecida, o que quer dizer que, não foi possível identificar a interface a qual esses arquivos pertencem. Nela também é possível observar que, a maioria das interfaces de comunicação transmitiu poucos arquivos durante o período analisado, porém, vale lembrar que, a quantidade de arquivos transmitidos não indica necessariamente o volume de dados trafegado.

93 92 Figura 40 - TransferenciaHora Gráfico mensal do total de bytes transmitidos, recebidos e em quarentena, por interface - Junho/2009. Fonte: Os Autores. Já a Figura 40, mostra o volume de dados trafegado. Ao se comparar o gráfico mostrado na Figura 39 com o gráfico mostrado na Figura 40, nota-se algumas semelhanças, por exemplo, com relação às transmissões, se pode observar que, as interfaces e rvs, se destacam tanto na quantidade de arquivos transmitidos, quanto no volume de dados transmitidos, sendo que a primeira, trafegou um volume de dados um pouco superior a segunda. Entretanto, a interface Desconhecida, transferiu um volume de dados por arquivo, superior as demais interfaces. Com relação ao volume de dados recebidos, as mesmas interfaces se destacam, porém, a interface :7700, que no gráfico da Figura 39, aparece em segundo lugar na quantidade de arquivos transmitidos, no gráfico da Figura 40, aparece em terceiro lugar, invertento sua posição nos dois gráficos com a interface Desconhecida. Já com relação ao volume de dados enviados a quarentena, a interface Desconhecida e a interface rvs se destacam. O monitoramento da quantidade e volume de arquivos trafegados é importante para o dimencionamento das linhas de comunicação, e o monitoramento da quantidade de arquivos e volume de dados enviados a quarentena é importante por que, um dos motivos pelo qual, um arquivo é enviado a quarentena são as falhas ocorridas durante a comunicação. Sendo assim, um número excessivo de arquivos sendo enviados a quarentena em uma mesma interface de comunicação pode indicar um problema.

94 Análise dos dados do cubo ConexoesDia Para o cubo ConexoesDia [sic] tem-se como tabela fato á tabela Fato_Conexoes_Dia [sic] e, como já mencionado anteriormente em ETL2 (Extract, Transform and Load), esta tabela tem granularidade de tempo de um dia e guarda registros diários dos meses, como já citado é trabalhando apenas com seis meses, de janeiro de 2009 a junho de 2009, tendo todos estes dias carregados na tabela. Figura 41 - ConexoesDia Tela inicial da consulta de soma das conexões diárias. Fonte: Os autores. Na Figura 41, temos página inicial da consulta que retorna a soma total das conexões realizadas. Nesta mesma imagem, temos presente mais duas colunas que demonstram o total de conexões abortadas e o total de tentativas de conexões com senha inválida. Como já citado, o período acima é Janeiro a Junho de 2009, realizado por todos os usuários e interfaces Análise através da dimensão de tempo (ConexoesDia) Efetuando Drill-Down na dimensão tempo, mostrando os meses de 2009 e eliminando as dimensões de usuário e interface, temos como resultado os dados apresentados na Figura 42 em que se têm as mesmas medidas, porém divididas por mês.

95 94 Figura 42 - ConexoesDia Drill-Down Tempo para fato conexões ao nível de mês. Fonte: Os autores. Mesmo sem a utilização de gráficos, para analisar melhor os dados acima, já podemos notar, a grosso modo, algumas situações como um crescente mês a mês nas conexões, conexões abortadas e tentativas de conexões com senhas inválidas. Figura 43- ConexoesDia Gráfico Primeiro Semetre 2009, de conexõe efetuadas, abortadas e tentivas com senhas inválidas. Fonte: Os autores. Com o gráfico da Figura 43, podemos complementar o comentário acima sobre o número de conexões que apresentaram uma crescente, exceto no mês de Fevereiro. Este motivo pode estar associado ao motivo de o mês de Fevereiro possuir dias a menos se comparados aos demais. Neste caso, 28 dias para fevereiro, contra 30 ou 31 para os demais.

96 95 Esta mesma situação pode ser verificada nas conexões abortadas e tentativas de conexões com senhas inválidas, que, também, apresentam uma queda no mês de Fevereiro. Uma outra informação, que podemos extrair do gráfico, é que, o mês de Maio, teve um número quase duas vezes maior ao mês posterior (Junho) ou anterior (Abril), ou até quatro vezes mais se comparado aos mes de Janeiro. Podemos associar essa informação a uma possível falha na ferramenta de transmissão ou a fatores externos como a possível falha no provedor de internet de uma determinada região, como sudeste do país que poderia concentram a grande maioria dos clientes Análise dos dados do cubo TransferenciaDia O cubo TransferenciaDia [sic] tem como tabela fato a tabela Fato_Transferencia_Dia [sic], que, como já mencionado anteriormente, possui granularidade de tempo em dias Análise através da dimensão de tempo (TransferenciaDia) A Figura 44 mostra a soma das medidas da tabela fato, com a opereção de Drill- Down da dimensão de tempo para o nível mensal e eliminando as dimensões de usuário, interface e de produtos. Figura 44 - TransferenciaDia Drill-Down Tempo para fato transferência ao nível de mês. Fonte: Os autores.

97 96 A Figura 45 mostra um gráfico com o total mensal de bytes transmitidos, recebidos e enviados para a quarentena nos primeiros seis meses do ano. Nele, é possível notar certa estabilidade nos quatro primeiros meses, com uma pequena queda no mês de fevereiro, que, provavelmente está relacionada a menor quantidade de dias do mês e a uma alta nos dois últimos meses. Figura 45 - TransferenciaDia Gráfico semestral com medidas mensais de bytes transmitidos e em quarentena - Primeiro semestre de Fonte: Os autores. Com relação à quantidade de arquivos transmitidos, recebidos e enviados para a qaurentena, a Figura 46 mostra um gráfico com o total mensal para o primeiro semestre do ano. Nele, é possível observar um comportamento um pouco diferente do mostrado na Figura 45. No primeiro trimestre, tem-se uma queda em fevereiro com relação a janeiro, seguido por uma alta considerável em março. Já, no segundo trimestre, tem-se uma pequena queda em abril com relação a março, seguida por duas altas em maio e junho.

98 97 Figura 46 - TransferenciaDia Gráfico semestral com medidas mensais de arquivos transmitidos e em quarentena - Primeiro semestre de Fonte: Os autores. A Figura 47 mostra um gráfico gerado a partir de um Drill-Down do mês de junho. A análise de um gráfico idêntico foi feita no item Análise dos dados do cubo TransferenciaHora. Tal gráfico é exibido na Figura 32. Figura 47 - TransferenciaDia Gráfico mensal com médias diárias de bytes transmitidos, recebidos e em quarentena - Junho/2009. Fonte: Os autores. Se analisarmos os gráficos, mostrados na Figura 32 e na Figura 47, chegaremos à conclusão de que são idênticos. Na verdade, a única diferença entre os dois é a origem dos dados. Enquanto os dados do gráfico da Figura 32 foram gerados a partir da tabela Fato_Transferencia_Hora [sic] e suas dimensões, o gráfico da Figura 47 teve como tabela

Sistemas de Apoio à Decisão (SAD) - Senado

Sistemas de Apoio à Decisão (SAD) - Senado Sistemas de Apoio à Decisão (SAD) - Senado DW OLAP BI Ilka Kawashita Material preparado :Prof. Marcio Vitorino Sumário OLAP Data Warehouse (DW/ETL) Modelagem Multidimensional Data Mining BI - Business

Leia mais

Aplicação A. Aplicação B. Aplicação C. Aplicação D. Aplicação E. Aplicação F. Aplicação A REL 1 REL 2. Aplicação B REL 3.

Aplicação A. Aplicação B. Aplicação C. Aplicação D. Aplicação E. Aplicação F. Aplicação A REL 1 REL 2. Aplicação B REL 3. Sumário Data Warehouse Modelagem Multidimensional. Data Mining BI - Business Inteligence. 1 2 Introdução Aplicações do negócio: constituem as aplicações que dão suporte ao dia a dia do negócio da empresa,

Leia mais

DATA WAREHOUSE. Introdução

DATA WAREHOUSE. Introdução DATA WAREHOUSE Introdução O grande crescimento do ambiente de negócios, médias e grandes empresas armazenam também um alto volume de informações, onde que juntamente com a tecnologia da informação, a correta

Leia mais

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE Engenharia de Computação Professor: Rosalvo Ferreira de Oliveira Neto OLPT x OLAP Roteiro OLTP Datawarehouse OLAP Operações OLAP Exemplo com Mondrian e Jpivot

Leia mais

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4. SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.1 Armazenamento... 5 4.2 Modelagem... 6 4.3 Metadado... 6 4.4

Leia mais

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br Data Warehousing Leonardo da Silva Leandro Agenda Conceito Elementos básicos de um DW Arquitetura do DW Top-Down Bottom-Up Distribuído Modelo de Dados Estrela Snowflake Aplicação Conceito Em português:

Leia mais

Planejamento Estratégico de TI. Prof.: Fernando Ascani

Planejamento Estratégico de TI. Prof.: Fernando Ascani Planejamento Estratégico de TI Prof.: Fernando Ascani Data Warehouse - Conceitos Hoje em dia uma organização precisa utilizar toda informação disponível para criar e manter vantagem competitiva. Sai na

Leia mais

5 Estudo de Caso. 5.1. Material selecionado para o estudo de caso

5 Estudo de Caso. 5.1. Material selecionado para o estudo de caso 5 Estudo de Caso De modo a ilustrar a estruturação e representação de conteúdos educacionais segundo a proposta apresentada nesta tese, neste capítulo apresentamos um estudo de caso que apresenta, para

Leia mais

CONSIDERAÇÕES SOBRE ATIVIDADES DE IDENTIFICAÇÃO, LOCALIZAÇÃO E TRATAMENTO DE DADOS NA CONSTRUÇÃO DE UM DATA WAREHOUSE

CONSIDERAÇÕES SOBRE ATIVIDADES DE IDENTIFICAÇÃO, LOCALIZAÇÃO E TRATAMENTO DE DADOS NA CONSTRUÇÃO DE UM DATA WAREHOUSE CONSIDERAÇÕES SOBRE ATIVIDADES DE IDENTIFICAÇÃO, LOCALIZAÇÃO E TRATAMENTO DE DADOS NA CONSTRUÇÃO DE UM DATA WAREHOUSE Fabio Favaretto Professor adjunto - Programa de Pós Graduação em Engenharia de Produção

Leia mais

Business Intelligence e ferramentas de suporte

Business Intelligence e ferramentas de suporte O modelo apresentado na figura procura enfatizar dois aspectos: o primeiro é sobre os aplicativos que cobrem os sistemas que são executados baseados no conhecimento do negócio; sendo assim, o SCM faz o

Leia mais

Data Warehouses. Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos

Data Warehouses. Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos Data Warehouses Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos Conceitos Básicos Data Warehouse(DW) Banco de Dados voltado para

Leia mais

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago DATA WAREHOUSE Rafael Ervin Hass Raphael Laércio Zago Roteiro Introdução Aplicações Arquitetura Características Desenvolvimento Estudo de Caso Conclusão Introdução O conceito de "data warehousing" data

Leia mais

IMPLANTAÇÃO DO DW NA ANVISA

IMPLANTAÇÃO DO DW NA ANVISA IMPLANTAÇÃO DO DW NA ANVISA Bruno Nascimento de Ávila 1 Rodrigo Vitorino Moravia 2 Maria Renata Furtado 3 Viviane Rodrigues Silva 4 RESUMO A tecnologia de Business Intelligenge (BI) ou Inteligência de

Leia mais

Data Warehouse. Debora Marrach Renata Miwa Tsuruda

Data Warehouse. Debora Marrach Renata Miwa Tsuruda Debora Marrach Renata Miwa Tsuruda Agenda Introdução Contexto corporativo Agenda Introdução Contexto corporativo Introdução O conceito de Data Warehouse surgiu da necessidade de integrar dados corporativos

Leia mais

DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP.

DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP. DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP. Eduardo Cristovo de Freitas Aguiar (PIBIC/CNPq), André Luís Andrade

Leia mais

Data Warehouse Processos e Arquitetura

Data Warehouse Processos e Arquitetura Data Warehouse - definições: Coleção de dados orientada a assunto, integrada, não volátil e variável em relação ao tempo, que tem por objetivo dar apoio aos processos de tomada de decisão (Inmon, 1997)

Leia mais

Tópicos Avançados Business Intelligence. Banco de Dados Prof. Otacílio José Pereira. Unidade 10 Tópicos Avançados Business Inteligence.

Tópicos Avançados Business Intelligence. Banco de Dados Prof. Otacílio José Pereira. Unidade 10 Tópicos Avançados Business Inteligence. Tópicos Avançados Business Intelligence Banco de Dados Prof. Otacílio José Pereira Unidade 10 Tópicos Avançados Business Inteligence Roteiro Introdução Níveis organizacionais na empresa Visão Geral das

Leia mais

Data Warehouses Uma Introdução

Data Warehouses Uma Introdução Data Warehouses Uma Introdução Alex dos Santos Vieira, Renaldy Pereira Sousa, Ronaldo Ribeiro Goldschmidt 1. Motivação e Conceitos Básicos Com o advento da globalização, a competitividade entre as empresas

Leia mais

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO @ribeirord FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO Rafael D. Ribeiro, M.Sc,PMP. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br Lembrando... Aula 4 1 Lembrando... Aula 4 Sistemas de apoio

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Exercícios OLAP - CESPE Material preparado: Prof. Marcio Vitorino OLAP Material preparado: Prof. Marcio Vitorino Soluções MOLAP promovem maior independência de fornecedores de SGBDs

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com Sistemas de informação Disciplina: Introdução a SI Noções de sistemas de informação Turma: 01º semestre Prof. Esp. Marcos Morais

Leia mais

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence É um conjunto de conceitos e metodologias que, fazem uso de acontecimentos e sistemas e apoiam a tomada de decisões. Utilização de várias fontes de informação para se definir estratégias de competividade

Leia mais

Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse

Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse Definição escopo do projeto (departamental, empresarial) Grau de redundância dos dados(ods, data staging) Tipo de usuário alvo (executivos, unidades) Definição do ambiente (relatórios e consultas préestruturadas

Leia mais

4 Aplicação da Sistemática

4 Aplicação da Sistemática 4 Aplicação da Sistemática Este capítulo descreve a aplicação da sistemática definida no Capítulo 3 utilizando dados reais de uma estatística pública e aplicando tecnologias avançadas fazendo o uso de

Leia mais

Palavras-chave: On-line Analytical Processing, Data Warehouse, Web mining.

Palavras-chave: On-line Analytical Processing, Data Warehouse, Web mining. BUSINESS INTELLIGENCE COM DADOS EXTRAÍDOS DO FACEBOOK UTILIZANDO A SUÍTE PENTAHO Francy H. Silva de Almeida 1 ; Maycon Henrique Trindade 2 ; Everton Castelão Tetila 3 UFGD/FACET Caixa Postal 364, 79.804-970

Leia mais

Chapter 3. Análise de Negócios e Visualização de Dados

Chapter 3. Análise de Negócios e Visualização de Dados Chapter 3 Análise de Negócios e Visualização de Dados Objetivos de Aprendizado Descrever a análise de negócios (BA) e sua importância par as organizações Listar e descrever brevemente os principais métodos

Leia mais

Módulo 2. Definindo Soluções OLAP

Módulo 2. Definindo Soluções OLAP Módulo 2. Definindo Soluções OLAP Objetivos Ao finalizar este módulo o participante: Recordará os conceitos básicos de um sistema OLTP com seus exemplos. Compreenderá as características de um Data Warehouse

Leia mais

Adriano Maranhão BUSINESS INTELLIGENCE (BI),

Adriano Maranhão BUSINESS INTELLIGENCE (BI), Adriano Maranhão BUSINESS INTELLIGENCE (BI), BUSINESS INTELLIGENCE (BI) O termo Business Intelligence (BI), popularizado por Howard Dresner do Gartner Group, é utilizado para definir sistemas orientados

Leia mais

Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso

Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso Aplicando Técnicas de Business Intelligence sobre dados de desempenho Acadêmico: Um estudo de caso Ana Magela Rodriguez Almeida 1, Sandro da Silva Camargo 1 1 Curso Engenharia de Computação Universidade

Leia mais

Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em

Leia mais

Curso Data warehouse e Business Intelligence

Curso Data warehouse e Business Intelligence Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

Leia mais

Sistema de Informação Gerencial baseado em Data Warehouse aplicado a uma software house

Sistema de Informação Gerencial baseado em Data Warehouse aplicado a uma software house Universidade Regional de Blumenau Centro de Ciências Exatas e Naturais Curso de Sistemas de Informação (Bacharelado) Sistema de Informação Gerencial baseado em Data Warehouse aplicado a uma software house

Leia mais

DESMISTIFICANDO O CONCEITO DE ETL

DESMISTIFICANDO O CONCEITO DE ETL DESMISTIFICANDO O CONCEITO DE ETL Fábio Silva Gomes da Gama e Abreu- FSMA Resumo Este artigo aborda os conceitos de ETL (Extract, Transform and Load ou Extração, Transformação e Carga) com o objetivo de

Leia mais

Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS

Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS Sumário Conceitos/Autores chave... 3 1. Introdução... 5 2. OLAP... 6 3. Operações em OLAP... 8 4. Arquiteturas em OLAP...

Leia mais

Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹

Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹ Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹ ¹Ciência da Computação Universidade Federal de Itajubá (UNIFEI) MG Brasil

Leia mais

Uma Ferramenta WEB para apoio à Decisão em Ambiente Hospitalar

Uma Ferramenta WEB para apoio à Decisão em Ambiente Hospitalar Uma Ferramenta WEB para apoio à Decisão em Ambiente Hospitalar Mikael de Souza Fernandes 1, Gustavo Zanini Kantorski 12 mikael@cpd.ufsm.br, gustavoz@cpd.ufsm.br 1 Curso de Sistemas de Informação, Universidade

Leia mais

Uma Ferramenta Web para BI focada no Gestor de Informação

Uma Ferramenta Web para BI focada no Gestor de Informação Uma Ferramenta Web para BI focada no Gestor de Informação Mikael de Souza Fernandes 1, Gustavo Zanini Kantorski 12 mikael@cpd.ufsm.br, gustavoz@cpd.ufsm.br 1 Curso de Sistemas de Informação, Universidade

Leia mais

Bloco Administrativo

Bloco Administrativo Bloco Administrativo BI Business Intelligence Objetivo O objetivo deste artigo é dar uma visão geral sobre o Módulo Business Intelligence, que se encontra no Bloco Administrativo. Todas informações aqui

Leia mais

A importância da. nas Organizações de Saúde

A importância da. nas Organizações de Saúde A importância da Gestão por Informações nas Organizações de Saúde Jorge Antônio Pinheiro Machado Filho Consultor de Negócios www.bmpro.com.br jorge@bmpro.com.br 1. Situação nas Empresas 2. A Importância

Leia mais

Fundamentos da inteligência de negócios: gestão da informação e de bancos de dados

Fundamentos da inteligência de negócios: gestão da informação e de bancos de dados Fundamentos da inteligência de negócios: gestão da informação e de bancos de dados slide 1 1 Copyright 2011 Pearson Education, Inc. publishing as Prentice Hall Objetivos de estudo Como um banco de dados

Leia mais

Data Warehouse. Diogo Matos da Silva 1. Universidade Federal de Ouro Preto, Ouro Preto, MG, Brasil. Banco de Dados II

Data Warehouse. Diogo Matos da Silva 1. Universidade Federal de Ouro Preto, Ouro Preto, MG, Brasil. Banco de Dados II Data Warehouse Diogo Matos da Silva 1 1 Departamento de Computação Universidade Federal de Ouro Preto, Ouro Preto, MG, Brasil Banco de Dados II Diogo Matos (DECOM - UFOP) Banco de Dados II Jun 2013 1 /

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Introdução a Data Warehousing e OLAP Introdução a Data Warehouse e Modelagem Dimensional Visão

Leia mais

UNIVERSIDADE DO SUL DE SANTA CATARINA DANIEL LUIZ DA SILVA

UNIVERSIDADE DO SUL DE SANTA CATARINA DANIEL LUIZ DA SILVA UNIVERSIDADE DO SUL DE SANTA CATARINA DANIEL LUIZ DA SILVA ESTUDO DE CASO: ARQUITETURA DE BI PARA APOIAR O PROCESSO DECISÓRIO DE UMA FÁBRICA DE SOFTWARE Florianópolis 2014 DANIEL LUIZ DA SILVA ESTUDO DE

Leia mais

Business Intelligence aplicado a área da saúde: potencializando a tomada de decisão

Business Intelligence aplicado a área da saúde: potencializando a tomada de decisão Business Intelligence aplicado a área da saúde: potencializando a tomada de decisão Daiane Kelly de Oliveira 1, Dorirley Rodrigo Alves 1 1 Instituto de Ciências Exatas e Informática PUC Minas Campus Guanhães

Leia mais

Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse

Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse Prof. Dr. Oscar Dalfovo Universidade Regional de Blumenau - FURB, Blumenau, Brasil dalfovo@furb.br Prof. Dr. Juarez

Leia mais

Implementação de um Data Warehouse para Analise Multidimensional de Informações da Secretária de Trânsito de Guaíba

Implementação de um Data Warehouse para Analise Multidimensional de Informações da Secretária de Trânsito de Guaíba Implementação de um Data Warehouse para Analise Multidimensional de Informações da Secretária de Trânsito de Guaíba Fernando Maganha 1, Daniel Murara Barcia 2 1 Acadêmico do Curso de Sistemas de Informação

Leia mais

Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan

Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan Faculdade INED Curso Superior de Tecnologia em Banco de Dados Disciplina: Projeto de Banco de Dados Relacional II Prof.: Fernando Hadad Zaidan 1 Unidade 4.2 2 1 BI BUSINESS INTELLIGENCE BI CARLOS BARBIERI

Leia mais

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

Leia mais

Conversão de Base de Dados Relacional para Dimensional para Business Intelligence Utilizando Banco de Dados Mysql

Conversão de Base de Dados Relacional para Dimensional para Business Intelligence Utilizando Banco de Dados Mysql Conversão de Base de Dados Relacional para Dimensional para Business Intelligence Utilizando Banco de Dados Mysql Carlos H. Cardoso 1, Roberto D Nebo 1, Luis A. da Silva 1 1 Curso de Tecnologia em Banco

Leia mais

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5 Para entender bancos de dados, é útil ter em mente que os elementos de dados que os compõem são divididos em níveis hierárquicos. Esses elementos de dados lógicos constituem os conceitos de dados básicos

Leia mais

Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence

Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence Juntamente com o desenvolvimento desses aplicativos surgiram os problemas: & Data Warehouse July Any Rizzo Oswaldo Filho Década de 70: alguns produtos de BI Intensa e exaustiva programação Informação em

Leia mais

Kimball University: As 10 Regras Essenciais para a Modelagem de Dados Dimensional

Kimball University: As 10 Regras Essenciais para a Modelagem de Dados Dimensional Kimball University: As 10 Regras Essenciais para a Modelagem de Dados Dimensional Margy Ross Presidente Kimball Group Maio de 2009, Intelligent Enterprise.com Tradução livre para a língua portuguesa por

Leia mais

srbo@ufpa.br www.ufpa.br/srbo

srbo@ufpa.br www.ufpa.br/srbo CBSI Curso de Bacharelado em Sistemas de Informação BI Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Tópicos Especiais em Sistemas de Informação Faculdade de Computação Instituto

Leia mais

Capítulo 1 - A revolução dos dados, da informação e do conhecimento 1 B12 4

Capítulo 1 - A revolução dos dados, da informação e do conhecimento 1 B12 4 Sumário Capítulo 1 - A revolução dos dados, da informação e do conhecimento 1 B12 4 Capítulo 2 - Reputação corporativa e uma nova ordem empresarial 7 Inovação e virtualidade 9 Coopetição 10 Modelos plurais

Leia mais

PLANO DE ENSINO PRÉ-REQUISITOS: ENS

PLANO DE ENSINO PRÉ-REQUISITOS: ENS UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI PLANO DE ENSINO DEPARTAMENTO: DSI Departamento de Sistema de Informação DISCIPLINA: Data Warehouse

Leia mais

MANUAL BI- Business Intelligence

MANUAL BI- Business Intelligence 1. VISÃO GERAL 1.1 SISTEMA BI Business Intelligence: Segundo Gartner Group, a maior ameaça das empresas da atualidade é o desconhecimento... O Business Intelligence se empenha em eliminar as dúvidas e

Leia mais

Data Warehousing Visão Geral do Processo

Data Warehousing Visão Geral do Processo Data Warehousing Visão Geral do Processo Organizações continuamente coletam dados, informações e conhecimento em níveis cada vez maiores,, e os armazenam em sistemas informatizados O número de usuários

Leia mais

Administração de Sistemas de Informação Gerenciais UNIDADE IV: Fundamentos da Inteligência de Negócios: Gestão da Informação e de Banco de Dados Um banco de dados é um conjunto de arquivos relacionados

Leia mais

Arquitetura física de um Data Warehouse

Arquitetura física de um Data Warehouse É um modo de representar a macroestrutura de, comunicação, processamento e existentes para usuários finais dentro da empresa. Operacionais origem Data / Arquitetura física Serviços Armazenamento de Área

Leia mais

APLICAÇÃO DE MINERAÇÃO DE DADOS PARA O LEVANTAMENTO DE PERFIS: ESTUDO DE CASO EM UMA INSTITUIÇÃO DE ENSINO SUPERIOR PRIVADA

APLICAÇÃO DE MINERAÇÃO DE DADOS PARA O LEVANTAMENTO DE PERFIS: ESTUDO DE CASO EM UMA INSTITUIÇÃO DE ENSINO SUPERIOR PRIVADA APLICAÇÃO DE MINERAÇÃO DE DADOS PARA O LEVANTAMENTO DE PERFIS: ESTUDO DE CASO EM UMA INSTITUIÇÃO DE ENSINO SUPERIOR PRIVADA Lizianne Priscila Marques SOUTO 1 1 Faculdade de Ciências Sociais e Aplicadas

Leia mais

SAD orientado a DADOS

SAD orientado a DADOS Universidade do Contestado Campus Concórdia Curso de Sistemas de Informação Prof.: Maico Petry SAD orientado a DADOS DISCIPLINA: Sistemas de Apoio a Decisão SAD orientado a dados Utilizam grandes repositórios

Leia mais

Fundamentos da Análise Multidimensional

Fundamentos da Análise Multidimensional Universidade Técnica de Lisboa INSTITUTO SUPERIOR DE ECONOMIA E GESTÃO Informática e Sistemas de Informação Aplicados em Economia Fundamentos da Análise Multidimensional Fundamentos da Análise Multidimensional

Leia mais

Gerenciamento de Dados e Gestão do Conhecimento

Gerenciamento de Dados e Gestão do Conhecimento ELC1075 Introdução a Sistemas de Informação Gerenciamento de Dados e Gestão do Conhecimento Raul Ceretta Nunes CSI/UFSM Introdução Gerenciando dados A abordagem de banco de dados Sistemas de gerenciamento

Leia mais

BUSINESS INTELLIGENCE -Inteligência nos Negócios-

BUSINESS INTELLIGENCE -Inteligência nos Negócios- UNIVERSIDADE SÃO FRANCISCO CENTRO DE CIÊNCIAS JURÍDICAS, HUMANAS E SOCIAIS BUSINESS INTELLIGENCE -Inteligência nos Negócios- Curso: Administração Hab. Sistemas de Informações Disciplina: Gestão de Tecnologia

Leia mais

Módulo 5. Implementando Cubos OLAP

Módulo 5. Implementando Cubos OLAP Módulo 5. Implementando Cubos OLAP Objetivos Compreender a importância da manipulação correta da segurança nos dados. Conhecer as operações que podem ser realizadas na consulta de um cubo. Entender o uso

Leia mais

MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML

MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML 1 MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML JOANA SCHEEREN Porto Alegre 2009 2 JOANA SCHEEREN MODELAGEM GRÁFICA DE DATA WAREHOUSES E DATA MARTS USANDO UML Trabalho de Conclusão de Curso

Leia mais

Projeto de Data Warehousing sobre Informações em Saúde para dar Suporte a Análise de Faturamento Hospitalar

Projeto de Data Warehousing sobre Informações em Saúde para dar Suporte a Análise de Faturamento Hospitalar Projeto de Data Warehousing sobre Informações em Saúde para dar Suporte a Análise de Faturamento Hospitalar Newton Shydeo Brandão Miyoshi Joaquim Cezar Felipe Grupo de Informática Biomédica Departamento

Leia mais

Modelando um Data Warehouse GRIMALDO OLIVEIRA

Modelando um Data Warehouse GRIMALDO OLIVEIRA Modelando um Data Warehouse GRIMALDO OLIVEIRA Sobre Grimaldo Grimaldo Oliveira grimaldo_lopes@hotmail.com Formação Mestre em Tecnologias Aplicadas a Educação pela Universidade do Estado da Bahia. Especialização

Leia mais

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado)

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) SISTEMA INTERNO INTEGRADO PARA CONTROLE DE TAREFAS INTERNAS DE UMA EMPRESA DE DESENVOLVIMENTO

Leia mais

Uma aplicação de Data Warehouse para apoiar negócios

Uma aplicação de Data Warehouse para apoiar negócios Uma aplicação de Data Warehouse para apoiar negócios André Vinicius Gouvêa Monteiro Marcos Paulo Oliveira Pinto Rosa Maria E. Moreira da Costa Universidade do Estado do Rio de Janeiro - UERJ IME - Dept

Leia mais

Capítulo 2 Data Warehousing

Capítulo 2 Data Warehousing Capítulo 2 Data Warehousing Objetivos de Aprendizado Compreender as definições e os conceitos básicos dos data warehouses Compreender as arquiteturas de data warehousing Descrever os processos usados no

Leia mais

OLAP em âmbito hospitalar: Transformação de dados de enfermagem para análise multidimensional

OLAP em âmbito hospitalar: Transformação de dados de enfermagem para análise multidimensional OLAP em âmbito hospitalar: Transformação de dados de enfermagem para análise multidimensional João Silva and José Saias m5672@alunos.uevora.pt, jsaias@di.uevora.pt Mestrado em Engenharia Informática, Universidade

Leia mais

UNIVERSIDADE DO SUL DE SANTA CATARINA LEONARDO BRAND BIANCO PEREIRA BUSINESS INTELLIGENCE APLICADO AO TRANSPORTE COLETIVO

UNIVERSIDADE DO SUL DE SANTA CATARINA LEONARDO BRAND BIANCO PEREIRA BUSINESS INTELLIGENCE APLICADO AO TRANSPORTE COLETIVO UNIVERSIDADE DO SUL DE SANTA CATARINA LEONARDO BRAND BIANCO PEREIRA BUSINESS INTELLIGENCE APLICADO AO TRANSPORTE COLETIVO Palhoça 2008 LEONARDO BRAND BIANCO PEREIRA BUSINESS INTELLIGENCE APLICADO AO TRANSPORTE

Leia mais

PENTAHO. História e Apresentação

PENTAHO. História e Apresentação PÓS-GRADUAÇÃO LATO SENSU Curso: Banco de Dados Disciplina: Laboratório de Data Warehouse e Business Intelligence Professor: Fernando Zaidan Unidade 2 2012 Crédito dos Slides: Clever Junior 2 PENTAHO História

Leia mais

Aplicação de Data Warehousing no Cadastro de Ficha Limpa do TSE

Aplicação de Data Warehousing no Cadastro de Ficha Limpa do TSE Aplicação de Data Warehousing no Cadastro de Ficha Limpa do TSE Mateus Ferreira Silva, Luís Gustavo Corrêa Lira, Marcelo Fernandes Antunes, Tatiana Escovedo, Rubens N. Melo mateusferreiras@gmail.com, gustavolira@ymail.com,

Leia mais

Business Intelligence Um enfoque gerencial para a Inteligência do Negócio.Efrain Turban e outros.tradução. Bookman, 2009.

Business Intelligence Um enfoque gerencial para a Inteligência do Negócio.Efrain Turban e outros.tradução. Bookman, 2009. REFERÊNCIAS o o Business Intelligence Um enfoque gerencial para a Inteligência do Negócio.Efrain Turban e outros.tradução. Bookman, 2009. Competição Analítica - Vencendo Através da Nova Ciência Davenport,

Leia mais

Thiago Locatelli de OLIVEIRA, Thaynara de Assis Machado de JESUS; Fernando José BRAZ Bolsistas CNPq; Orientador IFC Campus Araquari

Thiago Locatelli de OLIVEIRA, Thaynara de Assis Machado de JESUS; Fernando José BRAZ Bolsistas CNPq; Orientador IFC Campus Araquari DESENVOLVIMENTO DE AMBIENTE PARA A GESTÃO DO CONHECIMENTO RELACIONADO AOS DADOS PRODUZIDOS PELO SISTEMA DE GERENCIAMENTO DE TRANSITO DA CIDADE DE JOINVILLE/SC PARTE I Thiago Locatelli de OLIVEIRA, Thaynara

Leia mais

Uma análise de ferramentas de modelagem e gerência de metadados aplicadas ao projeto de BI/DW-UFBA

Uma análise de ferramentas de modelagem e gerência de metadados aplicadas ao projeto de BI/DW-UFBA Universidade Federal da Bahia Instituto de Matemática Departamento de Ciência da Computação MATA67 Projeto Final II Uma análise de ferramentas de modelagem e gerência de metadados aplicadas ao projeto

Leia mais

Integração Access-Excel para produzir um sistema de apoio a decisão que simula um Data Warehouse e OLAP

Integração Access-Excel para produzir um sistema de apoio a decisão que simula um Data Warehouse e OLAP Integração Access-Excel para produzir um sistema de apoio a decisão que simula um Data Warehouse e OLAP Wílson Luiz Vinci (Faculdades IPEP) wilson@cnptia.embrapa.br Marcelo Gonçalves Narciso (Embrapa Informática

Leia mais

Técnicas de Business Intelligence na Análise de Dados de Produção. Rafael Deitos

Técnicas de Business Intelligence na Análise de Dados de Produção. Rafael Deitos Copyright 2014-15 OSIsoft, LLC. 1 Técnicas de Business Intelligence na Análise de Dados de Produção Presented by Felipe Trevisan Rafael Deitos Copyright 2014-15 OSIsoft, LLC. Sumário Contextualização Itaipu

Leia mais

ACOMPANHAMENTO TESTE 6. Fonte: Carlos Barbieri. Fonte: Carlos Barbieri

ACOMPANHAMENTO TESTE 6. Fonte: Carlos Barbieri. Fonte: Carlos Barbieri PÓS-GRADUAÇÃO LATO SENSU Curso: Banco de Dados Disciplina: Data Warehouse e Business Intelligence Professor: Fernando Zaidan Unidade 2.1 - Cubos 2012 ACOMPANHAMENTO IMPLEMENTAÇÃO 8 7 9 TESTE 6 CONSTRUÇÃO

Leia mais

Data Warehouse Granularidade. rogerioaraujo.wordpress.com twitter: @rgildoaraujo - rgildoaraujo@gmail.com 1

Data Warehouse Granularidade. rogerioaraujo.wordpress.com twitter: @rgildoaraujo - rgildoaraujo@gmail.com 1 Data Warehouse Granularidade rogerioaraujo.wordpress.com twitter: @rgildoaraujo - rgildoaraujo@gmail.com 1 Granularidade A granularidade de dados refere-se ao nível de sumarização dos elementos e de detalhe

Leia mais

ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO

ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO IMPLEMENTANDO UMA SOLUÇÃO OLAP UTILIZANDO SOFTWARE LIVRE CURITIBA PR 2009 RACHEL TEREZA MENEGAZZO IMPLEMENANDO

Leia mais

Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados

Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Disciplina: Ferramentaspara Tomadade Decisão Prof.: Fernando Hadad Zaidan Unidade 1.2 1 Conceitos Iniciais Tomada de Decisão, Modelagem

Leia mais

Administração de dados - Conceitos, técnicas, ferramentas e aplicações de Data Mining para gerar conhecimento a partir de bases de dados

Administração de dados - Conceitos, técnicas, ferramentas e aplicações de Data Mining para gerar conhecimento a partir de bases de dados Universidade Federal de Pernambuco Graduação em Ciência da Computação Centro de Informática 2006.2 Administração de dados - Conceitos, técnicas, ferramentas e aplicações de Data Mining para gerar conhecimento

Leia mais

Prova INSS RJ - 2007 cargo: Fiscal de Rendas

Prova INSS RJ - 2007 cargo: Fiscal de Rendas Prova INSS RJ - 2007 cargo: Fiscal de Rendas Material de Apoio de Informática - Prof(a) Ana Lucia 53. Uma rede de microcomputadores acessa os recursos da Internet e utiliza o endereço IP 138.159.0.0/16,

Leia mais

ADMINISTRAÇÃO DOS RECURSOS DE DADOS

ADMINISTRAÇÃO DOS RECURSOS DE DADOS Capítulo 7 ADMINISTRAÇÃO DOS RECURSOS DE DADOS 7.1 2003 by Prentice Hall OBJETIVOS Por que as empresas sentem dificuldades para descobrir que tipo de informação precisam ter em seus sistemas de informação?

Leia mais

Curso de Engenharia de Sistemas e Informática - 5º Ano. Ficha T. Prática n.º 1

Curso de Engenharia de Sistemas e Informática - 5º Ano. Ficha T. Prática n.º 1 Análise Inteligente de Dados Objectivo: Curso de Engenharia de Sistemas e Informática - 5º Ano Ficha T. Prática n.º 1 Estudo do paradigma multidimensional com introdução de uma extensão ao diagrama E/R

Leia mais

Business Intelligence para Computação TítuloForense. Tiago Schettini Batista

Business Intelligence para Computação TítuloForense. Tiago Schettini Batista Business Intelligence para Computação TítuloForense Tiago Schettini Batista Agenda Empresa; Crescimento de Dados; Business Intelligence; Exemplos (CGU, B2T) A empresa Empresa fundada em 2003 especializada

Leia mais

Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI

Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI Requisitos de business intelligence para TI: O que todo gerente de TI deve saber sobre as necessidades reais de usuários comerciais para BI Janeiro de 2011 p2 Usuários comerciais e organizações precisam

Leia mais

01/12/2009 BUSINESS INTELLIGENCE. Agenda. Conceito. Segurança da Informação. Histórico Conceito Diferencial Competitivo Investimento.

01/12/2009 BUSINESS INTELLIGENCE. Agenda. Conceito. Segurança da Informação. Histórico Conceito Diferencial Competitivo Investimento. BUSINESS INTELLIGENCE Agenda BI Histórico Conceito Diferencial Competitivo Investimento Segurança da Objetivo Áreas Conceito O conceito de Business Intelligencenão é recente: Fenícios, persas, egípcios

Leia mais

Uma Arquitetura de Gestão de Dados em Ambiente Data Warehouse

Uma Arquitetura de Gestão de Dados em Ambiente Data Warehouse Uma Arquitetura de Gestão de Dados em Ambiente Data Warehouse Alcione Benacchio (UFPR) E mail: alcione@inf.ufpr.br Maria Salete Marcon Gomes Vaz (UEPG, UFPR) E mail: salete@uepg.br Resumo: O ambiente de

Leia mais

UNIVERSIDADE DO EXTREMO SUL CATARINENSE - UNESC CURSO DE PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM MBA EM GESTÃO EMPRESARIAL DÉBORA EULÁLIA TANQUELLA GOMES

UNIVERSIDADE DO EXTREMO SUL CATARINENSE - UNESC CURSO DE PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM MBA EM GESTÃO EMPRESARIAL DÉBORA EULÁLIA TANQUELLA GOMES UNIVERSIDADE DO EXTREMO SUL CATARINENSE - UNESC CURSO DE PÓS-GRADUAÇÃO ESPECIALIZAÇÃO EM MBA EM GESTÃO EMPRESARIAL DÉBORA EULÁLIA TANQUELLA GOMES AVALIAÇÃO DE UMA FERRAMENTA DE BUSINESS INTELLIGENCE PARA

Leia mais

Arquiteturas de DW e Abordagens de Implementação. Arquiteturas e Abordagens de Implementação

Arquiteturas de DW e Abordagens de Implementação. Arquiteturas e Abordagens de Implementação Curso de Dwing TecBD-DI PUC-Rio Prof. Rubens Melo Arquiteturas de DW e Abordagens de Implementação Arquiteturas e Abordagens de Implementação Arquitetura adequada é fundamental Infra-estrutura disponível

Leia mais

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Diretoria de Sistema - DS Superintendência de Arquitetura de Sistemas - SAS Gerência de Arquitetura de Informação - GAAS

Leia mais

UNIVERSIDADE DO SUL DE SANTA CATARINA MICHEL ANGELO DA SILVA DARABAS

UNIVERSIDADE DO SUL DE SANTA CATARINA MICHEL ANGELO DA SILVA DARABAS UNIVERSIDADE DO SUL DE SANTA CATARINA MICHEL ANGELO DA SILVA DARABAS CONSTRUINDO SOLUÇÕES DE BUSINESS INTELLIGENCE COM PENTAHO BI SUITE COMMUNITY EDITION (CE) Palhoça 2012 MICHEL ANGELO DA SILVA DARABAS

Leia mais

KDD E MINERAÇÃO DE DADOS:

KDD E MINERAÇÃO DE DADOS: KDD E MINERAÇÃO DE DADOS: Revisão em Data Warehouses Prof. Ronaldo R. Goldschmidt ronaldo@de9.ime.eb.br rribeiro@univercidade.br geocities.yahoo.com.br/ronaldo_goldschmidt 1 DATA WAREHOUSES UMA VISÃO GERAL

Leia mais

Uma análise multidimensional dos dados estratégicos da empresa usando o recurso OLAP do Microsoft Excel

Uma análise multidimensional dos dados estratégicos da empresa usando o recurso OLAP do Microsoft Excel Uma análise multidimensional dos dados estratégicos da empresa usando o recurso OLAP do Microsoft Excel Carlos Alberto Ferreira Bispo (AFA) cafbispo@siteplanet.com.br Daniela Gibertoni (FATECTQ) daniela@fatectq.com.br

Leia mais

CEP 97420-000 São Vicente do Sul RS Brasil. filipe-kulinski@hotmail.com, {maicon.amarante, eliana.zen} @iffarroupilha.edu.br

CEP 97420-000 São Vicente do Sul RS Brasil. filipe-kulinski@hotmail.com, {maicon.amarante, eliana.zen} @iffarroupilha.edu.br 109 Utilização de Businnes Intelligence para análise de evasão escolar nos diferentes níveis de ensino do Instituto Federal Farroupilha Campus São Vicente do Sul Filipe Kulinski Mello 1, Eliana Zen 1,

Leia mais