あなたのディメンション・キーがユニークであるためには、あなたが
SELECT DISTINCT Country[,... other things] FROM TheSingleTable
クエリに(たとえば、国ディメンションの)あなたの寸法を基準とする必要があると思います。
この方法には欠点があります。ディメンションはキューブ自体の外で決してマテリアライズされません。ディメンションデータが間違っていると思われる場合、問題を分析することが非常に困難になります。同じ理由から、ゆっくり変化する次元を作成することは不可能です。
利点は、新しいディメンション・メンバーを検出し、新しいデータが入ったときにディメンション表を移入するためのETL作業を行う必要がないことです。欠点は、すべてのディメンションがテーブル、それはインコヒーレントになるでしょう。
寸法が複数の列のように基づいている場合:次に
SELECT DISTINCT CountryCode,CountryName FROM TheSingleTable
、二つの列が値マップの範囲ことを保証するために、単一のテーブルまたはETLプロセスには制約がない場合ちょうど1対1のお互いに新しいデータがあれば、ディメンションメンバーシップが狂ってしまいます。
たとえば、CountryCodeが "USA"、国名が "United States"の既存のメンバーが存在します。CountryCode "USA"、CountryName "Uited States"(またはNULL)という表に新しいファクト行が1つだけ入っている場合、これは新しいディメンションメンバーとして解釈されます。重複したキーエラー(運がよければ)、または複数のディメンションメンバーを偽ったディメンションを処理します。
本当に小さくてシンプルなプロジェクトでない限り、新しいデータがこの種のデザインを混乱させるのはとても簡単です。それは、あなたが入ってくるアップデートを集中的に分析し、 。