Search Results weight_id




Overview
Explore in AI Chat

Overview

The table BIS.BIS_WEIGHTED_MEASURE_SCORES is an Oracle EBS Business Intelligence System (BIS) transactional data object that stores the scoring bands used to convert a raw numeric measurement into a weighted score. Each row defines a range — bounded by LOW_RANGE and HIGH_RANGE — and the SCORE that is awarded when a measurement falls within that range, for a given weighting definition identified by WEIGHT_ID. The object resides in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10 and is owned by the BIS schema, with FND design data registered as BIS.BIS_WEIGHTED_MEASURE_SCORES. Its status is VALID under both Oracle EBS 12.1.1 and 12.2.2.

The heuristic Data Vault classification mined from the foreign-key structure is standalone, meaning the table carries no outbound relationships to a parent hub beyond the single documented reference on WEIGHT_ID. From a modeling perspective this suggests the table behaves as a satellite-like detail set keyed by a weighting identifier, rather than as a central hub or an associative link. The absence of an explicit foreign key constraint in the dictionary reinforces that the WEIGHT_ID linkage is enforced through application logic rather than declarative referential integrity.

Key Information Stored

The documented physical schema comprises nine columns. The most consequential are:

  • WEIGHT_ID (NUMBER) — the weighting definition to which a score band belongs. This is the leading column of both unique indexes and the documented reference to CS_SR_LOAD_BALANCE_WT.
  • LOW_RANGE (NUMBER) — the lower bound of the measurement interval for the band.
  • HIGH_RANGE (NUMBER) — the upper bound of the measurement interval for the band.
  • SCORE (NUMBER) — the weighted score assigned to measurements falling inside the band.
  • CREATED_BY, CREATION_DATE — standard EBS audit attributes recording row creation.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS audit attributes recording the most recent modification and the originating login.

There is no single-column surrogate primary key documented. Instead, two unique indexes act as business-key candidates. BIS_WEIGHTED_MEASURE_SCORES_U1 enforces uniqueness on (WEIGHT_ID, LOW_RANGE, HIGH_RANGE), guaranteeing that no two bands within the same weighting overlap on identical bounds. BIS_WEIGHTED_MEASURE_SCORES_U2 enforces uniqueness on (WEIGHT_ID, SCORE), preventing duplicate scores within a weighting definition. Together these constraints make WEIGHT_ID the effective driving key for all lookups.

Common Use Cases and Queries

The table is consumed wherever a weighted scoring calculation must translate a measurement into a normalized value — for example, supplier scorecards, load-balancing weight derivations, and balanced-scorecard style KPIs. A typical retrieval returns all bands for a weighting definition in ascending range order:

SELECT WEIGHT_ID, LOW_RANGE, HIGH_RANGE, SCORE
FROM   BIS.BIS_WEIGHTED_MEASURE_SCORES
WHERE  WEIGHT_ID = :p_weight_id
ORDER  BY LOW_RANGE;

A band-lookup pattern resolves a measurement to its score:

SELECT SCORE
FROM   BIS.BIS_WEIGHTED_MEASURE_SCORES
WHERE  WEIGHT_ID = :p_weight_id
AND    :p_measurement BETWEEN LOW_RANGE AND HIGH_RANGE;

Validation reporting identifies overlapping or gapped bands, the two most common configuration defects, by self-joining on WEIGHT_ID and comparing range endpoints. Because U1 already blocks identical bounds, gap detection is the more useful audit.

Related Objects

  • CS_SR_LOAD_BALANCE_WT — the documented referenced object for WEIGHT_ID; the parent weighting definition from which score bands inherit identity.
  • APPS.BIS_WEIGHTED_MEASURE_SCORES — the APPS-owned synonym or view exposing the table to the application layer, listed as a dependent.
  • BIS_WEIGHTED_MEASURE_SCORES_U1 and BIS_WEIGHTED_MEASURE_SCORES_U2 — the unique indexes in APPS_TS_TX_IDX that enforce the business keys on (WEIGHT_ID, LOW_RANGE, HIGH_RANGE) and (WEIGHT_ID, SCORE).

No other tables or views are documented as referencing this object, confirming its standalone classification. Integrations should therefore treat WEIGHT_ID as the join key to the load-balance weighting definition and validate band completeness before publishing scores.