Search Results cz_conversion_rels_v




Overview
Explore in AI Chat

Overview

CZ_CONVERSION_RELS_V is a read-only database view owned by the APPS schema within the Oracle E-Business Suite Configurator (CZ) product module. It presents a filtered, denormalized projection of conversion-type relationships defined in the Configurator data model. The view exposes only active relationships flagged as conversions, specifically those whose relationship type code equals 'CNV' and whose deletion indicator is '0'. Because Configurator relies on a metadata-driven model to describe how configurable items, models, and their associated structures interrelate, this view serves as a stable, purpose-built interface for reporting, integration, and diagnostic queries that must retrieve conversion relationships without being polluted by logically deleted or non-conversion records.

The object is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2. Its principal value is abstraction: consumers query a narrow, pre-filtered result set rather than the broader base relationship table, reducing the risk of returning irrelevant relationship types and simplifying application logic. Note, however, that REL_ID is exposed as the physical ROWID of the underlying row rather than a surrogate key, a characteristic that constrains the view's stability under table reorganization.

Underlying Base Objects

The view is defined over a single documented base object, CZ_TYPE_RELATIONSHIPS, accessed through a synonym in the APPS schema. The defining query applies two predicates to that table:

  • REL_TYPE_CODE = 'CNV' — restricts output to conversion relationships, excluding other relationship categories maintained in the same table.
  • DELETED_FLAG = '0' — excludes rows that have been logically deleted, since Configurator generally performs soft deletes rather than physical removal.

Consequently, the view is not an independent data store; it inherits the referential and transactional behavior of CZ_TYPE_RELATIONSHIPS. Any commit affecting conversion relationships in the base table is immediately visible through the view, subject to the standard read-consistency semantics of the querying session. Because the relationship is one-to-one between qualifying base rows and view rows, no aggregation, union, or join is performed.

Key Columns

  • REL_ID — Derived from ROWID, uniquely identifies each qualifying relationship row within the base table. It should be treated as a physical locator, not a durable business key.
  • SUBJECT_TYPE — Identifies the entity type occupying the subject (source) side of the relationship; used to interpret what the relationship originates from.
  • OBJECT_TYPE — Identifies the entity type occupying the object (target) side of the relationship; together with SUBJECT_TYPE it defines the conversion pairing.
  • REL_TYPE_CODE — Always 'CNV' in this view by construction, but retained as a column for consistency with the base table and for use in self-documenting queries.
  • DELETED_FLAG — Always '0' in this view; retained to signal that only active rows are present.
  • SEEDED_FLAG — Distinguishes Oracle-seeded (delivered) relationships from customer-created ones, which is important when assessing whether a relationship may be safely modified during upgrades.

Common Use Cases and Queries

The view is typically used in diagnostic and integration contexts: validating that expected conversion relationships exist between model structures, auditing seeded versus custom relationships prior to patching or upgrade, and powering reports on configurator conversion metadata without exposing soft-deleted rows.

A representative query lists all active conversion relationships and their endpoint types:

  • SELECT subject_type, object_type, seeded_flag FROM apps.cz_conversion_rels_v ORDER BY subject_type, object_type;

To isolate customer-defined relationships, which are the most common candidates for impact analysis:

  • SELECT rel_id, subject_type, object_type FROM apps.cz_conversion_rels_v WHERE seeded_flag = 'N';

Because REL_ID is a ROWID, queries joining this view to tables keyed on business identifiers should resolve the relationship using SUBJECT_TYPE, OBJECT_TYPE, and REL_TYPE_CODE rather than REL_ID. Additionally, since the view depends on CZ_TYPE_RELATIONSHIPS remaining intact, any maintenance or reorganization of that base table can invalidate stored REL_ID values derived from the view.