Search Results cz_imp_tmp_itemcat_pk




Overview

The CZ.CZ_IMP_TMP_ITEMCAT object is a transient staging table within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environment, residing in the CZ schema. Its name, containing the token IMP_TMP, indicates its purpose as an import temporary structure used during item catalog data conversion, migration, or bulk load operations. The table acts as an intermediate holding area between an external data source and the final application tables, allowing validation, de-duplication, and controlled transfer into the operational model before data becomes permanent.

The object is owned by the CZ schema but is exposed to the APPS layer through the synonym APPS.CZ_IMP_TMP_ITEMCAT, the documented reverse dependency. Physically it is stored in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10. From a Data Vault modeling perspective, the heuristic classification for this object is standalone, meaning it does not function as a hub, link, or satellite in a conformed model. It is best regarded as a keyed staging container whose two columns together form the business transaction key for a single import run.

Key Information Stored

The documented physical schema is intentionally minimal, consisting of only two columns. Both participate in the unique primary key, so there is no separate surrogate key distinct from the business key.

  • RUN_ID (NUMBER) — Identifies the specific import or conversion run that populated the row. This column is the primary grouping and partitioning attribute, enabling multiple concurrent or sequential loads to share the table without collision.
  • ITEM_CATALOG_GROUP_ID (NUMBER) — Identifies the item catalog group being staged for that run. In EBS this corresponds to a catalog group definition used to organize items into hierarchies or category sets.
  • CZ_IMP_TMP_ITEMCAT_PK (UNIQUE, NORMAL, APPS_TS_TX_DATA) — The primary key, defined over (RUN_ID, ITEM_CATALOG_GROUP_ID). This is the documented business-key candidate; no non-key columns exist.

Because the table carries no descriptive or attribute columns beyond the key pair, it serves purely as a control or relationship register: for a given run, which item catalog groups were touched. Any richer data would be sourced from companion staging tables keyed by the same RUN_ID.

Common Use Cases and Queries

Typical usage centers on run-scoped diagnostics and reconciliation of item catalog imports. A technician verifies which catalog groups were processed in a run, detects duplicate or overlapping groups across runs, and confirms completion before promoting data downstream.

  • List groups for a run: SELECT ITEM_CATALOG_GROUP_ID FROM CZ.CZ_IMP_TMP_ITEMCAT WHERE RUN_ID = :run_id;
  • Detect overlapping groups between runs by joining the table to itself on ITEM_CATALOG_GROUP_ID where RUN_ID differs.
  • Validate the primary key by grouping on both columns and filtering for counts greater than one.
  • Reconcile staged groups against the live catalog group definition tables joined on ITEM_CATALOG_GROUP_ID.
  • Purge transient rows after a successful load with a delete scoped by RUN_ID.

The minimal column list makes queries fast, as the primary key index alone can satisfy most retrievals without a table access.

Related Objects

Documented relationships are narrow. The table references no other database object, and its only documented reverse dependency is the APPS synonym.

  • APPS.CZ_IMP_TMP_ITEMCAT — synonym providing the APPS-layer entry point to the CZ table.
  • Companion CZ import temporary tables sharing the RUN_ID key, joined on RUN_ID to correlate staged item data with the catalog groups.
  • Item catalog group definition tables, joined on ITEM_CATALOG_GROUP_ID, to resolve groups to their descriptions.
  • Item catalog (functional catalog) tables, joined on ITEM_CATALOG_GROUP_ID, for final promotion of catalog membership.
  • Source staging or interface tables supplying rows into this structure, linked by the run identifier.

Because the metadata records no outbound foreign keys, joins to functional EBS catalog tables must be established through the ITEM_CATALOG_GROUP_ID business value rather than declared constraints.