Search Results eam_wo_relationships




Overview
Explore in AI Chat

Overview

EAM_WO_RELATIONSHIPS is a table in the Oracle Enterprise Asset Management (EAM) module, owned by the EAM schema. It stores the hierarchical and dependency relationships that exist between work orders and other EAM objects, allowing the application to model parent-child structures such as a parent work order that spawns multiple child work orders, or a work order that is linked to an activity, asset, or other schedulable entity. The table is documented as valid in both Oracle EBS 12.1.1 and 12.2.2, and its physical schema in ETRM 12.2.2 comprises 13 columns anchored by the primary key EAM_WO_RELATIONSHIP_ID_PK on WO_RELATIONSHIP_ID.

From a data-modeling perspective, the metadata classifies this object heuristically as a standalone entity rather than a strict hub, link, or satellite. In Data Vault terms, it is best treated as a relationship or link-style structure that captures associations between objects, since each row encodes a parent object, a child object, and the nature of the tie between them. Because no foreign keys are documented in the mined metadata, the classification remains heuristic and should be validated against the actual referential constraints in a given environment.

Key Information Stored

The most significant columns in EAM_WO_RELATIONSHIPS describe the endpoints of the relationship and its context:

The presence of TOP_LEVEL_OBJECT_ID is notable: it denormalizes the hierarchy's apex onto every row, which simplifies reporting on multi-level work order structures.

Common Use Cases and Queries

Typical usage centers on work order hierarchies and dependency reporting. A common query retrieves all children of a given parent work order:

  • SELECT WO_RELATIONSHIP_ID, CHILD_OBJECT_ID, CHILD_OBJECT_TYPE_ID, RELATIONSHIP_STATUS FROM EAM.EAM_WO_RELATIONSHIPS WHERE PARENT_OBJECT_ID = :parent_id;
  • Roll-up reporting can group by TOP_LEVEL_OBJECT_ID to count all descendants of a top-level work order without recursive queries.
  • Status filtering with RELATIONSHIP_STATUS isolates active dependencies from historical or cancelled links.
  • Joining to work order tables via PARENT_OBJECT_ID or CHILD_OBJECT_ID enriches relationship data with work order numbers, assets, and departments.

These patterns support maintenance scheduling, dependency validation, and audit reporting of how work orders were structured over time.

Related Objects

The following objects are most significant when working with EAM_WO_RELATIONSHIPS:

  • EAM_WORK_ORDERS (and its base table WIP_EAM_WORK_ORDERS) — joined via PARENT_OBJECT_ID and CHILD_OBJECT_ID to resolve work order detail.
  • EAM_WO_OPERATIONS — joined through object identifiers to relate operations to work order hierarchies.
  • EAM_WO_RELATIONSHIP_TYPES / object type lookups — referenced by PARENT_OBJECT_TYPE_ID and CHILD_OBJECT_TYPE_ID.
  • EAM_ACTIVITIES — often the child object in activity-to-work-order relationships.
  • EAM_ASSETS (EAM_ASSET_DEFINITIONS) — linked through object type resolution for asset-centric relationships.
  • EAM reporting views and APIs that expose work order hierarchy data, which read this table as the authoritative relationship store.