Results for “minor_unit_set_cd3”

8 results




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

Overview

The IGS_DA_REQ_WIF table belongs to the IGS (Student System) product family within Oracle E-Business Suite. It stores program and unit set details associated with a "what-if" request, a self-service mechanism that allows a student or advisor to simulate an alternative program of study and view the resulting academic progress without committing changes to the actual record. Each row pairs a batch identifier with a what-if identifier and captures the program, catalog reference, and the unit sets that constitute the simulated curriculum.

The object is documented as obsolete and, per the ETRM metadata, is not implemented in this database. The information below therefore describes the historical 12.1.1/12.2.2 schema definition and should be treated as reference material for data migration, archiving, or legacy impact analysis rather than as guidance for new development.

Applying Data Vault heuristics to the foreign-key structure, the table leans toward a satellite classification. Its two-part primary key, IGS_DA_REQ_WIF_PK (BATCH_ID, WIF_ID), depends directly on the parent request aggregate in IGS_DA_RQST, so the row describes attributes of that parent rather than acting as an independent hub or a many-to-many link.

Key Information Stored

The table carries 19 documented columns in the 12.1.1 physical schema, owned by the IGS schema. The columns of primary analytical interest are:

The unique index IGS_DA_REQ_WIF_PK on (BATCH_ID, WIF_ID) is the only documented business-key candidate; it establishes that the pair must be unique. The three major/minor/track groupings of three columns each reflect the historical limit of three unit sets per category in the what-if evaluation engine.

Common Use Cases and Queries

Because the object is obsolete and not implemented, contemporary use cases center on historical reporting and migration rather than transactional processing. Typical questions include identifying which programs were most frequently simulated, which unit-set combinations were evaluated, and reconciling what-if request headers with their program detail rows.

A representative join reconstructs the request with its simulated program:

  • SELECT r.BATCH_ID, r.WIF_ID, w.PROGRAM_CODE, w.CATALOG_CAL_TYPE, w.CATALOG_CI_SEQ_NUM
  • FROM IGS_DA_RQST r, IGS_DA_REQ_WIF w
  • WHERE r.BATCH_ID = w.BATCH_ID;

A second pattern enumerates unit-set selection frequency by unpivoting the nine unit-set columns, while a third joins IGS_DA_REQ_STDNTS on BATCH_ID and WIF_ID to link the student population to each simulated program. Catalog validation queries join to IGS_CA_INST_ALL on CATALOG_CAL_TYPE and CATALOG_CI_SEQ_NUM, and program validation joins to IGS_PS_COURSE on PROGRAM_CODE. Reporting extracts should always filter or partition on BATCH_ID given its role in both the primary key and the parent foreign key.

Related Objects

The following objects are the most significant dependencies based on the documented constraints:

  • IGS_DA_RQST — parent request table; joined on IGS_DA_REQ_WIF.BATCH_ID = IGS_DA_RQST.BATCH_ID.
  • IGS_DA_REQ_STDNTS — child table holding student-level what-if detail; references this table through BATCH_ID and WIF_ID.
  • IGS_CA_INST_ALL — catalog calendar instance; joined on CATALOG_CAL_TYPE and CATALOG_CI_SEQ_NUM.
  • IGS_PS_COURSE — program definition; joined on PROGRAM_CODE.

No public APIs or views specific to IGS_DA_REQ_WIF are documented in the ETRM metadata; access was through the internal what-if processing logic of the Student System.