Data Profiling. Engenharia Informática e de Computadores

Transcrição

1 Data Profiling Identificação de problemas de qualidade de dados usando análise de dados e métodos estatísticos em base de dados de cartões de clientes Ana Carina Vieira Rodrigues Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Prof. Doutor Pedro Sousa - DEI/IST Orientador: Prof. Doutora Helena Isabel de Jesus Galhardas - DEI/IST Vogais: Prof. Doutor Manuel João Fonseca - DEI/IST Eng. João Carlos Pereira Damásio - Link Consulting Setembro de 2008

2

3 Resumo O que não se sabe sobre os dados de uma empresa prejudica bastante o negócio da mesma. Ao longo do tempo grandes iniciativas, tais como a implementação de ERPs, CRMs, fusões, aquisições ou migração de dados, têm uma grande falha em comum: dados errados, corrompidos, incompletos, etc. De acordo com os relatórios do TDWI, mais de 80% dos gestores de negócio inquiridos acreditam que os seus dados estão bons. Contudo mais de metade dos seus técnicos reconhecem que os dados estão em pior estado do que os executivos pensam. Esta dissertação descreve qual o potencial do Data Profiling na detecção das várias anomalias que os dados de uma BD podem apresentar e quais as vantagens de utilizar o mesmo. Para que a detecção de erros seja rigorosa e completa é necessário uma metodologia de DP que permita ao analista avaliar todos os elementos de uma BD e que disponha de um conjunto de funcionalidades através das quais se consiga reportar o maior número de erros. Desta forma, nesta dissertação foi reformulada a metodologia DP de forma a concentrar na mesma, todos os objectivos enumerados atrás. Perante grandes quantidades de dados, o analista só com a metodologia de DP não consegue reportar em tempo útil e de uma forma completa todas as anomalias. Devido a este factor foi necessário realizar um estudo de ferramentas de DP existentes no mercado. Como resultado final, foram reportados um conjunto de anomalias de uma BD relacional de cartões de clientes de operadores de transportes. Estes foram obtidos através de uma auditoria de qualidade de dados realizada através da aplicação das várias etapas da metodologia DP, auxiliada pelas ferramentas de DP escolhidas. Palavras-Chave: Data Profiling, Qualidade de Dados, Erros, Auditoria de dados, Base de dados e Metodologia DP. i

4 Abstract The data of a company that is unknown can harm its business on a large scale. Over time, great initiatives, such as the implementation of an ERP, CRM, mergers, acquisitions or data migration, have one big flaw in common: incorrect, corrupt, incomplete data, etc. Unfortunately, low quality data causes a slow death. According to the TDWI reports, over 80% of the interviewed business managers believe their data is just good. However, over half of their technicians recognize that the data is in worse condition than the executives believe it to be. This thesis describes the potential of Data Profiling in detecting several anomalies that can be found in databases and what are the advantages of using it. To have an accurately and comprehensively detection its necessary one methodology of DP that allows analysts to assess all elements of a BD and which has a range of features through which it can report the highest number of errors. Thus, this thesis recast DP methodology in order to concentrate on it, all the objectives listed above. Faced with large amounts of data, analysts cant report in real time and in comprehensive manner all the anomalies with only DP methodology. For this reason was necessary to study existing DP Tools. Has final result, were reported a set of anomalies in a relational database of cards of clients of transports company. These were obtained through an audit of Data Quality held by applying all stages of DP methodology, aided by the DP tools chosen. Keywords: Data Profiling, Data Quality, Errors, Data Audit, Database and DP Methodology. ii

5 Índice Resumo Abstract Lista de Figuras Lista de Tabelas Lista de Acrónimos i ii vi viii ix 1 Introdução Motivação Qualidade de Dados Problemas de qualidade de dados Dimensões de qualidade de dados Data Profiling Problema a Resolver Tecnologia Existente Solução Contribuições Metodologia de Investigação Organização da Dissertação Trabalho relacionado Ferramentas de Data Profiling Actividades das ferramentas de DP Classificação das ferramentas de DP Algoritmos de detecção de duplicados O que são registos duplicados? Algoritmos de detecção simples Algoritmos de detecção complexos Ferramentas Conclusão Metodologia de Data Profiling Análise de cada coluna de uma tabela Análise da coluna através das suas propriedades Análise da coluna através de funções estatísticas Análise da coluna através de dicionários de palavras Análise da estrutura da base de dados iii

6 3.3 Análise dos dados através de regras de negócio Análise de registos aproximadamente duplicados Auditoria da qualidade de dados da BD_OT Ambiente Experimental Tabela Clientes Tabela Requisições Tabela Cartões Aplicação da metodologia de DP Análise de cada coluna de uma tabela Análise da estrutura da base de dados Análise dos dados através de regras de negócio Análise de registos aproximadamente duplicados Avaliação das ferramentas de Data Profiling da Oracle OWB - Módulo DP ODI-DQ OWB - Módulo DP versus ODI-DQ Conclusões Trabalho Futuro Referências 77 6 Anexos Magic Quadrant for Data Quality Tools, 2007 and Detecção de registos aproximadamente duplicados no ODI-DQ Actividades das ferramentas de DP da Oracle Actividades da ferramenta OWB - Módulo DP Actividades da ferramenta ODI_DQ iv

7 Lista de Figuras 2.1 Métodos para detecção de qualidade de dados [1] À esquerda a metodologia de DP segundo Jack Olson [2] e à direita a metodologia de DP segundo esta dissertação Processo de análise da coluna segundo as propriedades da mesma Padrões dominantes para o cartão do cidadão (OWB - Módulo DP) Padrões dominantes para o bilhete de identidade Número de clientes com bilhete de identidade distintos (OWB-Módulo DP) Padrões dominantes para o bilhete de identidade militar Padrões dominantes para a carta de condução Padrões dominantes para a cédula pessoal Padrões dominantes para a cédula consular Padrões dominantes para a autorização de residência Padrões dominantes para o atestado de residência Padrões dominantes para a autorização de permanência Padrões dominantes para o n o de Ordem CCFL Padrões dominantes para o passaporte Padrões que o código-postal da tabela Clientes, assume ao longo da sua coluna Padrões que o código-postal da tabela Requisições, assume ao longo da sua coluna Expressão regular para detectar s inválidos [3] Padrões que o número de telefone da tabela Clientes assume Padrões que o número de telefone da tabela Requisições assume Padrões que o número de telemóvel assume na tabela Clientes Padrões que o número de telemóvel assume na tabela Requisições Expressão regular para detectar números de telemóvel errados Expressão regular para detectar números de telefone errados Padrões dominantes para o número de requisição dos clientes Data de nascimento mais recente e mais antiga - Tabela Clientes Data de nascimento mais recente e mais antiga - Tabela Requisições Data de emissão de um documento de identificação mais recente e mais antiga - Tabela Clientes Data de emissão de um documento de identificação mais recente e mais antiga - Tabela Requisições Data do pedido de um cartão mais recente e mais antiga Número de clientes que não têm o género definido, através da ferramenta ODI-DQ Número de requisições que não têm o género do cliente definido, através da ferramenta OWB - Módulo DP v

8 4.30 Query para detectar campos de colunas redundantes com valores distintos Queries para detectar datas de nascimento inválidas Query para detectar datas de nascimento posteriores a datas de emissão de documentos de identificação Query para detectar clientes com perfis incorrectos Campos da primeira regra para a formação da chave de detecção Campos da segunda regra para a formação da chave de detecção Campos da terceira regra para a formação da chave de detecção Campos da última regra para a formação da chave de detecção Magic Quadrant for Data Quality Tools Magic Quadrant for Data Quality Tools Projecto de qualidade de dados para a detecção de registos duplicados Transformer - Parser Inputs Customer Data Parser - Options Window Key Generator - Keys Relationship Linker - Process Relationship Linker - Match Rules Relationship Linker - Frequência dos valores únicos da coluna LEV1_MATCHED da tabela pt rellink p Relationship Linker - Exemplo de um cliente aproximadamente duplicado Estrutura de um projecto de profiling no ODI-DQ vi

9 Lista de Tabelas 2.1 Classificação das várias ferramentas de DP (1). Legenda: N -> Não, S -> Sim, - -> Indefinido, O -> Oracle, SQLS -> SQL Server, A -> Acess, FF -> Flat Files, MS -> MySql, FP -> Formato Próprio Classificação das várias ferramentas de DP (2). Legenda: N -> Não, S -> Sim, - -> Indefinido, O -> Oracle, SQLS -> SQL Server, A -> Acess, FF -> Flat Files, MS -> MySql, FP -> Formato Próprio Amostra dos resultados de s inválidos na tabela Clientes Amostra dos resultados de s inválidos na tabela Requisições Amostra dos resultados de telefones errados na tabela Clientes Amostra dos resultados de telefones errados na tabela Requisições Amostra dos resultados de telemóveis errados na tabela Clientes Amostra dos resultados de telemóveis errados na tabela Requisições Amostra de padrões inválidos do número da requisição Amostra dos resultados de moradas mal distribuídas na tabela Clientes Amostra dos resultados de moradas mal distribuídas na tabela Requisições Amostra dos resultados de códigos-postal inválidos na tabela Clientes Amostra dos resultados de códigos-postal inválidos na tabela Requisições Amostra de clientes com requisições de outros clientes Amostra de clientes, onde os campos em comum estão preenchidos na tabela Clientes, mas não o estão na tabela Requisições Amostra de clientes, cujos campos comuns na tabela Requisições estão mal escritos Amostra dos resultados de datas inválidas na tabela Clientes Amostra dos resultados de datas inválidas na tabela Requisições Amostra dos resultados de datas de emissão inválidas na tabela Clientes Amostra dos resultados de datas de emissão inválidas na tabela Requisições Amostra dos resultados de datas de requisições inválidas Amostra dos resultados de datas de nascimento posteriores às datas de emissão na tabela Clientes Amostra dos resultados de datas de nascimento posteriores às datas de emissão na tabela Requisições Amostra dos resultados de datas de nascimento posteriores às datas de requisições Amostra dos resultados de datas de emissão de documentos de identificação posteriores às datas de requisições Amostra de clientes com cartões que não correspondem ao seu perfil Amostra de clientes duplicados Actividades da ferramenta OWB - DP que se encontram nas várias etapas da metodologia DP (1) vii

10 4.27 Actividades da ferramenta OWB - DP que se encontram nas várias etapas da metodologia DP (2) Actividades da ferramenta ODI-DQ que se encontram nas várias etapas da metodologia DP (1) Actividades da ferramenta ODI-DQ que se encontram nas várias etapas da metodologia DP (2) Actividades da ferramenta ODI-DQ que se encontram nas várias etapas da metodologia DP (3) Actividades da ferramenta ODI-DQ que se encontram nas várias etapas da metodologia DP (4) Amostra dos tempos de execução das duas ferramentas de DP sobre as principais tabelas da BD_OT viii

11 Lista de Acrónimos BD Base de Dados CRM Customer Relationship Management DC Data Cleaning DQ Data Quality DP Data Profiling ERP Enterprise Resource Planning ETL Extract, Transform and Load ODI-DQ Oracle Data Quality for Data Integrator OT Operadora de Transportes OWB Oracle Warehouse Builder RI Restrição de Integridade SI Sistema de Informação SGBDRs Sistemas de Gestão de Base de Dados Relacionais TDWI The Data Warehousing Institute TI Tecnologias de Informação ix

12 1 Introdução 1.1 Motivação A área da qualidade dos dados num Sistema de Informação (SI) revela o quão longe ou perto os dados e a sua estrutura estão do padrão definido como óptimo para uma determinada aplicação [4]. Até há dez anos atrás, esta área era relativamente mal definida dentro da estratégia de uma organização de Tecnologias de Informação (TI) [5]. De facto, nas aplicações já existentes, a manutenção da qualidade dos dados era considerada como um acto secundário, pois julgava-se que gerava pouco ou nenhum valor para o negócio da empresa. A juntar-se a este factor, na integração de várias aplicações, as equipas de projecto normalmente iniciavam a sua actividade programando a nova aplicação que suportava a integração, em vez de, numa primeira fase, analisarem e interrogarem as Bases de Dados (BD) que iriam servir a nova aplicação [1]. Ao longo do tempo de vida dos Sistemas de Informação, os utilizadores e as equipas de desenvolvimento das aplicações, demonstraram uma falta de preocupação sobre os dados, originando um decréscimo da respectiva qualidade. Esta situação surgiu pelos seguintes motivos [6]: Falta de validação na entrada dos dados dos SI; Demasiada confiança nos metadados das base de dados, ignorando que uma especificação correcta não invalida a existência de erros nos dados; Utilização de métodos primários na detecção de anomalias nos dados, como é o caso das interrogações Structured Query Language (SQL) efectuadas de maneira ad-hoc. Estas interrogações são normalmente executadas sobre amostras de dados e não cobrem, na totalidade, todos os registos de uma BD [1]. Devido aos vários problemas provocados pela falta de uma minuciosa e sistemática análise de dados, o interesse pela qualidade dos mesmos que suportam um SI, tem crescido ao longo do tempo. Como tal têm sido vários os inconvenientes gerados, mas os mais marcantes podem ser enunciados da seguinte forma [7]. Em primeiro lugar, o descontentamento demonstrado pelos clientes de SI ao adquirirem aplicações que não foram pensadas de acordo com os dados e estrutura das suas BDs. Por exemplo, a existência de uma aplicação que tem na sua interface um formulário em que a morada está separada em três caixas de texto, tendo também a sua BD três campos a representar a mesma, mas ao longo da BD existem registos em que a morada se encontra dividida nos três campos e registos em que a mesma se encontra num só campo. Em segundo encontra-se o descontentamento da administração de uma empresa, que em certas ocasiões julga ter um conjunto de clientes, mas na realidade, parte destes estão duplicados nas base de dados que suportam os diferentes SI s da empresa. Por último, pode-se enunciar o aumento de custo dos projectos devido ao alargamento do tempo dos mesmos para a correcção dos vários erros de uma aplicação e/ou dos dados de uma BD, que não foram planeados nem pensados. 1

13 1.2 Qualidade de Dados A qualidade de dados define-se como a actividade que detecta e corrige anomalias nos dados [4]. Os dados são considerados de alta qualidade se cumprirem os requisitos para as operações a que foram destinados e se estão de acordo com as decisões tomadas e planeadas [8]. Quando não o são, significa que existe um conjunto de problemas de qualidade de dados que podem ser encontrados a nível do esquema de dados e/ou a nível das instâncias dos mesmos Problemas de qualidade de dados Os problemas de qualidade de dados representados a seguir foram retirados do artigo A survey of data quality tools [9]. No âmbito desta dissertação os problemas a detectar estão focados nas instâncias dos dados, sendo que parte destes podem ser eliminados pela tecnologia relacional (SGBDRs) e outros não Problemas de qualidade de dados eliminados pelos SGBDRs Os Sistemas de Gestão de Base de Dados Relacionais (SGBDRs) possuem um mecanismo, designado Restrição de Integridade (RI), que assegura a definição de um esquema de dados. Quando definidas, as RI evitam um conjunto de problemas de qualidade dos dados [8], tal como apresentado em seguida: Not Null: Obriga que uma coluna esteja sempre preenchida. Por exemplo, todos os valores do campo telefone têm de estar sempre preenchidos; Unique e Primary Key: Evitam valores duplicados numa coluna. Existem dados que não fazem sentido como duplicados, pois identificam univocamente cada registo de uma tabela, como por exemplo o número do bilhete de identidade; Foreign Key: Evita que numa coluna de uma tabela existam valores que não existem numa coluna chave de outra tabela. Por exemplo: O campo identificador de um departamento é uma chave estrangeira na tabela dos empregados, ou seja, um empregado tem sempre um departamento associado que existe; Domain: Obriga que uma coluna tenha só valores que foram definidos nos metadados. Por exemplo, uma coluna que define o género de uma pessoa, só tem dois tipos definidos (F e M) não permitindo o preenchimento de outro valor que não seja um dos dois referidos; Check: Evita através de uma condição que sejam colocados valores numa tabela que vão contra da mesma. Por exemplo, a idade de um empregado deve ser maior do que 18 anos. Todos os valores que sejam inferiores a este valor não são permitidos; Default: Evita valores a null numa coluna, através da inserção de um valor predefinido, por exemplo, se a idade de um colaborador não for inserida o valor colocado será 18; Assertion: Evita através de uma condição que sejam colocados valores numa tabela ou várias que vão contra da mesma. Por exemplo, a soma de todos os empréstimos de uma filial tem de ser menor do que a soma dos valores de todas suas contas; 2

14 triggers: Obrigam a execução de determinados eventos, através de procedimentos que definem restrições de integridade e são executados antes ou depois de ocorrerem determinados eventos na base de dados. Por exemplo, a verificação do código do distribuidor de um filme se existe na tabela de Distribuidores antes de se inserir ou actualizar uma linha da tabela Filmes Problemas de qualidade de dados que não são evitados pelos SGBDRs Existem no entanto problemas com dados que não podem ser evitados através da definição de restrições de integridade suportados pelos SGBDRs. Estes problemas podem atingir registos isolados ou conjuntos de registos. Em termos de registos isolados, os problemas dizem respeito a uma só entidade do mundo real e são os seguintes [8] [9]: Falta de dados correctos: Existem colunas que estão definidas como sendo not null, logo é necessário preencher a coluna com um valor. Por vezes, o utilizador não dispõe destes valores, sendo levado a colocar um valor não correcto no registo. Por exemplo: O número do bilhete de identidade para um determinado cliente não foi preenchido, levando o utilizador a inserir o valor , para que o sistema não dê erro; Dados erróneos: Existem dados que são válidos, mas que não estão de acordo com a entidade no mundo real. Por exemplo: O atributo Idade de um empregado contém o valor trinta e um quando, na verdade, a sua idade real é trinta anos; Palavras mal escritas: São dados com erros de ortografia. Como por exemplo, o campo nome com um registo Mria ; Valores embebidos: São referentes a palavras que se adicionam aos campos mas que não fazem parte. O campo nome tem o seguinte valor: Presidente Jorge Sampaio. Neste exemplo, a palavra Presidente não deveria estar contida no nome da pessoa, pois o campo diz respeito ao nome de uma pessoa e não ao seu cargo na sociedade; Dados no campo errado: São todos os dados que são colocados em campos que não são os respectivos. Por exemplo, no campo cidade não pode existir um valor Espanha, porque o mesmo não é uma cidade mas sim um país; Dados ambíguos: Referem-se a dados que podem ter vários significados. Podem ser encontrados em abreviaturas ou em contextos incompletos. Por exemplo, o valor J. Guerra tanto pode ser interpretado como João Guerra ou como Joaquim Guerra. Outro exemplo poderá ser a palavra Cuba que pode ser entendida como sendo a vila de Portugal ou como o país da América Central; Categoria de dados errada: Diz respeito a um conjunto de valores que saem do intervalo de uma categoria. Tem-se como exemplo, o atributo país e cidade não fazem parte da mesma categoria; Os problemas de dados que afectam conjuntos de registos podem ser identificados numa só tabela ou em várias e são os seguintes: Registos aproximadamente duplicados: São registos escritos de uma forma um pouco diferente, mas que se referem a uma mesma entidade no mundo real. Exemplo: Empregado1 (Nome = Maria Simões, Morada = 223, praceta A, Lisboa, Aniversário = 01/01/1945 ) e Empregado2 3

15 (Nome = M. Simoes, Morada = 23, praceta A, Lx, Aniversário = 01/01/1945 ); Registos contraditórios: São registos que se referem à mesma entidade, mas que têm algo de contraditório na sua informação. Exemplo: Empregado1 (Nome = Maria Simões, Morada = 223, praceta A, Lisboa, Aniversário = 01/01/1945 ) e Empregado2 (Nome = M. Simoes, Morada = 23, praceta A, Lx, Aniversário = 01/01/1955 ), onde se pode verificar que existem datas de aniversário diferentes; Dados temporais não adequados: São dados que violam um intervalo de tempo. Por exemplo,o salário de um colaborador deve de deixar de estar disponível quando o mesmo o levanta por completo. Se isto não acontecer, então existe uma inconsistência a nível do tempo; Dados sem padrão: São todos os registos que usam representações diferentes, o que invalida a sua comparação. Como exemplos tem-se, o campo Nome com os valores: Ana Fernandes e Ferreira Cátia, que não usam a mesma regra de escrita. O uso de diferentes formatos de codificação, ASCII e UTF-8. Formatação da representação, 10.5 e 10.5; Unidades de medida inconsistentes: Existe uma falta de coerência na representação das unidades de medida utilizadas em diferentes valores de uma mesma coluna. Por exemplo, a distância entre localidades pode ser descrita num valor em quilómetros e noutro em milhas; Conflito de nomes: Existem nomes de atributos iguais mas com significado diferente, que são usados por diferentes tabelas de uma base de dados (homónimos), como por exemplo o atributo planta, que pode designar um ser vivo ou um desenho de uma habitação. Podem ainda existir atributos com nome diferente numa mesma tabela mas que dizem respeito à mesma entidade no mundo real (sinónimos), como é o caso do atributo Idade e do atributo Anos; Conflitos de estrutura: Existem diferentes representações de um mesmo objecto em base de dados distintas. Exemplo: Num registo tem-se a morada num só campo, e noutro a mesma está separada em vários campos Dimensões de qualidade de dados Raramente os dados manipulados por um SI de grande dimensão se podem classificar como sendo 100% de boa qualidade. O grande objectivo não é garantir que a qualidade seja perfeita, mas que seja suficiente para que a organização possa sobreviver e tomar decisões com base em dados fiáveis. Uma qualidade de dados elevada significa que os dados são adequados para serem usados pelos clientes, ou seja, um dado tem qualidade se satisfaz os requisitos desejados. Estes requisitos podem ser ditados por dimensões de qualidade de dados. Uma dimensão de qualidade de dados é uma característica que um dado deve conter, cada dimensão tem uma ou mais medidas para verificar se o dado detém ou não a dimensão em questão. Os dados para serem de qualidade devem de ser [10] [11] [12] [13] [4]: Precisos: A precisão é a característica que define o quão correctos, livres de erros e próximos do mundo real estão os dados. Para ser preciso, um valor deve ser certo e deve ser representado de uma forma consistente e sem ambiguidade. A precisão é a dimensão fundamental da qualidade de dados. Se um dado não é preciso, as outras dimensões são menos importantes; 4

16 Completos: A completude é a dimensão que caracteriza se os dados contêm todos os pormenores necessários ao negócio onde estão inseridos; Actualizados: A temporalidade permite verificar se os dados estão suficientemente actualizados para as tarefas que são precisos; Consistentes: A consistência é uma característica que afirma que um dado é consistente se o seu valor e se a sua estrutura têm sempre a mesma representação. A dimensão precisão pode ser dividida em duas partes: sintáctica e a semântica. A precisão sintáctica preocupa-se em avaliar se o valor em questão pertence ou não a um domínio. Por exemplo: o nome João é correcto, enquanto Jão não é um nome válido, pois não pertence a nenhum domínio de nomes de pessoas. Em relação à precisão semântica, esta preocupa-se com o verdadeiro sentido e valor dos dados no mundo real. Exemplo: filme1 (nome = Casablanca, Director = "Weir ) e filme2 (nome = Clube dos poetas mortos, Director = Curtiz ). Estes dois registos não são precisos semanticamente, pois têm os directores trocados. Do ponto de vista sintáctico estão correctos. Em relação à completude, esta dimensão pode ser dividida em três tipos: a nível do esquema, ao nível da coluna e a nível da população. Ao nível do esquema é necessário verificar se estão definidas todas as entidades e atributos precisos ao negócio. A nível da coluna, é necessário que não faltem valores na mesma. E a nível da população verifica que valores estão em falta para que a mesma fique completa, por exemplo, uma coluna deveria ter pelo menos a ocorrência de 50 países e no fim só tem 43, a população é considerada incompleta. A temporalidade é composta por um conjunto de dimensões relacionadas com o tempo que permitem verificar a idade dos dados, ou seja, se os mesmos são actualizados ou não com alguma frequência, se estão actuais, etc. A actualidade avalia a rapidez com que um estado do sistema é modificado depois de o sistema do mundo real ter mudado. Por exemplo: O Manuel fez 19 anos há um mês atrás e o sistema demora um mês a mudar o mesmo. A volatilidade preocupa-se com o intervalo de tempo com que um estado do sistema é modificado. Por exemplo: a data de nascimento de uma pessoa tem volatilidade 0, pois nunca deve mudar, a pessoa só nasce uma vez. Em contrapartida, o stock de supermercado muda frequentemente, logo terá uma volatilidade grande. A última dimensão do tempo enumerada é a intemporalidade que analisa se os dados estão disponíveis para serem usados numa determinada tarefa, ou seja, podem estar actuais mas serem inúteis, pois estão atrasados para um uso específico. Por exemplo: O horário de um curso de uma universidade, pode conter a que horas começa cada disciplina, mas se só é colocado no fim do semestre, é actual mas não foi utilizado quando preciso, ou seja, no início das aulas. Por fim, a consistência dos dados é avaliada através de restrições de integridade, onde todos os dados da BD devem obedecer as mesmas. Existem dois tipos: as restrições intra-relação e as restrições inter-relação. As primeiras podem olhar para um único atributo (restrições de domínio) ou para vários de uma relação. Uma restrição de domínio pode ser: A idade de uma pessoa está definida entre 0 e 120 anos. E uma restrição de integridade mais complexa, poderá ser: Se os anos de trabalho de uma pessoa são inferiores a 3 anos, então o salário não pode exceder um determinado valor por ano. Em relação às segundas restrições, estas preocupam-se com os diferentes tipos de dependências que 5

17 podem existir entre os dados, como o caso da dependência de chave (não há duplicados), dependência de inclusão (chave estrangeira) e dependência funcional Data Profiling A tarefa de Data Profiling (DP) é definida como uma das sub-actividades do processo de qualidade de dados. O processo de data profiling pretende detectar de forma sistemática, os erros, as inconsistências, as redundâncias e a existência de informação incompleta nos dados e respectivos metadados [2], [14], [15]. Depois de analisados os dados, o processo de DP deve produzir um conjunto de relatórios com informação sobre o estado dos dados. Com estes relatórios os analistas podem [16] [17]: Avaliar se os metadados descrevem exactamente os valores reais da base de dados. Por exemplo, um campo pode estar a ser definido como alfanumérico, quando deveria ser definido como numérico [18]; Ter uma ideia clara da qualidade dos dados. A informação contida nos relatórios, pode servir para saber se as dimensões da qualidade de dados estão a ser cumpridas ou não. Como por exemplo: a existência de muitos registos não preenchidos pode significar que o campo ou tabela não estão completos (dimensão completude); Corrigir os dados que têm problemas, através de uma ferramenta de limpeza de dados (Data Cleaning). Muitas ferramentas de DP geram regras para resolver alguns problemas detectados, para além de alertarem para um conjunto de erros que precisa de ser resolvido. É aconselhado fazer-se sempre o ciclo detecta, corrige, até que os resultados dos relatórios de DP sejam atingidos [19]; Equacionar a alteração dos requisitos da aplicação. Se ao analisar os dados, os erros que estão a ser detectados não fizerem sentido aos analistas, é provável que a aplicação não tenha sido bem desenhada, ou seja, a aplicação não está de acordo com os dados que estão na BD. Se a aplicação tem problemas é necessário rever os requisitos e os respectivos processos de negócio e se for necessário alteram-se os mesmos [1]; Avaliar o planeamento de um projecto. Se uma equipa compreender cedo os possíveis erros ou anomalias que podem estar nos dados de um projecto, pode evitar atrasos e os aumentos de custo no mesmo [6]. Para além de todas as vantagens enumeradas, o processo de data profiling, permite a qualquer analista compreender melhor o negócio do projecto onde está envolvido [18]. 1.3 Problema a Resolver Este trabalho foi realizado no Instituto Superior Técnico e na unidade de Business Intelligence da Link Consulting. O objectivo geral desta dissertação foi a realização de uma auditoria da qualidade de dados de uma base de dados relacional de cartões de clientes de operadores de transportes, que é denominada por BD_OT. A informação armazenada na BD_OT diz respeito aos clientes dos operadores de transporte públicos de uma determinada zona. As suas principais tabelas são: clientes, requisições 6

18 e cartões. Cada uma destas tabelas contêm aproximadamente dois milhões de registos. A tabela Clientes suporta os dados pessoais do cliente (nome, morada, etc.) e um conjunto de campos que são úteis à gestão dos mesmos, como por exemplo a data em que um cliente aderiu ao operador. A tabela Requisições contém informação relacionada com o tipo de requisição efectuada pelo cliente, qual o motivo para o pedido de uma requisição (exemplo: cartão caducado), o local onde foi pedida, e alguma informação pessoal referente ao cliente. Os registos da tabela Cartões contêm informação acerca do tipo físico de cartão, qual é a sua requisição e a que tipo de cliente pertence consoante a sua idade ou profissão. Como ponto de partida para a auditoria da BD, foi indicado o seguinte conjunto de problemas de dados detectados pelos utilizadores da aplicação, são eles: Clientes duplicados. Existem um conjunto de clientes que são ditos únicos, mas que na realidade dizem respeito a outro cliente existente na tabela. Por exemplo, cliente1 (Marco António, 19/10/1989, Rua Verde, n14) e cliente2 (MARCO A., 19/10/1989, R. verde, n o 14); Clientes mal consolidados. São todos os clientes que têm requisições pertencentes a outros clientes ou requisições com os dados pessoais do cliente errados; Números de documentos de identificação não normalizados. Existem identificadores de documentos que no geral são diferentes mas que na realidade são de um mesmo cliente, como por exemplo, o número de um bilhete de identidade ser e outro N ; Números de documentos de identificação inválidos. São todos os identificadores que não seguem o formato standard definido segundo o documento de identificação do cliente. Por exemplo, o identificador do bilhete de identidade é um número inteiro, positivo e sequencial, se existirem valores como jkj987676, estão errados; Data de nascimento inválida. Representa todas as datas de nascimento que não podem ser reais, devido ao intervalo de tempo normal para o nascimento de uma pessoa. Exemplo 2/09/2050, a pessoa ainda não nasceu devido ao ano de nascimento ser superior ao ano actual no mundo real; Data de emissão do documento de identificação inválida. São todas as datas que saíam do intervalo de tempo possível para a realização de um documento de identificação. Por exemplo todas as datas que não estão compreendidas no intervalo de anos [ ]; Data da requisição inválida. Existem requisições com datas inferiores a 2001, ano este em que o sistema de cartões começou a ser utilizado pela operadora em questão; Moradas não normalizadas. Existem clientes que têm a sua morada num só campo e outros que têm a mesma repartida por vários na BD; Códigos postais não existentes. São todos os códigos-postais que não fazem parte da lista disponibilizada pelos CTT, por exemplo ; Códigos postais incompletos. São códigos que existem mas que não estão completos, por exemplo 1900 ; inválido. São s que estão mal escritos e que são impossíveis de existir no mundo real, como por exemplo, o número um ser um válido; Campo sexo não preenchido (M/F). O campo Género do cliente, não tem os valores da sua coluna todos preenchidos; 7

19 Números de telemóvel ou telefone incompletos. São números que não têm na sua composição nove dígitos; Números de telemóvel ou telefone errados. São números de telefone ou telemóvel que não podem existir. Por exemplo, o número de telemóvel ser 21 ou o número de telefone ser 5 ; Modelo de cartão não compatível com idade do cliente. São todos os clientes que não têm um passe correspondente a sua idade, como por exemplo, existirem crianças com passes de idosos e vice-versa; N o de requisição inválido. São todas as requisições cujo número não obedecem ao formato OOPPPPPSSSSSSS, onde OO significa o código do operador, PPPPP o código do posto e SSSSSSSS é um número sequencial. Estes são alguns dos problemas que a BD_OT contém. Com base na metodologia de data profiling apresentada no Capítulo 3, irão ser detectados de forma rigorosa e sistemática a maior parte dos problemas que existem nas três tabelas referidas. 1.4 Tecnologia Existente A auditoria da qualidade de dados armazenados numa BD relacional pode ser efectuada através da realização de interrogações ad-hoc em SQL, utilizando aplicações como o SQL Navigator da Quest Software, SQL Server Management Studio da Microsoft ou o Sqlplus da Oracle, sabendo que uma auditoria realizada desta forma não detecta de uma forma rigorosa e sistemática todos os problemas existentes numa BD. Para que isto não aconteça utilizam-se ferramentas desenhadas segundo a metodologia de DP. Estas últimas, permitem ao analista verificar de uma forma sistemática e automática a maior parte dos problemas ou anomalias existentes numa determinada base de dados relacional. As ferramentas de DP estão normalmente incluídas nas soluções de Data Quality (DQ), sendo raramente comercializadas em separado. Segundo a classificação do quadrante mágico da Gartner de 2007 e 2008 [20] [21], em termos de ferramentas de Data Quality, as empresas leaders são Trillium Software, Business Objects, DataFlux, IBM e Informatica. Para mais informação sobre o lugares ocupados pelas empresas com soluções de Data Quality mais importantes do mercado, consultar o anexo 6.1. Para que se pudesse utilizar uma ou mais ferramentas de DP foi necessário saber o que existia no mercado. Desta forma realizou-se um estudo sobre que ferramentas comerciais e de distribuição livre que existiam hoje em dia. Este estudo pode ser visualizado no Capítulo 2, designado como estado da arte das ferramentas de DP. Deste estudo foram escolhidas as ferramentas de Data Quality da Oracle, porque: Já existiam na Link Consulting; Uma das ferramentas para DP disponibilizadas pela Oracle foi comprada à Trillium Software, uma das empresas leaders das ferramentas de DQ. 8

20 1.5 Solução A solução encontrada para efectuar a auditoria à qualidade dos dados da BD_OT, foi a aplicação sistemática de uma metodologia de data profiling utilizando a solução de DP da Oracle. As componentes da Oracle utilizadas foram as seguintes: Oracle Warehouse Builder (OWB) 10G Release 2, módulo data profiling e Oracle Database 10G Release 2; Oracle Data Quality for Data Integrator (ODI-DQ) 10G Release 3; SQL Navigator 5.0. para as interrogações que não foram possíveis de realizar nas duas ferramentas anteriores; LingPipe 3.5.1, Apache-ant-1.7.1, MySQL Server 5.0 e Navicat for MySQL, para detecção de anomalias que envolveram dicionários de palavras. 1.6 Contribuições As principais contribuições desta tese são as seguintes: Metodologia de data profiling, que dispõe exaustivamente todos os problemas de dados; Análise da qualidade de dados de uma base de dados de clientes de transportes públicos; Estado da arte das ferramentas comerciais e de distribuição livre, para data profiling; Avaliação do pacote de componentes de software da Oracle para data profiling, no que diz respeito à sua capacidade para executar as tarefas que compreendem a metodologia DP e o desempenho conseguido perante um conjunto de dados de grande dimensão. 1.7 Metodologia de Investigação Esta secção pretende dar a conhecer o método de trabalho adoptado e quais as etapas usadas na realização desta dissertação, este método de trabalho é explicado através da metodologia de investigação Estudo de Caso. Uma metodologia de investigação pode ser classificada como qualitativa ou quantitativa. O método qualitativo consiste em coleccionar, analisar e interpretar informação através da observação do objecto no seu local de acção. Assim sendo, o foco deste método está na descrição do objecto a analisar usando a interpretação e consequentemente a criação de teorias. Por outro lado, o método quantitativo consiste em usar um conjunto de questões com respostas pre-definidas para obter informação sobre o objecto em estudo. Esta informação extraída é mensurável e permite testar teorias, como exemplo tem-se os questionários. Nesta dissertação a escolha recaiu sobre o Estudo de Caso, pois trata-se da investigação de um objecto no seu ambiente real (método qualitativo). Esta metodologia permite abordar a problemática dos SI com foco no contexto organizacional onde esta se enquadra. A falha deste método está no facto de se limitar a uma única instância ou organização, dificultando a generalização dos resultados, para outras organizações. Qualquer metodologia tem no mínimo uma iteração. Uma iteração (etapa) é composta normalmente por três passos: 9