Нормальная форма - что это такое?

Всего их шесть штук 1NF, 2NF, 3NF, 4NF, 5NF, 6NF плюс одна загадочная DKNF. Коротенько про все формы на вики, подробно можно почитать в Часть 1 в учебнике Ребекки М.Райордан.

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

Я расскажу только про первые три формы.

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

Всё просто - никаких массивов данных в ячейках таблиц, никаких перечисляемых через запятую значений.

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

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

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

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

Это означает, что мы должны исключить из таблицы атрибуты, которые не имеют отношение к объекту Заказ. Но просто так их выкинуть нельзя, раз мы их включили в таблицу, значит нам нужна эта информация. В таких случаях необходимо провести декомпозицию таблицы - разделить её на 2, 3 и более таблиц, по количеству функционально связанных наборов атрибутов - отношений.
Представленную выше в первой нормальной форме таблицу декомпозируем на три: Заказы, Клиенты и Товары.

Раз - потенциальным ключом является номер заказа.

Два - потенциальным ключом является код клиента. Адрес и телефон клиента функционально не зависят от Заказа.

Три - потенциальным ключом является номер заказа. 

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

На самом деле мы имеем дело с заказанным товаром, а не просто с ассортиментом, который предлагает магазин своим клиентам. Нам нужно немного изменить набор атрибутов в таблице, а наш потенциальный ключ станет составным. А для составных ключей мы используем суррогатные ключи (см.пост про Ключи).

Поле "Номер записи" - это наш суррогатный ключ, образованный от 2-х потенциальных ключей - Номер заказа и Код товара.

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

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

Предположим, нам нужно доставить наши заказы по указанному адресу. Выглядит логичным, если адрес доставки мы укажем в таблице заказов, вот так:

Но с ракурса приведения данных к третьей нормальной форме, такое проектирование не корректно. Адрес доставки не является атрибутом заказа, а описывает местонахождение клиента или точнее место, по которому он готов принять данный заказ. Т.е. адрес доставки соотносится с заказом транзитивно - через Клиента. И правильный паттерн проектирования в этом случае будет таким:

При этом таблица Заказы остаётся без изменений, как показано в разделе 2NF.

Словарь терминов RDB:

Кортеж - это запись или строка в таблице (tuple, row).

Атрибут - это поле или заголовок в таблице с записями (column, attribute).

Отношение - таблица с записями и атрибутами (Relation).

Постскриптум: Ещё несколько слов про Отношения. На самом деле, если бы ООП - объектно-ориентированный подход (или проектирование) - появился чуть раньше, чем Кодд сформулировал свои принципы реляционной модели, то возможно мы бы с вами изначально оперировали бы терминами Сущность или Класс вместо Отношения. Имхо это одно и то же. 

Можно ли обойтись без нормальных форм в процессе моделирования данных? В целом да, при достаточной насмотренности на бизнес-процессы и функции, вам не составит труда правильно выделить Сущности (это наши Отношения), описать их через атрибуты и определить, какие из них являются потенциальными ключами (бизнес-ключи). А дальше протягиваем связи между сущностями и готова логическая модель данных!
Моделирование хранилищ данных - общие понятия. Часть 1