Search Results cz_type_relationships_u2




Overview

CZ.CZ_TYPE_RELATIONSHIPS is a configuration management table within the Oracle E-Business Suite (EBS) Configurator (CZ) schema. It stores the semantic relationships between configurator data types, which are themselves defined in CZ_SIGNATURES. The table captures three principal relationship classes: subtype equivalency and implicit conversion, parent/child inclusion hierarchies, and the intrinsic association of system properties to node types. In effect, it is the metadata layer that tells the Configurator engine how one type may be treated as, contained within, or annotated by another type during model compilation and runtime validation.

The object is owned by the CZ schema, resides in the APPS_TS_SEED tablespace, and is present in both EBS 12.1.1 and 12.2.2. From a Data Vault modeling perspective, the heuristic classification of this object is standalone — it is not a dependent satellite or a transactional link. Rather, it behaves as a reference or relationship structure keyed on its own composite business identifiers, which aligns with its role as an ETRM (E-Business Tables Reference Model) seed/reference entity.

Key Information Stored

The table comprises eleven documented columns. Its most important columns are:

  • SUBJECT_TYPE — the parent or originating data type in the relationship.
  • OBJECT_TYPE — the child, target, or related data type.
  • REL_TYPE_CODE — the discriminator that classifies the relationship: 'CNV' for implicit data type conversion, 'SYS' for intrinsic association of a system property to a node type, and 'CHL' where the object type is an allowable child or member of the subject type.
  • SEEDED_FLAG'1' indicates the relationship is a seeded (out-of-the-box) entry rather than user-defined.
  • DELETED_FLAG — indicates logical deletion.
  • ZD_EDITION_NAME — Edition-Based Redefinition (EBR) column introduced in 12.2 to support online patching.
  • Audit columns: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.

The surrogate primary key is CZ_TYPE_RELATIONSHIPS_PK on (SUBJECT_TYPE, REL_TYPE_CODE, OBJECT_TYPE). Business-key candidates are captured by the unique indexes CZ_TYPE_RELATIONSHIPS_U1 on (DELETED_FLAG, REL_TYPE_CODE, OBJECT_TYPE, SUBJECT_TYPE, ZD_EDITION_NAME) and CZ_TYPE_RELATIONSHIPS_U2 on (REL_TYPE_CODE, DELETED_FLAG, SUBJECT_TYPE, OBJECT_TYPE, ZD_EDITION_NAME).

Common Use Cases and Queries

Typical use cases include diagnosing why a configurator model permits or rejects a particular child type, tracing implicit conversion paths between types, and auditing seeded versus customer-defined relationships after an upgrade or patch.

A sample query to list all seeded child relationships for a given subject type:

SELECT subject_type
     , object_type
     , rel_type_code
  FROM cz.cz_type_relationships
 WHERE rel_type_code = 'CHL'
   AND seeded_flag   = '1'
   AND deleted_flag  = '0'
   AND subject_type  = :p_subject_type;

A second pattern enumerates conversion relationships, useful when validating data type interchangeability:

SELECT s.name AS subject_name, o.name AS object_name
  FROM cz.cz_type_relationships r
     , cz.cz_signatures s
     , cz.cz_signatures o
 WHERE r.rel_type_code = 'CNV'
   AND r.subject_type  = s.type_id
   AND r.object_type   = o.type_id
   AND r.deleted_flag  = '0';

Because the table includes ZD_EDITION_NAME, reporting queries in 12.2 should filter to the active edition to avoid duplicate rows across EBR editions.

Related Objects

The most significant objects related to CZ.CZ_TYPE_RELATIONSHIPS are:

  • CZ.CZ_SIGNATURES — defines the data types referenced by SUBJECT_TYPE and OBJECT_TYPE; joined on the type identifier columns.
  • CZ.CZ_TYPE_RELATIONSHIPS_PK — the primary unique index enforcing (SUBJECT_TYPE, REL_TYPE_CODE, OBJECT_TYPE).
  • CZ.CZ_TYPE_RELATIONSHIPS_U1 and CZ_TYPE_RELATIONSHIPS_U2 — alternate unique indexes supporting business-key lookups.
  • CZ.CZ_PROPERTIES — system properties attached through REL_TYPE_CODE = 'SYS'.
  • CZ.CZ_NODES — node types whose parent/child inclusion is governed by 'CHL' rows.
  • Configurator runtime and model validation APIs that consume these relationships to enforce type constraints.