SISTEMA DE OBTENÇÃO DE RECOMENDAÇÕES PARA … · 0 edson roberto duarte weren sistema de...

0

EDSON ROBERTO DUARTE WEREN

SISTEMA DE OBTENÇÃO DE RECOMENDAÇÕES PARA ANÁLISE

DE RUÍDO AMBIENTAL

CANOAS, 2011

1



DE RUÍDO AMBIENTAL

Trabalho de conclusão apresentado para a banca examinadora do curso de Ciência da Computação do Centro Universitário La Salle, como exigência parcial para a obtenção do grau de Bacharel em Ciência da Computação.

Orientação: Profª. Dra. Patrícia Kayser Vargas Mangan

CANOAS, 2011

2



DE RUÍDO AMBIENTAL

Trabalho de conclusão aprovado como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação do Curso de Ciência da Computação do Centro Universitário La Salle – UNILASALLE.

Aprovado pela banca examinadora em 28 de Julho de 2011.

BANCA EXAMINADORA:

________________________________ Prof. Me. Roberto Petry

Unilasalle

________________________________ Prof. Me. Rafael Kunst

Unilasalle

3

AGRADECIMENTOS

Agradeço a professora e orientadora Patrícia Kayser Vargas Mangan por

compartilhar de seus conhecimentos e contribuir para o desenvolvimento desta

pesquisa.

Aos professores Abraham Lincoln Rabelo de Sousa; Alessandra Dahmer; Eder

Stone Fontoura; Mozart Lemos de Siqueira; Roberto Petry; Simão Sirineo Toscani;

Rafael Kunst e Roberto Scheid, que compartilharam seu conhecimento comigo

durante estes anos de graduação.

Também agradeço a todos os colegas que compartilharam desta caminhada.

A todos, meu muito obrigado.

4

RESUMO

A realização de avaliações de ruído ambiental em pontos georreferenciados, em

função da construção da usina Fase-C da Eletrobrás-Companhia de Geração

Térmica de Energia Elétrica (CGTEE) é exigida através de resoluções do Conselho

Nacional do Meio Ambiente (CONAMA). Em muitos destes pontos em alguns

períodos foram detectados índices de ruído acima dos limites estabelecidos pela

legislação, o que levou a suspeita de possíveis influências atmosféricas.

Considerando que para este contexto especifico não foi encontrado registro na

literatura, técnicas computacionais com o objetivo de tratar este problema foram

investigadas e serão descritas ao longo deste trabalho.O principal objetivo foi

estabelecer padrões nas avaliações já realizadas, permitindo a possibilidade da

criação de sistemas de recomendações de forma a melhorar a qualidade das futuras

coletas. Dentre os objetivos específicos, foi realizada uma análise dos algoritmos de

mineração de dados presentes na ferramenta Waikato Environment for Knowledge

Analysis (WEKA). Constatando-se a eficácia de construção dos fluxos ETL e DW

utilizando os roteiros, diagramas e arquétipos propostos, quatro algoritmos mais

eficientes de mineração de dados considerando o problema proposto, foram

identificados. Assim, uma das principais contribuições deste trabalho é a definição

de qual algoritmo de mineração de dados é mais indicado para busca de padrões

considerando a base de dados testada.

Palavras-chave: ETL. DW. Data mining. Análise de Ruído Ambiental.

5

ABSTRACT

The realization of environmental noises evaluations in georeferenced points, in

function of the construction of the Fase-C plant of Eletrobrás – Companhia de

Geração Térmica de Energia Elétrica (CGTEE) is exhibited thought resolutions of the

Conselho Nacional do Meio Ambiente (CONAMA). In many of these points in some

periods were detected noise levels above the limits established for the legislation,

which led the suspicion of possible atmospheric influences. Considering that for this

specific context it was not found register of literature, computational techniques with

the objective of deal with this problem it was investigated and will be describe

throughout this work. The principal objective was to establish the patterns in the

evaluations already made, allowing the possibility of the creation of recommendation

systems to improve the quality of future collects. The mining algorithms of the

present data in the tool Waikato Environment for Knowledge Analysis (WEKA) also

were analyzed, as one of the specific objectives. We identified four more efficient of

data mining algorithms considering the proposed problem, considering the efficiency

of the flow ETL and DW construction using the routs, diagrams and archetypes

proposed. Thus, one of the principal contributions of this work is the definition of

which data mining algorithm is the most indicate for the search of patterns

considering the tested data base.

Keywords. ETL. DW. Data Mining. Environmental Noise Analysis

6

LISTA DE FIGURAS

Figura 1 – Exemplo de um modelo multidimensional de DW .................................... 19

Figura 2 - Abstração de um cubo de dados do DW ................................................... 21

Figura 3 – Instrumento de Medição e Software ......................................................... 28

Figura 4 - Exemplo de um registro adquirido do Site do INMET ............................... 29

Figura 5 - Exemplo de um registro adquirido com o coordenador do INMET ............ 30

Figura 6 – Resultado do primeiro fluxo de trabalho ................................................... 39

Figura 7 – Resultado do décimo sexto e ultimo fluxo de trabalho ............................. 40

Figura 8 - Dimensões hierarquias embutidas ............................................................ 44

Figura 9 - Descrição das 5 etapas e 3 níveis de diagramas para o modelo DW ....... 47

Figura 10 – Do nível conceitual ao nível físico .......................................................... 48

Figura 11 - Representação de um diagrama de componente ................................... 49

Figura 12 – Representação de um nodo em um diagrama de implementação ......... 50

Figura 13 - Nível 1 do Esquema Conceitual de um DW ............................................ 50



Figura 16 - Esquema físico da origem dos dados: diagrama de implementação ...... 53

Figura 17 - Esquema físico da origem dos dados: diagrama de componente ........... 54

Figura 18 - Esquema físico da origem dos dados: diagrama de implementação ...... 54

Figura 19 - Diagrama de transporte e integração Diagrama de Implementação ....... 55

Figura 20 - Diagrama customizado de transporte: Diagrama de Implementação...... 56

Figura 21 - Menus disponibilizados para navegação ................................................ 57

Figura 22 - Interface gráfica do WEKA. ..................................................................... 60

Figura 23 - Exemplo de Validação Cruzada em 10 blocos ........................................ 64

Figura 24 – Resultados para o ponto 1com algoritmos Bagging e DecisionStump ... 67

Figura 25 – Resultados para o ponto 1 com algoritmos J48Graft e Part ................... 69

Resultados do segundo fluxo ETL ............................................................................. 74

Resultados do terceiro fluxo ETL .............................................................................. 74

Resultados do quarto fluxo ETL ................................................................................ 75

Resultados do quinto fluxo ETL ................................................................................. 75

Resultados do sexto fluxo ETL .................................................................................. 75

Resultados do sétimo fluxo ETL ................................................................................ 76

7

Resultados do oitavo fluxo ETL ................................................................................. 76

Resultados do nono fluxo ETL .................................................................................. 77

Resultados do décimo fluxo ETL ............................................................................... 77

Resultados do décimo quarto fluxo ETL .................................................................... 78

Resultados do décimo quinto fluxo ETL .................................................................... 79

Resultados para o ponto 2 com algoritmos Bagging e DecisionStump ..................... 82




Resultados para o ponto 6 com algoritmo Bagging e DecisionStump ....................... 84

Resultados para o ponto 7 com algoritmo Bagging e DecisionStump ....................... 85


Resultados para o ponto 3 com algoritmos J48Graft e Part ...................................... 86


Figura 35 - Resultados para o ponto 7 com algoritmos J48Graft e Part .................... 87


8

LISTA DE QUADROS

Quadro 1 – Comparação dos fluxos ETL construídos com ferramentas comerciais . 35

Quadro 2 – Transformações executadas pelos fluxos ETL ....................................... 39

Quadro 3 - Características das ferramentas de aprendizagem de máquinas

pesquisadas .............................................................................................................. 61

Fonte: Autoria própria, 2011 (construída a partir de informações de ROCHA, 2005).

.................................................................................................................................. 61

Quadro 4 – Nível de critério de avaliação Nível de Critério de Avaliação (NCA) para

ambientes externos, em dB(A) .................................................................................. 62

Quadro 5 – Avaliação dos algoritmos para 70 dB ..................................................... 65

Quadro 6 – Avaliação dos algoritmos para 60 dB ..................................................... 65

Avaliação dos algoritmos para 70 dB ........................................................................ 80

Avaliação dos algoritmos para 60 dB ........................................................................ 81

9

LISTA DE TABELAS

Tabela 1 - Exemplo de Resumo ................................................................................ 24

10

LISTA DE ABREVIATURAS

ABNT – Associação Brasileira de Normas Técnicas

ANSI – American National Standards Institute

CCS - Client Conceptual Schema

CETESB – Companhia de Tecnologia de Saneamento Ambiental

CGTEE – Companhia de Geração Térmica de Energia Elétrica

CLS - Cliente Logical Schema

CONAMA- Conselho Nacional do Meio Ambiente

CPS - Client Physical Schema

CPU – Central Processing Unit

CSV – Comma Separated Values

CTD - Customization Transportation Diagram

dB – Decibel

DM – Data Mart

DSS – Decision Support System

DW – Data Warehouse

DWCS - Data Warehouse Conceptual Schema

DWLS - Data Warehouse Logical Schema

DWPS - Data Warehouse Physical Schema

EIS - Executive Information System

ER – Entidade Relacionamento

ETL – Extract Transform Load

GB - Gigabyte

IBAMA – Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais Renováveis

INMET – Instituto Nacional de Meteorologia

IPVR - Institute For Parallel And Distributed High Performance Systems

ITD - Integration Transportation Diagram

KB - Kilobyte

LEQ – Equivalent Level

LIBSVM - Library Support Vector Machines

MEN - Memória

MW - Megawatt

11

NBR – Norma Brasileira Regulamentadora

NCA – Nível de Critério de Avaliação

OLAP – On-Line Analytical Processing

OLTP – On-Line Transaction Processing

OS – Operating System

ROLAP – Relational On Line Analytical Processing

SCS - Source Conceptual Schema

SGBD – Sistema de Gerenciamento de Banco de Dados

SNNS - Stuttgart Neural Network Simulator

SPS - Source Physical Schema

SQL – Structured Query Language

SVM - Support Vector Machine

SW - Software

UML – Unified Modeling Language

WEKA – Waikato Environment for Knowledge Analysis

12

SUMÁRIO

1 INTRODUÇÃO ....................................................................................................... 14

1.1 Contexto do Problema de Pesquisa .............. .................................................. 14

1.2 Definição do Problema ......................... ............................................................. 15

1.3 Objetivo ...................................... ........................................................................ 16

1.4 Solução e Metodologia ......................... ............................................................ 16

1.5 Estrutura do texto ............................ ................................................................. 17

2 REFERENCIAL TEÓRICO ............................. ........................................................ 18

2.1 Data Warehouse ................................ ................................................................ 18

2.1.1 Modelagem de um DW ..................................................................................... 20

2.2 Extração, Transformação e Carga de Dados (ETL) ........................................ 22

2.3 Data Mining ................................... ..................................................................... 23

3 OBTENÇÃO DOS DADOS .............................. ...................................................... 27

3.1 Origem dos Dados .............................. .............................................................. 27

3.1.1 Pressão Sonora ................................................................................................ 27

3.1.2 Atmosféricos .................................................................................................... 29

3.1.3 Produção de Energia ....................................................................................... 30

3.2 Extract Tranform Load (ETL) ................... ......................................................... 31

3.2.1 Ferramentas Utilizadas..................................................................................... 31

3.2.2 Metodologia do ETL ......................................................................................... 32

3.2.2.1 Descrição das transformações executadas sobre as bases de dados .......... 36

4 DATA WAREHOUSE .................................. ........................................................... 41

4.1 Notações preliminares ......................... ............................................................. 41

4.2 Roteiro de construção ......................... ............................................................. 42

4.3 Arquétipos .................................... ..................................................................... 46

4.3.1 – DWCS ........................................................................................................... 50

4.3.2 – DWLS ............................................................................................................ 51

4.3.3 – DWPS ............................................................................................................ 52

4.3.3.4 Esquema físico para o cliente ....................................................................... 56

4.3.3.5 Diagrama personalizado de transporte.......................................................... 56

4.4 – WinDesktopClient ............................ ............................................................... 57

5 DESCOBERTA DE CONHECIMENTO ...................... ............................................ 59

5.1 Ferramentas Pesquisadas ....................... ......................................................... 59

13

5.2 Organização dos Dados de Entrada .............. .................................................. 61

5.3 Comparação e Avaliação ........................ .......................................................... 63

5.4 Resultados das Comparações .................... ..................................................... 64

5.5 Descrição dos algoritmos selecionados ......... ................................................ 65

5.6 Regras geradas ................................ ................................................................. 66

REFERÊNCIAS ......................................................................................................... 72

APENDICE A – DETALHAMENTO DO RESULTADO DOS FLUXOS E TL ............. 74

APENDICE B – QUADROS COMPARATIVOS DOS 71 ALGORITMOS DE

DATAMING PARA CADA LIMITE DE LEQ .................. ............................................ 80

APENDICE C – DETALHAMENTO DAS REGRAS GERADAS ...... ......................... 82

14

1 INTRODUÇÃO

1.1 Contexto do Problema de Pesquisa

A Companhia de Geração Térmica de Energia Elétrica (CGTEE) foi constituída

em julho de 1997. Em novembro de 1998, seu controle acionário foi transferido para

a União. Posteriormente, em 31 de julho de 2000, a CGTEE tornou-se uma empresa

do Sistema Eletrobrás. A CGTEE possui os direitos de exploração e produção de

energia elétrica através de suas usinas termelétricas instaladas no estado do Rio

Grande do Sul: Usina Termelétrica Presidente Médici (Candiota II), com 446

Megawatts (MW); Usina Termelétrica São Jerônimo, com 20 MW; e Nova Usina

Termelétrica de Porto Alegre - Nutepa, com 24 MW.

Em 2007, a CGTEE iniciou a construção de Candiota III (Fase C). Contando

com a parceria do grupo chinês Citic International Contracting Inc., a usina iniciará

operações em junho de 2010, com uma potência instalada de 350MW. No que se

refere a esta construção a RESOLUÇÃO/ Conselho Nacional do Meio Ambiente

(CONAMA)/Nº 001 de 08 de março de 1990 estabelece que na execução dos

projetos de construção ou de reformas de edificações para atividades heterogêneas,

o nível de som produzido por uma delas não poderá ultrapassar os níveis

estabelecidos pela Norma Brasileira Regulamentadora (NBR) 10152 - Avaliação do

Ruído em Áreas Habitadas visando o conforto da comunidade, da Associação

Brasileira de Normas Técnicas (ABNT) (NBR, 1999).

De forma a monitorar o nível de ruído produzido por este empreendimento, a

CGTEE no segundo semestre de 2006 criou o "Procedimento para determinação do

nível de ruído em ambientes externos". Neste procedimento foram definidos 9

pontos georreferenciados para coleta mensal de ruído nos mesmos. A coleta é

realizada por um período de 10 minutos tempo necessário para estabilizar o audio-

dosimetro, que é um aparelho utilizado para medir a intensidade sonora, utilizando a

unidade de decibéis (dB).

Este aparelho é portátil possuindo uma bateria, mostrador digital, um microfone

tendo ainda a possibilidade de descarregar os resultados das coletas em um

15

computador. Uma das condições para coleta é sempre que possível medir-se a

velocidade do vento, utilizando-se anemômetro ou a escala Beaufort.

Com relação a escala Beaufort esta é composta pelos seguintes atributos:

força, metros/segundo, quilômetros/hora, influência no mar e influência em terra. A

situação-problema ou questão de pesquisa relacionada a esta escala e que será

abordada nesta pesquisa envolve prever e evitar a influência da velocidade de vento

nos resultados das coletas dos pontos já citados. Existem evidências dessa

influência do vento, uma vez que a CETESB L11.032 indica que deve ser anotada a

ocorrência de vento (CETESB, 1992) e que a Norma CETESB : L11.031 indica que

para a obtenção de um nível de ruído de fundo representativo das condições

ambientais a coleta só deve ser realizada na ausência de precipitação atmosférica e

em condições em que o vento não interfira nas medições (CETESB, 1992). No

entanto, não existe uma relação explícita de influência quantitativa. Além disso, não

existe legislação ou normatização para tratar e/ou isolar esta influência não

permitindo calcular o ruído real.

1.2 Definição do Problema

De modo geral esta proposta apresenta o seguinte problema de pesquisa:

Como auxiliar os agentes de coleta de campo, através de mecanismos

computacionais, quanto a tomada de decisão que se refere a escolha de condições

atmosféricas mais propícias a fim de diminuir a possibilidade de influências externas

nas coletas já citadas?

A partir desta proposição, no contexto da Ciência da Computação, busca-se

também responder: Quais técnicas e algoritmos podem ser usados/combinados para

realizar a análise de dados necessária para tratar a detecção de ruído?

16

1.3 Objetivo

O principal objetivo deste estudo é detectar padrões nas coletas já realizadas,

permitindo a possibilidade da criação de sistemas de recomendações de forma a

melhorar a qualidade das futuras coletas, contemplando o estabelecido pelo

Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais Renováveis (IBAMA)

através de suas resoluções.

Como objetivos específicos destacam-se:

a) Obter o estado da arte em Data Warehouse (DW) e Data Mining;

b) Construir um DW a partir de bases de dados distintas e heterogêneas;

c) Utilizar Data Mining para analisar possíveis relações entre os dados

coletados.

1.4 Solução e Metodologia

Sobre o ponto de vista computacional, uma metodologia foi utilizada com

objetivo de testar as evidências da influência do vento através da combinação,

adaptação e avaliação de técnicas de ETL além das técnicas como DW e Data

Mining, realizando a tarefa específica de recomendar a execução ou não das coletas

em determinado período. Os dados utilizados são dados reais cedidos pela CGTEE

que realiza medições sistemáticas de ruído.

Como caracterização metodológica, segundo Silva e Menezes (2005) o

presente trabalho consiste de uma pesquisa de campo através da qual obtêm-se

dados sobre os fenômenos atmosféricos e de produção da usina da CGTEE em

Candiota.

Utilizou-se os métodos Exploratório e Experimental, conforme Wainer (2007)

com o objetivo de formulação de questões a respeito da influência destes

fenômenos sobre coletas de ruído ambiental. Estes métodos foram empregados

tendo como finalidade: (1) desenvolver e testar hipóteses no que diz respeito a

relações de causa e efeito; (2) aumentar a familiaridade sobre estes fenômenos,

17

para realização de uma pesquisa futura mais precisa; e (3) modificar e clarificar

conceitos.

Para atingir o objetivo e as metas propostas, foram definidas as seguintes

etapas:

a) recuperar dados armazenados nas diversas bases de dados através de

rotinas de Extração Transformação e Carga do inglês Extract Transform Load (ETL),

e posterior carga no Data Warehouse (DW). Estes dados por padrão possuem duas

características essenciais: são integrados e históricos. A natureza integrada provê

os fundamentos para execução de análise corporativa e sua natureza histórica, as

bases para análises de tendências e a observação da empresa por um grande

espectro de tempo (INMON, 1997);

b) após a geração do DW, realizar um trabalho Data Mining através da análise

de técnicas de mineração de dados tradicionais, de forma a buscar relação entre os

decibéis coletados, a energia gerada e velocidade do vento em determinado horário.

Esta meta exigirá um levantamento do estado da arte em mineração de dados;

c) gerar um conjunto de recomendações para a execução de coletas com maior

qualidade a partir desta aplicação/adaptação.

Os resultados obtidos indicam que os algoritmos Bagging, DecicionStump,

J48Graft e Part, presentes nas ferramenta Waikato Environment for Knowledge

Analysis (WEKA) mostraram-se eficientes na identificação de relações entre os

dados coletados.

1.5 Estrutura do texto

O desenvolvimento desta monografia está organizada na seguinte forma: o

referencial teórico é apresentado no capítulo 2. No capítulo 3 é apresentado como

foram obtidos os dados para o experimento. No capítulo 4 será descrita as

características do DW que compõem esta monografia. No capítulo 5 são

apresentados os testes com algoritmos de mineração de dados juntamente com os

resultados e finalmente no capítulo 6 há a conclusão do trabalho.

18

2 REFERENCIAL TEÓRICO

Para a realização deste trabalho, faz-se necessário o estudo de alguns

conceitos básicos e o levantamento do estado da arte das tecnologias disponíveis.

Assim sendo nas seções 2.1, 2.2 e 2.3 serão apresentados os aspectos sobre a

modelagem de Data Warehouse (DW), os fluxos Extract Transformation Load (ETL)

e Data Mining respectivamente.

2.1 Data Warehouse

Segundo Machado (2004) o DW pode ser definido como um conjunto de

armazéns de dados onde a história da empresa, seus clientes, fornecedores e

operações se mantêm disponíveis e acessíveis para consultas e análises. Para

possibilitar estas consultas, surgiram as ferramentas On Line Analytical Processing

(OLAP) que permitem a análise dos dados e descoberta das informações

desconhecidas, disponibilizar a visualização dos dados sob diversas perspectivas e

a capacidade de navegar no nível de detalhe da informação.

No DW a modelagem realizada é a multidimensional, técnica estruturada

desenvolvida para a obtenção de modelo de dados de simples entendimento e alta

performance de acesso de dados. Como um DW é um banco de dados orientado

somente para a consulta de seus dados, a orientação da técnica criou os

denominados modelos estrela como o apresentado na Figura 1.

19

Figura 1 – Exemplo de um modelo multidimensional de DW Fonte: Machado, 2004.

Conforme Machado (2004), justifica-se a aplicação da tecnologia de DW em

uma empresa que apresente:

a) Várias plataformas de software; b) Constantes alterações nos sistemas transacionais corporativos; c) Dificuldade acentuada na recuperação de dados históricos em períodos superiores ao ano atual; d) Falta de padronização e integração dos dados existentes nos diversos sistemas; e) Carência de documentação e segurança no armazenamento dos dados; f) Dificuldades de aplicação de sistemas Executive Information System (EIS) ou Decision Support System (DSS) devido a dependências múltiplas de sistemas corporativos; Tomando como base o modelo de montagem do DW apresentado, a empresa pode optar por construí-lo em uma base global ou em bases teoricamente locais de acordo com as áreas de negócios. Isso implica na utilização de arquiteturas específicas para a construção de um DW, as quais têm evoluído desde o principio dos conceitos de DW até o momento atual sempre em busca do sucesso de sua utilização. (MACHADO, 2004, P. 26).

20

Além disso, deve-se considerar as diversas ferramentas disponíveis em um

DW. Assim, o sucesso de um DW pode depender da disponibilidade da ferramenta

certa para as necessidades de seus usuários. Para garantir essa flexibilidade,

normalmente são empregadas:

a) Ferramentas para pesquisa e relatórios: geração de relatórios e análise de

dados históricos;

b) Ferramentas do tipo OLAP: permite ao usuário analisar o porquê dos

resultados obtidos;

c) Data Mining: permite ao usuário avaliar tendências e padrões não

conhecidos (processo estudado no capitulo 5 desta monografia).

Além das ferramentas já citadas um elemento no DW é o Data Mart (DM), que

representa um subconjunto de dados do DW. Permite acesso descentralizado

servindo de fonte para os dados que comporão os bancos de dados individuais. Os

dados do DM são direcionados a um departamento ou uma área específica de

processos do negócio. O DM, normalmente, é modelado em um esquema estrela de

acordo com as necessidades específicas do usuário final. Uma das principais

vantagens de seu emprego é a possibilidade de retorno rápido, garantindo um maior

envolvimento do usuário final, capaz de avaliar os benefícios extraídos de seu

investimento.

2.1.1 Modelagem de um DW

A modelagem inicial de um DW tem como base o mesmo padrão de um

sistema transacional, ou seja, deve representar uma abstração do mundo real,

comumente esta abstração é representada graficamente por modelagem Entidade

Relacionamento (ER).

Após a modelagem ER, é executada a modelagem multidimensional conforme

ilustrado na Figura 2, a modelagem multidimensional é 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ócios, sendo utilizada para sumarizar e reestruturar dados e

apresenta-los em visões, sendo formado por três elementos básicos:

21

a) Fatos: Um fato é uma coleção de itens de dados compostos de dados de

medidas e de contexto;

b) Dimensões: São elementos que participam de um fato, assunto de negócios,

podendo ser mais de 3;

c) 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

deste fato.

Figura 2 - Abstração de um cubo de dados do DW Fonte: Machado, 2004.

Com a concepção deste cubo, finalmente é possível executar operações sobre

ele. Estas operações estão descritas a seguir:

a) Drill Down e Roll Up: Permite a movimentação da visão de dados ao longo

dos níveis hierárquicos de uma dimensão;

b) Drill Across: Permite que o usuário pule um nível intermediário dentro de

uma mesma dimensão;

c) Drill Throught: Permite que a passagem de uma informação contida em uma

dimensão para outra;

d) Slice and Dice: São operações para realizar a navegação no cubo e

visualizá-lo sobre várias perspectivas. Slice é a operação que corta o cubo, mas

mantém a mesma perspectiva de visualização dos dados. Dice é a mudança de

perspectiva de visão, o que pode ser entendido como a extração de um sub-cubo.

22

Um dos fatores importantes para a modelagem física de dados, independente

da arquitetura e implementação a serem utilizadas, é a definição de granularidade

de dados. A granularidade de dados refere-se ao nível de sumarização dos

elementos e de detalhe disponíveis nos dados, considerando o mais importante

aspecto do projeto de um DW. Esta granularidade afete diretamente o volume de

dados que será armazenado e tipo de consulta que se pretende fazer.

Ilustrando a necessidade de se tratar a granularidade dos dados para um

projeto de DW, o projetista deve pesar, por exemplo, qual seria a utilidade desse DW

para estratégia de negócios de vendas, se a granularidade for baixa, tratando as

vendas mês a mês ou granularidade alta, tratando as vendas por cada operação

realizada.

2.2 Extração, Transformação e Carga de Dados (ETL)

Segundo Vassiliadis et al (2009) e Muñoz et al (2009) atividades de extração

transformação carga ETL são módulos de software responsáveis pelo

preenchimento de um armazém de dados com dados operacionais, que sofreram

uma série de transformações em seu caminho para o depósito. Todo o processo é

muito complexo e de grande importância para a concepção e manutenção do DW.

Um fluxo de trabalho ETL pode ser visto como um grafo dirigido. Os nós deste

gráfico são atividades e conjuntos de registros. As bordas do gráfico são relações de

provedor que combinam atividades e conjuntos de registros.

Os tipos de atividades em ETL podem ser assim descritos:

a) Atividades unárias. Estas atividades aproveitam os dados do esquema de

entrada, realizam uma transformação ou limpeza de operação para eles e

direcionam os dados processados para a saída. Atividades unárias têm exatamente

uma entrada e uma saída de bancos de dados.

Dentro de uma atividade unária, as combinações que podem ocorrer entre seus

tuplas de entrada e saída são os seguintes:

− 1: 1.uma tupla de entrada é mapeada para exatamente um coleção de itens

de saída;

− 1:M tuplas de entrada é mapeada para mais de uma saída de tuplas.

23

− N:1, mais do que uma entrada de tuplas são combinados para produzir

exatamente um coleção de itens de saída. Observar que esta relação apresenta um

conjunto de classes entre tuplas de entrada: todas as tuplas pertencentes à mesma

classe correspondem à coleção de itens de saída mesmo. Se cada tola de entrada

corresponde a no máximo de uma classe, então são classes de equivalência;

− 0:M algumas funções ou valores constantes são utilizados para produzir de

uma ou mais tuplas de saída;

− N:M a relação entre um determinado grupo de tuplas de entrada e um

determinado grupo de tuplas de saída não pode ser simplificada para uma das

categorias acima.

b) Atividades Ns-árias: Estas atividades combinam informações de múltiplas

entradas e preenchem um esquema de saída.

Esta envolve duas configurações mais utilizadas:

− Fluxo principal. Estas são atividades binárias onde um dos seus inputs é uma

parte de um fluxo principal que realizam testes em uma segunda entrada para testar

se seus valores beneficiarem ainda mais a propagação. − Combinadores. São

atividades binárias (ou n-ários em geral) cujas instâncias de saída são mais do que

uma combinação de valores do esquema de entrada.

c) Roteadores & filtros. As duas classes anteriores envolvem exatamente um

esquema de saída. É possível, no entanto, que atividades ETL possuem mais de um

esquema de saída para realizar sua tarefa. Normalmente, estas atividades são

usadas como nos seguintes casos:

− Roteadores. Estas atividades direcionam tuplas para um caminho específico

de fluxo de trabalho, de acordo com o valor de um dos seus atributos.

− Filtros. Estas atividades bloqueiam o tratamento posterior de tuplas

desnecessários e permitam a propagação de tuplas, que respeitam a um critério de

seleção específica.

2.3 Data Mining

Nesta seção será mostrado: conceito de mineração de dados; como as regras

de associação e classificação são definidas; fórmulas e propriedades que fazem

24

parte das regras de associação e classificação, sendo que ao final deste capítulo

será mostrada a evolução e combinação dos algoritmos genéricos de mineração de

dados desde a concepção do seu conceito até o estado da arte.

Segundo Geng et al (2006) a mineração de dados pode ser considerada como

um processo algorítmico que recebe dados como entrada e retorna como saídas

padrões de produtividade, tais como regras de classificação, regras de associação,

ou um resumo.

a) exemplo de regras de associação: (leite, ovos) → (pão) é uma regra de

associação que diz que quando o leite e os ovos são comprados, o pão é

susceptível de ser comprado também;

b) exemplo de regras de classificação: se um cliente que tem um emprego e

uma renda anual maior de $ 50.000, este é classificado como tendo um bom crédito;

c) exemplo de resumo: as três primeiras colunas da Tabela 1 formam um

resumo.

Tabela 1 - Exemplo de Resumo

Fonte: Geng, Hamilton, 2006.

As Regras de associação são normalmente utilizadas como ferramentas

descritivas, regras de classificação, por outro lado, são utilizados como um meio de

prever as classificações de dados invisíveis.

Ambas possuem duas etapas:

Regras de associação:

a) encontrar itemsets freqüentes, ou seja, todos os itemsets com suporte igual

ou superior a um limite;

b) gerar regras de associação baseado no itemsets freqüentes.

Regras de classificação:

a) usar heurística para selecionar pares atributo-valor a ser usado para formar

as condições da regulamentação;

25

b) utilizar métodos de poda, para evitar pequenas disjunções.

Atualmente não há um acordo generalizado sobre a definição formal do que é

interessante (classificar ou associar) ou não de se mapear em um trabalho de

mineração de dados. Um conceito amplo enfatiza características que devem ser

levadas em consideração como: concisão, cobertura, confiabilidade, peculiaridade,

diversidade, novidade, surpresa, utilidade e acionabilidade.

Estes nove critérios específicos são utilizados para determinar se existe ou não

um padrão interessante (Geng et al, 2006):

a) Concisão: Um padrão é conciso se contém relativamente poucos pares

atributo-valor;

b) Cobertura: Um padrão é geral quando abrange um subconjunto

relativamente grande de um conjunto de dados;

c) Confiabilidade: Um padrão é confiável, se a relação descrita pelo padrão

ocorre em uma alta porcentagem de casos aplicáveis;

d) Peculiaridade: Um padrão é peculiar, se está longe de outros padrões

descobertos de acordo com alguma medida;

e) Diversidade: Um padrão é diverso, se os seus elementos diferem

significativamente entre si;

f) Novidade: Um padrão é uma novidade para uma pessoa se ele ou ela não

sabia disso antes e não é capaz de inferir que a partir de outros padrões conhecidos;

g) Surpresa: Um padrão é surpreendente (ou inesperado) se ele contradiz o

conhecimento existente de uma pessoa ou expectativas;

h) Utilidade: Um padrão é útil se o seu uso por uma pessoa, contribuir para

alcançar um objetivo;

i) Acionabilidade: é por vezes associada a uma estratégia de seleção padrão.

Estes nove critérios podem ser ainda divididos em três classificações: objetiva,

subjetiva e baseada em semântica.

a) Objetiva: medida objetiva é baseada apenas em dados brutos, não sendo

necessário conhecimento sobre o usuário ou aplicação;

b) Subjetiva: medida subjetiva leva em consideração tanto os dados e o usuário

desses dados;

c) Baseado em Semântica: medida de semântica envolve conhecimento de

domínio do usuário.

26

Durante o processo de mineração de dados, pode ser usada de três formas

para definir o que é ou não interessante além dos nove critérios já mencionados:

a) As medidas podem ser usadas para podar padrões irrelevantes durante o

processo de mineração, de modo a reduzir o espaço de busca e, assim, melhorar a

eficiência de mineração;

b) As medidas podem ser usadas para classificar os padrões de acordo com a

ordem de seus escores de interesse;

c) As medidas podem ser usadas durante o pós-processamento para

selecionar padrões interessantes.

Na prática mineração de dados são atividades que fazem uso de probabilidade

e estatística, para isso muitas notações estatísticas e propriedades se fazem

necessárias.

27

3 OBTENÇÃO DOS DADOS

Neste capitulo serão tratados aspectos relacionados com a obtenção do dados

das bases reais e posterior transformação destes, segundo as regras de negócio.

Este capitulo está organizado em duas seções, sendo tratada na seção 2.1 a técnica

utilizada para obteção dos dados. E finalmente na seção 2.2 serão apresentadas as

técnicas de construção e utilização dos fluxos ETL.

3.1 Origem dos Dados

Considerando que o objetivo desta pesquisa é verificar a relação existente

entre o nível de pressão sonora em decibéis, resultante das coletas ambientais para

licenciamento ambiental, com elementos atmosféricos e de produção da usina

termoelétrica de Candiota/RS, buscou-se acesso a base de dados confiáveis que

contivessem estas informações.

3.1.1 Pressão Sonora

Os dados referentes à pressão sonora são provenientes das coletas mensais,

realizadas pelo Departamento de Segurança e Medicina do Trabalho da Eletrobrás-

CGTEE. Estes dados são gerados pelo instrumento denominado Áudio-dosimetro Q-

400 ilustrado na Figura 3. Os dados do equipamento são transferidos para um

computador em formato proprietário através do software QuestSuite Professional.

28

Figura 3 – Instrumento de Medição e Software Fonte: Editado a partir do software QuestSuite Professional, 2011.

Os arquivos gerados por este software têm extensão “.ndat”, sendo um formato

binário. Considerando que estes arquivos somente podem ser abertos pelo software

já citado, para uso dos mesmos foi necessário o uso de uma ferramenta de

exportação ndat/txt disponível neste software. Os arquivos “.txt” poderiam ser

carregados diretamente em uma tabela Structured Query Language (SQL), porém

não seria possível estabelecer ordem para utilização destes dados. Surgiu a

necessidade da criação de um programa extrator, utilizando critérios de seleção, e,

ao encontrar dados que atendam aos critérios (data, horário e média de

ruído), transporta os dados a uma tabela no MYSQL.

Os arquivos referentes a pressão sonora dos pontos georreferenciados do

período compreendido entre janeiro de 2007 e dezembro de 2010, foram adquiridos,

através do Setor de Medicina e Segurança do Trabalho da Eletrobrás-CGTEE.

Após extração dos arquivos, a tabela resultante registrou 684 registros.

29

3.1.2 Atmosféricos

Para aquisição dos dados atmosféricos, pesquisou-se no Site do Instituto

Nacional de Meteorologia (INMET)1. Os dados referentes ao período de Janeiro de

2008 á Dezembro de 2010. Após o donwload, foi adquirido 26068 registros a

exemplo da série identificada na figura 4.

Figura 4 - Exemplo de um registro adquirido do Site do INMET Fonte: Autoria Própria, 2011.

Esta série está no formato txt seguindo o padrão de colunas separadas por “,”

e linhas separadas por “\n”.

Considerando que os dados disponíveis referente aos níveis de pressão

sonora, a partir dos quais pretende-se realizar a descoberta de conhecimento é de

um período entre janeiro de 2007 à dezembro de 2010. Foi necessário contato com

o Sr. Solismar Damé Prestes - Coordenador do 8º Distrito do INMET para aquisição

dos dados referente ao período de Janeiro á Dezembro de 2007, que não estavam

contidos no download citado anteriormente. Após o contato o coordenador enviou

por e-mail 8665 registros a exemplo da série identificada na figura 5.

1 http://www.inmet.gov.br/sonabra/dspDadosCodigo.php?QTgyNw==. Acesso em: 8 Março

2011.

30

Figura 5 - Exemplo de um registro adquirido com o coordenador do INMET Fonte: Autoria Própria, 2011.

Esta série está no formato txt seguindo o padrão de colunas separadas por

espaço e linhas separadas por “;”.

Estas duas séries foram carregadas em tabelas pré-criadas através do

seguinte comando no MySql “5.0: LOAD DATA LOCAL INFILE ' Local e nome do

arquivo com extensão txt/Comma Separated Values (cs v) ' INTO TABLE Nome da

Tabela FIELDS TERMINATED BY ' \espaço ' LINES TERMINATED BY ' \n '; ”.

Após extração de ambas as séries, cada uma das tabelas resultantes,

registraram 26068 e 8665 registros respectivamente, totalizando 34733 registros.

3.1.3 Produção de Energia

Os dados de produção de energia da Usina foram adquiridos através do setor

de programação de produção da Eletrobrás-CGTEE. Para coleta destes dados na

Usina por vários anos, tentou-se o uso de vários sistemas informatizados,

considerando que os mesmo por vários problemas de infraestrutura não ofereciam

confiabilidade. Por este fato os dados diários acabaram sendo coletados

manualmente e armazenados em planilhas MS-EXCEL. Para uso nesta pesquisa,

cada uma destas planilhas foi convertida no formato “.CSV” com o auxílio do

BrOffice.org. Surgiu a necessidade da criação de um programa extrator, que

31

combinado com a linha de comando citado na seção 3.1.2, pudesse ler esta massa

de arquivos “CSV” de uma única vez e transporta-los a uma tabela no MYSQL.

Após extração de todos estes arquivos, a tabela resultante, registrou 1460

registros.

3.2 Extract Tranform Load (ETL)

Nesta seção será descrita a metodologia para construção dos fluxos ETL, bem

como as ferramentas utilizadas para este fim.

3.2.1 Ferramentas Utilizadas

Utilizou-se o sistema de gerenciamento de banco de dados (SGBD) Mysql

essential 5.1.53-win32, que utiliza a Linguagem SQL como interface. As principais

razões para uso deste nos experimentos vinculados à esta monografia, são: Ser

livre; Bom desempenho e estabilidade; Pouco exigente quanto a recursos de

hardware, além da facilidade de uso verificada nas disciplinas de banco de dados

durante a graduação.

No desenvolvimento utilizou-se o ambiente de desenvolvimento integrado livre

Dev C++, que utiliza os compiladores do projeto GNU, para compilar programas para

o sistema operacional Microsoft Windows. Suporta as linguagens de programação C

e C++, e possui toda a biblioteca American Nacional Standards Institute (ANSI) C. A

escolha deste nos experimentos vinculados a esta monografia, deve-se o fato de:

Ser livre; ter facilidade de uso; geração de executáveis que podem ser utilizados em

equipamentos com recursos modestos de hardware; além da experiência do autor

com a linguagem C, adquirida nas diversas disciplinas da faculdade que exigiram o

uso de programação.

O libmysql-5.0.5-1sid, que é um pacote para conexão com o BD Mysql,

instalado na Biblioteca do Dev C++, que também foi utilizado.

32

3.2.2 Metodologia do ETL

Considerando que atualmente: (1) um grande número de ferramentas de ETL

estão disponíveis no mercado, e que em geral, elas seguem diferentes desenhos e

técnicas de modelagem e uso de diferentes construções internas; (2) que até pouco

tempo as atividades ETL eram encaradas como uma questão técnica de software na

arquitetura do DW; (3) sendo ainda que até agora, a comunidade de pesquisa não

tratou e acordou as características básicas de fluxos de trabalho de atividades ETL.

Conclui-se, portanto, que sem uma maneira formal de representar atividades ETL, e

ao mesmo tempo, usando técnicas de projeto ad hoc, não é possível melhorar a

qualidade e a eficiência de fluxos de trabalho de ETL de forma sistemática, ou

realizar outras operações cruciais como what-if e análise de impacto.

Sobre o uso das ferramentas especializadas relacionadas com os tradicionais

DBMS, estas soluções tem algumas desvantagens importantes:

a) Fornecem notação proprietária;

b) Configuração e estrutura de ETL os processos são muito complexos, e;

c) Grandes requisitos de hardware são necessários.

Estas características tornam difícil a integração em ambientes heterogêneos de

DWs e aumentam a curva de aprendizado.

De forma a preencher estas lacunas, a realização desta seção é justificada,

considerando as bases de dados heterogêneas utilizadas; a linguagem de

programação e o banco de dados empregados, além de uma possível taxonomia

proposta por Vassiliadis et al (2009). Contribuindo para a recomendação no início

desta seção de documentar todas as estratégias de implantações diferentes,

evitando desta forma, a utilização de soluções proprietárias, facilitando a

configuração de processos ETL, e finalmente utilizando soluções com requisitos

mínimos de hardware.

Em 2009 Vassiliadis et al, identificaram as propriedades genéricas que

caracterizam as atividades de ETL, colaborando para uma taxonomia destas

atividades. Esta taxonomia será utilizada para descrever as atividades que foram

realizadas para transformação das bases de dados utilizadas. Sendo que esta

taxonomia explora as atividades ETL em dois níveis principais:

33

a) Caracterização das atividades, no que diz respeito à relação de seus

esquemas de entrada-saída;

b) A caracterização das atividades através de uma forma normal de

representação que pode ser usada para descreve-las.

Esta taxonomia prevê uma classificação de alto nível com relação aos

esquemas de entrada descritos por atividades unárias, binárias e enárias e seus

equemas de saída descritos por roteadores e filtros.

Uma atividade unária realiza uma transformação, ou operação de limpeza por

exemplo, e direciona os dados processados para a saída. Atividades unárias têm

exatamente um esquema entrada e um de saída. Com base nisso, os valores mais

interessantes para a cardinalidade de mapeamento de atividades unários são os

seguintes:

a) 1:1, uma entrada tupla é mapeada a exatamente uma tupla de saída;

b) 1: M, uma entrada tupla é mapeado para mais de uma tuplas de saída;

c) N: 1, mais de uma tuplas de entrada são combinados para produzir

exatamente uma tupla de saída;

d) 0: M, algumas funções ou valores constantes, são utilizadas para produzir

uma ou mais tuplas de saída;

e) N: M, a relação entre um certo grupo de tuplas de entrada e um certo grupo

de tuplas de saída não pode ser simplificada para uma das categorias de atividades

acima.

Já atividades enárias combinam informações de múltiplas entradas e

preenchem um esquema de saída. Uma atividade enária (por exemplo, um multi-

join) pode ter n entradas ou pode ser implementado como uma série de atividades

binárias. As atividades de binárias envolvem duas configurações interessantes:

a) Fluxo principal: Estas atividades são binárias, onde suas entradas são parte

de um fluxo principal, sendo estas testadas para posterior propagação.

b) Combinadores: Atividades cuja produção é uma combinação de valores de

mais de um esquema de entrada.

Roteadores são atividades que encaminham as tuplas direto para um caminho

específico do fluxo de trabalho, de acordo com o valor de um dos seus atributos. Os

roteadores são aplicáveis a todos os casos em que uma tupla passe por diferentes

tipos de processamento e armazenamento, dependendo do valor que elas tenham.

34

Já filtros são atividades que permitem a propagação de tuplas, que venham a

respeitar um critério de seleção.

Com relação a formalização normal, foi feita uma analogia entre as atividades

de ETL e a estrutura da matéria, a partir do domínio da física, como um meio

intuitivo para identificar componentes ETL com diferentes níveis de complexidade,

bem como as suas composições. Neste contexto as atividades serão comparadas

com partículas, átomos e moléculas.

Uma partícula ETL envolve uma única transformação ou tarefa de limpeza.

Por exemplo, quando o desenvolvedor adiciona uma atividade na tela, ele introduz

uma partícula no projeto. Um átomo ETL é uma atividade de ETL simples que

executa exatamente um trabalho envolvendo exatamente uma partícula de ETL.

Quando o desenvolvedor customiza os esquemas de uma atividade e conecta os

fornecedores e consumidores, ele define um átomo. Finalmente, uma molécula de

ETL é uma combinação de átomos de ETL que são mesclados em uma grande

construção, este é um caso freqüente onde várias funcionalidades são mescladas no

mesmo script. Neste caso, em vez de uma única partícula, há um fluxo linear de

partículas entre estes dois grupos de esquemas.

Como prova de conceito sobre a taxonomia, pode-se estabelecer uma relação

com atividades oferecidas por populares ferramentas de ETL e com o sistema

gerenciador construido para esta monografia.

Segundo Vassiliadis et al (2009) o quadro 1 apresenta uma adaptação com a

finalidade de exibir a classificação das atividades propostas pela taxonomia e

compara-las com as oferecidas por ferramentas populares de ETL e avaliar as

desenvolvidas nesta pesquisa.

35

Classe de Partícula

Categoria de Transformação

SQL SSIS Data Stage Oracle Warehouse

Builder

Sistema Proposto

1:1. Nível de registro:

Função que pode ser aplicada localmente para um único registro

Mapa de Caracter; Cópia de Coluna; Conversão de Dados; Coluna derivada; Script Componente; Comando OLE DB; Outros filtros (não nulo, seleção, etc.).

Transformador (Um representante genérico de uma ampla gama de funções: data e tempo. Lógica, matemática, manipulação nula, número, seqüência, string, utilidade, conversão de tipo/ fusão, roteamento.); Remoção de duplicatas; Modifica (apagando/criando colunas ou trocando tipos).

Deduplicador (distinção); Filtro; Seqüência; Constante; Função tabela (aplicada em um conjunto de linhas para aumentar o desempenho); Operadores de limpeza de dados (Nome e Endereço, Match-Merge);Outras transformações SQL (Carácter, Data, Número, XML, etc).

Cópia de Coluna; Conversão de Dados; Remoção de duplicatas; Modifica (apagando/criando colunas ou trocando tipos).

N:1. Agrupamento Unário: Transforma um registro de registros para um registro.

Agregador; Pivot. Agregador; Combina/ Promover registros.

Agregador; Pivot. Agregador.

1:N. Separação unária: Separa um registro para um conjunto de registros.

Unpivot. Marca/Separa em sub registros; Marca /Separa em vetor.

Unpivot. Marca/Separa em sub registros.

N:M. Holística unária: Realiza uma transformação para um conjunto de dados inteiro (bloqueio).

Classificar; Porcentagem de amostragem; Amostragem de registro.

Classificação (sequencial, paralela, total).

Classificar. Classificação (seqüencial).

Binário ou N-ário: Combina muitas entradas em uma saída.

Uniões, tais como: Unir todos; Merge. Junções, tais como: Merge Join (MJ); Pesquisa (SKJ);- Importação de coluna (NLJ).

Uniões, tais como: Funil (contínuo, seqüência, classificação); Junções, tais como: Junção; Merge; Pesquisa. Diferenciações, tais como: Capturando e aplicando mudanças; Diferença (registro-por-registro); Compara (coluna-por – coluna).

Uniões, tais como: Setando (União, união de tudo, cruzamento, diferença); Junções, tais como: Joiner; Chave de pesquisa (SKJ).

Importação de coluna (NLJ); Diferença (registro-por-registro);

Roteador: Define para qual saída o registro deve ser enviado.

Divisão Condicional; Multicast.

Cópia; Filtro; Seleção.

Divisão. Cópia

Quadro 1 – Comparação dos fluxos ETL construídos com ferramentas comerciais Fonte: Adaptado de Vassiliades et al, 2009.

36

3.2.2.1 Descrição das transformações executadas sobre as bases de dados

Um fluxo de trabalho de ETL pode ser visto como um grafo direcionado. Os

nós deste grafo são as atividades (compostas por partículas, átomos e moléculas) e

registros. As arestas deste grafo são as relações com o fornecedor que combinam

as atividades e estes registros.

O primeiro fluxo de trabalho realiza a atividade de extração das bases de

dados indicadas no capitulo 3. Foram criadas as tabelas Ruido, Atmosfericos,

Atmosfericos3 e Geracao que receberão os dados resultantes da atividade de

extração.

O segundo fluxo de trabalho realiza a exclusão das colunas NomeEstacao,

Um, Dois, TempMax, TempMin, UmidadeMax, UmidadeMin, OrvalhoMax,

OrvalhoMin, PressaoMax, PressaoMin, MedidorGerador1, MedidorGerador2,

MedidorGerador3, MedidorGerador4, Total, FaseA, FaseB das tabelas Atmosfericos,

Atmosfericos3 e Geracao. Considerando que estas informações não serão utilizadas

nas próximas etapas deste trabalho, e que a permanência destas colunas iriam

acarretar um acréscimo de uso de recursos computacionais, optou-se por essa

exclusão.

O terceiro fluxo de trabalho realiza a exclusão de campos nulos na tabela

geração, reduzindo o número de registros desta tabela de 2106 para 1224.

O quarto fluxo de trabalho realiza a agregação da coluna Dia com a coluna

Mes, e desta com a coluna Data na tabela Atmosfericos, padronizando o formato

desta coluna no padrão Mysql. Excluindo ao final, as colunas Mes e Dia.

O quinto fluxo de trabalho realiza a padronização da coluna Data no formato

“DATE” nas tabelas Atmosfericos3 e Geracao.

O sexto fluxo de trabalho, realizando a padronização da colunas

GeracaoUnidade1, GeracaoUnidade2, GeracaoUnidade3 e GeracaoUnidade4.

Inserindo “.” no lugar de “,” na indicação de pontos flutuantes, padronizando estas

colunas no formato “REAL”.

O sétimo fluxo de trabalho realiza a concatenação da tabela Atmosfericos3

com a tabela Atmosfericos, totalizando 34733 registros.

O oitavo fluxo de trabalho realiza a formatação da coluna hora nas tabelas

Atmosfericos e Geracao, padronizando esta coluna no formato “TIME”.

37

O nono fluxo de trabalho realiza a inserção da coluna Id nas tabelas

Atmosfericos e Geracao. Esta inserção visa facilitar a tarefa de exclusão de datas e

horários não relevantes, além de ser utilizada na função de interpolação linear que

será mostrada nos próximos capítulos.

O décimo fluxo de trabalho realiza a inserção das colunas Hora2, Minutos,

Segundos, TempInstFinal, UmidadeInstFinal, OrvalhoInstFinal, PressaoInstFinal,

VentoVelocidadeFinal, VentoDirecaoFinal, VentoRajadaFinal, RadiacaoFinal,

ChuvaFinal, GeracaoUnidade1Final, GeracaoUnidade2Final,

GeracaoUnidade3Final, GeracaoUnidade1Final nas tabelas Ruido, Atmosfericos e

Geracao. Estas colunas receberão as informações necessárias para realização da

interpolação linear.

O décimo primeiro fluxo de trabalho realiza a extração das informações hora,

minuto e segundo da coluna Hora de todas as tabelas, e insere nas respectivas

colunas criadas no fluxo anterior.

Como será explicado, um dos tratamentos necessários aos dados refere-se

ao fato dos dados atmosféricos serem medidos a cada hora, enquanto que de ruído

são amostrados em diferentes horários. Para obter dados atmosféricos mais

próximos dos reais, optou-se por aplicar a técnica de interpolação. Para aplicar esta

técnica, é necessária a amostragem anterior e posterior de horário ao horário do

registro de ruído. Deste modo, criou-se a inicialmente a redundância gerada pelo

décimo segundo fluxo.

O décimo segundo fluxo copia as colunas TempInst, UmidadeInst,

OrvalhoInst, PressaoInst, VentoVelocidade, VentoDirecao, VentoRajada, Radiacao,

Chuva, GeracaoUnidade1, GeracaoUnidade2, GeracaoUnidade3, GeracaoUnidade4

respectivamente para as colunas TempInstFinal, UmidadeInstFinal, OrvalhoInstFinal,

PressaoInstFinal, VentoVelocidadeFinal, VentoDirecaoFinal, VentoRajadaFinal,

RadiacaoFinal, ChuvaFinal, GeracaoUnidade1Final, GeracaoUnidade2Final,

GeracaoUnidade3Final, GeracaoUnidade4Final, para as tabelas Atmosfericos e

Geracao. Nesta operação as colunas destino são deslocadas posição n-1, de forma

que o registro atual contenha também dados do instante de tempo imediatamente

seguinte.

O décimo terceiro fluxo de trabalho realiza a exclusão de registros na tabela

Atmosfericos que não tem relação com as datas da tabela Ruido. Esta operação tem

38

por objetivo reduzir o espaço volume de dados a serem processados pela função de

interpolação.

O décimo quarto fluxo de trabalho realiza a interpolação envolvendo o valor

inicial e final no intervalo de cada hora para as colunas relevantes das tabelas

Atmosfericos e Geracao, considerando o instante em minutos de cada uma das

avaliações de ruído. As colunas relevantes são: TempInst, UmidadeInst, OrvalhoInst,

PressaoInst, VentoVelocidade, VentoDirecao, VentoRajada, Radiacao, Chuva,

GeracaoUnidade1, GeracaoUnidade2, GeracaoUnidade3, GeracaoUnidade4. Ou

seja, as leituras das informações referentes a condições atmosféricas e de produção

da usina são executadas ao final de cada hora, porém as avaliações de ruído não

seguem este padrão, podendo ser executadas a qualquer instante de tempo dentro

de uma hora. Como não existem informações de instantes de tempo específicos nas

colunas das tabelas de Geracao e Atmosfericos, esta informação será produzida

realizando a interpolação entre o TempInst e TempInstFinal, por exemplo,

considerando o período em minutos da hora em questão na ocasião da avaliação de

ruído. A interpolação linear é uma linha que se ajusta a dois pontos. A interpolação

linear de Lagrange é dada por (PAIVA, 2003):

g(x) = b – x * f(a) + x – a * f(b)

b – a b – a

onde por exemplo, para a coluna de temperatura:

g(x) = Temperatura resultado da interpolação,

f(a) = Temperatura inicial,

f(b) = Temperatura final,

a = 0, correspondendo aos 0 minutos de uma hora,

b= 59, correspondendo aos 59 minutos de uma hora,

x = dado instante em minutos, que se deseja saber a temperatura.

O décimo quinto fluxo de trabalho realiza a exclusão de registros das tabelas

Atmosfericos, Geracao que não tem relação com os horários da tabela Ruido.

O décimo sexto fluxo de trabalho realiza a exclusão das colunas Hora2,

Minutos, Segundos, TempInstFinal, UmidadeInstFinal, OrvalhoInstFinal,

PressaoInstFinal, VentoVelocidadeFinal, VentoDirecaoFinal, VentoRajadaFinal,

Radiacao, Chuva, GeracaoUnidade1Final, GeracaoUnidade2Final,

GeracaoUnidade3Final, GeracaoUnidade4Final das tabelas Ruido, Atmosfericos,

Geracao.

39

De forma a ilustrar os fluxos de trabalhos descritos, a figura 6 mostra o

resultado do primeiro fluxo de trabalho, na seqüência o quadro 2 ilustra os fluxos a

partir do segundo até o décimo quinto. Finalmente a figura 7 mostra o resultado do

décimo sexto e ultimo fluxo de trabalho.

Figura 6 – Resultado do primeiro fluxo de trabalho

Fonte: Autoria própria, 2011.

O quadro 2 tem como finalidade exibir as transformações sofridas pelas tabelas

relevantes, no que se refere o numero de registros e colunas envolvidas nos fluxos

de trabalhos, descritos anteriormente.

Ruído Atmosféricos Atmosfericos3 Geração Fluxos Reg Col Reg Col Reg Col Regi Col

2º 683 5 8665 24 26068 20 2106 13 3º 683 5 8665 13 26068 11 1224 6

4º - 5º - 6º 683 5 8665 11 26068 11 1224 6 7º - 8º 683 5 34733 11

Dados unificados na tabela

Atmosféricos

1224 6 9º 683 5 34733 12 1224 7

10º - 11º - 12º 683 8 34733 24 1224 14 13º 683 8 1224 24 1224 14 14º 683 8 1893 24 1893 14 15º 683 8 683 24 683 14

Quadro 2 – Transformações executadas pelos fluxos ETL Fonte: Autoria Própria, 2011.

40

As transformações descritas no quadro 2 podem ser vistas em detalhes no

Apêndice A. A Figura 7 mostra o resultado ao final dos dezesseis fluxos.

Figura 7 – Resultado do décimo sexto e ultimo fluxo de trabalho Fonte: Autoria Própria, 2011.

41

4 DATA WAREHOUSE

Luján-Mora e Trujillo (2004), e Pardillo e Mansmann (2010) construíram

notações e arquétipos para representar os aspectos da modelagem física, lógica e

conceitual de um DW utilizando para isto Unified Modeling Language (UML), visto

que esta é uma linguagem de modelagem geral, podendo seus mecanismos serem

estendidos para domínios específicos. Considerando que não existe um padrão

estabelecido para representação destas modelagens, estas notações serão

utilizadas para descrever os processos de modelagem do DW vinculado a esta

pesquisa.

4.1 Notações preliminares

As partículas iniciais das notações citadas foram obtidas a partir da análise e

comparação das sintaxes abstratas que caracterizam o estado da arte da

modelagem. Sendo representadas por:

a) Tabela de Fatos: ;

b) Dimensões: ;

c) Medidas de fato: FA;

d) Níveis: ; ;

e) Possibilidade de operações roll-up e drill-down: ;

f) Operações drill-down: 'd';

g) Operações roll-up: ‘r’;

42

h) Cada nível pode ser exibido pelo atributo: D.

4.2 Roteiro de construção

Segundo Machado (2004), é necessário um roteiro básico de orientações

para a execução da modelagem de um DW, de forma a destacar pontos importantes

e criar uma seqüência de operações que levem a utilizar uma formatação

metodológica na construção de bancos de dados orientados a DW. Este roteiro será

detalhado a seguir:

a) Calcular a Granularidade de Cada Tabela Fato: A granularidade da tabela

de fato não deve ter muitos detalhes a ponto de extrapolar a capacidade de

armazenamento do DW.

Para verificar a viabilidade de uma tabela de fatos é preciso fazer alguns

cálculos. Parte-se de um valor bruto do somatório de um fato em um dado

período, e de um valor médio daquele mesmo fato na granularidade que se

deseja para obter o número de registros. Divide-se o primeiro pelo segundo,

para obter o número de registros que constituirá a tabela de fatos. Multiplica-

se ainda esse número pelo total de períodos que se pretende manter.

No caso desta pesquisa, o espaço ocupado até o momento é de 144 KB para

um período de 4 anos, logo, 1 ano seria equivalente a aproximadamente 36

KB. Para manter estes registros e ainda realizar novos acréscimos por mais

16 anos representando a vida útil das unidades geradoras em operação,

totalizando 20 anos seriam necessários apenas 720 KB.

b) Definição das Dimensões Associadas a Cada Tabela Fato: As dimensões

devem ser definidas conforme a necessidade de visualização do usuário.

Intuitivamente o usuário pode identificar cruzamentos de dados que lhe

interessam.

Considerando que o objetivo desta pesquisa envolve identificar os elementos

atmosféricos e também de produção das usinas que possam ter relação com

índices elevados e baixos de pressão sonora. Assim sendo, estas dimensões

foram adicionadas ao banco de dados juntamente com as dimensões de

tempo e de ruído.

43

c) Dimensão Relativa a Tempo: A dimensão tempo relativa a esta pesquisa foi

criada com base nas datas presentes nas bases de dados originais. Após

serem transportadas para a tabela tempo, as granularidades destas datas

foram aumentadas até a menor unidade possível (hora), conforme ilustrado

na figura 8.

d) Identificação dos Atributos das Dimensões e as Hierarquias Embutidas: De

modo geral, os atributos de uma dimensão descrevem as suas características

e identidades.

Para facilitar a identificação de hierarquias e apoiar a modelagem das

dimensões, o autor do roteiro sugere a utilização do modelo ER como

ferramenta.

Nesse modelo ER, cada entidade corresponde a um atributo da dimensão e

os relacionamentos mostram as cardinalidades entre esses atributos.

As hierarquias em um modelo ER são caracterizadas por uma seqüência de

entidades interligadas de tal forma que os relacionamentos entre cada par de

entidades na seqüência sejam N:1.

O padrão que deve ser adotado é o de desnormalização dessas hierarquias,

levando todos os atributos para uma única tabela de dimensão com a

redundância textual de atributos que possa vir a existir. Uma normalização

nas tabelas dimensões economizaria 0,01%, o que pode ser considerado

desprezível em relação ao tamanho total do DW. Deste modo, justifica-se o

uso do modelo estrela, ao invés do modelo floco de neve, para obter-se

melhor desempenho em consultas. (MACHADO, 2004, P. 282).

Assim, as tabelas dimensões não necessitam ser normalizadas, pois não

compensa a perda de tempo para economizar tão pouco espaço em disco,

além de comprometer a habilidade de navegação pelas dimensões.

A figura 8 ilustra as dimensões modeladas para esta pesquisa.

44

Figura 8 - Dimensões hierarquias embutidas Fonte: Adaptado de Mora et al, 2004.

e) Identificação de Múltiplas Hierarquias: Uma dimensão pode apresentar

uma ou mais hierarquias embutidas juntamente com outros atributos que não

fazem parte das hierarquias.

Um exemplo de múltiplas hierarquias que será utilizado é o da figura anterior.

A dimensão semestre que se refere à ano possui uma estrutura hierárquica

de subordinações, porém essa hierarquia está inserida na própria dimensão,

pois mesmo em um modelo ER não se apresentariam como entidades

diferentes e relacionadas, e sim como um auto-relacionamento. Não é

necessário criar dimensões separadas para comportar hierarquias diferentes

e/ou os atributos que não tomem parte da hierarquia embutida em uma

dimensão.

45

Assim sendo as ferramentas OLAP devem ser capazes de movimentar-se por

múltiplas hierarquias e atributos contidos em uma única dimensão.

f) Especificação de Fatos: Expressar os fatos na menor granularidade,

principalmente quando for o caso de dimensões com hierarquias, os fatos

devem ser expressos na menor granularidade da dimensão como foi definido.

A tabela de fatos não deve armazenar registros que representem totais

referentes a um nível mais alto na hierarquia de uma dimensão.

g) Identificação de Valores Aditivos/ Semi aditivos: Valores aditivos são

aqueles que podem ser manipulados algebricamente (soma, subtração, etc.)

nas operações de drill up/down em uma tabela de fatos.

Valores semi-aditivos são aqueles que envolvem contagem dupla. Eles

também devem ser manipulados cuidadosamente. Neste caso é possível

somar se a dimensão não aditiva for restrita a um único valor. Quando isso

ocorre, uma solução seria avisar ao usuário.

No contexto desta pesquisa, estes valores não serão levados em

consideração, devido a necessidade de se utilizar todo o conjunto de dados

proveniente de uma consulta, com o objetivo de reconhecimento de padrões.

h) Identificação de Valores Não Aditivos: Valores não aditivos são aqueles

valores que não podem ser manipulados livremente.

Por exemplo, os valores percentuais ou relativos não são aditivos, sendo as

computações feitas com os dados absolutos em que estão baseados.

Considerando o contexto desta pesquisa praticamente todos os dados podem

ser classificados como valores não aditivos.

i) Manter Valores Não Aditivos para Futuras Manipulações: Todos os valores

que medem um nível de intensidade, como por exemplo, Equivalent Level

(LEQ), são estáticos não aditivos, que valem para o dado momento em que

se tomou a medida, e não podem ser somados através do tempo. Mas ainda

assim são valores que podem ser úteis para futuras manipulações. Uma

informação útil seria obter a média de intensidade em um dado período de

tempo.

j) Identificação da Dimensão mais Significativa Correspondente a Cada

Tabela de Fatos: No caso do DW desta pesquisa, existem duas dimensões

importantes: atmosféricos e geração, ambas descritas com vários atributos.

Justificam-se ambas dimensões visto que os atributos descritos nestas

46

colaboram diretamente para que atributo LEQ da dimensão ruído esteja

dentro dos parâmetros ou não.

l) Cuidados no Detalhamento das Dimensões: As dimensões de um negócio

são em sua maioria derivadas de um On-Line Transaction Processing (OLTP),

mas é preciso considerar algumas questões:

- Remapeamento da chave para evitar a dependência da chave original.

Devido à pouca duração dos registros de um OLTP em comparação com

DW, é comum reutilizar chaves. Manter a mesma chave do sistema-fonte

pode ocasionar duplicidades ou inconsistências no DW.

- Remapeamento com a preocupação de reduzir chaves longas, buscando

melhor desempenho.

- 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).

Considerando que os dados para construção do DW não partiram e não

são vinculadas a um OLTP e sim de base de dados sem vínculos com

banco de dados, estas questões foram minimizadas durante as atividades

de ETL.

4.3 Arquétipos

A arquitetura de um DW é geralmente descrita como várias camadas de

dados no qual os dados de uma camada são derivados da camada anterior. Neste

contexto o desenvolvimento de um DW pode ser estruturado em uma estrutura

integrada, com cinco etapas e três níveis que definem os diferentes diagramas para

o modelo DW, como ilustrado na Figura 9 e resumido a seguir.

47

Figura 9 - Descrição das 5 etapas e 3 níveis de diagramas para o modelo DW Fonte: Mora et al, 2004.

Onde:

a) Estágios: existem cinco fases distintas na definição de DW:

- Origem, que define as fontes de dados do DW, tais como sistemas OLTP,

fontes de dados externos, etc ;

- Integração, que define o mapeamento entre as fontes de dados e o DW;

- Data Warehouse, que define a estrutura do DW;

- Customização, que define o mapeamento entre do DW e as estruturas dos

clientes;

- Cliente, que define as estruturas que são usados pelos clientes para acessar

o DW, como aplicações OLAP por exemplo.

b) Níveis: cada etapa pode ser analisado em três diferentes níveis ou

perspectivas:

- Conceitual: define a partir de um ponto de vista conceitual o DW;

- Lógico: aborda aspectos lógicos do projeto DW, como a definição dos

processos de ETL;

48

- Físico: define aspectos físicos do DW, como o armazenamento das

estruturas lógicas em disco, ou a configuração do banco de dados e/ou

servidores que suportam o DW.

c) Diagramas: cada fase ou nível requer formalismos de modelagem diferente.

Portanto, a abordagem proposta pelos autores citados é composta de 15

diagramas. Por convenção, em cada diagrama o nome do diagrama fica em

negrito e o perfil em itálico.

A figura 10 ilustra a abordagem adotada por Mora et.al em 2010 e as relações

entre os diferentes diagramas a seguir: Esquema Conceitual do DW (DWCS),

Esquema Lógico do DW (DWLS) e Esquema Físico do DW (DWPS).

Figura 10 – Do nível conceitual ao nível físico Fonte: Mora et al, 2004.

No lado esquerdo desta figura é representado o Esquema Conceitual do DW

(DWCS), que está estruturado em três níveis: nível 1, Esquema estrela; nível 2,

pacote de dimensões e de fato e nível 3, Classe dimensão e nível de hierarquia.

A partir do Esquema Conceitual do DW (DWCS), é desenvolvido o modelo

lógico (DWLS, representado no meio da Figura 10).

Finalmente, a partir do Esquema Lógico do DW (DWLS) é derivado o DWPS,

que está representado no lado direito da Figura 10 O Esquema Físico do DW

(DWPS) mostra os aspectos físicos da implementação do DW. Este diagrama é

dividido em duas partes: o diagrama de componentes, que mostra a configuração

49

das estruturas lógicas usadas para armazenar o DW, e o diagrama de implantação,

que especifica os diferentes aspectos relativos ao hardware e software configuração.

Na Figura 11 é ilustrado uma representação possível do componente relativo

a esta pesquisa.

Figura 11 - Representação de um diagrama de componente Fonte: Autoria Própria, 2011.

Na figura, a classe (avaliação ambiental), que reside no componente (fatos) é

mostrado aninhada dentro do componente (isso indica residência e não

propriedade).

Na Figura 12 é ilustrado uma representação possível de implementação

relativa a esta pesquisa, conforme definido:

a) Formulário descritor: contém os tipos de nós e componentes. Este

formulário é usado como um diagrama de implantação primeiro corte na fase

de concepção de um sistema, quando não há uma decisão completa sobre a

arquitetura de hardware final;

b) Formulário exemplo: ele contém nós e componentes específicos e

identificáveis. Este formulário é usado para mostrar a implantação real de um

sistema em um determinado site, portanto, é normalmente usado na última

etapa da atividade de execução, quando os detalhes do local de implantação

são conhecidos.

50

Figura 12 – Representação de um nodo em um diagrama de implementação Fonte: Autoria Própria, 2011.

Na figura 12, o componente (Tcc2) que é implantado no nó (DWServer) é

mostrado aninhado dentro do nó.

4.3.1 – DWCS

Conforme ilustrado na figura 10 este modelo é dividido em três níveis, assim

sendo o primeiro nível vinculado a esta monografia é ilustrado na figura 13.

Figura 13 - Nível 1 do Esquema Conceitual de um DW Fonte: Adaptado de Mora et al, 2004.

O primeiro nível é formado por um único pacote, chamado de esquema

avaliação ambiental.

Já o segundo nível é ilustrado na figura 14.


51

O segundo nível é formado por um fato Avaliação ambiental sendo

representado no meio da figura, enquanto que os pacotes de dimensões: Ruído,

Ambiental, Geração e Tempo são colocados ao redor do pacote fato.

Finalmente o terceiro nível é ilustrado na figura 15.


Neste diagrama de terceiro nível são ilustrados os atributos das classes de

fato e de dimensão.

4.3.2 – DWLS

52

No contexto desta pesquisa, um sistema Relational On Line Analytical

Processing (ROLAP) foi selecionado para a implementação do DW, considerando o

pequeno volume de dados, cerca de 85 registros por ponto georreferenciados e

possível escalabilidade desta abordagem, o que significa a utilização do modelo

relacional no projeto lógico do DW. Na Figura 8 já mostrada, cinco tabelas são

ilustradas, sendo elas: Ruído, Atmosféricos, Geração, tempo e Avaliação Ambiental,

aparecendo como ícones de estereótipo dentro da representação típica de uma

classe em UML.

Na tabela Avaliação Ambiental, os atributos IdRuido, IdAtmosfericos,

IdGeração e IdTempo são as chaves estrangeiras que ligam a tabela de fatos com

as tabelas de dimensão.

4.3.3 – DWPS

Para ilustrar e documentar este modelo propõe-se o uso de cinco diagramas,

que correspondem com os cinco estágios apresentados no capitulo 4.3, sendo

detalhados nas próximas subseções.

4.3.3.1 Esquema Físico

O Source Physical Schema (SPS) descreve a origens dos dados do DW a

partir de um ponto de vista físico. Na Figura 16, é ilustrado o SPS que é formado por

um servidor chamado Avaliação_AmbientalServer, sendo suas a configurações de

hardware e software exibidos por meio de tags de valores.

53

Figura 16 - Esquema físico da origem dos dados: diagrama de implementação Fonte: Autoria Própria, 2011.

4.3.3.2 DWPS

O DWPS mostra os aspectos físicos da implementação do DW. Este

diagrama é dividido em duas partes:

No primeiro diagrama, é exibida a configuração das estruturas lógicas usadas

para o DW. Na Figura 17, é ilustrado que o DW é implementado por meio de um

banco de dados chamado TCC2, que é formado por um espaço de tabela chamado

Fato e dimensões, este espaço de tabela hospeda por sua vez as tabelas,

avaliação_ambiental, ruído, atmosféricos, geração e tempo.

54

Figura 17 - Esquema físico da origem dos dados: diagrama de componente Fonte: Autoria Própria, 2011.

No segundo diagrama, diferentes aspectos relativos à configuração de

hardware e software são especificados. Além disso, a distribuição física das

estruturas lógicas previamente definidas nos diagramas de componentes também

está representada.

Figura 18 - Esquema físico da origem dos dados: diagrama de implementação Fonte: Autoria Própria, 2011.

55

4.3.3.3 Diagrama de transporte e integração

O Integration Transportation Diagram (ITD) define a estrutura física dos

processos ETL utilizados no carregamento dos dados no DW a partir das fontes dos

dados.

No lado esquerdo deste diagrama, um servidor de origem de dados é

representado: Avaliação_AmbientalServer, que foi previamente definidos na Figura

16. No lado direito é ilustrado, o DWServer, previamente definido na Figura 18.

Nesta figura, o ETLServer é introduzido através de um servidor adicional que é

usada para executar os processos ETL. Esse servidor se comunica com o resto dos

servidores por meio de um protocolo específico denominado libmysql-5.0.5-1.

Figura 19 - Diagrama de transporte e integração Diagrama de Implementação Fonte: Autoria Própria, 2011.

56

4.3.3.4 Esquema físico para o cliente

A Cliente Physical Schema (CPS) define a estrutura física das estruturas que

são usadas pelos clientes para acessar o DW. O servidor de DW fornece acesso aos

dados para os clientes.

4.3.3.5 Diagrama personalizado de transporte

O Customization Transportation Diagram (CTD) define os processos de

exportação a partir do DW para as estruturas específicas usadas pelos clientes.

Neste diagrama, o DW é representado por meio da DWPS e clientes são

representados por meio do CPS.

Na figura 20 é ilustrado o Diagrama Personalizado de Transporte, sendo na

parte superior deste, ilustrado parte do DWPS, que já foi previamente definido na

Figura 18, sendo por fim ilustrado no lado direito o cliente.

Figura 20 - Diagrama customizado de transporte: Diagrama de Implementação Fonte: Autoria Própria, 2011.

57

4.4 – WinDesktopClient

Segundo Machado (2004) OLAP é o conjunto de ferramentas que possibilita

efetuar a exploração dos dados de um DW. A análise denominada multidimensional

representa os dados como dimensões ao invés de tabelas. Combinando essas

dimensões, o usuário tem uma visão dos dados de um DW, podendo efetuar

operações ditas básicas como slice and dice, que é uma forma de mudança das

dimensões a serem visualizadas, drill down e roll up, como se denomina a

navegação entre os níveis de detalhamento dos dados de DW.

A análise multidimensional implica a utilização de operações típicas como,

comparações de valores entre períodos e diversas funções estatísticas.

O resultado desse tipo de análise, por meio do comportamento de

determinadas variáveis ao longo do tempo, é permitir a descoberta de tendências e

cenários, e com isso transformar os dados de um DW em informação estratégica.

Com o objetivo de obter informações estratégicas no contexto desta pesquisa,

além de implementar o diagrama ilustrado na seção 4.3.3.5, foi desenvolvido um

sistema gerenciador, permitindo realizar operações drill down, roll up e exportação

de arquivos csv/txt, formatos estes reconhecidos pela maioria dos programas de

mineração de dados, permitindo desta forma a transformação de informação em

conhecimento.

A figura 21, ilustra os menus disponibilizados pelo sistema.

(a) (b) (c) (d)

Figura 21 - Menus disponibilizados para navegação Fonte: Autoria Própria, 2011.

No menu (a), é ilustrada a opção de operações drill down e roll up aplicadas

sobre a dimensão ponto, além das opções referentes as demais dimensões. Na

seqüência no menu (b), é ilustrada também a opção de operações drill down e roll

58

up aplicadas a dimensão tempo, permitindo acesso ao primeiro nível hierárquico, já

o menu (c) permite acesso ao segundo nível. Conforme figura 8 a modelagem

dimensional vinculada a esta pesquisa permitirá consultas com níveis de

granularidade em horas, porém ao se considerar o volume de dados por ponto

georreferenciado, em torno de 85 registros por ponto, este nível de granularidade

provavelmente não traria resultados relevantes. Neste contexto os níveis

hierárquicos na dimensão tempo foram limitados, em todo o conjunto de dados, anos

e semestre.

Finalmente, no menu (d), é ilustrada a operações referentes a consultas

como:

a) Remover a dimensão atmosféricos: Remove a dimensão citada, no caso de

ser necessário relacionar a dimensão ponto apenas com a dimensão geração;

b) Remover a dimensão geração: Remove a dimensão citada, no caso de ser

necessário relacionar a dimensão ponto apenas com a dimensão

atmosféricos;

c) Salvar consulta: Realiza a exportação da consulta gerada pelas opções do

menu dimensões, no formato csv/txt permitindo que esta consulta seja

importada e carregada em programas de mineração de dados.

59

5 DESCOBERTA DE CONHECIMENTO

Considerando que os objetivos desta pesquisa buscam apoiar os agentes de

campo nas coletas de ruído quanto da identificação de condições mais favoráveis

para realização destas, evitou-se uma inspeção puramente manual dos dados.

Para a solução do problema a um custo baixo, técnicas de mineração de dados

foram investigadas, visando à indução automática de modelos. Desta investigação

surgiu do ponto de vista computacional a necessidade de comparação de algoritmos

de mineração de dados que melhor se adequassem ao conjunto de dados

disponíveis.

Este capítulo está organizado em 6 seções, sendo tratada na seção 5.1 as

características das ferramentas Stuttgart Neural Network Simulator (SNNS), Library

Support Vector Machines (LIBSVM) e Waikato Environment for Knowledge Analysis

(WEKA). Na seção 5.2 a organização dos dados de entrada. Na seção 5.3 a

comparação e avaliação dos algoritmos disponíveis na ferramenta. Na seção 5.4 o

resultado das comparações. Na seção 5.5 a descrição dos algoritmos selecionados.

E finalmente na seção 5.6 serão apresentadas as regras geradas pelos algoritmos

de mineração de dados selecionados.

5.1 Ferramentas Pesquisadas

Foram comparadas as características principais de ferramentas de mineração

de dados Open Source SNNS, LIBSVM e WEKA. Estas foram analisadas a partir

dos manuais e documentações. Conforme será descrito, através deste estudo foi

possível obter a definição da ferramenta mais adequada para busca de padrões

considerando a base de dados disponível.

A ferramenta Stuttgart Neural Network Simulator (SNNS) é assim descrita por

Rocha (2005):

O SNNS, simulador utilizado no treinamento de vários tipos de redes neurais, foi desenvolvido em 1989 pelo Institute For Parallel And Distributed High Performance Systems (IPVR) da Universidade de Stuttgart na Alemanha. O objetivo da sua criação era prover uma ambiente de simulação

60

eficiente para pesquisa e aplicação de redes neurais artificiais. (ROCHA, 2005, P. 35).

Outra ferramenta analisada é a Library Support Vector Machines (LIBSVM):

LIBSVM é um simulador para classificação e regressão de distribuição de Support vector machine (SVM). Ele possui uma interface com o usuário simples e de fácil manipulação. Ele contém alguns softwares auxiliares como, por exemplo, o svmscale, que normaliza base de dados. Ao contrário do SNNS, que não implementa a validação cruzada como opção para treinamento, o LIBSVM o faz. (ROCHA, 2005, P. 38).

A terceira ferrramenta analisada é o WEKA. Desenvolvido em Java pela

universidade de Waikato, caracteriza-se como uma coleção de algoritmos de

aprendizagem de máquina para resolução de problemas de associação,

classificação, regressão e clustering. Conforme ilustrado na figura 22, o WEKA

fornece quatro opções principais: Simple CLI, Explorer, Experimenter e

KnowledgeFlow. A primeira opção permite a realização de experimentos por meio de

comandos (prompt), a segunda é utilizada para pré-processamento e aplicação de

técnicas de aprendizagem de máquina, a terceira é usada para fins de comparação

entre as diversas técnicas de inteligência computacional, e finalmente a quarta e

última é uma nova interface gráfica para o WEKA.

Figura 22 - Interface gráfica do WEKA. Fonte Autoria Própria, 2011.

O quadro 3 foi compilado utilizando as características identificadas por

ROCHA (2005) e tem por finalidade exibir as características das ferramentas

pesquisadas no que se refere às técnicas de identificação de padrões; forma de

61

realização de experimentos; uso em aplicativos com linguagens distintas; e técnicas

de avaliação.

CARACTERISTICAS SNNS LIBSVM WEKA

Identificação de padrões por associação X

Identificação de padrões por classificação X X X

Identificação de padrões por regressão X X

Identificação de padrões por Clusterização X

Experimentos por meio de Prompts X X

Experimento por comparação de varias técnicas simultâneas X

Permite o uso em Aplicativos em ANSI-C X X

Permite o uso em Aplicativos em JAVA X X

Permite o uso em Aplicativos em C# X

Avaliação por validação cruzada X X

Avaliação por porcentagem de treinamento com ordem aleatória X

Avaliação por porcentagem de treinamento com ordem Preservada X

Quadro 3 - Características das ferramentas de aprendizagem de máquinas pesquisadas

Fonte: Autoria própria, 2011 (construída a partir de informações de ROCHA, 2005).

Considerando a identificação das características exibidas no quadro 3. A

ferramenta escolhida para descoberta de conhecimento envolvendo os dados já

citados foi o WEKA (Bouckaert et al, 2010). Esta escolha baseou-se no fato desta

ferramenta disponibilizar um número maior de técnicas de identificação de padrões,

permitir a comparação de diversas técnicas em um único ciclo de execução,

possuindo diversas técnicas de avaliação, além de ser gratuita, de código aberto, de

fácil manuseio, com interface gráfica e possuir também uma vasta documentação.

5.2 Organização dos Dados de Entrada

Anteriormente ao processo de treinamento do classificador utilizando o

WEKA, os dados de entrada foram organizados para o programa a partir de um DW,

apresentado no capítulo 4 considerando as características presentes nas bases de

dados do INMET e dos departamentos de Operação e Segurança do Trabalho da

Eletrobrás-CGTEE. Cada atributo possui um conjunto de características cujas

62

intensidades são expressas em números reais. As características consideradas para

a criação dos arquivos de entrada para o WEKA foram descritas na seção 4.2 figura

8.

Com relação ao atributo LEQ a NBR 10151:2000 (quadro 4) estabelece os

níveis de intensidade sonora para os períodos diurno e noturno considerando o tipo

de área. No contexto dessa pesquisa serão utilizados os limites estabelecidos para

área predominantemente industrial, ou seja, 70 decibéis para o período diurno e 60

para o noturno.

Tipos de áreas Diurno Noturno

Áreas de sítios e fazendas 40 35

Área estritamente residencial urbana ou de hospitais ou de escolas 50 45

Área mista, predominantemente residencial 55 50

Área mista, com vocação comercial e administrativa 60 55

Área mista, com vocação recreacional 65 55

Área predominantemente industrial 70 60

Quadro 4 – Nível de critério de avaliação Nível de Critério de Avaliação (NCA) para ambientes externos, em dB(A)

Fonte: NBR 10151, 2000.

Como as usinas de Candiota e as estações do INMET operam por 24 horas, as

condições favoráveis para índices de ruído elevado podem se manifestar sem

qualquer relação com o horário. Por isso, as medições ocorrem ao longo de todo

este período de operação das usinas, sendo que no período de Janeiro de 2007 à

Dezembro de 2010 tem-se em média 40 registros para o período diurno e a mesma

quantidade para o período noturno por ponto. Esta quantidade poderia ser

insuficiente para investigação de padrões. Por isso, optou-se por utilizar toda a base

de dados para geração de regras, não levando-se em consideração os períodos

diurno ou noturno.

Desta forma foi implementada uma funcionalidade ao sistema permitindo que,

para o conjunto de dados referente a um ponto específico, o mesmo conjunto de

dados fosse usado tanto para avaliar o padrão noturno quanto o diurno, uma vez

que possíveis variações climáticas entre os turnos já estariam expressos na base

63

atmosférica. Esta mesma funcionalidade permitiu para visualização, transformar os

dados de valores reais para dois valores discretos: baixo e alto.

5.3 Comparação e Avaliação

Para o desenvolvimento desta seção foi utilizada a opção Experimenter

disponível no Weka. Esta permite a realização de comparação entre os algoritmos

de classificação em 9 categorias: bayes, functions, lazy, meta, mi, misc, rules,

scripting e trees. No apêndice 2 é ilustrado o resultado da comparação de 71

algoritmos compatíveis com os atributos dos dados de entrada, permitindo uma

avaliação completa de todos os algoritmos disponibilizados pelo Weka.

A comparação citada anteriormente utiliza três técnicas de avaliação as quais

serão detalhadas a seguir.

A validação cruzada (Cross-validation) é utilizada para testar e comparar

classificadores, a base de dados é sub-dividada em n blocos (n-fold) de tamanhos

aproximados, nos quais n-1 blocos são utilizados como conjunto de treinamento e o

último bloco restante é usado como conjunto de teste. Sendo assim, n rodadas

serão necessárias para realizar o treinamento. Em suma, durante o treinamento

acontecem rodadas:

a) Primeira rodada, o primeiro bloco é utilizado como conjunto de teste

enquanto os n-1 blocos restantes são utilizados como conjunto de

treinamento;

b) Segunda rodada, o segundo bloco é utilizado como conjunto de teste e

os n-1 blocos restantes como conjunto de treinamento, e assim

sucessivamente conforme ilustrado na figura 25. Ao final de cada

rodada o erro de classificação é calculado, e ao término da última

rodada, a média e desvio padrão do erro total é efetuado.

A aplicação de validação cruzada em experimentos é sugerida quando a

quantidade de padrões existentes nas bases de dados do estudo é pequena. Os

resultados obtidos também são considerados mais precisos, desde que a freqüência

de exemplos é distribuída ao longo do treinamento.

64

Figura 23 - Exemplo de Validação Cruzada em 10 blocos Fonte: Autoria Própria, 2011.

A porcentagem de treinamento com ordem aleatória (Train/Test

Percentage Split - data randomized) divide de forma aleatória, um conjunto de dados

de acordo com o percentual determinado, em um arquivo de treinamento e outro de

teste, não sendo transparente ao usuário a definição de qual é o de treinamento e

qual é o de teste no experimenter.

A Porcentagem de treinamento com ordem preservada (Train/Test

Percentage Split - order preserved) divide um conjunto de dados de acordo com um

percentual determinado em um arquivo de treinamento e outro de teste, sendo

explícito que a porcentagem de treinamento correspondem aos registros iniciais dos

dados de entrada.

5.4 Resultados das Comparações

Conforme descrito na seção 5.2, realizou-se experimentos para limites

diurnos e noturnos de ruído, utilizando-se a totalidade de algoritmos disponíveis no

WEKA. Dentre os 71 algoritmos avaliados os quais permitem a criação de regras

legíveis e compatíveis com os atributos de entrada, considerou-se as 3 metodologias

de validação propostas. Pode-se dizer que os algoritmos J48graft e Part com

validação cruzada, obteve maior percentual de confiabilidade, o qual é calculado

automaticamente pelo sistema, para o limite de LEQ de 70 dB, conforme ilustrado no

Quadro 5. Já o algoritmo Bagging com validação cruzada acima de 20 n-fold e o

65

algoritmo DecisionStump com order preserved acima de 50% apresentaram maior

confiabilidade para limite de LEQ de 60 dB, conforme ilustrado na Quadro 6.

O critério para escolha de qual algoritmo deveria ser utilizado para gerar

regras, baseou-se nas porcentagens de confiabilidade mais altas dentro de uma

mesma categoria de técnicas de validação. Sendo que para a técnica de Cross

Validation o limite para utilização de fatias limitou-se em 80 conjunto de dados pois

em média em cada um dos pontos georreferenciados estão disponíveis 85 registros.

Cross Validation Data randomized 0rder preserved

Algoritmos 10 20 30 40 50 60 70 80 30 50 70 30 50 70

trees.J48graft 61,06 64,78 67,78 70,08 71,2 70,75 72,21 72,06 54,04 58,24 56,22 38,98 14,29 12

rules.PART 59,26 61,53 61,53 65,04 64,1 62,75 63 63,56 55,03 57,5 57,82 38,98 14,29 12

Quadro 5 – Avaliação dos algoritmos para 70 dB Fonte: Autoria Própria, 2011.

Cross Validation data randomized 0rder preserved

Algoritmos 10 20 30 40 50 60 70 80 30 50 70 30 50 70

meta.Bagging 91,72 92,5 92,22 93,33 93 94,17 94,93 94,38 91,77 91,99 91,77 - - -

trees.DecisionStump 91,94 92,5 92,22 93,33 93 94,17 95 94,38 88,4 88,18 91,77 77,97 100 100

Quadro 6 – Avaliação dos algoritmos para 60 dB Fonte: Autoria Própria, 2011.

Os resultados contendo os 71 algoritmos avaliados podem ser vistos em

detalhes no Apêndice B.

5.5 Descrição dos algoritmos selecionados

O algoritimo J48graft gera uma árvore de decisão C4.5 sendo esta uma

extensão do algoritmo ID3, estes introduzidos por Quinlan em 1987 para induzir

modelos de classificação. Utiliza método guloso para induzir árvores de decisão para

posterior classificação. O modelo de árvore de decisão é construído pela análise dos

dados de treino e o modelo utilizado para classificar dados ainda não classificados.

O J48 gera árvores de decisão, em que cada nó da árvore avalia a existência ou

66

significância de cada atributo individual. As árvores de decisão são construídas do

topo para a base, através da escolha do atributo mais apropriado para cada

situação. Uma vez escolhido o atributo, os dados de treino são divididos em

subgrupos, correspondendo aos diferentes valores dos atributos e o processo é

repetido para cada subgrupo até que uma grande parte dos atributos em cada

subgrupo pertençam a uma única classe. A indução por árvore de decisão é um

algoritmo que habitualmente aprende um conjunto de regras com elevada acuidade.

Este algoritmo é escolhido para comparar percentagem de acerto com outros

algoritmos.

Já o algoritmo PART gera uma lista de decisão PART, usando a técnica

Dividir-e-conquistar. Constrói uma árvore de decisão C4.5 parcial em cada iteração e

faz da melhor folha uma regra.

Sobre o algoritmo Bagging este gera um classificador para reduzir a variância.

Pode fazer a classificação e regressão em função da base de treinamento. Este

algoritmo é combinado com o algoritmo RepTree, gerando uma árvore de decisão de

rápida aprendizagem, construindo uma árvore de regressão, usando ganho de

informação reduzindo as atividades de poda. Os valores com falha são tratados

dividindo suas instâncias em pedaços como o C4.5.

Finalmente, o algoritmo DecisionStump gera e usa um ramo de uma árvore de

decisão. Normalmente utilizado em conjunto com um algoritmo de reforço. A

regressão é baseada no quadrado do erro médio e a classificação é baseada na

entropia. Erros são tratados como um valor em separado.

5.6 Regras geradas

Utilizando a aba Explorer foi realizado o pré-processamento e aplicação das

técnicas de aprendizagem de máquina descritas na seção anterior. As figuras de 26

a 38 mostram os resultados dos algoritmos Bagging e J48graft aplicados sobre os

dados de entrada, considerando o ponto georreferenciado, o período (diurno ou

noturno) e o limite estabelecido para o mesmo. Além destes foram testados os

algoritmos DecisionStump e Part.

67

Para o limite de 60dB , no ponto 1 (Figura 24) verificou-se que a produção da

unidade 1 tem um fator determinante para índices elevados de ruído, com

influências da direção do vento. Esta suposição é consistente com a proximidade da

unidade1 e da direção do vento sobre este ponto. O algoritmo Part para este

conjunto de dados, foi incapaz de construir regras para a categoria baixo.

Figura 24 – Resultados para o ponto 1com algoritmos Bagging e DecisionStump Fonte: Autoria Própria, 2011.

No ponto 2 verificou-se que o ruído proveniente da produção da usina não

tem influência sobre os índices de pressão sonora registradas neste ponto. Os dois

algoritmos não chegaram a um consenso sobre a possibilidade de a radiação

atmosférica interferir sobre as amostras de ruído. Porém, a direção do vento a favor

do instrumento de medição parece colaborar com índices elevados. O algoritmo Part

para este conjunto de dados, foi incapaz de construir regras para a categoria alto.

No ponto 3 verificou-se a que a influência da velocidade do vento intensificou

os níveis de ruído produzidos pela unidade 3.

68


tem influência sobre os índices de pressão sonora registradas neste ponto. Porém

foi identificada uma série de elementos atmosféricos combinados com influência da

rajada de vento.

No ponto 5 verificou-se a que a influência da direção e velocidade do vento

intensificaram os níveis de ruído produzidos pela unidade 3. O algoritmo Part para

este conjunto de dados, foi incapaz de construir regras para a categoria baixo.

No ponto 6 verificou-se a influência clara da geração da unidade 2, com

possibilidade de intensificação por radiação atmosférica. O algoritmo Part para este

conjunto de dados, foi incapaz de construir regras para a categoria baixo.


tem influência sobre os índices de pressão sonora registradas neste ponto. Porém

foi identificada uma série de elementos atmosféricos combinados com o orvalho. O

algoritmo Part para este conjunto de dados, foi incapaz de construir regras para a

categoria alto.

No ponto 8 os dados produzidos pelos 2 algoritmos foram controversos não

apontaram os mesmos elementos, porém apresentou a influência da direção do

vento naquela localização e a força da rajada do vento. Suspeitando-se também de

uma possível influência da geração da unidade2 apesar desta estar localizada a

aproximadamente a 5 km deste ponto de coleta.

Para o limite de 70dB , no ponto 1 (Figura 32) verificou-se a influência da

unidade 2 e unidade 4, considerando também a possibilidade da velocidade do

vento intensificar a intensidade sonora produzida pela unidade 4.

69

Figura 25 – Resultados para o ponto 1 com algoritmos J48Graft e Part Fonte: Autoria Própria, 2011.

No ponto 2, 4 e 5 não foi gerada nenhuma regra utilizando os dois algoritmos

pesquisados, acredita-se que este fato se deve as condições com nível de pressão

sonora alta correspondendo a uma porcentagem muito baixa, entre 6,98 e 16,27%

das bases de dados.

No ponto 3 além da possível influência da radiação atmosférica, verificou-se a

influência combinada da geração da unidade1 e unidade2.

No ponto 6 verificou-se a influência da direção do vento na intensificação do

ruído provocado pelas unidade4 e unidade1.

No ponto 7 verificou-se uma combinação da pressão atmosférica e

praticamente todos os demais atributos.

No ponto 8 verificou-se a interferência da rajada e velocidade do vento sobre

o índice de pressão sonora produzida pelas unidade2 e unidade3.

De modo geral verificou-se que os atributos probabilidade de chuva e

umidade praticamente não interferiram na geração de regras.

As regras geradas para os pontos de 2 à 8 considerando ainda os limites de 60

e 70 decibéis podem ser vistos em detalhes no Apêndice C.

70

6 CONCLUSÃO

Este trabalho apresentou uma proposta metodológica descrevendo os passos

desde a extração das bases de dados (Excel, txt e Mysql) até obtenção de

conhecimento através do programa de mineração de dados WEKA. Este

conhecimento poderá ser aplicado na organização cedente das bases de dados, por

ocasião da seleção das condições ambientais mais favoráveis para realização das

coletas de ruído.

Testou-se uma classificação genérica das atividades ETL proposto por

Valissiadis et al (2009) para extração dos dados das bases já citadas, além da

transformação segundo as regras de negócio e posterior carga no DW. Sendo

verificado que essa caracterização simples pode levar a uma forma normal para

realizar operações simples para atividades de ETL. Além de uma forma normal para

o tratamento formal das atividades ETL e fluxos de trabalho, também verificou-se

formas normais no nível macro podendo estas ser reutilizáveis melhorando a

eficiência dos fluxos ETL.

Também testou-se uma adaptação dos diagramas de componente e de

implantação da UML proposto por Mora et al (2006) para a modelagem do projeto

físico de um DW que receberá a carga proveniente das atividades ETL. Verificou-se

desta forma, uma estrutura que facilita a integração de diferentes modelos de DW,

no sentido de coordenar esforços para incluir a configuração de hardware

(servidores e unidades necessárias para a data), bem como a melhor maneira de

organizar os dados no banco de dados de estruturas lógicas (de tabela e tabelas).

Após a modelagem do DW e carga dos dados provenientes dos fluxos ETL,

partiu-se para atividades de mineração de dados sendo um instrumento fundamental

para a aprendizagem de máquinas.

Realizou-se os experimentos com os 71 algoritmos de classificação disponíveis

na ferramenta Weka, para a extração de conhecimento de três bases reais de dados

vinculadas as coletas de ruído ambientais. Em função do maior percentual de

confiabilidade atingido, foram selecionados os algoritmos J48Graft e Part para

coletas diurnas, e Bagging e DecisionStump para coletas noturnas. Para todos os

experimentos foram utilizados cross-validation, Train/Test Percentage Split (data

71

randomized), Train/Test Percentage Split (order preserved) para tornar os resultados

mais confiáveis.

Este trabalho serviu para consolidar os conceitos envolvidos no processo KDD

e verificar a viabilidade de extrair conhecimento em áreas que possuem um grande

volume de dados. A partir deste trabalho foi adquirida uma habilidade em trabalhar

com a ferramenta Weka, bastante utilizada no meio acadêmico. Verificou-se que

essa ferramenta possibilita uma facilidade em realizar experimentos distintos

rapidamente, porém o seu desempenho é deteriorado com o uso de grandes

conjuntos de dados.

Após avaliação dos algoritmos constatou-se que J48graft e Part com validação

cruzada, obtiveram maior percentual de confiabilidade para limite de LEQ de 70 dB.

Já o algoritmo Bagging com validação cruzada acima de 20 n-fold e o algoritmo

DecisionStump com order preserved acima de 50% apresentaram maior

confiabilidade para limite de LEQ de 60 dB.

De forma geral os objetivos específicos foram alcançados, ou seja, foi estudado

um conjunto representativo de técnicas de Data Mining, com suas características e

propriedades e estes foram aplicados ao problema em questão. Uma metodologia

de aplicação foi estabelecida e os resultados foram estudados, encontrando-se

propriedades e características não evidentes no conjunto de dados. Isso permitiu

que o objetivo geral fosse atingido, conforme dados da seção 5.6 e Apêndice C, ou

seja, foram identificadas novas informações presentes nos dados obtidos

fornecendo subsídios para a automatização da classificação de condições

adequadas para realização de coletas ambientais.

Em Trabalhos futuros pretende-se apresentar os resultados deste trabalho ao

comitê de P&D (Programa de Pesquisa e Desenvolvimento) da empresa, no sentido

de aplicar os resultados obtidos a ferramentas mais sofisticadas permitindo, por

exemplo, acesso web além de portabilidade.

72

REFERÊNCIAS

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 10151: acústica: avaliação do ruído em áreas habitadas, visando o conforto da comunidade: procedimento. Rio de Janeiro, 1999. BOUCKAERT, Remco R. et. al. WEKA manual for version 3-7-3 . New Zealand: University of Waikato, 2010. Disponível em: <http://www.cs.waikato.ac.nz/ml/weka/index.html>. Acesso em: 26 maio 2011. CEGLAR, Aaron; RODDICK, John F. Association mining. ACM Computing Surveys , v. 38, n 2. July 2006. Disponível em: <http://portal.acm.org/citation.cfm?id=1132956.1132958&coll=DL&dl=GUIDE&CFID=23752610&CFTOKEN=66987378>. Acesso em: 26 maio 2011. COMPANHIA DE TECNOLOGIA DE SANEAMENTO AMBIENTAL. Norma técnica L11.032: ruído : determinação do nível de ruído em ambientes internos e externos de áreas habitadas- método de ensaio. São Paulo, 1992. GENG, Liqiang; HAMILTON, Howard J. Interestingness measures for data mining: a survey. ACM Computing Surveys , v. 38, n 3. September 2006. Disponível em: <http://portal.acm.org/citation.cfm?id=1132960.1132963&coll=DL&dl=GUIDE&CFID=23752610&CFTOKEN=66987378>. Acesso em: 26 maio 2011. LUJÁN-MORA, Sergio; TRUJILLO, Juan. Physical modelin of data warehouses using UML. In Proceedings of the 7th ACM international workshop o n Data warehousing and OLAP . (Washington, DC, USA, November 12–13, 2004). DOLAP '04, p. 48 - 57. Disponível em: <http://portal.acm.org/citation.cfm?id=1031763.1031772&coll=DL&dl=GUIDE&CFID=23507023&CFTOKEN=82748358 >. Acesso em: 25 maio 2011. MACHADO, Felipe Nery Rodrigues. Tecnologia e projeto de data Warehouse : uma visão multidimensional. São Paulo: Érica, 2004. MUÑOZ, Lilia; MAZÓN, Jose-Norberto; TRUJILLO, Juan. Automatic generation of ETL processes from conceptual models. In Proceeding of the ACM twelfth international workshop on Data warehousing and OLAP . (Hong Kong, China, November 6, 2009). DOLAP’09. p. 33 - 40. Disponível em: <http://portal.acm.org/citation.cfm?id=1651291.1651298&coll=DL&dl=GUIDE&CFID=23507023&CFTOKEN=82748358>. Acesso em: 25 maio 2011.

73

ORACLE. MySQL 5.1 Reference Manual :Including MySQL Cluster NDB 6.X/7.X Reference Guide. 2011. Disponível em: <http://dev.mysql.com/doc/refman/5.1/en/>. Acesso em: 8 jun. 2011. PAIVA, Manoel. Matemática : volume único. 2. ed. São Paulo: Moderna, 2003. PARDILLO, Jesús; MANSMANN, Florian. Towards readable layouts for modeling data warehouses. In Proceedings of the ACM 13th international workshop on Data warehousing and OLAP . (Toronto, Ontario, Canada, October 30, 2010). DOLAP’10. p. 25 - 29. Disponível em: <http://portal.acm.org/citation.cfm?id=1871940.1871947&coll=DL&dl=GUIDE&CFID=23752610&CFTOKEN=66987378>. Acesso em: 26 maio 2011. ROCHA, Thyago Antonio Barbosa Vieira da. Estudo comparativo entre técnicas de aprendizagem de máquina para sistemas de detecçã o de intrusão (IDS). 2005. 66 f. Trabalho de Conclusão de Curso (Graduação em Engenharia da Computação) - Escola Politécnica de Pernambuco : Universidade de Pernambuco, Pernambuco, 2005. Disponível em: <http://dsc.upe.br/~tcc/20052/ThyagoAntonioRocha.pdf>. Acesso em: 30 junho 2011. SILVA, Edna L da; MENEZES, Ester M. Metodologia da pesquisa e elaboração de dissertação . 4. ed. rev. atual. Florianópolis: UFSC, 2005. Disponível em: <http://tccbiblio.paginas.ufsc.br/files/2010/09/024_Metodologia_de_pesquisa_e_elaboracao_de_teses_e_dissertacoes1.pdf>. Acesso em: 17 junho 2011. VASSILIADIS, Panos; SIMITSIS, Alkis; BAIKOUSI, Eftychia. A taxonomy of ETL activities. In Proceeding of the ACM twelfth international worksho p on Data warehousing and OLAP .(Hong Kong, China, November 6, 2009). DOLAP’09. p. 25 - 32. Disponível em: <http://portal.acm.org/citation.cfm?id=1651291.1651297&coll=DL&dl=GUIDE&CFID=25144678&CFTOKEN=24546119>. Acesso em: 24 maio 2011. WAINER, Jacques. Métodos de pesquisa quantitativa e qualitativa para a Ciência da Computação. In: Tomasz Kowaltowski and Karin Breitman (Org.). Atualização em informática 2007 . SBC e Editora PUC-Rio, 2007. p. 221-262. Disponível em: < http://www.ic.unicamp.br/~wainer/papers/metod07.pdf>. Acesso em: 17 junho 2011. WITTEN, Ian H; FRANK Eibe. Data mining pratical machine learning tools and techniques . San Francisco: Elsevier, 2005.

74

APENDICE A – DETALHAMENTO DO RESULTADO DOS FLUXOS E TL

Resultados do segundo fluxo ETL Fonte: Autoria Própria, 2011.

Resultados do terceiro fluxo ETL Fonte: Autoria Própria, 2011.

75

Resultados do quarto fluxo ETL Fonte: Autoria Própria, 2011.

Resultados do quinto fluxo ETL Fonte: Autoria Própria, 2011.

Resultados do sexto fluxo ETL Fonte: Autoria Própria, 2011.

76

Resultados do sétimo fluxo ETL Fonte: Autoria Própria, 2011.

Resultados do oitavo fluxo ETL Fonte: Autoria Própria, 2011.

77

Resultados do nono fluxo ETL Fonte: Autoria Própria, 2011.

Resultados do décimo fluxo ETL Fonte: Autoria Própria, 2011.

78

Resultados do décimo quarto fluxo ETL Fonte: Autoria Própria, 2011.

79

Resultados do décimo quinto fluxo ETL Fonte: Autoria Própria, 2011.

80

APENDICE B – QUADROS COMPARATIVOS DOS 71 ALGORITMOS DE

DATAMING PARA CADA LIMITE DE LEQ

Avaliação dos algoritmos para 70 dB

Fonte: Autoria Própria, 2011.

81

Avaliação dos algoritmos para 60 dB

Fonte: Autoria Própria, 2011.

82

APENDICE C – DETALHAMENTO DAS REGRAS GERADAS

Resultados para o ponto 2 com algoritmos Bagging e DecisionStump Fonte: Autoria Própria, 2011.


83


84


Resultados para o ponto 6 com algoritmo Bagging e DecisionStump Fonte: Autoria Própria, 2011.

85

Resultados para o ponto 7 com algoritmo Bagging e DecisionStump Fonte: Autoria Própria, 2011.


86

Resultados para o ponto 3 com algoritmos J48Graft e Part Fonte: Autoria Própria, 2011.


87

Figura 35 - Resultados para o ponto 7 com algoritmos J48Graft e Part Fonte: Autoria Própria, 2011.

88


SISTEMA DE OBTENÇÃO DE RECOMENDAÇÕES PARA … · 0 edson roberto duarte weren sistema de...

Documents

Transcript of SISTEMA DE OBTENÇÃO DE RECOMENDAÇÕES PARA … · 0 edson roberto duarte weren sistema de...