Untitled - aplicação prática de um ambiente simulacional e análise

ii
Relatório de Projecto
Data Mining associado ao Diagnóstico Médico
José Miguel Bernardo Cordeiro
20186
Instituto Politécnico de Bragança
Escola Superior de Tecnologia e Gestão
Bragança
Engenharia Informática
3o Ano
[email protected]
Setembro 2011
A Escola Superior de Tecnologia e Gestão não se responsabiliza pelas opiniões expressas neste
relatório.
ii
Aprovações
Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como
demonstrador do trabalho desenvolvido no âmbito da disciplina de Projecto.
_____________________________________
Prof. Doutor Paulo Matos – Orientador
Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma
como demonstrador do trabalho desenvolvido no âmbito da disciplina de Projecto.
_____________________________________
Prof. Arguente
Aceite para avaliação da unidade curricular de Projecto
iii
iv
Abstract
Having access to accurate and organized is an asset for any decision process.
This project stems from a concern shown by the stakeholders of the problem domain, healthcare professionals, to achieve greater efficiency in the use of antibiotics. It is thought that the
medic history of the patients can be used to help choose the more appropriate antibiotic to
prescribe in each case.
This project is therefore to explore the existing data, including using Data-Mining techniques to extract hidden or not easily identifiable information from the data, in order to ascertain
the feasibility and usefulness of such data for the problem at hand.
vi
Resumo
Ter a informação correcta e organizada é uma mais-valia para qualquer processo de decisão.
Este projecto resulta de uma preocupação demonstrada por parte dos próprios intervenientes
do domínio do problema, os profissionais de saúde, no sentido de obter uma maior eficácia na
utilização de antibióticos. Pensa-se que a informação existente sobre o histórico dos vários
utentes possa ser utilizada para identificar o antibiótico a receitar mais adequado a cada caso.
Este projecto tem assim por objectivo explorar os dados existentes, nomeadamente com recurso a técnicas de Data-Mining no sentido de extrair informação que à partida não é facilmente
identificável, no sentido de averiguar a viabilidade e utilidade desses dados para o problema em
questão.
Palavras-chave: Data-Mining, Extracção de conhecimento.
viii
Agradecimentos
Durante o último ano em que estive envolvido neste projecto de investigação e análise desta
tecnologia, tive a oportunidade de contar com o apoio de várias pessoas que contribuíram para
a realização deste projecto.
Em primeiro lugar, quero agradecer ao meu orientador, Professor Paulo Matos, pela ajuda e
pela sua visão simples e crítica de ver os problemas para a realização deste projecto.
Também quero agradecer à minha família e amigos que estiveram sempre perto de mim e
que me apoiaram durante o difícil e duro percurso que é a licenciatura.
Também quero agradecer à comunidade que contribuiu para a criação do LATEX que é uma
ferramenta espantosa de criar texto saindo este relatório através dessa ferramenta.
E por fim, quero agradecer ao Instituto Politécnico de Bragança por me ter acolhido e me
ter proporcionado dos 3 melhores anos da minha vida.
A todos, os meus maiores agradecimentos!
x
Lista de abreviaturas
• BD – Base de Dados
• BIDS – Business Intelligence Development Studio
• CSV – Comma separated value
• DM – Data-Mining
• GUI – Graphical User Interface
• IDE – Integrated Development Environment
• JDBC – Java Database Connectivity
• MD – Mineração de Dados
• SGBD – Sistema de Gestão de Base de Dados
• SQL - Structured Query Language
• YACC – Yet Another Compiler Compiler
xii
Índice
1
2
3
4
Introdução e Objectivos
1
1.1
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Objectivo do projecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Conceitos
5
2.1
Data-Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Tipos de abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1
Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.2
Clustering (ou Segmentação) . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.3
Associação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.4
Regressão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.5
Previsão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.6
Análise Sequencial . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.7
Análise de desvio . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Ferramentas utilizadas
11
3.1
Weka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3
NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.4
Outras ferramentas Data Mining existentes . . . . . . . . . . . . . . . . . . . .
14
3.4.1
BIDS (comercial) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.4.2
Tanagra (gratuíto e de código aberto) . . . . . . . . . . . . . . . . . .
15
Implementação
17
4.1
Descrição do Dataset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.2
Análise do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.3
Formulação do processo de mineração . . . . . . . . . . . . . . . . . . . . . .
21
4.3.1
Problemas resultantes do modelo de mineração . . . . . . . . . . . . .
22
4.3.2
Decisões para a resolução dos problemas . . . . . . . . . . . . . . . .
22
Aplicação do Algoritmo de Data Mining . . . . . . . . . . . . . . . . . . . . .
27
4.4
xiii
4.5
4.6
4.7
Como gerar resultados através do Weka . . . . . . . . . . . . . . . . . . . . .
Síntese dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Análise crítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
30
33
Conclusões
5.1 Análise crítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
35
36
A Código
A.1 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Rotina para geração dos ficheiros CSV . . . . . . . . . . . . . . . . . . . . . .
39
39
45
5
xiv
Lista de Figuras
2.1
Àrvore de decisão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
GUI do Weka. . . . . . . . . . . . . . . .
Ave Weka inspirada no programa de MD.
Logo MySQL. . . . . . . . . . . . . . . .
Logo do IDE NetBeans. . . . . . . . . . .
Logo do BIDS. . . . . . . . . . . . . . .
Logo Tanagra. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
13
14
15
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
Imagem do dataset original montada numa BD. . . . . . . . . . . .
Exemplo do dataset a criar para o modelo de mineração. . . . . . .
Ligações da tabela da BD. . . . . . . . . . . . . . . . . . . . . . .
Resultado da simplificação da tabela principal. . . . . . . . . . . . .
Resultados do valor da Sensibilidade. . . . . . . . . . . . . . . . .
Resultado da combinação antibiótico/microorganismo e vice-versa. .
Resultado de combinações repetidas. . . . . . . . . . . . . . . . . .
Representação do algoritmo k-means. . . . . . . . . . . . . . . . .
Escolha do método clustering e do algoritmo. . . . . . . . . . . . .
Escolha dos parâmetros do algoritmo k-means. . . . . . . . . . . .
Começar a gerar resultados . . . . . . . . . . . . . . . . . . . . . .
Resultados Exemplo 1. . . . . . . . . . . . . . . . . . . . . . . . .
Resultados Exemplo 2. . . . . . . . . . . . . . . . . . . . . . . . .
Resultados Exemplo 3. . . . . . . . . . . . . . . . . . . . . . . . .
Resultados Exemplo 4. . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
21
23
23
24
25
26
27
28
28
29
30
31
32
32
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
xv
xvi
Capítulo 1
Introdução e Objectivos
1.1
Introdução
O evoluir da informática e dos meios de comunicação potenciou o crescimento da sociedade da
informação. O que era outrora desprezado pelo facto de ser inconsistente, redundante, disperso,
de pouca utilidade, deu origem a informação estruturada, classificada e de uma enorme utilidade
e influência para a sociedade em geral. Hoje em dia sabe-se o valor real dessa informação, que
condiciona tudo e todos, desde a economia à política. Ter informação é um trunfo, uma mais
valia, uma vantagem concorrencial.
É assim natural o aparecimento exponencial de fontes de informação, cada vez com dados
de maior qualidade e em maior quantidade. Percebeu-se inclusive que a prospecção dessas
fontes de dados permitia obter informação, e até mesmo conhecimento, que à partida não seria
previsível obter. É nesta realidade que surge este trabalho de projecto, que pretende tirar partido
das tecnologias emergentes desta realidade, para aferir novas informações e mais conhecimento,
neste caso, aplicado à área da saúde.
Este projecto resulta de uma preocupação manifestada pelos próprios intervenientes do
domínio do problema: os profissionais da saúde. Segundo estes, determinados microorganismos (vírus e bactérias) têm demonstrado uma enorme capacidade de adaptação que lhes permite
ser imunes aos novos antibióticos, reduzindo o efeito destes ou chegando mesmo a torná-los obsoletos. O caso é de maior gravidade nos espaços de saúde pública, que são sistematicamente
expostos a novas estirpes trazidas pelos utentes. Estes locais acabam por funcionar eles próprios
como incubadoras e fontes indesejáveis de propagação desses mesmos vírus e bactérias.
Ter informação actualizada sobre a manifestação destas estripes ou variantes, ou simplesmente identificar casos problemáticos de utentes que de alguma forma carregam consigo estes
microorganismos, é fundamental para despoletar acções que permitam controlar a sua propagação. Trata-se de uma questão de saúde pública, merecedora da nossa maior atenção, pois
como se diz na gíria "com a saúde não se brinca!".
Um dos grandes desafios da medicina actual é garantir um controlo mais afinado da apli1
cação dos antibióticos. A sua utilização de forma desmedida como recurso para todos os males,
que muitas vezes nem sequer tem em conta um diagnóstico preciso e o historial clínico do paciente, levou a que as bactérias e vírus se fossem adaptando, tornando-se mais resistentes ou
mesmo imunes a esses antibióticos. Casos há, que já só com as soluções mais agressivas é que
se consegue tratar os pacientes.
Ter presente o historial clínico do paciente é muito importante para se receitar o antibiótico
adequado, aquele que vai permitir curar o paciente sem no entanto recorrer a soluções mais
agressivas, ou que devem ser salvaguardadas para casos mais graves, ou para outro tipo de
diagnósticos.
É também sabido que mesmo perante o mesmo diagnóstico, a reacção dos pacientes a um
determinado antibiótico, nem sempre é igual. Novamente, o historial clínico tem um peso
importante na compreensão deste fenómeno, mas também a própria fisionomia do paciente,
entre outros elementos.
1.2
Objectivo do projecto
O objectivo deste projecto é desenvolver um modelo de mineração de dados (MD) que permita
caracterizar e agrupar os utentes segundo o seu historial de análises e a sua fisionomia. Esperase que este modelo possa posteriormente ser utilizado num sistema de apoio à decisão que
permita identificar os antibióticos mais adequados a receitar para cada tipo de caso.
2
1.3
Estrutura do documento
A estrutura deste relatório foi criada com o objectivo de que o leitor perceba o que se pretende,
o que contém e o que se realizou ao longo projecto.
O primeiro capítulo pretende enquadrar o leitor para o tema do projecto, mostrando a motivação deste, os objectivos e também a forma como o relatório de final de curso está estruturado.
O segundo capítulo mostra os conceitos de MD e as abordagens genéricas deste tema.
O terceiro capítulo fala das ferramentas utilizadas na elaboração deste projecto e de outras
ferramentas que se poderiam utilizar.
O quarto capítulo é sobre a implementação, onde está presente, a descrição do dataset; uma
análise do problema; formulação do modelo de mineração; problemas resultantes do modelo de
mineração; decisões para a resolução dos problemas, aplicação do algoritmo utilizado; síntese
dos resultados e, por fim, uma análise crítica dos resultados obtidos.
O quinto e último capítulo encontram-se as conclusões com uma análise crítica e possíveis
trabalhos futuros.
3
4
Capítulo 2
Conceitos
2.1
Data-Mining
Data-mining (DM) [11, 9, 23, 4, 13, 24], ou Mineração de Dados (MD), é o processo de explorar
grandes quantidades de dados à procura de padrões e relações entre dados. “Este processo
permite encontrar informação valiosa só pelo facto de analisar dados”. [1]
O ser humano aprendeu com a observação de padrões, com a formulação de hipóteses e com
a realização de testes para descobrir novas regras. Mas quando a quantidade de informação é de
tal forma gigantesca um ser humano não consegue assimilar tantos conteúdos, pois a solução
encontrada foi usar o computador para detectar relações novas e úteis.
A ideia é contruir um programa que passe por bases de dados e procure padrões ou informação semelhante, para depois prever, classificar ou associar acertadamente dados que se
poderão adicionar posteriormente. Poderá surgir dificuldades porque muitos padrões são banais, outros poderão ser coincidentes e os dados reais sejam imperfeitos, porque há sempre
dados ilegíveis e falta dados, por isso, tudo que poderá ser descoberto, poderá não ser exacto.
Os algoritmos precisam de ser capazes de lidar com os dados e extrair regularidades que não
são exactas mas que poderão ser úteis mais tarde.
Hoje em dia, a MD surge para ser aplicada para a pesquisa científica ou até para estimular
os lucros de empresas.
Um dos exemplos que se destaca, é o de uma empresa de seguros, que experimentou esta
tecnologia e obteve resultados interessantes, em que os clientes que cancelavam os seus seguros
de saúde eram aqueles que menos o usavam. Para não estarem a perder clientes iniciaram uma
nova campanha, porque conquistar um novo cliente pode custar sete vezes mais do que manter um cliente antigo. Com outro cruzamento de dados, puderam verificar quais os clientes
com maior hipótese de comprar um seguro para os carros, então fizeram novos contratos com
clientes para ter ambos os seguros a um preço reduzido. Contudo, apesar da empresa ganhar
menos com este novo método, o facto é que resultou, obtendo mais lucros graças a esta tecnologia. Outro exemplo a ter em conta e que ficou para a história, é o de uma empresa que pegou
5
na sua Data-Warehouse1 e descobriu que às sextas-feiras, homens entre os 20 e 35 anos que
compravam fraldas descartáveis, também compravam cerveja. A partir desta constatação, e por
experiência, puseram os produtos lado a lado, sendo o resultado o previsto, ou seja, a venda de
cerveja e fraldas descartáveis disparou.
_________
1 - Uma Data-Warehouse é uma base dados construída com o propósito de integrar grandes
quantidades de dados e facultar um acesso mais rápido e eficiente para efeitos de análise.
6
2.2
2.2.1
Tipos de abordagem
Classificação
Uma das abordagens mais utilizadas na resolução de problemas de MD, é a classificação [12,
17, 3]. Como o próprio nome deixa antever, a ideia é classificar elementos segundo métricas
discretas que são previamente definidas. É o tipo de solução cuja aprendizagem é normalmente
supervisionada, o que significa que, com base em exemplos, tenta-se construir um modelo que
permita posteriormente efectuar a classificação dos elementos de entrada.
Os modelos criados são normalmente do tipo árvores (de decisão) ou conjunto de regras.
O algoritmo J48 (ou C4.5) permite obter uma árvore de decisão com base em informação
previamente obtida (dataset, ou dados de uma base de dados, etc.).
Temos como exemplo, a decisão de uma criança ir para a rua brincar. Aplicando o algoritmo,
obtém-se a árvore de decisão na figura 2.1.
Figura 2.1: Àrvore de decisão.
Então a figura 2.1 mostra que:
• quando está nublado vai brincar.
• quando está sol e a humidade estiver:
alta, não vai brincar.
normal, vai brincar.
• quando está a chover:
se houver vento, não vai brincar.
se não houver vento, vai brincar.
7
2.2.2
Clustering (ou Segmentação)
O método de clustering [7], com base num conjunto de objectos de dados, tenta identificar
grupos onde os elementos sejam similares entre si. Os não similares ficam fora do cluster
ou dentro de outro(s) cluster(s), porque um elemento pode ter várias afinidades com outros
elementos de outros grupos. É um tipo de classificação não supervisionada, ou seja, o algoritmo
tenta segmentar os elementos agrupando-os com a afinidade que têm.
Para esta abordagem existem algoritmos como EM, K-means, etc.
2.2.3
Associação
A associação [12, 22, 8] identifica e caracteriza ligações naturais que podem existir entre classes,
com o objectivo de identificar associações relevantes entre elementos e definir regras que caracterizam essas associações para obter melhor informação.
Esta técnica é umas das melhores técnicas de MD para descobrir informação ignorada. A
ideia é identificar itens consistentes e verificar a sua ocorrência relativamente a outros itens.
2.2.4
Regressão
A regressão [12] é semelhante à classificação mas aplicada a um domínio continuo, ou seja,
não se pretende classificar segundo uma escala discreta, mas sobre uma escala contínua. Então,
para um conjunto de entradas, pretende-se saber qual o valor que deverá corresponder ao valor
de saída segundo uma abordagem genérica onde é possível utilizar técnicas de regressão linear,
árvores de regressão ou redes neuronais.
8
2.2.5
Previsão
A previsão [17, 12] visa identificar efeitos sazonais e tendências em séries de dados temporais.
O que permite prever a evolução futura dessas séries, com base nos valores passados. É útil
para identificar fenómenos tendenciais como estimar a evolução dos mercados financeiros, ou
mesmo prever a evolução do consumo de um determinado bem ou serviço.
2.2.6
Análise Sequencial
A análise sequêncial [12] é uma técnica que pretende identificar padrões comportamentais em
séries de eventos designados por sequências. Esta, consegue perceber o percurso de ligações,
operações que executa, que páginas consulta, entre outros, dos utilizadores num determinado
site. Com base nesses padrões consegue determinar os percursos mais utilizados. É semelhante
à previsão em que aqui entram valores discretos ou estados.
2.2.7
Análise de desvio
A análise de desvio [12] identifica padrões comportamentais que raramente surgem, como por
exemplo, identificar acessos ilegais ou não desejados a sites ou também o uso de determinados serviços que alguém não subscreveu. Podem ser aplicadas às árvores de decisão, redes
neuronais ou mesmo técnicas de clustering.
9
10
Capítulo 3
Ferramentas utilizadas
3.1
Weka
Weka [26, 15] é um software, feito em Java e livre, que agrega algoritmos que provém da área
da inteligência artificial. Assim, faz com que o computador aprenda através do uso de um
algoritmo dessa área. Este procede à análise dos dados fornecidos, recorrendo à técnica de MD
tentanto encontrar padrões para gerar hipóteses e soluções.
Figura 3.1: GUI do Weka.
O Weka é uma boa ferramenta, mas tem um grande
defeito, é que existe pouca documentação e o interface
é bastante confuso e difícil de manusear. A título de curiosidade, o weka é uma ave neozelandesa que está em
perigo de extinção (figura 3.2). É conhecida pela sua
curiosidade e agressividade. Esta ave dá nome a uma
vasta colecção de algoritmos de máquinas de conhecimento.
O Weka contém as ferramentas necessárias para re- Figura 3.2: Ave Weka inspirada no
alizar transformações sobre os dados, tarefas de clas- programa de MD.
sificação, regressão, clustering, associação e visualização. Podendo também adicionar novas funcionalidades.
11
3.2
MySQL
MySQL [19, 21, 20] é um sistema de gestão de BD, que usa a linguagem SQL. Foi escrito em C
e C++, para fazer o parser das queries usa o YACC. Este SGBD tem um grande sucesso pelo seu
desempenho, estabilidade, por ser fácil de instalar e configurar, por não exigir grandes recursos,
por existirem drivers para as principais plataformas de desenvolvimento (Java, PHP, .NET, etc),
por haver versões para os principais sistemas operativos UNIX, Windows e Macintosh, mas
principalmente porque é livre (baseado em GPL). É usado muitas vezes para suportar portais
e aplicações web e, também, para aplicações locais. É neste momento proprietário da Oracle,
mas antes passou pela Sun Microsystems.
Figura 3.3: Logo MySQL.
12
3.3
NetBeans
O NetBeans [25] é um IDE – Integrated Development Environment - gratuito e de código aberto
para programadores nas linguagens Java, C, C++, PHP, Groovy, Ruby, entre outras. Dado
ser implementado em Java pode ser utilizado em qualquer sistema operativo para o qual já
exista a Máquina Virtual do Java (JVM - Java Virtual Machine), o que actualmente abrange
praticamente todas as plataformas computacionais.
Pelo facto de ser uma aplicação de código aberto e por facultar soluções que permitem facilmente expandir as suas funcionalidades, o Netbeans disponibiliza um vasto conjunto de recursos para os programadores, capaz de suportar o desenvolvimento das mais diversas aplicações,
como web sites, web services, aplicações para dispositivos móveis, aplicações stand-alone, aplicações distribuídas, etc.
Como é comum nos IDE’s mais evoluídos, o Netbeans faculta um editor com tecnologia intellisense e highlight, compiladores e interpretadores, depuradores de código para as linguagens
já citadas, e muitos outros recursos que potenciam a produtividade de quem o utiliza.
Figura 3.4: Logo do IDE NetBeans.
13
3.4
3.4.1
Outras ferramentas Data Mining existentes
BIDS (comercial)
Business Intelligence Development Studio (BIDS) [27, 5, 14] é um IDE da Microsoft que é
parte integrante do SQL Server 2008 e que tem por base o Visual Studio 2008, parametrizado
para facultar recursos especializados para o desenvolvimento de soluções de análise de dados e
business intelligence1 .
O SQL Server é um servidor de base de dados relacionais, mas não só, é também capaz de
albergar Data-Warehouses, processos de integração de dados, processos de geração automática
de relatórios, entre outros. Faculta directamente ou através do BIDS vários recursos para a
análise de dados, designadamente por OLAP (On-line Analytical Processing) e por MD.
Figura 3.5: Logo do BIDS.
_________
1 - O business inteligence é o processo de organizar, analisar, partilhar e monitorizar as informações mais importantes para o trabalho final.
14
3.4.2
Tanagra (gratuíto e de código aberto)
Tal como o Weka, o Tanagra [18, 28] é um software livre e de código aberto, para análise de
dados, que inclui muitas soluções de MD, mas também de análise estatística. Este projecto vem
suceder a outro (SIPINA) que implementa vários algoritmos de aprendizagem com interacção
visual para construções de árvores de decisão. Este programa contém vários algoritmos de
aprendizagem supervisionada, bem como algoritmos de aprendizagem não supervisionada para
clustering, análise de desvio, etc.
O principal objectivo do Tanagra é facultar aos investigadores e estudantes uma framework
de suporte à investigação, que lhes permita testar os seus próprios algoritmos e compará-los com
os já existentes. É também um software fácil de usar, dado que, permite descrever os modelos
de mineração de forma gráfica e com recurso a uma interface desenvolvida propositadamente
para este efeito.
Figura 3.6: Logo Tanagra.
15
16
Capítulo 4
Implementação
É importante compreender que este é um trabalho de investigação aplicada, que parte de uma
hipótese e que essencialmente visa averiguar a viabilidade dessa hipótese, o que por si só se
mostrou uma tarefa muito complexa. Mesmo a formulação dessa hipótese não foi um trabalho
trivial. Pelas informações facultadas pelos profissionais da saúde era de acreditar haver um
enorme potencial nos dados existentes nas unidades de saúde.
Infelizmente, e apesar de haver muitos dados, a grande maioria são inacessíveis. Existe uma
clara falta de abertura das entidades responsáveis pelos sistemas de informação instalados nas
unidades de saúde. Acresce a isto, as normais preocupações sobre a privacidade dos dados. Mas
talvez o pior seja mesmo o facto de não haver uma integração e total cobertura dos sistemas
de informação. Do que resulta um conjunto de bases de dados independentes, redundantes,
incoerentes e pouco úteis para efectivamente rastrear o percurso dos utentes em termos clínicos.
Para complicar, uma parte significativa dos procedimentos clínicos não estão suportados pelos
sistemas de informação (diagnóstico médico, confirmação dos efeitos dos tratamentos, etc).
Pelo que foi muito moroso conseguir elementos concretos sobre os dados existentes. Quando se
refere isto, não se está a falar de dados concretos e reais, mas apenas do tipo de dados existentes
e do seu significado e utilidade.
Só quando se teve acesso a esta informação, é que foi possível efectuar uma análise desses
dados (entenda-se tipo de dados), para perceber o que se poderia fazer, nomeadamente no âmbito das preocupações manifestadas pelos profissionais de saúde. Contudo, a hipótese formulada foi aquela que se entendeu ser viável e de maior interesse para o domínio do problema.
Mesmo sabendo de antemão que a obtenção de resultados concretos seria uma tarefa muito
complexa.
17
4.1
Descrição do Dataset
Na impossibilidade de se fazer uso de dados reais, criou-se um dataset que tem por base os campos existentes no laboratório de análises clínicas, mas com dados que apesar de representativos
dessa realidade são fictícios.
O dataset utilizado representa assim uma hipotética realidade dos registos existentes sobre
as análises clínicas realizadas numa unidade hospitalar. Tentou-se dentro dos possíveis utilizar
a mesma terminologia e os mesmos conceitos que são utilizados no mundo real. Cada registo do
dataset representa a realização de uma análise de imunidade de um microorganismo a um antibiótico. Análise essa, que corresponde a uma de muitas que normalmente são solicitadas para
um utente num dado momento da sua vida. Cada lote de análises requisitadas está associado a
uma requisição. O microorganismo advém de uma amostra (sangue, urina, fezes, expectoração,
etc.) recolhida do utente.
Segunda a informação prestada, os dados existentes possuem os seguintes campos:
• NSF – é o código de identificação do utente, neste caso é um código fictício;
• Data_Nasc – representa a data de nascimento do utente;
• Data_Req – representa a data solicitada da análise;
• Proveniencia – identifica o local de onde foi efectuado o pedido da análise;
• Tipo_Exame – identifica o tipo de exame solicitado;
• Microorganismos – identifica o microorganismo para qual se vai verificar a imunidade;
• Antibiotico – identifica o antibiótico utilizado na análise;
• Sensibilidade – é o resultado da análise de imunidade do microorganismo ao antibiótico.
O resultado poderá ser sensível, significa que o microorganismo é afectado pelo antibiótico,
isto é, este faz efeito. Pode ser resistente, significa que para o utente e microorganismo em
questão, o antibiótico já não faz efeito, isto é, na amostra em causa o microorganismo é imune
ao antibiótico. E pode ser é indeterminado, o que significa que funcionou parcialmente, isto é,
afectou parte da amostra mas não toda a amostra (sinal de que já há alguma imunidade por parte
do microorganismo).
Como era possível, o conceito de Data_Req foi substituído por um outro, o de Episodio,
também utilizado neste contexto, mas mais útil para os objectivos deste projecto. Enquanto
a data de requisição é uma representação de uma data, o conceito de episódio aqui utilizado
funciona como um identificador relativo ao utente que faculta uma sequência temporal dos
vários episódios de um utente. Normalmente, são solicitadas várias análises de cada vez, isto é,
se o utente for hospitalizado o médico pode solicitar a realização de um conjunto de análises.
18
Cada conjunto de análises tem um número de episódio, que é sequencial para cada utente. A
primeira vez que são solicitadas análises para um utente corresponde ao episódio um.
Há ainda um segundo campo introduzido que é o ID e que serve para atribuir uma chave
única a cada registo, mas que não tem qualquer significado especial para lá disto. Isto porque,
com os campos base não é possível formar uma chave, mesmo que composta, que garanta a
unicidade dos registos.
Figura 4.1: Imagem do dataset original montada numa BD.
19
4.2
Análise do problema
Com o modelo de dados disponibilizado, o passo seguinte foi perceber o que é que se poderia
fazer com ele. Segundo este modelo, há um registo do histórico de análises efectuadas por
cada paciente. Análises essas, que de alguma forma descrevem a sensibilidade do utente (mais
concretamente dos microorganismos do utente) aos antibióticos.
Sabe-se também que os resultados das análises são utilizados pelos médicos para decidirem
que antibiótico receitar ao utente. Não foi possível obter dados que permitissem confirmar
concretamente qual o antibiótico efectivamente receitado. Informação que teria certamente sido
uma enorme mais-valia para os objectivos deste projecto. Também não há qualquer controlo
directo sobre a eficácia da medicação receitada e muito menos registos informáticos.
Os dados das análises clínicas, podem dar alguma informação sobre a eficácia dos antibióticos, isto porque, se resultar, o utente não volta tão cedo à unidade de saúde. Mas se a medicação
falhar, o utente regressa e, o normal é, que sejam solicitadas novas análises. Assim, o facto de
essas análises existirem, pode ser significativo da ineficácia da medicação.
Partindo deste pressuposto e sabendo de antemão das potencialidades das tecnologias de
mineração de dados, tentou-se dar alguma utilidade prática a estes dados. A hipótese formulada foi de que o registo das análises dos utentes poderia ser útil para averiguar a eficácia dos
antibióticos. Se tal hipótese fosse verdade, a informação daí resultante seria certamente muito
valiosa na escolha dos antibióticos a receitar. A prova desta hipótese passou por tentar obter grupos de utentes com um histórico semelhante. Cada grupo seria representativo de uma parte da
realidade no que diz respeito à evolução de determinados microorganismos e da sua imunidade
aos antibióticos, considerando nesta equação elementos característicos dos próprios utentes (por
exemplo: idade e sexo).
Rapidamente se percebeu que a solução a utilizar para fazer prova da hipótese formulada,
passava por utilizar soluções de clustering/segmentação, o que permitiria criar os tais grupos de
utentes.
20
4.3
Formulação do processo de mineração
Para representar o historial de análises clínicas de cada utente, havia que sintetizar toda a informação do utente num único registo. Esse registo deveria conter informação da fisionomia
do utente e do dito histórico de análises, reflectindo o número, sequência e tipo das análises
realizadas, bem como os respectivos resultados.
Ou seja, cada registo para além da dita informação fisionómica do utente deve conter a descrição dos vários episódios, em que para cada episódio se identificam as várias triplas formadas
por microorganismo versus antibiótico versus resultado (sensibilidade).
A ideia de vectorizar vem na utilização da abordagem clustering em que se pretende criar
grupos. Para criar esses grupos é preciso ter o historial completo do utente num único registo. Assim o algoritmo (de clustering) vai comparar os campos das combinações possíveis
e comparar resultados. Aqueles que tenham resultados semelhantes da combinação episódio,
microorganismo e antibiótico, irão para o mesmo cluster.
A figura 4.2 mostra um exemplo do dataset construído para o modelo de mineração. Para
além do número de identificação do utente (NSF), se existisse no dataset original 2 episódios,
2 microorganismos e 3 antibióicos, neste novo dataset haveria 12 combinações possíveis entre
episódio, microorganismo e antibiótico.
Figura 4.2: Exemplo do dataset a criar para o modelo de mineração.
21
4.3.1
Problemas resultantes do modelo de mineração
Para ter a tabela 4.2 como na figura é preciso reduzir bastante os dados de maneira a que no fim
a BD tenha a combinação episódio, microorganismo e antibiótico que resulte em poucas colunas. Segundo apurado, haveria utentes com 33 episódios (número que poderia naturalmente
aumentar, o número de microorganismos era de 116 e o número de antibióticos de 87, logo, o
resultado das combinações possíveis destes números é 307824 (este seria o número de colunas
de um novo dataset). Como se pode verificar o número é demasiado elevado, o que levaria
muito tempo de processamento e memória para gerar uma tabela deste tipo, para mais tarde
aplicar o algoritmo de MD, para posteriormente verificar os resultados obtidos. Convém acrescentar que a grande maioria das BD existentes no mercado dificilmente comporta mais do que
alguns poucos milhares de campo (<4000). Foi assim imprescindível tentar reduzir o numero
de combinações, tarefa que se mostrou muito complexa e que requereu uma análise bem mais
detalhada dos dados e muito bom senso.
Foi também logisticamente complexo, pois requereu solicitar a execução de muitas queries
sobre a BD original (uma vez que não se tinha acesso directo aos dados).
4.3.2
Decisões para a resolução dos problemas
Antes de começar a redução de antibióticos, episódios ou microorganismos deve-se simplificar o
mais possível a BD. O campo NSF e data de nascimento pertencem sempre a um mesmo utente,
como tal, esses dois campos passaram para uma outra tabela e na tabela original retirou-se a
Data de Nascimento mantendo o campo NSF como chave estrangeira ligada à nova tabela onde
NSF é a chave primária. O mesmo, também deve ser aplicado para os campos Microorganismo
e Antibiotico, para facilitar a criação de resultados e obter uma melhor eficiência. Criou-se um
ID (identificador) para cada microorganismo e para cada antibiótico, e na tabela principal em
vez do nome passou a ter o número do seu ID (de Microorganismo e Antibiótico) como chave
estrangeira das tabelas antibiotico e microorganismo onde contêm o ID e o respectivo Nome.
Ao ter feito esta uniformização permitiu que, mais tarde, a aplicação dos algoritmos de
MD seja mais rápida e eficiente, porque um computador consegue processar mais facilmente
números do que strings (identificadores iniciais dos microorganismos e antibióticos). Caso seja
necessário verificar o nome do antibiótico ou microorganismo que o número representa, basta
fazer um inner join entre a tabela principal e a tabela microorganismo ou antibiotico. Assim
sendo, obtém-se a tabela final com o aspecto da figura 4.4, ficando assim, concluído o processo
que contém apenas os dados necessários.
A partir deste momento, começa a redução de dados desnecessários ou menos relevantes
para a construção de um novo dataset para aplicar um dos algoritmos de segmentação.
Com a seguinte query:
select t0.cnt, COUNT(*) from
22
Figura 4.3: Ligações da tabela da BD.
Figura 4.4: Resultado da simplificação da tabela principal.
(select NSF, MAX(EPISODIO) as cnt from dbo.analisesKF2 group by nsf) as t0
group by t0.cnt
order by t0.cnt
como se pode verificar a partir do episódio 9 existem poucos resultados, isto porque, existe na
BD poucos utentes com os números de episódios superior a esse número.
Tendo em conta esta informação, analisou-se o que aconteceria caso se desprezassem os
utentes com mais do que 9 episódios. Ao passar de um máximo de 33 episódios para 9, permitiu reduzir significativamente o número de combinações entre episódios, microorganismos e
antibióticos.
Uma vez que interessavam apenas as situações em que efectivamente havia um historial,
entendeu-se também desprezar todos os utentes com 2 ou menos episódios. Isto não permite
reduzir directamente o número de combinações, dado que quem tem mais do que 2 episódios
também tem que ter no seu registo, informação respeitante aos dois primeiros episódios. Mas
permitiu reduzir efectivamente, eliminando microorganismos e antibióticos que apenas ocorriam em utentes com um ou dois episódios.
23
Com estas simplificações, conseguiu-se reduzir o número de episódios para 9, o número de
microorganismos para 85 e o número de antibiótico para 75. Do que resultam 57375 combinações, em oposição às mais de 300 mil iniciais.
Após algum tempo a verificar a BD, foi possível perceber que havia registos com outros
valores possíveis para a sensibilidade para lá dos inicialmente previstos. Ao fazer
select distinct(Sensibilidade) from analises
apresenta os resultados, como está presente na figura 4.5, ‘S’, ‘R’, ‘I’, ‘N’, ‘P’, ‘ ‘ e segundo
informações obtidas por parte de entidades ligadas a este ramo os resultados que interessam são
os ‘S’, ‘R’ e ‘I’. Pelo que se descartam os outros resultados de modo a que a BD fique mais
leve.
Figura 4.5: Resultados do valor da Sensibilidade.
Ao apagar os resultados da Sensibilidade verificou-se que diminuiu o número de microorganismos e o número de antibióticos descendo estes para 57 e 68 unidades, respectivamente.
Assim sendo neste momento o número de campos possíveis é de 34884.
O próximo passo foi apagar combinações de microorganismos/antibióticos e vice-versa, que
sejam muito pouco representativos com objectivo de reduzir ainda mais o número de microorganismos e antibióticos, de modo a que, também se possa reduzir o número de campos do novo
dataset. Para tal usou-se as queries que estão abaixo da figura 4.6, e verificou-se possíveis
combinações a apagar a fim de reduzir o número de antibióticos e de microorganismos.
SELECT COD_ANTIBIO , t1.COD_MICRO , count( * ) , t1.tm
FROM dbo.analisesKF3 AS t2
INNER JOIN (
SELECT COD_MICRO , count( COD_MICRO ) AS tm
FROM dbo.analisesKF3
GROUP BY COD_MICRO
) AS t1
ON t1.COD_MICRO = t2.COD_MICRO
GROUP BY COD_ANTIBIO , t1.COD_MICRO , t1.tm
order by t1.tm,t1.COD_MICRO
24
Figura 4.6: Resultado da combinação antibiótico/microorganismo e vice-versa.
SELECT COD_MICRO , t1.COD_ANTIBIO , count( * ) , t1.ta
FROM dbo.analisesKF3 AS t2
INNER JOIN (
SELECT COD_ANTIBIO , count( COD_ANTIBIO) AS ta
FROM dbo.analisesKF3
GROUP BY COD_ANTIBIO
) AS t1
ON t1.COD_ANTIBIO = t2.COD_ANTIBIO
GROUP BY COD_MICRO , t1.COD_ANTIBIO , t1.ta
order by t1.ta, t1.COD_ANTIBIO
Então relativamente à figura 4.6 está ordenada pelo ‘tm’, que significa total de microorganismos e pelo ‘COD_MICRO’ que é o código do microorganismo. Então o resultado desta
query significa que a combinação de um antibiótico para um dado microorganismo aparece o
número de vezes que está representado na terceira coluna. A última coluna representa o total de
microorganismos. Como a tarefa é eliminar o número máximo de microorganismos e antibióticos possível, o ideal é pegar nestas duas colunas e verificar se realmente se pode eliminar. Por
exemplo, relativamente à primeira linha podemos verificar que o resultado da query obteve-se o
antibiótico 139 combinado com o microorganismo 203, a combinação de ambos aparece na BD
apenas uma vez e o total de registos em que o microorganismo aparece é de 5, por isso, aqui
está um dos potenciais microorganismos que pode desaparecer.
Na mesma figura está presente o oposto, ou seja, em vez de ser a combinação antibiótico
/microorganismo é a combinação microorganismo/antibiótico, em que na primeira e segunda
colunas está representado o código do microorganismo e o código do antibiótico, respectiva25
mente. A 3a coluna é o número de vezes que a combinação aparece na BD e a última coluna
representa o número de vezes que o antibiótico aparece. Na primeira linha aparece um potencial
antibiótico a eliminar, visto que na BD inteira apenas é utilizado uma única vez.
Depois de definir um número mínimo de antibióticos e microorganismos (pelos menos 10)
optou-se por apagar todos aqueles inferiores a esse número. Com esta simplificação ficou-se
reduzido a 55 microorganismos, 60 Antibióticos e 9 episódios o que dá um total de 29700
campos.
Numa fase avançada deste processo de redução, e como mostra a figura 4.7 constatou-se que
para uma combinação utente, episódio, microorganismo e antibiótico poderia haver mais do que
um resultado. Isto significaria voltar a duplicar o número de combinações (considerando que
no máximo poderia haver dois resultados), pelo que se entendeu considerar o primeiro registo
e desprezar os restante. Opção esta também sustentada pelo facto de que quando havia mais do
que um resultado, o valor era na maioria das situações igual (segundo os entendidos, servia de
confirmação de resultados).
Figura 4.7: Resultado de combinações repetidas.
Detectou-se também combinações que não continham resultados. Pelo que ao subtrair estes
registos foi possível reduzir o número de combinações para um pouco mais de 6000.
Como mesmo assim, não era possível tratar estes resultados a partir de uma BD (limite
do MySQL é de pouco mais de 1000 colunas), optou-se por utilizar um formato textual para
representar os dados. Optou-se por gerar um ficheiro csv com os resultados da sensibilidade
vectorizados, no anexo A.2 está o código que gerou o ficheiro. Foi escolhido este formato por
ser o mais simples de construir, pois o Weka é capaz de converter um ficheiro csv para um
ficheiro com a extensão que o programa normalmente usa (arff ).
Finalmente o último passo é correr no Weka e verificar os resultados.
26
4.4
Aplicação do Algoritmo de Data Mining
O algoritmo k-means [6, 2, 16] usa um método de agrupamento não-supervisionado, consiste
num procedimento em que um dado número de clusters, previamente determinado, calcula os
pontos que representam os centros destes clusters sendo espalhados no conjunto de respostas
e movidos até alcançar um equilíbrio estático. Em seguida, procede a uma divisão de todos os
casos obtidos pelos ‘k’ grupos estabelecidos previamente e a melhor partição de ‘n’ casos será
aquela que optimize o critério escolhido. Este procedimento inicia-se ao usar os valores dos
primeiros ‘k’ casos como estimativas. Os casos iniciais são formados através da designação de
cada caso ao cluster mais próximo. Sempre que se incluir um ou mais casos é preciso recalcular
as médias e alterar as posições do cluster até que não haja mais alterações nos cálculos das
médias.
Figura 4.8: Representação do algoritmo k-means.
Este é um dos algoritmos mais simples para o método de clustering, um dos mais avançados foi feito com base no k-means que é o EM (Expected Maximization). Pontos fracos deste
algoritmo:
• Quando o número de dados é pequeno, o grupo inicial determina o cluster;
• O número de clusters tem que ser previamente definido;
• Sensível aos dados iniciais, mesmo se trocar a ordem dos atributos poderá definir um
cluster diferente.
[10]
27
4.5
Como gerar resultados através do Weka
Ao ter o dataset carregado no Weka pode-se escolher tratar os dados ou usar uma das abordagens. Como os dados já estão tratados, escolhe-se o separador cluster e de imediato escolhe-se
o algoritmo que se pretende usar (através do botão choose, como mostra a figura 4.9).
Figura 4.9: Escolha do método clustering e do algoritmo.
O algoritmo escolhido foi o k-means, como tal é preciso clicar nesse algoritmo para ficar
seleccionado.
Para aceder às opções deste algoritmo, é necessário clicar na caixa de texto onde tem o seu
nome, aparecendo assim, um menu com opções, nas quais é possível escolher quantos clusters
se pretendem criar, o número de seeds, entre outros (tal como mostra a figura 4.10).
Figura 4.10: Escolha dos parâmetros do algoritmo k-means.
Escolhido o número de clusters é necessário escolher o tipo de acção:
• treino;
• usar um ficheiro de treino sendo que os dados do dataset ficam a ser avaliados;
28
• divisão de uma percentagem do dataset para treino e para avaliação.
Para começar clica-se em Start (como é visível na figura 4.11) e na caixa de texto ao lado
aparecerão os resultados momentos depois.
Figura 4.11: Começar a gerar resultados
29
4.6
Síntese dos resultados
Exemplo 1 Na figura 4.12 estão representados 10 clusters (definido nos parâmetros) e a quantidade de utentes que foi atribuída a cada grupo, num universo de 269 utentes. No primeiro
cluster (cluster 0) apenas foi atribuído um utente o que corresponde a aproximadamente 0%,
o mesmo acontece com os clusters 4 e 6; quanto ao cluster 1 foram-lhe atribuídos 22 utentes
que em termos percentuais corresponde a 8%; em relação ao cluster 2 foram-lhe atribuídos 34
utentes o que corresponde a 13%; o cluster 3 apenas foi-lhe atribuído 4 utentes, o que equivale
a 1% ; o cluster 5 obteve 10 utentes que corresponde a 4%; já o cluster 7 obteve 183 utentes
que corresponde a 68%; por fim, os clusters 8 e 9 obtiveram 2 e 11 utentes o que corresponde a
1% e 4%, respectivamente.
Figura 4.12: Resultados Exemplo 1.
Exemplo 2 Este exemplo foi elaborado de uma maneira diferente do exemplo anterior, desta
vez em vez de apenas treinar, também se atribuíu uma percentagem a casos “reais”, como
apresenta a figura 4.13. Portanto, 66% do dataset foi usado para treino e os restantes 34%
(91 utentes) foram usados para serem atribuídos a clusters. Em termos de resultados podemos
verificar quantos utentes foram atribuídas a cada um dos grupos (clusters). Aos clusters 0,
1, 3, 6 e 8 não foram atribuídos utentes. Para o cluster 2 foram atribuídos 14 utentes o que
corresponde a 15%; para o cluster 4 foram atribuídos 6 utentes que equivale a 7%; nos clusters
5 e 7 foram atribuídos 3 e 1 utentes o que corresponde a 3 e 1%, respectivamente; por fim, no
cluster 9 foram atribuídos 60 utentes, ou seja, 74%.
30
Figura 4.13: Resultados Exemplo 2.
Exemplo 3 Na figura 4.14 estão representados 20 clusters. Nos clusters 0, 4, 15 e 19 contém
apenas 1 utente o que corresponde a aproximadamente a 0%; no cluster 1 existem 16 utentes que
em termos percentuais corresponde a 6%; no cluster 2, 31 utentes equivale a 12%; os clusters 3
e 9 contêm 9 utentes e que corresponde a 3%; o cluster 5 possui 25 utentes que equivale a 9%;
os clusters 6 e 17 contêm apenas 2 utentes que corresponde a 1%; ao cluster 7 foi atribuído 20
utentes que equivale a 7%; no cluster 8 existem 6 utentes que corresponde a 2%; os clusters 10
e 11 possuem 3 utentes que equivale a 3%; o cluster 12 é o que possui maior número de utentes
com 102 que corresponde a 38%; nos clusters 14 e 16 contêm 7 utentes que equivale a 3%;
finalmente, o cluster 18 com 4 utentes que corresponde a 1%.
31
Figura 4.14: Resultados Exemplo 3.
Exemplo 4 Tal como no Exemplo 3, a figura 4.15 contém 66% para treino e 34% para serem
atribuídos a clusters. Para o cluster 2 foram associados 15 utentes que corresponde a 16%; no
cluster 5 vieram 10 utentes que equivale a 11%; o cluster 9 obteve a maior atribuíção com 45
utentes que corresponde a 49%; para o cluster 10 apenas 1 utente que em termos percentuais
equivale a 1%; o cluster 12 apenas lhe foi atribuído 2 utentes, ou seja, 2%; os clusters 17 e 18,
obtiveram 7 e 12 utentes, que corresponde a 8% e 13%, respectivamente; por fim, os restantes
clusters não obtiveram nenhuma atribuíção.
Figura 4.15: Resultados Exemplo 4.
32
4.7
Análise crítica
Na análise dos resultados foi possível verificar que nos exemplos 1 e 3, houve alguns casos em
que num cluster ficava apenas um utente, isto possivelmente quer dizer que são casos especiais,
ou seja, é preciso ter um cuidado especial com estes casos vistos serem casos raros (neste universo de 269 utentes) e analisá-los ao pormenor. Em relação aos outros casos dos outros clusters
pode-se concluir que são casos em que possivelmente, uma medicação semelhante poderá resolver o mesmo problema (para aqueles que pertencem ao mesmo clusters). Em comparação
com os dois exemplos, é que quanto maior for o número de clusters, mais distribuído será a
colocação dos utentes porque o grupo onde se posiciona contém um tratamento mais específico,
podendo ter melhor soluções de tratamento. Ao mesmo tempo também também pode significar
que o tratamento poderia não resultar porque com um menor número de clusters menos específico é o problema e mais geral é o tratamento.
Infelizmente, e dado ter sido despendido muito tempo nos testes de aprendizagem, nomeadamente antes da redução do dataset, não foi possível efectuar mais testes que permitissem validar
consistentemente a hipótese formulada.
33
34
Capítulo 5
Conclusões
5.1
Análise crítica
O processo de MD analisa grandes quantidades de dados à procura de padrões e relações escondidas que é (quase) impossível para um ser humano encontrar.
A parte de analisar dados, tem muito que se lhe diga, se o dataset for na ordem das centenas
de Megabytes (MB) ou mesmo Gigabytes (GB), quase que é preciso ter um supercomputador
para tratar os seus dados. Este projecto foi feito num computador com 2GB de RAM e muitas
vezes ao gerar o dataset, dava excepção com o erro de “out of memory” a solução foi reduzir
drasticamente o dataset que continha inicialmente mais de 300 mil registos e passou para pouco
mais de 20 mil, o que condicionou muito estes resultados. Com um dataset real (em termos de
resultados de um país), provavelmente só com um supercomputador é que se poderia chegar a
resultados. No caso do Weka, a preparar os clusters para 20 clusters ocupava a volta de 900MB
de memória o que é muito.
O objectivo proposto do projecto, que pretendia agrupar utentes mediante o seu historial
clinico foi cumprido, conseguiu-se agrupar 269 utentes e conhecer casos simples, em que o
tratamento deveria ser quase igual para todos, e casos que apenas um utente se inseria num
cluster, o que leva a crer que seja uma situação mais complicada e necessitava de cuidados
especiais por parte dos profissionais de saúde.
Por fim, o DM, é uma tecnologia que está cada vez a ganhar mais adeptos e são as empresas
que recorrem a esta solução a fim de perceber o que pode ser melhorado, aumentar os lucros,
aumentar produtividade, melhor gestão das despesas, entre outros. Contudo, posso concluir que
é uma área que se pode e se deve investir.
35
5.2
Trabalho Futuro
Um possível trabalho futuro era a criação de uma aplicação que comparasse resultados de um
sistema maior para um sistema único, ou seja, o sistema era treinado com o dataset, que ao
serem inseridos novos dados de um utente é verificado o clusters a que pertence. O sistema
produz uma resposta de qual o melhor tratamento, comparando com casos semelhantes, a fim
de tratar o problema do paciente.
Outra proposta possível, é a criação de um modelo que permita verificar surtos de microorganismos, para poder determinar a altura do ano que um microorganismo seja mais resistente e
verificar qual seria a solução em antibiótico mais eficaz para realizar os tratamentos. Este resultado era possível visto que, no dataset utilizado existe a informação do local onde foi efectuada
a análise, o resultado das análises, os microorganismos encontrados, os antibióticos usados para
combater os microorganismos e, também, a data do exame.
36
Bibliografia
[1] Satnam Alag. Collective Intelligence in Action. Data acesso: 16/06/2011.
[2] anpcont. http://www.anpcont.com.br/site/docs/congressoii/01/ccg223.pdf, Data acesso:
07/09/2011.
[3] databasesabout.
http://databases.about.com/od/datamining/g/classification.htm, Data
acesso: 05/09/2011.
[4] datawarehouse.inf. http://www.datawarehouse.inf.br/artigos/cervejaefraldas.pdf, Data
acesso: 16/06/2011.
[5] dreamspark. https://www.dreamspark.com/products/product.aspx?productid=37, Data
acesso: 22/06/2011.
[6] dtreg. http://www.dtreg.com/kmeans.htm, Data acesso: 07/09/2011.
[7] Ian Witten & Eibe Frank. Data Mining : practical machine learning tools and techniques.
Data acesso: 05/09/2011.
[8] Ian Witten & Eibe Frank. Data Mining : practical machine learning tools and techniques.
Data acesso: 05/09/2011.
[9] Ian Witten & Eibe Frank. Data Mining : practical machine learning tools and techniques.
Data acesso: 16/06/2011.
[10] gmu.edu.
http://cs.gmu.edu/cne/modules/dau/stat/clustgalgs/clust5_bdy.html,
acesso: 07/09/2011.
Data
[11] ieee. http://www.ieee.org.ar/downloads/2007-markel-ruz-datamining.pdf, Data acesso:
16/06/2011.
[12] Paulo Matos. Data-Mining. Data acesso: 05/09/2011.
[13] Paulo Matos. Data-Warehouses. Data acesso: 16/06/2011.
[14] msdn. http://msdn.microsoft.com/en-us/library/ms173767.aspx, Data acesso: 22/06/2011.
37
[15] Mark Hall Richard Kirkby Peter Reutemann Alex Seewald David Scuse Remco R. Bouckaert, Eibe Frank. Weka Manual 3-6-2. Data acesso: 20/06/2011.
[16] revoledu. http://people.revoledu.com/kardi/tutorial/kmean/, Data acesso: 07/09/2011.
[17] shvoong. http://pt.shvoong.com/books/1778553-t%c3%a9cnicas-data-mining-dataminigminera%c3%a7%c3%a3o/#ixzz1tjmuq82l, Data acesso: 05/09/2011.
[18] univ lyon2.
31/08/2011.
http://eric.univ-lyon2.fr/ ricco/tanagra/en/tanagra.html, Data acesso:
[19] w3schools.
04/09/2011.
http://www.w3schools.com/php/php_mysql_intro.asp,
Data acesso:
[20] wikipedia. http://en.wikipedia.org/wiki/mysql, Data acesso: 04/09/2011.
[21] wikipedia. http://pt.wikipedia.org/wiki/mysql, Data acesso: 04/09/2011.
[22] wikipedia.
05/09/2011.
http://en.wikipedia.org/wiki/association_rule_learning,
Data acesso:
[23] wikipedia. http://en.wikipedia.org/wiki/data_mining, Data acesso: 16/06/2011.
[24] wikipedia. http://pt.wikipedia.org/wiki/minera%c3%a7%c3%a3o_de_dados, Data acesso:
16/06/2011.
[25] wikipedia. http://pt.wikipedia.org/wiki/netbeans, Data acesso: 20/06/2011.
[26] wikipedia. http://pt.wikipedia.org/wiki/weka, Data acesso: 20/06/2011.
[27] wikipedia. http://pt.wikipedia.org/wiki/intelig%c3%aancia_empresarial, Data acesso:
22/06/2011.
[28] wikipedia. http://en.wikipedia.org/wiki/tanagra_(software), Data acesso: 31/08/2011.
38
Anexo A
Código
A.1
SQL
/*
select t3.nsf, t3.cod_episodio, t3.microorganismo, t3.antibiotico, t3.sensibilidade
from (
select distinct t2.NSF from (
select * from (
select NSF, cod_episodio, antibiotico, microorganismo, COUNT(sensibilidade) as cnt
from analises
group by NSF, cod_episodio, antibiotico, microorganismo) as t1
where t1.cnt>1) as t2) as t4
inner join chne as t3 on t4.NSF=t3.NSF
order by t3.nsf, t3.cod_episodio, t3.microorganismo, t3.antibiotico;
*/
--select count(*) from (select distinct(NSF), DATA_NASC from analises) as t1;-- 6944
--select count(*) from (select distinct NSF, DATA_NASC from analises) as t1;-- 6944
--delete from utentes;
--insert into utentes (NSF, DATA_NASC) (select NSF, min(DATA_NASC) as DN from chne
--group by NSF);
--insert into exames (exame) (select distinct exame from chne);
--delete analises;
/*
insert into analises (NSF,EPISODIO, DATA_REQ, COD_PROV, COD_EXAME, COD_ANTIBIO,
COD_MICRO, SENSIBILIDADE)
(select t0.NSF, t0.COD_EPISODIO, t0.DATA_REQ, t1.COD_PROV, t2.cod_exame,
39
t3.cod_antibio, t4.cod_micro, t0.sensibilidade from chne as t0
inner join proveniencias as t1 on t0.proveniencia = t1.proveniencia
inner join exames as t2 on t0.exame = t2.exame
inner join antibioticos as t3 on t0.antibiotico = t3.antibiotico
inner join microorganismos as t4 on t0.microorganismo = t4.microorganismo)
*/
--select count(*) from (select NSF, cod_episodio, antibiotico, microorganismo from
chne) as t0; --87193
--select count(*) from (select distinct NSF, cod_episodio, antibiotico, microorganismo
from chne) as t0; --79624
--select NSF, MAX(episodio) as cnt from analises group by nsf) as t0
--select * from analises where episodio=33;
--select COUNT(*) from microorganismos; --116
--select COUNT(*) from antibioticos; --87
--insert into analisesKF1 (nsf, episodio, data_req, cod_prov, cod_exame, cod_antibio,
cod_micro, sensibilidade) select * from analises order by NSF, episodio, cod_micro,
cod_antibio;
--select t0.ne, COUNT(T0.NE) from (select nsf, max(episodio) as ne from analisesKF1
group by nsf) as t0 GROUP BY t0.NE ORDER BY t0.NE;
--DELETE FROM UTENTESf1 WHERE NOT EXISTS(SELECT NSF FROM ANALISESkf1
WHERE UTENTESf1.NSF = ANALISESkf1.NSF);
--select * FROM UTENTESf1 WHERE NOT EXISTS(SELECT * FROM ANALISESkf1
WHERE UTENTESf1.NSF = ANALISESkf1.NSF);
--SELECT * FROM ANALISESKF1 WHERE NSF=’20822’
--delete microorganismosf1;
--insert into microorganismosf1 select distinct cod_micro from microorganismos;
--DELETE FROM microorganismosf1 WHERE NOT EXISTS(SELECT cod_micro FROM ANALISESkf1
WHERE microorganismosf1.cod_micro = ANALISESkf1.cod_micro);
--delete antibioticosf1 ;
--insert into antibioticosf1 select distinct cod_antibio from antibioticos;
--DELETE FROM antibioticosf1 WHERE NOT EXISTS(SELECT cod_antibio FROM ANALISESkf1
WHERE antibioticosf1.cod_antibio = ANALISESkf1.cod_antibio);
--insert into examesf1 select distinct cod_exame from exames;
40
--DELETE FROM examesf1 WHERE NOT EXISTS(SELECT cod_exame FROM ANALISESkf1
WHERE examesf1.cod_exame = ANALISESkf1.cod_exame);
--insert into provenienciasf1 select distinct cod_prov from proveniencias;
--DELETE FROM provenienciasf1 WHERE NOT EXISTS(SELECT cod_prov FROM ANALISESkf1
WHERE provenienciasf1.cod_prov = ANALISESkf1.cod_prov);
--select COUNT(*) from antibioticos f1; --75
--select COUNT(*) from microorganismosf1; --85
--select COUNT(*) from analisesk --87193
--select COUNT(*) from analiseskf1 --45271
--select COUNT(*) from Microorganismos; --116
--select COUNT(*) from Microorganismosf1; --85
--select COUNT(*) from Microorganismosf2; --62
--select COUNT(distinct(dbo.analisesKF3.COD_MICRO)) from analisesKF3 -- 57
--select COUNT(*) from antibioticos; --87
--select COUNT(*) from antibioticosf1; --75
--select COUNT(*) from antibioticosf2; --71
--select COUNT(distinct(dbo.analisesKF3.COD_ANTIBIO)) from analisesKF3 -- 68
/*
select t0.cnt, COUNT(*) from
(select NSF, MAX(EPISODIO) as cnt from dbo.analisesKF2 group by nsf) as t0
group by t0.cnt
order by t0.cnt
*/
/*insert into analiseskf2 (nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,
COD_MICRO,SENSIBILIDADE)
select nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,COD_MICRO,
SENSIBILIDADE from analisesK;
*/
--delete from analiseskf2 where exists(
--select * from (select NSF, MAX(EPISODIO) as cnt from analisesk group by nsf) as t0
where t0.cnt>9 and analiseskf2.nsf=t0.nsf)
41
--delete antibioticosf2;
--insert into antibioticosf2 select distinct cod_antibio from antibioticos;
--DELETE FROM antibioticosf2 WHERE NOT EXISTS(SELECT cod_antibio FROM ANALISESkf2
WHERE antibioticosf2.cod_antibio = ANALISESkf2.cod_antibio);
--delete microorganismosf2;
--insert into microorganismosf2 select distinct cod_micro from microorganismos;
--DELETE FROM microorganismosf2 WHERE NOT EXISTS(SELECT cod_micro FROM ANALISESkf2
WHERE microorganismosf2.cod_micro = ANALISESkf2.cod_micro);
/*
insert into dbo.analisesKF3(nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,
COD_MICRO,SENSIBILIDADE)
select nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,COD_MICRO,SENSIBILIDADE
from dbo.analisesKF2;
*/
-- _____________________________________________________________________________
/*
select t0.cnt, COUNT(*) from
(select NSF, MAX(EPISODIO) as cnt from dbo.analisesKF2 group by nsf) as t0
group by t0.cnt
order by t0.cnt
*/
--delete from analiseskf3 where exists(
--select * from (select NSF, MAX(EPISODIO) as cnt from analisesk group by nsf) as
t0 where t0.cnt>9 and analiseskf3.nsf=t0.nsf)
-- select COUNT(distinct(dbo.analisesKF2.COD_ANTIBIO)) from analisesKF2
--insert into dbo.analisesKF2(nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,
COD_MICRO,SENSIBILIDADE)
--select nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,COD_MICRO,SENSIBILIDADE
from dbo.analisesKF3;
/*
SELECT COD_ANTIBIO , t1.COD_MICRO , count( * ) , t1.tm
42
FROM dbo.analisesKF3 AS t2
INNER JOIN
(
SELECT COD_MICRO , count( COD_MICRO ) AS tm -- quantas vezs aparece os microorganismos
FROM dbo.analisesKF3
GROUP BY COD_MICRO
)
AS t1 ON t1.COD_MICRO = t2.COD_MICRO
GROUP BY COD_ANTIBIO , tm.COD_MICRO
*/
--delete
-- N
--
from dbo.analisesKF3 where SENSIBILIDADE = ’P’
--insert into dbo.antibioticosF4
--select distinct(dbo.analisesKF3.COD_ANTIBIO) from analisesKF3
--insert into dbo.MicroorganismosF4
--select distinct(dbo.analisesKF3.COD_MICRO) from analisesKF3
/*
SELECT COD_ANTIBIO , t1.COD_MICRO ,
FROM dbo.analisesKF3 AS t2
INNER JOIN
(
SELECT COD_MICRO , count( COD_MICRO
FROM dbo.analisesKF3
GROUP BY COD_MICRO
) AS t1
ON t1.COD_MICRO = t2.COD_MICRO
GROUP BY COD_ANTIBIO , t1.COD_MICRO
order by t1.tm,t1.COD_MICRO
*/
/*
SELECT COD_MICRO , t1.COD_ANTIBIO ,
FROM dbo.analisesKF3 AS t2
INNER JOIN
(
count( * ) , t1.tm
) AS tm
, t1.tm
count( * ) , t1.ta
43
SELECT COD_ANTIBIO , count( COD_ANTIBIO) AS ta -- quantas vezs aparece os microorganism
FROM dbo.analisesKF3
GROUP BY COD_ANTIBIO
) AS t1
ON t1.COD_ANTIBIO = t2.COD_ANTIBIO
GROUP BY COD_MICRO , t1.COD_ANTIBIO , t1.ta
order by t1.ta, t1.COD_ANTIBIO
*/
--insert into dbo.analisesKF4(nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,
COD_MICRO,SENSIBILIDADE)
--select nsf, EPISODIO,DATA_REQ,COD_PROV,COD_EXAME,COD_ANTIBIO,COD_MICRO,SENSIBILIDADE
from dbo.analisesKF3;
/*
delete from [AlertN].[dbo].[analisesKF4] where COD_MICRO=203 or COD_MICRO=228
delete
FROM [AlertN].[dbo].[analisesKF4] where COD_ANTIBIO=99 or COD_ANTIBIO=93 or
COD_ANTIBIO=127 or COD_ANTIBIO=166 or
COD_ANTIBIO=101 or COD_ANTIBIO=170 or COD_ANTIBIO=145 or COD_ANTIBIO=167
*/
/*
SELECT COD_ANTIBIO , t1.COD_MICRO , count( * ) , t1.tm
FROM [AlertN].[dbo].[analisesKF4] AS t2
INNER JOIN
(
SELECT COD_MICRO , count( COD_MICRO ) AS tm
FROM [AlertN].[dbo].[analisesKF4]
GROUP BY COD_MICRO
) AS t1
ON t1.COD_MICRO = t2.COD_MICRO
GROUP BY COD_ANTIBIO , t1.COD_MICRO , t1.tm
order by t1.tm,t1.COD_MICRO
SELECT COD_MICRO , t1.COD_ANTIBIO , count( * ) , t1.ta
FROM [AlertN].[dbo].[analisesKF4] AS t2
INNER JOIN
44
(
SELECT COD_ANTIBIO , count( COD_ANTIBIO) AS ta -- quantas vezs aparece os microorganism
FROM [AlertN].[dbo].[analisesKF4]
GROUP BY COD_ANTIBIO
) AS t1
ON t1.COD_ANTIBIO = t2.COD_ANTIBIO
GROUP BY COD_MICRO , t1.COD_ANTIBIO , t1.ta
order by t1.ta, t1.COD_ANTIBIO
*/
--select COUNT(distinct(AlertN.dbo.analisesKF4.COD_MICRO)) from AlertN.dbo.analisesKF4-
--select COUNT(distinct(AlertN.dbo.analisesKF4.COD_ANTIBIO)) from AlertN.dbo.analisesKF
A.2
using
using
using
using
using
using
Rotina para geração dos ficheiros CSV
System;
System.Collections.Generic;
System.Linq;
System.Text;
System.Data.SqlClient;
System.IO;
namespace test_projecto
{
class Program
{
static void Main(string[] args)
{
SqlConnection sql = new SqlConnection();
sql.ConnectionString = "Data Source=(local);Initial Catalog=AlertN;
Integrated Security=True; MultipleActiveResultSets=True";
string fich = @"c:\asd2.txt";
StreamWriter w = File.AppendText(fich);
try
{
sql.Open();
45
Console.WriteLine("Entrou");
using (SqlCommand com = new SqlCommand("select distinct(NSF) from
analisesKF4;", sql))
{
SqlDataReader dr = com.ExecuteReader();
while (dr.Read())
{
string nsf = dr[0].ToString();
using (SqlCommand com2 = new SqlCommand(
"SELECT distinct EPISODIO, COD_ANTIBIO, COD_MICRO FROM
[AlertN].[dbo].[analisesKF4] group by EPISODIO, COD_ANTIBIO,
COD_MICRO order by EPISODIO, COD_ANTIBIO, COD_MICRO "
, sql))
{
SqlDataReader dr2 = com2.ExecuteReader();
while (dr2.Read())
{
string epi = dr2[0].ToString();
string anti = dr2[1].ToString();
string micro = dr2[2].ToString();
using (SqlCommand com3 = new SqlCommand("select Sensibilidade from
analisesKF4 where NSF = " + nsf + " and EPISODIO = " + epi + " and
COD_ANTIBIO = " + anti + " and COD_MICRO=" + micro, sql))
{
SqlDataReader dr3= com3.ExecuteReader();
while (dr3.Read())
{
w.Write(dr3[0].ToString());
break;
}
com3.Dispose();
dr3.Dispose();
dr3.Close();
}
w.Write(",");
}
com2.Dispose();
dr2.Dispose();
46
dr2.Close();
}
w.WriteLine("");
}
com.Dispose();
dr.Dispose();
dr.Close();
}
w.Close();
openfile string fich2 = @"c:\dsa.txt";
StreamWriter wr = File.AppendText(fich2);
wr.Write("NSF,");
using (SqlCommand comf = new SqlCommand(
"SELECT distinct EPISODIO, COD_ANTIBIO, COD_MICRO FROM
[AlertN].[dbo].[analisesKF4] group by EPISODIO, COD_ANTIBIO,
COD_MICRO order by EPISODIO, COD_ANTIBIO, COD_MICRO "
,sql))
{
SqlDataReader drf = comf.ExecuteReader();
while (drf.Read())
{
wr.Write(drf[0].ToString() + "_" + drf[1].ToString() + "_"
+ drf[2].ToString() + ",");
}
comf.Dispose();
drf.Dispose();
drf.Close();
}
Console.WriteLine("Feito!");
wr.Close();
sql.Close();
}
catch
{
Console.WriteLine("falhou !");
}
}
}
}
47