Datawarehouse Fact table вопрос

Question

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

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

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

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

Answer 1

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

M

Answer 2

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

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

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

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

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

Answer 3

Считайте 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 ;

Answer 4

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

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

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

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

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

Answer 5

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

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