Deep Battle Cards A–F
Use these when several answers are plausible and you must identify the deciding feature.
A — Data Architecture vs Data Modeling & Design
Definition: Architecture identifies enterprise data needs and maintains master blueprints/alignment. Modeling & Design discovers, scopes, represents, and communicates precise data requirements and structures.
Purpose: architecture keeps enterprise direction coherent; modeling turns requirements into increasingly precise models.
Inputs/outputs: strategy and enterprise requirements → blueprints/roadmaps vs scoped data requirements → CDM/LDM/PDM, definitions, issues, lineage, physical design.
Deciding distinction: enterprise master blueprint/alignment vs detailed representation/design.
Scenario switch: “Establish enterprise target subject areas” → Architecture. Change to “resolve Customer–Order cardinality and keys” → Modeling & Design.
Trap: models can be architecture artifacts, but detailed model construction/review is still modeling work.
Hook: Architecture aligns; Modeling specifies.
B — Entity vs Instance vs Relationship vs Cardinality vs Arity
- Entity = type/concept.
- Instance = one occurrence.
- Relationship = association.
- Cardinality = allowed instance participation.
- Arity = number of entity types.
Deciding question: Are we naming what is modeled, which occurrence, the connection, how many occurrences, or how many types?
Scenario: “Each Course has many Students” gives cardinality on a binary Student–Course relationship. “Employee manages Employee” is unary arity even if many employees participate.
Trap: the word “many” describes cardinality, not arity.
Hook: what / which one / connection / how many / how many types.
C — Key Taxonomy: Construction vs Function
Construction: simple, composite, compound.
Function: super, candidate, primary, alternate, business, surrogate.
Purpose: explain both what a key is made of and what identification role it plays.
Scenario: (Order_ID, Product_ID) where both are FKs and together are minimally unique can be compound + composite + candidate; if chosen, primary.
Generated Student_ID can be surrogate primary while natural Student_Number remains business/alternate.
Trap: one key may have multiple simultaneous labels. Surrogate introduction does not erase natural uniqueness.
Hook: Build of the key vs Job of the key.
D — Relational vs Dimensional Modeling
Relational purpose: accurate operational business rules and stable normalized structure.
Dimensional purpose: intuitive/high-performance analysis around measured processes.
Inputs: transactions/rules vs analytic questions, measures, dimensions, grain.
Outputs: normalized relations/entities vs facts and dimensions.
Deciding distinction: is the dominant need transaction/business-rule integrity or analysis by descriptive perspectives?
Scenario switch: capture valid enrollment transactions → relational. Change to enrollment count by semester/campus → dimensional.
Trap: relationship lines mean different things in each scheme; dimensional lines primarily support navigation for analysis.
Hook: Relational runs the business; Dimensional asks the questions.
E — Fact vs Dimension vs Grain vs Conformance vs SCD
Fact: measured process. Dimension: descriptive context. Grain: meaning of one fact row. Conformed dimension: shared descriptive meaning. Conformed fact: shared standardized measure. SCD: history-handling for changing descriptive dimension values.
Deciding distinction: measure / “by what?” / row meaning / shared context / shared measure / history.
Scenario switches: all Address versions → Type 2. Sales and Enrollment share exact Campus definitions → conformed dimension. Standardized Net Revenue formula across marts → conformed fact.
Trap: never interpret a fact measure without understanding grain.
F — Six Modeling Schemes
| Scheme | Dominant purpose clue |
|---|---|
| Relational | operational rules |
| Dimensional | analytics |
| Object-Oriented | classes + behavior/methods |
| Fact-Based | facts/roles/verbalization |
| Time-Based | historization |
| NoSQL | storage/access shape |
Scenario switches: variable graph traversal → NoSQL graph. Controlled natural-language facts/roles → Fact-Based. Classes with public/private operations → Object-Oriented.
Trap: these are not maturity levels and no scheme is universally superior.
Hook: Rule / Analyze / Behave / Verbalize / History / Storage-shape.