3

私は今まで直面したことのない状況に直面しています。

サテライト ロケールによって異なる、同じ ERP システムの複数のインスタンスがあります。各ロケールには独自の ID が割り当てられます。

各サテライト ロケーション内で、DB スキーマは他のものと同じで、同じテーブル、同じ値です。

これらのロケールの 2 つ以上のテーブル、たとえばパーツを組み合わせる場合、それらの自然操作キーは同じになりますが、追加の属性データは異なる場合があります。また、パーツがどのサテライト ロケールから来たかに基づいてパーツにリンクできるようにする必要があるため、ここで複合キー (パーツ ID とサテライト ID) が必要だと考えています。

これは、この 1 つのディメンションでは問題ありませんが、このサテライト ID は他の多くのディメンションでも同じように使用されます。また、多くのファクト テーブルの主要なスライサーでもあります。

この属性をどのように扱うべきですか? それを独自の次元に置き、スノーフレーク？または、値を各ディメンション (複製) にプッシュしますが、ファクト テーブルにサテライト ディメンションへの唯一の FK を保持させますか?

4

1 に答える 1

2

理想的な世界では、解決策は、ETL プロセス中に、Natural Operational Keys各 PartID/SatelliteID (および同じ状況にあるすべてのディメンション) に固有の代理キーに置き換えることです。たとえば、Time ディメンションの場合は、代理キーをスキップできます)。

もちろん、これには、ディメンション テーブルだけでなく、ファクト テーブルにもこの代理キーを追加する必要があります。

サテライト別にレポートする必要がある場合は、サテライト ID 列も別のディメンションとして表示されます。

これは理想的なソリューションになります。

自然キーの横にサテライト ID を持つ追加の列を追加することを提案したように、迅速で汚い解決策になる可能性があります。この列を各ディメンション (時間ディメンションを除く) とファクト テーブルに追加する必要があります。次に、参加するたびにサテライト ID 列を含める必要があります。

この場合、レポート ツールに、Natural Operational Key とサテライト ID で形成された複合 ID の一部としてサテライト ID を含める必要があります。

また、特定のサテライトのデータを選択するために使用できる特定のサテライト ディメンションを作成することもできます。

于 2015-03-17T15:55:30.817 に答える