[Employee]——[Department] is the notation for 1-to-1, which means that one dedicated department corresponds to each single employee. However, there are only 10 departments for 50 employees, so they cannot each be matched to a separate department. Besides, if the relationship really were 1-to-1, the two could simply be combined into a single table, which also does not fit the stated quantities of 50 employees and 10 departments.
×Incorrectイ
[Employee]——▶[Department] is 1-to-many, that is, it reads as one employee corresponding to multiple departments. This runs squarely against the statement in the question that “no single employee belongs to more than one department.” It is a typical wrong answer that is easy to choose when the direction of the arrow is read backwards.
○ウ
正解Multiplicity is decided by counting from both directions. First, since “no single employee belongs to more than one department,” exactly one department corresponds to one employee. Conversely, there are 50 employees but only 10 departments, so multiple employees belong to one department. Therefore Employee:Department = many:1, that is, a “many-to-1” relationship. In the [Notation], [a]◀——[b] is defined as many-to-1, so putting Employee in place of a and Department in place of b gives [Employee]◀——[Department], which is choice ウ. The structure of the tables backs this up as well. Department Code in the Employee table has a dashed underline, meaning it is a foreign key, and it refers to Department Code, the primary key of the Department table. A foreign key is placed so that the table on the “many” side refers to the primary key on the “1” side, which agrees with reading Employee as the many side and Department as the 1 side.
×Incorrectエ
[Employee]◀——▶[Department] is many-to-many, which means that multiple items correspond in both directions. It is true that, seen from the department side, there are multiple employees, but it also makes multiple departments correspond when seen from the employee side, and that violates the given condition. In addition, a many-to-many relationship cannot be expressed by giving the Employee table just one Department Code; a linking table (an associative entity) that joins the two is needed, so it does not fit the table structure shown either.
ここがポイント
Multiplicity (cardinality) is decided by counting, from both directions, how many items on the other side correspond. Employee → Department is 1 item (one person, one department), while Department → Employee is multiple items (50 people divided among 10 departments), so Employee:Department = many:1. The figures 50 and 10 in the question are a hint showing which side is the “many” side.
In a 1-to-many (many-to-1) relationship, the table on the “many” side holds the primary key of the “1” side as a foreign key. In this question the Employee table contains Department Code as a foreign key (dashed underline), so from that alone you can judge that Employee is the many side and Department is the 1 side.
Arrows in an E-R diagram must not be read by a memorized general rule; read them according to the [Notation] defined in the question. Here [a]——▶[b] is defined as 1-to-many and [a]◀——[b] as many-to-1, so the side the arrowhead points to is the “many” side. If you assume the arrowhead marks the “1” side, you will mix up イ and ウ.