MINERAÇÃO DE DADOS:

UMA IMPLEMENTAÇÃO FORTEMENTE ACOPLADA A UM SISTEMA

GERENCIADOR DE BANCO DE DADOS PARALELO

MAURO SÉRGIO RIBEIRO DE SOUSA

TESE SUBMETIDA AO CORPO DOCENTE DA COORDENAÇÃO DOS

PROGRAMAS DE PÓS-GRADUAÇÃO DE ENGENHARIA DA UNIVERSIDADE
FEDERAL DO RIO DE JANEIRO COMO PARTE INTEGRANTE DOS REQUISITOS
NECESSÁRIOS PARA OBTENÇÃO DE GRAU DE MESTRE EM CIÊNCIAS EM
ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.

APROVADA POR:
_______________________________________
Prof. Marta L. Q. Mattoso, D. Sc.
(Presidente)

_______________________________________
Prof. Nelson Francisco Favilla Ebecken, D. Sc.

_______________________________________
Prof. Maria Luiza Machado Campos, Ph. D.

_______________________________________
Prof. Alex Alves Freitas, Ph. D.

RIO DE JANEIRO, RJ – BRASIL

AGOSTO DE 1998

i
SOUSA, MAURO SÉRGIO RIBEIRO
Mineração de Dados: Uma
implementação fortemente acoplada a um
sistema gerenciador de banco de dados
paralelo [Rio de Janeiro] 1998
VIII, 67 p., 29, 7 cm (COPPE/UFRJ,
M.Sc., Engenharia de Sistemas e
Computação, 1998)
Tese – Universidade Federal do Rio
de Janeiro, COPPE
1. Mineração de Dados.
2. Paralelismo em SGBDs.
I. COPPE/UFRJ II.Título (série)

ii
Resumo da tese apresentada à COPPE / UFRJ como parte dos requisitos necessários
para a obtenção do grau de Mestre em Ciências (M. Sc.).

MINERAÇÃO DE DADOS:
UMA IMPLEMENTAÇÃO FORTEMENTE ACOPLADA A UM SISTEMA
GERENCIADOR DE BANCO DE DADOS PARALELO

Mauro Sérgio Ribeiro de Sousa

Agosto de 1998
Orientador: Marta Lima de Queirós Mattoso
Nelson Francisco Favilla Ebecken

Programa: Engenharia de Sistemas e Computação

Banco de Dados

As últimas décadas vêm mostrando a necessidade de um processo automatizado

para a descoberta de padrões interessantes e desconhecidos em bancos de dados reais,
envolvendo grandes volumes de dados. Este tipo de processo implica em um poder
computacional muito grande, memória e E/S, os quais podem ser oferecidos por
máquinas baseadas em arquiteturas paralelas. Nosso trabalho contribui com uma
solução que integra um algoritmo de aprendizado de máquina, paralelismo e a utilização
fortemente acoplada de um SGBD, endereçando problemas de desempenho com
processamento paralelo e fragmentação de dados.

iii
 Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the
requirements for the degree of Master of Science (M. Sc.).

DATA MINING: A TIGHTLY-COUPLED IMPLEMENTATION ON A

PARALLEL DATABASE SERVER

Mauro Sérgio Ribeiro de Sousa

August / 1998
Advisor: Marta Lima de Queirós Mattoso
Nelson Francisco Favilla Ebecken

Department: System Engineering

Databases

Recent years have shown the need of an automated process to discover

interesting and hidden patterns in real-world databases, handling large volumes of data.
This sort of process implies a lot of computational power, memory and disk I/O, which
can only be provided by parallel computers. Our work contributes with a solution that
integrates a machine learning algorithm, parallelism and a tightly-coupled use of a
DBMS, addressing performance problems with parallel processing and data
fragmentation.

iv
 À minha filha, Júlia, nascida no decorrer do mestrado, e à minha esposa, Eliane,
que, com paciência e muita compreensão, muito me incentivou a cumprir mais esta
etapa de minha vida.
Aos meus pais, Tércio e Wilma, pelo apoio e por terem me oferecido uma boa
educação, muitas vezes fazendo sacrifícios, mas nunca encarando como uma obrigação,
mas sim como uma maneira de dar um futuro melhor para mim e para meus irmãos.

v
 AGRADECIMENTOS

À professora Marta Mattoso, uma pessoa sempre presente e disposta a ajudar,

pela orientação atenciosa e pela amizade.
Ao professor Nelson Ebecken, meu co-orientador, que, com sua experiência e
visão prática dos assuntos, possibilitou o sucesso do trabalho.
À professora Maria Luiza, que conheci durante a graduação e com a qual aprendi
os primeiros conceitos na área de banco de dados, pela motivação tanto na área
profissional quanto na área acadêmica.
À todos os amigos que conquistei na COPPE, incluindo professores, alunos e
funcionários.

vi
 ÍNDICE

CAPÍTULO 1- INTRODUÇÃO ............................................................................................. 1

CAPÍTULO 2- TÉCNICAS DE MINERAÇÃO DE DADOS ................................................ 4

2.1.CLASSIFICAÇÃO .............................................................................................................. 5
2.1.1.Árvores de Decisão ................................................................................................. 5
2.1.2.Redes Neurais ......................................................................................................... 6
2.2.REGRAS DE ASSOCIAÇÃO................................................................................................. 6
2.3.AGRUPAMENTO (CLUSTERING) ........................................................................................ 7
2.4.PADRÕES SEQÜENCIAIS ................................................................................................... 7
2.5.VISÃO GERAL DE SISTEMAS DE MINERAÇÃO DE DADOS.................................................... 8
2.5.1.Quest ...................................................................................................................... 8
2.5.2.DBMiner................................................................................................................. 8
2.5.3.SKICAT .................................................................................................................. 9
2.5.4.Outros Trabalhos .................................................................................................... 9

CAPÍTULO 3- PARALELISMO NA GERÊNCIA DOS DADOS DE MINERAÇÃO ...... 10

3.1.UTILIZAÇÃO DE GRANDES VOLUMES EM MINERAÇÃO DE DADOS .................................... 10

3.1.1.Arquivos Isolados.................................................................................................. 10
3.1.2.Mineração de Dados e SGBDs .............................................................................. 11
3.2.CONSIDERAÇÕES SOBRE SGBDS E ARQUITETURAS PARALELAS ...................................... 11
3.3.OPORTUNIDADES PARA SGBDS PARALELOS EM ALGORITMOS DE
MINERAÇÃO DE DADOS ................................................................................................ 12
3.4.SERVIDOR PARALELO DA ORACLE ................................................................................. 14
3.4.1.Operações Paralelas Disponíveis .......................................................................... 15
3.4.2.Consultas Paralelas e a Regra 9/13....................................................................... 17
3.4.3.Grau de Paralelismo ............................................................................................. 18
3.4.4.Oracle Parallel Server e a Arquitetura MPP.......................................................... 19

- MINERAÇÃO DE DADOS UTILIZANDO ÁRVORES DE DECISÃO........................... 20

4.1.CRESCIMENTO DA ÁRVORE ............................................................................................ 21

4.2.PONTO DE QUEBRA........................................................................................................ 23
4.3.PODA (PRUNING)........................................................................................................... 25
4.4.EXTRAÇÃO DE REGRAS.................................................................................................. 28
4.4.1.Generalização das Regras..................................................................................... 28
4.4.2.Conjuntos de Regras ............................................................................................. 30
4.4.3.Ordenação de Regras e Classe Padrão.................................................................. 31

vii
CAPÍTULO 5.......... - IMPLEMENTAÇÃO DE UM ALGORITMO DE MINERAÇÃO DE
DADOS EM UM SGBD PARALELO............................................. 32

5.1.INTEGRAÇÃO FRACAMENTE ACOPLADA ......................................................................... 32

5.2.INTEGRAÇÃO FORTEMENTE ACOPLADA.......................................................................... 33
5.3.CONSULTAS TÍPICAS DE UM ALGORITMO DE INDUÇÃO DE REGRA.................................... 35
5.4.PONTO DE QUEBRA........................................................................................................ 36
5.4.1.Atributos Contínuos .............................................................................................. 36
5.4.2.Atributos Discretos ............................................................................................... 39
5.5.PODA ............................................................................................................................ 40
5.6.EXTRAÇÃO DE REGRA ................................................................................................... 43
5.7.TÉCNICAS DE FRAGMENTAÇÃO ...................................................................................... 44
5.7.1.Fragmentação Horizontal ..................................................................................... 44
5.7.2.Fragmentação Vertical.......................................................................................... 46
5.8.FRAGMENTAÇÃO E PROBLEMAS DE ALOCAÇÃO .............................................................. 47

CAPÍTULO 6- AVALIAÇÃO DE DESEMPENHO ............................................................ 49

6.1.ESTUDO DE CASO........................................................................................................... 50
6.2.CRESCIMENTO DA ÁRVORE ............................................................................................ 51
6.3.TÉCNICAS DE FRAGMENTAÇÃO ...................................................................................... 54
6.4.PODA ............................................................................................................................ 55
6.5.EXTRAÇÃO DE REGRAS.................................................................................................. 56

7.CONCLUSÕES.................................................................................................................. 59

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 63

viii
 CAPÍTULO 1 - Introdução

Com a recente explosão da informação e a disponibilidade de armazenamento

barato, tem sido possível coletar dados maciçamente durante as últimas décadas. O
objetivo desta coleta intensiva de dados é o uso destas informações para ganhar
vantagens competitivas, descobrindo padrões não conhecidos nos dados, os quais
podem guiar o processo de decisão.
Os últimos anos mostraram que está ficando cada vez mais difícil analisar os
dados utilizando apenas ferramentas OLAP (Online Analytical Process), existindo a
necessidade de um processo automatizado para descobrir padrões desconhecidos nos
dados. Técnicas de mineração de dados têm sido crescentemente estudadas [16, 37],
especialmente nas suas aplicações em bancos de dados reais. Um problema típico é que
bancos de dados tendem a ser muito grandes e estas técnicas freqüentemente necessitam
varrer repetidamente o conjunto inteiro de dados. A extração de uma amostra de
treinamento é uma solução por muito tempo utilizada, de tal forma que o algoritmo de
mineração de dados possa ser executado acessando uma porção menor de informação.
Neste caso, diferenças sutis entre conjuntos de objetos se tornam menos evidentes.
A necessidade de manusear grandes quantidades de dados implica em um maior
poder computacional, memória e E/S, que podem ser oferecidos por arquiteturas
projetadas para o processamento paralelo. Uma variedade de algoritmos de mineração
de dados têm sido propostos endereçando processamento paralelo, a maioria deles
utilizando arquivos isolados, explorando o paralelismo através da programação.
Apesar da idéia de utilizar SGBDs em mineração de dados não ser nova [4, 13],
a maioria das implementações utiliza-os somente para executar consultas que são
disparadas e processadas por uma máquina cliente. Um exemplo é o sistema SKICAT
[17], que utiliza um SGBD relacional (Sybase) para armazenamento, modificação e
gerenciamento de dados. Desta forma, a maioria das aplicações de mineração de dados
possuem um fraco acoplamento com bancos de dados, resultando em problemas de
desempenho e limitações quanto à memória disponível [7]. Um outro exemplo é o
sistema de mineração de dados Quest [6], cujos algoritmos vêm sendo paralelizados
para executar em máquinas multiprocessadas de memória distribuída da IBM (RS/6000

1
SP2), utilizando tanto arquivos isolados quanto a família de produtos de banco de dados
DB2. Neste caso, o SGBD também é acessado de um modo fracamente acoplado.
Mostrando a importância da utilização de bancos de dados em mineração de dados,
Freitas [20, 21, 23] apresentou uma série de primitivas para indução de regra (IR), após
a análise de vários algoritmos de Knowledge Discovery in Databases (KDD) do
paradigma de IR. As primitivas podem ser traduzidas em tipos de comandos SQL que
oferecem um potencial grau de paralelismo em SGBDs paralelos.
Um requisito de mineração de dados é a eficiência e poder de expansão de seus
algoritmos, o que torna ainda mais relevante o uso de paralelismo para oferecer uma
maneira de processar tarefas longas em tempo hábil. Neste contexto, sistemas de banco
de dados paralelos desempenham um papel importante, porque eles podem oferecer,
entre outras vantagens, implementação de paralelismo transparente e simples para
processar grandes conjuntos de dados. É importante perceber que, quando mencionamos
o uso de grandes quantidades de informação em mineração de dados, não estamos nos
referindo aos usuais volumes dos SGBDSs existentes, os quais podem alcançar mais de
um terabyte de dados. Métodos de mineração de dados normalmente varrem
repetidamente o conjunto de dados completo, sendo a mineração em tais bases de dados
ainda não citada na literatura corrente. Para estes métodos, um grande número de
atributos (algumas dezenas) e um número razoável de casos (algumas centenas de
milhares) representam um problema suficientemente complexo a ser resolvido nos dias
de hoje.
O problema que este trabalho visa abordar é representado pela necessidade do
manuseio de uma quantidade cada vez maior de informações durante processos de
mineração de dados e pela incapacidade de grande parte das aplicações atualmente
existentes em fazê-lo. Devido às características dos processos de mineração, o uso de
paralelismo é um outro fator importante a ser considerado, uma vez que um grande
volume de dados é envolvido e o término do processo em um tempo hábil é
naturalmente importante para o seu sucesso. Algumas soluções baseadas em arquivos
isolados foram propostas, mas a utilização de um SGBD representa uma solução
natural, uma vez que SGBDs vêm sendo utilizados com sucesso no gerenciamento do
negócio e, atualmente, podem armazenar conhecimento valioso não conhecido. Nosso
trabalho contribui com uma solução que integra um algoritmo de aprendizado de

2
máquina, paralelismo e uma utilização fortemente acoplada de um SGBD [45, 46, 47].
Nós ressaltamos as vantagens de uma forte integração de técnicas de mineração de
dados a sistemas de banco de dados, endereçando problemas de desempenho com
processamento paralelo e fragmentação de dados.
Visando validar nossos experimentos, utilizamos o Oracle Parallel Server
(OPS), configurado em um sistema RISC/6000 SP2 da IBM com 4 (quatro) nós. Um
conjunto de procedimentos armazenados escritos em PL/SQL foi construído, sendo
estes procedimentos armazenados dentro do dicionário de dados do Oracle, oferecendo
alto desempenho e integração nativa com o banco de dados. Os experimentos foram
validados através de uma aplicação genérica representando diversas situações adversas,
contendo um volume de tuplas e atributos que caracterizam uma aplicação complexa.
Esta tese foi organizada da seguinte forma. No capítulo 2, apresentamos as
principais técnicas utilizadas em mineração de dados e analisamos alguns sistemas
existentes. No capítulo 3, discutimos possibilidades de gerência de dados a serem
utilizados no processo de mineração. Em particular, analisamos a adequação do
processamento paralelo em SGBDs ao processo de mineração de dados e apresentamos
a funcionalidade oferecida pelo OPS. O capítulo 4 apresenta a combinação de técnicas
escolhidas para o desenvolvimento de mineração de dados fortemente acoplada a um
SGBD paralelo. A apresentação das técnicas conta com uma discussão quanto às
possibilidades de implementação via SGBDs. O capítulo 5 discute as soluções adotadas
na implementação das técnicas descritas no capítulo 4 junto ao servidor paralelo da
Oracle. A validação da implementação é realizada através de um estudo de caso sobre
uma aplicação complexa descrita no capítulo 6, onde também são apresentados os
resultados de desempenho obtidos. Finalmente, no capítulo 7, apresentamos nossas
conclusões e futuros trabalhos a serem realizados.

3
 CAPÍTULO 2 - Técnicas de Mineração de Dados

Mineração de dados é uma fase na descoberta de conhecimento em bancos de

dados (KDD) que procura por uma série de padrões escondidos nos dados,
freqüentemente envolvendo uma aplicação iterativa e repetitiva de métodos de
mineração de dados particulares. O objetivo de todo o processo de KDD é tornar os
padrões compreensíveis às pessoas, visando facilitar uma melhor interpretação dos
dados existentes [16, 18, 19].

Interpretação
Avaliação

Mineração de
Dados

Transformação

Pré-processamento conhecimento
padrões
Seleção dados
dados transformados
pré-processados
alvo

dados

Figura 1: Processo KDD (Knowledge Discovery in Databases). Fonte: [16]

A Figura 1 apresenta, resumidamente, todo o processo de KDD, englobando

uma fase de seleção de dados, que visa focar em um subconjunto de variáveis, uma
etapa de limpeza e pré-processamento dos dados, a escolha do objetivo do processo
KDD, a mineração de dados propriamente dita, e a interpretação e consolidação do
conhecimento descoberto.
Nós apresentamos a seguir quatro classes de tarefas de mineração de dados
tipicamente encontradas em uma variedade de aplicações e pesquisas reconhecidas e
atualmente citadas na comunidade de mineração de banco de dados. Elas, obviamente,
não representam todas as tarefas de mineração, mas representam uma considerável
porção delas quando uma grande quantidade de dados é considerada.

4
2.1. Classificação
Classificação é uma tarefa de mineração de dados bastante conhecida que vem
sendo estudada nas comunidades de aprendizado de máquina e estatística por um longo
tempo [10,12,31,34,42]. Seu objetivo é classificar casos em diferentes classes, baseado
em propriedades (atributos) comuns entre um conjunto de objetos em uma base de
dados. O modelo de classificação construído é utilizado para predizer classes de novos
casos que serão incluídos em um banco de dados. Aplicações adequadas para
classificação incluem diagnóstico médico, avaliação de risco de crédito, detecção de
fraude e propaganda direcionada.
Entre os algoritmos de classificação, existem dois métodos amplamente
utilizados: árvores de decisão e redes neurais.

2.1.1. Árvores de Decisão

Métodos de árvore de decisão representam um tipo de algoritmo de aprendizado

de máquina que utilizam uma abordagem dividir-para-conquistar para classificar casos
usando uma representação baseada em árvores [12,42]. Eles usualmente utilizam um
algoritmo guloso que recursivamente subdivide o conjunto de treinamento até alcançar
uma partição que represente casos total ou dominantemente pertencentes à mesma
classe, ou até que um critério de parada seja alcançado (pré-poda). Ao decidir qual
atributo será utilizado em cada subdivisão, um teste estatístico é adotado como critério
de quebra.
Após a fase de crescimento da árvore, podemos nos deparar com uma estrutura
especializada que está superajustada aos dados, oferecendo mais estrutura que o
necessário. A poda passa a desempenhar um papel importante, produzindo árvores
menores com potencialmente melhor precisão quando novos casos são considerados
[42].
Mesmo após a fase de poda, uma árvore pode ainda representar uma estrutura
complexa e de difícil compreensão. A extração de regras é a fase final utilizada para
extrair regras menores e menos complexas com precisão similar. Um algoritmo guloso é
normalmente utilizado para selecionar o subconjunto mínimo de regras que cobrem os
exemplos [26].

5
 O principal problema relativo a árvores é que elas precisam de uma considerável
quantidade de dados para desvendar estruturas complexas. Por outro lado, árvores
podem ser construídas de forma consideravelmente mais rápida do que alguns métodos
alternativos de classificação, produzindo resultados com precisão similar [37].
Existem várias implementações utilizando algoritmos de aprendizado baseados
em árvores de decisão, tais como o CART [12], ID3 e seu sucessor C4.5 [42] e o
SPRINT (implementação paralela do SLIQ) [44, 34].

2.1.2. Redes Neurais

Métodos baseados em redes neurais artificias [11] oferecem um método prático
para funções de aprendizado, representadas por atributos contínuos, discretos ou
vetores. Uma característica importante do algoritmo é sua robustez ao lidar com erros
no conjunto de treinamento. Basicamente, redes neurais têm sido usadas para interpretar
cenas visuais e reconhecimento de voz, sendo usadas não somente para classificação
(i.e. redes neurais são amplamente utilizadas para propósitos de predição).
Algoritmos de redes neurais tipicamente necessitam de maior força
computacional que, por exemplo, algoritmos de árvores de decisão [37]. Os tempos de
treinamento variam dependendo do número de casos de treinamento, número de pesos
na rede e das configuração dos diversos parâmetros do algoritmo de aprendizado. Redes
neurais aprendidas não são facilmente compreensíveis para pessoas, o que não ocorre
com regras, as quais são facilmente interpretadas. Entretanto, recentemente tem havido
bastante pesquisa sobre como extrair regras de redes neurais.

2.2. Regras de Associação

A mineração de regras de associação [5, 8, 50] é tipicamente importante ao
tentar encontrar associações relevantes entre itens de uma dada transação de um cliente.
Um exemplo da saída de tal mineração é a sentença que diz que

80% das transações que negociam fraldas e leite também lidam com mamadeiras,

onde o número 80% é o fator de confiabilidade da regra.

Uma apresentação formal do problema é apresentada em [5].
Seja I = {i1, i2, i3, .., im} um conjunto de atributos binários de itens e seja T transações
em um banco de dados. Cada transação t é representada por um vetor binário, com

6
t[k] = 1 se t comprou o item ik e t[k] = 0 caso contrário. É interessante perceber que,
neste momento, não estamos preocupados com quantidades, isto é, quantos itens são
comprados em cada transação. Agora seja X um conjunto de itens tal que X ⊂ I.
Podemos dizer que uma transação t satisfaz X se, para todos os itens em X, t[k] = 1.
Uma regra de associação é uma implicação da forma X ⇒Y, onde X ⊂ I, Y ⊂ I,
e X ∩Y = ∅. Se c% das transações em T que contêm X também contêm Y, então c%
representa o fator de confiabilidade da regra. A regra X ⇒Y tem o suporte s% se s% das
transações em T contêm X ∪ Y.
O problema de mineração de regras de associação pode ser decomposto em duas
partes:
• Gerar todas as combinações de itens que possuam um suporte de transações
acima de um limite mínimo informado. Essas combinações de itens com
suporte acima do mínimo são chamadas de conjuntos grandes. Esta fase é
considerada a tarefa que consome mais tempo do algoritmo.
• Para todos os conjuntos grandes, gerar regras de associação para o banco de
dados de transação, o que é feito de uma maneira bastante direta.

2.3. Agrupamento (Clustering)

Algoritmos de agrupamento [2], uma forma de aprendizado não supervisionado,

representam um processo de agrupamento de objetos físicos ou abstratos em classes de
objetos similares. A análise de agrupamento ajuda a identificar grupos significativos de
grandes conjuntos de objetos baseados na metodologia “dividir para conquistar”, a qual
decompõe um sistema de grande escala em componentes menores para simplificar o
projeto e implementação.

2.4. Padrões Seqüenciais

A descoberta de padrões seqüenciais [48] tem sido motivada por aplicações na
indústria varejista, incluindo mala direta e vendas on-line, e no domínio da medicina,
por exemplo.
Os dados de entrada são tipicamente uma lista de transações seqüenciais,
existindo freqüentemente um tempo de transação associada a cada uma delas. O
objetivo primário é encontrar todos os padrões seqüenciais com um suporte mínimo pré-

7
definido, isto é, a porcentagem de seqüências de dados que contêm o padrão está acima
de um limite fornecido. Consequentemente, algoritmos de padrões seqüenciais são úteis
para descobrir tendências nos dados, tais como:
O número de revistas de esporte vendidas a clientes com receita entre 20,000 e
30,000 morando na cidade 2 está crescendo.

2.5. Visão Geral de Sistemas de Mineração de Dados

Nesta seção apresentamos alguns sistemas de mineração de dados e outros
trabalhos interessantes na área. Eles possuem em comum o fato de serem
implementados levando em consideração grandes volumes de dados.

2.5.1. Quest
O sistema de mineração de dados Quest [6] vem endereçando o desenvolvimento
de algoritmos rápidos e escaláveis. Os algoritmos implementados incluem regras de
associação, generalização, padrões seqüenciais, agrupamento baseado em séries
temporais e classificação. Os algoritmos do Quest foram paralelizados utilizando
máquinas multiprocessadas da IBM (SP2). Eles têm trabalhado com a implementação
paralela da mineração de regras de associação (APRIORI [8]) e com o algoritmo de
classificação SPRINT [44], onde vários processadores são capazes de trabalhar juntos
para construir um modelo de classificação, particularmente uma árvore de decisão.
Estes algoritmos utilizam tanto arquivos isolados quanto a família de produtos DB2,
mas bancos de dados são acessados de um modo fracamente acoplado usando SQL
dinâmico. O sistema Quest é comercialmente disponível através do Intelligent Miner da
IBM [49].

2.5.2. DBMiner
O DBMiner [26,27] integra mineração de dados com sistemas de bancos de
dados relacionais, oferecendo uma interface para a descoberta de conhecimento baseada
em SQLs para generalização de dados baseada em operações relacionais, facilitando sua
integração com SGBDs relacionais. O DBMiner foi projetado com ênfase na
simplicidade e extensibilidade. Seus módulos incluem caracterização e associação de
múltiplos níveis, descoberta de regras discriminantes, classificação e predição.

8
2.5.3. SKICAT
O sistema SKICAT [17] (Sky Image Cataloging Analysis Tool) foi
implementado para processar imagens do Second Palomar Observatory Sky Survey
(POSS-II). Ele utiliza uma variedade de técnicas de classificação supervisionada para
automatizar a redução e análise de grandes conjuntos de dados de astronomia,
integrando métodos para processamento de imagens, classificação de dados e
gerenciamento de bancos de dados. Desta forma, o propósito do SKICAT é permitir e
maximizar a extração de informação significativa de um grande banco de dados de uma
maneira eficiente e em tempo hábil. Alguns algoritmos de aprendizado (GID3*, O-Btree
e RULER) são usados para produzir árvores de decisão e regras de classificação a partir
de dados de treinamento consistindo de objetos classificados na astronomia.

2.5.4. Outros Trabalhos

Freitas [20, 21, 23] apresentou uma série de primitivas para indução de regras,
após analisar vários algoritmos de KDD do paradigma de IR. Operações principais do
procedimento de avaliação de regras candidatas são descritas considerando
características de desempenho e paralelização. As primitivas podem ser traduzidas em
cláusulas GROUP BY / ORDER BY usuais em comandos SQL, os quais
freqüentemente oferecem um alto grau de paralelismo em SGBDs paralelos.
Holshemeir et al. [28] implementaram uma arquitetura de dois níveis para
descobrir regras. Um SGBD (Monet Database Server, desenvolvido em CWI) foi
utilizado nos experimentos, sendo o algoritmo ID3 utilizado como ponto de partida. Os
resultados são apresentados usando um estudo de caso com 100k casos (2.6Mb
comprimidos). Na execução paralela, uma relação de 25k foi utilizada com 4 nós.

9
 CAPÍTULO 3 - Paralelismo na Gerência dos
Dados de Mineração

A necessidade cada vez maior de atender a sistemas de suporte a decisão (DSS)

e a novas classes de aplicações não convencionais, que necessitam lidar com consultas
complexas envolvendo um grande volume de dados, motivaram o desenvolvimento de
sistemas gerenciadores de bancos de dados paralelos (SGBDP). Um SGBDP visa
explorar o processamento oferecido por arquiteturas paralelas baseadas na utilização de
componentes comuns (processadores, memória e discos). Como motivações principais
para SGBDPs podemos citar a maior velocidade e a conseqüente possibilidade de
manipulação de um maior volume de dados, fatores de vital importância para o sucesso
do processo de mineração de dados.
Uma discussão detalhada sobre características de sistemas gerenciadores de
banco de dados, em especial sobre os SGBDs paralelos, pode ser encontrada em [36,
39, 51], enquanto que vantagens do processamento paralelo em um grande volume de
dados utilizando SGBDs são apresentadas na seção 3.2.

3.1. Utilização de Grandes Volumes em Mineração de Dados

Uma característica importante do processo de mineração de dados é que ele pode
utilizar dados que foram coletados durante vários anos para transformá-los em
conhecimento valioso. Quanto maior o banco de dados, mais apropriado e preciso tende
a ser o conhecimento adquirido. Aplicações de mineração de dados trabalham com dois
tipos de fonte de dados, cada uma com suas próprias vantagens: arquivos isolados e
sistemas gerenciadores de banco de dados. O paralelismo pode ser empregado nos dois
casos.

3.1.1. Arquivos Isolados

Arquivos isolados vêm sendo largamente usados como fonte para algoritmos de
mineração de dados. Até mesmo quando os dados operacionais estão armazenados em
um SGBD, vários sistemas extraem uma porção das informações para ser utilizada no
processo de mineração, alguns deles trabalhando apenas com dados que cabem na
memória principal, fato que limita a quantidade total de informação a ser utilizada.

10
Implementações usando arquivos isolados oferecem algumas vantagens relacionadas a
resultados de desempenho.

3.1.2. Mineração de Dados e SGBDs

A tecnologia de banco de dados tem sido utilizada com sucesso no
processamento de dados do negócio tradicional. Empresas têm coletado uma grande
quantidade de informações, utilizando um SGBD para gerenciá-las. Consequentemente,
é desejável que tenhamos uma forma fácil e direta de utilizar a tecnologia de banco de
dados em outras áreas, tal como na mineração de dados.
A tecnologia de SGDB oferece várias funcionalidades que a tornam valiosa ao
implementar aplicações de mineração de dados. Por exemplo, é possível trabalhar com
conjuntos de dados consideravelmente maiores que a memória principal, uma vez que o
SGBD por si só é o responsável pelo manuseio das informações, paginação e swapping
quando necessário. Além disso, um gerenciamento simplificado dos dados e uma maior
integração com outros sistemas estão disponíveis (i. e. os dados podem ser atualizados
ou gerenciados como parte de um processo operacional mais abrangente). Além disso,
na medida em que os bancos de dados orientados a objetos [30] estão surgindo com a
capacidade de manusear imagem, vídeo e voz, existe uma área em potencial para
explorar a mineração de dados de tipos complexos. Finalmente, após a descoberta das
regras, podemos utilizar consultas ad-hoc e OLAP para validar os padrões descobertos
de uma maneira fácil. Não devemos esquecer que a informação usada durante o
processamento de mineração de dados é muitas vezes confidencial. Desta forma,
SGBDs podem também ser usados como um meio de oferecer a segurança necessária, a
qual é amplamente implementada em SGBDs comerciais, evitando a necessidade de
utilização de algoritmos de codificação para processar as informações.

3.2. Considerações sobre SGBDs e Arquiteturas Paralelas

Um SGBD paralelo deve ser projetado para tirar proveito da arquitetura no qual
o mesmo se baseia, visando o processamento paralelo eficiente das consultas típicas,
evitando comunicação desnecessária entre processadores. SGBDs paralelos baseados
em arquiteturas de memória distribuída freqüentemente implementam envio de funções.
Isto significa que tabelas e outros conjuntos de dados são estaticamente particionados e
operações baseadas nestas partições são efetuadas pelos nós que as possuem, em

11
resposta a uma mensagem enviada pelo processo coordenador. A principal vantagem do
envio de funções é sua escalabilidade. Além disso, a contenção na rede compartilhada é
minimizada porque somente fragmentos de planos de execução e respostas filtradas são
transmitidas. Por outro lado, o envio de funções em arquiteturas de memória distribuída
apresenta o problema de desbalanceamento de carga, uma vez que uma subutilização de
recursos pode ocorrer quando os dados não estão distribuídos uniformemente entre os
nós, ou quando os dados relevantes a uma consulta estão localizados em apenas um
subconjunto dos nós existentes.
Uma abordagem que pode ser usada em arquiteturas de discos compartilhados e
também de memória distribuída é o envio de dados, no qual qualquer processo pode
requisitar qualquer bloco de disco. Vários processos cooperantes executando em
paralelo oferecem paralelismo de UCP e E/S. Em sistemas de memória distribuída, as
mensagens podem ser usadas para enviar blocos do banco de dados para outros nós a
partir da rede. A principal vantagem do envio de dados é o balanceamento de carga
automático, uma vez que os dados podem ser divididos entre processos escravos durante
a execução da consulta. Além disso, o dicionário de dados está disponível através do
cluster, de tal forma que qualquer nó pode checar a sintaxe do SQL e otimizar
comandos. Uma desvantagem é o acesso remoto a discos potencialmente ineficiente em
máquinas de memória distribuída. Além disso, o alto tráfego de dados na rede pode
comprometer o desempenho do sistema, principalmente a medida que o número de
processadores aumenta.
Idealmente, a melhor abordagem seria uma que eliminasse as desvantagens do
envio de funções e de dados, usando as melhores características disponíveis, com o
mínimo de sobrecarga possível.

3.3. Oportunidades para SGBDs Paralelos em Algoritmos de

Mineração de Dados
Dado que é desejável que um processo de mineração de dados possa manipular
uma grande quantidade de dados, algoritmos paralelos são necessários para oferecer
escalabilidade, visando terminar o processo em tempo hábil. A classificação e a
descoberta de regras de associação são duas técnicas de mineração que vêm sendo
extensivamente estudadas para propósitos de paralelização [6,8,28,31]. Isto pode ser

12
explicado por diversos motivos, tais como a importância de tais tarefas para o uso
comercial, além de sua natural escalabilidade.
Uma variedade de algoritmos de mineração foram construídos para serem
executados em paralelo, tirando proveito de arquiteturas paralelas utilizando rotinas de
programação específicas. Como uma solução alternativa, sistemas de banco de dados
paralelos podem oferecer paralelismo de uma forma transparente para a aplicação.
Existem várias vantagens associadas à segunda abordagem:
• A implementação se torna mais simples.
Não existe a necessidade de utilizar rotinas paralelas disponíveis em algumas
linguagens de programação. O SGBD é por si só responsável por paralelizar as
consultas que por ele são processadas. Devemos estruturar nossas consultas de tal
forma que elas possam explorar o máximo possível do paralelismo oferecido por
um SGBD em particular.
• O SGBD é capaz de escolher entre planos de execução serial e paralelo
transparentemente para a aplicação.
Dependendo do algoritmo de mineração de dados e da técnica utilizada, fica claro
que o paralelismo é mais útil nas fases iniciais e intermediárias do processo. Na
construção de árvores de decisão, por exemplo, o conjunto de treinamento é
recursivamente subdividido e processado. Desta forma, assumindo que apenas
paralelismo de dados é explorado, a partir de algum ponto do processamento, o
paralelismo pode não ser útil porque a sobrecarga imposta pela comunicação entre
processos coordenador e escravo passa a representar o tempo dominante da
consulta, uma vez que poucos exemplos de treinamento estão sendo pesquisados.
Baseados em estatísticas sobre os dados, o SGBD pode avaliar o custo de planos de
consulta seriais e paralelos e decidir qual é o mais vantajoso, dependendo também
da quantidade de recursos de máquina disponíveis.
• Oportunidade para fragmentação de dados.
A fragmentação da base de dados [35,40] oferece várias vantagens relacionadas ao
reduzido número de acessos a páginas necessários para a leitura dos dados. Dados
irrelevantes para a consulta podem ser simplesmente ignorados dependendo do
filtro especificado nos comandos SQL. Além disso, alguns SGBDs podem
processar cada partição em paralelo, utilizando planos de execução diferentes

13
 quando aplicável. Em geral, SGBDs oferecem o gerenciamento automático de tal
funcionalidade.

Entretanto, algumas desvantagens devem ser consideradas, tais como:

• Menor controle sobre como a paralelização ocorre.
Apesar de existir a possibilidade de alguma customização, tal como a configuração
de quais nós participarão no processo, o SGBD está com o comando da
paralelização.
• O algoritmo pode se tornar dependente de alguma característica do SGBD paralelo
utilizado.
Em um banco de dados paralelo, podemos tentar direcionar qual o plano de
execução que o otimizador deve utilizar, mas nosso algoritmo pode se tornar
dependente de alguma característica específica existente.
• Sobrecarga do núcleo de um SGBD.
O núcleo de um SGBD é projetado para manusear um grande conjunto de
operações, tais como transações OLTP, consultas OLAP, etc. Apesar de existir a
possibilidade de minimizar a sobrecarga e customizar o ambiente para tirar o
melhor proveito possível da arquitetura correspondente, sempre existem algumas
funcionalidades implementadas que não são aplicáveis ao algoritmo de mineração
de dados, as quais podem degradar o desempenho quando comparado com o acesso
a arquivos isolados.

3.4. Servidor Paralelo da Oracle

O Oracle Parallel Server (OPS) é um produto da Oracle que roda em múltiplos

nós, redundantes e isolados, oferecendo disponibilidade contínua e isolando os usuários
e aplicação de falhas do sistema. O OPS permite que usuários em múltiplos nós acessem
o mesmo banco de dados simultaneamente, beneficiando-se de um maior poder
computacional para transações e maior disponibilidade para vários sistemas de
computadores. O OPS é um sistema de alta disponibilidade projetado para manusear
falhas em nós, discos ou interfaces de rede em um ambiente de cluster. Os sistemas são
interligados através de conexões de alta velocidade e baixa latência. Todos os nós no

14
cluster podem ter acesso concorrente de escrita e leitura aos dados localizados nos
discos compartilhados.
Devido ao fato que o OPS é um ambiente projetado para trabalhar com discos
compartilhados, uma parte essencial para seu funcionamento em uma arquitetura MPP é
o software que gerencia o bloqueio distribuído entre os nós (Distributed Lock Manager
- DLM). O DLM permite que vários recursos sejam compartilhados por múltiplos nós,
sincronizando acessos a blocos de disco entre os vários componentes do cluster.

3.4.1. Operações Paralelas Disponíveis

A opção de paralelização de consultas (Oracle Parallel Query – OPQ) [25], que
é incluída com o OPS, permite que instâncias do Oracle dividam o trabalho de processar
comandos SQL entre vários processos servidores de consulta. O OPS oferece a estrutura
para o funcionamento da opção OPQ através de um cluster, utilizando o mecanismo de
interconexão para transferir informações sobre transações distribuídas entre nós. No
Oracle 7.3, o paralelismo está concentrado nas seguintes tarefas:
• Carga, indexação e sumarização.
É possível carregar arquivos isolados, criar ou reconstruir índices em paralelo.
Finalmente, a sumarização (i.e. COUNT, SUM sem cláusula GROUP BY) pode
explorar o paralelismo.
• Criação de partições, organização e compactação.
É possível gerar tabelas isoladas, chamadas de partições, e criar uma visão (visão
particionada) que represente a união de todas estas tabelas. Cada partição pode ser
varrida em paralelo (os operadores UNION e UNION ALL são paralelizáveis). A
organização e compactação de dados também pode ser feita em paralelo, oferecendo
uma maneira rápida de reorganizar os dados.
• Full table scans, junções, agrupamentos e ordenações.
Full table scans acontecem quando é necessário ler todos os blocos de uma tabela
para processar uma consulta. Algumas vezes é melhor efetuar uma operação como
esta que efetuar uma varredura de índice, principalmente quando a maior parte de
uma tabela é necessariamente processada pela consulta. Junções são métodos para
processar duas ou mais tabelas, descobrindo o valor correspondente em cada uma
delas. Elas podem ser processadas em paralelo utilizando, por exemplo, métodos

15
 como nested loops e hash joins. No método nested loop todas as tuplas de uma
tabela são lidas e o SGBD tenta encontrar o valor correspondente em uma outra
tabela utilizando uma varredura de índice. Agrupamentos (são implementados
utilizando uma operação de ordenação) e ordenações, incluindo o uso do operador
DISTINCT, também podem ser resolvidos em paralelo.
• Amostragem, construção de histogramas e coleta de estatísticas.
Estes são métodos para coletar estatísticas que serão utilizadas pelo otimizador para
encontrar o melhor plano de execução para uma consulta. Como para tabelas com
um grande volume de dados a tarefa de gerar estatísticas de maneira exata consome
bastante tempo, o servidor Oracle oferece a possibilidade de amostragem de dados,
analisando apenas uma parte das informações. Histogramas são estruturas
particularmente úteis para mapear a distribuição dos valores de atributos, visando
oferecer ao otimizador melhor embasamento para decidir entre usar ou não índices.
• Inclusão, atualização e exclusão.
Estas operações pode ser paralelizadas se elas envolvem qualquer comando
SELECT que pode ser resolvido em paralelo. Por exemplo, podemos inserir
diretamente em uma tabela o resultado de uma consulta.
• CREATE TABLE AS SELECT em paralelo.
Esta construção faz com que seja possível criar tabelas de agregação em paralelo.
Isto é particularmente útil em grandes ambientes de data warehousing. Através da
especificação de operação “unrecoverable”, a sobrecarga imposta pelo
gerenciamento de integridade de uma transação durante um comando CREATE
TABLE AS SELECT pode ser removido.
• Fast full index scan.
Um fast full index scan é efetuado quando todas as colunas usadas em uma consulta
estão presentes em um índice, de tal forma que apenas o índice é utilizado, sem a
necessidade de procurar por dados da tabela. Esta operação funciona da mesma
forma que um full table scan, com a diferença que esta operação lida com menos
dados, uma vez que um índice representa uma estrutura mais compacta (somente
algumas colunas estão incluídas).

16
3.4.2. Consultas Paralelas e a Regra 9/13
O Oracle Parallel Server utiliza uma regra chamada 9/13 ao paralelizar
consultas. Em um primeiro passo, o Oracle cria um processo coordenador (PC), o qual é
responsável pela criação de processos escravos (PE) e distribuição dinâmica do trabalho
entre eles, balanceando a carga e retornando o resultado para o cliente.

tamanho partição =
número de blo cos da tabela
(1)
número de processos escravos

O tamanho da partição, indicado pela equação (1), representa o número de

blocos que devem ser processados por cada um dos processos escravos. Na fase
seguinte, o PC subdivide cada partição em três outras partes, onde o número de blocos
em cada uma delas pode ser alcançado através das seguintes frações: 9/13, 3/13 e 1/13
do número obtido em (1).

Fragmentos de
Planos de Execução PE001

PE002 Processos
Processo
Coordenador PE003 Escravos

PE004

Figura 2: Divisão de tarefas entre processo coordenador e escravos.

O PC atribui a cada escravo uma partição 9/13 para que o mesmo trabalhe.
Assim que cada escravo termina sua tarefa, o PC atribui as partições 3/13 utilizando um
critério first-come, first-serve. O primeiro escravo a terminar de processar sua partição
9/13 recebe uma partição 3/13 para trabalhar até que todas as partições 3/13 tenham sido
exploradas. Quando isto acontece, o PC passa a distribuir as partições 1/13 também da
mesma forma. Esta técnica procura minimizar os efeitos de um distribuição desigual dos

17
dados através das áreas de disco, sendo o processo coordenador da consulta responsável
pela balanceamento dinâmico da carga entre todos os processos escravos. Para maiores
informações, uma descrição mais detalhada sobre o Oracle Parallel Server pode ser
encontrada em [24, 32, 41].

3.4.3. Grau de Paralelismo

O grau de paralelismo define o número de processos escravos que podem ser
usados em paralelo para processar uma consulta. Entretanto, para operações com vários
estágios, este número pode ser até duas vezes maior que o grau de paralelismo definido.
Por exemplo, se uma consulta inclui uma cláusula de ordenação (ORDER BY) e uma de
agrupamento (GROUP BY), três conjuntos de processos paralelos são necessários, mas,
como o Oracle reutiliza o primeiro conjunto de processos escravos, o número de
processos alocados nunca é maior que duas vezes o grau de paralelismo.

Processo Processo Processo

Paralelo #1 Paralelo #3 Paralelo #1
Tabela Coordenador
T1 da Consulta
Processo Processo Processo
Paralelo #2 Paralelo #4 Paralelo #2

Full table scan

Ordenação Ordenação
(GROUP BY) (ORDER BY)

Figura 3: Grau de Paralelismo. Grupos de processos paralelos criados e utilizados durante o

processamento paralelo de consultas a partir do grau de paralelismo definido.

No exemplo da Figura 3, o primeiro conjunto de processos (#1 and #2) é

reutilizado na operação de ordenação causada pela operação ORDER BY, porque estes
já terminaram suas tarefas.
O grau de paralelismo é um atributo da tabela, que é definido quando o objeto é
criado ou configurado mais tarde através de um comando SQL. O grau de paralelismo
adequado leva em consideração fatores como o tamanho da tabela, número de

18
processadores disponíveis e quantidade de discos utilizados para armazenar os dados
correspondentes.

3.4.4. Oracle Parallel Server e a Arquitetura MPP

O Oracle Parallel Server (Figura 4) em sistemas IBM RS/6000 SP2, um
sistema de memória distribuída baseado na arquitetura MPP (Massively Parallel
Processing), utiliza o envio de funções quando os dados acessados estão localizados em
um nó remoto, oferecendo execução paralela eficiente uma vez que transferências de
dados entre nós são evitadas. Um processo coordenador subdivide o trabalho de varrer
as tabelas e índices em diversas partições lógicas. O particionamento inicial leva em
consideração a localização física dos dados e tenta minimizar a contenção de disco. Esta
fase é equivalente a uma fase shared-everything. No próximo passo, o coordenador usa
envio de funções para atribuir uma partição local a cada processo escravo,
representando a fase shared-nothing. Nós que terminarem seu processamento mais cedo
podem “roubar” uma partição remota através de uma camada que simula discos
compartilhados (VSD – Virtual Shared Disk da IBM), minimizando o
desbalanceamento de carga. Esta última fase é equivalente a uma abordagem de discos
compartilhados [24].

HPS – high-performance switch

Gerenciador de Bloqueio Distribuído

(DLM)

n1 n2 n3 n4

Discos Virtualmente Compartilhados

(VSD)

Figura 4: Esquema característico do Oracle Parallel Server em arquiteturas MPP.

19
 CAPÍTULO 4 - Mineração de Dados Utilizando Árvores
de Decisão

Apresentamos neste capítulo algumas técnicas de mineração de dados escolhidas

para nossos experimentos. A escolha da utilização de um algoritmo baseado em árvores
de decisão levou em conta os métodos mais bem sucedidos e mais adequados ao uso de
SGBDs, além do desempenho a ser alcançado, tanto ao nível da precisão do modelo
gerado quanto à velocidade do processo como um todo.
Métodos de árvore de decisão são métodos de aprendizado de máquina que usam
uma abordagem “dividir para conquistar” para classificar os dados de treinamento,
utilizando uma representação baseada em árvores [31]. Classificadores de árvores de
decisão são apropriados para problemas de mineração de dados, produzindo precisão
similar quando comparados a outros métodos de classificação. Além disso, eles
representam um dos métodos mais utilizados e práticos para inferência indutiva [37],
sendo construídos mais rapidamente que outras técnicas de aprendizado de máquina
[9, 15]. Uma outra vantagem que nos levou a implementar este tipo de algoritmo é que
árvores de decisão podem ser facilmente construídas a partir de comandos SQL [3], os
quais podem ser usados para manipular a base de dados, em particular através de um
SGBD paralelo.
Existem várias implementações usando algoritmos de aprendizado através de
árvores de decisão, tais como CART [12], ID3 e seu sucessor C4.5 [42], além do
SPRINT (implementação paralela do SLIQ) [44, 34]. Nosso trabalho é baseado no
SPRINT [44] para o crescimento da árvore e no C4.5 [42] para as demais fases, sendo
necessárias diversas adaptações para a integração do algoritmo com a tecnologia de
bancos de dados. Além disso, diversas considerações importantes sobre o
processamento de consultas em SGBDs apresentadas em [20, 21] serviram como ponto
de partida para a implementação deste algoritmo.

20
4.1. Crescimento da Árvore
O algoritmo constrói a árvore a partir dos dados de treinamento, recursivamente
subdividindo o conjunto de dados até que cada partição consista de nós “puros”, isto é,
cada nó folha represente apenas uma única classe, ou algum outro critério de parada seja
satisfeito, por exemplo um número mínimo de itens definido pelo usuário é alcançado.
O algoritmo de árvore de decisão gera um modelo de classificação na forma de
uma árvore, uma estrutura como a da Figura 5, constituída por:
a) um nó folha ⇒ indica uma classificação.
b) um nó interno (de decisão) ⇒ especifica algum teste a ser efetuado em um único
atributo, com duas ou mais sub-árvores representando cada possível saída do teste.

wage_increase

<= 2.5 > 2.5

working_hours statutory_holidays

<= 36 > 36 <= 10 > 10

contrib_health_plan wage_increase
G G

none full <= 4 >4

half G - good
B - bad
B G B B G

Figura 5: Árvore de decisão para o modelo de negociação trabalhista.

O tipo de teste depende da característica do atributo que é representado pelo nó

de decisão. Existem dois tipos de atributos que podem ser manuseados:
• Atributos Contínuos. Quando usado como ponto de quebra, um atributo contínuo
gera duas sub-árvores com comparações do tipo <= (menor ou igual) e > (maior).
Devemos analisar cada um dos n – 1 pontos de quebra, onde n representa o número
de valores distintos. Este cálculo pode representar uma tarefa de grande consumo de
tempo quando existirem muitos valores distintos para um atributo.
Consequentemente, uma discretização é uma abordagem aconselhável [22, 29]. A
figura 6 apresenta uma sub-árvore tipicamente gerada por uma quebra utilizando
atributos contínuos.

21
 idade

<= 20 > 20

Figura 6: Sub-árvore característica de atributos contínuos.

• Atributos Discretos. Existem várias abordagens que lidam com este tipo de atributo.
Podemos criar uma sub-árvore para cada valor distinto, duas sub-árvores e
segmentar os valores em dois grupos, criar quantas sub-árvores forem necessárias
ou, se os valores puderem ser ordenados, tratar um atributo discreto como um
contínuo. Quando existirem muitos valores distintos, um algoritmo guloso é
normalmente aplicado para dividir os valores em grupos.

car type car type

not in
in {economic,
{economic,
medium}
medium} economic compact medium large

car type
car type

in
in {economic, in {medium} <= medium > medium
large} {compact}

Figura 7: Possibilidades de tratamento de atributos discretos.

Uma diferença entre nossa implementação e a proposta em [34, 44] é o

tratamento de atributos contínuos. Para encontrar o melhor ponto de quebra, é
necessário que avaliemos todas as n – 1 possibilidades, onde n representa o número de
valores distintos. A implementação do SLIQ [34] propõe que uma ordenação preliminar
seja feita sobre os dados, de tal modo que esta ordenação não seja necessária em fases
posteriores. Esta abordagem não é apropriada a como sistemas bancos de dados
paralelos em geral, especialmente o Oracle, processam as informações. Mesmo quando

22
os dados estão fisicamente armazenados de maneira ordenada, não existe a garantia que
os mesmos serão lidos em sua ordem física. Consequentemente, uma ordenação
adicional é realizada antes de cada fase, tirando proveito dos recursos de máquinas
paralelas. Este fato certamente degrada o desempenho do algoritmo, mas garante que a
informação será processada corretamente.

Construir_Arvore_Decisao (DadosTreinamentoT)
INICIO
Subdividir (T);
FIM;

Subdividir (Dados S)
INICIO
SE todos os elementos em S pertencem à mesma classe ENTAO
FIM;
SENAO
PARA CADA atributo A FAÇA
Avaliar quebra no atributo A;
FIM-PARA
Usar melhor quebra encontrada para subdividir S em S1, ..., Sn;
Subdividir (S1);
...
Subdividir (Sn);
FIM-SE
FIM;

4.2. Ponto de Quebra

Um classificador de árvore de decisão iterativamente subdivide o conjunto de

treinamento até que cada partição represente casos total ou dominantemente
pertencentes à mesma classe. Para dividir os dados de treinamento, um teste estatístico é

23
usado como critério de quebra. O teste que implementamos é chamado de índice gini.
Para um conjunto de dados T contendo exemplos de n classes, gini(T) é definido como

gini (T )= 1 − ∑ p j
2
(2 )
onde pj é a freqüência relativa da classe j em T.
Quando uma quebra divide T em dois subconjuntos, T1 and T2, com n1 e n2
exemplos respectivamente, o novo índice dos dados divididos ginisplit(T) é dado por:

n1 n
ginisplit (T ) = gini(T1 )+ 2 gini(T2 ) (3).
n n

A vantagem desta medida é que ela requer somente a distribuição de classes em

cada partição, envolvendo um cálculo relativamente simples. O índice gini é calculado
para cada atributo, sendo usado como quebra do nó corrente o atributo com menor
índice. Este teste estatístico é também implementado em outros classificadores, tais
como o SPRINT [44]. O CART[12] usa uma variação deste teste, chamada de
Reduction of Gini Diversity Index.
O cálculo do índice gini varia para atributos discretos e contínuos. No caso de
atributos contínuos desejamos dividir a partição considerada em dois conjuntos através
dos operadores <= e > (ex.: idade <= 20 e idade > 20). Desta forma, precisamos analisar
apenas cada um dos n – 1 pontos de quebra, onde n representa o número de valores
distintos. Para realizar este cálculo e armazenar resultados intermediários, precisamos
de histogramas, estruturas que nos possibilitam manter a distribuição de classes
necessária.
As linhas da relação são lidas uma por vez para recalcular o valor dos
histogramas Cabaixo and Cacima. Cada vez que encontramos uma mudança de valor em um
atributo, o índice gini é calculado. Ao final do processo, é possível escolher o valor de
um atributo que resulta no melhor índice gini. Este processo é repetido para cada
atributo, sendo escolhido o com melhor ponto de quebra.

24
 SELECT idade, classe, COUNT(*) 0 1 0 1
FROM relacao_mineracao
GROUP BY idade, classe 0 0 9 8

Cabaixo Cacima
idade classe cont.
0 1 0 1
18 0 5
5 2 4 6
18 1 2
20 1 4
21 0 1 0 1 0 1
24 0 3
24 1 2 5 6 4 2

0 1 0 1
6 6 3 2

Figura 8: Construção de histogramas utilizados na fase de crescimento da árvore.

Como representado na Figura 8, a primeira coluna representa o atributo sendo

analisado. A segunda é a classificação correspondente do caso. Finalmente, a terceira
coluna representa quantas tuplas existem para aquele valor de atributo e classe. Esta
última informação pode ser utilizada para atributos discretos e contínuos. Se os atributos
contínuos possuem apenas alguns atributos distintos quando comparados com o total de
exemplos sendo pesquisados, o desempenho será melhor, uma vez que o índice gini será
calculado menos vezes. De outra forma, uma discretização (não necessariamente uma
agressiva) é aconselhável.
Para cada partição, apenas estes dois histogramas serão necessários. O melhor
ponto de quebra e o histograma correspondente podem ser utilizados como parâmetros
para a próxima fase.

4.3. Poda (Pruning)

O método de divisão imposto aos exemplos de treinamento resulta,
freqüentemente, em uma árvore muito complexa, que está superajustada aos dados
inferindo mais estrutura do que é representado pelos mesmos [42]. A idéia principal da
poda é remover partes da árvore que não contribuam para a precisão da classificação,

25
produzindo estruturas menos complexas e, consequentemente, de mais fácil
entendimento.
Existem três abordagens que podem ser utilizadas:
• Pré-poda (pre-pruning)
Ao mesmo tempo em que o algoritmo está construindo a árvore, ele testa se um
critério de parada é satisfeito. A abordagem de pré-poda é mais rápida mas menos
confiável [12].
• Pós-poda (post-pruning ou crescimento e poda)
Na primeira fase, crescemos a árvore até que cada folha represente casos
pertencentes à mesma classe. Esta abordagem é mais lenta, mas mais confiável.

• Pré-poda e pós-poda
Esta estratégia combina as duas abordagens, na maioria das vezes implementando
um critério de pré-poda não agressivo, mas agressivo o suficiente para diminuir o
tempo de UCP necessário para processar os dados de treinamento.

Um problema na fase de poda é como prever taxas de erro, que guiarão o

processo. A taxa de erro obtida simplesmente usando o conjunto de treinamento
utilizado para construir a árvore não oferece uma estimativa razoável. De acordo com
Quinlan [42], existem duas famílias de técnicas para predição de taxas de erro. A
primeira prevê a taxa usando um conjunto separado de dados (às vezes chamado de
dados de poda), distinto do conjunto de treinamento. Uma vez que estes dados não
foram examinados no momento em que a árvore foi construída, as estimativas obtidas a
partir dos mesmos não são tendenciosas e, se existirem casos suficientes, são confiáveis.
Exemplos de tais técnicas são a poda baseada em complexidade de custos [12] e
reduced-error pruning [43].
As desvantagens associadas a estas técnicas estão relacionadas à necessidade de
possuir à disposição um grande volume de dados, de tal forma que possamos separar um
porção para construir a árvore e uma outra significativa para podá-la. Quando os dados
são escassos, uma técnica chamada validação cruzada (cross-validation) pode ser
utilizada. Neste caso, os dados de treinamento são divididos em n blocos de igual
tamanho, preferencialmente com a mesma distribuição de classes. A árvore é construída

26
utilizando casos em todos os outros blocos e testada com o bloco reservado. Esta técnica
oferece a desvantagem de necessitar que n árvore sejam construídas, o que obviamente é
uma tarefa que consome um tempo considerável, principalmente quando um grande
volume de dados é utilizado.
A outra família para predição de taxas de erro usa apenas os dados de
treinamento a partir do qual a árvore foi construída. Um exemplo de tais técnicas é a
pessimistic error rate [42].
Como estamos interessados principalmente em mineração de dados em grandes
volumes de dados, podemos assumir que possuímos dados em abundância. Desta forma,
decidimos usar a primeira família de técnicas, aleatoriamente dividindo os dados em
duas partes, de tal maneira que ambas possuam a mesma distribuição de classes.
A estratégia implementada para podar a árvore de decisão é a mais simples que
poderia ser utilizada. Começamos de baixo na árvore, examinando cada sub-árvore dos
nós de decisão. Nós consideramos a substituição desta sub-árvore por uma folha
representando o escopo corrente ou pelo ramo mais utilizado. A alternativa que
conduzir a uma previsão de taxa de erro menor guiará a poda da árvore [42]. Este
processo é apresentado na Figura 9.

taxa de erro= 0.25 taxa de erro = 0.13

0 1 0 1

80 exemplos
200 exemplos 338 exemplos

35 exemplos
23 exemplos

Figura 9: Fase de poda. A raiz da sub-árvore mostrada acima está sendo substituída por um nó
folha representando a classe mais freqüente no escopo correspondente.

27
 Visando alcançar o paralelismo, construímos uma função em PL/SQL que é
capaz de classificar casos de poda baseados na árvore de decisão criada durante a
primeira fase (crescimento da árvore). A função recebe os valores dos atributos usados
no processo de mineração de dados, lê o conjunto de poda completo e calcula o
resultado em paralelo.
SELECT classe, Classify(idade, tipo_carro, tipo_seguro)
FROM relacao_mineracao_poda
[WHERE ...]

A função Classify retornará a classe prevista. Uma vez possuindo as classes real
e prevista, podemos calcular a taxa de erro relacionada ao conjunto de treinamento.

4.4. Extração de Regras

Mesmo depois de podar a árvore, ela pode ainda representar uma estrutura
complexa e indecifrável em um primeiro momento. Árvores de decisão grandes são
difíceis de entender porque cada nó possui um contexto específico estabelecido pelas
saídas dos testes em nós antecedentes [42]. A extração de regras tende a solucionar este
problema, originando uma estrutura mais simples e mais compacta, isto porque
expressões irrelevantes são eliminadas da árvore originalmente gerada.

4.4.1. Generalização das Regras

Para cada regra original, iterativamente removemos a condição mais irrelevante,
se houver; isto é, nós removemos a expressão que mais contribui para melhorar a
precisão no modelo de classificação. Este método minimiza a limitação existente do
algoritmo de árvore de decisão, que trata um atributo por vez. Ao remover um nó,
métodos convencionais baseados na representação de árvores removeriam todas as
sub-árvores abaixo deste, o que nem sempre representa a melhor abordagem.
Seja uma regra R da forma:

IF A THEN Classe C,

onde A = X1 AND X2 AND... AND Xn, e Xi (i = 1..n) representa uma das n

condições da expressão A, e uma outra regra R-:

IF A- THEN C,

28
 onde a expressão A- é obtida removendo uma condição Xi de A.
A importância de cada condição Xi pode ser calculada usando-se as tuplas dos
conjuntos de treinamento e poda. Cada caso que satisfaz o antecedente A- pertence ou
não à classe C e satisfaz ou não a condição Xi. O número de casos em cada um destes
quatro grupos podem ser organizados em uma tabela 2 x 2:

Pertence Não pertence

à classe C à classe C
Satisfaz Xi S_C S_nC
Não satisfaz Xi nS_C nS_nC

Tabela 1. Matriz representando as informações relevantes para a fase de extração de regras.

A regra R cobre S_C + S_nC casos, sendo S_nC deles correspondentes a uma
classificação errônea. Analogamente, a regra R- cobre S_C + S_nC + nS_C + nS_nC,
sendo S_nC + nS_nC correspondentes a classificações errôneas. Para calcular a tabela
acima, poderíamos utilizar um comando SQL com a seguinte estrutura:

SELECT atributoi, classe, COUNT(*)

FROM relacao_mineracao
WHERE A-
GROUP BY atributoi, classe

onde atributoi representa o atributo utilizado na condição Xi.

Como relatado em [20], esta consulta retorna muitas linhas. Uma vez que
estamos interessados somente em quatro partições do tipo GROUP BY, é desejável que
esta consulta seja simplificada. Em todas as consultas de uma dada iteração do
procedimento de remoção de uma condição, as partições S_C e S_nC possuem valores
que são constantes. Desta forma, podemos computá-los uma única vez durante o
processo, reutilizando estes valores para as próximas iterações. Consequentemente,
podemos utilizar uma consulta da seguinte forma para calcular nS_C e nS_nC:

SELECT classe, COUNT(*)

FROM relacao_mineracao
WHERE A- and not (Xi)
GROUP BY classe,

29
 Utilizando uma construção existente no servidor Oracle, podemos traduzir esta
consulta de tal forma que a mesma retorne apenas uma única linha. É importante
ressaltar que este tipo de consulta é facilmente processada por um SGBDP.
O cálculo da taxa de erro das regras R e R- para avaliar se uma condição Xi deve
ou não ser excluída pode ser obtido utilizando-se valores reais dos conjuntos de
treinamento e poda, uma vez que assumimos que estamos lidando com um grande
volume de dados. Uma opção que permite utilizarmos um outro método de estimativa
de precisão também foi implementada, baseada no método proposto por Quinlan e
utilizado do software C4.5 [42]. Este método é chamado de taxa de erro pessimista
(pessimistic error rate), que estima o erro verdadeiro associado a um nó folha como
sendo o limite superior para a distribuição binomial para algum nível de confiança CF
(ex. 25%). Este limite superior é escrito como UCF(E,N), onde N representa o número de
casos cobertos pelo nó folha e E o número de casos erradamente cobertos. Se a taxa de
erro pessimista for maior que a da regra original, então não faz sentido excluir a
condição.
Ao invés de utilizar uma busca exaustiva para encontrar o subconjunto das
condições dentre todos os existentes que deve ser excluído, uma abordagem baseada em
um algoritmo guloso é utilizada. Cada iteração deste procedimento é repetida até que
não haja melhora na precisão do classificador.

4.4.2. Conjuntos de Regras

Após a fase de generalização das regras, podem existir algumas destas com uma
taxa de erro inaceitavelmente alta, as quais podem ser eliminadas, ou até mesmo regras
duplicadas. Desta forma, o conjunto de regras será menor, não mais apresentando a
característica das regras serem mutuamente exclusivas. Para solucionar o problema de
existirem casos em que nenhuma regra cobre uma tupla a ser classificada, uma classe
padrão deve ser encontrada, através da verificação de qual é a classe mais freqüente
entre os casos que não são cobertos por regra alguma.
O método utilizado para encontrar conjuntos de regras é novamente baseado no
software C4.5 [42]. Primeiramente, separamos as regras, dividindo-as em grupos, uma
para cada classe existente. A ordem em que definiremos as regras dentro de um grupo
não é importante, pois todas elas representam a mesma classificação.

30
 Suponha que, a partir do conjunto de regras obtido após a fase de generalização,
tenhamos que escolher um subconjunto das regras S para cobrir uma classe C em
particular. A importância deste subconjunto pode ser percebida pelo número de casos
cobertos por S que não pertencem à classe C (falsos positivos) e o número de casos da
classe C que não sejam contemplados por qualquer regra em S (falsos negativos). A
importância do subconjunto S de regras é avaliada utilizando o princípio MDL
(Minimum Description Length) [42]. Este princípio oferece a base para eliminar regras
muito complexas sem diminuir a precisão do modelo de classificação.
Existem diversas maneiras de encontrarmos o melhor subconjunto S. Podemos,
por exemplo, checar todos os possíveis subconjuntos e escolher o melhor deles,
abordagem que pode consumir um tempo considerável. Este processo leva à produção
de um modelo de classificação tão preciso quanto uma árvore podada, com a vantagem
de oferecer um entendimento mais fácil das regras descobertas.

4.4.3. Ordenação de Regras e Classe Padrão

Os subconjuntos de regras geradas associados a cada uma das classes existentes

são examinados e a classe que possuir o subconjunto com menor número de casos falsos
positivos é utilizada em primeiro lugar. Após esta escolha, os casos falsos positivos são
recalculados para selecionar a próxima classe utilizando os casos restantes, e assim por
diante.
Este cálculo de falsos positivos pode ser transformado em comandos SQL, que
podem ser executados em paralelo, dependendo da característica da consulta e do
número de exemplos contemplados por esta.

31
 CAPÍTULO 5 - Implementação de um Algoritmo de
Mineração de Dados em um SGBD Paralelo

Visando validar a abordagem proposta, construímos um conjunto de

procedimento armazenados (agrupados em pacotes), os quais são armazenados no
dicionário de dados do servidor Oracle. Usamos um sistema multiprocessado da IBM
com quatro nós (IBM RS/6000 SP2) [1] com o Oracle Parallel Server 7.3 instalado
[41].

5.1. Integração Fracamente Acoplada

A maioria das aplicações de mineração que utilizam SGBDs o fazem de uma

forma fracamente acoplada. O banco de dados é tratado simplesmente como um meio de
armazenamento a partir do qual os dados são extraídos diretamente para a memória
principal do computador responsável pela execução do algoritmo (Figura 10), logo antes
da execução principal ter início. Esta abordagem limita a quantidade de dados que
podem ser utilizados, forçando que as aplicações tenham que filtrar as informações,
utilizando apenas uma parte para descobrir os padrões. Por outro lado, algumas
aplicações efetuam consultas dinâmicas ao banco de dados, mas trabalham em uma
arquitetura cliente / servidor. Isto significa que, dependendo da quantidade de dados a
serem transferidos, um tráfego de rede desnecessário é gerado. Além disso, elas
freqüentemente estão codificadas em linguagens de programação que não possuem
qualquer integração com o sistema de banco de dados.

Cliente Servidor
FILTRO

Dados

Figura 10: Abordagem tradicional utilizada para aplicações de mineração de dados.

Ocasionalmente, o cliente e o servidor poderiam estar representados pela mesma máquina.

32
5.2. Integração Fortemente Acoplada
A idéia de executar computação definida pelo usuário dentro de SGBDs,
evitando tráfego de rede desnecessário, tem sido uma grande preocupação em vários
SGBDs. Um exemplo deste tipo de implementação são os procedimentos armazenados
em bancos de dados comerciais. Por exemplo, o servidor Oracle oferece a possibilidade
de implementar código procedural em PL/SQL e armazená-lo dentro do próprio
dicionário de dados, em uma forma pré-compilada. (o PL/SQL é uma linguagem
interpretada).

MakeDecisionTree

PruneTree

errorRate errorRate
ExtractRules
Classify Classify
giniSplit giniSplit

F2 F2 F2 F2 F2 F2 F2 F2

Figura 11: Integração com o SGBD. Abordagem simplificada mostrando as chamadas do cliente
e as funções em PL/SQL que são executadas pelo servidor a partir de comandos.

Alguns autores desenvolveram uma metodologia para uma integração fortemente

acoplada de aplicações de mineração de dados e bancos de dados. [7], seletivamente
colocando partes da aplicação no SGBD. Eles efetuaram alguns experimentos práticos
com um sistema de banco de dados relacional e propuseram que, sempre quando
possível, a computação deve ser incluída dentro de comandos SQL. Nós
experimentamos uma variação destas metodologias, tirando proveito de características
de paralelismo disponíveis em diversos sistemas de banco de dados paralelos, em
particular as oferecidas pelo Oracle Parallel Server. A Figura 11 mostra um esquema
simplificado de como a integração com um SGBD pode ser alcançada.

33
 É importante ressaltar que devemos minimizar o número de chamadas ao
servidor de banco de dados. Idealmente, deveríamos ser capazes de efetuar um comando
em SQL da seguinte forma:

SELECT EXTRACTRULES (profundidade, latitude, longitude)

FROM relacao_mineracao,

onde relacao_mineracao representa os dados e a função EXTRACTRULES

retornaria a lista de regras descobertas analisando os atributos passados como
parâmetros (profundidade, latitude e longitude). Devido à natureza do SQL oferecido
pelos SGBDs correntes, não é possível efetuar tal tarefa. A maneira que usamos para
implementar esta funcionalidade foi a codificação de uma série de procedimentos e
funções, os quais foram logicamente agrupados em um objeto denominado package.
Consequentemente, o usuário faz a chamada de um único procedimento
(MakeDecisionTree), iterativamente informando todos os parâmetros disponíveis.
Idealmente, o algoritmo implementado para manusear um grande volume de
dados deveria ser executado onde os dados residem, visando evitar tráfego de rede.
Também é desejável que o algoritmo construído tenha uma forte integração com os
dados para evitar, por exemplo, conversão de tipos, o que pode degradar o desempenho.
Ao trabalhar com alguns dos mais conhecidos servidores de banco de dados, é
possível armazenar código no dicionário de dados, em uma forma pré-compilada. O
PL/SQL é a extensão ao SQL da Oracle que adiciona construções procedurais, variáveis
e outras funcionalidades ao SQL. Um bloco em PL/SQL é enviado para o servidor e
executado como uma unidade, reduzindo a carga da rede. O PL/SQL é projetado para
ter uma íntima integração com o sistema de banco de dados Oracle e com o SQL.
Consequentemente, ele suporta todos os tipos de dados internos nativos ao SGBD
Oracle.

A maioria dos algoritmos paralelos de mineração de dados desenvolvidos

utilizam funções MPI (ou bibliotecas similares) para implementar o paralelismo. Eles
dividem o processamento entre os nós do sistema, tornando o paralelismo totalmente
dependente da aplicação construída. Em PL/SQL isto não é possível. O paralelismo
deve ser alcançado através de consultas e não através da linguagem de programação,
tornando o paralelismo dependente do servidor de banco de dados. A única forma de

34
paralelizar um código escrito em PL/SQL é construindo uma função armazenada, a qual
pode ser chamada a partir de um comando em SQL.

5.3. Consultas Típicas de um Algoritmo de Indução de Regra

Uma característica do SQL que pode degradar o desempenho de um algoritmo

de indução de regra, em particular um baseado em árvores de decisão, é que a sua
estrutura necessita de uma consulta separada para construir o histograma para cada
atributo. Desta forma, não é possível efetuar um comando em SQL que nos traga o
resultado lendo os dados apenas uma única vez.

A maioria das consultas efetuadas durante a fase de crescimento da árvore de

decisão lida com dois tipos de operação: ordenações (ORDER BY) e agrupamentos
(GROUP BY) [20, 21, 23]. Estes tipos de consulta representam as tarefas que
consomem mais tempo durante o algoritmo implementado.

SELECT salario, classe, COUNT(*)

FROM relacao_mineracao
GROUP BY salario, classe
ORDER BY salario

Poderíamos utilizar diversas tabelas normalizadas e efetuar junções para

processá-las, mas esta operação é bastante dispendiosa, até mesmo quando processada
em paralelo. Como uma solução alternativa, poderíamos criar uma visão que conteria o
comando em SQL correspondente à operação de junção, utilizando-a como base para o
processo, mas isto não resolveria os problemas de desempenho, representando uma
solução apenas para deixar a implementação mais flexível.

Servidores de banco de dados paralelos podem facilmente processar a consulta

acima, tirando bom proveito dos recursos de máquinas paralelas. Em arquiteturas MPP,
por exemplo, cada nó pode independentemente contar o número de registros
armazenados localmente. Em uma próxima fase, um processo coordenador pode
consolidar estas contagens e retornar o resultado para o usuário [35].

Uma abordagem típica utilizada que permite que consultas dos usuários lidem
com relações menores, causando um menor número de acessos a páginas, é a
fragmentação vertical. No caso de árvores de decisão, seria necessário criar uma relação

35
para cada par atributo/classe (lembre-se que árvores de decisão trabalham com listas de
atributos, em cada fase tentando encontrar o melhor ponto de quebra entre todos os
atributos), assim como é feito com arquivos isolados no SPRINT [44].

Nossos testes mostraram que a fragmentação vertical é útil principalmente

durante o primeiro passo do algoritmo, quando nenhum ponto de quebra foi ainda
definido; cada consulta é composta por um simples comando em SQL com uma
cláusula de GROUP BY, sem filtro algum. Em uma segunda fase, no máximo uma
junção entre duas tabelas é necessária; em uma terceira, no máximo junções de três
tabelas, e assim por diante. Junções em SGBDs constituem uma tarefa custosa, até
mesmo quando resolvidas em paralelo (o servidor Oracle pode efetuar junções em
paralelo usando diferentes métodos, tais como nested loops e hash joins). Visando
oferecer um melhor tempo de resposta para a primeira fase, sugerimos a construção de
índices concatenados (atributo, classe). Uma vez que a consulta mencionada necessita
apenas destas duas colunas, ela pode usar diretamente os índices, sem ao menos
referenciar a tabela original. No servidor Oracle, isto é chamado de fast full index scan,
que pode ser executado em paralelo.

5.4. Ponto de Quebra

Visando oferecer uma forte integração com o banco de dados, é aconselhável

que sejam construídas funções que possam ser chamadas a partir de comandos SQL.
Isto aumenta o número de chamadas ao banco de dados e torna o código
consideravelmente mais simples.

5.4.1. Atributos Contínuos

SELECT MIN(giniSplit(atributo, classe, num))

FROM (SELECT atributo, classe, count(*) num
FROM relacao_mineracao
GROUP BY atributo, classe)

No exemplo acima, apresentamos o comando SQL originalmente construído

para o cálculo do ponto de quebra de um atributo contínuo. O comando SQL interno
ordena o conjunto de treinamento baseado nos valores dos atributos. A cláusula
GROUP BY é utilizada ao invés de um simples ORDER BY para contar o número de

36
ocorrências para cada par atributo / classe, uma vez que não podemos separar casos
possuindo o mesmo valor para o atributo. Desta maneira, o critério de quebra é
computado mais rapidamente que antes. Quando o atributo possui muitos valores
distintos, uma discretização é aconselhável [22, 29], minimizando a parte seqüencial do
comando SQL, representado pela função giniSplit. O resultado final desta consulta é o
melhor ponto de quebra de um dado atributo. Este processo é repetido para todos os
outros atributos, de forma que o menor valor é escolhido.

Devido à forma em que o servidor Oracle processa um comando SQL com uma
cláusula GROUP BY, a implementação teve que ser modificada, pois chegaríamos a um
resultado incorreto se mantivéssemos a utilização do comando apresentado. Para
processar um GROUP BY em paralelo, cada processador fica responsável por um
subconjunto de valores distintos da consulta (atributo / classe). Dentro de cada
subconjunto, consequentemente em cada processador, é feito uma ordenação dos
valores visando o cálculo do número de ocorrências para cada combinação atributo /
classe. Quando todos os processadores terminam de processar seu subconjunto, uma
união de resultados é realizada. O problema é que o Oracle não garante que os dados
retornados por uma cláusula GROUP BY estejam em forma ordenada, apesar do mesmo
utilizar uma operação de ordenação para resolvê-lo, sendo para isto necessário uma
cláusula ORDER BY adicional. Se um ORDER BY não for realizado, o resultado final
estará dividido em n grupos ordenados de valores, onde n representa o número de
processadores / processos envolvidos na consulta, como representado no esquema da
Figura 12.

37
SELECT TKBEG attrib_value, CLASS_A class_value, count(*) num_classes
FROM MR_D GROUP BY TKBEG, CLASS_A

1945 2 6 1946 1 6
1948 1 3 1948 2 3
1952 2 3 1950 2 6
1954 2 11 Processador 1951 1 30 Processador
1955 1 51 #1 1953 1 42 #3
1956 0 3
1958 1 165
1959 2 77
1960 1 270

1943 1 3
1943 2 3
1944 2 3
1947 1 6 Processador
1945 1 9
1953 2 15 #2
1950 1 6 Processador
1954 1 60
1952 1 39 #4
1955 1 34
1957 1 159
1958 2 11
1959 1 228
1960 2 114

Figura 12: Processamento paralelo de consultas com agrupamentos. Resultado obtido por uma
consulta utilizando cláusula GROUP BY solucionada em paralelo.

O esquema apresenta um exemplo de uma consulta utilizando uma cláusula

GROUP BY, juntamente com o seu resultado. É importante perceber que as linhas
resultantes estão agrupadas de acordo com os processadores responsáveis por seu
processamento.
Como resultado desta característica do servidor Oracle, a chamada da função
giniSplit, responsável pelo cálculo do ponto de quebra, foi migrada para dentro do
código em PL/SQL, sendo retirada da consulta. É importante frisar que testes realizados
mostraram que não há uma perda significativa gerada por esta mudança na
implementação. Apesar da necessidade de manusear o resultado dentro do programa em
PL/SQL responsável pela execução do algoritmo propriamente dito, tempos de resposta

38
similares foram encontrados, o que reforça ainda mais a afirmação de que a linguagem
PL/SQL é fortemente ligada ao servidor de banco de dados.

5.4.2. Atributos Discretos

Três formas de tratamento para atributos discretos foram implementadas. A
primeira delas cria uma sub-árvore para cada valor distinto do atributo. Neste caso, a
limitação existente para os atributos contínuos não se aplica, pois não estamos
interessados em ordenar os dados. Uma consulta como a seguinte é utilizada para
realizar o cálculo do índice gini:

SELECT attrib_value, sum(num_classes) *

(1 - ( sum( power(num_classes, 2 ) ) / power( sum(num_classes), 2) )) giniGroup
FROM (SELECT ESTADO_CIVIL attrib_value, CLASS_A class_value,
COUNT(*) num_classes
FROM MR_D
GROUP BY ESTADO_CIVIL, CLASS_A)
GROUP BY attrib_value

O cálculo do índice está diretamente vinculado à consulta, que retornará

resultados intermediários pré-calculados para a aplicação. O código então, após ler as
linhas da consulta pode facilmente calcular o critério de quebra, ficando para o SQL o
processamento mais pesado. Repare que o número de linhas retornado é igual ao
número de valores distintos para um atributo discreto em uma dada sub-árvore, número
este que costuma ser razoavelmente pequeno.
Uma segunda forma de tratar um atributo discreto implementado é quebrando os
valores em dois grupos e, consequentemente, criando duas subárvores, como
exemplificado na seção correspondente à descrição do algoritmo. Nesta situação uma
consulta simples é necessária.

SELECT ESTADO_CIVIL attrib_value, CLASSE class_value,

COUNT(*) num_classes
FROM MR_D GROUP BY ESTADO_CIVIL, CLASSE

39
 Neste caso, um maior número de linhas é lido e armazenado em estruturas
internas do PL/SQL (equivalente a vetores). Um algoritmo guloso é aplicado para
descobrir a melhor divisão de valores, onde melhor mais uma vez significa possuir o
menor índice gini. A implementação deste módulo está baseado no software C4.5 [42].
Finalmente, é oferecida a possibilidade de tratar um atributo discreto exatamente
da mesma forma que um atributo contínuo, ou seja, podemos particionar os valores
utilizando uma construção do tipo <= e >. As mesmas observações referentes aos
atributos contínuos se aplicam neste caso.

5.5. Poda

A tarefa mais custosa associada à fase de poda é o cálculo da taxa de erro

associada a cada nó da árvore, uma vez que esta operação é fundamental para a
estimativa de qual a melhor alternativa para um determinado nó de decisão: manter suas
sub-árvores, transformar o nó em um nó folha, ou substituí-lo pela sub-árvore mais
freqüente. Este cálculo da taxa de erro é realizado através da computação de quantos
exemplos de poda foram classificados de maneira errônea pela árvore originalmente
gerada.

Durante a fase de poda, uma função definida pelo usuário baseada na árvore
original é utilizada para classificar casos de poda em paralelo. Esta função, que é
chamada a partir de um comando SQL, é utilizada para calcular o número de acertos e
erros durante a classificação.

SELECT class, Classify(estado_civil, ano_nascimento, salario, ...)

FROM relacao_mineracao_poda

Inicialmente, implementamos um módulo que gera automaticamente uma função

em PL/SQL (Classify), que pode ser chamada a partir de um comando SQL. Esta função
é criada lendo-se a árvore, de cima para baixo, e gerando comandos do tipo:

40
IF salario <= 3000 THEN
IF estado_civil = ‘S’ THEN
RETURN 0; -- (equivalente a uma regra IF salario <= 3000
-- AND estado_civil = ‘S’ THEN classe = 0);
ELSIF estado_civil = ‘C’ THEN
...
ELSIF estado_civil = ‘D’ THEN
...
END IF;
ELSE
IF Ano_fim_contrato <= 2000 THEN
...
ELSE
...
END IF;
END IF;

O Oracle7 possui uma limitação associada ao tamanho de um bloco em PL/SQL.

Desta forma, dependendo do número e tamanho das regras geradas pelo algoritmo, a
função Classify construída pode ser extremamente grande, ultrapassando os limites
permitidos, sendo possível utilizá-la somente para a geração de modelos de classificação
simples. Uma solução alternativa implementada foi a criação, sempre automaticamente,
de diversas funções a serem chamadas dentro da função original a partir de uma certa
profundidade da árvore, pois, desta forma, estaríamos diminuindo o tamanho do bloco
da função original (Classify). Entretanto, ainda assim encontraríamos problemas ao lidar
com um conjunto de regras relativamente grande.
Como a árvore gerada é armazenada na própria base de dados do Oracle, uma
maneira alternativa que encontramos para solucionar este problema, apesar da piora em
termos de desempenho, foi a tradução desta função em uma outra que utilize consultas
para descer na árvore, de acordo com os valores dos atributos dos casos de poda a serem
classificados. Desta forma, para cada caso de poda, são necessárias p consultas para
retornar a classificação, onde p representa a profundidade do nó folha correspondente à
classificação do caso.

Como o problema da poda está dividido em duas partes (substituição de um nó

interno por um nó folha ou pela subárvore mais freqüente), procuramos também dividir
a solução em duas. Para o primeiro caso, é interessante que um determinado exemplo de
poda seja classificado o menor número de vezes possível, visando aumentar o
desempenho do algoritmo. Desta forma, preliminarmente ao início da fase de poda

41
propriamente dita, criamos uma outra tabela que possui valores associados a cada um
dos nós folhas, através de um comando SQL da seguinte forma:

CREATE TABLE poda_data

AS SELECT Classify(...), classe, COUNT(*)
FROM relacao_mineracao_poda
GROUP BY Classify(...), classe

A função Classify foi alterada para que, ao invés de retornar a classificação

(informação já existente associada ao nó folha), retorne um número identificador do nó
folha correspondente, visando a criação de um relacionamento entre tabelas.

0 1 0 2

0 1323 0 823 0 1323 0 347

1 42 1 22 1 12
2 21 2 18 2 43

Classe Número de
Classificações

Figura 13: Fase de poda. Cada um dos nós folha da árvore pode possuir um conjunto de linhas
associadas a classificações relacionadas aos dados de poda.

Como representado na Figura 13, cada um dos nós folha da árvore possui um
conjunto de linhas associadas a classificações, de acordo com o resultado computado
utilizando os dados de poda. No caso da substituição de um nó interno por um nó folha,
estes dados são utilizados para descobrir a classe mais freqüente da sub-árvore em
questão, além de computar qual a taxa de erro associada a esta nova estrutura da árvore,
se esta fosse escolhida, sem a necessidade de consultar os dados de poda novamente. Ao
considerar a substituição do nó interno pela sua sub-árvore mais freqüente, estes dados
são utilizados para descobrir qual a sub-árvore mais utilizada. Para realizar a nova
classificação dos casos de poda associados às demais subárvores, a leitura dos dados de

42
poda é inevitável, consistindo na tarefa mais custosa do módulo de poda, principalmente
na medida em que analisamos possíveis alterações em nós localizados em níveis
superiores da árvore, os quais representam uma maior quantidade de dados de poda.

5.6. Extração de Regra

Uma vez que o modelo de classificação é construído, um conjunto de regras
pode ser derivado lendo a árvore, de cima para baixo, até alcançar cada nó folha. As n
regras originalmente definidas (onde n representa o número de nós folha) são
generalizadas, sendo algumas delas simplificadas ou até mesmo eliminadas. Como
resultado final, alcançaremos um conjunto ordenado de regras, tal como:

IF a > 1 AND b <= 5 AND c > 2 THEN

RETURN 1;
END IF;
IF a <= 1 AND d = ‘A’ THEN
RETURN 0;
END IF;
...
RETURN 1; -- classe padrão

Como relatado no Capítulo 4, o núcleo do processamento deste módulo pode ser

representado por uma consulta do tipo:

SELECT classe, COUNT(*)

FROM relacao_mineracao
WHERE A- and not (Xi)
GROUP BY classe,

Utilizando uma construção existente no servidor Oracle, podemos traduzir esta

consulta de tal forma que a mesma retorne apenas uma única linha. É importante
ressaltar que este tipo de consulta é facilmente processada por um SGBDP.

Assim como no caso da poda, este conjunto de regras é transformado em uma

função em PL/SQL, a qual pode ser chamada a partir de um comando SQL,
possibilitando a classificação de novos casos em paralelo. Esta função recebe os
atributos utilizados durante o algoritmo de mineração de dados e retorna a classificação
esperada. Da mesma forma que no caso da poda, uma função extremamente grande

43
pode ser gerada, sendo necessária a criação de uma função que dinamicamente leia a
base de dados para realizar a classificação.

5.7. Técnicas de Fragmentação

Uma característica do SQL que pode degradar o desempenho de um algoritmo

de indução de regra, em particular um baseado em árvores de decisão, é que sua
estrutura requer uma consulta separada para construir o histograma para cada atributo.
Consequentemente, não é possível efetuar um comando SQL que nos traga o resultado
lendo os dados apenas uma vez. Técnicas de fragmentação desempenham uma função
importante neste contexto, porque elas tendem a eliminar as informações durante a
execução da consulta.

5.7.1. Fragmentação Horizontal

A fragmentação horizontal divide uma relação a partir de suas tuplas, cada
fragmento possuindo um subconjunto de tuplas da relação. Diversos SGBDs comerciais
oferecem esta funcionalidade, sendo que a maioria deles oferecem-na de uma forma
transparente para a aplicação. Em um passo anterior, podemos criar diversas tabelas
similares, cada uma correspondendo a um fragmento horizontal, associando a elas
regras especiais.

Medicao_1 Medicao_2 Medicao_3

profundidade profundidade profundidade

latitude latitude latitude
longitude longitude longitude
temperatura temperatura temperatura

profundidade between 500m and 1500m

profundidade < 500m profundidade > 1500m

select * from Medicao_2

select * from Medicao_1 select * from Medicao_3

Medicao

Figura 14: Fragmentação horizontal. Vários fragmentos são criados baseados em funções de
fragmentação.

A Figura 14 apresenta um exemplo de fragmentação horizontal, onde

profundidade < 500, profundidade between 500 and 1500, e profundidade > 1500

44
representam funções de fragmentação. A relação original pode ser obtida utilizando um
comando SQL que une todos os fragmentos em um só resultado. Alguns SGBDs
paralelos, particularmente o servidor Oracle, são capazes de utilizar estas funções
(regras associadas a tabelas) para eliminar algumas partições ao ler os dados,
dependendo do filtro utilizado no comando SQL correspondente.

A alocação de fragmentos é um outro problema importante. Suponha que

definamos F fragmentos a serem distribuídos entre N nós. Se simplesmente alocarmos
F / N fragmentos a cada nó, um desbalanceamento de carga ocorrerá, uma vez que o
algoritmo de árvore de decisão trabalha com apenas alguns poucos fragmentos após um
certo ponto do processamento.

HPS

n1 n2 n3 n4

F1 F1 F2 F2 F3 F3 F4 F4

Figura 15: Desbalanceamento de carga. Após um certo ponto do algoritmo, as leituras estarão
concentradas em somente algumas partições. Desta forma, a maioria dos nós estarão efetuando
leituras remotas. F1, F2, F3 e F4 representam fragmentos distribuídos entre quatro nós (N1, N2,
N3 e N4). Discos com uma cor diferente dos demais indicam que estes estão sendo
correntemente acessados pela aplicação.

A fragmentação horizontal oferecerá a habilidade de descartar algumas

partições, de tal forma que o algoritmo leia menos dados, mas, idealmente, os dados
deveriam estar igualmente distribuídos entre todos os nós que participarão do processo.
[11].

45
 HPS

n1 n2 n3 n4

F1
F2

F3

Figura 16: Balanceamento de Carga. Ainda trabalhamos com partições entre os quatro nós, com
a diferença que os dados estão espalhados entre todos os discos disponíveis. Porções de discos
com cor diferente significam que parte dos dados estão sendo lidos pela aplicação de mineração.

O “fatiamento” dos dados explora o paralelismo de E/S e minimiza o

desbalanceamento, mas envolve um maior tempo e custo de inicialização e terminação,
porque um processo deve ser iniciado e terminado em cada nó onde a relação reside
[24]. Estas operações são feitas em paralelo, de modo que o tempo de resposta não
aumenta significativamente.

5.7.2. Fragmentação Vertical

Uma abordagem típica utilizada que permite que consultas do usuário lidem com
relações menores, causando um menor número de acessos a páginas, é a fragmentação
vertical [40]. No caso de árvores de decisão, seria necessário criar uma relação para
cada par atributo/classe (lembre-se que árvores de decisão trabalham com listas de
atributos, em cada fase tentando encontrar o melhor ponto de quebra dentre todos os
atributos), assim como é realizado com arquivos isolados no SPRINT [44].

id profundidade classe id temperatura classe

1 200 0 1 32 0
2 232 1 2 32 1
3 259 1 3 23 1
4 310 0 4 21 0
5 310 1 5 19 1

Figura 17. Representação de dois fragmentos de uma relação após uma fragmentação vertical
característica de árvores de decisão.

46
5.8. Fragmentação e Problemas de Alocação

Em relação à fragmentação horizontal, poderíamos imaginar que, idealmente, a

melhor função de particionamento é uma que separe os dados em fragmentos que se
enquadrariam com a fase de crescimento da árvore, evitando a leitura de mais dados que
o necessário. O problema em definir claramente esta função é que, de antemão, não
possuímos a idéia clara de como os dados serão subdivididos durante o algoritmo.
Podemos afirmar que uma boa função de particionamento utilizaria atributos do topo da
árvore, de tal forma que a varredura de diferentes ramos seria direcionada para
diferentes partições.
Visões particionadas são objetos que o Oracle7 utiliza para implementar a
fragmentação horizontal. Ao invés de definir uma partição muito grande, definimos
diversas tabelas menores, atribuindo uma função de particionamento a cada uma delas.
Após este passo, uma visão é criada utilizando o operador UNION ALL. Funções de
particionamento são combinadas para filtrar condições em comandos SQL, de tal forma
que algumas partições possam ser ignoradas. Cada partição pode ser processada em
paralelo, utilizando diferentes planos de execução quando aplicável.

Devemos considerar a alocação dos fragmentos horizontais após sua definição

Existem duas possibilidades que o servidor Oracle utiliza para distribuir os dados entre
nós. O primeiro é criando uma tablespace (divisão lógica da base de dados) possuindo
diversos arquivos de dados, os quais estariam espalhados através do nós, permitindo que
o SGBD por si só gerencie o fatiamento. Todos os arquivos de dados são acessados a
partir de todos os nós através da camada VSD. Se tentarmos espalhar os dados
utilizando VSDs, isto representa uma vantagem porque a afinidade de disco,
funcionalidade presente no Oracle equivalente ao envio de funções, pode ser utilizada.
Uma outra possibilidade é permitir que o sistema operacional gerencie o
fatiamento de dados, representando uma abordagem mais simples. No caso de sistemas
IBM RS/6000 SP2, podemos utilizar o Hashed Shared Disk (HSD) da IBM, o qual
permite que os dados de uma tabela sejam transparentemente espalhados através de
múltiplos VSDs, baseados em fatias de tamanho pré-definido.

Em relação à fragmentação vertical, nossos testes mostraram que ela é

particularmente importante durante a primeira fase do passo de crescimento da árvore
do algoritmo de árvore de decisão, quando nenhum ponto de quebra foi ainda definido;
cada consulta é constituída por um simples comando SQL com cláusula group by, sem

47
filtros. Na segunda fase, no máximo uma junção entre duas tabelas é necessária; na
terceira, no máximo uma junção de três tabelas, e assim por diante. Junções em SGBDs
representam tarefas que consomem bastante tempo, até mesmo quando processadas em
paralelo (o servidor Oracle pode efetuar junções em paralelo usando métodos chamados
nested loops, merge joins, hash joins e star joins).

A idéia de fragmentação vertical pode ser implementada através de índices

concatenados (atributo / classe), visando oferecer um melhor tempo de resposta para o
primeiro passo da fase de crescimento da árvore. Uma vez que a consulta mencionada
necessita apenas destas duas colunas, podemos utilizar diretamente os índices, sem
referenciar a tabela original. No servidor Oracle, isto é chamado de fast full scan, o
qual pode ser executado em paralelo.

48
 CAPÍTULO 6 - Avaliação de Desempenho

Nós implementamos um algoritmo de classificação (árvore de decisão)

fortemente acoplado com um servidor de banco de dados paralelo, visando estudar e
identificar problemas relacionados à mineração de dados em um grande volume de
dados. Construímos um conjunto de procedimentos armazenados que são guardados no
dicionário de dados do Oracle em uma forma pré-compilada. Utilizamos um sistema
multiprocessado IBM RS/6000 SP2 com o Oracle Parallel Server 7.3 instalado [25].
Uma consideração importante sobre nossa implementação é que ela não tem
qualquer dependência de memória, isto é, ela funciona não importa o tamanho do
conjunto de dados. Se os dados não cabem em memória, o próprio SGBD é responsável
pela paginação e swapping quando necessário. Não propomos novo algoritmo de
mineração de dados, mas uma abordagem diferente de implementar aplicações de
mineração de dados. Nosso trabalho está baseado no C4.5 [42] e SPRINT [44],
adaptando-os para usar um SGBD ao invés de arquivos isolados.
Inicialmente, para validar a implementação em relação à sua funcionalidade,
utilizamos algumas bases de dados públicas padrões existentes para aprendizado de
máquina, como Iris Plant e Pima Indians Diabetes [33]. Algumas das saídas geradas
para estas bases de dados foram comparadas com as correspondentes utilizando uma
ferramenta comercial chamada Intelligent Miner, da IBM [49]. Em uma próxima fase,
passamos a realizar diversos testes a nível de fragmentação de dados e utilização de
apenas uma relação ou de várias tabelas normalizadas, utilizando relações com
aproximadamente 1.200.000 linhas e 5 atributos. Os dados utilizados são de domínio
público, pertencentes a um acervo denominado Banco Nacional de Dados
Oceanográficos. Finalmente, os testes sobre a avaliação de desempenho de nossa
implementação foram realizados utilizando-se uma base de dados extraída de um
sistema de seguro de vida, a qual será descrita em maiores detalhes na seção a seguir.

49
6.1. Estudo de caso

O conjunto de dados utilizado durante o processo de classificação está baseado

em um sistema de seguro de vida, que controla informações sobre clientes, contratos de
seguro e componentes de tarifas. Pessoas em posições gerenciais usam esta base de
dados em um ambiente de data-warehousing para ajudar na tomada de decisão.
Informações sobre os clientes e seus dependentes incluem data de nascimento,
profissão, sexo, estado civil e dados sobre receita familiar. Além disso, o sistema
armazena dados sobre contratos, tais como o ano em que o contrato começa e termina,
modo de pagamento, nome do agente responsável e tipo de seguro. Finalmente, a base
de dados contém informações sobre taxas de cada tarifa associada a um contrato de
seguro.

Nós construímos uma única relação, apesar de uma série de tabelas normalizadas
estarem disponíveis, devido a problemas de desempenho relacionados a operações de
junção. O servidor Oracle oferece uma variedade de métodos para efetuar junções, mas,
mesmo quando efetuados em paralelo, junções representam uma tarefa custosa. Esta
única relação é relativamente pequena, cabendo inteiramente em memória, com
aproximadamente 50Mb, 200.000 tuplas e 70 atributos. Para propósitos de mineração de
dados, esta relação é consideravelmente grande quando comparada a outras que
aparecem na literatura. Nós manuseamos atributos com diferentes características:
atributos discretos com poucos (2) e vários atributos distintos (86), atributos contínuos
com apenas alguns valores distintos (55) e atributos contínuos com muitos valores
distintos (18.545).
Diversas medições foram efetuadas ao executar o algoritmo de mineração de
dados. Alguns passos foram efetuados seqüencialmente, devido à natureza da linguagem
de programação do Oracle (PL/SQL). Enfatizamos o uso de comandos SQL sempre que
possível para implementar a lógica do algoritmo. Estes comandos SQL são efetuados
pelo servidor paralelo de banco de dados, representando as tarefas mais custosas do
algoritmo, porque eles são responsáveis por lidar com grandes volumes de dados e por
realizar computações sempre que aplicável.
Visando validar os experimentos realizados utilizando o estudo de caso, usamos
o Oracle Parallel Server 7.3.2.3, instalado em um IBM RISC/6000 SP com quatro nós e
memória distribuída de 1.75 Gb [38]. Os dados da relação foram armazenados em uma
única tablespace, espalhada pelos diversos discos existentes no cluster. Cuidados foram

50
tomados para que uma mesma quantidade de tuplas estivesse armazenada em cada um
dos nós existentes. Uma outra tablespace, também espalhada por todos os nós, foi
utilizada para armazenamento de índices criados para auxiliar na filtragem das
informações. Durante algumas medições, apresentamos os tempos de resposta de
consultas quando os dados envolvidos não estão no cache da máquina (cold) e quando
estes mesmos dados já estão em memória (hot). Foi reservado um cache de 100Mb para
as instâncias do Oracle ativas em cada um dos nós.

6.2. Crescimento da Árvore

O tempo de resposta associado a cada consulta SQL varia dependendo,
principalmente, do número de linhas que serão processadas e do número de valores
distintos a serem recuperados. Uma vez que a árvore de decisão repetidamente
subdivide os dados, o tempo de resposta diminui na medida em que descemos na árvore.

Execução Serial
2500 Execução Paralela (4 nós)
Tempo de Resposta (0.01 segs)

2000

1500

1000

500

0
1 2 3 4 5 6
Profundidade da Árvore

Figura 18: Tempo de resposta para execuções paralela e serial para um atributo discreto com
poucos valores distintos (tipo de profissional – 4 valores) durante a fase de crescimento da
árvore.

Analisando a Figura 18, observamos que um comportamento interessante está

representado. Após o quarto nível, o Oracle efetua uma execução serial ao invés de uma
paralela. No caso do Oracle7, não é possível efetuar uma varredura de índice em
paralelo, a menos que todos os atributos usados na consulta estejam presentes no índice
ou um método de junção seja utilizado. A partir do quarto nível, analisamos uma

51
quantidade mais reduzida de dados, sendo uma varredura seqüencial melhor que uma
varredura completa de uma tabela em paralelo. Para tornar o processamento seqüencial
o mais eficiente possível, foram criados índices bitmap no lugar dos tradicionais índices
utilizando árvores B, até mesmo para alguns atributos contínuos, pois os primeiros são
especialmente úteis para consultas que possuam filtros com diversas comparações
utilizando o operador de conjunção (AND).

800 Cold
750 Hot
Tempo de Resposta (0.01 segs)

700
650
600
550
500
450
400
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Profundidade da Árvore

Figura 19: Comportamento das consultas paralelas de acordo com a profundidade da árvore para
um atributo discreto com poucos valores distintos (tipo de profissional – 4 valores).

Apesar do otimizador do Oracle, baseado em estatísticas geradas para as tabelas

e índices correspondentes, na maioria dos casos tomar por si só a decisão de utilizar um
plano de execução seqüencial ou paralelo para uma consulta, é possível direcioná-lo a
como resolver o problema. Para decidir qual o melhor plano de execução para uma
consulta, o otimizador calcula os custos dos diversos planos de execução existentes.
Podemos, por exemplo, definir qual o peso que será atribuído a planos paralelos,
direcionando para a abordagem que deve ser favorecida. Desta forma, para mostrar qual
seria o comportamento do SGBD se todas as consultas fossem efetuadas em paralelo,
em detrimento da utilização de índices, direcionamos o otimizador para que utilizasse
somente planos de execução em paralelo, que, neste caso, fariam uma varredura
completa na tabela. O resultado apresentado na Figura 19 foi obtido, mostrando um
ganho inicial em tempo de reposta na medida em que descemos na árvore e, após um
certo ponto, uma piora gradual no tempo de resposta das consultas, graças à maior
complexidade dos filtros existentes na consulta.

52
 As consultas também são influenciadas pelo tipo de atributo que estamos usando
no algoritmo de mineração. Atributos discretos (Figura 20) normalmente resultam em
um melhor tempo de resposta. Isto acontece pois menos pontos de quebra serão
analisados e menos dados serão recuperados pela aplicação. Atributos contínuos
normalmente manuseiam muitos valores distintos, representando uma tarefa bastante
custosa. Entretanto, na medida em que descemos na árvore, atributos contínuos são
freqüentemente representados por menos valores distintos, resultando em melhores
tempos de reposta, como apresentado na Figura 21.

3000 Cold
Hot
2500
Tempo de Resposta (0.01 segs)

2000

1500

1000

500

0
1 2 3 4
Número de Processadores

Figura 20: Tempo de resposta associado a um atributo discreto com poucos valores distintos
(tipo de profissional – 4 valores) durante a fase de crescimento da árvore. Este gráfico
representa os tempos associados à descoberta do atributo a ser usado como nó raiz da árvore de
decisão.

3000 Cold
Hot
Tempo de Resposta (0.01 segs)

2500

2000

1500

1000

500

0
1 2 3 4
Número de Processadores

Figura 21: Tempo de resposta associado a um atributo contínuo com muitos valores distintos
(prêmio - 18.545 valores) durante a fase de crescimento da árvore. Este gráfico representa os
tempos associados à descoberta do atributo a ser usado como nó raiz da árvore de decisão.

53
 A maior parte da paralelização ocorre ao lidar com nós de decisão que estão no
topo da árvore, de tal forma que mais dados estão sendo analisados. Para estas fases,
percebemos uma melhora de desempenho significativa quando dois nós são utilizados.
Entretanto, ao adicionar mais nós de processamento, o tempo de resposta não decresce
na mesma taxa. Esta situação representa a influência de acesso a tuplas remotas. Uma
vez que as linhas são altamente correlacionadas, nós adicionais também aumentam o
custo de comunicação.
A árvore de decisão foi gerada com aproximadamente 38.000 nós e uma
profundidade igual a 43 (quarenta e três), o que comprova a complexidade do problema.
Uma visão parcial da árvore é apresentada na Figura 22, onde podemos visualizar
alguns atributos situados no topo da mesma.

tariff_date

<= 1985
benefits

<= 0 > 0
bonus sex

<= 0 = ‘M’ = ‘F’

age
tariff_date

<= 58 > 58
<= 1970
age job

= ‘0’ = ‘3’

= ‘1’ = ‘2’

Figura 22: Visão parcial da árvore de decisão construída após a análise dos dados de
treinamento.

6.3. Técnicas de Fragmentação

Os mesmos testes realizados anteriormente foram repetidos utilizando uma base
de dados fragmentada horizontalmente. Como comentado no Capítulo 5, seção 5.7, uma
tarefa difícil para o projetista da base de dados é saber de antemão quais as funções
ideais para subdividir os dados a serem utilizadas pelo algoritmo de árvore de decisão.
A nível de ilustração, foi criada uma base de dados, com 13 (treze) fragmentos com
funções de fragmentação baseadas na árvore gerada usando-se os dados de treinamento.

54
É importante ressaltar que estes testes visam oferecer uma visão de uma solução ideal,
que nem sempre pode ser alcançada.

Os resultados obtidos foram surpreendentemente piores em relação à base sem a

fragmentação definida, devido a problemas existentes com a versão do produto instalada
(Oracle 7.3.2.3), sendo este problema relatado como existente em boletins técnicos do
produto. Como a fragmentação não é uma funcionalidade específica de SGBDs
paralelos, alguns testes foram realizados em uma versão mais recente instalada em um
computador Pentium 200 MMX com Windows NT 4.0 instalado, testes estes que
comprovaram o potencial ganho de se utilizar este tipo de abordagem. O algoritmo foi
executado até a árvore atingir a profundidade 5 (cinco), apenas para termos alguma
idéia de quais atributos são mais significativos. Estes atributos foram utilizados nas
funções de particionamento que geraram 13 (treze) fragmentos. Ganhos de desempenho
relativos à eliminação de partições durante o processamento do plano de execução da
consulta foram comprovados.
Em relação à fragmentação vertical, diversos índices compostos (atributo /
classe) foram criados sobre a relação de mineração de dados, visando oferecer um
melhor desempenho. Mais uma vez, por problemas de versão, não obtivemos o
resultado esperado. Apesar do SGBD Oracle utilizar os índices diretamente, sem a
necessidade de acessar a relação de mineração na primeira etapa do algoritmo (nenhum
filtro definido), esta leitura de índices não se realizou em paralelo. Mais uma vez,
segundo boletins técnicos, este problema estaria resolvido em versões mais recentes do
produto.
Apesar de tudo, é importante ressaltar o potencial existente nestas
funcionalidades, que vêm se tornando cada vez mais comuns nos SGBDs comerciais
atualmente disponíveis.

6.4. Poda
A fase de poda é representada por consultas consideravelmente menos
complexas em relação às fases de crescimento da árvore e extração de regras, até porque
os critérios utilizados para a realização dos processos são bastante simples. Em níveis
onde a profundidade de um nó interno sendo analisado é alta, as consultas são
extremamente rápidas, principalmente porque para a verificação do segundo critério de
poda (substituição de um nó interno por sua subárvore mais freqüentemente utilizada)
envolve uma menor quantidade de exemplos a serem classificados novamente.

55
 Na medida em que analisamos níveis no topo da árvore, um processo
consideravelmente mais demorado é realizado, justamente pelo fato de estarmos
trabalhando com um conjunto maior de exemplos. A verificação do primeiro critério
(substituição por nó folha) mantém-se relativamente constante, uma vez que os
exemplos de teste não precisam ser consultados, estando todas as informações
necessárias presentes na tabela intermediária gerada em uma fase inicial do processo de
poda, que originou uma tabela de aproximadamente 32.000 linhas, as quais estão
relacionadas a aproximadamente 20.000 nós folha. Considerando que esta tabela
intermediária contém poucos atributos, o tamanho deste objeto no banco de dados é
consideravelmente menor que a relação de mineração original utilizada, ocupando, na
situação apresentada no estudo de caso, menos que 1Mb. Consultas seriais se
apresentam suficientemente eficientes para este tipo de problema, situação que pode se
alterar na medida em que uma massa de dados maior for utilizada.
Uma vantagem da utilização da poda que pode ser facilmente percebida está
relacionada ao menor tempo que será gasto na próxima fase (extração de regras), uma
vez que menos regras serão analisadas. O número de regras a serem analisadas é
representado pela quantidade de nós folha, quantidade esta que é reduzida após a poda.

6.5. Extração de Regras

Em relação ao tempo de resposta, o comportamento das consultas efetuadas na

fase de extração de regras, responsáveis pelo cálculo do número de positivos falsos e
negativos falsos, pode ser comparado com o que acontece no crescimento da árvore,
mas em uma ordem inversa. A tentativa de eliminarmos uma primeira condição de cada
regra é representada por uma consulta que envolve uma quantidade relativamente
pequena de dados. Neste caso, uma execução serial tem grande possibilidade de ser
mais eficiente que a execução em paralelo correspondente, pois uma leitura de índices é
executada de uma forma consideravelmente mais rápida que uma varredura completa da
tabela.
Na medida em que mais condições são extraídas do lado esquerdo da regra, esta
passa a representar uma quantidade maior de exemplos. A partir de um certo ponto, uma
leitura em paralelo passa a ser mais vantajosa que uma leitura seqüencial
correspondente. É importante lembrar que estes comentários são importantes já que
leituras de índices não podem ser realizadas em paralelo no Oracle7, uma vez que
estamos utilizando uma única relação, a não ser na exceção representada por um fast full

56
scan. A seguir apresentamos um exemplo de consulta para a verificação se é vantajoso
ou não eliminar a condição TKBEG <= 1985) da regra originalmente gerada.

SELECT NVL (SUM (DECODE (classe, 1, 1, 0)), 0) Y,

NVL (SUM (DECODE (classe,1, 0, 1)), 0) nY
FROM V_MRD_ALL
WHERE NOT (TKBEG <= 1985) AND TKLEIST <= 0 AND
TKINKPRL <= 0 AND EPGEBUDAT <= 1960 AND
TKBEG > 1947 AND TKBEG <= 1984 AND
EPERWEART = '0' AND EPGEBUDAT <= 1956 AND
TKBEG <= 1967

Onde:
EPERWEART – tipo de profissional (discreto)
EPSEXCD – sexo (discreto)
EPGEBUDAT – data de nascimento (contínuo)
TKBEG – início da tarifa do componente (contínuo)
TKLEIST – benefícios assegurados do componente (contínuo)
TKINKPRL – prêmio (contínuo)
CLASSE – atributo alvo

400,00
Execução Paralela
Tempo de Resposta (0.01 segs) .

350,00
Execução Serial
300,00

250,00

200,00

150,00

100,00

50,00

0,00
Regra 1a 2a 3a 4a 5a 6a 7a 8a

Eliminação das condições

Figura 23: Extração de Regras. Características das consultas típicas na fase de extração de
regras.

A Figura 23 mostra o comportamento das consultas referentes à generalização de

uma regra originalmente com 9 (nove) condições. Em um primeiro momento, é efetuada
uma única consulta para o cálculo do número de falsos positivos e negativos associados

57
à regra. A partir deste momento, são efetuadas 9 (nove) outras consultas para verificar
qual das 9 (nove) condições existentes na expressão que representa a regra deve ser
eliminada. Na próxima fase 8 (oito), a seguir 7 (sete) e assim por diante. Neste exemplo,
a regra original foi generalizada em uma regra com apenas 2 (duas) expressões.

58
 7. Conclusões

A mineração de dados e sua aplicação em grandes bancos de dados vem sendo

extensamente estudada, graças à dificuldade crescente de analisar grandes volumes de
informações utilizando apenas ferramentas OLAP. Esta dificuldade nos mostra a
necessidade de um processo automatizado para descobrir padrões interessantes e
desconhecidos em conjuntos de dados reais. A habilidade de manusear grandes
quantidades de informações tem sido uma preocupação crescente em diversas
aplicações de mineração de dados recentes. O processamento paralelo desempenha um
importante papel neste contexto, uma vez que máquinas paralelas oferecem um grande
potencial de poder computacional, memória e E/S de disco.

Neste trabalho descrevemos algumas técnicas importantes de mineração de

dados, mostrando como cada uma pode contribuir para o processo de descoberta de
padrões. Além disso, apresentamos diversas vantagens de implementar um método de
mineração de dados utilizando um SGBD ao invés de arquivos isolados convencionais.
Nosso trabalho prático explorou diversas características específicas de SGBDs,
oferecendo uma integração fortemente acoplada entre uma técnica de mineração de
dados e um SGBD paralelo, utilizando uma aplicação complexa. Através do estudo de
caso, nós exercitamos situações adversas, tais como um grande número de atributos
(discretos e contínuos com muitos valores distintos), observando problemas e propondo
soluções durante o processo como um todo.

Diversos pontos positivos associados à implementação utilizando um SGBD, em

particular um SGBD paralelo, durante o processo de mineração de dados foram
confirmados. A implementação utilizando o PL/SQL como linguagem de programação,
além de oferecer um alto desempenho no processamento de resultados de consultas,
oferece uma portabilidade de versão entre plataformas suportadas pelo servidor Oracle,
baseadas ou não em arquiteturas paralelas. Os mesmos módulos projetados para
executar em paralelo não sofrem qualquer tipo de alteração em relação à execução
serial, sendo possível, desta forma, a codificação e teste de grande parte do código em
um ambiente mono processado, o que definitivamente simplificou e agilizou o processo
de desenvolvimento, além de não existir a preocupação de codificar a aplicação
utilizando rotinas complexas para a implementação do processamento paralelo. Em

59
relação à escolha de planos de execução seriais ou paralelos para a consulta, o SGBD
gerou resultados satisfatórios de acordo com o número de nós existentes no sistema,
característica importante dependendo da técnica de mineração utilizada, como
comentado anteriormente. Uma análise mais detalhada utilizando um maior número de
processadores é desejável. A fragmentação de dados, uma característica que auxilia na
melhora do desempenho e flexibilidade de administração dos dados, mostrou uma área
em potencial a ser explorada, obviamente levando em consideração as característica da
técnica de mineração utilizada.

Em relação ao tráfego de dados usualmente gerado entre aplicações e banco de

dados, uma implementação fortemente acoplada com o SGBD mostrou uma outra
vantagem considerável, pois, sempre que possível, o processamento necessário pelo
algoritmo foi realizado no próprio SGBD, através de comandos SQL com funções
definidas pelo usuário ou até mesmo com a utilização de funções existentes no próprio
SQL do Oracle, retornando para a aplicação um conjunto de informações menor e pré-
processado.

Resultados práticos mostraram gargalos de desempenho ao utilizar SGBDs,

quando comparado com o uso de arquivos isolados, devido à natureza do SQL existente
oferecido pela maioria dos bancos de dados comerciais. Entretanto, se assumirmos que a
mineração de dados em grandes bases de dados se tornará uma tarefa de rotina no futuro
e empresas de SGBDs implementarão novas funcionalidades que ajudarão no processo
de mineração, servidores de bancos de dados desempenharão um papel muito
importante neste contexto. A sobrecarga imposta pelo núcleo do SGBD, apesar de
minimizada através de uma configuração específica da base de dados para o algoritmo
de mineração utilizado (e.g. configuração da base de dados para leitura somente) que
possibilitou uma redução em cerca de 20% do tempo de resposta original, é um outro
fator que ainda deve ser analisado com mais atenção pelas equipes de desenvolvimento
dos produtos.

Enquanto a maioria dos trabalhos utiliza mineração em SGBDs seqüenciais ou

mineração com paralelismo utilizando arquivos isolados, este trabalho contribui para a
validação do uso de um sistema genérico de SGBD com capacidade de processamento
paralelo no auxílio do desenvolvimento de um sistema de mineração de dados. O uso de
uma aplicação complexa mostrou o potencial do paralelismo de um SGBD em situações
onde o processamento seqüencial era suficiente. Embora as técnicas de mineração de

60
dados utilizadas não apresentem características inovadoras, sua combinação
implementada sobre um SGBD paralelo constitui uma experiência prática inovadora.

É possível que mudanças nos SGBDs correntes e na linguagem SQL

possibilitem que operações de mineração de dados sejam efetuadas mais eficientemente.
Por exemplo, otimizações entre consultas possibilitariam que uma única varredura nos
dados servissem simultaneamente a múltiplas consultas que precisassem das mesmas
informações [14]. Além disso, SGBDs relacionais orientados a objetos oferecem uma
grande área em potencial a ser explorada, uma vez que é possível desenvolver
componentes para estender a capacidade de um servidor de banco de dados. Seus
componentes são armazenados no servidor, sendo possível definir novos tipos de dados
e comportamentos para oferecer capacidades orientadas a soluções anteriormente não
disponíveis. Os usuários podem livremente utilizar estes novos tipos de dados em suas
aplicações ou até mesmo estender os componentes existentes. Outras interfaces, tais
como aquelas para mecanismos de indexação e otimização estarão disponíveis em um
futuro próximo.

Este trabalho abre portas para outras pesquisas a serem realizadas nesta área, as
quais poderiam abordar aspectos que não puderam ser contemplados seja por problemas
existentes na versão atual do SGBD instalado, seja por alguma característica específica
existente no SGBD utilizado, ou simplesmente devido ao grande número de variáveis a
serem consideradas em um curto intervalo de tempo. Por exemplo, uma maior ênfase à
medição de desempenho associada à partição dos dados poderia ser realizada, ênfase
que não pode ser dada de uma forma completa devido a problemas existentes na versão
do produto instalada, apesar de ter sido possível verificar o potencial existente neste tipo
de abordagem ao utilizar operações de mineração de dados. Além disso, pesquisas sobre
mineração de dados incremental representam uma área ainda a ser bastante explorada,
principalmente considerando-se sua integração com SGBDs, onde novas informações
estão sucessivamente sendo cadastradas. De acordo com novos dados que serviriam de
entrada, poderíamos ajustar gradativamente o modelo criado através da análise de dados
históricos, ao invés de efetuar um processamento completo utilizando todo o conjunto
de dados.

Apesar de testes preliminares terem mostrado que a utilização de uma única

relação de mineração oferece diversas vantagens relacionadas a desempenho em
comparação com a utilização de diversas tabelas (totalmente normalizadas ou não)

61
devido a problemas de desempenho relacionados a operações de junção, ainda há
espaço para outros experimentos nesta área. Por exemplo, é interessante que sejam
realizados testes utilizando uma abordagem típica de ambientes de data-warehousing,
onde uma modelagem de dados baseada em star schema é amplamente utilizada. Este
tipo de experimento é de vital importância, pois esta representaria uma solução que
evitaria a criação de ambientes separados para os dois processos. Isto torna-se ainda
mais importante na medida em que a implantação de um ambiente de data-warehousing
anterior ao início de um processo de mineração de dados é um caminho natural a ser
seguido nos dias atuais.

Uma futura implementação poderia ser representada por um processo de

conversão para a utilização do Oracle8, construindo o que a Oracle chama de cartucho
(data cartridge), um tipo de componente que pode ser anexado ao servidor de banco de
dados), solução cada vez mais difundida na medida em que surgem os bancos de dados
relacionais orientados a objetos. Esta conversão é motivada não só pelos benefícios
existentes nesta abordagem, mas também pela presença de novas funcionalidades nesta
versão associadas ao processamento paralelo, funcionalidades estas que representariam
um ganho de desempenho consideravelmente maior para a implementação. Um
exemplo de tal nova característica é a possibilidade de efetuarmos leituras de índices em
paralelo. Para que isto seja realizado, o Oracle8 oferece uma nova funcionalidade que é
a possibilidade de criar índices armazenados em diversas partições, sendo cada um dos
processos escravos responsável pela leitura de uma partição do índice. Além disso,
melhoras no módulo otimizador de consultas foram realizadas, dando mais relevância a
fatores como a fragmentação dos dados e paralelismo envolvido nas consultas como
pontos importantes na escolha dos planos de execução das mesmas.

62
Referências Bibliográficas

[1] AGERWALA, T., MARTIN, J. L., MIRZA, J. H., et al. “SP2 system architecture”,
IBM Systems Journal – Scalable Parallel Computing, v. 34, n. 2, 1995.
[2] AGRAWAL, R., GEHRKE, J., GUNOPULOS, D., et al. “Automatic Subspace
Clustering of High Dimensional Data for Data Mining Applications”. In:
Proceedings of the ACM SIGMOD International Conference on Management of
Data, pp. 94-105, Seattle, 1998.
[3] AGRAWAL, R., GHOSH, S., IMELINSKI, T., et al. “An Interval classifier for
database mining applications”. In: Proceedings of the 18th Conference on Very
Large Databases, pp.560-573, Vancouver, 1992.
[4] AGRAWAL, R., IMIELINSKI, T., SWAMI, A. “Database Mining: A Performance
Perspective”. In: Proceedings of IEEE Transactions on Knowledge Discovery and
Data Engineering (TKDE), v. 5., n.6, pp. 914-925, 1993.
[5] AGRAWAL, R., IMIELINSKI, T., SWAMI, A. “Mining association rules between
sets of items in large databases”. In: Proceedings of the ACM SIGMOD
International Conference on the Management of Data, pp.207-216, Washington D.
C., 1993.
[6] AGRAWAL, R., METHA, M., SHAFER, J., et al. “The Quest Data Mining
System”. In: Proceedings of the 2nd International Conference on Knowledge
Discovery in Databases and Data Mining, pp. 244-249, Portland, 1996.
[7] AGRAWAL, R., SHIM, K. “Developing Tightly-Coupled Data Mining
Applications on a Relational Database System”. In: Proceedings of the 2nd
International Conference on Knowledge Discovery in Databases and Data Mining,
pp. 287-290, Portland, 1996.
[8] AGRAWAL, R., SRIKANT, R. “Fast Algorithms for mining association rules”. In:
Proceedings of the 20th International Conference on Very Large Databases, pp.
487-499, Santiago, 1994.
[9] ARANTES, J. A. A., BOTELHO, P. L., EBECKEN, N. F. F., CALOBA, L. P.
“Ship’s Classification by its Magnetic Signature”. In: Proceedings of IEEE World
Conference on Computational Intelligence,1988.

63
[10] BLOCKEEL, H., DE RAEDT, L. “Top-down Induction of Logical Decision
Trees”. In: Proceedings of the 9th Dutch Conference on Artificial Intelligence
(NAIC), 1997.
[11] BIGUS, J. P., Data Mining with Neural Networks, McGraw-Hill, 1996.
[12] BREIMAN, L., FRIEDMAN, J., OLSHEN, R., et al. Classification and Regression
Trees. Pacific Groves, CA, Wadsworth, 1984.
[13] CHEN, M. S., HAN, J., YU, P. S. “Data Mining: An Overview from Database
Perspective” In: IEEE Trans. on Knowledge and Data Engineering, Vol. 8, No. 6,
pp.866-883, 1996.
[14] CHOENNI, R., KERSTEN, M. L., AKKER, J. F. P. “On multi-query
optimization”. In: Report CS-R9638, CWI, Computer Science / Department of
Algorithmics and Architecture, Amsterdam, 1996.
[15] EBECKEN, N. F. F. “Prediction of Metereologic Conditions Using Data Mining
Techniques”. In: Proceedings of the 3rd Workshop on Computational Methods for
Oceanic, Atmospheric and Ground Water Flows, LNCC, Rio de Janeiro, 1997.
[16] FAYYAD, U., PIATESKY-SHAPIRO, G., SMYTH, P., et al. (Eds.) Advances in
Knowledge Discovery and Data Mining.AAAI/MIT Press. 1996.
[17] FAYYAD, U, DJORGOVSKI, S., WEIR, N. “Automating the Analysis and
Cataloging of Sky Surveys”. In [16], pp.471-493, 1996.
[18] FAYYAD, U., PIATESKY-SHAPIRO, G., SMYTH, P. “From Data Mining to
Knowledge Discovery: An Overview”, In [16], pp.1-34. 1996.
[19] FAYYAD, U., PIATESKY-SHAPIRO, G., SMYTH, P. “From Data Mining to
Knowledge Discovery in Databases”, Artificial Intelligence Magazine, pp. 37-54,
Fall, 1996.
[20] FREITAS, A., Generic, Set-oriented Primitives to Support Data-parallel
Knowledge Discovery in Relational Database Systems, Ph. D. dissertation,
University of Essex, UK, 1997.
[21] FREITAS, A., LAVINGTON, S. Mining Very Large Databases with Parallel
Processing. Kluwer Academic Publishers, 1998.
[22] FREITAS, A., LAVINGTON, S. “Speeding up Knowledge Discovery in Large
Databases by Means of a New Discretization Algorithm”. In Proceedings of the
14th British International Conference on Databases. pp. 124-133, Edinburgh.
[23] FREITAS, A., LAVINGTON, S. “Towards Large-Scale Knowledge Discovery in
Databases (KDD) by Exploiting Parallelism in Generic KDD Primitives”. In:

64
 Proceedings of the 3rd International Workshop on Next Generation Information
Technologies and Systems (NGITS), Neve Ilan, 1997.
[24] HALLMARK, G. “Oracle Parallel Warehouse Server”. In: Proceedings of the 13th
International Conference on Data Engineering, pp.314-320, Birmingham,1997.
[25] HALLMARK, G. “Tuning the Performance of the Oracle7 Parallel Query Option”.
International Oracle User Week, 1995.
[26] HAN, J., FU, Y., KOPERSKI, K., MELLI, et al. “Knowledge Mining in Databases:
An Integration of Machine Learning Methodologies with Database Technologies”,
Canadian AI Magazine, 1995.
[27] HAN, J., FU, Y., WANG, W., CHIANG, J., et al. “DBMiner: A System for Mining
Knowledge in Large Relational Databases”. In: Proceedings of the International
Conference on Knowledge Discovery in Databases, pp. 250-255, Portland, 1996.
[28] HOLSHEIMER, M., KERSTEN, M. L., SIEBES, A., “Data Surveyor: Searching
the Nuggets in Parallel”. In: Advances in Knowledge Discovery and Data Mining,
pp.447-467, AAAI Press, 1996.
[29] KERBER, R. “ChiMerge: Discretization of Numeric Attributes”. In Proceedings of
the 10th National Conference on Artificial Intelligence. , pp-123-128, San Jose,
1992.
[30] KIM, W. Modern Database Systems. New York, Addison-Wesley / ACM Press,
1995.
[31] KUFRIN, R. “Decision Trees on Parallel Processors”. In: Parallel Processing for
Artificial Intelligence 3, Elsevier Science, pp.279-306, 1997.
[32] LINDER, B. “Oracle Parallel RDBMS on Massively Parallel Systems”. In:
Proceedings of the 2nd International Conference on Parallel and Distributed
Information Systems, pp. 67-68, San Diego, 1993.
[33] MERZ, C. J. , MURPHY, P. M. UCI Repository of machine learning databases.
http://www.ics.uci.edu/~mlearn/MLRepository.html. University of California,
Irvine, Dept. of Information and Computer Sciences, 1998.
[34] METHA, M., AGRAWAL, R., RISSANEN, J. “SLIQ: A Fast Scalable Classifier
for Data Mining”. In: Proceedings of the 5th International Conference on
Extending Database Technology (EDBT), pp. 18-32, Avignon, 1996.
[35] METHA, M., DEWITT, D. J. “Data Placement in shared-nothing parallel database
systems”. VLDB Journal, v.6, n.1, Springer-Verlag, January, 1997.

65
[36] MEYER, L. A. V. C., MATTOSO, M.L.Q. “Sistemas de Banco de Dados
Distribuídos e Paralelos”. In: Tutorial dos Anais do XII Simpósio Brasileiro de
Banco de Dados, Apostila publicada como separata com 38 págs.
[37] MITCHELL, T. M., Machine Learning. McGraw-Hill, 1997.
[38] NACAD. http://www.nacad.ufrj.br, 1998.
[39] NAVATHE, S. B., ELMASRI, R., Fundamentals of Database Systems, 2 ed.,
Redwood City, The Benjamin/Cummings Publishing Company Inc, 1994.
[40] NAVATHE, S. B., RA, M. “Vertical Partitioning for Database Design: A
Graphical Algorithm”. In: Proceedings of the ACM SIGMOD International
Conference on Management of Data, pp.440-450, 1989.
[41] ORACLE CORPORATION. Oracle Parallel Server Concepts & Administration
Rel. 7.3. Oracle Technical Manual, 1997.
[42] QUINLAN, J. R., C4.5: Programs for Machine Learning. Morgan Kaufman, 1993.
[43] QUINLAN, J. R., “Simplifying decision trees”. International Journal of Man-
Machine Studies 27, pp. 221-234, 1997.
[44] SHAFER, J., AGRAWAL, R., METHA, M. “SPRINT: A Scalable Parallel
Classifier for Data Mining”. In: Proceedings of the 22nd International Conference
on Very Large Databases, pp. 544-555, Mumbi, 1996.
[45] SOUSA, M. S., MATTOSO, M.L.Q., EBECKEN, N.F.F. “Data Mining: A Tightly-
Coupled Implementation using a Parallel Database Server”. In: Proceedings of the
International Conference on Database and Expert Systems Applications Workshop
"Parallel Databases: innovative applications and new architecture", IEEE CS,
Vienna, 1998.
[46] SOUSA, M. S., MATTOSO, M.L.Q., EBECKEN, N.F.F. “Data Mining on Parallel
Database Systems”. In: Proceedings of the International Conference on Parallel
and Distributed Processing Techniques and Applications: Special Session on
Parallel Data Warehousing, CSREA Press, pp. 1147-1154, Las Vegas, 1998.
[47] SOUSA, M. S., MATTOSO, M.L.Q., EBECKEN, N.F.F. “Data Mining: a database
perspective”. In: Proceedings of the International Conference on Data Mining, Rio
de Janeiro, 1998.
[48] SRIKANT, R., AGRAWAL, R. “Mining Sequential Patterns: Generalizations and
Performance Improvements”. In: Proceedings of the 5th International Conference
on Extending Database Technology (EDBT), pp. 3-17, Avignon, 1996.

66
[49] TKACH, D. S. Information Mining with the IBM Intelligent Miner Family.
http://www.software.ibm.com/data/pubs/papers/#whitefam. IBM White Paper,
1998.
[50] TSUR, D., ULLMAN, J. D., ABITEBOUL, S., et al. “Query Flocks: A
Generalization of Association-Rule Mining”. In: Proceedings of the ACM
SIGMOD International Conference on Management of Data, pp. 1-12, Seattle,
1998.
[51] VALDURIEZ, P. “Parallel Database Systems: open problems and new issues”.
International Journal on Distributed and Parallel Databases, v. 1, n. 2, pp. 137- 165,
1993.

67