Employee projects have subtypes if the candidate subtypes are
- not utterly different, but
- not exactly alike
That means that
- Every employee project has some
attributes (columns) in common. So they're not utterly different.
- Some employee projects have different
attributes than others. So they're not exactly alike.
The determination has to do with common and distinct attributes. It doesn't have anything to do with the number of columns in a candidate key. Do you have employee projects that are not utterly different, but not exactly alike?
The most common business supertype/subtype example concerns organizations and individuals. They're not utterly different.
- Both have addresses.
- Both have phone numbers.
- Both can be plaintiffs and defendants
in court.
But they're not exactly alike.
- Individuals can go to college.
- Organizations can have a CEO.
- Individuals can get married.
- Individuals can have children.
- Organizations (in the USA) can be liquidated.
So you can express individuals and organizations as subtypes of a supertype called, say, "Parties". The attributes all the subtypes have in common relate to the supertype.
- Parties have addresses.
- Parties have phone numbers.
- Parties can be plaintiffs and defendants
in court.
Again, this has to do with attributes that are held in common, and attributes that are distinct. It has nothing to do with the number of columns in a candidate key.
To me a composite key relationship is
a 'Is A' relationship
(Employee_Project is a Employee and a
Project).
Database designers don't think that way. We think in terms of a table's predicate.