완전히 시뮬레이션된 EDW 여섯 개 — HKBC(홍콩 유니버설 뱅크), AYA(홍콩 복합 보험사), Smire(홍콩 복합용도 랜드로드), Hilson(글로벌 호텔 그룹), Cathea(홍콩 화물·여객 물류), P&C(소비재) — 현실적인 벤더 고유 스키마, ClickHouse의 메달리온 준비 브론즈, 라이브 이벤트 스트림. VibeBI에서 시맨틱 레이어, 디멘셔널 모델링, 셀프서비스 분석을 시험하기 위해 만들었습니다.
가상 회사 안내: 「HKBC」는 데모 목적으로만 만들어진 완전히 가상의 회사입니다. HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited 또는 실제 은행과 제휴·후원·대변하지 않습니다.
HKBC (Hong Kong Banking Corporation)는 Central에 본사를 둔 홍콩 유니버설 뱅크로, Wealth and Personal Banking, Commercial Banking, Global Banking and Markets를 운영합니다. HKD 예금을 받고 HIBOR 주택담보대출과 무담보 신용을 취급하며, 카드를 발행하고 24×7 Faster Payment System과 PearlPay(PayMe급) 레일을 운영하며, Greater Bay Area 무역을 금융하고 7.75–7.85 태환 밴드 안에서 USD/HKD 및 CNH FX를 장부에 올립니다.
장부는 홍콩섬·구룡·신계의 약 10개 지점과 첸하이 GBA 도매 데스크, 런던 마켓 데스크를 아우릅니다. 각 시뮬레이션 일에 상관된 FPS 입금, 카드 승인, CHATS/SWIFT 이체, 코어 복식 분개, AML 알림, SAP 분개를 생성하며, 설날 / 1분기 세금대출 급증 PearlPay P2P 거래량, FPS 수금, 개인대출 취급을 끌어올립니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템입니다. 전체 EDW에는 브론즈 테이블 60개 전반의 추가 엔터티, 하위 유형, 전용 테이블(AML 케이스, ECL 충당금, 증권 주문, 한도 레드라인 등)이 포함됩니다. V2에서는 FpsPayment 및 관련 도메인 클래스가 PayToPostToBalance 중추를 구동합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| 지점 / 데스크 | hkbc_core | branch |
| 상품 카탈로그 | hkbc_core | product |
| 고객 (CIF) | hkbc_core · salesforce | customer · account · contact |
| 예금 / 대출 계좌 | hkbc_core | account · posting · deposit_balance |
| FPS / CHATS / SWIFT | hkicl_fps · hkicl_chats · swift | proxy · payment · rtgs_payment · message |
| 카드 | fiserv_visionplus | card · authorization · clearing_transaction |
| PearlPay 월렛 | hkbc_pay | wallet · wallet_payment |
| 무역금융 | hkbc_trade | documentary_credit · guarantee |
| FX / 마켓 | murex · bloomberg | fx_trade · position · fx_rate |
| AML / 신용 위험 | nice_actimize · moodys_risk | aml_alert · case · credit_facility · ecl_provision |
| 웰스 딜링 | hkbc_wealth | holding · securities_order |
| GL / COA | sap_s4 | journal_entry · journal_line |
HkbcEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
PayToPostToBalance 이 기본 프로세스 중추입니다. FpsPayment.execute_lifecycle() (및 PearlPay, 카드, CHATS, SWIFT 대응 클래스)는 레일 메시지 → 코어 복식 분개 → 선택적 AML 알림 → EOD 예금 잔액 → GL 순으로 진행합니다. HkbcPortfolio.publish_foundation() 결제가 돌기 전에 지점, 상품, CIF 고객, 계좌를 마스터합니다. 서비스 객체가 CMB 무역, GBM FX, 웰스, 리스크, 코퍼레이트 행을 방출합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
Branch | branch_code | hkbc_core에서 마스터된 지점 / 도매 데스크 |
Product | product_code | CASA, 주택담보, 카드, 월렛, 무역, FX 카탈로그 |
Customer | customer_id | CIF + KYC 세그먼트; Salesforce CRM 미러 |
Account | account_id | publish() → post_pair() 균형 원장 |
FpsPayment | payment_id | execute_lifecycle() → 레일 → 분개 → AML |
DocumentaryCredit | lc_id | CMB LC / 보증 발행 |
FxTrade | trade_id | Murex 티켓 → USD/HKD 포지션 |
flowchart LR
PORT[HkbcPortfolio.publish_foundation]
PAY[FpsPayment.execute_lifecycle]
PORT --> PAY
PAY --> RAIL[FPS / PearlPay / card / CHATS / SWIFT]
RAIL --> CORE[post_pair in hkbc_core]
CORE --> AML[Actimize AML]
CORE --> EOD[EOD deposit balance]
EOD --> GL[SAP S/4 journal]
CIF와 상품 마스터에서 레일, 코어 분개, 리스크, 재무 마감까지.
샘플 보기: 이는 HKBC 생태계를 관통하는 주요 가치 사슬을 보여 줍니다. 생성된 전체 EDW에는 여기에 표시되지 않은 교차 기능 통합, 웰스 딜링, GBA 무역 회랑을 포함한 소스 시스템 32개가 모두 포함됩니다.
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph master["CIF & product master"]
direction TB
CORE[hkbc_core CIF / account]
SF[salesforce]
CORE ~~~ SF
end
subgraph rails["Payments rails"]
direction TB
FPS[hkicl_fps]
PP[hkbc_pay PearlPay]
CARD[fiserv_visionplus]
CHATS[hkicl_chats · swift]
end
subgraph book["Core & risk"]
direction TB
POST[hkbc_core posting]
AML[nice_actimize]
ECL[moodys_risk]
POST ~~~ AML
AML ~~~ ECL
end
subgraph franchise["CMB · GBM · WPB"]
direction TB
TRD[hkbc_trade]
FX[murex]
WLT[hkbc_wealth]
TRD ~~~ FX
FX ~~~ WLT
end
subgraph corp["Corporate"]
direction TB
WD[workday]
S4[sap_s4 GL]
WD ~~~ S4
end
master --> rails --> book --> franchise --> corp
Harbourview Tower 본사와 직속 기능, 대표 소스 시스템 포함.
샘플 조직 구조: 이는 주요 보고 라인입니다. 전체 HKBC 조직에는 벤더 통합 32개 전반의 추가 지구 지점, GBA 데스크, 공유 서비스 기능이 포함됩니다.
flowchart TB
CEO[HKBC Hong Kong]
CEO --> WPB[Wealth & Personal Banking]
CEO --> CMB[Commercial Banking]
CEO --> GBM[Global Banking & Markets]
CEO --> RISK[Risk & AML]
CEO --> FIN[Finance & ALM]
CEO --> HR[Human resources]
CEO --> OPS[Operations & branches]
CEO --> LEG[IT / legal / security]
카탈로그 stage 기반부터 전사까지 테이블을 묶습니다.
표시된 샘플 구성: 이는 성숙 레이어에 분포된 전체 60개 테이블 인벤토리의 대표 단면입니다. 실제 분포는 기반부터 전사 골드 테이블까지의 완전한 데이터 리니지를 반영합니다.
flowchart LR F["foundation
~13 tables"] P["payments
~11 tables"] M["markets & risk
~12 tables"] C["commercial
~6 tables"] CO["corporate
~18 tables"] F --> P --> M --> C F -.-> CO P -.-> CO
논리 관계와 앵커 키. 고객 (customer_id) 및 계좌 (account_id)가 중추입니다. 결제는 다음으로 조인됩니다 source_txn_id.
샘플 다이어그램: 이 엔터티 관계 다이어그램은 핵심 논리 모델을 보여 줍니다. 생성된 전체 EDW에는 브론즈 테이블 60개 걸쳐 벤더 시스템 32개 추가 상세 테이블과 리니지 분기가 있습니다. 엔터티 인스턴스는 다음을 가집니다 entity_refs 조인 가능성을 시험하기 위해 방출되는 모든 이벤트에.
erDiagram
CUSTOMER ||--o{ ACCOUNT : holds
PRODUCT ||--o{ ACCOUNT : defines
BRANCH ||--o{ ACCOUNT : books
ACCOUNT ||--o{ PAYMENT : pays
ACCOUNT ||--o{ POSTING : ledgers
ACCOUNT ||--o{ DEPOSIT_BALANCE : snapshots
PAYMENT ||--o{ AML_ALERT : screens
COMMERCIAL_CLIENT ||--o{ TRADE_CREDIT : finances
ACCOUNT ||--o{ FX_TRADE : hedges
ACCOUNT ||--o{ WEALTH_ORDER : deals
벤더 접두사 32개, 브론즈 테이블 60개.
표시된 샘플 시스템: 아래 다이어그램은 대표 벤더 시스템입니다. 생성된 전체 데이터셋에는 이력 백필과 라이브 스트림 전반의 테이블 리니지와 통합 지점을 포함한 시스템 32개가 모두 들어 있습니다. 공유 소스 시스템 매니페스트는 kb/source_systems/ 은 산업 간에 재사용됩니다 — HKBC가 추가하는 hkbc_core, hkbc_pay, hkbc_trade, 그리고 hkbc_wealth 를 산업 고유 내부 시스템으로 더하고, 홍콩 시장 레일을 사용합니다.
각 테이블은 다음을 따릅니다 {source_system_}__{entity} 명명 규칙(예: hkbc_core__account, hkicl_fps__payment), 각 제품의 실제 내보내기 스키마에서 벤더 고유 컬럼 형태와 외래 키를 유지합니다. VibeBI는 레코드를 실버와 골드로 승격할 때 마스터 데이터 정합을 추론합니다.
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["hkbc_core branch · product · CIF · account"]
f2["salesforce · workday · sap_s4 dimensions"]
end
subgraph payments["Payments"]
direction TB
p1["hkicl_fps · hkbc_pay · fiserv_visionplus"]
p2["hkicl_chats · swift · core posting"]
end
subgraph markets["Markets & risk"]
direction TB
m1["murex · bloomberg · hkbc_trade · hkbc_wealth"]
m2["nice_actimize · moodys_risk"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce pipeline · hubspot · marketo"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · anaplan · adp · ukg"]
co2["genesys · zendesk · servicenow · okta"]
co3["splunk · ironclad · onetrust · greenhouse"]
end
foundation --> payments --> markets --> commercial
foundation --> corporate
payments --> corporate
V2 OOP 시뮬 → ClickHouse 브론즈, VibeBI 시맨틱 → 같은 인스턴스에서 실버 → 골드.
OOP 경로: kb/industries/hkbc/ 운영 중추와 엔터티 모델을 정의합니다. HkbcEnterpriseSimulation 도메인 라이프사이클을 순서대로 실행합니다. SourceSystem 어댑터가 벤더 고유 행을 다음으로 내보냅니다 hkbc_v2.
flowchart LR
subgraph kb["kb/industries/hkbc"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/hkbc"]
ORCH[HkbcEnterpriseSimulation]
DOM["FpsPayment.execute_lifecycle()
Account · Customer · FxTrade …"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse hkbc_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-hkbc — 60초 틱 경유 HkbcEnterpriseSimulation.generate().
라이브 주기: 각 틱은 PayToPostToBalance 상태 머신을 실행합니다. 도메인 객체가 상관된 FPS, PearlPay, 카드, CHATS, SWIFT, 코어 분개, AML, GL 행을 방출합니다. 오늘 라이브 틱은 홍콩 as_of 결제 테이프가 하루 동안 늘어납니다. 스케일은 틱마다 달라집니다(기본 베이스 5). 필요한 이력 구간은 백필할 수 있습니다 (--days N 라이브 스크립트 또는 CLI에서).
flowchart LR
START([60s tick]) --> SIM[HkbcEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> PAY[Payment lifecycles]
FOUND --> MKT[Trade · FX · wealth · risk]
PAY --> EVT[SourceSystem events]
MKT --> EVT
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
PayToPostToBalance 상태 머신 — 각 전이는 벤더 행을 방출하는 도메인 메서드입니다.
프로세스 중추: 다음에 정의됨 kb/industries/hkbc/process_model.yaml. 지연 도착 모드(SWIFT ack 지연, 승인 후 카드 클리어링, AML 케이스 지연, GL 배치 지연)와 예외 모드(FPS 거절, 카드 거절, AML 보류, 잔액 부족, LC 불일치)는 독립 난수 삽입이 아니라 같은 엔터티 라이프사이클에서 분기합니다.
flowchart LR
OPEN[account_opened] --> INIT[payment_initiated]
INIT --> POST[core_posted]
POST --> AML[aml_screened]
AML --> CLR[cleared]
CLR --> BAL[balance_snapshot]
BAL --> GL[posted_to_gl]
INIT -.->|fps_reject| REJ[fps_rejected]
INIT -.->|card_decline| DEC[card_declined]
POST -.->|aml_hold| HOLD[aml_hold]
모든 테이블에 동일한 리니지 봉투, 범주가 라이브 동작을 결정합니다.
샘플 범주: 브론즈 테이블 60개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["CIF · product · branch · account"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Payments · postings · LC · FX · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["AML · card auth · access · NPS"]
E2[Append each live tick]
end
BRONZE[("hkbc_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
가상 회사 안내: 「AYA」는 데모 목적으로만 만들어진 완전히 가상의 회사입니다. AXA SA, AXA Hong Kong and Macau 또는 실제 보험사와 제휴·후원·대변하지 않습니다.
AYA 는 홍콩 복합 보험사입니다. Life & Savings, Health(VHIS 및 직원 복리 포함), General Insurance를 전속 설계사, 방카슈랑스, 브로커, Aria by AYA 앱, 임베디드 e월렛 파트너로 판매합니다. 본사는 쿼리베이이며 Central 자문 센터, 침사추이 AYA Medical Centre, 마카오 지점, 첸하이 GBA 영업소가 있습니다.
사업은 상품 팩토리, Magnum급 언더라이팅, 분할 PAS(생명은 Ingenium급, 일반보험은 Guidewire), FPS 보험료 수금, Varicent 수수료, 24×7 자동차/여행 FNOL, FINEOS 건강 클레임, 재보험 출재, Prophet IFRS 17 평가, SAP S/4 분개를 아우르며, 태풍철 일반보험 클레임 증가 (6–10월)과 디지털·에이전시 채널 전반의 설날 여행 / 북향 자동차보험 급증.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템입니다. 전체 EDW에는 브론즈 테이블 60개 전반의 추가 엔터티, 하위 유형, 전용 테이블(Prophet BEL/CSM, 특약 출재, 의료센터 방문, CLM 레드라인 등)이 포함됩니다. V2에서는 LifePolicy 및 GiPolicy 도메인 클래스가 QuoteToBindToPremium 및 FnolToPay 중추를 구동합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| 사업 부문 / 상품 | aya_product | line_of_business · product |
| IA 라이선스 설계사 | aya_agency | agent |
| 계약자 | salesforce | account · contact · address |
| 디지털 견적 / FNOL | aya_digital | session · quote · claim_submission |
| 생명 / 건강보험 증권 | dxc_ingenium · swissre_magnum | policy · coverage · premium · decision |
| 일반보험 증권 / 청구 | guidewire_pc · guidewire_bc | policy · coverage · invoice |
| 일반보험 클레임 | guidewire_cc | claim · claim_transaction |
| 건강보험 클레임 / 클리닉 | fineos · aya_health | health_claim · clinic_visit |
| 보험료 / 클레임 현금 | fps | payment |
| 수수료 | varicent | commission |
| 재보험 | sap_fs_ri | cession |
| 투자 / 평가 | bloomberg_aim · prophet | holding · trade · valuation |
| GL / IFRS 17 | sap_s4 | journal_entry · journal_line |
AyaEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
QuoteToBindToPremium 는 신계약 중추입니다. FnolToPay 는 클레임 중추입니다. LifePolicy.execute_lifecycle() 견적 → Magnum UW → Ingenium 발행 → FPS 수금 → 수수료 → GL 순으로 진행합니다. GiPolicy.execute_lifecycle() 견적 → PolicyCenter 인수 → BillingCenter 청구서 → ClaimCenter의 선택적 당일 FNOL 순으로 진행합니다. AyaPortfolio.publish_foundation() 증권이 돌기 전에 상품, 설계사, 사무소, 계약자를 마스터합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
InsuranceProduct | product_code | aya_product의 생명 / 건강 / 일반보험 요율 |
Agent | agent_id | IA 라이선스 등록 + Salesforce 프로듀서 |
Policyholder | sf_account_id | 매스 / HNW / SME / 고용주 CRM |
LifePolicy | policy_number | publish_quote() → UW → 인수 → 수금 → 수수료 → GL |
GiPolicy | policy_number | publish_quote() → 인수 → 청구 → open_claim() |
HealthClaim | claim_number | 클리닉 방문 → FINEOS → FPS 지급 |
flowchart LR
PORT[AyaPortfolio.publish_foundation]
LIFE[LifePolicy.execute_lifecycle]
GI[GiPolicy.execute_lifecycle]
PORT --> LIFE
PORT --> GI
LIFE --> Q[Aria quote]
Q --> UW[Magnum UW]
UW --> PAS[Ingenium / PolicyCenter]
PAS --> FPS[FPS collect]
GI --> FNOL[ClaimCenter FNOL]
FNOL --> RI[reinsurance cession]
FPS --> GL[SAP S/4 IFRS 17]
상품 팩토리에서 판매, 인수, 수금, 클레임, 재무 마감까지.
샘플 보기: 이는 AYA 생태계를 관통하는 주요 가치 사슬을 보여 줍니다. 생성된 전체 EDW에는 여기에 표시되지 않은 교차 기능 통합, 의료센터 캐시리스 방문, 특약 회계를 포함한 소스 시스템 39개가 모두 포함됩니다.
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph factory["Product & distribution"]
direction TB
PRD[aya_product]
AG[aya_agency]
DIG[aya_digital Aria]
PRD ~~~ AG
AG ~~~ DIG
end
subgraph bind["Underwrite & bind"]
direction TB
MAG[swissre_magnum]
LIFE[dxc_ingenium]
PC[guidewire_pc]
MAG ~~~ LIFE
LIFE ~~~ PC
end
subgraph cash["Collect & commission"]
direction TB
BC[guidewire_bc]
FPS[fps]
VAR[varicent]
BC ~~~ FPS
FPS ~~~ VAR
end
subgraph claims["Claims & health"]
direction TB
CC[guidewire_cc]
FN[fineos]
CLIN[aya_health]
CC ~~~ FN
FN ~~~ CLIN
end
subgraph corp["Investments & close"]
direction TB
AIM[bloomberg_aim]
PR[prophet]
S4[sap_s4]
AIM ~~~ PR
PR ~~~ S4
end
factory --> bind --> cash --> claims --> corp
AYA Tower 쿼리베이 본사와 직속 기능, 대표 소스 시스템 포함.
샘플 조직 구조: 이는 주요 보고 라인입니다. 전체 AYA 조직에는 벤더 통합 39개 전반의 추가 에이전시 지구, 마카오·GBA 팀, 공유 서비스 기능이 포함됩니다.
flowchart TB
CEO[AYA Hong Kong]
CEO --> LIFE[Life & Savings]
CEO --> HLTH[Health & Employee Benefits]
CEO --> GI[General Insurance]
CEO --> DIST[Agency / banca / digital]
CEO --> CLM[Claims]
CEO --> FIN[Finance & actuarial]
CEO --> HR[Human resources]
CEO --> LEG[IT / legal / security]
카탈로그 stage 기반부터 전사까지 테이블을 묶습니다.
표시된 샘플 구성: 이는 성숙 레이어에 분포된 전체 60개 테이블 인벤토리의 대표 단면입니다. 실제 분포는 기반부터 전사 골드 테이블까지의 완전한 데이터 리니지를 반영합니다.
flowchart LR F["foundation
~12 tables"] D["distribution
~10 tables"] P["policy & premium
~9 tables"] C["claims
~6 tables"] CO["finance & corporate
~23 tables"] F --> D --> P --> C F -.-> CO P -.-> CO
논리 관계와 앵커 키. 상품 (product_code) 및 증권 (policy_number)가 중추입니다. 클레임은 FNOL과 청구 번호로 조인됩니다.
샘플 다이어그램: 이 엔터티 관계 다이어그램은 핵심 논리 모델을 보여 줍니다. 생성된 전체 EDW에는 브론즈 테이블 60개 걸쳐 벤더 시스템 39개 추가 상세 테이블과 리니지 분기가 있습니다. 엔터티 인스턴스는 다음을 가집니다 entity_refs 조인 가능성을 시험하기 위해 방출되는 모든 이벤트에.
erDiagram
PRODUCT ||--o{ LIFE_POLICY : tariffs
PRODUCT ||--o{ GI_POLICY : tariffs
AGENT ||--o{ LIFE_POLICY : sells
AGENT ||--o{ GI_POLICY : sells
POLICYHOLDER ||--o{ LIFE_POLICY : owns
POLICYHOLDER ||--o{ GI_POLICY : owns
LIFE_POLICY ||--o{ HEALTH_CLAIM : incurs
GI_POLICY ||--o{ GI_CLAIM : notifies
GI_POLICY ||--o{ INVOICE : bills
LIFE_POLICY ||--o{ PREMIUM : collects
GI_CLAIM ||--o{ CESSION : cedes
벤더 접두사 39개, 브론즈 테이블 60개.
표시된 샘플 시스템: 아래 다이어그램은 대표 벤더 시스템입니다. 생성된 전체 데이터셋에는 이력 백필과 라이브 스트림 전반의 테이블 리니지와 통합 지점을 포함한 시스템 39개가 모두 들어 있습니다. 공유 소스 시스템 매니페스트는 kb/source_systems/ 은 산업 간에 재사용됩니다 — AYA가 추가하는 aya_product, aya_agency, aya_digital, 그리고 aya_health 를 산업 고유 내부 시스템으로 더하고, 분할 PAS(Guidewire + Ingenium)를 사용합니다.
각 테이블은 다음을 따릅니다 {source_system_}__{entity} 명명 규칙(예: aya_product__product, guidewire_cc__claim), 각 제품의 실제 내보내기 스키마에서 벤더 고유 컬럼 형태와 외래 키를 유지합니다. VibeBI는 레코드를 실버와 골드로 승격할 때 마스터 데이터 정합을 추론합니다.
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["aya_product · aya_agency · oracle_scm"]
f2["salesforce · workday · sap_s4 dimensions"]
end
subgraph distribution["Distribution"]
direction TB
d1["aya_digital · salesforce_cpq"]
d2["hubspot · marketo · google_analytics"]
end
subgraph policy["Policy & premium"]
direction TB
p1["swissre_magnum · dxc_ingenium"]
p2["guidewire_pc · guidewire_bc · fps · varicent"]
end
subgraph claims["Claims"]
direction TB
c1["guidewire_cc · fineos · aya_health · sap_fs_ri"]
end
subgraph corporate["Finance & corporate"]
direction TB
co1["prophet · bloomberg_aim · sap_s4 journals"]
co2["anaplan · adp · ukg · concur · coupa"]
co3["servicenow · okta · splunk · ironclad · onetrust"]
end
foundation --> distribution --> policy --> claims
foundation --> corporate
policy --> corporate
V2 OOP 시뮬 → ClickHouse 브론즈, VibeBI 시맨틱 → 같은 인스턴스에서 실버 → 골드.
OOP 경로: kb/industries/aya/ 운영 중추와 엔터티 모델을 정의합니다. AyaEnterpriseSimulation 도메인 라이프사이클을 순서대로 실행합니다. SourceSystem 어댑터가 벤더 고유 행을 다음으로 내보냅니다 aya_v2.
flowchart LR
subgraph kb["kb/industries/aya"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/aya"]
ORCH[AyaEnterpriseSimulation]
DOM["LifePolicy · GiPolicy
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse aya_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-aya — 60초 틱 경유 AyaEnterpriseSimulation.generate().
라이브 주기: 각 틱은 QuoteToBindToPremium과 FnolToPay를 실행합니다. 도메인 객체가 상관된 견적, UW 결정, PAS 인수, FPS 수금, 수수료, FNOL, GL 행을 방출합니다. 오늘 라이브 틱은 홍콩 as_of 견적, FNOL, FPS, 분개가 하루 동안 늘어납니다. 스케일은 틱마다 달라집니다(기본 베이스 5). 필요한 이력 구간은 백필할 수 있습니다 (--days N 라이브 스크립트 또는 CLI에서).
flowchart LR
START([60s tick]) --> SIM[AyaEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> LIFE[LifePolicy lifecycles]
FOUND --> GI[GiPolicy lifecycles]
LIFE --> CORP[Health + investments + finance]
GI --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
QuoteToBindToPremium 및 FnolToPay 상태 머신 — 각 전이는 벤더 행을 방출하는 도메인 메서드입니다.
프로세스 중추: 다음에 정의됨 kb/industries/aya/process_model.yaml. 지연 도착 모드(PAS 발행 지연, FPS 클리어링, 수수료 배치, 야간 FNOL, 재보험 보더로)와 예외 모드(UW 회부/거절, 보험료 실효, 청구 거절, 부분 지급)는 독립 난수 삽입이 아니라 같은 엔터티 라이프사이클에서 분기합니다.
flowchart LR
Q[quoted] --> UW[underwritten]
UW --> BIND[bound]
BIND --> BILL[billed]
BILL --> COL[collected]
COL --> COMM[commissioned]
COMM --> GL[posted_to_gl]
UW -.->|uw_decline| DEC[declined]
BILL -.->|lapse| LAPSE[premium_lapse]
flowchart LR
FNOL[fnol_submitted] --> OPEN[claim_opened]
OPEN --> RSV[reserved]
RSV --> PAY[paid]
PAY --> CLOSE[closed]
OPEN -.->|denied| DENY[claim_denied]
PAY -.->|partial| PART[partial_settlement]
모든 테이블에 동일한 리니지 봉투, 범주가 라이브 동작을 결정합니다.
샘플 범주: 브론즈 테이블 60개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Product · agent · policyholder masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Policies · premiums · claims · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["Digital sessions · FNOL · clinic visits"]
E2[Append each live tick]
end
BRONZE[("aya_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
가상 회사 안내: 「Smire」는 시연 목적으로만 만든 완전히 가상의 회사입니다. Swire Properties Limited, Swire Pacific Limited 또는 실제 부동산 회사와 제휴·후원·표상 관계가 없습니다.
Smire Properties 는 쿼리베이 Smire Tower에 본사를 둔 홍콩 복합용도 랜드로드입니다. 그레이드 A 오피스 캠퍼스(Eastgate Place, Harbour Place), 몰(Harbourplaza, Peakgate Outlets, Eastgate Li), 주거, Harbour House 호텔, 그리고 베이징·상하이·광저우·청두의 태고리 스타일 리테일.
장부는 리싱 오퍼에서 Yardi 리스와 일일 렌트롤, 기본 임대료와 몰 POS 매출 연동 임대료, HK FPS / CNY 수금, SAP S/4 NOI 분개, 준실시간 BMS, Nedap 배지 이벤트, 주차장, 11:00–22:00 HKT 몰 유동량, 그리고 Argus GAV/NAV, CoStar 풍 컴프, 개발 CAPEX 인출, 호텔 점유/ADR/RevPAR까지 이어집니다 — 춘절 몰 거래 급증 Harbourplaza와 Eastgate Li 유동량, 매출 연동 임대료, FPS 수금을 끌어올립니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템을 보여 줍니다. 완전한 EDW에는 60개 브론즈 테이블 전반의 추가 엔터티, 하위 유형, 전용 테이블(ESG 미터, CAPEX 인출, 호텔 점유, CLM 레드라인 등)이 포함됩니다. V2에서는 Lease 및 Tenant 도메인 클래스가 LeaseToCollect와 MallTradingDay 스파인을 구동합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| 프로퍼티 / 빌딩 / 유닛 | smire_portfolio | property · building · unit |
| 임차인 | yardi_voyager · salesforce | tenant · account · contact |
| 리싱 오퍼 | smire_leasing | offer |
| 리스 / 렌트롤 / 인보이스 | yardi_voyager | lease · rent_roll · invoice |
| 임대료 수금 | fps | payment |
| 몰 POS / 유동량 | smire_mall | tenant_sale · footfall |
| BMS / 출입 / 주차 | honeywell_bms · nedap_aeos · smire_park | telemetry · badge_event · session |
| 밸류에이션 / 컴프 | argus_enterprise · costar_analytics | valuation · comp |
| 개발 | smire_dev | project · capex_draw |
| 호텔 점유 | smire_hotel | occupancy |
| 분양 매각 | smire_residential | sale |
| 로열티 | smire_loyalty | member · earn |
| NOI / GL | sap_s4 | journal_entry · journal_line |
SmireEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
LeaseToCollect 는 리싱 스파인입니다. MallTradingDay 는 리테일 운영 스파인입니다. Lease.execute_lifecycle() 오퍼 → Yardi 리스와 렌트롤 → 인보이스(기본+매출 연동 임대료) → FPS 수금 → NOI 분개를 따라갑니다. Tenant.publish() 리스가 돌기 전에 Yardi와 Salesforce를 마스터합니다。 SmirePortfolio.publish_foundation() 먼저 프로퍼티, 빌딩, 임대 유닛, 사이트를 마스터합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
Property | property_code | smire_portfolio의 캠퍼스 / 몰 / 호텔 마스터 |
Unit | unit_id | 임대 가능 NFA; 점유 원장 |
Tenant | tenant_code | publish() → Yardi + Salesforce CRM |
Lease | lease_id | execute_lifecycle() → offer → lease → invoice → FPS → GL |
CorporateOffice | location_id | oracle_scm의 HQ 및 자산관리 사이트 |
flowchart LR
PORT[SmirePortfolio.publish_foundation]
TNT[Tenant.publish]
LS[Lease.execute_lifecycle]
PORT --> TNT
TNT --> LS
LS --> OFF[leasing offer]
OFF --> YAR[Yardi lease / invoice]
YAR --> FPS[FPS collect]
FPS --> GL[SAP S/4 NOI]
PORT --> MALL[Mall POS + footfall]
MALL --> YAR
포트폴리오 마스터에서 리싱, 몰 거래, 자산 운영, 재무 마감까지.
샘플 보기: 이는 Smire 생태계 전반의 주요 가치사슬을 보여 줍니다. 완전히 생성된 EDW에는 교차 기능 통합, 호텔 RevPAR, 여기에 보이지 않는 개발 CAPEX를 포함한 소스 시스템 39개가 모두 들어 있습니다.
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph portfolio["Portfolio"]
direction TB
PORT[smire_portfolio]
SCM[oracle_scm]
PORT ~~~ SCM
end
subgraph lease["Lease & collect"]
direction TB
OFF[smire_leasing]
YAR[yardi_voyager]
FPS[fps]
OFF ~~~ YAR
YAR ~~~ FPS
end
subgraph ops["Operate asset"]
direction TB
MALL[smire_mall]
BMS[honeywell_bms]
AEOS[nedap_aeos]
MALL ~~~ BMS
BMS ~~~ AEOS
end
subgraph value["Value & hotels"]
direction TB
ARG[argus_enterprise]
HOT[smire_hotel]
DEV[smire_dev]
ARG ~~~ HOT
HOT ~~~ DEV
end
subgraph close["NOI close"]
direction TB
S4[sap_s4]
CST[costar_analytics]
S4 ~~~ CST
end
portfolio --> lease --> ops --> value --> close
Smire Tower Quarry Bay HQ와 대표 소스 시스템을 갖춘 직속 기능.
샘플 조직 구조: 이는 주요 보고 라인을 보여 줍니다. 완전한 Smire 조직에는 추가 자산관리 사무소, 본토 몰 팀, 벤더 통합 39개 전반의 공유 서비스 기능이 포함됩니다.
flowchart TB
CEO[Smire Properties]
CEO --> OFF[Office]
CEO --> RET[Retail]
CEO --> RES[Residential]
CEO --> HOT[Hotels]
CEO --> DEV[Development]
CEO --> FIN[Finance]
CEO --> HR[Human resources]
CEO --> LEG[IT / legal / security]
카탈로그 stage 기반부터 전사까지 테이블을 묶습니다.
표시된 샘플 구성: 이는 성숙 레이어에 분포된 전체 60개 테이블 인벤토리의 대표 단면입니다. 실제 분포는 기반부터 전사 골드 테이블까지의 완전한 데이터 리니지를 반영합니다.
flowchart LR F["portfolio
~10 tables"] L["leasing
~8 tables"] O["operations
~10 tables"] V["valuation
~8 tables"] CO["corporate
~24 tables"] F --> L --> O --> V F -.-> CO L -.-> CO
논리 관계와 앵커 키. 숙박 시설(property_code) 및 유닛 (unit_id)가 스파인입니다. 리스는 다음으로 조인합니다: lease_id 및 인보이스를 통한 FPS.
샘플 다이어그램: 이 엔터티 관계 다이어그램은 핵심 논리 모델을 보여 줍니다. 생성된 전체 EDW에는 브론즈 테이블 60개 걸쳐 벤더 시스템 39개 추가 상세 테이블과 리니지 분기가 있습니다. 엔터티 인스턴스는 다음을 가집니다 entity_refs 조인 가능성을 시험하기 위해 방출되는 모든 이벤트에.
erDiagram
PROPERTY ||--o{ BUILDING : contains
BUILDING ||--o{ UNIT : lets
UNIT ||--o{ LEASE : occupies
TENANT ||--o{ LEASE : signs
LEASE ||--o{ INVOICE : bills
INVOICE ||--o{ FPS_PAYMENT : collects
TENANT ||--o{ MALL_SALE : trades
PROPERTY ||--o{ VALUATION : values
벤더 접두사 39개, 브론즈 테이블 60개.
표시된 샘플 시스템: 아래 다이어그램은 대표 벤더 시스템입니다. 생성된 전체 데이터셋에는 이력 백필과 라이브 스트림 전반의 테이블 리니지와 통합 지점을 포함한 시스템 39개가 모두 들어 있습니다. 공유 소스 시스템 매니페스트는 kb/source_systems/ 는 업계 횡단으로 재사용됩니다 — Smire가 추가하는 smire_portfolio, smire_leasing, smire_mall, 그리고 smire_hotel 을 업종 고유 내부 시스템으로 더하고, Yardi Voyager와 Argus를 사용합니다.
각 테이블은 다음을 따릅니다 {source_system_}__{entity} 명명 규칙(예: smire_portfolio__unit, yardi_voyager__lease), 각 제품의 실제 내보내기 스키마에서 벤더 고유 컬럼 형태와 외래 키를 유지합니다. VibeBI는 레코드를 실버와 골드로 승격할 때 마스터 데이터 정합을 추론합니다.
flowchart TB
subgraph foundation["Portfolio"]
direction TB
f1["smire_portfolio property · building · unit"]
f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
end
subgraph leasing["Leasing"]
direction TB
l1["smire_leasing · yardi_voyager · fps"]
end
subgraph operations["Operations"]
direction TB
o1["smire_mall · honeywell_bms · nedap_aeos · smire_park"]
o2["smire_hotel · smire_esg · smire_loyalty"]
end
subgraph valuation["Valuation"]
direction TB
v1["argus_enterprise · costar_analytics · smire_dev · smire_residential"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · anaplan · adp · ukg · concur"]
co2["hubspot · marketo · zendesk · servicenow · okta"]
co3["splunk · ironclad · onetrust · greenhouse"]
end
foundation --> leasing --> operations --> valuation
foundation --> corporate
leasing --> corporate
V2 OOP 시뮬 → ClickHouse 브론즈, VibeBI 시맨틱 → 같은 인스턴스에서 실버 → 골드.
OOP 경로: kb/industries/smire/ 운영 중추와 엔터티 모델을 정의합니다. SmireEnterpriseSimulation 도메인 라이프사이클을 순서대로 실행합니다. SourceSystem 어댑터가 벤더 고유 행을 다음으로 내보냅니다 smire_v2.
flowchart LR
subgraph kb["kb/industries/smire"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/smire"]
ORCH[SmireEnterpriseSimulation]
DOM["Lease.execute_lifecycle()
Tenant · Property · Unit"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse smire_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-smire — 60초 틱 경유 SmireEnterpriseSimulation.generate().
라이브 주기: 각 틱은 LeaseToCollect와 MallTradingDay를 실행합니다 — 도메인 객체가 상관된 오퍼, 리스, 인보이스, FPS 수금, 몰 POS, 유동량, 배지 이벤트, GL 행을 방출합니다. 오늘 라이브 틱은 홍콩 as_of 까지 이벤트만 방출하므로 렌트롤, 몰 거래, BMS, 분개가 하루 동안 늘어납니다. 스케일은 틱마다 다릅니다(기본 베이스 5). 필요한 이력 구간은 백필할 수 있습니다(--days N 라이브 스크립트 또는 CLI에서).
flowchart LR
START([60s tick]) --> SIM[SmireEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> TNT[Tenant.publish]
TNT --> LS[Lease lifecycles]
FOUND --> OPS[Mall · BMS · hotel]
LS --> CORP[NOI + valuation + finance]
OPS --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
LeaseToCollect와 OperateAsset 상태 머신 — 각 전이는 벤더 행을 방출하는 도메인 메서드입니다.
프로세스 중추: 다음에 정의됨 kb/industries/smire/process_model.yaml. 지연 도착 모드(FPS 클리어링 지연, GL 배치 전기 지연, 야간 BMS, 워크오더 지연)와 예외 모드(공실, 연체, 출입 거부, 설비 알람)는 독립 무작위 삽입이 아니라 같은 엔터티 라이프사이클에서 분기합니다.
flowchart LR
OFF[offered] --> LS[leased]
LS --> OCC[occupied]
OCC --> INV[invoiced]
INV --> COL[collected]
COL --> GL[posted_to_gl]
LS -.->|vacancy| VAC[vacancy]
INV -.->|arrears| ARR[arrears]
flowchart LR
MTR[metered] --> ACC[accessed]
ACC --> WO[work_ordered]
WO --> VAL[valued]
ACC -.->|denied| DEN[access_denied]
MTR -.->|alarm| ALM[plant_alarm]
모든 테이블에 동일한 리니지 봉투, 범주가 라이브 동작을 결정합니다.
샘플 범주: 브론즈 테이블 60개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Property · unit · tenant masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Leases · invoices · FPS · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["Footfall · badge · BMS · park"]
E2[Append each live tick]
end
BRONZE[("smire_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
가상 회사 안내: "Hilson"은 시연 목적으로만 만든 가상의 회사입니다. Hilton Inc., Hyatt Hotels Corporation 또는 실제 어떤 호스피탈리티 기업과도 제휴되어 있지 않으며, 보증하거나 대표하지 않습니다.
Hilson Hospitality Group 은 18개 브랜드에 걸쳐 약 680개 숙박 시설을 운영하는 글로벌 호텔 사업자입니다. 럭셔리 플래그(Waldorf급, Conrad급)부터 풀서비스(Hilson, DoubleTree급), 셀렉트 서비스, 장기 숙박 티어까지 포함합니다. 각 숙박 시설은 온프레미스 Opera PMS와 중앙 Amadeus CRS를 운영하며, 단기 레저, 기업 협상, 단체/컨벤션 투숙객이 섞여 있습니다.
사업은 로열티(수백만 회원의 Hilson Honors), 단체·컨벤션 영업(Salesforce 파이프라인, CPQ 객실 블록), 식음료 매장(MICROS Simphony POS), 오너/프랜차이즈 리포팅(Oracle Fusion 명세서), 전사 기능을 포괄합니다. 일반적인 평일에는 PMS 예약 약 1,900건, folio 헤더 약 1,750건이 발생하며, 여름 여행 급증 (6–8월)으로 전 숙박 시설의 점유율, ADR, F&B 매출, 로열티 활동을 끌어올립니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템을 보여 줍니다. 완전한 EDW에는 추가 엔터티, 하위 유형, 특수 테이블(예: OTA 채널 이벤트, 요금제 제한, 프랜차이즈 법률 계약, 딜데스크 레드라인)이 브론즈 테이블 62개 전반에 포함됩니다. V2에서는 StayReservation 관련 도메인 클래스가 숙박 라이프사이클이 진행됨에 따라 소스 시스템 어댑터를 통해 PMS, CRS, folio, 로열티 행을 방출합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| 숙박 시설 마스터 | oracle_opera | property · room_type · occupancy_snapshot |
| 브랜드 / CRS | hilson_brand · amadeus_hosp | brand · property_profile |
| 로열티 회원 | hilson_loyalty | member · point_transaction · redemption |
| 예약 (PMS/CRS) | oracle_opera · amadeus_hosp | reservation · reservation_change_event |
| Folio / 청구 | oracle_opera | folio_header · folio_charge |
| F&B 매장 | micros_simphony | check_header · check_line |
| 결제 | adyen | payment · refund |
| 단체 영업 | salesforce · salesforce_cpq | account · opportunity · quote |
| 하우스키핑 | oracle_opera | room_status_event · housekeeping_task |
| 오너 / GL | oracle_fusion · sap_s4 | owner_statement · journal_line |
| 투숙객 경험 | medallia · zendesk | stay_survey · guest_case |
HilsonEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
ReservationToLoyaltyAndOwnerReporting 이 기본 프로세스 중추입니다. StayReservation.execute_lifecycle() 예약 → PMS 동기화 → folio 요금 → 결제 → 로열티 포인트 → 점유 스냅샷 → 오너 명세서 → GL 순으로 진행합니다. HilsonPortfolio.publish_foundation() 예약 실행 전에 브랜드, 숙박 시설, Honors 회원을 마스터합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
Brand | brand_code | hilson_brand에서 마스터된 브랜드 사다리 |
Property | hotel_code | Opera/CRS의 숙박 시설 + 객실 재고 |
GuestMember | honors_member_id | 예약과 숙박에 걸친 로열티 프로필 |
StayReservation | crs_confirmation_no | book() → sync_pms() → open_folio() → settle() → award_points() |
PropertyOccupancy | hotel_code, 날짜 | 일별 ADR / RevPAR 스냅샷 |
PropertyFinance | owner_statement_id | 오너 명세서 + 균형 GL 전기 |
flowchart LR
PORT[HilsonPortfolio.publish_foundation]
STAY[StayReservation.execute_lifecycle]
PORT --> STAY
STAY --> BOOK[CRS booking]
BOOK --> PMS[PMS sync]
PMS --> FOL[folio charges]
FOL --> PAY[Adyen settlement]
PAY --> LOY[Honors points]
LOY --> OWN[owner statement + GL]
브랜드·숙박 시설 마스터부터 유통, 숙박, 정산, 오너 리포팅까지.
샘플 보기: 이는 Hilson 생태계를 관통하는 주요 가치 사슬을 보여 줍니다. 생성된 전체 EDW에는 여기에 표시되지 않은 교차 기능 통합, 이차 매출 흐름, 로열티 라이프사이클 흐름을 포함한 소스 시스템 31개가 모두 포함됩니다.
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph master["Brand & property master"]
direction TB
BR[hilson_brand]
PROP[oracle_opera property]
RMS[ideas_rms rate plans]
BR ~~~ PROP
PROP ~~~ RMS
end
subgraph dist["Distribution & booking"]
direction TB
AMA[amadeus_hosp CRS]
SM[siteminder OTA]
AMA ~~~ SM
end
subgraph stay["Stay & revenue"]
direction TB
RES[oracle_opera reservation]
FOL[folio header / charges]
SIM[micros_simphony F&B]
PAY[adyen payments]
end
subgraph loy["Loyalty & VoC"]
direction TB
HON[hilson_loyalty member]
MED[medallia · qualtrics]
HON ~~~ MED
end
subgraph corp["Owner & corporate"]
direction TB
OWN[oracle_fusion owner stmt]
SAP[sap_s4 GL]
GRP[salesforce group sales]
OWN ~~~ SAP
SAP ~~~ GRP
end
master --> dist --> stay --> loy
stay --> corp
엔터프라이즈 HQ와 직속 기능, 대표 소스 시스템.
샘플 조직 구조: 이는 주요 보고 체계를 보여 줍니다. 전체 Hilson 조직에는 벤더 통합 31개 전반의 추가 지역 관리, 브랜드별 팀, 공유 서비스 기능이 포함됩니다.
flowchart TB
CEO[Hilson Hospitality Group]
CEO --> BRAND[Brand & marketing]
CEO --> DIST[Distribution & revenue mgmt]
CEO --> PROP[Property operations]
CEO --> SALES[Group sales]
CEO --> LOY[Loyalty program]
CEO --> FIN[Finance & owner reporting]
CEO --> HR[Human resources]
CEO --> GX[Guest experience]
CEO --> LEG[IT / security / legal]
카탈로그 stage 기반부터 전사까지 테이블을 묶습니다.
표시된 샘플 구성: 이는 성숙 레이어에 분포된 전체 62개 테이블 인벤토리의 대표 단면입니다. 실제 분포는 기반부터 전사 골드 테이블까지의 완전한 데이터 리니지를 반영합니다.
flowchart LR F["foundation
~15 tables"] C["commercial
~7 tables"] GR["guest_revenue
~17 tables"] PO["property_ops
~7 tables"] CO["corporate
~16 tables"] F --> C --> GR --> PO F -.-> CO GR -.-> CO
논리 관계와 앵커 키. 숙박 시설(hotel_code)이 중추이며, 투숙객 신원은 Honors와 숙박 테이블을 통해 연결됩니다.
샘플 다이어그램: 이 엔터티 관계 다이어그램은 핵심 논리 모델을 보여 줍니다. 생성된 전체 EDW에는 브론즈 테이블 62개 걸쳐 벤더 시스템 31개 수천 개의 추가 상세 테이블과 리니지 분기가 있습니다.
erDiagram
PROPERTY ||--o{ RESERVATION : hosts
PROPERTY ||--o{ RATE_PLAN : offers
BRAND ||--o{ PROPERTY : flags
MEMBER ||--o{ RESERVATION : books
MEMBER ||--o{ POINT_TXN : earns
MEMBER ||--o{ REDEMPTION : redeems
RESERVATION ||--|| FOLIO : bills
FOLIO ||--o{ FOLIO_CHARGE : lines
RESERVATION ||--o{ FNB_CHECK : posts
CORP_ACCOUNT ||--o{ OPPORTUNITY : pursues
SUPPLIER ||--o{ PO : supplies
PROPERTY ||--o{ WORK_ORDER : maintains
벤더 접두사 31개, 브론즈 테이블 62개.
표시된 샘플 시스템: 아래 다이어그램은 대표 벤더 시스템을 보여 줍니다. 생성된 전체 데이터셋에는 31개 시스템 전부와 이력 백필·라이브 스트림에 걸친 전체 테이블 리니지 및 통합 지점이 포함됩니다.
각 테이블은 다음을 따릅니다 {source_system_}__{entity} 명명 규칙(예: oracle_opera__reservation, hilson_loyalty__member), 각 제품의 실제 내보내기 스키마에서 벤더 고유 컬럼 형태와 외래 키를 유지합니다. VibeBI는 레코드를 실버와 골드로 승격할 때 마스터 데이터 정합을 추론합니다.
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["hilson_brand · oracle_opera property · room_type"]
f2["amadeus_hosp · ideas_rms · hilson_loyalty member"]
f3["salesforce account · workday · sap_s4 · coupa supplier"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce pipeline · CPQ · hubspot · marketo"]
end
subgraph guest_rev["Guest revenue"]
direction TB
g1["oracle_opera reservation · folio · events"]
g2["amadeus_hosp · siteminder · micros_simphony"]
g3["adyen · loyalty points · oracle_fusion owner"]
end
subgraph prop_ops["Property ops"]
direction TB
p1["housekeeping · occupancy · ibm_maximo · coupa PO"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · adp · ukg · anaplan"]
co2["medallia · qualtrics · zendesk · concur"]
co3["servicenow · okta · splunk · ironclad · onetrust"]
end
foundation --> commercial --> guest_rev --> prop_ops
foundation --> corporate
guest_rev --> corporate
V2 OOP 시뮬 → ClickHouse 브론즈, VibeBI 시맨틱 → 같은 인스턴스에서 실버 → 골드.
OOP 경로: kb/industries/hilson/ 운영 중추와 엔터티 모델을 정의합니다. HilsonEnterpriseSimulation 도메인 라이프사이클을 순서대로 실행합니다. SourceSystem 어댑터가 벤더 고유 행을 다음으로 내보냅니다 hilson_v2.
flowchart LR
subgraph kb["kb/industries/hilson"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/hilson"]
ORCH[HilsonEnterpriseSimulation]
DOM["StayReservation.execute_lifecycle()
Property · GuestMember …"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse hilson_v2
62 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-hilson — 60초 틱 경유 HilsonEnterpriseSimulation.generate().
라이브 주기: 각 틱이 예약-로열티 상태 머신을 실행합니다. 도메인 객체가 상관된 CRS, PMS, folio, F&B, 결제, 로열티, GL 행을 방출합니다. 규모는 틱마다 달라집니다(기본 베이스 5). 필요한 이력 구간을 백필하십시오 (--days N); Hilson은 예약 앵커 테이블에서 공백 탐지를 포함합니다.
flowchart LR
START([60s tick]) --> SIM[HilsonEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> STAY[StayReservation lifecycles]
STAY --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
ReservationToLoyaltyAndOwnerReporting 상태 머신 — 각 전이가 벤더 행을 방출합니다.
프로세스 중추: 다음에 정의됨 kb/industries/hilson/process_model.yaml. 예외 모드(노쇼, 차지백, 객실 업그레이드)는 독립된 무작위 삽입이 아니라 동일 엔터티 라이프사이클에서 분기합니다.
flowchart LR
BOOK[booked] --> SYNC[synced_to_pms]
SYNC --> CHKIN[checked_in]
CHKIN --> HOUSE[in_house]
HOUSE --> CHKOUT[checked_out]
CHKOUT --> SET[settled]
SET --> PTS[points_posted]
PTS --> OCC[occupancy_snapshotted]
OCC --> OWN[owner_reported]
OWN --> GL[posted_to_gl]
SYNC -.->|no_show| NS[no_show]
SET -.->|chargeback| CB[chargeback]
모든 테이블에 동일한 리니지 봉투, 범주가 라이브 새로고침과 마이크로배치 추가를 제어합니다.
샘플 범주: 브론즈 테이블 62개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Property · brand · member masters"]
S2[Daily full refresh]
end
subgraph txn["transaction"]
direction TB
T1["Reservations · folios · payments"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["HK · OTA · surveys · access"]
E2[Append each live tick]
end
BRONZE[("hilson_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
가상 회사 안내: 「Cathea」는 시연 목적으로만 만든 완전히 가상의 회사입니다. Cathay Pacific Airways Limited, Cathay Pacific Group 또는 실제 항공사와 제휴·후원·표상 관계가 없습니다.
Cathea Pacific 는 첵랍콕 Cathea City에 본사를 둔 홍콩 허브 항공사입니다. 프리미엄 여객(HP), 항공화물과 Cathea Cargo Terminal, LCC Peak Express(PX), Air Harbour Express 화물기(AH), 그리고 Pacific Miles 라이프스타일. 네트워크는 HKG 시각: A350/777 장거리 로테이션, 야간 747-8F 웨이브, A321neo 지역선.
하루는 NDC 오더 → Altéa급 PNR과 168 접두 e티켓 → Adyen 카드 캡처 → DCS 체크인과 수하물 스캔 → Navblue OFP, AIMS 승무, SITA MVT(야간 화물 01:00–05:00 HKT 포함) → Pacific Miles 적립과 Accelya 레이팅 → SAP S/4 분개. 화물은 Cargospot 부킹 → AWB → 터미널 인수 → ULD 스캔 → 무브먼트 → OTM 트럭킹 → FPS 수금 — 춘절 여행 / 태풍 IRROPS 증가 Peak Express 탑재율, 수하물 스캔, 화물 대기열을 급증시킵니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템을 보여 줍니다. 완전한 EDW에는 60개 브론즈 테이블 전반의 추가 엔터티, 하위 유형, 전용 테이블(연료 업리프트, TRAX 워크오더, ULD 스캔, 로열티 적립 등)이 포함됩니다. V2에서는 Pnr 및 AirWaybill 도메인 클래스가 OfferToFlyToRevenue와 BookToDeliverCargo 스파인을 구동합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| 항공기 / 노선 / 편 | cathea_network | aircraft · route · flight |
| 스테이션 | oracle_scm | station |
| NDC 오더 | cathea_ndc | order |
| PNR / e티켓 | amadeus_altea | pnr · ticket |
| 체크인 / 수하물 | amadeus_dcs | checkin · bag_scan |
| 여객 카드 | adyen | payment |
| 화물 부킹 / AWB | champ_cargospot | booking · awb |
| 화물 터미널 | cathea_cht | acceptance · uld_scan |
| 편 무브먼트 | sita_typeb | movement |
| OFP / 승무 | navblue · aims_crew | ofp · duty |
| Pacific Miles | cathea_loyalty | member · accrual |
| 화물 수금 | fps | payment |
| 수익 / GL | accelya_ra · sap_s4 | document · journal_entry · journal_line |
CatheaEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
OfferToFlyToRevenue 는 여객 스파인입니다. BookToDeliverCargo 는 화물 스파인입니다. Pnr.execute_lifecycle() NDC 오더 → Altéa PNR과 e티켓 → Adyen 캡처 → DCS 체크인 → 탑승 쿠폰 → Pacific Miles → Accelya → GL을 따라갑니다. AirWaybill.execute_lifecycle() Cargospot 부킹 → AWB → CHT 인수 → ULD → SITA 무브먼트 → OTM 트럭킹 → FPS 수금을 따라갑니다. CatheaPortfolio.publish_foundation() PNR과 AWB가 돌기 전에 항공기, 노선, 스테이션, HKG 시각 편을 마스터합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
Aircraft | registration | cathea_network의 항공기 마스터 |
Flight | flight_id | HKG 시각 로테이션; SITA MVT + Navblue OFP |
Pnr | pnr_locator | execute_lifecycle() → NDC → Altéa → DCS → Adyen → Miles → GL |
AirWaybill | awb_number | execute_lifecycle() → Cargospot → CHT → ULD → FPS |
LoyaltyMember | member_id | Pacific Miles는 탑승 쿠폰에서 적립됩니다 |
flowchart LR
PORT[CatheaPortfolio.publish_foundation]
PNR[Pnr.execute_lifecycle]
AWB[AirWaybill.execute_lifecycle]
PORT --> PNR
PORT --> AWB
PNR --> NDC[NDC order]
NDC --> PSS[Altéa PNR / ticket]
PSS --> DCS[DCS check-in]
DCS --> GL[SAP S/4 journal]
AWB --> CS[Cargospot AWB]
CS --> CHT[CHT + ULD]
CHT --> FPS[FPS collect]
네트워크 마스터에서 여객, 화물, 운영, 재무 마감까지.
샘플 보기: 이는 Cathea 생태계 전반의 주요 가치사슬을 보여 줍니다. 완전히 생성된 EDW에는 교차 기능 통합, 야간 화물 웨이브, 여기에 보이지 않는 TRAX MRO를 포함한 소스 시스템 40개가 모두 들어 있습니다.
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph network["Network"]
direction TB
NET[cathea_network]
SCM[oracle_scm station]
NET ~~~ SCM
end
subgraph fly["Offer to fly"]
direction TB
NDC[cathea_ndc]
PSS[amadeus_altea]
DCS[amadeus_dcs]
ADY[adyen]
NDC ~~~ PSS
PSS ~~~ DCS
end
subgraph cargo["Cargo"]
direction TB
CS[champ_cargospot]
CHT[cathea_cht]
OTM[oracle_otm]
FPS[fps]
CS ~~~ CHT
CHT ~~~ OTM
end
subgraph ops["Ops"]
direction TB
NAV[navblue]
AIMS[aims_crew]
SITA[sita_typeb]
NAV ~~~ AIMS
AIMS ~~~ SITA
end
subgraph close["Revenue & close"]
direction TB
PM[cathea_loyalty]
RA[accelya_ra]
S4[sap_s4]
PM ~~~ RA
RA ~~~ S4
end
network --> fly --> cargo --> ops --> close
Cathea City Chek Lap Kok HQ와 대표 소스 시스템을 갖춘 직속 기능.
샘플 조직 구조: 이는 주요 보고 라인을 보여 줍니다. 완전한 Cathea 조직에는 추가 아웃스테이션, GBA 화물 데스크, 벤더 통합 40개 전반의 공유 서비스 기능이 포함됩니다.
flowchart TB
CEO[Cathea Pacific]
CEO --> PREM[Premium Travel]
CEO --> CARGO[Cargo & Logistics]
CEO --> LCC[Peak Express LCC]
CEO --> LIFE[Pacific Miles]
CEO --> OPS[Flight ops]
CEO --> FIN[Finance]
CEO --> HR[Human resources]
CEO --> LEG[IT / legal / security]
카탈로그 stage 기반부터 전사까지 테이블을 묶습니다.
표시된 샘플 구성: 이는 성숙 레이어에 분포된 전체 60개 테이블 인벤토리의 대표 단면입니다. 실제 분포는 기반부터 전사 골드 테이블까지의 완전한 데이터 리니지를 반영합니다.
flowchart LR F["network
~8 tables"] P["passenger
~10 tables"] C["cargo
~8 tables"] O["operations
~6 tables"] CO["corporate
~28 tables"] F --> P --> C --> O F -.-> CO C -.-> CO
논리 관계와 앵커 키. 편(flight_id) 및 PNR (pnr_locator)가 여객 스파인입니다. AWB(awb_number)가 부킹과 FPS로 화물에 조인합니다.
샘플 다이어그램: 이 엔터티 관계 다이어그램은 핵심 논리 모델을 보여 줍니다. 생성된 전체 EDW에는 브론즈 테이블 60개 걸쳐 벤더 시스템 40 추가 상세 테이블과 리니지 분기가 있습니다. 엔터티 인스턴스는 다음을 가집니다 entity_refs 조인 가능성을 시험하기 위해 방출되는 모든 이벤트에.
erDiagram
AIRCRAFT ||--o{ FLIGHT : operates
ROUTE ||--o{ FLIGHT : schedules
FLIGHT ||--o{ PNR : carries
PNR ||--o{ TICKET : issues
TICKET ||--o{ CHECKIN : boards
FLIGHT ||--o{ AWB : uplifts
AWB ||--o{ FPS_PAYMENT : collects
PNR ||--o{ LOYALTY_ACCRUAL : earns
벤더 접두사 40개, 브론즈 테이블 60개.
표시된 샘플 시스템: 아래 다이어그램은 대표 벤더 시스템을 보여 줍니다. 완전히 생성된 데이터셋은 이력 백필과 라이브 스트림 전반의 테이블 리니지와 통합 지점을 가진 40개 시스템을 모두 포함합니다. 공유 소스 시스템 매니페스트는 kb/source_systems/ 는 업계 횡단으로 재사용됩니다 — Cathea가 추가하는 cathea_network, cathea_ndc, cathea_cht, 그리고 cathea_loyalty 을 업종 고유 내부 시스템으로 더하고, Altéa PSS와 Cargospot를 사용합니다.
각 테이블은 다음을 따릅니다 {source_system_}__{entity} 명명 규칙(예: cathea_network__flight, amadeus_altea__pnr), 각 제품의 실제 내보내기 스키마에서 벤더 고유 컬럼 형태와 외래 키를 유지합니다. VibeBI는 레코드를 실버와 골드로 승격할 때 마스터 데이터 정합을 추론합니다.
flowchart TB
subgraph foundation["Network"]
direction TB
f1["cathea_network aircraft · route · flight"]
f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
end
subgraph passenger["Passenger"]
direction TB
p1["cathea_ndc · amadeus_altea · amadeus_dcs"]
p2["adyen · cathea_loyalty"]
end
subgraph cargo["Cargo"]
direction TB
c1["champ_cargospot · cathea_cht · oracle_otm · fps"]
end
subgraph operations["Operations"]
direction TB
o1["navblue · aims_crew · sita_typeb · trax_mro · cathea_fuel"]
end
subgraph corporate["Corporate"]
direction TB
co1["accelya_ra · sap_s4 journals · anaplan · adp · ukg"]
co2["hubspot · marketo · zendesk · servicenow · okta"]
co3["splunk · ironclad · onetrust · greenhouse"]
end
foundation --> passenger --> cargo --> operations
foundation --> corporate
cargo --> corporate
V2 OOP 시뮬 → ClickHouse 브론즈, VibeBI 시맨틱 → 같은 인스턴스에서 실버 → 골드.
OOP 경로: kb/industries/cathea/ 운영 중추와 엔터티 모델을 정의합니다. CatheaEnterpriseSimulation 도메인 라이프사이클을 순서대로 실행합니다. SourceSystem 어댑터가 벤더 고유 행을 다음으로 내보냅니다 cathea_v2.
flowchart LR
subgraph kb["kb/industries/cathea"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/cathea"]
ORCH[CatheaEnterpriseSimulation]
DOM["Pnr · AirWaybill
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse cathea_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-cathea — 60초 틱 경유 CatheaEnterpriseSimulation.generate().
라이브 주기: 각 틱은 OfferToFlyToRevenue와 BookToDeliverCargo를 실행합니다 — 도메인 객체가 상관된 NDC 오더, PNR, 티켓, DCS 스캔, 화물 AWB, SITA 무브먼트, FPS 수금, GL 행을 방출합니다. 오늘 라이브 틱은 홍콩 as_of 까지 이벤트만 방출하므로 체크인, 수하물 스캔, 야간 화물, 분개가 하루 동안 늘어납니다. 스케일은 틱마다 다릅니다(기본 베이스 5). 필요한 이력 구간은 백필할 수 있습니다(--days N 라이브 스크립트 또는 CLI에서).
flowchart LR
START([60s tick]) --> SIM[CatheaEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> PNR[Pnr lifecycles]
FOUND --> AWB[AirWaybill lifecycles]
PNR --> CORP[Loyalty + RA + finance]
AWB --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
OfferToFlyToRevenue와 BookToDeliverCargo 상태 머신 — 각 전이는 벤더 행을 방출하는 도메인 메서드입니다.
프로세스 중추: 다음에 정의됨 kb/industries/cathea/process_model.yaml. 지연 도착 모드(DCS 스캔 지연, MVT 지연, RA 배치 지연, GL 배치 전기 지연)와 예외 모드(노쇼, IRROPS 지연, 카드 거절, 숏 쉽먼트, 용량 대기열)는 독립 무작위 삽입이 아니라 같은 엔터티 라이프사이클에서 분기합니다.
flowchart LR
OFF[offered] --> PNR[pnr_created]
PNR --> TKT[ticketed]
TKT --> CKIN[checked_in]
CKIN --> BRD[boarded]
BRD --> FLN[flown]
FLN --> ACC[accrued]
ACC --> RA[rated]
RA --> GL[posted_to_gl]
TKT -.->|card_refuse| REF[card_refused]
CKIN -.->|no_show| NS[no_show]
flowchart LR
BK[booked] --> AWB[awb_issued]
AWB --> ACC[accepted]
ACC --> ULD[uld_built]
ULD --> DEP[departed]
DEP --> TRK[trucked]
TRK --> DLV[delivered]
DLV --> COL[collected]
COL --> GL[posted_to_gl]
BK -.->|waitlist| WL[capacity_waitlist]
ACC -.->|short| SH[short_shipment]
모든 테이블에 동일한 리니지 봉투, 범주가 라이브 동작을 결정합니다.
샘플 범주: 브론즈 테이블 60개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Aircraft · route · station · loyalty masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["PNRs · tickets · AWBs · FPS · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["DCS scans · SITA MVT · bag events"]
E2[Append each live tick]
end
BRONZE[("cathea_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
가상 회사 안내: "P&C"는 시연 목적으로만 만든 가상의 회사입니다. The Procter & Gamble Company 또는 실제 어떤 CPG 제조사와도 제휴되어 있지 않으며, 보증하거나 대표하지 않습니다.
P&C 은 글로벌 소비재 제조·마케팅 기업입니다. 약 180개국에서 대형 유통, 클럽, 식료품, 이커머스 채널로 일상 제품을 판매하는 B2B2C 모델입니다. 5개 Sector Business Unit(SBU)이 Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care, Grooming을 포괄하며, 약 12개 플래그십 브랜드(TidalWave, ComfortWrap, BrightSmile, EdgePro 등)와 제조 공장 8곳, 지역 물류센터 3곳을 운영합니다.
사업은 수요 계획, 원자재 조달, MES 생산, 품질 출고, 완제품 유통, 소매 고객 주문, 트레이드 마케팅, 재무를 포괄합니다. 각 시뮬레이션 일에 상관된 MES 작업 지시, Ariba PO, OMS 헤더, OTM 출하, SAP 분개 라인이 생성되며, Spring Clean 급증 (3–4월)으로 북미와 EMEA에서 패브릭/홈케어 수요, 공장 처리량, 소매 셀인(sell-in)을 끌어올립니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템을 보여 줍니다. 완전한 EDW에는 추가 엔터티, 하위 유형, 특수 테이블(예: IoT 센서 측정, 유지보수 작업 지시, 트레이드 프로모션, CLM 레드라인)이 브론즈 테이블 60개 전반에 포함됩니다. V2에서는 ProductionBatch 및 CustomerOrder 도메인 클래스가 MakeToShipToSell 중추를 구동합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| SBU / 브랜드 사다리 | pc_brand | brand · category |
| 완제품 SKU | akeneo_pim | sku · brand · category |
| 공장 / DC 마스터 | oracle_scm | warehouse · office |
| 수요 예측 | blueyonder | forecast_daily |
| 원자재 PO | sap_ariba | purchase_order · purchase_order_line |
| 생산 배치 | siemens_mes | work_order |
| 품질 출고 | mastercontrol | quality_incident |
| 완제품 재고 | manhattan_wms | stock_balance · movement · pick_pack_event |
| 소매 고객 주문 | manhattan_oms | order_header · order_line |
| 출하 | oracle_otm | shipment · shipment_tracking_event |
| 소매 계정 | salesforce | account · opportunity · sales_activity |
| GL / COA | sap_s4 | journal_entry · journal_line |
PcEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
MakeToShipToSell 이 기본 프로세스 중추입니다. ProductionBatch.execute_lifecycle() 예측 → 조달 → 생산 → QC 출고 → 완제품 순으로 진행합니다. CustomerOrder.execute_lifecycle() OMS 캡처 → WMS 이행 → OTM 출하 순으로 진행합니다. PcPortfolio.publish_foundation() 배치와 주문 실행 전에 SBU, 브랜드, 공장, SKU, 소매 계정을 마스터합니다. 서비스 객체(PlantOperations, CommercialProgram, FinanceAndCorporate)가 지원용 전사·마케팅 행을 방출합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
Brand | brand_code | pc_brand + PIM의 SBU/카테고리 사다리 |
ProductSku | sku, material_number | PIM 게시 → MES 자재 연결 |
Plant | facility_code | 제조 공장 또는 DC 등록 |
ProductionBatch | work_order_id | forecast_demand() → procure_materials() → run_production() → release_quality() → receive_finished_goods() |
RetailCustomer | sf_account_id | Salesforce의 트레이드 계정 |
CustomerOrder | order_number | place_order() → fulfill() → ship() |
Supplier | ariba_supplier_id | 조달 마스터 + 송장 연결 |
flowchart LR
PORT[PcPortfolio.publish_foundation]
BATCH[ProductionBatch.execute_lifecycle]
ORDER[CustomerOrder.execute_lifecycle]
PORT --> BATCH
PORT --> ORDER
BATCH --> FCST[BlueYonder forecast]
FCST --> PO[Ariba PO]
PO --> MES[SIEMENS MES work order]
MES --> QC[MasterControl release]
QC --> WMS[WMS finished goods]
ORDER --> OMS[OMS order]
OMS --> SHIP[OTM shipment]
SHIP --> GL[SAP S/4 journal]
브랜드 포트폴리오부터 계획, 생산, 이동, 판매, 전사 마감까지.
샘플 보기: 이는 P&C 생태계 전반의 주요 가치 사슬을 보여 줍니다. 생성된 전체 EDW에는 여기에 표시되지 않은 교차 기능 통합, IoT 공장 텔레메트리, 트레이드 마케팅 흐름을 포함한 소스 시스템 34개가 모두 포함됩니다.
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph portfolio["Portfolio & R&D"]
direction TB
PCB[pc_brand SBU ladder]
PIM[akeneo_pim SKU]
PCB ~~~ PIM
end
subgraph plan["Plan & procure"]
direction TB
BY[blueyonder forecast]
ARB[sap_ariba PO]
BY ~~~ ARB
end
subgraph make["Make & quality"]
direction TB
MES[siemens_mes work order]
MC[mastercontrol QC]
MES ~~~ MC
end
subgraph move["Store & ship"]
direction TB
WMS[manhattan_wms inventory]
OTM[oracle_otm TMS]
WMS ~~~ OTM
end
subgraph sell["Sell to retail"]
direction TB
SF[salesforce trade]
OMS[manhattan_oms orders]
SF ~~~ OMS
end
subgraph corp["Corporate"]
direction TB
WD[workday]
S4[sap_s4 GL]
WD ~~~ S4
end
portfolio --> plan --> make --> move --> sell --> corp
신시내티 글로벌 HQ와 직속 기능, 대표 소스 시스템.
샘플 조직 구조: 이는 주요 보고 체계를 보여 줍니다. 전체 P&C 조직에는 벤더 통합 34개 전반의 지역 SBU 팀, 공장 관리자, 공유 서비스 기능이 포함됩니다.
flowchart TB
CEO[P&C Global]
CEO --> SBU[SBU portfolio & R&D]
CEO --> MFG[Supply chain & manufacturing]
CEO --> COMM[Commercial & retail sales]
CEO --> MKT[Marketing & brand]
CEO --> FIN[Finance & controller]
CEO --> HR[Human resources]
CEO --> QUAL[Quality & regulatory]
CEO --> LEG[IT / legal / security]
카탈로그 stage 기반부터 전사까지 테이블을 묶습니다.
표시된 샘플 구성: 이는 성숙 레이어에 분포된 전체 60개 테이블 인벤토리의 대표 단면입니다. 실제 분포는 기반부터 전사 골드 테이블까지의 완전한 데이터 리니지를 반영합니다.
flowchart LR F["foundation
~13 tables"] SC["supply_chain
~10 tables"] D["distribution
~6 tables"] C["commercial
~16 tables"] CO["corporate
~15 tables"] F --> SC --> D --> C F -.-> CO C -.-> CO
논리 관계와 앵커 키. 브랜드(brand_code)와 공장(facility_code)이 중추이며, 자재 번호가 PIM을 MES에 연결합니다.
샘플 다이어그램: 이 엔터티 관계 다이어그램은 핵심 논리 모델을 보여 줍니다. 생성된 전체 EDW에는 브론즈 테이블 60개 걸쳐 벤더 시스템 34개 추가 상세 테이블과 리니지 분기가 있습니다. 엔터티 인스턴스는 다음을 가집니다 entity_refs 조인 가능성을 시험하기 위해 방출되는 모든 이벤트에.
erDiagram
BRAND ||--o{ PRODUCT : owns
PRODUCT ||--o{ PRODUCTION_BATCH : produces
PLANT ||--o{ PRODUCTION_BATCH : runs
SUPPLIER ||--o{ PO : supplies
PRODUCTION_BATCH ||--o{ PO : triggers
PLANT ||--o{ INVENTORY : stocks
RETAIL_CUSTOMER ||--o{ CUSTOMER_ORDER : places
PRODUCT ||--o{ ORDER_LINE : contains
CUSTOMER_ORDER ||--|{ ORDER_LINE : lines
CUSTOMER_ORDER ||--o{ SHIPMENT : ships
CUSTOMER_ORDER ||--o{ JOURNAL : posts
벤더 접두사 34개, 브론즈 테이블 60개.
표시된 샘플 시스템: 아래 다이어그램은 대표 벤더 시스템을 보여 줍니다. 생성된 전체 데이터셋에는 34개 시스템 전부와 이력 백필·라이브 스트림에 걸친 전체 테이블 리니지 및 통합 지점이 포함됩니다. 공유 소스 시스템 매니페스트는 kb/source_systems/ 산업 전반에서 재사용합니다. P&C는 다음을 추가합니다 pc_brand 산업별 내부 시스템으로.
각 테이블은 다음을 따릅니다 {source_system_}__{entity} 명명 규칙(예: pc_brand__brand, siemens_mes__work_order), 각 제품의 실제 내보내기 스키마에서 벤더 고유 컬럼 형태와 외래 키를 유지합니다. VibeBI는 레코드를 실버와 골드로 승격할 때 마스터 데이터 정합을 추론합니다.
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["pc_brand · akeneo_pim
oracle_scm · workday"]
f2["sap_s4 dimensions"]
end
subgraph supply_chain["Supply chain"]
direction TB
s1["blueyonder · sap_ariba
siemens_mes · mastercontrol"]
s2["ibm_maximo · aws_iot"]
end
subgraph distribution["Distribution"]
direction TB
d1["manhattan_wms
oracle_otm"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce · manhattan_oms
hubspot · marketo"]
c2["google_analytics · qualtrics · zendesk"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · coupa
adp · ukg · concur"]
co2["servicenow · okta · splunk
ironclad · onetrust · greenhouse"]
end
foundation --> supply_chain --> distribution --> commercial
foundation --> corporate
commercial --> corporate
V2 OOP 시뮬 → ClickHouse 브론즈, VibeBI 시맨틱 → 같은 인스턴스에서 실버 → 골드.
OOP 경로: kb/industries/pnc/ 운영 중추와 엔터티 모델을 정의합니다. PcEnterpriseSimulation 도메인 라이프사이클을 순서대로 실행합니다. SourceSystem 어댑터가 벤더 고유 행을 다음으로 내보냅니다 pnc_v2.
flowchart LR
subgraph kb["kb/industries/pnc"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/pnc"]
ORCH[PcEnterpriseSimulation]
DOM["ProductionBatch · CustomerOrder
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse pnc_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-pnc — 60초 틱 경유 PcEnterpriseSimulation.generate().
라이브 주기: 각 틱이 MakeToShipToSell 상태 머신을 실행합니다. 도메인 객체가 생산 배치와 소매 고객 주문마다 상관된 예측, PO, MES, WMS, OMS, OTM, GL 행을 방출합니다. 규모는 틱마다 달라집니다(기본 베이스 5). 필요한 이력 구간을 백필하십시오 (--days N 라이브 스크립트 또는 CLI에서).
flowchart LR
START([60s tick]) --> SIM[PcEnterpriseSimulation.generate]
SIM --> FOUND[PcPortfolio.publish_foundation]
FOUND --> BATCH[ProductionBatch lifecycles]
FOUND --> ORDER[CustomerOrder lifecycles]
BATCH --> CORP[PlantOps + Finance + Commercial]
ORDER --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
MakeToShipToSell 상태 머신 — 각 전이는 벤더 행을 방출하는 도메인 메서드입니다.
프로세스 중추: 다음에 정의됨 kb/industries/pnc/process_model.yaml. 예외 모드(배치 폐기, 품질 보류, 부분 출하, 공급사 지연)는 독립된 무작위 삽입이 아니라 동일 엔터티 라이프사이클에서 분기합니다.
flowchart LR
FCST[forecasted] --> PROC[materials_procured]
PROC --> PROD[production_started]
PROD --> QC[quality_released]
QC --> FG[finished_goods_received]
FG --> ORD[customer_ordered]
ORD --> FUL[fulfilled]
FUL --> SHIP[shipped]
SHIP --> GL[posted_to_gl]
PROD -.->|scrap| SCRAP[batch_scrap]
QC -.->|hold| HOLD[quality_hold]
FUL -.->|short| PART[partial_shipment]
모든 테이블에 동일한 리니지 봉투, 범주가 라이브 동작을 결정합니다.
샘플 범주: 브론즈 테이블 60개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Brand · plant · SKU masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["POs · work orders · OMS · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["IoT · WMS movement · OTM tracking"]
E2[Append each live tick]
end
BRONZE[("pnc_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE