Qualidade de Dados / Data Quality

Quanto à normalização é um processo que requer cuidados específicos, especialmente se estivermos a tratar registos sensíveis. Quando digo sensíveis, refiro-me a registos de clientes e/ou de fornecedores, que não devem ser confundidos com outros, apenas porque têm um nome parecido ou porque moram por vezes na mesma casa, mas são pai e filho. Se tivermos na nossa BD dois registos com ligeiras diferenças, mas que não sejam diferenciadoras para ficarmos com a certeza se são realmente dois registos distintos, ou que são realmente duplicados, na grande maioria dos casos o melhor é deixar os dois duplicados assinalados, para que o departamento competente possa fazer a respectiva validação.

Mas existem casos em as duvidas na deduplicação são aceites como duplicados, como por exemplo, se tivermos um envio de uma peça publicitária, mas apenas existem peças suficientes para 75% dos clientes, uma das soluções pode ser a remoção do envio precisamente destas registos duvidosos. Os softwares de deduplicação, têm precisamente esta capacidade de ajustar conforme o necessário com aumento/diminuição dos pesos, para que se possa ter a deduplicação pretendida. Existem deduplicações predefinidas, mas cada BD tem as características próprias e são essas características que muitas vezes têm de ser contempladas nos ajustes para que se consiga os melhores resultados. A perfeição nestes casos não existe, quando estamos a tratar milhões de registos, porque se por um lado podemos estar a deixar duplicados não identificados, se alterarmos os ajustes poderemos estar a dar como duplicados registos que não são duplicados, como tal, o que recomendo é ter uma deduplicação que seja "segura", que não esteja a identificar falsos duplicados e deixar a indicação da deduplicação mais apertada, alertando assim para deduplicações mais duvidosas, mas que podem ser resolvidas num posterior contacto com o cliente.

Uma deduplicação sempre importante é a deduplicação por household.

É possível ter a(s) nossa(s) bases de dados com qualidade de dados, mantendo acesso às mesmas e com elevada qualidade de dados, poupando dinheiro?

A primeira pergunta a ser feita caso existam várias Bases de dados, é se é necessário coexistirem essas diferentes Bases de dados e se não será vantajoso fazer uma integração. É sempre mais fácil de manter uma base de dados que muitas, sendo que em alguns casos os dados são coincidentes. Se tivermos duas bases de dados com dados dos nossos clientes e sejamos informados da alteração de morada, o mais certo é que essa alteração apenas seja feita em uma das bd's. Caso os dados estejam integrados, normalizados e deduplicados isso já não acontece. É tempo que não se perde e é a qualidade das BD's que aumenta por estarem sempre com os registos actualizados.

Depois desta integração ser ou não executada, uma vez que pode ser executada em service bureau e reintegrada nos moldes actuais, existem outras questões que convém estarem bem presentes, especialmente nos tempos de contenção de despesas que estamos a viver. É necessário manter uma estrutura interna para manter as bases de dados? Em muitos casos estamos a falar não apenas de servidores, como de recursos humanos que estão muitas vezes parcialmente alocados a este área, mas por norma não têm tempo, nem conhecimentos, nem as ferramentas para manterem uma BD com qualidade. Como tal a melhor opção é entregar a BD a uma empresa especializada.

Actualmente e com a velocidade que se consegue ter nas ligações de Internet, é possível ter acesso à BD quase como se estivesse dentro da própria rede da empresa. Com isto e através de web services consegue-se desenvolver programas que permitam ter acesso remoto, não apenas pelos meios tradicionais, mas permite ainda colocar os novos meios a comunicar com a BD. Nestes novos meios estou a falar por exemplo dos smartphones.

Tudo isto incluído pode ser desenvolvido à medida das especificidades de cada uma das empresas, com um custo que é certamente muito inferior ao custo que se tem em manter as BD's dentro da organização. Em muitos casos sem qualquer custo inicial de desenvolvimento/adaptação de plataformas. Usando assim as novas possibilidades de Saas.

Hoje em dia já existem várias hipóteses para que se possa assegurar a manutenção da qualidade dos dados em níveis elevados. Não apenas com a compra das mais avançadas ferramentas de qualidade de dados, mas igualmente adoptando as mais modernas e económicas versões de Saas. Dependendo do numero de registos a serem tratados, existem inúmeras hipóteses: desde a compra da normalização de um valor predeterminado de registos, quer sejam 10.000 anuais quer sejam muitos milhões. Tudo isto num "tratamento" que é feito no momento mais importante de qualquer operação que envolve dados. O momento da inserção/alteração/modificação.

Imaginemos que na inserção de um registo é colocado apenas "Liberdade, 14 3 Esq" e que nessa cidade existem a Rua a Travessa e o Largo da Liberdade. Este registo muito dificilmente ficará correcto na Base de dados. Sendo que o mais certo é que venha a trazer custos para a empresa com a devolução de toda a correspondência que for enviada. Por outro lado e mesmo que seja feito um trabalho de ETL em cima desta BD, não há software nenhum que possa normalizar esta rua e caso algum o faça tem apenas 33% de hipóteses de acertar na "correcção". Mas por norma é assinalado e não é corrigido.

Tudo isto poderia ser evitado, caso no momento de inserção dos dados o utilizador recebesse uma mensagem que dissesse: "Existem 3 hipóteses de normalização: Rua da Liberdade, Travessa da Liberdade e Largo da Liberdade". Com estas hipóteses e com a possibilidade de perguntar directamente ao cliente, caso estejamos a falar de um Call Center, ou de um atendimento directo ao publico, o problema seria de imediato resolvido.

Neste caso estamos mais uma vez a falar de moradas, mas o mesmo se aplica relativamente aos duplicados e a muitos outros campos em que temos erros mais ou menos frequentes, mas que estão certamente identificados. Sempre que um determinado erro frequente ocorra há a hipótese de criar um alerta para que imediatamente se possa resolver o problema.

Na grande maioria dos casos os projectos de limpeza de dados ou qualidade de dados, são projectos simples de ETL, em que existem várias abordagens.

Há projectos que são "simples". É feita a Extracção dos dados, o seu tratamento (Transform) e posteriormente o seu carregamento em BD (Load). Com estes projectos há uma aproximação a uma verdadeira qualidade de dados, mas se "olharem" com mais atenção vão verificar que na realidade, os dados nunca chegaram realmente a ficar limpos nos valores que são apresentados. Estes processos de ETL demoram algum tempo, e durante esse tempo, alguns dos dados que estão a ser tratados, estão a ser alterados pelos utilizadores. Ou seja, quando a BD é reposta, esses dados para alem de não poderem ser carregados, as alterações que entretanto foram efectuadas trouxeram mais "lixo" para o sistema.

E depois? Na semana seguinte a este projecto há novos dados, alterações e todo um conjunto de processos que fazem os dados voltar ao seu estado de falta de qualidade.

Existem outras abordagens, que já vi serem implementadas por grandes empresas em Portugal, que são ainda mais chocantes, que é a execução de projectos de ETL de forma progressiva. Ou seja, primeiro por exemplo tratam os registos que têm o código postal 1000. Depois os 1050 e assim sucessivamente. Este processo apenas permite que uma empresa fique eternamente a fazer a limpeza de dados, porque quando chegam ao fim do processo, estão os dados iniciais já totalmente "sujos". Apenas continuam o processo Ad aeternum.

Os processos ETL devem ser o principio de qualquer projecto de qualidade de dados. Durante o processo de ETL deve ser implementada uma solução online que permita a manutenção dos dados actualizados, evitando assim estar sempre a implementar processos ETL, com os elevados custos inerentes.

Aqui podem ver uma demonstração de como podem funcionar estas aplicações que em termos de moradas evitam a entrada de "lixo" para o sistema.