Exemplo de Utilização do Framework

Para monstrar o funcionamento do framework e da ferramenta será utilizado um banco de dados exemplo, cujo esquema relacional é exibido na Figura 5.12. As tabelas usadas no banco de dados são Cliente, Cônjuge, Endereço, Empréstimo e Parcela. A tabela Cliente possui os dados cadastrais do cliente como idade, endereço e renda, e possui um relacionamento de um para um com as tabelas Cônjuge e Endereço. A tabela Cliente possui um relacionamento de um para muitos com a tabela Empréstimo, que possui as informações do tipo, valor e data do empréstimo. A tabela Empréstimo possui um relacionamento de um para muitos com a tabela Parcela, que possui informações sobre o valor e data de vencimento da parcela. A Figura 5.13 exibe as tabelas no banco de dados MySQL.

Figura 5.12: Esquema relacional para exemplo

Figura 5.13: Tabelas no banco de dados MySQL

Fonte: O Autor (2015)

O minerador de dados deve estabelecer uma conexão com o banco de dados antes de construir um projeto, para isso é necessário especificar os parâmetros de conexão, conforme ilustrado na Figura 5.14. Após estabelecer a conexão, é necessário definir a granularidade do projeto, como objetivo deste exemplo é prever se o empréstimo será honrado pelo cliente, a granularidade é a relação Empréstimo. O usuário deve clicar no conceito Granularity disponível no quadro "A"e escolher a tabela que representa a granularidade, conforme ilustra a Figura 5.15. Na sequência, o minerador de dados deve realizar o mapeamento dos conceitos Record e Behavior para as demais tabelas do banco de dados e especificar os relacionamentos.

Figura 5.14: Tela de configuração da conexão com o banco de dados

85

Figura 5.15: Tela de especificação do conceito

Fonte: O Autor (2015)

A Figura 5.16 ilustra o modelo instanciado dentro da ferramenta para o banco de dados exemplo. O modelo possui três elementos do tipo Record, que representam as tabelas Cliente, Endereço e Cônjuge. O elemento Granularity representa a Tabela Empréstimo, que define a granularidade do projeto. Os elementos dados_cli, dados_end e dados_conj representam o conceito de Relationship, que estabelece o relacionamento entre as relações backgrounds que estão na mesma granularidade de decisão do projeto.

Figura 5.16: Instância do modelo para o exemplo

Fonte: O Autor (2015)

A Figura 5.17 ilustra como é realizado a especificação do elemento dados_cli, que estabelece o relacionamento entre Empréstimo e Cliente. O minerador de dados deve especificar

qual atributo do elemento Empréstimo está relacionado com o elemento Cliente.

Figura 5.17: Tela de especificação do elemento RelationShip

Fonte: O Autor (2015)

O elemento Parcela representa o conceito Behavior. O elemento dados_bh representa o conceito RelationshipTemp, que representa o relacionamento temporal existente entre o elemento Empréstimo (Granularity) e Parcela (Behavior). Este relacionamento possui os atributos fDate e fResume, que representam os campos de data e valor da entidade que tem maior cardinalidade no relacionamento, que neste caso é a entidade Parcela. A Figura 5.18 ilustra como o minerador de dados deve especificar este relacionamento.

Figura 5.18: Tela de especificação do elemento RelationShipTemp

Fonte: O Autor (2015)

O elemento Window representa o conceito de segmentação temporal que será utilizado na geração das variáveis. A Figura 5.19 ilustra como o minerador de dados deve especificar

87 os períodos das janelas temporais, que neste exemplo foram 6, 12 e 24 meses. As Figuras 5.20, 5.21, 5.22 exibem os códigos gerados pelo framework para o exemplo.

Figura 5.19: Tela de especificação das janelas temporais

Fonte: O Autor (2015)

Figura 5.20: Código SQL final gerado pelo framework

SELECT EMPRESTIMO0 . CODEMP, EMPRESTIMO0 . QTDPAR, EMPRESTIMO0 . TIPO , EMPRESTIMO0 . VALOR, CLIENTE1 . ESTADOCIVIL , CLIENTE1 . RENDA, CLIENTE1 . SEXO , ENDERECO2 . BAIRRO , ENDERECO2 . CIDADE , ENDERECO2 . ESTADO, CONJUGE2 . RENDA, CONJUGE2 . SEXO , COMPORTAMENTO_PARCELA_6_APRIORI . * , COMPORTAMENTO_PARCELA_12_APRIORI . * , COMPORTAMENTO_PARCELA_24_APRIORI . * , EMPRESTIMO0 . ALVO FROM EMPRESTIMO EMPRESTIMO0

LEFT JOIN CLIENTE CLIENTE1 ON

CLIENTE1 . CODCLI = EMPRESTIMO0 . CODCLI LEFT JOIN ENDERECO ENDERECO2 ON

ENDERECO2 . CODCLI = CLIENTE1 . CODCLI LEFT JOIN CONJUGE CONJUGE2 ON

CONJUGE2 . CODCLI = CLIENTE1 . CODCLI

LEFT JOIN COMPORTAMENTO_PARCELA_6_APRIORI ON

COMPORTAMENTO_PARCELA_6_APRIORI . CODCLI = EMPRESTIMO0 . CODCLI LEFT JOIN COMPORTAMENTO_PARCELA_12_APRIORI ON

COMPORTAMENTO_PARCELA_12_APRIORI . CODCLI = EMPRESTIMO0 . CODCLI LEFT JOIN COMPORTAMENTO_PARCELA_24_APRIORI ON

COMPORTAMENTO_PARCELA_24_APRIORI . CODCLI = EMPRESTIMO0 . CODCLI Fonte: O Autor (2015)

Figura 5.21: Código SQL para geração da visão auxiliar

CREATE VIEW COMPORTAMENTO_PARCELA AS SELECT

EMPRESTIMO . CODEMP,

(PARCELA . DATAVENC < EMPRESTIMO . DATAEMP) AS APRIORI , DATEDIFF ( EMPRESTIMO . DATAEMP, PARCELA . DATAVENC) AS DAYS, PARCELA . VALOR

FROM

EMPRESTIMO , PARCELA WHERE

EMPRESTIMO . CODEMP = PARCELA . CODEMP Fonte: O Autor (2015)

Figura 5.22: Código SQL para geração da visão comportamenal de seis meses

CREATE VIEW COMPORTAMENTO_PARCELA_6_apriori AS SELECT COMPORTAMENTO_CONTRATO . COD, COUNT( * ) AS FREQUENCY_6_apriori , MAX(DAYS) AS RECENCY_6_apriori , MIN(VALOR) AS VALOR_MIN_6_apriori , MAX(VALOR) AS VALOR_MAX_6_apriori , AVG(VALOR) AS VALOR_AVG_6_apriori , SUM(VALOR) AS VALOR_SUM_6_apriori , STDDEV(VALOR) AS VALOR_STDDEV_6_apriori FROM COMPORTAMENTO_PARCELA WHERE APRIORI I S TRUE AND DAYS > 0 AND DAYS <= 180 GROUP BY COMPORTAMENTO_CONTRATO . CODEMP Fonte: O Autor (2015)

5.5

RESUMO DO CAPÍTULO

Este capítulo apresentou um novo framework inspirado no Desenvolvimento Dirigido por Modelos para sistematizar a tarefa de transformação dos dados em projetos de KDD no domínio de Credit Behavior Scoring. Inicialmente, foi exposta a ideia geral da abordagem de

89 MDD. Em seguida, foram descritas as estratégias utilizadas para aquisição de conhecimento durante a tarefa de transformação dos dados. Por fim, o framework proposto foi apresentado.

O framework proposto possui duas contribuições principais: 1) inclui no processo de construção de novas variáveis o aspecto temporal inerente às soluções de Credit Behavior Scoring, através da análise RFM e da segmentação temporal e 2) automatiza a geração do código SQL, o que reduz o tempo desta tarefa e a possibilidade de erros.

O framework é composto por um meta-modelo que mapeia os principais conceitos do domínio e por um algoritmo de transformação que gera código SQL a partir de modelos instanciados pelo meta-modelo proposto. No próximo capítulo, serão apresentados os dois estudos experimentais realizados para validar o framework proposto.

6

RESULTADOS EXPERIMENTAIS

Este Capítulo apresenta os dois estudos experimentais realizados para mensurar as contribuições do CoMoVi. O primeiro avalia o aumento do poder discriminatório proporcionado pelo framework e o segundo mede a redução do tempo proporcionada. Os experimentos serão detalhados a seguir.

6.1

EXPERIMENTO I

Para validar a eficácia do CoMoVi foi realizado um estudo experimental comparando- o com os principais frameworks encontrados na literatura. O RelAggs foi escolhido como representante da abordagem proposicional e o CbMVV como representante da abordagem de mineração de dados relacional. Estes são os dois principais frameworks de cada abordagem, conforme analisado no Capítulo de Abordagens de Transformação de Dados. As mesmas técnicas de mineração de dados foram aplicadas às bases de dados geradas pelos três frameworks. Desta forma, é possível verificar qual framework de transformação de dados proporciona maior poder discriminatório.