Search Results gender_txt

Overview

IGF.IGF_AP_MATCH_DETAILS is a transactional table in the Oracle E-Business Suite 12.1.1 / 12.2.2 Financial Aid (IGF) schema. It stores the attribute-level results of the matching process that compares an incoming student record — an ISIR (Institutional Student Information Record) or a Profile record — against an existing person record already held in the system. Where the incoming record does not produce a complete match and instead resolves to a partial or "soft" match, this table captures exactly which demographic attributes matched and which did not, together with a cumulative numeric score. It therefore acts as the audit and scoring ledger behind the person-matching logic used during financial aid data load and verification.

From a Data Vault modelling perspective, the metadata classifies this object as satellite-leaning. This is a reasonable heuristic suggestion: the table is neither a pure hub of business keys nor a linking table, but rather a descriptive satellite that hangs off the person match context and records measurable outcomes (individual attribute match flags and an aggregate score) at a point in time. Its natural parent is the person match header, to which it is joined through the APM_ID foreign key.

Key Information Stored

The table is defined with 28 columns and a single-column primary key. The most important of these are:

• AMD_ID — the surrogate primary key (NUMBER(15)) enforcing uniqueness for each match-detail row. Note that this column is documented with a non-unique index (IGF_AP_MATCH_DETAILS_U1) in the metadata, an anomaly worth verifying in any given deployment.
• APM_ID — the foreign key to IGF_AP_PERSON_MATCH_ALL, tying each detail row to its parent person-match record. It is the leading column of index IGF_AP_MATCH_DETAILS_N1, jointly with PERSON_ID.
• PERSON_ID — the system person identifier against which the incoming record was evaluated.
• The attribute match flags — SSN_MATCH, GIVEN_NAME_MATCH, SURNAME_MATCH, DOB_MATCH, ADDRESS_MATCH, CITY_MATCH, ZIP_MATCH, GENDER_MATCH, EMAIL_ID_MATCH — each indicating whether the profile or ISIR attribute agreed with the corresponding person record. In particular, ZIP_MATCH flags agreement on the postal code.
• The corresponding captured text — SSN_TXT, GIVEN_NAME_TXT, SUR_NAME_TXT, BIRTH_DATE, ADDRESS_TXT, CITY_TXT, ZIP_TXT, GENDER_TXT, EMAIL_ID_TXT — the actual incoming values being compared.
• MATCH_SCORE — the total weighted score across all defined attributes for a given system-versus-profile record comparison.
• RECORD_STATUS — the matching status of the profile or ISIR record, indexed by IGF_AP_MATCH_DETAILS_N2 and therefore a common filter predicate.
• The standard WHO audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN.

AMD_ID functions as the technical key, while the combination APM_ID + PERSON_ID is the most practical business-key candidate for retrieval. There is no documented unique index guaranteeing a single detail row per match/person pair.

Common Use Cases and Queries

The principal use case is diagnosing why a particular student record was treated as a partial match rather than confirmed or rejected. Because each matching attribute is stored independently, analysts can reconstruct the decision and the score that drove it. A typical query joins the detail rows to the match header:

• List all attribute flags and scores for a match: SELECT d.amd_id, d.apm_id, d.match_score, d.record_status, d.ssn_match, d.zip_match, d.zip_txt FROM igf.igf_ap_match_details d WHERE d.apm_id = :p_apm_id;
• Find records where the postal code agreed but other critical attributes did not: SELECT * FROM igf.igf_ap_match_details WHERE zip_match = 1 AND ssn_match = 0 AND record_status = 'PARTIAL';
• Rank candidate matches by score for a person: SELECT person_id, match_score FROM igf.igf_ap_match_details WHERE record_status = 'PARTIAL' ORDER BY match_score DESC;
• Audit history by operator and date using the WHO columns to determine who ran the match and when.

Reporting uses include match-quality dashboards, identification of systematically weak attributes (for example, frequent ZIP_MATCH failures caused by stale address data), and reconciliation of ISIR loads where ISIR_ZIP_TXT is present but ZIP_MATCH is set to zero. The text columns are also useful for data-quality extracts because they preserve the values as received.

Related Objects

• IGF_AP_PERSON_MATCH_ALL — the parent object referenced by the APM_ID foreign key; the primary header-level record of the person match.
• IGF_AP_MATCH_DETAILS_N1, _N2, _U1 — the supporting indexes on APM_ID/PERSON_ID, RECORD_STATUS, and AMD_ID respectively.
• IGF_AP_PERSON_MATCH — the logical match entity with which this detail table is associated through the _ALL synonym.
• PER_PERSON_NAMES_F / PER_ALL_PEOPLE_F — joined via PERSON_ID to confirm the identity of the system record.
• IGF_AP_ISIR_* and Profile ISIR tables — the source of the incoming data whose attributes are recorded in the _TXT columns.

Collectively, these objects allow the match header, the system person, and the incoming ISIR or Profile data to be correlated into a complete audit trail.