It looks like you want to get the hang of many-to-many relationships.

This would occur, if , in your example, the same model CAR was available in many "Sizes" - i.e. perhaps Compact, Sedan, and hatchback.

Now, if you wanted to keep the database "normalized" - i.e. have no duplicate primary data, you would set up CARS and SIZES as you started with, and add a table, say "MODEL", which contained a carID and a SizeID, and perhaps a date-introduced.

Now, for each car, say MiniCooper, you add a record in "MODEL" for each size it offers.

Actually creating a database would make this more clear.

Anyway - all this stuff is old-school "relational" database" modelling.
"NOSQL" databases are in fashion now, and these store key-value pairs. However, it does help to understand the old structured databases, even if you use one of these new-fangled things(My favourite is ElasticSearch).