sistema de obtenÇÃo de recomendaÇÕes para … · 0 edson roberto duarte weren sistema de...
Post on 09-Nov-2018
215 Views
Preview:
TRANSCRIPT
0
EDSON ROBERTO DUARTE WEREN
SISTEMA DE OBTENÇÃO DE RECOMENDAÇÕES PARA ANÁLISE
DE RUÍDO AMBIENTAL
CANOAS, 2011
1
EDSON ROBERTO DUARTE WEREN
SISTEMA DE OBTENÇÃO DE RECOMENDAÇÕES PARA ANÁLISE
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
EDSON ROBERTO DUARTE WEREN
SISTEMA DE OBTENÇÃO DE RECOMENDAÇÕES PARA ANÁLISE
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 14 - Nível 2 do Esquema Conceitual de um DW ............................................ 50
Figura 15 - Nível 3 do Esquema Conceitual de um DW ............................................ 51
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 3 com algoritmos Bagging e DecisionStump ..................... 82
Resultados para o ponto 4 com algoritmos Bagging e DecisionStump ..................... 83
Resultados para o ponto 5 com algoritmos Bagging e DecisionStump ..................... 84
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 8 com algoritmos Bagging e DecisionStump ..................... 85
Resultados para o ponto 3 com algoritmos J48Graft e Part ...................................... 86
Resultados para o ponto 6 com algoritmos J48Graft e Part ...................................... 86
Figura 35 - Resultados para o ponto 7 com algoritmos J48Graft e Part .................... 87
Resultados para o ponto 8 com algoritmos J48Graft e Part ...................................... 88
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.
Figura 14 - Nível 2 do Esquema Conceitual de um DW Fonte: Adaptado de Mora et al, 2004.
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.
Figura 15 - Nível 3 do Esquema Conceitual de um DW Fonte: Adaptado de Mora et al, 2004.
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
No ponto 4 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. 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.
No ponto 7 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. 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.
Resultados para o ponto 3 com algoritmos Bagging e DecisionStump Fonte: Autoria Própria, 2011.
83
Resultados para o ponto 4 com algoritmos Bagging e DecisionStump Fonte: Autoria Própria, 2011.
84
Resultados para o ponto 5 com algoritmos Bagging e DecisionStump Fonte: Autoria Própria, 2011.
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.
Resultados para o ponto 8 com algoritmos Bagging e DecisionStump Fonte: Autoria Própria, 2011.
86
Resultados para o ponto 3 com algoritmos J48Graft e Part Fonte: Autoria Própria, 2011.
Resultados para o ponto 6 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
Resultados para o ponto 8 com algoritmos J48Graft e Part Fonte: Autoria Própria, 2011.
top related