Search Results bism_associates




Overview
Explore in AI Chat

Overview

BISM_ASSOCIATES is a table owned by the APPLSYS schema and registered in the FND — Application Object Library product within Oracle E-Business Suite 12.1.1 and 12.2.2. It is documented in the ETRM repository as a VALID database object. Functionally, the table stores association records that link a source entity (SOURCE_ID) to a target entity (TARGET_ID) using a name/value pair (NAME, VALUE). This pattern is characteristic of EBS metadata and Business Intelligence / summary management infrastructure, where named attributes are attached to specific target definitions without requiring schema changes for every new attribute.

From a data modeling perspective, the heuristic Data Vault classification mined from the foreign key structure is standalone. This means the table is not modeled as a strict hub, link, or satellite in the documented relationship graph; instead, it behaves as an independent attribute-carrying entity that references a single parent. Readers should treat this classification as a modeling suggestion rather than a mandated design constraint. The only documented outgoing foreign key is from BISM_ASSOCIATES.TARGET_ID to AMS_DM_TARGETS_B, which anchors the table to the target definitions maintained by the Oracle Marketing / AMS data model.

Key Information Stored

The documented physical schema for release 12.2.2 shows four columns in APPLSYS.BISM_ASSOCIATES. Each column participates directly in the table's business meaning:

  • SOURCE_ID — Identifies the source record that owns the association. It forms part of the composite unique business key.
  • TARGET_ID — Identifies the associated target. This is the only documented foreign key column, referencing AMS_DM_TARGETS_B.
  • NAME — The attribute or association name being recorded; the semantic label for the pairing.
  • VALUE — The value assigned to the NAME attribute for the given source/target combination.

The table's unique index, BISM_ASSOCIATES_PK, is defined over (SOURCE_ID, NAME, VALUE). This composite key is the documented business-key candidate: it guarantees that a given source cannot carry two identical name/value associations. Notably, TARGET_ID is not part of the unique index, meaning the uniqueness enforced at the database level is driven by the source, name, and value rather than by the target. There is no separately documented single-column surrogate key; the natural composite key serves as the primary identifier. Because the table has only four columns, no further column-level distinction is required.

Common Use Cases and Queries

Typical usage centers on resolving named attributes attached to target definitions. Reporting and integration queries generally join from BISM_ASSOCIATES to its parent target table to pick up descriptive target information, while filtering by NAME to isolate a specific association type. A representative pattern is:

  • SELECT a.SOURCE_ID, a.TARGET_ID, a.NAME, a.VALUE FROM APPLSYS.BISM_ASSOCIATES a WHERE a.NAME = :attribute_name;
  • SELECT a.*, t.* FROM APPLSYS.BISM_ASSOCIATES a JOIN AMS_DM_TARGETS_B t ON t.TARGET_ID = a.TARGET_ID WHERE a.SOURCE_ID = :source_id;
  • Lookup by the composite business key: ... WHERE SOURCE_ID = :s AND NAME = :n AND VALUE = :v;

Common scenarios include extracting association metadata for data warehouse loads, auditing which named attributes are attached to which targets, and validating uniqueness during conversion or interface programs. Because the unique index excludes TARGET_ID, any ETL process that intends per-target associations must account for this behavior and avoid unintended collisions on identical name/value pairs.

Related Objects

The documented relationships identify the following significant dependent and referenced objects:

  • AMS_DM_TARGETS_B — Referenced via BISM_ASSOCIATES.TARGET_ID; the parent target definition table and the primary join partner.
  • BISM_ASSOCIATES_PK — The unique index over (SOURCE_ID, NAME, VALUE) enforcing the business key.
  • APPLSYS schema objects — The owning schema, whose FND metadata governs access and validation.
  • FND — Application Object Library — The product module under which the table is registered; relevant for metadata and security review.

Because the documented FK graph is limited to a single reference, additional dependent views or APIs are not enumerated in the source metadata and should be confirmed against the live data dictionary before being relied upon.