Surrogate Keys
Surrogate Keys or IDs uniquely identify a record in a data set (table). Typically they (should) consist of only one column. Best example: ID column that is automatically incremented.
A Surrogate Key is also known as Meaningless Key.
Surrogate Keys should be used for internal purposes inside a relational database. They should be hidden to end users. To display unique identifiers to end users you may want to introduce an Alternate Key.
Surrogate Keys are “artificial” or a “substitute“. Some folks say a Surrogate Key is always a substitute for something and if there is nothing to substitue they cannot use the term Surrogate Key. I encourage you to be as precise as necessary.
Alternate Keys
Alternate Keys usually are a readable identifier for humans. You may want to include Alternate Keys if you need to display readable identifiers for a record to end users. It also may contain certain “meaning” in its value. This might be the case if it is derived from multiple columns of a record.
Alternate Keys may be artificial but are not limited to this. For example: A book record may contain an internal ID. It may also carry a ISBN number that may uniquely identify this book. Another example could be a product that has a Product No used in publications and order systems. This column may also be used as an Alternate Key column.
Natural Keys
Natural Keys are columns that out-of-nature create a unique identifier for a record. They contain readable text. Natural Keys may be created across multiple columns. Examples for a natural key are an ISBN number, a social insurance number or the tuple {FirstName, LastName, Address, BirthDate}.
Natural Keys are fine and you may want to use them as a basis for your Alternate Keys for display purposes.
But !NEVER! use Natural Keys as the Primary Key column to create relations between tables!! Many years ago I worked in a fashion company in which they used readable product numbers (consisting of a category and other stuff) as Primary Keys and after 25 years of business the numbers went out. Nice work followed :-).
ID Column
An ID or Identifier column is usually a non-readable internal column used to uniquely identify a record and to create relations between tables.
I recommend naming an Identifier column with only the two letters ID. Following the DRY principle you should not repeat the table name in all columns. Sticking to this principle will also make your queries easier to read. The ID column will always be addressed by a prefix table like myTableName.ID.
A Foreign Key column is always named following the schema: Table name + ID.
If your Product table has its own ID column and a ProductCategoryID column then it is easy to understand what might be the PK (*) and what is a FK to another table.
Imagine you have a large table with 20 Foreign Keys to other tables and its own ID column. It’s easy using Intellisense to distinguish the ID column from all the other Foreign Keys without having to find out the name of the column that is the ID column of that table (as this must not be the Primary Key and therefore marked with a yellow key symbol).
I encourage you to use the term ID in relational databases and omitting the term Key from being used in an OLTP system.
You may use the term Key as a substitue for the term ID in Data Warehouse scenarios. But please decide on which term you exclusively want to use.
Don’t start mixing Key with ID columns in the same database!

Conformed Dimension
Non-Conformed Dimension
Shared Dimension
Normalized Dimension
Denormalized Dimension
Degenerated Dimension
Additive Measures
Semi-additive Measures
Non-additive Measures