Most master-data products keep master data alone and leave transactions to a warehouse.
| Layer | Holds | Examples | Owned by |
|---|---|---|---|
| Reference data | code lists that classify other data | countries, currencies, units, Incoterms, payment terms, tax codes | reference owners |
| Hierarchies | versioned trees with levels | product, customer, cost centre, plant, organisation | the owning functions |
| Dimensions | axes of analysis | time (calendars), version, scenario, channel, region | planning and finance |
| Master data | golden records with their cross-references | customers, suppliers, materials, sites, accounts, employees, assets | domain stewards |
| Transactions | events that refer to master data | sales orders, purchase orders, invoices, stock, receipts, forecasts, actuals | the systems of record, read in place or replicated |
Rows from any hierarchy level, time on the columns, measures from the transactions, one query.
Read the page →Open orders against a credit limit; parent revenue equals the sum of children; weights sum to 100%.
Read the page →From a customer or a cell to the orders behind it and to the source row in SAP.
Read the page →As of 31 March: the customer record and its orders as they stood together.
Read the page →The bed is a logical model with one query engine over it. Master data and reference data are governed views, materialised where latency needs it; transactions are read in place from the ERPs and lakes through the federated engine, or from the governed replica the Backbone keeps for a slow source. Every column states its freshness contract.
The keys are enforced at write time wherever Lima writes (golden records, hierarchies, reference data, data entry) and checked at read time for transactions read in place, where a broken key becomes a rule failure the steward sees.
It is a model with one engine over the sources and, where needed, your lake. It replaces the second copy a hub needs for analytics; it leaves your lake as the place for history at scale.
The row is readable and flagged: a rule failure names the missing customer or material, and the steward's queue shows it with the rows affected.
SAP and Oracle enforce keys inside one ERP. The bed enforces them across ERPs, the CRM, the lake and the golden records, with one cross-reference.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.
