Search Results cz_constraints_pk

Overview

CZ_CONSTRAINTS is the master definition table for the Oracle Configurator within the Bills of Material (BOM) product family of Oracle E-Business Suite. It stores the header-level records for configurator constraints — the logical rules that govern which option combinations are valid when a user configures a model, kit, or pick-to-order item through the Oracle Configurator runtime. Each row represents one named constraint that may be attached to a configuration model and evaluated during the configuration session to accept or reject user selections.

The table is documented as "Not implemented in this database" in the supplied ETRM metadata, which reflects that the Oracle Configurator schema (the CZ schema) is only created when the Configurator product is licensed and installed. In environments where Configurator is not deployed, CZ_CONSTRAINTS does not physically exist, and any query against it returns an invalid-object error rather than an empty result set.

From a Data Vault modelling perspective, the mined foreign-key structure classifies CZ_CONSTRAINTS as hub-leaning. This heuristic reflects that the table is referenced by dependent tables through its own primary key, so it behaves as a central business entity whose identity is stable while descriptive and rule detail is carried in child tables.

Key Information Stored

The documented structure identifies the following elements:

• CONSTRAINT_ID — the surrogate primary key, defined by the unique index CZ_CONSTRAINTS_PK. Every constraint receives a system-generated numeric identifier that is used by all dependent tables for referential linkage.
• Constraint header attributes — the descriptive columns that name and classify a constraint, including the constraint name and the constraint type (such as logical, numerical, or compatibility rules) maintained by the Configurator UI.
• Owner/model association columns — attributes that bind the constraint to the owning configuration model or inventory item, determining the scope in which the rule is evaluated.
• Status and version indicators — lifecycle flags that indicate whether the constraint is active, complete, or still under definition.
• Audit columns — the standard EBS WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) that support change tracking.
• Rule body reference — the logical expression of the constraint itself is not held on the header row; it is decomposed into clause and assignment rows in the child tables, with CONSTRAINT_ID acting as the shared join key.

No alternate unique index or natural business key is documented in the metadata beyond CONSTRAINT_ID, so CONSTRAINT_ID should be treated as the authoritative identifier for joins and for any extraction into an analytical model.

Common Use Cases and Queries

The most frequent scenario is auditing which constraints are defined for a given configuration model, and confirming that every constraint has at least one clause and at least one assignment. A standard header lookup is:

• SELECT constraint_id, constraint_name FROM cz_constraints WHERE constraint_name LIKE :pattern;
• SELECT c.constraint_id, c.constraint_name FROM cz_constraints c WHERE NOT EXISTS (SELECT 1 FROM cz_constraint_clauses cl WHERE cl.constraint_id = c.constraint_id);
• SELECT c.constraint_id, COUNT(cl.constraint_id) AS clause_count FROM cz_constraints c, cz_constraint_clauses cl WHERE cl.constraint_id = c.constraint_id GROUP BY c.constraint_id;
• Orphan detection: SELECT a.constraint_id FROM cz_constraint_assignments a WHERE NOT EXISTS (SELECT 1 FROM cz_constraints c WHERE c.constraint_id = a.constraint_id);

Reporting use cases include impact analysis before deleting or modifying a model, migration checks when copying configuration definitions between environments, and diagnostics when the Configurator runtime reports a constraint that fires unexpectedly. Because the runtime resolves rules from the child tables, a complete picture requires joining CZ_CONSTRAINTS to both CZ_CONSTRAINT_CLAUSES and CZ_CONSTRAINT_ASSIGNMENTS.

Related Objects

The documented foreign-key relationships establish CZ_CONSTRAINTS as the parent of two dependent tables, and additional Configurator objects reference the same key indirectly:

• CZ_CONSTRAINT_ASSIGNMENTS — joined on CONSTRAINT_ID; records where a constraint applies within the model structure.
• CZ_CONSTRAINT_CLAUSES — joined on CONSTRAINT_ID; holds the individual clauses that build the constraint expression.
• CZ_CONSTRAINT_CLAUSE_USAGES — the assignment of clause variables and nodes used when evaluating a clause.
• CZ_MODEL_NODES and CZ_PS_NODES — the model and option node hierarchy against which assignments are resolved.
• CZ_CONFIG_HDRS and CZ_CONFIG_DETAILS — the runtime configuration session and its saved selections, which are validated against the constraint definitions.
• CZ_UI_DEFINITIONS — presentation definitions that determine how constrained options are displayed to the user.

No Configurator PL/SQL API is documented in the supplied metadata for loading or maintaining this table; changes are normally made through the Oracle Configurator administrative UI rather than direct DML, and direct inserts risk violating the referential integrity enforced by the two dependent child tables.