サンプルデータ · SimEDW

エンタープライズ規模の サンプルウェアハウス。

完全シミュレーションされた EDW 6 つ — 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)はセントラルに本拠を置く香港のユニバーサルバンクで、Wealth and Personal Banking、Commercial Banking、Global Banking and Markets を展開します。HKD 預金を受け入れ、HIBOR 住宅ローンと無担保与信を組成し、カードを発行し、24×7 の Faster Payment System と PearlPay(PayMe クラス)レールを運用し、グレーターベイエリア貿易をファイナンスし、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 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。

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 ウォレットパートナー経由で販売します。本社はクオリーベイ、セントラルにアドバイザリーセンター、尖沙咀に 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 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。

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 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。

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 は約 680 施設・18 ブランドを持つグローバルホテルオペレーターです。ラグジュアリー旗艦(Waldorf 級、Conrad 級)からフルサービス(Hilson、DoubleTree 級)、セレクトサービス、長期滞在層まで。各施設はオンプレミスの Opera PMS と中央 Amadeus CRS を運用し、一時レジャー、法人契約、団体/コンベンションのゲストに対応します。

事業はロイヤルティ(数百万人規模の Hilson Honors)、団体・コンベンション営業(Salesforce パイプライン、CPQ ルームブロック)、F&B 店舗(MICROS Simphony POS)、オーナー/フランチャイズ報告(Oracle Fusion 計算書)、コーポレート機能にまたがります。典型的な平日で約 1,900 の PMS 予約と 1,750 のフォリオヘッダーを生成し、 夏季旅行需要急増 (6〜8月)により、全施設で稼働率、ADR、F&B 消費、ロイヤルティ活動が上昇します。

サンプルエンティティ: 下表は代表的な事業エンティティとソースシステムです。完全な EDW には追加エンティティ、サブタイプ、専用テーブル(例:OTA チャネルイベント、料金プラン制限、フランチャイズ契約、ディールデスク・レッドライン)が 62 のブロンズテーブル全体に含まれます。V2 では、 StayReservation および関連ドメインクラスが、滞在ライフサイクルの進行に合わせて PMS、CRS、フォリオ、ロイヤルティの行をソースシステムアダプター経由で出力します。

エンティティソースシステムテーブル例
施設マスタ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
フォリオ/請求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 同期 → フォリオ課金 → 決済 → ロイヤルティポイント → 稼働スナップショット → オーナー計算書 → GL と進みます。 HilsonPortfolio.publish_foundation() が予約実行前にブランド、施設、Honors 会員をマスタ化します。

ドメインエンティティナチュラルキーライフサイクルメソッド
Brandbrand_codeブランド階層は hilson_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
          

部門別の機能組織

企業本社と直属機能、代表的なソースシステム付き。

サンプル組織構造: これは主要な報告ラインです。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、フォリオ、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 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。

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 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。

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 はグローバルな消費財メーカー兼マーケターです。日用品をマスリテール、クラブ、グロサリー、Eコマース経由で約 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 でファブリック/ホームケア需要、工場スループット、小売向けセルインが上昇します。

サンプルエンティティ: 下表は代表的な事業エンティティとソースシステムです。完全な 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]
          

Make-to-ship バリューチェーン

ブランドポートフォリオから、計画、製造、物流、販売、コーポレート決算まで。

サンプルビュー: これは 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
          

部門別の機能組織

シンシナティのグローバル本社と直属機能、代表的なソースシステム付き。

サンプル組織構造: これは主要な報告ラインです。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 ステートマシンを実行します。ドメインオブジェクトが生産バッチと小売顧客注文ごとに相関した forecast、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
          

Make-to-ship イベントグラフ

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 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。

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 サンプルデータをダウンロードし、午後のうちに最初のガバナンス済みウェアハウス構築を進められます。

クイックスタート → プロダクトプレビュー ホワイトペーパーを読む