Skip to content

Lesson 8 — Governance, Data Model Scorecard, and Decision Rules

A data model is not complete because a modeling session ended. Chapter 5 treats models as governed assets that must be reviewed, controlled, and maintained.

Three governance control areas

1. Modeling and design standards

Standards are the rulebook: expected notation, naming, modeling practices, required Metadata, and related conventions.

2. Design review

A design review is a quality checkpoint for a specific model. Chapter 5 emphasizes correctness, completeness, and consistency.

A multidisciplinary review may involve modelers, analysts, business SMEs/stewards, architects, designers, DBAs, and system owners as appropriate.

If a review finds unresolved conflicts, the model is reworked rather than approved merely because a meeting occurred. When a final unresolved design decision remains, the owner of the system represented has the source-defined final authority.

3. Version / change control

Version control preserves change lineage. Record:

  • Why the change happened;
  • What / How changed;
  • When;
  • Who;
  • Where in the model/scope.

Memory hook: rulebook vs checkpoint vs history.

Review vs maintenance

Review tests quality at a point in time. Maintenance keeps the model synchronized as requirements, processes, and implementations change.

If teams alter physical tables directly and never update the logical/physical model, the organization no longer has trustworthy model Metadata.

Data Model Scorecard — 100 points

The current Mastery Lab preserves these ten categories and weights:

Category Points
Capture requirements 15
Completeness 15
Match the declared modeling scheme/level 10
Structural soundness 15
Appropriate use of generic structures 10
Naming standards 5
Readability 5
Definitions 10
Consistency with enterprise models 5
Metadata matches actual data 10
Total 100

A polished diagram can fail badly if requirements are missing. A complete-looking model can fail structural soundness. A model can score well on readability and naming but still fail because the actual database drifted away from the governed Metadata.

Scorecard distinction examples

  • Two required business facts are absent → capture requirements / completeness.
  • Model claims relational but violates the selected scheme’s structural rules → scheme fit.
  • Relationships/keys cannot produce a valid implementation → structural soundness.
  • Names are cryptic/inconsistent → naming.
  • Diagram is hard to read → readability.
  • Model says one thing but production stores another → Metadata matches actual data.

Twenty high-value deciding rules

  1. Data Architecture vs Modeling & Design: enterprise blueprint/alignment vs precise model/design work.
  2. Entity vs instance: type vs occurrence.
  3. Relationship vs foreign key: business association vs relational implementation mechanism.
  4. Cardinality vs arity: number of occurrences vs number of entity types.
  5. Attribute vs domain: property vs valid values.
  6. Simple/composite/compound/surrogate: one attr / 2+ / 2+ FKs / generated meaningless ID.
  7. Super/candidate/primary/alternate: any unique / minimal unique / chosen / unchosen candidate.
  8. Identifying vs non-identifying: migrated parent key enters child PK vs remains non-PK FK.
  9. Relational vs dimensional: operational business rules vs analytic navigation.
  10. Fact vs dimension: measurement vs descriptive context.
  11. Grain vs cardinality: fact-row meaning vs relationship participation.
  12. Star vs snowflake: collapsed vs normalized dimension structures.
  13. CDM vs LDM vs PDM: high-level business / detailed tech-independent / technology-specific.
  14. Normalization vs denormalization: remove redundancy/dependency defects vs deliberately add/combine for justified physical need.
  15. Normalization vs abstraction: dependency cleanup vs supertype/subtype inheritance.
  16. Forward vs reverse: requirements downward vs existing database upward.
  17. View vs materialized view: virtual on-demand vs stored/instantiated result.
  18. Vertical vs horizontal partition: columns vs rows.
  19. Pattern vs industry model: generic reusable structure vs broad industry reference starting point.
  20. Tool vs modeler: software stores/transforms representations; human judgment establishes business meaning and appropriate design.

Final teach-it-back

You should be able to explain Chapter 5 as one flow:

Discover requirements → agree meaning and scope → model entities/relationships/attributes/domains and keys → select an appropriate scheme → refine through CDM/LDM/PDM → normalize and abstract logically → adapt the physical design deliberately → preserve lineage and reusable Metadata → review against standards and Scorecard criteria → version and maintain the model as reality changes.

← Lesson 7 · Exam Map →