Domain catalogue Products on Snowflake

Bill of materials on Snowflake

One governed structure per product per plant: components, quantities, effectivity, alternates and phantoms, consistent with the golden materials.

SOURCES, READ IN PLACESnowflakelakehouseASSEMBLED1 · standardise2 · match on the domain keys3 · survive field by field4 · place in the hierarchies5 · run the column and row rules6 · publish the golden viewGOLDEN BILL OF MATERIALSBill of materialsone id · every source key keptREAD BYGrids, pivots and drill-downswith the transactionsAPIs, SQL and agentsone policyWrite-back to the systemsacknowledged
The objects the domain reads in place on Snowflake, the assembly steps, and who reads the result. Writes go through MERGE into a governed schema.
2
objects read in place from Snowflake
catalogue
4
attribute groups assembled
catalogue
5 days
to production-grade
estimate
1
write path, acknowledged and logged
catalogue
0
rows copied to start
product
What the domain reads

The Snowflake objects behind the golden record

Tables are read in place through the Snowflake connector with filters and aggregates pushed down; nothing is copied out.

ObjectRead fromFields the domain usesFreshness
BOM headerCONFORMED.BOMbom_id · material_key · plant · usage · alternative · base_qty · statusas fresh as the landing pipeline; live for governed tables
BOM componentCONFORMED.BOM_COMPONENTbom_id · position · component_key · quantity · uom · valid_from · valid_to · phantomas fresh as the landing pipeline; live for governed tables
The keys

How bill of materials records match, in this system's fields

parent item + plant + usage + alternativecomponent item + positionchange number

The first object above carries the strong keys; the standardised attributes come from the same rows. Components resolve to golden materials first, so every component points at the golden item.

What is written back

Through the interfaces Snowflake supports

Golden records and their history are written with MERGE into a governed schema, so the warehouse always carries the current keys.

InterfaceUsed forResult
MERGE INTO GOLDEN.BOM on the golden key; history in GOLDEN.BOM_HISTORYgolden values approved for write-back: header; components; effectivitythe id or error Snowflake returns, stored beside the change

Write-back is off per object until a test write succeeds, and approval rules can require a person per object. Reconciliation compares the source row with the golden value on a schedule.

Access and prerequisites

What is in place before the first build

Snowflake roles and row access policies are honoured; Lima adds its own layers on top.

Register the objects2 objects from the connector catalogue; each shows its rows at once.
Nearby

This domain on other systems, and other domains on Snowflake

Bill of materials on

Other domains on Snowflake

Terms on this page

EffectivityThe date or serial range from which a component belongs to the structure.
PhantomAn assembly that exists in the design and is passed through in production; its components explode straight through.
Read in placeThe rows stay in Snowflake; Lima sends the filter and the columns and Snowflake returns the matching rows.
Questions

Does this domain copy data out of Snowflake?

The golden record reads the objects above in place. History the pivot needs at scale is landed in your lake by the Backbone, under the same keys, security and audit.

What does the Snowflake team need to do?

Grant the read access and the write interfaces listed above and agree the refresh method. Nothing is installed in Snowflake.

Can we start with reads only?

Yes. Write-back stays off per object until a test write succeeds; the golden view, the API and the pivots work from day one on reads.

See your first domain built on your data

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.