Search Results igs_ad_disbl_type




Overview

The IGS_AD_DISBL_TYPE table is a foundational reference table within the Oracle E-Business Suite (EBS) Student System (IGS). Its primary role is to define and maintain a standardized list of disability classifications used across the student lifecycle. This table acts as a master source for valid disability types, ensuring data integrity and consistency when recording disability information for persons, typically applicants or enrolled students. It is critical for compliance reporting, student support services, and institutional research. Notably, the ETRM metadata explicitly classifies the IGS - Student System module as "Obsolete," indicating this table is part of a legacy codebase that may be deprecated or superseded in more recent versions of Oracle EBS or its successor applications.

Key Information Stored

While the provided ETRM excerpt does not list specific columns beyond the primary key, the table's structure can be inferred from its description and relationships. The core data stored includes the unique disability type code and its associated descriptive information. A typical structure would include:

  • DISABILITY_TYPE: The primary key column. This is a short code (e.g., 'VIS', 'AUD', 'MOB') that uniquely identifies a category of disability.
  • DESCRIPTION: A full textual name or description for the disability type (e.g., 'Visual Impairment', 'Hearing Impairment', 'Mobility Impairment').
  • Potential auxiliary columns for controlling data lifecycle (e.g., START_DATE, END_DATE, CLOSED_IND) and system auditing (CREATION_DATE, LAST_UPDATE_DATE).

The "Implementation/DBA Data" note stating "Not implemented in this database" suggests this specific table definition may not be present in a standard installation, possibly replaced by a flexfield or another configuration.

Common Use Cases and Queries

The primary use case is to validate and describe disability information. It is essential for generating accurate reports on student demographics for government compliance (e.g., ADA reporting) and internal resource allocation. Common SQL operations include joining to person disability records for reporting and enforcing referential integrity. A typical query to list all persons with their disability descriptions would be:

SELECT p.person_id, p.disability_type, t.description
FROM igs_pe_pers_disablty p, igs_ad_disbl_type t
WHERE p.disability_type = t.disability_type;

Another standard pattern is querying the reference table itself to obtain the list of valid codes for a user interface LOV (List of Values):
SELECT disability_type, description
FROM igs_ad_disbl_type
WHERE NVL(closed_ind, 'N') = 'N'
ORDER BY description;

Related Objects

The table's main relationship is defined by its foreign key constraint. It is referenced as a parent table to ensure that only valid, predefined disability types can be recorded against a person.

  • IGS_PE_PERS_DISABLTY: This is the primary transactional table that stores disability information for specific persons. Its DISABILITY_TYPE column is a foreign key that references IGS_AD_DISBL_TYPE.DISABILITY_TYPE. This relationship links a person's specific disability record to its official classification.

This relationship is critical; the IGS_AD_DISBL_TYPE table cannot be purged of codes that are in active use within the IGS_PE_PERS_DISABLTY table without violating this integrity constraint.