Я тут как-то писал другу-студенту свое понимание, сейчас нашел в логе. Могу немного ошибаться, т.к. на суперспециалиста по базам данных не претендую.
По поводу терминологии — может наблюдаться некоторая взаимозаменяемость терминов, поэтому сразу оговорюсь, чтобы не было придирок: при логическом моделировании БД используются термины сущность, экземпляр сущности и атрибут. В физической модели им соответствуют таблица, строка и колонка.

Первая нормальная форма:

• Значения атрибутов должны быть атомарны. Т.е., к примеру, не должно быть списков. Таким образом, атрибут CustomerEmails сущности Customer, который может иметь значение “vasya@mail.ru;vasya-super-coder@yandex.ru” нарушает первую нормальную форму. Решение – завести отдельную таблицу customer_emails с полями CustomerID и Email. Так же не должно быть составных значений, если возможно потребуется работать с частью этих значений. К примеру, если у сущности Customer есть атрибут FullName (ФИО), и может потребоваться работать только с фамилией (к примеру где-то в программе вычленять фамилию из ФИО и выводить только фамилию, или делать поиск по фамилии в БД), то в таком случае атрибут FullName нарушает первую нормальную форму.
  
  
• Все экземпляры сущности должны иметь одинаковое количество атрибутов и их значений. Реальный пример (нарушающий 1НФ) встречающийся на практике: Сущность Заказ имеет атрибуты Supplier1, Supplier2, Supplier3 для указания поставщиков, которым может быть отравлен заказ. Т.е. сначала заказ от клиента отправляется первому поставщику и ID поставщика записывается в поле Supplier1, если этот поставщик не поставляет заказ, то заказ отправляется другому поставщику и его ID записывается в поле Supplier2 и т.д.. Соответственно, в таблице у некоторых строк указан только Supplier1, у других Supplier1 и Supplier2, у третьих – все. Это нарушает первую нормальную форму. Решение – завести отдельную таблицу supplier_orders с полями CustomerOrderID, SupplierID и другими атрибутами, описывающими заказ поставщику.
  
  
• Все экземпляры сущности должны быть разными. Это условие требует наличие ключа (первичного или уникального), с помощью которого можно однозначно отличить одну сущность от другой, и не должно хранится сущностей с одинаковым значением ключа. Технически, это условие можно выполнить, добавив суррогатный ключ (типа автоинкрементного счетчика или GUID), но при этом в таблице могут быть строки, у которых значения всех остальных атрибутов одинаковые, и которые на самом деле указывают на одну и ту же сущность (т.е. к примеру в таблие могут быть 2 строки с разными CustomerID но описывающими на самом деле одного и того же клиента) – это неправильно. В таком случае можно либо добавить еще один уникальный ключ (к примеру по номеру паспорта клиента), либо вообще вместо суррогатного первичного ключа использовать естественный первичный ключ (т.е. основанный на естественных, а не автоматически генерируемых атрибутах).

Вторая нормальная форма:

• Сущность должна находиться в первой нормальной форме.
  
  
• Каждый неключевой атрибут сущности должен зависеть от всего первичного ключа (а не только от одного из атрибутов первичного ключа). К примеру есть таблица book_author, хранящая общую для автора и книги информацию (к примеру, какой процент от продаж издательство будет платить автору за определенную книгу). Первичный ключ составной, и состоит из атрибутов AuthorID и BookISBN. Неключевые атрибуты: AuthorPercent, BookTitle, AuthorFirstName, AuthorLastName. Атрибут AuthorPercent зависит от всего первичного ключа, т.е. и от ID автора и от ISBN книги, а не только от автора или только от книги, поэтому с этим атрибутом все в порядке. Атрибут BookTitle зависит только от ЧАСТИ первичного ключа, а именно от книги (т.е. только от атрибута BookISBN). Поэтому атрибут BookTitle нарушает вторую нормальную форму. Таким же образом нарушают 2НФ атрибуты AuthorFirstName и AuthorLastName. Решение — либо убрать атрибуты BookTitle, AuthorFirstName и AuthorLastName из таблицы book_author (если они уже есть в соответствующих таблицах books и authors), либо перенести их в соответсвующие таблицы books и authors (если их там по каким-то странным причинам еще нет).

Третья нормальная форма:

• Сущность должна находиться во второй нормальной форме.
  
  
• Неключевые атрибуты не должны зависить от других неключевых атрибутов (т.е. все неключевые атрибуты должны зависеть только от ключа). К примеру есть таблица books, первичный ключ в ней – BookISBN, и так же есть атрибуты Title, Price, PublisherID, PublisherCity. Присутствие атрибута PublisherCity нарушает третью нормальную форму, т.к. этот атрибут на самом деле зависит от неключевого атрибута PublisherID, а не от BookISBN.