Results for “group_student_id”

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

Overview

The IGS.IGS_AZ_ADVISING_RELS table is a core relationship table within the IGS (Student System) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the combinations of students and advisors across the various advising groups defined in an institution's academic structure. In practical terms, the table records which advisor is associated with which student, and under which advising group that relationship applies. This supports academic advising workflows such as assignment of advisors, tracking of active advising relationships over time, and reporting on advisor workloads.

The object is documented as VALID in the IGS schema, with a documented physical structure of 11 columns in ETRM 12.1.1. The metadata classifies this object heuristically, via its foreign key structure, as a standalone Data Vault classification. As a modeling suggestion, this implies the table behaves largely as a link-style association capturing relationships between two independent entities — advisors and students — rather than as a pure hub or satellite. Institutions adopting Data Vault or dimensional modeling may wish to treat it as a link between the advisor and student hubs, with effective-dating attributes forming a satellite.

Key Information Stored

The primary key is the surrogate column GROUP_ADVISING_REL_ID, enforced by the IGS_AZ_ADVISING_RELS_PK constraint. A unique index, IGS_AZ_ADVISING_RELS_U1, defines a business-key candidate across GROUP_NAME, GROUP_ADVISOR_ID, GROUP_STUDENT_ID, and START_DATE, meaning the same advisor-student pairing within a group cannot commence twice from the same start date.

• GROUP_ADVISING_REL_ID — surrogate primary key uniquely identifying each advising relationship record.
• GROUP_NAME — the advising group to which the relationship belongs.
• GROUP_ADVISOR_ID — foreign key referencing IGS_AZ_ADVISORS, identifying the advisor.
• GROUP_STUDENT_ID — foreign key referencing IGS_AZ_STUDENTS, identifying the student.
• START_DATE — the effective start of the advising relationship; part of the business-key candidate.
• END_DATE — the effective end of the relationship, supporting temporal validity and historically accurate reporting.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN capture standard EBS who/when audit information.

Common Use Cases and Queries

Typical uses include identifying a student's current advisor, listing all students assigned to a given advisor, and analyzing advisor distribution across advising groups. Because the table is effective-dated, queries should constrain on START_DATE and END_DATE to obtain active relationships.

• Current advisors for a student: join to IGS_AZ_ADVISORS and filter where GROUP_STUDENT_ID = :student_id and the current date falls between START_DATE and END_DATE (or END_DATE IS NULL).
• Advisor workload: aggregate counts of GROUP_STUDENT_ID per GROUP_ADVISOR_ID for active relationships.
• Historical advising audit: query without date filters to trace the complete advising history for a student or group.
• Group membership reporting: group by GROUP_NAME to summarize advising activity across organizational advising units.

Related Objects

The table participates in two documented foreign key relationships and is otherwise standalone. The most significant related objects are:

• IGS_AZ_ADVISORS — referenced via GROUP_ADVISOR_ID; supplies advisor identity.
• IGS_AZ_STUDENTS — referenced via GROUP_STUDENT_ID; supplies student identity.
• IGS_AZ_ADVISING_RELS_PK — the primary key constraint on GROUP_ADVISING_REL_ID.
• IGS_AZ_ADVISING_RELS_U1 — the unique index enforcing the group, advisor, student, and start-date business key.

Because the metadata records no downstream foreign keys referencing this table, dependent views, PL/SQL APIs, and concurrent programs are not enumerated in the source and should be validated against the specific 12.1.1 or 12.2.2 installation.