Database: foreign keys between class and just 1 of the subclasses. Use single FK column?

Question

I'm reworking and extending an existing data model where a section covers person data. The current person table is just 1 big table containing all fields, both for natural and legal persons and the non-relevant fields just remain empty. As we're adding more and more fields, the idea would be to have a single PERSON table and 2 subclasses NATURALPERSON and LEGALPERSON, where a person could never be both at the same time.

Sounds easy enough but started reading and doubting my initial approach. What would you do?

1. First option I had in mind was to have a single column in the PERSON table for the Foreign key, LEGAL_NATURAL, which would be a pointer to either LEGALPERSON or NATURALPERSON. To ensure mutually exclusiveness the record ID's for the subclasses could be constructed using a single sequence.

SELECT * 
FROM PRSN pr 
    left join LEGALPERSON_DETAIL lp on pr.legal_natural = lp.id
    left join NATURALPERSON_DETAIL np on pr.legal_natural = np.id;

2. Instead of the 1 column for 2 FK's, an alternative would be to have 2 columns in the PERSON table (e.g. NATURALPERSON, LEGALPERSON), each with a possible pointer to a subclass. A constraint could then make sure both aren't filled at the same time. Could make the FK relationship more obvious.

3. Different approach would be to have the subclasses point to the PERSON table. Has the disadvantage that in the PERSON table it's not visible whether it's a natural or legal person record but might be a nicer design overall.

Found some info on exclusive arcs on Database development mistakes made by application developers.

Is there a clear winner here?

Answer 1

The design of your three tables looks good.

AS far as PKs and FKs are concerned I recommend a technique called Shared Primary Key.

The person table has an ID field which functions as a PK.
The natural person and legal person tables do not have an independent ID field. Instead, both subclasses use PersonID as the PK in their own table. PersonID is also an FK that references ID in the person table.

This makes joins simple, easy, and fast.