Let's say in an ER Model, there is an identifying relation between a strong entity and a weak entity with total participation from both entities, how many minimum tables are required to represent such a relation if: Case 1: The mapping is one-to-one (1 : 1). Case 2: The mapping is many-to-one (N : 1) or one-to-many (1 : N). Case 3: The mapping is many-to-many (N : M).
I know what is the answer if there is no total participation, but I don't know the case when total participation occurs. I too read somewhere that if there is a total participation constraint from both entities and the mapping for the above case is many-to-many, then you only require one table. Is that true? What about other mappings? I am in need of more insight.
Total participation on both sides of a relationship is just impossible to implement, ultimately due to the constraint that database transactions be ACID, so that, in particular, it is not possible to insert records in different tables at the same time: which is what would be needed to satisfy such relationships.
To understand the issue, consider the distinction between conceptual and concrete ER models. -- The technical literature distinguishes more than just two levels, in fact usually presents three, corresponding to conceptual analysis (of requirements), abstract design (abstract specification), and concrete specification (for implementation): but just two levels, which I am simply dubbing "conceptual" vs "concrete", I think are sufficient for understanding the relevant distinctions.
At the conceptual level, in particular notice that relationships do not have any intrinsic direction (the graph represented by the ERD is undirected), relationships here are two-way connections just with certain attributes (cardinality and optionality in ERD terminology) on each side (at each end): indeed there is one and only one, usually verbal, name for any one relationship, and it is rather the informal reading that conventionally goes in the active mode in one direction and in the passive mode in the other, yet abstractly there is simply a relationship so and so between two entities.
At the concrete level, to the ACID requirement add the fact that, to implement a relationship, we must define an FK in one table and not the other. What we get is necessarily an asymmetry in concrete relationships, to the point that we can use the informal notions of parent and child entities, where the latter is where the FK is defined. And, in particular, the graph becomes directed.
Now, because there is no way out of that "limitation"; and because of "logical" considerations (we can argue that the only valid logic in our realm is a computable logic, to be adopted since the conceptual analysis, because "computable" must be the business processes and rules themselves): I'd personally rather suggest to think in terms of directed relationships already at the conceptual level (namely, ban relationships that are mandatory on both sides, i.e. total participation): there just is no (ACID) computable logic to attach to those! -- Anyway, on this, mileage may vary.