Search Results region_cd




Overview
Explore in AI Chat

Overview

IGS.IGS_OR_LOC_REGION is a persistent database table in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environments, owned by the IGS schema (the schema associated with Oracle's Higher Education / Student Systems product family). As documented in the ETRM metadata, the table "Stores the Region Information for a Location," making it a location-attribute association table that maps a location code to one or more region codes. In practice, this supports concepts such as admissions regions, recruiting territories, residency classification, or geographic reporting groupings tied to a specific location record.

The table carries only seven documented columns: two business data columns (LOCATION_CD and REGION_CD) and five standard "Who" audit columns. From a Data Vault modeling perspective, the metadata heuristic classifies this object as satellite-leaning. This is a modeling suggestion rather than a fixed rule: the table behaves like a descriptive satellite keyed to its parent location, since it holds descriptive region attributes that qualify a location rather than defining new independent business entities. It could also be modeled as a link if region is treated as a separate reference hub, but the documented structure is dominated by the parent-location dependency.

Key Information Stored

The most important columns and their roles are:

  • LOCATION_CD (VARCHAR2(10)) — The location code identifying the location whose region information is being stored. This is a foreign key to IGS.IGS_AD_LOCATION_ALL.LOCATION_CD.
  • REGION_CD (VARCHAR2(30)) — The region code assigned to that location. This is the column users search for ("region_cd"), and it holds the geographic or administrative region grouping.
  • CREATED_BY, CREATION_DATE — Standard Who columns recording the user and timestamp of row creation.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Who columns recording the last change, the responsible user, and the login session.

The composite primary key is IGS_OR_LOC_REGION_PK on (LOCATION_CD, REGION_CD). Because this unique index is also the business key, there is no separate surrogate key column documented; the location/region pair serves both as the natural identifier and the uniqueness constraint. This means a single location may be associated with multiple regions, but the same location-region combination cannot be duplicated.

Common Use Cases and Queries

Typical use cases include determining which region a given location belongs to, listing all locations assigned to a particular region, and auditing changes through the Who columns. A common reporting query joins the table to the location master to display descriptive location information alongside its region:

SELECT lr.LOCATION_CD, lr.REGION_CD, lr.LAST_UPDATE_DATE
FROM IGS.IGS_OR_LOC_REGION lr
WHERE lr.REGION_CD = :p_region_cd;

A reverse lookup retrieves all regions for a location:

SELECT REGION_CD
FROM IGS.IGS_OR_LOC_REGION
WHERE LOCATION_CD = :p_location_cd;

Because REGION_CD is the searched term, an application or report may filter on it directly; the composite index supports prefix access on LOCATION_CD and full key access on the pair, but not an index-only lookup on REGION_CD alone. Queries frequently filtering by REGION_CD alone should be reviewed for a supporting index in local implementations.

Related Objects

The most significant related objects are:

  • IGS.IGS_AD_LOCATION_ALL — The primary parent table. The FK relationship is IGS_OR_LOC_REGION.LOCATION_CD → IGS_AD_LOCATION_ALL.LOCATION_CD, so all location descriptive attributes are sourced from this table.
  • APPS.IGS_OR_LOC_REGION — The APPS-synonym view of the base table used by forms, concurrent programs, and reports in the EBS runtime.
  • IGS_OR_LOC_REGION_PK — The unique index enforcing the business key on (LOCATION_CD, REGION_CD).
  • Region reference objects — Any region definition/lookup entity used by the IGS product to validate REGION_CD values should be treated as a logical reference, even though it is not documented as a foreign key in the provided metadata.
  • IGS_AD_LOCATION_ALL audit and history components — Related location timeline/history tables that track changes to the parent location and can be joined for historical reporting.

All access should respect the documented tablespace placement (APPS_TS_TX_DATA for data, APPS_TS_TX_IDX for indexes) and the standard concurrency/audit conventions of the IGS schema.