Search Results cs_kb_ele_type_attrs




Overview
Explore in AI Chat

Overview

The CS_KB_ELE_TYPE_ATTRS table is a foundational data structure within the Oracle E-Business Suite Service (CS) module's Knowledge Base (KB) functionality. Its primary role is to define the permissible attributes for different types of knowledge base elements by establishing a many-to-many relationship between element types and attribute types. This design allows for flexible content modeling, where a single element type (e.g., a "Solution" or "FAQ") can be associated with multiple descriptive attributes, and a single attribute type (e.g., "Product," "Severity") can be reused across multiple element types. Crucially, the provided ETRM documentation explicitly states this table has been deprecated and was "Not used since before 11.5.8." Therefore, in releases 12.1.1 and 12.2.2, this table is a legacy artifact and is not actively utilized by the application's core logic for managing knowledge base content.

Key Information Stored

The table's structure is minimal, serving solely as a junction table to link two key entities. The critical columns are the composite primary key, which enforces the unique relationship between an element type and an attribute.

  • ELEMENT_TYPE_ID: A foreign key column referencing CS_KB_ELEMENT_TYPES_B. This identifies a specific category or class of knowledge base content, such as a document type or template structure.
  • ATTRIBUTE_ID: A foreign key column referencing CS_KB_ATTRS_B. This identifies a specific attribute or metadata field that can be assigned to an element type, such as a text field, date, or list of values.

Together, these two columns form the primary key (CS_KB_ELE_TYPE_ATTRS_PK), ensuring that any given pairing of element type and attribute is recorded only once in the system.

Common Use Cases and Queries

Given its deprecated status in modern releases, there are no active application use cases for this table in EBS 12.1.1 or 12.2.2. Its presence is historical. However, for diagnostic or data migration purposes, one might query it to understand legacy data relationships that were potentially migrated from earlier versions. A sample query to retrieve all defined relationships would be:

SELECT et.element_type_name, a.attribute_name
FROM cs_kb_ele_type_attrs eta
JOIN cs_kb_element_types_b et ON eta.element_type_id = et.element_type_id
JOIN cs_kb_attrs_b a ON eta.attribute_id = a.attribute_id
ORDER BY 1, 2;

Any reporting or integration logic in versions 11.5.8 and later should reference the successor data model and APIs, not this table.

Related Objects

The table's relationships are explicitly defined by its foreign key constraints, linking it to the master tables for element types and attributes.

  • CS_KB_ELEMENT_TYPES_B: This table is referenced via the foreign key on CS_KB_ELE_TYPE_ATTRS.ELEMENT_TYPE_ID. It stores the master list of defined knowledge base element types.
  • CS_KB_ATTRS_B: This table is referenced via the foreign key on CS_KB_ELE_TYPE_ATTRS.ATTRIBUTE_ID. It stores the master definition of all available attribute types in the knowledge base.

These relationships confirm the table's intended purpose as a pure association table between these two core entities. Developers and administrators should consult the documentation for CS_KB_ELEMENT_TYPES_B and CS_KB_ATTRS_B to understand the current, active data model for knowledge base attributes in release 12.x.