Search Results advising_rel_id

Overview

IGS_AZ_ADVISING_RELS_V is a Web-view object owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It is registered in the FND Design Data repository as IGS.IGS_AZ_ADVISING_RELS_V and carries a VALID status. As the name implies, the view belongs to the IGS (Intelligent Graduate System / Student System) product family and exposes the advisor-to-student relationship information maintained by the advising functionality within the institution's academic structure.

The view is explicitly classified as a Web view, a form of database view designed to simplify access from Oracle Self-Service Web Applications. Its purpose is to flatten the normalized advising relationship data into a single, denormalized row set that self-service and reporting consumers can query without needing to understand the underlying entity relationships. Each row represents one advising relationship, pairing a named advisor with a named student within a defined advising group and over a defined validity period.

Because the view resolves surrogate identifiers into descriptor fields (group name, student name, advisor name), it is particularly well suited to personalized dashboards, advisor lookup pages, and operational reports where a human-readable listing is more useful than raw ID values.

Underlying Base Objects

The ETRM documentation for this view does not enumerate the referenced base objects in the excerpt provided. The dependency section is truncated, and no explicit underlying tables are listed in the documented view metadata. Consistent with standard IGS advising data model conventions, the view is understood to be defined over the advising relationship and advising group entity tables in the IGS schema, joined to person and party name sources in order to resolve the STUDENT_NAME and ADVISOR_NAME columns and the corresponding person number values.

Practically, this means the view functions as a convenience layer: the base tables store the primary keys (advising relationship IDs, group IDs, person IDs), while the view performs the joins and concatenations necessary to present descriptive output. Administrators querying the view only require SELECT privilege on APPS.IGS_AZ_ADVISING_RELS_V; they do not need direct grants on the underlying IGS tables. Because the metadata is limited, DBAs reviewing this object for customization or performance tuning should confirm the exact base objects using ALL_DEPENDENCIES or the compiled view text in the data dictionary.

Key Columns

The view exposes eighteen columns, including the standard WHO audit columns. The most operationally significant are:

• ADVISING_REL_ID — the numeric, sequence-generated relationship identifier. This is the primary key of the advising relationship and is the value most commonly searched by developers and support personnel.
• GROUP_NAME — the name of the advising group to which the relationship belongs.
• STUDENT_NAME and STUDENT_NUMBER — the name and person number of the student in the relationship.
• ADVISOR_NAME and ADVISOR_NUMBER — the name and person number of the advisor in the relationship.
• RELATION_START_DATE and RELATION_END_DATE — the effective date range of the advising relationship.
• GROUP_ADVISOR_ID and GROUP_STUDENT_ID — identifiers linking the participants to their advising group records.
• STUDENT_PERSON_ID and ADVISOR_PERSON_ID — the underlying person identifiers used to join to person and party tables.
• ROW_ID — the ROWID pseudo-column, exposed for Web-view processing.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.

Common Use Cases and Queries

Typical consumers of this view include self-service advising pages, administrative reports, and integration extracts that need advisor-student mappings. A frequent requirement is to resolve a single relationship identifier:

• SELECT * FROM APPS.IGS_AZ_ADVISING_RELS_V WHERE advising_rel_id = :rel_id;
• SELECT advisor_name, student_name, relation_start_date, relation_end_date FROM APPS.IGS_AZ_ADVISING_RELS_V WHERE student_number = :student_number AND (relation_end_date IS NULL OR relation_end_date > SYSDATE);
• SELECT group_name, COUNT(*) FROM APPS.IGS_AZ_ADVISING_RELS_V GROUP BY group_name;

Because the view performs name resolution joins, queries should filter by the indexed identifier columns where possible rather than scanning on the descriptive name columns. Reports filtering on ACTIVE relationships should test RELATION_END_DATE for NULL or a future date, as ending a relationship is recorded by populating that column. As with all APPS Web views, the object should be treated as read-only in custom code, and its columns may change between patch levels.