^B There might be philosophical issues that need to be explored and modelled before it is safe to do a technical design. For example, (1) a car might exist but that doesn't mean the car you are designing exists.

And then (2) there is the common inclination to think in terms of Aristotle's categories. Because Aristotle's hierachical approach to categorisation did not survive modern reality, (e.g. a mobile telephone can also be a computer), a flexible solution to this that allows pointwise senior-junior relationships carries then the burden (3) that this doesn't automatically prevent circular categorisation.

(Update: ^I just noticed that Immanuel Kant meanwhile ;) diagnosed and corrected this problem (in Critik der reinen Bernunft, pub. ca. 1781).)

^C In view of this tree of problems with trees ;), I'd be inclined to escape horizontally via having a product class and an attribute class (update: many to many relationship) so that products may have any number of attributes and allow this to do the categorisation (e.g. give both a Mondeo and a Focus the car attribute, maybe the vehicle attribute too and give a truck maybe a vehicle and a truck attribute). You can search for (update: an enhanced implementation of) existence (i.e. that solves problem (1)) in the database based on (combined) attribute values (update: in the ProductAttribute table, see below).

Update: Bachman diagram of what I mean:

Product -< ProductAttribute >- Attribute

More update: to search for whether a particular car design already exists in the database (TRANSACT-SQL), using a notional cars-oriented datrabase design, searching for where in its lifecycle via a phase attribute:

SELECT 1
WHERE EXISTS(
    SELECT 1 
    FROM PRODUCTATTRIBUTE a,
         PRODUCTATTRIBUTE b,
         PRODUCTATTRIBUTE c, etc.
    WHERE a.product_id = b.product_id
    AND b.product_id = c.product_id
        etc. 
    AND a.attr_id = "doors" and a.attr_value = "4",
    AND b.attr_val = "productionphase" and b.attr_value 
> "2"
    AND etc. 
)
[download]

note: only the product/attribute table has attribute values - the attribute table has attribute ids without values (in practice you might have a strongly typed database imposed and have to split the attribute table into several by datatype with supporting navigation tables such as one for enumerated data and one for type-independent lookup)