Results for “cs_kb_set_sets”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CS_KB_SET_SETS is a table in the CS (Service) product schema of Oracle E-Business Suite. It is documented in the E-Business Suite Technical Reference Manual (ETRM) as a knowledge base set-sets table that implements the many-to-many relationship between knowledge base sets. In effect, it records which sets are associated with or composed of other sets, functioning as the associative structure that connects two rows of the base set table to one another.

The ETRM description explicitly states that the object is "Not used since before 11.5.8." This is a critical implementation fact: although the table remains VALID and physically present in both 12.1.1 and 12.2.2 environments, Oracle no longer populates or maintains it through application logic in current releases. It exists primarily for backward compatibility, legacy data retention, and to satisfy the structural expectations of long-standing scripts. It should not be treated as an active functional table in new development.

Applying a Data Vault modeling heuristic to the documented foreign key structure, the object is best classified as a link table. Its entire purpose is to resolve a many-to-many relationship between two entities, which is the defining characteristic of a link construct. The two foreign keys to CS_KB_SETS_B establish the connected entities, while the surrogate-style composite primary key identifies each relationship instance.

Key Information Stored

The documented physical schema contains 24 columns. The most significant are the identifiers that define the relationship, followed by the standard concurrent-program audit columns and the descriptive flexfield (DFF) segment columns.

• SET_ID_1 — First component of the relationship. Foreign key to CS_KB_SETS_B. Part of the composite primary key CS_KB_SET_SETS_PK and of the unique index CS_KB_SET_SETS_U1.
• SET_ID_2 — Second component of the relationship. Also a foreign key to CS_KB_SETS_B, and the second column of the primary key and unique index.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, controlling multi-org / security-group access to the row.
• CREATION_DATE, CREATED_BY — Standard audit columns recording who created the row and when.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit columns recording the most recent modification and the login session that performed it.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — Descriptive flexfield columns available for client-specific or legacy contextual data.

Regarding key structure: the composite primary key CS_KB_SET_SETS_PK on (SET_ID_1, SET_ID_2) is the row identifier, and the unique index CS_KB_SET_SETS_U1 on the same two columns confirms it as the business-key candidate — no two rows may assert the same pair of sets. In Data Vault terms, this pair of foreign keys would typically be modeled as a single hash key in a link table, with the audit and DFF columns carried as link-level metadata. The audit columns are not business keys but are essential for lineage and change tracking.

Common Use Cases and Queries

Because the table is unused since before 11.5.8, active query patterns are limited. The primary practical scenarios are legacy data archaeology, migration assessment, and structural discovery.

A basic query to enumerate the linkages for a given set:

SELECT SET_ID_1, SET_ID_2, CREATION_DATE, LAST_UPDATE_DATE FROM CS.CS_KB_SET_SETS WHERE SET_ID_1 = :set_id;

A join to the base set table to resolve descriptive names for both ends of the relationship:

SELECT s1.SET_NAME AS parent_set, s2.SET_NAME AS child_set FROM CS.CS_KB_SET_SETS kss JOIN CS.CS_KB_SETS_B s1 ON s1.SET_ID = kss.SET_ID_1 JOIN CS.CS_KB_SETS_B s2 ON s2.SET_ID = kss.SET_ID_2;

Reporting scenarios include detecting orphaned or asymmetric linkages, measuring legacy data volume prior to archival, and validating referential integrity before retiring the object. For data-migration planning, a query grouping by SECURITY_GROUP_ID can reveal how many legacy rows belong to each security group and therefore which migration batches are affected.

Related Objects

The most significant dependencies are established by the documented foreign keys and by the base table the table was designed to serve.

• CS_KB_SETS_B — Base knowledge base sets table. Referenced twice, via CS_KB_SET_SETS.SET_ID_1 and CS_KB_SET_SETS.SET_ID_2. This is the primary parent object.
• FND_SECURITY_GROUPS — Reference table for the SECURITY_GROUP_ID column; governs row-level security and organization access.
• CS_KB_SET_SETS_PK — The composite primary key constraint/unique index on (SET_ID_1, SET_ID_2) that enforces relationship uniqueness.
• CS_KB_SET_SETS_U1 — The unique index on (SET_ID_1, SET_ID_2), confirming the business-key candidate.
• CS_KB_SETS_TL — The translated (TL) companion object commonly associated with CS_KB_SETS_B for resolving set names and descriptions in multilingual reporting.

No application API is documented as writing to this table in current releases, consistent with its deprecated status. Integration efforts should treat CS_KB_SET_SETS as read-only legacy inventory rather than an operational dependency.