Подтвердить что ты не робот

Ошибка "Дублировать атрибут", когда атрибут не является ключом

При обработке Dimension появляется следующая ошибка:

Ошибки в модуле хранения OLAP: дубликат ключа атрибута был найденный при обработке: Таблица: 'dbo_Orders', Column: 'Project', Value: "клиентский сервис". Атрибут - "Проект".

"Проект" - это атрибут измерения "Заказы", ​​но не ключ. Нигде я не указал, что столбец проекта является ключом! Я должен иметь столько дубликатов, сколько необходимо, точно так же, как поле имени.

Я новичок в проекте Analysis Services, и мне действительно нужно пройти мимо того факта, что SSAS постоянно жалуется на дублирующие значения, когда должно быть отлично, чтобы иметь повторяющиеся значения. Я уверен, что это должно быть что-то простое, что я пропускаю.

Изменить: я понимаю, что можно установить KeyDuplicate = ReportAndContinue/ReportAndStop, а также установить KeyColumns и NameColumns. Но этот многоступенчатый процесс кажется очень громоздким для того, что, казалось бы, должно быть очень нормальной операцией, например добавлением Address1, Address2, Address3, Firstname, Zipcode и других полей, которые обычно дублируются. Не могу поверить, что этот громоздкий процесс необходимо применять ко всем таким областям?

Спасибо заранее.

4b9b3361

Ответ 1

Обычно это результат наличия как пробелов, так и NULL в исходной таблице/представлении.

По сути, SSAS делает это для каждого атрибута SELECT DISTINCT COALESCE (attr, '') ИЗ ИСТОЧНИКА

Услуги анализа по умолчанию преобразуют NULL в пробелы, что приводит к дублированию значений в полученном фиде - отсюда и ошибка.

Я согласен, что это отстой и является большой болью для новых игроков.

Решение: удалите все нули из источника данных, например, используя ISNULL/COALESCE всюду или отфильтровывая строки, содержащие null, используя предложение where, или выполняйте инструкцию обновления, чтобы заменить все значения NULL перед обработкой куба и т.д.

Ответ 2

Щелкните правой кнопкой мыши атрибут и выберите "Свойства". Найдите "KeyColumn", который находится в категории "Источник" в окне свойств. Отредактируйте свойство "KeyColumn", оно отобразит удобное для пользователя окно.

Удалите атрибут справа (ключевые столбцы) стороны окна и замените его фактическим столбцом id слева (доступные столбцы).

Затем отредактируйте свойство "NameColumn", появится одно и то же окно. Переместите столбец атрибутов (фактические данные, которые вы хотите отобразить) с левой стороны вправо.

Протестировано в SSDT оболочки VS 2010.

Ответ 3

У меня была такая же проблема, и в атрибуте не было пустых или NULL-значений. После некоторого анализа я обнаружил, что некоторые строки имели символ прерывания строки в конце. Итак, если 2 значения атрибута почти одинаковы, но один из них имеет символ прерывания строки в конце, а другой - нет, тогда SSAS вызывает ошибку "Duplicate attribute key".
Его можно устранить, удалив символ прерывания строки из атрибута.

Я создал расчетный столбец со следующим определением:

REPLACE(REPLACE(ISNULL([AttributeColumn], ''), CHAR(13), ''), CHAR(10), '')

Я использовал этот вычисленный столбец в кубе, и ошибка исчезла.

Ответ 4

Просто это случилось со мной сегодня и немного поцарапало голову, так как ни одно из решений здесь не работало. Наконец, решила его и подумала, что добавлю свое решение для кого-то другого, отправляющего эту ошибку и прибывающей сюда так же, как и я.

В моем случае это не было NULL и пустые строки, поскольку у меня было значение [NullProcessing], уже установленное на "UnknownMember". Скорее это значение [Trimming], в моем случае оно было установлено как "Right".

В то время как я знаю, как я решил (?), я не на 100% объясняю почему, но я предполагаю, что когда SQL Server делает это SELECT DISTINCT(col) FROM source, а значение [Trimming] установлено как таковое, сервер Analysis позже удаляет среди других (например, RTRIM в SQL Server, например, нет) и заканчивается дубликатами.

Таким образом, установка [Обрезка] на "Нет" может решить ее, поскольку вкладки были данными, которые мне не нужны (мои данные анализируются/читаются/вводятся из внешних источников) Я просто заменил вкладки в столбце и после этой обработки куб снова прекрасен.

Ответ 5

В то время как мое другое решение на этой странице работает (и в зависимости от ситуаций может быть более идеальным), это альтернативное решение:

Вот макет части моей ошибки:

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 было две разные записи, которые соответствовали этому:

  • Строка поиска
  • строка поиска

Первое решение разделило их без проблем, поэтому это рабочее решение (плюс бонус производительности). Однако альтернативой (если вы хотите сохранить текстовые значения в качестве ключей) является изменение Collation:

Key Columns → Column Name → Source → Collation

Включить "чувствительный к регистру".

Другие подобные проблемы могут быть символами пробела и другими легкомысленными изменениями текста.

Ответ 6

У меня была та же проблема, и я нашел обходное решение для нее.

Щелкните правой кнопкой мыши в "Кубе" = > "Процесс" = > "Изменить настройки" = > "Ошибки ключа измерения"

Активная настройка пользовательской ошибки пользователя

Установите "Игнорировать ошибки" для этого четырех выпадающего списка "Ключ не найден" "Дублированный ключ" "Нулевой ключ, преобразованный в неизвестный" "Null key not allowed"

Проблема с ключами будет проигнорирована.

Ответ 7

У меня была аналогичная проблема сегодня (такое же сообщение об ошибке), ради кого-то другого, попавшего сюда с той же проблемой, я поместил некоторые заметки в свою вики: 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 для ключа атрибута и имя для имени атрибута. Я этого раньше не видел, но почему-то это произошло здесь. Это решение, на мой взгляд, лучше, чем установка куба для обработки игнорирования повторяющихся ошибок ключа.

Я предполагаю, что если вы строите измерение, соединяющее таблицы, это даст лучшую производительность/надежность. Но не цитируйте меня на этом.

Ответ 8

У меня возникла проблема после того, как я играл с добавлением идентификатора в ключевой столбец атрибута. С тех пор я удалил ключ, но обнаружил, что оператор select во время обработки все еще ссылался на ID, делая атрибут не уникальным. Я не мог найти способ разрешить это с помощью свойств атрибута, поэтому я удалил все Dimension и воссоздал его. Это устранило проблему.

Ответ 9

Прочтите этот блог: найден дубликат ключа атрибута.... Посмотрите на длинное объяснение причины 1. Это объяснит, почему именно это происходит.

Спасибо, ребята,

Нед

Ответ 10

Ничто из вышеперечисленного не решено для меня. То, что сработало, было чем-то похожим на то, что предложил Эрик У.

Мне пришлось настроить несколько ключевых столбцов для моих атрибутов. Например, для атрибута "Город" нужны ключевые столбцы "Страна", "Штат" и "Город".

Более подробная информация здесь: https://www.mssqltips.com/sqlservertip/3271/sql-server-analysis-server-ssas-keycolumn-vs-namecolumn-vs-valuecolumn/

Ответ 11

Я решил, указав COLLATION на мои взгляды на реляционную базу данных следующим образом.

COALESCE ([Descrição da Transação], '') COLLATE Latin1_General_CI_AI

Ответ 12

Если ваши данные содержат как NULL, так и "SSAS" выдают дубликат атрибутного ключа, потому что он считает, что NULL является "". Вам не нужно прикасаться к своим данным, чтобы исправить это. Вы можете перейти к представлению источника данных и добавить именованный расчет с выражением COALESCE (mycolumn, ''), а затем использовать его в своем измерении вместо исходного столбца. Это устранит проблему на уровне представления источника данных и размер будет обрабатываться нормально.

Ответ 13

Lemme дает вам обходной путь, если вы все еще хотите продолжить развертывание и просмотр кубов. В окне "Process Cube" измените параметры ошибки размера ключа на пользовательский. Вы сможете легко развертывать и просматривать куб. компромисс здесь заключается в том, что вы не можете получить ожидаемые результаты.

Ответ 14

некоторое время, требующее составной ключ в keyColumns для устранения ключа дублирующего атрибута

Ответ 15

Я сталкивался с этой ошибкой много раз по разным причинам, но недавно столкнулся с довольно неясной причиной: присутствием символа бета в текстовом столбце. Несмотря на то, что тысячи уникальных слов в столбце использовали мешанину всех непонятных кодов ASCII под солнцем, SSAS подавился только при обработке значений столбцов, включающих символ ß. Нули, дубликаты, обрезка и тому подобное систематически исключались. По всей вероятности, это связано с непостижимой и нерешенной проблемой, обсуждаемой в потоке MSDN Ошибка дублирующегося ключа SSAS 2012 с 'ss' и 'ß', в которой SSAS интерпретировал значения ß как 'ss' по какой-то непостижимой причине, даже когда параметры сопоставления были правильны. В моем случае установка параметров сортировки в свойствах столбца SSAS в соответствии с исходной сортировкой столбца SQL_Latin1_General_CP1_CS_AS на реляционной стороне не устранила этого; Мне также пришлось изменить параметры сортировки для всего сервера. Этот обходной путь может быть болезненным в определенных средах, где другие столбцы зависят от разных параметров сортировки, но в моем случае он обошел эту проблему и позволил мне обработать измерение без помех. Я надеюсь, что это поможет следующему человеку наткнуться на ту же самую "ошибку".

Ответ 16

В случае, если это поможет другим квази-новичкам, таким как я, я нарисую решение, которое я наконец-то нашел после борьбы с сообщением об ошибке "дублирующий ключ атрибута" при попытке развернуть измерение Date, охватывающее несколько лет. Например, в сообщении об ошибке указано, что у меня в атрибуте CalendarQuarter есть дубликаты ключей атрибутов. Это первоначально смутило меня, потому что каждый полный год состоит из четырех кварталов (то есть 1, 2, 3 и 4), поэтому, конечно, у меня были дубликаты. В конце концов меня осенило, что это проблема - иными словами (и вопреки названию этой темы) атрибут БЫЛ ключом. Я решил эту проблему, добавив именованный столбец вычисления CalendarQuarterKey в мою таблицу DSVs Date, чтобы получить уникальные ключи для моего атрибута CalendarQuarter, например, "20171" вместо просто "1" для 2017 Q1, "20172" вместо просто "2" для 2017 Q2, и т.д. То же самое с моим атрибутом CalendarMonth: у каждого полного года есть двенадцать месяцев (то есть 1, 2, 3..., 11, 12), поэтому, конечно, у меня также были дубликаты. То же решение: я добавил именованный столбец вычисления CalendarMonthKey в свою таблицу дат DSV, чтобы получить уникальные ключи для атрибута CalendarMonth, например, "201701" вместо просто "1" для января 2017 года, "201702" вместо просто "2" для Февраль 2017 года и т.д. Затем я использовал мои новые столбцы "CalendarQuarterKey" и "CalendarMonthKey" в качестве KeyColumn для моих атрибутов CalendarQuarter и CalendarMonth соответственно. Возможно, это не самое предпочтительное решение, но оно сработало для меня, и я наконец могу вернуться к построению своего куба.