Relational data modeling for sub types

Question

I am learning the Relational Model and data modeling.
And I have some confusion in my mind regarding sub types.

I know that data modeling is an iterative process and

Answer 1

When cut down to its bare essence, the relational model of data has no more than exactly one "rule" : all information in the database must be represented as values of attributes in tuples in relations.

All of your "alternatives" potentially comply to that rule, provided :
- that each attribute has an associated data type,
- and that each tuple in each relation in the database will always have a value for each of its attributes,
- and that value is a value that is a member of the data type associated with that attribute.

EDIT : you have also failed to provide any detail of what the precise nature is of the facts you want to make a record of in your system.

EDIT 2 : first comment by Walter M. still applies. Your facts seem to state things at different levels (which in the typical use cases will be notably distinct) :

"6. A Hydrogen atom is composed of one proton and one electron"

After a small rewrite to eliminate the 'AND' therein :

"6. A atom contains "

This one looks like something that would go into your database (if your use case is as typical/mundane as could be supposed) :

A 'H' atom contains 1 proton
A 'H' atom contains 1 electron
A 'H' atom contains 1 neutron

(Note how eliminating the 'AND' involved splitting the conjunction into "atomic" parts (pun intended).)

From this one, we can start wondering what to do about the . If your use case is such that the existence of proton/neutron/electron is just a given, and it will never change, then you can simply use a data type for it, and modeling it will not involve more than identifying the type so that your model's readers will know the intended value set. If, however your use case is such that, say, you are experimenting to try and find a completely new model of chemistry, in which there could also be foobarons alongside protons [or their existence could be removed again for the sake of experimentation], then you'd have to include a table that says " is part of my model of atoms".

Furthermore, you'd then also have to include a rule in your model that any that is claimed to be part of an atom, must indeed be one that is part of your model of atoms. In SQLspeak : you'd need an FK from your ATOM_CONTAINS_PARTICLE table to this EXISTING_PARTICLES table.

In a sense, the declaration of this rule is like your

"2. Atoms are composed of protons, neutrons, and electrons."

But note that you won't have a table in your own database that says this kind of thing. Instead, by declaring the FK to the system, this particular statement will be made in the catalog.

You need to make proper distinction between the type of statements that directly state things that are within the domain of interest (those end up being entities/classes/... in your conceptual models and most likely tables in your database) and the type of statements that state things about the domain of interest (like your FK rule).

(In use cases where the domain itself is highly abstract, the line between the two may be extremely thin or even nonexistant.)