The database design should not be dependent on the persistence layer implementation.

Consider the following situation:

Table A

• a_id (identity, pk)
• a_name (with unique constraint, a surrogate key)
• ...

Table B

• a_id (fk, pk)
• b_id (identity, pk)
• b_name (unique constraint)
• ...

Table C

• a_id (fk, pk)
• c_id (identity, pk)
• c_name (unique constraint)
• ...

Table D

• a_id (fk, pk)
• b_id (fk, pk)
• c_id (fk, pk)
• ...

The foreign keys defined in the database guarantee that the records in Table B and Table C referenced by a record in Table D both reference the same table A. Regardless of which clients are using the database, this structure is protected by the foreign keys.

This structure makes a lot of sense in many situations, i.e:
Table A - projects
Table B - activities
Table C - resources
Table D - activity / resource assignments.

It is guaranteed that a resource of a certain project can only be assinged to an activity of the same project.

When Hibernate does not support composite PK's with an identity part, database designers will have to resort to either programming logic or making the surrogate key the primary key (and providing all the cascading options) to support this structure.