1. 初始数据
数据清洗是数据分析任务面临的挑战之一。 该材料反映了在解决地籍价值形成过程中分析数据库的实际问题时所产生的进展和解决方案。 来源在这里 .
考虑了“附录 B. 确定 KS 5 的结果。有关确定地籍价值的方法的信息 5.1 比较方法”中的文件“比较模型total.ods”。
表 1 “对比模型total.ods”文件中数据集的统计指标
字段总数，个。 — 44
记录总数，条。 — 365 490
总字符数，个。 — 101 714 693
一条记录中的平均字符数，个。 — 278,297
记录中字符的标准偏差，个。 — 15,510
条目中的最小字符数，个。 — 198
条目中的最大字符数，个。 — 363
2.绪论部分。 基本标准
在分析指定数据库时，制定了一项任务来指定净化程度的要求，因为众所周知，指定数据库会给用户带来法律和经济后果。 工作中发现，对于大数据的清洗程度并没有具体的要求。 通过分析这件事的法律规范，我得出的结论是，它们都是由可能性形成的。 即，出现某个任务，为该任务编译信息源，然后形成数据集，并基于创建的数据集提供解决问题的工具。 由此产生的解决方案是从替代方案中进行选择的参考点。 我在图 1 中介绍了这一点。
由于在确定任何标准时，最好依赖经过验证的技术，因此我选择了 ，因为我认为这份文档对于这个问题来说是最全面的。 特别是，在本文件中，该部分指出“应该指出的是，数据完整性要求同样适用于手动（纸质）数据和电子数据。” （翻译：“……数据完整性要求同样适用于手册（纸质）和电子数据”）。 这一提法与《民事诉讼法》第 71 条第 70 条规定的“书面证据”概念密切相关。 75 CAS，第 84 条 APC，“书面”第 XNUMX 条。 XNUMX 《民事诉讼法》。
图 2 展示了法理学中信息类型方法的形成图。
米。 2. 来源 .
图3显示了图1的机制，用于上述“指南”的任务。 通过比较不难看出，现代信息系统标准中满足信息完整性要求时所采用的方法与信息的法律概念相比有很大的局限性。
Ris.3
在指定文件（指南）中，与技术部分的联系、处理和存储数据的能力，通过第 18.2 章的引用得到了很好的证实。 关系数据库：“这种文件结构本质上更安全，因为数据以大文件格式保存，保留了数据和元数据之间的关系。”
事实上，在这种方法中 - 从现有的技术能力来看，没有什么异常，并且就其本身而言，这是一个自然的过程，因为概念的扩展来自于研究最多的活动 - 数据库设计。 但另一方面，法律规范似乎并没有对现有系统的技术能力提供折扣，例如： .
米。 4. 技术能力漏斗（).
在这些方面，很明显，原始数据集（图 1）首先必须被保存，其次，成为从中提取附加信息的基础。 举个例子：记录交通规则的摄像头无处不在，信息处理系统淘汰违规者，但其他信息也可以提供给其他消费者，例如，对购物中心客流结构的营销监控。 这是使用 BigDat 时额外附加值的来源。 根据类似于当前 1700 个稀有版本的价值的机制，现在收集的数据集很可能在未来的某个地方具有价值。 毕竟，事实上，临时数据集是唯一的，并且将来不太可能重复。
3.绪论部分。 评价标准
在处理过程中，制定了以下错误分类。
1. 错误类别（基于 GOST R 8.736-2011）： a) 系统错误； b) 随机误差； c) 失误。
2. 按多重性： a) 单声道失真； b) 多重失真。
3. 根据后果的严重程度： a) 严重； b) 不重要。
4. 按发生来源分类：
A) 技术 – 设备运行过程中发生的错误。 对于物联网系统、对通信质量、设备（硬件）有很大影响的系统来说，这是一个相当相关的错误。
B) 操作员错误——错误范围很广，从操作员输入期间的拼写错误到数据库设计技术规范中的错误。
C) 用户错误 - 这里是从“忘记切换布局”到将米误认为英尺的整个范围内的用户错误。
5. 分成一个单独的类：
a）“分隔符的任务”，即重复时的空格和“：”（在我们的例子中）；
b) 写在一起的单词；
c) 服务字符后没有空格
d) 对称的多个符号：()、“”、“……”。
总而言之，通过图 5 所示的数据库错误的系统化，形成了一个相当有效的坐标系，用于搜索错误并为此示例开发数据清理算法。
米。 5、数据库结构单元对应的典型错误（来源： ).
准确性、域完整性、数据类型、一致性、冗余、完整性、重复、符合业务规则、结构确定性、数据异常、清晰度、及时性、遵守数据完整性规则。 （第 334 页。IT 专业人员的数据仓库基础知识/Paulraj Ponniah。—第二版。）
括号内给出了英文措辞和俄文机器翻译。
准确性。 系统中存储的数据元素的值是该数据元素出现的正确值。 如果您的记录中存储有客户姓名和地址，则该地址就是具有该姓名的客户的正确地址。 如果您在订单号 1000 的记录中发现订购数量为 12345678 件，则该数量就是该订单的准确数量。
[准确性。 系统中存储的数据元素的值是该数据元素出现的正确值。 如果您的记录中存储了客户姓名和地址，则该地址就是具有该姓名的客户的正确地址。 如果您在订单号 1000 的记录中发现订购数量为 12345678 件，则该数量就是该订单的确切数量。]
域完整性。 属性的数据值落在允许的定义值范围内。 常见的例子是性别数据元素的允许值为“男性”和“女性”。
[域完整性。 属性数据值落在有效的定义值范围内。 一般示例是性别数据元素的有效值“男性”和“女性”。]
数据类型。 数据属性的值实际上存储为为该属性定义的数据类型。 当商店名称字段的数据类型定义为“文本”时，该字段的所有实例都包含以文本格式显示的商店名称，而不是数字代码。
[数据类型。 数据属性的值实际上存储为为该属性定义的数据类型。 如果商店名称字段数据类型定义为“文本”，则该字段的所有实例都包含以文本格式显示的商店名称，而不是数字代码。]
一致性。 数据字段的形式和内容在多个源系统中是相同的。 如果一个系统中产品 ABC 的产品代码是 1234，则该产品在每个源系统中的代码都是 1234。
[一致性。 数据字段的形式和内容在不同的源系统中是相同的。 如果一个系统上产品 ABC 的产品代码是 1234，则该产品在每个源系统上的代码都是 1234。]
冗余。 相同的数据不得存储在系统中的多个位置。 如果出于效率原因，有意将数据元素存储在系统中的多个位置，则必须清楚地识别和验证冗余。
[冗余。 相同的数据不应存储在系统中的多个位置。 如果出于效率原因，有意将数据元素存储在系统中的多个位置，则必须明确定义和验证冗余。]
完整性。 系统中给定属性不存在缺失值。 例如，在客户文件中，每个客户的“state”字段必须有一个有效值。 订单明细文件中，订单的每条明细记录都必须填写完整。
[完整性。 系统中没有该属性的缺失值。 例如，客户端文件必须具有每个客户端的“状态”字段的有效值。 订单明细文件中，每条订单明细记录必须完整填写。]
复制。 系统中的重复记录得到彻底解决。 如果已知产品文件具有重复记录，则识别每个产品的所有重复记录并创建交叉引用。
[复制。 系统中的重复记录已被完全消除。 如果已知产品文件包含重复条目，则会识别每个产品的所有重复条目并创建交叉引用。]
遵守业务规则。 每个数据项的值都遵守规定的业务规则。 在拍卖系统中，成交价或销售价不能低于底价。 在银行贷款系统中，贷款余额必须始终为正或为零。
[遵守业务规则。 每个数据元素的值都符合既定的业务规则。 在拍卖系统中，成交价或销售价不能低于底价。 在银行信贷系统中，贷款余额必须始终为正或为零。]
结构确定性。 只要数据项可以自然地构建为单独的组件，该数据项就必须包含这种明确定义的结构。 例如，一个人的名字自然分为名字、中间名首字母和姓氏。 个人姓名的值必须存储为名字、中间名首字母和姓氏。 数据质量的这一特征简化了标准的执行并减少了缺失值。
[结构确定性。 如果数据元素可以自然地构造为单独的组件，则该元素必须包含这种明确定义的结构。 例如，一个人的名字自然分为名字、中间名首字母和姓氏。 个人姓名的值应存储为名字、中间名首字母和姓氏。 这种数据质量特征简化了标准的应用并减少了缺失值。]
数据异常。 字段只能用于其定义的目的。 如果为长地址的任何可能的第三行地址定义了字段Address-3，则该字段必须仅用于记录第三行地址。 它不得用于输入客户的电话或传真号码。
【数据异常。 字段只能用于其定义的目的。 如果Address-3字段被定义为长地址的任何可能的第三地址线，则该字段仅用于记录第三地址线。 它不应用于输入客户的电话或传真号码。]
明晰。 数据元素可能拥有高质量数据的所有其他特征，但如果用户不能清楚地理解其含义，则该数据元素对用户来说没有价值。 正确的命名约定有助于使用户更好地理解数据元素。
[明晰。 一个数据元素可能具有好数据的所有其他特征，但如果用户不能清楚地理解其含义，那么该数据元素对用户来说就没有价值。 正确的命名约定有助于让用户很好地理解数据元素。]
及时。 用户决定数据的时效性。 如果用户期望客户维度数据不超过一天，则源系统中客户数据的更改必须每天应用到数据仓库。
[及时。 用户决定数据的时效性。 如果用户期望客户维度数据不超过一天，则源系统中客户数据的更改应每天应用于数据仓库。]
用处。 数据仓库中的每个数据元素都必须满足用户集合的某些要求。 一个数据元素可能是准确的、高质量的，但如果它对用户没有价值，那么该数据元素就完全没有必要存在于数据仓库中。
[公用事业。 数据存储中的每个数据项必须满足用户集合的某些要求。 数据元素可能是准确且高质量的，但如果它不为用户提供价值，则该数据元素没有必要位于数据仓库中。]
遵守数据完整性规则。 存储在源系统的关系数据库中的数据必须遵守实体完整性和引用完整性规则。 任何允许 null 作为主键的表都不具有实体完整性。 参照完整性强制正确建立父子关系。 在客户到订单的关系中，引用完整性确保数据库中每个订单都存在客户。
[遵守数据完整性规则。 源系统关系数据库中存储的数据必须遵守实体完整性和引用完整性规则。 任何允许 null 作为主键的表都不具有实体完整性。 参照完整性迫使父母和孩子之间的关系得以正确建立。 在客户-订单关系中，引用完整性确保数据库中的每个订单都存在客户。]
4. 数据清洗的质量
数据清洗的质量是大数据中一个相当成问题的问题。 回答完成任务所需的数据清理程度是每个数据分析师的基础。 在当前的大多数问题中，每个分析师都会自己确定这一点，外部任何人不太可能在他的解决方案中评估这一方面。 但对于本案的任务来说，这个问题极其重要，因为法律数据的可靠性应该趋于一。
考虑软件测试技术来确定运行可靠性。 如今，不仅仅是这些型号 。 许多模型使用索赔服务模型：
图。 6
思考如下：“如果发现的错误是与该模型中的故障事件类似的事件，那么如何找到参数t的类似物？” 我编译了以下模型： 假设测试人员检查一条记录所需的时间是 1 分钟（对于相关数据库），那么要找到所有错误，他将需要 365 分钟，大约需要 494 年零 3 年几个月的工作时间。 据我们了解，这是一项非常大量的工作，并且检查数据库的成本对于该数据库的编译器来说将是令人望而却步的。 在这个反思中，出现了成本的经济学概念，经过分析我得出的结论是，这是一个相当有效的工具。 根据经济学定律：“企业获得最大利润时的产量（以单位为单位）位于生产新单位产出的边际成本与该企业可以获得的价格相比较的点上。为一个新单位。” 基于发现每个后续错误都需要越来越多的记录检查的假设，这是一个成本因素。 也就是说，测试模型中采用的假设具有以下模式的物理意义：如果要找到第 i 个错误，就需要检查 n 条记录，那么要找到下一个 (i+3) 个错误，就需要检查 n 条记录检查m条记录，同时检查n条记录
- 当发现新错误之前检查的记录数稳定时；
- 当发现下一个错误之前检查的记录数将会增加。
为了确定临界值，我转向了经济可行性的概念，在这种情况下，使用社会成本的概念，可以表述如下：“纠正错误的成本应该由能够做的经济主体承担以最低的成本实现。” 我们有一名代理 - 一名测试员，他花 1 分钟检查一条记录。 以货币计算，如果您每天赚取 6000 卢布，则相当于 12,2 卢布。 （大约今天）。 经济法中均衡的第二边仍有待确定。 我是这样推理的。 存在的错误就需要当事人，即业主，花力气去纠正。 假设这需要 1 天的时间（提交申请，收到更正的文件）。 那么，从社会的角度来看，他的成本将等于每天的平均工资。 汉特-曼西自治区 平均应计工资 73285 卢布。 或 3053,542 卢布/天。 因此，我们得到的临界值等于：
3053,542：12,2 = 250,4 单位记录。
这意味着，从社会角度来看，如果测试人员检查了251条记录并发现了一个错误，就相当于用户自己修复了这个错误。 因此，如果测试人员花费的时间相当于检查252条记录来查找下一个错误，那么在这种情况下最好将纠正成本转嫁给用户。
这里提出了一种简化的方法，因为从社会的角度来看，有必要考虑每个专家产生的所有附加价值，即包括税收和社会支付在内的成本，但模型是明确的。 这种关系的结果是对专家的以下要求：IT行业的专家的薪水必须高于全国平均水平。 如果他的工资低于潜在数据库用户的平均工资，那么他自己必须亲手检查整个数据库。
当使用所描述的标准时，形成了对数据库质量的第一个要求：
我（tr）。 严重错误的比例不应超过 1/250,4 = 0,39938%。 略小于 工业中的黄金。 从物理角度来看，有错误的记录不超过 1459 条。
经济退却。
事实上，由于记录中出现如此多的错误，社会同意承担以下金额的经济损失：
1459*3053,542 = 4 卢布。
这个数额是由社会没有降低这些成本的工具决定的。 因此，如果有人拥有一项技术，可以将有错误的记录数量减少到例如 259 条，那么这将使社会节省：
1200*3053,542 = 3 卢布。
但与此同时，他可以要求他的才华和工作，好吧，比方说 - 1万卢布。
也就是说，社会成本通过以下方式降低：
3 – 664 = 250 卢布。
从本质上讲，这种效果是使用 BigDat 技术带来的附加值。
但这里应该考虑到这是一种社会效应，数据库的所有者是市政当局，他们使用该数据库中记录的财产的收入按0,3%计算为：2,778亿卢布/年。 这些费用（4卢布）并没有让他太烦恼，因为它们已转移给业主。 而且，在这方面，大数据中更精炼的技术的开发者必须表现出说服这个数据库的所有者的能力，而这样的事情需要相当的人才。
本例中，在可靠性测试过程中，基于软件验证的舒曼模型[2]选择了错误评估算法。 由于其在互联网上的盛行并且能够获得必要的统计指标。 该方法取自 Monakhov Yu.M. “信息系统的功能稳定性”，参见图 7 的剧透部分。 9-XNUMX。
米。 7 – 9 舒曼模型的方法论
本材料的第二部分介绍了一个数据清理的示例，其中获得了使用舒曼模型的结果。
让我介绍一下所得到的结果：
估计错误数 N = 3167 n。
参数 C、lambda 和可靠性函数：
Ris.17
本质上，lambda 是每个阶段检测到错误的强度的实际指标。 如果您查看第二部分，该指标的估计值为每小时 42,4 个错误，这与 Schumann 指标相当。 上面确定，每分钟检查 1 条记录时，开发人员发现错误的比率应不低于每 250,4 条记录 1 个错误。 因此舒曼模型的 lambda 临界值：
60 / 250,4 = 0,239617。
也就是说，必须执行错误检测程序，直到 lambda 从现有的 38,964 减小到 0,239617。
或者直到指标 N（潜在错误数）减去 n（已纠正错误数）低于我们接受的阈值 - 1459 件。
文学
- Monakhov, Yu. M. 信息系统的功能稳定性。 3 小时内。第 1 部分：软件可靠性：教科书。 津贴 / Yu. M. Monakhov； 弗拉迪姆。 状态大学。 – 弗拉基米尔：伊兹沃·弗拉基姆。 状态大学，2011 年。 – 60 页。 – ISBN 978-5-9984-0189-3。
- Martin L. Shooman，“软件可靠性预测的概率模型。”
- IT 专业人员的数据仓库基础知识 / Paulraj Ponniah。—第二版。
来源： habr.com