Results for “as_contact_hobbies”

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

Overview

AS_CONTACT_HOBBIES is a Sales Foundation (AS) table owned by the OSM schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores hobby and personal-interest information associated with contacts, extending the core contact record beyond standard party and address attributes. The table holds ten documented columns and is classified by the ETRM metadata with a status of VALID. The object carries no foreign-key dependencies in the documented schema, and the heuristic Data Vault classification mined from that structure is standalone. From a modeling perspective, this suggests the table behaves independently rather than participating in a hub-and-link network; if a Data Vault or dimensional model were constructed, the table would most naturally map to a satellite or a child detail table hanging off a contact hub, since HOBBY_ID is its only documented primary-key component and no relationships are asserted.

The presence of WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) confirms that the table is maintained through standard Oracle EBS concurrent and form-based DML, with auditing handled by the applications schema conventions rather than the object itself.

Key Information Stored

The most significant columns documented are:

• HOBBY_ID — the single-column surrogate primary key, forming constraint AS_CONTACT_HOBBIES_PK. It uniquely identifies each hobby record and is the column referenced when the object was located via the AS_CONTACT_HOBBIES_PK search term.
• CONTACT_ID — the identifier linking the hobby row to its owning contact. Although no FK is documented in the ETRM metadata, this column is the practical business join key to the contact entity.
• HOBBY — the descriptive name or code of the hobby or interest itself; the principal business attribute of the row.
• DESCRIPTION — free-form supporting text elaborating on the hobby record.
• SINCE — a date-like attribute indicating when the contact adopted or began the hobby, providing temporal context for the interest.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard EBS audit columns recording who created and last modified each row, from which application or login, and when.

No unique index other than the primary key is documented, so HOBBY_ID should be treated as the only guaranteed unique key; CONTACT_ID plus HOBBY and SINCE may form a logical business key in practice but is not enforced by the documented metadata.

Common Use Cases and Queries

Typical usage centers on contact profiling and customer insight reporting. A standard lookup by contact might run as follows:

• SELECT hobby_id, contact_id, hobby, description, since FROM osm.as_contact_hobbies WHERE contact_id = :contact_id ORDER BY since DESC; — retrieves all interests for a given contact, newest first.
• SELECT hobby, COUNT(*) FROM osm.as_contact_hobbies GROUP BY hobby ORDER BY 2 DESC; — ranks the most frequently recorded hobbies across the contact base for marketing or segmentation analysis.
• Audit or delta extracts across a period: SELECT * FROM osm.as_contact_hobbies WHERE last_update_date >= :since_date; — supports incremental ETL and change tracking.
• Joins to the contact and party tables to enrich contact master reports with interest attributes.

Related Objects

The metadata documents the primary key AS_CONTACT_HOBBIES_PK but does not enumerate foreign keys, so related objects are inferred from the CONTACT_ID business column and standard EBS Sales Foundation patterns:

• AS_CONTACTS / HZ_CONTACTS — joined on CONTACT_ID, providing the owning contact record.
• HZ_PARTIES / HZ_PARTY_SITES — reached through the contact to resolve the party and location context.
• AS_CONTACT_HOBBIES_PK — the supporting primary-key index for direct HOBBY_ID lookups.
• AS_CONTACT_HOBBY_OTHER variants, if present in the schema, and other AS_* contact detail tables that follow the same child-table pattern.
• Standard WHO-column consumers such as user and application audit views used when reporting on CREATED_BY and LAST_UPDATED_BY.

Because no FK is documented, any referential integrity between these objects is enforced at the application layer rather than at the database level.