Database Normalization chaining

Question

I have multiple table chaining like so:

Table1

product_id SERIAL NOT NULL,
name varchar,

Table2 ( kept separate from table1

Answer 1

Yes that's fine, but arguably the model ought to be something like:

product -< product_variant >- product_size

                  V
                  |
           product_colour

Answer 2

This is the second version of the same question you have submitted. The answer is the same.

A product is an entity. Size and color are attributes.

A table contains entities. Each entity is represented by a row. The fields of each row are the attributes of each entity. You do not create a new table every time you need to add an attribute to an entity. That would make relational databases impossible to work with.

Answer 3

It seems like maybe you think that you need an id every time a given subtuple of value appears more than once in a table. Ie that you are trying to remove "duplicates" that do not need to be removed. The same value appearing more than once is not a "duplicate" in the normalization sense and is not necessarily bad, either. Also neither your use of multiple tables nor of ids is normalization. (I have already tried to address this table definition "chaining" anti-pattern here.)

From this answer:

The problem is that a bus stops several times at the same stop in different hours, how could I store this information avoiding redundancy?

There is no such problem. A subrow can appear more than once in a table whether or not there is "redundancy". (Whatever you think that means. Although one can replace subrows that appear multiple times by ids plus another table, then one needs more joins for the same query result. See this answer.)

Or from that answer's link:

This has nothing to do with normalization. Normalization never creates new column names. 'I don't want "Nintendo" to be duplicated' is misconceived. There is nothing wrong per se with values appearing in multiple places. See the answers by sqlvogel & myself here.

"Redundancy" is not about values appearing in multiple places. It is about multiple rows stating the same thing about the application. When using a design like that there are two basic problems: to say certain things multiple rows are involved (while the normalized version involves just one row); and there is no way to say just one of the things at a time (which normalization can help with). If you make two different independent statements about Nintendo then you need two tables and Nintendo mentioned in each one. Re rows making statements about the application see this. (And search my other answers re a table's "statement" or criterion".) Normalization helps because it replaces tables whose rows state things of the form "... AND ..." by other tables that state the "..." separately. See this and this. (Normalization is commonly erroneously thought to involve or include avoiding multiple similar columns, avoiding columns whose values have repetitive structure and/or replacing strings by ids, but although these can be good design ideas they're not normalization.)

From my answer at that answer's first link:

If SUBJECT_MODULE is rows where "[SUBJECT_NAME] has [MODULE_NAME] identified by [MODULE_ID]" and a subject might have more than one module then somewhere you must have multiple mentions of that subject (perhaps via its name) with mentions of different modules (perhaps by name or id). That would not involve redundancy.