Search Results igs_ad_location_rel




Overview
Explore in AI Chat

Overview

IGS_AD_LOCATION_REL is a table within the IGS (Student System) product family, which Oracle classifies as obsolete in Oracle E-Business Suite releases 12.1.1 and 12.2.2. Functionally, the table describes the relationship between locations for the purpose of determining geographical equivalence between them — that is, it records which sub-locations are treated as equivalent to, or associated with, a parent location for student-system processing purposes.

Under the ETRM metadata, the object is flagged as "Not implemented in this database," meaning the physical table is documented but absent from the delivered schema in the environments surveyed. Consequently, no application logic or seeded data references it in a standard 12.1.1 or 12.2.2 installation. It should be regarded as a legacy or design-stage artifact of the IGS data model.

From a data-modeling perspective, the heuristic Data Vault classification mined from the foreign-key structure is link. This is a modeling suggestion rather than a documented Oracle construct: the table's identity is defined entirely by two foreign keys to the same parent table, with no independent descriptive payload typical of a hub or satellite. It is best understood as an associative (many-to-many) entity resolving relationships between location records.

Key Information Stored

The documented physical schema for ETRM 12.1.1 carries eight columns under the IGS owner. The most significant are:

  • LOCATION_CD — The primary location code. Part of the composite primary key and a foreign key to IGS_AD_LOCATION_ALL. Identifies the "from" or parent location in the equivalence relationship.
  • SUB_LOCATION_CD — The related sub-location code. Also part of the composite primary key and a second foreign key to IGS_AD_LOCATION_ALL. Identifies the "to" or subordinate location.
  • DFLT_IND — Default indicator. Flags whether the sub-location relationship is the default for the parent location, allowing consumers to select a preferred equivalent location when several exist.
  • CREATED_BY — Standard WHO column capturing the user who created the row.
  • CREATION_DATE — Standard WHO column recording row creation timestamp.
  • LAST_UPDATED_BY — Standard WHO column capturing the most recent updater.
  • LAST_UPDATE_DATE — Standard WHO column recording the most recent update timestamp.
  • LAST_UPDATE_LOGIN — Standard WHO column identifying the login session of the last update.

The surrogate primary key is defined by the constraint IGS_AD_LOCATION_REL_PK over (LOCATION_CD, SUB_LOCATION_CD). The unique index IGS_AD_LOCATION_REL_U1 is defined on the same two columns, making them the business-key candidates. Because the primary key is composite and natural — built from the two code columns rather than a generated sequence — the surrogate and business keys coincide here. The five WHO columns supply the audit payload; DFLT_IND supplies the only non-key business attribute documented.

Common Use Cases and Queries

In installations where the IGS Student System was deployed, this table supported geographic equivalence resolution — for example, mapping a campus sub-location to its governing main location when validating student addresses, scheduling, or enrollment eligibility. Reporting scenarios would include listing all sub-locations for a given location and identifying the default equivalent:

  • Resolving all equivalents of a location: SELECT SUB_LOCATION_CD, DFLT_IND FROM IGS_AD_LOCATION_REL WHERE LOCATION_CD = :p_location
  • Finding the default equivalent: SELECT SUB_LOCATION_CD FROM IGS_AD_LOCATION_REL WHERE LOCATION_CD = :p_location AND DFLT_IND = 'Y'
  • Validating orphaned mappings by outer-joining to IGS_AD_LOCATION_ALL on both LOCATION_CD and SUB_LOCATION_CD.

Because the object is not implemented and the product is obsolete, these patterns serve primarily data-migration, archival, or historical-audit purposes rather than live transactional processing. Any upgrade or consolidation effort should treat the table and its contents as candidates for retirement unless custom extensions depend on them.

Related Objects

  • IGS_AD_LOCATION_ALL — The single parent object for both foreign keys. Join on IGS_AD_LOCATION_REL.LOCATION_CD = IGS_AD_LOCATION_ALL.LOCATION_CD for the parent location and on IGS_AD_LOCATION_REL.SUB_LOCATION_CD = IGS_AD_LOCATION_ALL.LOCATION_CD for the equivalent sub-location. Both joins hit the same table, so aliasing (for example, LOC and SUBLOC) is required in queries.
  • IGS_AD_LOCATION_REL_PK — The primary-key constraint over LOCATION_CD and SUB_LOCATION_CD.
  • IGS_AD_LOCATION_REL_U1 — The unique index reinforcing the composite business key.

Beyond these documented dependencies, related IGS address and location components — such as address, campus, and student-location entities within the same product family — would historically have consumed the equivalence mappings. These should be confirmed in the target database, since the ETRM metadata confirms only the two foreign keys above.