Базы данных

Цель преобразования всех функциональных зависимостей


Цель преобразования всех функциональных зависимостей в ключевые зависимости в этой схеме не достигнута. Следующая таблица удовлетворяет двум ограничениям ключа, так как каждая строка имеет уникальное значение для каждого из ключей.

supplierld supplierName street zipcode

101101 Acme Video 312 South St. 44444

101101 Acme Video 45 Park Ave. 01455

101101 Not Acme Video 12370 12th St. 32306

В то же время зависимость supplierld -» supplierName не выполняется. Ограничений ключей недостаточно для обеспечения выполнения функциональных зависимостей.

Нарушение требований BCNF устраняется обычным образом: таблица расщепляется с целью устранения зависимости. В результате получаются следующие BCNF схемы.

Supplier: (supplierld, street, zipcode)

SupplierName: (supplierld, supplierName)

В предыдущем примере зависимость между supplierld и supplierName не обеспечивалась новой схемой. Следует определить supplierName в качестве вторичного ключа схемы SupplierName, чтобы гарантировать выполнение всех функциональных зависимостей.

К сожалению, иногда приведение схемы к BCNF не может быть выполнено без удаления функциональных зависимостей. В качестве примера рассмотрим схему резервирования, предназначенную для резервирования клиентами видеокассет на определенные дни:

FutureReservation: (accountld, movield, date)

Функциональные зависимости этой схемы требуют, чтобы один человек не мог зарезервировать один и тот же фильм несколько раз и чтобы на определенный день резервировалось не более одного фильма1.

(1) {accountld, videold) —» date

(2) date —» videold

Из функциональных зависимостей можно определить, что схема имеет два ключа: {accountld, videold} и {accountld, date}. Функциональные зависимости допускают многократное резервирование видеокассеты в разные дни, а также резервирование нескольких видеокассет однилГ клиентом, т.е. нижеприведенные строки не являются функциональными зависимостями.

(3) not (accountld —» videold)

(4) not (videold —» date)

Функциональная зависимость 2 нарушает требования BCNF, но для нее не существует удовлетворительной декомпозиции на BCNF-отношения. Декомпозиция, устраняющая это нарушение, приводит к следующим двум отношениям.

FR1: (accountld, date)

FR2: (date, videold)

1 Этот пример достаточно нереалистичен, но он позволяет увидеть потенциальные проблемы BCNF.

Глава 5. Улучшение качества проектирования баз данных 117

В результате такой декомпозиции функциональная зависимость 1 не сохраняется, т.е. возможно существование кортежей (a, dl) и (a, d2) в схеме FR1 и кортежей (dl, v) и (d2, v) в схеме FR2, при этом dl  d2.

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

Комментарии закрыты