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

sua dívidas em um determinado período de tempo no futuro. As medidas de interesse passam a ser variáveis que contêm informações sobre o comportamento do cliente em um determinado período de tempo e são calculadas em tempo de execução.

Uma tabela desnormalizada na granularidade do projeto com as informações necessárias para aplicação de um algoritmo de mineração de dados é o resultado final da etapa de transfor- mação. A Tabela 3.6 ilustra o produto final da etapa de transformação dos dados para o problema de cobrança.

Tabela 3.6: Exemplo de layout da tabela desnormalizada para o problema de cobrança

Campo Descrição

PKCliente Granularidade do projeto

Idade Informações cadastrais

Estado Informações cadastrais

Cidade Informações cadastrais

Bairro Informações cadastrais

Vendedor Informações cadastrais

Loja Informações cadastrais

Quantidade de compras em um determinado período de tempo Medida de interesse Valor total de compras em um determinado período de tempo Medida de interesse Quantidade de pagamentos em um determinado período de tempo Medida de interesse

Alvo Variável resposta

Para superar a diferença de modelagem dos dados entre o processo de transformação dos dados e a construção de um DW, o RelAggs utiliza o new star schema antes de aplicar as sumarizações e criar uma relação desnormalizada. O algoritmo 3.1 exibe a especificação para construção de um banco de dados utilizando o new star schema. A ideia principal do algoritmo é gerar um novo banco de dados, no qual a chave primária da relação Alvo estará contida em todas as relações Background.

Algoritmo 3.1: Geração do new star schema

Input: BD com um conjunto de Relações Background Rb e uma Relação Alvo Ra Output: BDn (Banco de dados no new star schema)

Copiar Ra de BD para BDn 2: For all as relações Rb ∈ a BD do

Criar uma nova relação em BDn contendo Rb mais a chave primária de Ra; 4: End For

É importante notar que o esquema resultante do 3.1 é diferente do bem conhecido esquema estrela típico em DW, no qual a tabela fato contém as chaves estrangeiras apontando para as chaves primárias das tabelas de dimensões.

47