The primary key

One of expert said that  "the primary key of a table is a set of one or more attributes such that every row in the table has a unique value. When these attributes are things that the business uses routinely, the key is called a “natural key.” Examples could include Social Security numbers, vehicle identification numbers, customer or patient IDs, account numbers, and so on. However, sometimes a table has no obvious natural key, or the natural key has many columns. Database designers frequently create a key using a sequence generator. This is called a “synthetic key,” because it serves the purpose of a primary key but has no real meaning to the business."   After research the internet and books I figured out  that he or she hit upon one of the strong arguments for synthetic keys instead of Natural keys – the multi-field primary key.  The problem occurs when you have one key that propagates through several tables.  The first table may only have 1 field as its natural PK, but then if it gets used in another table, that table may now need to have 2 (or more) fields concatenated to define the PK.  Very quickly you may have a table that has a PK in a table consisting of many (4, 5, 6+) columns to define it.  
With a synthetic key defined on every table (auto-generated number), you will have one, and only one numeric column for the table PK. So when it migrates as a FK into other tables, the join is only on 1 single numeric field. Row uniqueness can then be ensures by a surrogate key (alternate key) that is composed from as many columns as necessary to define uniqueness.
This architecture has several advantages:
The PK is numeric, therefore the B-Tree index is most efficient when doing joins.
No more than 1 column ever migrated from a table as a FK.
In some cases, multiple alternate keys can be defined on a table without system conflict.