Вопрос таблицы фактов хранилища данных

У меня есть таблица фактов под названием Кредиты. В этой таблице в идентификаторе кредита, дата кредита был сделан, и сумма кредита.

Бизнес-требование, которое я не совсем знаю, как сделать в хранилище данных, заключается в следующем. Сумма кредита может быть скорректирована в будущем. Итак, скажем, 1 августа мы делаем кредит с идентификатором 1 и суммой 20 000. 1 октября этот кредит корректируется до 19000. Нужно ли помещать в таблицу фактов две записи с одинаковым идентификатором, разными датами и суммами?

Создать новую таблицу (таблицу измерений) с суммой кредита и датой? Как лучше всего реализовать этот сценарий?

В производственной базе данных у нас есть таблица для общей суммы кредита, а затем таблица для суммы кредита, поэтому комбинация сумм кредита равна totalLoanAmount.


data-warehouse database-design
person Rjc    schedule 17.09.2010    source источник

Ответы (5)


arrow_upward
3
arrow_downward

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

M

person MarkH    schedule 20.09.2010

arrow_upward
1
arrow_downward

Рассматривайте LoanID как вырожденное измерение и вводите исправление отдельно. Вы также можете использовать измерение типа транзакции для описания: кредитов, платежей, исправлений и т. д.

DateKey CustomerKey TransacionTypeKey LoanID    Amount
---------------------------------------------------------
20100801    175          1               1     20000.00
20101001    175          2               1    - 1000.00

Показать все кредиты по клиенту, по кредиту

select
      CustomerKey
    , LoanID
    , sum(Amount) as Amt
from factLoan
group by CustomerKey, LoanID
order by CustomerKey, LoanID ;
person Damir Sudarevic    schedule 17.09.2010

arrow_upward
1
arrow_downward

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

В медленно меняющемся измерении Типа 1 новая информация просто перезаписывает исходную информацию. Другими словами, история не сохраняется.

В медленно изменяющемся измерении типа 2 в таблицу добавляется новая запись для представления новой информации. Таким образом, будет присутствовать как оригинальная, так и новая запись. Новая запись получает свой собственный первичный ключ.

В медленно изменяющемся измерении типа 3 будет два столбца для указания конкретного интересующего атрибута: один указывает исходное значение, а другой — текущее значение. Также будет столбец, который указывает, когда текущее значение становится активным.

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

person Saad El Oualji    schedule 15.06.2015

arrow_upward
0
arrow_downward

Нужно ли вам на самом деле несколько версий, зависит от требований. Вам нужно только сообщить суммы кредита как есть или вам нужно также знать положение как было? Если вы не уверены, возможно, имеет смысл сохранить историю (несколько версий). Мое предположение состояло бы в том, чтобы сохранить историю.

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

person nvogel    schedule 17.09.2010
comment
Мне нужно знать обе суммы кредита как есть, так и как было. Но мне также нужно иметь возможность сказать, есть ли один кредит с двумя корректировками суммы кредита, то есть 1 один кредит для целей подсчета. Поэтому я подумал о том, чтобы сделать таблицу фактов для кредитов и подтаблицу для детализированных сумм кредитов. Имеет ли это смысл? - person Rjc; 22.09.2010

arrow_upward
0
arrow_downward

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

  1. Вставьте новую строку с дельтой к факту. В этом есть теперь две строки для кредита. Это означает, что первичным ключом для факта займа не может быть только идентификатор займа. Он должен (логически, не обязательно физически) быть идентификатором загрузки и датой или идентификатором ссуды и номером записи (с датой в качестве другого атрибута). Результат будет таким, как вы сказали. Я бы изменил TransactionTypeKey на TransactionTypeCode, что является более правильным названием.

  2. Обновите факт с новым балансом. В этом случае окончательный результат сохраняется, но изменения теряются. Первичный ключ — LoanID; дата является атрибутом.

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

Что касается комментария Саада Эль Уальджи, то это вовсе не случай SCD, а детальный дизайн фактов. Его описание SCD верно, но SCD ​​описывает изменения измерений, а не изменения фактов.

person TomFH    schedule 06.08.2015