From add67223b80994d4007088291f167897603c922e Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Sun, 23 Nov 2025 12:07:59 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9C=D0=B5=D0=BB=D0=BA=D0=B8=D0=B5=20=D0=BF?= =?UTF-8?q?=D1=80=D0=B0=D0=B2=D0=BA=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dwh-modeling/DataVault.md | 40 ++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/dwh-modeling/DataVault.md b/dwh-modeling/DataVault.md index fba17c8..5e42d8f 100644 --- a/dwh-modeling/DataVault.md +++ b/dwh-modeling/DataVault.md @@ -104,13 +104,13 @@ erDiagram timestamp load_dttm } - SAT_ORDER_STATUS { - varchar link_key FK - varchar hashdiff - varchar status - varchar record_source - timestamp load_dttm - } + SAT_ORDER_STATUS { + varchar link_key FK + varchar hashdiff + varchar status + varchar record_source + timestamp load_dttm + } ``` Как это читать: @@ -119,6 +119,8 @@ erDiagram * ⚪ LINK_ORDER_CUSTOMER — «именно этот заказ сделал именно этот клиент»; * 🟡 SAT_… — как менялись атрибуты (email, статус и т.п.) во времени. +На схеме выше для наглядности показаны бизнес-ключи (`customer_bk`, `order_id`, `link_key`), а в DDL-примерах дальше используются уже хэш-ключи (`hk_*`) — это два уровня детализации одной и той же модели. + ## 3. Три типа таблиц в Data Vault 2.0 Чуть менее «сказочно», чуть более технично. @@ -274,7 +276,7 @@ Business Vault (BV) — следующий слой над Raw DV: Если сильно упростить: * Raw DV → «мы всё собрали»; -* Business DV → «мы это привели в вид, с которым удобно жить»; +* Business Vault → «мы это привели в вид, с которым удобно жить»; * DM → «мы вынесли это на витрину в понятной форме». #### 5.2.1. PIT-таблицы (Point-in-Time) @@ -284,7 +286,7 @@ PIT (Point-in-Time) решает очень конкретную боль: > «Покажи, как объект выглядел **на дату X**, но так, чтобы запрос был простым». Если у нас есть несколько сателлитов с историей (например, `sat_customer_info`, `sat_customer_segment`, `sat_customer_risk`), то без PIT любой запрос превращается в пачку условий -`BETWEEN valid_from AND valid_to` или оконных функций. +`BETWEEN valid_from AND valid_to` (в effectivity-сателлитах или любых таблицах с периодами действия) или оконных функций. **Идея PIT:** @@ -412,7 +414,7 @@ GROUP BY c.customer_bk; Bridge — это **не обязательный элемент DV**, а инструмент оптимизации. Он нужен тогда, когда цепочки Links становятся длинными и повторяются во многих отчётах. -#### 5.2.3. Business-правила и derived-таблицы Business-правила и derived-таблицы +#### 5.2.3. Business-правила и derived-таблицы В BV логично размещать бизнес-логику, которая: @@ -494,10 +496,10 @@ customer_bk | record_source | load_dttm 101 | CRM | 2023-01-10 10:00 SAT_CUSTOMER_INFO -customer_bk | load_dttm | email | city ---------------------------------------------------------------------- -101 | 2023-01-10 10:00 | a@example.com | Moscow -101 | 2023-06-01 09:00 | alice@newmail.com | Moscow +customer_bk | load_dttm | hashdiff | email | city +--------------------------------------------------------------------------- +101 | 2023-01-10 10:00 | ... | a@example.com | Moscow +101 | 2023-06-01 09:00 | ... | alice@newmail.com | Moscow HUB_ORDER -------------------------------------- @@ -507,11 +509,11 @@ order_id | record_source | load_dttm 5002 | SHOP | 2023-06-11 09:30 SAT_ORDER_STATUS -order_id | load_dttm | status -------------------------------------------------------- -5001 | 2023-06-10 12:00 | created -5001 | 2023-06-10 12:05 | paid -5001 | 2023-06-11 09:00 | shipped +order_id | load_dttm | hashdiff | status +-------------------------------------------------------------- +5001 | 2023-06-10 12:00 | ... | created +5001 | 2023-06-10 12:05 | ... | paid +5001 | 2023-06-11 09:00 | ... | shipped ... | ... | ... ```