1. Datos iniciales
La limpieza de datos es uno de los desafíos que enfrentan las tareas de análisis de datos. Este material reflejó los desarrollos y soluciones que surgieron como resultado de la resolución de un problema práctico de análisis de una base de datos en la formación del valor catastral. Fuentes aquí .
Se consideró el archivo “Modelo comparativo total.ods” del “Apéndice B. Resultados de la determinación de KS 5. Información sobre el método de determinación del valor catastral 5.1 Enfoque comparativo”.
Tabla 1. Indicadores estadísticos del conjunto de datos del archivo “Modelo comparativo total.ods”
Número total de campos, uds. — 44
Número total de registros, uds. — 365 490
Número total de caracteres, uds. — 101 714 693
Número medio de caracteres en un registro, uds. — 278,297
Desviación estándar de caracteres en un registro, uds. - 15,510
Número mínimo de caracteres en una entrada, uds. — 198
Número máximo de caracteres en una entrada, uds. — 363
2. Parte introductoria. Estándares básicos
Al analizar la base de datos especificada, se creó la tarea de especificar los requisitos para el grado de purificación, ya que, como todos saben, la base de datos especificada crea consecuencias legales y económicas para los usuarios. Durante el trabajo resultó que no existen requisitos específicos para el grado de limpieza de big data. Analizando las normas legales en esta materia, llegué a la conclusión de que todas están formadas por posibilidades. Es decir, ha aparecido una determinada tarea, se recopilan fuentes de información para la tarea, luego se forma un conjunto de datos y, a partir del conjunto de datos creado, se crean herramientas para resolver el problema. Las soluciones resultantes son puntos de referencia a la hora de elegir entre alternativas. Presenté esto en la Figura 1.
Dado que, a la hora de determinar cualquier estándar, es preferible confiar en tecnologías probadas, elegí los requisitos establecidos en , porque consideré este documento el más completo para este tema. En particular, en este documento la sección dice "Cabe señalar que los requisitos de integridad de los datos se aplican igualmente a los datos manuales (en papel) y electrónicos". (traducción: “...los requisitos de integridad de los datos se aplican igualmente a los datos manuales (en papel) y electrónicos”). Esta formulación está muy específicamente asociada al concepto de “prueba escrita”, en lo dispuesto en el artículo 71 del Código de Procedimiento Civil, art. 70 CAS, Art. 75 APC, “por escrito” Art. 84 Código de Procedimiento Civil.
La Figura 2 presenta un diagrama de la formación de enfoques sobre tipos de información en la jurisprudencia.
Arroz. 2. Fuente .
La Figura 3 muestra el mecanismo de la Figura 1, para las tareas de la “Guía” anterior. Al hacer una comparación, es fácil ver que los enfoques utilizados para cumplir con los requisitos de integridad de la información en los estándares modernos para sistemas de información son significativamente limitados en comparación con el concepto legal de información.
Ris.3
En el documento especificado (Guía), la conexión con la parte técnica, las capacidades para procesar y almacenar datos, está bien confirmada por una cita del Capítulo 18.2. Base de datos relacional: "Esta estructura de archivos es inherentemente más segura, ya que los datos se guardan en un formato de archivo grande que preserva la relación entre datos y metadatos".
De hecho, en este enfoque, a partir de las capacidades técnicas existentes, no hay nada anormal y, en sí mismo, es un proceso natural, ya que la expansión de conceptos proviene de la actividad más estudiada: el diseño de bases de datos. Pero, por otro lado, aparecen normas legales que no prevén descuentos en las capacidades técnicas de los sistemas existentes, por ejemplo: .
Arroz. 4. Embudo de capacidades técnicas ().
En estos aspectos, queda claro que el conjunto de datos original (Fig. 1) deberá, en primer lugar, guardarse y, en segundo lugar, ser la base para extraer información adicional del mismo. Pongamos un ejemplo: las cámaras que graban las normas de tráfico están en todas partes, los sistemas de procesamiento de información eliminan a los infractores, pero también se puede ofrecer otra información a otros consumidores, por ejemplo, como seguimiento de marketing de la estructura del flujo de clientes a un centro comercial. Y esta es una fuente de valor añadido adicional al utilizar BigDat. Es muy posible que los conjuntos de datos que se recopilan ahora, en algún momento en el futuro, tengan un valor según un mecanismo similar al valor de las ediciones raras de 1700 en la actualidad. Después de todo, de hecho, los conjuntos de datos temporales son únicos y es poco probable que se repitan en el futuro.
3. Parte introductoria. Criterios de evaluación
Durante el proceso de procesamiento se desarrolló la siguiente clasificación de errores.
1. Clase de error (según GOST R 8.736-2011): a) errores sistemáticos; b) errores aleatorios; c) un error garrafal.
2. Por multiplicidad: a) monodistorsión; b) multidistorsión.
3. Según la criticidad de las consecuencias: a) crítica; b) no crítico.
4. Por fuente de ocurrencia:
A) Técnico – errores que ocurren durante el funcionamiento del equipo. Un error bastante relevante para los sistemas IoT, sistemas con un grado significativo de influencia en la calidad de la comunicación, equipos (hardware).
B) Errores del operador: errores en una amplia gama, desde errores tipográficos del operador durante la entrada hasta errores en las especificaciones técnicas para el diseño de la base de datos.
C) Errores del usuario: aquí hay errores del usuario en todo el rango, desde "olvidé cambiar el diseño" hasta confundir metros con pies.
5. Separados en clase separada:
a) la “tarea del separador”, es decir, el espacio y “:” (en nuestro caso) cuando fue duplicado;
b) palabras escritas juntas;
c) sin espacios después de los caracteres de servicio
d) símbolos múltiples simétricamente: (), "", "...".
En conjunto, con la sistematización de errores de la base de datos presentada en la Figura 5, se forma un sistema de coordenadas bastante efectivo para buscar errores y desarrollar un algoritmo de limpieza de datos para este ejemplo.
Arroz. 5. Errores típicos correspondientes a las unidades estructurales de la base de datos (Fuente: ).
Precisión, integridad del dominio, tipo de datos, coherencia, redundancia, integridad, duplicación, conformidad con las reglas comerciales, definición estructural, anomalía de los datos, claridad, puntualidad, cumplimiento de las reglas de integridad de los datos. (Página 334. Fundamentos del almacenamiento de datos para profesionales de TI / Paulraj Ponniah.—2ª ed.)
Se presenta redacción en inglés y traducción automática en ruso entre paréntesis.
Exactitud. El valor almacenado en el sistema para un elemento de datos es el valor correcto para esa aparición del elemento de datos. Si tiene un nombre de cliente y una dirección almacenados en un registro, entonces la dirección es la dirección correcta para el cliente con ese nombre. Si encuentra que la cantidad pedida es de 1000 unidades en el registro del número de pedido 12345678, entonces esa cantidad es la cantidad exacta para ese pedido.
[Exactitud. El valor almacenado en el sistema para un elemento de datos es el valor correcto para esa aparición del elemento de datos. Si tiene el nombre y la dirección de un cliente almacenados en un registro, entonces la dirección es la dirección correcta para el cliente con ese nombre. Si encuentra que la cantidad pedida es de 1000 unidades en el registro del número de pedido 12345678, entonces esa cantidad es la cantidad exacta para ese pedido.]
Integridad del dominio. El valor de datos de un atributo se encuentra dentro del rango de valores definidos permitidos. El ejemplo común son los valores permitidos como "masculino" y "femenino" para el elemento de datos de género.
[Integridad del dominio. El valor de los datos del atributo se encuentra dentro del rango de valores definidos válidos. Un ejemplo general son los valores válidos "masculino" y "femenino" para un elemento de datos de género.]
Tipo de datos. El valor de un atributo de datos en realidad se almacena como el tipo de datos definido para ese atributo. Cuando el tipo de datos del campo de nombre de la tienda se define como "texto", todas las instancias de ese campo contienen el nombre de la tienda que se muestra en formato textual y no en códigos numéricos.
[Tipo de datos. El valor de un atributo de datos en realidad se almacena como el tipo de datos definido para ese atributo. Si el tipo de datos del campo de nombre de la tienda se define como "texto", todas las instancias de este campo contienen el nombre de la tienda que se muestra en formato de texto en lugar de códigos numéricos.]
Consistencia. La forma y el contenido de un campo de datos son los mismos en varios sistemas de origen. Si el código de producto ABC en un sistema es 1234, entonces el código de este producto es 1234 en cada sistema fuente.
[Consistencia. La forma y el contenido del campo de datos son los mismos en diferentes sistemas fuente. Si el código de producto ABC en un sistema es 1234, entonces el código de ese producto es 1234 en cada sistema fuente.]
Redundancia. Los mismos datos no deben almacenarse en más de un lugar de un sistema. Si, por razones de eficiencia, un elemento de datos se almacena intencionalmente en más de un lugar de un sistema, entonces la redundancia debe identificarse y verificarse claramente.
[Redundancia. Los mismos datos no deben almacenarse en más de un lugar del sistema. Si, por razones de eficiencia, un elemento de datos se almacena intencionalmente en múltiples ubicaciones de un sistema, entonces la redundancia debe definirse y verificarse claramente.]
Lo completo. No faltan valores para un atributo determinado en el sistema. Por ejemplo, en un archivo de cliente, debe haber un valor válido para el campo "estado" para cada cliente. En el archivo de detalles del pedido, todos los registros de detalle de un pedido deben estar completamente completados.
[Lo completo. No faltan valores en el sistema para este atributo. Por ejemplo, el archivo del cliente debe tener un valor válido para el campo "estado" de cada cliente. En el archivo de detalle del pedido, cada registro de detalle del pedido debe estar completamente completado.]
Duplicación. La duplicación de registros en un sistema queda completamente resuelta. Si se sabe que el archivo del producto tiene registros duplicados, se identifican todos los registros duplicados para cada producto y se crea una referencia cruzada.
[Duplicar. Se ha eliminado por completo la duplicación de registros en el sistema. Si se sabe que un archivo de producto contiene entradas duplicadas, se identifican todas las entradas duplicadas para cada producto y se crea una referencia cruzada.]
Conformidad con las reglas comerciales. Los valores de cada elemento de datos se ajustan a las reglas comerciales prescritas. En un sistema de subasta, el precio de remate o de venta no puede ser inferior al precio de reserva. En un sistema de préstamos bancarios, el saldo del préstamo siempre debe ser positivo o cero.
[Cumplimiento de las normas de negocio. Los valores de cada elemento de datos cumplen con las reglas comerciales establecidas. En un sistema de subasta, el precio de remate o de venta no puede ser inferior al precio de reserva. En un sistema de crédito bancario, el saldo del préstamo siempre debe ser positivo o cero.]
Definitividad estructural. Siempre que un elemento de datos pueda estructurarse naturalmente en componentes individuales, el elemento debe contener esta estructura bien definida. Por ejemplo, el nombre de una persona se divide naturalmente en nombre, inicial del segundo nombre y apellido. Los valores para los nombres de las personas deben almacenarse como nombre, inicial del segundo nombre y apellido. Esta característica de la calidad de los datos simplifica la aplicación de estándares y reduce los valores faltantes.
[Certeza estructural. Cuando un elemento de datos puede estructurarse naturalmente en componentes individuales, el elemento debe contener esta estructura bien definida. Por ejemplo, el nombre de una persona se divide naturalmente en nombre, inicial del segundo nombre y apellido. Los valores de los nombres individuales deben almacenarse como nombre, inicial del segundo nombre y apellido. Esta característica de calidad de los datos simplifica la aplicación de estándares y reduce los valores perdidos.]
Anomalía de datos. Un campo debe utilizarse únicamente para el propósito para el que está definido. Si el campo Dirección-3 está definido para cualquier posible tercera línea de dirección para direcciones largas, entonces este campo debe usarse solo para registrar la tercera línea de dirección. No debe usarse para ingresar un número de teléfono o fax del cliente.
[Anomalía de datos. Un campo sólo debe utilizarse para el fin para el que está definido. Si el campo Dirección-3 está definido para cualquier posible tercera línea de dirección para direcciones largas, entonces este campo solo se utilizará para registrar la tercera línea de dirección. No debe usarse para ingresar un número de teléfono o fax de un cliente.]
Claridad. Un elemento de datos puede poseer todas las demás características de los datos de calidad, pero si los usuarios no comprenden claramente su significado, entonces el elemento de datos no tiene valor para los usuarios. Las convenciones de nomenclatura adecuadas ayudan a que los usuarios comprendan bien los elementos de datos.
[Claridad. Un elemento de datos puede tener todas las demás características de buenos datos, pero si los usuarios no entienden claramente su significado, entonces el elemento de datos no tiene valor para los usuarios. Las convenciones de nomenclatura correctas ayudan a que los usuarios comprendan bien los elementos de datos.]
Oportuno. Los usuarios determinan la actualidad de los datos. Si los usuarios esperan que los datos de la dimensión del cliente no tengan más de un día, los cambios en los datos del cliente en los sistemas de origen deben aplicarse al almacén de datos diariamente.
[De una manera oportuna. Los usuarios determinan la actualidad de los datos. Si los usuarios esperan que los datos de la dimensión del cliente no tengan más de un día de antigüedad, los cambios en los datos del cliente en los sistemas de origen deben aplicarse al almacén de datos diariamente.]
Utilidad. Cada elemento de datos en el almacén de datos debe satisfacer algunos requisitos de la colección de usuarios. Un elemento de datos puede ser preciso y de alta calidad, pero si no tiene valor para los usuarios, entonces es totalmente innecesario que ese elemento de datos esté en el almacén de datos.
[Utilidad. Cada elemento de datos del almacén de datos debe satisfacer algunos requisitos de la colección del usuario. Un elemento de datos puede ser preciso y de alta calidad, pero si no proporciona valor a los usuarios, entonces no es necesario que ese elemento de datos esté en el almacén de datos.]
Cumplimiento de las reglas de integridad de datos. Los datos almacenados en las bases de datos relacionales de los sistemas de origen deben cumplir con las reglas de integridad de la entidad y de integridad referencial. Cualquier tabla que permita nulo como clave principal no tiene integridad de entidad. La integridad referencial obliga a establecer correctamente las relaciones entre padres e hijos. En una relación cliente-pedido, la integridad referencial asegura la existencia de un cliente para cada pedido en la base de datos.
[Cumplimiento de las normas de integridad de datos. Los datos almacenados en bases de datos relacionales de sistemas fuente deben cumplir con las reglas de integridad de entidad e integridad referencial. Cualquier tabla que permita nulo como clave principal no tiene integridad de entidad. La integridad referencial obliga a establecer correctamente la relación entre padres e hijos. En una relación cliente-pedido, la integridad referencial garantiza que exista un cliente para cada pedido en la base de datos.]
4. Calidad de la limpieza de datos
La calidad de la limpieza de datos es un tema bastante problemático en bigdata. Responder a la pregunta de qué grado de limpieza de datos es necesario para completar la tarea es fundamental para todo analista de datos. En la mayoría de los problemas actuales, cada analista determina esto por sí mismo y es poco probable que alguien externo pueda evaluar este aspecto en su solución. Pero para la tarea que nos ocupa en este caso, esta cuestión era sumamente importante, ya que la confiabilidad de los datos legales debe tender a uno.
Considerar tecnologías de prueba de software para determinar la confiabilidad operativa. Hoy en día existen más que estos modelos. . Muchos de los modelos utilizan un modelo de atención de reclamos:
La figura. 6
Pensando de la siguiente manera: "Si el error encontrado es un evento similar al evento de falla en este modelo, entonces ¿cómo encontrar un análogo del parámetro t?" Y compilé el siguiente modelo: Imaginemos que el tiempo que le toma a un evaluador verificar un registro es 1 minuto (para la base de datos en cuestión), luego para encontrar todos los errores necesitará 365 minutos, lo que equivale aproximadamente a 494 años y 3 meses de jornada laboral. Como entendemos, se trata de una cantidad de trabajo muy grande y los costos de verificar la base de datos serán prohibitivos para el compilador de esta base de datos. En esta reflexión aparece el concepto económico de costos y luego del análisis llegué a la conclusión de que esta es una herramienta bastante efectiva. Basado en la ley de la economía: “El volumen de producción (en unidades) en el que se logra el beneficio máximo de una empresa se ubica en el punto donde el costo marginal de producir una nueva unidad de producción se compara con el precio que esta empresa puede recibir para una nueva unidad”. Basado en el postulado de que encontrar cada error posterior requiere una verificación cada vez mayor de los registros, este es un factor de costo. Es decir, el postulado adoptado en los modelos de prueba adquiere un significado físico en el siguiente patrón: si para encontrar el i-ésimo error fue necesario verificar n registros, entonces para encontrar el siguiente error (i+3) será necesario para comprobar m registros y al mismo tiempo n
- Cuando se estabiliza el número de registros verificados antes de encontrar un nuevo error;
- Cuando aumentará la cantidad de registros verificados antes de encontrar el siguiente error.
Para determinar el valor crítico recurrí al concepto de viabilidad económica, que en este caso, utilizando el concepto de costos sociales, se puede formular de la siguiente manera: “Los costos de corregir el error deben ser asumidos por el agente económico que puede hacerlo”. hacerlo al menor costo”. Tenemos un agente: un evaluador que dedica 1 minuto a verificar un registro. En términos monetarios, si gana 6000 rublos al día, serán 12,2 rublos. (aproximadamente hoy). Queda por determinar el segundo lado del equilibrio en el derecho económico. Razoné así. Un error existente requerirá que el interesado haga un esfuerzo para corregirlo, es decir, el propietario del inmueble. Digamos que esto requiere 1 día de acción (enviar una solicitud, recibir un documento corregido). Entonces, desde un punto de vista social, sus costos serán iguales al salario promedio por día. Salario promedio acumulado en el Okrug autónomo de Khanty-Mansi 73285 frotar. o 3053,542 rublos/día. En consecuencia, obtenemos un valor crítico igual a:
3053,542: 12,2 = 250,4 unidades de registros.
Esto significa que, desde un punto de vista social, si un evaluador verificó 251 registros y encontró un error, equivale a que el usuario corrija este error él mismo. En consecuencia, si el evaluador dedicó un tiempo equivalente a verificar 252 registros para encontrar el siguiente error, entonces, en este caso, es mejor trasladar el costo de la corrección al usuario.
Aquí se presenta un enfoque simplificado, ya que desde el punto de vista social es necesario tener en cuenta todo el valor adicional generado por cada especialista, es decir, costos incluidos impuestos y pagos sociales, pero el modelo es claro. Una consecuencia de esta relación es el siguiente requisito para los especialistas: un especialista de la industria de TI debe tener un salario superior al promedio nacional. Si su salario es menor que el salario promedio de los usuarios potenciales de la base de datos, entonces él mismo debe verificar toda la base de datos personalmente.
Cuando se utiliza el criterio descrito, se forma el primer requisito para la calidad de la base de datos:
Yo(tr). La proporción de errores críticos no debe exceder 1/250,4 = 0,39938%. Un poco menos que oro en la industria. Y en términos físicos no hay más de 1459 registros con errores.
Retiro económico.
De hecho, al cometer tal cantidad de errores en los registros, la sociedad acepta pérdidas económicas por la cantidad de:
1459*3053,542 = 4 rublos.
Este monto está determinado por el hecho de que la sociedad no tiene las herramientas para reducir estos costos. De ello se deduce que si alguien tiene una tecnología que le permite reducir el número de registros con errores a, por ejemplo, 259, entonces esto permitirá a la sociedad ahorrar:
1200*3053,542 = 3 rublos.
Pero al mismo tiempo, puede pedirle su talento y su trabajo, bueno, digamos: 1 millón de rublos.
Es decir, los costos sociales se reducen mediante:
3 – 664 = 250 rublos.
En esencia, este efecto es el valor añadido del uso de tecnologías BigDat.
Pero aquí hay que tener en cuenta que se trata de un efecto social, y el propietario de la base de datos son las autoridades municipales, sus ingresos por el uso de la propiedad registrada en esta base de datos, a razón del 0,3%, son: 2,778 mil millones de rublos/ año. Y estos costes (4 rublos) no le molestan mucho, ya que se transfieren a los propietarios. Y, en este aspecto, el desarrollador de tecnologías más refinadas en Bigdata tendrá que demostrar la capacidad de convencer al propietario de esta base de datos, y esas cosas requieren un talento considerable.
En este ejemplo, el algoritmo de evaluación de errores se eligió basándose en el modelo Schumann [2] de verificación de software durante las pruebas de confiabilidad. Debido a su prevalencia en Internet y la capacidad de obtener los indicadores estadísticos necesarios. La metodología está tomada de Monakhov Yu.M. "Estabilidad funcional de los sistemas de información", ver debajo del spoiler en la Fig. 7-9.
Arroz. 7 – 9 Metodología del modelo Schumann
La segunda parte de este material presenta un ejemplo de limpieza de datos, en el que se obtienen los resultados del uso del modelo Schumann.
Permítanme presentar los resultados obtenidos:
Número estimado de errores N = 3167 n.
Parámetro C, función lambda y fiabilidad:
Ris.17
Básicamente, lambda es un indicador real de la intensidad con la que se detectan errores en cada etapa. Si nos fijamos en la segunda parte, la estimación de este indicador fue de 42,4 errores por hora, lo que es bastante comparable al indicador Schumann. Anteriormente, se determinó que la velocidad a la que un desarrollador encuentra errores no debe ser inferior a 1 error por 250,4 registros, al verificar 1 registro por minuto. De ahí el valor crítico de lambda para el modelo de Schumann:
60 / 250,4 0,239617 =.
Es decir, la necesidad de realizar procedimientos de detección de errores debe realizarse hasta que lambda, de los 38,964 existentes, disminuya a 0,239617.
O hasta que el indicador N (número potencial de errores) menos n (número corregido de errores) disminuya por debajo de nuestro umbral aceptado: 1459 unidades.
Literatura
- Monakhov, Yu.M. Estabilidad funcional de los sistemas de información. En 3 horas Parte 1. Fiabilidad del software: libro de texto. subsidio / Yu.M.Monakhov; Vladimir. estado univ. – Vladímir: Izvo Vladim. estado Universidad, 2011. – 60 p. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Modelos probabilísticos para la predicción de la confiabilidad del software".
- Fundamentos del almacenamiento de datos para profesionales de TI / Paulraj Ponniah.—2ª ed.
Fuente: habr.com