Data Quality: Como está a qualidade dos nossos dados?
Carlos Caldo
Imagine:
Mesmo pagando a fatura, você recebe pela terceira vez aquela indesejável carta de cobrança de seu cartão de crédito. Prontamente, mas irritado, você liga apara central de atendimento ao cliente e o atendente lhe diz:
-Sinto muito senhor, consta em nosso sistema que a fatura esta em aberto.
Após muitas ligações e explicações a operadora do cartão reconhece que foi um erro do sistema. Cansado pelo transtorno você solicita o cancelamento do cartão...
Mais um Cliente perdeu a paciência...
Mais uma Empresa perdeu um Cliente...
E tudo porque os DADOS estavam errados!
Mas como isso ocorreu? Que tipo de erro os dados apresentavam? Como podem os dados armazenados estarem incorretos?
Bem, para respondermos a estas perguntas teríamos que analisar minuciosamente o universo de dados do cenário acima e para isto entraríamos no terreno denominado de Data Quality.
O leitor pode agora estar com uma série de perguntas na mente. Vamos tentar respondê-las.
Caldo, o que é Data Quality?
Em minha opinião existe uma visão minimalista sobre Data Quality, pois a maioria das organizações associa o termo única e exclusivamente a uma Ferramenta. Data Quality pode e deve ser visto como algo maior, ou seja, um conjunto de processos que visa garantir que os dados armazenados sejam:
- Corretos;
- Precisos;
- Consistentes;
- Completos;
- Integrados;
- Aderentes às regras de negócio;
- Aderentes aos domínios estabelecidos.
Estes processos devem abranger desde a identificação de problemas com os dados e sua classificação até a correção dos valores e a posterior monitoração, ou seja, identificamos aquilo que denominamos de dados “sujos” e promovemos, dentro do possível, a “limpeza” dos mesmos. Depois monitoramos para verificar se erros não estão sendo introduzidos novamente. Em outras palavras: Seguimos os princípios de TQM (Total Quality Management): ANALISAR, MEDIR E MELHORAR.
Mas o que podemos entender por dados “sujos”?
São aqueles dados armazenados que estão inconsistentes. Podemos classificar estes dados em categorias, vamos citar algumas, utilizando nomes de Tabelas e Colunas hipotéticos:
Valores Default DUMMY: Quando encontramos Defaults para os valores de colunas ou campos obrigatórios.
Exemplo: CPF com 999.999.999-9
Valores Default “INTELIGENTES”: Quando os Defaults possuem significado. Exemplo: Se a coluna IDADE contiver 000 o cliente é corporativo!
Valores contraditórios: Quando os valores de uma coluna ou campo são inconsistentes com os valores de outra coluna ou campo relacionado.
Exemplo:
Na Tabela de CLIENTES determinada linha possui os seguintes valores:
Coluna CEP: 031085-020
Coluna Endereço: Rua Amazonas;
Todavia, na Tabela de CEPs este CEP não é da rua Amazonas!
Violação de Regras de Negócio: Quando o encontramos um valor de uma coluna ou campo que não está aderente a uma regra de negócio.
Exemplo: Se na Tabela de CONTRATOS a coluna TIPO-DE-CONTRATO conter o valor ‘VIP’ e a coluna DATA-DO-CONTRATO for inferior a ’01.012006’ o valor da coluna PERCENTUAL-TAXA-DE-JURO deve ser inferior a 4. Todavia, encontramos em uma linha da Tabela que obedece a regra, mas a coluna taxa de juro está com o valor 6!
Valores em desacordo com o domínio: Quando os valores de uma coluna ou campo não obedecem ao domínio estabelecido.
Exemplo: Na Tabela de FUNCIONARIO a coluna SITUACAO-DO-FUNCIONARIO deve conter os seguintes valores: ‘ATIVO’, ‘INATIVO’,’DEMITIDO’. Todavia, encontramos em uma linha da Tabela que possui uma situação igual a ‘AFASTADO!
Estas são algumas categorias, porém a lista é um pouco maior.
Entendi, mas como implementar os processos de Data Quality?
Bem, como respondi na primeira pergunta, Data Quality não é somente uma Ferramenta. Portanto, é necessário especificar formalmente o conjunto de processos, com suas entradas, atividades, itens regulatórios, itens de suporte, e suas saídas. Com os processos definidos, podemos depois avaliar com maior precisão uma ferramenta que seja aderente às necessidades da organização.
Numa visão geral, a arquitetura de processos teria o seguinte contexto:
Arquitetura de Processos de Data Quality: Cada retângulo representa um processo a ser especificado detalhadamente.
Poderia falar um pouco mais sobre os processos centrais?
Vamos a uma visão geral sobre eles:
Analise dos Dados (Profiling): Varre a base de dados e apresenta como estão os dados, ou seja, é o retrato daquilo que existe armazenado.
Por exemplo, em um relatório de distribuição de freqüência poderíamos ter:
Na tabela de CLIENTE a coluna sexo apresenta os seguintes valores armazenados:
1000 linhas com ‘M’
2000 linhas com ‘F’
200 LINHAS COM ‘X’
Auditoria (Audit): Com base no conhecimento daquilo que existe, especifica-se, para efeito de validação e medição, aquilo que deveria existir.
Por exemplo:
Na Tabela CLIENTE a coluna sexo deveria conter somente os valores ‘M’ e ‘F’
Correção (Cleansing): Promover a “limpeza” dos dados inconsistentes. Claro que após recebermos os Relatórios de auditoria deve ser feita uma análise de impacto para sabermos aquilo que podemos corrigir. Não raro, corrigimos aquilo que consideramos critico para o funcionamento do negócio, deixando a correção de alguns erros para momento oportuno.
Além dos processos acima citados, temos o de Monitoração que consiste em realizar auditorias periódicas (após a Correção) para verificar como está a qualidade dos dados. Através do processo de Monitoração conseguimos, inclusive, apresentar relatórios com Indicadores de Qualidade que permitem uma visão sobre a melhoria da qualidade de determinada Base de Dados: Estamos melhorando ou piorando?
Caldo, e quanto ao Checklist de Avaliação de Qualidade de Dados?
Esta é uma peça fundamental para que os processos centrais possam ser executados. Neste Checklist definimos os quesitos de qualidade de dados.
Quando vamos executar uma Auditoria na Qualidade dos Dados seguimos este Checklist, ou seja, se, por exemplo, as Tabelas de determinada Base de Dados estão em conformidade com os quesitos de qualidade tudo está bem, se não, identificamos onde e o que está com problemas.
Validade de Domínios, Integridade estrutural e de Regras de Negócio são alguns exemplos de quesitos de Qualidade de Dados. Porém, quando definimos este Checklist para uma Empresa efetuamos adaptações na nomenclatura dos quesitos, bem como adicionamos alguns e retiramos outros, em relação aos quesitos normalmente conhecidos no mercado.
Na arquitetura o processo de aquisição de Ferramenta. Poderia recomendar alguma?
Existem várias ferramentas disponíveis no mercado e cada empresa deve promover uma avaliação que valide se a ferramenta atende as necessidades dos processos Regulatórios e Centrais. Entretanto, podemos apenas dizer que estamos trabalhando em projetos que utilizam alguns produtos da suíte de Data Quality da IBM:
Ø WebSphere ProfileStage
Ø WebSphere AuditStage
Ø WebSphere QualityStage
Ø WebSphere DataStage
Em nossa análise os produtos atendem plenamente as necessidades dos processos de Data Quality e possuem ótimo desempenho para tratamento de grandes volumes de dados.
Conclusão:
Neste pequeno artigo não temos a pretensão de esgotar o assunto Data Quality, mas apenas sensibilizar o amigo leitor, quanto à importância de se entender claramente a amplitude deste tema.
Em tempo, gostaria de recordar que dados incorretos acarretam, entre outros problemas:
Ø Retrabalho para efetuar correções (custo com recursos e tempo extra!);
Ø Perda de oportunidades de negócios e clientes;
Ø Risco de Imagem;
Ø Multas por não cumprimento de normas regulatórias.
Para encerrarmos deixo uma pequena reflexão:
Será que as razões acima não são suficientes para que nossas empresas empreendam, rapidamente, iniciativas de Data Quality?
Um grande abraço a todos e até o próximo artigo!
