問題タブ [dimensional-modeling]

スター スキーマ設計はデータ ウェアハウスに不可欠ですか? それとも、別の設計パターンでデータ ウェアハウジングを行うことができますか?

私は、ユーザーが一連のファクト テーブルに対して任意にクエリを実行できるようにするレポート システムに取り組んでおり、ファクト テーブルごとに複数のディメンション テーブルを制限しています。制約パラメーターに基づいてすべての正しい結合とサブクエリを自動的にアセンブルするクエリ ビルダー クラスを作成しましたが、すべてが設計どおりに機能します。

しかし、私は最も効率的なクエリを生成していないと感じています。数百万件のレコードを含む一連のテーブルでは、これらのクエリの実行に約 10 秒かかります。1 秒未満の範囲に収まるようにしたいと考えています。サブクエリを取り除くことができれば、結果ははるかに効率的になると感じています。

実際のスキーマ (はるかに複雑です) を示すのではなく、アプリケーションとデータ モデル全体を説明することなく、要点を説明する類似の例を示します。

アーティストと会場を含むコンサート情報のデータベースがあるとします。ユーザーは、アーティストと会場を任意にタグ付けできます。したがって、スキーマは次のようになります。

ものすごく単純。

ここで、今日から 1 か月以内に開催されるすべてのコンサート、「cheap-beer」および「great-mosh-pits」タグでコンサートに出演する「テクノ」および「トロンボーン」タグを持つすべてのアーティストについて、データベースにクエリを実行するとします。 .

私が思いついた最高のクエリは次のようになります。

クエリは機能しますが、これらの複数のサブクエリを使用するのは本当に好きではありません。純粋に JOIN ロジックを使用して同じロジックを実現できれば、パフォーマンスが大幅に向上すると感じています。

完璧な世界では、実際の OLAP サーバーを使用することになります。しかし、私の顧客は MySQL、MSSQL、または Postgres にデプロイする予定であり、互換性のある OLAP エンジンが利用できるとは保証できません。そのため、スター スキーマを持つ通常の RDBMS を使用することに行き詰まっています。

この例の詳細にあまりこだわらないでください (私の実際のアプリケーションは音楽とは何の関係もありませんが、ここで示したものと類似した関係を持つ複数のファクト テーブルがあります)。このモデルでは、「artist_tag」テーブルと「venue_tag」テーブルがファクト テーブルとして機能し、それ以外はすべてディメンションです。

この例では、ユーザーが単一の artist_tag またはvenue_tag 値に対してのみ制約できるようにすると、クエリの記述がはるかに簡単になることに注意することが重要です。複数の異なるタグを必要とする AND ロジックをクエリに含めることを許可する場合にのみ、非常に扱いにくくなります。

私の質問は、複数のファクト テーブルに対して効率的なクエリを作成するための、あなたが知っている最良の手法は何ですか?

Data Warehouse Toolkitを読んだばかりで、スター スキーマのモデリングは初めてです。

クライアントとクライアント以外の従業員との電話会議に参加するビジネス プロセスがあります。

「オーディエンス」と呼ばれる私のファクト テーブルには、出席者が通話に接続されていた時間と、この通話への接続にかかるコストの測定値が含まれます。粒度は「電話会議への個別接続」です。

準拠したクライアント ディメンションを使用して、非クライアント ディメンションを (まだクライアントではない発信者のために) このように作成する必要があります (この質問の一部ではないディメンションを省略します)。

または、次のように、準拠した Client ディメンションに非準拠の Attending ディメンションを関連付けた方がよいでしょうか。

または、このようなビジネス プロセスをモデル化するためのより優れた標準的なメカニズムはありますか?

編集：

上記のモデル 2 を使用して、クライアント ディメンション テーブルと対応するディメンションの上にビューを作成して、それが 1 つのディメンションにしか見えないようにするにはどうすればよいでしょうか?

それは、以下のダミールの答えに代わる許容可能なものですか?

特定の日付ディメンションと、作成、更新、キャンセルなどのアクション タイプのファクトを格納するファクト テーブルを設計しました。ファクトは 1 回だけ作成およびキャンセルできますが、何度も更新できます。

これにより、完了したすべての更新、一定期間に作成されたすべての新しい更新のカウントを取得し、場所のディメンションを通じて特定の地域を指定できます。

さらに、事実ごとに 2 つのカウント、つまり人数、建物の数もあります。これらの間には関係はありません。そして、特定のカウントを持つ事実の数を照会したいと思います。たとえば、建物が 10 であるファクトの数、建物が 9 であるファクトの数などです。

これらに最適なテーブルのデザインは何でしょうか。基本的に、次のオプションが表示されますが、より良い解決策を聞くことができます。

1. カウントを参照情報としてファクト テーブルに追加しpeople_count、building_count

2. これらのそれぞれに、有効なオプションを格納するディメンションを追加します。つまりpeople dimension、akeyとカウントbuilding dimensionを格納し、a とカウントを格納しkeyます。主な事実には apeople_keyと abuilding_key

3. これらは人数と建物の両方の数に使用されます。つまりcount dimension、a と一般的な数を格納しkeyます。主な事実には apeople_count_keyと abuilding_count_key

したがって、データ ウェアハウスには次の 2 つのディメンションがあります。

確認したいのは、両方のディメンションの machine_type フィールドに同じデータがあることです。2 つの間にスノーフレークする 3 番目のディメンションを作成する必要がありますか、それとも別の方法がありますか?

私のチームは、プロジェクトで SQL Server Analysis Services の使用を開始する準備をしていますが、誰も経験がありません。始めるために見ることができる良いスクリーンキャストは何ですか?

特定のシステムからXMLファイルとしてデータを収集し（これらはWebリクエストとして受信されます）、それをエンティティモデルに変換し、レポート用にデータベースに詰め込むプロジェクトを取得しました。

プロジェクトでは、次のソフトウェアを使用しています（この質問に関連）。

• C＃4.0 / .Net 4
• NHibernate 3.0（NuGetで利用可能な最新のもの）
• 流暢なNHibernate（NH 3と一緒に行くもの）

私がこのようなエンティティを持っているとしましょう（簡略化）：

そしてこれはこうしてマッピングされます：

（IDはエンティティ基本クラスから取得されます）

そのようなことを扱う人はおそらくすでにコードから読んでいるので、私はここでいくつかの次元モデリングをしようとしています。私はこのテーマに不慣れで、おそらくDoing It Wrong（tm）ですが、少なくともこの方法からいくつかのメリットを得ることを望んでいます。各インシデントは、次のようなDateDimensionオブジェクトを参照します。

DateDimensionテーブルはすでに入力されています-私のシステムは実際にここにレコードを作成することはありません。これらは、実際に使用される前に生成されます。システム内の関連する日付ごとに1行です。それが私のシステムの特徴のひとつです。可能な日付ごとに1つの行が存在することを約束します。1つが欠落している場合、それは壊滅的な障害になります。

これを書いている2日前の私がそうであったように、なぜこれを行うのか、あなたが次元モデリングに不慣れであるかどうかを尋ねるかもしれません。

さて、私は各日付のインシデントレコードをたくさん持っています。したがって、DateDimensionテーブルはIncidentテーブルよりもはるかに小さくなり、NHibernateLINQで他の方法では困難なことを実行できるようになります。たとえば、次のようなものです。

事件が平日の間でどのように分かれているかを教えてくれるグループのリストを教えてください。もちろん、ここに追加できるさまざまなディメンションがあり、さまざまなパラメーターを中心にレポートをピボットして、興味深いレポートを作成できます。

ただし、ちょっとした煩わしさが1つあり、ここでようやく本当の問題にたどり着きます。

DateDimensionには、基本的に特定の形式で表される日付である主キーがあります。2011年4月30日の場合、次のようになります。

20110430

これは、NHibernateのカスタムIIdentifierGeneratorを使用して行われます。日付ごとに1つのレコードしかないので、これは私の意見ではかなりクリーンな方法です。

また、新しいインシデントエンティティに関連するDateDimensionへの参照の外部キーを知らせる簡単な方法になります。一部のファクトリは、たとえばIncident.RegisterTime DateTimeからこのキーを抽出し、それをDateDimension_id列に詰め込むことを知っています。

しかし、これは私が行う方法を見つけることができないように思われることです。Incident.DateDimensionは、当然、エンティティ参照を要求します。つまり、データベースからロードする必要があります（右？）。これは、可能な限り短い時間で多くのインシデントエンティティをデータベースに挿入する必要がある特定のインポートシナリオでは遅すぎる可能性があります。

確かに、この特定の例では、エンティティを挿入するたびにカスタムSQLを実行し、NULL参照を許可することでこれを行うことができます。理想的ではありませんが、機能する可能性があります。

ただし、実際の保存された参照オブジェクトへの参照を設定する代わりに、DateDimension参照の外部キーを直接指定する方法はありますか？

それは確かに私に大きな頭痛を取り除くでしょう！

洞察を事前に感謝します！

データウェアハウスとディメンションモデリングに関するラルフキンボールの本を読んでいます。ケーススタディの1つを読んでいます。これは、注文システムのディメンションモデリングに関するもので、注文から履行、出荷までの注文ライフサイクルをキャプチャすることが要件です。

ですから、トランザクションタイプがFKの複数の行をトランザクションディメンションに含めることを提案するのではないかと考えていました。ただし、この本では、代わりに「ロールプレイング」ディメンションを作成することを提案しています。複数の日付ディメンションテーブルを作成します（1つは注文日用、1つは履行用、もう1つは出荷用）。それぞれがファクトテーブルへの外部キーを持っているため、ファクトテーブルにはこれに関連する3つの列があります。

このような制限はありませんか？トランザクションごとの行がより良い選択ではないでしょうか？

親が常に子を持つとは限らない属性階層を持つことは可能ですか? もしそうなら、これは SQL サーバーの Analysis Services でどのように達成されますか?

次の SQL を検討してください。

ここでは、集計されたファクトに、詳細で集計されていないファクトと同じ名前を付けています。これは良い考えですか、それとも悪い考えですか?

利点: 集約されたデータ項目は、そのディメンションを保存するすべての点で、詳細なデータ項目と「同じタイプ」のデータ項目です。

短所: 次元が異なるため、同じタイプのデータ項目ではありません。他のデータ項目と組み合わせる場合は注意が必要です。したがって、fact_agg のような名前で区別することをお勧めします。