Qualidade de Dados / Data Quality

Depois de ter no post anterior feito um resumo não apenas dos ambientes, mas também das plataformas em que as ferramentas de qualidade de dados podem assentar, vou agora aprofundar um pouco mais as vantagens destes sistemas.

Como se pode ver na imagem, as ferramentas estão disponíveis em praticamente todos as plataformas e ambientes disponíveis no mercado.

Estas aplicações em nada vão interferir com o já existente e desenvolvido na actual estrutura de qualquer empresa, mas apenas vem acrescentar processos que para alem de facilitarem o dia a dia do utilizador, ainda e principalmente permitem que se possa garantir uma constante manutenção da qualidade dos dados.

Como já tinha referido em anteriores posts, estas ferramentas, permitem que mesmo depois de um processo de ETL, a qualidade seja mantida em níveis muito acima do que é normal. Depois de terminado um processo de ETL o normal é que no dia seguinte a serem integrados os dados já tratados, se inicie um processo de contaminação que apenas vai ser "corrigido" num posterior processo de ETL.

Com estas ferramentas isso é evitado uma vez que cada um dos dados que é inserido ou alterado, passa pelos "filtros" que permitem que a qualidade se mantenha, ou até em muitos casos se possa incrementar.

Se no processo de ETL houve dúvidas em alguns registos que não foram alterados por não se ter a certeza da correcção, com estes sistemas de "firewall" permite que quando se fizer uma alteração a um desses registos se possa finalmente corrigir esse registo.

Vamos a um caso prático, se por exemplo numa BD temos dois registos em que as diferenças são mínimas, ou seja há uma dúvida se são ou não duplicados, num posterior processo em que alguém dentro da organização tenha essa pessoa ao telefone, é possível dissipar essa dúvida.

Estes são alguns dos motivos pelos quais estas ferramentas que actuam nos momentos mais fulcrais dentro de qualquer organização são tão importantes e cada vez mais essenciais, uma vez que todos os departamentos dentro das empresas hoje em dia, de uma forma ou de outra dependem dos dados. Se não houver qualidade nos dados, certamente que sempre haverá problemas que possam ocorrer em qualquer um dos processos diários.

Os produtos estão disponíveis nas seguintes plataformas:

Windows

• Como um cliente sob as versões 2000, XP e Vista.
• Interfaces e exemplos para todas as linguagens de desenvolvimento e tecnologias de ligação geralmente utilizados no ambiente Windows estão disponíveis para integração em aplicações in-house. Exemplos: C, C + +, Cobol, Visual Basic, Perl, Java, COM, PHP, CORBA, ABAP (SAP), PL / SQL (Oracle ®).
• Tal como um servidor sob as versões 2000, 2003 e 2008, em colaboração com todas as bases de dados geralmente utilizados no ambiente Windows, por exemplo, Oracle ®, DB / 2 ou SQL Server.

UNIX

• Com os derivados do sistema operacional HP-UX, AIX, Sun Solaris, Linux.
• Como servidor e como cliente para todos os derivados do UNIX acima indicado, em colaboração com todos as bases de dados geralmente utilizados no ambiente UNIX, por exemplo, Oracle ®, DB / 2 ou SQL Server.
• Interfaces e exemplos para todas as linguagens de desenvolvimento e tecnologias de ligação geralmente utilizados no ambiente UNIX estão disponíveis para integração em aplicações in-house. Exemplos: C, C + +, Cobol, Perl, Java, COM, PHP, CORBA, ABAP (SAP), PL / SQL (Oracle).

iSeries (AS/400)

• Com o sistema operacional i5/OS.
• Como servidor e como cliente, em colaboração com a base de dados i5/OS.
• Tanto os interfaces clássicos com exemplos para a linguagem de programação RPG, bem como para chamar de programas Cobol, C ou Java estão disponíveis para integração em aplicações in-house.

Mainframe

• Com o sistema operacional IBM z / OS (ex-MVS), VSE e Siemens BS2000.
• Como um servidor de aplicações mainframe, tanto em batch e em aplicações interactivas no âmbito da operação monitorização CICS, IMS e UTM, em colaboração com todas as bases de dados de mainframe usadas geralmente, como o DB / 2, / IMS DB, ADABAS ou UDS.
• Interfaces e exemplos para todos os "clássicos" de desenvolvimento, tais como línguas mainframe Cobol, Assembler e PL / 1, bem como chamar de programas C ou Java está disponíveis para integração em aplicações in-house.

Por algumas reacções que obtive relativamente ao post Ferramentas de qualidade de dados em Portugal, acho que devo evidenciar as diferenças entre uma normalização, que certamente é parte integrante dos processos de qualidade de dados, mas apenas uma pequena parte e um processo completo de qualidade de dados. Diria mesmo que é a parte mais simples, caso as fases que considero primordiais tenham obtido sucesso.

Para melhor poder mostrar a diferença entre uma normalização e um processo completo de qualidade de dados, vamos dar alguns exemplos. Imaginemos que temos a seguinte BD para tratamento.
Ant Sousa Mendes; R. frenando Diaz, 4 3º Direito; 1000 Lisboa
Man Jose Tavares; Aven. Fern Diaz, 5 6 Es; 1100-000 Lisvoa
Mª Jaão Tavares; Av Fernado Dias, 5 6ª ESQUERDO; 1100-199 LISBOA

Se em cima destes dados for feito um trabalho de normalização e dependendo das regras que forem definidas, o resultado final será qualquer coisa como:
António Sousa Mendes; Rua Frenando Diaz, 4 3º Dto; 1000 Lisboa
Manuel José Tavares; Avenida Fernando Diaz, 5 6º Esq; 1100-000 Lisvoa
Maria João Tavares; Avenida Fernado Dias, 5 6º Esq; 1100-199 Lisboa

Mas como se podem ver existem erros que persistem, com um processo de qualidade de dados mais completo facilmente conseguiríamos os seguintes resultados:
António Sousa Mendes; Avenida Fernando Dias, 4 3º Dto; Lisboa; 1100-199 LISBOA
Manuel José Tavares; Avenida Fernando Dias, 5 6º Esq; Lisboa; 1100-199 LISBOA
Maria João Tavares; Avenida Fernando Dias, 5 6º Esq; Lisboa; 1100-199 LISBOA

Não apenas temos as ruas TOTALMENTE normalizadas e confirmadas, como temos sempre o código postal completo com as 7 posições correctas.

Esta pode ser a diferença entre conseguirmos encontrar ou não alguns dos registos duplicados. E quando falamos em duplicados tanto podem ser duplicados por household, como seria aqui o caso ou mesmo indivíduos duplicados.

Espero que tenha sido um pouco mais esclarecedor, que um processo de normalização, com maior ou menor dificuldade, se consegue fazer sem grandes problemas. Mas por outro lado um processo completo de qualidade de dados já não é assim tão simples de ter bons resultados. Para se conseguirem valores elevados de qualidade de dados, necessitamos não apenas de uma ferramenta poderosa, mas também de um ficheiro de arruamentos que o consiga acompanhar. Como sabemos em Portugal, mesmo em termos cartográficos, não temos o levantamento total do país. E estamos a falar de uma área muito activa, mas neste momento temos um street file que nos permite ter qualidade de dados de 93%, o que é excelente não apenas em Portugal, como em qualquer parte do mundo.

O que é necessário para uma integração de dados?

O primeiro passo para que se possa fazer a integração de dados provenientes de diferentes bases de dados, é a normalização dos mesmos para que se possa fazer o segundo passo com maior segurança. Esse segundo passo será a deduplicação, mas antes de passarmos a essa fase, vamos focar um pouco mais na normalização.

Para que serve essa normalização? Essa normalização serve acima de tudo para dar consistência aos dados. Os dados provenientes de fontes diferentes, muitas vezes mesmo de origens totalmente distintas, têm especificidades próprias. Com esta normalização o que se pretende é criar uma uniformização, sempre importante, mas também para que se consiga ter melhores resultados na deduplicação. Existem softwares que permitem ir um pouco mais alem nesta normalização e permitem ainda fazer a validação e correcção dos dados. Com isto temos a certeza que o nomes estão correctos, quer sejam os nomes das pessoas, como os nomes das ruas. É importante que os dados fiquem normalizados, mas também é importante que não se percam dados/informações neste processo.

De seguida e tal como foi referenciado, passamos à fase da deduplicação. Nesta fase, sempre complicada, pode ter sido um pouco facilitada pelo trabalho feito na fase anterior. Se um registo por exemplo tiver um nome como Nantónio Santos, R Prof Dr Zé Ninguem, 14 3 Esquerdo e num outro registos duplicado tivermos António Santos, Rua Professor Doutor José Ninguem, 14 3 Esq as diferenças são muitas e como tal o resultado percentual em termos de deduplicação pode ser inferior ao valor mínimo que foi definido como mínimo para serem considerados como duplicados. Isto seria evitado com um trabalho anterior de normalização/verificação/correcção.

Depois de encontrados os grupos de duplicados, temos ainda a terceira fase de complementarização. Logicamente que entre cada um destes processos tem de haver um trabalho de verificação de resultados. Neste processo pode obrigar-nos a voltar a um nível anterior devido aos erros/problemas que se possam encontrar.

No processo de complementarização o que é feito é agrupar os dados/informações que possam estar espalhados pelos diferentes duplicados, "criando" assim um registo com toda a informação. Imaginemos que temos um registo em que existem os dados do nome, morada e telefone em outro registo para alem destes dados existem ainda os dados do telemóvel e do email. O que se pretende é que no fim se tenha um registo apenas com todas as informações espalhadas pelos diferentes duplicados que possam existir.

No fim deste processo temos uma BD com qualidade, em que temos uma certeza maior não apenas por exemplo do numero dos clientes, coisa que provavelmente muitas empresas em Portugal não conseguem ter a certeza, mas por outro lado uma base de dados que permite dar uma maior confiança em termos da qualidade dos dados. Consegue-se assim também ter uma melhor visão de cada um dos clientes, uma vez que os seus dados estão agregados e desta forma aquilo que se pensava serem dois clientes médios, é afinal um dos melhores clientes da empresa, tudo isto porque se estavam a dar entrada das encomendas em dois registos diferentes.

Existem algumas ferramentas de qualidade de dados que dizem funcionar em Portugal. Algumas dizem ser muito avançadas por terem um dicionário de sinónimos com muitos milhões de entradas. Outras dizem que têm ferramentas internacionais que funcionam para Portugal, apenas necessitam de pequenos ajustamentos consoante a BD a tratar. Mas na realidade quais a diferenças entre as ferramentas existentes no mercado Português?

Vamos por partes, as que referi em primeiro lugar, são ferramentas que facilmente se percebe as suas limitações. Todos sabemos que a quantidade de erros que é possível dar é totalmente ilimitada. Ou seja por cada BD que seja tratada, certamente que novas "versões" das diferentes ruas vão ser criadas. Isto apenas para referir as já existentes. Porque se houver um trabalho de actualização com novas ruas e alterações de ruas, todo um histórico de "versões" de erros tem de ser criado. Nunca se conseguem grandes resultados com estas ferramentas, porque simplesmente as actualizações são diárias e virtualmente infinitas.

Depois existem ainda outras de origem normalmente Americana ou Anglo-Saxónica e às quais foi "anexado" um street file (ficheiro com os arruamentos) e que supostamente, trabalham sem problemas. Aqui temos um outro problema, que são as especificidades de um país como Portugal. Nestes mercados não existem a Rua, Travessa, Largo e Beco da Liberdade, tudo na mesma cidade. Logo aqui em muitos casos existem problemas na identificação/normalização das ruas.

Conheço este problema muito bem porque há pouco mais de 10 anos, andei a fazer um estudo para a "importação" de ferramentas disponíveis no mercado internacional e foram estes alguns dos problemas com que me deparei e hoje mais de 10 anos depois, continuam actuais como nesse tempo.

Então no final qual a solução?

A solução é um misto das duas, ou seja uma ferramenta que consiga "gerar" automaticamente esse histórico de erros, contando com mais de uma dezena de algoritmos internos, entre os quais o fuzzy logic, Patricia structure, Levenshtein distance e muitos outros, mas que por outro lado esteja adaptado ao mercado Português. Essa adaptação demorou quase dois anos, mas os resultados finais que conseguimos obter falam por si.

A confiança neste software é tão grande que o disponibilizamos na internet para que se possa testar. Mais nenhum outro está disponível desta forma e isso diz um pouco da confiança que se tem nos produtos. Para comprovar o que digo basta fazer um teste aqui, onde podem testar com uma morada com erros e por exemplo apenas com o código postal de 4 dígitos.

É 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.