TL;DR: ムービング ルールに従って調整された、不適切なムービング データから一貫性のある適切なビューを構築するにはどうすればよいでしょうか?
みなさんこんにちは:)私は、データを変換し、可能な場合は調整し、大幅に強化する必要があるデータベースを構築しています。
(ちなみに、この一般的なトピックに関する良い本を知っている場合は、投稿してください!)
私の特定のケースでは、生データは 2 つのテーブルから取得されます。
生のテーブルで何が起こるかは次のとおりです。
- フォーマットされていないデータ (フォーマットされる: 電話番号、メールアドレスを小文字にするなど)
- 欠落データ: 一部のフィールドが欠落しており、将来的に強化される可能性があります
- 更新データ: 一部の行が更新されました
- 新しいデータ: 新しい行が挿入されます
調整部分では、フィールド (ID、住所など) が部分的に使用されるか、テーブルにないか、他のテーブルに見つからない可能性があります。いくつかの調整規則が使用されます。すべてSQLで表現できます。それらのいくつかはGROUP BYs を使用しています (ビューが更新可能になるのを防ぎます)。
制約は次のとおりです。
- 基礎となるテーブルは更新できます。新しいデータは、最大で 72 時間後に追随する必要があります。
- 新しいデータは、許容できるパフォーマンスを備えたクエリ可能な形式 (テーブル、ビュー、またはマテリアライズド ビュー) である必要があります。
- 新しいデータの行は、注釈を付けることができるように、時間の経過とともにある程度一貫している必要があります (それらを充実させたり、別の場所に送信されたことをマークしたりするためなど)。
- 新しいデータの一部の行は、手動で強化する必要があります。
- 新しいデータの行には、調整された時刻 (および更新された場合は更新時刻) が含まれている必要があります。
- 調整方法は更新できます。新しいデータは、最大で 72 時間後に追随する必要があります。
ビューを使用するか、ストアド プロシージャで更新されるテーブルを使用するかを決定できません。
ビューは、生データの変更と調整ルールの更新を適切に処理します。ただし、改行の注釈はサポートされません。
ストアド プロシージャで更新されたテーブルはそれを適切に処理しますが、調整ルールが変更されたとき、または生データが更新されたときに、複雑な処理が必要になります。
私はおそらくビューを使用して、テーブルの主キーが新しいデータのいくつかの安定したフィールドのハッシュであるテーブルを横に持っていると考えていました。
ツールは次のとおりです。 Oracle 10g (および必要に応じて Java)
テキストの壁で申し訳ありません。
質問は：あなたならどうしますか？