1. Datos iniciais
A limpeza de datos é un dos retos aos que se enfrontan as tarefas de análise de datos. Este material reflectiu os desenvolvementos e solucións que xurdiron como resultado de resolver un problema práctico de análise da base de datos na formación do valor catastral. Fontes aquí .
Considerouse o ficheiro “Modelo comparativo total.ods” do “Anexo B. Resultados da determinación de KS 5. Información sobre o método de determinación do valor catastral 5.1 Aproximación comparativa”.
Táboa 1. Indicadores estatísticos do conxunto de datos do ficheiro “Modelo comparativo total.ods”
Número total de campos, unidades. — 44
Número total de rexistros, pzas. — 365 490
Número total de caracteres, unidades. — 101 714 693
Número medio de caracteres nun rexistro, unidades. — 278,297
Desviación estándar de caracteres nun rexistro, pcs. — 15,510
Número mínimo de caracteres nunha entrada, pcs. —198
Número máximo de caracteres nunha entrada, pcs. — 363
2. Parte introdutoria. Normas básicas
Durante a análise da base de datos especificada, formouse unha tarefa para especificar os requisitos para o grao de depuración, xa que, como está claro para todos, a base de datos especificada crea consecuencias legais e económicas para os usuarios. Durante o traballo, resultou que non había requisitos específicos para o grao de limpeza de big data. Analizando as normas xurídicas nesta materia, cheguei á conclusión de que todas están formadas a partir de posibilidades. É dicir, apareceu unha determinada tarefa, recompílanse fontes de información para a tarefa, despois fórmase un conxunto de datos e, en función do conxunto de datos creado, utilízanse ferramentas para resolver o problema. As solucións resultantes son puntos de referencia para escoller entre alternativas. Presentei isto na figura 1.
Dado que, en materia de determinación de estándares, é preferible confiar en tecnoloxías probadas, escollín os requisitos establecidos en , porque considerei este documento o máis completo para esta cuestión. En particular, neste documento a sección di "Hai que ter en conta que os requisitos de integridade dos datos aplícanse por igual aos datos manuais (en papel) e electrónicos". (tradución: “... os requisitos de integridade dos datos aplícanse por igual aos datos manuais (en papel) e electrónicos”). Esta formulación está asociada de xeito bastante específico ao concepto de “proba escrita”, no disposto no artigo 71 do Código de axuizamento civil, art. 70 CAS, Art. 75 APC, “por escrito” Art. 84 Código de axuizamento civil.
A figura 2 presenta un diagrama da formación dos enfoques dos tipos de información na xurisprudencia.
Arroz. 2. Fonte .
A Figura 3 mostra o mecanismo da Figura 1, para as tarefas da "Orientación" anterior. Facendo unha comparación, é doado ver que os enfoques utilizados para cumprir os requisitos de integridade da información nos estándares modernos para sistemas de información son significativamente limitados en comparación co concepto legal de información.
Fig. 3
No documento especificado (Orientación), a conexión coa parte técnica, as capacidades para procesar e almacenar datos, está ben confirmada por unha cita do capítulo 18.2. Base de datos relacional: "Esta estrutura de ficheiros é inherentemente máis segura, xa que os datos consérvanse nun formato de ficheiro grande que preserva a relación entre os datos e os metadatos".
De feito, neste enfoque -a partir das capacidades técnicas existentes, non hai nada anormal e, en si mesmo, trátase dun proceso natural, xa que a expansión dos conceptos provén da actividade máis estudada - o deseño de bases de datos. Pero, por outra banda, aparecen normas legais que non contemplan descontos nas capacidades técnicas dos sistemas existentes, por exemplo: .
Arroz. 4. Funil de capacidades técnicas ().
Nestes aspectos, queda claro que o conxunto de datos orixinal (Fig. 1) terá que, en primeiro lugar, ser gardado e, en segundo lugar, ser a base para extraer información adicional del. Ben, a modo de exemplo: as cámaras que gravan as normas de tráfico son omnipresentes, os sistemas de procesamento de información eliminan os infractores, pero tamén se pode ofrecer outra información a outros consumidores, por exemplo, como o seguimento de mercadotecnia da estrutura do fluxo de clientes a un centro comercial. E esta é unha fonte de valor engadido adicional cando se usa BigDat. É moi posible que os conxuntos de datos que se recollen agora, nalgún lugar do futuro, teñan un valor segundo un mecanismo similar ao valor das edicións raras de 1700 na actualidade. Despois de todo, de feito, os conxuntos de datos temporais son únicos e é improbable que se repitan no futuro.
3. Parte introdutoria. Criterios de avaliación
Durante o proceso de procesamento, desenvolveuse a seguinte clasificación de erros.
1. Clase de erro (baseada en GOST R 8.736-2011): a) erros sistemáticos; b) erros aleatorios; c) un erro.
2. Por multiplicidade: a) distorsión mono; b) multidistorsión.
3. Segundo a criticidade das consecuencias: a) crítica; b) non crítica.
4. Por fonte de aparición:
A) Técnicos: erros que se producen durante o funcionamento do equipo. Un erro bastante relevante para sistemas IoT, sistemas cun grao de influencia importante na calidade da comunicación, equipos (hardware).
B) Erros do operador: erros nunha ampla gama, desde erros tipográficos do operador durante a entrada ata erros nas especificacións técnicas para o deseño da base de datos.
C) Erros do usuario: aquí están os erros do usuario en todo o intervalo de "esquecín cambiar o deseño" ata confundir metros con pés.
5. Separados nunha clase separada:
a) a “tarefa do separador”, é dicir, o espazo e “:” (no noso caso) cando se duplicou;
b) palabras escritas xuntas;
c) sen espazo despois dos caracteres de servizo
d) Símbolos simétricamente múltiples: (), "", "...".
En conxunto, coa sistematización dos erros da base de datos que se presenta na Figura 5, fórmase un sistema de coordenadas bastante eficaz para buscar erros e desenvolver un algoritmo de limpeza de datos para este exemplo.
Arroz. 5. Erros típicos correspondentes ás unidades estruturais da base de datos (Fonte: ).
Precisión, integridade do dominio, tipo de datos, coherencia, redundancia, integridade, duplicación, conformidade coas regras comerciais, definición estrutural, anomalía dos datos, claridade, puntualidade, cumprimento das regras de integridade dos datos. (Páxina 334. Fundamentos de almacenamento de datos para profesionais de TI / Paulraj Ponniah.—2ª ed.)
Presentouse a redacción en inglés e a tradución automática rusa entre corchetes.
Precisión. O valor almacenado no sistema para un elemento de datos é o valor correcto para esa aparición do elemento de datos. Se tes un nome de cliente e un enderezo almacenado nun rexistro, entón o enderezo é o enderezo correcto para o cliente con ese nome. Se atopa a cantidade pedida como 1000 unidades no rexistro do número de pedido 12345678, entón esa cantidade é a cantidade exacta para ese pedido.
[Precisión. O valor almacenado no sistema para un elemento de datos é o valor correcto para esa aparición do elemento de datos. Se tes un nome e enderezo de cliente almacenados nun rexistro, entón o enderezo é o enderezo correcto para o cliente con ese nome. Se atopa a cantidade pedida como 1000 unidades no rexistro do número de pedido 12345678, esa cantidade é a cantidade exacta para ese pedido.]
Integridade do dominio. O valor de datos dun atributo cae no intervalo de valores permitidos e definidos. O exemplo común é que os valores permitidos son "masculino" e "feminino" para o elemento de datos de xénero.
[Integridade do dominio. O valor dos datos do atributo está dentro do intervalo de valores válidos e definidos. Un exemplo xeral son os valores válidos "masculino" e "feminino" para un elemento de datos de xénero.]
Tipo de datos. O valor dun atributo de datos almacénase realmente como o tipo de datos definido para ese atributo. Cando o tipo de datos do campo do nome da tenda se define como "texto", todas as instancias dese campo conteñen o nome da tenda que se mostra en formato textual e non en códigos numéricos.
[Tipo de datos. O valor dun atributo de datos almacénase realmente como o tipo de datos definido para ese atributo. Se o tipo de datos do campo do nome da tenda se define como "texto", todas as instancias deste campo conteñen o nome da tenda que se mostra en formato de texto en lugar de códigos numéricos.]
Consistencia. A forma e o contido dun campo de datos é o mesmo en varios sistemas de orixe. Se o código do produto ABC nun sistema é 1234, entón o código deste produto é 1234 en todos os sistemas fonte.
[Coherencia. A forma e o contido do campo de datos son os mesmos en diferentes sistemas de orixe. Se o código do produto ABC nun sistema é 1234, entón o código para ese produto é 1234 en cada sistema fonte.]
Redundancia. Os mesmos datos non deben almacenarse en máis dun lugar dun sistema. Se, por razóns de eficiencia, un elemento de datos se almacena intencionadamente en máis dun lugar dun sistema, entón a redundancia debe identificarse e verificarse claramente.
[Redundancia. Os mesmos datos non deben almacenarse en máis dun lugar do sistema. Se, por razóns de eficiencia, un elemento de datos se almacena intencionalmente en varias localizacións dun sistema, entón a redundancia debe estar claramente definida e verificada.]
Completar. Non hai valores que faltan para un determinado atributo no sistema. Por exemplo, nun ficheiro de cliente, debe haber un valor válido para o campo "estado" para cada cliente. No ficheiro de detalles do pedido, todos os rexistros de detalles dun pedido deben cubrirse completamente.
[Completezza. Non hai valores que faltan no sistema para este atributo. Por exemplo, o ficheiro do cliente debe ter un valor válido para o campo "estado" de cada cliente. No ficheiro de detalles do pedido, cada rexistro de detalles do pedido debe completarse completamente.]
Duplicación. A duplicación de rexistros nun sistema está completamente resolta. Se se sabe que o ficheiro do produto ten rexistros duplicados, identifícanse todos os rexistros duplicados de cada produto e créase unha referencia cruzada.
[Duplicar. Eliminouse por completo a duplicación de rexistros no sistema. Se se sabe que un ficheiro de produto contén entradas duplicadas, identificaranse todas as entradas duplicadas de cada produto e créase unha referencia cruzada.]
Conformidade ás regras comerciais. Os valores de cada elemento de datos adhírense ás regras comerciais prescritas. Nun sistema de poxa, o prezo de martelo ou de venda non pode ser inferior ao prezo de reserva. Nun sistema de préstamo bancario, o saldo do préstamo debe ser sempre positivo ou cero.
[Cumprimento das normas comerciais. Os valores de cada elemento de datos cumpren as regras comerciais establecidas. Nun sistema de poxa, o prezo de martelo ou de venda non pode ser inferior ao prezo de reserva. Nun sistema de crédito bancario, o saldo do préstamo sempre debe ser positivo ou cero.]
Definición estrutural. Sempre que un elemento de datos poida estruturarse naturalmente en compoñentes individuais, o elemento debe conter esta estrutura ben definida. Por exemplo, o nome dunha persoa divídese naturalmente en nome, inicial do segundo e apelido. Os valores dos nomes das persoas deben almacenarse como nome, inicial do segundo e apelido. Esta característica da calidade dos datos simplifica a aplicación dos estándares e reduce os valores perdidos.
[Certeza estrutural. Cando un elemento de datos pode estruturarse naturalmente en compoñentes individuais, o elemento debe conter esta estrutura ben definida. Por exemplo, o nome dunha persoa divídese naturalmente en nome, inicial do segundo e apelido. Os valores dos nomes individuais deben almacenarse como nome, inicial do segundo e apelido. Esta característica de calidade dos datos simplifica a aplicación de estándares e reduce os valores que faltan.]
Anomalía de datos. Un campo debe usarse só para o propósito para o que está definido. Se o campo Enderezo-3 está definido para calquera terceira liña de enderezo posible para enderezos longos, entón este campo debe usarse só para rexistrar a terceira liña de enderezo. Non debe utilizarse para introducir un número de teléfono ou fax para o cliente.
[Anomalía de datos. Un campo só debe usarse para o propósito para o que está definido. Se o campo Enderezo-3 está definido para calquera terceira liña de enderezo posible para enderezos longos, entón este campo só se utilizará para rexistrar a terceira liña de enderezo. Non se debe usar para introducir un número de teléfono ou fax dun cliente.]
Claridade. Un elemento de datos pode posuír todas as outras características dos datos de calidade, pero se os usuarios non entenden claramente o seu significado, entón o elemento de datos non ten ningún valor para os usuarios. As convencións de nomenclatura adecuadas axudan a que os usuarios sexan ben entendidos polos elementos de datos.
[Claridade. Un elemento de datos pode ter todas as outras características de bos datos, pero se os usuarios non entenden claramente o seu significado, entón o elemento de datos non ten ningún valor para os usuarios. As convencións de nomenclatura correctas axudan a que os usuarios comprendan ben os elementos de datos.]
Oportuno. Os usuarios determinan a actualidade dos datos. Se os usuarios esperan que os datos da dimensión do cliente non sexan máis antigos dun día, os cambios nos datos do cliente nos sistemas de orixe deben aplicarse ao almacén de datos diariamente.
[De forma oportuna. Os usuarios determinan a actualidade dos datos. Se os usuarios esperan que os datos das dimensións do cliente non teñan máis dun día de antigüidade, os cambios nos datos do cliente nos sistemas de orixe deberían aplicarse ao almacén de datos a diario.]
Utilidade. Cada elemento de datos do almacén de datos debe satisfacer algúns requisitos da recollida de usuarios. Un elemento de datos pode ser preciso e de alta calidade, pero se non ten ningún valor para os usuarios, entón é totalmente innecesario que ese elemento de datos estea no almacén de datos.
[Utilidade. Cada elemento de datos do almacén de datos debe satisfacer algúns requisitos da recollida de usuarios. Un elemento de datos pode ser preciso e de alta calidade, pero se non proporciona valor aos usuarios, non é necesario que ese elemento de datos estea no almacén de datos.]
Cumprimento das regras de integridade de datos. Os datos almacenados nas bases de datos relacionais dos sistemas fonte deben aterse ás regras de integridade da entidade e integridade referencial. Calquera táboa que permita nulo como clave principal non ten integridade de entidade. A integridade referencial obriga a establecer correctamente as relacións entre pais e fillos. Nunha relación cliente a pedido, a integridade referencial garante a existencia dun cliente para cada pedido da base de datos.
[Cumprimento das normas de integridade de datos. Os datos almacenados en bases de datos relacionais dos sistemas fonte deben cumprir as regras de integridade da entidade e integridade referencial. Calquera táboa que permita nulo como clave principal non ten integridade de entidade. A integridade referencial obriga a establecer correctamente a relación entre pais e fillos. Nunha relación cliente-pedido, a integridade referencial garante que exista un cliente para cada pedido da base de datos.]
4. Calidade da limpeza de datos
A calidade da limpeza de datos é un problema bastante problemático en bigdata. Responder á pregunta de que grao de limpeza de datos é necesario para completar a tarefa é fundamental para todo analista de datos. Na maioría dos problemas actuais, cada analista o determina por si mesmo e é improbable que alguén de fóra sexa capaz de avaliar este aspecto na súa solución. Pero para a tarefa que nos ocupa neste caso, esta cuestión era extremadamente importante, xa que a fiabilidade dos datos legais debería tender a un.
Considerando tecnoloxías de proba de software para determinar a fiabilidade operativa. Hoxe hai máis que estes modelos . Moitos dos modelos usan un modelo de servizo de reclamacións:
Fig 6
Pensando do seguinte xeito: "Se o erro atopado é un evento similar ao evento de falla neste modelo, entón como atopar un análogo do parámetro t?" E compilei o seguinte modelo: Imaxinemos que o tempo que tarda un probador en comprobar un rexistro é de 1 minuto (para a base de datos en cuestión), entón para atopar todos os erros necesitará 365 minutos, o que é aproximadamente 494 anos e 3 meses de tempo de traballo. Segundo entendemos, esta é unha cantidade de traballo moi grande e os custos de comprobar a base de datos serán prohibitivos para o compilador desta base de datos. Nesta reflexión aparece o concepto económico dos custos e tras a análise cheguei á conclusión de que se trata dunha ferramenta bastante eficaz. Baseándose na lei da economía: “O volume de produción (en unidades) no que se consegue o máximo beneficio dunha empresa sitúase no punto no que o custo marxinal de producir unha nova unidade de produción se compara co prezo que esta empresa pode recibir. para unha nova unidade”. Partindo do postulado de que atopar cada erro posterior require cada vez máis verificación dos rexistros, este é un factor de custo. É dicir, o postulado adoptado nos modelos de proba adquire un significado físico no seguinte patrón: se para atopar o erro i-ésimo era necesario comprobar n rexistros, entón para atopar o seguinte erro (i+3) será necesario. para comprobar m rexistros e ao mesmo tempo n
- Cando se estabiliza o número de rexistros comprobados antes de atopar un novo erro;
- Cando o número de rexistros comprobados antes de atopar o seguinte erro aumentará.
Para determinar o valor crítico recorreime ao concepto de viabilidade económica, que neste caso, empregando o concepto de custos sociais, pode formularse do seguinte xeito: “Os custos da corrección do erro deben ser asumidos polo axente económico que poida facer co menor custo". Temos un axente: un probador que pasa 1 minuto comprobando un rexistro. En termos monetarios, se gañas 6000 rublos/día, isto será de 12,2 rublos. (aproximadamente hoxe). Queda por determinar o segundo lado do equilibrio no dereito económico. Razonei así. Un erro existente esixirá que a persoa interesada faga esforzos para corrixilo, é dicir, o propietario. Digamos que isto require 1 día de acción (enviar unha solicitude, recibir un documento corrixido). Logo, desde o punto de vista social, os seus custos serán iguais ao salario medio diario. Salario medio acumulado en Khanty-Mansi Autonomous Okrug 73285 fregar. ou 3053,542 rublos/día. En consecuencia, obtemos un valor crítico igual a:
3053,542: 12,2 = 250,4 unidades de rexistros.
Isto significa, desde o punto de vista social, se un probador comprobou 251 rexistros e atopou un erro, equivale a que o usuario solucione este erro por si mesmo. En consecuencia, se o probador pasou un tempo igual a comprobar 252 rexistros para atopar o seguinte erro, neste caso é mellor transferir o custo da corrección ao usuario.
Preséntase aquí un enfoque simplificado, xa que dende o punto de vista social é necesario ter en conta todo o valor adicional que xera cada especialista, é dicir, os custos tendo en conta os impostos e as pagas sociais, pero o modelo é claro. Consecuencia desta relación é o seguinte requisito para os especialistas: un especialista do sector informático debe ter un salario superior á media nacional. Se o seu salario é inferior ao salario medio dos potenciais usuarios da base de datos, entón el mesmo debe comprobar a base de datos enteira corpo a corpo.
Cando se utiliza o criterio descrito, fórmase o primeiro requisito para a calidade da base de datos:
eu (tr). A proporción de erros críticos non debe superar 1/250,4 = 0,39938%. Un pouco menos que ouro na industria. E en termos físicos non hai máis de 1459 rexistros con erros.
Retroceso económico.
De feito, ao cometer tal número de erros nos rexistros, a sociedade acepta perdas económicas por importe de:
1459*3053,542 = 4 rublos.
Esta cantidade vén determinada polo feito de que a sociedade non dispón das ferramentas para reducir estes custos. Polo tanto, se alguén dispón dunha tecnoloxía que lle permita reducir o número de rexistros con erros a, por exemplo, 259, isto permitirá que a sociedade aforre:
1200*3053,542 = 3 rublos.
Pero ao mesmo tempo, pode pedir o seu talento e traballo, bo, digamos: 1 millón de rublos.
É dicir, os custos sociais redúcense por:
3 – 664 = 250 rublos.
En esencia, este efecto é o valor engadido do uso das tecnoloxías BigDat.
Pero aquí hai que ter en conta que se trata dun efecto social, e o propietario da base de datos son as autoridades municipais, os seus ingresos polo uso dos bens rexistrados nesta base de datos, a unha taxa do 0,3%, son: 2,778 millóns de rublos/ ano. E estes custos (4 rublos) non lle molestan moito, xa que son transferidos aos propietarios. E, neste aspecto, o desenvolvedor de tecnoloxías máis refinadas en Bigdata terá que demostrar a capacidade de convencer ao propietario desta base de datos, e tales cousas requiren un talento considerable.
Neste exemplo, elixiuse o algoritmo de avaliación de erros baseándose no modelo de Schumann [2] de verificación de software durante as probas de funcionamento sen fallos. Pola súa prevalencia en Internet e a capacidade de obter os indicadores estatísticos necesarios. A metodoloxía está tomada de Monakhov Yu.M. "Estabilidade funcional dos sistemas de información", ver debaixo do spoiler na Fig. 7-9.
Arroz. 7 – 9 Metodoloxía do modelo Schumann
A segunda parte deste material presenta un exemplo de limpeza de datos, no que se obteñen os resultados da utilización do modelo de Schumann.
Permítanme presentar os resultados obtidos:
Número estimado de erros N = 3167 n.
Parámetro C, lambda e función de fiabilidade:
Fig. 17
Esencialmente, a lambda é un indicador real da intensidade coa que se detectan os erros en cada etapa. Se observas a segunda parte, a estimación deste indicador foi de 42,4 erros por hora, o que é bastante comparable ao indicador Schumann. Arriba, determinouse que a taxa á que un desenvolvedor atopa erros non debe ser inferior a 1 erro por cada 250,4 rexistros, ao comprobar 1 rexistro por minuto. De aí o valor crítico de lambda para o modelo de Schumann:
60 / 250,4 = 0,239617.
É dicir, a necesidade de realizar trámites de detección de erros debe realizarse ata que a lambda, do 38,964 existente, diminúa a 0,239617.
Ou ata que o indicador N (número potencial de erros) menos n (número de erros corrixido) diminúe por debaixo do noso limiar aceptado - 1459 unidades.
Literatura
- Monakhov, Yu. M. Estabilidade funcional dos sistemas de información. En 3 horas Parte 1. Fiabilidade do software: libro de texto. subsidio / Yu. M. Monakhov; Vladim. estado univ. – Vladimir: Izvo Vladim. estado Universidade, 2011. – 60 p. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, "Modelos probabilísticos para a predición da fiabilidade do software".
- Fundamentos de almacenamento de datos para profesionais de TI / Paulraj Ponniah.—2ª ed.
Fonte: www.habr.com