dante77Имеется таблица заказов с потенциальным первичным ключом (Поставщик, Наименование_детали)
Однако, требуется, чтобы каждому заказу был присвоен идентификационный код, следовательно, это тоже потенциальный первичный ключ. Получается, что эта таблица не нормализована по BCNF
Заранее спасибо.
Еще не видно, что "Получается, что эта таблица не нормализована по BCNF". Нужны еще зависимости. Наличия нескольких ключей не достаточно. Нужны транзитивные зависимомсти.

dante77
Может действительно голову не морочить c BCNF, сколько я ресурсов в сети перерыл, часто пишут, что нормализация по BCNF, 4NF и 5NF при решении практических задач встречается редко. Это, наверное, и имелось в виду под "обычной" жизнью.

Если схема нормализована по 3НФ, но не нормализована по НФБК, то нормализация по последней может привести к невозможности обеспечить полноту схемы (нельзя навязать ФЗ с помощью выделения ключей). Т.е. сложноссти с обеспечением ОЦ.


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

Вообще то нужны транзитивные зависмости. Без этого хоть сто составных всевозможных ключей не помогут нарушить НФБК. Т.е. нужно, чтобы был(и) атрибут(ы), от которого(ых) бы зависел ваш Поставщик или Наименование детали, но этот атрибут(ы) не был(и) бы ключем (ни каким: ни потенциальным, ни первичным). Если бы при таковой зависимости пара (Поставщик, Наименование_детали) не была бы ключем, то было бы нарушение 3НФ.

dante77Почему? Транзитивные зависимости устраняются же при нормализации по 3NF!

Таблица находится в третьей нормальной форме (3NF), если
она находится во второй нормальной форме (2NF),
и при этом любой ее неключевой атрибут зависит только от первичного ключа (Primary key, PK)
Не все транзитивные зависимости устраняются из отношения при нормализации по 3NF!
Еще могут оставаться транзитивные зависимомсти для НФБК. Вот при нормализации по
НФБК устраняются все транзитивные зависимости.
Отношение находится в 3НФ, если оно находится в 1НФ и не один не первичный атрибут (т.е. который не входит ни в один ключ, наверное, в Ваших терминах - не ключевой) транзитвно не зависит ни от одного ключа.
А при НФБК снимается требование первичности транзитивно зависимого атрибута:
там просто ни один атрибут не должен транзитивно зависеть ни от одного ключа.
Т.е. и первичные (ключевые) не должны транзитивно зависеть. Вот их то Вы и устраняете нормализуя по НФБК, если отношение уже нормализовано по 3НФ (устранены для не ключевых).
Это существенно из-за того, что у НФБК есть проблемы с полнотой, а у 3НФ их нет.
Ну там еще кое-что про сложность алгоритма выявления проверки НфБК отличает от 3НФ.

dante77Нижеприведенное определение BCNF правильное?

Нормальная форма Бойса-Кодда (BCNF)
Таблица находится в BCNF, если она находится в третьей нормальной форме, и при этом отсутствуют функциональные зависимости атрибутов первичного ключа от не-ключевых атрибутов.

Данная нормальная форма — это модификация третьей нормальной формы. Таблица может находиться в 3NF, но не в BCNF, только в одном случае: если она имеет, помимо первичного ключа, ещё по крайней мере один составной возможный ключ, и по крайней мере один из атрибутов таблицы входит и в первичный, и в возможный ключи. Такое бывает достаточно редко, в остальном 3NF и BCNF эквивалентны.
Ну я приводил Вам определение. Ведь есть же смысл нормализации, а не просто так табу какие-то там, чтобы их знать и отличаться от тех кто не знает. Зачем нужны эти нормальные формы?
Из тех простых определений, что я приводил это видно (без лишних слов "состаной", "возможный" и проч):
Ясно что если есть транзитивная зависимость, то это означает возможность избытка.
Ее устранение приводит к устранию именно этой возможности (хотя есть другие причины для избыточности, устраняемые более высокими формами НФ), потому транзитивная зависимость и фигкрирует в определении.
Если схема в BCNF, то нет вообще транзитивных зависимостей, а при 3НФ они еще могут быть - BCNF более сильная, сильнее подавляет избыток. Зачем тогда нужна 3НФ? Ее определение расчитано на частный случай транзитивных зависмостей. Зачем все эти упоминания про первичные ключи - определение выглядит сложнее, чем НФБК.
Проще продемонстрировать проблему:
Рассмотрим схему отношения из трех атрибутов:
A, B, C.
Пусть есть ФЗ: С от В, В от А, но нет ФЗ А от В, т.е. транзитвная зависмость (обеспечивает избыток по С). Тогда А ключ (иначе дубли, а их не может быть в отношении). С не входит ни в один ключ (нет кроме перечисленных ФЗ) Нарушена 3НФ. Нормализуем (устраняем избыточность вызванную транзитивной зависимостью):
декомпозиция на отношения со схемами АВ и ВС. Соединение без потерь обеспечивает ФЗ С от В.
И еще важная деталь: в первом выделим (объявим) ключ А, а во втором В и тем самым навяжем схеме все выше перечисленные ФЗ: юзер не сможет для одного значения А внести разные В и т.д.
Теперь НФБК:
Та же схема, но зависимости:
С от В, В от АС.
Теперь очевидно есть ключи АС и АВ. Причем от АВ транзитивно зависит С, что дает повод беспокоиться об избыточности. Однако, С - первичный: входи в ключ АС. Отношение находится в 3НФ, но не в НФБК.
Если мы теперь устраним избыточность как и прежде, то выяснится, что мы не можем навязать схеме ФЗ В от АС с помощью выделения ключей, поскольку АС не содержится ни в одном отношении. Но схема в НФБК, хотя юзер может для однинаковых значений пары АС внести разные В. Т.е. проблемы с контролем избыточности устранили, а с контролем ОЦ есть.
Есть другой вариант схемы: первое отношение сохранили и добавили отношение ВС. В первом выделили ключи АС и АВ, а во втором В. Теперь схема в 3НФ, все ФЗ навязаны, но НФБК нарушена, есть проблемы избыточности. Однако, это показывает, что у 3НФ нет проблемы с навязываеием всех ФЗ, а у НФБК есть, что и делает 3НФ достойной быть выделенной в отдельную форму.
Такова примерно обусловленность наличия 3НФ, более слабой чем НФБК, но более сложной в определении.

Опечатка: вместо пеервичные ключи читать первичные атрибуты. Т.е. атрибуты которые входят хоть в один ключ.

На те же в первом примере: AB и BC. Устраняем ить транзитивную зависимость С от АВ. Кроме того, только зависмость С от В позволяет произвести декомпозицию без потерь. Если произвести на АС и СВ, то после соединения можем получить несколько больше записей, чем было в АВС. А больше вариантов устранить транзитивную (для нее нуно как минимум три атрибута) зависмомть нет - тока два. Ну извиняюсь, если невнятно написал в предыдущем посту.

А Вы все еще думаете найти в этих формах семидесятых годов, что-то новое, кроме избитых истин, которым нас учили в свое время все эти профессора?

dante77Я понял, спасибо.

Хотя я бы, увидев, что и первичный ключ АС и возможный ключ АВ имеют общий атрибут А и руководствуясь принципом "таблица может находиться в 3NF, но не в BCNF, только в одном случае: если она имеет, помимо первичного ключа, ещё по крайней мере один составной возможный ключ, и по крайней мере один из атрибутов таблицы входит и в первичный, и в возможный ключи", произвел бы декомпозицию на те же отношения АВ и ВС. В результате таблица нормализована по BCNF. Так ведь?

Этот Ваш принцип, а точнее какая-то теорема, которую еще надо вывести из того простейшего и ямно определения, что я дал (а я его естевтвенно давно вычитал в книгах по теории РБД, а не сам придумал), не совсем ясен в плане пользы от него. Мне кажется, что он тока все усложняет, даже если окажется не ошибочным. Тем более, что первичные ключи к НФ не имеют отношения по любому. Они имеют отношение к навязыванию схеме ФЗ, наряду с альтернативными. Т.е. это разновидности того, что я называл выделенными.

Схема то нормализована по BCNF. Это позволяет подавить избыточность. Но что делать с ОЦ?
Ведь зависимость В от АС в этой схеме навязать нельзя (с помощью объявления хать первичных, хоть альтернативных ключей). Значит она будет нарушена?
Произойтет нарушение логических правил, которым должны отвечать данные. Это придется как-то контролировать. Не ясно что хуже. Проектировщик стоит перед выбором.

dante77Я хочу теорию максимально применять на практике и посмотреть что из этого выйдет.
Это, конечно, доброе дело.