bas1. Каждый атребут должен содержать только атомарные значения, т.е. атрибут не должен содержать значения "Петров Иван Иванович", вместо этого должно быть 3 атрибута.
2. Каждый неключевой атрибут (это тот атрибут, кот не входит в состав PK), должен однозначно зависеть от ключевого(ых) атрибута(ов). Т.е. кол-во товара на складе в магазине долно зависеть от свзяки (магазин, товар), а не просто от Товара или Магазина. Можно еще сказать по другому - каждая запись должна быть уникальной.
3. Не одно из ее неключевых атрибутов не зависит функционально от любого другого неключевого атрибута. Т.е. имя таблицу Собака(ИД, Имя, Порода), Мы должны разбить на две Собака(ИД, Имя) и ПородаСобаки(ИД, Порода). Это не всегда удобно для этого введа НФБК.
НФБК. Если любая функциональную зависимость между его атрибутами сводится к полной функциональной зависимости от возможного ключа. Т.е. в пред. примере мы имеем два возможных ключа: ИД и Имя, и зависимость Порода->Имя сводится к зависимости неключ. атрибута от возможного ключа.Многовато ошибок. Мне-то все равно, а вот кто-нибудь начинающий прочтет и поверит. Итак:
1. Атомарность характеристики есть понятие не абсолютное, а относительное. То есть для одной задачи и, скажем, атрибут ФИО пойдет, а для другой надо атрибуты Ф, И, О заводить. Критерий простой: если для предполагаемых запросов не требуется оперировать *частью* значения атрибута, его атомарность верна. Если есть предполагаемые запросы, для которых нужна часть значения атрибута, проект (скорее всего) неверен.
2. «каждая запись должна быть уникальной» вообще не имеет к нормализации никакого отношения. Это имманентное свойство реляционной модели данных.
3.Пример неверен. Отношение Собака(ИД, Имя, Порода) уже находится в 3НФ, т.к. в нем все неключевые атрибуты нетранзитивно зависят от потенциальных ключей. Ничего разюивать не надо.
4. НФБК можно сформулировать и короче (это не ошибка, просто подсказка). Итак, отношение находится в НФБК, если каждый детерминант является потенциальным ключом.