Entity and Relationship Set

Question

I am confused about "entity set" and "relationship set". I am aware of "entity" and "relationship". Is there any clear example for entity set and relationship set which shows the real use cases of these terms?

 ___________            /\           ___________ 
|           |          /  \         |           |
|  Teacher  |-------- /Tea \--------|  Student  |
|___________|         \che /        |___________|
                       \s /                      
                        \/                       

In the above diagram Teacher and Student are entities and Teaches is a relationship.

Answer 1

Originally in Entity-Relationship Modeling: An entity is an individual thing. A relationship between/among or an association of/on/between/among some things is an individual (concrete or conceptual) thing. Either can have properties. An entity or relatinship/association type/set/class is a collection of entities or relationships/associations. A type/set/class corresponds to a relation and contains a row per entity or relationship/association that is an element/member. An entity or relationship/association is called an instance of the type/set/class of which it is an element/member.

However, "entity" gets used as shorthand for "entity class" and "association" gets used for "association class". Which, of course, is confusing. Then "entity instance" gets used for "entity" and "class instance" gets used for "class". Even more confusing. This means that we can see entity or relationship "set/class instance" meaning entity or relationship. Ugh. But entity or association "type" gets used to mean a set/collection of what could be called potential things with entity and relationship/association set/class meaning those potential elements/members of a type that actually do correspond to a thing in the current situation/state. (Like a relation's row "type" meaning the set of all potentially present tuples vs a relations being a set of actually present tuples. Or like class vs extent.) Ughnnnn. You just have to figure out how an author is using terms.

Many presentations of or products supporting E-RM or variants also incorrectly use "relationship" to mean "foreign key".

Boo is a Teacher is an example of an entity (instance) if and only if Boo is a teacher.
Gee is a Student is an example of an entity (instance) if and only if Gee is a student.
Boo teaches Gee is a relationship/association (instance) if and only if Boo teaches Gee.
Teacher is an entity type/set/class, containing all such entities (instances).
Student is an entity type/set/class, containing all such entities (instances).
Teaches is a relationship/association type/set/class, containing all such relationships/associations (instances).
A rectangle denotes an entity type/set/class.
A diamond denotes a relationship/association type/set/class.
Rectangles & diamonds correspond to relations
(with attributes for participant things plus owned/possessed/associated property things).
A line from a diamond to a rectangle represents the participation of an entity type/set/class in the relationships/associations of the relationship/association type/set/class
(and a foreign key from a relationship/association relation to a participant entity relation).

Ironically all this variation and confounding of terminology is in reference to concepts that are unnecessary in the first place. E-RM makes unnecessary distinctions between "entity" things, "relationship/association" things and "property" things, and between being a property of and being in a relationship/association with. Directly modeling relationally avoids all that. Every superkey of every query is in 1:1 correspondence with some kind/type of thing. But the E-R Modeling & variants just don't understand the Relational Model.

See A: What is the difference between an entity relationship model and a relational model?.

Answer 2

Entity sets are usually visible (exposed via DbSet<T>, ICollection<T>) while relationship sets look like hidden when using Linq to Entity. You can access to navigation property of collection, query for some entities, it's very visible about entity sets.

For relationship set, it's not so visible. In fact the so-called navigation property represents relationship. A relationship contains info about both ends so it looks like a link. Entity looks like one of 2 ends.

E.g: you have 2 teachers T1, T2 and 2 students S1, S2. It depends on the kind of relationship, you can have different relationship sets.

• For one-one relationship, suppose T1 teaches S1 and T2 teaches S2. So the relationship sets include just 2 entries: (T1-S1), (T2-S2). This relationship is maintained via a foreign key column defined in one of the 2 tables: Teacher or Student. In code, the relationship can be modified/established by just changing the navigation property (of reference):

  T1.Student = S1;
  T2.Student = S2;
  //or
  S1.Teacher = T1;
  S2.Teacher = T2;
  

• For one-many relationship, suppose T1 teaches S1, S2 and T2 is reserved (teaches no student). We also have 2 relationships: (T1-S1), (T1-S2). This kind of relationship is maintained via a foreign key column defined in the many-side table (in this case it's Student). The Teacher then exposes a collection of Students while Student exposes just a reference to a Teacher. In code you can modify/establish the relationship by changing one of those navigation properties:

  //via Teacher navigation property
  S1.Teacher = T1;
  S2.Teacher = T1;
  //or via Students navigation property
  //NOTE: this is for demonstration, in practice doing something
  //like this should be done carefully.
  //Students should be fully loaded first, otherwise 
  //if lazy loading is enabled, the new list will be merged with  
  //loaded data before being set to Students.
  //This may null out some foreign keys (if foreign key column is nullable)
  //Otherwise an exception will be thrown after calling SaveChanges()
  T1.Students = new List<Student>{ S1, S2 };
  

• For many-many relationship, suppose both teachers teach both students, now we have 4 relationships: (T1-S1), (T1-S2), (T2-S1), (T2-S2). This kind of relationship is maintained via a junction (join) table containing both foreign keys (pointing to Teacher and Student tables). The Teacher then exposes a collection of Students and Student exposes a collection of Teachers. In code you can modify/establish the relationships by changing one of those navgiation properties:

  //Setting collection navigation property 
  //like this has the same note as above (about merging collection)
  //However there won't be no exception
  //It's easier than one-many relationship.
  S1.Teachers = new List<Teacher> { T1, T2};
  S2.Teachers = new List<Teacher> { T1, T2};
  //or 
  T1.Students = new List<Student> { S1, S2};
  T2.Students = new List<Student> { S1, S2};
  

The code above is mainly for demonstrative purpose (although work in some specific scenario/context). In practice, you can modify the collection navigation property by using its Remove, Clear, Add methods. The list value can also be queried from database (instead of creating a new one). The most noticeable thing is when modifying collection navigation property of one-many relationship. It's safer to modify/change the reference navigation property instead for this kind of relationship.