Search Results okr_ip_ctrct_rels_pk

Overview

The OKR_IP_CTRCT_RELS table belongs to the Oracle E-Business Suite product family OKR — Contracts for Rights, a module historically used to manage intellectual property (IP) contracts, royalty agreements, and rights-related licensing arrangements. In Oracle EBS 12.1.1 and 12.2.2, the OKR product line is classified as obsolete, meaning Oracle no longer actively develops or supports the module, and the underlying schema objects are retained only for backward compatibility, historical data access, or migration reference. The ETRM metadata explicitly notes: "Not implemented in this database." This indicates that the table exists as a documented schema definition but is not populated or deployed in the target environment.

The logical naming convention — OKR_IP_CTRCT_RELS — suggests it stored IP Contract Relationships, capturing associations or linkages between intellectual property contract records and related entities (parties, rights, or related contracts). From a heuristic Data Vault modeling perspective, the metadata classifies this object as standalone, which maps most naturally to a hub or, given its relationship-oriented naming, potentially a link construct. Because no foreign keys are documented, a standalone hub classification is the safest modeling suggestion, keyed on the surrogate ID.

Key Information Stored

The metadata for this table is minimal. Only the primary key structure is documented:

• ID — The surrogate primary key column, defined by constraint OKR_IP_CTRCT_RELS_PK. This is the only column explicitly identified in the ETRM documentation.

The primary key is documented as OKR_IP_CTRCT_RELS_PK (ID), confirming that ID is the single-column surrogate key. No unique business-key index or alternate key is documented in the available metadata, so no verified business-key candidates can be named. Because the table is not implemented and no column list beyond ID is provided, the remaining columns (which would, in a typical OKR relationship table, include foreign-key pointers to parent IP contracts, party identifiers, relationship type codes, and audit/WHO columns such as CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY) cannot be confirmed from the supplied documentation and should be verified against the actual database dictionary if the object is present.

Common Use Cases and Queries

Because the table is flagged as not implemented, its realistic uses are limited to script inspection, lineage documentation, and schema auditing rather than live reporting. Typical investigative queries include checking whether the object exists in ALL_TABLES and whether it holds rows:

• Existence check: SELECT table_name, num_rows, last_analyzed FROM all_tables WHERE table_name = 'OKR_IP_CTRCT_RELS';
• Constraint review: SELECT constraint_name, constraint_type, column_name FROM all_cons_columns WHERE table_name = 'OKR_IP_CTRCT_RELS';
• Relationship reconstruction: Where the table is deployed, joins would typically resolve an ID to a parent IP contract or party, reconstructing licensing relationships for royalty or rights reporting.

For environments still running legacy OKR functionality, the table may have supported reconciliation of which rights were associated with which contracts — a scenario relevant to royalty disbursement auditing and IP portfolio reporting. In modern 12.2.2 deployments, such reporting is generally superseded by successor modules.

Related Objects

The ETRM metadata provides no foreign key relationships, and the object is classified as standalone. Consequently, the following related objects are inferred from the OKR naming domain rather than documented:

• OKR_IP_CTRCT_RELS_PK — the primary key constraint on ID.
• Other OKR_* contract and rights tables (e.g., IP contract headers/lines) that would conventionally join via a contract identifier.
• Standard EBS WHO/audit columns and reference objects.

Given the standalone classification and the "not implemented" status, integrators should treat any dependency assumptions as unverified and confirm relationships directly against the target EBS schema before use.