ERDs

Key Components of an ERD

Entities

Entities represent real-world objects that are stored as records in a table. Each entity becomes a table in a relational database.

Examples: Student, Course

Attributes

Attributes are the properties or details of an entity, stored as fields within the table.

Examples: StudentID, CourseName

Relationships

Relationships define how two entities are associated with each other.

Example: Student enrols in Course, Teacher assigned to Course

Cardinality

Cardinality defines the number of instances of one entity that can be associated with instances of another entity.

• One-to-One (1:1): One (each) student has one ID card. Each (one) ID card has one student.
• One-to-Many (1:M): One (each) teacher teaches many classes - defining the Many side of relationship. Each (one) class has one teacher - defining the one side of relationship.
• Many-to-Many (M:N): Many students enrol in many courses. Or, one (each) student is enrolled in many courses - defining one half of the Many side of relationship. One (each) course has many students enrolled - defining the other half of the Many side of relationship.

Cardinality: One-to-One (1:1)

Each student has one ID card, and each ID card belongs to one student.

Explanation: Student 1001 (Amira) has one ID card (ID1001), and that ID card belongs only to her. The same applies to student 1002 and card ID1002 - this shows a true 1:1 relationship.

A 1:1 relationship

Cardinality: One-to-Many (1:M)

Each teacher can teach many classes, but each class has only one teacher.

Explanation: Teacher T01 (Ms Roberts) teaches two classes: Maths and English. Teacher T02 (Mr Clark) teaches History. Each class has exactly one teacher, but a teacher may teach multiple classes - this is a 1:M relationship.

A 1:M relationship

Cardinality: Many-to-Many (M:N)

Students can enrol in many courses, and each course may have many students. A linking (or junction) table (Enrolments) connects them.

NOTE: In a relationship such as this, you ALWAYS introduce a junction table.

Explanation: Student 2001 (Isla) is enrolled in two courses - CS01 and PH01. Student 2002 (Kian) is enrolled in PH01. The course PH01 is taken by both Isla and Kian. This shows a many-to-many relationship where both students and courses can appear multiple times in the Enrolments table.

A M:N relationship

Modality

Modality defines whether corresponding records in a relationship are optional or required.

• Mandatory: Every order must have a customer.
• Optional: A student may have a project, but not all students are assigned one.

Modality: Mandatory

In a mandatory relationship, each record in the dependent table must be linked to an existing record in the parent table. Orders must always be associated with a valid customer. However, a customer can exist without an (active) order.

A mandatory relationship: the 'cross' on the 1 side denotes mandatory. The 'circle' on the Many side denotes optional.

Modality: Optional

In an optional relationship, some records may not be linked to others. Participation in the relationship is not required.

Example 1: Optional 1:M – Not every student has a project

Example 2: Optional M:N – Some students have not enrolled in any club

Explanation: Optional relationships allow some records to remain unlinked. For example, Daniel (5012) is a valid student who hasn’t joined a club. Similarly, Leo (3012) doesn’t yet have a project. These are acceptable in systems that support optional modality.

An optional relationship: the 'circles' denote optional.

Common ERD Notations

Why ERDs Matter

• Visual Planning: Simplifies database design before implementation.
• Efficient Modelling: Supports logical structuring of data and relationships.
• Improves Integrity: Encourages good database practices to avoid anomalies.
• Supports Scalability: Adapts well to new entities and relationships as the system grows.