Search Results okr_prop_resp_set_b




Overview
Explore in AI Chat

Overview

The OKR_PROP_RESP_SET_B table is a base table within the Oracle E-Business Suite OKR module — Contracts for Rights, a legacy product that Oracle has since marked as obsolete. As documented in the ETRM metadata, its stated purpose is to store the base records for a response value set. In the OKR functional model, "proposal response sets" define the permissible or expected responses available to respondents involved in a rights contract proposal workflow. The table therefore acts as the persistent storage layer beneath the response-set configuration and lookup functionality used by the Contracts for Rights application.

An important caveat accompanies this object: the ETRM documentation records it as "Not implemented in this database." This means the table appears in the data model definition and object inventory, but the corresponding physical segment may not exist in a given EBS instance, particularly in 12.1.1 or 12.2.2 environments where OKR is not licensed or installed. Any query development against this table should first confirm physical existence through ALL_TABLES before coding dependencies.

Regarding the heuristic Data Vault classification supplied in the metadata, this table is assessed as satellite-leaning. In Data Vault modeling terms, a satellite records descriptive attributes that change over time and attach to a parent hub or link. The presence of a single surrogate primary key alongside a foreign key to a type table is consistent with that assessment; it should be treated as a modeling suggestion rather than a definitive classification.

Key Information Stored

The documented metadata exposes a deliberately narrow column footprint. The primary structural elements are:

  • ID — the surrogate primary key, enforced by the OKR_PROP_RESP_SET_B_PK constraint. This column uniquely identifies each response value set row and is the anchor for relational joins.
  • IP_TYPE — a foreign key column referencing OKR_PROP_TYPES_B. This column associates each response set row with a proposal type, effectively categorizing the value set by the type of rights proposal or intellectual property classification it serves.

The metadata identifies no additional unique indexes beyond the primary key, so no formal business-key candidate is documented. In practice, a business user would typically distinguish rows by the combination of response set identifier and type, but because the ETRM extract does not enumerate a descriptive name or code column, such identifiers must be confirmed directly against the deployed schema. Redundant columns that commonly appear in EBS base tables — such as LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, and CREATED_BY — are standard conventions but are not enumerated in the supplied metadata and should not be assumed without inspection.

Common Use Cases and Queries

The principal use case is configuration reporting: determining which response value sets exist and how they map to proposal types. A representative query joins the base table to its parent type table:

  • SELECT rs.ID, rs.IP_TYPE, pt.NAME FROM OKR_PROP_RESP_SET_B rs, OKR_PROP_TYPES_B pt WHERE rs.IP_TYPE = pt.ID;
  • Existence verification: query ALL_TABLES and ALL_TAB_COLUMNS for OWNER and TABLE_NAME to confirm deployment before building reports.
  • Referential integrity auditing: identify orphaned rows where IP_TYPE has no matching record in OKR_PROP_TYPES_B.
  • Extensibility review: because OKR is obsolete, most organizations use these queries to inventory residual configuration ahead of migration or decommissioning, or to assess customizations layered on the OKR data model.

Related Objects

The documented foreign key relationship identifies OKR_PROP_TYPES_B as the primary related object, joined on OKR_PROP_RESP_SET_B.IP_TYPE = OKR_PROP_TYPES_B.ID. This parent table holds the proposal type definitions that qualify each response set. The PK constraint OKR_PROP_RESP_SET_B_PK governs uniqueness on ID. Additional dependent objects — such as response set line tables, translated (_TL) tables, and OKR public APIs — are likely to exist in a fully implemented OKR schema, but these are not enumerated in the supplied metadata and must be verified against the deployed dictionary before use.