Search Results igs_pe_eit_u1




Overview
Explore in AI Chat

Overview

IGS.IGS_PE_EIT is an Oracle E-Business Suite table in the IGS (Intellectual Gateway Services / Student System) schema that stores a person's extra information — the descriptive attributes associated with a person's record that are captured in addition to the core person registration data held elsewhere. Each row represents a single extra-information value set for a person, identified by a unique surrogate key and segmented by information type and effective date range. The table is registered in FND Design Data as IGS.IGS_PE_EIT and has a status of VALID.

From a Data Vault modeling perspective, the mined relationship data classifies this object as satellite-leaning. It is a descriptive, multi-active attribute table attached to a person, carrying a unique business key of person, information type, and start date — the classic fingerprint of a satellite keyed off a parent hub rather than a hub or link in its own right.

Physically, the table resides in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10, and its unique indexes live in APPS_TS_TX_IDX. The documented schema contains 15 columns and the primary key, IGS_PE_EIT_PK, is defined on PE_EIT_ID.

Key Information Stored

The table is anchored by its surrogate primary key, PE_EIT_ID (NUMBER(15), mandatory), described as a unique identifier. Two unique indexes act as business-key candidates:

The remaining important columns include:

  • PERSON_ID (NUMBER(15), mandatory) — the person identification number, the foreign-key link back to the person record.
  • INFORMATION_TYPE (VARCHAR2(40), mandatory) — the extra information type that categorizes the value set being captured.
  • PEI_INFORMATION1 through PEI_INFORMATION5 (VARCHAR2(150) each) — five flexible descriptive attribute columns holding the actual extra information values.
  • START_DATE (DATE, mandatory) — the date the information becomes effective; part of the business key.
  • END_DATE (DATE) — the date the information ceases to be effective.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns tracking row provenance and modification.

Common Use Cases and Queries

Typical reporting retrieves the currently effective extra information for a person by filtering on the effective date range. The following pattern returns active rows for a given person:

  • SELECT pe_eit_id, information_type, pei_information1, pei_information2, start_date, end_date FROM igs.igs_pe_eit WHERE person_id = :person_id AND NVL(end_date, SYSDATE) >= SYSDATE;

A common administrative query lists all information types captured for a person across history, ordered by type and start date, joining the unique key columns to reconstruct the business key:

  • SELECT person_id, information_type, start_date, end_date FROM igs.igs_pe_eit WHERE person_id = :person_id ORDER BY information_type, start_date;

Because the table is effective-dated, date-range joins are needed when correlating extra information with other person-centric transactions. The presence of five generic attribute columns makes IGS_PE_EIT a common target for investigating where a particular person attribute is stored when it does not appear on the primary person record.

Related Objects

IGS.IGS_PE_EIT does not reference other database objects as a child, but it participates in the following relationships:

  • HZ_PARTIES — the foreign-key relationship from IGS_PE_EIT.PERSON_ID to HZ_PARTIES establishes the parent party/person record that the extra information describes.
  • APPS.IGS_PE_EIT — the APPS synonym or view over the base table, the normal access point for application and reporting SQL.
  • IGS_PE_EIT_PK / IGS_PE_EIT_U1 / IGS_PE_EIT_U2 — the primary and unique indexes that enforce row identity and the natural business key.
  • The wider IGS person entity family — the person registration and party structures underlying PERSON_ID — provides the context into which these extra-information rows attach.

The dependents list confirms that IGS_PE_EIT is referenced by the APPS layer rather than being a referencing child itself, consistent with its satellite-leaning classification as a descriptive attribute store attached to the person hub.