タイプ2別の次元に関する次元の変更

Question

さまざまなタイプ2次元の求人データウェアハウスをモデル化しようとしていますが、この特定のシナリオを正しくモデル化しているかどうかはわかりません。ここで私はこれまで何をやっています：

私は2次元があります。これらの二つの寸法は、両方の寸法にFKSが含まれているファクトレス（数値なし）ファクトテーブルFact_PersonEmployer、を介して接合されている

Dim_PersonとDim_Clientを、有効な開始日と終了日が表示されます。

人が別の事業所に移動した場合、その企業を旧雇用主にリンクするファクト行の有効期限を締め切りにし、新しい会社とのファクトテーブルに新しいレコードを挿入します。

これは非常に簡単なことですが、その人が新しい雇用者に移ってきたので、ユーザーは基本的にユーザー（募集/募集マネージャー）とは根本的に異なるため、 。

私の見解では、クライアントがpersonディメンションのタイプ2属性であるかのように思われるので、私はそれをモデリングすることを検討してきました。実際のファクトテーブルを使用せずにディメンションを一緒に結合することが受け入れられるかどうかはわかりません（できるだけKimballの方法論に固執しようとしています）。

I必要があります。それは2型が

または

Bを変更生成することができるように

a）の人の次元で、彼らは属性として働いている会社のIDを保管してください）が使用することを続行します2つの次元を互いに関連付けるファクト表

これは意味すると思います...

ありがとうございます！

Answer 1

ポイントのカップル：

1. Storeからと寸法表自体の日付に、ファクトレス（数値なし）ファクトテーブルに保管する必要はありません。

2. 人が別のビジネスに移動すると、ディメンションテーブルのみを変更する、つまりレコードを閉じて新しいビジネステーブルを挿入する必要があります。

3. 人は別の会社に移動し、あなたは彼がorganizatonを去った後に、その人を追跡しますか

   1. の明確にする必要がいくつかありますか？
   2. レコードを完全に閉じますか？

あなたは人の歴史と記録を保持したい場合は、IDを保持することは適切であろう。

Answer 2

DimPerson & DimClientの間に採用関係が示されている場合は、DimPersonにクライアント情報を持たないでください。関係がファクトに含まれているため、DimPersonレコードを変更する必要はありません（また、イベントの日付/時刻が必要です）。

ただし、雇用者が従業員の属性であると考えると、その関係はDimに含まれているため、Factテーブルは必要ありません。このような状況では、クライアント情報をDimPersonに非正規化する必要があります。日時は、ディメンション・レコードの有効日と以前アクティブなディメンション・レコードの有効期限として使用されます。

別の注意点として、ベストプラクティスでは、ファクトテーブルでイベントが記述されていることが記載されています。私はFact_PersonEmployerという名前が混乱していることがわかります。キャプチャするイベントは何ですか？それは雇用行為ですか？