Search Results school_of_interest_id

Overview

IGS.IGS_SS_INQUIRY is a table in the Oracle E-Business Suite 12.1.1 / 12.2.2 schema owned by IGS (the Student Systems / self-service product family). Per the ETRM metadata, the table "Holds Selfservice Staging Inquiry records" and is flagged Obsolete. It resides in the APPS_TS_INTERFACE tablespace with PCTFREE 10, a placement consistent with its role as an interface/staging object rather than a transactional core table. Records are populated by self-service recruitment and admissions channels (typically web inquiry forms), then staged for downstream processing before being resolved into the institution's operational student records.

Despite its obsolete designation, the table remains physically present and VALID, and is still referenced by several dependent child tables, which is why legacy reports, customizations, and extensions may continue to query it. From a Data Vault modeling perspective, the mined FK structure classifies this object as hub-leaning: INQ_INQ_ID acts as a durable business key for the inquiry event, while descriptive and flexfield attributes behave satellite-like. This classification is a heuristic suggestion, not a physical design mandate.

Because the table is obsolete, Oracle no longer recommends new development against it; persisted data typically represents historical self-service inquiry traffic retained for audit or migration purposes.

Key Information Stored

• INQ_INQ_ID — Surrogate primary key (IGS_SS_INQUIRY_PK) and the column backing unique index IGS_SS_INQUIRY_U1. This is the join key for all child tables.
• INQ_PERSON_ID — Foreign key to IGS_SS_INQ_PERSON_ALL, identifying the prospective applicant who submitted the inquiry.
• INQUIRY_DATE — The date the inquiry was captured; the primary date dimension for recruitment funnel reporting and the column most frequently searched.
• INQ_ENTRY_STAT_ID / INQ_ENTRY_LEVEL_ID — Status and level of the inquiry entry, driving workflow stage and scoring.
• EDU_GOAL_ID, SCHOOL_OF_INTEREST_ID — Declared educational goal and target school/program of interest.
• ACAD_CAL_TYPE / ACAD_CI_SEQUENCE_NUMBER and ADM_CAL_TYPE / ADM_CI_SEQUENCE_NUMBER — Academic and admission calendar context for the inquiry.
• HOW_KNOWUS_ID, WHO_INFLUENCED_ID, INQUIRY_SOURCE_TYPE_ID — Marketing attribution: how the prospect learned of the institution and who influenced the decision.
• COMMENTS — Free-text remarks (up to 2000 characters).
• ATTRIBUTE_CATEGORY / ATTRIBUTE1–20 — Descriptive flexfield columns capturing customer-specific extension data.
• CREATION_DATE, LAST_UPDATE_DATE, CREATED_BY, LAST_UPDATED_BY — Standard Who columns for auditability.
• REQUEST_ID / PROGRAM_ID / PROGRAM_APPLICATION_ID — Concurrent program context, useful for tracing batch loads.

Common Use Cases and Queries

Typical usage centers on inquiry volume analysis, source attribution, and staging validation before migration. A count of inquiries by date:

SELECT TRUNC(inquiry_date), COUNT(*) FROM igs.igs_ss_inquiry GROUP BY TRUNC(inquiry_date) ORDER BY 1;

Attribution reporting joins person and source data:

SELECT i.inquiry_date, i.inquiry_source_type_id, i.how_knowus_id FROM igs.igs_ss_inquiry i WHERE i.inquiry_date BETWEEN :p_from AND :p_to;

A integrity check for orphaned staging rows uses the FK join to the person table:

SELECT i.inq_inq_id FROM igs.igs_ss_inquiry i, igs.igs_ss_inq_person_all p WHERE i.inq_person_id = p.inq_person_id (+);

Because the table is obsolete, assess row counts and last update timestamps before relying on it in production reporting.

Related Objects

• IGS.IGS_SS_INQ_PERSON_ALL — Parent table; joined on INQ_PERSON_ID to resolve the inquiring person's details.
• IGS.IGS_SS_INQ_INFO_REQ — Child table referencing INQ_INQ_ID; holds additional information requests.
• IGS.IGS_SS_INQ_PROG — Child table on INQ_INQ_ID; captures programs of interest per inquiry.
• IGS.IGS_SS_INQ_USET — Child table on INQ_INQ_ID; stores associated user/test data.

These children inherit the hub-leaning model: the inquiry ID is the shared key, and the surrounding columns supply contextual detail. Any migration or archival effort should account for all three child tables to preserve referential integrity.