Search Results per_jp_address_lookups




Overview
Explore in AI Chat

Overview

PER_JP_ADDRESS_LOOKUPS is a reference table owned by the HR schema within the PER (Human Resources) product family of Oracle E-Business Suite. It stores the lookup values used to validate and describe Japanese addresses, specifically the district-level address components that precede the postal code hierarchy. The object is documented as VALID in both 12.1.1 and 12.2.2 releases.

Because Japanese addressing traditionally follows a prefecture, city, and district (or machi/aza) progression that is not strictly derived from the postal code, Oracle maintains a dedicated lookup table to hold the district code and its corresponding native and phonetic name forms. This table therefore serves as the master source from which postal code records inherit their district identity.

Under a heuristic Data Vault classification mined from the foreign key structure, the table is hub-leaning. In modeling terms it behaves as a hub candidate: a small set of distinct business keys (DISTRICT_CODE) around which dependent records cluster. The descendant foreign key from PER_JP_POSTAL_CODES suggests that DISTRACTS_JP addresses act as the natural business key for downstream link or satellite structures.

Key Information Stored

The documented physical schema contains nine columns. The most consequential are:

  • DISTRICT_CODE — the unique business identifier and sole component of the primary key PER_JP_ADDRESS_LOOKUPS_PK. This is the value referenced by dependent postal-code records.
  • ADDRESS_LINE_1 — the primary address line rendered in Japanese characters, describing the district or locality.
  • ADDRESS_LINE_1_KANA — the phonetic (kana) representation of the same address line, used for sorting, search, and matching against phoenetic input.
  • DISTRICT_NAME_KANA — the phonetic form of the district name, again supporting kana-based retrieval and normalization.
  • CREATED_BY, CREATION_DATE — standard audit columns recording which user or process inserted the row and when.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — audit trail capturing the most recent modification and the login session that performed it.

The primary key is a surrogate-free, single-column business key; there is no synthetic ID column. The unique index PER_JP_ADDRESS_LOOKUPS_PK on DISTRICT_CODE is therefore simultaneously the primary key and the business-key candidate, simplifying lookups and joins.

Common Use Cases and Queries

The table is typically queried to resolve a district code to its native and phonetic names, or to drive list-of-values popups in Japanese address entry forms. A representative lookup follows:

  • SELECT DISTRICT_CODE, ADDRESS_LINE_1, ADDRESS_LINE_1_KANA, DISTRICT_NAME_KANA FROM PER_JP_ADDRESS_LOOKUPS WHERE DISTRICT_CODE = :p_district_code;
  • Joining to dependent postal codes: SELECT p.POSTAL_CODE, a.ADDRESS_LINE_1, a.DISTRICT_NAME_KANA FROM PER_JP_POSTAL_CODES p, PER_JP_ADDRESS_LOOKUPS a WHERE p.DISTRICT_CODE = a.DISTRICT_CODE;
  • Kana-based search and validation: SELECT * FROM PER_JP_ADDRESS_LOOKUPS WHERE ADDRESS_LINE_1_KANA LIKE :p_prefix || '%';

Reporting scenarios include mailing label generation for Japanese employees and third parties, address normalization for HR data cleansing, and extraction of district reference data into downstream master data hubs.

Related Objects

  • PER_JP_POSTAL_CODES — the principal dependent table. Its column DISTRICT_CODE carries a foreign key to PER_JP_ADDRESS_LOOKUPS, making this the primary inbound relationship in the documented model.
  • PER_JP_ADDRESS_LOOKUPS_PK — the unique index and primary key constraint enforcing uniqueness of DISTRICT_CODE.
  • PER (Human Resources) address and person-related tables that consume Japanese address values indirectly through the postal code relationship (for example, PER_ADDRESSES and location-related HR entities), where district resolution flows via PER_JP_POSTAL_CODES.
  • Standard HR date-tracked APIs and concurrent programs that load or seed Japanese address reference data during localization setup.

Because the documented metadata identifies only one explicit foreign key path, the above reflects the confirmed relationship plus the immediate enclosing HR address context; broader dependencies are inferred from the PER product family rather than asserted as documented constraints.