4

システムは、現実世界の不良データの可能性に対応しなければならない場合があります。一部のデータは紙のフォームから作成されていると考えてください。また、フォームは本質的に、データを検証する手段が限られています。

例 1: あるフォームでは、ユーザーは空欄に整数の距離 (マイル単位) を入力する必要があります。常に整数値を取得するとは限らないため、文字列として記述された情報を取得します。

例 2: 別のフォームでコードをキャプチャします。そのコードは、システム内のコードの 1 つにマップする必要があります。ただし、フォームに記述されたコードが正しくない場合があります。コードをキャプチャし、将来の解決時まで無効な値で存在できるようにします。つまり、一部が無効であってもレコードを記録することが重要であるため、一時的に不良データを許可します。

システムが不良データ、つまり人的エラーにどのように対応するかについて、もっと知りたいと思っています。データベースはデータの完全性を確保するための砦であると考えられていますが、現実の世界は乱雑であり、人々は間違いを犯します。システムは、これらの間違いを反映できるようにする必要があります。

あなたが開発したシステムがヒューマン エラーに対処する方法にはどのようなものがありますか? どのような慣行を使用しましたか? どのような教訓を学びましたか?

このトピックについてさらに読むことはありますか？（ググるのに苦労しました。）

4

6 に答える 6

2

私はあなたに同意します、私たちが何をするにしても、私たちが悪いまたは間違ったデータを取り除くことができるという保証はありません。特に、ユーザー入力に関しては、それだけではありません。私の経験では、同じ問題が複雑な統合プロジェクトにも存在します。このプロジェクトでは、さまざまなシステムから取得したデータを統合してマージする必要があります（多くの場合、一貫性がありません）。

優れた戦略は、入力を運用システム自体から切り離すことです。まず、ユーザー（または外部システム）が提供したデータを別のデータストア（別のスキーマなど）に配置します。2番目のステップでは、このデータを運用データストアにロードしますが、厳密なルールを確認した場合に限ります（たとえば、アドレス検証ソフトウェアを使用して特定のアドレスを検証します）。この抽出、変換、読み込み（ETL）アプローチは、データウェアハウス（DWH）ソリューションではかなり一般的ですが、トランザクションシステムにもプログラムで適用できます（私の経験では）。

上記のアプローチは、多くの場合、入力が最初に送信され、（おそらく）後で外部エンティティ（ユーザーまたはシステム）がデータが正しいかどうかにかかわらずフィードバックを取得する非同期プロセスにつながります。

編集：詳細については、DWHの概念を確認することをお勧めします。ただし、そのようなものを構築したくない場合は、それらの概念を部分的に適用できます。

http://en.wikipedia.org/wiki/Extract,_transform,_load

http://en.wikipedia.org/wiki/Data_warehouse

http://en.wikipedia.org/wiki/Data_cleansing

于 2011-07-22T13:35:23.370 に答える
1

私が働いていた政府部門は多くの調査を行っていますが、そのほとんどはまだ紙ベースです。

  • すべての結果は OCR でシステムに取り込まれました。
  • OCR プロセスの一部として、フォームのデジタル スキャンが保持されます。
  • その後、データが検証され、解読できないデータや検証に失敗したデータにはフラグが立てられます。
  • 人間のオペレーターがデジタル データを確認するとき、コードが正しく解釈できなかったものを正しく解釈できると確信している場合は、データを変更できます。彼ら (ここにクールなビットがあります) は、紙ベースのオリジナルのスキャンを表示し、それを使用してユーザーが何を言おうとしていたかを判断することもできます。

別のスレッドで。ある時点で、入ってくるデータを、準拠させたい予想されるデータ範囲に対して検証する必要があります。エントリの時点で拒否すると、ユーザーに修正する機会が与えられます。トレードオフは、拒否するたびにプロセス全体を放棄する可能性が高くなることです。

システムのある時点で、検証に使用されるルールを指定する必要があります。結局のところ、システムはこれらのルールと同程度にスマートになるだけです。これらを自分でコード (おそらくビジネス ロジック) に開発することも、サード パーティのコンポーネントを使用することもできます。

時間の経過とともに変更される可能性があるため、検証を柔軟に制御できることは非常に重要です。

于 2011-07-25T07:13:07.300 に答える
1

正直なところ、紙ベースのシステムから IT に移行する際のポイントの 1 つは、これらのエラーを取り除き、すべてのデータが常に正しいことを確認することです。正しく計画および開発された IT システム (特にビジネスの財務システム) が、このようなエラーを許すとは思えません。自分の勤めている会社ではありませんが…

于 2011-07-22T12:55:40.613 に答える
0

私はPC時代の前に法制度を始めました。訴訟サポートデータベースは、事実上正しくない、不完全な、矛盾する情報に日常的に対応する必要があります。それは別の考え方を取ります。

ショートバージョン。。。

単一のファクトを記録する代わりに、ファクトに関する複数のアサーションを記録します。つまり、このようなアサーションからのデータを格納するデータベースを設計することです。

  • 2011-01-03 08:13のインタビューで、ニール・ライムスはケイン将校に、2011-01-0220:00から2011-01-0308:13まで家にいると語った。
  • 2011-01-03 08:25のインタビューで、LizaNeversはCane将校に、NeilRimesが2011-01-0223:45に帰宅したと語った。
  • 2011-05-13 10:22の証言録取で、コーディ・マクソンは弁護士のカート・シュラゲルに、2011-01-0303:00にクローガーでニール・ライムスを見たと語った。
于 2011-07-23T14:06:35.953 に答える
0

あなたが言及した種類の問題に対処するソフトウェアツールはたくさんあります。データのスクラブと変換、および検証エラーの処理に関するルールを定義できるプラットフォームとツールがあります。これらの手法は、データ統合およびビジネス インテリジェンス アプリケーションで広く使用されています。「データ品質」または「データ統合」の Google。

于 2011-07-22T12:56:22.963 に答える