Search Results parent_org_unit_code




Overview
Explore in AI Chat

Overview

IGSBV_ORG_UNIT_HIERARCHIES is a read-only reporting view within the Oracle E-Business Suite IGS (Student System) product family, documented as obsolete in ETRM 12.2.2. The view exposes the parent-to-child relationships that exist between organizational units, allowing a single organizational unit to participate simultaneously as a parent of many children and as a child of many parents. This many-to-many structure is characteristic of academic and administrative hierarchies, where faculties, departments, schools, and cost centers may be nested or cross-linked in ways that a strict tree cannot represent.

Because it is a Business View (the "BV" naming convention), IGSBV_ORG_UNIT_HIERARCHIES is intended for query and reporting access rather than for direct transactional maintenance. The view is defined with the WITH READ ONLY clause, which prevents DML through the view and confirms its role as a reporting and integration surface. The underlying data is owned by the base entity IGS_OR_UNIT_REL, and the view presents a denormalized column naming layer over that table, converting abbreviated column names such as PARENT_ORG_UNIT_CD into more readable forms such as PARENT_ORG_UNIT_CODE.

Underlying Base Objects

The documented base table for this view is IGS_OR_UNIT_REL, which stores organizational unit relationship records. The view text is a straightforward projection:

  • SELECT ... FROM IGS_OR_UNIT_REL WITH READ ONLY

No additional joins, filters, or derived expressions are applied. The view is therefore a renamed column projection of the base relationship table, and its row count and content are identical to IGS_OR_UNIT_REL. No base objects beyond IGS_OR_UNIT_REL are documented in the ETRM metadata. Note that the metadata records the view as "Not implemented in this database," meaning it is not deployed in the reference environment against which the ETRM documentation was generated.

Key Columns

The view exposes ten columns. The first six are renamed projections; the final four are standard who-columns.

  • PARENT_ORG_UNIT_CODE (from PARENT_ORG_UNIT_CD) — identifier of the parent organizational unit in the relationship.
  • PARENT_START_DATE (from PARENT_START_DT) — the effective start date associated with the parent side of the relationship.
  • CHILD_ORG_UNIT_CODE (from CHILD_ORG_UNIT_CD) — identifier of the child organizational unit.
  • CHILD_START_DATE (from CHILD_START_DT) — effective start date for the child side of the relationship.
  • CREATE_DATE (from CREATE_DT) — application-level creation date recorded on the relationship record.
  • LOGICAL_DELETE_DATE (from LOGICAL_DELETE_DT) — the date on which the relationship was logically (soft) deleted. A NULL value indicates the relationship is currently active; a non-NULL value indicates the record has been superseded or retired but retained for audit and historical reporting. This column is the one most commonly used to distinguish current versus historical hierarchy membership.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — standard Oracle EBS audit columns recording the user and timestamp of insert and last modification.

Common Use Cases and Queries

Typical usage includes hierarchy traversal, active-membership reporting, and audit reconciliation. Because the view is read-only, all queries are SELECT statements.

Retrieving active parent-child relationships (excluding logically deleted rows):

  • SELECT PARENT_ORG_UNIT_CODE, CHILD_ORG_UNIT_CODE FROM IGSBV_ORG_UNIT_HIERARCHIES WHERE LOGICAL_DELETE_DATE IS NULL;

Finding all children of a given parent:

  • SELECT CHILD_ORG_UNIT_CODE FROM IGSBV_ORG_UNIT_HIERARCHIES WHERE PARENT_ORG_UNIT_CODE = :p_parent AND LOGICAL_DELETE_DATE IS NULL;

Auditing logical deletions within a date range:

  • SELECT PARENT_ORG_UNIT_CODE, CHILD_ORG_UNIT_CODE, LOGICAL_DELETE_DATE, LAST_UPDATED_BY FROM IGSBV_ORG_UNIT_HIERARCHIES WHERE LOGICAL_DELETE_DATE BETWEEN :from_date AND :to_date;

Given its obsolete status, the view should be treated as a legacy reporting artifact. Organizations still running the IGS Student System may continue to reference it, but no functional enhancements should be expected, and migration planning should account for its eventual retirement alongside the IGS application family.