Edición de Datos
El procesamiento de la base de datos derivada del censo implicó la ejecución de un proceso de validación de la información con la finalidad de garantizar, tanto su congruencia lógica, como la completitud e integridad de los datos asociados a las preguntas de los módulos del instrumento de captación. Para ello, se aplicó una serie de criterios que se diseñaron tomando fielmente el contenido y la estructura de los cuestionarios. En términos generales, la validación se llevó a cabo para corregir las inconsistencias de la información derivadas básicamente por la existencia de errores como omisión o falta de respuesta, multirrespuesta, valores inadmisibles o fuera de rango, falta de atención en los pases de preguntas y, también, incongruencias entre respuestas.
Para estos efectos, el proceso se ejecutó en tres grandes fases: la preparación del proceso de validación, la revisión y pruebas del funcionamiento de los vectores de validación y la ejecución de la validación y generación de la base de datos definitiva.
1) Fase de preparación
Antes de validar la base de datos, se realizó un conjunto de actividades que no fueron ejecutadas necesariamente de manera secuencial, pero que resultaron indispensables para garantizar el proceso de validación. Enseguida se enuncia brevemente cada una de ellas. Clasificación de preguntas por tipo. Se realizó una clasificación de las preguntas del cuestionario de acuerdo con el tipo de respuesta que se solicita y se identificaron las relaciones que guardan con otras preguntas. Se identificaron 23 tipos.
Esto permitió contar con elementos precisos para definir los criterios de validación tomando en consideración las necesidades derivadas de cada tipo de pregunta y asegurar que todas ellas también contaran con criterios definidos de manera particular. A su vez, la agrupación de las preguntas permitió aplicar los mismos criterios a todas las incluidas en la clasificación. Enseguida se describió brevemente cada tipo de pregunta y se establecieron los criterios mínimos de validación por cada uno de ellos. A continuación, se identificaron aquellas preguntas que correspondían a cada uno de los 23 tipos definidos.
Modelado de la base de datos
Para establecer y describir la forma en que se organizaron y ordenaron los datos para su almacenamiento de forma que la información se encuentre disponible sin redundancia y de manera entendible, se creó un modelo entidad-relación el cual define de manera precisa las relaciones entre las entidades u objetos para los que se almacenan datos y sus atributos, es decir, las características de la entidad cuyos valores se encuentran en los campos de las tablas de la base de datos.
Migración de la base de datos de captura
Con la finalidad de empatar la base de datos de captura con el modelo de la definitiva, se efectuó un proceso de mapeo entre la base de datos preliminar (base de datos de captura) y el modelo definitivo de base de datos, para encontrar la relación entre los datos que requiere cada campo de éste último y el campo en que se encuentra en la base de datos preliminar. Asimismo, se creó un esquema de consultas (vistas) en SQL para acceder a los datos de la base preliminar y ordenarlos en tablas y campos siguiendo la estructura de la base de datos definitiva.
Enseguida se llevó a cabo un proceso mediante el cual se insertaron los datos de la base preliminar, a través de las consultas o vistas, a la base de desarrollo. Para ello se construyó una serie de paquetesque generaron la estructura de las tablas de la base de datos de acuerdo con los tipos de dato permitidos. De manera paralela se creó una tabla especial para almacenar casos en que los datos no se encontraban en los rangos establecidos. Esto permitió detectar errores en los datos de la base de captura y corregirlos. En este proceso se realizó la conversión algunos datos alfanuméricos
de la base de datos preliminar como NS y los NA a datos numéricos para insertarlos a la estructura de la base de datos definitiva, convirtiendo los NS a -1 y los NA a -2.
Definición de funciones
Se definieron 28 funciones para contar con un lenguaje común formado por un conjunto de símbolos y variables para expresar las operaciones y/o procesos que debe llevar a cabo la computadora al aplicar cada uno de los vectores de validación, así como su descripción, su clasificación por tipo, de acuerdo con el uso que se le dio durante el proceso, así como la cantidad mínima de argumentos que debió considerar
y su valor de retorno.
Definición de vectores
Se definió un conjunto de tratamientos (vectores de validación) para corregir las posibles inconsistencias en la base de datos preliminar, considerando las distintas combinaciones de valores que se pudieran encontrar dentro de una misma pregunta y entre las preguntas. Los criterios de validación son necesarios para que todos los casos se resuelvan de la misma forma y así los datos sean consistentes.
En total se crearon 27 escenarios; 21 para el primer módulo, uno para el segundo, uno para el tercero y cuatro para el cuarto módulo. Asimismo, se desarrollaron 790 vectores de validación: 296 para el primer módulo, 14 para el segundo, 41 para el tercero y 439 para el cuarto módulo.
Vectores por módulo
Con el fin de estandarizar el proceso para definir los vectores de validación y su programación, se creó una aplicación informática denominada Entorno de Desarrollo para Criterios de Validación Exhaustiva, mediante la cual, por un lado, se realizó la definición de vectores de validación, en la que se tomaron en cuenta todas las posibles combinaciones que se pueden dar en la pregunta o preguntas que se están validando, y se definió un tratamiento para cada una de esas combinaciones. Por otro lado, esta aplicación permitió la programación sistematizada de los vectores de validación. A partir de las funciones definidas se crearon sus correspondientes códigos en lenguaje PL/SQL, es decir fragmentos de código predefinidos, que se generan de manera automática a partir de la función y las variables definidas en la
aplicación para cada vector.
Definición de criterios de validación
Para poder validar la información se definieron dos tipos de criterios para aplicarlos de manera homogénea a lo largo del proceso. Por un lado, un conjunto de criterios básicos que permitieron establecer relaciones primarias entre respuestas que involucraron los caracteres alfanuméricos NS (no contó con elementos para responder) y NA (no le aplica).
2) Fase de pruebas
Una vez programados los vectores se corrieron sobre la base de datos ya migrada en el esquema de desarrollo y se revisó la traza. Por medio de estas pruebas se encontraron algunos errores y se corrigieron. Los errores encontrados fueron de tres tipos:
a) En la programación de vectores de validación (se corrigieron reprogramando las funciones del PL).
b) En la definición de vectores de validación (se corrigieron ajustando el vector en la aplicación).
c) Se identificaron cifras o valores que fue necesario considerar como revisiones de caso.
Estas últimas resultan de casos en que la inconsistencia de datos no puede ser corregida por los vectores aplicados y es necesaria la intervención de una persona. Aunque en algunos casos fue posible realizar una re consulta con el informante y encontrar una solución, la mayoría de ellos se resolvió revisando los datos con el equipo de campo y buscando la mejor solución con el área conceptual. Después de realizar las correcciones se volvieron a probar los vectores sobre la base de desarrollo. Una vez que no se encontró ningún error se liberaron, considerándolos terminados y listos para ser aplicados en la base de datos productiva.
3) Fase de validación definitiva
Al terminar de realizar las pruebas, se migraron los datos de la base preliminar a la base en el esquema de producción, con todos los ajustes realizados a partir de las revisiones de caso. A esta base de datos se le aplicaron nuevamente los vectores de validación que fueron probados previamente, para verificar la consistencia de los datos y, en su caso, se realizaron los ajustes finales.
La base validada se liberó como base definitiva el 29 de septiembre de 2017 para su uso en los procesos de generación de resultados. Con excepción de la entidad 15 en el módulo 1 sección 1, y de las entidades 15, 19 y 21 en el módulo 3, que se liberaron el 10 de octubre de 2017; y de las entidades 15 y 21 en el módulo 2, que se liberaron el 12 de octubre de 2017.
4) Resumen de datos procesados
De acuerdo con la forma en que están diseñados los cuestionarios que corresponden al Censo Nacional de Gobierno, Seguridad Pública y Sistema Penitenciario Estatales 2017, y para efectos de la integración, procesamiento y validación de la información, se genera una base de datos relacional. La base de datos generada considera un total de 2 508 391 datos individuales, sin considerar las relaciones entre las tablas, los catálogos, y las llaves de las tablas. Con respecto al total de datos que se contabilizan, el 8.79 por ciento corresponden al módulo 1 sección 1, el 0.25 por ciento al módulo 1 sección 2, el 1.45 por ciento al módulo 1 sección 3, el 2.80 por ciento al módulo 1 sección 5, el 0.44 por ciento al módulo 1 sección 6, el 0.91 por ciento corresponden al módulo 1 sección 7, el 1.15 por ciento al módulo 1 sección 8, el 2.22 por ciento al módulo 1 sección 9, el 2.44 por ciento corresponden al módulo 1 sección 10, el 4.52 por ciento corresponden al módulo 1 sección 11, el 40.68 por ciento al módulo 2, 34.15 por ciento al módulo 3 y 0.18 por ciento corresponden al módulo 5.
Durante el procesamiento de los datos que se integraron en la base de datos y que se derivaron de los cuestionarios respondidos, se incluye la discriminación de cuatro tipos de datos: Valores o datos mayores o iguales a cero y que incluyen códigos relacionados con preguntas de tipo “verdadero” y “falso”; valores que corresponden a reactivos que, por las características de las preguntas no requieren una respuesta o no requieren el registro de datos específicos, y que se registran como “No aplica” y se codifican con “-2”; valores que corresponden a datos que no fueron proporcionados por el informante, ya fuera porque no supieron la respuesta o porque no tuvieron elementos de información en sus registros administrativos para responderla y que se registraron como “No se sabe” y se codificaron con “-1”; y por último, valores nulos que corresponden a variables que no requieren registro de información dada la construcción de las tablas y las características de las preguntas.