2

DimPlaces、FactPlaces、DimGeography などの倉庫テーブルに関連する場所を設計しました。見れば分かりやすいデザインです。すべての場所は DimPlaces (Addrline1、Addrline2、placename など) にあり、地理階層は DimGeography (市、州、国、郵便番号) にあります。FactPlaces は、DimPlaces と DimGeography への外部キーを持つテーブルです。

場所の名前またはそのプロパティが変更される可能性があり、同時に場所の場所が変更されると地理的階層キーが変更される可能性があるため、履歴データを維持したいと思います。

私はデザインパターンを見つけました -

もう 1 つの便利な設計パターンは、ディメンションの代理キーに加えて、恒久勘定キーをファクト テーブルに追加することです。これにより、ディメンション内の現在の行に再び結合され、現在のディメンション属性によってすべての履歴を簡単にレポートできるようになります。

この解決策に従っても大丈夫ですか？はいの場合、一意の値に UNIQUEIDENTIFIER タイプの KEY を使用する必要がありますか?

これに関する別の質問 - 従業員データ (DimEmployee および FactEmployee) があります。各従業員は、彼が働く場所に関連付けられています。これらの EMPLOYEE TABLES を PLACES TABLES に接続する方法。FACTEMPLOYEE と FACTPLACES を接続する必要がありますか?

4

1 に答える 1

0

まず第一に、彼らはビジネスキーについて言及していると思いますか? したがって、ディメンション テーブルにサロゲート キー 1 と 2 の 2 つの行があり、どちらも同じものを参照している場合、両方とも AccountId/ProductId/WhateverId が 1 の場合、サロゲート キー 1 とビジネス キーを持ついくつかのファクト テーブル行ができます。 1、および代理キー 2 とビジネス キー 1 を持つそれ以降のもの。

Uniqueidentifiers は非常に幅広いため、可能であれば、ファクト テーブルや結合には使用しないようにしてください。

最後の質問ですが、それは実際には報告に関するものです。あなたはそれをする必要がありますか？それは人々が見る必要があるものですか、それによってスライスする必要がありますか? 参照されたディメンションを考慮することができます - 場所テーブルが従業員ディメンションの placeId を介してファクト テーブルにリンクしている場合。または、開始日と終了日を含む factemployees テーブルを作成することもできます。何を達成する必要があるかによって異なります。

于 2013-02-25T17:07:21.357 に答える