Поиск служб SSIS с компонентом поиска и компонентом сценария

Question

Мне нужно загрузить измерения из таблиц EDW (которые поддерживают исторические записи) и имеет тип Key-Value-Parameter.

Мой сценарий в порядке, если есть запись в EDW, как показано ниже

Key1  Key2   Code     Value     EffectiveDate           EndDate        CurrentFlag
100   555     01      AAA       2010-01-01 11.00.00     9999-12-31         Y
100   555     02      BBB       2010-01-01 11.00.00     9999-12-31         Y

Это нужно загрузить в DM, повернув его как

комбинации клавиш key1 и key2 делают Natural ключом для DM

 SK    NK       01     02        EffectiveDate        EndDate      CurrentFlag
 1    100-555   AAA    BBB       2010-01-01 11.00.00  9999-12-31        Y

Мой пакет ssis делает все это с хорошим поворотом ... ищет входящий NK в DIM ... если новый вставит ... еще с последующим поиском с датой вступления в силу и определит, получил ли входящий для того же естественного ключа новый (изменить ) в атрибуте .. если это так, обновляет текущую запись, устанавливая дату окончания и вставляя новую с новым значением атрибута и извлекая значения последних записей для других атрибутов.

Моя проблема в том, что если один и тот же естественный ключ встречается дважды с одним и тем же атрибутом в одном извлечении, мой первый поиск, который по естественному ключу ... пропустит обе записи и попытается вставить ... в случае сбоя. Если я получаю разные записи на NK, вторая не выбрана, и мне нужно снова запустить пакет.

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

Не уверен, что это имеет смысл, что я пытаюсь объяснить. Будет прикреплен скриншот обратно на рабочий стол (в понедельник).

Спасибо

Answer 1

Комментарии Кейда точны, но я считаю, что ваша главная проблема - дубликаты, точка. Означает ли тот факт, что у вас есть две версии одного и того же NK в потоке «источник», две разные, значимые версии? Или имеет значение только «последняя» версия?

Если изменения, отраженные в обеих версиях, должны быть отражены в вашей таблице измерений, то я повторяю предложение Кейда разделить вашу обработку на партии. Вы можете отсортировать ввод по NK (и времени изменения), затем использовать скрипт подсчета строк, чтобы перечислить «версии» каждого NK, а затем обработать «партии» по номеру версии.

Если в таблицу измерений должна быть включена только последняя «версия», я предлагаю вам исключить дубликаты перед использованием Lookup.

Answer 2

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

Возможно, вам лучше передать его в задачу «Команда SQL», и сохраненный процесс сделает вставку или истечет / вставит в зависимости от того, что он найдет.

Вы также можете передавать их на стол и делать это в пакетном режиме.

Чтобы обратиться к вашему потоку и модели, которую он пытается заполнить:

Для начала, всегда неудобно, когда порядок строк во входных данных вызывает поведенческие различия - то есть NK = A, Val = 1, затем NK = A, Val = 2, поведение отличается от NK = A, Val = 2, а затем NK = A, Val = 1. Следует задаться вопросом, правильный ли это размерный дизайн. Помните, что все атрибуты измерений присваиваются таблицам измерений на основе прагматического выбора. В конечном итоге размеры могут быть организованы в таблицы по желанию, поэтому другой дизайн может иметь больше смысла. Если что-то меняется в пределах одной загрузки, это может указывать на то, что вам нужно разбить эту загрузку, чтобы соответствовать размеру (не пытаясь загрузить данные за 2 дня за один раз).

Я заметил, что в вашем измерении есть Дата вступления в силу и Дата окончания. Прямо сейчас это звучит во многом как свойство поведения измерения (где ваши коды 01 и 02 меняются на NK), а не фактов, к которым это измерение будет прикреплено. Это может означать, что его нужно отслеживать в отдельной таблице фактов, скажем (SK, EffectiveDate, EndDate), или что это просто не важно, потому что все, что вас волнует, это комбинация NK, 01, 02, присоединенная к факту, в этом случае ваш естественный ключ - это все NK, 01, 02.

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

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