Results for “image_file_name”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_PE_PERSON_IMAGE is a table owned by the IGS schema within the Oracle E-Business Suite Student System module. It stores binary image content associated with a person record — typically a photograph, identification portrait, or similar captured image used in student, applicant, or constituent processing. The table is documented against release 12.1.1 (11 columns) and is carried forward in the 12.2.2 documentation set.

The Oracle Student System is designated Obsolete in the ETRM documentation, and the implementation notes record that the table is Not implemented in this database. This indicates that deployments which have moved to successor products (for example, Oracle Student Cloud or third-party student information systems) will not contain the physical object, and any legacy code path referencing it will fail at runtime. The table should therefore be treated as reference metadata for historical or upgrade-analysis purposes rather than as a supported integration surface.

Under a heuristic Data Vault classification mined from the foreign key structure, the table is satellite-leaning. In Data Vault terms, this is a modeling suggestion: the table behaves like an attribute-bearing satellite hanging off a person hub (HZ_PARTIES), where the descriptive payload is the image itself plus its descriptive attributes. It is not a hub, because its identity is inherited from the referenced party rather than being an independent business concept.

Key Information Stored

The primary key, IGS_PE_PERSON_IMAGE_PK, is a composite of PERSON_ID and IMAGE_DT. This design implies that a single person may hold multiple images over time, with IMAGE_DT acting as the effective/temporal discriminator. The unique index IGS_PE_PERSON_IMAGE_U1 covers the same column pair, confirming that this combination is the controlling business-key candidate. There is no independent surrogate identifier such as a sequence-generated *_ID column.

• PERSON_ID — Foreign key to HZ_PARTIES. Identifies the party (student, applicant, contact) to whom the image belongs. This is the join spine of the table.
• IMAGE_DT — The date the image was captured or recorded. Combined with PERSON_ID, it forms the primary key and provides the temporal grain of the image history.
• PERSON_IMAGE — The image payload, stored in the base table's row. Depending on the physical configuration, this is the raw binary (BLOB) content or a pointer to the LOB segment.
• PERSON_IMAGE_LOB — The LOB locator column used by Oracle to address the out-of-line LOB segment. The presence of an internal index such as SYS_IL0000197812C00009$$ in the documented unique-index list confirms that a LOB segment is physically created for this column.
• IMAGE_CONTENT_TYPE — The MIME type of the stored image (for example, image/jpeg or image/png). Essential for correct rendering by consuming applications.
• IMAGE_FILE_NAME — The original or assigned file name of the image, useful for download operations and auditability.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — The standard Oracle EBS WHO columns. These record the creating and last-updating user, timestamp, and login session, supporting audit and change-tracking requirements.

Common Use Cases and Queries

The principal application use case is retrieval of the current image for a given person, for display in a student or constituent maintenance form or for printing on an identification document. Historical images are recovered by specifying an effective date. A typical pattern for the newest image is:

• Select the row with the maximum IMAGE_DT for a supplied PERSON_ID, returning PERSON_IMAGE, IMAGE_CONTENT_TYPE, and IMAGE_FILE_NAME.
• Join PERSON_ID to HZ_PARTIES.PARTY_ID to enrich results with party name, party type, and contact information for reporting extracts.
• Count or aggregate by IMAGE_CONTENT_TYPE to profile the image formats held across a population.
• Reconcile against the LOB segment by comparing byte length via the LOB functions when validating migrated or imported image content.

Because the object is obsolete and not implemented in current installations, these queries are relevant chiefly to legacy data migration, archival extracts, or forensic analysis of historical schemas rather than to live production reporting.

Related Objects

The dominant relationship is the foreign key from IGS_PE_PERSON_IMAGE.PERSON_ID to HZ_PARTIES, making the Trading Community Architecture party model the authoritative source for person identity. The following objects are the most significant in practice:

• HZ_PARTIES — referenced via PERSON_ID; supplies party identity, name, and party type.
• HZ_PERSON_PROFILES — extends party records with person-specific attributes; commonly joined through the shared party identifier when building person-centric reports.
• HZ_ORG_CONTACTS — relates organizational contacts to parties, allowing image lookups for contact roles.
• IGS_PE_PERSON_IMAGE_PK — the composite primary key constraint enforcing uniqueness of PERSON_ID and IMAGE_DT.
• IGS_PE_PERSON_IMAGE_U1 — the unique index that documents the business-key candidate columns.
• Student System person views and concurrent programs that consume the IGS_PE_* family of tables for biographical and admissions processing.

Consumers should verify the existence of the table before use, given its obsolete status and the documented absence from the reference database.