EXTRAÇÃO DE REGRAS DE ASSOCIAÇÃO EM UMA BASE

EXTRAÇÃO DE REGRAS DE ASSOCIAÇÃO EM UMA BASE DE DADOS
RELACIONAL
Hélcio Gomes de Souza Filho
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 DOS REQUISITOS NECESSÁRIOS
PARA A OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIAS EM ENGENHARIA
CIVIL.
Aprovada por:
_______________________________________________________
Prof. Nelson Francisco Favilla Ebecken, D.Sc
_______________________________________________________
Prof. José Murilo Ferraz Saraiva D.Sc.
_______________________________________________________
Prof. Beatriz de Souza Leite Pires de Lima, D.Sc
RIO DE JANEIRO, RJ - BRASIL
MARÇO DE 2004
SOUZA FILHO, HÉLCIO GOMES DE
Extração de Regras de Associação de um
Banco de Dados Relacional [Rio de Janeiro] 2004
VI, 67 p. 29,7 cm (COPPE/UFRJ, M. Sc.,
Engenharia Civil, 2004)
Tese - Universidade Federal do Rio de Janeiro,
COPPE
1. Regras de Associação
2. Banco de Dados Relacional
3. Algoritmo Apriori
I. COPPE/UFRJ
II. Título (série)
ii
Aos meus avós,
José, Elídia,
Alfredo e Rosa.
iii
AGRADECIMENTOS
Ao professor Nelson Ebecken, meu orientador, que com sua experiência e visão
prática possibilitou que este trabalho fosse concluido com sucesso.
À minha amiga Silvana Scofano que me incentivou muito para iniciar o
mestrado.
À funcionária Estela pelo apoio que me deu durante o curso e pela amizade.
A todos os demais funcionários e amigos da COPPE.
iv
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.)
EXTRAÇÃO DE REGRAS DE ASSOCIAÇÃO DE UM BANCO DE DADOS
RELACIONAL
Hélcio Gomes de Souza Filho
Março/2004
Orientador: Nelson Francisco Favilla Ebecken
Programa: Engenharia Civil
Atualmente as empresas estão armazenando uma quantidade grande de dados e
com isso surge a necessidade de se criar procedimentos automatizados para pesquisar estes
dados a fim de descobrir as associações e correlações existentes, porém ocultas. Os
algoritmos de extração de regras de associação constituem uma importante ferramenta para
busca de conhecimento escondido em grandes bases de dados. Nosso trabalho tem o
objetivo de desenvolver uma forma otimizada de extrair as regras de associação utilizando
as facilidades disponíveis nos SGBDs relacionais.
v
Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the requirements
for the degree of Master of Science (M. Sc.)
EXTRACTION OF ASSOCIATION RULES FROM RELATIONAL DATABASES
Hélcio Gomes de Souza Filho
March/2004
Advisor: Nelson Francisco Favilla Ebecken
Department: Civil Engineering
Nowadays the companies are storing a large amount of data and the need of
creating an automated process to search this data appears,
in order to find hidden
associations and correlations existent among them. The algorithms to extract the association
rules are an important tool used to find the hidden knowledge in large databases. Our work
develops a program more efficient to extract the association rules, using the facilities of the
relational DBMSs.
vi
ÍNDICE
1 – INTRODUÇÃO ..............................................................................................9
2 – REGRAS DE ASSOCIAÇÃO .....................................................................12
2.1. Declaração formal do problema ...........................................................13
2.1.1. Decobrindo os grandes conjuntos de itens..................................15
2.1.2. O algoritmo apriori .....................................................................18
2.1.2. O algoritmo de regras de associação aplicado a tabelas ................
relacionais ..................................................................................18
2.2. O problema do item raro ......................................................................21
2.3. O grau de interesse de uma regra .........................................................21
3 – INTEGRAÇÃO DO ALGORITMO DE REGRAS DE ASSOCIAÇÃO
E BANCOS DE DADOS RELACIONAIS .................................................23
3.1. Fontes de dados usadas pelos algoritmos.............................................23
3.2. Estrutura do ambiente de Mineração de Dados....................................24
3.2.1. Implementação fracamente acoplada ..........................................24
3.2.2. Implementação fortemente acoplada ..........................................26
3.3. Representação dos Modelos de Mineração em Bancos de Dados .......26
4 – IMPLEMENTAÇÃO DE UM ALGORITMO DE REGRAS DE
ASSOCIAÇÃO EM UM SGBD RELACIONAL ......................................29
4.1. Pré-processamento ...............................................................................29
4.2. Representação dos dados......................................................................30
4.3. Geração dos grandes conjuntos de itens...............................................31
4.4. Poda......................................................................................................33
4.5. Extração das regras de associação........................................................33
7
4.6. Determinação do grau de interesse de uma regra.................................35
4.6.1. A utilização de critérios objetivos...............................................36
4.6.2. A utilização de critérios subjetivos .............................................37
5 – AVALIAÇÃO DO ALGORITMO IMPLEMENTADO NO SGBD........39
5.1. Geração dos grandes conjuntos de itens...............................................39
5.2. Limitação da quantidade de conjuntos de itens gerados ......................42
5.2.1. Utilizando o suporte mínimo ......................................................42
5.2.2. Utilizando o tamanho máximo dos conjuntos de itens ...............43
5.3. Avaliação do grau de interesse das regras extraídas ............................45
5.3.1. Regras interessantes segundo critérios objetivos........................45
5.3.2. Regras interessantes segundo critérios subjetivos ......................45
5.3.2.1. Determinando os itens que não devem fazer parte das
regras..................................................................................46
5.3.2.2. Determinando a quantidade máxima de itens presentes nas..
regras..................................................................................46
5.3.2.3. Utilizando as impressões gerais do usuário .......................47
5.3.2.4. Utilizando o conhecimento razoavelmente preciso do
usuário...............................................................................48
5.3.2.4. Utilizando o conhecimento preciso do usuário..................49
5.4. A extração de regras que possuem itens raros .....................................49
5.5. Avaliação dos resultados obtidos .........................................................50
6 – CONCLUSÕES.............................................................................................52
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................55
ANEXO I
........................................................................................................57
ANEXO II
........................................................................................................59
8
ANEXO III ........................................................................................................60
ANEXO IV ........................................................................................................61
9
1. INTRODUÇÃO
Os recentes avanços tecnológicos tem permitido às empresas coletar e
armazenar uma grande quantidade de dados referentes às suas atividades. Estes dados
podem esconder conhecimentos valiosos e úteis para apoiar decisões estratégicas. Ao
mesmo tempo, a utilização de computadores tem permitido a extração automática de
conhecimento destes dados.
Estudos indicam que o volume de dados em uma organização dobra a cada
cinco anos. A maioria das organizações não sofre de falta de dados, mas sim de uma
abundância de dados redundantes e inconsistentes difíceis de usar para o suporte à decisão
[19]. Neste contexto as empresas enfrentam o desafio de organizar os seus dados e extrair o
conhecimento que se esconde nesta grande massa de dados.
Está se tornando cada dia mais difícil analisar essa grande quantidade de dados
usando apenas ferramentas OLAP (Online analytical processing), existindo a necessidade
de utilizar um processo automatizado para descobrir padrões desconhecidos nos dados.
Técnicas de mineração de dados têm sido extensivamente estudadas,
especialmente para análise de grandes massas de dados. Um problema típico é que os
algoritmos utilizados na mineração de dados precisam varrer a base de dados mais de uma
vez. Uma forma de otimizar este processo e diminuir a quantidade de dados utilizados, seria
a utilização de uma amostra dos dados, mas esta opção tem a desvantagem de tornar menos
evidente as diferenças sutis entre os dados.
A necessidade de manusear grandes quantidades de dados tem exigido um
maior poder computacional e uma otimização dos programas desenvolvidos. A maioria das
aplicações de mineração de dados, mesmo trabalhando com bancos de dados, utilizam-no
apenas como depósito de dados, extraindo-os diretamente para a memória principal do
computador responsável por executar o algoritmo de mineração de dados. Esta abordagem
limita a quantidade de dados que pode ser usada, forçando as aplicações a filtrar as
informações, e usar apenas parte delas para descobrir padrões desconhecidos. Algumas
aplicações executam dinamicamente consultas em um ambiente cliente / servidor. Neste
caso uma grande quantidade de dados é transferida, logo um tráfego desnecessário é gerado
na rede.
10
A idéia de executar programas que acessam bancos de dados evitando gerar
tráfego desnecessário nas redes, tem sido uma preocupação em muitos SGBDs (Sistemas
Gerenciadores de Banco de Dados). Um exemplo dessas aplicações são os procedimentos
armazenados. Por exemplo, o SQL SERVER 2000, SGBD desenvolvido pela Microsoft,
possibilita a implementação de procedimentos utilizando comandos da linguagem TransactSQL. [7] [9]
Tem havido um grande desenvolvimento de técnicas para integrar as aplicações
de mineração de dados com os SGBDs, implementando parte da aplicação dentro deles.
Estão sendo produzidas aplicações com bancos de dados relacionais, onde se constata que,
sempre que possível, o processamento deve ser incluído em comandos SQL.
A eficiência e o poder de expansão de seus algoritmos são atributos das
aplicações de mineração de dados, o que torna a otimização dos programas um fator
relevante no momento em que for necessário processar uma grande quantidade de dados em
um intervalo de tempo satisfatório. Neste contexto, a utilização de procedimentos, que são
executados dentro dos SGBDs, desempenham um papel importante, porque proporcionam
um redução no tempo de execução e uma diminuição no tráfego de dados em uma rede.
Aplicações de mineração de dados normalmente varrem repetidamente todo o conjunto de
dados e alguns podem ter um grande número de atributos e algumas centenas de milhares
de casos .
O problema que este trabalho visa abordar é representado pela necessidade do
manuseio de uma quantidade cada vez maior de dados em processos de mineração de dados
e pela incapacidade de algumas aplicações atualmente existentes executarem esta tarefa de
uma forma eficiente. Devido às características dos processos de mineração de dados, o uso
da capacidade de processamento fornecida pelos SGBDs é um fator importante na
implementação de uma aplicação, por se tratar do processamento de uma quantidade muito
grande de dados que é lida várias vezes, o tempo de execução é naturalmente uma
preocupação. Visando validar nossos experimentos, utilizamos o SQL SERVER 2000. [7]
[9]
Um conjunto de procedimentos armazenados escritos em Transact-SQL foi
construído, oferecendo integração com o banco de dados. O experimento utilizado foi uma
aplicação para extrair as regras de associação de um banco de dados relacional. Esta técnica
11
é particularmente importante quando tentamos encontrar associações e correlações entre os
dados.
Este trabalho foi organizado da seguinte forma: No capítulo 2, apresentamos
uma visão geral da técnica de descoberta das regras de associação. No capítulo 3
abordamos as implementações dos algoritmos de mineração de dados em relação ao
acoplamento entre aplicação e o banco de dados. No capítulo 4 implementamos uma
aplicação para extração de regras de associação usando uma integração fortemente
acoplada. O capítulo 5 avaliamos o desempenho do algoritmo apresentado no capítulo 4 e
estabelecemos uma comparação entre a implementação fortemente acoplada e uma outra
fracamente acoplada. Finalmente o capítulo 6, onde apresentamos as conclusões e futuros
trabalhos a serem realizados.
12
2– REGRAS DE ASSOCIAÇÃO
O processo utilizado para extrair o conhecimento existente em grandes bases de
dados se chama Mineração de Dados. Este processo deve ser semi-automático, porque
exige a participação do usuário na definição dos dados que serão analisados e na
verificação do conhecimento descoberto, informando se é útil ou não. Este processo visa
extrair de grandes bases de dados, sem nenhuma formulação prévia de hipóteses,
informações desconhecidas, válidas e úteis para a tomada de decisões.
Existem vários modelos de padrões e conhecimentos ocultos em grandes bases
de dados, um destes modelos são as regras de associação.
As regras de associação fazem parte das técnicas de mineração de dados e são
utilizadas para descobrir associações e correlações existentes entre os dados de um grande
banco de dados que atendam a critérios estabelecidos. Estes critérios podem ser objetivos
ou subjetivos e servem para determinar se uma regra de associação encontrada é
interessante ou não.
O conceito de interesse de uma regra de associação freqüentemente depende do
problema que está sendo analisado. Por exemplo, uma regra descoberta pode ser do tipo: se
você tem idade entre 18 e 20 anos e o CEP do seu endereço é 22420-000 (Av. Vieira
Souto), então você possui um carro que custa US$ 50.000,00. Se estivermos tentando
desenvolver uma campanha de marketing para produtos de luxo esta regra é interessante,
mas se estivermos interessados em analisar o problema de fraudes em seguro saúde esta
regra não terá muita importância.
Um exemplo típico de regras de associação é a análise da cesta de mercado.
Esse processo analisa os hábitos de consumo dos clientes descobrindo associações entre
diferentes itens que são colocados nas cestas de compra.
Se pensarmos em todos os itens presentes do estoque da loja, cada item possui
uma variável booleana que representa a sua presença ou ausência na cesta de um
determinado cliente. Caso o item esteja presente na cesta a variável tem o valor 1, caso
contrário o valor é 0. Cada cesta pode ser representada por um vetor booleano formado por
estas variáveis, conforme mostrado na Tabela 1.
13
Cesta
1
2
3
4
5
6
A
1
0
1
1
1
0
B
1
1
1
1
1
1
C
0
1
0
1
1
1
D
1
0
1
0
1
1
E
1
1
1
1
1
0
Tabela 1: Exemplo de uma tabela de transações
Neste exemplo, existem 5 itens no estoque da loja: A, B, C, D e E e as linhas da
tabela mostrada na Tabela 1 representam as compras de cada cliente.
Considerando a regra A, B → C extraída do conjunto de transações dos itens.
Podemos constatar que os itens A, B e C foram comprados juntos em duas das seis
transações (transações 4 e 5). Dizemos que a regra tem suporte (“covarage”) de 0,33 (2/6).
Para encontrarmos as associações existentes entre os dados devemos calcular a
quantidade de vezes que um conjunto de itens aparece nas cestas e comparar o valor
calculado com um limite pré-determinado chamado suporte mínimo. Os conjuntos de itens
que estão presentes em uma quantidade de cestas maior que o valor do suporte mínimo são
considerados grandes conjuntos de itens e serão utilizados para gerar as regras de
associação. Chamaremos de conjunto de itens a todo subconjunto dos itens do estoque.
2.1 Declaração formal do problema.
A declaração formal do problema foi apresentada por AGRAWAL et al [2].
Seja I = I1, I2, ....., Im um conjunto de atributos binários, chamados de itens. Seja T um
banco de dados de transações. Cada transação t é representada como um vetor binário, com
t[k] = 1, se t contém o item Ik, e t[k] = 0 caso não contenha. Há uma linha no banco de
dados para cada transação. Seja X um conjunto de itens em I. Dizemos que a transação t
satisfaz X se para todos os itens Ik em X, t[k] = 1.
No exemplo mostrado na Tabela 1 cada cesta de compra representa uma
transação. Temos então as seguintes transações:
14
T1 = (A,B,D,E)
T2 = (B,C,E)
T3 = (A,B,D,E)
T4 = (A,B,C,E)
T5 = (A,B,C,D,E)
T6 = (B,C,D)
Utilizando a técnica de regras de associação, encontramos implicações da
forma: X → I j, que significa X implica em Ij, onde X é um conjunto composto por alguns
itens de I, e Ij é um item de I que não está presente em X.
Considerando os itens existentes na transação T1 podemos ter, por exemplo, a
seguinte implicação: A → B, onde A é um conjunto de itens do estoque e o elemento B,
presente no conseqüente da implicação, não está presente no antecedente. Não podemos ter
implicações do tipo: A → A ou A → AB.
Dado um conjunto de transações T, estamos interessados em gerar todas as
regras que satisfazem a restrições de dois tipos:
Restrição sintática: neste caso determinamos se um item Ij deve estar contido
ou não nas regras que serão geradas. Esta restrição é subjetiva, pois depende da opinião da
pessoa que irá definir qual é o item que deverá ser ignorado.
Restrição de suporte: esta restrição diz respeito ao número de transações em T
que suportam a regra. O suporte de uma regra é definido como a porcentagem de transações
em T que contém os elementos do seu antecedente e os elementos do seu conseqüente.
O suporte de uma regra de associação é uma medida do grau de interesse da
regra. Estabelecemos um valor chamado suporte mínimo e estaremos interessados apenas
nas regras que possuem um suporte maior que o suporte mínimo determinado. Não existe
um valor fixo para o suporte mínimo, ele vai depender do problema que está sendo
analisado.
15
Outra medida do grau de interesse de uma regra de associação é a confiança. A
regra X → Ij possui fator de confiança 0 ≤ c ≤ 1 se no mínimo c% de transações em T que
contém X também contêm Ij. Usaremos a notação X → I
j
tem o fator de confiança c. A
confiança é probabilidade condicional P(Ij / X), probabilidade de ocorrer Ij dado que
ocorreu X. Temos então:
1. Suporte (X → I j) = P(X ∪ I j)
2. Confiança (X → I j) = P(I j / X)
O problema de extrair regras de associação pode ser decomposto em dois
subproblemas:
1. Gerar todas as combinações de itens que possuem suporte maior que um certo limite
chamado suporte mínimo. Chamamos estas combinações de grandes conjuntos de
itens e as outras são os pequenos conjuntos de itens.
2. Para todos os grandes conjuntos de itens, gerar as regras de associação e calcular os
respectivos valores para a confiança de cada um. Se o valor da confiança for maior
que um limite determinado chamado confiança mínima então a regra satisfaz o
critério do fator de confiança, caso contrário não satisfaz.
2.1.1 Descobrindo os grandes conjuntos de itens
O algoritmo para descoberta dos grandes conjuntos de itens está demonstrado
em [2] e [3]. Para cada transação o algoritmo forma todas as combinações possíveis de itens
e cada combinação representa um conjunto de itens. Cada conjunto de itens possui um
contador associado que armazena o número de transações em que ele aparece.
As primeiras combinações de dados encontradas são formadas por 1 elemento,
e para cada uma é armazenado no contador a quantidade de transações em que eles
aparecem. Depois encontramos as combinações de itens contendo 2 elementos, formando
extensões dos conjuntos já encontrados. Uma extensão de um conjunto de dados é definida
16
da seguinte forma: seja X e Y conjuntos de itens formados por elementos de I. Então X + Y
é dito uma extensão do conjunto de dados X se X ∩ Y = ∅.
A Figura 1 mostra um modelo de algoritmo para descobrir grandes conjuntos de
itens. O parâmetro dbsize é o total de linhas em um banco de dados e o parâmetro
minsuppot é o valor considerado como suporte mínimo para os conjuntos de itens.
O algoritmo executa múltiplos passos sobre o banco de dados. A cada passo os
conjuntos de itens são estendidos e os respectivos suportes calculados. Estes conjuntos de
itens são chamados conjuntos de itens candidatos, porque os seus suportes ainda não foram
comparados com o parâmetro suporte mínimo para determinarmos se são grandes conjuntos
de dados ou não.
Inicialmente existe apenas um conjunto de itens, que é o conjunto vazio. Ao
término de um passo, o suporte para um conjunto de itens candidato é calculado e
comparado com o minsupport para determinar se é um grande conjunto de itens. Ao mesmo
tempo, é determinado se este conjunto de itens deve ser adicionado ao conjunto de dados
que será estendido no próximo passo. O algoritmo termina quando o conjunto fronteira
(Frontier) se torna vazio. O contador de suporte para o conjunto de itens é preservado
quando um conjunto de itens é adicionado ao conjunto fronteira. O conjunto fronteira é
formado pelos conjuntos de itens que serão estendidos.
Na melhor hipótese poderíamos encontrar todos os grandes conjuntos de itens
com apenas um passo. Mas na pior situação serão necessários 2m contadores para todos os
conjuntos de itens que podem ser encontrados em I, onde m é o número de itens em I. Isto
não é apenas impraticável como desnecessário. De fato, é muito provável que poucos
conjuntos de itens grandes contenham mais de l itens, onde l é um valor pequeno.
Uma abordagem melhor é encontrar em apenas k passos os conjuntos de itens
grandes que contêm exatamente k itens. Tendo encontrado alguns conjuntos de itens no késimo passo, precisamos encontrar em k + 1 passos apenas aqueles conjuntos de itens que
possuem um item a mais que os grandes conjuntos de itens já encontrados. Se um conjunto
de itens é pequeno, sua extensão acrescida de apenas um elemento também é pequena.
Dessa forma, o conjunto fronteira para o próximo passo é o conjunto de itens candidatos
determinados no passo corrente com apenas mais um item. Esta alternativa representa outro
extremo, efetuaremos várias leituras sobre a base de dados.
17
Estas duas abordagens ilustram a questão entre o número de passos e o esforço
desperdiçado a fim de gerar conjunto de itens que na verdade são pequenos.
procedure Largeltemsets
begin
let Large set L = 0;
let Frontier set F = {∅};
while F ≠ 0 do begin
—— make a pass over the database
let Candidate set C=0;
forall database tuples t do
forall itemsets f em F do
if t contains f then begin
let Cf = candidate itemsets that are extensions
of f and contained in t;
forall itemsets cf in Cf do
if Cf ∈ C then
Cf.count = cf.count + 1;
else begin
cf.count = 0;
C = C + cf;
end
end
— consolidate
let F = 0;
forall itemsets c in C do begin
if count(c) / dbsize > minsupport then
L = L + c;
If c should be used as a frontier
in the next pass then
F = F + c;
end
end
Figura 1: Modelo de algoritmo para encontrar os grandes conjuntos de itens.
18
2.1.2 O algoritmo apriori
O algoritmo Apriori, demonstrado em [3], é um dos mais conhecidos para
encontrar grandes conjuntos de itens em bancos de dados de transações. Ele utiliza os
conjuntos de itens de tamanho k para gerar os conjuntos de itens de tamanho (k + 1). O
primeiro passo do algoritmo é encontrar os conjuntos de itens com 1 item. Este conjunto é
denominado L1. O conjunto L1 é usado para gerar L2, que representa os conjuntos de itens
com 2 itens e assim por diante até que nenhum conjunto de itens possa ser gerado.
Para reduzir o numero de conjuntos de itens gerados, o algoritmo utiliza uma
propriedade dos grandes conjuntos de itens. Esta propriedade é baseada na seguinte
observação. Por definição, se um conjunto de itens I não satisfaz a condição de suporte
mínimo, então I não é grande, isto é, P(I) < minsupport. Se um item A é adicionado ao
conjunto de itens I, então o conjunto de itens resultante (I ∪ A) não pode ocorrer mais
freqüentemente que I. Portanto, I ∪ A também não é grande, ou seja, P(I ∪ A) <
minsupport.
O primeiro passo do algoritmo é realizar a contagem dos conjuntos de itens
para encontrar os grandes conjuntos de itens de tamanho unitário. Os passos seguintes,
consistem de duas fases. Primeiro, os conjuntos de itens freqüentes Lk-1, encontrados no
passo anterior (k – 1) são utilizados para gerar os conjuntos de itens potencialmente
grandes, os conjuntos de itens candidatos (Ck). Na seqüência, é realizada uma nova busca
no banco de dados, contando-se o suporte de cada candidato em Ck.
A geração dos conjuntos de itens candidatos utiliza como argumento o conjunto
Lk-1. Isto retorna um super conjunto de itens com todos os conjuntos de itens de tamanho k
acrescidos de um item. Se um conjunto de itens X contém o conjunto de itens Y, dizemos
que X é um super conjunto de Y. O próximo passo é excluir todos os conjuntos de itens c ∈
Ck, tal que os conjuntos de itens de tamanho (k – 1) de c não estejam em Lk-1.
2.1.3 O algoritmo de regras de associação aplicado a tabelas relacionais
Uma abordagem para a extração de regras de associação em tabelas relacionais,
tratando dos atributos quantitativos, foi apresentado em [4]. Os algoritmos vistos até agora
foram desenvolvidos para utilizarem tabelas de transações, encontrando associações entre
valores “1” em uma tabela relacional onde todos os atributos são booleanos. Normalmente
19
as tabelas relacionais existentes nos bancos de dados possuem atributos de vários tipos,
estes atributos podem ser quantitativos ou categóricos, e cada atributo da tabela pode
possuir vários valores distintos. A Tabela 2 apresenta um exemplo de tabela relacional com
os dados de alguns alunos.
Matricula
001
002
003
004
005
Idade
15
16
15
17
16
Média
4,5
5
9
4
8
Aprovado
Não
Sim
Sim
Não
Sim
Tabela 2: Exemplo de tabela relacional
As colunas Idade e Média possuem valores quantitativos com muitos valores
distintos e uma forma de trabalhar com estes atributos é primeiramente dividi-los em
intervalos. A coluna Idade será dividida em dois intervalos: de 10 a 15 e de 16 a 20, e a
coluna Média será dividida nos intervalos: de 0 a 5 e de 5,1 a 10.
A tabela com os atributos quantitativos divididos em intervalos ficará conforme
mostrado na Tabela 3.
Matricula
001
002
003
004
005
Idade
10 –|15
16 –| 20
10 –| 15
16 –| 20
16 –| 20
Média
0 –| 5
0 –| 5
5 –| 10
0 –| 5
5 –| 10
Aprovado
Não
Sim
Sim
Não
Sim
Tabela 3: Distribuição dos dados quantitativos em intervalos.
Podemos transformar uma tabela relacional qualquer em uma tabela com
valores booleanos. O valor de um atributo booleano corresponde ao par (atributo1, valor1)
e será “1” se o atributo1 tiver o valor1 no registro original e “0” caso contrário. Então
poderemos utilizar qualquer algoritmo de regras de associação. A tabela transformada
ficará da seguinte forma:
20
Matrícula
10 < Idade ≤ 15
15 < Idade ≤ 20
0 < Média ≤ 5
5 < Média ≤ 10
Aprovado = Sim
Aprovado = Não
001
1
0
1
0
0
1
002
0
1
1
0
1
0
003
1
0
0
1
1
0
004
0
1
1
0
0
1
005
0
1
0
1
1
0
Tabela 4: Tabela relacional transformada em tabela de atributos booleanos.
Há dois problemas com este tratamento simplificado quando se trata de
atributos quantitativos, a criação de intervalos altera o suporte e a confiança dos valores dos
atributos.
Suporte – Se o tamanho definido para os intervalos de um atributo quantitativo
é pequeno, o suporte para algum intervalo pode ser pequeno, então algumas regras
envolvendo este atributo podem não ser encontradas, porque seus suportes estarão abaixo
do suporte mínimo. Se aumentamos o tamanho dos intervalos, diminuímos a quantidade de
intervalos e aumentamos o suporte de cada um deles.
Confiança – Algumas regras podem ter confiança mínima somente quando um
item nos seus antecedentes consistirem de um valor simples (ou um intervalo pequeno).
Esta perda de informação aumenta de forma diretamente proporcional ao tamanho do
intervalo.
Isto cria um impasse, se os intervalos são grandes, algumas regras podem não
satisfazer o critério de confiança mínima; se são pequenos as regras podem não satisfazer o
critério de suporte mínimo.
Este problema pode ser resolvido introduzindo um novo parâmetro chamado
suporte máximo. Para um determinado atributo quantitativo aumentamos o tamanho do seu
intervalo até que o suporte exceda o suporte máximo. Este parâmetro é usado apenas para
determinar o tamanho do intervalo em que serão divididos os valores do atributo, ele não
será utilizado para determinar se um conjunto de itens é grande ou não.
21
2.2 O problema do item raro.
Usando apenas um valor para o suporte mínimo em todo o banco de dados, o
modelo assume que todos os itens são da mesma natureza e/ou tem a mesma freqüência.
Contudo este caso é raro nas aplicações da vida real. Em muitas aplicações, alguns itens
aparecem muito freqüentemente, enquanto outros aparecem raramente. Se determinarmos
um valor alto para o suporte mínimo, aquelas regras que envolvem itens raros não serão
geradas. Para gerar as regras que contenham tanto itens freqüentes como itens raros, temos
que determinar um valor baixo para o suporte mínimo. Isto pode provocar a geração de um
número muito grande de regras. Este problema é chamado de problema do item raro.
Para solucionar este problema é utilizada uma técnica que permite ao usuário
especificar múltiplos suportes mínimos para refletir as naturezas dos itens e suas variadas
freqüências no banco de dados. Na mineração de regras de associação, diferentes regras
precisam satisfazer diferentes suportes mínimos dependendo de quais itens estejam
presentes.[13]
No modelo utilizado neste caso o conceito de regras de associação continua o
mesmo, mas a definição de suporte não. O suporte de um conjunto de itens é expresso em
termos do MIS (minimum item support) dos seus itens. Isto é, cada item no banco de dados
pode ter um suporte especificado pelo usuário. O suporte do conjunto de itens será o menor
MIS de seus itens. Estabelecendo diferentes valores para MIS de diferentes itens, o usuário
efetivamente expressa diferentes requerimentos para o suporte das regras.
Este modelo é mais flexível que o clássico e permite a geração de regras que
incluem os itens raros, sem produzir o grande número de regras que não são interessantes.
2.3 Grau de interesse de uma regra
Uma das questões mais importante da extração de regras de associação é o grau
de interesse das regras. Isto ocorre porque na maioria das situações um grande número de
regras são geradas, mas nem todas são úteis e/ou interessantes. Identificar as regras
interessantes entre todas as que são geradas é difícil para o usuário. Ele precisa de um
procedimento automatizado para ajudá-lo.
22
Estabelecer se uma regra é interessante é difícil, porque diferentes pessoas têm
interesses diferentes e até a mesma pessoa pode mudar de interesse em diferentes períodos
de tempo.
O grau de interesse de um regra pode ser estabelecido usando medidas objetivas
e subjetivas. As medidas objetivas envolvem a análise da estrutura da regra e a
significância estatística, que no caso das regras de associação incluem o suporte e a
confiança. Contudo, verifica-se que estas medidas são insuficientes para determinar se uma
regra é interessante ou não e medidas subjetivas também são necessárias.
As duas principais medidas subjetivas são:
1. Regras inesperadas: neste caso as regras são consideradas inesperadas se são
desconhecidas do usuário ou contradizem o conhecimento que ele possui.
2. Regras úteis: as regras são úteis se o usuário pode tomar alguma decisão baseado
nelas para seu benefício.
Embora as duas medidas sejam importantes, a utilidade é um conceito chave na
maioria das aplicações porque regras úteis permitem ao usuário melhorar o seu trabalho
tomando algumas ações específicas em resposta ao conhecimento descoberto. Contudo
utilidade é um conceito evasivo porque não é possível conhecer o espaço de todas as regras
e as ações ligadas a elas. Um regra pode ser inesperada independentemente de ser útil. As
regras interessantes podem ser classificadas em três categorias:
1. Regras que são inesperadas e úteis.
2. Regras que são inesperadas, mas não são úteis.
3. Regras que são úteis, porém esperadas.
23
3. INTEGRAÇÃO DO ALGORITMO DE REGRAS DE ASSOCIAÇÃO E BANCOS
DE DADOS RELACIONAIS
A promessa dos sistemas de apoio à decisão é explorar os dados corporativos
para proporcionar vantagens competitivas. Contudo, mesmo depois que um DataWarehouse
está criado, é freqüentemente difícil analisar e assimilar os dados. As ferramentas OLAP
foram um importante passo neste sentido, permitindo a visão multidimensional dos dados,
utilizando sofisticadas ferramentas para exibir e consultar os dados.
A mineração de dados promete um grande salto em relação às ferramentas
OLAP, porque descobre automaticamente regras interessantes. Tal funcionalidade será
muito útil em bancos de dados corporativos, que são caracterizados por uma grande
quantidade de dados, e a descoberta das regras de associação será uma das técnicas
utilizada.
3.1 Fontes de dados usadas pelos algoritmos
As aplicações que extraem as regras de associação podem trabalhar com dois
tipos de fontes de dados, cada uma com suas próprias vantagens: arquivos isolados e
SGBDs.
As aplicações têm usado freqüentemente arquivos isolados como fonte de
dados. Mesmo quando os dados operacionais estão armazenados em um SGBD, vários
sistemas extraem parte das informações para usarem no processo de mineração, alguns
deles trabalhando com dados que cabem na memória principal, este fato limita a quantidade
de informação a ser utilizada. Contudo estas implementações oferecem alguma vantagem
relacionada a resultados de desempenho, quando a quantidade de dados não é grande e cabe
toda na memória principal do computador.
A tecnologia de banco de dados tem sido utilizada com sucesso no
processamento de dados de negócios. Empresas têm coletado uma grande quantidade de
informações, utilizando um SGBD para gerenciá-las. Conseqüentemente, é desejável que
tenhamos uma forma fácil e direta de utilizar a mineração de dados aproveitando as
vantagens oferecidas pela tecnologia de banco de dados.
24
3.2 Estrutura do ambiente de Mineração de Dados
Durante muito tempo as pesquisas na área de mineração de dados se
preocuparam com o número de atributos dos dados analisados, e não com a quantidade de
registros. Isto ocorre porque a análise de dados
trabalha com estimativas sobre a
distribuição dos dados. Estas estimativas podem ser determinadas utilizando-se uma
quantidade pequena de dados, no caso uma amostra no lugar do total de dados. Contudo,
trabalhar apenas com uma parte dos dados compromete a precisão das informações obtidas.
Este problema nos leva a duas opções:
1. O desenvolvimento de algoritmos que levem em consideração a utilização de uma
grande quantidade de registros.
2. A restrição do escopo da análise.
Obviamente percebemos que a segunda opção não é interessante, porque é uma
solução que limita as possíveis soluções. Há a necessidade de desenvolver algoritmos de
extração de regras de associação que trabalhem com uma quantidade de dados cada vez
maior e de uma forma rápida e eficiente, faz-se necessário a melhoria da escalabilidade dos
algoritmos.
Os requisitos de escalabilidade levam os algoritmos a se preocuparem com o
fato de os dados não caberem todos na memória principal de uma vez, isto exige que o
algoritmo seja desenvolvido de forma a obter uma boa performance durante a execução.
Neste caso, a tecnologia de SGBD oferece várias funcionalidades que a torna valiosa para a
implementação de aplicações de mineração de dados.
Abaixo mostraremos dois ambientes utilizados para a implementação de
algoritmos de mineração de dados, um fracamente acoplado ao banco de dados e o outro
fortemente acoplado.
3.2.1 Implementação fracamente acoplada.
Neste tipo de implementação, também chamada convencional, os dados e os
algoritmos estão separados. A maioria das atividades de mineração de dados reside fora do
25
controle do SGBD ou os dados não estão armazanados em um Banco de Dados, eles se
encontram em arquivos isolados. Neste tipo de implementação o Banco de Dados serve, na
melhor das hipóteses, como repositório dos dados.
Uma máquina cliente contém a aplicação que é utilizada para a mineração de
dados e os dados armazenados sob um SGBD são lidos linha a linha através de um cursor.
A vantagem desta abordagem é a flexibilidade de programação, visto que o algoritmo de
mineração é implementado completamente no lado da aplicação. Além disso, qualquer
aplicação de mineração de dados pode facilmente passar a utilizar dados sob a gerência de
um SGBD.
Este tipo de implementação provoca um aumento na quantidade de dados que
são trocados entre a aplicação e o SGBD. As redes devem ser usadas desta forma somente
quando a quantidade de dados, a ser minerada, é pequena e a aplicação não é executada
freqüentemente, isto permite que a máquina cliente tenha tempo suficiente para executar a
tarefa sem ultrapassar o limite dos seus recursos e os da rede a qual está conectada.
Em um ambiente como este podem existir várias fontes de dados, como
arquivos isolados e vários bancos de dados, o que o torna mais complexo. Por isso antes de
iniciarmos o processo de mineração há a necessidade de coletar os dados nos respectivos
locais de armazenamento. Por estarem separados, estes dados provavelmente não estarão
integrados e poderão também estar inconsistentes. Neste caso todo o processo de mineração
dos dados englobará uma fase de seleção dos dados, que visa estabelecer quais são as
variáveis importantes para a análise, uma etapa de limpeza dos dados e uma fase de préprocessamento dos dados, a escolha do objetivo do processo, a mineração dos dados
propriamente dita e a interpretação e consolidação do conhecimento descoberto. A fase de
pré-processamento engloba a divisão dos dados quantitativos em intervalos e a estimativa
de valores faltantes.
Outro problema que pode ocorrer em uma implementação como esta é a
utilização de várias aplicações diferentes, cada uma possuindo uma interface diferente. Isto
pode dificultar a utilização de uma aplicação por um usuário que está habituado a usar
outra. Ocorre também uma demora na extração da informação contida nos dados devido a
todos os passos anteriores à extração das regras de associação.
26
3.2.2 Implementação fortemente acoplada
Em uma implementação fortemente acoplada, parte dos algoritmos de
mineração de dados está contida no núcleo do SGBD, através de procedimentos
armazenados e funções definidas pelo usuário. Desta forma, as operações de acesso a
dados, que consomem mais tempo, são implementadas em SQL e executadas no lado
servidor.
A máquina cliente apenas envia a instrução que dará início ao processamento e
fica com a tarefa de visualizar o conhecimento minerado no lado servidor. Neste caso a
aplicação pode se beneficiar das vantagens próprias de um SGBD.
Os SGBDs possibilitam o trabalho com bases de dados grandes, maiores que a
memória principal, uma vez que o SGBD por si só controla o manuseio da informação, a
paginação e o swapping.
Esta implementação permite uma padronização das interfaces dos aplicativos e
se transforma em um ambiente menos complexo que o anterior, e ainda proporciona mais
rapidez na conversão em conhecimento, das regras extraídas.
Outra implementação possível é a chamada caixa preta, aos olhos do usuário, o
algoritmo de mineração é completamente encapsulado dentro do SGBD. A aplicação envia
uma simples requisição solicitando a extração de algum conhecimento e recebe o resultado
final como resposta. Note que se trata também de uma integração fortemente acoplada.
Pode-se até dizer que, do ponto de vista do desempenho, esta é a melhor alternativa, visto
que todos os recursos do SGBD são explorados. A desvantagem potencial é que a
integração é escrava do particular algoritmo de mineração implementado e sabe-se que
nenhum algoritmo de mineração é o mais adequado para todos os conjuntos de dados a
minerar.
3.3 Representação dos Modelos de Mineração em Bancos de Dados
O progresso no desenvolvimento de algoritmos de mineração de dados tem
possibilitado várias implementações de operações eficientemente em grandes bancos de
dados. Isto é certamente uma importante contribuição, mas o principal objetivo é capacitar
os desenvolvedores de aplicações para a construção de modelos de mineração de dados
27
para o uso destes modelos, em uma variedade de tarefas de análise e para compartilhar estes
modelos com outras aplicações.
Dois SGBDs que já oferecem recursos para efetuarmos a Mineração de Dados
são o SQL Server 2000 fornecido pela Microsoft e o Oracle 10g fornecido pela Oracle.
A Microsoft integrou pela primeira vez algoritmos de mineração de dados junto
com banco de dados relacional e aplicações OLAP. O componente do SQL Server 2000
que contem o mecanismo de mineração de dados se chama Analysis Services. Este
componente é mostrado através de uma interface OLE DB DM (OLE DB para Data
Mining).[16]
O OLE DB é uma API, sigla em inglês para interfaces de programação de
aplicativos, padrão desenvolvido pela Microsoft para obter dados de uma grande variedade
de fontes de dados. Uma API é um meio utilizado para comunicação com o SGBD.
A interface OLE DB DM é uma extensão do OLE DB para permitir a
mineração de dados utilizando o SQL Server 2000. Ela permite que as aplicações cliente
examinem e manipulem os modelos de mineração existentes e suas propriedades de uma
forma similar a que é usada para examinar as tabelas. Todos os modelos de mineração são
representados na forma de tabela, com colunas, tipos de dados e metadados, que são
necessários aos algoritmos de mineração de dados.
O mecanismo de mineração de dados está integrado tanto no componente de
serviços de análise do servidor, que inclui também a tecnologia OLAP, quanto no
componente cliente.
O serviço de análise do SQL Server 2000 oferece duas classes de algoritmo: a
classificação e o agrupamento. A classificação utiliza o algoritmo de árvore de decisão e o
algoritmo utilizado no processo de agrupamento é o K-means. A sua principal característica
é agrupar os dados em k grupos, o valor de k é estabelecido pelo usuário.
O produto oferece uma console baseada em uma GUI (interface gráfica de
usuário) completa para administração do modelo de mineração de dados, incluindo a
criação, o treinamento, a possibilidade de percorrer o conteúdo e gerenciar a segurança.
O Oracle Data Mining (OMD) oferece funcionalidades de mineração de dados
embutidas no SGBD da Oracle. A versão em questão é o Oracle Database 10g.
28
O modelo ODM constrói e modela funções que são acessadas através de uma
interface Java ou PL/SQL (APIs) e um cliente de Mineração de Dados. Isto permite uma
infra-estrutura para o desenvolvimento de aplicações que integrem a mineração de dados
com o banco de dados.
O ODM oferece as seguintes implementações:
•
Componentes principais
•
Classificação e regressão
•
Agrupamento
•
Associações
•
Extração de características
•
Mineração de textos
•
Padrões seqüenciais
29
4- IMPLEMENTAÇÃO DE UM ALGORITMO DE REGRAS DE ASSOCIAÇÃO
EM UM SGBD RELACIONAL
Esta implementação tem por objetivo demonstrar a possibilidade de usar um
algoritmo de regra de associação fortemente acoplado a um SGBD, se beneficiando dos
recursos que este sistema oferece, para isto utilizamos o SGBD SQL Server 2000.
Como mostramos anteriormente um algoritmo de regras de associação pode ser
implementado fracamente acoplado ao Banco de Dados, neste caso o algoritmo é executado
fora do SGDB ou a implementação pode ser fortemente acoplada, onde os dados e a
aplicação estão armazenados no núcleo do SGBD. Usamos neste trabalho a segunda
abordagem, o algoritmo foi implementado através de procedimentos armazenados escritos
na linguagem Transact-SQL.
Neste trabalho usamos uma base de dados com 268 transações de clientes de
um mercado, onde os clientes podem escolher entre vários produtos. Cada transação pode
ter um número diferente de itens.
4.1 Pré-processamento
Na maioria das vezes as tabelas relacionais possuem colunas que possuem
valores quantitativos. Se o domínio destas colunas é grande, ocorrerá a geração de um
número muito grande de regras que possuem esta coluna, e poucas ou nenhuma com um
suporte maior que o valor determinado como suporte mínimo. O problema da geração de
regras de associação utilizando tabelas relacionais que possuem colunas quantitativas foi
discutido em [4]. Uma medida necessária é a distribuição dos valores quantitativos em
intervalos, por exemplo a coluna idade pode ser distribuída em faixas etárias.
Entretanto há dois problemas quando criamos intervalos para os valores:
•
O suporte do intervalo aumenta a medida que aumentamos o seu tamanho.
•
A confiança do intervalo diminui quando aumentamos o seu tamanho.
O algoritmo implementado não se preocupa com o processo de criação dos
intervalos para distribuir os dados quantitativos. Este processo é realizado antes da sua
execução, tomando-se o cuidado de definir um tamanho para os intervalos que não acarrete
30
perda de informação, considerando-se as mudanças provocadas no suporte e na confiança
das regras geradas.
4.2 Representação dos dados
Os algoritmos de regras de associação tratam os dados de entrada como se
estivessem contidos em uma tabela de transações que possui apenas valores 0 e 1. Para cada
transação enumera-se os itens que são membros da transação em questão, ou seja os itens
que possuem o valor 1. No caso de uma tabela relacional cada atributo pode possuir valores
diferentes de 0 e 1 e representar vários itens, dependendo da quantidade de valores distintos
que ela possui. Um item é caracterizado pelo par (atributo1, valor1), onde o item1 está
presente quando o atributo1 possui o valor1.
Podemos fazer um mapeamento dos dados de uma tabela relacional e
transformá-la em uma tabela booleana de transações., conforme demonstrado em [4].
Depois de realizada a transformação podemos utilizar qualquer algoritmo conhecido para
extração das regras de associação.
Uma tabela booleana pode, também, ter dois tipos de representação: horizontal
e vertical. Em uma tabela organizada horizontalmente, cada linha possui os itens presentes
nas transações. Na organização vertical cada item é um atributo e os valores são as
transações em que o atributo está presente.
Considerando os dados da Tabela 1 teremos as seguintes tabelas com os seus
dados organizados horizontalmente e verticalmente.
Transação
1
2
3
4
5
6
Itens
ABDE
BCE
ABDE
ABCE
ABCDE
BCD
Figura 2: Dados organizados horizontalmente
31
A
1
3
4
5
B
1
2
3
4
5
6
C
2
4
5
6
D
1
3
5
6
E
1
2
3
4
5
Figura 3: Dados organizados verticalmente
Utilizamos, neste trabalho, os dados organizados horizontalmente.
4.3 Geração dos grandes conjuntos de itens
Os grandes conjuntos de itens são armazenados no banco de dados em uma
tabela. Os grandes conjuntos de itens são encontrados da seguinte forma:
1 – Encontramos todos os conjunto de itens de tamanho K. Estes conjuntos são
chamados de conjuntos candidatos.
2 – Armazenamos em uma tabela os conjuntos de itens candidatos que possuem
suporte maior que o suporte mínimo especificado os demais são excluídos.
3 – Fazemos K = K + 1 e voltamos ao passo 1.
Inicialmente K = 1.
Em [3] encontramos um exemplo de instrução em SQL para gerar conjuntos de
itens candidatos, conforme mostrado na Figura 4.
Para geração dos grandes conjuntos de itens criamos duas tabela. Uma para
armazenar os conjuntos de itens candidatos e outra para armazenar os grandes conjuntos de
itens, conforme mostrados nas Figuras 5 e 6.
32
Insert into Ck
Select p.item1, p.item2, ..., p.itemk-1, q.itemk-1
From Lk-1 p, Lk-1 q
Where p.item1 = q.item1, ...p.itemk-2 = q.itemk-2,
p.itemk-1 < q.itemk-1
Figura 4: Exemplo de comando para gerar conjuntos de itens candidatos
CREATE TABLE [dbo].[CANDIDATOS] (
[ITENS] [varchar] (1000) NULL ,
[ULTIMA] [varchar] (1000) NULL ,
[TAMANHO] [numeric](18, 0) NULL ,
[LINHA] [int] NULL
) ON [PRIMARY]
GO
Figura 5: Tabela de conjunto de itens candidatos
A tabela que armazena os conjuntos de itens candidatos se chama
CANDIDATOS. A coluna ITENS recebe o conjunto de itens, se houver mais de um item
eles estarão separados por vírgula. A coluna ULTIMA armazena o último item do conjunto
de itens. A coluna TAMANHO recebe a quantidade de itens que estão presentes no
conjunto de itens. As linhas em que os conjuntos de itens estão presentes são armazenadas
na coluna LINHA.
Os grandes conjuntos de itens são armazenados na tabela chamada ITEMSET,
que possui as colunas: ITENS, ULTIMA e TAMANHO como a tabela CANDIDATOS.
Além destas colunas esta tabela possui uma coluna SUPORTE que armazena o suporte do
conjunto de itens. Nesta tabela só estarão gravados os conjuntos de itens que possuem
suporte maior que o suporte mínimo estabelecido.
33
CREATE TABLE [dbo].[ITEMSET] (
[ITENS] [varchar] (1000) NULL ,
[SUPORTE] [numeric](18, 0) NULL ,
[ULTIMA] [varchar] (1000) NULL ,
[TAMANHO] [numeric](18, 0) NULL
) ON [PRIMARY]
GO
Figura 6: Tabela de grandes conjuntos de itens
Depois de gerados todos os grandes conjuntos de itens, são excluídos da tabela
CANDIDATOS todos os conjuntos que não foram considerados grandes.
4.4 Poda
Um algoritmo para geração de conjuntos de itens pode gerar uma quantidade
muito grande de conjuntos, o que acarreta a geração de muitas regras. Por este motivo
precisamos encontrar formas de limitar a quantidade de conjuntos que serão gerados. O
programa implementado oferece duas formas de limitar a quantidade de regras geradas.
A primeira é através do tamanho máximo que um conjunto de itens pode ter.
Este parâmetro k também reduz o tempo de processamento, porque depois de gerar os
conjuntos de itens de tamanho k, o programa encerra a tarefa de gerar novos itemsets.
A segunda é através da comparação do suporte dos conjuntos de itens com o
valor do parâmetro suporte mínimo. Se o valor do suporte do conjunto de itens for menor
que o suporte mínimo o conjunto de itens é desprezado.
4.5 Extração das regras de associação
A forma de se obter as regras baseadas nos grandes conjuntos de itens foi
mostrada em [2]. Seja I um conjunto de itens com N itens, as regras formadas a partir dele
são do tipo X → Y, onde X ∈ I, Y ∈ I e X ∩ Y = ∅. O antecedente X da regra é formado
34
por qualquer subconjunto de I com tamanho máximo igual a N – 1 e o conseqüente é
formado pelos elementos de I que não pertencem a X.
Todos os grandes conjuntos de itens estão armazenados em uma tabela do
banco de dados com os respectivos suportes, a tabela ITEMSET, então para cada conjunto
de itens de tamanho N, geramos todas as combinações possíveis contendo 1 item, depois
todas com 2 itens até gerarmos todas as combinações com N – 1 ítens. Estas combinações
são armazenadas na tabela REGRA, mostrada na Figura 7:
CREATE TABLE [dbo].[REGRAS] (
[ANTECEDENTE] [varchar] (450) NULL ,
[CONSEQUENTE] [varchar] (450) NULL ,
[SUPORTE] [numeric](18, 0) NULL ,
[CONFIANCA] [numeric](18, 0) NULL
)
GO
Figura 7: Tabela com as regras geradas.
A tabela que contém as regras se chama REGRAS. Possui as colunas chamadas
ANTECEDENTE e CONSEQUENTE. Significa que o valor contido na coluna
ANTECEDENTE implica no valor do CONSEQUENTE. A coluna SUPORTE contém o
suporte da regra. A coluna CONFIANCA armazena a confiança da regra.
Seja a regra ANTECEDENTE → CONSEQUENTE, então a confiança desta
regra é dada por P(CONSEQUENTE/ANTECEDENTE), ou seja, a probabilidade do
CONSEQUENTE estar presente na regra dado que o ANTECEDENTE está presente.
Uma vez que os grandes conjuntos de itens foram encontrados, é fácil encontrar
regras interessantes. Isto pode ser feito utilizando-se a seguinte equação para calcular a
confiança da regra, onde a probabilidade condicional é expressa em termos do suporte do
conjunto de itens:
35
CONFIANCA(ANTECEDENTE → CONSEQUENTE) =
= P(CONSEQUENTE / ANTECEDENTE) =
= SUPORTE (ANTECEDENTE ∪ CONSEQUENTE) / SUPORTE (ANTECEDENTE)
Figura 8: Cálculo da confiança das regras
No nosso exemplo o suporte de (ANTECEDENTE ∪ CONSEQUENTE) é
igual ao suporte da regra, que já está armazenado na tabela ITEMSET e o mesmo ocorre
com o suporte do ANTECEDENTE.
4.6 Determinação do grau de interesse de uma regra
A determinação do grau de interesse de uma regra de associação é importante
na mineração de dados. Isto significa encontrar quais regras são interessantes para o
usuário. Um algoritmo de extração de regras de associação é capaz de gerar uma
quantidade muito grande de regras e se torna difícil determinar quais regras são
interessantes através de um procedimento manual e sabemos que é necessário criar um
procedimento automatizado.
Sabemos que o grau de interesse de uma regra pode ser medido utilizando-se
critérios objetivos e critérios subjetivos.
Antes de tratarmos dos critérios para determinação do grau de interesse de uma
regra, vamos introduzir o conceito de Regras de Associação Generalizada, que é um
modelo mais geral que o apresentado em [2].
Segundo Srikant et al [21], a mineração de regras de associação generalizadas é
definida como uma implicação da forma X → Y, onde X ⊂ I, Y ⊂ I, X ∩ Y = ∅, e
nenhum item em Y é ancestral de qualquer item de X.
36
4.6.1 A utilização de critérios objetivos
O suporte de uma regra de associação é a probabilidade de ocorrer o
conseqüente dado que ocorreu o antecedente na mesma transação. As regras extraídas estão
armazenadas na tabela REGRAS, da seguinte forma:
ANTECEDENTE
CONSEQÜENTE
SUPORTE
CONFIANÇA
Figura 9: Estrutura da tabela REGRAS
A maioria das consultas efetuadas durante a fase de cálculo do suporte
envolvem operações de agrupamento (GROUP BY) , conforme mostrado na Figura 10.
SELECT ITENS , COUNT(*)
FROM CANDIDATOS
GROUP BY ITENS
Figura 10: Consulta utilizada para calcular o suporte dos conjuntos de itens
Os conjuntos de itens, depois de calculados os suportes, são gravados na tabela
ITEMSET, caso tenham o suporte maior que o valor do suporte mínimo estabelecido. A
tabela ITEMSET armazena os grandes conjuntos de itens, que serão utilizados para gerar as
regras de associação.
O valor da confiança é a probabilidade de ocorrência do antecedente nas
transações que também possuem o conseqüente da regra.
Caso a regra possua o suporte maior que o parâmetro suporte mínimo e
confiança maior que o parâmetro confiança mínima dizemos que se trata de uma regra
interessante. Contudo esta conclusão se baseia apenas em critérios objetivos e este critérios
nem sempre são suficientes para a determinação do grau de interesse de uma regra.
37
4.6.2 A Utilização de critérios subjetivos
A maioria das abordagens para encontrar regras de associação subjetivamente
pede ao usuário para especificar quais tipos de regras são interessantes ou não. O
conhecimento do usuário possui diferentes graus de precisão que são divididos da seguinte
forma:
•
Impressões gerais,
•
Conceitos razoavelmente precisos, e
•
Conhecimento preciso.
Os dois primeiros tipos representam conhecimento vago a respeito dos dados e
o último o conhecimento preciso. Esta divisão é importante porque o ser humano possui
diferentes granularidades de conhecimento.[12]
É importante permitir a especificação de diferentes tipos de conhecimento. Isto
não determina apenas como podemos usar o conhecimento, mas também se podemos usar
todo o conhecimento do usuário. Por exemplo, se um sistema só permite a especificação de
conhecimento preciso, um usuário que só possui conhecimento vago do assunto não poderá
usá-lo.
O nosso trabalho propõe usar a idéia de classe hierárquica , que é o mesmo
usado pelo IAS – Interestingness Analysis System [11] e nas regras de associação
generalizadas [20]. Representamos a hierarquia da seguinte forma:
{uva, pera, maçã} ⊂ Frutas ⊂ Itens de Alimentação
{leite, queijo, manteiga} ⊂ Laticínios ⊂ Itens de Alimentação
{vaca, porco, frango} ⊂ Carnes ⊂ Itens de Alimentação
Frutas, Laticínios, Carne e Itens de Alimentação são classes e uva, pera, maçã,
leite, queijo, manteiga, vaca, porco e frango são itens. Note que nas regras de associação
generalizadas, as classes também podem ser tratadas como itens.
Agora discutiremos como o usuário pode informar os três tipos de
conhecimento.
38
1 - Impressões Gerais: representa que o usuário possui um conhecimento vago
sobre existência de associações entre algumas classes de itens, mas ele não sabe como estes
itens estão associados. Neste caso o usuário informa as classes ou os itens que ele considera
que estão associados, qualquer regra que possua estes itens será considerada em
conformidade com a especificação, e inesperada, tendo em vista que
baseou-se em
impressões gerais que o usuário possui em relação aos dados.
2 – Conceitos razoavelmente precisos: representa os conceitos que o usuário
possui de que pode haver associações entre algumas classes de itens, e ele sabe a direção
das associações, ou seja, ele especifica quais itens fazem parte do antecedente e do
conseqüente das regras interessantes.
3 – Conhecimento preciso: neste caso o usuário acredita em uma determinada
associação. Ele especifica os itens que fazem parte do antecedente e do conseqüente da
regra interessante. Ao contrário dos dois tipos anteriores, neste caso é necessário informar o
suporte e a confiança. Se a regra extraída tiver suporte ou confiança menor que o valor
especificado, a regra é considerada menos em conformidade com a especificação e mais
inesperada, porque possui os valores de suporte e confiança um pouco diferente dos
valores especificados.
A tabela REGRAS permite um pesquisa rápida quando o usuário possui
conhecimento razoavelmente preciso e conhecimento preciso. De posse do antecedente e do
conseqüente informado, pesquisamos a tabela REGRAS e obtemos as regras. No caso de o
usuário possuir apenas impressões gerais sobre os dados, serão informados os itens que
compõem a regra, sem especificar o antecedente e o conseqüente. Para permitir esta
pesquisa alteramos a estrutura da tabela REGRAS, incluindo uma coluna chamada ITENS,
que contem os itens que estão presentes na regra, independente de estarem no antecedente
ou no conseqüente da regra. Os itens contidos na coluna ITENS estarão em ordem
alfabética.
39
5- AVALIAÇÃO DO ALGORITMO IMPLEMENTADO NO SGBD
Esta seção tem por objetivo avaliar o desempenho do algoritmo quanto ao
tempo de execução e a capacidade de gerar regras de associação interessantes. O
desempenho do algoritmo será comparado ao CBA (Classification Based in Associations).
Para esta avaliação utilizamos um arquivo de transações de um mercado. Onde
cada transação corresponde a compra efetuada por um cliente. As transações possuem 80
itens e o arquivo contém o registro de 268 transações.
Os clientes não compram os mesmos itens, abaixo temos uma tabela que mostra
a quantidade de itens que foram comprados juntos e o número de transações que possuem
esta determinada quantidade de itens.
Qtd de itens
2
3
4
5
6
7
8
9
10
11
15
19
28
Total
Qtd de Transações
140
33
50
5
6
8
9
2
4
2
4
2
3
268
Figura 11: Quantidade de transações por quantidade de itens.
A figura 11 nos mostra a quantidade de transações no banco de dados com a
respectiva quantidade de itens. Por exemplo, existem 140 transações com 2 itens.
5.1 Geração dos grandes conjuntos de itens.
As transações presentes no banco de dados são compostas por itens do estoque
do mercado e para cada transação podemos obter os seus subconjuntos. Cada subconjunto
40
encontrado é chamado de conjunto de itens e os que possuem suporte maior que o valor
determinado como suporte mínimo, são chamados de grandes conjuntos de itens.
A quantidade de conjuntos de itens que podem ser gerados com os itens de uma
transação pode ser muito grande. Este valor é dado pela fórmula:
N
Q=∑
n=1
N!____
(n!) (N – n)!
Onde:
Q = quantidade de conjuntos de itens que podem ser formados
N = quantidade de itens da transação
n = quantidade de itens no conjunto de itens
Por exemplo: As transações que possuem 28 itens podem gerar 268.435.455
conjuntos de itens segundo a tabela mostrada no Anexo II.
O gráfico da Figura 12 mostra a quantidade de conjuntos de itens que podem
ser gerados a partir de uma transação com 28 itens. O eixo das abscissas contém a
quantidade de itens presentes no conjunto de itens gerado e o eixo das ordenadas contém a
quantidade de conjuntos de itens gerados.
Para a transação em questão podem ser gerados 28 conjuntos de itens com um
item e um único conjunto com 28 itens. A quantidade de conjuntos de itens gerados
aumenta exponencialmente até chegarmos aos conjuntos de itens com 14 itens, depois
desse valor a quantidade vai diminuindo. Todos estes conjuntos de itens seriam gerados se
determinarmos o valor 0 para o suporte mínimo.
O SQL Server 2000 mantém uma área chamada buffer cache de onde ele lê
páginas de dados que precisam ser recuperados. Os comandos INSERT, UPDATE e
DELETE não produzem os seus resultados diretamente no disco, em vez disso, as
modificações são feitas na cópia dos dados existente no buffer cache. As modificações não
são gravadas em disco até que ocorra um Checkpoint ou a modificação precise ser gravada
em disco para que o buffer possa ser usado para carregar outra página. Checkpoint é o
momento em que o SQL Server 2000 grava em disco os dados que estão no buffer cache.
[7] [9].
41
Qtd de conjuntos de itens gerados
45000000
40000000
Qtd de conjuntos gerados
35000000
30000000
25000000
20000000
15000000
10000000
5000000
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Qtd de itens
Figura 12: Quantidade de conjuntos de itens gerados
O intervalo entre os Checkpoints é inversamente proporcional a quantidade de
modificações efetuadas no banco de dados, significa que quanto mais inclusões, alterações
e exclusões forem efetuadas, menor é o intervalo de tempo em que ocorrerão Checkpoints.
Cada conjunto de itens gerado é inserido na tabela CANDIDATOS e na tabela
ITEMSET, caso se trate de um grande conjunto de itens. Se a quantidade de registros
gravados for muito grande ocorrerá um Checkpoint e isso provoca um Overherd na
aplicação, porque ela é interrompida até que termine a gravação em disco dos dados que
estão no buffer cache.
Percebemos que a quantidade de conjuntos de itens gerados influencia na
performance da aplicação, que pode ficar mais lenta se ocorrerem muitos Checkpoints.
42
A quantidade de conjuntos de itens que são gerados diminui a medida que
aumentamos o valor do suporte mínimo.
5.2 Limitação da quantidade de conjuntos de itens gerados
Como pode ser observado, a geração de conjuntos de itens é um processo que
pode resultar na inclusão de muitos registros nas tabela, e isto provoca a ocorrência de um
Checkpoint. É preciso encontrar uma forma de limitar a quantidade de conjuntos de itens
gerados.
5.2.1 Utilizando o suporte mínimo
Os conjuntos de itens possuem uma propriedade que é utilizada pelo algoritmo
a-priori para limitar a quantidade de conjuntos gerados. A propriedade diz que: se um
conjunto de itens C não é grande, qualquer outro conjunto de itens que contenha C não será
grande também. Baseado nesta propriedade, encontramos todos os conjuntos de itens com
um item e calculamos os seus suportes, os conjuntos que tiverem suporte menor que o
suporte mínimo determinado são descartados.
As transações do nosso exemplo contém 80 itens e a tabela do Anexo I mostra
estes itens e seus respectivos suportes.
Os conjuntos de itens que contêm um item apresentam suporte entre 1 e 49. De
todos estes conjuntos de itens serão considerados grandes aqueles que possuirem suporte
maior que o suporte mínimo determinado.
A determinação do suporte mínimo é importante porque pode limitar a
quantidade de conjuntos de itens com K itens, que participarão na formação dos conjuntos
de itens de tamanho K + 1. Por exemplo, se o valor do suporte mínimo for zero, todos os
itens serão usados para gerar os conjuntos de itens candidatos de tamanho dois, se o suporte
mínimo for dez, trinta e sete conjuntos de itens serão desprezados. No primeiro caso
usaremos 80 conjuntos de itens para gerar os conjuntos candidatos de tamanho dois e no
segundo caso serão 44 conjuntos. Nos conjuntos candidatos aparecerão os itens que estão
nos grandes conjuntos de itens de tamanho um, combinados dois a dois, sem repetição. A
figura 13 mostra a quantidade de conjuntos candidatos de tamanho dois que são gerados
para cada um dos suporte mínimos determinados.
43
Suporte
mínimo
0
5
10
15
20
25
30
35
40
45
50
Quantidade de conjuntos de
tamanho 2 gerados
3160
1378
946
253
78
36
10
3
3
3
0
Figura 13: Quantidade de conjuntos gerados em função do suporte mínimo
Verificamos que a quantidade de conjuntos de itens gerados diminui a medida
aumentamos o valor do suporte mínimo. Este valor deve ser bem dimensionado, pois é um
dos critérios objetivos para determinar o grau de interesse das regras que serão extraídas no
final do processo. Se for escolhido um valor alto deixará de fora as regras que possuem
itens raros.
5.2.2 Utilizando o tamanho máximo dos conjuntos de itens.
No nosso exemplo existem transações que possuem de dois a vinte e oito itens,
por isso os menores conjuntos de itens terão um item e os maiores vinte e oito. Para
verificarmos a influência do tamanho dos conjuntos de itens na geração dos grandes
conjuntos de itens fixamos o valor do suporte mínimo em 2%, o que corresponde a
aproximadamente 6 transações, e verificamos o suporte dos conjuntos de itens gerados.
A tabela do Anexo III nos mostra o total de conjuntos de itens gerados
agrupados pelo suporte. Com base nestes valores verificamos que o suporte diminui quando
aumentamos o tamanho de um conjunto de itens. Na Figura 14 mostramos o maior suporte
que possuem os conjuntos de itens de acordo com a quantidade de itens que eles possuem.
44
Quantidade de itens
Máximo Suporte
1
2
3
4
5
6
7
8
49
21
8
6
6
6
6
6
Figura 14: Máximo suporte dos grandes conjuntos de itens
Fixando o suporte mínimo em 2% produzimos conjuntos de itens com no
máximo 8 itens, acima desse valor os conjuntos de itens gerados não satisfazem o critério
de suporte mínimo.
Na figura 15 mostramos o maior conjunto de itens que pode ser gerado com
suporte mínimo variando de 2% a 10%.
Suporte Mínimo (%) Tamanho do maior conjunto de itens
2
8
3
2
4
2
5
2
6
2
7
2
8
1
9
1
10
1
Figura 15: Maiores conjuntos de itens gerados de acordo com o suporte mínimo
Verificamos que os grandes conjuntos de itens terão no máximo 8 itens, se o
suporte mínimo for 2% e a partir de 8% eles são compostos de apenas 1 item.
A limitação da quantidade máxima de itens que um grande conjunto de itens
pode ter, provoca a limitação, também, do número de passos que o programa precisa
executar para gerá-los. Esta medida melhora a performance do aplicativo, quando
45
utilizamos valores muito baixos para o suporte mínimo, além de produzir regras mais fáceis
de serem analisadas, por conterem uma quantidade pequena de itens.
5.3 Avaliação do grau de interesse das regras extraídas
Depois que obtemos os grandes conjuntos de itens podemos gerar as regras de
associação entre os dados. Como são geradas muitas regras e algumas não são
interessantes, implementamos alguns procedimentos automatizados para ajudar a identificar
as regras consideradas interessantes.
5.3.1 Regras interessantes segundo critérios objetivos
Como vimos anteriormente, os critérios objetivos são o suporte e a confiança da
regra. Inicialmente utilizamos o parâmetro suporte mínimo para limitar a quantidade de
conjuntos de itens que são gerados. Os conjuntos de itens, que possuem suporte menor que
o valor do parâmetro, são descartados porque não são considerados interessantes.
Do mesmo modo que fizemos com o suporte, utilizamos vários valores para a
confiança das regras e avaliamos os resultados obtidos. As regras que não possuem
confiança maior que a confiança mínima são descartadas, pois não são consideradas
interessantes.
Os critérios objetivos são facilmente implementados em um programa de
computador e com sua utilização podemos extrair regras interessantes sem ter nenhum
conhecimento sobre os dados ou sobre o problema que estiver sendo analisado, basta ter
acesso aos dados e conhecer os conceitos de suporte e confiança das regras. Contudo estes
critérios podem produzir muitas regras que não são consideradas interessantes pelo usuário.
5.3.2 Regras interessantes segundo critérios subjetivos
Os critérios subjetivos são obtidos de pessoas que possuem conhecimento
prévio dos dados e do problema que está sendo analisado. Estes critérios podem ser
utilizados antes ou depois da extração das regras de associação. Chamaremos a utilização
dos critérios subjetivos antes da extração das regras de pré-processamento e de pósprocessamento a sua utilização depois de extraídas as regras.
46
Durante o pré-processamento o usuário pode indicar alguns itens que não
devem fazer parte das regras ou a quantidade máxima de itens que as regras podem ter. Na
fase de pós-processamento o usuário baseia-se no conhecimento que possui sobre o
problema em questão.
5.3.2.1 Determinando os itens que não devem fazer parte das regras
Como mostramos anteriormente neste caso o usuário exclui alguns itens da
análise. Este procedimento pode representar uma melhora na performance do programa,
porque diminui a quantidade de conjuntos de itens gerados. Contudo não ocorre nenhuma
alteração nos resultados se o usuário decidir excluir algum item que possua suporte menor
que o suporte mínimo determinado.
Na tabela do anexo I, temos todos os itens que estão presentes nas transações e
seus respectivos suportes. O usuário pode determinas alguns itens dessa relação para serem
excluídos das regras.
Esta medida representa um ganho de velocidade de processamento, porque
diminui a quantidade de conjuntos de itens gerados, e conseqüentemente as inclusões,
alterações e exclusões de registros dentos das tabelas do banco de dados, reduzindo a
quantidade de Checkpoints.
5.3.2.2 Determinando a quantidade máxima de itens presentes nas regras
Geralmente é dificil analisar regras com mais de 6 itens, por isso a limitação da
quantidade de itens das regras é um procedimento importante, porque evita a geração de
regras com muitos itens e ainda otimiza a execução do programa.
Conforme mostrado na Figura 14, percebemos que o suporte dos conjuntos de
itens vai diminuindo em função do aumento da quantidade de itens presentes neles. Na
Figura 16 mostramos um gráfico em que mostra o maior suporte dos conjuntos de dados
com uma determinada quantidade de itens, utilizando como suporte mínimo 2%.
Para os conjuntos de itens com 1 item o maior suporte é 49 e para os conjuntos
de itens de tamanho 8 é 6.
47
Podemos perceber que o suporte dos conjuntos de itens vai diminuindo a
medida que a quantidade de itens vai aumentando. Segundo o critério de suporte os
conjuntos de itens vão se tornando menos interessantes.
60
50
40
30
20
10
0
1
2
3
4
5
6
7
8
9
Figura 16: Gráfico de tamanho dos conjuntos de itens x suporte
No eixo das abscissas encontram-se os tamanhos dos conjuntos de itens e no
eixo das ordenadas o maior valor do suporte.
5.3.2.3 Utilizando as impressões gerais do usuário
Neste caso o usuário sabe que alguns itens estão associados, mas não sabe
quem é o antecedente ou o conseqüente da regra. É necessário selecionar todas as regras
que contenham os itens que o usuário informou. Para cada regra é necessário informar
todos os itens que fazem parte dela, por exemplo, o usuário informa que existem as
seguintes regras e quais itens estão contidos nelas:
Regra 1: Composta pelos itens: White bread, Salty Biscuits e Car mats
Regra 2: Composta pelos itens: Vodka e Sekt
Regra 3: Composta pelos itens: Champagne, Vodka e Lemonade
48
Para obtenção das regras interessantes segundo este critério não é necessário
informar o suporte mínimo, porque o conhecimento que se tem é vago.
As regras interessantes nesse caso podem ser obtidas através de um comando
SQL:
SELECT * FROM REGRAS
WHERE ITENS = ‘Car mats, Salty Biscuits, White bread’
A coluna ITENS contém os itens que fazem parte da regra independente de
estarem no antecedente ou no conseqüente. O itens informados pelo usuário devem escritos
em ordem alfabética e separados por vírgulas. Neste exemplo podemos verificar se a regra
1 é interessante ou não, segundo os critérios do usuário.
5.2.3.4 Utilizando o conhecimento razoavelmente preciso do usuário
Conhecimento razoavelmente preciso do usuário significa que além de
conhecer os itens que fazem parte das regras interessantes, o usuário também sabe a direção
da associação existente entre eles, ou seja, ele sabe qual(is) item(ns) faz(em) parte do
antecedente e do conseqüente das regras.
Utilizando as mesmas regras do item anterior poderíamos ter:
Regra 1: White bread, Salty Biscuits → Car mats
Regra 2: Vodka → Sekt
Regra 3: Champagne → Vodka, Lemonade
Neste caso também não é necessário informar o suporte mínimo das regras.
Para verificarmos o grau de interesse da Regra 2, utilizamos o seguinte comando SQL:
SELECT * FROM REGRAS
WHERE ANTECEDENTE = ‘Vodka’
AND CONSEQUENTE = ‘Sekt’
49
5.2.3.5 Utilizando o conhecimento preciso do usuário
No momento de definir este critério o usuário possui um conhecimento preciso
sobre o problema analisado, ele sabe qual(os) item(ns) faz(em) parte das regras e dos seus
respectivos antecedentes e conseqüentes. A definição deste critério parece com o anterior,
porém é necessário também que o usuário defina o suporte e a confiança mínima das regras
que estão sendo informadas.
Neste caso podemos informar as mesmas regras do item anterior, acrescentando
os valores do suporte e da confiança da regra.
Regra 1: White bread, Salty Biscuits → Car mats (2%, 50%)
Regra 2: Vodka → Sekt (5%, 68%)
Regra 3: Champagne → Vodka, Lemonade (6%, 45%)
Usaremos a Regra 2 também neste exemplo para medirmos o seu grau de
interesse. Escrevemos o seguinte comando SQL:
SELECT * FROM REGRAS
WHERE ANTECEDENTE = ‘Vodka’
AND CONSEQUENTE = ‘Sekt’
AND SUPORTE >= 5
AND CONFIANCA >= 68
Neste caso usamos o sinal >= porque se a regra tiver suporte e confiança
maiores que os valores informados pelo usuário não significa que as regras não são
interessantes, pelo contrário, o seu grau de interesse é maior. Contudo se o suporte ou a
confiança da regra for menor que o valor informado ela será considerada não interessante.
5.3 A extração de regras que possuem itens raros
Uma das soluções propostas para se extrair regras que contenham os itens raros
é a utilização de mais de um valor para o suporte mínimo. O nosso algoritmo só utiliza um
único valor para o suporte mínimo.
50
Para encontrarmos regras que contêm os itens raros definimos os parâmetros
suporte e confiança mínima com o valor zero. Esta medida contudo provoca overhead,
porque provoca a inclusão de muitos registros nas tabelas do banco de dados e a ocorrência
de vários Checkpoints.
A solução utilizada foi determinar um valor para a quantidade máxima de itens
que as regras podem possuir. Este valor foi aumentado até atingir valores que ainda
proporcionaram uma performance satisfatória ao programa.
5.4 Avaliação dos resultados obtidos
Para avaliarmos os resultados obtidos fizemos uma comparação com os
resultados obtidos utilizando-se uma aplicação fracamente acoplada. A aplicação escolhida
foi o CBA (Classification Based in Associations), para a geração das regras de associação e
o IAS (IAS – Interestingness Analysis System) para encontrar regras interessantes segundo
os critérios subjetivos.
O CBA é utilizado para a extração das regras de associação. Utiliza uma
implementação fracamente acoplada, lendo os dados de um arquivo isolado. A aplicação
fortemente acoplada mostrada neste trabalho, apresenta um desempenho semelhante ao do
CBA, quando está extraindo as regras de associação, todas as vezes em que não ocorreu
Checkpoint.
Como dissemos antes, o Checkpoint ocorre quando é realizado um determinado
número de inclusões, alterações ou exclusões nas tabelas. Há várias formas de aumentar o
intervalo entre os Checkpoints [7] [9]. Contudo todas as medidas apenas retardam a sua
ocorrência e aumenta a quantidade de dados que tem que ser transferida do Buffer Cache
para o disco e o tempo necessário para realizar esta tarefa. Por isso a melhor opção, para se
obter uma boa performance é a geração da menor quantidade possível de grandes conjuntos
de itens.
O grau de interesse de uma regra segundo critérios subjetivos, pode ser obtido
utilizando os comandos SQL mostrados anteriormente, ou armazenando-se as informações
fornecidas pelo usuário e criando um procedimento armazenado que leia estas informações
e acesse a tabela REGRAS para permitir que sejam avaliadas mais de uma regra de cada
vez.
51
O aplicativo IAS trabalha com as várias formas de conhecimento que o usuário
possui: impressões gerais, informações razoavelmente precisas e informações precisas.
Podemos analisar várias regras de cada vez. Os dados são gerados pelo CBA e
armazenados em um arquivo isolado, o IAS obtém as informações fornecidas pelo usuário e
extrai as regras consideradas interessantes do arquivo que foi gerado pelo CBA.
As consultas feitas na tabela REGRAS são executadas relativamente rápido,
porque as intruções SELECT não são consideradas pelo sistema para a realização de um
Checkpoint. Elas também podem ser agilizadas com a utilização de índices. Para o caso de
obtermos impressões gerais do usuário, podemos utilizar um índice composto pela coluna
ITENS e para os outros casos um índice contendo o ANTECEDENTE e o
CONSEQÜENTE.
52
6 – CONCLUSÕES
A utilização da mineração de dados e suas técnicas, entre elas as regras de
associação, em aplicações desenvolvidas com forte acoplamento com bancos de dados, vem
sendo muito estudada, em virtude da dificuldade de análise de grandes volumes me dados.
Neste caso a mineração de dados oferece resultados melhores que os métodos estatísticos e
as ferramentas OLAP. O aumento da quantidade de dados armazenados e a necessidade de
analisar estes dados tem sido uma preocupação crescente. O processamento utilizando um
banco de dados relacional de forma a utilizar os seus recursos se apresenta como uma
solução eficiente.
Neste trabalho descrevemos uma técnica importante de mineração de dados, as
regras de associação, mostrando como elas são utilizadas para encontrar regras
interessantes que estão escondidas nos dados. Apresentamos também uma forma de
implementar o algoritmo apriori em um SGBD relacional ao invés de usar arquivos
isolados. Exploramos características específicas do SGBD, oferecendo uma integração
fortemente acoplada entre a técnica de regras de associação e um SGBD relacional.
Abordamos o problema dos atributos quantitativos que possuem um domínio muito grande,
observando o problema e propondo soluções durante o processo todo.
Podemos apontar vários pontos positivos na implementação utilizando SGBD
relacional. A implementação através de procedimentos armazenados escritos em linguagem
Transact-SQL, oferece um alto desempenho no processamento de resultados de consultas, e
embora a aplicação tenha sido desenvolvida no ambiente do SQL Server 2000, com poucas
alterações ela pode ser utilizada em qualquer outro SGBD.
Aplicações desenvolvidas em diversas linguagens poderão utilizar as rotinas
desenvolvidas, precisando apenas enviar comandos para o SGBD iniciar a execução dos
procedimentos armazenados e passar os parâmetros necessários. O processo feito dessa
forma não gera grande tráfego de dados, pois toda a manipulação de dados necessária é
realizada no próprio SGBD, através de comandos SQL, de funções definidas pelo usuário
ou mesmo funções existentes no banco de dados utilizado, retornando para aplicação um
conjunto menor de informações.
Resultados práticos mostraram gargalos de desempenho na execução do
algoritmo em um SGBD, quando comparado com o uso de programas que utilizam
53
arquivos isolados. Isto ocorre devido às características da linguagem SQL oferecida pelos
bancos de dados relacionais e a quantidade de registros que são inseridos. Entretanto
podemos perceber que a mineração de dados em grandes bancos de dados se tornará uma
tarefa de rotina no futuro e que os SGBDs incorporarão novas funcionalidades que ajudarão
no processo, então os servidores de banco de dados desempenharão um papel importante
neste contexto.
A maioria das aplicações existentes para regras de associação utiliza os bancos
de dados apenas como repositório ou utiliza arquivos isolados. As ferramentas oferecidas
pelos SGBDs para mineração de dados apresentam uma performance excelente, mas a
aplicação é escrava do algoritmo utilizado e sabemos que nenhum algoritmo de mineração
de dados consegue atender a todas as necessidades. Uma aplicação fortemente acoplada, se
beneficiando dos recursos oferecidos pelo SGBD, e ao mesmo tempo feita sob medida para
atender a determinada necessidade, também se apresenta como uma boa solução para o
futuro.
É possível que a evolução dos SGBDs atuais e na linguagem SQL, possibilitem
a sua utilização em operações de mineração de dados que sejam efetuadas mais
eficientemente. Por exemplo, disponibilizar comandos que possibilitem obter várias
informações sobre os dados, com apenas uma varredura na base de dados. Além disso, os
bancos de dados orientados a objetos e os SGBDs paralelos oferecem uma grande área a ser
explorada.
Este trabalho possibilita o início de outras pesquisas a serem realizadas nesta
área, as quais poderiam abordar aspectos que não puderam ser contemplados, seja por
limitações da versão atual do SGBD utilizado, seja por alguma característica existente nele,
ou simplesmente pelo grande número de variáveis, que podem ser analisadas. Poderia ser
implementado todos os algoritmos e facilidades oferecidas pelos diversos algoritmos de
regras de associação, de forma a tornar a aplicação mais flexível. Além disso, pesquisas
procurando desenvolver programas fortemente acoplados a banco de dados representa ainda
uma área a ser explorada, principalmente considerando-se que as ferramentas oferecidas
pelos SGBDs não são muito flexíveis.
É interessante que seja realizada uma abordagem típica de database marketing.
O database marketing envolve a transformação da informação existente na base de dados
54
em decisões. Este tipo de experimento determinaria as medidas podem ser adotadas com
base nas regras interessantes que foram extraídas.
Uma futura implementação seria a implementação de um processo
automatizado para determinar o tamanho dos intervalos dos atributos contínuos, baseado
em um suporte máximo que o atributo pode ter. A utilização, também de múltiplos
suportes, para minimizar o problema do item raro. Poderíamos também considerar a
implementação em um banco de dados orientado a objetos. Esta conversão é motivada
pelos benefícios existentes nesta abordagem e pela presença de novas funcionalidades que
representariam um ganho de desempenho consideravelmente maior.
55
REFERÊNCIAS BIBLIOGRÁFICAS
[1] ADAMO, J., “Data Mining for Association Rules and Sequential Patterns – Sequential
and Parallel Algorithms”, 1 ed., New York, Springer-Verlag
[2] AGRAWAL, R., IMIELINSKI, T., SWAMI, A., “Mining Association Rules between
Sets of Items in Large Databases”, ACM SIGMOD Conference on Management
of Data, pp.207-216, Washington DC, May 1993
[3] AGRAWAL, R., SRIKANT, R., “Fast Algorithms for Mining Association Rules”, In
Proc. Of the 20th Int’l Conference on Very Large Databases, Santiago, Chile,
September 1994.
[4] AGRAWAL, R.,SRIKANT, R., “Mining Quantitative Association Rules in Large
Relational Tables”, Proc. Of the ACM-SIGMOD 1996 Conference on
Management of Data, Montreal, Canada, June 1996.
[5] BRADLEY, P. S., FAYYAD, U. M., REINA,C. A., “Scaling Clustering Algorithms to
Large Datases”, In: The fourth International Conference on Knowledge
Discovery and Data Mining, New York, August, 1998.
[6] BRADLEY, P. S., FAYYAD, U. M., REINA,C. A., “Initialization of Iterative
Refinement Clustering Algorithms”, In: The fourth International Conference on
Knowledge Discovery and Data Mining, New York, August, 1998.
[7] GARCIA, M. F., REDING, J., WHALEN, E., et al, Microsoft SQL SERVER 2000
Administrator’s Companion, 1 ed., Redmond, Microsoft Press.
[8] GRAEFE, G., FAYYAD, U., CHAUDHURI, S., “On the Efficient Gathering of
Sufficient Statistics for Classification from Large SQL Databases”, The fourth
International Conference on Knowledge Discovery and Data Mining, New
York, August 1998.
[9] GUNDERLOY, M., JORDEN, J. L., SQL SERVER 2000 A Bíblia, 1 ed., São Paulo,
Makron Books.
[10] HUANG, Y., WU, C., “Mining Generalized Association Rules Using Pruning
Techniques”, In: IEEE International Conference on Data Mining, Maebashi,
Japan, December 2002.
56
[11] LIU, B., HSU, W., MA, Y., “Integrating Classification and Association Rule Mining”,
American Association for Artificial Intelligence, 1998.
[12] LIU, B., HSU, W., CHEN, S. et al , “Analysing the Subjective Interestingness of
Association Rules”, National University os Singapore
[13] LIU, B., HSU, W., MA, YIMING. et al , “Mining Association Rules with Multiple
Minimum Supports”, National University os Singapore
[14] NG, E. K. K., FU, A. W., WANG, K., “Mining Association Rules for Stars”, In:
IEEE International Conference on Data Mining, Maebashi, Japan, December
2002.
[15] OMIECINSKI, E. R., "Alternative Interest Measures for Mining Associations in
Databases" IEEE Transactions on Knowledge & Data Engineering, January
2003.
[16] NETZ, A., Chaudhuri, S., Fayyad, U., et al, “Integranting Data Mining With SQL
Databases: ole dbFOR Data Mining”, Microsoft Corporation
[17] PARTHASARATHY, S., “Efficient Progressive Sampling for Association Rules”, In:
IEEE International Conference on Data Mining, Maebashi, Japan, December
2002.
[18] PYLE, D., “Data Preparation for Data Mining”, 1 ed., San Francisco, Morgan
Kaufmann Publisher
[19] SHEN, Y., ZHANG, Z., YANG, Q., “Objective-Oriented Utility-Based Association
Mining”, In: IEEE International Conference on Data Mining, Maebashi, Japan,
December 2002.
[20] SINGH, H.S., Data Warehouse – Conceitos, Tecnologias, Implementação e
Gerenciamento, 1 ed., São Paulo, Makron Books
[21] SRIKANT, R., AGRAWAL, R., “Mining Generalized Association Rules”,
Proceedings of the 21st VLDB
57
ANEXO I
Relação de itens presentes nas transações com os respectivos suportes
Itens
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Nome
Flash set
Grape juice
Large doll
Milk powder
Orangeade
Puzzle-500p
Port wine
Lens cleaner
Irish whiskey
Baby food A
Toy lorry
water
White bread
Card game
Irish Butter
Oil-brand B
Salty Biscuits
Sherry
Small doll
Red Italian wine
Monopoly game
Brown bread
Car mats
Sekt
Oil filter XYZ
Vodka
White French wine
Spark plugs ABC
Cheddar Cheese
Oil-brand A
Jamaican Rum
Toast
Red German wine
Asti Spumante
Windscreen wipers
Washing-up liquid
Antifreeze
Colour neg. film
Suporte
1.000
1.000
1.000
1.000
1.000
1.000
2.000
2.000
2.000
2.000
2.000
2.000
3.000
3.000
3.000
3.000
3.000
3.000
3.000
4.000
4.000
4.000
5.000
5.000
5.000
5.000
5.000
6.000
6.000
7.000
7.000
7.000
8.000
8.000
9.000
9.000
10.000
10.000
58
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
Detergent
Gouda Cheese
Red French wine
Camera A
Tonic water
Battery
Crispbread
Cognac
Color slide film
Battery charger
Cottage cheese
Soap A
White Italian wine
White German wine
B-Beer
Apple juice
Orange juice
Disp. nappies Q
Lime juice
Export
car light bulb H4
Stout
Toilet Paper
Crisps
Scotch whisky
C-Beer
A-Beer
Baby bottle
Milk
Brandy
Cachaca
Disp. nappies P
Crackers
Champagne
Car Types Cherry LiqueurBaby food B
Puzzle-1000p
Mineral water
Cider
Toy car
Cream
Lemonade
59
10.000
10.000
11.000
11.000
11.000
12.000
12.000
12.000
13.000
13.000
14.000
14.000
15.000
15.000
15.000
15.000
15.000
15.000
15.000
16.000
16.000
16.000
16.000
17.000
18.000
19.000
20.000
20.000
20.000
21.000
24.000
25.000
25.000
26.000
27.000
28.000
29.000
31.000
33.000
47.000
48.000
49.000
ANEXO II
Quantidade de conjuntos de itens gerados, para uma transação com 28 itens
Quantidade de itens nos
conjuntos gerados
Quantidade de
conjuntos gerados
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Total
28
378
3.276
20.475
98.280
376.740
1.184.040
3.108.105
6.906.900
13.123.110
21.474.180
30.421.755
37.442.160
40.116.600
37.442.160
30.421.755
21.474.180
13.123.110
6.906.900
3.108.105
1.184.040
376.740
98.280
20.475
3.276
378
28
1
268.435.455
60
ANEXO III
Quantidade de itens
Suporte
Quantidade de conjuntos
de itens
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
3
3
3
4
5
6
7
8
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
24
25
26
27
28
29
31
33
47
48
49
6
7
8
9
10
12
14
21
6
7
8
6
6
6
6
6
2
3
2
3
4
2
4
2
1
7
4
1
1
1
3
1
1
2
1
1
1
1
1
1
1
1
1
57
12
17
3
2
1
1
1
37
1
1
40
36
21
7
1
61
ANEXO IV
Procedimento armazenado para gerar regras de associação
CREATE PROCEDURE G_REGRAS
@MIN_SUP NUMERIC (6,3),
@MIN_CONF NUMERIC (6,3),
@K INT
AS
--***************************************************************
--
CRIAÇÃO DA TABELA CANDIDATOS
--***************************************************************
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[CANDIDATOS]')
and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[CANDIDATOS]
CREATE TABLE [dbo].[CANDIDATOS] (
[ITENS] [varchar] (1000) NULL ,
[ULTIMA] [varchar] (50) NULL ,
[TAMANHO] [numeric](18, 0) NULL ,
[LINHA] [int] NULL
) ON [PRIMARY]
CREATE INDEX [IX_CANDIDATOS] ON [dbo].[CANDIDATOS]([TAMANHO]) ON [PRIMARY]
CREATE INDEX [IX_CANDIDATOS_1] ON [dbo].[CANDIDATOS]([LINHA]) ON [PRIMARY]
--***************************************************************
--
CRIAÇÃO DA TABELA ITEMSET
--***************************************************************
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[ITEMSET]')
and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[ITEMSET]
CREATE TABLE [dbo].[ITEMSET] (
[ITENS] [varchar] (900) NULL ,
[SUPORTE] [numeric](6, 3) NULL ,
[ULTIMA] [varchar] (50) NULL ,
[TAMANHO] [numeric](18, 0) NULL
) ON [PRIMARY]
CREATE INDEX [IX_ITEMSET] ON [dbo].[ITEMSET]([ITENS]) ON [PRIMARY]
62
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[REGRAS]')
and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[REGRAS]
--***************************************************************
--
CRIAÇÃO DA TABELA REGRAS
--***************************************************************
CREATE TABLE [dbo].[REGRAS] (
[ITENS] [varchar] (1000) NULL ,
[ANTECEDENTE] [varchar] (450) NULL ,
[CONSEQUENTE] [varchar] (450) NULL ,
[SUPORTE] [numeric](6, 3) NULL ,
[CONFIANCA] [numeric](6, 3) NULL
)
--***************************************************************
--
DECLARAÇÃO DAS VARIÁVEIS AUXILIARES
--***************************************************************
DECLARE @CONTADOR INT
DECLARE @QTD_COLUNAS INT
DECLARE @QTD_ITENS INT
DECLARE @TABELA VARCHAR(20)
DECLARE @I_SQL NVARCHAR(1000)
DECLARE @QTD_LINHAS INT
DECLARE @IND INT
DECLARE @POS INT
DECLARE @COLUNAS VARCHAR(2000)
DECLARE @ITEM VARCHAR(1000)
DECLARE @ITEMSET VARCHAR(1000)
DECLARE @ULTIMA VARCHAR(1000)
DECLARE @LINHA INT
DECLARE @ITENS varchar(900)
DECLARE @ITENS_AUX varchar(900)
DECLARE @TAMANHO INT
DECLARE @MIN_SUP2 INT
DECLARE @SUPORTE numeric (6,3)
DECLARE @SUPORTE_2 numeric (6,3)
DECLARE @CONFIANCA numeric (6,3)
DECLARE @V_Col001 VARCHAR(25)
DECLARE @V_Col002 VARCHAR(25)
DECLARE @V_Col003 VARCHAR(25)
DECLARE @V_Col004 VARCHAR(25)
DECLARE @V_Col005 VARCHAR(25)
63
DECLARE @V_Col006 VARCHAR(25)
DECLARE @V_Col007 VARCHAR(25)
DECLARE @V_Col008 VARCHAR(25)
DECLARE @V_Col009 VARCHAR(25)
DECLARE @V_Col010 VARCHAR(25)
DECLARE @V_Col011 VARCHAR(25)
DECLARE @V_Col012 VARCHAR(25)
DECLARE @V_Col013 VARCHAR(25)
DECLARE @V_Col014 VARCHAR(25)
DECLARE @V_Col015 VARCHAR(25)
DECLARE @V_Col016 VARCHAR(25)
DECLARE @V_Col017 VARCHAR(25)
DECLARE @V_Col018 VARCHAR(25)
DECLARE @V_Col019 VARCHAR(25)
DECLARE @V_Col020 VARCHAR(25)
DECLARE @V_Col021 VARCHAR(25)
DECLARE @V_Col022 VARCHAR(25)
DECLARE @V_Col023 VARCHAR(25)
DECLARE @V_Col024 VARCHAR(25)
DECLARE @V_Col025 VARCHAR(25)
DECLARE @V_Col026 VARCHAR(25)
DECLARE @V_Col027 VARCHAR(25)
DECLARE @V_Col028 VARCHAR(25)
SET @TABELA = 'cbaform'
SELECT @QTD_COLUNAS = COUNT(*)
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = @TABELA
IF @K = 0
BEGIN
SET @K = @QTD_COLUNAS
END
SELECT @QTD_LINHAS = COUNT(*) FROM cbaform
SET @MIN_SUP2 = (@QTD_LINHAS * @MIN_SUP) / 100
SET @MIN_SUP = (@QTD_LINHAS * @MIN_SUP) / 100
IF @MIN_SUP2 < @MIN_SUP
BEGIN
SET @MIN_SUP2 = @MIN_SUP2 + 1
END
DECLARE C_COLUNAS CURSOR FOR
64
SELECT Col001, Col002, Col003,
Col004, Col005, Col006,
Col007, Col008, Col009,
Col010, Col011, Col012,
Col013, Col014, Col015,
Col016, Col017, Col018,
Col019, Col020, Col021,
Col022, Col023, Col024,
Col025, Col026, Col027,
Col028
FROM CBAFORM
SET @CONTADOR = 1
OPEN C_COLUNAS
FETCH NEXT FROM C_COLUNAS
INTO @V_Col001,
@V_Col002,
@V_Col003,
@V_Col004,
@V_Col005,
@V_Col006,
@V_Col007,
@V_Col008,
@V_Col009,
@V_Col010,
@V_Col011,
@V_Col012,
@V_Col013,
@V_Col014,
@V_Col015,
@V_Col016,
@V_Col017,
@V_Col018,
@V_Col019,
@V_Col020,
@V_Col021,
@V_Col022,
@V_Col023,
@V_Col024,
@V_Col025,
@V_Col026,
@V_Col027,
@V_Col028
SET @LINHA = 1
65
WHILE @@FETCH_STATUS = 0
BEGIN
IF @V_Col001 <> '?'
BEGIN
BEGIN TRAN REG_000_1
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col001, @V_Col001, 1, @LINHA)
COMMIT TRAN REG_000_1
END
IF @V_Col002 <> '?'
BEGIN
BEGIN TRAN REG_000_2
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col002, @V_Col002, 1, @LINHA)
COMMIT TRAN REG_000_2
END
IF @V_Col003 <> '?'
BEGIN
BEGIN TRAN REG_000_3
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col003, @V_Col003, 1, @LINHA)
COMMIT TRAN REG_000_3
END
IF @V_Col004 <> '?'
BEGIN
BEGIN TRAN REG_000_4
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col004, @V_Col004, 1, @LINHA)
COMMIT TRAN REG_000_4
END
IF @V_Col005 <> '?'
BEGIN
BEGIN TRAN REG_000_5
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col005, @V_Col005, 1, @LINHA)
COMMIT TRAN REG_000_5
END
IF @V_Col006 <> '?'
BEGIN
66
BEGIN TRAN REG_000_6
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col006, @V_Col006, 1, @LINHA)
COMMIT TRAN REG_000_6
END
IF @V_Col007 <> '?'
BEGIN
BEGIN TRAN REG_000_7
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col007, @V_Col007, 1, @LINHA)
COMMIT TRAN REG_000_7
END
IF @V_Col008 <> '?'
BEGIN
BEGIN TRAN REG_000_8
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col008, @V_Col008, 1, @LINHA)
COMMIT TRAN REG_000_8
END
IF @V_Col009 <> '?'
BEGIN
BEGIN TRAN REG_000_9
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col009, @V_Col009, 1, @LINHA)
COMMIT TRAN REG_000_9
END
IF @V_Col010 <> '?'
BEGIN
BEGIN TRAN REG_000_10
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col010, @V_Col010, 1, @LINHA)
COMMIT TRAN REG_000_10
END
IF @V_Col011 <> '?'
BEGIN
BEGIN TRAN REG_000_11
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col011, @V_Col011, 1, @LINHA)
COMMIT TRAN REG_000_11
END
IF @V_Col012 <> '?'
67
BEGIN
BEGIN TRAN REG_000_12
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col012, @V_Col012, 1, @LINHA)
COMMIT TRAN REG_000_12
END
IF @V_Col013 <> '?'
BEGIN
BEGIN TRAN REG_000_13
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col013, @V_Col013, 1, @LINHA)
COMMIT TRAN REG_000_13
END
IF @V_Col014 <> '?'
BEGIN
BEGIN TRAN REG_000_14
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col014, @V_Col014, 1, @LINHA)
COMMIT TRAN REG_000_14
END
IF @V_Col015 <> '?'
BEGIN
BEGIN TRAN REG_000_15
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col015, @V_Col015, 1, @LINHA)
COMMIT TRAN REG_000_15
END
IF @V_Col016 <> '?'
BEGIN
BEGIN TRAN REG_000_16
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col016, @V_Col016, 1, @LINHA)
COMMIT TRAN REG_000_16
END
IF @V_Col017 <> '?'
BEGIN
BEGIN TRAN REG_000_17
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col017, @V_Col017, 1, @LINHA)
COMMIT TRAN REG_000_17
END
68
IF @V_Col018 <> '?'
BEGIN
BEGIN TRAN REG_000_18
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col018, @V_Col018, 1, @LINHA)
COMMIT TRAN REG_000_18
END
IF @V_Col019 <> '?'
BEGIN
BEGIN TRAN REG_000_19
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col019, @V_Col019, 1, @LINHA)
COMMIT TRAN REG_000_19
END
IF @V_Col020 <> '?'
BEGIN
BEGIN TRAN REG_000_20
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col020, @V_Col020, 1, @LINHA)
COMMIT TRAN REG_000_20
END
IF @V_Col021 <> '?'
BEGIN
BEGIN TRAN REG_000_21
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col021, @V_Col021, 1, @LINHA)
COMMIT TRAN REG_000_21
END
IF @V_Col022 <> '?'
BEGIN
BEGIN TRAN REG_000_22
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col022, @V_Col022, 1, @LINHA)
COMMIT TRAN REG_000_22
END
IF @V_Col023 <> '?'
BEGIN
BEGIN TRAN REG_000_23
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col023, @V_Col023, 1, @LINHA)
COMMIT TRAN REG_000_23
END
69
IF @V_Col024 <> '?'
BEGIN
BEGIN TRAN REG_000_24
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col024, @V_Col024, 1, @LINHA)
COMMIT TRAN REG_000_24
END
IF @V_Col025 <> '?'
BEGIN
BEGIN TRAN REG_000_25
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col025, @V_Col025, 1, @LINHA)
COMMIT TRAN REG_000_25
END
IF @V_Col026 <> '?'
BEGIN
BEGIN TRAN REG_000_26
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col026, @V_Col026, 1, @LINHA)
COMMIT TRAN REG_000_26
END
IF @V_Col027 <> '?'
BEGIN
BEGIN TRAN REG_000_27
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col027, @V_Col027, 1, @LINHA)
COMMIT TRAN REG_000_27
END
IF @V_Col028 <> '?'
BEGIN
BEGIN TRAN REG_000_28
INSERT INTO CANDIDATOS (ITENS, ULTIMA, TAMANHO, LINHA) VALUES
(@V_Col028, @V_Col028, 1, @LINHA)
COMMIT TRAN REG_000_28
END
FETCH NEXT FROM C_COLUNAS
INTO @V_Col001,
@V_Col002,
@V_Col003,
@V_Col004,
@V_Col005,
70
@V_Col006,
@V_Col007,
@V_Col008,
@V_Col009,
@V_Col010,
@V_Col011,
@V_Col012,
@V_Col013,
@V_Col014,
@V_Col015,
@V_Col016,
@V_Col017,
@V_Col018,
@V_Col019,
@V_Col020,
@V_Col021,
@V_Col022,
@V_Col023,
@V_Col024,
@V_Col025,
@V_Col026,
@V_Col027,
@V_Col028
SET @LINHA = @LINHA + 1
END
CLOSE C_COLUNAS
DEALLOCATE C_COLUNAS
SET @I_SQL = 'INSERT INTO ITEMSET SELECT LTRIM(RTRIM(ITENS)), COUNT(*), ULTIMA, TAMANHO
FROM CANDIDATOS GROUP BY ITENS, ULTIMA, TAMANHO HAVING COUNT(*) > ' + STR(@MIN_SUP2)
EXEC sp_executesql @I_SQL
SET @I_SQL = 'DELETE FROM CANDIDATOS WHERE ITENS NOT IN (SELECT ITENS FROM ITEMSET)'
EXEC sp_executesql @I_SQL
SET @CONTADOR = 1
WHILE @CONTADOR < @K
BEGIN
BEGIN TRAN REG_001
SET @I_SQL = 'INSERT INTO CANDIDATOS SELECT C1.ITENS
+STR(@CONTADOR) + ' + 1, C1.LINHA
71
+ '', '' + C2.ITENS, C2.ITENS, '
FROM CANDIDATOS C1, CANDIDATOS C2
WHERE C1.LINHA = C2.LINHA
AND C1.ULTIMA < C2.ITENS
AND C1.TAMANHO = ' + STR(@CONTADOR) +
' AND C2.TAMANHO = 1'
EXEC sp_executesql @I_SQL
COMMIT TRAN REG_001
BEGIN TRAN REG_002
SET @I_SQL = 'INSERT INTO ITEMSET SELECT LTRIM(RTRIM(ITENS)), COUNT(*), ULTIMA, TAMANHO
FRO
CANDIDATOS GROUP BY ITENS, ULTIMA, TAMANHO HAVING COUNT(*) > ' +
STR(@MIN_SUP2) +
' AND TAMANHO = (' + STR(@CONTADOR) + ' + 1)'
EXEC sp_executesql @I_SQL
COMMIT TRAN REG_002
BEGIN TRAN REG_003
IF @CONTADOR > 1
BEGIN
SET @I_SQL = 'DELETE FROM CANDIDATOS WHERE (TAMANHO = ' + STR(@CONTADOR)
+ ')'
EXEC sp_executesql @I_SQL
SET @I_SQL = 'DELETE FROM CANDIDATOS WHERE (TAMANHO = (' + STR(@CONTADOR)
+
' + 1) AND ITENS NOT IN (SELECT ITENS FROM ITEMSET
WHERE TAMANHO = ' + STR(@CONTADOR) + ' + 1))'
EXEC sp_executesql @I_SQL
END
COMMIT TRAN REG_003
SET @CONTADOR = @CONTADOR + 1
END
DECLARE C_ITEMSET CURSOR FOR
SELECT ITENS, SUPORTE, TAMANHO
FROM ITEMSET
WHERE TAMANHO > 1
72
OPEN C_ITEMSET
FETCH NEXT FROM C_ITEMSET
INTO @ITENS, @SUPORTE, @TAMANHO
WHILE @@FETCH_STATUS = 0
BEGIN
BEGIN TRAN REG_005
SET @CONTADOR = 1
WHILE @CONTADOR < @TAMANHO + 1
BEGIN
SET @IND = 1
SET @POS = 1
WHILE @IND < (LEN(@ITENS))
BEGIN
IF SUBSTRING(@ITENS, @IND, 1) = ','
OR @IND = LEN(@ITENS)
BEGIN
IF @POS = 1
BEGIN
SET @ITENS_AUX = SUBSTRING(@ITENS, (@IND + 2), (LEN(@ITENS) @IND + 1)) + ', ' + SUBSTRING(@ITENS, @POS, (@IND - @POS))
END
SELECT @SUPORTE_2 = SUPORTE FROM ITEMSET
WHERE ITENS = SUBSTRING(@ITENS, @POS, (@IND - @POS))
SET @CONFIANCA = (@SUPORTE / @SUPORTE_2) * 100
SET @I_SQL = 'INSERT INTO REGRAS ('
SET
@I_SQL
=
@I_SQL
+
'ITENS,
ANTECEDENTE,
CONSEQUENTE,
SUPORTE,CONFIANCA) VALUES
(''' + @ITENS + ''', ''' + SUBSTRING(@ITENS, @POS, (@IND - @POS)) +''',
''' + SUBSTRING(@ITENS, (@IND + 2), (LEN(@ITENS - @IND
+ 1)) + '''
' + STR(@SUPORTE) + ', ' + STR(@CONFIANCA) + ')'
EXEC sp_executesql @I_SQL
73
END
SET @IND = @IND + 1
END
SET @ITENS = @ITENS_AUX
SET @CONTADOR = @CONTADOR + 1
END
COMMIT TRAN REG_005
FETCH NEXT FROM C_ITEMSET
INTO @ITENS, @SUPORTE, @TAMANHO
END
BEGIN TRAN REG_006
DELETE FROM REGRAS WHERE CONFIANCA <= @MIN_CONF
COMMIT TRAN REG_006
BEGIN TRAN REG_007
UPDATE REGRAS SET SUPORTE = (SUPORTE / @QTD_LINHAS) * 100
COMMIT TRAN REG_007
DEALLOCATE C_ITEMSET
GO
74