Monografia

    Aluno
    Daniel de Jesus Dominguez
    danieljd@linux.ime.usp.br

    Supervisor
    João Eduardo Ferreira
    jef@ime.usp.br

    Tipo de Trabalho
    Iniciação Científica

Parte 1

Parte 2

1. Desafios e frustrações

2. Disciplinas relevantes

3. Interação

4. Diferenças notadas

5. Observações sobre aplicação de conceitos

6. Atuação na área

7. Agradecimentos

Parte 1

    Existem no mercado muitos produtos de Data Mining, responsáveis por realizar predição, clustering, classificação, forecasting, encontrar regras de associação entre dados, entre muitas outras funções.
    Data mining é um processo de busca de padrões úteis a partir de uma grande base de dados, visando reunir informações específicas para a tomada de decisões em negócios.
    Usa complexas pesquisas em grandes volumes de dados para explorar e identificar relacionamentos entre variáveis que antes eram previamente independentes. Isso permite que as organizações gerenciem relacionamentos de causa e efeito mais eficientemente, e antecipem políticas para isso. Eis algumas técnicas utilizadas:

• Classificação: agrupa itens baseados em atributos pré-definidos, como, por exemplo, identificar os clientes que moram em um determinado bairro de uma determinada cidade, que tenham apartamento próprio e viajem ao exterior.
• Associação: busca correlações entre itens e indivíduos, deduzindo relacionamentos. Um exemplo típico é identificar que quem compra peixe compra também vinho branco.
• Clustering: agrupa itens baseados em atributos. Exemplo: clientes tipo C serão aqueles que tem renda mensal menor que R$ 2.000,00; clientes tipo B terão renda mensal entre R$ 2001,00 e R$ 5.000,00 e clientes tipo A terão renda maior que R$ 5001,00. 
• Predição: busca prever tendências. Exemplo: prever que no ano de 2005 o ticket médio de cada checkout será de R$ 500,00.<

• Altos custos.
• Complexidade de ferramentas.
• Preparação dos dados para mineração (80% do trabalho). Os dados devem estar limpos, consistentes e livres de excessivas nulidades. (foco maior do trabalho)
• Dificuldade em se estimar a taxa de retorno do investimento. Uma vez que o objetivo do DM é descobrir tendências em dados invisíveis de outra maneira, torna-se impossível estimar a partir de algo desconhecido.
  

    O objetivo principal do trabalho é verificar a viabilidade desses produtos, dos limites de representação de dados nos algoritmos, comparando as soluções e a delimitação da utilização em função do comportamento dos vários tipos de instâncias de dados e aplicações.
    Analisa-se, por exemplo, o formato de entrada dos dados, pois o custo de formatá-los de maneira que o programa os aceite pode ser alto se comparado com os benefícios obtidos.
    Além disso, espera-se obter em algum banco de dados existente resultados práticos e convincentes do processo realizado por esses produtos.

    Foram levantados muitos produtos, que realizavam muitas tarefas. Porém, para termos práticos, 2 deles foram analisados. Quando falo em termos práticos, refiro-me ao banco de dados utilizado como parâmetro para testes, o VGDN.
    O VGDN (Viral Genetic Diversity Network) é um projeto temático da FAPESP na área de genômica, e tem por objetivo estudar as variedades genéticas de quatro vírus: HIV-1 (AIDS), HCV (hepatite C), Hantavírus (causador de uma síndrome pulmonar) e RSV (infecções no trato respiratório, sobretudo em crianças).
    O IME é o responsável pelo suporte computacional. O banco de dados clínicos armazena todas as informações relativas aos pacientes com AIDS e seus tratamentos. Há tabelas de pacientes, de instituições envolvidas no levantamento dos seus dados (via preenchimento de questionários) e na análise das amostras de sangue, de critérios de análise dos exames realizados nessas amostras, de drogas utilizadas, etc. 
    O VGDN foi utilizado pra realizar os testes dos programas, tentando-se extrair o máximo possível de novas informações. O banco possui cerca de 400 registros (ainda está no começo). Há dados sobre o comportamento do paciente, bem como de seus parceiros, drogas tomadas na tentativa de controlar a doença, eventuais resistências a algumas delas, etc. Um dos objetivos é achar relações implícitas entre esses dados, como por exemplo descobrir se uma determinada droga aplicada conjuntamente com outra ajuda a diminuir a carga viral. Outro objetivo poderia ser confirmar na prática o que já se suspeita sobre determinado comportamento e/ou relacionamento dos atributos.
    Os produtos analisados foram Cubist e See5. O Cubist se preocupa em modelar numericamente os dados (calculando o valor de um atributo em relação a outros), já o See5 faz classificação dos mesmos (divisão entre classes de dados).

Cubist

• Funções: modelagem numérica.
• Técnicas: regressão, regras.
• Plataformas: Windows, Unix (Linux, Irix, Solaris).
• Gera valores de predição reais com as regras.
• Mais rápido e fácil de entender que redes neurais.
• Modelos cubistas são expressados como coleções de regras, onde cada regra tem associado um modelo linear de várias variáveis.
• Sempre que uma situação é compatível com as condições da regra, o modelo associado é usado para calcular o valor de predição.
  

See5

• Funções: classificação.
• Técnicas: árvores de decisão, regras.
• Plataformas: Windows, Unix (Linux, Solaris, Irix).
• O algoritmo de classificação C5.0 é implementado nesses 2 produtos: See5 em Windows e C5.0 em Unix.
• Código fonte em C é fornecido de modo que classificadores gerados possam ser usados em outras aplicações.

    Alguns resultados gerados pelos programas para resistência a drogas:

Class specified by attribute `PRAPV'

Rules:

Rule 1: (95.3, lift 1.8)
PRIDV = Susceptible
-> class Susceptible [0.990]

Rule 2: (10.6, lift 1.7)
AZT = Ja tomou a droga
PRIDV = Potential low-level resistance
-> class Susceptible [0.921]

Rule 3: (9.9, lift 14.5)
AZT = Nunca tomou a droga
PRIDV = Potential low-level resistance
-> class Low-level resistance [0.916]

Rule 4: (2.2, lift 12.1)
PRIDV = Low-level resistance
-> class Low-level resistance [0.764]

Rule 5: (33.2, lift 5.4)
AZT = Ja tomou a droga
NVP = Nunca tomou a droga
EFV = Nunca tomou a droga
PRIDV = High-level resistance
-> class Intermediate resistance [0.972]

Rule 6: (1.7, lift 4.0)
PRIDV = Intermediate resistance
-> class Intermediate resistance [0.728]

Rule 7: (18.3, lift 4.6)
NVP = Ja tomou a droga
PRIDV = High-level resistance
-> class High-level resistance [0.951]

Rule 8: (14.2, lift 4.5)
EFV = Ja tomou a droga
PRIDV = High-level resistance
-> class High-level resistance [0.938]

Rule 9: (9.3, lift 4.4)
AZT = Nunca tomou a droga
PRIDV = High-level resistance
-> class High-level resistance [0.911]

    Aqui encontra-se uma forte relação entre a resistência à droga APV e a resistência à droga IDV. Assim, trocar IDV por APV em um coquetel de um usuário muito resistente à IDV, por exemplo, não surtirá efeito, já que como pode-se ver pelas regras 5 a 9, resistência alta ao IDV implica, em geral, em resistência alta ao APV.
    Foram encontradas outras relações entre as resistências: IDV e RTV (e vice-versa), NFV e IDV, SQV e NFV, DDI e DDC, D4T e AZT, etc.
    Agora resultados com relação à condição atual do paciente no preenchimento do prontuário médico: assintomático ou sintomático.

Class specified by attribute `PCondAtual'

Rules:

Rule 1: (3, lift 6.4)
PUsaDroga = Sim (paciente usa drogas injetáveis)
PUltCD4Val <= 100 (número de células CD4 menor ou igual a 100)
NFV = Nunca tomou a droga
-> class Sintomatico [0.800]

Rule 2: (6/1, lift 6.0)
EUsouARV = Nao (nunca usou esquema anti-retroviral)
PUltCD4Val <= 100
-> class Sintomatico [0.750]

Rule 3: (7/3, lift 4.5)
PUsaDroga = Sim
PUltCD4Val <= 100
-> class Sintomatico [0.556]

Rule 4: (41/21, lift 3.9)
ECondAtual = Com sintomas/doenca (paciente declarou em entrevista que não tem sintomas/doenças associadas)
-> class Sintomatico [0.488]

Rule 5: (202/9, lift 1.1)
ECondAtual = Sem nenhum sintoma/doenca
PUltCD4Val > 100
-> class Assintomatico [0.951]

Rule 6: (119/6, lift 1.1)
EDoencas = Nunca apresentou doença e/ou condicao associada a AIDS
-> class Assintomatico [0.942]

Rule 7: (32/1, lift 1.1)
PRelacoesH = Nao (não manteve relações com indivíduos sabidamente soropositivos)
RTD4T = Susceptible (é suscetível à droga D4T)
-> class Assintomatico [0.941]

Rule 8: (28/1, lift 1.1)
PStatusARV = Nao faz e nunca fez uso (nunca usou esquema anti-retroviral)
-> class Assintomatico [0.933]

Rule 9: (141/9, lift 1.1)
ECondAtual = Sem nenhum sintoma/doenca
EUsouARV = Sim
-> class Assintomatico [0.930]

(a)  (b)  (c) <-classified as
---- ---- ----
29   4          (a): class Sintomatico
     227        (b): class Assintomatico
     4    1     (c): class Ignorado

        Vemos nesse caso que houve classificações erradas. Quatro pacientes sintomáticos foram classificados como assintomáticos. Isso, sem dúvida, é ruim. Mas poderia ser pior ainda. Imagine um caso em que um indivíduo é classificado como não soropositivo, sendo que ele o é.
        Podemos ver aqui um bom limite para avaliar se o paciente está ou não assintomático: o número de células CD4. Essas células são as atacadas pelo vírus HIV. Assim, quanto menos células CD4, pior o estado do paciente. No caso acima (regras 1, 2, 3 e 5), pode-se notar que 100 parece ser um limite. Assim, um paciente cuja contagem de CD4 seja menor que 100, provavelmente está com sintomas e/ou doenças associadas à AIDS. O mesmo vale pro caso contrário.

        As relações acima foram confirmadas em sua maioria por uma médica responsável pelo projeto. Já se sabia de antemão algumas delas (principalmente as associações entre as resistências).
        Mas sendo o objetivo principal do trabalho analisar a viabilidade desses softwares, cheguei à conclusão de que sua relação custo-benefício é alta. Alguns problemas:

• a interface não é muito amigável. O modo de entrada dos dados, menos ainda.
• é preciso montar uma espécie de “layout”, dizendo aos programas qual atributo será o alvo de pesquisas, bem como especificar os tipos de dados que pode conter cada atributo.
• isso teve de ser feito à mão, já que é complicado analisar o conteúdo dos campos e decidir por um ou outro tipo de dado.
• depois de extraído o arquivo de dados do VGDN, com um script em Perl, os dados são transformados, de maneira que fiquem mais inteligíveis e que o programa possa lê-los, sempre com base no “layout” fornecido.
• o banco possui poucos registros e isso acaba facilitando erros que ocorrem por coincidências, como por exemplo encontrar-se uma relação que diz que todo paciente nascido antes de uma data tem carga viral em torno de x.
• há muita falha na entrada dos dados, sendo que somente cerca de 260 puderam ser aproveitados.

    Os problemas em destaque são os principais. Perde-se muito tempo tentando ajustar os dados de entrada. Creio que posso fixar essa relação em 3 pra 1. Perde-se 3 vezes mais tempo tentando moldar a entrada do que achando relações satisfatórias.

• http://watson.fapesp.br/virus/menu.htm
• http://www.rulequest.com
• http://www.spss.com.br
• http://www.google.com.br (sempre ele)
• JEFF ULLMAN, JENNIFER WIDOM, A first course in database systems, 2nd edition

Parte 2

Desafios

• lidar com uma área totalmente diferente (biológica).
• aprender a lidar com os softwares.
• escolher aqueles que melhor se adaptavam à situação.
• saber diferencias resultados encontrados em satisfatórios ou não, devido à geração de regras nem sempre condizente com o mundo real.

Frustrações

• não conseguir encontrar muitos resultados novos, apenas confirmando alguns dos que já se tinha alguma idéia a respeito.
• não ter programado muito.

• MAC242 - Laboratório de Programação II: deu-me noções de Perl, que usei para formatar os dados de entrada.
• MAC246 - Sistemas de Banco de Dados: deu-me noções sobre as estruturas de banco de dados, possibilitando-me compreender as relações entre os bancos.
• MAE121 - Introdução à Probabilidade e Estatística I: ajudou-me nos momentos de decisão sobre os resultados que fui obtendo, descartando os que possuiam baixa probabilidade de acerto e mantendo aqueles que pareciam mais satisfatórios.
• MAC335 - Leitura Dramática: ajudou-me na comunicação com meus colaboradores.

        Não houve maiores problemas de interação com a equipe. Sempre que preciso fui atendido assim que possível. O maior problema encontrado foi a diferença de vocabulário "computês" e "biologuês", além do não tão rápido feedback do pessoal responsável pela área médica/biológica do projeto.

        A principal diferença é que não havia prazos. Tive toda a liberdade para exercer o trabalho, assim sendo eu mesmo estipulava meus prazos, e assim que terminava alguma tarefa, conseguia obter alguns resultados ou tinha dúvidas que não permitiam o andamento do trabalho, procurava o meu colaborador.

        Sem dúvida as disciplinas acima citadas me deram muitos conceitos e idéias que contribuíram pra facilitar meu trabalho, mas é claro que outros conceitos aprendidos durante o curso também contribuíram, seja aprimorando o raciocínio, seja ampliando a visão de mundo e idéias.

        Se eu continuar na área de banco de dados, pretendo me inteirar das mais novas tecnologias, tendo assim uma visão mais prática, já que o curso é voltado pra uma formação mais teórica.
        Em relação ao projeto, o VGDN ainda não está completamente pronto, assim sendo um outro aluno poderá dar continuidade ao trabalho, caso decidam pela aquisição de algum software estudado.

7. Agradecimentos

        Agradeço a Luciano V. de Araújo e Carlos A. Leite pela colaboração, apoio e ajuda.