샘플 데이터 · SimEDW

엔터프라이즈 규모 샘플 웨어하우스.

완전히 시뮬레이션된 EDW 여섯 개 — HKBC(홍콩 유니버설 뱅크), AYA(홍콩 복합 보험사), Smire(홍콩 복합용도 랜드로드), Hilson(글로벌 호텔 그룹), Cathea(홍콩 화물·여객 물류), P&C(소비재) — 현실적인 벤더 고유 스키마, ClickHouse의 메달리온 준비 브론즈, 라이브 이벤트 스트림. VibeBI에서 시맨틱 레이어, 디멘셔널 모델링, 셀프서비스 분석을 시험하기 위해 만들었습니다.

6
산업 팩
215
벤더 소스 시스템
362
브론즈 테이블 합계
60초
라이브 데이터 새로고침
32 벤더 시스템 60 브론즈 테이블 5 단계 DB hkbc_v2

회사 프로필

가상 회사 안내: 「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_corebranch
상품 카탈로그hkbc_coreproduct
고객 (CIF)hkbc_core · salesforcecustomer · account · contact
예금 / 대출 계좌hkbc_coreaccount · posting · deposit_balance
FPS / CHATS / SWIFThkicl_fps · hkicl_chats · swiftproxy · payment · rtgs_payment · message
카드fiserv_visionpluscard · authorization · clearing_transaction
PearlPay 월렛hkbc_paywallet · wallet_payment
무역금융hkbc_tradedocumentary_credit · guarantee
FX / 마켓murex · bloombergfx_trade · position · fx_rate
AML / 신용 위험nice_actimize · moodys_riskaml_alert · case · credit_facility · ecl_provision
웰스 딜링hkbc_wealthholding · securities_order
GL / COAsap_s4journal_entry · journal_line

OOP 도메인 모델

HkbcEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.

PayToPostToBalance 이 기본 프로세스 중추입니다. FpsPayment.execute_lifecycle() (및 PearlPay, 카드, CHATS, SWIFT 대응 클래스)는 레일 메시지 → 코어 복식 분개 → 선택적 AML 알림 → EOD 예금 잔액 → GL 순으로 진행합니다. HkbcPortfolio.publish_foundation() 결제가 돌기 전에 지점, 상품, CIF 고객, 계좌를 마스터합니다. 서비스 객체가 CMB 무역, GBM FX, 웰스, 리스크, 코퍼레이트 행을 방출합니다.

도메인 엔터티자연 키라이프사이클 메서드
Branchbranch_codehkbc_core에서 마스터된 지점 / 도매 데스크
Productproduct_codeCASA, 주택담보, 카드, 월렛, 무역, FX 카탈로그
Customercustomer_idCIF + KYC 세그먼트; Salesforce CRM 미러
Accountaccount_idpublish() → post_pair() 균형 원장
FpsPaymentpayment_idexecute_lifecycle() → 레일 → 분개 → AML
DocumentaryCreditlc_idCMB LC / 보증 발행
FxTradetrade_idMurex 티켓 → 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]
          

EDW 성숙 단계

카탈로그 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
          

Pay-to-post 이벤트 그래프

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
          
39 벤더 시스템 60 브론즈 테이블 5 단계 DB aya_v2

회사 프로필

가상 회사 안내: 「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_productline_of_business · product
IA 라이선스 설계사aya_agencyagent
계약자salesforceaccount · contact · address
디지털 견적 / FNOLaya_digitalsession · quote · claim_submission
생명 / 건강보험 증권dxc_ingenium · swissre_magnumpolicy · coverage · premium · decision
일반보험 증권 / 청구guidewire_pc · guidewire_bcpolicy · coverage · invoice
일반보험 클레임guidewire_ccclaim · claim_transaction
건강보험 클레임 / 클리닉fineos · aya_healthhealth_claim · clinic_visit
보험료 / 클레임 현금fpspayment
수수료varicentcommission
재보험sap_fs_ricession
투자 / 평가bloomberg_aim · prophetholding · trade · valuation
GL / IFRS 17sap_s4journal_entry · journal_line

OOP 도메인 모델

AyaEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.

QuoteToBindToPremium 는 신계약 중추입니다. FnolToPay 는 클레임 중추입니다. LifePolicy.execute_lifecycle() 견적 → Magnum UW → Ingenium 발행 → FPS 수금 → 수수료 → GL 순으로 진행합니다. GiPolicy.execute_lifecycle() 견적 → PolicyCenter 인수 → BillingCenter 청구서 → ClaimCenter의 선택적 당일 FNOL 순으로 진행합니다. AyaPortfolio.publish_foundation() 증권이 돌기 전에 상품, 설계사, 사무소, 계약자를 마스터합니다.

도메인 엔터티자연 키라이프사이클 메서드
InsuranceProductproduct_codeaya_product의 생명 / 건강 / 일반보험 요율
Agentagent_idIA 라이선스 등록 + Salesforce 프로듀서
Policyholdersf_account_id매스 / HNW / SME / 고용주 CRM
LifePolicypolicy_numberpublish_quote() → UW → 인수 → 수금 → 수수료 → GL
GiPolicypolicy_numberpublish_quote() → 인수 → 청구 → open_claim()
HealthClaimclaim_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]
          

EDW 성숙 단계

카탈로그 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
          

Quote-to-bind 및 FNOL 이벤트 그래프

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
          
39 벤더 시스템 60 브론즈 테이블 5 단계 DB smire_v2

회사 프로필

가상 회사 안내: 「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_portfolioproperty · building · unit
임차인yardi_voyager · salesforcetenant · account · contact
리싱 오퍼smire_leasingoffer
리스 / 렌트롤 / 인보이스yardi_voyagerlease · rent_roll · invoice
임대료 수금fpspayment
몰 POS / 유동량smire_malltenant_sale · footfall
BMS / 출입 / 주차honeywell_bms · nedap_aeos · smire_parktelemetry · badge_event · session
밸류에이션 / 컴프argus_enterprise · costar_analyticsvaluation · comp
개발smire_devproject · capex_draw
호텔 점유smire_hoteloccupancy
분양 매각smire_residentialsale
로열티smire_loyaltymember · earn
NOI / GLsap_s4journal_entry · journal_line

OOP 도메인 모델

SmireEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.

LeaseToCollect 는 리싱 스파인입니다. MallTradingDay 는 리테일 운영 스파인입니다. Lease.execute_lifecycle() 오퍼 → Yardi 리스와 렌트롤 → 인보이스(기본+매출 연동 임대료) → FPS 수금 → NOI 분개를 따라갑니다. Tenant.publish() 리스가 돌기 전에 Yardi와 Salesforce를 마스터합니다。 SmirePortfolio.publish_foundation() 먼저 프로퍼티, 빌딩, 임대 유닛, 사이트를 마스터합니다.

도메인 엔터티자연 키라이프사이클 메서드
Propertyproperty_codesmire_portfolio의 캠퍼스 / 몰 / 호텔 마스터
Unitunit_id임대 가능 NFA; 점유 원장
Tenanttenant_codepublish() → Yardi + Salesforce CRM
Leaselease_idexecute_lifecycle() → offer → lease → invoice → FPS → GL
CorporateOfficelocation_idoracle_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
          

Lease-to-collect 가치사슬

포트폴리오 마스터에서 리싱, 몰 거래, 자산 운영, 재무 마감까지.

샘플 보기: 이는 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]
          

EDW 성숙 단계

카탈로그 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
          

Lease-to-collect 및 자산 이벤트 그래프

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
          
31 벤더 시스템 62 브론즈 테이블 5 단계 DB hilson_v2

회사 프로필

가상 회사 안내: "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_operaproperty · room_type · occupancy_snapshot
브랜드 / CRShilson_brand · amadeus_hospbrand · property_profile
로열티 회원hilson_loyaltymember · point_transaction · redemption
예약 (PMS/CRS)oracle_opera · amadeus_hospreservation · reservation_change_event
Folio / 청구oracle_operafolio_header · folio_charge
F&B 매장micros_simphonycheck_header · check_line
결제adyenpayment · refund
단체 영업salesforce · salesforce_cpqaccount · opportunity · quote
하우스키핑oracle_operaroom_status_event · housekeeping_task
오너 / GLoracle_fusion · sap_s4owner_statement · journal_line
투숙객 경험medallia · zendeskstay_survey · guest_case

OOP 도메인 모델

HilsonEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.

ReservationToLoyaltyAndOwnerReporting 이 기본 프로세스 중추입니다. StayReservation.execute_lifecycle() 예약 → PMS 동기화 → folio 요금 → 결제 → 로열티 포인트 → 점유 스냅샷 → 오너 명세서 → GL 순으로 진행합니다. HilsonPortfolio.publish_foundation() 예약 실행 전에 브랜드, 숙박 시설, Honors 회원을 마스터합니다.

도메인 엔터티자연 키라이프사이클 메서드
Brandbrand_codehilson_brand에서 마스터된 브랜드 사다리
Propertyhotel_codeOpera/CRS의 숙박 시설 + 객실 재고
GuestMemberhonors_member_id예약과 숙박에 걸친 로열티 프로필
StayReservationcrs_confirmation_nobook() → sync_pms() → open_folio() → settle() → award_points()
PropertyOccupancyhotel_code, 날짜일별 ADR / RevPAR 스냅샷
PropertyFinanceowner_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]
          

EDW 성숙 단계

카탈로그 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
          
40 벤더 시스템 60 브론즈 테이블 5 단계 DB cathea_v2

회사 프로필

가상 회사 안내: 「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_networkaircraft · route · flight
스테이션oracle_scmstation
NDC 오더cathea_ndcorder
PNR / e티켓amadeus_alteapnr · ticket
체크인 / 수하물amadeus_dcscheckin · bag_scan
여객 카드adyenpayment
화물 부킹 / AWBchamp_cargospotbooking · awb
화물 터미널cathea_chtacceptance · uld_scan
편 무브먼트sita_typebmovement
OFP / 승무navblue · aims_crewofp · duty
Pacific Milescathea_loyaltymember · accrual
화물 수금fpspayment
수익 / GLaccelya_ra · sap_s4document · journal_entry · journal_line

OOP 도메인 모델

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 시각 편을 마스터합니다.

도메인 엔터티자연 키라이프사이클 메서드
Aircraftregistrationcathea_network의 항공기 마스터
Flightflight_idHKG 시각 로테이션; SITA MVT + Navblue OFP
Pnrpnr_locatorexecute_lifecycle() → NDC → Altéa → DCS → Adyen → Miles → GL
AirWaybillawb_numberexecute_lifecycle() → Cargospot → CHT → ULD → FPS
LoyaltyMembermember_idPacific 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]
          

Offer-to-fly 및 화물 가치사슬

네트워크 마스터에서 여객, 화물, 운영, 재무 마감까지.

샘플 보기: 이는 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]
          

EDW 성숙 단계

카탈로그 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
          

Offer-to-fly 및 화물 이벤트 그래프

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
          
34 벤더 시스템 60 브론즈 테이블 5 단계 DB pnc_v2

회사 프로필

가상 회사 안내: "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_brandbrand · category
완제품 SKUakeneo_pimsku · brand · category
공장 / DC 마스터oracle_scmwarehouse · office
수요 예측blueyonderforecast_daily
원자재 POsap_aribapurchase_order · purchase_order_line
생산 배치siemens_meswork_order
품질 출고mastercontrolquality_incident
완제품 재고manhattan_wmsstock_balance · movement · pick_pack_event
소매 고객 주문manhattan_omsorder_header · order_line
출하oracle_otmshipment · shipment_tracking_event
소매 계정salesforceaccount · opportunity · sales_activity
GL / COAsap_s4journal_entry · journal_line

OOP 도메인 모델

PcEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.

MakeToShipToSell 이 기본 프로세스 중추입니다. ProductionBatch.execute_lifecycle() 예측 → 조달 → 생산 → QC 출고 → 완제품 순으로 진행합니다. CustomerOrder.execute_lifecycle() OMS 캡처 → WMS 이행 → OTM 출하 순으로 진행합니다. PcPortfolio.publish_foundation() 배치와 주문 실행 전에 SBU, 브랜드, 공장, SKU, 소매 계정을 마스터합니다. 서비스 객체(PlantOperations, CommercialProgram, FinanceAndCorporate)가 지원용 전사·마케팅 행을 방출합니다.

도메인 엔터티자연 키라이프사이클 메서드
Brandbrand_codepc_brand + PIM의 SBU/카테고리 사다리
ProductSkusku, material_numberPIM 게시 → MES 자재 연결
Plantfacility_code제조 공장 또는 DC 등록
ProductionBatchwork_order_idforecast_demand() → procure_materials() → run_production() → release_quality() → receive_finished_goods()
RetailCustomersf_account_idSalesforce의 트레이드 계정
CustomerOrderorder_numberplace_order() → fulfill() → ship()
Supplierariba_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]
          

EDW 성숙 단계

카탈로그 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
          

BI를 바이브하기 시작하십시오.

데스크톱 앱, 서버, SimEDW 샘플 데이터를 다운로드하고, 오후에 첫 거버넌스 웨어하우스 구축을 진행하십시오.

빠른 시작 → 제품 미리보기 백서 읽기