|
SQL*Plus
Отношение, имеющее такое "содержание" состоит из трех атрибутов,
совокупность которых является первичным ключом этого отношения.
Поскольку никаких неключевых атрибутов нет, не может быть
ни их неполной функциональной зависимости от первичного ключа,
ни функциональной зависимости между ними (транзитивной зависимости от первичного ключа).
То есть отношение, не имеющее неключевых атрибутов, находится и в 2NF, и в 3NF.
.
Т.е. Вы согласны, что без "семантики" все же можно иногда понять, что отношение находится в 3НФ?
т.е. не совсем точна фраза в плане выявляения нахождения в 3НФ по "содержанию"
SQL*PlusНевозможно по содержанию таблицы данного отношения в данный момент сказать,
находится или нет это отношение, например, в 3НФ.
.
Кроме того, мне кажется, проще сказать с точки зрения НФ, что там нет ФЗ ( кроме тривиальных: атрибут зависит от самого себя, и потому, подмножество атрибутов зависит от множества, содержащее данное подмножество).
В частности, например, оно находится не только в "и в 2NF, и в 3NF.", но и нормальной форме Бойса Кодда, которое нарушена даже если транзитивно завит ключевой атрибут(входящий в некоторый ключ).
Т.е. упоминание про не ключевые излишне, скорее всего, в данном примере.
Еще, возможно, стоит упомянуть для начинающих, что если находится в в 3NF, то находится и в 2NF. Если в Бойса Кодда, то и подавно в "и в 2NF, и в 3NF."
Но я был тоже не точен, не упомянув про тривиальные зависимости. Конечно, это формальность, но имеет значение при выводе одних ФЗ из других в теории.
Для начинающих в связи с этим тут можно отметить, что есть понятие ключа, и есть понятие суперключа. Любой ключ если его дополнить атрибутом, тоже будет уникальным. И может быть назван супеключом. Однако, не ключом. У ключа никакое собственное подмножество не может быть ключом. Иначе это был не ключ, а суперключ. Однако, супеключ, скорей всего, имеет только то практическое значение, что мог быть ошибочно принят за ключ.
Например, все атрибуты отношения всегда суперключ в теории.
Но в реальных СУБД используется понятие мультимножества, вместо множества. Т.е. все записи таблицы могут быть не уникальны.
SQL*PlusСформулируйте вашу мысль еще раз, другими словами и с примерами.
Мысль в том, что тут без "семантики" нельзя сказать, что нарушена 3НФ. Т.е. в этой части, мне показалось, ваше утверждение точным.
В основе утверждение что выявить ФЗ без семантики нельзя, так оно должно быть во всех возможных состояних БД, тогда как для нарушения достаточно одного состояния.
Приведу пример. Но пояснения, окажутся длинными, иначе могут истолковать не то, что хотел сказать.
Пример.
1 состояние, в котором как есть ФЗ для нарушения 3НФ.
<1,2,3>
<2,2,3>
<3,3,3>
Очевидно, первый атрибут выглядит как ключевой (но не факт что и потом останется таковым). И потому от него все остальные зависят. Однако он не зависит в данном состоянии ни от какого подмножества атрибутов, так как все они не уникальны, а он уникален. Но третий зависит от второго (третий вообще имеет только одно значение). Так как первый не зависит от второго, то это выглядит как транзитивная зависмость третьего атрибута от первого. Ну так же этот третий не входит на в один из ключей. Он мог входить только в ключ состоящий из второго и третьего. Но эта пара не уникальна (1 и 2 запись имеют одинаковый набор).
Т.е. выглядит как нарушение 3НФ.
Ну допустим провели диспозицию, посчитав, что есть избыточность.
Получили два отношения
<1,2>
<2,2>
<3,3>
<2,3>
<3,3>
Видно, что во втором отношении 2 записи вместо 3. Есть «выигрыш» из-за устранения избыточности: если есть ФЗ, то для второго значения 2, третий всегда имеет значение 3. У нас один раз уже это была, что значению 2 соответствует 3. Второй раз занесли уже известное ранее.
И, соединив эти отношения по атрибуту, который был вторым, получим в точности исходное отношение, т.е. правильную информацию (исходное считаем правильным)
<1,2,3>
<2,2,3>
<3,3,3>
Но ведь это все было сделано на основе состояния БД, без «семантики».
Тогда не исключено переход БД в состояние, в котором “содержание” отношение:
<1,2,3>
<2,2,3>
<3,3,3>
<4,3,4>
Нарушение ФЗ третьего атрибута от второго: значению 3 второго теперь может соответствовать как 3 так 4. Оно находится, к примеру, в 3НФ.
И если провести его декомпозицию как в первом случае, то получим
<1,2>
<2,2>
<3,3>
<4,3>
И
<2,3>
<3,3>
<3,4>
Но если теперь соединить, чтобы получить исходное, то получим
<1,2,3>
<2,2,3>
<3,3,3>
<3,3,4>
<4,3,3>
<4,3,4>
Т.е. записи, которых не было в исходном отношении. Это и называют иногда соединением с потерей информации. Поэтому проводить декомпозицию нельзя.
Есть теорема о том, что при нарушении НФ, существует декомпозиции без потерь информации (которая может снизить избыточность).
ФЗ выведенные из "семантики" должны быть верны для всех состояний БД. Впрочем, их еще надо выявить и желательно навязать схеме. Что не удается например для нормальной формы Бойса Кодда, но всегда удается для 3Нф.
Потому обычно 3НФ как может обеспечить логичческую оптимальность схемы, а выше уже как теория не может сказать что оптимальнее: навязывание ФЗ или отсутствие избыточности.
|
