Keep a business identifier in the fact when it has no attributes

An order number groups several lines but often has no descriptive attributes for a separate dimension. A key-only table adds a join without meaning.

This business key is a degenerate dimension stored directly on the fact.

Do not confuse it with the fact surrogate key

A surrogate identifies one fact row; an order number identifies a business transaction. The same order number can exist in several source systems.

Retain source scope and original formatting, with a normalized matching key if needed.

It supports drill-through, order grouping, distinct order count, lines per order, and reconciliation across facts.

Name order count, line count, and customer order frequency separately instead of treating the identifier as a measure.

Channel, shipping address, whole-order status, or discount may justify an order-header fact or dimension depending on grain and change behavior.

Avoid copying header amounts to every line and summing them repeatedly.

Reconcile line amount, distinct orders, partial returns, split orders, duplicate source numbers, and header attributes.

BuildTable can support grain and key definition; recognition, uniqueness tests, and generated query behavior need POC verification.