web-dev-qa-db-ja.com

データウェアハウススキーマにディメンションを入力する方法とタイミング

私はRalph Kimballの本を読んでおり、現在、次のデータウェアハウススキーマを調査しています。

AdventureWorks 2008 Data Warehouse Schema

データウェアハウスの作成/更新時に、ディメンションテーブルとファクトテーブルの両方が入力されますか？どのくらいの頻度で？ DimDateテーブルはどうですか？可能なすべての日付またはファクトテーブルで使用される日付のみを入力しますか？

データウェアハウスを生成する標準的なプロセスは何ですか？

databasedata-warehouse
3
user2567

データウェアハウスの作成/更新中に、ディメンションテーブルとファクトテーブルの両方が入力されますか？

曖昧で答えにくい。

どのくらいの頻度で？

答えるのが難しい

DimDateテーブルについてはどうでしょう。可能なすべての日付を入力するか、ファクトテーブルで使用される日付のみを入力しますか？.

本当に、答えるのは本当に難しい。

読み続けてください。 「Dimension Conformance」と、Kimballの「Dimension Bus」の考え方を読む必要があります。

  1. 最初に寸法を入力する必要があります。それらは、時には複数のソースからの情報を「付加」します。共通の次元（「製品」など）は、複数のアプリケーションで複数の視点を持つことがよくあります。これは、個別のソースから個別に読み込まれる属性につながります。

  2. 寸法は「適合」しています。入力されるデータは、既存のディメンションと一致する場合があります。良い。データが一致しない場合があります。ディメンション属性の変更を管理するための多くの標準的な「緩やかに変化するディメンション」（SCD）アルゴリズムがあります。これは深くて複雑なテーマです。読み続けます。

  3. ファクトは、読み込まれたときに、適合した寸法に一致します。ファクトロードスケジュールは、ソースアプリケーションと倉庫の目的によって異なります。 「どれくらいの頻度で？」に対する簡単な答えはありません。

  4. 一部のディメンションは、（Timeなどの）外部ソースからのものか、本質的に静的であるため、（Timeなどの）事前入力できます。場合によっては、ディメンションを静的に宣言し、特別なほぼ手動のユーティリティを使用して、ビジネスの変更が発生したときにディメンションを微調整することは、便利なビジネスフィクションです。ディメンションは法律またはその他の外部標準によって定義される場合があります。

    時間の事前設定は、寸法の適合性をわずかに単純化するため、一般的です。また、時間インスタンスは変更可能な属性を持たないため、時間ディメンションが「緩やかに変化するディメンション」になることはありません。

    行が読み込まれるときに時間を累積すると、時間ディメンションの行に、会計期間や、入力で使用できる単純なY/M/D日付から簡単に導き出せないその他の事実などの豊富な情報が含まれることが多いため、煩わしい場合があります。

4
S.Lott

データキューブの構築に関する1つの経験を共有します。私はSQL Server Analysis Services 2005を使用しました。この会社は小売業で、いくつかの場所に店舗があります。各ストアには独自のデータベースサーバーがありますが、同じデータベーススキーマを使用します。

まず、各サイトから1つの中央データベースにデータをプルします。これは定期的に、私の場合は毎月行われます。この中央データベースは、サイトデータベースと同じスキーマを使用します。

次に、この中央データベースからデータがマッサージされて、「スタースキーマ」が形成されます。私の場合、私はsalesキューブを構築したかった。この販売キューブは、製品、日付、および場所でスライスできる必要があります。販売キューブは、販売されたアイテムの数量の合計、総売上の合計、および純売上の合計を表示できる必要があります。

このスタースキーマを作成するために、いくつかのビューを作成していくつかのテーブル参照をフラット化することにしました。

  • 販売ヘッダーと販売詳細テーブルを結合する1つのビュー。販売日、製品コード、ロケーションコード、販売数量、単価、数量*価格、数量*価格-割引を表示します。これはsales fact tableと呼ぶことができます。
  • 製品テーブルを製品カテゴリなどのサブテーブルと結合する1つのビュー。これは製品ディメンションのデータソースです。
  • ロケーションテーブルとそのサブテーブルを結合する1つのビュー。これはロケーションディメンションのデータソースです。

日付については、2001年1月1日から2030年12月31日までのすべての日付を含む次のようなcalendarテーブルを作成しました。

|date      |year|month|dayofweek|
|2001-01-01|2001|1    |0        |
|...

このカレンダーテーブルは日付ディメンションのデータソースです。

次に、ビジュアルスタジオで新しい「分析サービス」プロジェクトを作成しました。上記のビューとテーブルをデータソースとして設定し、salesビューの製品コードを製品ディメンションにリンクし、販売日を日付ディメンションにリンクし、さらにbuildキューブをリンクしました。

次に、Analysis Servicesはキューブ定義を設定し、キューブとディメンションを設定します。このプロセスが完了すると、キューブを使用できるようになります。

そのため、キューブを処理すると、キューブが設定されます。再処理しない限り、同じままです。

2
Endy Tjahjono

毎日の更新は私には合理的に見えますが、ビジネス要件に基づいて期間を選択します。私は商社向けのソリューションを開発し、毎日夜通しのアップデートを選びました。今日、昨日はすべてのトランザクションと在庫を包括的に表示でき、分析には十分です。また、トランザクションシステムのパフォーマンスの問題を回避し、ビジネスユーザーがデータの更新を開始する前にデータを読み取りました。

トランザクションシステムからデータを取得する場合、最初にディメンションを更新します。対応するディメンションがない場合、ファクトテーブルにデータを挿入できません。

DimDateに範囲内のすべての日付を入力します。たとえば、19日に売上がない場合は、それを確認できないことがあります。

標準プロセス？さまざまな方法があります。キンボールのアプローチが好きなら、試してみてください http://www.kimballgroup.com/

1
Branimir