Search Results hr_application_ownerships




Overview
Explore in AI Chat

Overview

HR_APPLICATION_OWNERSHIPS is a table owned by the HR schema in Oracle E-Business Suite, delivered under the PAY (Payroll) product family. Its documented purpose is to hold the primary keys for entities that enable identification of the products which use each piece of startup data. In practical terms, the table acts as a cross-reference registry that maps a logical data element (identified by KEY_NAME and a KEY_VALUE) to the owning application or product (identified by PRODUCT_NAME). This allows Oracle EBS to determine, for any given startup or seed data record, which modules have registered an ownership interest in that data.

From a dimensional modeling perspective, the ETRM metadata classifies this object heuristically as standalone, meaning it does not participate in a classic hub, link, or satellite pattern through foreign key dependencies. It is best treated as an independent reference or association table rather than as a transactional fact or a dependent satellite. Readers should regard the Data Vault classification as a modeling suggestion only; the physical table is a simple, narrow key-based registry.

Key Information Stored

The documented physical schema for 12.2.2 consists of four columns. The most important include:

  • KEY_NAME — The logical name of the startup data key being registered. This is the primary search column referenced in user queries and identifies the type of data element whose ownership is being tracked.
  • PRODUCT_NAME — The name of the Oracle EBS product or application that owns or consumes the identified startup data.
  • KEY_VALUE — The specific value of the key, allowing ownership to be recorded at the individual data-row level rather than only at the type level.
  • ZD_EDITION_NAME — The editioning column introduced by Oracle EBS 12.2 online patching (Edition-Based Redefinition). This column enables non-disruptive upgrades and is present in the 12.2.2 schema but not in 12.1.1.

The primary key is documented as HR_APPLICATION_OWNERSHIPS_PK, which the ETRM metadata lists over (KEY_NAME, PRODUCT_NAME, KEY_VALUE). The unique index is additionally documented over (KEY_NAME, PRODUCT_NAME, KEY_VALUE, ZD_EDITION_NAME). No separate surrogate system-generated identifier column is documented; the composite business key itself functions as the primary key, and the unique index on the four-column combination serves as the business-key candidate. The absence of additional columns means all relationships are key-driven rather than attribute-driven.

Common Use Cases and Queries

The most frequent query pattern filters on KEY_NAME to discover which products have registered ownership of a particular startup data element. A representative pattern is:

  • SELECT product_name, key_value FROM hr.hr_application_ownerships WHERE key_name = :key_name; — the canonical "who owns this key" lookup.
  • SELECT DISTINCT key_name FROM hr.hr_application_ownerships WHERE product_name = :product_name; — reverse lookup to enumerate all keys owned by a given product, useful during upgrades or module de-installation analysis.
  • SELECT key_name, product_name, key_value FROM hr.hr_application_ownerships WHERE key_name IN (...); — bulk ownership validation across a set of keys during data migration or startup data reconciliation.

Reporting use cases include auditing startup data ownership before patch application, verifying that seed data references remain valid after an upgrade, and diagnosing orphaned or conflicting ownership registrations during implementation of Payroll or HR modules. Because the table is narrow and key-only, queries are inexpensive and typically executed as reference-data lookups rather than large scans. In 12.2 environments, queries should account for ZD_EDITION_NAME when comparing rows across editions, since edition-aware joins may otherwise return duplicate or unexpected results.

Related Objects

The ETRM metadata classifies this table as standalone, so no formal foreign key relationships are documented. The following objects are significant by functional association and by the shared key columns:

  • HR_APPLICATION_OWNERSHIPS_PK — the primary key constraint enforcing uniqueness on (KEY_NAME, PRODUCT_NAME, KEY_VALUE).
  • HR startup and seed data tables — consult this registry to determine the owning product before loading or modifying seed rows keyed by KEY_NAME and KEY_VALUE.
  • FND_APPLICATION / FND_PRODUCT_GROUPS — reference objects for resolving PRODUCT_NAME values to application and product group descriptions.
  • Oracle Payroll (PAY) startup data objects — the principal consumers of ownership records maintained here.
  • Editioning-related views and synonyms in 12.2 that expose ZD_EDITION_NAME and mediate cross-edition access.

Because no FK relationships are documented, joins are executed on the business-key columns (KEY_NAME, PRODUCT_NAME, KEY_VALUE) rather than through enforced referential constraints, and integrators should apply these joins explicitly when resolving ownership metadata.