Search Results eng_subject_entities_u2




Overview

ENG.ENG_SUBJECT_ENTITIES is a seed-data configuration table owned by the ENG (Engineering) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the subject entities associated with engineering subject definitions, defining which business entities — such as items or item revisions — participate in a given subject, the parent-child hierarchy among those entities, and the foreign key columns through which each entity is resolved. The table resides in the APPS_TS_SEED tablespace with a PCTFREE of 10, which is consistent with its role as setup/reference data rather than high-volume transactional data.

From a Data Vault modeling perspective, the metadata classifies this table as standalone (no outgoing foreign key dependencies documented at the physical level). This suggests it may be modeled as a hub-like structure centered on SUBJECT_ID, with the non-key descriptive attributes (entity name, parent entity, foreign key column names, bean type) behaving as satellite attributes. In EBS terms, the table functions as metadata that drives how engineering change and subject-based processes resolve their underlying entity instances.

Key Information Stored

  • SUBJECT_ID — Subject identifier; the primary correlation key that links rows to a subject definition. It is the leading column of both documented unique indexes.
  • ENTITY_NAME — Name of the entity, identifying whether it is an item or an item revision. Part of the business key candidate ENG_SUBJECT_ENTITIES_U2.
  • PARENT_ENTITY_NAME — Name of the parent entity, supporting hierarchical subject structures.
  • SUBJECT_LEVEL — Numeric subject level indicating the entity's position within the subject hierarchy. Part of the business key candidate ENG_SUBJECT_ENTITIES_U1.
  • FK1_COLUMN_NAME through FK5_COLUMN_NAME — Five columns holding the foreign key identifiers/column names used to resolve each entity to its source table.
  • BEAN_TYPE — Identifies the bean (business object) type associated with the entity, used by the middle-tier application layer.
  • ZD_EDITION_NAME — Editioning column present in 12.2.x; part of both unique indexes and central to Edition-Based Redefinition (EBR).
  • CREATED_BY / CREATION_DATE / LAST_UPDATE_DATE / LAST_UPDATED_BY / LAST_UPDATE_LOGIN — Standard WHO audit columns.

The documented unique indexes — ENG_SUBJECT_ENTITIES_U1 (SUBJECT_ID, SUBJECT_LEVEL, ZD_EDITION_NAME) and ENG_SUBJECT_ENTITIES_U2 (SUBJECT_ID, ENTITY_NAME, ZD_EDITION_NAME) — function as business-key candidates, while there is no separate single-column surrogate key beyond SUBJECT_ID combined with the edition column.

Common Use Cases and Queries

Typical scenarios include retrieving the entities configured for a given engineering subject, determining parent-child entity relationships, and introspecting which foreign key columns drive entity resolution. A common query pattern is:

  • Filtering by subject: SELECT SUBJECT_ID, ENTITY_NAME, PARENT_ENTITY_NAME, SUBJECT_LEVEL FROM ENG.ENG_SUBJECT_ENTITIES WHERE SUBJECT_ID = :p_subject_id;
  • Resolving hierarchy: order by SUBJECT_LEVEL to reconstruct the parent-child tree.
  • Inspecting resolution metadata: select the FK1_COLUMN_NAMEFK5_COLUMN_NAME and BEAN_TYPE columns to understand how an entity maps back to its source.
  • Edition-aware reporting in 12.2.x: include ZD_EDITION_NAME in predicates and grouping to isolate edition-specific configurations.

Related Objects

  • IGS_UC_COM_EBL_SUBJ — Referenced via the documented foreign key on SUBJECT_ID; the subject definition table supplying subject context.
  • ENG_SUBJECT_ENTITIES (APPS synonym) — The APPS-layer synonym through which ENG.ENG_SUBJECT_ENTITIES is referenced by application code and views.
  • ENG schema subject/entity definition tables — Related engineering subject setup objects that share SUBJECT_ID as a join column.
  • Item / item revision master tables — Resolved indirectly through the five FK*_COLUMN_NAME foreign key columns when ENTITY_NAME designates an item or item revision.

Because the heuristic classification is standalone, no direct outgoing FK chain beyond SUBJECT_ID is documented; consumers typically join on SUBJECT_ID, ENTITY_NAME, and SUBJECT_LEVEL to relate this seed metadata to engineering subject and item data.