Sorry, I have to disagree with you, and strongly.

First of all, identity columns are unique within a table on a given server. Always. Unless there are some replication issues, these are ideal as PK's, as the footprint is very small. Efficiency is important in large database design, both for updating and querying data. GUIDs are good alternatives, but being alphanumeric and much longer, are inherently less efficient (but they are also guaranteed unique across tables and servers)

Secondly, natural keys (what you've called logical keys) are, in my opinion, poor choices for primary keys. Natural keys suffer from a number of problems, among them:
a) If generated outside a system (such as SSN's) there is no way to guarantee uniqueness
b) If generated inside a system, they very often rely on business rules for their generation. Business rules are subject to change. You do NOT want the rules for primary key generation to EVER CHANGE.
c) They also tend to be alphanumeric in composition, and can get quite large depending on the bizrules that generate them. Integer identity columns, again, are much more efficient.
d) Users tend to memorize them. If for some reason the business rules change their appearance, you've got a training issue waiting to happen.

I for one have seen no good reasons for using compound primary keys, ever. Yes, there may be good business reasons for having a natural key as a CANDIDATE key - something that you want to enforce uniqueness on, for lookups, but upon which you don't want to bet the farm on for uniqueness, for reasons I've noted above. Single-column surrogate keys have no function other than to uniquely identify a record. In fact, they should normally be completely hidden from the user.