Results for “ak_inst_attribute_values”

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

Overview

AK_INST_ATTRIBUTE_VALUES is a table owned by the AK (Common Modules-AK) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Per the ETRM documentation, the table is used by the Configurator (CZ) team and stores item-related attribute values. It functions as the attribute-value store behind the Oracle Configurator's generic instance model, allowing an attribute code to be resolved to a concrete value for a specific database object instance.

The table is classified as VALID and is documented with 22 columns. From an analytical modeling perspective, the heuristic Data Vault classification mined from the foreign-key structure is standalone. This suggests that, in a Data Vault model, AK_INST_ATTRIBUTE_VALUES would most appropriately be treated as its own hub-like or standalone entity rather than being decomposed into a hub, link, or satellite, because no parent-child FK relationships were detected in the metadata.

Key Information Stored

The table's primary key is AK_INST_ATTRIBUTE_VALUES_PK, a composite surrogate composed of DATABASE_OBJECT_NAME, KEY_VALUE1 through KEY_VALUE10, ATTRIBUTE_CODE, and ATTRIBUTE_APPLICATION_ID. This composite key identifies a single attribute value for a specific instance of a database object.

• DATABASE_OBJECT_NAME — identifies the database object (entity) to which the attribute value belongs; it is the anchor of the composite key.
• KEY_VALUE1 – KEY_VALUE10 — the ten generic key segments that together identify the specific instance row of the referenced object. This multi-segment design is what allows the table to store attribute values for many different object types without schema changes.
• ATTRIBUTE_CODE — the code of the attribute being stored; combined with ATTRIBUTE_APPLICATION_ID it distinguishes attributes that share a code across applications.
• ATTRIBUTE_APPLICATION_ID — the application that owns the attribute definition.
• VALUE_VARCHAR2, VALUE_DATE, VALUE_NUMBER — the actual attribute values, held in three typed columns so that character, date, and numeric attributes can all be persisted in one table.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit columns.
• ZD_EDITION_NAME — the editioning column present in 12.2.x, reflecting the Edition-Based Redefinition architecture introduced with Online Patching.

The unique index AK_INST_ATTRIBUTE_VALUES_U1 covers the same columns as the primary key plus ZD_EDITION_NAME, confirming that the business key is only unique within an edition in 12.2.2. The surrogate primary key (AK_INST_ATTRIBUTE_VALUES_PK) and this business-key candidate should be distinguished in any model: the PK is the physical constraint, while the U1 index defines the logical business identity.

Common Use Cases and Queries

Typical usage centers on retrieving the value of a named attribute for a known object instance. A representative query pattern is:

• SELECT attribute_code, value_varchar2, value_date, value_number FROM ak.ak_inst_attribute_values WHERE database_object_name = :object_name AND key_value1 = :kv1 AND attribute_code = :code;
• Reporting on which attributes are populated for a given object type by grouping on database_object_name and attribute_code.
• Audit and change-tracking queries filtered on last_update_date or last_updated_by.
• Joining to Configurator and item definition tables via DATABASE_OBJECT_NAME and the applicable KEY_VALUE segments.

Because the key is generic, queries must always constrain the correct KEY_VALUE positions for the object type in question; treating KEY_VALUE1–10 as free-form search fields without the object context can produce misleading results.

Related Objects

The metadata classifies this object as standalone, so no FK relationships are documented. Practically, the most significant related objects are the Configurator (CZ) instance and attribute definition tables, which supply DATABASE_OBJECT_NAME, ATTRIBUTE_CODE, and ATTRIBUTE_APPLICATION_ID, and the item master tables that the stored items ultimately reference. Joins are performed on DATABASE_OBJECT_NAME together with the appropriate KEY_VALUE columns and on ATTRIBUTE_CODE with ATTRIBUTE_APPLICATION_ID, rather than through declared foreign keys.