Search Results subtype_description

Overview

CZ_DATA_SUBTYPES_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, registered with a VALID status in both the 12.1.1 and 12.2.2 releases. It belongs to the CZ – Configurator product family, which supplies the modeling engine used by Oracle Configurator and related configuration-driven order capture flows. The view exposes the relationship between a supertype signature and its subtype signature, filtered specifically to conversion relationships (REL_TYPE_CODE = 'CNV'). In practical terms, it provides a denormalized, read-only projection of the CZ_SIGNATURES and CZ_TYPE_RELATIONSHIPS data, joining signature metadata for both ends of the relationship alongside the relationship-level audit columns.

Because the base Configurator tables store signatures and their type relationships in separate, normalized structures, this view serves as a convenient reporting surface for administrators, integrators, and support analysts who need to inspect how data types are linked without writing the multi-table join manually. The presence of the REL_LAST_UPDATE_DATE and related audit columns makes the view particularly relevant to users searching for "rel_last_update_date," as it exposes the last-update timestamp of the underlying conversion relationship record.

Underlying Base Objects

The view is defined over two referenced base objects, both exposed through synonyms in the APPS schema:

• CZ_SIGNATURES (SYNONYM) — the source of signature definitions. It is joined twice: once as SUBSIG for the supertype (SUBJECT_TYPE = SUBSIG.SIGNATURE_ID) and once as OBJSIG for the subtype (OBJECT_TYPE = OBJSIG.SIGNATURE_ID). The join to SUBSIG is further restricted by DELETED_FLAG = '0', ensuring logically deleted supertypes are excluded.
• CZ_TYPE_RELATIONSHIPS (SYNONYM) — aliased as TYPREL, this table supplies the REL_TYPE_CODE, relationship audit columns, and seeded flag. The view filters this source to REL_TYPE_CODE = 'CNV', returning only conversion-type relationships.

The join is an inner join across all three aliases, so a row is returned only when a conversion relationship exists between two valid, non-deleted signatures. This design means the view is inherently a subset of the full type-relationship catalog.

Key Columns

• SUPERTYPE_ID / SUPERTYPE_NAME — identifier and name of the subject (supertype) signature.
• SUBTYPE_ID / SUBTYPE_NAME — identifier and name of the object (subtype) signature.
• SUPERTYPE_SIG_TYPE, SUPERTYPE_JAVA_DATA_TYPE, SUPERTYPE_DESCRIPTION, SUPERTYPE_SEEDED_FLAG — metadata describing the supertype signature, including its signature type, Java data type mapping, description, and whether Oracle seeded it.
• SUBTYPE_SIG_TYPE, SUBTYPE_JAVA_DATA_TYPE, SUBTYPE_DESCRIPTION, SUBTYPE_SEEDED_FLAG — the equivalent metadata set for the subtype signature.
• REL_TYPE_CODE — the relationship type; always 'CNV' given the view's filter.
• REL_SEEDED_FLAG — indicates whether the underlying relationship was seeded by Oracle or created by a user.
• REL_LAST_UPDATED_BY, REL_LAST_UPDATE_DATE, REL_CREATION_DATE, REL_CREATED_BY, REL_LAST_UPDATE_LOGIN — the standard EBS audit columns derived from CZ_TYPE_RELATIONSHIPS. REL_LAST_UPDATE_DATE is the timestamp that most users search for, and it reflects when the relationship record itself was last modified, not the signature records.

Common Use Cases and Queries

Typical scenarios include auditing conversion relationship changes, troubleshooting Configurator type mapping, and driving integration extracts. A common query retrieves relationships changed after a given date:

• SELECT supertype_name, subtype_name, rel_last_update_date, rel_last_updated_by FROM cz_data_subtypes_v WHERE rel_last_update_date >= :since ORDER BY rel_last_update_date DESC;

To isolate user-defined versus seeded relationships, filter on REL_SEEDED_FLAG. To inspect Java type mappings for a specific conversion path, select the SUPERTYPE_JAVA_DATA_TYPE and SUBTYPE_JAVA_DATA_TYPE columns for the relevant signature pair. Because the view confines itself to REL_TYPE_CODE = 'CNV', queries seeking other relationship types must access CZ_TYPE_RELATIONSHIPS directly. All queries should be issued against the APPS schema or a synonym granted appropriate read privileges.