Identificação de Anomalias Contextuais

Identificação de Anomalias Contextuais Por Daniela Oliveira Baía Soares Vasco Tese de Mestrado – Modelação, Análise de Dados e Sistemas de Apoio à Decisão Orientada por Prof. João Manuel Portela Gama, FEP Prof. Pedro Pereira Rodrigues, FMUP 2013 ii BIOGRAFIA Daniela Oliveira Baía Soares Vasco licenciou-se em Matemática Aplicada e Computação, pelo Instituto Superior Técnico da Universidade Técnica de Lisboa. Estagiou na Divisão de Informação Geográfica da Câmara Municipal da Amadora, desenvolvendo alguns estudos estatísticos, além da integração e limpeza dos dados, de forma a melhor servir os interesses do serviço e da comunidade. Trabalhou nos Censos 2011, como subcoordenadora da Freguesia da Venteira, Amadora, tendo como principal função a supervisão do trabalho efetuado por um grupo de 10 recenseadores. Também estagiou no Departamento de Tecnologias de Informação da empresa de Retalho, Parfois, onde esteve a trabalhar na área de Reporting Services. Na área académica tem duas publicações: Limpeza Contextual de Dados, JOCLAD 2013, e Contextual Cleaning of Medical Data, CBMS 2013. iii AGRADECIMENTOS Em primeiro lugar, e acima de tudo, agradeço a Deus, que é o meu “refúgio e fortaleza, socorro bem presente na angústia” (Salmos 46:1), por me ter abençoado e acompanhado durante toda a minha vida, dando-me capacidades e colocando pessoas maravilhosas no meu caminho. Como aprendeu Christopher McCandless: “A felicidade só é verdadeira se for partilhada”, por isso tenho muito a quem agradecer. Agradeço à minha família que sempre me apoiou nos momentos de alegria e de tristeza; rimos e chorámos muitas vezes juntos. Em especial, agradeço à minha mãe, que é a mulher que eu mais admiro, meu exemplo de vida e persistência. Ao meu marido, agradeço o amor e a paciência demonstrada a cada dia, pelo seu companheirismo e apoio, os quais espero continuar a desfrutar e a partilhar durante toda a vida. À minha família do Porto, em especial sogros e cunhados, que me receberam muito bem e que sempre fizeram tudo para que eu me sentisse “em casa”. Aos amigos de toda a vida, pessoas que me ajudaram a crescer não apenas como pessoa, mas também como estudante e profissional. Também devo um agradecimento muito especial ao Professor João Gama, que sempre me apoiou e desafiou a ir além do que eu pensava ser possível. Possibilitou-me duas publicações, sendo uma internacional, e muito boas experiências no meio académico. Agradeço também ao Professor Pedro Pereira Rodrigues pelo apoio neste trabalho, nomeadamente na seleção e interpretação dos resultados, e ao Professor Alberto Freitas pela disponibilização dos dados. Por fim, agradeço às instituições que ajudaram na minha formação, IST e FEP, e ao LIAAD-INESC TEC pelo apoio financeiro para as publicações. iv RESUMO A tarefa de limpeza de dados tem como objetivo detetar e corrigir erros e inconsistências nos dados, de forma a melhorar a qualidade da informação disponível nos sistemas de informação. Atualmente, devido ao grande volume de dados disponível e pelo facto de muitas vezes estes dados serem provenientes de diversas fontes, as técnicas de limpeza de dados têm-se tornado cada vez mais relevantes e importantes na garantia da qualidade da informação em soluções de suporte à decisão. No presente trabalho, inicialmente expõe-se os principais problemas, abordagens e métodos utilizados em limpeza de dados, definem-se os tipos de anomalias existentes nos dados, as técnicas utilizadas para o seu tratamento e um conjunto de ferramentas existentes para abordar este tipo de problema. Sendo o processo de limpeza de dados bastante exaustivo, a parte prática deste trabalho, foca-se apenas na auditoria dos dados, ou seja, no processo de identificação das anomalias. Para isto, utilizou-se o GritBot, uma ferramenta que permite identificar casos raros, ou possíveis anomalias, não apenas globais (em todo o conjunto de dados), como também locais (em subconjuntos do conjunto de dados original). Assim, esta ferramenta identifica o contexto onde determinado valor de uma variável é um caso raro ou anómalo. Nesta dissertação aplicamos o GritBot a um conjunto de dados médicos e analisamos as regras geradas. De seguida, usamos árvores de decisão de forma a tentar obter o mesmo tipo de regras geradas pelo GritBot, método em que se obteve bons resultados. PALAVRAS-CHAVE: Anomalias Contextuais, Limpeza dos Dados, Qualidade dos Dados, Regras, GritBot, Árvores de Decisão. v ABSTRACT The task of data cleaning is to detect and correct errors and inconsistencies in the data in order to improve the quality of information available in information systems. Nowadays, due to the large volume of data available and the fact that often these data come from different sources, data cleaning techniques have become increasingly relevant and important in ensuring the quality of information in decision support solutions. In this work, initially it’s exposed the major problems, approaches and methods used in data cleaning, it’s defined the types of anomalies in data, the techniques used for their treatment and a set of existing tools to address such problem. As the data cleaning process is fairly exhaustive, the practical part of this work focuses only on the audit data, in other words, the process of identifying anomalies. In this matter it was used the GritBot, a tool to identify rare cases or possible anomalies, not only global (whole dataset), but also local (in subsets of the original dataset). Thus, this tool identifies the context in which a particular value of a variable is rare or unusual. In this thesis it was applied the GritBot in a set of medical data and we analyzed the generated rules. Then, we used decision trees in order to try to achieve the same kind of rules generated by GritBot, a method that has achieved good results. KEYWORDS: Contextual Anomalies, Data Cleaning, Data Quality, Rules, GritBot, Decision Trees. vi ÍNDICE BIOGRAFIA ............................................................................................................................................................... ii AGRADECIMENTOS ............................................................................................................................................ iii RESUMO ....................................................................................................................................................................iv ABSTRACT ................................................................................................................................................................ v ÍNDICE DE FIGURAS ......................................................................................................................................... viii ÍNDICE DE TABELAS ........................................................................................................................................ viii 1. MOTIVAÇÃO ........................................................................................................................................................ 9 2. DEFINIÇÃO DO PROBLEMA E TRABALHOS RELACIONADOS ..................................................... 12 2.1. Representação dos Dados .................................................................................................................. 12 2.2. Classificação das Anomalias existentes nos Dados ................................................................. 12 2.2.1. Anomalias de Sintaxe .................................................................................................................. 13 2.2.2. Anomalias de Semântica ............................................................................................................ 14 2.2.3. Anomalias de Cobertura ............................................................................................................. 16 2.3 Qualidade dos Dados ............................................................................................................................. 16 2.4 O Processo de Limpeza de Dados .................................................................................................... 21 2.4.1. Auditoria da Qualidade dos Dados ........................................................................................ 22 2.4.2. Identificação dos métodos a serem utilizados .................................................................. 23 2.4.3. Aplicação dos métodos ao conjunto de dados .................................................................. 24 2.4.4. Pós-processamento e Controlo ............................................................................................... 24 2.5 Métodos usados no Processo de Limpeza de Dados ................................................................ 25 2.5.1. Análise Sintática (Parsing) ........................................................................................................ 25 2.5.2. Transformação dos Dados ......................................................................................................... 25 2.5.3. Aplicação de Restrições de Integridade ............................................................................... 26 2.5.4. Eliminação de Duplicados ......................................................................................................... 26 2.5.5. Métodos Estatísticos .................................................................................................................... 27 2.6 Abordagens e Ferramentas usadas em Limpeza de Dados ................................................... 28 2.6.1. AJAX .................................................................................................................................................... 28 2.6.3. Potter’s Wheel ................................................................................................................................ 30 2.6.4. ARKTOS ............................................................................................................................................. 31 2.6.5. IntelliClean ....................................................................................................................................... 32 vii 2.6.6. Trillium ............................................................................................................................................. 33 2.6.7. Google Refine .................................................................................................................................. 34 2.6.8. GritBot ............................................................................................................................................... 34 3. Um Caso de Estudo ........................................................................................................................................ 36 3.1 Descrição do Conjunto de Dados ..................................................................................................... 36 3.2 Usando o GritBot para gerar Regras ............................................................................................... 38 3.2.1. Descrição das Regras Geradas pelo GritBot ....................................................................... 39 3.2.2.Resultados ......................................................................................................................................... 41 3.3 Usando Árvores de Decisão para gerar Regras .......................................................................... 48 3.3.1. Descrição do Método ................................................................................................................... 48 3.3.2.Resultados ......................................................................................................................................... 52 4. Conclusão .......................................................................................................................................................... 63 5. Referências Bibliográficas .......................................................................................................................... 65 ANEXOS ................................................................................................................................................................... 69 viii ÍNDICE DE FIGURAS Figura 1: Classificação dos Problemas de Qualidade dos Dados ..................................................... 13 Figura 2: Hierarquia dos critérios de qualidade .................................................................................... 17 Figura 3: O Processo de Limpeza de Dados ............................................................................................. 22 Figura 4: Estrutura das regras geradas pelo GritBot. Adaptado: Quinlan, 2007. ..................... 39 Figura 5: Boxplot CL_IDADAN. ...................................................................................................................... 37 Figura 6: Boxplot CL_TOTDIAS. .................................................................................................................... 37 Figura 7: Estrutura da Árvore de Decisão gerada. ................................................................................ 49 Figura 8: Workflow KNIME. ............................................................................................................................ 49 Figura 9: Configurações para criar a Árvore de Decisão. ................................................................... 50 Figura 10: Configurações para selecionar um nó da Árvore de Decisão. .................................... 51 Figura 11: Output do comando Statistics. ................................................................................................. 51 Figura 12: Subconjunto 1. ............................................................................................................................... 52 Figura 13: Subconjunto 2. ............................................................................................................................... 54 Figura 14: Subconjunto 3. ............................................................................................................................... 56 Figura 15: Subconjunto 4. ............................................................................................................................... 57 Figura 16: Subconjunto 5. ............................................................................................................................... 59 Figura 17: Subconjunto 6. ............................................................................................................................... 60 Figura 18: Subconjunto 7. ............................................................................................................................... 61 ÍNDICE DE TABELAS Tabela 1: Dados com erros lexicais ............................................................................................................. 14 Tabela 2: Anomalias que afetam os critérios de qualidade dos dados ......................................... 20 Tabela 3: Caracterização das Variáveis ..................................................................................................... 36 Tabela 4: Frequências das Variáveis DSP e ADM_TIP.......................................................................... 38 Tabela 5: Descrição das Variáveis do Conjunto de Dados ................................................................. 69 9 1. MOTIVAÇÃO A Extração de Conhecimento de Dados (Lorena, Faceli, Oliveira, Carvalho, Leon e Gama, 2012) tem tido um papel cada vez mais importante na economia moderna, governos e trabalhos de investigação (Müller e Freytag, 2003). Com o avanço das tecnologias de processamento de informação, cada vez mais empresas, instituições, indústrias, etc., têm investido nos seus próprios sistemas de gestão e armazenamento de dados (Hao e Xing-chun, 2008). Apesar da qualidade dos dados se ter tornado tema de pesquisas académicas no início dos anos 90, nas empresas a consciência da sua importância é muito mais recente (Goasdoué, Nugier, Duquennoy e Laboisse, 2007). Muitos gestores não têm conhecimento sobre a qualidade dos dados que usam, e talvez assumam que as tecnologias de informação garantem dados perfeitos e informação pronta a ser analisada. No entanto, uma vez que a informação a ser analisada, geralmente é proveniente de diversas fontes (Cortes, 2005), as inconsistências, casos omissos, duplicações, valores extremos e outras anomalias a serem corrigidas ou eliminadas correspondem, em média, a 5% dos dados armazenados nos sistemas de gestão de bases de dados (Müller e Freytag, 2003). Muitas vezes, quando os gestores se apercebem que estes sistemas são falíveis quanto à garantia e manutenção da qualidade dos dados, já pode ser tarde para remediar os danos causados. As anomalias e impurezas existentes nos dados podem causar grandes problemas, não apenas no desempenho do processamento e confirmação dos resultados, como nas conclusões obtidas pela interpretação e análise dos dados (Müller e Freytag, 2003). Estes problemas podem levar a estratégias ou decisões incorretas que, muitas vezes, podem causar prejuízo económico imediato (Ciszak, 2008) e ter efeitos indiretos mais subtis. Assim, a qualidade dos dados pode afetar a satisfação, confiança e até mesmo causar a perda de clientes, pode afetar a capacidade de tomar decisões estratégicas (fraca qualidade dos dados de um sistema de gestão significa que os gestores não podem efetivamente implementar estratégias), causar perda de oportunidades de negócio ou decisões incorretas (Lindström, Gustafsson, Jägerlind e 16 2.2.3. ANOMALIAS DE COBERTURA As anomalias de cobertura diminuem a quantidade de entidades representadas e de propriedades destas mesmas entidades no conjunto de dados. Valores Omissos: resultam da ausência de informação sobre uma determinada entidade ou acontecimento, no conjunto de dados. Caso os atributos contenham o valor NULL, esta anomalia pode ser considerada uma violação de restrições caso para este atributo exista a restrição NOT NULL. Em outros casos podemos não ter uma condição que permita valores nulos para um atributo. Nestes casos deve-se decidir qual o valor existente que deve ser deduzido aqui ou não. Apenas são considerados valores omissos os casos em que a entidade deveria ter valores mensuráveis. Registos Omissos: resultam da falta de entidades completas, que não estão representadas por um registo no conjunto de dados. O desenvolvimento e aplicação de métodos de limpeza de dados têm sido, em grande parte, motivados pela existência de anomalias nos dados no mundo-real. Com as definições feitas acima, pode-se agora definir o Processo de Limpeza de Dados e especificar como medir o sucesso da limpeza dos dados errados. 2.3 QUALIDADE DOS DADOS A qualidade dos dados determina a precisão das análises efetuadas sobre estes mesmos dados, que por sua vez servem de apoio das tomadas de decisões em diversos meios. 17 A qualidade dos dados não é facilmente quantificável, a sua definição pode variar de acordo com a aplicação e possui componentes subjetivas (Delmater e Hancock, 2000). Os dados têm que satisfazer um certo conjunto de critérios para que o seu processamento e interpretação sejam considerados efetivos e eficientes, e serem então considerados de alta qualidade (Delmater e Hancock, 2000; Müller e Freytag, 2003; Ahmed e Aziz, 2010). A qualidade dos dados é definida como um valor agregado sobre um conjunto de critérios de qualidade (Ahmed e Aziz, 2010). Para medir a qualidade dum certo conjunto de dados, deve-se considerar as pontuações obtidas para cada critério de qualidade (Müller e Freytag, 2003; Ahmed e Aziz, 2010). O conhecimento destas pontuações torna possível saber se será necessário a aplicação do processo de limpeza de dados e se este processo será bem-sucedido (Müller e Freytag, 2003). Os critérios de qualidade também podem ser usados para otimizar este processo, uma vez que permite determinar quais os critérios prioritários para a limpeza dos dados, afetando, assim, os métodos utilizados. Os critérios definidos para uma limpeza de dados possuem uma hierarquia, que resulta da divisão dos critérios de qualidade em critérios mais finos, como mostra a Figura 2 (Müller e Freytag, 2003; Ahmed e Aziz, 2010). Delmater e Hancock (2000) não consideram a existência de uma hierarquia, sendo os critérios adotados para avaliar a qualidade dos dados os seguintes: Precisão, Consistência, Completude, Relevância e Independência. Figura 2: Hierarquia dos critérios de qualidade. Fonte: Ahmed e Aziz, 2010 18 Para cada critério definimos critérios para a avaliação da pontuação de qualidade para um dado conjunto de dados. A pontuação de cada critério de qualidade é influenciada por uma ou mais anomalias definidas no capítulo anterior. Precisão: pode ser definida como o quociente entre número de valores corretos e o número total de valores existentes no conjunto de dados (Naumann, 2002; Ahmed e Aziz, 2010). No entanto, assim como Müller e Freytag (2003), definir-se-á previsão como um agregado de valores sobre os critérios de qualidade de Integridade, Consistência e Densidade. Sendo assim, o único tipo de anomalia existente nos dados são os duplicados. De seguida serão definidos os critérios de Integridade, Consistência e Densidade. Integridade: Este critério também resulta da agregação dos critérios de Completude e Validade (Motro, 1989). Quando este critério é satisfeito não existem registos inválidos, nem violações das restrições de integridade ou registos omissos, pois estão representadas todas as entidades válidas, e nada além disso. Completude: é definido como o quociente entre as entidades em M, representadas por um registo e o número total de entidades em M. O processo de limpeza de dados contribui para a completude de um conjunto de dados uma vez que, caso o registo pertença às entidades de M, é feita a correção e não a eliminação deste registo, caso tenha alguma anomalia. Este critério garante que todos a informação válida é incluída no conjunto de dados (Motro, 1989). Validade: corresponde ao quociente das entidades de M, representadas por registos, e o número total de registos, isto é, a percentagem de registos que são entidades (válidas) representadas em M. A validade pode ser aproximada pelas condições de integridade especificadas, pois estas representam o entendimento das regras existentes. Portanto, registos que violem as condições de integridade são considerados inválidos. Assim sendo, aproxima-se a validade pelo quociente dos registos que satisfazem todas as 19 condições de integridade e o número total de registos. Este critério garante que toda a informação inválida é excluída do conjunto de dados (Motro, 1989). Consistência: tem a ver com as anomalias de sintaxe e com contradições. É também a agregação dos critérios de qualidade de Conformidade de Esquema e Uniformidade. Intuitivamente, um conjunto de dados consistente é sintaticamente uniforme e livre de contradições. Conformidade de Esquema: é o quociente dos registos que estão conforme a estrutura sintática definida pelo esquema relacional. Uniformidade: é o quociente dos atributos que não contêm irregularidades nos seus valores e o número total de atributos. Densidade: é o quociente dos valores omissos nos registos e o número total de valores que devem ser conhecidos porque existem para uma entidade representada. Podem ainda ser valores ou propriedades não existentes que têm que ser representadas pelo valor NULL, significando exatamente que o valor não é conhecido. Este último caso só será considerado no processo de limpeza de dados caso se pretenda estimar o seu valor. Unicidade: corresponde ao quociente de registos que representam a mesma entidade e o número total de registos. Um conjunto de dados que é único não contém duplicados. Pela definição de precisão referida anteriormente, um conjunto de dados é preciso se não contém nenhuma anomalia além de duplicados e pela definição de unicidade, que é: um conjunto de dados único não contém duplicados. Portanto, um conjunto de dados preciso e único não possui nenhuma anomalia referida anteriormente, logo não necessita de limpeza de dados. 20 Müller e Freytag (2003) apresentam uma tabela que lista os critérios de qualidade, que não são subdivididos, e as anomalias que os afetam. Far-se-á uma representação desta tabela, Tabela 2, em que cada ● indica que a ocorrência desta anomalia afeta diretamente o critério de qualidade, enquanto cada ─ indica que a ocorrência desta anomalia afeta indiretamente o critério de qualidade em questão. Tabela 2: Anomalias que afetam os critérios de qualidade dos dados De forma a haver um controlo da qualidade dos dados, Grimmer e Hinrichs (2001) propuseram um sistema de gestão da qualidade dos dados genérico, que segue o requerimento do ISO 9001 standard, apresentando um caso de estudo onde um subconjunto dos conceitos apresentados foi aplicado a base de dados QUIS (QUality Information System) do Global Services and Parts division of the Group, usando técnicas de limpeza de dados. Com a definição dos critérios que avaliam a qualidade dos dados e sabendo as anomalias que os afetam, pode-se estudar, de forma mais detalhada, o processo de limpeza de dados. Completude Validade Conformidade do Esquema Uniformidade Densidade Unicidade Erro Lexical − ● − − − Erro no formato do domínio − ● − − Irregularidades − ● − Violação das Restrições ● Valores Omissos ● − Tuplos Omissos ● Duplicados ● Tuplos Inválidos ● 21 2.4 O PROCESSO DE LIMPEZA DE DADOS Pode definir-se o processo de Limpeza de Dados como a aplicação de um conjunto de operações realizadas sobre os dados, com o objetivo de remover as anomalias existentes e transformá-los numa representação precisa e única do cenário real (Müller e Freytag, 2003). Considera-se a aplicação (semi-)automática das operações na seguinte ordem (Müller e Freytag, 2003; Ahmed e Aziz, 2010): i. Adaptação do formato dos registos e valores; ii. Aplicação das restrições de integridade; iii. Derivação dos valores omissos através dos valores existentes; iv. Remoção de contradições nos registos e entre registos; v. Junção ou eliminação de duplicados; vi. Deteção dos valores extremos, isto é, registos e valores que têm uma probabilidade elevada de ser inválido. Este processo pode também incluir transformações estruturais, ou seja, transformar os dados num formato que facilita a sua utilização ou que melhor se adapta ao cenário real. O processo de limpeza de dados pode ser dividido da seguinte forma (Maletic e Marcus, 2000; Raman e Hellerstein, 2001): i. Auditoria da qualidade dos dados, a fim de identificar as anomalias existentes; ii. Escolha dos métodos apropriados para automaticamente detetar e eliminar as anomalias; iii. Aplicação dos métodos ao conjunto de dados. Torna-se importante acrescentar mais um passo (Müller e Freytag, 2003): iv. Pós-processamento ou controlo dos resultados. 22 Pode-se considerar que o processo de limpeza de dados, Figura 3, nunca termina, uma vez que as anomalias são bastante comuns e de difícil deteção e eliminação (Müller e Freytag, 2005; Ahmed e Aziz, 2010). 2.4.1. AUDITORIA DA QUALIDADE DOS DADOS Para analisar a qualidade dos dados, utilizam-se métodos estatísticos que permitem identificar os erros e inconsistências existentes nos dados. Este tipo de análise, tanto dos atributos como do conjunto de dados, permite obter informações tais como o mínimo, o máximo, a dimensão, a frequência, a variância, a unicidade, a ocorrência de valores nulos, identificar padrões, tanto dos atributos como de todo o conjunto de dados (dependência funcionais e regras de associação) (Müller e Freytag, 2003; Rahm e Hai Do, 2000). Os resultados desta análise apoiam as restrições de integridade e o formato do domínio. As restrições de integridade dependem da aplicação do domínio e são especificadas por especialistas no domínio. Cada restrição é verificada para identificar possíveis registos que as violem, numa primeira abordagem, e apenas estes serão considerados no processo de limpeza de dados. A auditoria dos dados também inclui a Figura 3: O Processo de Limpeza de Dados 23 procura por características que mais tarde poderão ser usadas para a correção de anomalias (Müller e Freytag, 2003). Como resultado deste primeiro passo do processo de limpeza de dados, deve-se obter indicação de cada possível anomalia e das suas características, para que os métodos mais adequados sejam escolhidos, como será estudado na próxima secção. 2.4.2. IDENTIFICAÇÃO DOS MÉTODOS A SEREM UTILIZADOS A deteção e eliminação de anomalias são feitas através de uma sequência de operações nos dados (data cleaning workflow), que apenas pode ser identificada após obter as informações sobre as anomalias existentes, através da auditoria da qualidade dos dados. A identificação das operações que, aplicadas aos dados, elimine automaticamente todas as anomalias existentes, é considerada um dos maiores desafios do processo de limpeza de dados (Müller e Freytag, 2003). Um factor importante para a especificação das operações necessárias para corrigir os erros existentes nos dados é o conhecimento das causas destas anomalias, que podem ser múltiplas. Geralmente, corrige-se primeiramente os erros de sintaxe, porque os dados têm que ser automaticamente processados para detetar e remover outros tipos de anomalias que, adicionalmente, estão escondidos pelos erros de sintaxe. Apesar de outros autores como Raham e Hai Do (2000), considerarem separadamente uma fase de verificação da sequência de operações, neste trabalho, tal como em Müller e Freytag (2003), considerar-se-á que esta fase está integrada na especificação. 24 2.4.3. APLICAÇÃO DOS MÉTODOS AO CONJUNTO DE DADOS Após a escolha e verificação da sequência de operações, procede-se então à sua aplicação aos dados, cuja implementação deve ser eficiente para conjuntos de dados de grandes dimensões. Uma vez que a execução das operações de limpeza de dados podem ser computacionalmente intensas, principalmente quando se quer eliminar todas as anomalias existentes, precisa-se de uma heurística para conseguir uma melhor precisão e ainda ter uma velocidade de execução aceitável (Galhardas, Florescu, Shasha, Simon e Saita, 2001). Durante o processo de execução das operações de limpeza de dados, é muito importante a interação com especialistas no domínio. Em casos difíceis, o especialista tem que decidir se um registo está incorreto ou não e especificar ou selecionar a modificação correta para o registo incorreto do conjunto de soluções. A interação com o especialista é dispendioso e demorado. Registos que não podem ser corrigidos imediatamente são muitas vezes separados para inspeção manual depois da execução do processo. 2.4.4. PÓS-PROCESSAMENTO E CONTROLO Após a execução das operações de limpeza de dados, os resultados são analisados para novamente verificar se as operações especificadas estão corretas. Com este passo de controlo, os registos que não puderam ser corrigidos inicialmente são analisados para serem corrigidos manualmente. Estes resultados iniciam um novo ciclo no processo de limpeza de dados, começando por analisar os dados e procurar por características em dados excecionais que permitem especificar uma sequência de operações adicional para limpar os dados por processos automáticos. Isto deve ser suportado pela aprendizagem de uma sequência de operações de limpeza para certas anomalias. 25 2.5 MÉTODOS USADOS NO PROCESSO DE LIMPEZA DE DADOS Tendo em vista a infinidade de métodos utilizados em limpeza de dados, nesta secção pretendemos, apenas, dar uma ideia geral sobre os métodos mais utilizados. 2.5.1. ANÁLISE SINTÁTICA (PARSING) A análise sintática é utilizada, como o próprio nome diz, para a deteção de erros de sintaxe. Nesta análise, decide-se para um dado registo, de uma instância relacional, ou para um atributo do domínio, se este elemento pertence, ou não, ao formato previamente definido. Estes registos ou atributos que apresentam erros de sintaxe devem ser corrigidos. Existem diversas técnicas para corrigir estes erros, como por exemplo, editar uma função distância que escolhe a correção possível utilizando a distância mínima. A existência e quantidade de erros de sintaxe, num conjunto de dados, dependem da extensão da aplicação do esquema, no ambiente onde os dados são mantidos. Caso os dados estejam mantidos num flat file, existe a possibilidade de erros lexicais e de domínio. Caso os dados sejam geridos por um sistema de gestão de base de dados, não é esperado que contenha erros lexicais ou de domínio. No entanto, podem existir, para cada atributo, erros no formato do domínio. A especificação do formato do domínio pode ser suportada por técnicas de aprendizagem de padrão. Raman e Hellerstein (2001) usam uma amostra de valores para deduzir o formato do domínio e garantem a deteção de discrepâncias que é usada para detetar anomalias. 2.5.2. TRANSFORMAÇÃO DOS DADOS A transformação dos dados pretende mapear os dados do seu formato original para o formato esperado pela aplicação (Abiteboul et al., 1999). A transformação afeta o esquema dos registos assim como o domínio dos seus valores. A transformação do 32 O sucesso da limpeza dos dados pode ser medida para cada atividade pela execução de uma simples instrução SQL contando os registos corretos e incorretos. 2.6.5. INTELLICLEAN IntelliClean (Lee, Ling e Low, 2000; Low, Lee, Ling, 2001) é uma abordagem baseada em regras para limpar os dados, cuja aplicação é efetuada através de um motor de inferência de um sistema pericial e cujo principal objetivo é a eliminação de duplicados. A arquitetura proposta pode ser aplicada sobre qualquer base de dados, permitindo a implementação de qualquer estratégia de limpeza de dados atualmente existente. São especificadas três fases distintas para o processo de limpeza de dados: pré-processamento, processamento e verificação e validação humana. Na fase de pré-processamento os erros sintático são eliminados, tais como a verificações ao tipo de dados, uniformização de formatos e adoção de uma representação consistente para as abreviaturas utilizadas. Não é especificado em detalhe, como isto é conseguido. A fase de processamento envolve a avaliação das regras de limpeza sobre os registos pré-processados. As regras especificam as ações a serem tomadas em determinadas circunstâncias perante a ocorrência de determinadas anomalias nos registos. Existem quatro diferentes classes de regras:  Regras de Identificação de Duplicados: especificam as condições sob as quais dois registos são classificados como duplicados.  Regras de Fusão/Eliminação: especificam como os registos duplicados devem ser tratados. Não é especificado como a fusão é executada ou como funcionalmente pode ser declarada. Se nenhuma regra de fusão/eliminação foi especificada, os registos duplicados também podem ser unidos manualmente na fase seguinte.  Regras de Atualização: especificam o modo como os dados devem ser atualizados numa determinada situação. Isto permite a especificação de regras de aplicação de restrição de integridade. Para cada restrição de integridade, uma regra de atualização define como modificar o registo de forma a satisfazer a condição. As regras de 33 atualização podem também ser usadas para especificar como os valores omissos devem ser preenchidos.  Regras de Alerta: especificam as condições sob as quais o utilizador é informado, perante a ocorrência de determinado evento, permitindo certas ações. Durante os primeiros dois estágios do processo de limpeza de dados as ações tomadas são registadas, permitindo a documentação das operações executadas. Na fase da validação e verificação humana, estes registos são analisados para verificar a consistência e precisão das ações efetuadas e, eventualmente, efetuar a sua correção. 2.6.6. TRILLIUM O Sistema de Software Trillium fornece um conjunto de produtos que ajudam as empresas a criar e a manter dados de alta qualidade. Na página oficial (Trillium, 2013), da empresa fabricante, na internet, garantem que este sistema oferece um ambiente colaborativo para negócios e recursos de TI para avaliar o nível de qualidade de um grande volume de dados, permite aos usuários compreenderem o domínio, o formato, os padrões e as relações existentes nos dados e a olhar para a configuração das regras específicas de negócio e padrões definidos nos dados e monitora mais tarde sistemas de anomalias e avalia periodicamente os dados para assegurar que a qualidade elevada é mantida. Este sistema também funciona em todos os tipos de ambientes (o sistema funciona de forma integrada para garantir resultados reproduzíveis em várias plataformas) e integra-se com todos os principais ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) e aplicações de ETC para simplificar os esforços de desenvolvimento e implementação, as regras criadas em um projeto são facilmente replicáveis e exportáveis em diversos formatos, incluindo XML e fornece um sistema totalmente integrado para corrigir, melhorar e padronizar todos os dados. 34 2.6.7. GOOGLE REFINE Google Refine é uma poderosa ferramenta, gratuita, para explorar, normalizar e limpar conjuntos de dados. Existem versões para o Linux, Windows e Mac e diversos tutoriais que ensinam a instalar e utilizar esta ferramenta. Huynh (2011) aconselha o uso desta ferramenta quando é preciso algo mais poderoso do que uma folha de cálculo, mais interativa e visual do que scripting e mais provisório, exploratório, experimental e divertido do que uma base de dados. O Google Refine não foi concebido para lidar com volumes de dados enormes (consegue processar confortavelmente 100.000 linhas e 10 colunas) nem para substituir outras ferramentas, mas sim para complementá-las (Huynh, 2011). O Google Refine possui uma interface tipo folha de cálculo, que torna a sua utilização mais intuitiva. Tem uma linguagem de programação própria para definir expressões, chamada Google Refine Expression Language (GREL) - tem algumas semelhanças com a linguagem utilizada pelo Excel para definir as fórmulas e com o Javascript (Huynh, 2011), mas também suporta outras linguagens, como por exemplo a Jython, caso sejam instaladas extensões que as suportem. Esta ferramenta possibilita, entre outras funcionalidades, a deteção e correção de inconsistências, duplicados e preenchimento de valores omissos. Isto pode ser feito utilizando a GREL ou os comando “Facet”, “Edit”, “Cluster” e outros. 2.6.8. GRITBOT O GritBot (Quinlan, 2007) é uma ferramenta comercial, cuja versão de distribuição livre apenas existe para o sistema operativo Linux, que deteta inconsistência no conjunto de dados. Infelizmente, não existe nenhuma descrição técnica dos métodos utilizados pelo GritBot. O que temos, contudo, permite-nos, através dos resultados e dos trabalhos publicados por Ross Quinlan, concluir que o GritBot gera diversas regras, considerando a cada iteração um atributo do subconjunto de n atributos como atributo objetivo (dependente). Depois, cada registo que viole uma certa regra é 35 identificado um valor de significância indicando a probabilidade que o valor anómalo pode ocorrer por acaso e não por erro. Os atributos numéricos são discretizados automaticamente e os valores nominais são agrupados onde apropriado. Esta ferramenta mostra-se bastante capaz de lidar com grandes volumes de dados e os resultados gerados são muito promissores. Um das desvantagens do GritBot é a falta de uma interface de dados: deve-se criar manualmente dois ficheiros simples – um contendo os dados e um correspondente aos nomes, descrevendo os tipos e valores possíveis para cada atributo. Como o GritBot gera uma longa listagem de resultados (regras), devem ser implementados passos de pós-processamento para agregar os resultados analíticos. No próximo capítulo estudar-se-á com mais detalhe esta ferramenta. 36 3. UM CASO DE ESTUDO 3.1 DESCRIÇÃO DO CONJUNTO DE DADOS O conjunto de dados considerado corresponde à totalidade dos casos onde existe, pelo menos, um código relativo a doenças das válvulas do coração num qualquer diagnóstico, principal ou secundário. Os dados dizem respeito a admissões em todo o país e foram recolhidos entre 1993 e 2009, resultando em 160.853 observações, incluindo informações de 63 variáveis diferentes. De forma a facilitar a leitura das regras a seguir apresentadas, segue-se a Tabela 3, com a descrição e categorias de cada variável. As restantes variáveis serão apresentadas em anexo. Tabela 3: Caracterização das Variáveis Existem algumas técnicas de estatística descritiva que permitem identificar casos extremos, como, por exemplo, boxplot, para o dados quantitativos e a análise das frequências, para os dados qualitativos. Abaixo, apresenta-se os boxplots destas duas variáveis quantitativas, CL_IDADAN e CL_TOTDIAS: Variáveis Descrição Categorias 1: Programada / 2: Não programada / 5: Privada / 3,4,6,7: recuperação de listas de espera CL_TOTDIAS Número total de dias de internamento − DDXBin Doença Valvular como Diagnóstico Principal Sim / Não DRG Código dos grupos homogéneos de cada diagnóstico de admissão Códigos GDH GDHTIPO Tipo de DRG M: Médico / C: Cirúrgico SRG1 Procedimentos Códigos dos Procedimentos CL_PREOP Número de Dias no Período Pré ‐ Operatório − 1: exterior nao referenciado / 2: hospital do SNS / 3: consulta externa do hospital / 4: hospital não pertencente ao SNS / 6: serviço domiciliário / 7: saída contra parecer médico / 20: falecido HOSPRESIDEb Hospital da área de residência Código do Hospital ICU Dias de internamento na UCI − MDC Grande Categoria de Diagnóstico Código de Grande Categoria de Diagnóstico RINT30 Se é um reinternamento em menos de 30 dias 0: Não / 1: Sim ADM_TIP Tipo de Admissão DSP Destino Após a Alta 37 Figura 4: Boxplot CL_IDADAN Figura 5: Boxplot CL_TOTDIAS De forma a exemplificar a análise das frequências para as variáveis qualitativas, apresenta-se a Tabela 4, onde estão apresentadas as frequências para as variáveis DSP e ADMTIP, Código de destino após a alta e Tipo de admissão, respetivamente. 38 Tabela 4: Frequências das Variáveis DSP e ADM_TIP Note-se que na Tabela 4, destacam-se, para a variável DSP, o valor 99, e para a variável ADMTIP, os valores 3 e 5, que aparecem 1, 21 e 15 vezes, em todo o conjunto de dados. As duas técnicas apresentadas anteriormente são úteis apenas para identificar casos extremos em todo o conjunto de dados, não em subconjuntos do mesmo. Assim, o GritBot torna-se relevante e inovador neste tipo de estudo, uma vez que mesmo técnicas mais avançadas de análise de dados, como técnicas agrupamento e análise de distâncias, não encontram anomalias ou casos raros em subconjuntos dos dados. 3.2 USANDO O GRITBOT PARA GERAR REGRAS Como referido no capítulo anterior, o GritBot é uma ferramenta que deteta possíveis anomalias existentes no conjunto de dados. O GritBot gera diversas regras, considerando a cada iteração um atributo do subconjunto de n atributos como atributo objetivo (dependente). As principais vantagens do GritBot, em relação a todas as outras ferramentas referidas, são a sua capacidade de definir o contexto e explicar porque uma determinada anomalia ocorre e de considerar subgrupos para gerar as regras. Doravante, Variáveis Valor Frequência 1139161 20 11511 28909 6745 7520 99 1 2112775 146769 61110 4163 321 515 DSP ADMTIP 39 analisar-se-á com algum detalhe as regras geradas pelo GritBot e a sua aplicação ao conjunto de dados descrito anteriormente. 3.2.1. DESCRIÇÃO DAS REGRAS GERADAS PELO GRITBOT As regras geradas pelo GritBot têm a seguinte estrutura: identificação do caso: [significância] valor anómalo ( N casos, razão) condição 1 condição 2 … condição k O GritBot gera regras de forma a identificar casos extremos/raros num subconjunto de casos. As regras são identificadas da seguinte forma:  Identificação de caso: índice nas aplicações do ficheiro data. Caso o atributo tenha um rótulo (lable) definido, este valor é mostrado aqui.  Significância: probabilidade da anomalia ter ocorrido aleatoriamente e não por erro. Quanto menor a significância, maior é a certeza do valor encontrado ser uma anomalia.  Valor anómalo: valor da variável que é considerado anómalo num determinado subconjunto.  N casos: número de casos considerados no subconjunto (o GritBot considera apenas subconjuntos para um N mínimo de 35 ou 0.5% dos dados).  Razão: motivo pelo qual o valor é considerado anómalo (frequência dos valores diferentes ao valor considerado), que podem tomar duas formas: Figura 6: Estrutura das regras geradas pelo GritBot. Adaptado: Quinlan, 2007 40  Caso contínuo: Média M, X% de casos <= valor ou Média M, X% de casos > = valor (o valor do caso considerado é demasiado alto ou demasiado baixo em relação à distribuição de quase todos os valores do subconjunto.  Caso discreto: X% ‘valor’ (o valor do caso considerado difere do valor comum a quase todos os casos no subconjunto).  Condições 1… k: condições que definem o subconjunto de N casos. Cada condição refere a um único atributo e restringe o valor dum atributo numérico ou especifica um ou mais possíveis valores para um atributo discreto. Se não existirem condições, o valor anómalo corresponde a todo o conjunto de dados. As condições podem tomar várias formas:  atributo = valor (o atributo discreto tem um valor particular);  atributo em valor1 .. valor2 [valor atual] (o atributo discreto ordenado tem um valor num subintervalo e o valor anómalo, do caso atual, está entre parenteses retos);  atributo em {valor1,valor2, …, valor} [valor atual] (o atributo discreto não ordenado tem um dos seus valores no conjunto e o valor anómalo, do caso atual, está entre parenteses retos).  atributo <=valor [valor atual] ou atributo > valor [valor atual] ou atributo > valor1 e <= valor2 [valor atual] (o atributo contínuo tem um valor restringido como mostrado acima e o valor anómalo, do caso atual, está entre parenteses retos). O GritBot permite ao utilizador definir alguns parâmetros como o nível de filtragem (quanto maior o valor da percentagem definida, menor é o número de anomalias encontradas. O valor definido por defeito é de 50%), é possível restringir o número de condições (o valor definido por defeito é 4) e ainda limitar o número de anomalias reportadas (é reportado o número total de anomalias encontradas, mas apenas 41 são mostradas no número definido de regras). Também é possível salvar o processo de análise (o GritBot escreve continuamente informações num ficheiro ASCII, nomeficheiro.sift, e assim é possível utilizar as verificações feitas em novos dados) e o número dos casos de possíveis anomalias de forma a facilitar a sua correção (é gerado um ficheiro ASCII, nomeficheiro.list, em que em cada linha está o número de um caso considerado anómalo). Apesar de ser possível definir estes parâmetros, conclui-se que os valores utilizados por defeito geram resultados bastante bons. 3.2.2.RESULTADOS Nesta subsecção, apresentar-se-á algumas das regras obtidas pela aplicação do GritBot ao conjunto de dados especificado acima. Como variável dependente considerou-se o facto da doença vascular ter sido ou não o motivo da aceitação do indivíduo para o programa de tratamento, tendo sido obtidas 491 regras que identificam diferentes tipos de anomalias. A variável DRG (diagnosis-related group) é utilizada para classificar os casos hospitalares por grupos homogéneos de diagnóstico de forma a organizar o financiamento das instituições. Esses códigos podem ser agrupados em: Médico ou Cirúrgico; assim a variável GDHTIPO codifica o tipo correspondente de DRG (M: médico e C: cirúrgico). Antes de identificar as possíveis anomalias, o GritBot exclui da análise os valores em falta e os valores altos / baixos que podem ser enganadores e exibe mensagens de aviso. Dois exemplos destas mensagens para os nossos dados: while checking GDHTIPO: excluding 19 missing values while checking CL_TOTDIAS: excluding high tail (4769 Cases above 41) 48 3.3 USANDO ÁRVORES DE DECISÃO PARA GERAR REGRAS 3.3.1. DESCRIÇÃO DO MÉTODO Uma vez que o GritBot mostra-se uma ferramenta bastante poderosa para a identificação de inconsistências e, apesar do seu código estar disponível na linguagem de programação C, não há nenhuma descrição do seu funcionamento. Torna-se interessante então, encontrar um método que sabemos como os resultados, semelhantes aos gerados pelo GritBot, foram encontrados. Tendo em conta que o GritBot foi criado pelo Ross Quinlan, inventor do C4.5, considerar-se-á uma árvore de decisão para gerar regras e descobrir casos raros. Uma árvore de decisão classifica exemplos de uma base de dados em um número finito de classes, possuindo uma forma simples de representação. Em uma árvore de decisão, os nós representam os atributos, os ramos ou ligações representam os possíveis valores deste atributos e as folhas representam as diferentes classes. Um objeto é classificado seguindo o caminho da raiz da árvore até uma folha, enquanto as suas características satisfazem os nós e as suas ligações. Estes caminhos definirão as diversas regras a serem consideradas neste trabalho. A utilização das árvores de decisão apresenta diversas vantagens, entre as quais destacam-se o facto de estas poderem ser aplicadas a grandes conjuntos de dados, serem adequadas a qualquer tipo de dados (discretos ou contínuos), terem uma fácil interpretação e os resultados poderem ser usados diretamente pelo utilizador. Considere-se a seguinte árvore e o workflow KNIME: 49 Figura 4: Estrutura da Árvore de Decisão gerada Figura 5: Workflow KNIME A Árvore de Decisão, ilustrada na Figura 7, e as regras apresentadas na próxima subsecção, foram geradas utilizando a sequência de operações (workflow), apresentada na Figura 8, do software de data mining KNIME. 50 O comando Decision Tree Learner foi utilizado para gerar a árvore de decisão, ilustrada na Figura 7, com as seguintes especificações: Figura 6: Configurações para criar a Árvore de Decisão Como é possível verificar, utilizou-se a variável DDXBin como classe, assim como foi utilizada como variável dependente pelo GritBot. Os outros atributos foram escolhidos de forma a não gerarem uma árvore muito profunda. Os comandos Row Filter foram utilizados para definirem cada nó da árvore utilizado para formar regras (1º conjunto) e para definir o caso identificado pela regra (2º conjunto). Para definir o conjunto de nós que definem o subconjunto, ou caminho, desejado, utiliza-se este comando em cascata. A Figura 10 ilustra como cada nó é definido: 51 Figura 7: Configurações para selecionar um nó da Árvore de Decisão No caso ilustrado pela Figura 10, são selecionados todos os casos em que a variável ADM_TIP toma o valor 1. O comando Statistics devolve a frequência absoluta dos 20 valores mais e menos frequentes, de cada variável, assim como os valores omissos, como ilustrado na Figura 11: Figura 8: Output do comando Statistics 52 Assim, obtendo a frequência absoluta dos casos mais raros, torna-se fácil calcular a sua frequência relativa. Este comando também calcula as estatísticas descritivas das variáveis, tais como média, desvio padrão, máximo, mínimo, etc. O comando HiLite Filter é usado para criar uma base de dados com o subconjunto definido pelas regras e para mostrar o caso identificado pela regra como possível anomalia. Uma vez que já foi explicado o método utilizado para gerar resultados semelhantes aos do GritBot, podemos analisar as regras obtidas utilizando a árvore apresentada na Figura 7. 3.3.2.RESULTADOS Apresentar-se-á nesta subsecção, um conjunto de regras que foram consideradas, por um especialista, como sendo relevantes. Como será verificado adiante, um mesmo “caminho”, ou subconjunto, pode conter diferentes tipos de anomalias. Doravante, analisar-se-á as regras representadas pelo “caminho”, ilustrado nas Figuras abaixo, da raiz até à folha que está a cinzento. Figura 9: Subconjunto 1 53 O subconjunto apresentado na Figura 12, corresponde aos indivíduos que tiveram a admissão programada, DRG menor ou igual a 137 (na verdade o DRG deste subconjunto está entre 1 e 103) e MDC menor ou igual a 4. Nenhum paciente deste subgrupo tem como diagnóstico principal uma doença valvular. A regra apresentada abaixo pode ser considerada uma anomalia uma vez que o paciente teve um total dias de internamento igual a 209 dias, sendo que 99,84% dos pacientes estiveram internados no máximo durante 100 dias. Neste caso, é comum a variável CL_TOTDIAS ter valores extremos, o que parece ser o caso desta observação. Case 110700 CL_TOTDIAS = ‘209’ (1919 Cases, 99,84% < ‘100’) ADM_TIP <=1 [1] DRG <=137 MDC <= 4 No entanto, a regra seguinte aparenta ser um erro de registo, uma vez que apresenta um valor negativo para a variável CL_PREOP, ou seja, dias de internamento no pré-operatório negativo. Case 40151 CL_PREOP = ‘-92’ (1919 Cases, 99,90% >= ‘0’) ADM_TIP <=1 [1] DRG <=137 MDC <= 4 A regra apresentada abaixo pode ser considerada uma anomalia, uma vez que possui MDC igual a 0, enquanto 99,01% os elementos deste subconjunto possuem MDC maior que 0. Isto pode dever-se ao facto do diagnóstico deste paciente não se enquadrar em nenhum dos outros MDC, logo foi-lhe atribuído um MDC mais geral (MDC igual a 0 significa Pré- Grandes Categorias Diagnósticas). 54 Case 92847 MDC = ‘0’ (1929 Cases, 99,01% > ‘0’) ADM_TIP <=1 [1] DRG <=137 MDC <= 4 Na última regra, deste subconjunto, apresentada, o paciente foi reinternado após menos de 30 dias a seguir a sua alta, sendo que isto não acontece em 93,43% dos casos. No entanto, a taxa de reinternamento num curto espaço de tempo (menos de 30 dias) é considerável, sendo quase 7% dos casos. Este facto tem implicações ao nível do financiamento e organização do sistema de saúde, uma vez que as instituições são penalizadas por este tipo de reinternamento. Case 82 RINT30 = ‘1’ (1929 Cases, 93,43% = ‘0’) ADM_TIP <=1 [1] DRG <=137 MDC <= 4 Figura 10: Subconjunto 2 55 O subconjunto apresentado na Figura 13 corresponde aos indivíduos que tiveram a admissão programada, MDC igual a 5 (Doenças e Perturbações do Aparelho Circulatório) e DRG menor ou igual a 105 (na verdade, entre 104: Procedimentos nas válvulas cardíacas e/ou outros procedimentos cardiotorácicos major, com cateterismo cardíaco e 105: Procedimentos nas válvulas cardíacas e/ou outros procedimentos cardiotorácicos major, sem cateterismo cardíaco). Neste subconjunto, 91,76% dos pacientes têm uma doença valvular como diagnóstico principal e apenas 8,24% não têm. Todos os casos que serão apresentados abaixo tiveram admissão programada, foram codificados com um diagnóstico alargado de Doenças e Perturbações do Aparelho Circulatório (MDC 5), diagnóstico de admissão Procedimentos nas válvulas cardíacas e/ou outros procedimentos cardiotorácicos major, sem cateterismo cardíaco (GDH 105) e tiveram como diagnóstico principal uma doença valvular. A regra apresentada abaixo pode ser considerada uma anomalia uma vez que o paciente teve um total de dias de internamento na UCI igual a 104 dias, sendo que 99,99% dos pacientes estiveram internados no máximo durante 26 dias. Assim como para a variável CL_TOTDIAS, é comum a variável ICU ter valores extremos, o que parece ser o caso desta observação. Case 31967 ICU = ‘104’ (13562 Cases, 99,99% <= ‘26’) ADM_TIP <=1 [1] MDC > 4 [5] DRG <=105 [105] Assim como na regra anterior, o caso seguinte pode tratar-se de um valor extremo, uma vez que o total de dias de internamento no pré-operatório foi de 368 dias, mais de um ano, sendo 95 o número máximo de dias de internamento no pré-operatório em 99,97% dos casos. Entretanto, caso o ano de admissão esteja preenchido com o ano anterior e este paciente tenha ficado internado apenas 3 dias no pré-operatório, como 56 este valor é calculado automaticamente, daria um total de 368 dias, tratando-se assim de um erro de registo. Case 38995 CL_PREOP = ‘368’ (13562 Cases, 99,97% <= ‘95’) ADM_TIP <=1 [1] MDC > 4 [5] DRG <=105 [105] A regra abaixo pode ser considerada um caso raro, uma vez que 94,28% dos destinos após a alta são exteriores não referenciados (DSP igual a 1) e neste caso o destino foi um hospital do SNS. Case 38544 DSP = ‘2’ (13562 Cases, 94,28% = ‘1’) ADM_TIP <=1 [1] MDC > 4 [5] DRG <=105 [105] Figura 11: Subconjunto 3 57 O subconjunto apresentado na Figura 14 corresponde aos indivíduos que tiveram a admissão programada, MDC igual a 5 e DRG entre 106 e 123. Neste subconjunto, 77,2% dos pacientes têm uma doença valvular como diagnóstico principal, enquanto e 22,8% dos pacientes não têm. Case 1013 GDH_TIPO = ‘M’ (2583 Cases, 95,32% = ‘C’) ADM_TIP <=1 [1] MDC > 4 [5] 105 > DRG <=123 [121] A regra acima pode representar um caso duvidoso a ser analisado, uma vez que a admissão foi programada, foi codificado com MDC 5 (Doenças e Perturbações do Aparelho Circulatório), GDH entre 106 e 123 (GDH 121: Doença circulatória com enfarte agudo do miocárdio e com complicações cardiovasculares, alta vivo) codificado com GDH médico e não cirúrgico (como acontece em 95,32% dos casos). Figura 12: Subconjunto 4 64 Apesar das vantagens referidas, o método utilizado pelo GritBot para encontrar as regras que definem as possíveis anomalias não está descrito na literatura. Assim, o método desenvolvido neste trabalho, usando árvores de decisão mostra-se bastante interessante, uma vez que permite saber como a regra foi obtida. Este método permite encontrar um número bastante elevado de regras e cada árvore gera regras diferentes. As regras obtidas são claras e de fácil identificação, devido à interpretação intuitiva da representação gráfica das árvores de decisão. No entanto, algo que pode ser aperfeiçoado no futuro seria a automatização do método, o que tornaria o processo mais rápido e eficaz, dado que, para um grande conjunto de dados este método ainda exige um tempo de análise considerável para a definição das regras, cálculos das probabilidades e análise dos casos identificados. Assim quanto mais eficiente o método, menos será exigido do analista, tornando assim o método mais viável. Nesta parte, provavelmente, seria exigida alguma programação e talvez o uso de outra ferramenta. Entretanto, o KNIME mostrou-se bastante útil e adequado para esta parte do trabalho, permitindo uma sequência de operações intuitiva, de fácil utilização e que devolviam resultados essenciais para o desenvolvimento do método. Outra questão a ser abordada futuramente é a continuação do processo de limpeza de dados, uma vez que o foco deste trabalho foi a auditoria dos dados, ou seja, a identificação das anomalias existentes. Assim, pretende-se identificar as anomalias mais frequentes, não apenas eliminá-las dos dados, mas também através de um processo de pós-processamento, restrições de integridade e outros métodos, evitar o seu aparecimento. 65 5. REFERÊNCIAS BIBLIOGRÁFICAS Abiteboul, S., Cluet, S., Milo, T., Mogilevsky, P., Siméon, J., & Zohar, S. (1999). Tool for Data Translation and Integration. Paper presented at the Bolletin of IEEE Computer Society Technical Committee on Data Engineering. Agrawal, R., Imielinski, T., & Swami, A. (1993). Mining Association Rules between Sets of Items in Large Databases. Paper presented at the Proceeding of the AMC SIGMOD on Management of Data, Washington DC, USA Ahmed, I., & Aziz, A. (2010). Dynamic Approach for Data Scrubbing Process. International Journal on Computer Science and Engineering, Vol. 02, 416-423. Ananthakrishna, R., Chaudhuri, S., & Ganti, V. (2002). Eliminating Fuzzy Duplicates in Data Warehouses. Paper presented at the Proceeding of 28th Very Large Data Base Conference, Hong Kong, China. Ciszak, L. (2008). Application of Clustering and Association Methods in Data Cleaning. Paper presented at the Proceeding of the Internatinal Multiconference on Computer Science and Information Technology, Wisla, Poland. Cortes, B. (2005). Sistemas de Suporte à Decisão. Lisboa: FCA - Editora de Informática. Delmater, R., & Hancock, M. (2000). Data Mining Explained - A Manager's Guide to Customer-Centric Business Intelligence. Woburn: Digital Press. Elmasri, R., & Navathe, S. B. (1999). Fundamentals of Database Systems (3rd Edition): Addison Wesley Publishing Company. Escalante, H. J. (2006). Cleaning Training-Datasets with Noise-Aware Algoritms. Paper presented at the IEEE Seventh Mexican International Conference on Computer Science (ENC'06), San Luis Potosi, Mexico. Gallhardas, H., Florescu, D., & Shasha, D. (2000). AJAX: An extensive data cleaning tool. ACM SIGMOD on Management of Data. Dallas, TX, USA. Galhardas, H., Florescu, D., Shasha, D., Simon, E., & Saita, C.-A. (2001). Declarative Data Cleaning: Language, Model and Algorithms. Paper presented at the Proceedings of the 27th VLDB Conference, Roma, Italy. Goasdoué, V., Nugier, S., Duquennoy, D., & Laboisse, B. (2007). An Evaluation Framework for Data Quality Tools (Practice Oriented). Paper presented at the In Proceedings of the International Conference for Information Quality. 66 Google Refine, a power tool for working with messy data. from http://code.google.com/p/google-refine/ Grimmer, U., & Hinrichs, H. (2001). A Methodological Approach to Data Quality Management Supported by Data Mining. Proceedings of the Sixth International Conference on Information Quality, (pp. 217 - 232). Cambridge, MA, USA. Han, J., & Kamber, M. (2005). Data Mining: Concepts and Techniques (2nd ed.). San Francisco, CA, USA: Morgan Kaufmann Publishers. Hao, Y., & Xing-chun, D. (2008). The Design and Implementation of Data Cleaning Knowledge Modeling. Paper presented at the IEEE International Symposium on Knowledge Acquisition and Modeling, Wuhan, China. Hernández, M. A., & Stolfo, S. J. (1998). Real-world Data is Dirty: Data Cleaning and The Merge/Purge Problem. Data Mining and Knowledge Discovery, Vol. 2, 9- 37. Huynh, D. (2011). Google Refine Tutorial. Paper presented at the Computer Assisted Reporting Conference, Raligh, NC, USA. Inmon, W. H. (2002). Building the Data Warehouse (3rd Edition) USA: John Wiley & Sons, Inc. Lee, M. L., Lu, H., Ling, T. W., & Ko, Y. T. (1999). Cleansing Data for Mining and Warehousing Paper presented at the Proceedings of the 10th International Conference on Database and Expert Systems Applications, Florence, Italy. Lindström, A., Gustafsson, P., Jägerlind, C., & Tsoi, J. (2006).A Framework for Assessing Enterprise Data Quality - From a Business Perspective EARP Working Paper AL101. Stockholm, Sweden: Department of Industrial Information and Control Systems - Royal Intitute of Technoligy (KTH). Lorena, A. C., Faceli, K., Oliveira, M., Carvalho, A. P. d. L., & Gama, J. (2012). Extração de Conhecimento de Dados - Data Mining: Edições Sílabo. Low, W. L., Lee, M. L., & Ling, T. W. (2001). A Knowledge-based Approach for Duplicate Elimination in the Data Cleaning. Information Systems, Vol. 26, 585- 606. Maletic, J. I., & Marcus, A. (2000). Data Cleaning: Beyond Integrity Analysis. Paper presented at the Conference in Information Quality, Cambridge, MA, USA. Mayol, E., & Teniente, E. (1999). A Survey of Current Methods for Integrity Constraint Maintenance and View Updating (pp. 62-73): ER Workshops 1999. 67 Mohamed, H. H., Kheng, T. L., Collin, C., & Lee, O. S. (2011). E-Clean: A Data Cleaning Framework for Patient Data. Paper presented at the First International Conference on Informatics and Computational Intelligence Bandung, Indonesia. Monge, A. E., & Elkan, C. P. (1997). An Efficient Domain-independent Algorithm for Detecting Approximately duplicate database records Paper presented at the Proceedings of the SIGMOD 1997 Workshops on Data Mining and Knowledge Discovery, Tucson, Arisona, USA. Motro, A. (1989). Integrity = Vality + Completeness. Paper presented at the ACM Transactions on Database Systems. Müller, H., & Freytag, J.-C. (2005). Problems, Methods and Challenges in Comprehensive Data Cleaning . Berlin. Naumann, F. (2002). Quality-driven query answering for integrated information systems. Germany: Springer. Oliveira, P. J., Rodrigues, F., & Henriques, P. R. (2004). Limpeza de Dados - Uma Visão Geral. Paper presented at the Data Gadgets. Olson, J. E. (2003). Data Quality, The Accuracy Dimension USA. Patel, S. (2012). Requirement to cleanse DATA in ETL process and Why is data cleansing in Business Application? International Journal of Engineering Research and Applications (IJERA), Vol. 2, 840-842. Quinlan, R. (2007). GritBot: An Informal Tutorial, from http://www.rulequest.com/gritbot-unix.html Rahm, E., & Hai Do, H. (2000). Data Cleaning: Problems and Current Aproaches. IEEE Bulletin of the Technical Committee on Data Engineering, Vol. 24. Raman, V., & Hellerstein, J. M. (2001). Potter's Wheel: An Interactive Data Cleaning System. Paper presented at the 27th Very Large Data Base Endowment Conference, Roma, Italy. Redman, T. C. (1998). The Impactof Poor Data Quality on theTypical Enterprise. Communications of the ACM, 41, 79-82. Sattler, K.-U., Conrad, S., & Saake, G. (2000). Adding Conflict Resolution Features to a Query Language for Database Federations. Paper presented at the Proceedings of the 3rd International Workshop on Engeneering Federated Information Systems, Dublin, Irland. Sattler, K.-U., & Schallehn, E. (2001). A Data Preparation Framework based on a 68 Multidatabase Language. Paper presented at the International Database Engeneering Applications Symposium (IDEAS) Grenoble, France. Smith, T. F., & Watermann, M. S. (1981). Identification of Common Molecular Subsequences. Journal of Molecular Biology, Vol. 147, 195-197. Trillium Software (2013). from http://www.trilliumsoftware.com/ Winkle, W. E. (1999). State of Statistical Data Editing and Current Research Problems. Paper presented at the UN/ECE Work Session on Statistical Data Editing, Rome, Italy. Vassiliadis, P., Vagena, Z., Skiadopoulos, S., Karayannidis, N., & Sellis, T. (2001). ARKTOS: A Tool for Data Cleaning and Transformation in Data Warehouse Environments. 69 ANEXOS Tabela 5: Descrição das Variáveis do Conjunto de Dados Variáveis Descrição Categorias 1: Programada / 2: Não programada / 5: Privada / 3,4,6,7: recuperação de listas de espera ANOALTA Ano de Alta − CLIDADAN Idade do paciente em anos − CLIDADDI Idade do paciente em dias − CLPREOP Número de Dias no Período Pré‐Operatório − CLSAIDLAST Data de Alta − CLTOTDIAS Número total de dias de internamento − DDX1 Diagnóstico Principal Códigos dos Diagnósticos (ICD‐9MC) DDX2 … DDX20 Diagnósticos Secundários Códigos dos Diagnósticos (ICD‐9MC) DDXBin Doença Valvular como Diagnóstico Principal Sim / Não DRG Código dos grupos homogéneos de cada diagnóstico de admissão Códigos GDH 1: exterior nao referenciado / 2: hospital do SNS / 3: consulta externa do hospital / 4: hospital não pertencente ao SNS / 6: serviço domiciliário / 7: saída contra parecer médico / 20: falecido GDHTIPO Tipo de DRG M: Médico / C: Cirúrgico HOSPFROMr Hospital de origem (quando transferido) Código do Hospital de origem HOSPIDr Hospital Código do Hospital HOSPRESIDEb Hospital da área de residência Código do Hospital HOSPTOr Hospital de destino (quando transferido) Código do Hospital de destino ICU Dias de internamento na UCI − INTERVCIR Data da Intervenção Cirúrgica − MDC Grande Categoria de Diagnóstico Código de Grande Categoria de Diagnóstico RESIDEb Área de Residência Código de Área de Residência (Distrito e Concelho) RINT30 Se é um reinternamento em menos de 30 dias SEX Sexo 1: Masculino / 2:Feminino SRG1 … SRG20 Procedimentos Códigos dos Procedimentos (ICD‐9MC) TIPOA Classe do hospital de destino − TIPOC Classe do hospital de destino (outra classificação) − ADMTIP Tipo de Admissão Destino Após a Alta DSP