Scenario Lab — 8–15
8 — Data in Motion Between Services
Ten applications exchange Customer payloads but every point-to-point interface uses a different structure.
Best: canonical model/message structure that systems map to/from.
Weaker: another custom payload for each pair.
Changed fact: if the problem is storage of Customer in one specific DBMS, use a database PDM instead.
9 — Reverse Engineer Reality
Documentation is obsolete; production database is accessible.
Best sequence: existing DB → reconstruct PDM → infer LDM → infer CDM, then reorganize and interpret with business knowledge.
Weaker: infer CDM directly from table names and assume physical structure equals business meaning.
Changed fact: new solution begins from approved requirements and no implementation exists → forward engineering.
10 — Subtype Implementation Decision
Logical School supertype has University and High School subtypes; PDM team wants one table.
Best: subtype absorption — subtype-specific attributes become nullable columns in one supertype table.
Weaker: call it normalization.
Changed fact: if separate subtype tables are required and each carries inherited supertype attributes → supertype partition.
11 — Surrogate Key Migration
Large composite natural key is replaced with generated Student_ID as PDM PK.
Best: preserve original natural/composite uniqueness as alternate key/constraint.
Weaker: drop natural uniqueness because surrogate is unique.
Changed fact: if stable natural key remains an effective chosen primary key and there is no physical reason for a surrogate, no replacement is required.
12 — Source Mapping Uncertainty
Analytics attribute appears in model but nobody knows which operational field supplies it.
Best: source-target mapping / lineage to identify source field and rule before treating the attribute as validated.
Weaker: keep it because stakeholders probably need it.
Changed fact: source is known but stakeholders disagree on meaning → business definition/stewardship issue rather than lineage first.
13 — Graph-Shaped Requirement
Need to traverse unpredictable numbers of connections among people and find nearest connections.
Best: NoSQL graph model/database recognition clue.
Weaker: key-value merely because both are NoSQL.
Changed fact: retrieve an opaque preference object by one known key with no traversal → key-value or document becomes stronger depending on structure.
14 — Naming Drift
Logical model uses CUST_NM; physical DB uses Customer Name with spaces.
Best: reverse the intent: logical names should favor meaningful business words; physical names adapt to approved DBMS conventions/constraints while retaining traceability.
Changed fact: logical Customer Name mapped to approved physical CUST_NM → source-aligned.
15 — Design Review Fails
Multidisciplinary review finds unresolved business-rule conflicts and does not approve model.
Best: rework and resubmit. If a final unresolved decision remains, the owner of the represented system/domain has decision authority under the source logic.
Weaker: approve because diagram is technically valid or because review meeting occurred.
Changed fact: review approved, then a new requirement arrives → model maintenance plus version/change control rather than failed-review correction.