Skip to content

Rapid Battle Cards 31–38

31 — Associative Entity vs Ordinary Entity

  • Associative entity: resolves M:M (or higher-arity) relationship and can store relationship-specific facts.
  • Clue: the relationship itself needs identity/data, e.g. Registration Date for Student–Course.

32 — Subtype Absorption vs Supertype Partition

  • Absorption: one supertype table with subtype-specific nullable columns.
  • Partition: separate subtype tables carry inherited supertype attributes.
  • Clue: one broad table vs separate subtype tables.

33 — Natural Key Retained vs Surrogate PK

If a surrogate replaces a natural/composite PK, preserve original business uniqueness as an alternate key/constraint.

  • Clue: technical identity must not erase a business uniqueness rule.

34 — Data Model Pattern vs Industry Model

  • Pattern: reusable generic structure for recurring situations.
  • Industry model: broad pre-built reference for an industry, requiring customization.
  • Clue: generic structural solution vs industry-wide starting content.

35 — Logical Naming vs Physical Naming

  • Logical: meaningful, business-friendly full terms.
  • Physical: approved abbreviations/underscores/constraints of the DBMS.
  • Clue: business readability vs implementation constraints.

36 — Model Review vs Model Maintenance

  • Review: correctness/completeness/consistency quality checkpoint.
  • Maintenance: keep governed model synchronized as requirements/implementation change.
  • Clue: quality gate vs ongoing currency.

37 — Standards vs Design Review vs Version Control

  • Standards: rulebook / expected modeling practice.
  • Review: checkpoint on a specific model.
  • Version control: history of what changed and why.
  • Clue: rulebook vs gate vs history.

38 — Scorecard Completeness vs Structural Soundness

  • Completeness: are required things present and inappropriate extras absent?
  • Structural soundness: is the design structurally valid/buildable?
  • Clue: missing/extra vs structurally invalid.

Rapid Discrimination Drill

  1. Customer_ID is generated and meaningless; unique Email remains business-recognizable. Likely: surrogate primary key + business/alternate Email key.
  2. “One row = one student registration per class per day.” Concept: grain.
  3. Detailed attributes/domains/keys but no DBMS specifics. Level: LDM.
  4. Existing database is being documented upward into business meaning. Direction: reverse engineering.
  5. Reviewer asks whether a relational/dimensional/NoSQL model follows the rules of its declared scheme. Scorecard: match the model to its scheme/level.

← Cards 21–30 · Deep Cards A–F →