An ER model of a database consists of entity types A and B. These are…

Concept. When an ER schema is converted to relations, a binary relationship set is normally given a table of its own that holds the primary keys of the two entity sets it connects. That separate table can instead be absorbed into one entity set’s table only when each entity on that side is related to at most one entity on the other side, because a single foreign-key column can then represent the whole relationship. If, in addition, that side’s participation is total, the foreign-key column always carries a value, so the merged table needs no NULL entries. A relationship that has no descriptive attributes of its own carries nothing beyond the pairing, so there is nothing else the merged table would have to store.

Applying it here.

1. For A’s table to hold the pairing, one row of A must point to at most one row of B. That is exactly the many-to-one direction from A to B: many A entities may be related to the same B entity, and each A entity is related to at most one B entity.

2. Add to A’s table one foreign-key column holding the primary key of the related B entity. Because R has no attributes of its own, this single column stores everything the separate R table would have stored.

3. Require the participation of A in R to be total, so every A entity takes part in R. Then that foreign-key column carries a value in every row of A, so the merged table needs no NULL entries — this is the condition under which the standard ER-to-relational mapping treats the merge as proper.

4. The separate table for R is now redundant and can be dropped — R has been merged into A.

Comparing the other conditions.

• One-to-many from A to B: one A entity may be related to several B entities. A single foreign-key column in A can hold only one B key, so the pairing has to be stored on B’s side or in a table of its own. Making A’s participation total does not remove that obstacle — it only guarantees that each A entity is related to at least one B entity.

• Many-to-one from A to B with partial participation of A: the foreign-key direction is right, but A entities that take part in no instance of R leave that column NULL. Such a table can still be created in SQL with a nullable column, but the standard ER-to-relational mapping rule states the merge condition with total participation precisely so that the foreign-key column is never NULL — which is why total participation, and not partial, is the condition being asked for here.

Result. The relational table for R can be merged with that of A when R is many-to-one from A to B and the participation of A in R is total.