じゃんけんゲームのようにデータをクリーンアップします。 これはエンディングのあるゲームですか、それともエンディングのないゲームですか? パート 1. 理論的

1.初期データ

データ クリーニングは、データ分析タスクが直面する課題の XNUMX つです。 この資料は、地籍値の形成におけるデータベースの分析という実際的な問題を解決した結果として生じた開発と解決策を反映しています。 ソースはこちら 「ハンティ・マンシースク自治管区 - ウグラの領土内のあらゆる種類の不動産（土地区画を除く）の国家地籍評価の結果に関する報告書 No. 01/OKS-2019」.

「付録 B. KS の決定結果 5. 地籍値の決定方法に関する情報 5.1 比較アプローチ」のファイル「比較モデル total.ods」を検討しました。

表 1. ファイル「比較モデル total.ods」内のデータセットの統計指標
フィールドの合計数 (個) — 44
レコードの合計数 (個) — 365 490
総文字数、個。 — 101 714 693
レコード内の平均文字数 (個)。 — 278,297
レコード内の文字の標準偏差、個数。 — 15,510
エントリの最小文字数、個。 — 198
エントリ内の最大文字数 (個)。 — 363

2. 導入部分。 基本的な基準

誰の目にも明らかなように、指定されたデータベースはユーザーに法的および経済的な影響を与えるため、指定されたデータベースを分析する際に、浄化の程度の要件を指定するタスクが作成されました。 作業中に、ビッグデータのクリーニングの程度については特別な要件がないことが判明しました。 この問題における法規範を分析したところ、それらはすべて可能性から形成されているという結論に達しました。 つまり、あるタスクが出現し、そのタスクに対応する情報源が収集され、データセットが形成され、作成されたデータセットに基づいて問題を解決するためのツールが作成されます。 結果として得られるソリューションは、代替案から選択する際の参照点となります。 これを図 1 に示しました。



規格を決定する際には実証済みのテクノロジーに依存することが望ましいため、次の要件を選択しました。 「業界向けの MHRA GxP データ整合性の定義とガイダンス」, この文書がこの問題に関して最も包括的であると考えたためです。 特にこの文書では、「データの完全性要件はマニュアル（紙）と電子データに同様に適用されることに注意する必要があります。」と記載されています。 (翻訳: 「...データの完全性要件はマニュアル (紙) と電子データに同様に適用されます」)。 この定式化は、民事訴訟法第 71 条第 70 条の規定における「書面による証拠」の概念と極めて具体的に関連しています。 75 CAS、第 84 条、APC、「書面による」条項。 XNUMX 民事訴訟法。

図 2 は、法学における情報の種類に対するアプローチの形成を示す図です。

米。 2. 出典 ここで.

図 3 は、図 1 の仕組みを、上記「指導」のタスクに対して示したものです。 比較すると、最新の情報システム標準における情報完全性の要件を満たす際に使用されるアプローチが、情報の法的概念と比較して大幅に制限されていることが簡単にわかります。

Pic.3

指定された文書 (ガイダンス) では、技術的な部分、データの処理および保存機能との関連性が、第 18.2 章からの引用によって十分に確認されています。 リレーショナル データベース: 「データはデータとメタデータ間の関係を保持する大きなファイル形式で保持されるため、このファイル構造は本質的により安全です。」

実際、このアプローチでは、既存の技術的能力からは何も異常はなく、概念の拡張は最も研究されている活動であるデータベース設計から行われるため、それ自体は自然なプロセスです。 しかしその一方で、既存のシステムの技術的機能に対する割引を規定していない法規範も現れています。たとえば、次のとおりです。 GDPR - 一般データ保護規則.

米。 4. 技術力のファネル（ソース).

これらの側面から、元のデータセット (図 1) をまず保存し、次にそこから追加情報を抽出するための基礎にする必要があることが明らかになります。 たとえば、交通ルールを記録するカメラはどこにでもあり、情報処理システムは違反者を排除しますが、ショッピング センターへの顧客の流れの構造のマーケティング監視など、他の情報も他の消費者に提供される可能性があります。 これは、BigDat を使用する際のさらなる付加価値の源となります。 現在収集されているデータセットが、将来のどこかで、現時点での 1700 冊の希少版の価値と同様のメカニズムに従って価値を持つようになる可能性は十分にあります。 結局のところ、実際には、一時的なデータセットは一意であり、将来的に繰り返される可能性はほとんどありません。

3. 導入部分。 評価基準

処理プロセス中に、次のエラーの分類が開発されました。

1. エラークラス (GOST R 8.736-2011 に基づく): a) 系統的エラー。 b) ランダムエラー。 c) 失敗。

2. 多重度による: a) モノラル歪み。 b) マルチディストーション。

3. 結果の臨界度に応じて: a) 臨界的。 b) 重要ではない。

4. 発生源別:

A) 技術的 – 機器の動作中に発生するエラー。 IoT システム、通信の品質、機器 (ハードウェア) に重大な影響を与えるシステムにかなり関連するエラー。

B) オペレーターのエラー - 入力時のオペレーターのタイプミスからデータベース設計の技術仕様のエラーまで、幅広い範囲のエラー。

C) ユーザー エラー - ここには、「レイアウトの切り替えを忘れた」からメートルとフィートの間違いまで、あらゆる範囲のユーザー エラーがあります。

5. 別のクラスに分割します。

a) 「区切り文字のタスク」、つまり、複製されたときのスペースと「:」（この場合）。
b) 一緒に書かれた単語。
c) サービス文字の後にスペースを入れない
d) 対称的な複数の記号: ()、「」、「...」。

図 5 に示すデータベース エラーの体系化と組み合わせると、エラーの検索とこの例のデータ クリーニング アルゴリズムの開発に非常に効果的な座標系が形成されます。

米。 5. データベースの構造単位に対応する典型的なエラー (出典: オレシコフ V.I.、パクリン N.B. 「データ統合の重要な概念」).

正確性、ドメインの整合性、データの種類、一貫性、冗長性、完全性、重複、ビジネスルールへの準拠、構造の明確性、データの異常、明瞭性、タイムリー、データ整合性ルールの遵守。 (334 ページ。IT プロフェッショナルのためのデータ ウェアハウジングの基礎 / Paulraj Ponniah。第 2 版)

英語の文言とロシア語の機械翻訳を括弧内に示します。

正確さ。 システムに格納されているデータ要素の値は、そのデータ要素の出現に対する正しい値です。 顧客の名前と住所がレコードに保存されている場合、その住所はその名前の顧客の正しい住所です。 注文番号 1000 のレコードで注文数量が 12345678 単位であることが判明した場合、その数量はその注文の正確な数量です。
[正確さ。 システムに保存されているデータ要素の値は、そのデータ要素の出現に対する正しい値です。 顧客の名前と住所がレコードに保存されている場合、その住所はその名前の顧客の正しい住所です。 注文番号 1000 のレコードで注文数量が 12345678 単位であることが判明した場合、その数量はその注文の正確な数量です。]

ドメインの整合性。 属性のデータ値は、許容される定義された値の範囲内にあります。 一般的な例は、性別データ要素の許容値が「男性」と「女性」であることです。
[ドメインの整合性。 属性データ値は、有効な定義された値の範囲内にあります。 一般的な例は、性別データ要素の有効な値「男性」と「女性」です。]

データ・タイプ。 データ属性の値は、実際にはその属性に定義されたデータ型として保存されます。 店舗名フィールドのデータ型が「テキスト」として定義されている場合、そのフィールドのすべてのインスタンスには、数値コードではなくテキスト形式で表示される店舗名が含まれます。
[データ・タイプ。 データ属性の値は、実際にはその属性に定義されたデータ型として保存されます。 店舗名フィールドのデータ型が「テキスト」として定義されている場合、このフィールドのすべてのインスタンスには、数値コードではなくテキスト形式で表示される店舗名が含まれます。]

一貫性。 データ フィールドの形式と内容は、複数のソース システム間で同じです。 あるシステムの製品 ABC の製品コードが 1234 である場合、この製品のコードはすべてのソース システムで 1234 になります。
[一貫性。 データ フィールドの形式と内容は、異なるソース システムでも同じです。 あるシステム上の製品 ABC の製品コードが 1234 の場合、各ソース システム上のその製品のコードは 1234 になります。]

冗長性。 同じデータをシステム内の複数の場所に保存してはなりません。 効率性の理由から、データ要素がシステム内の複数の場所に意図的に保存されている場合は、冗長性を明確に識別して検証する必要があります。
[冗長性。 同じデータをシステム内の複数の場所に保存しないでください。 効率性の理由から、データ要素がシステム内の複数の場所に意図的に保存されている場合は、冗長性を明確に定義して検証する必要があります。]

完全。 システム内の特定の属性に欠損値はありません。 たとえば、顧客ファイルでは、すべての顧客の「状態」フィールドに有効な値が存在する必要があります。 注文詳細のファイルには、注文のすべての詳細レコードが完全に入力されている必要があります。
[完全。 この属性のシステムには欠損値はありません。 たとえば、クライアント ファイルには、各クライアントの「ステータス」フィールドの有効な値が含まれている必要があります。 注文詳細ファイルでは、各注文詳細レコードが完全に完了している必要があります。]

複製。 システム内のレコードの重複は完全に解決されます。 製品ファイルに重複レコードがあることがわかっている場合、各製品のすべての重複レコードが特定され、相互参照が作成されます。
[重複。 システム内のレコードの重複は完全に排除されました。 製品ファイルに重複エントリが含まれていることがわかっている場合、各製品のすべての重複エントリが特定され、相互参照が作成されます。]

ビジネスルールへの準拠。 各データ項目の値は、所定の業務ルールに準拠します。 オークション システムでは、ハンマーまたは販売価格は最低価格を下回ることはできません。 銀行融資システムでは、融資残高は常にプラスまたはゼロでなければなりません。
【ビジネスルールの遵守。 各データ要素の値は、確立されたビジネス ルールに準拠します。 オークション システムでは、ハンマーまたは販売価格は最低価格を下回ることはできません。 銀行信用システムでは、ローン残高は常にプラスまたはゼロでなければなりません。]

構造的明確性。 データ項目が自然に個別のコンポーネントに構造化できる場合は常に、項目にはこの明確に定義された構造が含まれている必要があります。 たとえば、個人の名前は自然にファーストネーム、ミドルネームのイニシャル、ラストネームに分かれます。 個人名の値は、名、ミドルネームのイニシャル、姓として保存する必要があります。 データ品質のこの特性により、標準の適用が簡素化され、欠損値が減少します。
[構造の確実性。 データ要素が自然に個別のコンポーネントに構造化できる場合、要素にはこの明確に定義された構造が含まれている必要があります。 たとえば、人の名前は当然、ファーストネーム、ミドルネームのイニシャル、ラストネームに分けられます。 個人名の値は、名、ミドルネームのイニシャル、姓として保存する必要があります。 このデータ品質特性により、標準の適用が簡素化され、欠損値が減少します。]

データの異常。 フィールドは、定義された目的にのみ使用する必要があります。 フィールド Address-3 がロング アドレスのアドレスの XNUMX 行目に対して定義されている場合、このフィールドはアドレスの XNUMX 行目を記録するためにのみ使用する必要があります。 顧客の電話番号や FAX 番号の入力には使用しないでください。
[データ異常。 フィールドは、定義された目的にのみ使用する必要があります。 Address-3 フィールドが長いアドレスの可能な XNUMX 番目の住所行に対して定義されている場合、このフィールドは XNUMX 番目の住所行を記録するためにのみ使用されます。 顧客の電話番号または FAX 番号を入力するために使用しないでください。]

明瞭さ。 データ要素は、高品質データの他のすべての特性を備えている可能性がありますが、ユーザーがその意味を明確に理解していなければ、そのデータ要素はユーザーにとって価値がありません。 適切な命名規則は、データ要素をユーザーがよく理解できるようにするのに役立ちます。
【明晰さ。 データ要素は、優れたデータの他のすべての特性を備えている可能性がありますが、ユーザーがその意味を明確に理解していなければ、そのデータ要素はユーザーにとって価値がありません。 正しい命名規則は、データ要素をユーザーがよく理解できるようにするのに役立ちます。]

タイムリーな。 データの適時性はユーザーが決定します。 ユーザーが顧客ディメンション データが XNUMX 日以上古いものではないことを期待している場合は、ソース システム内の顧客データに対する変更を毎日データ ウェアハウスに適用する必要があります。
[はやくて。 データの適時性はユーザーが決定します。 ユーザーが顧客ディメンション データが XNUMX 日以内のものであることを期待している場合は、ソース システム内の顧客データに対する変更を毎日データ ウェアハウスに適用する必要があります。]

使いやすさ。 データ ウェアハウス内のすべてのデータ要素は、ユーザーのコレクションのいくつかの要件を満たしている必要があります。 データ要素は正確で高品質である可能性がありますが、ユーザーにとって価値がなければ、そのデータ要素をデータ ウェアハウスに置く必要はまったくありません。
[ユーティリティ。 データ ストア内の各データ項目は、ユーザー コレクションのいくつかの要件を満たす必要があります。 データ要素は正確で高品質である可能性がありますが、ユーザーに価値を提供しない場合、そのデータ要素をデータ ウェアハウスに置く必要はありません。]

データ整合性ルールの遵守。 ソース システムのリレーショナル データベースに格納されているデータは、エンティティの整合性と参照整合性のルールに準拠している必要があります。 主キーとして null を許可するテーブルにはエンティティの整合性がありません。 参照整合性により、親子関係が正しく確立されます。 顧客と注文の関係では、参照整合性により、データベース内のすべての注文に顧客が存在することが保証されます。
[データ整合性ルールの遵守。 ソース システムのリレーショナル データベースに格納されたデータは、エンティティの整合性と参照整合性のルールに準拠する必要があります。 主キーとして null を許可するテーブルにはエンティティの整合性がありません。 参照整合性により、親と子の関係が正しく確立されます。 顧客と注文の関係では、参照整合性により、データベース内のすべての注文に顧客が存在することが保証されます。]

4. データクリーニングの品質

データクリーニングの品質は、ビッグデータにおいてかなり問題のある問題です。 タスクを完了するにはどの程度のデータ クリーニングが必要かという質問に答えることは、すべてのデータ アナリストにとって基本です。 現在の問題のほとんどでは、各アナリストが自分自身でこれを決定しており、外部からの誰かがその解決策のこの側面を評価できる可能性はほとんどありません。 しかし、法的データの信頼性は常に重要であるため、この問題は非常に重要でした。

動作の信頼性を判断するためのソフトウェアテスト技術を検討します。 現在、これらのモデル以外にもさまざまなモデルがあります 200。 モデルの多くは、請求サービス モデルを使用します。

図。 6

次のように考えます。「見つかったエラーがこのモデルの障害イベントに似たイベントである場合、パラメーター t の類似物をどのように見つけますか?」 そして、次のモデルをコンパイルしました。テスターが 1 つのレコードをチェックするのにかかる時間が (問題のデータベースの場合) 365 分であると想像してみましょう。その後、すべてのエラーを見つけるには 494 分、つまり約 3 年と 3 分かかります。数か月の労働時間。 ご存知のとおり、これは非常に膨大な作業であり、データベースのコンパイラにとってデータベースをチェックするコストは法外なものになります。 この反省の中で、コストという経済概念が登場し、分析の結果、これはかなり有効なツールであるという結論に達しました。 経済学の法則に基づくと、「企業の最大利益が達成される生産量（単位）は、新しい生産単位を生産する限界費用と、この企業が受け取ることができる価格とを比較した点に位置します。」新しいユニットのために。」 後続のエラーを見つけるたびに、レコードのチェックがますます必要になるという仮定に基づくと、これはコスト要因となります。 つまり、モデルのテストで採用された公準は、次のパターンで物理的な意味を持ちます。i 番目のエラーを見つけるために n 個のレコードをチェックする必要がある場合、次の (i+1) 個のエラーを見つけるには、次のエラーが必要になります。 m 個のレコードをチェックし、同時に n 個のレコードをチェックします

1. 新しいエラーが見つかる前にチェックされるレコードの数が安定したとき。
2. 次のエラーが見つかるまでにチェックされるレコードの数が増加する場合。

臨界値を決定するために、私は経済的実現可能性の概念に目を向けました。この場合、社会的コストの概念を使用すると、次のように定式化できます。最低のコストで。」 エージェントは 1 名、テスターは 6000 分間で 12,2 つのレコードをチェックします。 金銭的には、1 日あたり XNUMX ルーブル稼いだ場合、これは XNUMX ルーブルになります。 （ほぼ今日）。 経済法における均衡の第 XNUMX 側を決定することはまだ残っています。 私はこのように推論しました。 既存のエラーがある場合、関係者、つまり不動産所有者はそれを修正するために労力を費やす必要があります。 これには XNUMX 日のアクション (申請書の提出、修正された文書の受け取り) が必要だとしましょう。 そうすれば、社会的な観点から見ると、彼のコストは XNUMX 日あたりの平均給与と同じになります。 ハンティ・マンシ自治管区における平均未収給与 「2019年XNUMX月からXNUMX月までのハンティ・マンシースク自治管区 - ウグラの社会経済的発展の結果」 73285こする。 または3053,542日あたりXNUMXルーブル。 したがって、次の臨界値が得られます。
3053,542: 12,2 = 250,4 レコード単位。

これは、社会的な観点から見ると、テスターが 251 件のレコードをチェックして 252 つのエラーを見つけた場合、それはユーザーが自分でこのエラーを修正したことと同等であることを意味します。 したがって、テスターが次のエラーを見つけるために XNUMX レコードのチェックに等しい時間を費やした場合、この場合、修正のコストをユーザーに転嫁した方がよいでしょう。

社会的な観点からは、各専門家が生み出すすべての追加価値、つまり税金や社会的支払いを含むコストを考慮する必要があるため、ここでは簡略化したアプローチを示しますが、モデルは明確です。 この関係の結果として、スペシャリストに対する次の要件が決まります。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万ルーブル/です。年。 そして、これらの費用（455ルーブル）は不動産所有者に送金されるため、彼はあまり気にしません。 そして、この側面では、ビッグデータのさらに洗練された技術の開発者は、このデータベースの所有者を説得する能力を示さなければならず、そのようなことにはかなりの才能が必要です。

この例では、エラー評価アルゴリズムは、障害のない動作のテスト中のソフトウェア検証のシューマン モデル [2] に基づいて選択されました。 インターネット上で普及しており、必要な統計指標を取得できるためです。 この方法論は Monakhov Yu.M から引用されています。 「情報システムの機能的安定性」、図のスポイラーの下を参照。 7-9.

米。 7 – 9 シューマンモデルの方法論





この資料の XNUMX 番目の部分では、シューマン モデルを使用した結果が得られるデータ クリーニングの例を示します。
得られた結果を紹介します。
推定エラー数 N = 3167 n。
パラメータ C、ラムダ、信頼性関数:

Pic.17

基本的に、ラムダは各段階で検出されるエラーの強度を示す実際の指標です。 42,4 番目の部分を見ると、このインジケーターの推定値は 1 時間あたり 250,4 エラーであり、これはシューマン インジケーターとほぼ同等です。 上記で、開発者がエラーを発見する割合は、1 分あたり XNUMX レコードをチェックする場合、XNUMX レコードあたり XNUMX エラー以上である必要があると判断されました。 したがって、シューマン モデルのラムダの臨界値は次のようになります。

60 / 250,4 = 0,239617。

つまり、ラムダが既存の 38,964 から 0,239617 に減少するまで、エラー検出手順を実行する必要があります。

または、指標 N (潜在的なエラー数) から n (修正されたエラー数) を引いた値が、許容されるしきい値である 1459 個を下回るまで減少します。

文学

1. Monakhov、Yu.M. 情報システムの機能の安定性。 3 時間で完了 パート 1. ソフトウェアの信頼性: 教科書。 手当/Yu.M.モナホフ。 ウラディム。 州大学– ウラジーミル: イズヴォ・ウラディム。 州大学、2011年 – 60ページ。 – ISBN 978-5-9984-0189-3。
2. Martin L. Shooman、「ソフトウェア信頼性予測のための確率モデル」
3. IT プロフェッショナルのためのデータ ウェアハウジングの基礎 / Paulraj Ponniah — 第 2 版

パートXNUMX。 理論的

出所： habr.com