Peter,

> Not that the remainder atributes are Candidate Keys; They just are not, because they won't be unique anyhow. Right ?

A candidate key is any attribute or group of attributes that can be used to uniquely identify an instance of the entity. In my example both the CustID (PK) and the CustNum (CK) will be unique for every customer record. They must be because the business rules state that they must be unique. Because they must be unique they are both "Candidates" for being the primary key, candidate keys. We choose one of them to work as the primary key thus relegating the other to being a candidate or alternate key.

>Sadly your example just doesn't allow to remove the CKs to new entities (as you state yourself).

That is because they are, in fact, CKs. If they could be removed to another entity it would be because they violate some other NF. For example;

Three entities Projects PK PN, members PK MN, adn Advisors PK AN. Rules;

1. projects may have many members
2. members may have many advisors
3. Projects may have many advisors
4. a member on a Project has only one advisor

Initaial design to track projects and their advisors and members

PN (PK part 1)
MN (PK part 2)
AN

This design is in 3rd NF because AN is dependent on the complete PK (the combination of PN and MN)

The combination of AN + MN is also unique by definition since a member can only be on the project once and that member has a single advisor. This means that the following is also a possible design;

MN (PK Part 1)
AN PK (Part 2)
PN

However, in this situation the PN is NOT dependent on the entire PK but on only a subset of the PK causing this design to NOT be in 3rd NF.

This does not mean that BCNF prcludes the existance of valid and necessary CKs but rather that if there are any CKs one must apply the BCNF to flesh out problems in the design.