Search Results bsc_kpi_tree_nodes_tl




Overview
Explore in AI Chat

Overview

The BSC_KPI_TREE_NODES_TL table belongs to the Oracle Balanced Scorecard (BSC) product family, a module classified as obsolete in Oracle EBS 12.1.1 and 12.2.2. The table stores translated (language-specific) information for simulation tree nodes used in Balanced Scorecard KPI hierarchies. Its name suffix "_TL" identifies it as the translation table paired with the base table BSC_KPI_TREE_NODES_B. The documentation explicitly notes that this object is not implemented in the current database, meaning the module is dormant, but the schema definition and relationships are preserved in the ETRM reference.

From a Data Vault modeling perspective, the metadata classifies this object as satellite-leaning. It carries descriptive, language-dependent attributes keyed to a parent business entity, which is consistent with satellite behavior. Analysts modeling BSC data should treat it as a dependent descriptive table rather than a hub or link.

Key Information Stored

The table contains seven documented columns. The most significant are listed below.

  • INDICATOR — A key column identifying the KPI indicator context for the tree node; part of the composite primary key and a foreign key to the base table.
  • LANGUAGE — The language code for the translated row; part of the primary key and the discriminating column for translation.
  • NODE_ID — The identifier of the simulation tree node; part of the primary key and foreign key to BSC_KPI_TREE_NODES_B.
  • SOURCE_LANG — The source language from which the translation was derived.
  • NAME — The translated display name of the tree node, shown to end users in scorecard visualizations.
  • HELP — Translated help or descriptive text associated with the node.
  • Y_AXIS_TITLE — The translated label for the Y-axis when the node is rendered in a chart.

The surrogate primary key is defined by the unique index BSC_KPI_TREE_NODES_TL_PK on (INDICATOR, LANGUAGE, NODE_ID). A second unique index, BSC_KPI_TREE_NODES_TL_U1, covers (INDICATOR, NODE_ID, LANGUAGE), functioning as a business-key candidate. The two indexes are functionally equivalent sets but differ in column ordering.

Common Use Cases and Queries

Because the BSC module is obsolete, queries against this table typically serve historical reporting, data migration, or audit reconciliation rather than live scorecard rendering. A common pattern joins the translation table to its base parent to reconstruct a fully localized tree node:

  • Localized node lookup: SELECT b.NODE_ID, t.NAME, t.HELP FROM BSC_KPI_TREE_NODES_B b, BSC_KPI_TREE_NODES_TL t WHERE b.NODE_ID = t.NODE_ID AND b.INDICATOR = t.INDICATOR AND t.LANGUAGE = 'US';
  • Translation completeness check: Identify nodes lacking a row for a given LANGUAGE by comparing counts between the base and translated tables.
  • Chart label extraction: Retrieve Y_AXIS_TITLE and NAME values to rebuild axis labeling for archived scorecard dashboards.
  • Migration validation: Verify SOURCE_LANG and LANGUAGE pairings when moving BSC content into a successor analytics platform.

Reporting use cases center on restoring multi-language scorecard labels and confirming that every active node has a complete set of translated descriptors before decommissioning the module.

Related Objects

The strongest relationship is the mandatory parent-child link to the base translation source. The following objects are most significant.

  • BSC_KPI_TREE_NODES_B — The base table; joined on INDICATOR and NODE_ID, the documented foreign key relationship.
  • BSC_KPI_TREE_NODES_TL_PK — The primary key index on (INDICATOR, LANGUAGE, NODE_ID).
  • BSC_KPI_TREE_NODES_TL_U1 — The unique business-key index on (INDICATOR, NODE_ID, LANGUAGE).
  • BSC_KPI_TREE_NODES_VL — The conventional translated view typically layered atop the _B and _TL pair in EBS.
  • BSC_KPI_TREE_NODES_B (via FND_LANGUAGES) — Language rows in FND_LANGUAGES govern the LANGUAGE values that drive translation joins.

Because this object is documented as not implemented in the database, related views and APIs may exist only as metadata definitions. Any integration effort should verify physical presence before relying on these relationships.