Search Results fnd_oam_doc_category_pk

Overview

FND_OAM_DOC_CATEGORY is a table owned by the APPLSYS schema within the FND — Application Object Library product of Oracle E-Business Suite. As documented in the ETRM 12.2.2 repository (and applicable to 12.1.1), it stores information about document categories used by the Oracle Applications Manager (OAM) diagnostic and documentation infrastructure. The table has a status of VALID and comprises eight physical columns. Its primary key, FND_OAM_DOC_CATEGORY_PK, is defined on the composite of CATEGORY_KEY and CATEGORY_TYPE.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. In modeling terms, this suggests the table behaves as an independent reference or lookup entity rather than participating in a hub-and-link network. It carries its own descriptive attributes (notably CATEGORY_NAME) alongside the two key components, so it can reasonably be treated as a small code/reference table with a natural composite business key rather than a dependent satellite. No inbound or outbound foreign keys were identified in the documented relationship data, reinforcing the standalone suggestion.

Key Information Stored

The table’s documented columns fall into two functional groups: the business key attributes that identify a document category, and the standard Oracle EBS audit ("Who") columns maintained by the Applications Object Library.

• CATEGORY_KEY — One half of the composite primary key and also part of the unique index FND_OAM_DOC_CATEGORY_U1. It holds the short identifier or code for a document category.
• CATEGORY_TYPE — The second half of the composite primary key and the leading column of the unique index. It distinguishes the classification or grouping under which a given CATEGORY_KEY is defined, allowing the same key value to exist across different category types.
• CATEGORY_NAME — The descriptive, user-facing label associated with the composite key; this is the principal non-key attribute.
• CREATED_BY, CREATION_DATE — Standard audit columns recording the creating user and timestamp.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard audit columns capturing the most recent modification user, timestamp, and login context.

The surrogate-versus-business-key distinction is explicit here: FND_OAM_DOC_CATEGORY_PK (CATEGORY_KEY, CATEGORY_TYPE) is the enforced primary key, while the unique index FND_OAM_DOC_CATEGORY_U1, declared on (CATEGORY_TYPE, CATEGORY_KEY), is the documented business-key candidate. The reversed column order between the two constraints is a common EBS pattern and does not affect uniqueness given the identical column set.

Common Use Cases and Queries

Because OAM relies on this table to drive category-driven navigation and filtering of diagnostics and documentation, typical usage centers on lookups and reporting joins. A straightforward lookup of a single category is:

• SELECT category_key, category_type, category_name FROM fnd_oam_doc_category WHERE category_type = :type AND category_key = :key;
• Enumerating all categories of a given type: SELECT category_key, category_name FROM fnd_oam_doc_category WHERE category_type = :type ORDER BY category_name;
• Audit-oriented reporting on recently maintained categories: SELECT category_key, category_type, last_updated_by, last_update_date FROM fnd_oam_doc_category WHERE last_update_date >= :since;

Reporting use cases include validating that a category referenced downstream exists in this table, populating LOV queries for OAM-facing pages, and reconciliation extracts that compare CATEGORY_NAME against external documentation inventories. Because the table is small and static in nature, queries are inexpensive and generally benefit from the unique index on (CATEGORY_TYPE, CATEGORY_KEY).

Related Objects

The documented relationship data classifies this object as standalone, with no foreign-key dependencies recorded. Consequently, related objects are inferred from the OAM documentation framework that the table supports rather than from explicit FK constraints. The most significant associations are:

• Other FND_OAM_DOC_* tables and views that store the individual documents or diagnostics belonging to a category, joined on CATEGORY_KEY and CATEGORY_TYPE.
• Oracle Applications Manager components within the FND module that resolve category codes to their display CATEGORY_NAME.
• Concurrent programs and diagnostic scripts that select category metadata before generating output.
• Standard FND audit and lookup views that reference the audit columns maintained by the Applications Object Library.

Administrators and developers should confirm any join relationships against the actual data dictionary, since no FK constraints are documented for this table in the ETRM 12.2.2 schema.