0

I was going through this site to understand ER to relational model mapping. Below is the link:

ER Model to Relational model

Consider case 1: It says that since the passport entity type is in total participation, we can merge person and passport tables along with the has relationship into one table with all the attributes of the above three and primary key as Person_id.

My doubt is that wont it lead to a lot of NULL values for those people who do not own a passport. I was thinking that a better solution would be to include Person_id as a foreign key in the Passport relation and a separate relation for Person entity type itself.

Both the solutions seems to have their pros and cons:

1) One big table means a possibility of lot of NULL values but ease of access of passport details of a person.

2) Two separate tables mean that no NULL values but to find the passport details of people, we have to perform a join operation or search through two separate tables.

Which of these two solutions is correct? By correct, I mean to ask that in common practice in such cases, which solution is used?

Aditya Naidu
  • 697
  • 2
  • 7
  • 18

1 Answers1

0

Both solutions are commonly used. I would only consider option 1 if no other information depended on the passport number, but in this case I'd model it as an (optional) attribute in ER and not a separate entity. If a passport has any dependent attributes, such as country of origin or expiry date, I would model it as a separate entity and implement it using option 2.

reaanb
  • 9,806
  • 2
  • 23
  • 37