Datawarehouse - リンクの方法

Question

ちょうどデータウェアハウジングに入り、混乱を明確にするためにあなたの助けが必要です。従業員の次元と部門の次元があるとします。 dimEmployee（Name、Salary、Position）のフィールドと部門（DeptNo、Desc、Manager）のフィールドをリストする必要があるレポートがある場合、どうすればいいですか。これらの2つのディメンションの間の結合テーブルとなるファクトテーブル（無意味）を作成しますか？あるいは、これらの2つのテーブルを別々に設計する必要がありますか？誰もが事実と次元について語りますが、次元テーブルをリンクすることも考えていますか？

あなたの洞察をお寄せいただきありがとうございます。

RK

Answer 1

あなたは通常、集約されたデータを参照する寸法と実際のテーブルについて話しています。部門ごとの従業員の数について話すレポートを書くことができます。

あなたはデータのリストを扱っているようです。これは、直接SQLを使用する方がより効果的です。だから何かのように

SELECT person.Name, person.Salary, Person.Position, 
Department.DeptNo, Department.Desc, Department.Manager 
From person 
    join Department on person.DeptId = Department.Id 

Answer 2

従業員と部署の間には関係があります。典型的には、DepartmentId列をEmployeeテーブルに追加することによって行われます。

Answer 3

問題の典型的なサイズには、時間（常に）、地域（例：Department、Territory、Stateなど）などがあります。あなたのケースでは、会社のはしご、ポジションなどの給与の範囲が適切である。

ファクトテーブルには、通常、付加的なもの（特定の給与範囲内の人数、位置など）が含まれます。

従業員がディメンションとして認定されるかどうかはわかりません。私にとって事実のように聞こえる。

Answer 4

ありがとうございました。特定の給与範囲にDEPTの総従業員を検索するための要件ともDEPTで従業員をリストする。要件がある場合 だから、デザインはこの

dimEmployee
EMPID
部門のように見えるかもしれません
名前
等...

dimDept
DEPTID
DESC
マネージャー
など....

fctEmpDept
EMPID
DEPTID
給与

私はデータウェアハウスについて読んだとき、私は寸法とファクトテーブルのみを参照してください。通常のレポート作成のためにリストを表示する必要がある場合、テーブルがどのように構成されるのか、本当に混乱しました。明らかに、外部キーにリンクされる可能性のある次元がいくつか存在する可能性があります。

Answer 5

ディメンションをpersonディメンション内の部門参照なしで相互に独立させ、部門ディメンション内の人参照がない場合、代入ファクトテーブルは2つの間のブリッジとして機能できます。例えば

Person Table 
------------ 

PersonID 
Forename 
Surname 
EffectiveFromDate 
EffectiveToDate 


Department Table 
---------------- 

DepartmentID 
DepartmentName 

etc 


AssignmentFact Table 
-------------------- 

AssignmentID (primary key) 
PersonID (foreign key to person table) 
ManagerID (foreign key to person table) 
DepartmentID (foreign key to department table) 
Salary 
CostCentre 
EffectiveFromDate 
EffectiveToDate. 

ので、このようなラインマネージャーの変化として人物の割り当てやプロモーションへの変更は、寸法を変更する必要はありませんが、唯一のファクトテーブルに素敵なシンプルな歴史的な記録を提供するであろう変更のこれらの次元を共有するファクト表が複数ある場合は、それらを単純に保ちながら配当を支払うことになります。両方の簡単な実装を試して試してみてください。これがより自然なものだと私は確信しています。

Answer 6

オプションA：各従業員が1つの唯一の部門に所属できる場合。私はfactIDテーブルにdepartmentIDを追加します。

オプションB：従業員が複数の部署に所属できる場合は、3番目の代替設定メトリックテーブル（または集計ファクトテーブル）を使用します。その後、部門別に従業員の集計を行い、集計した数値をこの新しいテーブルに格納します。

オプションC：departmentIDをemployeeテーブルに追加すると、ジョブが完了しますが、階層を設定することになります。これを行うことはできますが、データセットが増えるにつれて結合が難しくなり効率も低下します。

従業員と部署の関係に応じて、最初の2つのオプションのいずれかを選択します。

他の解決策もありますが、これが最善の策です。