Моделирование финансовых данных: зерно, ключи, история

Сначала зерно, потом таблицы#

Зерно факта - строгое определение того, что представляет одна строка. Для финансовой системы это должно быть решено до проектирования таблиц и составления SQL.

Примеры:

fact_source_transaction: одна строка на операционное событие в конкретной системе.
fact_journal_line: одна строка на бухгалтерскую строку проводки.
fact_daily_account_balance: одна строка на счёт, валюту и дату среза (с учётом юридического лица и других измерений, если требуются).

Эти факты нельзя безусловно объединять в одну таблицу: разный уровень детализации может приводить к удвоению сумм при соединениях.

Ключи и происхождение#

Не смешиваем идентификатор в источнике и сквозной идентификатор EDWH. Бизнес-ключ может иметь вид (source_system, source_event_id); технический суррогатный ключ используют для эффективного хранения связей или версий.

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

Минимальная модель:

source_event 1 ─── n journal_entry 1 ─── n journal_line
                         │                       │
                         └── document_id          └── account_code

account / currency / financial_period - справочные измерения

В учебном стенде отношение упрощено: одному событию соответствует одна двухстрочная запись. Это осознанное ограничение лаборатории, а не универсальное свойство финансовых систем.

Движения и снимки#

Транзакционный факт хранит произошедшие события и допускает естественную агрегацию движения по разрешённым измерениям.
Снимок остатка фиксирует состояние на дату. Остатки обычно неаддитивны по времени.
Агрегат оборотов ускоряет расчёт, но не заменяет атомарных записей, необходимых для сверок и аудита.

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

Историзация#

Для справочников обычно рассматривают варианты SCD, включая SCD Type 2, где сохраняются прежние версии атрибутов. Но история бухгалтерских событий и история справочников - разные задачи. Позднее сторно лучше представлять как самостоятельное финансовое событие, когда это соответствует контракту источника, а не как молчаливое обновление исходной проводки.

У каждого уровня следует описать, что означает «действует на дату», и отдельно - «было известно системе на дату».

Контрольный пример#

Если одна операция создаёт четыре строки проводок, соединение transaction с journal_line даёт четыре строки. Суммирование суммы исходной операции после такого соединения без изменения зерна завысит результат в четыре раза.

Нужно либо считать показатель на уровне transaction, либо агрегировать journal_line к нужному зерну до соединения с другими источниками.

Подробнее: временная семантика и финансовые инварианты.

Define the grain before the tables#

Fact grain is a precise statement of what one row represents. For a financial system, define it before designing tables or writing SQL.

Examples:

fact_source_transaction: one row per operational event in a specific system.
fact_journal_line: one row per accounting journal line.
fact_daily_account_balance: one row per account, currency, and snapshot date, with legal entity and other required dimensions.

These facts cannot be combined indiscriminately. Different levels of detail can multiply amounts in joins.

Keys and lineage#

Keep the source identifier distinct from the EDWH-wide identifier. A business key might be (source_system, source_event_id); a technical surrogate key can make relationships or versions more efficient to store.

Business-key uniqueness must follow the source contract. If source identifiers are unstable or reused, define a composite identity rule and detect collisions.

A minimal model might be:

source_event 1 ─── n journal_entry 1 ─── n journal_line
                         │                       │
                         └── document_id          └── account_code

account / currency / financial_period - reference dimensions

The lab simplifies this relationship: one event produces a two-line entry. This is a deliberate lab constraint, not a universal property of financial systems.

Movements and snapshots#

A transaction fact stores events and supports aggregation of movements across permitted dimensions.
A balance snapshot records a state at a point in time. Balances are usually non-additive over time.
A turnover aggregate can speed up calculations, but does not replace atomic records needed for reconciliation and audit.

Define currency, sign conventions, and units separately. Amounts in different currencies cannot be added without explicit conversion.

History#

Reference data often uses SCD strategies, including Type 2, which preserves prior attribute versions. Accounting-event history and reference-data history are different problems. When the source contract supports it, a late reversal is better represented as a separate financial event than as a silent update to the original journal entry.

For each layer, define what “valid on a date” means and separately what “known to the system on a date” means.

A control example#

If one transaction creates four journal lines, joining transaction to journal_line creates four rows. Summing the transaction amount after this join without changing the grain overstates the result fourfold.

Either calculate the metric at transaction grain, or aggregate journal_line to the required grain before joining it to other sources.

See also: time semantics and financial invariants.