An integral part of transactional relational databases is the Primary Key (PK). A PK is a value that defines the data row and that related tables use to relate via a Foreign Key (FK).
Four standard criterion are commonly used to measure a PK.
1. Is it unique?
2. Is it immutable?
3. Is it minimal?
4. Is it never null?
A key can consist of one or more columns in a table as long as the combination meets the criteria.
My recommendation is that you stick to a Surrogate Key if you don't know. Here's why-
Natural keys made under an assumption that some business rule will not change can cause significant problems later when it does.
Most arguments for natural keys place emphasis on ease of use. If you find yourself joining multiple columns because your PK is a combo key then you lose that value. Create views to ease your suffering from joining a few more tables in your queries.
The exception I would make is for SOME lookups. Esp when a well defined code is used as the natural key. Bit even then, shit changes all the time. Suppose you assumed that the US state codes were immutable. Or telephone area codes. You would have to write scripts to update all those FKs that use 'Calif' or use some hacked in solution to fix your data and update all the apps that consume the data to support the hack. Contain volatility in your data!