Поиск SSIS с компонентом поиска и компонентом сценария

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

Мой сценарий в порядке, если есть запись в 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 создают естественный ключ для 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, а для второй должна иметь возможность обновляться с изменениями с помощью ссылка на один, вставленный выше.

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

Спасибо


ssis lookup script-component
person Sreedhar    schedule 05.06.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

Возможно, вам лучше передать его задаче команды 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.

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

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

person Cade Roux    schedule 05.06.2010
comment
Спасибо, Кейд, это имеет смысл. Если мой подход заключается в объединении двух источников данных, повороте и последующей передаче их через компонент скрипта для обработки исходных записей путем извлечения других значений новых входящих атрибутов => дамп в промежуточную таблицу и слияние с фактическим dim. Какова будет производительность при использовании компонента Script, это сценарий. - person Sreedhar; 06.06.2010
comment
@Nev_Rahd Все, что делается построчно, будет медленнее по сравнению с БД. Я думаю, вам действительно нужно посмотреть на вашу модель. Я добавил еще немного материала. Модель должна соответствовать фиду в той мере, в какой то, как моделируются данные, должно отражать поведение данных с точки зрения подкодов, меняющихся с течением времени. Я думаю, что это проблема моделирования, а не проблема ETL, потому что я не думаю, что когда вы запрашиваете таблицы фактов, связанные с этим измерением, вы собираетесь использовать дату вступления в силу и дату окончания, потому что они относятся к назначениям кода, а не к (текущим) фактам. - person Cade Roux; 06.06.2010
comment
@Nev_Rahd Поскольку факты в ленте, которые будут назначены этим измерениям, физически назначаются измерениям SK, поэтому дата вступления в силу не будет иметь значения при запросе к БД. - person Cade Roux; 06.06.2010

arrow_upward
0
arrow_downward

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

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

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

person Todd McDermid    schedule 07.06.2010