SAMiRA UMA PROPOSTA DE SISTEMA DE APOIO À MINERAÇÃO DE REGRAS DE ASSOCIAÇÃO

Transcrição

1 UNIVERSIDADE ESTADUAL DO CEARÁ Centro de Ciências Tecnológicas - CCT INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO CEARÁ Diretoria de Pesquisa e Pós-Graduação - DIPPG SANDRO LUIZ DA PAIXÃO XAVIER SAMiRA UMA PROPOSTA DE SISTEMA DE APOIO À MINERAÇÃO DE REGRAS DE ASSOCIAÇÃO FORTALEZA CEARÁ 2010

2 SANDRO LUIZ DA PAIXÃO XAVIER SAMiRA UMA PROPOSTA DE SISTEMA DE APOIO À MINERAÇÃO DE REGRAS DE ASSOCIAÇÃO Dissertação apresentada ao Curso de Mestrado Integrado Profissional em Computação Aplicada do Centro de Ciências e Tecnologia da Universidade Estadual do Ceará e Diretoria de Graduação e Pós-Graduação do Instituto Federal de Educação, Ciência e Tecnologia do Ceará, como requisito para a obtenção do grau de Mestre em Computação Aplicada. Área de Concentração: Mineração de dados. Orientador: Prof. Dr. Jerffeson Teixeira de Souza. FORTALEZA 2010

3 18 X3s Xavier, Sandro Luiz da Paixão SAMiRA uma proposta de sistema de apoio à mineração de regras de associação / Sandro Luiz da Paixão Xavier. Fortaleza, p. ; il. Orientador: Prof. Dr. Jerffeson Teixeira de Souza. Dissertação (Mestrado Integrado Profissional em Computação Aplicada) Universidade Estadual do Ceará, Centro de Ciências e Tecnologia, Instituto Federal de Educação, Ciência e Tecnologia do Ceará, Diretoria de Graduação e Pós-Graduação. Área de Concentração: Mineração de dados. 1. KDD. 2. Mineração de dados. 4. Regras de associação. 5. FP-Growth. I. Universidade Estadual do Ceará, Centro de Ciências e Tecnologia, Instituto Federal de Educação, Ciência e Tecnologia do Ceará, Diretoria de Graduação e Pós-Graduação. CDD:

4 19 SANDRO LUIZ DA PAIXÃO XAVIER SAMiRA UMA PROPOSTA DE SISTEMA DE APOIO À MINERAÇÃO DE REGRAS DE ASSOCIAÇÃO Dissertação apresentada ao Curso de Mestrado Integrado Profissional em Computação Aplicada do Centro de Ciências e Tecnologia da Universidade Estadual do Ceará e Diretoria de Graduação e Pós-Graduação do Instituto Federal de Educação, Ciência e Tecnologia do Ceará, como requisito para a obtenção do grau de Mestre em Computação Aplicada. Área de Concentração: Mineração de dados. Aprovada em: 28/12/2010. COMISSÃO EXAMINADORA Prof. Dr. Jerffeson Teixeira de Souza (Orientador) Universidade Estadual do Ceará UECE Prof. Dr. Gustavo Augusto Lima de Campos Universidade Estadual do Ceará UECE Prof. Dr. Fernando Antônio de Carvalho Gomes Universidade Federal do Ceará UFC

5 20 Dedico esta dissertação aos meus pais Haroldo e Verônica pelo incentivo e apoio incondicional durante a realização dos meus estudos.

6 21 AGRADECIMENTOS A Deus pela oportunidade e condições de concluir o meu curso. Aos meus pais, Haroldo Xavier Silva e Sandra Verônica da Paixão Xavier pelo incentivo e apoio incondicional durante a realização dos meus estudos. Ao Professor Jerffeson Teixeira de Souza pelas sábias orientações, paciência e confiança depositada em mim para a realização deste trabalho. Ao Professor Gustavo Campos através de suas sugestões e conversas amigas a respeito desta Dissertação. Eu gostaria de agradecer aos professores que foram membros das bancas das defesas dos seminários e da dissertação, Professora Verônica Pimentel, Marcos Negreiros e Fernando Carvalho, pois a cada defesa, a cada etapa, pude graças as suas contribuições, desenvolver e aprimorar o meu trabalho final. Eu sou imensamente grato a Anna Cássia Gonçalves de Oliveira que sempre esteve ao meu lado durante este trabalho, transmitindo seu precioso apoio, paciência, incentivo e contribuição através de seus conhecimentos acadêmicos. As amigas Albina Chaves e Sandra Simões pela valiosa contribuição através dos seus conhecimentos e habilidades. Ao Antônio Carlos Leite Soares pela troca das experiências a respeito do assunto de sua dissertação, que muito me ajudou, facilitando meu trabalho. Aos amigos Antônio Garcia Neto e Ivone Cavalcante pelo apoio e incentivo através de conselhos amigos. A todos os alunos, professores e colaboradores do MPCOMP pela agradável convivência e transmissão de conhecimentos nesses anos.

7 22 A ciência e a religião são as alavancas da inteligência humana. Allan Kardec

8 23 RESUMO Descoberta de Conhecimento em Bancos de Dados é um processo essencial em que métodos inteligentes são aplicados, em ordem, para extrair conhecimentos implícitos e auxiliar na tomada de decisão. Um dos padrões mais comuns que pode ser descoberto a partir deste processo é o conjunto de Regras de Associação que representam combinações de itens que ocorrem com determinada freqüência em uma base de dados. Neste trabalho foi desenvolvido um sistema de apoio à decisão denominado SAMiRA (Sistema de Apoio à Mineração de Regras de Associação), que contempla todas as etapas do processo de Mineração de Dados. Para validar este sistema, foram realizados estudos de casos com as bases de dados de duas empresas: uma focada no comércio de produtos veterinários e a outra no comércio de produtos de controle de pragas, em que foi possível analisar os perfis das regras geradas para estes ramos de negócio e realizar uma avaliação comparativa dos algoritmos para Regras de Associação Apriori e FP- Growth para os conjuntos de transações de vendas deste mesmos ramos de negócios. Como resultados destes estudos de casos, para a empresa de produtos veterinários foram encontradas regras com suporte de até 5%. O Apriori encontrou uma quantidade maior de regras em alguns casos, enquanto que o FP-Growth apresentou um tempo de processamento expressivamente menor. Para a empresa de produtos de controle de pragas foram encontradas regras com suporte de até 21%. Na avaliação comparativa entre os algoritmos, o Apriori encontrou uma quantidade maior de regras em alguns casos, enquanto que o FP-Growth apresentou tempos de processamentos apenas um pouco menor que os encontrados pelo Apriori. Palavras-chave: KDD. Mineração de Dados. Regras de Associação. Apriori. FP- Growth.

9 24 ABSTRACT Knowledge Discovery in Databases is an essential process where intelligent methods are applied in order to extract implicit knowledge and aid in decision making. One of the most common patterns that can be discovered from this process is the set of Association Rules that represent combinations of items that occur with particular frequency in a daabase. In this work, a decision support system called SAMiRA (Sistema de Apoio à Mineração de Banco de Dados, in Portuguese, that it means Support System for Mining Association Rules) was developed, which covers all stages of the process of Data Mining. To validate this system we performed case studies with the databases of two companie: one focused on trade in veterinary products and the other in trade in pest control, where it was possible to analyze the profiles of the generated rules for these branches of business and make a comparative evaluation of algorithms for Association Rules Apriori and FP-Growth for combinations of sales transactions of the same business. As results of these cases studies, for veterinary products company were found rules with support for up to 5%. The Apriori found a greater number of rules in some cases, while the FP-Growth showed a significantly lower processing time. For pest control products company were found rules with support for up to 21%. In the benchmarking of the algorithms, the Apriori found a larger amount of rules in some cases, while the FP-Growth showed processing times only a bit lower than those found by Apriori. Key-words: KDD. Data Mining. Association Rules. Apriori. FP-Growth.

10 25 LISTA DE ILUSTRAÇÕES Figura 1.1 Primeira iteração da busca por itens frequentes através do algoritmo Apriori Figura 1.2 Segunda iteração da busca por itens frequentes através do algoritmo Apriori Figura 1.3 Terceira iteração da busca por itens frequentes através do algoritmo Apriori Figura 1.4 FP-Tree apresentada por Borgelt(2005) Figura 1.5 Construção de FP-Tree: Leitura das seis primeiras transações Figura 1.6 Comando Weka via linha de comando utilizando o algoritmo FP-Growth. 45 Figura 1.7 Resultado da mineração de regras de associação utilizando o algoritmo FP- Growth através do comando apresentado na Figura Figura 2.1 Diagrama de Caso de Uso do SAMiRA Figura 2.2 Abstração da Integração SAMiRA Versus Weka Figura 2.3 Diagrama de Atividades da Integração SAMiRA Versus Weka Figura 2.4 Configuração UDL Lista de provedores de Banco de Dados Figura 2.5 Configuração UDL Dados para conexão com Banco de Dados Figura 2.6 Registros modelos para a Primeira Consulta Figura 2.7 Registros modelos para a Segunda Consulta Figura 2.8 Tela de integração do SAMiRA com outro sistema Figura 2.9 Área de Pré-Processamento do SAMiRA Figura 2.10 Área de Mineração de Dados do SAMiRA Figura 2.11 Área de Pós-Processamento do SAMiRA Figura 2.12 Relatório de Regras do SAMiRA Figura 3.1 Abstração do Planejamento dos Experimentos Figura 3.2 Espaço de Pesquisa do 1º Experimento... 69

11 26 Figura 3.3 Espaço de Pesquisa do 2º Experimento Figura 3.4 Espaço de Pesquisa do 3º Experimento Figura 3.5 Espaço de Pesquisa do 4º Experimento Figura 3.6 Espaço de Pesquisa do 5º Experimento Figura 3.7 Espaço de Pesquisa do 6º Experimento Figura 3.8 Espaço de Pesquisa do 7º Experimento Figura 3.9 Espaço de Pesquisa do 8º Experimento Figura 3.10 Gráfico de quandidades de regras por suporte dos conjuntos de dados da Filial Figura 3.11 Top 30 da Regras extraídas pelo Apriori dos dados de março de 2010 da Filial Figura 3.12 Top 30 da Regras extraídas pelo FP-Growth dos dados de março de 2010 da Filial Figura 3.13 Gráfico de quandidades de regras por suporte dos conjuntos de dados da Filial Figura 3.14 Gráfico de quandidades de regras por suporte dos conjuntos de dados da Filial Figura 3.15 Gráfico de quandidades de regras por suporte dos conjuntos de dados da Filial Figura 3.16 Gráfico de tempo de processamento dos algoritmos por conjunto de dados Figura 3.17 Gráfico de quandidades de regras por suporte dos conjuntos de dados da DEDETEC de março de Figura 3.18 Gráfico de quandidades de regras por suporte dos conjuntos de dados da DEDETEC de março a maio de Figura 3.19 Gráfico de quandidades de regras por suporte dos conjuntos de dados da DEDETEC de março de Figura 3.20 Gráfico de quandidades de regras por suporte dos conjuntos de dados da DEDETEC de março a maio de

12 27 Figura 3.21 Top 30 da Regras extraídas pelo FP-Growth dos dados da DEDETEC de março de Figura 3.22 Gráfico de tempo de processamento dos algoritmos por conjunto de dados... 89

13 28 LISTA DE TABELAS Tabela 1.1 Relação de Vendas de um mercadinho em um período Tabela 1.2 Exemplo de índices de suporte e confiança Tabela 1.3 Relação de Vendas de um mercadinho em um período Tabela 1.4 Transações apresentadas por Borgelt(2005) Tabela 2.1 Descrição da tabela de Tipos de Métricas Tabela 2.2 Descrição da tabela de Algoritmos Tabela 2.3 Descrição da tabela de Processamentos Tabela 2.4 Descrição da tabela de Regras Tabela 2.5 Descrição da tabela de Itens da Regra Tabela 3.1 Conjunto de transações referentes à vendas Tabela 3.2 Parâmetros do 1º Experimento Tabela 3.3 Parâmetros do 2º Experimento Tabela 3.4 Parâmetros do 3º Experimento Tabela 3.5 Parâmetros do 4º Experimento Tabela 3.6 Parâmetros do 5º Experimento Tabela 3.7 Parâmetros do 6º Experimento Tabela 3.8 Parâmetros do 7º Experimento Tabela 3.9 Parâmetros do 8º Experimento... 74

14 29 LISTA DE ABREVIATURAS E SIGLAS API ARFF ASCIII Conf DIC Eclat FP-Tree IDE KDD RI SAMiRA SGBD Sup UDL Weka Application Programming Interface Attribute-Relation Files Format American Standard Code for Information Interchange Confiança Dynamic Itemset Counting Equivalence Class Transformation Frequent Pattern Integrated Development Environment Knowledge Discovery in Databases ou Descoberta de conhecimento em banco de dados Rule Interest Sistema de Apoio à Mineração de Regras de Associação Sistema Gerenciador de Banco de Dados Suporte Universal Data Link Waikato Environment for Knowledge Analysis

15 30 SUMÁRIO LISTA DE ILUSTRAÇÕES LISTA DE TABELAS LISTA DE ABREVIATURAS E SIGLAS INTRODUÇÃO Contextualização Problemas Identificados Objetivos Metodologia Organização do Trabalho FUNDAMENTAÇÃO TEÓRICA Mineração de Dados Etapa de Pré-Processamento Seleção de Dados Limpeza Etapa de Mineração de Dados Etapa de Pós-Processamento Regras de Associação Definição Formal Medidas de Interesse Medidas de Interesse Subjetivas Medidas de Interesse Objetivas Suporte e Confiança Lift... 30

16 Rule Interest Algoritmos de Regras de Associação Algoritmo Apriori Algoritmo FP-Growth A ferramenta Weka Arquivo ARFF Executando o Weka via linha de comando Principais parâmetros para os algoritmos Apriori e FP-Growth no Weka Analisando resultados de Mineração de Regras de Associação geradas pelo Weka SISTEMA DE APOIO À MINERAÇÃO DE REGRAS DE ASSOCIAÇÃO Motivação Funcionalidades do Sistema Modelagem de Dados Plataforma Integração com a Ferramenta Weka Integração com Sistemas de Automação Comercial Conexão com banco de dados de outro sistema Consulta de dados de outro sistema Descrição da Ferramenta Área de Pré-Processamento Área de Mineração de Dados Área de Pós-Processamento ESTUDOS DE CASOS Considerações Iniciais Planejamento dos Experimentos de Mineração... 67

17 Bateria de Experimentos de Mineração de Dados Execução do Projeto de Mineração Análise dos Resultados do Estudo de Caso de Comércio de Produtos Veterinários Perfil das Regras de Associações encontradas Algoritmos Apriori Vesus FP-Growth Análise comparativa considerando a quantidade das regras encontraras Análise comparativa considerando a qualidade das regras encontraras Análise comparativa considerando o desempenho dos algoritmos Análise dos Resultados do Estudo de Caso de Comércio de Produtos de Controle de Pragas Perfil das Regras de Associações encontradas Algoritmos Apriori Vesus FP-Growth Análise comparativa considerando a quantidade das regras encontraras Análise comparativa considerando a qualidade das regras encontraras Análise comparativa considerando o desempenho dos algoritmos Considerações Finais Comércio de Produtos Veterinários Comércio de Produtos de Controle de Pragas Análise do Ponto de Vista do Negócio Análise do Ponto de Vista Técnico CONCLUSÕES E TRABALHOS FUTUROS Conclusões Principais Contribuições Trabalhos Futuros REFERÊNCIAS... 96

18 33 INTRODUÇÃO Contextualização Nas últimas décadas, os sistemas de computação vêm se popularizando cada vez mais e participando da vida das pessoas de forma mais intensa. Os avanços tecnológicos,tais como sistemas de banco de dados, dispositivos de memória secundária de maior capacidade de armazenamento e de menor custo, têm viabilizado o armazenamento de grandes e múltiplas bases de dados, proporcionando que pessoas das áreas de natureza governamental, corporativa, administrativa e científica promovam um crescimento explosivo em seus dados oriundos de tarefas cotidianas operacionais (SILVA, 2004; CAMARGO, 2002; GOLDSCHMIDT; PASSOS, 2005). Na área corporativa, por exemplo, as empresas vêm coletando e armazenando, de forma contínua, uma enorme quantidade de dados a respeito de seus clientes, fornecedores, produtos, vendas e serviços (GONÇALVES, 2005; AGRAWAL et al., 1993) Estes dados constituem uma mina de ouro em potencial de informações comerciais valiosas (AGRAWAL et al., 1993) que podem ser consultados por especialistas na busca de novas informações e utilizadas em benefício da organização (GONÇALVES, 2005), como vantagens competitivas, além da possibilidade, por exemplo, de conhecer o comportamento de compra de seus clientes (FUGIMOTO, 2008; JUNIOR;NIQUE, 1998). Organizações bem sucedidas vêem tal banco de dados como importante peça de marketing. Eles estão interessados em instituir processo de marketing orientado por informação e gerenciado por tecnologia de banco de dados que permita, aos profissionais de marketing, desenvolver e implementar estratégias e programas de marketing customizadas (AGRAWAL; SRIKANT, 1994). A análise desta grande quantidade de dados pelas técnicas tradicionais não se trata de uma tarefa trivial, por ser dispendiosa, subjetiva e inviável devido a grande quantidade de dados (CAMARGO, 2002; FUGIMOTO, 2008). Portanto, surge a necessidade urgente de se desenvolver novas tecnologias que auxiliem o homem, de forma

19 34 automatizada e inteligente, na tarefa de transformar dados processados em informação e conhecimento úteis (FUGIMOTO, 2008; CAMARGO, 2002), a fim de que possam se transformar em grande aliada nos processos de tomadas de decisão. Para compreender este novo contexto, surge uma área denominada de Descoberta de Conhecimento em Bancos de Dados, conhecida pela expressão em inglês Knowledge Discovery in Databases - KDD (SILVA, 2004; CAMARGO, 2002). Uma das definições mais populares do KDD foi proposta por Fayyad et al,(1996, p.40) como:... o processo não trivial de identificação de padrões válidos, novos, potencialmente úteis e compreensíveis, a partir de grandes conjuntos de dados. Onde dado é um conjunto de fatos (por exemplo, casos em um banco de dados). Padrões é uma expressão em alguma determinada linguagem, descrevendo um subconjunto de dados ou um modelo aplicado para um subconjunto. O termo processo implica que KDD compreende um conjunto de etapas que envolvem a preparação dos dados. Não trivial é uma expressão que serve de alerta para a complexidade geralmente presente na execução de processos KDD. Por padrões válidos indica que o conhecimento deve ser verdadeiro e adequado ao contexto da aplicação. Finalmente, os padrões devem ser novos, compreensíveis e potencialmente úteis, trazendo algum benefício que possa ser facilmente compreendido pelo usuário, auxiliando-o no processo de tomada de decisão (FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996, p.41; GOLDSCHMIDT; PASSOS, 2005). Muitas pessoas tratam a Mineração de Dados como um sinônimo de KDD. Na realidade, é uma das etapas essenciais no processo de descoberta de conhecimento em bases de dados (HAN;KAMBER, 2000, p.5; GOLDSCHMIDT; PASSOS, 2005). Ao definir os passos do KDD, Han e Kamber (2000, p.7) resume Mineração de Dados como um processo essencial, onde métodos inteligentes são aplicados, em ordem, para extrair padrões de dados. Um dos padrões mais comuns que pode ser descoberto a partir do processo de Mineração de Dados é um conjunto de Regras de Associação que representa combinações de itens que ocorrem simultaneamente com determinada freqüência em uma base de dados (GONÇALVES, 2005).

20 35 Um típico exemplo de regras de associação é a análise de transações de compras (market basket analysis), que foi formulado por Agrawal et. al.(1993). Este processo analisa hábitos de compras de clientes, buscando associações entre os diferentes itens que colocam em suas cestas de compras. Para exemplificar a importância da descoberta de tais associações, considere a seguinte situação e considerações apresentadas por Han e Kamber(2000, p.225): se clientes estão comprando leite, qual a probabilidade deles também incluírem pão na mesma lista de compras? Esta informação pode levar ao aumento das vendas, ajudando os varejistas a fazerem análise de marketing, planejando o conteúdo de suas prateleiras. Por exemplo, colocando leite e pães próximos podem incentivar ainda mais a venda destes itens juntos. Na área de comércio varejista, a aplicação de ferramentas de descoberta de regras de associação pode ter relevante utilidade para compreender melhor o comportamento do cliente, a determinação do layout da loja, a fim de incentivar a compra de produtos em conjunto na mesma lista de compras e a determinação de produtos sujeitos a promoção (permitindo assim a renovação destes no estoque) e, ainda, fornecer suporte aos processos de tomada de decisão (BERRY; LINOFF, 1997 apud CAMARGO, 2002). Problemas Identificados Apesar da existência de técnicas e ferramentas de mineração de regras de associação, muitas organizações ainda desconhecem a importâncias destas tecnologias no apoio à tomada de decisão. Este problema pode estar relacionado à dificuldade da utilização de ferramentas de forma mais simples e dos benefícios relacionados ao apoio a tomada de decisão. Um outro problema a ser considerado são as dificuldades encontradas da etapa de pósprocessamento. Os algoritmos de extração de regras de associação geralmente produzem milhares de regras, dificultando a compreensão dos modelos extraídos e a identificação de um possível conhecimento interessante (FUGIMOTO, 2008, Pag. 2). Neste contexto faz-se necessário recursos para o pós-processamento que possibilite filtrar e ordenar regras a partir de parâmetros e indicadores relevantes para o tipo de conhecimento desejado.

21 36 Objetivo Geral O objetivo principal deste trabalho é projetar, implementar e avaliar um sistema de apoio a decisão que auxilie o usuário final no processo de mineração de regras de associação. Objetivos Específicos Desenvolver uma ferramenta que permita que um usuário possa extrair regras de associação a partir de conjunto de dados armazenados na base de um sistema de automação comercial, sem necessitar de conhecimentos avançados em informática. Conceber um mecanismo que permita a gravação na base de dados de todas as informações de processamentos e as respectivas regras encontradas. Disponibilizar uma área de pós-processamento que se possa ordenar e filtrar as regras interessantes, baseado nas métricas Suporte, Confiança, Lift e RI. Disponibilizar no sistema duas opções de algoritmos para regras de associação para que se possa utilizar o que melhor se adequar aos tipos de dados que se deseja minerar. Metodologia Foi realizada uma revisão bibliográfica sobre o problema da descoberta de regras de associação em bancos de dados e selecionados dois dos algoritmos mais utilizados para este tipo de tarefa. Objetivando compreender melhor o funcionamento destes algoritmos e seus respectivos parâmetros disponíveis na ferramenta Weka, foram realizados experimentos em duas etapas distintas: a primeira com um conjunto de dados contendo apenas 7 (sete)

22 37 atributos e 9 (nove) transações de vendas, dados expressivamente pequenos para facilitar o entendimento dos resultados exibidos a cada alteração de parâmetro. A segunda etapa foi realizada com um conjunto de dados reais contendo 139 (cento e trinta e nove) atributos e 618 (seiscentos e dezoito) transações de vendas. Para esta segunda etapa, foram realizados vários experimentos sobre este conjunto de dados, visando encontrar pontos críticos dos algoritmos estudados em relação à perda de desempenho e pesquisa das possíveis soluções para os problemas encontrados. Com base nos conhecimentos adquiridos até o momento, foi implementado um sistema de apoio à decisão denominado SAMiRA, que se integra de forma automatizada com as bibliotecas do Weka. Para esta integração tornar-se automatizada, foi necessário compreender o funcionamento das chamadas via linha de comando para o Weka; e interpretar e importar os resultados de processamento para o banco de dados do SAMiRA. A última etapa do desenvolvimento do SAMiRA foi disponibilizar uma área de pósprocessamento, onde o usuário possa ordenar e filtrar regras geradas através das medidas de interesse: Suporte, Confiança, Lift e RI. Para validar o SAMiRA, foram realizados estudos de casos utilizando conjuntos de dados de transações de vendas de duas lojas da COMERCIAL VET LTDA. e transações de vendas da DISTRIBUIDORA DEDETEC LTDA., empresas focadas respectivamente no comércio de produtos veterinários e produtos para controle de pragas (inseticidas e raticidas), objetivando compreender os perfis das regras destes ramos de negócios e realizar uma análise comparativa dos algoritmos de regras de associação, disponíveis através dos resultados gerados no sistema. Organização do Trabalho Este trabalho está estruturado em três partes, ou seja: Introdução, Desenvolvimento e Conclusão. Sendo o Desenvolvimento composto por 4 (quatro) Capítulos.

23 38 Introdução: faz uma contextualização a respeito de descoberta de conhecimento em bancos de dados e dos problemas encontrados. Descreve os objetivos e a metodologia utilizada. Desenvolvimento: - Capítulo 1: descreve a fundamentação teórica da área de Mineração de Dados; - Capítulo 2: descreve o sistema de apoio à decisão desenvolvido neste trabalho; - Capítulo 3: descreve o Estudo de Caso realizado com bases de dados de transações de vendas de produtos veterinários, analisando o perfil das regras geradas e uma análise comparatória dos algoritmos Apriori e FP-Growth. - Capítulo 4: descreve o Estudo de Caso realizado com bases de dados de transações de vendas de produtos de controle de pragas, analisando o perfil das regras geradas e uma análise comparatória dos algoritmos Apriori e FP-Growth. Conclusão: descreve as conclusões, principais contribuições e sugestões para trabalhos futuros.

24 39 1 FUNDAMENTAÇÃO TEÓRICA 1.1 Mineração de Dados O processo de Descoberta de Conhecimento em Banco de Dados (KDD) é utilizado para buscar padrões úteis em grandes bancos de dados e pode ser dividido em três etapas principais: pré-processamento, mineração de dados e pós-processamento. Cada uma destas etapas possui objetivos distintos aos quais serão apresentados a seguir Etapa de Pré-Processamento Esta etapa consiste de um número de diferentes estratégias e técnicas especializadas em tratar, organizar, adequar e preparar dados de forma a deixá-los mais apropriados para a Mineração de Dados (TAN;STEINBACH;KUMAR, 2009,p.53), onde a escolha da técnica está diretamente relacionada com o tipo de tarefa do KDD a ser empregada na etapa de Mineração de Dados. A qualidade dos conjuntos de dados a serem encaminhados para a próxima etapa influenciará na qualidade de modelos de conhecimentos gerados. Assim, quanto pior a qualidade dos conjuntos de dados, pior será a qualidade dos modelos de conhecimentos gerados (GOLDSCHMIDT; PASSOS, 2005, p.37). A seguir serão apresentadas algumas técnicas de pré-processamento relevantes para a tarefa de Regras de Associação Seleção de Dados Esta função é responsável por identificar e selecionar as informações dentre bases de dados existentes que devem ser consideradas na etapa de Mineração de Dados. Identificadas as informações a serem consideradas, a seleção pode ser norteada pela escolha de um ou mais atributos, que serão cláusulas chaves para segmentação de dados

25 40 ou eliminação direta de casos, objetivando a delimitação do conjunto de dados para a etapa seguinte. A título de exemplo, considere que se deseja analisar os clientes que moram em residência própria e que não sejam casados. Esta operação poderia ser executada por uma instrução de Select em SQL do tipo (GOLDSCHMIDT; PASSOS, 2005, p.27): SELECT * FROM CLIENTES WHERE TipoResidencia = P AND EstadoCivil <> C ; Limpeza Esta tarefa é responsável pela verificação de inconsistências de informações, possíveis correções de erros e preenchimento ou a eliminação de valores desconhecidos, redundantes ou que não pertençam ao domínio. Todos estes cuidados devem ser tomados de forma a não comprometer a qualidade dos modelos de conhecimento a serem extraídos na etapa de Mineração de Dados Etapa de Mineração de Dados Trata-se do núcleo do processo de descoberta de conhecimento, onde são aplicados algoritmos sobre os dados, procurando extrair novos conhecimentos que sejam úteis. Baseado nos objetivos de um processo KDD, pode-se definir o tipo de tarefa a ser executada e a expectativa que se tem com relação ao modelo de conhecimento a ser gerado. Com base nisso, o especialista em KDD tem condições de definir quais tipos de padrões devem ser abstraídos a partir dos dados (GOLDSCHMIDT; PASSOS, 2005, p.52). A escolha dos algoritmos de Mineração de Dados também pode ser definida pelos tipos de variáveis envolvidas. Alguns algoritmos possuem restrições quanto aos tipos de variáveis existentes no conjunto de dados. Para estes problemas, ou se usa um algoritmo

26 41 compatível com os tipos de variáveis, ou se tenta tornar o conjunto de dados compatível com o algoritmo desejado (GOLDSCHMIDT; PASSOS, 2005, p.54) Etapa de Pós-Processamento Esta fase envolve avaliação e interpretação das descobertas geradas pela etapa de Mineração de Dados e definição de novas alternativas de investigação dos dados. Para facilitar estas tarefas, utilizam-se técnicas de visualização que permitam a interpretação de informação vista por uma pessoa e a formação de um modelo mental das informações e percepções de novos padrões (TAN;STEINBACH;KUMAR, 2009,p.125). Grandes quantidades de informações em formato visual podem ser absorvidas rapidamente pela mente humana (TAN;STEINBACH;KUMAR, 2009,p.125). Um exemplo para esta afirmativa são as apresentações de Previsão do Tempo pelos telejornais. Ao invés de divulgarem indicadores meteorológicos, costumam mostrar imagens como a do mapa do Brasil com divisões estaduais bem definidas, destacando figurinhas bem representativas como: sol, nuvens brancas ou com chuva. Esta técnica de visualização permite que pessoas compreendam a previsão do tempo, sem precisar interpretar indicadores meteorológicos. Convêm citar algumas formas de apresentação de resultados gerados pela etapa de Mineração de Dados, tais como: árvores, gráficos, regras, planilhas e tabelas. 1.2 Regras de Associação A tarefa de regras de associação, também denominadas de regras associativas, foi introduzida em (AGRAWAL et al., 1993). No referido trabalho, foram consideradas grandes bases de dados no formato de cestas de compra com informações de transações de compras de um determinado período. Cada transação de compra consistia em itens comprados por um cliente em uma visita (AGRAWAL et al., 1993). O principal objetivo daquele trabalho era apresentar novas técnicas que apresentasse um bom desempenho na geração de regras de associação entre vários tipos de produtos das bases de dados mencionadas (GOLDSCHMIDT; PASSOS, 2005). A esse processo de

27 42 associação entre produtos comprados por um cliente em uma mesma visita à loja ficou conhecido como análise de cesta de compras (do inglês market basket analysis). Mineração de Regras de Associação pesquisa relacionamentos interessantes entre itens em um dado banco de dados, permitindo que as regras geradas sejam indicadores valiosos no processo de tomada de decisão (HAN;KAMBER,2000,p ) Definição Formal Agrawal e Srikant (1994) formalizaram o problema de Regras de Associação da seguinte forma: Seja I = {i 1, i 2,..., i m } um conjunto de literais chamados itens. Seja D = {T 1,...,T n } um conjunto de transações, onde cada transação T é um conjunto de itens tal que Ti I. Associado a cada transação existe um único identificador chamado de TID. Dizemos que a uma transação T contém X, um conjunto de alguns itens de I, se X T. Uma Regra de Associação é uma implicação na forma X Y onde X I, Y I e X Y =. A regra X Y mantida no conjunto de transações D com confiança c, se c% das transações em D que contém X também contém Y. A regra X Y tem suporte s no conjunto de transações D, se s% das transações em D contém X Y. Em X Y = convém destacar que a interseção vazia entre o X e o Y da regra assegura que não sejam extraídas regras óbvias que indiquem que um item está associado a ele próprio (GOLDSCHMIDT; PASSOS, 2005). 1.3 Medidas de Interesse Embora tarefas especializadas na etapa de pré-processamento delimitem dados a serem processados de acordo com sua relevância e tipo de conhecimento a ser extraído (por exemplo, associação, etc.), podendo reduzir a quantidade de padrões gerados, a etapa de Mineração de Dados pode ainda gerar um grande número de padrões, onde apenas uma pequena fração desses padrões será realmente interessante para um determinado usuário. Diante deste problema, faz-se necessário que um usuário (geralmente

28 43 especialista em KDD em conjunto com o especialista no domínio da aplicação), continue a limitar o número de padrões desinteressantes gerados pelo processo, utilizando para isto a especificação e aplicação de medidas de interesse (HAN;KAMBER;2000, p.156), onde elas poderão guiar ou restringir o espaço de busca, proporcionando assim uma melhor eficiência nesta tarefa ao eliminar conjuntos de padrões irrelevantes. As medidas de interesse também são essenciais na etapa de Pós- Processamento, podendo ser usadas a fim de ordenar ou filtrar os padrões gerados de acordo com o grau de interesse associados a estes padrões (GOLDSCHMIDT; PASSOS,2005,p.53). Medidas de interesse podem ser objetivas ou subjetivas Medidas de Interesse Subjetivas Pode ocorrer de uma regra possuir valores altos para uma determinada medida de interesse e não ser interessante para o analista em virtude das crenças que este especialista tenha com os dados e os modelos de conhecimento gerado. Muitas vezes uma regra é interessante para um analista, mas não é para outro. É neste contexto que se destaca a importância das medidas de interesse subjetivas (GONÇALVES, 2005; GOLDSCHMIDT; PASSOS, 2005, p.53). Um analista através de seu conhecimento do negócio pode subjetivamente descobrir muitas oportunidades de negócios a partir das regras geradas, sejam elas baseadas pela utilidade, ou ainda pelas descobertas inesperadas (CARVALHO, 2007, p.21; GONÇALVES, 2005) Medidas de Interesse Objetivas Medidas objetivas são baseadas sobre a estrutura do padrão e nas estatísticas a eles relacionados. Geralmente cada medida é associada a um limiar que pode ser controlado pelo usuário (um valor de indicador mínimo para que se a regra seja aceita). Um analista, por exemplo, pode configurar na Mineração de Dados que só é para aceitar as regras com suporte mínimo (limiar da medida de interesse suporte) de 60% e confiança mínima de 70% (limiar da medida de interesse confiança) (HAN; KAMBER, 2000, p.55).

29 44 Neste trabalho foram utilizadas as medidas de interesse objetivas: suporte, confiança, Lift e RI Suporte e Confiança Tabela 1.1 Relação de Vendas de um mercadinho em um período TID Lista de Itens T100 I2,I3, I4 T200 I1,I2,I3 T300 I2,I3,I5 T400 I1,I2,I4 T500 I1,I3,I4 T600 I2,I4,I5 A Tabela 1.1 representa 6 (seis) transações de vendas em um banco de dados D. O suporte de um item é calculado pela freqüência que ele ocorre em relação ao número total de transações do banco de dados (GOLDSCHMIDT; PASSOS, 2005, p.61), podendo ser calculado por: Onde P é de Probabilidade. Analogamente, o suporte de uma associação do tipo A B é calculado pela freqüência em que A B ocorre em relação ao número total de transações do banco de dados (GOLDSCHMIDT; PASSOS, 2005, p.61), podendo ser calculado por: A medida de interesse confiança se propõe a avaliar o quão é forte uma regra, indicando o quanto a ocorrência do antecedente de uma regra pode influenciar na ocorrência do conseqüente da regra. Em outras palavras, para a regra A B a confiança é a probabilidade condicionada da ocorrência do B (conseqüente da regra) quando A (antecedente da regra) ocorre. Pode ser calculada por: Conf(A B) = P(B A)

30 45 Tabela 1.2 Exemplo de índices de suporte e confiança Regra Sup(A) Sup(B) Sup(A B) Conf(A B) r : 1 I1 I3 3/6 = 0,5 4/6 = 0,66 2/6 = 0,33 0,33/0,5 = 0,66 r : 2 I3 I4 4/6 = 0,66 4/6 = 0,66 2/6 = 0,33 0,33/0,66 = 0,5 r : 3 I1 I2 3/6 = 0,5 5/6 = 0,83 2/6 = 0,33 0,33/0,5 = 0,66 r : 4 I4 I2 4/6 = 0,66 5/6 = 0,83 3/6 = 0,5 0,5/0,66 = 0,75 r 5: 12 I5 2/6 = 0,33 3/6 = 0,5 2/6 = 0,33 0,33/0,33 = 1 Com base nos dados da Tabela 1.1, foram gerados exemplos de índices de suporte e confiança que estão demonstrados na Tabela 1.2. Considerando os valores de suporte e confiança mínimos iguais a 30% e 65%, todas as regras passaram nestas condições. Mas será que considerando apenas estas medidas garantem a qualidade da regra? Alguns trabalhos disponíveis na literatura (HAN; KAMBER,2000,p.259; GONÇALVES, 2005) defendem e provam que não necessariamente apenas as duas medidas de suporte e confiança garantem a qualidade. Por exemplo, analisando a regra 3 (r 3 ), pode-se perceber que independente de se comprar o item I1, o item I2 já ocorre em 83% das transações. Para calcular o nível de dependência entre itens, pode-se utilizar mais algumas medidas de interesse tais como as que serão abordadas em seguida neste trabalho: Lift e RI Lift A medida de avaliação Lift (BRIN;MOTOWANI;ULLMAN, 1997), também conhecida como interest, permite eliminar regras com confiança elevada, mas com pouco interesse. Dado uma regra de associação A B, esta medida calcula o quanto mais freqüente é B quando A ocorre. O valor do Lift para A B é calculado por: Se Lift(A B) = 1, então A e B são independentes, portanto a ocorrência de A não aumenta e nem diminui a probabilidade de B ocorrer. Se Lift(A B)>1, então A e B são positivamente dependentes, assim, a ocorrência de A aumenta a probabilidade de B

31 46 ocorrer. Por fim, se Lift(A B)<1, então A e B são negativamente dependentes, ou seja, a ocorrência de A diminui a probabilidade de B ocorrer. O índice Lift varia entre 0 e e a regra fica mais interessante à medida que o valor deste índice aumenta (GONÇALVES, 2005). Seguem os cálculos de Lift para as regras contidas na Tabela 1.2: r 1 : Lift(A B) = Conf(A B)/Sup(B) = 0,66/0,66 = 1; (A e B são Independentes) r 2: Lift(A B) = Conf(A B)/Sup(B) = 0,5/0,66 = 0,75; (A e B são negativamente dependentes) r 3: Lift(A B) = Conf(A B)/Sup(B) = 0,66/0,83 = 0,79; (A e B são negativamente dependentes) r 4: Lift(A B) = Conf(A B)/Sup(B) = 0,75/0,83 = 0,9; (A e B são negativamente dependentes) r 5: Lift(A B) = Conf(A B)/Sup(B) = 1/0,5 = 2; (A e B são positivamente dependentes) Rule Interest O índice Rule Interest (RI), introduzido em Piatetsky-Shapiro(1991) e também conhecido na literatura como PS (Piatetsky-Shapiro's), Novelty e Leverage, calcula a diferença entre os valores de suporte real e suporte esperado de uma regra de associação (GOLÇALVES, 2005). O valor do RI para A B é calculado por: RI(A B) = P(A U B) P(A) * P(B) Se RI(A B) = 0 nós dizemos que A e B são independentes, portanto a ocorrência de A não aumenta e nem diminui a probabilidade de B ocorrer. Se RI(A B)>0, então A e B são positivamente dependentes, assim, a ocorrência de A aumenta a probabilidade de B ocorrer. Senão, A e B são negativamente dependentes, ou seja, a ocorrência de A diminui a probabilidade de B ocorrer (GONÇALVES;PLASTINO, 2004). O índice RI varia entre -0,25 e 0,25 e a regra fica mais interessante à medida que o valor deste índice aumenta (GONÇALVES, 2005).

32 47 r 1 : RI(A B) = 0,33 (0,5 x 0,66) = 0; (A e B são Independentes) r 2: RI(A B) = 0,33 (0,66 x 0,66) = -0,1; (A e B são negativamente dependentes) r 3: RI(A B) = 0,33 (0,5 x 0,83) = -0,08; (A e B são negativamente dependentes) r 4: RI(A B) = 0,5 (0,66 x 0,83) = -0,05; (A e B são negativamente dependentes) r 5: RI(A B) = 0,33 (0,33 x 0,5) = 0,165; (A e B são positivamente dependentes) Com base nestes resultados de Lift e RI demonstrados, pode-se concluir que apesar das regras terem atingido o limite de tolerância de suporte e confiança, apenas a regra r 1 foi considerada com os itens A e B positivamente dependentes. 1.4 Algoritmos de Regras de Associação Este tópico apresenta as principais características dos algoritmos que foram utilizados nos experimentos computacionais deste trabalho, Apriori e FP-Growth Algoritmo Apriori Atualmente, diversos algoritmos, tais como Partition, DIC, Eclat, MaxEclat se baseiam no mesmo princípio do Apriori (AGRAWAL;SRIKANT,1994), anti-monotonicidade da medida do suporte (GOLDSCHMIDT; PASSOS, 2005, p.105). De acordo com este princípio Se um conjunto de itens é freqüente, então todos os seus subconjuntos também devem ser freqüentes (TAN;STEINBACH;KUMAR, 2009,p.397). O nome do algoritmo se baseia no fato de que o algoritmo usa o conhecimento prévio das propriedades itemset freqüentes para gerar novos itemsets candidatos. Para isto ele usa uma abordagem iterativa para buscar os itemsets candidatos, onde k-itemsets são usados para explorar (k+1)-itemsets. Considere a seguinte explicação: primeiro, o conjunto de itemset freqüente 1-itemsets é encontrado. Este conjunto é chamado L 1. L 1 é usado para encontrar L 2, o conjunto freqüente 2-itemsets, que é usado para encontrar o L 3, e assim até que não tenha mais itemsets para serem encontrados. Para cada L k encontrado, faz-se necessário uma varredura completa no banco de dados (HAN;KAMBER;2000, p ). O Apriori pode ser decomposto basicamente em duas etapas: 1 Encontrar todos os conjuntos de itens (itemsets) que tenha suporte acima do suporte mínimo.

33 48 2 A partir do conjunto de itens freqüentes gerados no passo anterior, gerar regras de associação que tenham confiança acima da confiança mínima. Para fins didáticos, mais detalhes destes dois passos são apresentados a seguir. Tabela 1.3 Relação de Vendas de um mercadinho em um período TID Lista de Itens T100 I1, I2, I5 T200 I2, I4 T300 I2, I3 T400 I1, I2, I4 T500 I1, I3 T600 I2, I3 T700 I1, I3 T800 I1, I2, I3, I5 T900 I1, I2, I3 A Tabela 1.3, retirada de Han e Kamber (2000, p.232), representa 9 (nove) transações de vendas em um banco de dados D. Passo 1: Geração de conjunto de itemsets freqüente Considere que o suporte mínimo é 2 (i.e. suporte mínimo para = 2/9 = 22%). O conjunto 1-itemsets, L 1, pode então ser determinado, ou seja, 1-itemsets satisfaz o suporte mínimo. Primeira Iteração: Cada item é membro do conjunto de candidatos 1-itemsets, C 1, o algoritmo varre todas as transações em ordem para contar o número e ocorrência de cada item. Considere que o mínimo de transação aceita é 2 (i.e. suporte mínimo = 9/2 = 22%). O conjunto de 1- itemsets, L 1, pode ser determinado satisfazendo o suporte mínimo. Figura 1.1 Primeira iteração da busca por itens frequentes através do algoritmo Apriori.

34 49 Segunda iteração: Para descobrir o conjunto de itens 2-itemsets, L 2, o algoritmo usa L 1 para gerar o conjunto candidato 2-itemsets, C 2. Em seguida, as transações são varridas e são calculados os suportes de cada candidato. O conjunto de itens freqüentes 2-itemsets, L 2, é então determinado considerando o suporte mínimo permitido. Figura 1.2 Segunda iteração da busca por itens frequentes através do algoritmo Apriori. Terceira Iteração: Segue os mesmos passos, usando k-itemsets para gerar o (k+1)- itemsets! Para descobrir o conjunto de itens 3-itemsets, L 3, o algoritmo usa L 2 para gerar o conjunto candidato 3-itemsets, C 3. Em seguida, as transações são varridas e são calculados os suportes de cada candidato, mostrado na tabela do meio abaixo. O conjunto de itens freqüentes 3-itemsets, L 3, é então determinado considerando o suporte mínimo permitido. Aqui se pode basear pela propriedade anti-monotonicidade, observe que is subconjuntos {I3,I4}, {I3,I5} e {I4,I5} não são freqüentes, logo {I2,I3,I4}, {I2,I3,I5} e {I2,I4,I5} também não são. Figura 1.3 Terceira iteração da busca por itens frequentes através do algoritmo Apriori.

35 50 Quarta Iteração: Segue os mesmos passos, usando k-itemsets para gerar o (k+1)-itemsets! Para descobrir o conjunto de itens 4-itemsets, L 4, o algoritmo usa L 3 para gerar o conjunto candidato 4-itemsets, C 4. Então é gerado C 4 = {I1,I2,I3,I5} que tem ocorre apenas em uma transação, visto que o suporte mínimo permitido é 2 então o algoritmo termina tendo encontrado todos os itemsets freqüentes. Outra abordagem pode ser pela propriedade anti-monotonicidade, já que o subconjunto { I2,I3,I5} não é freqüente, logo, C 4 = Passo 2: Geração de regras de associação que tenham confiança acima da confiança mínima. Com o objetivo de exemplificar esta etapa do algoritmo, vamos considerar um dos conjuntos freqüentes gerados, l={i1,i2,i5} e descobrir quais as regras de associação podem ser geradas a partir de l.os subconjuntos não vazios de l são{i1,i2}, {I1,I5}, {I2,I5}, {I1], {I2} e {I5}. A partir destes subconjuntos. seguem as possíveis regras de associação: Regra 1: I1 I2 I5 Confiança = 2/4 = 50% Regra 2: I1 I5 I2 Confiança = 2/2 = 100% Regra 3: I2 I5 I1 Confiança = 2/2 = 100% Regra 4: I1 I2 I5 Confiança = 2/6 = 33% Regra 5: I2 I1 I5 Confiança = 2/7 = 29% Regra 6: I5 I1 I2 Confiança = 2/2 = 100% Se a confiança mínima fosse 60%, então apenas as regras 2, 3 e 6 seriam válidas. O pseudo-código e análise de complexidade do Apriori podem ser encontrados respectivamente nas referências (HAN;KAMBER, 2000, p.235) e (TAN;STREINBACH;KUMAR, 2009, p.411).

36 Algoritmo FP-Growth A geração de itens freqüentes é a parte do Apriori que demanda maior custo operacional (GOLDSCHMIDT; PASSOS, 2005, p.106), visto que para esta tarefa deve-se varrer o banco de dados a cada geração de conjunto de itens candidatos. Muitos algoritmos surgiram depois do Apriori propondo uma melhoria na geração de candidatos. Uma melhoria notável, foi o algoritmo FP-Growth ter conseguido eliminar a geração de candidatos (HAN;PEI;YIN,2000 apud WU et al., 2007,p.14), usando outra estratégia para descobrir conjuntos de itens freqüentes. Para esta tarefa, ele codifica o conjunto de dados usando uma estrutura de dados compacta denominada FP-Tree (Frequent Pattern Tree) e extrai conjuntos de itens freqüentes diretamente desta estrutura (TAN;STEINBACH;KUMAR, 2009,p.433). A construção da FP-Tree (ou árvore FP) usa uma estratégia de forma que os itens de todas as transações percorridas fiquem organizados de forma mais compacta possível, criando menos ramos possíveis na árvore. Isto se torna possível pela forma que são inseridos os itens freqüentes na árvore, onde cada transação é mapeada em um caminho da árvore. Como diferentes transações podem conter diversos itens em comum, seus caminhos podem se sobrepor, considerando que para cada caminho novo (ainda não mapeado na árvore FP) é criado um novo ramo e quanto mais os caminhos se sobrepõem, mais são aproveitados ramos existentes colaborando assim para uma maior compressão na estrutura da árvore FP. Na construção de uma árvore FP, uma primeira lida nas transações do banco de dados são levantados os valores de suporte de todos os itens existentes. Itens freqüentes são posicionados em ordem decrescente de valor de suporte, enquanto os infreqüentes são descartados. Segue uma ilustração deste primeiro passo na tabela abaixo. Tabela 1.4 Transações apresentadas por Borgelt(2005)

37 52 Na Tabela 1.4, são apresentadas transações de banco de dados (à esquerda). Na parte do meio são listados os itens com seus respectivos valores de suporte ordenados de forma decrescentemente. Por fim, à direita são listadas as transações com os itens ordenados em forma decrescente em relação ao valor de suporte e descartados os itens infreqüentes {f} e {g}, considerando, para este exemplo, que o valor de suporte mínimo igual a 3 (três). Figura 1.4 FP-Tree apresentada por Borgelt(2005) Antes de continuar a idéia da construção da árvore FP, faz-se necessária uma breve apresentação de sua estrutura. Uma árvore FP consiste em um nó raiz (nulo), ramos compostos que representam itens freqüentes e uma tabela de cabeçalho responsável por facilitar os percursos na FP-Tree. Cada nó n na árvore FP é composto por três campos distintos: nome que identifica o item, contador (número após : ) que memoriza o número de transações que compartilha o conjunto de itens formados pelo sub-ramo composto pelos nós desde a raiz até o nó n. E um ponteiro que aponta para um nó da FP-Tree com o mesmo nome do nó n (PRADO, 2005).

38 53 Continuando a construção da árvore FP para cada transação lida é testado item por item se já existe um caminho na árvore para eles. Quando não existe são criados novos ramos ou sub-ramos e setado o contador do novo nó para 1 (um), ou seja, só existe um conjunto de itens que contemplem este último nó incluído na árvore. À medida que vão encontrando caminhos já existentes para a seqüência de itens de uma transação, para cada nó sobreposto é incrementado seu contador de 1 (um). Figura 1.5 Construção de FP-Tree: Leitura das seis primeiras transações Para os itens da primeira transação não existe conjunto de itens na árvore que sobreponha nenhum destes itens, assim é criado um ramo para estes itens e iniciados seus contadores com 1 (um) Figura 1.5(a). Para os itens da segunda transação, existe caminho apenas para o item d, que é incrementado seu contador ficando d:2, para os demais itens desta transação não existe conjunto de itens na árvore que os sobreponha, assim é criado um novo sub-ramo para estes itens e iniciados seus contadores com 1 (um) Figura 1.5(b). Para os itens da terceira transação, ocorre o mesmo que na transação anterior, apenas o item d já possuía caminho na árvore, incrementando seu contador ficando d:3, para os demais itens desta transação é criado um novo sub-ramo para estes itens e iniciados seus contadores com 1 (um) Figura 1.5(c).

39 54 Para os itens da quarta transação já existe o caminho para os itens {d,b} incrementando seus contadores de 1, ficando apenas o último item c sem caminho existente, conseqüentemente é criado um sub-ramo para ele como é mostrado na Figura 1.5(d).Para os itens da quinta transação ainda não existe caminho na árvore para este conjunto de itens, assim é criado um novo ramo a partir da raiz da árvore e iniciados os contadores com 1 (um). Finalmente, na sexta transação já se pode identificar caminhos para {d, b] incrementando seus contadores de 1(um) e ficando necessário apenas criar um novo sub-ramo para o item a. O algoritmo de construção da FP-Tree continua usando a mesma lógica até a leitura da última transação. Em virtude da ordenação dos itens de forma decrescente de valor de suporte, cria-se uma tendência de os itens de transações com maior número de ocorrência na árvore fique nos ramos de forma Top-Down, conseqüentemente contribui para que sejam mais bem aproveitadas as estruturas das árvores FP de forma que fiquem mais compactas. Depois que a FP-Tree é criada, o algoritmo FP-Growth utiliza-se dela explorando-a de baixo para cima (Bottom-Up). O algoritmo encontra todos os conjuntos de itens freqüentes, terminando com um prefixo específico e empregando uma estratégia dividirpara-conquistar fracionando o problema em subproblemas menores. Assim, as árvores FP-Tree são quebradas em sub-árvores condicionadas aos sufixos de cada item encontrando os itens freqüentes relacionados a ele. FP-Growth para determinados conjuntos de dados de transação possui um melhor desempenho que o algoritmo Apriori padrão em diversas ordens de magnitude. A performance do FP-Growth é influenciada pelo fator de compactação do conjunto de dados. Assim, mesmo se tratando de um subproblema, se uma sub-árvore FP-Tree condicionada estiver cheia de prefixos, então a performance do algoritmo cai porque terá que criar um grande número de sub-problemas e realizar a fusão dos resultados por cada sub-problema. O pseudo-código do FP-Growth pode ser encontrado em Han e Kamber(2000, p.242).

40 A Ferramenta Weka Weka (Waikato Environment for Knowledge Analysis) é um pacote desenvolvido na Universidade de Waikato, na Nova Zelândia, sendo elaborado em linguagem Java e sua última versão estável é a enquanto que sua versão em desenvolvimento atual é a Este software de domínio público disponibiliza ferramentas para préprocessamento, classificação, regressão, agrupamento, regras de associação e visualização (WAIKATO, 2010). Dentre os algoritmos disponíveis para a tarefa de Mineração de Regras de Associação, que é foco deste trabalho, serão utilizados os Apriori e FP-Growth da versão Arquivo ARFF Para minerar Regras de Associação no Weka utilizando os algoritmos Apriori e FP- Growth, é necessário carregar um dataset (conjunto de dados) no padrão ARFF (Attribute-Relation Files Format), um arquivo texto (formato ASCII) que descreve uma lista de instâncias, compartilhando um conjunto de atributos. Este tipo de arquivo possui duas sessões distintas: a Header e a Data (BOUCKAERT et al, 2010, Pag. 45). A Sessão Header contém os e trata-se do primeiro comando do arquivo, que deve ser seguida de uma palavra-chave que identifique a relação. <nome da este comando deve ser seguido de um nome do atributo e seu tipo. Uma lista de atributos é declarada com uma seqüência deste comando, um para cada linha. <nome do atributo> <tipo de dados>. Onde o <nome do atributo> deve iniciar com uma letra do alfabeto e se houver espaços dentro do nome, estes devem ficar entre aspas duplas. Os <tipo de dados> podem ser de 4 (quatro) tipos atualmente suportados pelo Weka (BOUCKAERT et al, 2010, Pag. 170): 1 - numeric; - integer que é tratado como numeric; - real que é tratado como numeric;

41 nominal; 3 - string; e 4 - date; Com exceção dos tipos nominal e date, os demais são case insensitive (não há distinção entre letras maiúsculas e minúsculas). O tipo de atributo nominal, único tipo que foi utilizado neste trabalho, é definido por oferecer uma lista de possíveis valores: {<nome nominal 1>, <nome nominal 2>, <nome nominal 3>,...}. Exemplo 1.1 Demonstração do para um arquivo sexo_cliente {masculino, feminino} A Sessão Data é iniciada com o em uma linha. Este comando sinaliza que nas demais linhas abaixo serão definidas as instâncias de transações. Cada instância é representada por uma linha, seguidos pelos respectivos valores dos atributos. Estes valores para cada instância são delimitados por vírgulas. Eles devem aparecer na mesma ordem em que foram declarados os atributos na sessão Header (i.e. o valor correspondente para o 1º atributo declarado estará sempre no 1º valor de cada instância, e 2º atributo estará sempre no 2º valor de cada instância e assim por diante). Exemplo do conteúdo de um arquivo.arff no formado matricial de itens-transação Paracetamol {0, Fralda {0, PastilhaV {0, Esparadrapo {0, SoroFisiologico {0, Gazes {0, 0,0,1,0,1,0 1,0,1,0,0,0 1,1,0,1,0,0 1,1,0,1,0,1 0,0,0,0,1,0 1,1,1,0,0,1

42 57 0,1,0,1,0,1 1,1,0,1,0,1 O arquivo farmacia.arff representa um conjunto de dados referentes à venda de produtos de uma farmácia. Para cada atributo (produto) foi definido o tipo nominal podendo receber os valores 1 (um) ou 0 (zero), representando respectivamente valores binariamente sim e não. Assim, os valores dos atributos listados nas transações na sessão Data atribuem à existência ou não existência de cada produto na venda. Com base nisto, pode-se afirmar, por exemplo, que a primeira transação 0,0,1,0,1,0 indica que apenas o 3º e 5º produto foram vendidos, respectivamente, o PastilhaV e o SoroFisiologico Executando o Weka via linha de comando Existem 3 (três) modos para executar os algoritmos do Weka: Interface Gráfica do Weka; Linha de Comando e API s Java do Weka. Grande parte dos recursos do Weka é acessível em sua Interface Gráfica que oferece um ambiente propício para o usuário poder explorar as suas ferramentas e aplicações. Para usuários mais experientes é mais indicado o uso por linha de comando. Por fim, o Weka permite que suas classes sejam importadas em aplicações Java e, para esta tarefa, também há uma boa fonte de documentação de suas API s disponíveis na internet (BOUCKAERT et al, 2010). Neste trabalho foi utilizado o modo via linha de comando, pois este método permite uma integração com o sistema de apoio a decisão que será apresentado no próximo capítulo. A seguir é apresentada uma sintaxe válida para executar os algoritmos de Regras de Associação do Weka via linha de comando e suas considerações a respeito. java <alocação máxima de memória RAM> -cp <caminho completo para o arquivo weka.jar> <nome da classe> <Parâmetros> -t <caminho o arquivo.arff > [ > <caminho do arquivo de resposta>] Exemplo 1.2 Comando para o algoritmo Apriori java Xmx1024m cp c:\weka\weka37\weka.jar weka.associations.apriori N 50 t c:\weka\arff\farmacia.arff > c:\weka\regrasextraidas\resp.txt

43 58 Exemplo 1.3 Comando para o algoritmo FP-Growth java Xmx1024m cp c:\weka\weka37\weka.jar weka.associations.fpgrowth N 50 t c:\weka\arff\farmacia.arff < alocação máxima de memória RAM >: Em virtude da limitação do Weka utilizar a memória principal para a execução dos algoritmos. Se o algoritmo precisar alocar mais memória que o valor padrão, a execução será abortada com o erro de "Out of Memory error"(erro por estouro de memória). Para solucionar este problema, faz-se necessário utilizar o comando Xmx<quantidade de memória>m para alocar uma quantidade máxima (set maximum Java heap size) de memória explicitamente, onde <quantidade de memória> é a quantidade de memória em Mega Bites (MB). Nos dois exemplos dados foram setados para 1024MB de memória RAM, assim o processo java utilizado na execução do Weka poderá utilizar até 1024MB de memória principal. Caso este comando não seja utilizado, será alocado o valor padrão de 128MB (nas versões e 3.7.1). Para complementar este assunto, considere as seguintes informações: O valor padrão fica setado no arquivo RunWeka.ini que fica no diretório de instalação do Weka atribuído no parâmetro maxheap. Também existe a possibilidade de setar a alocação mínima de memória RAM (initial Java heap size) através do comando Xms<quantidade de memória>m que se for usado deve ser definido antes do comando para alocação máxima de memória RAM. Segue um exemplo de como seria: Exemplo 1.4 Alocando memória explicitamente para o processo Java java Xms512m Xmx1024m cp c:\weka\weka37\weka.jar weka.associations.fpgrowth t c:\weka\arff\farmacia.arff -cp: indica que será usado um adicional para a máquina virtual Java. <caminho completo para o arquivo weka.jar>: caminho completo para a localização do arquivo weka.jar, considerando que o pacote foi instalado no diretório c:\weka\weka37\ (no caso do Windows). Caso o caminho completo para a localização do arquivo weka.jar já esteja declarado na variável de ambiente CLASSPATH, a

44 59 utilização do comando -cp <caminho completo para o arquivo weka.jar> poderá ser dispensada. <nome da classe>: nome da classe que implementa os algoritmos de regras de associação Apriori e FP-Growth. Este nome inclui o nome dos pacotes e subpacotes onde as classes estão organizadas. Assim, a classe que implementa o algoritmo Apriori é a weka.associations.apriori e a que implementa o algoritmo FP-Growth é a weka.associations.fpgrowth. <Parâmetros>: nos exemplos 1.2 e 1.3 informados apresentaram apenas o parâmetro N, que indica o número máximo de regras que poderá ser listado. Para o comando informado nestes exemplos, poderão ser listadas até as 50 (cinqüenta) melhores regras. Para cada um dos demais parâmetros que não foram utilizados explicitamente, o Weka assume seus respectivos valores padrões. Estes parâmetros serão apresentados mais a seguir no tópico <caminho o arquivo.arff >: caminho onde o arquivo.arff se encontra. > <caminho do arquivo de resposta>: opcionalmente pode-se utilizar o comando composto pelo sinal de maior ( > ) seguido do caminho de um de arquivo a qual se pretende armazenar a resposta do processamento conforme no Exemplo 1.2. Caso não seja informado este comando, a saída do processamento será apresentada na saída de vídeo Principais Parâmetros para os algoritmos Apriori e FP-Growth no Weka Considere os seguintes parâmetros a seguir e suas respectivas funções: -M indica o valor mínimo para suporte para consideração da regra. -U indica o valor máximo para suporte para consideração da regra. -T indica a métrica de ordenação (e filtragem) das regras: -T 0 ordena pela métrica confidence (Confiança). -T 1 ordena pela métrica Lift. -T 2 ordena pela métrica leverage (RI).

45 60 -T 3 ordena pela métrica conviction (Convicção). -C indica o valor mínimo da métrica de ordenação. Estes parâmetros influenciam diretamente na geração de Regras de Associação, utilizados na calibragem da mineração em busca das regras mais interessantes. Exemplo 1.5 Comando para algoritmo Apriori com seus princiais parâmetros java -Xmx512m cp c:\weka\weka37\weka.jar weka.associations.apriori N 20 T 1 C1.1 M 0.5 U 0.9 t c:\weka\arff\farmacia.arff Exemplo 1.6 Comando para algoritmo Apriori com seus princiais parâmetros java -Xmx512m cp c:\weka\weka37\weka.jar weka.associations.fpgrowth N 20 T 1 C 1.1 M 0.5 U 0.9 t c:\weka\arff\farmacia.arff Significados dos parâmetros para os últimos exemplos (Exemplos 1.5 e 1.6): - Poderão ser alocados até 512MB de memória RAM ( Xmx512m). - Poderão ser apresentadas até 20 regras (-N 20). - Estão setados para usar a métrica Lift (-T 1). - Valor mínimo da métrica de ordenação é 1.1 (-C 1.1). - O limite inferior do suporte mínimo é 0.5 (-M 0.5). - O limite superior do suporte mínimo é 0.9 (-U 0.9). Figura 1.6 Comando Weka via linha de comando utilizando o algoritmo FP-Growth Analisando resultados de Mineração de Regras de Associação geradas pelo Weka

46 61 Como já foi visto o resultado na mineração pode ser impresso na saída de vídeo ou em um arquivo texto. Considere um resultado de mineração apresentado na figura abaixo para análise: Figura 1.7 Resultado da mineração de regras de associação utilizando o algoritmo FP-Growth através do comando apresentado na Figura 1.6 Como resultado do comando apresentado na Figura 1.6, considerando os critérios exigidos pelos parâmetros T, -C, -M e U, que restringem as regras desejadas para Lift com valor mínimo de 1.1, Suporte Mínimo entre 0.5 e 0.9, foram encontradas apenas 6 (seis) regras. Alguns pontos de interesse nas regras listadas na Figura 1.7 são: A parte da regra anterior ao símbolo => é o lado antecedente da regra e a parte posterior, refere-se ao lado conseqüente da regra. Nota: Para a regra 1. o lado antecedente é o Fralda e o conseqüente é o Gazes. As abreviações conf, lift, lev e conv significam respectivamente as seguintes medidas de interesse objetivas: Confiança, Lift, RI e Convicção. Os valores que aparecem depois do conjunto de itens do lado antecedente da regra se refere ao número de instâncias ou ocorrência deste conjunto, e os valores que aparecem após o conjunto de itens do lado conseqüente é o número de instâncias ou ocorrências da regra. Nota: Para a regra 1. O conjunto de itens do lado antecedente, composto apenas pelo item Fralda, ocorreu 5 (cinco) vezes e enquanto que a regra ocorreu 4 (quatro) vezes.

47 62 Os valores que aparecem após cada item das regras representam a existência ou não existência do item, podendo representar regras positivas ou negativas. Esta representação vai depender da declaração dos valores que os atributos podem receber no arquivo.arff. No caso definido no conjunto de dados apresentado no farmacia.arff, por exemplo, foram utilizados os valores para atributos positivos igual a 1 (um) e para atributos negativos iguais à 0 (zero), mas poderia ser qualquer outra representação como sim e não ou true e false, etc. Para as regras apresentadas na Figura 1.7, todos os atributos são positivos, ou seja, todas são regras positivas. Considere um exemplo hipotético do que seria uma regra negativa: 10. SoroFisiologico=0 4 = PastilhaV=0 4 conf:(1) < lift:(2)> lev:(0.25) [2] conv:(2) Pode-se observar neste exemplo que os valores após cada item são iguais a 0 (zero), valor definido para representar a ausência do item. Assim, a regra poderia ser lida da seguinte forma: Se SoroFisiologico não foi comprado então PastilhaV também não foi comprada.

48 63 2 SISTEMA DE APOIO À MINERAÇÃO DE REGRAS DE ASSOCIAÇÃO Este capítulo apresenta o Sistema de Apoio à Mineração de Regras de Associação desenvolvido. Serão abordadas as principais funcionalidades implementadas e integração com o Weka. Na Seção 2.1 são discutidas as necessidades e os objetivos da existência do sistema integrado para mineração de regras de associação. Na seção seguinte, 2.2, são apresentadas as principais funcionalidades do SAMiRA. Na Seção 2.3 é apresentada a modelagem de bancos utilizada pelo software de mineração. Na Seção 2.4 é apresentada a plataforma de desenvolvimento do sistema. Na Seção 2.5 é apresentada a integração com a ferramenta Weka. Logo a seguir na Seção 2.6 são apresentadas informações técnicas sobre como integrar o SAMiRa com sistemas de automação comercial. Por fim, na Seção 2.7, é realizada uma demonstração da execução das principais funcionalidades desenvolvidas. 2.1 Motivação Um dos objetivos principais deste trabalho é fornecer ao analista de negócio a possibilidade de executar um projeto de mineração de regras de associação de forma intuitiva a partir de uma interface amigável, permitindo assim os especialistas de negócios realizarem esta tarefa sem a necessidade de um aprofundamento em conhecimento de informática. Um dos pontos críticos neste contexto são os requisitos de conhecimento de informática, tais como: a implementação de algoritmos para mineração de dados e operacionalização com os sistemas envolvidos. O SAMiRA traz uma proposta de facilitar a interação entre os especialistas e a execução de projetos de mineração de regras de associação, simplificando assim o processo de

49 64 tomada de decisões. Permitindo abstrair a utilização de bibliotecas do Weka de forma transparente para o usuário, onde o sistema se encarrega de realizar toda a comunicação com as bibliotecas, realiza a importação das regras extraídas e suas respectivas medidas de interesse objetivas Suporte, Confiança, Lift e RI para um banco de dados próprio do SAMiRA. Além de facilitar a apresentação das regras extraídas a partir de recursos de pós-processamento. 2.2 Funcionalidades do Sistema Figura 2.1 Diagrama de Caso de Uso do SAMiRA. A Figura 2.1 apresenta um diagrama de casos de uso que especificam o comportamento do sistema ou parte(s) dele e descrevem as funcionalidades do sistema desempenhadas pelos atores. Seguem algumas considerações a respeito dos casos de uso levantados: Gerar arquivo de vendas: trata-se da geração do arquivo.arff através da área de Pré- Processamento, em que o usuário informa o período de vendas que deseja minerar e

50 65 comanda a geração do arquivo.arff com o conjunto de dados das transações do período escolhido. Processar mineração: como pré-requisito, o usuário deve informar os parâmetros de processamento na área de Mineração de Dados e comandar o processamento da mineração. A partir deste momento, o Weka, representado pelo Ator Weka, assume a execução desta tarefa de processar a mineração. Consultar resultado processamento de mineração: após os processamentos realizados pelo Ator Weka, o SAMiRA importa todos os dados de resposta da mineração, permitindo assim que estes sejam consultados na área de Pós-Processamento do sistema. Esta funcionalidade permite consultar todos os processamentos realizados e suas respectivas regras (caso existam). Filtrar Regras por Medidas de Interesse Objetivas: uma das funcionalidades existentes na área de Pós-Processamento é a de filtro por medidas de interesse objetivas disponíveis no sistema (Suporte, Confiança, Lift e RI), em que o usuário pode informar o valor mínimo dos indicadores a ser considerado no filtro. Ordenar Regras por Medidas de Interesse Objetivas: funcionalidade existente na área de Pós-Processamento que permite ao usuário ordenar as regras de associações pelas medidas de interesse objetivas (Suporte, Confiança, Lift e RI), podendo a ordenação ser realizada por apenas uma medida de interesse ou mais de uma, através de uma ordem de prioridades. Filtrar Regras por Itens existentes nas regras: recurso que permite ao usuário realizar uma descoberta de conhecimento dirigida, ou seja, o usuário pode solicitar que sejam apresentadas apenas as regras que contenham um dos itens previamente selecionados por ele através de uma listagem de itens. Gerar Relatório de Regras de Associação: após a realização de consultas, o usuário pode solicitar ao SAMiRA que gere um relatório de regras considerando todos os filtros e ordenações informados pelo usuário.

51 Modelagem de Dados Toda solicitação de processamento realizado pelo SAMiRA, inicia-se com a fase em que são informadas as entradas de parâmetros de mineração, conjunto de dados a ser processado e algoritmo de mineração de regras de associação a ser utilizado. Como resultado deste processo é gerada uma resposta de processamento com um conjunto de regras extraídas, suas respectivas medidas de interesse objetivas e o tempo de processamento. Visando a possibilidade de consultar todos estes dados de resposta de forma simples, visualizando o incremento de recursos como filtros e ordenações de indicadores relevantes no processo de tomada a decisão, fez-se necessário uma modelagem de dados para o armazenamento destes dados. Seguem as principais tabelas envolvidas deste sistema: Tabela 2.1 Descrição da tabela de Tipos de Métricas TipoMetrica Nome do Campo Descrição do Conteúdo Tipo de Dado Tamanho Id Código do Tipo de Métrica Inteiro 4 Descricao Descrição da Métrica String 10 Tabela 2.2 Descrição da tabela de Algoritmos Algoritmos Nome do Campo Descrição do Conteúdo Tipo de Dado Tamanho Id Código do Algoritmo Inteiro 4 Descricao Descrição do Algoritmo String 10 Tabela 2.3 Descrição da tabela de Processamentos Processamentos Nome do Campo Descrição do Conteúdo Tipo de Dado Tamanho Id Código do Processamento Inteiro 4 IdAlgoritmo Código do Algoritmo Inteiro 4 IdTipoMetrica Código do Tipo de Métrica Inteiro 4 MetricaMin Valor Mínimo da Métrica Numérico 8 SupMin Lim. Inferior do Suporte Numérico 8 SupMax Mínimo Lim. Superior do Suporte Numérico 8 TempoExecucao Mínimo Tempo do Processamento Numérico 8 QtdeAtributos Quantidade de Atributos Inteiro 4 QtdeTransacoes Quantidade de Transações Inteiro 4 Notas Notas do Usuário String 255 DataHora Data e Hora do Início Data e Hora 8 ComandoWeka Processamento Comando enviado p/ o Weka String 255

52 67 Tabela 2.4 Descrição da tabela de Regras Regras Nome do Campo Descrição do Conteúdo Tipo de Dado Tamanho Id Código da Regra Inteiro 4 IdProc Código do Processamento Inteiro 4 Descricao Descrição da Regra Gerada String 200 LadoAntecedente Descrição do lado String 200 LadoConsequente Antecedente Descrição do lado String 200 TamItemSetsAntecedente Conseqüente Tamanho itemset do antec. Inteiro 4 TamItemSetsConsequente Tamanho itemset do antec. Inteiro 4 FeqAntecedente Freqüência do Antecedente Inteiro 4 FeqRegra Freqüência da Regra Inteiro 4 SupAntecedente Suporte do lado Numérico 8 SupRegra Antecedente Suporte da Regra Numérico 8 Conf Confiança da Regra Numérico 8 Lift Valor da Lift da Regra Numérico 8 RI Valor do RI da Regra Numérico 8 Conv Convicção da Regra Numérico 8 Tabela 2.5 Descrição da tabela de Itens da Regra Regras_Itens Nome do Campo Descrição do Conteúdo Tipo de Dado Tamanho IdRegra Código da Regra Inteiro 4 IdProc Código do Processamento Inteiro 4 DescricaoItem Descrição do Item String 255 Ordem Ordem dos Itens na Regra Inteiro 4 FladSimNao Flag se existe ou não o Item Booleano 1 LadoRegra A Antec. ou C - Conseq. String Plataforma Como Sistema Gerenciador de Banco de Dados tem-se o Microsoft SQL Server 2005 Express Edition, que é uma versão gratuita do SQL Server Como linguagem de desenvolvimento foi utilizado o Object Pascal através da IDE Borland Delphi 7.

53 Integração com o Weka Na Seção foi visto que existem 3 (três) modos para executar os algoritmos do Weka: Interface Gráfica do Weka; Linha de Comando e API s Java do Weka. Considerando que o SAMiRA foi desenvolvido em Delphi, foi adotado uma estratégia de integração automatizada através de linha de comando, onde o SAMiRA faz toda esta comunicação de forma transparente para o usuário do sistema. Nesta seção é apresentada uma ilustração da integração em questão, seguida de uma explicações sobre esta arquitetura proposta. Figura 2.2: Abstração da Integração SAMiRA Versus Weka. A Figura 2.2 apresenta uma abstração da integração do SAMiRA com o Weka, onde este intercâmbio ocorre na etapa de Mineração de Dados disponível no sistema de apoio a decisão apresentado. Para compreender melhor o funcionamento da integração, considere o seguinte diagrama de atividades seguidas de explicações:

54 69 Figura 2.3 Diagrama de Atividades da Integração do SAMiRA vesus Weka A Figura 2.3 apresenta um diagrama de atividade que representa o fluxo de eventos que caracterizam a integração do SAMiRA com o Weka, exatamente o que acontece entre a escolha dos parâmetros de mineração até a gravação dos resultados do processamento da mineração, demonstrando, ainda, os responsáveis por cada tarefa dentro do fluxo. O fluxo inicia quando o SAMiRA lê os parâmetros de mineração informados pelo usuário, que são utilizados para montar o comando de mineração compreendido pelo Weka e solicita via linha de comando que este processe a mineração. Neste momento, o Weka realiza a tarefa de processar a mineração de regras de associação e ao final gera um arquivo de resposta. O SAMiRA, ao identificar que foi gerado o arquivo de resposta da mineração, realiza uma interpretação do mesmo, armazenando dos dados em Objetos, instâncias das classes de processamento e regras. Após este último passo, o SAMiRA grava os parâmetros utilizados no processamento e o tempo utilizado para a

55 70 realização do processamento. Por fim, o SAMiRA encerra o fluxo após gravar os dados das regras extraídas (caso existam), as regras e suas respectivas medidas de interesse objetivas (Suporte, Confiança, Lift e RI). 2.6 Integração com Sistemas de Automação Comercial O SAMIRA permite a integração com sistemas de automação comercial, dependendo de compatibilidades tecnológicas de banco de dados. A idéia da integração é permitir que um usuário possa, através da área de Pré-Processamento do SAMiRA, selecionar conjuntos de dados oriundos do sistema de automação comercial de forma simples, sem precisar de conhecimentos avançados em informática. A configuração da Integração está dividida em duas partes: a conexão com o banco de dados de um sistema de automação comercial e criação de consultas de dados deste sistema Conexão com o banco de dados de outro sistema A configuração da conexão com o banco de dados do sistema de automação comercial é realizada através do arquivo CxIntegracao.udl, que fica na mesma pasta do executável do SAMiRA. Um arquivo com a extensão UDL (Universal Data Link) armazena informações necessárias para uma conexão com um banco de dados, tais como: o nome do servidor, o provedor utilizado, o método de segurança e o login a ser utilizado. Segue um exemplo de conexão com um banco SQL Server 2005 Express Edition.

56 71 Figura 2.4 Configuração UDL - Lista de Provedores de Banco de Dados A Figura 2.4 apresenta uma lista de provedores para SQL Server, ODBC, Oracle, dentre outros. São exatamente estas opções de conexão que permitirão ou não a integração com o banco de dados do sistema de automação comercial. Algumas opções, como a do banco de dados conhecido como MySql, só aparecerão na relação quando forem instalados no computador. Para o exemplo mostrado na Figura 2.4 foi utilizada a opção SQL Native Client, que provê conexão com SQL Server 2005 Express Edition.

57 72 Figura 2.5 Configuração UDL Dados para conexão com Banco de Dados A Figura 2.5 apresenta os campos necessários para uma conexão com o banco de dados, tais como: a Fonte de Dados (nome do servidor); usuário e senha; e o nome do banco de dados Consulta de dados de outro sistema Uma vantagem da Integração com outro sistema é simplesmente um usuário poder informar apenas um período de transações de vendas através da interface do SAMiRA e deixar que este se encarregue de consultar a base de dados configurada para gerar um conjunto de dados para mineração no formato.arff. Após configuração da conexão com o banco de dados de outro sistema, faz-se necessário preparar consultas em seu banco de dados e integrar o nome de campos chaves através de alias (apelidos).

58 73 A rotina de geração do arquivo.arff utiliza três conjuntos de dados. Para obtê-los, é necessário configurar três consultas distintas. São elas: a Primeira Consulta, que deve trazer a relação de itens a ser minerada, em que apenas os campos de identificação e descrição do item devem ser apresentados; a Segunda Consulta, que deve trazer a relação de agrupamentos de transações com seus respectivos itens, obrigatoriamente ordenados pelo campo de identificação da transação, onde apenas os campos de identificação da transação e identificação dos itens devem ser apresentados; e a Terceira Consulta, que deve trazer a relação de transações distintas, em que esta consulta servirá apenas para saber a quantidade de transações existentes através da quantidade de registros, assim, os campos apresentados aqui não serão utilizados, ficando a critério do usuário a escolha dos mesmos. Os parâmetros referentes à Data Inicial e Data Final deverão ser representados respectivamente por :dtinicio e :dtfim, dois pontos seguidos dos nomes dtinicio e dtfim, para que o SAMiRA substitua pelas datas informadas pelo usuário a área de Pré- Processamento. Segue um exemplo de utilização dos parâmetros de intervalo de dias logo abaixo: Exemplo: Where DataVenda between :dtinicio and :dtfim. Seguem modelos de registros esperados para cada consulta. Figura 2.6 Registros modelos para a Primeira Consulta. A Figura 2.6 apresenta um modelo de como os registros de itens devem vir na consulta.

59 74 Figura 2.7 Registros modelos para a Segunda Consulta. A Figura 2.7 apresenta um modelo de como os registros de agrupamento de transações com seus respectivos itens devem vir na consulta, obrigatoriamente ordenados pelo campo de identificação da transação. Pode se observar, por exemplo, que a transação de identificação 13 (treze) possui 4 (quatro) itens com as seguintes identificações: 693, 687, 656 e 652. Das consultas comentadas, destacam-se três campos que serão utilizados pela rotina de geração do arquivo.arff. São eles: o que representa a identificação do item, o que representa a descrição do item e o que representa a identificação da transação. Para a configuração da Integração também é necessário informar o nome destes campos existentes nas tabelas do outro sistema para que o SAMiRA os conheça e assim possa utilizá-los corretamente.

60 75 Figura 2.8 Tela de Integração do SAMiRa com outro sistema. A Figura 2.8 apresenta a tela de configuração de Integração com um exemplo. 2.7 Descrição da Ferramenta O Sistema de Apoio à Mineração de Regras de Associação está dividido em 4 (quatro) áreas, são elas: área de Pré-Processamento, de Mineração de Dados, de Pós- Processamento e de configurações. Nesta seção será realizada uma demonstração da utilização das funcionalidades do SAMiRA, pautadas dentro das áreas referentes às etapas do KDD. Para não generalizar o tipo de negócio a ser minerado, será considerada uma mineração de regras de associação referentes a dados de transações de vendas Área de Pré-Processamento A obtenção do conjunto de dados a serem preparados para a Etapa de Mineração de Dados, pode ser dada de duas formas:

61 76 1ª A partir de dados de um outro sistema previamente configurado para se integrar com o SAMiRA. Este consulta a base de dados do outro sistema e converte num conjunto de dados no formato.arff para regras de associação. 2ª A partir da criação de um conjunto de dados no formato.arff para regras de associação, gerado por outra ferramenta ou manualmente. Figura 2.9 Área de Pré-Processamento do SAMiRA Para exemplificar a geração de um conjunto de dados no formato.arff através do SAMiRA, considere a Figura 2.9 Inicialmente o SAMiRA está conectado ao banco de dados de um sistema de automação comercial integrado e a partir da área de Pré- Processamento deve-se seguir os seguintes passos: 1 - Informar o período das transações de vendas. No exemplo foi informado o período do mês de março de 2010; 2 Informar o caminho do arquivo.arff, que será criado com o conjunto de dados selecionados no passo anterior; 3 Clicar no botão Gerar arquivo.arff. Neste último passo o SAMiRA realiza uma consulta na bases de dados do sistema de automação comercial e seleciona os dados necessários para a geração do arquivo.arff, que são as transações de vendas e os produtos vendidos nestas transações. O comando de consulta de dados, além de selecionar apenas as transações dentro do período informado, realiza alguns tratamentos de seleção e eliminação de dados, retornando apenas os dados relevantes para a etapa de mineração.

62 77 Lembrando que na indisponibilidade da integração do SAMiRA com outro sistema, o conjunto de dados no formato.arff, necessário para a etapa de Mineração de Dados, poderé ser gerado por outra ferramenta ou manualmente Área de Mineração de Dados Utilizando-se dos conjuntos de dados disponibilizados na etapa anterior em formato.arff é possível avançar para a etapa de mineração de dados. Figura 2.10 Área de Mineração de Dados do SAMiRA Para exemplificar a chamada da mineração de dados dos conjuntos de dados contidos nos arquivos.arff através do SAMiRA, considere a Figura Através dos controles referentes à Mineração de Dados seguem os seguintes passos:

63 78 1 A área de Pré-Processamento deve informar o caminho do arquivo.arff gerado. É exatamente este conjunto de dados que será minerado. 2 Na área de Mineração de Dados deve-se informar os seguintes parâmetros: Algoritmo, Suporte Mínimo (-M), Suporte Máximo (-U), Tipo de Métrica (-T), Métrica Mínima (-C), Quantidade Máxima de Regras a ser considerada (-N) e opcionalmente alterar a quantidade de Memória RAM a ser alocada no processamento (por padrão está 1024 MB) e, opcionalmente, informar qualquer anotação referente ao processamento. No exemplo ilustrado na Figura 2.10 foram considerados os seguintes parâmetros para ser minerado pelo algoritmo FP-Growth: suporte mínimo variando de 0,01 à 1.0, (isto é, de 1% à 100%), o índice Lift com o valor mínimo igual a 1.1 e solicitado para retornar até (dez mil) regras. 3 Finalmente, o último passo se resume a clicar no botão Processar Mineração. Após este último passo, o sistema irá passar todos os parâmetros para as bibliotecas do Weka e aguardar o retorno do processamento. Após o fim do processamento, o SAMiRA irá gravar todas as informações do processamento (parâmetros utilizados, tempo de execução, notas informadas pelo usuário, dentre outras informações) e as regras encontradas (se houver) em sua base de dados. Nos casos de exceções, como as de não encontrar nenhuma regra, ou de o processamento ser cancelado pelo usuário, ou ainda do processamento ser interrompido em virtude de estouro de memória RAM, o sistema irá gravar os dados do processamento com uma observação referente ao evento encontrado, respectivamente: ATENÇÃO: SEM REGRAS!, CANCELADO PELO USUÁRIO!, ATENÇÃO: ESTOURO! Área de Pós-Processamento Como já foi mencionado, todos os dados de processamentos e respectivas regras de associações, casos existam, são gravados na base de dados do SAMiRA, permitindo assim diversas formas de visualizações.

64 79 Figura 2.11 Área de Pós-Processamento do SAMiRA A Figura 2.11 apresenta a área de Pós-Processamento onde são disponibilizadas recursos para consulta de todos os processamentos e suas respectivas regras existentes no banco de dados. Os dados são apresentados em duas grades, a de Processamentos e a de Regras. Na primeira são informados todos os parâmetros de mineração de regras de associação utilizados no processamento e algumas informações complementares. Quando um registro de processamento é selecionado nesta grade, todas as regras e suas respectivas medidas de interesse (Suporte, Confiança, Lift e RI) são listadas na grade de Regras. Além das consultas, a área de Pós-Processamento disponibiliza mecanismos que permite criar combinações de ordenações e filtros das regras através de suas medidas de interesse objetivas ou por itens. Através do filtro por item é possível ao usuário fazer uma descoberta de conhecimento dirigida, ou seja, o usuário poderá selecionar um ou mais itens e só serão apresentadas regras que contiverem estes itens no seu corpo, considerando ainda quaisquer filtros e ordenações por medidas de interesse configurada. Estas funcionalidades são de grande relevância para auxiliar na análise das regras geradas e, consequentemente, no processo de tomadas de decisão.

65 80 Figura 2.12 Relatório de Regras do SAMiRA A Figura 2.12 apresenta uma outra forma de visualização das regras de um determinado processamento, onde é considerado o processamento selecionado juntamente com os filtros e ordenações configurados na área de pós-processamento.

66 81 3 ESTUDOS DE CASOS 3.1 Considerações Iniciais Este capítulo apresenta dois estudos de casos de utilização da ferramenta através da execução de tarefa de mineração de regras de associação. No primeiro estudo de caso foram aplicadas essas técnicas ao Comércio de Produtos Veterinários, onde o objeto de investigação foi a COMERCIAL VET LDTA, mais especificamente os conjuntos de transações de vendas das lojas Filial 1 e Filial 2 desta empresa. No segundo estudo de caso foram aplicadas as mesmas técnicas ao Comércio de Produtos de Controles de Pragas, onde o objeto de investigação foi a DISTRIBUIDORA DEDETEC LTDA. A COMERCIAL VET atua no ramo de comércio varejista e atacadista focados na comercialização de produtos veterinários. O faturamento bruto médio mensal da loja Filia 1 gira em torno de R$ ,00 (um milhão e meio de reais) enquanto o da loja Filial 2 gira em torno de R$ ,00 (duzentos e quinze mil reais). A DISTRIBUIDORA DEDETEC atua no ramo de comércio atacadista focado na comercialização de raticidas e inseticidas e possui um faturamento bruto médio mensal que gira em torno de R$ ,00 (oitenta e dois mil reais). Ambas as empresas possuem suas atividades operacionais conduzidas de forma empírica, através do feeling, e apoiadas em relatórios gerenciais disponibilizados pelo sistema de automação comercial utilizado, o MwVenda. Apesar da existência de um grande histórico de transações comerciais nos bancos de dados dessas empresas, essas informações não respondem a muitas perguntas relevantes que poderiam contribuir para tomada de decisão. A falta de descoberta de novos conhecimentos e informações pode estar relacionada à ausência de técnicas de Mineração de Dados e, também, à falta de uma metodologia e de ferramentas para extrair conhecimentos destes bancos de dados. Com o desenvolvimento do Sistema de Apoio à Mineração de Regras de Associação SAMiRA, e sua integração com o MwVenda, foram realizados experimentos de mineração nas bases de dados das lojas Filial 1 e Filial 2 da COMERCIAL VET LTDA e da loja matriz da DEDETEC LTDA a fim de serem identificados os tipos de regras

67 82 existentes, suas respectivas medidas de interesses mais relevantes e uma avaliação comparativa dos algoritmos de regras de associação disponíveis no SAMiRA, Apriori e FP-Growth, respectivamente para estas bases de transações de vendas de produtos veterinários e de vendas de produtos para controle de pragas. É válido salientar que apesar de já existirem no Estado da Arte comparações para estes algoritmos com bases de dados em diversas áreas de negócio, ainda não constam estas avaliações para transações dos ramos de produtos veterinários e de produtos de controle de pragas. Para a realização dos experimentos de mineração, de forma à explorar os espaços de buscas das possíveis regras existentes e organizar de forma sistemática todas as configurações e calibrações necessárias com os algoritmos de regras de associação, fezse necessário a elaboração de um planejamento para estes experimentos de mineração que será apresentado a seguir. 3.2 Planejamento dos Experimentos de Mineração Como metodologia para descoberta de Regras de Associações, nas bases de dados apresentadas, foi elaborado o seguinte planejamento a fim de auxiliar no processo de calibração dos parâmetros para a mineração. Inicialmente foram utilizados 3 (três) bancos de dados de lojas distintas, Filial 1 e Filial 2 da COMERCIAL VET e o da loja matriz da DISTRIBUIDORA DEDETEC, das quais foram preparados os seguintes conjuntos de dados apresentados na Tabela 3.1 a seguir. Tabela 3.1 Conjunto de transações referentes à vendas. Bases de Dados Conjunto de Transações de Vendas referentes ao período de: Março de 2010 Março a Maio de 2010 COMERCIAL VET - Loja Filial 1 SIM SIM COMERCIAL VET - Loja Filial 2 SIM SIM DISTRIBUIDORA DEDETEC (Matriz) SIM SIM Cada um destes conjuntos de dados passará pela Etapa de Mineração de Dados utilizando os algoritmos Apriori e FP-Growth e, para cada algoritmo, passará pela Bateria de Experimentos descrita na Seção

68 83 Figura 3.1 Abstração do Planejamento dos Experimentos Bateria de Experimentos de Mineração de Dados A Bateria de Experimentos subdivide a exploração de regras de associações por espaços de buscas delimitadas pelas medidas de interesses de suporte e Lift. Preocupando-se, inicialmente, em descobrir tendências de suporte regras de associações nas bases de dados exploradas, de forma a delimitar apenas para regras de dependências positivas através do Lift maior que 1 (um). Além de busca de regras de associação em diversos espaços de busca, os experimentos também consideram a avaliação comparativa dos algoritmos Apriori e FP-Growth para os conjuntos de dados explorados. Segue a relação dos experimentos proposta para a Bateria dos Experimentos.

69 84 1º Experimentos com parâmetros padrões da Ferramenta Weka, alterando apenas a quantidade de Regras ( N) para e Tipo de Métrica para Lift (-T 1) onde o valor padrão é 1.1: Tabela 3.2 Parâmetros do 1º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.1 U Espaço de Pesquisa: Figura 3.2 Espaço de Pesquisa do 1º Experimento Como parte das definições do planejamento de cada experimento, é apresentado um gráfico que representa seus respectivos Espaços de Pesquisa, onde são exploradas regras cujo Suporte esteja contido dentro dos Limites Inferior e Superior para o Suporte Mínimo representados pela área com tom de cinza. A Figura 3.2 representa o espaço de pesquisa para regras que variam entre os Limites de Suporte 0.1 e 1.0, ou respectivamente 10% e 100%. 2 º Experimentos com Limite Inferior para Suporte Mínimo (-M) fixado em 0.1 e Limite Superior para Suporte Mínimo (-U) variando de 0.2 a 1.0. Tabela 3.3 Parâmetros do 2º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.1 U N T 1 C 1.1 M 0.1 U N T 1 C 1.1 M 0.1 U N T 1 C 1.1 M 0.1 U N T 1 C 1.1 M 0.1 U N T 1 C 1.1 M 0.1 U N T 1 C 1.1 M 0.1 U N T 1 C 1.1 M 0.1 U

70 85 9 -N T 1 C 1.1 M 0.1 U Espaço de Pesquisa: Figura 3.3 Espaço de Pesquisa do 2º Experimento A Figura 3.3 representa o espaço de pesquisa para regras entre os Limites de Suporte 0.1 e 1.0, onde o Limite Inferior para Suporte Mínimo permanece em 0.1 e o Limite Superior para Suporte Mínimo começa com 0.2 e cresce gradativamente até º Experimentos com Limite Inferior para Suporte Mínimo (-M) variando de 0.8 a 0.1 e Limite Superior para Suporte Mínimo (-U) fixado em 0.9: Tabela 3.4 Parâmetros do 3º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.8 U N T 1 C 1.1 M 0.7 U N T 1 C 1.1 M 0.6 U N T 1 C 1.1 M 0.5 U N T 1 C 1.1 M 0.4 U N T 1 C 1.1 M 0.3 U N T 1 C 1.1 M 0.2 U N T 1 C 1.1 M 0.1 U

71 86 Espaço de Pesquisa: Figura 3.4 Espaço de Pesquisa do 3º Experimento A Figura 3.4 representa o espaço de pesquisa para regras entre os Limites de Suporte 0.1 e 1.0, onde o Limite Superior para Suporte Mínimo permanece em 0.9 e o Limite Inferior para Suporte Mínimo começa com 0.8 e diminui gradativamente até º Experimentos com Limite Inferior para Suporte Mínimo (-M) variando de 0.09 a 0.01 e Limite Superior para Suporte Mínimo (-U) fixado em 0.1: Tabela 3.5 Parâmetros do 4º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.09 U N T 1 C 1.1 M 0.08 U N T 1 C 1.1 M 0.07 U N T 1 C 1.1 M 0.06 U N T 1 C 1.1 M 0.05 U N T 1 C 1.1 M 0.04 U N T 1 C 1.1 M 0.03 U N T 1 C 1.1 M 0.02 U N T 1 C 1.1 M 0.01 U Espaço de Pesquisa: Figura 3.5 Espaço de Pesquisa do 4º Experimento

72 87 A Figura 3.5 representa o espaço de pesquisa para regras entre os Limites de Suporte 0.01 e 0.1, onde o Limite Superior para Suporte Mínimo permanece em 0.1 e o Limite Inferior para Suporte Mínimo começa com 0.09 e diminui gradativamente até º Experimentos com Limite Inferior para Suporte Mínimo (-M) fixado em 0.01 e Limite Superior para Suporte Mínimo (-U) variando de 0.02 a Tabela 3.6 Parâmetros do 5º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.01 U N T 1 C 1.1 M 0.01 U N T 1 C 1.1 M 0.01 U N T 1 C 1.1 M 0.01 U N T 1 C 1.1 M 0.01 U N T 1 C 1.1 M 0.01 U N T 1 C 1.1 M 0.01 U N T 1 C 1.1 M 0.01 U Espaço de Pesquisa: Figura 3.6 Espaço de Pesquisa do 5º Experimento A Figura 3.6 representa o espaço de pesquisa para regras entre os Limites de Suporte 0.01 e 0.1, onde o Limite Inferior para Suporte Mínimo permanece em 0.01 e o Limite Superior para Suporte Mínimo começa com 0.02 e cresce gradativamente até º Experimentos com Limite Inferior para Suporte Mínimo (-M) fixado em 0.1, Limite Superior para Suporte Mínimo (-U) fixado em 1.0 e Valor Mínimo da Métrica Lift (-C) variando de 1.1 a 50 na sequência 1.1, 10, 20, 30, 40 e 50.

73 88 Tabela 3.7 Parâmetros do 6º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.1 U N T 1 C 10 M 0.1 U N T 1 C 20 M 0.1 U N T 1 C 30 M 0.1 U N T 1 C 40 M 0.1 U N T 1 C 50 M 0.1 U Espaço de Pesquisa: Figura 3.7 Espaço de Pesquisa do 6º Experimento A Figura 3.7 representa o espaço de pesquisa para regras que variam entre os Limites de Suporte 0.1 e 1.0, onde a métrica mínima do Lift pode assumir os seguintes valores: 1.1, 10, 20, 30, 40 e º Experimentos com Limite Inferior para Suporte Mínimo (-M) fixado em 0.01, Limite Superior para Suporte Mínimo (-U) fixado em 0.1 e Valor Mínimo da Métrica Lift (-C) variando de 1.1 a 50 na sequência 1.1, 10, 20, 30, 40 e 50. Tabela 3.8 Parâmetros do 7º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.01 U N T 1 C 10 M 0.01 U N T 1 C 20 M 0.01 U N T 1 C 30 M 0.01 U N T 1 C 40 M 0.01 U N T 1 C 50 M 0.01 U

74 89 Espaço de Pesquisa: Figura 3.8 Espaço de Pesquisa do 7º Experimento A Figura 3.8 representa o espaço de pesquisa para regras que variam entre os Limites de Suporte 0.01 e 0.1, onde a métrica mínima do Lift pode assumir os seguintes valores: 1.1, 10, 20, 30, 40 e º Experimentos com Limite Inferior para Suporte Mínimo (-M) fixado em 0.01, Limite Superior para Suporte Mínimo (-U) fixado em 1.0 e Valor Mínimo da Métrica Lift (-C) fixado em 1.1. Assim serão realizadas buscas por regras de associações em todos os espaços de buscas de em um único processamento, restringindo apenas à regras com dependência positiva apoiadas pelo Lift maior que 1. Tabela 3.9 Parâmetros do 8º Experimento Seq. Parâmetros de Mineração -N -C -M -U 1 -N T 1 C 1.1 M 0.01 U Espaço de Pequisa Figura 3.9 Espaço de Pesquisa do 8º Experimento A Figura 3.9 representa o espaço de pesquisa para regras que variam entre os Limites de Suporte 0.01 e 1.0, ou respectivamente 1% e 100%.

75 Execução do Projeto de Mineração Esta seção apresenta o roteiro a ser seguido para a execução do projeto de mineração, considerando os conhecimentos e planejamentos levantados nas seções 3.1 e 3.2. Para a execução da mineração das regras de associação foi utilizado o auxílio do sistema SAMiRA rodando em um computador com processador Intel Core 2 Quad e com 4GB de memória RAM com sistema operacional Windows XP Professional x64. Os dados a serem minerados são oriundos de vendas de produtos veterinários e de produtos de controle de pragas, onde os conjuntos de dados a serem considerados na mineração de regras de associação consistem em registros de transações de vendas de um determinado período e seus respectivos itens comercializados. Para a preparação dos dados foram criadas consultas para as bases de dados apresentadas no planejamento dos experimentos de mineração, onde a seleção de dados de um determinado período pode ser realizada de forma parametrizada, informando um período entre datas de transações de vendas. Todos esses conjuntos de dados foram gerados através dos recursos da área de Pré-Processamento do SAMiRA e convertidos no formato do arquivo.arff para mineração de regras de associação. Cada um destes conjuntos de dados foi processado pelos recursos disponíveis na área de Mineração de Dados do SAMiRA, utilizando os algoritmos Apriori e FP-Growth e, para cada algoritmo, utilizando todos os parâmetros de mineração definidos pela Bateria de Experimentos planejada. Todos os resultados encontrados nos processamentos planejados foram gravados no banco de dados do SAMiRA, permitindo através da área de Pós-Processamento uma análise destes resultados, que será apresenta na seção 3.4 a seguir.

76 Análise dos Resultados do Estudo de Caso de Comércio de Produtos Veterinários As análises dos resultados foram guiadas pelos critérios de descoberta do tipo de perfil das regras encontradas nos 4 (quatro) conjuntos de dados referentes as transações de vendas de produtos veterinários e avaliação comparativa dos algoritmos Apriori e FP- Growth, considerando a quantidade de regras encontradas, suas qualidades de acordo com suas medidas de interesse objetivas e o desempenho dos algoritmos quanto ao tempo de processamento Perfil das Regras de Associações encontradas Foram pesquisadas regras através das medidas de interesse objetivas cujo espaço de pesquisa foi delimitado pelo suporte variando entre 1% à 100% e pelo índice Lift superior à 1. Foi observado que as medidas de interesse de suporte das regras encontradas variaram entre 1% e 5%, caracterizando que a venda de determinados produtos em conjunto não se repete com tanta freqüência dentro de um conjunto de transações de vendas. Estas características divergem das que geralmente ocorrem em supermercados que podem alcançar suporte na casa de 60% ou até valores superiores (GONÇALVES, 2005) Algoritmos Apriori Versus FP-Growth Conforme foi observado na seção anterior, as regras encontradas nos experimentos realizados possuíam as medidas de interesse de suporte variando entre 1% à 5%. Com base nestas informações, num primeiro momento, foi realizado um levantamento da quantidade de regras por suporte, onde foram consideradas todas as regras com o Lift maior que 1 (um) e independente do valor das medidas de interesse Confiança e RI, ou seja, independente da qualidade das regras. Estas regras estão representadas nas Figuras 3.10 e Num segundo momento estas regras foram submetidas a um filtro de qualidade pelas medidas de interesse Confiança igual ou maior a 60% e RI maior que zero. Para este

77 92 último valor reforçando o papel do índice Lift em considerar apenas as regras com dependências positivas. Estas regras estão representadas nas Figuras 3.14 e Finalizando as avaliações dos algoritmos, é apresentada e discutida uma representação gráfica comparativa dos tempos de processamento dos algoritmos por conjunto de dados conforme ilustração na Figura Análise comparativa considerando a quantidade das regras encontradas Pode-se observar no gráfico da Figura 3.10 uma comparação quantitativa de regras encontradas por cada algoritmo dentro de cada conjunto de dados do banco de dados da Filial 2, o conjunto referente à transações de vendas de março de 2010 e o conjunto referente à transações de vendas do período de março a maio de Assim como os próximos gráficos a seguir das Seções e , todos seguem a mesma representatividade das distribuições das quantidades de regras encontradas e agrupadas pelos suportes definidos na legenda. Esclarecendo esta última informação, todos os números apresentados nos blocos da cor representada pelo suporte 0,01 (1%) representam a quantidade de regras encontradas com este valor de suporte. Por exemplo, no conjunto de dados da Filial 2 referentes às transações de vendas do período de março de 2010, o algoritmo Apriori encontrou 110 (cento e dez) regras com suporte 0,01, 18 (dezoito) regras com suporte 0,02, 4 (quatro) regras com suporte 0,03, duas regras com suporte 0,04 e duas com suporte 0,05.

78 Quantidade de Regras 93 Conjuntos de Dados da Filial Apriori FPGrowth Apriori FPGrowth Vendas no Período de Março de 2010 (Transações: 618 Atributos: 139) Vendas no Período de Março a Maior de 2010 (Transações: 2032 Atributos: 338) 0,01 0,02 0,03 0,04 0,05 Classificação por Suporte de Regras Figura 3.10 Gráfico de quantidades de regras por suporte dos conjuntos de dados da Filial 2 Dentro de cada conjunto de dados da Filial 2, apenas ocorreram diferenças de quantidade de regras encontradas pelos algoritmos para as regras com 0,01 de suporte. As Figuras 3.11 e 3.12 apresentam dois relatórios de regras distintos com regras oriundas do mesmo conjunto de dados referentes às transações de vendas do mês de março de 2010 da Filial 2. O primeiro relatório apresenta as 30 (trinta) primeiras regras extraídas pelo algoritmo Apriori e o segundo relatório apresenta as 30 (trinta) primeiras regras extraídas pelo algoritmo FP-Growth. Para ambos os relatórios, as regras estão ordenadas em ordem decrescente pelas seguintes métricas: Suporte, Confiança, Lift e RI. Considerando esta sequência como ordem de prioridades.

79 94 Figura 3.11 Top 30 das Regras extraídas pelo Apriori dos dados de março de 2010 da Filial 2. Figura 3.12 Top 30 das Regras extraídas pelo FP-Growth dos dados de março de 2010 da Filial 2

80 Quantidade de Regras 95 Conjuntos de Dados da Filial Apriori FPGrowth Apriori FPGrowth Vendas no Período de Março de 2010 (Transações: 2416 Atributos: 929) Vendas no Período de Março a Maior de 2010 ( Transações: 7182 Atributos: 1575) 0,01 0,02 0,03 0,04 0,05 Classificação por Suporte de Regras Figura 3.13 Gráfico de quantidades de regras por suporte dos conjuntos de dados da Filial 1 Assim como observado dentro de cada conjunto de dados da Filial 2, o mesmo ocorreu dentro de cada conjunto de dados da Filial 1, apenas existiram diferenças de quantidade de regras encontradas pelos algoritmos para as com 0,01 de suporte Análise comparativa considerando a qualidade das regras encontradas Os dados desta fase da análise comparativa se diferem dos da seção anterior por terem passado por um filtro delimitando as regras por mais dois critérios de medidas de interesse: Confiança igual ou maior a 60% e RI maior que zero. Com isto pode-se observar nas Figuras 3.14 e 3.15 que a quantidade de regras encontradas caiu significativamente ao mesmo tempo em que teve um aumento de qualidade em virtude dos novos critérios aplicados.

81 Quantidade de Regras Quantidade de Regras Conjuntos de Dados da Filial Apriori FPGrowth Apriori FPGrowth Vendas no Período de Março de 2010 (Transações: 618 Atributos: 139) Vendas no Período de Março a Maior de 2010 (Transações: 2032 Atributos: 338) 0,01 0,02 0,03 0,04 0,05 Classificação por Suporte de Regras Figura 3.14 Gráfico de quantidades de regras por suporte dos conjuntos de dados da Filial 2 Para as comparações dentro de cada conjunto de dados da Filial 2, apenas ocorreram diferenças de quantidade de regras encontradas pelo algoritmos para as com 0,01 de suporte. Conjuntos de Dados da Filial Apriori FPGrowth Apriori FPGrowth Vendas no Período de Março de 2010 (Transações: 2416 Atributos: 929) Vendas no Período de Março a Maior de 2010 ( Transações: 7182 Atributos: 1575) 0,01 0,02 0,03 0,04 0,05 Classificação por Suporte de Regras Figura 3.15 Gráfico de quantidades de regras por suporte dos conjuntos de dados da Filial 1

82 97 Dentro dos conjuntos de dados da Filial 1, apenas ocorreram diferenças de quantidade de regras encontradas pelos algoritmos para as com 0,01 de suporte dentro do conjunto de dados referentes a transações de vendas do período de março de Para o outro conjunto de dados não ocorreu nenhuma diferença, ou seja, os algoritmos encontraram as mesmas quantidades de regras por suporte Análise comparativa considerando o desempenho dos algoritmos Para esta última etapa da análise comparativa dos algoritmos foi considerado o critério tempo de processamento dos algoritmos para cada conjunto de dados. Figura 3.16 Gráfico de tempo de processamento dos algoritmos por conjunto de dados Na Figura 3.16, logo acima, pode-se observar que os algoritmos demonstraram expressivas diferenças de tempo de processamento. Destacando-se o algoritmo FP- Growth por utilizar menos de 1 (um) segundo de tempo de execução para cada conjunto de dados, enquanto o tempo utilizado pelo Apriori variou de 2,719 e 2.879,766 segundos para processar os mesmos conjuntos de dados.

83 Análise dos Resultados do Estudo de Caso de Comércio de Produtos de Controle de Pragas As análises dos resultados foram guiadas pelos critérios de descoberta do tipo de perfil das regras encontradas nos 2 (dois) conjuntos de dados referentes a transações de vendas de produtos de controle de pragas e avaliação comparativa dos algoritmos Apriori e FP-Growth, considerando quantidade de regras encontradas, suas qualidades de acordo com suas medidas de interesse objetivas e desempenho dos algoritmos quanto ao tempo de processamento. Através da bateria de experimento, foi identificado que o único caso em que não foi possível processar regras utilizando suporte variando de 1% a 100%, ocorre quando se utiliza o algoritmo Apriori para minerar o conjunto de dados referente às transações de vendas do período de março de Isto ocorre em virtude deste processamento requerer mais memória RAM que o computador utilizado nos experimentos possui, aproximadamente 3.5 GB disponível para processamento. Assim, para que todos os algoritmos pudessem processar todos os conjuntos de dados utilizando os mesmos parâmetros de mineração de forma a permitir uma análise comparativa, foi utilizado suporte mínimo variando de 2% a 100% e o índice Lift superior a 1 (um) Perfil das Regras de Associações encontradas Obsevou-se que as medidas de interesse de suporte das regras encontradas variaram entre 1% e 21%, dentre elas encontram-se regras de associações com conjunto de itens variando de 1 (um) até 11 (onze) itens por regra Algoritmos Apriori Versus FP-Growth Conforme já observado, as regras encontradas nos experimentos realizados possuíam as medidas de interesse de suporte variando entre 2% a 21%. Com base nestas informações, num primeiro momento, foi realizado um levantamento da quantidade de regras por suporte, onde foram consideradas todas as regras com o Lift maior que 1 (um) e independente do valor das medidas de interesse Confiança e RI, ou seja,

84 99 independente da qualidade das regras. Estas regras estão representadas nas Figuras 3.17 e Num segundo momento, estas regras foram submetidas a um filtro de qualidade pelas medidas de interesse Confiança igual ou maior a 60% e RI maior que zero. Para este último, reforçando o papel do índice Lift em considerar apenas as regras com dependências positivas. Estas regras estão representadas nas Figuras 3.19 e Finalizando as avaliações dos algoritmos, será apresentada e discutida uma representação gráfica comparativa dos tempos de processamento dos algoritmos por conjunto de dados, conforme ilustração na Figura Análise comparativa considerando a quantidade das regras encontradas Os gráficos das Figuras 3.17 e 3.18 apresentam comparações quantitativas de regras encontradas por cada algoritmo dentro dos conjuntos de dados referente a transações de vendas dos períodos de março de 2010 e de março a maio de 2010, respectivamente. Assim como os próximos gráficos a seguir das Seções e , todos seguem a mesma representatividade das distribuições das quantidades de regras encontradas e agrupadas pelos suportes definidos na legenda. Esclarecendo esta última informação, todos os números apresentados representados pelo suporte 0,02 (2%) representam a quantidade de regras encontradas com este valor de suporte. Por exemplo, no conjunto de dados da DEDETEC referentes às transações de vendas do período de março de 2010, o algoritmo Apriori encontrou 2 (duas) regras com suporte 0,21 (ou 21%), 2 (duas) regras com suporte 0,16 (ou 16%) e 8 (oito) regras com suporte 0,12 (ou 12%). É importante observar que as regiões dos gráficos em que aparecem apenas os traços simbolizados pelo algoritmo FP-Growth possuem os mesmos valores do Apriori. Finalizando o comentário dos gráficos, estes só apresentam os suportes encontrados nas regras, por este motivo que os suportes 0,13 a 0,15 e os de 0,17 a 0,20 não aparecem na relação de suportes da legenda da Figura 3.17.

85 Quantidade de Regras Encontradas Quantidade de Regras Encontradas Conjuntos de Dados da DEDETEC - Março de ,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,11 0,12 0,16 0,21 Suporte das regras encontradas Apriori FPGrowth Figura 3.17 Gráfico de quantidades de regras por suporte dos conjuntos de dados da DEDETEC de março de 2010 Pode-se observar no gráfico da Figura 3.17 que há divergência de quantidades de regras encontradas pelo algoritmos apenas para o suporte 0,02 (2%), onde o Apriori encontrou (quinhentos e setenta e três mil e setecentos e noventa e quatro) regras enquanto o FP-Growth encontrou (oitenta e quatro mil e duzentos e setenta e oito) regras Conjuntos de Dados da DEDETEC - Março a Maio de ,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,11 0,12 0,13 0,18 Suporte das regras encontradas Apriori FPGrowth Figura 3.18 Gráfico de quantidades de regras por suporte dos conjuntos de dados da DEDETEC de março a maio de 2010 No gráfico da Figura 3.18, é possível verificar que os dois algoritmos encontraram as mesmas quantidades de regras por suporte.

86 Quantidade de Regras Encontradas Análise comparativa considerando a qualidade das regras encontradas Os dados desta fase da análise comparativa se diferem dos da seção anterior por terem passado por um filtro delimitando as regras por mais dois critérios de medidas de interesse: Confiança igual ou maior a 60% e RI maior que zero. Com isto pode-se observar nas Figuras 3.19 e 3.20 que a quantidade de regras encontradas caiu significativamente para as regras com menor suporte, ao mesmo tempo em que teve um aumento de qualidade em virtude dos novos critérios aplicados Conjuntos de Dados da DEDETEC - Março de ,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,11 0,12 0,16 0,21 Suporte das regras encontradas Apriori FPGrowth Figura 3.9 Gráfico de quantidades de regras por suporte dos conjuntos de dados da DEDETEC de março de 2010 Para as comparações dentro do conjunto de dados DEDETEC apresentados na Figura 3.19, apenas ocorreram diferenças de quantidade de regras encontradas pelos algoritmos para as com 0,02 (2%) de suporte.

87 Quantidade de Regras Encontradas 102 Conjuntos de Dados da DEDETEC - Março a Maio de ,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,11 0,12 0,13 0,18 Suporte das regras encontradas Apriori FPGrowth Figura 3.20 Gráfico de quantidades de regras por suporte dos conjuntos de dados da DEDETEC de março a maio de 2010 De acordo com o gráfico da Figura 3.20, dentro do conjunto de dados referente a transações de vendas do período de março a maio de 2010, os algoritmos encontraram as mesmas quantidades de regras por suporte. A Figura 3.21 apresenta um relatório com regras oriundas do conjunto de dados referente às transações de vendas do mês de março de 2010 da DEDETEC, em que são apresentadas as 30 (trinta) primeiras regras extraídas pelo algoritmo FP-Growth. As regras deste relatório estão filtradas pelas métricas Suporte mínimo maior ou igual a 0,07 e Confiança Mínima maior ou igual a 0,7, e também estão ordenadas em ordem decrescente pelas seguintes métricas: Suporte, Confiança, Lift e RI, considerando esta sequência como ordem de prioridades.

88 103 Figura 3.21 Top 30 das Regras extraídas pelo FP-Growth dos dados de março de Análise comparativa considerando o desempenho dos algoritmos Para esta última etapa da análise comparativa dos algoritmos, foi considerado o critério tempo de processamento dos algoritmos para cada conjunto de dados.

89 Tempo (Segundos) 104 Tempo de Processamento dos Algoritmos por Conjunto de Dados 5,156 6,000 4,000 2,000 0,532 0,625 0,141 Apriori FPGrowth 0,000 DEDETEC (Março de 2010) Transações: 121 Atributos: 88 DEDETEC (Março a Maio de 2010) Transações: 343 Atributos: 97 Conjuntos de Dados Figura 3.22 Gráfico de tempo de processamento dos algoritmos por conjunto de dados Na Figura 3.22, pode-se observar que os algoritmos demonstraram pequenas diferenças de tempo de processamento considerando o suporte mínimo 0,02 (2%) e suporte máximo 1,0 (100%). O único caso em que não foi possível processar regras utilizando suporte variando de 1% a 100%, quando se utiliza o algoritmo Apriori para minerar o conjunto de dados referente às transações de vendas do período de março de 2010, chegou a levar aproximadamente 50 (cinquenta) minutos antes de ser cancelado por estouro de memória RAM, enquanto o FP-Growth, com os mesmos parâmetros, conseguiu processar o mesmo conjunto de dados em apenas 1,81 segundos. 3.6 Considerações Finais Neste capítulo foram apresentados dois estudos de casos de mineração de regras de associações em ramos comerciais distintos: o de comércio de produtos veterinários e o de comércio de produtos de controle contra pragas. Suas respectivas considerações finais serão apresentadas nas seções e a seguir.