One and only one relationship - ER diagram to relational schema

Question

I'm taking this term a DB course as part of my CS studies.
This week we began studying the subject of ER diagrams, which I find a bit confusing.

I have some uncertainty about the picture above (Note: the rounded arrows indicate "One and only one" - that is, every subject from B can and must be directed to exactly one subject in A, and vice versa).

I have to create a suitable relational schema for this diagram, and here is my try:

• A(a, b, c, d) (b is the key)
• B(e, f) (e is the key)

This is my uncertainty:

R(b, e) - no matter which key I'm creating out of those foreign keys, the "one and only one" constraint isn't held.

How can I create the schema where this constraint holds?

What about if you had "at most one" arrows, and not exactly?
How the answer would change?

Answer 1

Table a should reference (foreign key) b and vice versa. On the foreign keys you create a unique index, so you have a 1 on 1 relationship.

The following data respects these constraints, but is probably not what you'd like.

Tab a   Tab b
PK FK   PK FK
1   a   a   2
2   b   b   1

So you may need to be even more stringent, and put a foreign key on the primary key column, forcing both tables to have the same primary key.

"at most one": allow the column to be null.

A symmetric one on one relationship, as below, can't be enforced with foreign keys (unless logic is added, eg. triggers).

Tab a   Tab b
PK FK   PK FK
1   b   a   2
2   a   b   1

Answer 2

You have several possibilities, each of them with advantages and disadvantages.

Solution 1

Define a single table:

AB(a b c d e f)

with two candidate keys, b and e. You chose one of them as primary key, and declare the other as unique.

Advantages: All the constraints of the association among the two entities are satisfied.

Disadvantages: If there are other entities related to A or B, then the foreign key for the relation corresponding to this entity can be not “natural” if the primary key chosen for AB is the “other” key.

Solution 2

Define one of the two relations with a not nullable foreign key for the other, for instance add fke (“foreign key for attribute e in B”) to relation A. Then declare that this attribute is unique.

Advantages: it is more “natural” to keep the two entities in separate relations. You keep the constraints that each element of A is related to one and only one element of B (since the attribute fke is not nullable and it is unique in all the relation).

Disadvantages: you lose one constraints: that each element of B is related to some element of A. This constraint must be enforced in the applications developed on the database.

Solution 3

As before, exchanging the role of A and B.

Solution 4

As you have mentioned, with a bridge table R(b,e). Then declare both b and e as unique.

Advantages: you keep the constraint that each element of A can be related only to one element of B, and vice versa.

Disadvantages: you lose the constraints that each element of A is related to some element of B and vice versa. Those constraints must be enforced by the applications. Moreover, you have one more table, and this make the queries more complex.

Solution 5

You put a foreign key in each of the two tables to refer the other table. These foreign keys are also declared unique.

Advantages: you keep the constraint that each element in A is related to one and only one element in B, and vice versa.

Disadvantages: you lose the constraint that if a certain element b1 of B is associated to an element a1 of A, then a1 is associated to b1. In fact this solution allows inconsistences: an element a1 could be associated to b2, a2 could be associated to b1, while at the same time the foreign key for b2 could refer to a2, and the foreign key for b1 could refer to a1. So this constraint should be enforced by the application. Moreover, there is a certain redundancy in the data.

---

The solutions are listed in order from the more “secure”, to the more “dangerous”, at least in my opinion.

Finally, is worth to note an important point from this case: when translating from the ER model to the Relational Data Model, there are situations in which the translation is not completely satisfactory.

For your last question: what happen if at most one arrow. In this case the second or third solution can be used. And normally, if one arrow is total (i.e. you have exactly one element in the other entity set) while the other is partial, you put the foreign key in the relation for which the relation is total. If both are partial, then you can choose freely the relation in which to put the foreign key.