データウェアハウスのステージング領域内の構造

Question

私たちは銀行のデータウェアハウスに取り組んでおり、ステージングテーブルの標準Kimballモデル、スタースキーマ、およびETLを使用してプロセスを通じてデータを取得しています。

Kimballは、データをスタースキーマに入れる準備ができるまで、ステージング領域をインポート、クリーニング、処理などに使用する方法について話します。実際には、これは通常、ソースからのデータをほとんどまたはまったく変更せずにテーブルのセットにアップロードし、オプションで中間スキームに入る準備が整うまでデータを取り込みます。それは単一のエンティティのための多くの仕事であり、ここでの単一の責任はありません。私が働いている

従来のシステムは有する程度に、テーブルの異なるセット間の区別をした：

• アップロードテーブル：生のソース・システム・データ、非修飾
• ステージングテーブル：中間処理、型付きおよびクレンジング
• 倉庫テーブル

あなたは、別のスキーマでこれらを固執して、アーカイブ/バックアップ/セキュリティなどStagingInputがある場合、他の選手の一人が倉庫で働いており、StagingOutput、似たような話のために異なるポリシーを適用することができます。チーム全体として、データウェアハウスとそれ以外の両方の多くの経験があります。

しかし、これにもかかわらず、キングボールとウェブを見ても、ステージングデータベースに構造を与えることについては書かれていないようです。キンボール氏は、私たちすべてがこの深く暗い構造化されていないデータプールとしてステージングを行うようになると信じて、赦されるだろう。

もちろん、ステージング領域に構造を追加したい場合はどうすればいいのかは分かりませんが、それについては何も書かれていないようです。

だから、他の誰もそこにいるのですか？この大規模な構造化されていない混乱を演出しているのか、それとも民族はそれに興味深いデザインをしていますか？

Answer 1

私は同じ問題を経験しました。私たちには大規模なHRデータウェアハウスがあり、企業全体のシステムからデータを取得しています。私はファクトとディメンションテーブルの素晴らしいコレクションを持っていますが、ステージングエリアは混乱しています。私はこれの設計の基準を知らない。私は同じ道を歩み、物事を順調に保つために標準的な名前を思いついた。あなたの提案は命名にかなり良いです。私はそれを続けていくつもりです。

Answer 2

個人的には、私はキンボールなどで問題を探すつもりはありません。

あなたはどんな種類の「構造」を探していますか？どのような "構造"が必要と感じますか？今日あなたが持っている「構造」の欠如から、あなたはどんな問題を抱えていますか？

私はキンボールをあまり考えていないという印象を残しているかもしれません。そうではありません - 私はキンボールを読んでいません。私はちょうどいくつかのパターンをフィッティングする以上の理由のために物事を変更することの多くを考えていない。実際の問題を解決するための変更は問題ありません。たとえば、構造が不足してステージングとウェアハウスのテーブルが同じように扱われたためにステージングテーブルをバックアップしている場合は、構造を変更する理由があります。しかし、それがあなたが念頭に置いていたことのようなものなら、それを示すためにあなたの質問を編集すべきです。

Answer 3

ステージングにはサブ領域があります。例えば、staging1、staging2と呼ばれます。

Staging1は、変換なしでデータソースから直接引き出すことができます。 Staging1は最新のデータのみを保持します。

Staging2では、データが変換され、倉庫に保管されます。 Staging2はすべての履歴データを保持します。

Answer 4

Raph KimballとJoe Casertaの "The Data Warehouse ETL Toolkit"という本がありますので、Kimball氏はこれに少しでも努力しました。 :)

Answer 5

このポストを見てくださいhere。これは、DW内のステージング領域の責任の概要を示しています。

Answer 6

現時点では、大規模なInsurance DWHプロジェクトに取り組んでいますが、わずかに複雑ですが、ソースシステムテーブルはそれぞれSTAGINGデータベースの別々のスキーマに入れられ、次にETLが移動/クレンジング/ MDM）のデータをステージングデータベースからSTAGINGCLEANデータベースに、さらにETLを使用してデータをKimball DWHに移動します。

ステージングデータとStagingCleanデータベースを分離することで、データ品質の問題の診断に非常に役立ちます。ステージングされたデータが汚れていて、DWHの適切なものに変換される前に、クリーンなバージョンがあるためです。

Answer 7

どのように大きな質問です。

これまで、データベースに格納された変換されていないデータには、_MIRR（ミラー用）の接尾辞を使用していました。ソースを反映します。次に、ソースからの変換データには_STGを使用し、スタースキーマには_DWを使用します。

ステージングテーブルは3NFになります。私はこれがキーポイントだと思う。データは変換されずに格納され、データを完全に正規化した次のステップとは別に保存してから、レポート用にスタースキーマにすべて展開します。