In the case of tables with a natural PK of more than one column (i.e. composite PK) is it better to use an identity column (sequence in Oracle) as the PK and use a unique constraint on the columns that form the natural PK? Is this a better design ? Does this make any difference to LLBLGen Pro?

IMHO, in case of a composite PK it is better from a database design point of view to use an identity column as the PK and use a unique constraint on the columns that form the natural PK. Especially if you are going to have references for this table in another tables. So istead of having 2 or more fields as FKs in any table that uses the specified table, only one Int field will be enough to be the FK if you use an Identity PK.

Also I think there could be a slight performance advantage in LLBLGen Pro, taking into consideration the PK-FK synchronizations done when you associate related entities to one another.

I agree with Walaa--I prefer single-column PKs whenever possible, and surrogate keys (identity/sequence) is even better (IMHO).

We currently have a project where we use natural keys in a lot of places where we have no choice. Some of these keys are composite. This can cause performance problems when we fetch a deep graph that has entities with composite keys. This is simply because the subqueries get more and more complex as the graph gets larger.