Database Diagram

A database diagram seems to be an unofficial diagram mostly based on a simplified Class Diagram with some semantic changes.


A class πŸ—ƒοΈ, such as Person, is a structured data definition. It has attributes πŸ“š such as name which has the type String.

A record 🎫 is a concrete instance of a class, e.g., we gave concrete values to each attribute of the class (ex: Person(id=1, name="John Doe")).

Some attributes such as id are special attributes called identifiers. They are used to identify a record (e.g., given an ID, we can find a person).

Associations πŸ”—, Generalizations πŸ‘¨β€πŸ‘©β€πŸ‘§β€πŸ‘¦, and multiplicity πŸ”’ are the same as for classes diagrams.

πŸ‘€ In practice, identifiers are usually called keys πŸ”‘ while a key is actually the implementation (ex: in SQL) of an identifier.

πŸš€ We often use OCL along the diagram to express constraints.

My notes


Rules πŸ“

  • Each class must have an identifier
  • Identifiers are unique and not null (by design)
  • An identifier can be composed of multiple attributes

Diagram 🎨

  • # attr or attr: an attribute part of the primary key
  • * attr: an attribute that can potentially become a key
  • βŠ› attr: an artificial key

Both primary keys and artificial keys are explained here.

Changes with class diagrams

Diagram 🎨

  • There is no concept of visibility (#attr does not mean protected)
  • There is no concept of class attributes (attr is not a class attribute)
  • There are usually no operations. If there are, it means we will use PL/SQL or another procedural language to code them.