問題タブ [dimensional-modeling]

データ ウェアハウスを設計しており、日付ディメンションを生成できるツールが必要です。MySQL 5.x を使用しています。

ありがとう

次元モデリングに関していくつか質問があります。

1. 既存のOLTPシステムからディメンションモデルを設計する際に、ディメンションモデルのOLTPで同じテーブル構造を使用しますか？たとえば、OLTPに顧客テーブルがあり、それをディメンションモデルに含めたいので、顧客ディメンションテーブルの設計時に同じテーブル構造を使用できますか、それとも変更できますか？

2. ディメンションテーブルは相互に参照できますか？たとえば、私のOLTPにはEMPテーブルとDEPTテーブルがあり、EMPはDEPTを参照しているので、これら2つのテーブルをディメンションモデルの一部として選択します。EMPディメンションテーブルにFK制約を設定する必要がありますか？

3. さて、ブリッジテーブルについて、私のOLTPにSTOREテーブルとDEPTテーブルがあり、STOREとDEPTを結合するブリッジテーブルSTORE_DEPTがあるとします。つまり、この花嫁テーブルに記録される各ストア内に複数の部門を持つことができます。ここで、ディメンションモデルにSTOREおよびDEPTのディメンションテーブルを作成するとします。このブリッジテーブルもモデルに含める必要がありますか？

よろしくお願いします。

タイプ2の寸法について質問があります。

当社の人事システムでは、1つの日付で従業員を雇用し、その後、最初に間違って入力された場合は雇用日を変更することができます。タイプ2ディメンションを使用すると、ディメンションテーブルに新しいレコードが作成されるため、これは複雑になります。

したがって、基本的に、一部の更新（上記の更新など）によってディメンションテーブルに新しいレコードが作成されないようにする必要があると言う方法が必要です。ただし、従業員が新しいポジションに移動した場合など、他の場合は、ディメンションテーブルにレコードを作成する必要があります。

ここでの私のオプションは何ですか？

在庫データを含むキューブをモデリングしています。簡単にするために、1 つの日付ディメンションを維持しようとしています。これらのメジャーの一部には、在庫レベルが含まれています。

エンド ユーザーは Excel を使用して、分析サービスからのデータを表示しています。私がやりたいことは、このディメンションが実際の株式取引が終了する値を表示しないようにすることです。

将来の情報を必要とする他のメジャーがキューブ内にあるため、将来のすべての日付エントリを削除することはできません。

簡単な測定例:

日付ディメンションには将来の日付が含まれます。

[Transaction Date]このメジャーの最後のトランザクション (ファクト テーブルの最も高いトランザクション日) の後、ディメンションに情報の表示を停止させることはできますか?

OLAP ではかなり一般的なシナリオであると私は信じていますが、それに対処するための本当に優れた方法は私に飛び出していません。

私は、複数のアイテムの販売取引について、それぞれに異なる製品を使用していると言いました..

私がやりたいのは、製品グループの組み合わせをカテゴリ、つまり「犬のみ」、「猫のみ」、「猫と犬」に割り当てることです

だから、あなたは次のようなものになってしまうでしょう..

可能であれば、Transact-SQL または SSIS でこれを達成することを望んでいます。計算されたメンバー/メジャーが遅いことがわかりました。それが最善の方法である場合、そのソリューションを受け入れます

どんな助けでも大歓迎です

開発中のスター スキーマの特定のディメンションに何を入れるべきか、ファクト テーブルに何を入れるべきかを判断するのに苦労しています。

例として、プロジェクトが不動産管理会社の住宅を追跡しているとしましょう。さまざまな日付、賃借人、契約などのディメンションはすべてかなり簡単です。家の場合、データがどこにあるかに関係なく、現在の所有者、現在の賃借人、現在の賃貸契約、および近隣、住所、現在の賃貸価格、現在の市場価値などを追跡する必要があります。 . 所有者、賃借人、および契約自体が次元であることに注意してください (また、近隣と住所も次元である可能性がありますが、私はそれらをあまり気にしません)。

家について保持されている多くのデータは、クエリのフィルター処理や、キューブの行ヘッダーと列ヘッダーに使用されます。その一部は、補助的な情報としてのみ必要であり、家ごとに見られますが、全体としては必要ありません.

データとそれをどうする必要があるかを考えると、(少なくとも) 3 つのオプションがあります。

• DimHouse: house テーブルはディメンションであり、ファクト テーブルの方が見栄えがするかもしれない多くの属性がありますが、それらは参照とフィルター処理に使用されるため、ここにある必要があります。現在の賃借人のような属性には、スノーフレーク/アウトリガーが必要になります。
• FactHouse: 他のファクト テーブルに結合されたハウス情報の累積スナップショットを持ちます。おそらく、トリミングされた DimHouse をブリッジとして使用します。これは私には奇妙に思えますが、事実のように見えるものを事実テーブルに入れます。
  • 現在の所有者、現在の賃借人などを関連するファクト テーブルに入れ、それらの事実を所有者/賃借人/その他として最新の状態に保ちます。変更します (これも奇妙ですが、私たちをスター スキーマの土地にとどめます)。

ということで、次元ルートを下ってきました。胸焼けしますが、目標を達成します。データを整理するためのより良い方法があるかどうかを知りたいだけです。冗長性 (類似したデータを持つファクト テーブルとディメンション テーブルを使用するなど) やスノーフレークは、それらが意味を成し、物事を行うための最良の方法 (「最善」の値の場合) であれば気にしません。

VoIP サービス用の「通話録音システム」に関する次元モデルを作成しています。私の質問を示すために、ほんの少しの例を示します。

1 つの呼び出しを表すファクトがあるとします。そして、クライアントと呼ばれるディメンションと、プロバイダーと呼ばれる別のディメンションがあります。（もちろん、日付などの他の次元があるふりをします...）

これにより、クライアントが行った通話の数、プロバイダーを介して送信された通話の数、およびその他の質問を確認できます。

また、1 つのクライアントがプロバイダーに関連付けられており、1 つのプロバイダーが多数のクライアントを持つことができるとします。

では、ここで質問です。次のようなクエリを作成するにはどうすればよいですか: 各プロバイダーにはどのようなクライアントがありますか?

両方の次元の間にあるクエリのようです。クライアントがサービスを使用したことがない場合、そのクライアントは呼び出しファクト テーブルに含まれず、この「プロバイダーごとのクライアント」クエリに表示されないため、その事実を含めることはできません。

これを行う 1 つの方法は、クライアント ディメンションのビューであるロールプレイング ディメンションを作成し、それをプロバイダ ディメンションに直接追加して、このようなクエリを実行することではないかと考えていました。次のようになります。

もちろん、このアプローチでは、ユーザーはこの View Client ディメンションをファクト テーブルで使用しないように十分に注意する必要があります。これは、ファクト行が重複するためです。

では、これは有名なファクトレス ファクト テーブルを使用する必要がある状況の 1 つですか?

これを行う正しい方法は何ですか？

ありがとう！

不規則なアカウント階層[Data Type].[Data Type Hierarchy](単純なキー、名前、親キー テーブル) があります。

根

• アカウント 1

  1. サブアカウント 1A

  2. サブアカウント 1B

  3. アカウント 2 (アカウント 1 の子)

• アカウント 3

  1. サブアカウント 3A

[Data Type].[Data Type Hierarchy]ここで、セットを親階層として、親メンバーとして計算メンバーを追加します[account 2]。

ファクト テーブルには[account 2]、いくつかの計算されたメンバーの単純なプレースホルダーであると想定されているため、 のデータはありません。

問題 #1: BIDS で [親メンバーを選択] をクリックすると、メンバーが表示されません。[すべて] レベル、または他のアカウント (データがある) のいずれかに追加できます。

問題＃2：スクリプトビューを使用すると、正しい親メンバーを手動で設定できますが、計算されたメンバーが集約されないため、「空のセルを表示する」がチェックされていない限り非表示になります。ドリルダウンすると、計算されたメンバーが表示されますが、期待値が表示されます。

ディメンションモデルのデフォルト値に関して、ここに示すように、 これらの値を生成するためのベストプラクティスについて誰かが提案を持っていますか？

それらはデータウェアハウスデータベースまたはETLプロセスに関連していると思いますか？

MSソリューションがあるとしたら、それらをDW Sql Serverデータベースプロジェクトの展開後のスクリプトとして使用するのでしょうか、それともETLIntegrationServicesプロジェクトのディメンションテーブルに追加するのでしょうか。後者の場合、実行時にどのように行を生成できますか？

ディメンションを正しく設定するのに問題があります。基本的に、イベントの詳細を保持するファクトテーブルがあります。各イベントは分類できますが、レベルは異なります。すべてのカテゴリ、サブカテゴリを保持するカテゴリディメンションがあります。カテゴリには3つのレベルがあります。一部のカテゴリにはサブカテゴリがありますが、他のカテゴリにはありません。

ディメンションを参照していると、各アイテムのドリルダウンが表示されますが、ドリルダウンで空白のアイテム（青い円、テキストなし）が表示されることがあります。

したがって、異なる粒度のカテゴリを保持しているカテゴリディメンションがあると思います。

NULL処理とUnknownMemberの設定をいじってみましたが、それが物事にどのように影響するかを完全には理解していません。

おそらく、そこにいる誰かが私にこの問題に関するいくつかのヒントやアドバイスを与えることができます。

SQLServer2012を使用しています

ありがとう