Recomendaciones para entregar Informacin con Calidad de Bases de Datos

Versin 1.0 Agosto 2013

Pgina 1 de 7

Tabla de Contenido
Antecedentes. . . . Recomendaciones. . . . Revisar Layouts. . . . Valores Fuera de Rango. . . Estandarizar. . . . Valores contra Catlogo. . . Nulos. . . . . . Parsear. . . . Fechas Vlidas. . . . RFCs Vlidos. . . . CURPs Validas. . . . Encabezados. . . . Anlisis de frecuencias y tendencias. Desduplicar. . . . Cifras de Control. . . . Matriz-Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 3 4 4 4 4 5 5 5 6 7 7 7 8

Pgina 2 de 7

Antecedentes Para conformar un nico resultado se requiere del esfuerzo de la amalgama de diversas fuentes, y esto implica que los datos pueden estar duplicados o no ser homogneos, motivo por el cual se recomiendan las siguientes acciones para entregar informacin con un grado de calidad ms alto. Recomendaciones El presente documento expone una serie de actividades que mejorarn significativamente la calidad de la informacin final, dichas acciones son propensas a sufrir mejoras y dependiendo la informacin a tratar, algunas de ellas pueden no aplicar; de igual manera, se pueden proponer ms actividades que persigan el mismo fin. Todas estas actividades deben ser efectuadas antes de una entrega oficial por parte de la institucin. La diversidad de los datos es inmensa, por lo que en este documento las recomendaciones se exponen de manera genrica, quedando a cargo de la junta de gobierno (alta direccin), la redefinicin o aclaracin de reglas a aplicar para la mejora de los datos. Revisar Layouts Los diccionarios de datos (layouts, FDs estructuras, etc.) deben ser claros, tanto en su origen como en el destino en el que sern entregados, bajo ninguno motivo se deber modificar la estructura de entrega solicitada sin previo aviso a la junta directiva. En caso de requerir adicionar o eliminar campos, se debern informar la necesidad de manera clara. Si los diccionarios de salida no existen, la junta de gobierno deber definir los mismos. Es importante respetar los nombres lgicos y fsicos (en caso de existir) de los layouts, as como respetar el orden de los campos solicitados y con el tipo de datos solicitado. EJEMPLO: En el layout solicitado no existe identificador de registro, si se desea agregar, se deber explicar porque la necesidad. Valores Fuera de Rango Los layouts o modelos de datos a entregar debern especificar que valores son permitidos para cada campo, en caso de existir valores no permitidos, se debern corregir o preguntar a la junta directiva que acciones se debern tomar para dichos valores. EJEMPLO: Valores permitidos para el campo ao de nacimiento: de 1900 a 2013, y en el campo se encontraron aos: 9999 o 0000, se debern corregir, o convertir a nulos, de acuerdo con lo que se defina en la junta directiva. Estandarizar La duplicidad de registros depende en gran parte porque la informacin no se encuentra estandarizada, para ello se requieren de procesos de Data Quality que ayuden en la homologacin de valores repetitivos en los campos. EJEMPLO:
Pgina 3 de 7

El campo Pas de Nacimiento puede contener valores como: MEXICANA, MEXICANO, MEXICO, MEX, etctera, y todos se refieren a la misma entidad, en caso de contar con un catlogo de pases o una regla que lo defina, la junta directiva deber definir qu valor ser NICO para homologar al resto. Valores contra Catlogo Para el caso de los campos que provengan de o se cuenten con catlogo, se deber validar la integridad referencial, esto es, los valores que no existan en catlogo, se debern corregir y si no se pueden corregir, o no estn dentro del catlogo, se deber solicitar definicin para dichos valores por parte de la junta directiva. EJEMPLO: Se cuenta con un catlogo para Municipios, sin embargo, los municipios son propensos a variar muy fcilmente, en caso de que un valor no exista en el catlogo, se deber solicitar autorizacin a la junta directiva, para eliminar el valor, agregarlo al catlogo para actualizarlo, o permitirlo an sin actualizar el catlogo. Nulos Es importante identificar como se solicita la informacin, ya que un nulo se representa tcnicamente como: espacios en blanco, nulo (tal cual dentro de la base de datos), el valor alfanumrico NULL o NULO, y estandarizarlos todos de la misma manera, con la finalidad de que haya consistencia en la informacin entregada. Asimismo, es necesario identificar aquellos valores son propensos a convertirse en nulo. EJEMPLO: El campo CURP cuenta con valores nulos, y con espacios, adems con valores como XXXXXXXXXX, se debern homologar los nulos de manera igual, por default sern nulos, sin embargo, si el layout o la junta directiva definen que deber ser la palabra NULL u algn otro valor, todos los valores considerados como nulos se debern homologar. Parsear El proceso de parseo para nombres o domicilio es un proceso que demanda mucho tiempo, por lo que, antes de llevarlo a cabo, se debern evaluar los tiempos de entrega de la informacin, no obstante, si el layout de entrega solicita la informacin parseada, la informacin se deber entregar conforme a lo solicitado. EJEMPLO: Algunas entidades comparten su informacin con la informacin del nombre en un solo campo, esta se deber segmentar en NOMBRE, PRIMER_APELLIDO y SEGUNDO_APELLIDO. Fechas Vlidas El tratamiento de fechas en cualquier base de datos es complejo, pues las fechas tienen distintos formatos y su homologacin se vuelve muy costosa, no obstante, es importante identificar que formato solicita el layout de entrada y en caso de no estar definido, solicitar la definicin a la junta directiva y homologar todas las fechas correctamente. EJEMPLO: El campo fecha de nacimiento, puede tener valores como los siguientes:
Pgina 4 de 7

21/05/00 12-07-2001 1998-04-22 00/00/0000 Se debern homologar en un mismo formato de fecha y los valores no vlidos como 00/00/0000 se debern eliminar o transformar de acuerdo con lo permitido en el layout o lo definido por la junta directiva. RFCs Vlidos Se debe validar que los RFCs estn con la longitud correcta, las mscara vlidas y si es posible, solicitar su validacin con la instancia correspondiente (SAT), el layout deber especificar que valores permite como vlidos o en su defecto la junta directiva. Procesos de DQ se pueden implementar para darle un mayor grado de confiabilidad. El layout en conjunto con la junta directiva definen el nivel de profundidad para los valores permitidos en el RFC. EJEMPLO: En el campo RFC existe valores como: CUTJ772505SE0 el cual tiene una mscara correcta (XXXXNNNNNNXXX) sin embargo, la fecha est mal, ya que 77 corresponde al ao 25 al mes y 05 al da, 25 es un mes que no existe. La junta directiva dictamin que un RFC a 10 posiciones es vlido. CURPs Validas Para la CURP se debe validar que cumpla con la longitud correcta, mscaras correctas y se deber solicitar su validacin con la instancia correspondiente (RENAPO). El layout en conjunto con la junta directiva definen el nivel de profundidad para los valores permitidos en la CURP. Procesos de DQ se pueden implementar para darle un mayor grado de confiabilidad. El proceso de DQ debe validar lo siguiente: - Del primer apellido, primera letra y primera vocal interna (VA). - Del Segundo apellido, primera letra (G). En caso de no tener segundo apellido se posiciona una "X". - Del primer nombre, primera letra (E). En nombres compuestos que comiencen con Mara o Jos, se tomar en cuenta el segundo nombre para la asignacin de la inicial. - De la fecha de nacimiento, ao, mes y da (740913). - Del sexo, (H) para hombre y (M) para mujer. En este caso hombre (H). - Del lugar de nacimiento, las dos letras segn el cdigo de la Entidad Federativa que corresponda (CM). - De los apellidos y primer nombre, las primeras consonantes internas de cada uno (LTL). - La posicin 17 es un caracter asignado por el Registro Nacional de Poblacin para evitar registros duplicados (0). - El ltimo es un dgito verificador, un nmero que tambin es asignado por el Registro Nacional de Poblacin (6). EJEMPLO: CURPs no vlidas: XXXXXXXXXXXXXXXXXX
Pgina 5 de 7

Encabezados Si la informacin se entregar en archivo, los nombres de los campos debern estar claramente escritos dentro del archivo a entregar y en el orden solicitado, adicionalmente al archivo a entregar, se deber anexar un diccionario de datos con los nombres de campos y tipos de dato entregados. En caso de que la informacin se comparta en una base de datos, el diccionario de datos deber corresponder con el esquema o esquemas de datos dentro de la base de datos. EJEMPLO: El FD solicita NOMBRE, RFC y CURP, se entregar un archivo plano delimitado por pipes con nombres en la primera lnea como sigue: NOMBRE|RFC|CURP y un diccionario de datos como sigue:
nombre de campo descripcin observaciones El campo NOMBRE contiene nombre y apellidos en el siguiente orden: PRIMER APELLIDO, SEGUNDO APELLIDO, NOMBRES Si el RFC no es vlido el campo es Nulo Si la CURP no es vlido el campo es Nulo

NOMBRE RFC CURP

campo correspondiente al nombre del trabajador o maestro RFC del trabajador o maestro CURP del trabajador o maestro

Anlisis de frecuencias y tendencias Se recomienda analizar los datos con herramientas de DQ, o sentencias de SQL o incluso tablas dinmicas en Excel, esto para identificar tendencias en la informacin a entregar. EJEMPLO: Al analizar los nulos en el total de la informacin, se identific que 3 entidades no estn proporcionando correctamente la informacin solicitada. Desduplicar Se recomienda ampliamente que el proceso de desduplicacin sea al final de todas las anteriores actividades ya que durante las actividades anteriores los datos pudieron haberse transformado y como consecuencia algunos registros sern idnticos, el primer proceso de desduplicacin (y por lo menos el mnimo requerido) es un select de todos campos de la tabla a entregar agrupando por los mismos campos, si se requiere de un proceso de desduplicacin ms exhaustivo, se deber hacer uso de herramientas de DQ, no sin antes recalcar que las variables a considerar para considerar un registro idntico, deben ser correctamente definidas. EJEMPLO: La tabla procesada contiene ID_REGISTRO, NOMBRE, RFC, CCT, ENTIDAD y el FD a entregar solicita nicamente NOMBRE, RFC, ENTIDAD, la desduplicacin se deber realizar sobre los campos solicitados en el FD sin considerar ID_REGISTRO ni CCT.

Pgina 6 de 7

Cifras de Control Bajo ninguna circunstancia ninguna fuente que se entregue deber ir sin cifras de control, contando por lo menos con la siguiente informacin mnima: Nombre del (de los) archivo(s) Nmero de registro por archivo Nmero de campos (anexo con su respectivo diccionario de datos) Informacin de valor sobre la informacin entregada, por ejemplo, nmero de entidades entregadas, CCTs distintos, Alumnos por entidad, etctera, segn sea la necesidad de la informacin a entregar.

Matriz-Checklist La siguiente matriz servir de gua rpida para listar las actividades a realizar a una fuente de datos a entregar:
Actividad Revisar Layouts Valores Fuera de Rango Estandarizar Valores contra Catlogo Nulos Parsear Fechas Vlidas RFCs Vlidos CURPs Validas Encabezados Anlisis de frecuencias y tendencias Desduplicar Cifras de Control Aplica (SI/NO) Observaciones/Comentarios

Pgina 7 de 7