元のアドレス：https：//blog.csdn.net/xiepeifeng/article/details/42431027
データウェアハウスのデータモデルを設計する過程で、このような要件が頻繁に発生します。
1.データ量が比較的多い;
2。ユーザーの住所、製品の説明情報、注文ステータスなど、テーブルの一部のフィールドが更新されます;
3。特定の時点での過去のスナップショット情報を表示する必要があります時間または期間内、たとえば、履歴の特定の時点での特定の注文のステータスを確認します。
たとえば、特定のユーザーが過去の特定の期間に更新した回数などを確認します
。4。変更の割合と頻度はそれほど大きくありません。たとえば、1,000万人のメンバーがいて、毎日約100,000の新規および変更があります
。5。このテーブルの完全なコピーを毎日保持すると、多くの変更がありません。情報は各全量で保存されるため、ストレージの無駄になります。
ジッパー履歴テーブルは、応答データの履歴状態を満たすだけでなく、ストレージを最大限に節約できます。
たとえば、簡単な例では、 6月20日の3つのレコードを持つ注文テーブルです。
6月21日の時点で、テーブルには5つのレコードがあります。
6月22日の時点で、テーブルには6つのレコードがあります。
データウェアハウスにテーブルを保持する方法：
1.全額のコピーのみを保管し、データは6月22日の記録と同じです。6月21日の注文001のステータスを確認する必要がある場合、それを満たすことはできません。
2.毎日フルコピーを保持する場合、データウェアハウスのテーブルには14個のレコードがありますが、多くのレコードが繰り返し保存され、タスクの変更はありません。たとえば、注文002,004の場合、データ量が多くなります。これは多くのストレージの無駄を引き起こします。
テーブルがデータウェアハウスの履歴ジッパーテーブルとして設計されている場合、次のようなテーブルがあります。
説明：
1. dw_begin_dateはレコードのライフサイクルの開始時刻を示し、dw_end_dateはレコードのライフサイクルの終了時刻を示します。
2. dw_end_date = '9999-12-31'は、レコードが現在有効な状態にあることを意味します。
3.現在有効なすべてのレコードをクエリする場合は、* from order_his where dw_end_date = '9999-12-31'を選択します。
4. 2012-06-21の履歴スナップショットをクエリする場合、* from order_his where dw_begin_date <= '2012-06-21' and end_date> = '2012-06-21'を選択すると、このステートメントは次のレコードをクエリします。
これは、6月21日のソーステーブルのレコードとまったく同じです。
このような履歴ジッパーテーブルは、履歴データの需要を満たすだけでなく、ストレージリソースを大幅に節約できることがわかります。