Поставщики

ID поставщика	Наименование поставщика	Факс
1	Циклон	3-68-01
2	Трио	4-69-02
3	Аист	5-70-03
4	Сириус	7-81-04

Таблица 14.10

Поставщики изделий

ID изделия	ID поставщика
1	1
1	2
2	3
2	2
3	1
4	4

Таким образом, изначально представленные в табл. 14.5 данные на этом этапе формирования модели предметной области описываются табл. 14.7, 14.9 и 14.10. Среди них табл. 14.7, однако, не отвечает требованиям 3НФ, в которой каждый атрибут таблицы определяется либо ее суперключом, либо ее кандидатным ключом. Действительно, существующая в ней функциональная зависимость "ID изделия – Вид" не позволяет по значению ID изделия определить его вид. В частности, для ID изделия со значениями 1 и 2 в табл. 14.7. указывается один и тот же вид – "Диод".

Решение проблемы в том, чтобы ввести таблицу видов изделий (табл. 14.11), а табл. 14.7 записать с учетом определенных в табл. 14.11 видом, т. е. в виде табл. 14.12.

Таблица 14.11

Виды изделий

ID вида изделия	Вид
1	Диод
2	Микросхема

Таблица 14.12

Изделия

ID изделия	ID вида изделия	Тип
1	1	АД110
2	1	ГД508
3	2	К122
4	2	К245

В этом случае функциональная зависимость "ID изделия – Вид" перестает существовать; взамен ее появляется зависимость "ID вида изделия – Вид".

Аналогичная ситуация, в принципе, может возникнуть и в табл. 14.9, когда в ней окажутся поставщики с одинаковыми наименованиями. Однако это более терпимый случай нарушения 3НФ, с которым в большинстве случаев можно примириться.

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

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

14.4. Ссылочная целостность данных

При многотабличном представлении данных связь между таблицами нередко выполняется по специально вводимым полям. В нашем примере – это идентификаторы рассматриваемых сущностей – поставщиков, изделий и их видов. Так, табл. 14.11 и 14.12 очевидным образом связываются полем "ID вида изделия".

Такая структура данных создает проблему обеспечения ссылочной целостности данных, для иллюстрации которой рассмотрим три ситуации.

Попробуем, во-первых, удалить из табл. 14.11 первую запись. Если эта операции разрешена, то в табл. 14.12 окажутся две записи, ссылающиеся на неописанный в базе данных вид изделия "Диод". Избежать подобного можно двумя способами:

1. запретить удаление записи в табл. 14.11, если на нее имеется ссылка в табл. 14.12;

2. удалять вместе с записью в табл. 14.11 все записи табл. 14.12, ссылающиеся на удаляемую запись.

Попытаемся, во-вторых, изменить значение поля "ID вида изделия" для вида "Диод". Очевидно, что для корректного осуществления этой процедуры, необходимо соответствующим образом изменить значения этого поля в записях 1 и 2 табл. 14.12, ссылающихся на корректируемую запись табл. 14.11. (Уникальность нового "ID вида изделия" также должна быть гарантирована.)

И, в-третьих, добавим в табл. 14.12 новую запись. Чтобы эта операции не привела к нарушению ссылочной целостности, необходимо в поле "ID вида изделия" проставить существующее в табл. 14.11 значение.

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