Search Results cz_type_relationships




Overview
Explore in AI Chat

Overview

CZ_TYPE_RELATIONSHIPS is a Configurator (CZ) module table in the Oracle E-Business Suite 12.1.1 and 12.2.2 environments, owned by the CZ schema. It records the relationships that exist between configuration model types and the properties associated with those relationships. In the Configurator data model, this table functions as the store for typed links — pairs of subject and object types joined by a relationship type code — that describe how one configuration entity relates to another during model definition and validation.

The ETRM metadata marks this object with a heuristic Data Vault classification of standalone. This is a modeling suggestion arising from the absence of inbound or outbound foreign keys mined from the physical schema, rather than a statement about business semantics. Analysts modeling CZ_TYPE_RELATIONSHIPS into a dimensional or Data Vault warehouse should therefore treat the classification cautiously: the table is self-contained at the database level, but its columns reference configuration type identifiers that logically belong to the broader Configurator type framework.

Key Information Stored

Of the eleven documented columns, the business-critical content is concentrated in three type-related attributes plus a small set of audit and state flags.

  • SUBJECT_TYPE — the source type in the relationship; the "from" side of the typed link.
  • REL_TYPE_CODE — the code identifying the nature of the relationship between subject and object.
  • OBJECT_TYPE — the target type; the "to" side of the link.
  • ZD_EDITION_NAME — the edition designation used by Oracle's edition-based redefinition, allowing multiple editions of configuration metadata to coexist.
  • SEEDED_FLAG — indicates whether the row was shipped as Oracle seed data or created by a user.
  • DELETED_FLAG — soft-delete indicator; rows are logically removed rather than physically purged.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns recording row provenance.

No surrogate single-column key exists. The primary key, CZ_TYPE_RELATIONSHIPS_PK, is composite over (SUBJECT_TYPE, REL_TYPE_CODE, OBJECT_TYPE). Two additional unique indexes qualify as business-key candidates: 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). The data vault note that the documented PK also includes ZD_EDITION_NAME reflects 12.2.2 editioning behavior.

Common Use Cases and Queries

Configurator implementers query this table to enumerate which type relationships exist in a model, to validate that a proposed relationship is legal, and to report on user-defined versus seeded metadata. A typical lookup for a given relationship code is:

SELECT subject_type, rel_type_code, object_type
FROM cz.cz_type_relationships
WHERE rel_type_code = :rel_type_code
AND deleted_flag = 'N';

Because soft deletes are used, every production query should filter on DELETED_FLAG. When joining to related type tables, restrict the edition with ZD_EDITION_NAME to avoid duplicate rows across editions. Reporting use cases include impact analysis before deleting a relationship, and auditing the ratio of seeded to user-defined relationships via SEEDED_FLAG.

Related Objects

The metadata records no foreign keys, so the following relationships are logical rather than enforced at the database level. Most significant are the Configurator type definition tables that supply the SUBJECT_TYPE and OBJECT_TYPE values, the relationship type lookup that supplies REL_TYPE_CODE, and the standard EBS FND audit tables referenced by CREATED_BY and LAST_UPDATED_BY. Configurator runtime and model-generation APIs consume these relationship rows when resolving valid structure for a given model. Because the object is classified standalone, join columns must be inferred from the CZ type framework rather than taken from documented constraints; any integration should confirm the corresponding type identifier columns in the target CZ objects before assuming referential integrity.