Search Results sys_il0000163982c00004




Overview

BSC.BSC_SYS_IMAGES is a transactional table in the Oracle E-Business Suite 12.1.1 and 12.2.2 database, owned by the BSC (Balanced Scorecard) application schema. It stores information about the binary image files used by BSC, including the raw image payload itself, along with descriptive and dimensional metadata such as file name, description, MIME type, width, and height. The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, and its associated unique index BSC_SYS_IMAGES_U1 lives in the APPS_TS_TX_IDX tablespace.

The object is registered in FND Design Data as BSC.BSC_SYS_IMAGES and carries a documented status of VALID, confirming it is an active, supported component of the BSC data model. The FILE_BODY column is a BLOB and is accompanied by an internal LOB index (SYS_IL0000163982C00004$$) that is UNIQUE and stored in APPS_TS_TX_DATA, reflecting the independent segment allocation typical of LOB storage.

From a heuristic Data Vault modeling perspective — mined from the absence of foreign-key relationships — this table is classified as standalone, meaning it does not reference any other database object and no other documented object references it via foreign key. In a Data Vault pattern, it would most naturally be modeled as a satellite attached to an IMAGE hub keyed on IMAGE_ID, with the descriptive attributes (FILE_NAME, DESCRIPTION, WIDTH, HEIGHT, MIME_TYPE) and the binary FILE_BODY payload representing the descriptive and contextual data of that hub. Treat this classification as a suggested modeling direction rather than a physical constraint, since BSC enforces relationships at the application layer rather than through the database.

Key Information Stored

The table contains 12 documented columns. The most significant are:

  • IMAGE_ID (NUMBER, 15) — Mandatory surrogate primary key, "Image identifier." It is also the column of unique index BSC_SYS_IMAGES_U1, making it the documented business-key candidate and the join column to be used in all downstream queries.
  • FILE_NAME (VARCHAR2, 90) — The name of the stored image file.
  • DESCRIPTION (VARCHAR2, 150) — Human-readable description of the file's purpose or content.
  • FILE_BODY (BLOB) — The binary image payload itself. Note that the ETRM excerpt displays a length of 4000 for this column, which reflects the LOB segment descriptor view in ETRM rather than the true BLOB capacity.
  • WIDTH (NUMBER) and HEIGHT (NUMBER) — Dimensional attributes allowing image size to be reported without rendering the binary content.
  • MIME_TYPE (VARCHAR2, 240) — The MIME content type of the image, used by BSC when presenting the file.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — The standard "Who" audit columns maintained by Oracle EBS on transactional records.

The primary key, BSC_SYS_IMAGES_PK, is defined on IMAGE_ID, confirming that each row is uniquely identified by that surrogate value rather than by FILE_NAME or any other descriptive attribute.

Common Use Cases and Queries

Because the object is standalone and carries no database-enforced foreign keys, the most common interaction patterns involve direct retrieval by primary key or metadata filtering. Typical reporting scenarios include inventorying all stored images by MIME type and dimensions, or identifying orphaned files whose descriptions have not been maintained.

  • Retrieve a single image by identifier without touching the BLOB payload:
    SELECT IMAGE_ID, FILE_NAME, DESCRIPTION, WIDTH, HEIGHT, MIME_TYPE
    FROM BSC.BSC_SYS_IMAGES
    WHERE IMAGE_ID = :image_id;
  • Inventory images by format and size, useful for storage sizing and content auditing:
    SELECT MIME_TYPE, COUNT(*), SUM(DBMS_LOB.GETLENGTH(FILE_BODY)) AS total_bytes
    FROM BSC.BSC_SYS_IMAGES
    GROUP BY MIME_TYPE;
  • Identify stale or recently modified entries using the Who columns:
    SELECT IMAGE_ID, FILE_NAME, LAST_UPDATED_BY, LAST_UPDATE_DATE
    FROM BSC.BSC_SYS_IMAGES
    WHERE LAST_UPDATE_DATE >= TRUNC(SYSDATE) - 30;

The standard documented extraction query selects all 12 columns from BSC.BSC_SYS_IMAGES. When querying production data it is good practice to exclude FILE_BODY from list-style reports, since each BLOB fetch can materially increase I/O and network transfer.

Related Objects

The ETRM metadata explicitly states that BSC.BSC_SYS_IMAGES does not reference any database object, and that it is referenced only by the APPS synonym BSC_SYS_IMAGES, which is the interface through which application and reporting users normally access the underlying table. This absence of foreign-key relationships is why the object is classified as standalone.

Consequently, application-level consumers within the BSC schema — such as scorecard definition and dashboard rendering components — reference images by IMAGE_ID without a database-enforced constraint. The synonym APPS.BSC_SYS_IMAGES functions as the practical join target for custom views and concurrent programs, and any reporting object built on BSC metadata should join to BSC_SYS_IMAGES on IMAGE_ID. Inference of additional structural dependencies beyond the documented synonym is not supported by the ETRM metadata and should be confirmed against the BSC application module definitions before being relied upon.