Search Results edw_flex_attribute_mappings




Overview

EDW_FLEX_ATTRIBUTE_MAPPINGS is a table owned by the BIS schema (Applications BIS product) in Oracle E-Business Suite 12.1.1 and 12.2.2. It is a valid, standalone data dictionary object whose purpose is to describe the mapping between descriptive flexfield (DFF) and key flexfield (KFF) segments found across the EBS application tables and the value-set or attribute metadata used by the Enterprise Data Warehouse / Business Intelligence (BIS) layer. In other words, this table provides a technical bridge: it records, for a given flexfield structure and segment, the segment's data type, the associated value set, and the underlying application column and instance identifiers that an ETL or BI process needs in order to resolve flexible-field values into reportable dimensions.

From a heuristic Data Vault modeling perspective, the mined FK structure classifies this table as standalone (no inbound or outbound child dependencies beyond its foreign key). It therefore maps best to a hub or reference/satellite-style object rather than a transactional link. Because the only documented foreign key is an outbound reference to FRM_PART_VALUE_SETS, the table behaves as a dependent reference table rather than as a central transaction entity.

Key Information Stored

The table contains 15 documented columns. The most significant are:

VALUE_SET_ID is the documented foreign key, referencing EDW_FLEX_ATTRIBUTE_MAPPINGS.VALUE_SET_ID → FRM_PART_VALUE_SETS, which supplies the value-set definition. The surrogate key ATTR_MAPPING_FK serves as the row identifier; the natural or business-key candidate is the combination of structure and segment attributes (STRUCTURE_NUM, ID_FLEX_CODE, SEGMENT_NAME, and APPLICATION_ID). The metadata does not document an explicit unique index on these columns, so they are treated here as candidate business keys rather than confirmed uniqueness constraints.

Common Use Cases and Queries

This table is typically used to drive metadata-driven ETL and reporting. Common scenarios include:

  • Resolving an application column to its flexfield segment so that reporting queries can join flexible-field values back to a descriptive label.
  • Joining to value-set metadata to determine valid values or the type of a segment.
  • Building a data dictionary or lineage report across all flexfield segments in a warehouse.
  • Filtering segments by FLEX_FIELD_TYPE (key vs. descriptive) or by APPLICATION_ID for application-specific extracts.

A representative query pattern is:

  • SELECT m.STRUCTURE_NAME, m.SEGMENT_NAME, m.VALUE_SET_NAME, m.APPLICATION_COLUMN_NAME FROM EDW_FLEX_ATTRIBUTE_MAPPINGS m WHERE m.ID_FLEX_CODE = :flex_code AND m.APPLICATION_ID = :app_id;
  • Join to FRM_PART_VALUE_SETS v ON m.VALUE_SET_ID = v.VALUE_SET_ID to obtain full value-set attributes.

These patterns support BI publishers, data warehouse loads, and customer-facing metadata explorers that must decode flexfield values without hard-coding segment definitions.

Related Objects

The most significant related objects are:

  • FRM_PART_VALUE_SETS — referenced by VALUE_SET_ID; supplies value-set definitions used by each mapped segment.
  • FND_FLEX_VALUES / FND_FLEX_VALUES_TL — value-set values that the mappings ultimately resolve.
  • FND_ID_FLEX_STRUCTURES / FND_ID_FLEX_SEGMENTS — the EBS flexfield structure and segment definitions that correspond to STRUCTURE_NUM, ID_FLEX_CODE, and SEGMENT_NAME.
  • FND_APPLICATION_VL — provides APPLICATION_ID and APPLICATION_NAME for the owning application.
  • EDW_* warehouse mapping or dimension tables in the BIS schema that consume these mappings during load.
  • FND_FLEX_VALUE_SETS — the underlying value-set catalog aligned with VALUE_SET_ID and VALUE_SET_NAME.

Together these objects form the metadata chain from an EBS flexfield segment through its value set to the physical application column and, finally, to the warehouse reporting structure.