Для чего проводят нормализацию структуры данных? Для того чтобы данные потом вели себя в ней в соответствии с нашими бизнес-ожиданиями (см. основные принципы поведения данных в Моделирование хранилищ данных - общие понятия. Часть 2). Для этого и придуман инструмент нормализации, а точнее набор Нормальных Форм, которые определяют структуру базы данных.

Первым это понятие ввел Кодд, он же разработал первые три нормальные формы. Но перед тем как разбирать более подробно нормализацию и каждую из форм, надо вспомнить что же такое ключи и какие они бывают.

Каждая строка таблицы в реляционной базе данных должна содержать уникальный набор атрибутов, иначе говоря значения не должны повторяться - это один из основных принципов минимизации избыточности данных. Для того, чтобы добиться этого, необходимо на логическом уровне моделирования определить потенциальные ключи и выбрать из них первичные для дальнейшей физической реализации в базе данных.

Потенциальный ключ (candidate key) - в реляционной модели данных подмножество атрибутов отношения, удовлетворяющее требованиям уникальности и несократимости* (минимальности). Иногда этот ключ ещё называют натуральным или бизнес-ключом.

Альтернативный ключ (alternate key) - это потенциальный ключ, который не является первичным ключом отношения. Иногда его ещё называют Уникальный ключ, Возможный ключ.

Пример: нам нужно как-то отделять друг от друга экземпляры бизнес-сущности "Физическое лицо". Потенциально, мы можем сделать это по номеру СНИЛС, или по номеру паспорта, а также по номеру телефона. Все перечисленные свойства сущности "Физическое лицо" - это Потенциальные ключи! Но чтобы не ошибиться, необходимо погрузиться в предметную область и понять для чего - для каких задач и целей - мы проектируем базу данных. Это приводит нас к мысли, что только бизнес-эксперт может точно сказать вам, какой именно атрибут из перечисленных для него является номером "Один" или какое из перечисленных свойств самое главное для физического лица, по которому мы будем их - физлиц - различать. Именно этот атрибут станет Первичным ключом в базе данных. (Оставим в стороне сейчас сложный случай, когда бизнес-эксперт захочет проверять уникальность и генерировать первичный ключ по всем 3-м полям.)

Например, бизнес-эксперт выбрал в качестве первичного ключа СНИЛС, а что же будет с остальными атрибутами, которые тоже были определены как потенциальные ключи? Да ничего особенного. Просто в процессе выбора первичного ключа, на них поставили штамп "Отказать". При этом ни на их свойства уникальности, ни на тот факт, что потенциально все они могли бы стать первичным ключом, это никак не повлияло. А это значит, что они остаются очень важными и существенными признаками нашей бизнес-сущности, и мы просто не имеем право не обращать на них внимание. Это наши Альтернативные или Уникальные ключи.

Любой потенциальный ключ может стать первичным, выбор за вами, а точнее за владельцем данных, ведь именно он должен сказать какой из атрибутов для него самый важный, самый уникальный и наиболее точно идентифицирует его бизнес-сущность.

Крайне желательно в процессе сбора требований к данным, уделить внимание всем этим ключам и пометить атрибуты, в которых они хранятся, каким-то отдельным признаком или тэгом. Ведь может возникнуть ситуация, при которой бизнес-эксперт передумает и решит сделать Первичный ключ из другого Потенциального ключа. Такое часто бывает, когда условия первоначальной задачи изменяются или расширяются границы бизнес-продукта. 
Промежуточный итог:  все атрибуты, отвечающие требованиям уникальности, являются Потенциальными ключами; один такой потенциальный ключ становится Первичным, а остальные называются Альтернативными.

С логическим уровнем моделирования мы закончили, переходим на физический уровень.

Первичный ключ (primary key) — идентификатор сущности ID, выбранный в качестве потенциального ключа (или ключа по умолчанию) в процессе моделирования сущности или при проектировании базы данных. Первичный ключ обеспечивает уникальность экземпляров сущности, отсутствие дублей. В физической реализации может быть заменён на суррогатный ключ, искусственно сгенерированный для отдельной записи в таблице. Первичный ключ - это обязательный элемент физической модели данных, в то время как в концептуальных моделях их не используют, а в логических применяют по потребности. Пример модели

Внешний ключ (foreign key) — идентификатор другой сущности ID, на которую мы ссылаемся при описании/моделировании данных, проектировании баз данных. Обеспечивает ссылочную целостность - корректную связь между данными, позволяя таким образом поддерживать актуальность информации о сторонних сущностях в любой момент времени. Обязательный элемент физической модели данных. Пример: сущность "Продукт" ссылается на сущность "Группы продуктов", которая описана отдельным объектом данных ProductGroup, в физической реализации потребуется создание внешнего ключа ID_ProductGroup, а не простого атрибута Group_product. Пример модели

Суррогатный ключ (surrogate key) - это дополнительное служебное поле, добавленное к уже имеющимся информационным полям таблицы, единственное предназначение которого - служить первичным ключом; значение этого поля не несёт никакого бизнес-смысла, а генерируется искусственно. Использование суррогатных ключей сегодня - обычная практика, практически невозможно встретить базу данных, в которой в качестве ID (первичного ключа) использовался бы натуральный ключ. Это практика прижилась после усложнения процессов и приложений, когда в качестве потенциального ключа необходимо стало использовать сочетание двух и более атрибутов сущности, т.е. создание суррогатного ключа стало необходимостью, а не исключением из правил.

 
Здесь дано очень простое и поверхностное объяснение, не описаны правила и методы отбора и формирования самих ключей. Подробнее можно почитать в учебнике по реляционным базам данных, ссылка на который есть в статье Моделирование хранилищ данных - общие понятия.Часть1.    

*Несократимость (неделимость, неуменьшаемость, минимальность) - ровно столько знаков, сколько вы видите, и не меньше, и не больше, а иначе признак уникальности пропадёт!