− аномалия обновления: если изменяется какой-либо атрибут, то его приходится изменять во многих записях. Например, если изменится нормативный документ для некоторого типа объекта, то изменение потребуется вносить столько раз, сколько имеется проектов с данным типом объекта. Кроме того, при этом в некоторый момент времени одному типу объекта будут соответствовать разные нормативные документы.

Эти недостатки будут устранены при приведении БД к третьей нормальной форме.

1.5Третья нормальная форма

Основная причина недостатков БД во второй нормальной форме – наличие

транзитивных зависимостей.

Пусть атрибут B находится в функциональной зависимости от атрибута или группы атрибутов A (A → B), а атрибут С – в функциональной зависимости от атрибута B (B → C), причем A - ключ, B и C – неключевые атрибуты. Такая зависимость (A → B → C) называется транзитивной.

Таблица находится в третьей нормальной форме (3НФ), если она находится в 2НФ (а значит, и в 1НФ) и не содержит транзитивных зависимостей.

Примечание – Если таблица содержит только один неключевой атрибут или вообще не содержит неключевых атрибутов, то она всегда находится в 3НФ, так как в ней не может быть транзитивных зависимостей.

Чтобы привести к 3НФ таблицу, содержащую транзитивную зависимость A → B → C, требуется выделить атрибуты B и C в отдельную таблицу, где B становится ключевым атрибутом. Другими словами, для приведения к 3НФ таблица разбивается на две: в одну из них помещаются все атрибуты, кроме атрибута C, в другую - атрибуты B и C.

Примечание – Если таблица содержит “длинную” транзитивную зависимость, например, A → B → C → D → E (где A – ключ, B, C, D, E – неключевые атрибуты), то сначала в отдельную таблицу выделяются атрибуты D и E, затем в другую отдельную таблицу – атрибуты C и D, затем – B и C.

Приведем к 3НФ таблицы, составляющие БД проектно-строительной организации (таблицы 1.3 – 1.5). Таблицы 1.3 и 1.4 не содержат транзитивных зависимостей, т.е. они уже находятся в 3НФ. В таблице 1.5 имеется транзитивная зависимость Номер проекта → Тип объекта → Нормативный документ.

Именно в этом состоит причина недостатков, указанных в подразделе 1.4. Чтобы привести ее к 3НФ, разделим ее на две таблицы: таблицу 1.6, содержащую все атрибуты, кроме атрибута Нормативный документ (присвоим ей имя, например, “Список проектов”), и таблицу 1.7, содержащую атрибуты Тип объекта и Нормативный документ (назовем ее, например, “Нормативные докумен-

ты”).

13

Таблица 1.6 – Список проектов

Таблица 1.7 – Нормативные документы

Таблицы 1.6 и 1.7 находятся в 3НФ. Легко убедиться, что они не имеют недостатков, указанных в подразделах 1.3 и 1.4.

Таким образом, вся БД проектно-строительной организации приведена к 3НФ. Эта БД состоит из четырех таблиц: таблицы 1.3, 1.4, 1.6 и 1.7. Сопоставив эти таблицы с исходными данными, приведенными в подразделе 1.2, легко убедиться, что в процессе нормализации никакие данные не потеряны.

Таблицы 1.3, 1.4, 1.6 и 1.7 также не имеют недостатков, требующих приведения к нормальным формам более высоких порядков (они будут рассмотрены в подразделах 1.6 – 1.8). Таким образом, проектирование БД проектностроительной организации завершено.

1.6Нормальная форма Бойса-Кодда

Как отмечено выше, большинство аномалий, затрудняющих хранение и обработку БД, устраняются в процессе приведения к 3НФ. Однако в некоторых случаях таблицы, приведенные к 3НФ, тем не менее, обладают недостатками, аналогичными рассмотренным в подразделах 1.3, 1.4. В этом случае требуется приведение таблиц к нормальным формам более высоких порядков.

Приведем некоторые определения, необходимые для рассмотрения нормальной формы Бойса-Кодда.

Атрибут (или группа атрибутов) называется детерминантом, если от него функционально зависит какой-либо другой атрибут. Другими словами, если имеется функциональная зависимость A → B, то A – детерминант.

Атрибут (или группа атрибутов) называется возможным ключом, если он может использоваться в качестве ключа.

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

Таблица, не находящаяся в НФБК, может иметь ряд аномалий.

Пример – Разрабатывается БД о поставках деталей внутри предприятия. На предприятии имеются цехи-поставщики (выпускающие детали, используемые другими цехами) и цехи-потребители (использующие детали, выпущенные

14

цехами-поставщиками, и выпуска выпускающие готовую продукцию). Известно следующее:

−каждый цех-поставщик выпускает (и поставляет цехам-потребителям) детали только одного вида;

−каждый цех-потребитель получает детали каждого вида только от одного цеха-поставщика (например, если цех-потребитель Ц22 получает гайки от цеха-поставщика Ц17, то он не получает гайки от каких-либо других цехов);

−цех-поставщик может поставлять детали (одного вида) нескольким це- хам-потребителям;

−один вид деталей может выпускаться несколькими цехамипоставщиками.

Фрагмент БД приведен в таблице 1.8.

Таблица 1.8 – БД о поставках деталей внутри предприятия

Здесь ни один из атрибутов в отдельности не является ключом, так как значение любого атрибута в БД может встречаться несколько раз. В качестве ключей могут использоваться комбинации атрибутов (Цех-потребитель, Де-

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

разом, комбинации атрибутов (Цех-потребитель, Деталь) и (Цех-потребитель,

Цех-поставщик) – возможные ключи.

В данном примере имеются следующие функциональные зависимости: (Цех-потребитель, Деталь) → Цех-поставщик, (Цех-потребитель, Цехпоставщик) → Деталь, Цех-поставщик → Деталь. Таким образом, атрибут

Цех-поставщик является детерминантом, но не является возможным ключом. Будем использовать в качестве ключа комбинацию атрибутов (Цех-

потребитель, Деталь). Тогда таблица 1.8 находится в 2НФ (так как нет функциональных зависимостей от частей ключа) и в 3НФ (так как отсутствуют транзитивные зависимости вида A → B → C). Однако таблица не находится в НФБК, так как имеется детерминант (Цех-поставщик), не являющийся возможным ключом. Это является причиной следующих недостатков:

15

−избыточность данных: некоторые данные хранятся многократно. Например, данные о том, какая деталь выпускается цехом-поставщиком, хранятся несколько раз (столько, сколько имеется цехов-потребителей, получающих у цеха-поставщика данную деталь). Так, информация о том, что цех Ц10 выпускает планки, приведена в таблице 1.8 дважды;

−аномалия добавления (ввода): невозможность ввода данных о цехепоставщике, пока он не начал выпуск какой-либо детали;

−аномалия удаления: например, если цех Ц22 прекратит получать гайки от цеха Ц17, то информация о цехе Ц17 будет потеряна;

−аномалия обновления: если цех-поставщик перейдет на выпуск другой детали, то потребуется вносить изменения в несколько записей. Кроме того, при этом в некоторый момент времени одному цеху-поставщику будут соответствовать разные детали.

Чтобы привести таблицу к НФБК, требуется выделить детерминант, не являющийся возможным ключом, и атрибут, находящийся в функциональной зависимости от него, в отдельную таблицу. Другими словами, если в таблице имеется функциональная зависимость A → B, где A не является возможным ключом, то для приведения к НФБК таблица разбивается на две: в одну из них помещаются все атрибуты, кроме атрибута B, в другую - атрибуты A и B (атрибут A в ней становится ключом).

В рассматриваемом примере таблица 1.8 не находится в НФБК из-за функциональной зависимости Цех-поставщик → Деталь. Значит, требуется выделить их в отдельную таблицу (таблица 1.9). Атрибут Цех-поставщик в этой таблице является ключом. Еще одна таблица будет содержать все атрибуты, кроме атрибута Деталь (таблица 1.10). Таким образом, БД о внутренних поставках деталей, приведенная к НФБК, будет состоять из двух таблиц: 1.9

и1.10.

Таблица 1.9 – Цехи-поставщики

Таблица 1.10 – Поставки

16