Search Results rel_type_code




Overview
Explore in AI Chat

Overview

APPS.CZ_SYSTEM_PROPERTY_RELS_V is a reporting view in the Oracle E-Business Suite configuration management schema (the CZ_ table family). It exposes a filtered subset of the type-relationship definitions stored in the base table CZ_TYPE_RELATIONSHIPS, returning only those rows whose REL_TYPE_CODE is one of 'SYS', 'JSY', or 'CAP' and whose DELETED_FLAG is '0'. In effect, the view publishes the set of active "system property" relationships, covering system-type relations (SYS), Java system relations (JSY), and capability relations (CAP) as defined by the configuration model.

Because the view is owned by APPS and filters out logically deleted rows, it is intended for read-only consumption by forms, concurrent programs, and integration or reporting logic that must reason about which type-to-type relationships are currently in effect. The rel_type_code column that users frequently search on is the discriminator that gives the view its purpose: it is the exact predicate used in the view definition to constrain the result set.

Underlying Base Objects

The view is defined over a single documented base object, referenced through a synonym in the APPS schema:

  • CZ_TYPE_RELATIONSHIPS (SYNONYM) — the authoritative table of type relationship records. Each row links a subject type to an object type with a relationship type code, and carries deletion and seeding indicators.

The view performs no joins; it is a projection over five data columns plus ROWID. The REL_TYPE_CODE IN ('SYS','JSY','CAP') predicate restricts the relationship category, and DELETED_FLAG = '0' restricts the result to non-deleted records. No synonym or public synonym for the view itself is listed in the documented metadata, so callers reference it as APPS.CZ_SYSTEM_PROPERTY_RELS_V.

Key Columns

  • REL_ID — the ROWID of the underlying CZ_TYPE_RELATIONSHIPS row, aliased as a surrogate identifier. Because it is a physical row identifier, it is stable for the life of the row but changes if the row is re-created or the table is reorganized.
  • SUBJECT_TYPE — the type on the "from" side of the relationship. Combined with OBJECT_TYPE, it defines the directed relationship edge.
  • OBJECT_TYPE — the type on the "to" side of the relationship.
  • REL_TYPE_CODE — the relationship category discriminator. Within this view it is always 'SYS', 'JSY', or 'CAP', which is the value most commonly used in filter predicates.
  • DELETED_FLAG — logical deletion indicator; always '0' in this view, retained for schema compatibility.
  • SEEDED_FLAG — indicates whether the relationship is seed (Oracle-delivered) data versus customer-defined data. This is the primary means of separating baseline configuration from custom extensions.

Common Use Cases and Queries

Typical uses include validating that a required type relationship exists before configuration data is loaded, reporting on seeded versus customer-defined system relationships, and driving UI or integration logic that must resolve type-to-type edges for system properties.

List all active system-property relationships:

SELECT rel_id, subject_type, object_type, rel_type_code, seeded_flag
FROM   apps.cz_system_property_rels_v
ORDER  BY rel_type_code, subject_type, object_type;

Isolate capability relationships only:

SELECT subject_type, object_type
FROM   apps.cz_system_property_rels_v
WHERE  rel_type_code = 'CAP';

Distinguish seed data from customer extensions:

SELECT rel_type_code, seeded_flag, COUNT(*)
FROM   apps.cz_system_property_rels_v
GROUP  BY rel_type_code, seeded_flag;

Verify a specific relationship edge:

SELECT COUNT(*)
FROM   apps.cz_system_property_rels_v
WHERE  subject_type = :p_subject
AND    object_type  = :p_object;

Queries should always filter or group on rel_type_code where the intent is category-specific, since the view aggregates three distinct relationship types into one result set.