Проблема с предполагаемым участником, использующим компонент SCD измерения слияния SSIS - PullRequest
Новая
       56

Проблема с предполагаемым участником, использующим компонент SCD измерения слияния SSIS

1 голос
/ 14 декабря 2011

Я использую компонент SCD Dimension Merge SCGE (http://dimensionmergescd.codeplex.com/)), и у меня возникает ситуация, когда у меня есть конфигурация со столбцами SCD1 и SCD 2. У меня есть строки, в которых установлен флаг InferredMember, однако компонент вставил новые строки ине сбрасывал текущий флаг в существующих предполагаемых строках.

Кто-нибудь еще использует этот компонент, и видели ли вы, что он работает правильно? Я неправильно понимаю? Насколько я понимаю, столбцы SCD2 становятся SCD1, где InferredMember равен true,это неправильно?

Сортировка выполняется в базе данных по бизнес-ключу, и столбцы сортировки настроены на совпадение. Выходные данные компонента DMSCD подключаются непосредственно к компонентам назначения OLE DB Command / OLE DB.в производстве и в других случаях работал правильно каждый день в течение нескольких месяцев.

Это результат аудита из прогона: 

ExistingDimensionInputRowCount = 719941
SpecialMemberInputRowCount = 1
SourceSystemInputRowCount = 720516
UnchangedOutputRowCount = 719941
NewOutputRowCount = 720517
DeletedOutputRowCount = 0
SCD2ExpiredOutputRowCount = 0
SCD2NewOutputRowCount = 0
SCD1UpdatedOutputRowCount = 0
InvalidInputOutputRowCount = 0

Ответы [ 2 ]

2 голосов
/ 15 декабря 2011

У вас есть проблемы только с предполагаемыми участниками?И вы используете самую последнюю версию компонента, выпущенную на CodePlex?

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

  1. Вы изменяете даты, используя компоненты производного столбца после DMSCD, и /или не обновляют / не вставляют информацию о дате, поставляемую DMSCD.Вместо этого вы используете жестко закодированные или переменные значения в производном столбце, значения по умолчанию в определении таблицы или неправильное отображение столбцов назначения.

  2. Порядок сортировки входных данных в DMSCD:неверен.Возможно, вы предполагаете, что для свойства IsSorted на выходе вашего источника OLE DB указано значение true, а для установки различных свойств столбцов SortKeyPosition достаточно - это не так.Либо удалите внесенные вами дополнительные изменения, либо используйте компонент Sort в потоке (для целей тестирования - мы можем исправить источник OLE DB позже).

0 голосов
/ 16 декабря 2011

Итак, чтобы ответить на мой собственный вопрос, да, я ошибаюсь. Один только флаг InferredMember не запускает поведение Inferred Member.

Предполагаемые члены - это скелетные записи, вставленные в таблицы измерений - часто сохраненными процедурами. - когда поиск суррогатного ключа не удается во время обслуживания таблицы фактов. Флаг InferredMember обычно запускает процесс загрузки измерения, чтобы заполнить оставшиеся поля в записях скелетных предполагаемых членов. А в случае полей SCD2 в записях Inferred Member они обрабатываются как SCD1, и новые записи создавать не следует.

С помощью экспериментов я смог определить, что для компонента DMSCD требуется, чтобы скелет Предполагаемого участника включал хотя бы бизнес-ключ, флаг Предполагаемого участника и Активную дату, которая была в прошлом - я использовал текущую дату, поэтому записи не рассматривались как записи предполагаемого члена, они обрабатывались как новые записи и создавались дубликаты.

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

...