1. Dados iniciais
A limpeza de dados é um dos desafios enfrentados pelas tarefas de análise de dados. Este material refletiu os desenvolvimentos e soluções que surgiram como resultado da resolução de um problema prático de análise de base de dados na formação do valor cadastral. Fontes aqui .
Foi considerado o arquivo “Modelo comparativo total.ods” no “Apêndice B. Resultados da determinação do KS 5. Informações sobre o método de determinação do valor cadastral 5.1 Abordagem comparativa”.
Tabela 1. Indicadores estatísticos do conjunto de dados do arquivo “Modelo comparativo total.ods”
Número total de campos, unid. - 44
Número total de registros, unid. — 365 490
Número total de caracteres, unid. — 101 714 693
Número médio de caracteres em um registro, unid. – 278,297
Desvio padrão de caracteres em um registro, unid. – 15,510
Número mínimo de caracteres em uma entrada, unid. - 198
Número máximo de caracteres em uma entrada, unid. – 363
2. Parte introdutória. Padrões básicos
Ao analisar a base de dados especificada, foi criada a tarefa de especificar os requisitos para o grau de purificação, uma vez que, como é claro para todos, a base de dados especificada cria consequências jurídicas e económicas para os utilizadores. Durante o trabalho, descobriu-se que não havia requisitos específicos quanto ao grau de limpeza do big data. Analisando as normas legais nesta matéria, cheguei à conclusão de que todas elas são formadas a partir de possibilidades. Ou seja, surge uma determinada tarefa, são compiladas fontes de informação para a tarefa, então é formado um conjunto de dados e, com base no conjunto de dados criado, ferramentas para solucionar o problema. As soluções resultantes são pontos de referência na escolha de alternativas. Apresentei isso na Figura 1.
Dado que, em matéria de determinação de quaisquer normas, é preferível confiar em tecnologias comprovadas, escolhi os requisitos estabelecidos em , pois considerei este documento o mais completo para esta questão. Em particular, neste documento a seção diz “Deve-se notar que os requisitos de integridade de dados se aplicam igualmente a dados manuais (em papel) e eletrônicos”. (tradução: “...os requisitos de integridade de dados aplicam-se igualmente a dados manuais (em papel) e eletrônicos”). Esta formulação está associada muito especificamente ao conceito de “prova escrita”, no disposto no artigo 71.º do Código de Processo Civil, art. 70 CAS, Art. 75 APC, “por escrito” Art. 84 Código de Processo Civil.
A Figura 2 apresenta um diagrama da formação das abordagens aos tipos de informação na jurisprudência.
Arroz. 2. Fonte .
A Figura 3 mostra o mecanismo da Figura 1, para as tarefas da “Orientação” acima. É fácil, fazendo uma comparação, perceber que as abordagens utilizadas para atender aos requisitos de integridade da informação nos padrões modernos de sistemas de informação são significativamente limitadas em comparação com o conceito legal de informação.
Figura.3
No documento especificado (Orientação), a ligação à parte técnica, capacidades de processamento e armazenamento de dados, é bem confirmada por uma 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."
Na verdade, nesta abordagem – a partir das capacidades técnicas existentes, não há nada de anormal e, por si só, este é um processo natural, uma vez que a expansão de conceitos advém da atividade mais estudada – o design de bases de dados. Mas, por outro lado, surgem normas legais que não prevêem descontos nas capacidades técnicas dos sistemas existentes, por exemplo: .
Arroz. 4. Funil de capacidades técnicas ().
Nestes aspectos, fica claro que o conjunto de dados original (Fig. 1) deverá, em primeiro lugar, ser salvo e, em segundo lugar, ser a base para a extração de informações adicionais dele. Bem, por exemplo: câmeras que registram as regras de trânsito são onipresentes, os sistemas de processamento de informações eliminam 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 a um shopping center. E esta é uma fonte de valor agregado adicional ao usar BigDat. É bem possível que os conjuntos de dados recolhidos agora, algures no futuro, tenham valor de acordo com um mecanismo semelhante ao valor das edições raras de 1700 atualmente. Afinal, na verdade, os conjuntos de dados temporários são únicos e é pouco provável que se repitam no futuro.
3. Parte introdutória. Critério de avaliação
Durante o processo de processamento, foi desenvolvida a seguinte classificação de erros.
1. Classe de erro (com base em GOST R 8.736-2011): a) erros sistemáticos; b) erros aleatórios; c) um erro.
2. Por multiplicidade: a) distorção mono; b) multidistorção.
3. De acordo com a criticidade das consequências: a) críticas; b) não crítico.
4. Por fonte de ocorrência:
A) Técnico – erros que ocorrem durante a operação do equipamento. Um erro bastante relevante para sistemas IoT, sistemas com grau significativo de influência na qualidade da comunicação, equipamentos (hardware).
B) Erros do operador - erros que variam desde erros de digitação do operador durante a entrada até erros nas especificações técnicas para design do banco de dados.
C) Erros do usuário - aqui estão os erros do usuário em toda a faixa, desde “esqueci de mudar o layout” até confundir metros com pés.
5. Separado em uma classe separada:
a) a “tarefa do separador”, ou seja, o espaço e “:” (no nosso caso) quando foi duplicado;
b) palavras escritas juntas;
c) sem espaço após caracteres de serviço
d) símbolos simetricamente múltiplos: (), "", "...".
Em conjunto, com a sistematização dos erros do banco de dados apresentada na Figura 5, um sistema de coordenadas bastante eficaz é formado para procurar erros e desenvolver um algoritmo de limpeza de dados para este exemplo.
Arroz. 5. Erros típicos correspondentes às unidades estruturais da base de dados (Fonte: ).
Precisão, integridade de domínio, tipo de dados, consistência, redundância, integridade, duplicação, conformidade com regras de negócios, definição estrutural, anomalia de dados, clareza, oportunidade, adesão às regras de integridade de dados. (Página 334. Fundamentos de armazenamento de dados para profissionais de TI / Paulraj Ponniah.—2ª ed.)
Apresentou o texto em inglês e a tradução automática em russo entre colchetes.
Precisão. O valor armazenado no sistema para um elemento de dados é o valor correto para aquela 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 do cliente com esse nome. Se você encontrar a quantidade solicitada como 1000 unidades no registro do número de pedido 12345678, essa quantidade será a quantidade exata para esse pedido.
[Precisão. O valor armazenado no sistema para um elemento de dados é o valor correto para aquela ocorrência do elemento de dados. Se você tiver um nome e endereço de cliente armazenados em um registro, o endereço será o endereço correto do cliente com esse nome. Se você encontrar a quantidade solicitada como 1000 unidades no registro do número de pedido 12345678, essa quantidade será a quantidade exata desse pedido.]
Integridade de domínio. O valor dos dados de um atributo está na faixa de valores definidos e permitidos. O exemplo comum são os valores permitidos como “masculino” e “feminino” para o elemento de dados de gênero.
[Integridade do Domínio. O valor dos dados do atributo está dentro do intervalo de valores válidos e definidos. Um exemplo geral são os valores válidos "masculino" e "feminino" para um elemento de dados de gênero.]
Tipo de dados. O valor de um atributo de dados é, na verdade, 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 textual e não em códigos numéricos.
[Tipo de dados. O valor de um atributo de dados é, na verdade, armazenado como o tipo de dados definido para esse atributo. Se o tipo de dados do campo nome da loja for definido como "texto", todas as instâncias desse campo conterão o nome da loja exibido em formato de texto em vez de 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, então o código deste produto será 1234 em todos os sistemas de origem.
[Consistência. A forma e o conteúdo do campo de dados são iguais em diferentes sistemas de origem. Se o código do produto ABC em um sistema for 1234, então o código desse produto será 1234 em cada sistema de origem.]
Redundância. Os mesmos dados não devem ser armazenados em mais de um local do sistema. Se, por razões de eficiência, um elemento de dados for intencionalmente armazenado em mais de um local num sistema, então a redundância deverá ser claramente identificada e verificada.
[Redundância. Os mesmos dados não devem ser armazenados em mais de um local do sistema. Se, por razões de eficiência, um elemento de dados for armazenado intencionalmente em vários locais de um sistema, então a redundância deverá ser claramente definida e verificada.]
Completude. Não há valores faltantes para um determinado atributo no sistema. Por exemplo, em um arquivo de cliente, deve haver um valor válido para o campo “estado” para cada cliente. No arquivo de detalhes do pedido, todos os registros detalhados de um pedido devem ser totalmente preenchidos.
[Completude. Não há valores faltantes no sistema para este atributo. Por exemplo, o arquivo do cliente deve ter um valor válido para o campo "status" de 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 está completamente resolvida. Se houver registros duplicados no arquivo do produto, todos os registros duplicados de cada produto serão identificados e uma referência cruzada será criada.
[Duplicado. A duplicação de registros no sistema foi totalmente eliminada. Se for sabido que um arquivo de produto contém entradas duplicadas, todas as entradas duplicadas de cada produto serão identificadas e uma referência cruzada será criada.]
Conformidade com as regras de negócios. Os valores de cada item de dados seguem as regras de negócios prescritas. Num sistema de leilão, o preço de martelo ou de venda não pode ser inferior ao preço de reserva. Num sistema de empréstimos bancários, o saldo do empréstimo deve ser sempre positivo ou zero.
[Conformidade com as regras de negócios. Os valores de cada elemento de dados obedecem às regras de negócio estabelecidas. Num sistema de leilão, o preço de martelo ou de venda não pode ser inferior ao preço de reserva. Num sistema de crédito bancário, o saldo do empréstimo deve ser sempre positivo ou zero.]
Definição Estrutural. Sempre que um item de dados puder ser naturalmente estruturado em componentes individuais, o item deverá conter esta estrutura bem definida. Por exemplo, o nome de um indivíduo se divide naturalmente em nome, inicial do meio e sobrenome. Os valores para nomes de indivíduos devem ser armazenados como nome, inicial do meio e sobrenome. Esta característica da qualidade dos dados simplifica a aplicação dos padrões e reduz os valores faltantes.
[Certeza Estrutural. Quando um elemento de dados puder ser naturalmente estruturado em componentes individuais, o elemento deverá conter esta estrutura bem definida. Por exemplo, o nome de uma pessoa é naturalmente dividido em nome, inicial do meio e sobrenome. Os valores para nomes individuais devem ser armazenados como nome, inicial do meio e sobrenome. Esta característica de qualidade de dados simplifica a aplicação de padrões e reduz valores faltantes.]
Anomalia de dados. Um campo deve ser usado apenas para a finalidade para a qual foi definido. Se o campo Endereço-3 estiver definido para qualquer possível terceira linha de endereço para endereços longos, então este 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 do cliente.
[Anomalia de dados. Um campo só deve ser usado para a finalidade para a qual foi definido. Se o campo Endereço-3 for definido para qualquer possível terceira linha de endereço para endereços longos, então este campo deverá ser usado apenas para registrar a terceira linha de endereço. Não deve ser usado para inserir o número de telefone ou fax de um cliente.]
Clareza. Um elemento de dados pode possuir todas as outras características de dados de qualidade, mas se os usuários não compreenderem claramente o seu significado, então o elemento de dados não terá valor para os usuários. As convenções de nomenclatura adequadas ajudam a tornar os elementos de dados bem compreendidos pelos usuários.
[Clareza. Um elemento de dados pode ter todas as outras características de bons dados, mas se os usuários não compreenderem claramente o seu significado, então o elemento de dados não terá valor para os usuários. As convenções de nomenclatura corretas ajudam a tornar os elementos de dados bem compreendidos pelos usuários.]
Oportuno. Os usuários determinam a atualidade 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 deverão ser aplicadas diariamente ao data warehouse.
[Em tempo hábil. Os usuários determinam a atualidade 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 deverão ser aplicadas diariamente ao data warehouse.]
Utilidade. Cada elemento de dados no data warehouse deve satisfazer 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, será totalmente desnecessário que esse elemento de dados esteja no data warehouse.
[Utilitário. Cada item de dados no armazenamento de dados deve satisfazer alguns requisitos da coleção do usuário. Um elemento de dados pode ser preciso e de alta qualidade, mas se não agregar valor aos usuários, não é necessário que esse elemento de dados esteja no data warehouse.]
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 de entidade e de integridade referencial. Qualquer tabela que permita nulo como chave primária não possui integridade de entidade. A integridade referencial força o estabelecimento correto dos relacionamentos pai-filho. Em um relacionamento cliente-pedido, a integridade referencial garante a existência de um cliente para cada pedido no banco de dados.
[Conformidade com regras de integridade de dados. Os dados armazenados em bancos de dados relacionais de sistemas de origem devem obedecer às regras de integridade de entidade e integridade referencial. Qualquer tabela que permita nulo como chave primária não possui integridade de entidade. A integridade referencial obriga o relacionamento entre pais e filhos a ser estabelecido corretamente. Em um relacionamento cliente-pedido, a integridade referencial garante que exista um cliente para cada pedido no banco de dados.]
4. Qualidade da limpeza de dados
A qualidade da limpeza de dados é uma questão bastante problemática em bigdata. Responder à questão de qual grau de limpeza de dados é necessário para concluir a tarefa é fundamental para todo analista de dados. Na maioria dos problemas atuais, cada analista determina isso sozinho e é improvável que alguém de fora seja capaz de avaliar esse aspecto em sua solução. Mas para a tarefa em questão neste caso, esta questão era extremamente importante, uma vez que a fiabilidade dos dados jurídicos deveria tender a um.
Considerando tecnologias de teste de software para determinar a confiabilidade operacional. Hoje existem mais do que esses modelos . Muitos dos modelos usam um modelo de atendimento de sinistros:
Fig. 6
Pensando da seguinte forma: “Se o erro encontrado é um evento semelhante ao evento de falha neste modelo, então como encontrar um análogo do parâmetro t?” E compilei o seguinte modelo: Vamos imaginar que o tempo que um testador leva para verificar um registro é de 1 minuto (para o banco de dados em questão), então para encontrar todos os erros ele precisará de 365 minutos, o que dá aproximadamente 494 anos e 3 meses de tempo de trabalho. Pelo que entendemos, isso é muito trabalhoso e os custos de verificação do banco de dados serão proibitivos para o compilador desse banco de dados. Nesta reflexão surge o conceito económico de custos e após análise cheguei à conclusão que esta é uma ferramenta bastante eficaz. Com base na lei da economia: “O volume de produção (em unidades) no qual o lucro máximo de uma empresa é alcançado está localizado no ponto onde o custo marginal de produção de uma nova unidade de produção é comparado com o preço que esta empresa pode receber para uma nova unidade.” Com base no postulado de que encontrar cada erro subsequente requer cada vez mais verificação dos registros, este é um fator de custo. Ou seja, o postulado adotado nos testes de modelos assume um significado físico no seguinte padrão: se para encontrar o i-ésimo erro foi necessário verificar n registros, então para encontrar o próximo (i+3) erro será necessário para verificar m registros e ao mesmo tempo n
- Quando o número de registros verificados antes de um novo erro ser encontrado se estabiliza;
- Quando o número de registros verificados antes de encontrar o próximo erro aumentará.
Para determinar o valor crítico, recorri ao conceito de viabilidade económica, que neste caso, utilizando o conceito de custos sociais, pode ser formulado da seguinte forma: “Os custos de correção do erro devem ser suportados pelo agente económico que pode fazer pelo menor custo.” Temos um agente - um testador que passa 1 minuto verificando um registro. Em termos monetários, se você ganhar 6000 rublos/dia, serão 12,2 rublos. (aproximadamente hoje). Resta determinar o segundo lado do equilíbrio no direito econômico. Eu raciocinei assim. Um erro existente exigirá um esforço do interessado para corrigi-lo, ou seja, do proprietário do imóvel. Digamos que isso exija 1 dia de ação (enviar uma inscrição, receber um documento corrigido). Então, do ponto de vista social, seus custos serão iguais ao salário médio diário. Salário médio acumulado em Khanty-Mansi Autonomous Okrug 73285 esfregar. ou 3053,542 rublos/dia. Assim, obtemos um valor crítico igual a:
3053,542: 12,2 = 250,4 unidades de registros.
Isso significa que, do ponto de vista social, se um testador verificou 251 registros e encontrou um erro, equivale a que o próprio usuário corrija esse erro. Conseqüentemente, se o testador gastou um tempo igual à verificação de 252 registros para encontrar o próximo erro, nesse caso é melhor transferir o custo da correção para o usuário.
Apresenta-se aqui uma abordagem simplificada, pois do ponto de vista social é necessário ter em conta todo o valor adicional gerado por cada especialista, ou seja, custos incluindo impostos e prestações sociais, mas o modelo é claro. Uma consequência dessa relação é a seguinte exigência para os especialistas: um especialista da indústria de TI deve ter um salário superior à média nacional. Se seu salário for inferior ao salário médio dos usuários potenciais do banco de dados, ele próprio deverá verificar todo o banco de dados pessoalmente.
Ao utilizar o critério descrito, forma-se o primeiro requisito para a qualidade do banco de dados:
Eu(tr). A proporção de erros críticos não deve exceder 1/250,4 = 0,39938%. Um pouco menos que ouro na indústria. E em termos físicos não existem mais de 1459 registos com erros.
Recuo económico.
Na verdade, ao cometer tantos erros nos registros, a sociedade concorda com perdas econômicas no valor de:
1459*3053,542 = 4 rublos.
Esse valor é determinado pelo fato de a sociedade não possuir ferramentas para reduzir esses custos. Daqui resulta que se alguém tiver uma tecnologia que lhe permita reduzir o número de registos com erros para, por exemplo, 259, então isso permitirá à sociedade poupar:
1200*3053,542 = 3 rublos.
Mas, ao mesmo tempo, ele pode pedir pelo seu talento e trabalho, bem, digamos - 1 milhão de rublos.
Ou seja, os custos sociais são reduzidos por:
3 – 664 = 250 rublos.
Em essência, este efeito é o valor agregado do uso das tecnologias BigDat.
Mas aqui deve-se levar em conta que se trata de um efeito social, e o proprietário da base de dados são as autoridades municipais, sua receita proveniente do uso de bens registrados nesta base de dados, a uma taxa de 0,3%, é: 2,778 bilhões de rublos/ ano. E esses custos (4 rublos) não o incomodam muito, pois são transferidos para os proprietários. E, nesse aspecto, o desenvolvedor de tecnologias de maior refinamento em Bigdata terá que mostrar capacidade de convencer o dono desse banco de dados, e isso exige um talento considerável.
Neste exemplo, o algoritmo de avaliação de erros foi escolhido com base no modelo Schumann [2] de verificação de software durante testes para operação sem falhas. Pela sua prevalência na Internet e pela possibilidade de obtenção dos indicadores estatísticos necessários. A metodologia foi retirada de Monakhov Yu.M. “Estabilidade funcional dos sistemas de informação”, ver sob o spoiler na Fig. 7-9.
Arroz. 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 da utilização do modelo Schumann.
Deixe-me apresentar os resultados obtidos:
Número estimado de erros N = 3167 n.
Parâmetro C, lambda e função de confiabilidade:
Figura.17
Essencialmente, lambda é um indicador real da intensidade com que os erros são detectados em cada estágio. Se você olhar a segunda parte, a estimativa para esse indicador foi de 42,4 erros por hora, o que é bastante comparável ao indicador Schumann. Acima, foi determinado que a taxa na qual um desenvolvedor encontra erros não deve ser inferior a 1 erro por 250,4 registros, ao verificar 1 registro por minuto. Daí o valor crítico de lambda para o modelo Schumann:
60 / 250,4 = 0,239617.
Ou seja, a necessidade de realizar procedimentos de detecção de erros deve ser realizada até que o lambda, dos 38,964 existentes, diminua para 0,239617.
Ou até que o indicador N (número potencial de erros) menos n (número corrigido de erros) diminua abaixo do nosso limite aceito - 1459 unidades.
Literatura
- Monakhov, Yu.M. Estabilidade funcional de sistemas de informação. Em 3 horas Parte 1. Confiabilidade de software: livro didático. subsídio / Yu.M. Monakhov; Vladimir. estado universidade. – Vladimir: Izvo Vladim. estado Universidade, 2011. – 60 p. – ISBN 978-5-9984-0189-3.
- Martin L. Shooman, “Modelos probabilísticos para previsão de confiabilidade de software”.
- Fundamentos de armazenamento de dados para profissionais de TI / Paulraj Ponniah.—2ª ed.
Fonte: habr.com