“COMOVI: UM
FRAMEWORK
PARA
TRANSFORMAÇÃO DE DADOS EM APLICAÇÕES
DE
CREDIT BEHAVIOR SCORING
BASEADO NO
DESENVOLVIMENTO DIRIGIDO POR MODELOS”
PorRosalvo Ferreira de Oliveira Neto
Tese de Doutorado
Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
ROSALVO FERREIRA DE OLIVEIRA NETO
“COMOVI: UM FRAMEWORK PARA TRANSFORMAÇÃO DE DADOS EM
APLICAÇÕES DE CREDIT BEHAVIOR SCORING BASEADO NO
DESENVOLVIMENTO DIRIGIDO POR MODELOS"
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE DOUTOR EM CIÊNCIA DA COMPUTAÇÃO.
ORIENTADOR: PAULO JORGE LEITÃO ADEODATO CO-ORIENTADORA: ANA CAROLINA BRANDÃO SALGADO
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
O48c Oliveira Neto, Rosalvo Ferreira de.
COMOVI: um framework para transformação de dados em aplicações de credit behavior scoring baseado no desenvolvimento dirigido por modelos / Rosalvo Ferreira de Oliveira Neto. – 2015.
158 f.: il., fig., tab.
Orientador: Paulo Jorge Leitão Adeodato.
Tese (Doutorado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2015.
Inclui referências e apêndices.
1. Mineração de dados. 2. Inteligência artificial. I. Adeodato, Paulo Jorge Leitão (orientador). II. Título.
006.312 CDD (23. ed.) UFPE- MEI 2016-035
Rosalvo Ferreira de Oliveira Neto
COMOVI: UM FRAMEWORK PARA TRANSFORMAÇÃO DE DADOS EM APLICAÇÕES DE CREDIT BEHAVIOR SCORING BASEADO NO DESENVOLVIMENTO DIRIGIDO POR
MODELOS
Tese apresentada ao Programa de Pós- Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Doutor em Ciência da Computação.
Aprovado em: 11/12/2015
BANCA EXAMINADORA
__________________________________________________ Prof. Dr. Geber Lisboa Ramalho
Centro de Informática / UFPE
___________________________________________________ Prof. Dr. Germano Crispim Vasconcelos
Centro de Informática / UFPE
___________________________________________________ Prof. Dr. Robson do Nascimento Fidalgo
Centro de Informática / UFPE
___________________________________________________
Prof. Dr. André Carlos Ponce de Leon Ferreira de Carvalho Instituto de Ciências Matemáticas e de Computação / USP
___________________________________________________
Prof. Dr. Carlos Manuel Milheiro de Oliveira Pinto Soares Faculdade de Economia / Universidade do Porto
Agradecimentos
Aos professores Paulo Jorge Leitão Adeodato e Ana Carolina Salgado, pelas suas orientações, paciência e por sempre acreditarem que conseguiríamos obter resultados relevantes durante a pesquisa.
Aos diretores da NeuroTech, por convencerem um de seus clientes à disponibilizar o segundo banco de dados utilizado no primeiro experimento.
Aos profissionais da NeuroTech e Serasa Experian, que participaram da enquete realizada. Aos administradores de banco de dados, Osmar Vilarim e Arthur Brendler, por realizarem o experimento com o framework proposto.
Ao professor da Univasf, Mário Godoy Neto, que disponibilizou sua disciplina para execução dos experimentos.
Aos alunos da disciplina de Banco de Dados Avançados da Univasf, que participaram da execução do segundo experimento.
Ao professor da UFPB, Raoni Kulesza, que coordenou a equipe do projeto Softex para adaptar o CoMoVi à plataforma da NeuroTech.
Aos alunos de iniciação científica, Genival Rocha e Dailton de Carvalho, por ajudarem no desenvolvimento da primeira versão do CoMoVi.
Ao Centro de Informática da UFPE, pela infra-estrutura disponibilizada e pelo alto nível acadêmico de seus professores.
Ao colega Murilo Boratto, pela ajuda com o editor do LaTex.
Ao colega Jadsonlee da Silva, pela ajuda na geração de algumas figuras em MATLAB. À minha esposa Lorena e minha filha Luana, pelo incentivo constante e compreensão das inúmeras vezes que se privaram do meu convívio para realização deste trabalho.
Resumo
A etapa de pré-processamento em um projeto de descoberta do conhecimento é custosa, em geral, consome cerca de 50 a 80% do tempo total de um projeto. É nesta etapa que um banco de dados relacional é transformado para aplicação de um algoritmo de mineração de dados. A transformação dos dados nesta etapa é uma tarefa complexa, uma vez que exige uma forte integração entre projetistas de banco de dados e especialistas do domínio da aplicação. Os frameworksque buscam sistematizar a etapa de transformação dos dados encontrados na literatura apresentam limitações significativas quando aplicados a soluções comportamentais, como Credit Behavior Scoring. Estas soluções visam a auxiliar as instituições financeiras a decidirem sobre a concessão de crédito aos consumidores com base no risco das solicitações. Este trabalho propõe um framework baseado no Desenvolvimento Dirigido por Modelos para sistematizar esta etapa em soluções de Credit Behavior Scoring. Ele é composto por um meta-modelo que mapeia os conceitos do domínio e um conjunto de regras de transformações. As três principais contribuições do framework proposto são: 1) aumentar o poder discriminatório da solução, através da construção de novas variáveis que maximizam o conteúdo estatístico da informação do domínio; 2) reduzir o tempo da transformação dos dados através da geração automática de código e 3) permitir que profissionais e pesquisadores de Inteligência Artificial e Estatística realizem a transformação dos dados sem o auxílio de especialistas de Banco de Dados. Para validar o framework proposto, dois estudos comparativos foram realizados. Primeiro, um estudo comparando o desempenho entre os principais frameworks existentes na literatura e o framework proposto foi realizado em duas bases de dados. Uma base de dados de um conhecido benchmark de uma competição internacional organizada pela PKDD, e outra obtida de uma das maiores empresas de varejo do Brasil, que possui seu próprio cartão de crédito. Os frameworks RelAggs e Validação de Múltiplas Visões Baseado em Correção foram escolhidos como representantes das abordagens proposicional e mineração de dados relacional, respectivamente. A comparação foi realizada através do processo de validação cruzada estratificada, para definir os intervalos de confiança para a avaliação de desempenho. Os resultados mostram que o framework proposto proporciona um desempenho equivalente ou superior aos principais framework existentes, medido pela área sob a curva ROC, utilizando uma rede neural MultiLayer Perceptron, K vizinho mais próximos e Random Forest como classificadores, com um nível de confiança de 95%. O segundo estudo verificou a redução de tempo proporcionada pelo framework durante a transformação dos dados. Para isso, sete times compostos por estudantes de uma universidade brasileira mensuraram o tempo desta atividade com e sem o framework proposto. O teste pareado Wilcoxon Signed-Rank mostrou que o framework proposto reduz o tempo de transformação com um nível de confiança de 95%.
Abstract
The pre-processing stage in knowledge discovery projects is costly, generally taking between 50 and 80% of total project time. It is in this stage that data in a relational database are transformed for applying a data mining technique. This stage is a complex task that demands from database designers a strong interaction with experts who have a broad knowledge about the application domain. The frameworks that aim to systemize the data transformation stage have significant limitations when applied to behavior solutions such as the Credit Behavior Scoring solutions. Their goal is help financial institutions to decide whether to grant credit to consumers based on the credit risk of their requests. This work proposes a framework based on the Model Driven Development to systemize this stage in Credit Behavioral Scoring solutions. It is composed by a meta-model which maps the domain concepts and a set of transformation rules. This work has three main contributions: 1) improving the discriminant power of data mining techniques by means of the construction of new input variables, which embed new knowledge for the technique; 2) reducing the time of data transformation using automatic code generation and 3) allowing artificial intelligence and statistics modelers to perform the data transformation without the help of database experts. In order to validate the proposed framework, two comparative studies were conducted. First, a comparative study of performance between the main existing frameworks found in literature and the proposed framework applied to two databases was performed. One database from a known benchmark of an international competition organized by PKDD, and another one obtained from one of the biggest retail companies from Brazil, that has its own private label credit card. The RelAggs and Correlation-based Multiple View Validation frameworks were chosen as representatives of the propositional and relational data mining approaches, respectively. The comparison was carried out through by a 10-fold stratified cross-validation process with ten stratified parts in order to define the confidence intervals. The results show that the proposed framework delivers a performance equivalent or superior to those of existing frameworks, for the evaluation of performance measured by the area under the ROC curve, using a Multilayer Perceptron neural network, k-nearest neighbors and Random Forest as classifiers, with a confidence level of 95%. The second comparative study verified the reduction of time required for data transformation using the proposed framework. For this, seven teams composed by students from a Brazilian university measured the runtime of this stage with and without the proposed framework. The paired Wilcoxon Signed-Rank’s Test showed that the proposed framework reduces the time of data transformation with a confidence level of 95%.
Keywords: Data Mining. Propositionalization. Relational Data Mining. Credit Behavior Scoring. Model-Driven Development.
1.1 Etapas do processo de KDD . . . 20
1.2 Metodologia de Pesquisa . . . 26
2.1 Particionamento dos dados em Credit Behavior Scoring . . . 30
2.2 Exemplo de particionamento dos dados em função do tempo . . . 31
2.3 Exemplo de um problema de classificação relacional . . . 32
2.4 Q3) Natureza da experiência . . . 33
2.5 Q2) Tempo de experiência . . . 34
2.6 Q1) Grau de instrução . . . 34
2.7 Q4) Autoavaliação do nível de conhecimento em Banco de Dados . . . 35
2.8 Q5) Autoavaliação do nível de conhecimento em Técnicas de Mineração de Dados 35 2.9 Q9) Tempo médio desta tarefa . . . 37
3.1 Abordagem proposicional . . . 40
3.2 Esquema relacional para um problema de cobrança . . . 44
3.3 Esquema dimensional do DW para um problema de cobrança . . . 44
3.4 Exemplo de granularidade ano . . . 45
3.5 Exemplo de granularidade mês e ano . . . 45
3.6 Abordagem mineração de dados relacional . . . 47
3.7 Visão geral do processo de construção de solução em PRM . . . 50
3.8 Exemplo de esquema relacional para construção de solução em PRM . . . 51
3.9 Código em ProbLog para construção de regras . . . 51
3.10 Código em ProbLog com as evidências dos dados . . . 52
3.11 Exemplo de relacionamento um para muitos . . . 53
3.12 Exemplo de relacionamento direto . . . 56
3.13 Exemplo de relacionamento indireto . . . 56
3.14 Etapas do método de validação de múltiplas visões . . . 59
3.15 Taxonomia proposta para os principais frameworks de transformação de dados . 60 4.1 Relacionamento entre modelo e meta-modelo . . . 64
4.2 Esquema relacional para ilustrar a diferença entre os tipos de junção . . . 67
4.3 Conteúdo da tabela cliente . . . 67
4.4 Conteúdo da tabela cônjuge . . . 68
4.5 Exemplo de inner join . . . 68
4.6 Exemplo de left join . . . 69
5.2 Exemplo da decomposição do sinal . . . 71
5.3 Exemplo da segmentação temporal de uma variável . . . 73
5.4 Exemplo de Esquema Relacional de Empresas do Ramo de Varejo . . . 75
5.5 Arquitetura Geral do Framework . . . 76
5.6 Hierarquia de tipos de entidades do meta-modelo . . . 77
5.7 Meta-modelo do framework proposto . . . 78
5.8 Visão geral da execução do algoritmo de transformação . . . 79
5.9 Método de utilização do framework . . . 81
5.10 Tela principal da ferramenta . . . 82
5.11 Representação gráfica dos elementos do meta-modelo . . . 83
5.12 Esquema relacional para exemplo . . . 83
5.13 Tabelas no banco de dados MySQL . . . 84
5.14 Tela de configuração da conexão com o banco de dados . . . 84
5.15 Tela de especificação do conceito . . . 85
5.16 Instância do modelo para o exemplo . . . 85
5.17 Tela de especificação do elemento RelationShip . . . 86
5.18 Tela de especificação do elemento RelationShipTemp . . . 86
5.19 Tela de especificação das janelas temporais . . . 87
5.20 Código SQL final gerado pelo framework . . . 87
5.21 Código SQL para geração da visão auxiliar . . . 88
5.22 Código SQL para geração da visão comportamenal de seis meses . . . 88
6.1 Esquema relacional do banco de dados da PKDD99 . . . 91
6.2 Esquema relacional do banco de dados da empresa varejista . . . 93
6.3 Exemplo de uma Curva ROC . . . 96
6.4 Visão geral da metodologia experimental do Experimento I . . . 98
6.5 Gráfico de dispersão da RNA - PKDD sem feature selection . . . 101
6.6 Gráfico de dispersão da RNA - PKDD com feature selection . . . 101
6.7 Gráfico de dispersão da RNA - varejo sem feature selection . . . 101
6.8 Gráfico de dispersão da RNA - varejo com feature selection . . . 102
6.9 Gráfico de dispersão do KNN - PKDD sem feature selection . . . 103
6.10 Gráfico de dispersão do KNN - PKDD com feature selection . . . 103
6.11 Gráfico de dispersão do KNN - varejo sem feature selection . . . 103
6.12 Gráfico de dispersão do KNN - varejo com feature selection . . . 104
6.13 Gráfico de dispersão da RF - PKDD sem feature selection . . . 105
6.14 Gráfico de dispersão da RF - PKDD com feature selection . . . 105
6.15 Gráfico de dispersão da RF - varejo sem feature selection . . . 105
6.18 Percentual de cada grupo entre as vinte variáveis com maior ganho de informação
gerada pelo CoMoVi no experimento com o Varejo . . . 108
6.19 Foto do primeiro dia do Experimento II . . . 110
6.20 Percentual médio do tempo por atividade . . . 111
6.21 Exemplo do relatório fornecido pelo ManicTime . . . 112
7.1 Resumo da Tese . . . 115
7.2 Diferença de tempo entre a construção da solução e sua implantação . . . 118
C.1 Modelo instanciado para o banco de dados da PKDD . . . 140
H.1 Esquema relacional do banco de dados da PKDD . . . 154
Lista de Tabelas
2.1 Q6) Você utiliza algum método/framework para sistematizar a tarefa de geração
de base de dados a partir de um banco de dados relacional? . . . 36
2.2 Q7) Qual tipo de documentação você utiliza para auxiliar nesta tarefa? . . . 36
2.3 Q8) Quais os principais erros ocorridos durante esta tarefa em soluções de Credit Behavior Scoring? . . . 36
3.1 Dados de entrada . . . 41
3.2 Resultado da transformação . . . 41
3.3 Relação Cliente . . . 42
3.4 Relação Parcela . . . 42
3.5 Relação gerada através do Relational Aggregations (RELAGGS) . . . 42
3.6 Exemplo de layout da tabela desnormalizada para o problema de cobrança . . . 46
3.7 Exemplo da propagação dos ids para a relação Conta . . . 53
3.8 Comparação de características entre frameworks . . . 61
4.1 Tipos de dados e suas características - Adaptado de (RUD,2000) . . . 66
6.1 Quantidade de registros por tabela do banco de dados da PKDD99 . . . 91
6.2 Quantidade de registros por tabela do banco de dados da empresa varejista . . . 93
6.3 Matriz de Confusão . . . 96
6.4 Parâmetros das técnicas . . . 97
6.5 Resumo dos resultados dos experimentos com RNA . . . 99
6.6 Resumo dos resultados dos experimentos com KNN . . . 99
6.7 Resumo dos resultados dos experimentos com RF . . . 100
6.8 Resumo do teste de hipóteses dos experimentos com RNA . . . 100
6.9 Resumo do teste de hipóteses dos experimentos com KNN . . . 102
6.10 Resumo do teste de hipóteses dos experimentos com RF . . . 104
6.11 Resumo da análise do aumento do poder discriminatório das novas variáveis para o banco de dados da PKDD . . . 107
6.12 Resumo da análise do aumento do poder discriminatório das novas variáveis para o banco de dados de Varejo . . . 107
6.13 Resultados experimentais do experimento II . . . 111
6.14 Resumo do teste de hipótese do experimento II . . . 111
6.15 Resultados experimentais do experimento II - Análise Conservadora . . . 112
G.1 Rank do Ganho de Informação das variáveis geradas pelo CoMoVi para o banco
de dados do Varejo . . . 152
H.1 Relação Account (4500 registros) . . . 153
H.2 Relação Client (5369 registros) . . . 154
H.3 Relação order (6471 registros) . . . 154
H.4 Relação disp (5369 registros) . . . 154
H.5 Relação Loan (682 registros) . . . 155
H.6 Relação Card (892 registros) . . . 155
H.7 Relação Trans (1056320 registros) . . . 155
Lista de Acrônimos
KDD Knowledge Discovery in Database. . . 20
OLAP Online Analytical Processing. . . 43
SC Escalabilidade . . . 32
DW Data Warehouse. . . 41
ILP Indutive Logic Program. . . 39
FOIL First-order Inductive Learner. . . 48
PRM Probalistic Relational Models. . . 49
RELAGGS Relational Aggregations. . . 41
CoMoVi Conceptual Modeling Views. . . 70
RFM Recency, Frequency and Monetary Analysis. . . 73
SST Suporte a Segmentação Temporal . . . 31
AC Aquisição de Conhecimento . . . 32
ITM Independência de Técnica de Mineração . . . 32
MDE Engenharia Dirigida por Modelos . . . 62
MDD Desenvolvimento Dirigido por Modelos . . . 64
RNA Redes Neurais Artificiais . . . 94
KNN K-nearest neighbor. . . 94
CFS Correlation-based Feature Subset Selection. . . 98
CbMVV Correlation-based Multiple View Validation. . . 58
MDA Arquitetura Dirigida por Modelos . . . 64
OMG Object Management Group. . . 64
UML Unified Modeling Language. . . 65
DDL Data Definition Language. . . 65
SGBD Sistemas Gerenciadores de Banco de Dados . . . 73
BPM Modelos de Processo de Negócio . . . 65
RNA Redes Neurais Artificiais . . . 94
MLP Multi Layer Perceptron. . . 94
MIT Massachusetts Institute of Technology. . . 64
3.1 Geração do new star schema . . . 46
3.2 ILP . . . 48
3.3 CrossMine . . . 55
3.4 CbMVV . . . 59
Sumário
1 INTRODUÇÃO 20 1.1 MOTIVAÇÃO . . . 23 1.2 PROBLEMA DE PESQUISA . . . 24 1.3 OBJETIVO GERAL . . . 24 1.4 OBJETIVOS ESPECÍFICOS . . . 25 1.5 ESCOPO NEGATIVO . . . 25 1.6 METODOLOGIA DE PESQUISA . . . 25 1.7 ESTRUTURA DA TESE . . . 26 2 CARACTERIZAÇÃO DO PROBLEMA 28 2.1 CREDIT BEHAVIOR SCORING . . . 282.2 DEFINIÇÃO DO PROBLEMA . . . 30
2.3 REQUISITOS . . . 31
2.3.1 Características Necessárias . . . 31
2.3.2 Enquete com Profissionais . . . 33
2.4 RESUMO DO CAPÍTULO . . . 37
3 TRABALHOS RELACIONADOS 39 3.1 PROPOSICIONALIZAÇÃO . . . 39
3.1.1 Frameworks Baseados em Programação Lógica . . . 39
3.1.2 Frameworks Baseados em Banco de Dados . . . 41
3.2 MINERAÇÃO DE DADOS RELACIONAL . . . 47
3.2.1 Frameworks Baseados em Programação Lógica . . . 47
3.2.2 Frameworks Baseados em Modelos Relacionais Probabilísticos . . . 49
3.2.3 Frameworks Baseados em Banco de Dados . . . 52
3.2.3.1 Propagação do ID . . . 52
3.2.3.2 Múltiplas Visões . . . 55
3.3 TAXONOMIA PROPOSTA . . . 60
3.4 ANÁLISE COMPARATIVA DOS FRAMEWORKS . . . 60
3.5 RESUMO DO CAPÍTULO . . . 61
4 CONCEITOS BÁSICOS 62 4.1 ENGENHARIA DIRIGIDA POR MODELOS . . . 62
4.2 DESENVOLVIMENTO DIRIGIDO POR MODELOS . . . 64 4.3 TIPOS DE DADOS . . . 66 4.4 TIPOS DE JUNÇÕES . . . 67 4.5 RESUMO DO CAPÍTULO . . . 69 5 FRAMEWORK PROPOSTO 70 5.1 AQUISIÇÃO DE CONHECIMENTO . . . 70 5.1.1 Análise RFM . . . 73 5.2 CONCEITOS MODELADOS . . . 74 5.3 ARQUITETURA GERAL . . . 76
5.4 MÉTODO DE UTILIZAÇÃO DO FRAMEWORK . . . 81
5.4.1 Aplicação Prática . . . 82
5.4.2 Exemplo de Utilização do Framework . . . 83
5.5 RESUMO DO CAPÍTULO . . . 88
6 RESULTADOS EXPERIMENTAIS 90 6.1 EXPERIMENTO I . . . 90
6.1.1 Metodologia Experimental . . . 90
6.1.1.1 Descrição das Bases de Dados . . . 90
6.1.1.2 Técnicas de Mineração de Dados Selecionadas . . . 93
6.1.1.3 Método de Avaliação de Desempenho . . . 95
6.1.1.4 Métrica de Avaliação de Desempenho . . . 95
6.1.1.5 Análise Estatística . . . 96 6.1.1.6 Configuração Experimental . . . 97 6.1.2 Resultados e Discussões . . . 99 6.2 EXPERIMENTO II . . . 108 6.2.1 Configuração Experimental . . . 108 6.2.2 Resultados e Discussões . . . 110 7 CONCLUSÕES 114 7.1 RESUMO . . . 114 7.2 CONTRIBUIÇÕES . . . 115 7.3 LIMITAÇÕES . . . 118 7.4 TRABALHOS FUTUROS . . . 120 7.5 DIFICULDADES E SUGESTÕES . . . 121
Referências 122
Apêndice 130
A Questionário da Enquete 131
B Código SQL utilizado para importar a base de dados da PKDD 135
C Modelo instanciado para o banco de dados da PKDD 140
D Código SQL gerado pelo framework proposto para o banco de dados da PKDD 141
E Código MLP 147
F Lista com o rank das vinte variáveis gerada pelo CoMoVi com maior ganho de
informação para o banco de dados da PKDD 151
G Lista com o rank das vinte variáveis gerada pelo CoMoVi com maior ganho de informação para o banco de dados do Varejo 152
H Requisito Funcional 153
I Exemplo de mapeamento dos conceitos do CoMoVi para um domínio diferente
1
INTRODUÇÃO
Nos últimos 15 anos, o processo de descoberta do conhecimento em bases de dados, do inglês Knowledge Discovery in Database (KDD), tornou-se uma área de pesquisa ativa no campo de Tecnologia da Informação. A definição do termo KDD foi introduzida porFAYYAD et al. (1996) como parte de um processo ainda mais amplo que um algoritmo de mineração de dados. KDD ou Descoberta do Conhecimento em Bases de Dados é um processo não trivial, iterativo, interativo e com múltiplos estágios que manipula e transforma os dados no intuito de descobrir padrões relevantes. A Figura 1.1 ilustra a visão geral do processo de KDD, que é composta por nove itens agrupados em cinco macro etapas, que serão detalhados a seguir.
Figura 1.1: Etapas do processo de KDD
Fonte: Adaptada deFAYYAD et al.(1996)
1. Entendimento do domínio da aplicação: inclui definir o objetivo da aplicação e entender o que é relevante para o problema;
21 2. Seleção dos Dados: também chamado de amostragem dos dados, é o processo que define quais serão os dados utilizados no projeto. Os dados podem ser selecionados das mais diversas fontes, tais como: banco de dados relacional, arquivo texto, dentre outros; 3. Limpeza dos dados e pré-processamento: inclui escolhas de estratégias para lidar com
missing valuese outliers, bem como decidir questões de banco de dados, tais como: tipos de dados e esquemas;
4. Redução dos dados e projeção: inclui encontrar variáveis úteis para representar os dados dependendo do objetivo da tarefa. Métodos de transformação e redução de dimensionalidade são utilizados para reduzir o número efetivo de registros e variáveis a fim de encontrar a representação mais apropriada para os dados;
5. Escolha da função de mineração de dados: inclui decidir o objetivo do modelo derivado pelo algoritmo de mineração de dados, que pode ser: sumarização, classificação, regressão ou agrupamento;
6. Escolha do algoritmo de mineração de dados e transformação dos dados: inclui selecionar o algoritmo de mineração de dados que será utilizado, assim como transformar os dados da etapa de pré-processamento no formato adequado do algoritmo selecionado. Por exemplo, árvores de decisão necessitam que as variáveis de entrada sejam categóricas, desta forma, as variáveis numéricas precisam ser discretizadas. Por outro lado, Redes Neurais MultiLayer Perceptron precisam que as variáveis de entrada sejam numéricas, por isso, as variáveis categóricas precisam ser binarizadas;
7. Mineração de dados: inclui a aplicação do algoritmo de mineração de dados e a busca dos seus parâmetros que maximizem o objetivo do projeto;
8. Interpretação: inclui a validação do conhecimento minerado, onde o especialista do domínio de aplicação é fundamental para homologação do conhecimento descoberto, pois nesta fase são validados todos os resultados obtidos no projeto;
9. Utilização do conhecimento descoberto: inclui incorporar o conhecimento dentro de um sistema de decisão, no qual a empresa tomará decisões com base neste conhecimento ou apenas documentá-lo e apresentar para as partes interessadas.
Atualmente, existem diversas ferramentas de mineração de dados. Elas permitem que usuários com pouco conhecimento em mineração de dados construam modelos de classificação de forma rápida. No entanto, em situações reais de sistema de suporte à decisão, boas soluções de mineração de dados dependem mais da representação das variáveis de entrada do que apenas da seleção e especificação dos parâmetros da técnica (ZHAO; SINHA; GE,2009). A repre-sentação dos dados é uma parte da etapa de pré-processamento. Esta etapa é custosa, em geral, consome entre 50 e 80% do tempo total do projeto e normalmente é dependente do
domínio da aplicação (WITTEN; FRANK; HALL,2011). As atividades dessa região de fronteira exigem uma conjugação de competências em banco de dados (extração, integração, consultas), estatística (análise de dados) e análise de sistemas (entendimento do domínio de aplicação). Estas competências normalmente não são encontradas numa mesma equipe, seja no meio acadêmico, seja no meio profissional. É nesta etapa que os dados contidos em um banco de dados relacional são preparados e transformados para aplicação de uma técnica de mineração de dados. Embora esta etapa consuma mais da metade do tempo de um projeto de descoberta do conhecimento, as pesquisas na área são focadas principalmente na etapa principal do processo, nos algoritmos de mineração de dados, e proporcionalmente poucos trabalhos são encontrados na literatura referentes à fase de transformação dos dados durante a etapa de pré-processamento (CAO et al., 2011). De acordo comPYLE(1999), os dois objetivos gerais na fase de pré-processamento são: 1) os dados devem ser transformados no formato que permita que o algoritmo de mineração de
dados seja aplicado, e 2) os dados devem ser transformados no formato que permita a realização das análises necessárias para avaliação dos resultados após aplicação da técnica. De acordo comKROGEL(2005), em geral, esta tarefa envolve duas atividades:
1. Criação de Variáveis: a criação de novas variáveis, do inglês Feature Constructor, é o processo de criar variáveis de entrada para os algoritmos de mineração de dados. De uma forma geral, existem dois tipos de estratégias: 1) criação de uma nova variável a partir de variáveis originais. Por exemplo, criar uma variável que representa a área de um objeto a partir das variáveis originais altura e largura; 2) criação de variáveis que representam um conjunto de dados através de funções de sumarização como média e desvio padrão. 2. Seleção de Variáveis: o processo de Feature Constructor pode gerar um grande número
de variáveis de entrada, o que pode afetar negativamente o desempenho de técnicas que são mais sensíveis a problemas com muitas variáveis de entrada. Por isso, a seleção de variáveis do inglês Feature Selection tem como objetivo obter um subconjunto de variáveis com uma perda mínima de informação (HALL; HOLMES,2003). Os frameworks de seleção de variáveis são agrupados em dois grupos: Filter e Wrapper. Os frameworks classificados como Filter selecionam as variáveis com base em métricas que são independentes da técnica de seleção. Por outro lado, os frameworks classificados como Wrapper selecionam as variáveis utilizando a própria técnica de mineração de dados. Os frameworks de seleção de variáveis podem ser subdivididos entre aqueles que avaliam uma variável por vez e os que avaliam um conjunto de variáveis simultaneamente. Este último, utiliza algoritmos de busca para auxiliar na seleção do subconjunto de variáveis.
A construção de novas variáveis de entrada é uma forma sistemática de embutir conhe-cimento do domínio em um projeto de KDD. Essas variáveis serão utilizadas como entrada por uma técnica durante a etapa de Mineração de Dados. O processo de construção de novas variáveis é um dos mais antigos e ainda desafiadores problemas (HASTIE; TIBSHIRANI;
23
FRIEDMAN,2009). De acordo comWITTEN; FRANK; HALL(2011), a melhor maneira de
construir variáveis é manualmente, baseado no entendimento do problema de aprendizagem e no significado de cada atributo. De uma forma geral, a tarefa de construção de novas variáveis é muito mais dependente do conhecimento do domínio do que a construção de um classificador, por isso o conhecimento do domínio é um requisito (ZHAO; SINHA; GE,2009). A construção de novas variáveis que embutem conhecimento do domínio podem aumentar o poder discriminatório dos algoritmos de mineração, pois maximizam o conteúdo estatístico da informação.
A principal tecnologia de armazenamento de dados utilizada pelas empresas são os bancos de dados relacionais. Frameworks que sistematizam a tarefa transformação de dados na etapa pré-processamento, a partir de banco de dados relacionais, são encontrados na literatura. Os frameworksexistentes que objetivam sistematizar esta etapa seguem a abordagem proposicional ou mineração de dados relacional. Os frameworks que seguem a abordagem proposicional transformam a representação multidimensional dos dados dentro de uma simples relação organizada em uma tabela desnormalizada na granularidade em que se pretende tomar a decisão, a qual serve como entrada para algoritmos de mineração de dados convencionais. A mineração de dados relacional propõe que o conhecimento seja extraído de cada relação isoladamente, e posteriormente combinado, ao invés de juntar as diversas relações. Os frameworks de transfor-mação de dados a partir de banco de dados relacionais podem ser vistos como abordagens de Feature Constructorque levam em consideração diversas relações. Os frameworks existentes apresentam uma limitação significativa quando aplicados a soluções de Credit Behavior Scoring, que são soluções de mineração de dados que auxiliam as instituições financeiras a conceder crédito aos seus clientes.
1.1
MOTIVAÇÃO
Diante do cenário financeiro atual com várias crises em escalas globais, o suporte do processo de descoberta do conhecimento à área financeira é importante para estabilidade da economia. A indústria de crédito brasileira vem sendo beneficiada pelo ambiente de estabilidade monetária proporcionado pela consolidação do plano real e a estabilização da moeda, que contribuíram para a queda nas taxas de juros, o alongamento dos prazos das operações, a diversificação de operações e a consequente elevação do crédito do Sistema Financeiro Nacional, que segundoRelatório de Economia Bancária e Crédito(2012) representa 53,8% do Produto Interno Bruto. Outro fator fundamental apontado peloRelatório de Economia Bancária e Crédito (2007), para este cenário, é a utilização de sistemas de classificação de risco pelas instituições financeiras. Sistemas de classificação de risco, também conhecidos como Scoring Systems, são projetos de descoberta do conhecimento que atribuem uma nota a um cliente mediante sua capacidade de honrar com seus compromissos junto à instituição financeira.
As instituições financeiras estão procurando cada vez mais melhorar o desempenho de seus Scoring System, principalmente pela crescente exigência do acordo Basiléia II. Este acordo
tem como objetivo manter a estabilidade monetária e financeira da economia mundial, através da regulamentação de normas e da cooperação entre os bancos centrais e outras agências. Em função das diversas crises econômicas que historicamente afetaram o mercado financeiro mundial, ele foi criado pelo Comitê de Regulamentação Bancária e Práticas de Supervisão, sediado no Banco de Compensações Internacionais, em Basiléia, na Suíça. Por esse motivo, o nome Basiléia.
No Brasil, o impacto do acordo da Basiléia pode ser observado na instrução normativa N. 002682 do Banco Central do Brasil que diz em seu Art. 1º “Determinar que as instituições financeiras e demais instituições autorizadas a funcionar pelo Banco Central do Brasil devem classificar as operações de crédito”. A classificação da operação no nível de risco correspondente é de responsabilidade da instituição detentora do crédito. Esta classificação é feita por um Scoring System. SegundoTHOMAS(2000), os principais Scoring Systems são Credit Scoring e o Credit Behavior Scoring.
Dois grandes desafios na construção dos Scoring Systems são: 1) encontrar quais variáveis devem ser construídas, como mencionado anteriormente, o poder preditivo das soluções dependem mais das variáveis de entrada do que da técnica de mineração de dados e 2) o elevado tempo necessário para transformar os dados de um banco de dados relacional. Uma das principais críticas é o elevado tempo gasto durante este processo. De acordo comDOMINGOS(2003); GUO; VIKTOR(2008), o processo manual para construção de uma relação desnormalizada na granularidade de decisão do projeto torna a atividade lenta e complexa.
1.2
PROBLEMA DE PESQUISA
Esta tese pretende responder a seguinte pergunta de pesquisa no contexto de mineração de dados:
Pergunta de Pesquisa Como sistematizar a tarefa de transformação de dados em projetos de KDD de Credit Behavior Scoring a partir de banco de dados relacionais?
A resposta a essa pergunta é de grande relevância, uma vez que pode auxiliar especialistas a minimizarem o tempo e o custo dos projetos de KDD, além de melhorar o desempenho da solução.
1.3
OBJETIVO GERAL
O objetivo desta pesquisa é desenvolver um framework para sistematizar a tarefa de transformação dos dados em projetos de KDD sobre problemas comportamentais, de forma a tornar possível a criação semi-automática de uma base de dados.
25
1.4
OBJETIVOS ESPECÍFICOS
• Fornecer suporte à segmentação temporal inerente às soluções comportamentais de Credit Behavior Scoring;
• Aumentar o poder discriminatório das soluções através da construção de novas variáveis que maximizem o conteúdo estatístico da informação do domínio;
• Reduzir o tempo necessário para transformação dos dados durante a etapa de pré-processamento dos dados.
1.5
ESCOPO NEGATIVO
Como este trabalho faz parte de um contexto mais amplo, um conjunto de aspectos relacionados será deixado fora do seu escopo. Desta forma, os seguintes tópicos não são diretamente abordados nesta tese:
• Definir qual algoritmo de mineração de dados é melhor para soluções de Credit Behavior Scoring: existem diversos algoritmos de mineração de dados. Cada um com suas vantagens e desvantagens. Definir qual algoritmo de mineração de dados é melhor para construção de soluções de Credit Behavior Scoring, foge ao escopo deste trabalho, uma vez que um dos objetivos específicos é propor um framework que proporcione maior poder discriminatório independente do algoritmo de mineração de dados;
• Análise dos frameworks de seleção de variáveis: existem diversos frameworks para seleção de variáveis. No entanto, a análise de tais frameworks foge ao escopo deste trabalho, uma vez que seu objetivo principal é sistematizar a transformação de dados a partir de banco de dados relacionais.
1.6
METODOLOGIA DE PESQUISA
Com base nos conceitos oriundos da metodologia científica (LAKATOS; MARCONI, 2010), o presente trabalho pode ser classificado como sendo uma pesquisa: exploratória e aplicada. Exploratória porque realiza a estruturação e explicitação do problema, o levantamento bibliográfico, a definição de hipóteses, além de realizar uma enquete com profissionais. É aplicada porque os conhecimentos adquiridos são utilizados para aplicação prática voltada para a solução de um problema concreto.
A Figura 1.2 mostra o projeto de pesquisa aplicado nesta tese. O projeto iniciou com a definição dos objetivos da pesquisa que foram definidos na Seção 1.4, e avaliação inicial da literatura. Este último forneceu os conceitos básicos e a compreensão da área. Em seguida, foi
realizado um levantamento bibliográfico das principais abordagens de transformação de dados e uma enquete com profissionais da área. Estes dois processos foram utilizados para identificar o conjunto de requisitos para a tarefa de transformação de dados a partir de banco de dados relacionais. O passo seguinte foi a proposta de um novo framework de transformação de dados. Por fim, o projeto de pesquisa verificou a validade do framework proposto através de dois estudos experimentais.
Figura 1.2: Metodologia de Pesquisa
Fonte: O Autor (2015)
1.7
ESTRUTURA DA TESE
O trabalho está organizado em 7 (sete) capítulos. O Capítulo 2 apresenta a caracterização do problema e identifica os requisitos para um framework de transformação de dados quando aplicados a soluções de Credit Behavior Scoring. O Capítulo 3 apresenta as abordagens e os principais frameworks de transformação de dados, analisa suas limitações quando aplicados à soluções comportamentais e propõe uma nova taxonomia.
O Capítulo 4 apresenta os conceitos básicos utilizados para construção do framework. Este capítulo apresenta a abordagem do Desenvolvimento Dirigido por Modelos da Engenharia
27 de Software, que foi utilizada como base para sistematizar a tarefa de transformação de dados. O Capítulo 5 apresenta o framework proposto, definindo seus conceitos básicos, sua arquitetura geral e método de utilização. O Capítulo 6 apresenta os dois estudos experimentais realizados para validar o framework proposto. O primeiro estudo compara os principais frameworks existentes e o framework proposto. O objetivo deste estudo é verificar qual destes frameworks proporciona maior poder preditivo para uma técnica de mineração de dados, quando aplicados em soluções de Credit Behavior Scoring. O segundo estudo verifica a redução do tempo proporcionada pelo framework proposto durante a fase de transformação. Por fim, o Capítulo 7 apresenta as principais contribuições do trabalho, as limitações existentes, conclusões e trabalhos futuros.
2
CARACTERIZAÇÃO DO PROBLEMA
Este capítulo descreve as soluções de Credit Behavior Scoring e o problema de classificação relacional. Em seguida, apresenta os requisitos necessários a um framework de transformação de dados com base na análise a priori do problema. Por fim, apresenta uma enquete com profissionais que possuem experiência em transformação dos dados em soluções Credit Behavior Scoring. O objetivo da enquete foi identificar novos requisitos com base nas principais dificuldades apontadas pelos profissionais.
2.1
CREDIT BEHAVIOR SCORING
Credit Scoring e Credit Behavior Scoring são soluções que auxiliam as instituições financeiras a decidir sobre a concessão de crédito aos consumidores com base no risco de crédito de suas solicitações (THOMAS,2000). No contexto de mineração de dados, elas representam soluções para um problema de decisão binária, que é um problema de classificação em que a variável resposta é dicotômica, ou seja, corresponde a uma variável que possui apenas duas classes. O objetivo dessas ferramentas é atribuir uma pontuação "score" que permita identificar o quão próximo o consumidor está de dois grupos: "bom" que é provável cumprir com suas obrigações financeiras ou um grupo de "mau", cujo pedido deve ser negado devido à sua alta probabilidade de faltar com seus compromissos na instituição financeira. A variável resposta é normalmente calculada entre 6 e 24 meses a partir da data de concessão de crédito. Em geral, um consumidor é considerado "mau" se possuir um atraso de 60 dias ou mais em uma parcela, e "bom" caso contrário. No entanto, é importante ressaltar que a definição de "mau" é um critério da instituição financeira, por isso pode variar de instituição para instituição.
Credit Scoringé utilizado quando um novo consumidor faz uma solicitação de crédito. Apenas informações demográficas como, idade, sexo, renda, entre outras variáveis, são levadas em consideração no cálculo do escore. Credit Behavior Scoring é utilizado quando um consumidor, que já possui histórico de transações na base de dados da instituição, está solicitando crédito (BANASIAK; O’HARE, 2001). Neste caso, além das informações demográficas, informações comportamentais também são levadas em consideração: o histórico de pagamentos
29 em dia, em atraso, quantidade de empréstimos, entre outras informações. O objetivo desta solução é extrair da base de dados a pontuação que melhor separe os clientes bons dos maus.
O modelo de Credit Behavior Scoring, usado como uma ferramenta automática, fornece informação instantânea ao analista e, tendo um maior poder preditivo do que o modelo de Credit Scoring, aumenta a eficiência do analista de crédito. Os pontos fortes destes dois modelos são a precisão e a eficácia. A maior precisão de análise de crédito dos modelos de Credit Behavior Scoringvem das informações do histórico de relacionamento do cliente com a própria instituição e com outras. O que permite encontrar um conjunto capaz de fornecer uma melhor estimativa de predição, e em seguida, de forma otimizada, ponderar as variáveis de entrada para maximizar o poder preditivo do modelo. A saída de um modelo de Credit Behavior Scoring é interpretada como a propensão do cliente honrar sua dívida junto à instituição, ou seja, ser um bom cliente.
Uma vez que a saída do modelo de pontuação do comportamento pode ser interpretada como a propensão de o cliente honrar com seus compromissos financeiros, o gerente de crédito pode criar pontos de corte para tomada de decisão massificada, ou seja, qual é o mais baixo escore que pode ser aceito para a aprovação de crédito. Estes pontos de corte são ferramentas muito úteis na gestão do risco, pois flexibilizam o trabalho do gestor: aumentando o ponto de corte, aceita-se menos e melhores clientes, reduzindo a exposição ao risco, e vice-versa. Toda vez que estes pontos de corte são alterados, pode-se prever o risco de inadimplência ao qual a empresa será exposta.
Na indústria de crédito, os modelos de Credit Behavior Scoring e Credit Scoring, em geral, são confundidos com "Sistemas Especialistas" ou "Sistemas baseados em Regras" que utilizam a experiência de gerentes de crédito na escolha de quais variáveis serão analisadas e criam um processo automatizado de decisão baseado nestas regras. Basicamente, Sistemas Especialistas replicam em código de programa de computador as etapas da análise manual realizada por um gestor de crédito. Portanto, Sistemas Especialistas fornecem rapidez ao processo de avaliação de crédito por minimizar a intervenção do analista de crédito em operações de rotina. No entanto, os modelos de Credit Behavior Scoring possuem maior poder preditivo do que os sistemas especialistas, por serem capazes de descobrir tanto as relações entre as variáveis tradicionais de risco de crédito utilizadas num sistema especialista, como também, as relações menos óbvias para um gerente de crédito. SegundoSAS(2009), o poder discriminatório das soluções de Credit Behavior Scoring é mais importante do que a justificativa para a pontuação atribuída ao cliente.
KENNEDY et al.(2013) destacaram as oportunidades existentes para soluções de Credit Behavior Scoringe descreveram os processos envolvidos. Para os autores, a primeira etapa do processo corresponde à seleção de uma amostra de clientes, garantido que os dados referentes aos seus produtos e consumos estejam disponíveis em uma determinada data, chamada de ponto de observação. O período antes do ponto de observação é chamado de janela de desempenho. É preciso destacar que o significado de desempenho aqui se refere ao domínio de aplicação, não à qualidade dos modelos decisórios, como habitualmente usado pela área de Inteligência Artificial.
Os dados contidos na janela de desempenho são estruturados em atributos que serão usados como entrada para o modelo de Credit Behavior Scoring. Exemplos de variáveis criadas nesta janela são: máximo dias de atraso, quantidade de parcelas pagas em dia, número de ofertas recebidas, entre outras (MCNAB; WYNN,2000). A Figura 2.1 ilustra como os dados são particionados de acordo com a temporalidade.
Figura 2.1: Particionamento dos dados em Credit Behavior Scoring
Fonte: Adaptada deKENNEDY et al.(2013)
O período após o ponto de observação é chamado de janela de resultado. Os dados contidos na janela de resultado são estruturados em atributos que serão utilizados para avaliar a precisão do modelo. É nesta janela que a variável resposta binária ("bom" e "mau") é construída. A construção de variáveis em modelos de Credit Behavior Scoring deve levar em consideração esta segmentação temporal. A Figura 2.2 ilustra o particionamento dos dados seguindo os conceitos de janelas de desempenho e resultado para uma data de referência (ponto de observação) igual a 01/05/2012 para informações relacionadas às compras de um cliente.
2.2
DEFINIÇÃO DO PROBLEMA
Uma vez que os dados disponíveis para construção de uma solução de Credit Behavior Scoringestão em um banco de dados relacional, ela pode ser descrita como uma solução para um problema de classificação relacional no domínio de análise de risco de crédito (OLIVEIRA NETO
et al.,2012;OLIVEIRA NETO; SOBRINHO; CAVALCANTI,2013;OLIVEIRA NETO et al.,
2014). Em um problema de classificação relacional, os dados disponíveis para modelagem estão em um banco de dados R contendo uma determinada tabela alvo Ta e um conjunto de tabelas backgroundTb1...Tbn. Cada linha pertencente a Ta inclui um atributo único chamado de chave primária (identificador da linha) e uma variável categórica Y, que representa o conceito a ser aprendido "variável resposta". A tarefa de classificação relacional é encontrar uma Hipótese H(x) que mapeia cada linha x da tabela alvo para a categoria Y. A Figura 2.3 ilustra o problema de classificação relacional binária no domínio de aplicação concessão de crédito. A tabela alvo é
31
Figura 2.2: Exemplo de particionamento dos dados em função do tempo
Fonte: O Autor (2015)
representada pela Tabela de Empréstimo, na qual a coluna alvo representa a variável categórica que a Hipótese H(x) deve aprender. Esta variável possui dois valores: bom, se o empréstimo foi pago em dia ou mau, caso contrário. As tabelas de background são representadas pelas tabelas que possuem relacionamento com a tabela alvo, o que é o caso no exemplo da Figura 2.3 das Tabelas parcela e cliente. Antes de aplicar um algoritmo de mineração de dados é necessário que os dados contidos no banco de dados sejam transformados em um formato que permita a aplicação da técnica de mineração de dados. O principal desafio em realizar mineração de dados em ambientes relacionais é como incluir informações essenciais de várias relações (tabelas) para um problema de classificação. Quando a mineração de dados é realizada em ambientes relacionais é importante não apenas considerar as informações da relação alvo, mas também é essencial levar em consideração as informações que estão distribuídas nas tabelas backgrounds, pois informações adicionais aumentam o poder preditivo do algoritmo de mineração de dados.
2.3
REQUISITOS
2.3.1
Características Necessárias
Com base na nálise a priori do problema, foram identificadas características necessárias para a etapa de transformação dos dados em projetos KDD aplicados sobre bases de dados comportamentais, como as soluções de Credit Behavior Scoring. As características identificadas foram:
• Suporte a Segmentação Temporal (SST): Esta característica identifica se o framework aborda como realizar a segmentação temporal durante as construções das variáveis
Figura 2.3: Exemplo de um problema de classificação relacional
Fonte: O Autor (2015)
comportamentais, ou seja, levando em consideração o particionamento em janela de desempenho e janela de resultado. Este particionamento dos dados é imprescindível para o sucesso de projeto que utiliza dados históricos como Credit Behavior Scoring, uma vez que a utilização de dados disponíveis na janela de resultado como variáveis de entrada para a técnica de mineração de dados torna todo projeto inválido.
• Aquisição de Conhecimento (AC): Esta característica identifica se o framework aborda como embutir conhecimento do domínio na construção das variáveis durante a etapa de transformação dos dados para melhorar o poder discriminatório da técnica de mineração de dados.
• Independência de Técnica de Mineração (ITM): Esta característica identifica se o frameworkpode ser aplicado a qualquer técnica de mineração de dados, pois de acordo com o levantamento bibliográfico realizado, os frameworks, independente de técnica, proporcionam maior poder discriminatório para as soluções.
• Escalabilidade (SC): Esta característica identifica se o framework é robusto para problemas com um grande número de relações e atributos. Uma vez que alguns frameworks apresentam problemas de escalabilidade.
33
2.3.2
Enquete com Profissionais
Esta enquete teve como foco conhecer as principais dificuldades encontradas durante a tarefa de transformar um banco de dados relacional, que será utilizada como entrada por uma técnica de mineração de dados para soluções de Credit Behavior Scoring. A enquete coletou a opinião de profissionais experientes no desenvolvimento de soluções de Credit Behavior Scoring, de modo a identificar novos requisitos para o framework proposto.
A enquete foi colhida através de um questionário disponível no Apêndice A, disponibilizado onlinepela ferramenta Google Forms. Além das informações pessoais sobre os profissionais, o questionário foi composto por questões objetivas e descritivas que foram sintetizadas através da técnica de palavra chave (FLICK,2009).
Responderam ao questionário onze profissionais de empresas provedoras de soluções de crédito e de empresas que não são fornecedoras de soluções, mas que têm um departamento para construção de suas soluções. Apesar de todos os participantes possuirem experiência em mineração de dados de natureza profissional, 45% também indicou ter experiência acadêmica, conforme mostra a Figura 2.4.
Figura 2.4: Q3) Natureza da experiência
45 %
Acadêmico e profissional
55 %
Apenas profissional
Fonte: O Autor (2015)
A média do tempo de experiência dos participantes da pesquisa foi superior a 4 anos, o que demonstra um bom nível de conhecimento com as atividades envolvidas, conforme ilustra a Figura 2.5.
Os participantes que possuem apenas graduação indicaram alto grau de conhecimento e experiência no desenvolvimento de soluções de Credit Behavior Scoring. Os demais participantes possuíam elevado grau de instrução. A Figura 2.6 apresenta apenas o maior nível de instrução de
Figura 2.5: Q2) Tempo de experiência
9.09 %
mais de 1 ano e menos de 2 anos 9.09 %
mais de 2 anos e menos de 3 anos 18.18 %
mais de 3 anos e menos de 4 anos
54.55 %
mais de 4 anos
9.09 %
menos de 6 meses
Fonte: O Autor (2015) cada participante (não acumula títulos).
Figura 2.6: Q1) Grau de instrução
9.09 % Doutor 9.09 % Especialista 9.09 % Especialização em andamento 36.36 % Graduado 18.18 % Mestre 18.18 % Doutorado em andamento Fonte: O Autor (2015)
As questões objetivas Q4 e Q5 apresentam as suas alternativas de respostas em uma escala de avaliação que variou de: extremamente inadequado "0" até extremamente adequado "10"(pontos). Dessa forma, uma pontuação neutra atingiria uma nota igual a cinco.
A Figura 2.7 apresenta, por meio de uma autoavaliação, o nível de conhecimento dos participantes em Banco de Dados. A média de conhecimento obtida entre todos os participantes
35
Figura 2.7: Q4) Autoavaliação do nível de conhecimento em Banco de Dados
0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 Q U ANTID ADE DE V O T OS ESCALA DE PONTUAÇÃO Fonte: O Autor (2015) foi de 7,36 pontos.
A Figura 2.8 apresenta, por meio de uma autoavaliação, o nível de conhecimento dos participantes em técnicas de mineração de dados. A média de conhecimento obtida entre todos os participantes foi de 7,27 pontos.
Figura 2.8: Q5) Autoavaliação do nível de conhecimento em Técnicas de Mineração de Dados 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 Q U ANTID ADE DE V O T OS ESCALA DE PONTUAÇÃO Fonte: O Autor (2015)
A Tabela 2.1 apresenta o resultado da pesquisa sobre métodos/frameworks utilizados pelos participantes para sistematizar a geração de uma base de dados. Como pode ser observado na tabela, apenas ferramentas foram citadas, o que evidencia o desconhecimento dos frameworks existentes na literatura.
Tabela 2.1: Q6) Você utiliza algum método/framework para sistematizar a tarefa de geração de base de dados a partir de um banco de dados relacional?
Método/framework Percentual Ferramenta proprietária 63.6% SPSS 45.5% Código SQL 36.4% kettle 27.3% Excel 9.1%
A Tabela 2.2 apresenta os documentos utilizados pelos participantes para guiar o processo de geração da base de dados. Apesar de não existir um consenso, a grande maioria (73%) utiliza um documento de especificação, que geralmente é confeccionado pela equipe de negócios e contém as variáveis que devem ser calculadas.
Tabela 2.2: Q7) Qual tipo de documentação você utiliza para auxiliar nesta tarefa?
Tipo de Documentação Percentual Documento com especificação 73%
Dicionário de Dados 36%
Não utiliza documentação 18%
Histórico de atividades 9%
A Tabela 2.3 apresenta os principais erros ocorridos durante esta tarefa. Embora não exista uma unanimidade nos erros apontados, é possível perceber que a maior concentração dos erros está relacionada ao aspecto temporal inerente às soluções de Credit Behavior Scoring, uma vez que 72,73% apontaram erro no cálculo das variáveis comportamentais, seguido por entendimento da base de dados com 45,45% e entendimento do negócio 36,36%.
Tabela 2.3: Q8) Quais os principais erros ocorridos durante esta tarefa em soluções de Credit Behavior Scoring?
Principais Erros Percentual
Erro no cálculo das variáveis comportamentais 72.73%
Entendimento da base de dados 45.45%
Entendimento do negócio 36.36%
Controle de versão 9.09%
A Figura 2.9 apresenta o tempo médio de duração desta atividade de acordo com os participantes da pesquisa. Embora o tempo de execução desta tarefa dependa diretamente da quantidade de tabelas disponíveis no banco de dados, de seus relacionamentos e da quantidade de registros, houve uma convergência na resposta. O tempo médio desta atividade é medido em semanas de acordo com 91% dos participantes.
Como resultado desta enquete, é possível verificar que a tarefa de transformar os dados a partir de um banco de dados relacional possui alta relevância em soluções de Credit Behavior
37
Figura 2.9: Q9) Tempo médio desta tarefa
9 %
Horas
91 % Dias
Fonte: O Autor (2015)
Scoring, uma vez que o tempo médio desta atividade, de acordo com 91% dos participantes da pesquisa, é medido em semanas. O principal erro relatado pelos participantes envolve o cálculo de variáveis comportamentais, que exige o gerenciamento da segmentação temporal inerente às soluções comportamentais. Este tipo de erro é identificado, em geral, na fase final de um projeto de KDD, a avaliação de desempenho, e por isso eleva o custo do projeto pois o mesmo deverá ser reiniciado. Outros aspectos importantes que a pesquisa revelou foram: 1) a ocorrência de erros oriundos da falta de entendimento do banco de dados e 2) falta de entendimento do negócio.
2.4
RESUMO DO CAPÍTULO
Este capítulo apresentou o problema de classificação relacional e a solução de Credit Behavior Scoring. Identificou os requisitos necessários a um framework de transformação de dados quando aplicados a solução de Credit Behavior Scoring. Diante da análise a priori do problema e da respostas dos profissionais que responderam a enquete foram identificados os seguintes requisitos:
• Fornecer suporte ao aspecto temporal inerente às soluções;
• Fornecer aquisição de conhecimento através da construção de novas variáveis que aumentem o poder discriminatório das soluções;
• Reduzir o tempo da tarefa de transformação de dados a partir de um banco de dados relacional;
• Fornecer suporte para um maior entendimento do negócio e do banco de dados, reduzindo a ocorrência de erros;
• Fornecer independência da técnica de mineração; • Possuir escalabilidade.
39 39 39
3
TRABALHOS RELACIONADOS
As duas abordagens de transformação dos dados aplicadas na etapa de pré-processamento durante o processo de KDD são: proposicionalização e mineração de dados relacional. Este capítulo descreve cada abordagem e seus principais frameworks. Em seguida, propõe uma taxonomia dos principais frameworks. Por fim, analisa as limitações dos frameworks quando aplicados a soluções de Credit Behavior Scoring.
3.1
PROPOSICIONALIZAÇÃO
Proposicionalização é o processo de transformar a representação de várias relações em uma única relação, também conhecido como formato proposicional. Os frameworks que seguem a abordagem proposicional transformam a representação multidimensional dos dados em uma simples relação representada por uma tabela desnormalizada na granularidade em que se pretende tomar a decisão, a qual serve como entrada para algoritmos de mineração de dados convencionais. A Figura 3.1 ilustra o processo de proposicionalização. Os frameworks que seguem a abordagem proposicional podem ser classificados em dois grupos: os que são baseados em programação lógica e os baseados em banco de dados.
3.1.1
Frameworks Baseados em Programação Lógica
Os primeiros frameworks proposicionais foram baseados na Indutive Logic Program (ILP). ILP é um subcampo da área de aprendizagem de máquina que utiliza a programação em lógica como uma representação uniforme para exemplos, base de conhecimento e hipóteses. O problema de aprendizado em ILP é normalmente especificado como segue: dado uma base de conhecimento B, expressa como um conjunto de definições de predicados, exemplos positivos E+ e exemplos negativos E-, um sistema ILP buscará uma hipótese H tal que o erro de h seja minimizado em exemplos futuros. Em ILP, h é usualmente um conjunto de cláusulas de lógica de primeira ordem, e novos exemplos serão classificados como pertencente à classe positiva se e somente se, ele é coberto por todas as cláusulas de h. O primeiro framework proposicional baseado em programação lógica foi o LINUS (LAVRAC,1990).
Figura 3.1: Abordagem proposicional
Fonte: O Autor (2015) LINUS
O LINUS é um framework de ILP que transforma a representação multidimensional do problema para uma tabela atributo-valor. O LINUS foi apresentado pela primeira vez porLAVRAC (1990). A ideia é transformar um problema descrito em ILP dentro da forma proposicional e resolver o problema através da aprendizagem de regras proposicionais. O processo de transformação considera a combinação de todas as relações "predicado" com todos os valores possíveis, gerando assim um atributo distinto para cada elemento do conjunto. A geração da tabela final possui apenas atributos booleanos. O pós-processamento envolve especialmente eliminação de atributos irrelevantes.
Para uma melhor compreensão do seu funcionamento, a seguir será ilustrado um exemplo que foi retirado do livroLAVRAC; DZEROSKI(1993). No exemplo, a relação alvo é Filha (X, Y), e significa que a pessoa X é filha da pessoa Y. A tarefa é definir a relação alvo com auxílio das relações Feminino, Masculino e Progenitor. Todas as variáveis são do tipo Pessoa = (Ann, Eve, Pat, Sue e Tom). A Tabela 3.1 ilustra os dados de entrada em lógica de primeira ordem escritos na sintaxe de Prolog, e a Tabela 3.2 mostra o resultado da transformação utilizando o LINUS.
As características proposicionais F, M e P são representações booleanas para as relações Feminino, Masculino e Progenitor, respectivamente. As principais limitações do LINUS são: geração de variáveis irrelevantes, como pode ser observado na Tabela 3.2 na característica P(X, X) e limitação para tratar variáveis contínuas.
41
Tabela 3.1: Dados de entrada
Exemplos de Teinamento Relações
filha(sue,eve).Positivo progenitor(eve,sue). feminino(ann). masculino(pat). filha(ann,pat).Positivo progenitor(ann,tom). feminino(sue). masculino(tom). filha(tom,ann).Negativo progenitor(pat,ann). feminino(eve).
filha(eve,ann).Negativo progenitor(tom,sue).
Tabela 3.2: Resultado da transformação
Variáveis Características Proposicionais
X Y F(X) F(Y) M(X) M(Y) P(X,X) P(X,Y) P(Y,X) P(Y,Y) Classe
Sue Eve 1 1 0 0 0 0 1 0 Pos
Ann Pat 1 0 0 1 0 0 1 0 Pos
Tom Ann 0 1 1 0 0 0 1 0 Neg
Eve ann 0 1 0 0 0 0 0 0 Neg
3.1.2
Frameworks Baseados em Banco de Dados
Para superar as limitações dos frameworks proposicionais baseado em ILP, sugiram os frameworksproposicionais que lidam diretamente com banco de dados. Estes frameworks não precisam converter a representação do banco de dados em uma sintaxe lógica. Eles utilizam a linguagem SQL para geração dos dados que serão utilizados por qualquer técnica de mineração de dados tradicional.
RELAGGS
O Relational Aggregations (RELAGGS) (KROGEL, 2005) é o principal framework que segue a abordagem proposicional diretamente em banco de dados. O RelAggs proposto por KROGEL; WROBEL (2003) utiliza a ideia de agregação, comumente utilizada na área de Data Warehouse (DW). Agregação é uma operação que substitui um conjunto de valores por um simples valor que sumariza as propriedades destes conjuntos. O RelAggs possui dois mecanismos de features constructs:
• para variáveis numéricas, estatísticas descritivas são utilizadas para construção de novas variáveis, tais como: máximo, mínimo, média, soma e desvio padrão;
• para variáveis categóricas, são criadas novas variáveis que são contadores de cada valor distinto.
As tabelas abaixo ilustram o processamento do RELAGGS para duas relações: Cliente (Tabela 3.3) e Parcela (Tabela 3.4). Este é um tipo de relacionamento um para muitos, onde um cliente pode possuir várias parcelas. O conceito que se deseja aprender está localizado na relação Cliente (atributo Alvo). Desta forma, após a aplicação do framework RELAGGS, uma terceira
relação é gerada, representada pela Tabela 3.5, com os valores agregados das parcelas por cliente. O RELAGGS foi adotado pela plataforma WEKA (WITTEN; FRANK; HALL,2011), uma das principais ferramentas gratuitas de mineração de dados.
Tabela 3.3: Relação Cliente
Cliente
Codigo Sexo Estado Civil Alvo
1 M C S
2 F S N
3 M C S
Tabela 3.4: Relação Parcela
Parcela
Cod_Cliente Num_Parcela Vencimento Valor
1 1 01/06/2012 R$ 3,49 1 2 01/07/2012 R$ 68,20 1 3 01/06/2012 R$ 61,63 3 1 01/06/2012 R$ 20,16 3 2 01/07/2012 R$ 1,18 3 3 01/06/2012 R$ 68,68 3 4 01/07/2012 R$ 81,25
Tabela 3.5: Relação gerada através do RELAGGS
Cliente_Parcela
Codigo Sexo EstadoCivil Alvo Parcela_Min Parcela_Med Parcela_Max
1 M C S R$ 3,49 R$ 44,44 R$ 68,20
2 F S N R$ 0,00 R$ 0,00 R$ 0,00
3 M C S R$ 20,16 R$ 55,32 R$ 81,25
Embora existam semelhanças entre a abordagem proposicional de transformação de dados baseado de banco de dados, como por exemplo, o framework RelAggs e a construção de um DW, existem diferenças significativas quando aplicados a soluções de Behavior Scoring System. As diferenças estão no objetivo e modelagem dos dados. O objetivo do DW tradicional é fornecer informações gerenciais para auxiliar na tomada de decisão e sua utilização não afeta a operação da empresa. O objetivo do RelAggs é gerar uma base de dados que será utilizada por algum algoritmo de mineração de dados.
Sistemas de Data Warehouse fornecem uma visão dimensional de grandes quantidades de dados históricos a partir de fontes operacionais. Em um modelo dimensional, os dados são estruturados em fatos e dimensões. Um fato contém as medidas de interesse de um processo
43 de negócio como, por exemplo: faturas, vendas e dívidas; enquanto uma dimensão representa o contexto para a análise de um fato como, por exemplo: loja, produto, vendedor e tempo. As dimensões são organizadas em níveis hierárquicos para facilitar a análise. Em geral, a construção de qualquer Data Warehouse consiste nas seguintes etapas:
• Extrair os dados transacionais das fontes de dados para dentro de uma área de staging; • Transformar os dados transacionais;
• Carregar os dados transformados dentro de um banco de dados dimensional;
• Construção de valores pré-calculados de resumo para acelerar a geração de relatórios; • Construção de uma ferramenta de relatório para exibir os dados como, por exemplo, Online
Analytical Processing(OLAP);
Um dos conceitos mais importante na construção de um DW e de um projeto de KDD é a definição de granularidade. No contexto de DW, ele representa o nível de detalhe contido na tabela de fatos em uma estrutura de dados dimensional (que contém fatos e dimensões). No entanto, apesar de estar associado a tabela de fatos, ela não é considerada a tabela de fatos propriamente dita pela área de DW, ou seja, é um conceito abstrato. Por outro lado, no contexto de mineração de dados, o conceito de granularidade está relacionado com o que se pretende decidir, ou seja, o grão da decisão, que é representado pela tabela alvo em um problema de classificação relacional. Essa escolha depende do entendimento do negócio.
Para ilustrar a diferença na modelagem dos dados entre a etapa de transformação dos dados e a construção de um DW, será utilizado como exemplo um problema de cobrança bancária. O objetivo da construção de um DW para este problema é fornecer uma visão dimensional dos dados para que os gestores possam entender melhor as dívidas na sua carteira de clientes. Já o objetivo da etapa de transformação dos dados é gerar uma base de dados que atenda ao objetivo do projeto de Behavior Scoring System, que para este tipo de problema, é prever os clientes que quitarão suas dívidas em um determinado período de tempo no futuro.
A Figura 3.2 exibe o esquema relacional de um banco de dados para o problema de cobrança, que será utilizado como entrada tanto para construção de um DW como para a etapa de transformação dos dados.
A granularidade na construção do modelo dimensional do DW, para o exemplo de cobrança, está associado à tabela de contrato, portanto, ela será utilizada como Fato e terá como medida de interesse o valor em atraso (dívida). As medidas de interesse são pré-calculadas em um DW para obter um melhor tempo de respostas nas consultas Ad hoc. A tabela de fatos possui, além das medidas de interesse, as chaves primárias das dimensões utilizadas para análise. As dimensões utilizadas são Loja, Vendedor, Tempo (com as hierarquias ano, mês e dia) e Região (com as hierarquias estado, bairro e cidade). As hierarquias são importantes nas dimensões porque facilitam a navegação dos dados através de ferramentas OLAP, utilizando, por exemplo,
Figura 3.2: Esquema relacional para um problema de cobrança
Fonte: O Autor (2015)
as operações de drill-down e drill-up. A Figura 3.3 exibe o esquema dimensional do DW para o problema de cobrança bancária. Um dos resultados gerados por uma análise multidimensional de um DW pode ser observado na Figura 3.5, onde a granularidade da análise é ano e mês da dívida; enquanto a Figura 3.4 apresenta uma perspectiva com um menor nível de detalhamento da tabela de fato, onde a granularidade é apenas ano. Este exemplo reforça que o conceito de granularidade no contexto de DW está relacionado à tabela de fato, porém não representa a tabela de fato propriamente dita.
Figura 3.3: Esquema dimensional do DW para um problema de cobrança
45
Figura 3.4: Exemplo de granularidade ano
Fonte: O Autor (2015)
Figura 3.5: Exemplo de granularidade mês e ano
Fonte: O Autor (2015)
Analisando a modelagem dos dados pela perspectiva da etapa de transformação dos dados, a primeira diferença em relação à modelagem de um DW tradicional para o mesmo problema é a granularidade, que na etapa de transformação dos dados é bem menor do que no DW tradicional. Outros três pontos divergentes são:
1. As medidas de interesse são calculadas com dados que não estão na tabela de fatos; 2. As medidas de interesse não são pré-calculadas e sim calculadas em tempo de execução; 3. Não existe hierarquias nas dimensões.
Vamos retornar ao exemplo anterior de cobrança para ilustrar as diferenças na modelagem dos dados. Na etapa de transformação, a tabela de cliente passa a ser a tabela de fato (granularidade de decisão do projeto), uma vez que o projeto deseja prever os clientes mais propensos a quitarem
