Deep Battle Cards G–L
G — Conceptual vs Logical vs Physical vs Canonical
- CDM: high-level concepts/relationships/scope.
- LDM: detailed tech-independent attributes/domains/keys.
- PDM: technology-specific storage implementation.
- Canonical: message/payload structure for data in motion.
Deciding distinction: Concept / Logic / Platform / Message.
Scenario: datatypes + indexes + partitioning → PDM. Shared Customer event payload across ten services → canonical.
Trap: canonical is not the enterprise database PDM.
H — Normalization vs Denormalization vs Views vs Partitions
Normalize: remove redundancy/dependency defects. Denormalize: intentionally duplicate/combine structures for justified physical need. View: alternate virtual presentation. Materialized view: stored/instantiated derived result. Partition: divide data physically by columns or rows.
Deciding distinction: clean dependency logic vs add redundancy vs present derived data vs split physical data.
Scenario: a non-key attribute depends on only part of a composite key → 2NF issue. Measured read performance is unacceptable after less risky options → denormalization may be justified.
Trap: “slow query” does not automatically mean denormalize.
Hook: Clean logic first; optimize physical second.
I — Generalization/Specialization vs Physical Subtype Resolution
Generalization: common features move up to supertype. Specialization: distinguishing features move into subtypes.
Physical choices: - Subtype absorption: one broad supertype table with nullable subtype columns. - Supertype partition: separate subtype tables carrying inherited properties.
Deciding distinction: logical inheritance first; table mapping second.
Trap: do not call subtype absorption “normalization.”
J — Forward vs Reverse Engineering
Forward: requirements → CDM → LDM → PDM.
Reverse: existing DB → PDM → LDM → CDM.
Purpose: build implementation from requirements vs recover/document meaning from implementation.
Deciding clue: what is the starting evidence?
Trap: reverse-engineered diagrams need business interpretation; a physical schema cannot reveal every intended business meaning by itself.
Hook: Forward builds down; Reverse explains up.
K — Model Pattern vs Industry Model vs Naming Standard
- Pattern: reusable generic structural solution.
- Industry model: broad pre-built industry reference requiring customization.
- Naming standard: rules for forming consistent logical/physical names.
Deciding distinction: structure / industry content / language rules.
Scenario: reusable Party–Role design → pattern. Banking reference model customized to local products → industry model. Rule that logical names use full business words → naming standard.
Trap: industry models accelerate discovery but do not replace local requirements.
L — Standards vs Design Review vs Version Control vs Scorecard
- Standards: what modelers are expected to do.
- Design review: is this specific model acceptable?
- Version/change control: what changed, why, when, who, where?
- Scorecard: how strong is the model across multiple quality dimensions?
Purpose: govern creation, approval, change, and quality over time.
Scenario: missing requirements despite neat diagram → Scorecard requirements/completeness. Unapproved semantic change with no history → version/change-control failure.
Trap: passing one review does not eliminate future maintenance/version control.
Hook: Rule / Gate / History / Measure.