Назначение архитектурных слоёв, финансовое ядро, правила интеграции и критерии принятия решений.
3 мин чтения·База знаний
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Корпоративное хранилище должно объединять данные нескольких источников, сохранять смысл и происхождение показателей, поддерживать исторические состояния и делать результат проверяемым.
Для финансовой области этого недостаточно сформулировать как «загрузили таблицы и написали отчёт». Значение имеют достоверность сумм, бухгалтерские правила, временная семантика, единые справочники и возможность объяснить происхождение каждого результата.
Названия и число слоёв не стандартизированы. В конкретной системе они зависят от архитектуры и эксплуатационных требований. Слой контроля логически проходит через весь конвейер, а не обязан быть физически одной отдельной схемой.
Предлагаемый минимальный набор сущностей: source_event, account, document, journal_entry, journal_line, currency, financial_period, load_batch и отдельные представления результатов сверок.
Сущности имеют разные идентификаторы, потому что одна финансовая операция не обязательно соответствует одной бухгалтерской строке. Для каждого показателя фиксируем правила знаков, валюту, точность и деловое время.
В EDWH могут использоваться разные способы моделирования:
Нормализованное интеграционное ядро - полезно, когда важна однозначная модель сущностей, а число источников велико.
Data Vault - подход к интеграции и прослеживаемой истории бизнес-ключей и связей; требует правильного выбора зерна и правил сателлитов.
Dimensional modeling - факты и измерения, удобные для определённых классов расчётов и аналитических выборок.
Это не взаимоисключающие варианты: интеграционное ядро и витрины могут опираться на разные модели. Для начального лабораторного проекта выбран минимальный нормализованный журнал и представления финансовых расчётов - без попытки имитировать промышленную архитектуру банка.
Два источника передают операции в разных валютах, один - со сторнированием, второй - с заменой исходной записи. Нужно получить единую историю операций и корректные остатки за прошлый месяц в двух срезах: «как знали тогда» и «как знаем сейчас».
Такую задачу невозможно корректно решить одним JOIN. Требуется сначала установить модель времени, правила корректировок, бизнес-ключи и критерии сверки.
An enterprise data warehouse integrates data from multiple sources, preserves the meaning and lineage of metrics, maintains historical states, and makes results verifiable.
For financial data, it is not enough to say that tables were loaded and a report was written. Amount accuracy, accounting rules, time semantics, consistent reference data, and the ability to trace every result matter.
Layer names and counts are not standardized. They depend on the architecture and operating requirements. Control is a logical concern across the pipeline; it does not have to be one physical schema.
A proposed minimal set of entities includes source_event, account, document, journal_entry, journal_line, currency, financial_period, load_batch, and separate reconciliation result views.
These entities need different identifiers because one financial operation does not necessarily map to one accounting line. Define sign rules, currency, precision, and business time for every metric.
EDWH solutions can use different modeling approaches:
Normalized integration core is useful when an unambiguous entity model matters and there are many sources.
Data Vault supports integration and traceable history of business keys and relationships; it requires careful grain and satellite rules.
Dimensional modeling organizes facts and dimensions for particular classes of calculations and analytical queries.
These approaches are not mutually exclusive. The integration core and marts may use different models. The initial lab uses a minimal normalized journal and financial calculation views; it does not attempt to imitate a production banking architecture.
Two sources send transactions in different currencies. One sends reversals; the other replaces its original record. The goal is a unified transaction history and correct prior-month balances in two views: what was known then and what is known now.
A single JOIN cannot solve this correctly. First define time semantics, correction rules, business keys, and reconciliation criteria.