Search Results bsc_tab_views_tl




Overview

BSC_TAB_VIEWS_TL is the translation table for the Oracle Balanced Scorecard (BSC) module, which is documented in Oracle E-Business Suite Release 12.1.1 and 12.2.2 as an obsolete product. The suffix _TL denotes a translated (multi-language) entity: the table stores the language-dependent descriptive attributes of tab views — notably their display name and help text — keyed by language so that a single logical tab view can carry one row per installed language. Non-translatable, language-independent attributes of the same entity are held in the corresponding base table, BSC_TAB_VIEWS_B, which is paired with this table through the standard Oracle EBS MLS (Multi-Language Support) pattern.

The metadata characterises this object as a translated tab views information table and records that it is not implemented in the reference database, reflecting the retired status of the BSC module. Under the heuristic Data Vault classification mined from the foreign-key structure, the table is designated standalone. From a modelling perspective, this suggests the object behaves as an independent, self-contained reference structure rather than as a hub, link, or satellite within a Data Vault model, and no parent-child dependencies were mined for it.

Key Information Stored

The table carries eleven documented columns. The most significant are:

  • TAB_ID and TAB_VIEW_ID — identifiers of the parent tab and the tab view being translated; together these form the leading components of the primary key.
  • LANGUAGE — the NLS language code that completes the composite key and identifies the translation context.
  • SOURCE_LANG — the language of the source text from which the translation was derived, used by the MLS translation-maintenance framework.
  • NAME — the translated display name of the tab view, the primary attribute surfaced in the user interface.
  • HELP — the translated help or descriptive text associated with the tab view.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Oracle EBS WHO columns capturing audit and concurrency information for each row.

The surrogate primary key is defined by BSC_TAB_VIEWS_TL_PK over (TAB_ID, TAB_VIEW_ID, LANGUAGE). A unique index, BSC_TAB_VIEWS_TL_U1, is documented over the same three columns and therefore serves as the business-key candidate, guaranteeing at most one translation row per tab view per language.

Common Use Cases and Queries

Because the BSC module is obsolete, direct reporting against this table is largely historical or migration-oriented. Typical queries join the translation table to its base table on the shared key columns and filter by language, for example selecting TAB_ID, TAB_VIEW_ID, NAME and HELP where LANGUAGE equals the user's session language. Where the base table exists, the canonical pattern is:

  • Joining BSC_TAB_VIEWS_B to BSC_TAB_VIEWS_TL on TAB_ID and TAB_VIEW_ID, restricting LANGUAGE to the desired locale, to retrieve the translated label alongside language-independent attributes.
  • Auditing translation coverage by grouping rows by LANGUAGE and comparing counts against the base table to detect missing or stale translations.
  • Data-migration extraction, selecting SOURCE_LANG, NAME and HELP to preserve existing translated content when consolidating or archiving BSC metadata.
  • Investigating WHO columns to determine when a tab view translation was last maintained, useful in historical change analysis.

Related Objects

The most significant related object is the base table BSC_TAB_VIEWS_B, which shares the TAB_ID and TAB_VIEW_ID key and supplies the language-independent columns; the MLS join is performed on these two columns plus LANGUAGE. Other BSC tab and view definition tables within the same functional area, together with their corresponding _B and _TL translation tables, are the principal dependants and provide the surrounding hierarchy of tab and view metadata. Given the module's obsolete status, no active foreign-key relationships beyond this MLS pairing were mined in the documented relationship data, and the table is best treated as a standalone historical reference structure for the Balanced Scorecard configuration.