web-dev-qa-db-ja.com

スタースキーマに時間ディメンションがあることの利点？

ファクトテーブル自体に時間属性を持つよりも、スタースキーマに時間ディメンションを持つことの利点は何でしょうか？

例えば：

各トランザクションのユーザー情報、トランザクションが発生した国、トランザクションが発生した日付を含むトランザクションデータがあります。

オプション1私が間違っている場合は修正してください。ただし、これはおそらく広く使用されているアプローチであり、多くの人が最も推奨しています。

  • transaction_ID（PK）、user_id（FK）、country_id（FK）、およびdate_id（FK）を含むトランザクションファクトテーブル

  • user_id（PK）とその他のユーザー属性を含むユーザーディメンション。たとえば、name＆phone_numberとしましょう。

  • date_id（PK）、date、day、month、year、quarterで構成される日付ディメンション。

オプション2オプション1を選択する代わりに考えたことだけど、よくわからないもの：

  • transaction_ID（PK）、user_id（FK）およびcountry_id（FK）、date、day、month、year、quarter。

  • user_id（PK）とその他のユーザー属性を含むユーザーディメンション。たとえば、name＆phone_numberとしましょう。

オプション2よりもオプション1を使用する利点は何ですか？最も広く使用されているアプローチであるにもかかわらず、別の日付ディメンションとの結合がより良いオプションである理由を知りません。どうもありがとう！

database-designschemadata-warehousestar-schema
6
rolladice

簡単なトランザクションテーブルで始まるシナリオでこの質問に答えましょう。私たちのビジネスが始まったとき、経営者は月の「名前」を知りたがっていたので、その情報を表に含めました。

DECLARE @Transactions TABLE (
    TransactionId INT
    ,UserId VARCHAR(10)
    ,CountryId INT
    ,TransactionDate DATE
    ,[MonthName] VARCHAR(20)
    ,SalesAmount DECIMAL(18, 2)
    )

ビジネスは順調で、トランザクションテーブルにはすでに100万行あります。実際、ビジネスは非常に優れているため、経営陣は現在、販売についてより詳細な質問をしています。彼らは、販売が行われた「四半期」を知りたがっていました。

ALTER TABLE Transactions ADD [QuarterName] VARCHAR(10)
UPDATE Transactions SET QuarterName = ...

100万行を更新しました。

時間が経つにつれて、経営陣は私たちの販売についてますます質問をし始めます。

  • その売り上げはどのDayOfTheWeekでしたか？
  • それは休日でしたか？
  • その日は満月でしたか。

ALTER TABLE Transaction ADD ...

UPDATE TABLE SET ...

うまくいけば、これがどこに向かっているのかがわかるでしょう。さらに、すべてのトランザクション行のすべての冗長データは、パフォーマンスの低下とリソース使用率の増加（メモリ、ディスク容量など）につながる可能性があります。データベースは大きく、バックアップに時間がかかります。冗長データはすべてメモリを消費します。

日付ディメンションテーブルでは、そのすべての情報が1か所に保存されます。 2000-01-01から2100-01-01までの日付を持つ日付ディメンションテーブルには、36525行しか含まれていません。日付の新しい属性を追跡したいときはいつでも、追加の属性を追加して36525行を更新するだけで、そのテーブルを変更する必要があります。

販売の「日付」属性に関する特定の情報が必要な場合は、日付ディメンションテーブルに対して単純に結合します。

さらに、日付ディメンションのデータは一貫しています。 Januaryのスペルが正しい、Saturdayのスペルが正しい、など。トランザクションテーブルにこの種のデータを格納すると、スペルが正しくないなど、あらゆる種類の不一致が発生する可能性があります。

日付ディメンションテーブルの作成の詳細については、以下を確認してください SQLサーバーでの日付ディメンションまたはカレンダーテーブルの作成

7
Scott Hodgin

スターに時間次元を含めることにはいくつかの利点があります。これらのメリットはすべてのユースケースに適用されるわけではありませんが、お客様のケースに適用される場合があります。

まず、多くのスターはファクトテーブルを細く保つことで利益を得ます。ほとんどのディメンションに数百行あるが、ファクトテーブルには数十億行ある場合、ファクトテーブルを細く保つためにできることは、ストレージ要件を減らすだけでなく、多くの検索を高速化する可能性があります。時間属性を使用しないものは、通常、より高速に実行されます。これらの属性を使用するものでも、時間ディメンションとの追加の結合にもかかわらず、ほぼ同じように実行できます。

大きな利点は、柔軟性と管理のしやすさです。曜日などの日付属性は、DBMSに組み込まれた関数を複製する可能性があります。ただし、他の属性と同様に、属性として平日のみにアクセスできる場合は、ある種の自動レポート生成プログラムを簡略化できます。

会計四半期や営業日などの会社固有の属性は、会社のカレンダーがどのように変わっているかに応じて、属性として保存されることで本当にメリットがあります。私はかつて、会計四半期がどこから始まり、どこで始まったかを決定するために本当に奇妙なアルゴリズムを持っている会社のために報告データベースを生成しなければなりませんでした。すべてのカレンダーの癖がコード化された単一のプログラムを作成し、そのプログラムを使用して時間ディメンションを設定することで、システムの残りの部分が非常にシンプルで理解しやすくなりました。

必要に応じて、日とは異なる粒度を選択できます。私の場合、私たちはワークシフトを選びました。勤務時間は8時間で、1日3勤務でした。ファクトテーブルには、細分性のために日付のみを必要とするものもあれば、日付と日付内のシフトを必要とするものもあります。

この答えは私の以前の答えを複製します here が見つかりました

0
Walter Mitty