Verbalizing an ER Diagram

A simple verbalization grammar

1. Entities - “There is an entity NAME with attributes …” (define purpose + key).
2. Identifiers - “NAME is identified by PK (natural/surrogate).”
3. Relationships - Read both directions, stating min/max:
   • “Each A must|may be related to 0|1|many B.”
   • “Each B must|may be related to 0|1|many A.”
4. Participation and cardinality - Use the words must/may (minimum) and one/many (maximum). Avoid ambiguous phrasing.
5. Constraints - Domains, uniqueness, state-dependent rules, and relationship attributes.

Worked example - Stories on CD (relational shorthand)

The same ERD described as compact, relational notation (plural table names; keys labeled):

Customers (CustID PK, CustLast, CustFirst, CustStreet, CustCity, CustState, CustZip, CustPhone)
Orders    (OrderNo PK, CustID FK, OrderDate)

LineItems (OrderNo CPK/FK, CDNo CPK/FK, Quantity, SellingPrice, LineCost, Shipped)

CDs          (CDNo PK, CDTitle, DistID FK, RetailPrice, AgeGroup, Description)
Distributors (DistID PK, DistName, DistStreet, DistCity, DistState, DistZip, DistPhone)

Now verbalize the same model

• Entities and identifiers
  • There is an entity Customer identified by CustID.
  • There is an entity Order identified by OrderNo.
  • There is an entity CD identified by CDNo.
  • There is an entity Distributor identified by DistID.
  • There is an associative entity LineItem identified by the composite key (OrderNo, CDNo).
• Relationships (read both directions)
  • Each Order must belong to exactly one Customer; each Customer may have zero or many Orders.
  • Each LineItem must reference exactly one Order; each Order must have one or many LineItems.
  • Each LineItem must reference exactly one CD; each CD may appear in zero or many LineItems.
  • Each CD must have exactly one Distributor; each Distributor may supply zero or many CDs.
• Constraints and domains
  • CustPhone is a phone-number domain (format validated per locale).
  • RetailPrice and SellingPrice are non-negative currency amounts; LineCost = Quantity × SellingPrice.
  • Shipped is a boolean (or status enum) constrained by order state.

How to produce verbalizations quickly

1. List entities and keys first (one line each).
2. For every relationship, write two sentences using the must/may and one/many grammar.
3. Add only the constraints that change behavior (domains, uniqueness, state rules).
4. Keep it under one page per bounded context/domain.

Relational notation vs. verbalization - when to use each

• Relational notation is compact and great for modelers (naming, keys, and joins).
• Verbalization is for stakeholders-reviewing rules without reading symbols.
• Use both: place notation in an appendix; read verbalizations in review meetings.

Naming fields (be consistent)

• Prefer a stable prefix from the table name plus a descriptive suffix: CustID, DistID.
• Use CamelCase or snake_case consistently; avoid spaces in identifiers.
• Avoid non-obvious abbreviations. If you abbreviate, keep it intuitive (CustLast, CustFirst).
• Document natural keys with UNIQUE even when you use surrogate PKs.

Quality checks before sign-off

• Every entity has a purpose sentence and an identifier.
• Every relationship has two clear sentences (both directions) with min/max.
• All mandatory/optional rules in text match the ERD symbols.
• Constraints that affect behavior are stated and testable.

The next lesson concludes the module.