Search Results bism_database

Overview

BISM_DATABASE is a table owned by the APPLSYS schema within the FND — Application Object Library product of Oracle E-Business Suite. It is documented as a VALID object in both EBS 12.1.1 and 12.2.2. The ETRM reference material characterizes the object as implementation/DBA data containing Oracle proprietary and confidential information, and it forms part of the infrastructure that supports the Business Intelligence System Model (BISM) metadata layer used by Oracle's embedded business intelligence and reporting components.

The documented physical schema in ETRM 12.2.2 shows a single column, DATABASE_ID, confirming that BISM_DATABASE acts as a thin registration or reference table rather than a transactional entity. From a Data Vault modeling perspective, the heuristic classification mined from the foreign-key structure is standalone. This suggests the table functions as an independent hub-like reference registry rather than a link or satellite, because it neither resolves many-to-many relationships between other hubs nor carries descriptive business attributes belonging to a parent key. The presence of an outgoing foreign key to HR_DM_DATABASES indicates it participates in a referential chain anchored by a Human Resources data-mining table.

Key Information Stored

The documented column inventory for APPLSYS.BISM_DATABASE is intentionally minimal. Only one column is recorded in the ETRM 12.2.2 metadata:

• DATABASE_ID — the sole documented column. In the context of the BISM schema, this identifier designates a database registration entry. It is simultaneously the surrogate primary key of the table and an outgoing foreign-key reference to HR_DM_DATABASES.DATABASE_ID, meaning it is not an independently generated surrogate but a correlated identifier inherited from the parent registration.

Because the metadata exposes only this one column, no distinct business-key columns, alternate unique indexes, descriptive name fields, or audit columns are documented. Practitioners should treat DATABASE_ID as both the primary key and the principal join key. Any additional descriptive attributes that may physically exist in a given environment (for example database name, connect string, or platform metadata) are not part of the ETRM-documented schema and should be verified directly against the data dictionary before being relied upon in custom code or extracts.

Common Use Cases and Queries

BISM_DATABASE is typically queried for metadata validation, referential-integrity auditing, and support of diagnostic reporting against the BISM layer. A common pattern is confirming that every BISM_DATABASE row resolves to a valid HR_DM_DATABASES record, which exposes orphaned registrations:

• SELECT b.DATABASE_ID FROM APPLSYS.BISM_DATABASE b WHERE NOT EXISTS (SELECT 1 FROM HR.HR_DM_DATABASES d WHERE d.DATABASE_ID = b.DATABASE_ID);
• SELECT COUNT(*) FROM APPLSYS.BISM_DATABASE; — a volume check used to detect unexpected registrations after cloning or patching.
• SELECT b.DATABASE_ID, d.DATABASE_ID FROM APPLSYS.BISM_DATABASE b LEFT JOIN HR.HR_DM_DATABASES d ON b.DATABASE_ID = d.DATABASE_ID; — a reconciliation join for bidirectional verification.

Because the table is small and standalone, it is rarely a performance concern. Its practical value lies in DBA validation after Oracle Applications Manager or BISM-related patches, and in confirming that cloning procedures did not carry stale database identifiers into a target environment.

Related Objects

The foreign-key metadata identifies one direct dependency, from which the following related objects are most significant:

• HR_DM_DATABASES (HR schema) — referenced via BISM_DATABASE.DATABASE_ID → HR_DM_DATABASES.DATABASE_ID. This is the only documented foreign-key relationship and the primary parent of BISM_DATABASE.
• APPLSYS schema objects — sibling BISM* tables in APPLSYS that share the database registration context and are commonly examined together during diagnostics.
• FND product metadata objects — the FND — Application Object Library tables and views that expose BISM information to Oracle Applications Manager and related administrative interfaces.

No views, PL/SQL APIs, or triggers are documented as directly referencing BISM_DATABASE in the ETRM excerpt. Custom integrations should treat the table as read-only reference data and should not insert or update DATABASE_ID values independently of HR_DM_DATABASES, to preserve referential integrity.