Search Results estab_name




Overview

IGS.IGS_UC_APP_REFEREES is a transactional table in the Oracle E-Business Suite 12.1.1 / 12.2.2 IGS (Student Systems / Admissions) schema that stores UCAS applicant reference details. UCAS (Universities and Colleges Admissions Service) references are the supporting academic endorsements submitted on behalf of an applicant by a referee, typically a teacher, tutor, or employer, and this table persists the referee identity, the referee's establishment, contact details, and the narrative and predicted-grade content associated with the reference. The table is classified as VALID and is registered in FND Design Data as IGS.IGS_UC_APP_REFEREES, confirming it is a supported, documented application object.

From a modeling perspective, the mined relationship data classifies this object heuristically as a standalone structure rather than a hub, link, or satellite. Because it carries the composite business key (APP_NO, REFEREE_NAME) together with descriptive, ref-attribute-style columns, it can reasonably be treated as a satellite-of-the-applicant construct in a Data Vault-style model, though no explicit foreign key links are documented to enforce that interpretation. Physically, the table resides in the APPS_TS_TX_DATA tablespace with PCTFREE 10, and its indexes are split between APPS_TS_TX_IDX for the primary key and APPS_TS_TX_DATA for the LOB index.

Key Information Stored

The table comprises 18 documented columns. The columns most relevant to reference processing are:

  • APP_NO (NUMBER, 22) — Applicant number; the primary linking attribute to the applicant record and the first column of the composite primary key.
  • REFEREE_NAME (VARCHAR2, 50) — Referee name; the second column of the composite primary key and a mandatory business identifier.
  • REFEREE_POST (VARCHAR2, 35) — The referee's post or position held at the establishment.
  • ESTAB_NAME (VARCHAR2, 60) — Establishment name; the column matched in the user's search. It holds the name of the school, college, or organisation the referee represents and is a principal descriptive attribute for the reference.
  • ADDRESS1 through ADDRESS4 (VARCHAR2, 50 each) — Free-text address lines for the referee's establishment or correspondence address.
  • TELEPHONE, FAX (VARCHAR2, 35 each) — Voice and facsimile contact numbers for the referee.
  • EMAIL (VARCHAR2, 60) — Referee email address, used for electronic verification and correspondence.
  • STATEMENT (CLOB, 4000) — The electronic application statement, i.e. the referee's free-text supporting narrative.
  • PREDICTED_GRADES (VARCHAR2, 150) — Predicted qualification grades supplied by the referee.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO audit columns.

The surrogate-style unique index IGS_UC_APP_REFEREES_PK is defined on (APP_NO, REFEREE_NAME), which is therefore the documented business-key candidate. A second unique index, SYS_IL0000328082C00012$$, is the LOB index automatically created for the STATEMENT CLOB, not a business key.

Common Use Cases and Queries

Admissions and CRM reporting typically retrieves reference information per applicant for review panels, verification workflows, and UCAS submission audits. Searching by establishment name is common when institutions want to see which referees or schools are associated with a given cohort.

SELECT APP_NO
     , REFEREE_NAME
     , REFEREE_POST
     , ESTAB_NAME
     , EMAIL
     , PREDICTED_GRADES
  FROM IGS.IGS_UC_APP_REFEREES
 WHERE UPPER(ESTAB_NAME) LIKE UPPER('%' || :p_estab_name || '%');

A second pattern joins this table back to the applicant to enrich admissions dashboards:

SELECT i.APP_NO
     , i.REFEREE_NAME
     , i.ESTAB_NAME
     , i.PREDICTED_GRADES
     , i.STATEMENT
  FROM IGS.IGS_UC_APP_REFEREES i
 WHERE i.APP_NO = :p_app_no;

Additional use cases include referee contact lists for outreach, reconciliation of received versus expected references, and extraction of CLOB statements for document archival. Because STATEMENT is a CLOB, reporting layers should handle it with DBMS_LOB operations rather than plain concatenation.

Related Objects

The documented dependency output states that IGS_UC_APP_REFEREES does not reference any database object, meaning no foreign keys are declared from this table to other tables. It is referenced only by the APPS synonym IGS_UC_APP_REFEREES. Lacking declared FK relationships, associations must be established logically rather than through constraints. The most significant related objects are therefore:

  • IGS.IGS_UC_APP_REFEREES (APPS synonym) — the synonym through which application code and reports access the table.
  • The UCAS applicant table — the natural parent of this data, joined on APP_NO, which carries the applicant-level attributes the reference enriches.
  • IGS_UC_APP_REFEREES_PK — the unique index on (APP_NO, REFEREE_NAME) that enforces one reference per named referee per applicant.
  • SYS_IL0000328082C00012$$ — the LOB index supporting the STATEMENT CLOB, maintained automatically with the table.

Because the dependency metadata records no outgoing references, integrators should not rely on database-enforced integrity when joining APP_NO to applicant-centric tables; the relationship must be validated by convention and application logic.