Различные сценарии с медленно изменяющимися размерами (SCD) Тип 2

В настоящее время у нас есть таблица в хранилище данных под названием «Карты». Это было разработано как медленно меняющееся измерение типа 2; где мы создаем новую запись, если состояние карты изменится, чтобы мы могли отслеживать изменения состояния карты.

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

cardId     state          balanceAsAt     balance  ....
1          ACTIVE         2014-01-01      100.00
1          ACTIVE         2014-01-02       99.00
1          DELETED        2014-01-03        0.00

Каков оптимальный способ хранения данных, если мне нужно выполнить ETL для диапазона прошлых дат (например, 2 января 2014 г.) сегодня, в феврале 2015 г. (например, для 2014-01-01), при условии, что нет возможности получить прошлое состояние карты?

Вариант А - вставить запись с текущими данными за прошедшие сутки

cardId     state          balanceAsAt     balance  ....
1          ACTIVE         2014-01-01      100.00
1          DELETED        2014-01-01        0.00   [new entry here? - however now the card seems to have been 're-activated' on the 2nd, which is not the case]
1          ACTIVE         2014-01-02       99.00
1          DELETED        2014-01-03        0.00

Вариант Б - не изменять записи, уже созданные в измерении

cardId     state          balanceAsAt     balance  ....
1          ACTIVE         2014-01-01      100.00
1          ACTIVE         2014-01-02       99.00
1          DELETED        2014-01-03        0.00

Какие-нибудь другие варианты / стандартные практики?


person test    schedule 26.02.2015    source источник
comment
Я не понимаю проблемы - что вы имеете в виду под execute past ETL today, Feb 2015? Почему вы вставляете дополнительную строку для 2014-01-01?   -  person Marek Grzenkowicz    schedule 26.02.2015
comment
Извините, я хотел сказать, какие есть варианты, следует ли мне выполнять ETL для предыдущего диапазона дат (например, 2014-01-01) - должны ли мы включать новую запись из-за обновленного состояния карты?   -  person test    schedule 27.02.2015


Ответы (1)


Прочитав описание, я понял, что у вас в руках очень быстро меняющееся измерение. Мое предложение было бы, если возможно, изменить атрибут баланса на медленно меняющиеся измерения типа 1 (обновление) и вести учет балансов в таблице фактов. Для этого у вас есть два варианта:

  1. снимок: на каждый день создается запись для каждой карты. Это очень хорошо, например, если вам нужно знать (часто), каков был средний остаток на балансе карт в данный день (или в течение данного месяца).
  2. журнал транзакций: таблица фактов, в которой вы отслеживаете транзакции по карте, а также баланс до и после транзакции. Это имеет то преимущество, что снимок занимает меньше места на жестком диске.

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


Мое второе замечание заключается в том, что вы не реализуете медленно меняющиеся размеры должным образом. Вы не реализуете ни размерные ключи, ни флаги медленно изменяющихся размеров.

Правильно реализованное измерение будет выглядеть так:

keyCard   cardId         state          startDate       endDate      balance  
1          1          ACTIVE         2014-01-01     2014-01-03   100.00
2          1          ACTIVE         2014-01-03     2014-02-01   99.00
3          1          DELETED        2014-02-01     null          0.00

Вы можете получить последнюю запись, выполнив:

  select * from DimensionCards where endDate is null;
person SQL.injection    schedule 03.03.2015
comment
Спасибо за Ваш ответ. Да, конечно, я включил только необходимые поля. У меня есть дата начала и окончания вместе с флагом cardIsActive, который имеет значение ИСТИНА, когда у меня есть последняя версия для этой карты. - person test; 05.03.2015