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.

Identifiers ¶

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.