Search Results okr_ip_combinations_pk

Overview

OKR_IP_COMBINATIONS is a table within the Oracle E-Business Suite module OKR (Contracts for Rights), which is designated as obsolete in current Oracle EBS releases, including 12.1.1 and 12.2.2. The module historically supported intellectual property and rights management contracts, and this table served as the intersection entity linking individual intellectual property records to combination groupings. Organizations migrating, archiving, or auditing legacy Contracts for Rights data may still encounter references to this object in custom code, historical extracts, or upgrade scripts, despite the module no longer being actively implemented.

The ETRM metadata explicitly states "Not implemented in this database," indicating that in a standard Oracle EBS 12.1.1 or 12.2.2 environment the table is not physically present or populated. It exists in the data model lineage primarily as documentation of the former OKR schema. Under a heuristic Data Vault classification mined from its foreign key structure, OKR_IP_COMBINATIONS is modeled as a link table. This classification is a modeling suggestion: the table resolves a many-to-many relationship between two parent entities and contains no descriptive satellite attributes of its own.

Key Information Stored

The documented column set is deliberately narrow, reflecting the table's role as a pure intersection entity. The most important columns are:

• IP_ID — Foreign key to OKR_IP_COMMON_B, identifying the intellectual property record participating in the combination.
• CBN_ID — Foreign key to OKR_COMBINATIONS_B, identifying the combination grouping to which the intellectual property belongs.

The primary key OKR_IP_COMBINATIONS_PK is a composite surrogate key defined over (IP_ID, CBN_ID). Because both columns are also foreign keys, this composite key simultaneously enforces the uniqueness of each intellectual-property-to-combination pairing and guarantees referential integrity to both parent tables. No additional business-key candidate columns are documented; the pairing of IP_ID and CBN_ID effectively serves as the business key, since its uniqueness is what gives the row meaning. There are no documented descriptive, date-stamped, or audit columns in the metadata excerpt provided.

Common Use Cases and Queries

Because the module is obsolete, the practical use cases center on legacy data reconciliation, migration validation, and archival reporting rather than active transactional processing. A typical query resolves the many-to-many relationship to list every intellectual property attached to a given combination:

• Combination membership listing — join OKR_IP_COMBINATIONS to OKR_COMBINATIONS_B on CBN_ID to enumerate all IP records in a named combination.
• IP-centric lookup — join to OKR_IP_COMMON_B on IP_ID to retrieve all combinations containing a specific intellectual property, useful when decommissioning or reassigning rights.
• Orphan and integrity audits — anti-joins against either parent table detect dangling references before migration, for example rows whose IP_ID no longer resolves in OKR_IP_COMMON_B.
• Cardinality analysis — grouping and counting by IP_ID or CBN_ID reveals whether any combination aggregates multiple IP records, validating that the historical design behaved as an intersection entity.

Representative SQL follows the pattern: SELECT c.cbn_id, i.ip_id FROM okr_ip_combinations c JOIN okr_ip_common_b i ON c.ip_id = i.ip_id WHERE c.cbn_id = :cbn_id. Since the table is absent from standard installations, these queries are relevant only where OKR objects persist from prior releases or custom deployments.

Related Objects

The following objects are most significant in relation to this table, based on the documented foreign key relationships:

• OKR_COMBINATIONS_B — referenced by OKR_IP_COMBINATIONS.CBN_ID; the parent combination entity.
• OKR_IP_COMMON_B — referenced by OKR_IP_COMBINATIONS.IP_ID; the parent intellectual property entity.
• OKR_IP_COMBINATIONS_PK — the composite primary key constraint (IP_ID, CBN_ID) enforcing row uniqueness.

Additional OKR tables and views built on the Contracts for Rights schema may reference these parents indirectly, but the metadata documents only these two foreign key targets. Consultants should verify object existence in each target environment before relying on any of these dependencies.