Search Results bsc_sys_images




Overview
Explore in AI Chat

Overview

BSC_SYS_IMAGES is a table within the Balanced Scorecard (BSC) product family of Oracle E-Business Suite. ETRM classifies BSC as obsolete, and the table is documented with the description "Images files information." It belongs to the BSC schema and holds 12 documented columns in the 12.1.1 physical schema. Functionally, the table stores binary image content and associated descriptive attributes used by the Balanced Scorecard application, such as status indicator graphics, dashboard icons, and other visual assets referenced by scorecard definitions and display configurations.

The ETRM metadata includes the explicit note "Not implemented in this database," meaning the table is defined in the product data model but is not physically instantiated in every EBS environment. Where it does exist, it is owned by the BSC schema and identified by the primary key constraint BSC_SYS_IMAGES_PK on IMAGE_ID. From a heuristic Data Vault modeling perspective, the metadata classifies this object as standalone, suggesting it is best modeled as a hub or independent reference table rather than as a link or satellite dependent on another entity. Its unique index BSC_SYS_IMAGES_U1 on IMAGE_ID confirms that each image record is uniquely identified by that column.

Key Information Stored

The table centers on the surrogate primary key IMAGE_ID, which uniquely identifies each stored image record and is enforced both by BSC_SYS_IMAGES_PK and the unique index BSC_SYS_IMAGES_U1. Because IMAGE_ID appears in both the primary key and a unique index, it is effectively the sole documented business-key candidate; no separate natural key column is documented.

The most significant descriptive columns are FILE_NAME, which holds the name of the image file; DESCRIPTION, which carries a human-readable label or purpose; and MIME_TYPE, which records the content type (for example, image/gif or image/jpeg). FILE_BODY stores the actual binary image content, making this table a repository for embedded graphics rather than just metadata. WIDTH and HEIGHT capture the pixel dimensions of the image. Audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN follow the standard EBS WHO-column convention and record row provenance and change history.

Common Use Cases and Queries

Because BSC_SYS_IMAGES holds binary content, typical queries retrieve metadata without touching the large FILE_BODY column. A common pattern enumerates available images:

  • SELECT IMAGE_ID, FILE_NAME, MIME_TYPE, WIDTH, HEIGHT FROM BSC.BSC_SYS_IMAGES;
  • Filtering by content type: SELECT FILE_NAME FROM BSC.BSC_SYS_IMAGES WHERE MIME_TYPE = 'image/gif';
  • Auditing recent additions: SELECT IMAGE_ID, FILE_NAME, CREATED_BY, CREATION_DATE FROM BSC.BSC_SYS_IMAGES ORDER BY CREATION_DATE DESC;
  • Retrieving binary content for a specific asset: SELECT FILE_BODY FROM BSC.BSC_SYS_IMAGES WHERE IMAGE_ID = :id;

Reporting scenarios include inventorying available visual assets, validating that dimensions conform to display requirements, and tracking who uploaded or last modified an image. Administrators performing migration or cleanup work may join this table to scorecard configuration tables to determine which images are still referenced.

Related Objects

The documented relationship data marks BSC_SYS_IMAGES as standalone; no foreign keys to or from other tables are recorded in the ETRM metadata. Consequently, join relationships are implied rather than enforced. Objects that may reference IMAGE_ID logically, or that share the BSC schema context, include the following:

  • BSC_SYS_IMAGES_PK and BSC_SYS_IMAGES_U1 — the primary key and unique index constraints on IMAGE_ID.
  • SYS_IL0000163982C00004$$ — the system index associated with the FILE_BODY column.
  • Balanced Scorecard configuration and scorecard definition tables that store image references resolved against IMAGE_ID.
  • Other BSC system tables (for example, BSC_SYS_* objects) that share the same schema and audit conventions.
  • Standard EBS audit views and DBA dictionaries, such as FND_USER, joinable via CREATED_BY and LAST_UPDATED_BY to resolve user names.

Because the table is documented as obsolete and not universally implemented, integrators should verify its physical presence before relying on it, and should treat any joins to scorecard tables as unenforced logical relationships rather than database-level constraints.