Way around Composite Primary Key requiring Composite Foreign Key Here is a table called Make (where name is the PK)

name|other columns
----------------------
  A | ...
  B | ...
  C | ...


And a table called Type (where make, name together is the PK and make references Make.name as FK)

make|name|other columns
------------------------
  A |SUV | ...
  B |SUV | ...
  B |UTE | ...
  C |UTE | ...


Finally a table called Model (where make, type, name together is the PK and make, type reference Type.make, Type.name as FK)

make|type|name|other columns
-----------------------
  A |SUV |CRV | ...
  A |SUV |HRV | ...
  B |UTE |DMAX| ...


It seems to me the Model.make is redundant in the Model table, but it is necessary only because the Type table uses a composite key make, name.

What is the way to get rid of this redundancy?

I believe I can add an unique id column in the Type table, so that the Model table can reference that as FK. But it seems this extra column is just another form of redundancy, as make, name can uniquely identify every row already?
Both the designs are possible, reasonable, and non-redundant (in the sense that no data can be eliminated in one solution without losing information): 1) leaving the PK of Type as the pair (make, name) and use it as foreign key in Model, or introducing a surrogate PK in Type and using it in Model. 

And their pro and cons balances: the first option allows to perform more efficiently a join between Model and Make, the second one uses slightly less memory.