Search Results bsc_tmp_big_in_cond




Overview
Explore in AI Chat

Overview

BSC_TMP_BIG_IN_COND is a temporary staging table in the Balanced Scorecard (BSC) module of Oracle E-Business Suite. It resides in the BSC schema and is classified as VALID in both Oracle EBS 12.1.1 and 12.2.2. Its documented purpose is to hold intermediate values for temporary variables — those variables whose values must be computed, cached, or passed between processing steps during the execution of scorecard logic, rather than persisted as permanent business data.

The "TMP" prefix and "BIG_IN_COND" suffix indicate its role as a transient work area for large input conditions, typically consumed and purged within a single session. It should not be treated as a durable reporting source of record.

From a Data Vault modeling perspective, the ETRM heuristic classification places this table as standalone — it is not a hub, link, or satellite in the strict sense. It functions more like a staging or work table, and only its foreign-key edge to RG_DSS_VARIABLES gives it a single documented hub-like relationship.

Key Information Stored

The ETRM documentation lists four physical columns in the BSC schema (12.1.1). Their roles are as follows:

  • SESSION_ID — Identifies the runtime session or process that populated the row. This is the primary candidate for logical partitioning; it scopes the temporary data to a single execution context so concurrent runs do not interfere.
  • VARIABLE_ID — The foreign key to RG_DSS_VARIABLES. It identifies which temporary variable the row's value belongs to. This is the principal business-key candidate alongside SESSION_ID.
  • VALUE_N — The numeric value of the temporary variable, used when the variable is a number.
  • VALUE_V — The character (varchar) value of the temporary variable, used when the variable is textual.

No explicit surrogate primary key column is documented in the four-column layout; the natural composite of SESSION_ID and VARIABLE_ID is what identifies a row. The dual VALUE_N / VALUE_V design is a common EBS pattern for polymorphic temporary storage.

Common Use Cases and Queries

Because this is a transient working table, the dominant use case is diagnostic: investigating an in-flight or failed BSC calculation and inspecting what temporary variable values were cached for a given session.

  • Session inspection: Join on SESSION_ID to reconstruct the input conditions for a specific scorecard run.
  • Variable resolution: Join VARIABLE_ID to RG_DSS_VARIABLES to translate IDs into readable variable names.
  • Mixed-type extraction: Use NVL(VALUE_N, TO_NUMBER(NULL)) for numeric consumers and COALESCE(VALUE_V, TO_CHAR(VALUE_N)) for a unified display.

A representative pattern:

  • SELECT t.SESSION_ID, v.VARIABLE_NAME, t.VALUE_N, t.VALUE_V
  • FROM   BSC.BSC_TMP_BIG_IN_COND t, BSC.RG_DSS_VARIABLES v
  • WHERE  t.VARIABLE_ID = v.VARIABLE_ID
  • AND    t.SESSION_ID = :session_id;

Reporting should never treat this table as persistent. It is purged by its owning process and its contents are not guaranteed across runs.

Related Objects

The documented relationship data identifies one explicit foreign-key dependency and several contextual objects:

  • RG_DSS_VARIABLES — The parent of the sole documented FK (BSC_TMP_BIG_IN_COND.VARIABLE_ID → RG_DSS_VARIABLES). This is the primary join partner and defines the temporary variables referenced.
  • BSC_TMP_BIG_IN_COND as referenced by BSC scorecard engine programs and concurrent requests that populate and read temporary variable values during rule evaluation.
  • BSC temporary / staging siblings owned by the BSC schema that follow the same SESSION_ID-scoped pattern for other temporary input types.
  • RG_DSS_VARIABLES dependent views and constraints that enforce referential integrity for VARIABLE_ID.

Given the sparse documented relationship footprint, the authoritative dependency to model is the VARIABLE_ID link into RG_DSS_VARIABLES; all other associations should be verified against the live BSC schema before being relied upon in custom SQL.