Мелкие правки

dwh-modeling/DataVault.md

@@ -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
 ...      | ...                 | ...
 ```