Как вы вычисляете функциональные зависимости для декомпозиции? - PullRequest
3 голосов
/ 27 февраля 2012

Скажем, R имеет следующие атрибуты: {A, B, C, D, E} и имеет следующие функциональные зависимости:

A -> BC
CD -> E
B -> D
E -> A

И есть разложение, состоящее из R1 (A, B,В) и R2 (A, D, E).Как я могу вычислить функциональные зависимости R1 и R2?

Актуальный вопрос о домашнем задании спрашивает меня, есть ли R1 / R2 в BCNF / 3NF / нет, но я уже знаю, как выполнить эту часть (посмотрите, содержатся ли левые части FD в ключах-кандидатах).).

1 Ответ

4 голосов
/ 28 февраля 2012

Хитрость заключается в том, чтобы думать о FD как об определяющих ключах, не в вашей заданной схеме, а в ее ПРОЕКТАХ.

Например, в вашей стартовой схеме {ABCDE} FD A -> BC говорится, что A ({A}, фактически) представляет собой ключ в этой таблице, спроецированный до {ABC}. Таким образом, объединение LHS и RHS FD определяет, какая проекция, а LHS определяет ключ в этой проекции.

Теперь перейдем к разложенной версии, в которой у вас есть две отдельные таблицы (схемы) {ABC} и {ADE}.

Ваш первый и последний FD все еще можно выразить в этих схемах. Первый FD в первой схеме / таблице и последний в последней.

Но остальные два стали невыразимыми (то есть невыразимыми AS FD , то есть) из-за разложения. Для всего проекта базы данных это означает, что вам придется объявить / определить / реализовать ограничение базы данных, которое говорит и делает то же самое, что и исходный FD. (Общий рецепт для этого заключается в следующем: воссоздать исходную таблицу, снова объединив декомпозиции, спроектировать, объединяющий упомянутые атрибуты, и применить ключ к этой проекции. Достижение этого не совсем будет тривиальным для таких случаев, как эти упражнения курса.)

Решение о том, находятся ли R1 / R2 в xNF, теперь должно быть сделано с учетом только тех из оригинальных FD, которые все еще выразимы (a-> BC).

Полагаю, вам следует прийти к выводу, что R1 находится в 3 / BC NF, а R2 все еще нет.

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

...