Search Results igs_pe_eit_pk

Overview

IGS_PE_EIT is a table in the IGS (Student System) product schema of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. It holds details of a person's "extra information" — that is, additional, institution-defined attributes attached to a person record beyond what the standard person model captures. In EBS, this table functions as the extensibility layer for person data within the Student System: rather than adding institution-specific columns to the core person entity, IGS stores those values as typed, time-bounded rows in IGS_PE_EIT.

From a dimensional modeling perspective, the table is best characterized as satellite-leaning. Its grain is one row per person, per information type, per effective start date, and it hangs off a person hub (HZ_PARTIES via PERSON_ID) with effective-dated attribute values. Reflecting that structure, it should be modeled as a satellite of the person hub rather than as an independent hub or link.

Key Information Stored

The table carries fifteen documented columns, of which the following are the most significant:

• PE_EIT_ID — the surrogate primary key, enforced by IGS_PE_EIT_PK and also indexed by unique index IGS_PE_EIT_U1.
• PERSON_ID — the foreign key to HZ_PARTIES identifying the person to whom the extra information belongs.
• INFORMATION_TYPE — the classification of the extra information being stored, allowing a single table to hold many distinct attribute categories.
• START_DATE / END_DATE — the effective-dating pair that bounds the validity of each row, enabling historical tracking of person attributes.
• PEI_INFORMATION1 through PEI_INFORMATION5 — a set of five generic, flexfield-style value columns that carry the actual extra information content for each INFORMATION_TYPE.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit columns recording who created and last modified each row and when.

The business-key candidate is captured by unique index IGS_PE_EIT_U2, defined over (PERSON_ID, INFORMATION_TYPE, START_DATE). This confirms that a person cannot hold two rows of the same information type beginning on the same date, and distinguishes the true business identity of a row from the surrogate PE_EIT_ID.

Common Use Cases and Queries

Typical uses involve retrieving or reporting the current and historical extra information for a person, filtering by information type, and joining that data back to the person and party records. A representative pattern retrieves currently effective extra information for a given person:

• SELECT pei.information_type, pei.pei_information1, pei.pei_information2, pei.start_date, pei.end_date FROM igs.igs_pe_eit pei WHERE pei.person_id = :person_id AND TRUNC(SYSDATE) BETWEEN pei.start_date AND NVL(pei.end_date, TRUNC(SYSDATE));
• Joining to HZ_PARTIES to obtain party name and identifiers: SELECT p.party_name, pei.information_type, pei.pei_information1 FROM igs.igs_pe_eit pei JOIN hz.hz_parties p ON p.party_id = pei.person_id;
• Reporting the history of a single information type for a person, ordered by START_DATE descending, to trace changes over time.
• Extracting all persons with a specific INFORMATION_TYPE for downstream integration or compliance reporting, using the INFORMATION_TYPE column as the primary filter.

Related Objects

The table participates in a small, well-defined relationship set:

• HZ_PARTIES — referenced through IGS_PE_EIT.PERSON_ID, this is the master party record and the principal parent of the extra information.
• IGS_PE_EIT_PK — the primary key constraint on PE_EIT_ID.
• IGS_PE_EIT_U1 — unique index on PE_EIT_ID.
• IGS_PE_EIT_U2 — unique index on (PERSON_ID, INFORMATION_TYPE, START_DATE), defining the business key.
• Other IGS person and person-extra-information objects that share the PERSON_ID reference and the PEI_INFORMATION flexible attribute pattern typically surround this table in the Student System data model.

Because it is the extensibility store for person data, IGS_PE_EIT should be treated as a dependent satellite: any integration or reporting that consumes person extra information must resolve PERSON_ID to HZ_PARTIES and respect the START_DATE/END_DATE effective-dating rules encoded in the unique key.