Get best of the week

Limpeza de dados, como o jogo "Pedra, Tesoura, Papel". É um jogo com ou sem acabamento? Parte 1. Teórica

1. Os dados de origem


A limpeza de dados é um dos desafios enfrentados pelas tarefas de análise de dados. Esse material refletiu os desenvolvimentos, decisões que surgiram como resultado da solução do problema prático de analisar o banco de dados durante a formação do valor cadastral. As fontes aqui são "RELATÓRIO Nº 01 / -2019 sobre os resultados da avaliação cadastral do estado de todos os tipos de imóveis (exceto terrenos) no Okrug autônomo de Khanty-Mansiysk - Ugra" .

O arquivo “Modelo comparativo total.ods” foi considerado no “Apêndice B. Resultados da determinação da COP 5. Informações sobre o método para determinar o valor cadastral 5.1 Abordagem comparativa”.

Tabela 1. Indicadores estatísticos do conjunto de dados no arquivo “Modelo Comparativo Total.ods”
Número total de campos, pcs. - 44
Número total de registros - 365.490
O número total de caracteres, pcs. - 101,714,693 O
número médio de caracteres em um registro, pcs. - 278,297
Desvio padrão de caracteres no registro, pcs. - 15.510
O número mínimo de caracteres no registro, pcs. - 198 O
número máximo de caracteres no registro, pcs. - 363

2. Parte introdutória. Padrões básicos


Seguindo a análise do banco de dados indicado, foi criada uma tarefa para especificar os requisitos para o grau de purificação, pois, como todos entendem, esse banco de dados constitui as conseqüências legais e econômicas para os usuários. No processo, descobriu-se que nenhum requisito específico para o grau de purificação de big data foi formado. Analisando as normas legais nesta matéria, cheguei à conclusão de que todas são formadas a partir de oportunidades. Ou seja, uma determinada tarefa apareceu, as fontes de informações são concluídas para a tarefa e, em seguida, um conjunto de dados é formado e, com base no conjunto de dados criado, ferramentas para resolver o problema. As soluções obtidas são pontos de referência na escolha de alternativas. Apresentado na Figura 1.



Como é preferível confiar em tecnologias comprovadas na determinação de padrões, escolhi os critérios de análise como base para os requisitos estabelecidos nas Definições e Orientações para a Indústria do MHRA GxP para Indústria , porque considerei este documento o mais holístico para esse problema. Em particular, a seção deste documento diz "Deve-se observar que os requisitos de integridade de dados se aplicam igualmente aos dados manuais (em papel) e eletrônicos". (trad. "... os requisitos de integridade de dados se aplicam igualmente aos dados manuais (em papel) e eletrônicos"). Essa redação está associada especificamente ao conceito de “evidência escrita”, nas normas do artigo 71 do Código de Processo Civil, artigo 70 CAS, Art. 75 AIC, "escrevendo" art. 84 GIC.

A Figura 2 apresentou um diagrama da formação de abordagens para os tipos de informações em jurisprudência.


FIG. 2. Fonte aqui .

A Figura 3 mostra o mecanismo da Figura 1, para as tarefas da “Orientação” acima. Ao comparar, é fácil ver que as abordagens usadas, ao atender aos requisitos de integridade das informações, nos padrões modernos para sistemas de informação, são significativamente limitadas em comparação com o conceito legal de informação.


Fig.3

No documento indicado (Orientação), o link para a parte técnica, as capacidades de processamento e armazenamento dos dados, é bem confirmado pela citação do capítulo 18.2. Banco de dados relacional: "Essa estrutura de arquivo é inerentemente mais segura, pois os dados são mantidos em um formato de arquivo grande que preserva o relacionamento entre dados e metadados."

De fato, nessa abordagem - pelas capacidades técnicas existentes, não há nada normal e, por si só, é um processo natural, pois a expansão de conceitos advém da atividade mais estudada - o design de bancos de dados. Mas, por outro lado, aparecem normas legais que não oferecem descontos nas capacidades técnicas dos sistemas existentes, por exemplo: GDPR - Regulamento Geral de Proteção de Dados .


FIG. 4. Funil de recursos técnicos ( fonte ).

Nesses aspectos, fica claro que o conjunto de dados inicial (Fig. 1) deverá ser preservado, antes de tudo e, em segundo lugar, ser a base para extrair informações adicionais dele. Bem, como exemplo: as câmeras de fixação SDA são difundidas, os sistemas de processamento de informações filtram os infratores, mas outras informações também podem ser oferecidas a outros consumidores, por exemplo, como monitoramento de marketing da estrutura do fluxo de clientes para o shopping. E essa é uma fonte de valor agregado adicional ao usar o Bigdat. É inteiramente concebível que os conjuntos de dados que estão sendo montados agora, em algum lugar no futuro, tenham valor por um mecanismo semelhante ao valor de livros raros da década de 1700 atualmente. De fato, de fato, conjuntos de dados temporários são únicos e dificilmente serão repetidos no futuro.

3. Parte introdutória. Critério de avaliação


Durante o processamento, a seguinte classificação de erros foi desenvolvida.

1. Classe de erro (com base no GOST R 8.736-2011): a) erros sistemáticos; b) erros aleatórios; c) um erro grave.

2. Por multiplicidade: a) mono-distorção; b) multi-distorção.

3. De acordo com a criticidade das consequências: a) crítica; b) não é crítico.

4. Pela fonte da ocorrência:

A) Técnico - erros que surgem durante a operação do equipamento. Um erro bastante atual para sistemas de IoT, sistemas com um grau significativo de influência na qualidade da comunicação, equipamentos (hardware).

B) Operador - erros em uma ampla gama, desde erros tipográficos do operador durante a entrada até erros nas especificações técnicas para o design do banco de dados.

C) Personalizado - aqui estão os erros do usuário em todo o intervalo, desde "esqueci de mudar o layout" até o que os medidores levaram para os pés.

5. Selecionados em uma classe separada:

a) a “tarefa separadora”, ou seja, o espaço e “:” (no nosso caso) quando duplicada;
b) palavras todas em uma peça;
c) a ausência de um espaço após os caracteres de serviço
; d) caracteres simétricos-plurais: (), "", "...".

Em conjunto, com a sistematização dos erros do banco de dados apresentados na Figura 5, um sistema de coordenadas suficientemente eficaz é formado para pesquisar erros e desenvolver um algoritmo para limpeza de dados, para este exemplo.


FIG. 5. Erros típicos correspondentes às unidades estruturais do banco de dados (Fonte: Oreshkov VI, Paklin NB “Principais conceitos de consolidação de dados” ).

Precisão, Integridade do Domínio, Tipo de Dados, Consistência, Redundância, Completude, Duplicação, Conformidade com Regras de Negócios, Estrutural Definição, anomalia de dados, clareza, pontualidade, aderência às regras de integridade de dados. (Página 334. Fundamentos de data warehousing para profissionais de TI / Paulraj Ponniah. - 2ª ed.)

Apresentou formulações em inglês e tradução automática no idioma russo entre parênteses.

Precisão O valor armazenado no sistema para um elemento de dados é o valor correto para essa ocorrência do elemento de dados. Se você tiver um nome de cliente e um endereço armazenados em um registro, o endereço será o endereço correto para o cliente com esse nome. Se você encontrar a quantidade solicitada como 1000 unidades no registro do número de pedido 12345678, essa quantidade é a quantidade exata para esse pedido.
[Precisão. O valor armazenado no sistema para o item de dados é o valor correto para esta ocorrência do item de dados. Se você tiver um nome de cliente e o endereço armazenado no registro, o endereço será o endereço correto para o cliente com esse nome. Se você encontrar a quantidade solicitada como 1000 unidades na entrada do número de pedido 12345678, essa quantidade é a quantidade exata desse pedido.]

Integridade de Domínio O valor dos dados de um atributo cai no intervalo de valores definidos permitidos. O exemplo comum são os valores permitidos sendo "masculino" e "feminino" para o elemento de dados de gênero.
[Integridade de domínio. O valor dos dados do atributo cai no intervalo de valores definidos e válidos. Um exemplo comum são os valores masculinos e femininos válidos para um item de dados de gênero.]

Tipo de Dados. O valor para um atributo de dados é realmente armazenado como o tipo de dados definido para esse atributo. Quando o tipo de dados do campo de nome da loja é definido como "texto", todas as instâncias desse campo contêm o nome da loja mostrado em formato de texto e não em códigos numéricos.
[Tipo de dados. O valor do atributo de dados é realmente armazenado como o tipo de dados definido para este atributo. Se o tipo de dados do campo de nome da loja for definido como "texto", todas as instâncias desse campo conterão o nome da loja exibido no formato de texto e não nos códigos numéricos.]

Consistência. A forma e o conteúdo de um campo de dados são os mesmos em vários sistemas de origem. Se o código do produto ABC em um sistema for 1234, o código desse produto será 1234 em todos os sistemas de origem.
[Consistência. A forma e o conteúdo do campo de dados são os mesmos em diferentes sistemas de origem. Se o código do produto para um produto ABC em um sistema for 1234, o código para este produto será 1234 em cada sistema de origem.]

Redundância. Os mesmos dados não devem ser armazenados em mais de um local em um sistema. Se, por razões de eficiência, um elemento de dados for intencionalmente armazenado em mais de um local do sistema, a redundância deverá ser claramente identificada e verificada.
[Redundância. Os mesmos dados não devem ser armazenados em mais de um local no sistema. Se, por razões de eficiência, o elemento de dados for intencionalmente armazenado em vários locais do sistema, a redundância deverá ser claramente definida e verificada.]

Completude. Não há valores ausentes para um determinado atributo no sistema. Por exemplo, em um arquivo do cliente, deve haver um valor válido para o campo "state" para cada cliente. No arquivo para obter detalhes do pedido, todos os registros de detalhes de um pedido devem ser completamente preenchidos.
[Completude. Não há valores ausentes para este atributo no sistema. Por exemplo, o arquivo do cliente deve ter um valor válido para o campo "state" para cada cliente. No arquivo de detalhes do pedido, cada registro de detalhes do pedido deve ser totalmente preenchido.]

Duplicação. A duplicação de registros em um sistema é completamente resolvida. Se o arquivo do produto tiver registros duplicados, todos os registros duplicados para cada produto serão identificados e uma referência cruzada será criada.
[Duplicação. A duplicação de entradas no sistema é completamente eliminada. Se for sabido que o arquivo do produto contém entradas duplicadas, todas as entradas duplicadas para cada produto são identificadas e com referência cruzada.]

Conformidade com as regras de negócios. Os valores de cada item de dados seguem as regras de negócios prescritas. Em um sistema de leilão, o preço do martelo ou da venda não pode ser menor que o preço de reserva. Em um sistema de empréstimo bancário, o saldo do empréstimo deve sempre ser positivo ou zero.
[Conformidade com as regras de negócios. Os valores de cada item de dados estão de acordo com as regras de negócios estabelecidas. Em um sistema de leilão, o preço de um martelo ou venda não pode ser menor que o preço de reserva. Em um sistema de crédito bancário, o saldo do crédito sempre deve ser positivo ou zero.]

Definição estrutural. Sempre que um item de dados pode ser estruturado naturalmente em componentes individuais, o item deve conter essa estrutura bem definida. Por exemplo, o nome de um indivíduo naturalmente se divide em nome, inicial do meio e sobrenome. Os valores para nomes de indivíduos devem ser armazenados como nome, inicial do meio e sobrenome. Essa característica da qualidade dos dados simplifica a aplicação de padrões e reduz os valores ausentes.
[Certeza estrutural. Onde um elemento de dados pode ser naturalmente estruturado em componentes separados, o elemento deve conter essa estrutura bem definida. Por exemplo, o nome de uma pessoa é naturalmente dividido em nome, inicial do meio e sobrenome. Os valores para os nomes dos indivíduos devem ser armazenados como nome, inicial do meio e sobrenome. Esse recurso de qualidade dos dados simplifica a aplicação de padrões e reduz os valores ausentes.]

Anomalia de dados. Um campo deve ser usado apenas para a finalidade para a qual está definido. Se o campo Endereço-3 for definido para qualquer terceira linha de endereço possível para endereços longos, esse campo deverá ser usado apenas para registrar a terceira linha de endereço. Não deve ser usado para inserir um número de telefone ou fax para o cliente.
[Anomalia de dados. O campo deve ser usado apenas para a finalidade para a qual está definido. Se o campo Endereço-3 for definido para qualquer terceira linha de endereço possível para endereços longos, esse campo deverá ser usado apenas para registrar a terceira linha de endereço. Não deve ser usado para inserir um número de telefone ou fax para um cliente.]

Clareza. Um elemento de dados pode possuir todas as outras características dos dados de qualidade, mas se os usuários não entenderem claramente seu significado, o elemento de dados não terá valor para os usuários. Convenções de nomenclatura adequadas ajudam a tornar os elementos de dados bem compreendidos pelos usuários.
[Clareza. Um elemento de dados pode possuir todas as outras características dos dados de qualidade, mas se os usuários não entenderem claramente seu significado, o elemento de dados não será valioso para os usuários. As convenções de nomenclatura adequadas ajudam a tornar os elementos de dados bem compreendidos pelos usuários.] Em tempo

hábil. Os usuários determinam a pontualidade dos dados. Se os usuários esperam que os dados da dimensão do cliente não tenham mais de um dia, as alterações nos dados do cliente nos sistemas de origem devem ser aplicadas diariamente ao data warehouse.
[Em tempo hábil. Os usuários determinam a pontualidade dos dados. se os usuários esperarem que os dados de medição do cliente não tenham mais de um dia, as alterações nos dados do cliente nos sistemas de origem devem ser aplicadas diariamente ao data warehouse.]

Utilidade Todo elemento de dados no armazém de dados deve atender a alguns requisitos da coleção de usuários. Um elemento de dados pode ser preciso e de alta qualidade, mas se não tiver valor para os usuários, é totalmente desnecessário que esse elemento esteja no armazém de dados.
[Utilitário. Cada item de dados no armazém de dados deve atender a alguns requisitos da coleção de usuários. Um item de dados pode ser preciso e de alta qualidade, mas se não for de valor para os usuários, não será necessário que o item de dados esteja no armazém de dados.]

Adesão às regras de integridade de dados. Os dados armazenados nos bancos de dados relacionais dos sistemas de origem devem aderir às regras de integridade da entidade e de integridade referencial. Qualquer tabela que permita nulo como chave primária não possui integridade da entidade. A integridade referencial força o estabelecimento dos relacionamentos pai - filho corretamente. Em um relacionamento cliente-pedido, a integridade referencial garante a existência de um cliente para cada pedido no banco de dados.
[Conformidade com as regras de integridade de dados. Os dados armazenados nos bancos de dados relacionais dos sistemas de origem devem obedecer às regras de integridade da entidade e integridade referencial. Qualquer tabela que permita nulo como chave primária não possui integridade da entidade. A integridade referencial força o estabelecimento do relacionamento correto entre pais e filhos. Em um relacionamento de pedido do cliente, a integridade referencial garante a existência de um cliente para cada pedido no banco de dados.]

4. A qualidade da limpeza de dados


A qualidade da limpeza de dados é uma questão bastante problemática no bigdata. Para responder à pergunta que grau de limpeza de dados é necessário ao executar a tarefa, é básico para todo analista de dados. Na maioria das tarefas atuais, cada analista estabelece isso sozinho e é improvável que alguém de fora seja capaz de avaliar esse aspecto em sua decisão. Mas, para esta tarefa, neste caso, essa pergunta foi extremamente importante, pois a confiabilidade dos dados legais deve tender a se unir.

Considerando as tecnologias de teste de software para determinar a confiabilidade no trabalho. Hoje, existem mais de 200 desses modelos . Muitos dos modelos usam o modelo de serviço de aplicativo:


Fig. 6

Pensando da seguinte forma: “Se o erro encontrado for um evento semelhante ao evento de falha neste modelo, como encontrar um análogo do parâmetro t?” E fiz o seguinte modelo: imagine que o tempo que leva para um testador verificar um registro é de 1 minuto (para o banco de dados em questão) e, para encontrar todos os erros, serão necessários 365.494 minutos, que são aproximadamente 3 anos e 3 meses de tempo de trabalho. Como entendemos, isso não é uma quantidade muito pequena de trabalho e os custos de verificação do banco de dados serão insuportáveis ​​para o compilador desse banco de dados. Nessa reflexão, surge o conceito econômico de custos e, após análise, conclui-se que essa é uma ferramenta bastante eficaz. Com base na lei da economia: “O volume de produção (em unidades) em que o lucro máximo da empresa é alcançado,"está localizado no ponto em que o custo marginal de produção de uma nova unidade de produção é comparado com o preço que essa empresa pode receber por uma nova unidade". Baseando-se no postulado de que encontrar cada erro subsequente exige cada vez mais verificação de registros, esse é um fator de custo. Ou seja, o postulado adotado nos modelos de teste faz sentido fisicamente, na seguinte regularidade: se, para encontrar o i-ésimo erro, era necessário verificar n registros, para encontrar o próximo erro (i + 1), já seria necessário verificar m registros e n <m. Esse postulado, nos modelos de teste, é formulado principalmente pelo requisito de que os erros encontrados sejam corrigidos, mas não corrigidos, para que o software seja testado em seu estado natural, ou seja, o fluxo de falha é uniforme. Por conseguinte, para o nosso caso,A validação de registros pode mostrar duas variantes de uniformidade:

  1. ;
  2. .

Para determinar o valor crítico, ele se voltou para o conceito de viabilidade econômica, que neste caso, ao usar o conceito de custos sociais, pode ser formulado da seguinte forma: "O custo da correção do erro deve ser suportado pelo agente econômico que pode fazer isso pelo menor custo". Temos um agente - este é um testador que gasta 1 minuto na verificação de um registro. Em termos monetários, com ganhos de 6000 rublos / dia, isso representará 12,2 rublos. (aproximadamente hoje). Resta determinar o segundo lado do equilíbrio no direito econômico. Ele argumentou assim. O erro existente exigirá que alguém envolva esforços para corrigi-lo, ou seja, o proprietário da propriedade. Suponha que você precise de 1 dia de ação (inclua o aplicativo, obtenha o documento corrigido).Então, do ponto de vista público, seus custos serão iguais ao salário médio por dia. O salário médio acumulado no Okrug Autônomo de Khanty-Mansi"Resultados do desenvolvimento socioeconômico do Okrug autônomo de Khanty-Mansiysk - Ugra para janeiro-setembro de 2019" 73285 rublos. ou 3053.542 rublos / dia. Conseqüentemente, obtemos um valor crítico igual a:
3053.542: 12.2 = 250.4 unidades.

Isso significa, do ponto de vista público, se o testador verificou 251 entradas e encontrou um erro, isso é equivalente ao usuário que corrige esse erro por conta própria. Portanto, se o testador gastou o tempo igual à verificação de 252 registros para encontrar o próximo erro, nesse caso, é melhor transferir os custos de correção para o usuário.

Uma abordagem simplificada é apresentada aqui, pois, do ponto de vista público, é necessário levar em consideração todo o custo adicional gerado por cada especialista, isto é, custos incluindo impostos e pagamentos sociais, mas o modelo é claro. A conseqüência desse relacionamento é o seguinte requisito para especialistas: um especialista em TI deve ter um salário maior que a média nacional. Se o salário dele for menor que o salário médio dos usuários em potencial do banco de dados, ele próprio deve verificar todo o banco de dados em combate corpo a corpo.

Ao usar o critério descrito, o primeiro requisito para a qualidade do banco de dados é formado:
I (tr). A parcela de erros críticos não deve exceder 1 / 250,4 = 0,39938%. Um pouco menos que o refino de ouro na indústria. E em espécie, não mais que 1.459 entradas com erros.

Retiro econômico.

De fato, ao permitir esse número de erros nas entradas, a empresa concorda com perdas econômicas no valor de:

1.459 * 3.053.542 = 4.455.118 rublos.

Esse valor é determinado pelo fato de a empresa não possuir ferramentas para reduzir esses custos. Conclui-se que, se alguém desenvolve uma tecnologia que permite reduzir o número de registros com erros para, por exemplo, 259, isso permite que a sociedade economize:
1200 * 3053,542 = 3.664.250 rublos.

Mas, ao mesmo tempo, ele pode pedir seu talento e trabalho, digamos assim - 1 milhão de rublos.
Ou seja, os custos sociais são reduzidos em:

3 664 250 - 1 000 000 = 2 664 250 rublos.

De fato, esse efeito é o valor agregado do uso das tecnologias Bigdat.

Mas aqui deve-se ter em mente que isso é um efeito social, e como o proprietário do banco de dados é as autoridades municipais, sua receita com o uso de propriedades registradas nesse banco de dados a uma taxa de 0,3% é de: 2.788 bilhões de rublos / ano. E esses custos (4 455 118 rublos) não o incomodam muito, pois são transferidos para os proprietários da propriedade. E, nesse aspecto, o desenvolvedor de mais tecnologias de refino no Bigdata precisará mostrar a capacidade de convencer o proprietário desse banco de dados, e essas coisas precisam de talento considerável.

Neste exemplo, um algoritmo de estimativa de erro foi selecionado com base na verificação do software do modelo Schumann [2] ao testar a confiabilidade. Devido à sua prevalência na rede e à capacidade de obter os indicadores estatísticos necessários. A metodologia é retirada de Monks Yu.M. "Estabilidade funcional dos sistemas de informação", veja abaixo o spoiler na Fig. 7-9.

FIG. 7 - 9 Metodologia do Modelo Schumann






A segunda parte deste material apresenta um exemplo de limpeza de dados, no qual são obtidos os resultados do uso do modelo de Schuman.
Vou apresentar os resultados: O
número estimado de erros N = 3167 shN.
Parâmetro C, lambda e função de confiabilidade:


Fig.17

De fato, o lambda é um indicador real da intensidade com a qual erros são detectados em cada estágio. Se você observar, na segunda parte, a estimativa desse indicador foi de 42,4 erros por hora, o que é bastante comparável à figura de Schumann. Acima, foi determinado que a taxa de detecção de erros pelo desenvolvedor não deve ser inferior a 1 erro por 250,4 registros, enquanto verifica 1 registro por minuto. Daí o valor crítico de lambda para o modelo de Schumann:

60 / 250.4 = 0.239617.

Ou seja, a necessidade de procedimentos de localização de erros deve ser realizada até que o lambda, dos 38.964 disponíveis, caia para 0,239617.

Ou até que o indicador N (número potencial de erros) menos n (número corrigido de erros) não diminua menos do que o limite adotado - 1459 peças.

Literatura


  1. Monakhov, Yu. M. Estabilidade funcional de sistemas de informação. Às 3 horas, parte 1. Confiabilidade do software: livro didático. subsídio / Yu. M. Monakhov; Vladim. Estado un-t Vladimir: Izdvo Vladim. Estado Universidade, 2011 - 60 p. - ISBN 978-5-9984-0189-3.
  2. Martin L. Shooman, "Modelos probabilísticos para previsão de confiabilidade de software".
  3. Fundamentos de data warehousing para profissionais de TI / Paulraj Ponniah - 2ª ed.

Parte dois. Teórico

More articles:


All Articles