Search Results cs_forum_cat_cats

Overview

CS_FORUM_CAT_CATS is a persistent table in the CS (Service) product schema of Oracle E-Business Suite, available in releases 12.1.1 and 12.2.2 with a status of VALID. Its documented description, "Forum category categories," identifies it as a self-referencing association table within the Oracle Knowledge/Forum subsystem of Service. The table records pairwise relationships between forum categories, allowing categories defined in CS_FORUM_CATEGORIES_B to be grouped, nested, or otherwise associated with one another. Because it carries no descriptive or transactional measures of its own and consists almost entirely of two foreign key columns, it functions purely as an intersection construct.

From a dimensional and Data Vault modeling perspective, the heuristic classification mined from the foreign key structure is link. This is a modeling suggestion rather than a physical attribute: CS_FORUM_CAT_CATS relates two category entity instances and therefore behaves like a link table connecting two references to the same hub (the category hub). Analysts building an analytic or warehouse layer over EBS Service data should treat it as an associative/link object and resolve its relationships at query time against the category base table.

Key Information Stored

The table is narrow in business meaning. Its documented physical schema contains 24 columns, but only a small subset carries semantic content; the remainder are standard EBS bookkeeping and descriptive-flex attributes.

• CATEGORY_ID_1 – First category in the relationship; foreign key to CS_FORUM_CATEGORIES_B. Part of the composite primary key.
• CATEGORY_ID_2 – Second category in the relationship; foreign key to CS_FORUM_CATEGORIES_B. Part of the composite primary key.
• SECURITY_GROUP_ID – Foreign key to FND_SECURITY_GROUPS, providing multi-tenant/security-group partitioning of the row.
• CREATED_BY, CREATION_DATE – Standard WHO columns capturing the creating user and timestamp.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard WHO columns capturing the most recent modification and the login session that performed it.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 – The descriptive flexfield (DFF) columns, reserved for customer-configured extensions. They are unpopulated by base product code unless a flexfield has been configured and enabled.

Regarding keys: the surrogate primary key is CS_FORUM_CAT_CATS_PK, defined over (CATEGORY_ID_1, CATEGORY_ID_2). A second unique index, CS_FORUM_CAT_CATS_U1, exists on the same two columns, which is the documented business-key candidate — the natural uniqueness rule is that a given ordered pair of categories cannot appear twice. No standalone sequence-generated surrogate column is documented, so the primary key is effectively the natural composite identifier.

Common Use Cases and Queries

Because the table stores only associations, typical usage is resolution-oriented: listing the categories related to a given category, validating that a relationship exists, and exporting the association graph for reporting. The most common query pattern joins each foreign key column back to CS_FORUM_CATEGORIES_B, since the raw IDs are meaningless without the category names.

• Relationships for one category: SELECT category_id_2 FROM cs_forum_cat_cats WHERE category_id_1 = :p_category_id;
• Symmetric lookup: union the reverse direction (category_id_1 WHERE category_id_2 = :p) to obtain undirected associations.
• Labeled listing: join CS_FORUM_CATEGORIES_B twice, aliased c1 and c2, on CATEGORY_ID_1 and CATEGORY_ID_2 respectively, to return human-readable category names for both sides.
• Security-group-scoped reporting: filter or partition on SECURITY_GROUP_ID when producing multi-org or multi-tenant extracts, joining FND_SECURITY_GROUPS for group names.
• Integrity validation: detect orphaned associations by left-joining CS_FORUM_CATEGORIES_B and checking for missing matches on either ID column.
• Change auditing: use LAST_UPDATE_DATE and LAST_UPDATED_BY to report newly created or recently modified category relationships.

DBA-facing use cases include confirming the CS_FORUM_CAT_CATS_PK and CS_FORUM_CAT_CATS_U1 indexes exist after patching or cloning, and verifying row counts against the category base table during data migration of the Knowledge module.

Related Objects

The dependency graph is compact and centered on the category base table:

• CS_FORUM_CATEGORIES_B – referenced twice, via CS_FORUM_CAT_CATS.CATEGORY_ID_1 and CS_FORUM_CAT_CATS.CATEGORY_ID_2. This is the primary and most significant relationship; both joins resolve to the same base table.
• FND_SECURITY_GROUPS – referenced via CS_FORUM_CAT_CATS.SECURITY_GROUP_ID, identifying the security partition that owns the association row.
• Associated "_TL" table of CS_FORUM_CATEGORIES_B – the translatable companion used to obtain category display names in language-specific queries.
• Other CS_FORUM_* objects – sibling forum/knowledge tables that reference category IDs and are commonly reported alongside this table.
• CS_FORUM_CAT_CATS_PK / CS_FORUM_CAT_CATS_U1 – the supporting indexes that enforce the primary and alternate uniqueness of the category pair and drive lookup performance.

No public PL/SQL API specific to this table is documented in the source metadata; associations are maintained through the Service/Knowledge application logic and concurrent programs rather than a published interface. All references remain within the CS schema except for the security-group foreign key into FND.