Entities alone tell you nothing — relationships do the real work
A pile of unconnected entities cannot answer any interesting question. This lesson adds relationships between entities, the additional features that make an ER diagram precise, and closes Unit 1 by putting the whole conceptual design process together.
After this lesson
You should be able to
- Draw a relationship between two entity sets and label its degree (1:1, 1:N, M:N).
- Explain what a weak entity is and why it depends on another entity.
A relationship is an edge, exactly like in a graph
A relationship is an association among two or more entities — a Student entity connects to a Course entity through an "enrolls in" relationship. A relationship set is the collection of all such relationships of the same type, just like an entity set collects entities of the same type. This is CS205ES's graph vertices and edges again: entities are vertices, relationships are edges, and this entire diagram is a graph before it becomes anything else.
Relationships have a degree: one-to-one (a Student has exactly one Aadhaar record, and vice versa), one-to-many (a Department offers many Courses, but each Course belongs to one Department), and many-to-many (a Student enrolls in many Courses, and each Course has many Students). Getting this degree right is critical — it directly decides how the relationship becomes actual tables in Unit 2, including whether a foreign key is enough or a whole new table is needed.
Weak entities and other features that make a diagram precise
A weak entity cannot be uniquely identified by its own attributes alone — it depends on a related "owner" entity for identity. A Payment_Installment might only make sense tied to a specific Fee record; without knowing which Fee it belongs to, "installment number 2" is meaningless on its own. Weak entities are drawn distinctly in an ER diagram and always participate in an identifying relationship with their owner.
Additional ER features refine a design further: relationships can carry their own attributes (an "enrolls in" relationship might carry an enrollment_date, which belongs to neither Student nor Course alone), and generalization/specialization lets one entity type be a specific case of another (a Faculty entity might specialize into TeachingFaculty and ResearchFaculty). Conceptual design is the overall process of using all of this — entities, attributes, relationships, and these refinements — to produce one complete ER diagram before a single table is created, which Unit 2 then converts into the relational model.
Try it yourself
For the library system from the previous lesson (Book and Member entities), add a relationship connecting them, name its degree, and decide whether it needs its own attribute.
Need a hint?
A "borrows" relationship between Member and Book is naturally many-to-many — one member can borrow many books over time, and one book can be borrowed by many members over time (not at once, but across history).
Check the worked solution
"Borrows" is a many-to-many relationship between Member and Book. It should carry its own attributes — borrow_date and due_date — because these facts belong to a specific borrowing event, not to the Book or the Member alone (the same book has a different due_date each time it is borrowed).
Quick check
Why does a Payment_Installment entity, which only makes sense attached to a specific Fee record, count as a weak entity rather than a normal one?
Why this lesson exists
Syllabus mapping
Relationship and Relationship sets, Additional features of ER Model, Conceptual Design
Maps to course outcome CO2.