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的機制，用於上述「指南」的任務。 透過比較不難看出，現代資訊系統標準中滿足資訊完整性要求時所採用的方法與資訊的法律概念相比有很大的限制。
圖。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 和可靠度函數：
圖。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。—第二版。
來源： www.habr.com