• Option 2 is ruled out because you don't need a join table for 1:M relationships.

• The relationship between APPLICATION_STUDY and CONSULTATION is 0:M, not 1:M.

• Option 1 is the correct one. That's the usual way of modeling 0:M relationships: a nullable FK on the MANY side.

• Option 2 is ruled out because you don't need a join table for 1:M relationships.

• The relationship between APPLICATION_STUDY and CONSULTATION is 0:M, not 1:M.

• Option 1 is the correct one. That's the usual way of modeling 0:M relationships: a nullable FK on the MANY side.

EDIT : Note that the 0 in 0:M mean 0 or 1, which is why you have a nullable FK on the many side.

• Option 2 is ruled out because you don't need a join table for 1:M reletionships.

• The relationship between APPLICATION_STUDY and CONSULTATION is 0:M, not 1:M.

• Option 1 is the correct one, that's the usual way of modeling 0:M relationships, a nullable FK on the MANY side.

• Option 2 is ruled out because you don't need a join table for 1:M relationships.

• The relationship between APPLICATION_STUDY and CONSULTATION is 0:M, not 1:M.

• Option 1 is the correct one. That's the usual way of modeling 0:M relationships: a nullable FK on the MANY side.