Search Results ota_chat_obj_inclusions




Overview
Explore in AI Chat

Overview

OTA_CHAT_OBJ_INCLUSIONS is a transactional table in the OTA (Learning Management) schema of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. It functions as the inclusion resolver that maps a chat-based learning object to either a category or a class. The documented business rule is exclusive: a chat may belong to multiple categories, or to a single class, but not both. Once a chat is associated with a class, it cannot simultaneously be defined under a category, and the reciprocal restriction applies.

From a Data Vault modeling perspective, the heuristic classification mined from the foreign-key structure is standalone. Rather than behaving as a hub, link, or satellite, the table records a scoped association between a chat and the container to which it belongs, with no dependent parent chain surfaced through the key analysis. The primary key OTA_CHAT_OBJ_INCLUSIONS_UK1 is a composite business key spanning CHAT_ID, OBJECT_TYPE, and OBJECT_ID, which reinforces the interpretation that the table captures membership relationships rather than an independent entity.

Key Information Stored

The table contains 12 documented columns, of which the most operationally significant are the following.

  • CHAT_ID — Identifies the chat that is being included. This is the first component of the unique key OTA_CHAT_OBJ_INCLUSIONS_UK1.
  • OBJECT_TYPE — Discriminator that determines whether OBJECT_ID refers to a category or to a class. This enforces the category-versus-class exclusivity rule.
  • OBJECT_ID — Identifier of the category or class receiving the chat. Together with CHAT_ID and OBJECT_TYPE, it forms the full unique business key.
  • START_DATE_ACTIVE and END_DATE_ACTIVE — Effective-dating boundaries governing when the inclusion is in force.
  • PRIMARY_FLAG — Indicates the primary inclusion when a chat is associated with more than one container.
  • OBJECT_VERSION_NUMBER — Optimistic locking column used by the Oracle EBS framework to detect concurrent updates.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — Standard Oracle who-and-when audit columns describing row creation and the most recent modification.

The surrogate primary key is the composite unique index OTA_CHAT_OBJ_INCLUSIONS_UK1 (CHAT_ID, OBJECT_TYPE, OBJECT_ID). No separate single-column surrogate key is documented; the composite index also serves as the primary business-key candidate.

Common Use Cases and Queries

Typical reporting scenarios include cataloguing which chats belong to a given category or class, verifying that the exclusivity constraint has not been violated, and reconciling currently active inclusions for curriculum audits.

  • Listing all chats included in a specific class: select CHAT_ID from OTA_CHAT_OBJ_INCLUSIONS where OBJECT_TYPE = 'CLASS' and OBJECT_ID = :class_id and (END_DATE_ACTIVE is null or END_DATE_ACTIVE >= sysdate).
  • Finding chats eligible under a category for a learner-facing search: join CHAT_ID to the chat master table, filtering on OBJECT_TYPE and the active date window, and ordering by PRIMARY_FLAG.
  • Data-quality checks — detecting chats that appear under both a category and a class, which would indicate a breach of the documented rule.
  • Effective-dating reports that show inclusions that have been end-dated, supporting historical curriculum analysis.

Related Objects

The table is used in conjunction with several Learning Management objects, joined principally on CHAT_ID and on the OBJECT_TYPE/OBJECT_ID pair.

  • OTA_CHATS — the chat master that supplies CHAT_ID and chat attributes such as title and status.
  • The category definition object in OTA — resolved through OBJECT_TYPE = 'CATEGORY' and OBJECT_ID.
  • The class/offering object in OTA — resolved through OBJECT_TYPE = 'CLASS' and OBJECT_ID.
  • OTA_CHAT_OBJ_INCLUSIONS_UK1 — the unique index enforcing the composite business key.
  • Standard EBS who-column lookups such as FND_USER for CREATED_BY and LAST_UPDATED_BY.

Because the metadata classifies the object as standalone, direct foreign-key references are not surfaced; joins to the chat and container masters are therefore driven by the business-key columns documented above rather than by database-enforced constraints.