Search Results msd_dp_dimensions_u1




Overview

MSD.MSD_DP_DIMENSIONS is a Demand Planning configuration table in the Oracle E-Business Suite (EBS) Advanced Supply Chain Planning / Demand Planning schema (MSD). It stores the association between the Demand Plan user-defined dimensions (DP dimensions) and the real/canonical Demand Planning Server dimensions (real dimensions). In effect, it is the mapping table that tells the Demand Planning engine which user-facing dimension corresponds to which underlying server dimension within the context of a specific Demand Plan.

The table is owned by the MSD schema, resides in the APPS_TS_TX_DATA tablespace (with its unique index in APPS_TS_TX_IDX), and has a status of VALID in ETRM 12.2.2, with a documented schema of 15 columns. The primary key is MSD_DP_DIMENSIONS_PK on (DEMAND_PLAN_ID, DIMENSION_CODE, DP_DIMENSION_CODE), and it carries a foreign key from DEMAND_PLAN_ID to MSD.MSD_DEMAND_PLANS.

Heuristically, the relationship data classifies this object as satellite-leaning. This is a modeling suggestion: the table appears to hold descriptive, context-dependent attributes (the mapping and flags) that hang off a parent business key (the Demand Plan), rather than acting as an independent hub or a pure association link. Analysts building a Data Vault model should treat DEMAND_PLAN_ID as a reference to the Demand Plan hub, with the dimension mapping attributes treated as satellite payload.

Key Information Stored

The most significant columns fall into three functional groups: identifiers, mapping values, and control flags.

  • DEMAND_PLAN_ID (NUMBER) — the Demand Plan unique identifier and a component of the primary key and foreign key to MSD_DEMAND_PLANS.
  • DIMENSION_CODE (VARCHAR2) — the Demand Planning Server dimension; also part of the primary key.
  • DP_DIMENSION_CODE (VARCHAR2) — the Demand Plan user dimension; part of the primary key.
  • DELETEABLE_FLAG (VARCHAR2, 15) — indicates whether the record can be deleted.
  • ENABLE_NONSEED_FLAG (VARCHAR2, 15) — indicates whether fields for this record should be disabled for non-seeded records.
  • ZD_EDITION_NAME — the editioning column documented in the 12.2.2 physical schema, enabling Online Patching (Edition-Based Redefinition).
  • Standard WHO columnsLAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN.
  • Enhanced WHO columnsREQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, which capture the concurrent program context that created or updated the row.

The surrogate/primary key is MSD_DP_DIMENSIONS_PK on (DEMAND_PLAN_ID, DIMENSION_CODE, DP_DIMENSION_CODE). The documented unique business-key candidate index is MSD_DP_DIMENSIONS_U1, which spans (DEMAND_PLAN_ID, DIMENSION_CODE, DP_DIMENSION_CODE, ZD_EDITION_NAME) in the 12.2.2 schema — this matches the user's search for "msd_dp_dimensions_u1".

Common Use Cases and Queries

Typical use cases include reporting on which user dimensions are enabled for a given Demand Plan, auditing dimension configuration changes, and resolving user-friendly dimension labels to their server dimension counterparts in downstream extractions. Because the table is keyed by plan and dimension, queries generally filter on DEMAND_PLAN_ID.

A common reporting pattern retrieves all dimension mappings for a plan:

  • SELECT DEMAND_PLAN_ID, DP_DIMENSION_CODE, DIMENSION_CODE FROM MSD.MSD_DP_DIMENSIONS WHERE DEMAND_PLAN_ID = :plan_id;

An audit query can surface recently changed mappings using the WHO columns:

  • SELECT DEMAND_PLAN_ID, DP_DIMENSION_CODE, DIMENSION_CODE, LAST_UPDATE_DATE, LAST_UPDATED_BY FROM MSD.MSD_DP_DIMENSIONS WHERE LAST_UPDATE_DATE >= :since_date ORDER BY LAST_UPDATE_DATE DESC;

Analysts diagnosing dimension mismatches may join the mapping to the plan definition to confirm the owning plan, and may check DELETEABLE_FLAG and ENABLE_NONSEED_FLAG to determine whether a mapping can be modified or is locked by seeding.

Related Objects

MSD.MSD_DP_DIMENSIONS participates in a small but important dependency set:

  • MSD.MSD_DEMAND_PLANS — referenced by the foreign key on DEMAND_PLAN_ID; the parent plan definition.
  • MSD_DP_DIMENSIONS (APPS synonym/view) — the APPS-level access object used by application code.
  • MSD_VALIDATE_DEMAND_PLAN — a dependent object that consumes this table during demand plan validation.
  • MSD_DP_DIMENSIONS_U1 — the unique index enforcing the business key across plan, dimensions, and edition.
  • MSD_DP_DIMENSIONS_PK — the primary key constraint on the three identifier columns.

The documented FK shows no additional outward references, so the principal join is to MSD_DEMAND_PLANS via DEMAND_PLAN_ID. Any custom query or interface touching dimension mappings should honor the composite key and the editioning column when operating under 12.2.2 Online Patching.