Хранилище данных - управление версиями данных

Question

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

Чтобы объяснить проблему лучше.Предположим, у нас есть счет А, и за 2 месяца произошли 4 транзакции, которые влияют на его баланс, меняя его с 10000 на 20000. Когда я запускаю отчет за этот месяц, он показывает штраф, который показывает активность, получающую это значение.Теперь это становится трудным, через месяц после того, как я задним числом транзакции задним числом изменяю баланс, изменяя его с 20000 на 15000.

Запуск отчета.мне 15000.

Для иллюстрации лучше обратиться к данным ниже.

---

Транзакции за сентябрь и октябрь

с обратной датой транзакции от 28 октября по 13 сентября на сумму 500

исделка с датой возврата от 8 ноября на 17 сентября для зачисления -50

╔═════════════════╦═════════════════════════╦════════╦══════════════════╦═══════════════╦═════════════╦═════════╗
║ Key_Transaction ║ SK_TransactionEffective ║ Amount ║ PrincipleBalance ║ SK_ReportDate ║ SK_AsOfDate ║ Version ║
╠═════════════════╬═════════════════════════╬════════╬══════════════════╬═══════════════╬═════════════╬═════════╣
║               1 ║ 12/09/2018              ║  -1000 ║            20000 ║ 12/09/2018    ║ NULL        ║ 1       ║
║               6 ║ 13/09/2018              ║   -500 ║            19500 ║ 13/09/2018    ║ 28/10/2018  ║ 2       ║
║               2 ║ 16/09/2018              ║    -50 ║            19950 ║ 16/09/2018    ║ NULL        ║ 1       ║
║               7 ║ 16/09/2018              ║    -50 ║            19450 ║ 16/09/2018    ║ 28/10/2018  ║ 2       ║
║              12 ║ 16/09/2018              ║     50 ║            19950 ║ 16/09/2018    ║ 8/11/2018   ║ 3       ║
║               3 ║ 1/10/2018               ║    250 ║            20200 ║ 30/09/2018    ║ NULL        ║ 1       ║
║               8 ║ 1/10/2018               ║    250 ║            19700 ║ 30/09/2018    ║ 28/10/2018  ║ 2       ║
║              13 ║ 1/10/2018               ║    250 ║            20200 ║ 30/09/2018    ║ 8/11/2018   ║ 3       ║
║               4 ║ 6/10/2018               ║  -1200 ║            19000 ║ 6/10/2018     ║ NULL        ║ 1       ║
║               9 ║ 6/10/2018               ║  -1200 ║            17800 ║ 6/10/2018     ║ 28/10/2018  ║ 2       ║
║              14 ║ 6/10/2018               ║  -1200 ║            19000 ║ 6/10/2018     ║ 8/11/2018   ║ 3       ║
║               5 ║ 22/10/2018              ║    100 ║            19100 ║ 22/10/2018    ║ NULL        ║ 1       ║
║              10 ║ 22/10/2018              ║    100 ║            17900 ║ 22/10/2018    ║ 28/10/2018  ║ 2       ║
║              15 ║ 22/10/2018              ║    100 ║            19100 ║ 22/10/2018    ║ 8/11/2018   ║ 3       ║
║              11 ║ 29/10/2018              ║  -1000 ║            16900 ║ 29/10/2018    ║ NULL        ║ (New)1  ║
║              16 ║ 29/10/2018              ║  -1000 ║            18100 ║ 29/10/2018    ║ 8/11/2018   ║ (New)2  ║
╚═════════════════╩═════════════════════════╩════════╩══════════════════╩═══════════════╩═════════════╩═════════╝

Теперь, когда я запускаю отчет за сентябрь (с 2018 по 01-01 до 2018-09-30)Я должен быть V1 или когда SK_AsOfDate равен NULL

. Если я запускаю отчет за октябрь (с 2018-10-01 по 2018-10-31), моя последняя запись должна быть (11) с основным балансом 16900

И мой текущий баланс Принципов (по состоянию на 2018-11-09) должен быть рассчитан как остаток от (16) с PB (18100)

Я добавил SK_AsOfDate, чтобы попытатьсяЯ имею дело с версионностью, но я все еще изо всех сил пытаюсь найти простой и элегантный способ добиться этого "Какой у меня был баланс на 2018-09-30 годы, который будет игнорировать изменения V2 и V3.

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

Answer 1

В финансовых (и некоторых других) данных транзакции вы в основном имеете два временных измерения .

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

Дата бронирования - это отметка времени транзакции, введенная в вашу систему бронирования.Иногда называется дата входа .

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

Два измерения времени позволяют два разных вида отчетов .

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

Answer 2

Я думаю, что ваш случай может быть решен с помощью таблиц «моментальных снимков».В финансовом мире, который вы разработали по состоянию на 2018-10-31 или на 2018-11-09 годы, это важно, и вам нужно сохранять копию своих данных для каждого «по состоянию», они могут отличаться для каждой организации, которая выглядит как вашаеженедельноЭто зависит от вас, чтобы решить частоту.Когда у вас есть этот набор данных, независимо от конечного состояния, вы можете вернуться и получить точный отчет.

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

Дайте мне знать, если это решит вашу проблему.

Answer 3

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

Первый шаг - определить businesskey, который позволил бы уведомить о разнице.Изменяется ли сумма или PrincipleBalancefor Key_Transaction во времени или поступают только новые записи?Попробуйте создать снимки таблицы, чтобы найти разницу значений во времени, чтобы создать хороший бизнес-ключ.

Некоторые хорошие идеи можно найти здесь: http://www.disoln.org/2013/12/Design-Approach-to-Handle-Late-Arriving-Dimensions-and-Late-Arriving-Facts.html

Что такое исходная база данных?В Sql Server вы можете попробовать использовать Change Data Capture (он должен быть включен на сервере) или создать механизм, упомянутый выше в вашем ETL.

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