Results for “igs_sc_obj_attribs”

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

Overview

IGS_SC_OBJ_ATTRIBS is a table in the IGS (Student System) product schema within Oracle E-Business Suite, documented as VALID in both the 12.1.1 and 12.2.2 releases. The table stores the information related to Security Object Attributes. In the context of the Oracle Student System, security is modelled around grantable objects, and attributes act as the named, definable characteristics that qualify how access to those objects is granted, constrained, or evaluated. Each row defines a single attribute that belongs to a security object group, providing the metadata layer against which grant conditions, permitted attribute methods, and permissible attribute values are expressed.

The ETRM metadata classifies this table, on a heuristic basis mined from its foreign key structure, as hub-leaning in a Data Vault model. This is offered as a modelling suggestion rather than a documented fact: the table carries a single-part surrogate primary key and is referenced by multiple dependent tables, which is characteristic of a hub entity whose business keys are the object group and attribute name. It is not a transactional or purely descriptive satellite, although it does carry standard audit and status columns.

Key Information Stored

The documented physical schema for 12.1.1 contains nine columns. The most significant are:

• OBJ_ATTRIB_ID — the surrogate primary key, enforced by the unique index IGS_SC_OBJ_ATTRIBS_PK. This is the identifier propagated to all dependent child tables.
• OBJ_GROUP_ID — the foreign key identifying the security object group to which the attribute belongs. Together with the attribute name, this forms the business-key candidate.
• OBJ_ATTRIB_NAME — the user-meaningful name of the security object attribute.
• ACTIVE_FLAG — indicates whether the attribute definition is currently active and therefore available for use in security grants.
• CREATION_DATE, CREATED_BY — standard audit columns recording row creation.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard audit columns recording the most recent modification and the login session that made it.

The second unique index, IGS_SC_OBJ_ATTRIBS_UK, is defined on the column pair (OBJ_GROUP_ID, OBJ_ATTRIB_NAME). This confirms that attribute names are unique only within the scope of their parent object group, and it represents the natural or business key of the entity. The surrogate OBJ_ATTRIB_ID is the value that should be used in joins; the business key should be used for identification and de-duplication logic.

Common Use Cases and Queries

Typical use cases centre on security configuration reporting and validation. Administrators and support analysts query this table to inventory the attributes defined for a given security object group, to identify inactive attributes that may still be referenced by grant conditions, and to reconcile attribute definitions against attribute values and methods. A common pattern joins the table to its parent object group and filters on ACTIVE_FLAG to list only usable attributes. Another pattern discloses attributes that have no associated values in IGS_SC_OBJ_ATT_VALS, which usually indicates incomplete configuration.

A representative query for auditing attribute configuration is:

• SELECT a.obj_attrib_id, a.obj_group_id, a.obj_attrib_name, a.active_flag, a.last_update_date FROM igs.igs_sc_obj_attribs a WHERE a.obj_group_id = :group_id ORDER BY a.obj_attrib_name;
• A business-key lookup uses the unique index: SELECT obj_attrib_id FROM igs.igs_sc_obj_attribs WHERE obj_group_id = :group_id AND obj_attrib_name = :name;
• A referential-integrity check counts dependent rows across the three child tables keyed on OBJ_ATTRIB_ID.

Because the table is small and configuration-oriented, it is generally safe to query directly; however, changes to attribute definitions should be made through the Student System security setup forms rather than by direct DML, since dependent rows in grant conditions and value tables must remain consistent.

Related Objects

The table participates in a clearly documented referential structure:

• IGS_SC_GRANT_CONDS — references IGS_SC_OBJ_ATTRIBS via OBJ_ATTRIB_ID. This is the most significant dependent, since grant conditions consume attribute definitions to qualify security grants.
• IGS_SC_OBJ_ATT_MTHS — references IGS_SC_OBJ_ATTRIBS via OBJ_ATTRIB_ID, holding the attribute methods applicable to each attribute.
• IGS_SC_OBJ_ATT_VALS — references IGS_SC_OBJ_ATTRIBS via OBJ_ATTRIB_ID, holding the permissible values for each attribute.
• IGS_SC_OBJ_ATTRIBS (self-referencing path) — the OBJ_GROUP_ID column links each attribute to its parent security object group, so the object group entity is the principal upward dependency.

In practice, any report or extraction dealing with Student System security grants will traverse IGS_SC_OBJ_ATTRIBS as the descriptive anchor between object groups and the three dependent tables named above. These four relationships constitute the documented dependency footprint of the table and should be preserved in any data migration or ETL design that reproduces IGS security configuration.