Enterprise-Maßstab Beispiel-Warehouses.

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „AYA“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit AXA SA, AXA Hong Kong and Macau noch mit einem realen Versicherungsunternehmen verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

AYA ist ein hongkonger Kompositversicherer — Life & Savings, Health (inkl. VHIS und Employee Benefits) und General Insurance — vertrieben über gebundene Agenten, Bancassurance, Broker, die Aria-by-AYA-App und eingebettete E-Wallet-Partner. HQ in Quarry Bay, mit Advisory-Center in Central, AYA Medical Centre in Tsim Sha Tsui, einer Macau-Niederlassung und einem GBA-Vertriebsbüro in Qianhai.

Das Geschäft spannt Produktfabrik, Magnum-Klasse-Underwriting, split PAS (Leben auf Ingenium-Klasse, GI auf Guidewire), FPS-Prämieninkasso, Varicent-Provision, 24×7 Motor-/Reise-FNOL, FINEOS-Gesundheits-Claims, Rückversicherungszession, Prophet-IFRS-17-Bewertung und SAP-S/4-Journale — mit einem Taifun-Saison-GI-Claims-Anstieg (Juni–Oktober) und einem CNY-Reise-/Northbound-Kfz-Spike über digitale und Agenturkanäle.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäfts-Entitäten und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und spezialisierte Tabellen (z. B. Prophet BEL/CSM, Vertragzessionen, Klinikbesuche, CLM-Redlines) über alle 60 Bronze-Tabellen. In V2 LifePolicy und GiPolicy Domänenklassen treiben die QuoteToBindToPremium- und FnolToPay-Spines.

OOP-Domänenmodell

AyaEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

QuoteToBindToPremium ist die New-Business-Spine; FnolToPay ist die Claims-Spine. LifePolicy.execute_lifecycle() durchläuft Quote → Magnum-UW → Ingenium-Ausgabe → FPS-Inkasso → Provision → GL. GiPolicy.execute_lifecycle() durchläuft Quote → PolicyCenter-Bind → BillingCenter-Invoice → optionales Same-Day-FNOL auf ClaimCenter. AyaPortfolio.publish_foundation() mastert Produkte, Agenten, Offices und Versicherungsnehmer, bevor Policen laufen.

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]
          

Quote-to-claim-Wertschöpfungskette

Von der Produktfabrik über Distribution, Bind, Inkasso, Claims und Finance-Close.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette durch das AYA-Ökosystem; das vollständig erzeugte EDW umfasst alle 39 Quellsysteme mit funktionsübergreifenden Integrationen, bargeldlosen Klinikbesuchen und hier nicht gezeigter Vertragsbuchhaltung.

%%{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
          

Funktionale Organisation nach Abteilung

AYA Tower Quarry Bay HQ und Direktbericht-Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige AYA-Organisation umfasst zusätzliche Agenturdistrikte, Macau- und GBA-Teams und Shared-Services-Funktionen über alle 39 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 60-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Produkt (product_code) und Police (policy_number) bilden die Spine; Claims joinen über FNOL und Schadennummern.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 60 Bronze-Tabellen über 39 Vendor-Systeme mit zusätzlichen Detailtabellen und Lineage-Zweigen. Entitätsinstanzen tragen entity_refs auf jedem erzeugten Event für Joinability-Tests.

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
          

Quellsystemlandschaft

39 Vendor-Präfixe, 60 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 39 Systeme mit vollständiger Tabellen-Lineage und Integrationspunkten über History-Backfill und Live-Streams. Geteilte Quellsystem-Manifeste in kb/source_systems/ werden branchenübergreifend wiederverwendet — AYA fügt hinzu aya_product, aya_agency, aya_digital, und aya_health als branchenspezifische interne Systeme, plus ein split PAS (Guidewire + Ingenium).

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. aya_product__product, guidewire_cc__claim), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/aya/ definiert das Operations-Rückgrat und das Entitätsmodell; AyaEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen in 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-Bronze-Zyklus

./live-v2-aya — 60s-Tick über AyaEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt QuoteToBindToPremium und FnolToPay aus — Domänenobjekte emittieren korrelierte Quotes, UW-Entscheidungen, PAS-Binds, FPS-Inkasso, Provisionen, FNOL und GL-Zeilen; Live-Ticks für heute emittieren nur Events bis Hongkong as_of damit Quotes, FNOL, FPS und Journals über den Tag wachsen. Die Skala variiert pro Tick (Standard-Base 5). Backfillen Sie jede benötigte History-Spanne (--days N im Live-Skript oder 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- und FNOL-Eventgraphen

QuoteToBindToPremium- und FnolToPay-State-Machines — jeder Übergang ist eine Domänenmethode, die Vendor-Zeilen emittiert.

Prozess-Rückgrat: Definiert in kb/industries/aya/process_model.yaml. Late-Arrival-Modi (PAS-Ausgabe-Lag, FPS-Clearing, Provisions-Batch, Overnight-FNOL, Rückversicherungs-Bordereau) und Ausnahme-Modi (UW-Refer/Ablehnung, Prämienverfall, Schadenabweisung, Teilstregulierung) zweigen von denselben Entitäts-Lebenszyklen ab statt unabhängiger Zufalls-Inserts.

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]
          

Bronze-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert das Live-Verhalten.

Beispielkategorien: Alle 60 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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
          

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „Smire“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit Swire Properties Limited, Swire Pacific Limited noch mit einem realen Immobilienunternehmen verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

Smire Properties ist ein hongkonger Mixed-Use-Vermieter mit Sitz im Smire Tower, Quarry Bay — Grade-A-Office-Campuses (Eastgate Place, Harbour Place), Malls (Harbourplaza, Peakgate Outlets, Eastgate Li), Residential und Harbour-House-Hotels plus Mainland-Retail im Taikoo-Li-Stil in Peking, Shanghai, Guangzhou und Chengdu.

Das Buch spannt Leasing-Offers in Yardi-Leases und tägliche Rent Rolls, Base Rent plus Retail-Turnover-Rent aus Mall-POS, HK-FPS- / CNY-Inkasso, SAP-S/4-NOI-Journale, Near-Real-Time-BMS, Nedap-Badge-Events, Parkhaus und Mall-Footfall 11:00–22:00 HKT plus Argus GAV/NAV, CoStar-artige Comps, Development-CAPEX-Draws und Hotel-Occupancy/ADR/RevPAR — mit einem CNY-Mall-Trading-Surge der Harbourplaza- und Eastgate-Li-Footfall, Turnover-Rent und FPS-Inkasso anhebt.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäfts-Entitäten und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und spezialisierte Tabellen (z. B. ESG-Zähler, CAPEX-Draws, Hotelbelegung, CLM-Redlines) über alle 60 Bronze-Tabellen. In V2 Lease und Tenant Domänenklassen treiben die LeaseToCollect- und MallTradingDay-Spines.

OOP-Domänenmodell

SmireEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

LeaseToCollect ist die Leasing-Spine; MallTradingDay ist die Retail-Ops-Spine. Lease.execute_lifecycle() durchläuft Offer → Yardi-Lease und Rent Roll → Invoice (Base plus Turnover-Rent) → FPS-Inkasso → NOI-Journal. Tenant.publish() mastert Yardi und Salesforce, bevor Leases laufen. SmirePortfolio.publish_foundation() mastert Properties, Buildings, vermietbare Units und Sites zuerst.

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-Wertschöpfungskette

Vom Portfolio-Master über Leasing, Mall-Trading, Asset-Ops und Finance-Close.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette durch das Smire-Ökosystem; das vollständig erzeugte EDW umfasst alle 39 Quellsysteme mit funktionsübergreifenden Integrationen, Hotel-RevPAR und hier nicht gezeigtem Development-CAPEX.

%%{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
          

Funktionale Organisation nach Abteilung

Smire Tower Quarry Bay HQ und Direktbericht-Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige Smire-Organisation umfasst zusätzliche Property-Management-Büros, Mainland-Mall-Teams und Shared-Services-Funktionen über alle 39 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 60-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Property (property_code) und Unit (unit_id) bilden die Spine; Leases joinen über lease_id und FPS über Invoice.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 60 Bronze-Tabellen über 39 Vendor-Systeme mit zusätzlichen Detailtabellen und Lineage-Zweigen. Entitätsinstanzen tragen entity_refs auf jedem erzeugten Event für Joinability-Tests.

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
          

Quellsystemlandschaft

39 Vendor-Präfixe, 60 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 39 Systeme mit vollständiger Tabellen-Lineage und Integrationspunkten über History-Backfill und Live-Streams. Geteilte Quellsystem-Manifeste in kb/source_systems/ werden branchenübergreifend wiederverwendet — Smire fügt hinzu smire_portfolio, smire_leasing, smire_mall, und smire_hotel als branchenspezifische interne Systeme, plus Yardi Voyager und Argus.

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. smire_portfolio__unit, yardi_voyager__lease), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/smire/ definiert das Operations-Rückgrat und das Entitätsmodell; SmireEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen in 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-Bronze-Zyklus

./live-v2-smire — 60s-Tick über SmireEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt LeaseToCollect und MallTradingDay aus — Domänenobjekte emittieren korrelierte Offers, Leases, Invoices, FPS-Inkasso, Mall-POS, Footfall, Badge-Events und GL-Zeilen; Live-Ticks für heute emittieren nur Events bis Hongkong as_of damit Rent Rolls, Mall-Trading, BMS und Journals über den Tag wachsen. Die Skala variiert pro Tick (Standard-Base 5). Backfillen Sie jede benötigte History-Spanne (--days N im Live-Skript oder 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- und Asset-Eventgraphen

LeaseToCollect- und OperateAsset-State-Machines — jeder Übergang ist eine Domänenmethode, die Vendor-Zeilen emittiert.

Prozess-Rückgrat: Definiert in kb/industries/smire/process_model.yaml. Late-Arrival-Modi (FPS-Clearing-Lag, GL-Batch-Verzögerung, Overnight-BMS, Work-Order-Lag) und Ausnahme-Modi (Leerstand, Rückstände, Access Denied, Anlagenalarm) zweigen von denselben Entitäts-Lebenszyklen ab statt unabhängiger Zufalls-Inserts.

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]
          

Bronze-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert das Live-Verhalten.

Beispielkategorien: Alle 60 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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
          

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „Hilson“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit Hilton Inc., Hyatt Hotels Corporation noch mit einem realen Hospitality-Unternehmen verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

Hilson Hospitality Group ist ein globaler Hotelbetreiber mit ~680 Häusern über 18 Marken — von Luxury-Flags (Waldorf-Grade, Conrad-Grade) über Full-Service (Hilson, DoubleTree-Grade) bis Select-Service und Extended-Stay. Jedes Haus betreibt ein On-Premise Opera PMS und ein zentrales Amadeus CRS und bedient einen Mix aus Transient Leisure, Corporate Negotiated und Group/Convention.

Das Geschäft umfasst Loyalty (Hilson Honors mit Millionen Mitgliedern), Group- & Convention-Sales (Salesforce-Pipeline, CPQ-Zimmerblöcke), Food- & Beverage-Outlets (MICROS Simphony POS), Owner-/Franchise-Reporting (Oracle-Fusion-Statements) und Corporate-Funktionen — an einem typischen Wochentag rund 1.900 PMS-Reservierungen und 1.750 Folio-Köpfe, mit einem Sommerreise-Schub (Juni–August), der Auslastung, ADR, F&B-Umsatz und Loyalty-Aktivität über alle Häuser steigert.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäftsobjekte und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und Spezialtabellen (z. B. OTA-Kanalereignisse, Rate-Plan-Restriktionen, Franchise-Rechtsvereinbarungen, Deal-Desk-Redlines) über alle 62 Bronze-Tabellen. In V2 StayReservation und verwandte Domänenklassen erzeugen PMS-, CRS-, Folio- und Loyalty-Zeilen über Quellsystem-Adapter, während der Stay-Lebenszyklus fortschreitet.

OOP-Domänenmodell

HilsonEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

ReservationToLoyaltyAndOwnerReporting ist das primäre Prozess-Rückgrat. StayReservation.execute_lifecycle() führt Booking → PMS-Sync → Folio-Charges → Payment → Loyalty-Punkte → Occupancy-Snapshot → Owner Statement → GL. HilsonPortfolio.publish_foundation() mastert Marken, Properties und Honors-Mitglieder, bevor Reservierungen laufen.

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]
          

Gäste- und Property-Wertschöpfungskette

Vom Marken- und Property-Master über Distribution, Aufenthalt, Settlement und Owner-Reporting.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette durch das Hilson-Ökosystem; das vollständig erzeugte EDW umfasst alle 31 Quellsysteme mit funktionsübergreifenden Integrationen, sekundären Umsatzströmen und hier nicht gezeigten Loyalty-Lebenszyklusflüssen.

%%{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
          

Funktionale Organisation nach Abteilung

Enterprise-Zentrale und direkt unterstellte Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige Hilson-Organisation umfasst zusätzliches Regional Management, markenspezifische Teams und Shared-Services-Funktionen über alle 31 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 62-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Property (hotel_code) ist das Rückgrat; Gästeidentität über Honors und Stay-Tabellen.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 62 Bronze-Tabellen über 31 Vendor-Systeme mit Tausenden zusätzlicher Detailtabellen und Lineage-Zweigen.

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
          

Quellsystemlandschaft

31 Vendor-Präfixe, 62 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 31 Systeme mit ihrer vollständigen Tabellen-Lineage und den Integrationspunkten über History-Backfill und Live-Streams.

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. oracle_opera__reservation, hilson_loyalty__member), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/hilson/ definiert das Operations-Rückgrat und das Entitätsmodell; HilsonEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen in 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-Bronze-Zyklus

./live-v2-hilson — 60s-Tick über HilsonEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt die Reservation-to-Loyalty-State-Machine aus — Domänenobjekte erzeugen korrelierte CRS-, PMS-, Folio-, F&B-, Payment-, Loyalty- und GL-Zeilen; die Skalierung variiert pro Tick (Standardbasis 5). Backfillen Sie jede benötigte Historie (--days N); Hilson enthält Lückenerkennung auf der Reservierungs-Ankertabelle.

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
          

Guest-Stay-Event-Graph

ReservationToLoyaltyAndOwnerReporting-State-Machine — jeder Übergang erzeugt Vendor-Zeilen.

Prozess-Rückgrat: Definiert in kb/industries/hilson/process_model.yaml. Ausnahmezustände (No-Shows, Chargebacks, Zimmer-Upgrades) zweigen vom selben Entitätslebenszyklus ab, statt als unabhängige Zufallsinserts.

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]
          

Bronze-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert Live-Refresh vs. Micro-Batch-Append.

Beispielkategorien: Alle 62 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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
          

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „Cathea“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit Cathay Pacific Airways Limited, Cathay Pacific Group noch mit einer realen Airline verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

Cathea Pacific ist eine hongkonger Hub-Airline mit Sitz in Cathea City, Chek Lap Kok — Premium-Passenger (HP), Air Cargo und Cathea Cargo Terminal, Peak Express LCC (PX) und Air-Harbour-Express-Frachter (AH) plus Pacific-Miles-Lifestyle. Das Netz ist HKG-getaktet: Long-Haul-A350/777-Rotationen, Nacht-747-8F-Wellen und A321neo-Regionalflüge.

Der Tag läuft NDC-Order → Altéa-Klasse-PNR und 168-Prefix-E-Ticket → Adyen-Kartenerfassung → DCS-Check-in und Gepäckscans → Navblue-OFP, AIMS-Crew-Duty und SITA-MVT (inkl. Nacht-Cargo 01:00–05:00 HKT) → Pacific-Miles-Accrual und Accelya-Rating → SAP-S/4-Journale. Cargo durchläuft Cargospot-Booking → AWB → Terminal-Acceptance → ULD-Scan → Movement → OTM-Trucking → FPS-Inkasso — mit einem CNY-Reise- / Taifun-IRROPS-Anstieg der Peak-Express-Load-Factor, Gepäckscans und Cargo-Waitlists ansteigen lässt.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäfts-Entitäten und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und spezialisierte Tabellen (z. B. Fuel-Uplifts, TRAX-Work-Orders, ULD-Scans, Loyalty-Accruals) über alle 60 Bronze-Tabellen. In V2 Pnr und AirWaybill Domänenklassen treiben die OfferToFlyToRevenue- und BookToDeliverCargo-Spines.

OOP-Domänenmodell

CatheaEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

OfferToFlyToRevenue ist die Passenger-Spine; BookToDeliverCargo ist die Cargo-Spine. Pnr.execute_lifecycle() durchläuft NDC-Order → Altéa-PNR und E-Ticket → Adyen-Capture → DCS-Check-in → geflogener Coupon → Pacific Miles → Accelya → GL. AirWaybill.execute_lifecycle() durchläuft Cargospot-Booking → AWB → CHT-Acceptance → ULD → SITA-Movement → OTM-Trucking → FPS-Inkasso. CatheaPortfolio.publish_foundation() mastert Flugzeuge, Routen, Stationen und HKG-getaktete Flüge, bevor PNRs und AWBs laufen.

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- und Cargo-Wertschöpfungskette

Vom Netzwerk-Master über Passenger, Cargo, Ops und Finance-Close.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette durch das Cathea-Ökosystem; das vollständig erzeugte EDW umfasst alle 40 Quellsysteme mit funktionsübergreifenden Integrationen, Nacht-Cargo-Wellen und hier nicht gezeigtem TRAX-MRO.

%%{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
          

Funktionale Organisation nach Abteilung

Cathea City Chek Lap Kok HQ und Direktbericht-Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige Cathea-Organisation umfasst zusätzliche Outstations, GBA-Cargo-Desks und Shared-Services-Funktionen über alle 40 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 60-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Flug (flight_id) und PNR (pnr_locator) bilden die Passenger-Spine; AWB (awb_number) joinen Cargo über Booking und FPS.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 60 Bronze-Tabellen über 40 Vendor-Systeme mit zusätzlichen Detailtabellen und Lineage-Zweigen. Entitätsinstanzen tragen entity_refs auf jedem erzeugten Event für Joinability-Tests.

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
          

Quellsystemlandschaft

40 Vendor-Präfixe, 60 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 40 Systeme mit vollständiger Tabellen-Lineage und Integrationspunkten über History-Backfill und Live-Streams. Geteilte Quellsystem-Manifeste in kb/source_systems/ werden branchenübergreifend wiederverwendet — Cathea fügt hinzu cathea_network, cathea_ndc, cathea_cht, und cathea_loyalty als branchenspezifische interne Systeme, plus Altéa-PSS und Cargospot.

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. cathea_network__flight, amadeus_altea__pnr), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/cathea/ definiert das Operations-Rückgrat und das Entitätsmodell; CatheaEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen in 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-Bronze-Zyklus

./live-v2-cathea — 60s-Tick über CatheaEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt OfferToFlyToRevenue und BookToDeliverCargo aus — Domänenobjekte emittieren korrelierte NDC-Orders, PNRs, Tickets, DCS-Scans, Cargo-AWBs, SITA-Movements, FPS-Inkasso und GL-Zeilen; Live-Ticks für heute emittieren nur Events bis Hongkong as_of damit Check-ins, Gepäckscans, Nacht-Cargo und Journals über den Tag wachsen. Die Skala variiert pro Tick (Standard-Base 5). Backfillen Sie jede benötigte History-Spanne (--days N im Live-Skript oder 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- und Cargo-Eventgraphen

OfferToFlyToRevenue- und BookToDeliverCargo-State-Machines — jeder Übergang ist eine Domänenmethode, die Vendor-Zeilen emittiert.

Prozess-Rückgrat: Definiert in kb/industries/cathea/process_model.yaml. Late-Arrival-Modi (DCS-Scan-Lag, MVT-Lag, RA-Batch-Lag, GL-Batch-Verzögerung) und Ausnahme-Modi (No-Show, IRROPS-Delay, Kartenablehnung, Short Shipment, Capacity-Waitlist) zweigen von denselben Entitäts-Lebenszyklen ab statt unabhängiger Zufalls-Inserts.

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]
          

Bronze-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert das Live-Verhalten.

Beispielkategorien: Alle 60 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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
          

Unternehmensprofil

Hinweis zu fiktiven Unternehmen: „P&C“ ist ein vollständig fiktives Unternehmen, das ausschließlich zu Demonstrationszwecken geschaffen wurde. Es ist weder mit The Procter & Gamble Company noch mit einem realen CPG-Hersteller verbunden, von diesen unterstützt oder dazu bestimmt, sie darzustellen.

P&C ist ein globaler Hersteller-Vermarkter von Konsumgütern — ein B2B2C-Modell, das Alltagsprodukte über Mass Retail, Club, Grocery und E-Commerce in ~180 Ländern verkauft. Fünf Sector Business Units (SBUs) umfassen Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care und Grooming, mit ~12 Flagship-Marken (TidalWave, ComfortWrap, BrightSmile, EdgePro und andere) sowie acht Werken und drei regionalen Distributionszentren.

Das Geschäft umfasst Demand Planning, Rohstoffbeschaffung, MES-Produktion, Qualitätsfreigabe, Fertigwarenverteilung, Retail-Kundenaufträge, Trade Marketing und Finance — und erzeugt korrelierte MES-Work-Orders, Ariba-POs, OMS-Köpfe, OTM-Sendungen und SAP-Journalzeilen an jedem Simulationstag, mit einem Spring-Clean-Schub (März–April), der die Nachfrage in Fabric/Home Care, den Werkdurchsatz und den Retail-Sell-in in Nordamerika und EMEA anhebt.

Beispielentitäten: Die Tabelle unten zeigt repräsentative Geschäftsobjekte und ihre Quellsysteme; das vollständige EDW umfasst zusätzliche Entitäten, Subtypen und Spezialtabellen (z. B. IoT-Sensorwerte, Instandhaltungsaufträge, Trade Promotions, CLM-Redlines) über alle 60 Bronze-Tabellen. In V2 ProductionBatch und CustomerOrder Domänenklassen treiben das MakeToShipToSell-Rückgrat.

OOP-Domänenmodell

PcEnterpriseSimulation reiht den Tag; Domänenobjekte besitzen die Emissionslogik.

MakeToShipToSell ist das primäre Prozess-Rückgrat. ProductionBatch.execute_lifecycle() führt Forecast → Procure → Produce → QC-Release → Fertigerzeugnisse; CustomerOrder.execute_lifecycle() führt OMS-Capture → WMS-Fulfill → OTM-Ship. PcPortfolio.publish_foundation() mastert SBUs, Marken, Werke, SKUs und Retail-Accounts, bevor Chargen und Aufträge laufen. Serviceobjekte (PlantOperations, CommercialProgram, FinanceAndCorporate) erzeugen unterstützende Corporate- und Marketing-Zeilen.

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-Wertschöpfungskette

Vom Markenportfolio über Plan, Make, Move, Sell und Corporate Close.

Beispielansicht: Dies zeigt die primäre Wertschöpfungskette über das P&C-Ökosystem; das vollständig erzeugte EDW umfasst alle 34 Quellsysteme mit funktionsübergreifenden Integrationen, IoT-Werktelemetrie und hier nicht gezeigten Trade-Marketing-Flüssen.

%%{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
          

Funktionale Organisation nach Abteilung

Globale Zentrale Cincinnati und direkt unterstellte Funktionen mit repräsentativen Quellsystemen.

Beispiel-Organisationsstruktur: Dies zeigt die primären Berichtslinien; die vollständige P&C-Organisation umfasst regionale SBU-Teams, Werksleiter und Shared-Services-Funktionen über alle 34 Vendor-Integrationen.

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-Reifestufen

Katalog stage gruppiert Tabellen von der Foundation bis Corporate.

Gezeigte Beispielaufschlüsselung: Dies ist ein repräsentativer Ausschnitt des vollständigen 60-Tabellen-Inventars über Reifestufen; die tatsächliche Verteilung spiegelt die vollständige Daten-Lineage von der Foundation bis zu den Corporate-Gold-Tabellen.

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
          

Zentrale Geschäftsobjekte

Logische Beziehungen und Ankerschlüssel. Marke (brand_code) und Werk (facility_code) bilden das Rückgrat; Materialnummern verbinden PIM mit MES.

Beispieldiagramm: Dieses Entity-Relationship-Diagramm zeigt das logische Kernmodell; das vollständig erzeugte EDW enthält 60 Bronze-Tabellen über 34 Vendor-Systeme mit zusätzlichen Detailtabellen und Lineage-Zweigen. Entitätsinstanzen tragen entity_refs auf jedem erzeugten Event für Joinability-Tests.

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
          

Quellsystemlandschaft

34 Vendor-Präfixe, 60 Bronze-Tabellen.

Gezeigte Beispielsysteme: Das Diagramm unten zeigt repräsentative Vendor-Systeme; der vollständig erzeugte Datensatz umfasst alle 34 Systeme mit ihrer vollständigen Tabellen-Lineage und den Integrationspunkten über History-Backfill und Live-Streams. Gemeinsame Quellsystem-Manifeste in kb/source_systems/ werden branchenübergreifend wiederverwendet — P&C ergänzt pc_brand als branchenspezifisches internes System.

Jede Tabelle folgt der {source_system_}__{entity} Namenskonvention (z. B. pc_brand__brand, siemens_mes__work_order), wobei die vendor-native Spaltenform und die Fremdschlüssel aus dem realen Exportschema jedes Produkts erhalten bleiben. VibeBI leitet Master-Data-Konformität ab, wenn Datensätze nach Silber und Gold gehoben werden.

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
          

Ende-zu-Ende-Datenfluss

V2-OOP-Sim → Bronze in ClickHouse; VibeBI-Semantik → Silber → Gold auf derselben Instanz.

OOP-Pfad: kb/industries/pnc/ definiert das Operations-Rückgrat und das Entitätsmodell; PcEnterpriseSimulation reiht Domänenlebenszyklen; SourceSystem Adapter exportieren vendor-native Zeilen in 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-Bronze-Zyklus

./live-v2-pnc — 60s-Tick über PcEnterpriseSimulation.generate().

Live-Frequenz: Jeder Tick führt die MakeToShipToSell-State-Machine aus — Domänenobjekte erzeugen korrelierte Forecast-, PO-, MES-, WMS-, OMS-, OTM- und GL-Zeilen pro Produktionscharge und Retail-Kundenauftrag; die Skalierung variiert pro Tick (Standardbasis 5). Backfillen Sie jede benötigte Historie (--days N im Live-Skript oder 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-Event-Graph

MakeToShipToSell-State-Machine — jeder Übergang ist eine Domänenmethode, die Vendor-Zeilen erzeugt.

Prozess-Rückgrat: Definiert in kb/industries/pnc/process_model.yaml. Ausnahmezustände (Batch-Ausschuss, Qualitätssperre, Teillieferung, Lieferantenverzug) zweigen von denselben Entitätslebenszyklen ab, statt als unabhängige Zufallsinserts.

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]
          

Bronze-Tabellenkategorien

Dieselbe Lineage-Hülle auf jeder Tabelle; die Kategorie steuert das Live-Verhalten.

Beispielkategorien: Alle 60 Bronze-Tabellen folgen diesem Drei-Kategorien-Muster (Snapshot, Transaktion, Event) mit konsistenter Metadaten- und Zustandsverfolgung; das Diagramm zeigt das Muster, das im gesamten Warehouse verwendet wird.

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