Naming Conventions and Diagram Readability

Learning outcomes

A correct model can still fail as a communication artifact if its names are inconsistent, lines cross everywhere, abbreviations are unexplained, keys are hidden, or the diagram tries to show the entire enterprise on one page. Diagram readability is not decoration; it directly affects the team's ability to detect modeling defects.

Names are part of the model

An entity name should communicate the domain concept without requiring readers to inspect every attribute. Compare:

Bad:  TBL_MST  INFO  DATA1  XREF  HDRBetter:  Customer  WorkOrder  Technician  WorkOrderAssignment  PartUsage

Technical shorthand can save a few keystrokes while costing every future reader time.

Entity naming conventions

Choose one convention and use it consistently. Common logical-model rules include:

• use singular nouns: Customer, WorkOrder, Part;
• name associative entities by domain meaning: Enrollment, Membership, Assignment;
• avoid implementation prefixes such as tbl_ at the conceptual/logical level;
• avoid overloaded words such as Object, Record, or Data;
• reuse the terminology stakeholders already use when it is unambiguous.

Some SQL teams prefer plural physical table names. That is acceptable if documented. Consistency matters more than debating singular versus plural endlessly.

Attribute naming conventions

Attribute names should express meaning, not merely type:

Key naming

Common physical conventions include:

customer_idasset_idwork_order_idtechnician_id

Foreign-key names should reveal both the referenced entity and role when necessary:

opened_by_employee_idapproved_by_employee_idmentor_technician_id

Calling all of these simply employee_id would hide relationship semantics.

Relationship names should be verbs

Entity names are usually nouns; relationship labels work well as verbs or verb phrases:

• Customer owns Asset;
• WorkOrder services Asset;
• Technician participates in WorkOrder through Assignment;
• WorkOrder consumes Part through PartUsage.

When the model is read aloud, nouns and verbs naturally form business statements.

Avoid semantic abbreviations

Abbreviations such as WO, CST, TXN, PRT, and ST are often obvious only to the original designer. If abbreviations are unavoidable due to external standards or database limits, maintain a glossary and use them consistently.

One giant ERD is rarely readable

A database with hundreds of tables should not be reviewed as one poster of tiny boxes and crossing lines. Create multiple views:

• enterprise/domain overview;
• customer and asset lifecycle;
• work-order execution;
• parts and inventory;
• billing;
• security/audit;
• physical implementation view.

The same entity may appear in several views. That is fine if all views derive from one canonical model.

Use bounded subject areas

A useful diagram should answer a question. Examples:

• How does a work order move from customer asset to technician assignment?
• How is part usage recorded and priced?
• How is historical ownership preserved?
• How are users and organizations related?

Subject-area diagrams reduce cognitive load while preserving the complete model elsewhere.

Layout conventions

Good layout makes patterns visible. Helpful practices include:

• keep parent/lookup entities near related children;
• align associative entities between their parents when possible;
• minimize line crossings;
• use orthogonal connectors consistently;
• place high-traffic/core entities near the center of a subject view;
• avoid encoding meaning solely through color because diagrams may be printed or viewed by color-blind readers.

Use color sparingly and semantically

If the tool supports color, define a legend. Example categories could be:

• core/master entities;
• transaction/event entities;
• reference entities;
• external-system entities;
• deprecated/legacy structures.

Color should reinforce labels, not replace them.

Show the right amount of detail

For a stakeholder conceptual review, a box containing 70 physical columns hides the relationships that matter. For a migration review, omitting column types and keys may hide implementation risk.

Maintain different projections of the same model:

Document exceptions

If one table violates the normal naming convention because it comes from an external standard, record the reason. If a foreign key is intentionally nullable despite a general rule, document the lifecycle state that requires it.

Undocumented exceptions look like mistakes. Documented exceptions become deliberate design decisions.

Version and ownership metadata

Models should identify:

• owner or responsible team;
• last review date;
• model version or source commit;
• scope of the diagram;
• notation used;
• links to requirements and migration/schema source files.

This prevents stale screenshots from circulating as if they represent the production schema.

WorkshopHub naming cleanup

Compare an implementation-first draft:

tbl_wo  id  cust  tech1  dt  val  st

with a domain-oriented model:

WorkOrder  work_order_id  asset_id  opened_at  status_code  problem_descriptionWorkOrderAssignment  assignment_id  work_order_id  technician_id  assignment_role  started_at  ended_at

The second version communicates substantially more before any documentation is opened.

Practice: diagram refactoring

Summary and next lesson

Naming and layout determine whether a correct model can actually be understood. Consistent nouns, verbs, keys, subject views, and notation legends reduce ambiguity and make reviews more effective. The final lesson of Chapter 4 turns those diagrams into a structured collaborative review process with domain experts and developers.

References

• Steve Hoberman, Data Modeling Made Simple.
• Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Systems.
• Martin Fowler, Analysis Patterns.