Search Results advising_code




Overview
Explore in AI Chat

Overview

The IGS_AZ_GROUPS table belongs to the IGS - Student System product family, a legacy Oracle EBS module that is now classified as obsolete. Its documented purpose is to store advising group definitions, meaning each row represents a named configuration unit that governs how academic advising is delivered, tracked, and automated for a defined population of students and advisors. Within the broader IGS schema, this table functions as a configuration and control record rather than a high-volume transactional table; it defines the rules that downstream advising processes reference.

The supplied ETRM metadata records a heuristic Data Vault classification of "satellite-leaning" for this object. Treated as a modeling suggestion only, this implies the table behaves primarily as a descriptive satellite attached to one or more business keys, carrying a wide set of attributes that qualify those keys over time. It is not classified as a hub or a link, which is consistent with its 49-column descriptive profile and its single documented foreign key relationship. Note that the ETRM excerpt explicitly states "Not implemented in this database," and the product itself is flagged obsolete, so references to this table in a running 12.1.1 or 12.2.2 instance should be verified rather than assumed.

Key Information Stored

The primary key is defined by the unique index IGS_AZ_GROUPS_PK on the GROUP_NAME column. GROUP_NAME is therefore the documented business-key candidate as well as the physical primary key; there is no separate surrogate identifier column documented. The most significant columns include:

Common Use Cases and Queries

Reporting on advising group configuration is the principal use case. Administrators and analysts typically retrieve group definitions with their delivery method, responsible party, and automation status.

  • Listing active groups: SELECT group_name, group_desc, delivery_method_code, resp_person_id FROM igs_az_groups WHERE closed_flag = 'N';
  • Auditing automated membership behavior: SELECT group_name, auto_stdnt_add_flag, auto_stdnt_remove_flag, auto_match_flag FROM igs_az_groups;
  • Reconciling groups to locations: SELECT g.group_name, l.description FROM igs_az_groups g, igs_ad_location_all l WHERE g.location_cd = l.location_cd;
  • Extracting flexfield data using attribute_category and the attribute1..attribute20 columns for institution-specific extensions.

Given the obsolete status and the "not implemented" note, queries should be preceded by a dictionary check against ALL_TABLES before being relied upon.

Related Objects

The documented foreign key relationship defines the primary structural dependency: IGS_AZ_GROUPS.LOCATION_CD references IGS_AD_LOCATION_ALL, the location definition table. This makes IGS_AD_LOCATION_ALL the most significant related object, providing validation of the location context for each advising group. Additional integration points, drawn from the IGS Student System domain and the column naming in the documented schema, include the advisor and student group reference objects implied by ADVISOR_GROUP_ID and STUDENT_GROUP_ID, the personal and organization reference objects implied by RESP_PERSON_ID and RESP_ORG_UNIT_CD, and the entity that owns the primary key through IGS_AZ_GROUPS_PK on GROUP_NAME. Where these referenced tables exist, joins should be constructed on the specific identifier columns named above rather than assumed generic IDs, since only the LOCATION_CD relationship is formally documented in the ETRM metadata.