Results for “dflt_cat_ind”

31 results




Overview
Explore in AI Chat

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

Overview

The IGS_CO_CAT_MAP table belongs to the IGS – Student System product family within Oracle E-Business Suite. It is documented as an obsolete object, meaning it is retained for historical schema reference but is not implemented in the current database and is no longer actively used by the application. Functionally, the table describes the mappings between correspondence categories and admission categories. These mappings act as a restriction mechanism: they govern which correspondence categories may be allocated to students, based on the admission category the student belongs to.

From a data-modeling perspective, the heuristic Data Vault classification for this table is link. This classification is derived from the foreign-key structure, which shows the table primarily resolving a many-to-many style relationship between two independent entities (correspondence categories and admission categories) rather than storing descriptive attributes of a single business entity. The link interpretation is a modeling suggestion, not an application-declared role.

Key Information Stored

The table is defined with eight documented columns in the ETRM 12.1.1 schema, owned by the IGS schema. The most significant columns and their roles are as follows:

  • CORRESPONDENCE_CAT – Identifies the correspondence category being mapped. This is a foreign key to IGS_CO_CAT.
  • ADMISSION_CAT – Identifies the admission category to which a correspondence category is restricted. This is a foreign key to IGS_AD_CAT_ALL.
  • DFLT_CAT_IND – An indicator flag denoting whether the mapped correspondence category is the default category for the associated admission category.
  • CREATED_BY – The application user who created the mapping record.
  • CREATION_DATE – The timestamp when the mapping record was created.
  • LAST_UPDATED_BY – The application user who last modified the mapping record.
  • LAST_UPDATE_DATE – The timestamp of the most recent modification to the record.
  • LAST_UPDATE_LOGIN – The login identifier associated with the last update, used for audit and concurrency tracking.

The primary key is defined by IGS_CO_CAT_MAP_PK, composed of CORRESPONDENCE_CAT and ADMISSION_CAT. A unique index, IGS_CO_CAT_MAP_U1, also covers these same two columns, making them the business-key candidate. The primary key is therefore a composite natural key rather than a surrogate identifier.

Common Use Cases and Queries

Although the table is obsolete, it remains relevant for historical data analysis, migration validation, and understanding legacy admissions configuration. Typical scenarios include identifying which correspondence categories are permitted for a given admission category and confirming default assignments.

A representative query listing all mappings for a specific admission category:

  • SELECT correspondence_cat, admission_cat, dflt_cat_ind FROM igs_co_cat_map WHERE admission_cat = :admission_cat;

Joining to the parent correspondence category table to enrich results:

  • SELECT m.admission_cat, m.correspondence_cat, c.description FROM igs_co_cat_map m JOIN igs_co_cat c ON c.correspondence_cat = m.correspondence_cat;

Detecting default assignments:

  • SELECT admission_cat, correspondence_cat FROM igs_co_cat_map WHERE dflt_cat_ind = 'Y';

Auditing historical changes relies on the standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE).

Related Objects

The table participates in two documented foreign-key relationships, which define its most significant related objects:

  • IGS_CO_CAT – Parent table for correspondence categories, joined on IGS_CO_CAT_MAP.CORRESPONDENCE_CAT = IGS_CO_CAT.CORRESPONDENCE_CAT.
  • IGS_AD_CAT_ALL – Parent table for admission categories, joined on IGS_CO_CAT_MAP.ADMISSION_CAT = IGS_AD_CAT_ALL.ADMISSION_CAT.

These two tables supply the domain values that the mapping links together. Because the table is obsolete and not implemented, no additional dependent views, APIs, or child tables are documented in the ETRM metadata. Any integration or reporting that references this object should be treated as historical and validated against the current student-system data model.