属性がキーでない場合の「属性キーの重複」エラー
ディメンションの処理中に次のエラーが表示されます。
OLAPストレージエンジン：処理中に重複する属性キーが見つかりました：テーブル： 'dbo_Orders'、列： 'Project'、値： 'client service stuff'。属性は 'プロジェクト'。
「プロジェクト」は「注文」ディメンションの属性ですが、キーではありません。プロジェクト列が重要であることをどこにも示していません！名フィールドのように、必要なだけ複製を作成できるはずです。
私はAnalysis Servicesプロジェクトの初心者であり、SSASが値の重複を完全に許容できるはずなのに値の重複について常に不平を言っているという事実を乗り越える必要があります。これは私が見落としているシンプルなものでなければならないと確信しています。
編集：KeyDuplicate = ReportAndContinue/ReportAndStopまた、KeyColumnsとNameColumnsを設定することもできます。しかし、この複数ステップのプロセスは、Address1、Address2、Address3、Firstname、Zipcode、および通常複製される他のフィールドの追加など、非常に通常の操作と思われるものにとっては非常に面倒です。この面倒なプロセスをすべてのそのような分野に適用する必要があるとは信じられませんか？
前もって感謝します。
これは通常、ソーステーブル/ビューに空白とNULLの両方がある結果です。
基本的に、SSASはすべての属性に対してこれを行いますSELECT DISTINCT COALESCE（attr、 ''）FROM SOURCE
デフォルトでは、Analysis ServicesはNULLを空白に変換するため、結果のフィードで重複する値の空白が発生します。したがって、エラーになります。
これはひどく、新しいプレイヤーにとって大きな苦痛であることに同意します。
解決策：ISNULL/COALESCE everywhereを使用するか、where句を使用してnullを含む行をフィルタリングするか、updateステートメントを実行してキューブを処理する前にすべてのnullを値に置き換えるなどして、データソースからすべてのnullを削除します.
属性を右クリックして、「プロパティ」を選択します。 [プロパティ]ウィンドウ内の[ソース]カテゴリの下にある[キーカラム]を見つけます。 「KeyColumn」プロパティを編集すると、ユーザーフレンドリーなウィンドウが表示されます。
ウィンドウの右側（キー列）側から属性を削除し、左側（使用可能な列）側の実際のid列に置き換えます。
次に、「NameColumn」プロパティを編集すると、同じウィンドウが表示されます。属性列（表示する実際のデータ）を左側から右側に移動します。
VS 2010 Shell SSDTでテスト済み。
同じ問題が発生しましたが、属性に空白またはNULL値がありませんでした。いくつかの分析の後、一部の文字列の末尾に改行文字があることがわかりました。そのため、属性の2つの値がほぼ同じで、一方に最後に改行文字があり、もう一方にない場合、SSASは「属性キーの重複」エラーを発生させます。
属性から改行文字を削除することで修正できます。
次の定義で計算列を作成しました。
REPLACE(REPLACE(ISNULL([AttributeColumn], ''), CHAR(13), ''), CHAR(10), '')
この計算列をキューブで使用すると、エラーが消えました。
今日私にこれが起こっただけで、ここでの解決策はどれもうまくいかなかったのでしばらく頭を悩ましました。最終的にそれを解決し、私がこのエラーをグーグルして、私がやったようにここに到着する他の誰かのために私のソリューションを追加すると思いました。
私の場合、[NullProcessing]値がすでに「UnknownMember」に設定されていたため、NULLおよび空の文字列ではありませんでした。むしろ、それは[トリミング]値であり、私の場合は「右」に設定されていました。
私がどのように解決したかは知っていますが（？）、理由は100％ではありませんが、SQL ServerがSELECT DISTINCT(col) FROM sourceであり、[トリミング]値がそのように設定されると、分析サーバーは後で削除します他のものは、末尾から文字をタブ付けし（たとえば、SQL ServerのRTRIMはそうしません）、重複することになります。
[トリミング]を「なし」に設定すると、タブは不要なデータであったため（私のデータは外部ソースから解析/読み取り/入力される）、列のタブを置き換え、キューブの処理後にまたいい。
このページの他のソリューションは機能しますが（状況によってはより理想的かもしれません）、これは代替ソリューションです。
ここに私のエラーの一部のモックアップがあります：
Column: 'attribute1_name', Value: 'Search String'
私は簡単に検索しました：
SELECT dim_id,
dim_name,
dim_attribute1.id,
dim_attribute1.name,
dim_attribute2.id,
dim_attribute2.name
FROM dim_table
INNER JOIN dim_attribute1 ON dim.attribute1_id = dim_attribute1.id
INNER JOIN dim_attribute2 ON dim.attribute2_id = dim_attribute2.id
WHERE UPPER(dim_attribute1.name) = UPPER('Search String')
これに一致するdim_attribute1.nameには2つの異なるエントリがあったことがわかります。
- 検索文字列
- 検索文字列
最初のソリューションは問題なくそれらを分割したので、実用的なソリューション（およびパフォーマンスボーナス）です。ただし、代替手段（テキスト値をキーとして保持する場合）は、照合を変更することです。
Key Columns → Column Name → Source → Collation
「大文字と小文字を区別する」を含める。
他の同様の問題としては、空白文字や、テキストのわずかな変化を見つけにくいその他の問題があります。
私は同じ問題を抱えていて、それに対する回避策を見つけました。
[キューブ] => [プロセス] => [設定の変更] => [ディメンションキーエラー]を右クリックします。
アクティブな「ユーザーカスタムエラー設定」
この4つのドロップダウンリストに「エラーを無視」を設定します。「キーが見つかりません」「重複キー」「不明なキーに変換されたヌルキー」「許可されていないヌルキー」
キーに関する問題は無視されます。
属性のキー列にIDを追加して遊んでいた後に問題が発生しました。その後キーを削除しましたが、処理中のselectステートメントがまだIDを参照しているため、属性が一意ではないことがわかりました。属性プロパティでこれを解決する方法が見つからなかったため、ディメンション全体を削除して再作成しました。これにより問題が修正されました。
今日同じような問題が発生しました（同じエラーメッセージ）。同じ問題で他の誰かがここに来るために、Wikiにメモを書きました。 http://www.david-halliday.co.uk/ wiki/doku.php？id = databases：Oracle＆＃select_dates_for_ssas_include_hierarchy
私の場合はSQLでした（単純化され、無実の人を守るために言い換えられました）。
SELECT dim_id,
dim_name,
dim_attribute1.name,
dim_attribute2.name
FROM dim_table
INNER JOIN dim_attribute1 ON dim.attribute1_id = dim_attribute1.id
INNER JOIN dim_attribute2 ON dim.attribute2_id = dim_attribute2.id
奇妙なことは、dim_attribute1_nameではなくdim_attribute2_nameのいくつかのケースでエラーが発生したことです。ただし、この特定のケースでは、属性はまったく同じでした。最終的に、ソリューションはSQLを次のように変更することでした。
SELECT dim_id,
dim_name,
dim_attribute1.id,
dim_attribute1.name,
dim_attribute2.id,
dim_attribute2.name
FROM dim_table
INNER JOIN dim_attribute1 ON dim.attribute1_id = dim_attribute1.id
INNER JOIN dim_attribute2 ON dim.attribute2_id = dim_attribute2.id
次に、ディメンションで（リスト内のIDを非表示にして）属性のキーのid値と属性の名前の名前を使用します。私はこれを見たことがありませんが、何らかの理由でここで起こりました。このソリューションは、キューブが重複キーエラーを無視して処理するように設定するよりも優れていると思います。
テーブルを結合するディメンションを作成している場合、パフォーマンス/信頼性が向上すると考えられます。しかし、私にそのことを引用しないでください。
上記のどれも私にとって解決しませんでした。うまくいったのは、エリック・Wが提案したものに似たものでした。
属性に複数のキー列を設定する必要がありました。たとえば、属性「市」にはキー列「国」、「州」、および「市」が必要です。
リレーショナルデータベースのビューでCOLLATIONを次のように指定して解決しました。
COALESCE（[Transaçãoの説明]、 ''）COLLATE Latin1_General_CI_AI
私のような他の準初心者に役立つ場合は、複数年にわたるDateディメンションを展開しようとする際に、「属性キーの重複」エラーメッセージに苦労して最終的に見つけた解決策の概要を説明します。たとえば、CalendarQuarter属性に属性キーが重複していることを示すエラーメッセージが表示されました。それは最初は私を混乱させました。なぜなら、1年ごとに4四半期（つまり、1、2、3、4）があり、もちろん重複していました。最終的に、それが問題であることがわかりました。つまり、このスレッドのタイトルに反して、属性がキーでした。 DSVの日付テーブルに「CalendarQuarterKey」という名前の計算列を追加して、CalendarQuarter属性に一意のキーを生成することで解決しました。 2017年第1四半期の「1」の代わりに「20171」、2017年第2四半期の「2」の代わりに「20172」など。CalendarMonth属性を使用した場合も同様です。 、11、12）ですから、もちろん私もそこに複製がありました。同じ解決策：計算列という名前の「CalendarMonthKey」をDSVの日付テーブルに追加して、CalendarMonth属性の一意のキーを生成しました。 2017年1月の「1」の代わりに「201701」、2017年2月の「2」の代わりに「201702」など。それぞれ属性。これは好ましい解決策ではないかもしれませんが、私にとってはうまくいき、ついにキューブの構築に戻ることができます。
さまざまな理由で何度もこのエラーに遭遇しましたが、最近ではあいまいな原因に遭遇しました。テキスト列にベータß文字が存在するということです。列内の数千の一意の単語は、太陽の下ですべてのあいまいなASCIIコードの寄せ集めを使用したという事実にもかかわらず、SSASは、ß記号を含む列値の処理中にのみ詰まりました。ヌル、重複、これは、おそらく MSDNスレッドSSAS 2012の「ss」と「ß」を使用した重複キーエラー で説明されている、計り知れない解決されていない問題に関連している可能性があります。私の場合、SSASカラムプロパティの照合を、リレーショナル側のSQL_Latin1_General_CP1_CS_ASのソースカラムの照合と一致するように設定しても、これは修正されませんでした。この回避策は、他の列が異なる照合に依存する特定の環境では苦痛になる場合がありますが、私の場合はこの問題を回避し、問題なくディメンションを処理できるようにしました。これが次の人が同じ「落とし穴」につまずくのに役立つことを願っています。
重複する属性キーを解決するためにkeyColumnsの複合キーが必要な時間
データにNULLと ''の両方が含まれる場合、SSASはNULLを ''と見なすため、重複する属性キーを提供します。これを修正するためにデータに触れる必要はありません。データソースビューに移動し、式COALESCE（mycolumn、 ''）を使用して名前付き計算を追加し、元の列の代わりにディメンションでそれを使用できます。これにより、データソースビューレベルで問題が修正され、ディメンションが正常に処理されます。
展開とキューブブラウジングを続行する場合は、Lemmeが回避策を提供します。 [キューブの処理]ウィンドウで、ディメンションキーのエラー設定をcustomに変更します。キューブをシームレスに展開および参照できます。ここでのトレードオフは、期待した結果が得られない可能性があることです。