CALIDAD DE DATOS - Tercera entrega de un interesante tema

Ahora revisemos con mayor detalle el tema de la calidad de los datos en los desarrollos, ya he escrito dos artículos en los que he tratado el tema, pero ahora quiero embarrarme un poco las manos y presentar como estoy revisando mis propios desarrollos antes de liberarlos a un área de pruebas. Espero que este articulos les sea de mucha ayuda.

He estado revisando con mayor detalle algo muy interesante en la base de datos ORACE llamado Expresiones regulares, esto es algo que apareció desde la  versión 10g de su base de datos y potencialmente ofrece muchas bondades para la búsqueda de patrones.

Luego de revisar esto y viendo la necesidad de mejorar la calidad en mis programas de etl he decidido comenzar a trabajar fuertemente con las expresiones regulares y bueno algunos queries base que me ayuden a mejorar la calidad de mis desarrollos. Para comenzar las personas que no sepan mucho de expresiones regulares pueden revisar el siguiente artículo en español que escribio Fernando García en el sitio de Oracle que se da muy bueno para una introducción al tema: http://www.oracle.com/technetwork/es/articles/sql/expresiones-regulares-base-de-datos-1569340-esa.html. Para realizar consultas que nos ayuden a verificar la calidad de nuestros desarrollos es necesario que trabajemos en dos puntos separadamente:

 

1. Dimensiones
2. Tablas de Hechos

Se separan los temas porque cada una debe tener un especial cuidado a la hora de verificar su calidad, comencemos por las dimensiones y posteriormente revisemos las tablas de hechos.

1. Dimensiones

Para revisar que los datos de una dimensión hayan quedado correctamente lo primero que debemos verificar es la unicidad de la clave lógica, para esto hacemos un simple count que nos garantice que no exista registros que no sean únicos:

 

Select {llave_logica_dimension}, Count(1) C1 From {Tabla} Group By {llave_logica_dimension} Having Count(1) > 1;

Luego veamos si existe algún espacio en blanco en el campo (o campos) de la llave lógica, esto con una expresión Regular:

 

Select * From {Tabla} Where REGEXP_LIKE({llave_logica_dimension}, '*[ ]+*')

Si el campo es numérico otra validación que sirve es la siguiente (que comience por número):

Select * From {Tabla} Where Not REGEXP_LIKE({llave_logica_dimension}, '^[0-9]');

Otra importante validación es que no contenga caracteres invalidos o extraños como *, $, %, &, etc:

Select * From {Tabla} Where REGEXP_LIKE({llave_logica_dimension}, '^[0-9 || a-f]');

Validar que la clave subrogada se este llenando bien:

Select * From {Tabla} Where {clave_subrogada} is not null;

Select * From {Tabla} Where REGEXP_LIKE({clave_subrogada}, '*[ ]+*');

Vamos a ir mejorando e incrementando las consultas para validar datos de las dimensiones a medida que se vayan descubriendo mas consultas para certificar la calidad de los ETL's. Ahora veamos lo que tenemos para las tablas de Hechos.

 

2. Tablas de Hechos

Para realizar las pruebas en las tablas de hechos es muy importante tres factores:

 

1. Suma de Valores cuadren: Cuando se tienen valores monetarios en la tabla de hechos es muy importante tener un dato de referencia con el cual se debe realizar el cuadre de información, esto es que tomando la información sumada desde la fuente, sea igual a la información cargada en la tabla de hechos y que este valor sea aprobado por el usuarios. Incluso por ser algo tan genérico es común que una porción del código del etl se construya este cuadre de manera automática y en caso de encontrar diferencias, falle.
2. Conteo de registros: Es un poquito menos importante que el anterior pero que puede ser importante, es el conteo de los registros. Suele pasar que el conteo de registros de la fuente sea igual al de la tabla de hechos, si no se hace una operación de agregación sobre el programa o query que lleva la información a la tabla de hechos, cuando se cumple que los registros son iguales, es factible también automatizar esta condición. 
3. Valores por defecto: Asumiendo que todas las dimensiones deben existir para luego proceder a construir las tablas de hechos, suele suceder que se encuentren valores en nulo. Como es importante el cuadre de valores, no se pueden eliminar registros de la tabla de hechos, por el contrario lo que se debe hacer es llevar dichos registros y poner un dato comodín o por defecto en el campo que se encuentre vacio para que nos cuadren las cifras y lluego se puede proceder a revisar el porque de la falta de los datos.

Adicional a estas tres validaciones de las tablas de hechos, existen validaciones adicionales que se irán adicionando en esta entrada en un futuro.