Home · Sep 20, 2026

Composite Uniqueness for Commerce Entity Records

By iKawn Team / / 2 min read
Business team in a neutral office meeting with laptops and performance charts
iKawn viewBuilt for teams, not dashboards alone.
Updated

Quick answer

Composite uniqueness prevents duplicate commerce records within a defined combination of merchant, source, and entity identifiers.

Share:

Definition

A composite uniqueness constraint requires a combination of field values to be unique across stored rows. For commerce ingestion, the combination might be merchant ID, source system, and source order ID. Each individual value can recur, while the full combination identifies at most one record under the database constraint rules.

Why It Matters

  • Different merchants can legitimately use the same order number. Enforcing uniqueness on that number alone can reject valid orders or encourage incorrect merges.
  • A Commerce Intelligence OS needs an explicit entity scope so operational history and reported revenue are attached to the correct merchant and source.

How It Works

  1. Define the entity level and identifier namespace. Decide whether the record represents an order, line, shipment, or version before selecting the key fields.
  2. Require complete key values where identity depends on them. Document case, whitespace, and null treatment; database null behavior must not be assumed to match business identity rules.
  3. Enforce the combination in storage, not only through a check-before-insert query that can race with another writer. Classify conflicts as replay, conflicting content, or a modeling error.
  4. Reconcile existing duplicates before adding a constraint. Decide separately whether a new payload is a permitted update and preserve source version evidence for that decision.

Ecommerce Example

Context: Illustrative example: merchant A and merchant B both import order 104 from the same storefront platform.

Recommended move: The two merchant-and-source-and-order combinations remain distinct. A second import of merchant A order 104 reaches the existing identity instead of creating another order row.

Why it matters: If its amount differs, the unique key alone cannot decide whether to update or investigate. This is a proposed data-design example, not a claim about the current iKawn database.

iKawn Framework

Scope

The iKawn ontology framework names each merchant, source, and entity boundary.

Constrain

Prevent duplicate identities at the chosen record grain.

Classify

Distinguish repeat delivery from conflicting facts.

Reconcile

Resolve conflicts with source history before downstream action.

Concise Summary

Composite uniqueness enforces identity within a defined scope. It prevents duplicate keys, while version rules and reconciliation determine how conflicting content should be handled.

Related iKawn Pages

Frequently Asked Questions

No. Uniqueness limits duplicate keys; referential integrity validates relationships to referenced records.
No. A crosswalk maps identities across systems; uniqueness governs duplicates within the chosen key scope.
Do not assume so. Database behavior and constraint options vary; required identity fields often need non-null rules.
No. External effects and multi-step operations need their own replay and completion handling.
Book a decision audit