ddmitry/de-roadmap
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
ddadmin
2025-11-23 12:07:59 +03:00
parent 0521b6cc9a
commit add67223b8
1 changed files with 21 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dwh-modeling/DataVault.md
+21 -19
View File
@@ -104,13 +104,13 @@ erDiagram
timestamp load_dttm timestamp load_dttm
} }
SAT_ORDER_STATUS { SAT_ORDER_STATUS {
varchar link_key FK varchar link_key FK
varchar hashdiff varchar hashdiff
varchar status varchar status
varchar record_source varchar record_source
timestamp load_dttm timestamp load_dttm
} }
``` ```
Как это читать: Как это читать:
@@ -119,6 +119,8 @@ erDiagram
* ⚪ LINK_ORDER_CUSTOMER — «именно этот заказ сделал именно этот клиент»; * ⚪ LINK_ORDER_CUSTOMER — «именно этот заказ сделал именно этот клиент»;
* 🟡 SAT_… — как менялись атрибуты (email, статус и т.п.) во времени. * 🟡 SAT_… — как менялись атрибуты (email, статус и т.п.) во времени.
На схеме выше для наглядности показаны бизнес-ключи (`customer_bk`, `order_id`, `link_key`), а в DDL-примерах дальше используются уже хэш-ключи (`hk_*`) — это два уровня детализации одной и той же модели.
## 3. Три типа таблиц в Data Vault 2.0 ## 3. Три типа таблиц в Data Vault 2.0
Чуть менее «сказочно», чуть более технично. Чуть менее «сказочно», чуть более технично.
@@ -274,7 +276,7 @@ Business Vault (BV) — следующий слой над Raw DV:
Если сильно упростить: Если сильно упростить:
* Raw DV → «мы всё собрали»; * Raw DV → «мы всё собрали»;
* Business DV → «мы это привели в вид, с которым удобно жить»; * Business Vault → «мы это привели в вид, с которым удобно жить»;
* DM → «мы вынесли это на витрину в понятной форме». * DM → «мы вынесли это на витрину в понятной форме».
#### 5.2.1. PIT-таблицы (Point-in-Time) #### 5.2.1. PIT-таблицы (Point-in-Time)
@@ -284,7 +286,7 @@ PIT (Point-in-Time) решает очень конкретную боль:
> «Покажи, как объект выглядел **на дату X**, но так, чтобы запрос был простым». > «Покажи, как объект выглядел **на дату X**, но так, чтобы запрос был простым».
Если у нас есть несколько сателлитов с историей (например, `sat_customer_info`, `sat_customer_segment`, `sat_customer_risk`), то без PIT любой запрос превращается в пачку условий Если у нас есть несколько сателлитов с историей (например, `sat_customer_info`, `sat_customer_segment`, `sat_customer_risk`), то без PIT любой запрос превращается в пачку условий
`BETWEEN valid_from AND valid_to` или оконных функций. `BETWEEN valid_from AND valid_to` (в effectivity-сателлитах или любых таблицах с периодами действия) или оконных функций.
**Идея PIT:** **Идея PIT:**
@@ -412,7 +414,7 @@ GROUP BY c.customer_bk;
Bridge — это **не обязательный элемент DV**, а инструмент оптимизации. Bridge — это **не обязательный элемент DV**, а инструмент оптимизации.
Он нужен тогда, когда цепочки Links становятся длинными и повторяются во многих отчётах. Он нужен тогда, когда цепочки Links становятся длинными и повторяются во многих отчётах.
#### 5.2.3. Business-правила и derived-таблицы Business-правила и derived-таблицы #### 5.2.3. Business-правила и derived-таблицы
В BV логично размещать бизнес-логику, которая: В BV логично размещать бизнес-логику, которая:
@@ -494,10 +496,10 @@ customer_bk | record_source | load_dttm
101 | CRM | 2023-01-10 10:00 101 | CRM | 2023-01-10 10:00
SAT_CUSTOMER_INFO SAT_CUSTOMER_INFO
customer_bk | load_dttm | email | city customer_bk | load_dttm | hashdiff | email | city
--------------------------------------------------------------------- ---------------------------------------------------------------------------
101 | 2023-01-10 10:00 | a@example.com | Moscow 101 | 2023-01-10 10:00 | ... | a@example.com | Moscow
101 | 2023-06-01 09:00 | alice@newmail.com | Moscow 101 | 2023-06-01 09:00 | ... | alice@newmail.com | Moscow
HUB_ORDER HUB_ORDER
-------------------------------------- --------------------------------------
@@ -507,11 +509,11 @@ order_id | record_source | load_dttm
5002 | SHOP | 2023-06-11 09:30 5002 | SHOP | 2023-06-11 09:30
SAT_ORDER_STATUS SAT_ORDER_STATUS
order_id | load_dttm | status order_id | load_dttm | hashdiff | status
------------------------------------------------------- --------------------------------------------------------------
5001 | 2023-06-10 12:00 | created 5001 | 2023-06-10 12:00 | ... | created
5001 | 2023-06-10 12:05 | paid 5001 | 2023-06-10 12:05 | ... | paid
5001 | 2023-06-11 09:00 | shipped 5001 | 2023-06-11 09:00 | ... | shipped
... | ... | ... ... | ... | ...
``` ```