Модели и проектирование баз данных

Универсальное отношени


е и аномалии обновления. Создать логический макет БД, – значит определить набор базовых отношений и правил целостности данных.

Зачем нужен какой-то набор отношений? Почему бы не хранить все данные в одном отношении?

Для того чтобы ответить на эти вопросы, вернемся к нашей «учебной» БД ПОСТАВЩИК–ДЕТАЛЬ– ИЗДЕЛИЕ (см. п. 2.3.2). Она состоит из четырех базовых отношений. Чтобы поддерживать в ней порядок, необходимо следить за  соблюдением требования внешнего ключа. Вставляя кортеж в SPJ, мы должны проверить:

·  есть ли добавляемое значение S#

среди значений этого атрибута в текущем значении отношения S;

·  есть ли добавляемое значение P#

среди значений этого атрибута в текущем значении отношения P;

·  есть ли добавляемое значение J#

среди значений этого атрибута в текущем значении отношения J;

·  уникален ли новый набор значений {S#, P#, J#, Dt} в отношении SPJ.

При удалении кортежа из какого-либо родительского отношения возникнет вопрос: что делать с потомками удаляемого кортежа в отношении SPJ?

Если же мы создадим единственное (универсальное) отношение USPJ со схемой {S#, Sn, St, Sci, P#, PN, Co, We, Pci, J#, Jn, Jci, Qt}, то никаких проблем ссылочной целостности нет, потому что нет ссылок. Все связи между данными хранятся в одном месте, выражаются как связи между атрибутами одного отношения, а не как связи между отношениями. При добавлении кортежа достаточно проверить уникальность значения подмножества атрибутов {S#, P#, J#, Dt}. При удалении кортежа проблемы «отцов и детей» не возникает. Да и места на диске, кажется, потребуется меньше. В универсальном отношении нужно хранить значения всего тринадцати атрибутов, а в структуре, содержащей четыре отношения, – значения шестнадцати.

На первый взгляд – хорошо. На самом деле – очень плохо. Рассмотрим проблемы, возникающие при хранении данных в универсальном отношении.



Избыточность. Будем считать, что в нашей ПО действует, в дополнение к перечисленным в п. 2.3.2, следующее правило:

·  статус поставщика однозначно определяется городом его размещения.


Для иллюстрации выпишем фрагмент возможного значения нашего универсального отношения:

S#

Sn

St

Sci

P#

Pn

Co

We

Pci

J#

Qt

...

S1

Иван

50

Яя

P3

шайба

Ж

20

Ош

J1

1000

...

S1

Иван

50

Яя

P1

гайка

К

10

Яя

J1

1000

...

S1

Иван

50

Яя

P8

болт

Ч

30

Яя

J1

500

...

S2

Петр

100

Ош

P3

шайба

Ж

20

Яя

J2

1000

...

S3

Джон

50

Яя

P2

винт

С

40

Ош

J2

2000

...

S3

Джон

50

Яя

P1

гайка

К

10

Ош

J2

1000

...

S8

Боб

50

Томск

P8

болт

Ч

30

Яя

J2

500

...

Очевидно, группы вида {S1, Иван, 50, Яя} встретятся столько раз, сколько поставок этот поставщик выполнил. Встреченная в первый раз такая группа сообщает нам сведения о конкретном поставщике. Встреченная вторично, она не содержит новой информации.

         В универсальном отношении возможно неконтролируемое дублирование данных.

Аномалия вставки типа а).

Универсальное отношение не только нерационально использует пространство внешней памяти. Эта структура еще заставляет нас фиксировать один и тот же факт многократно. Поэтому вполне возможно появление кортежей {‘S1’, ‘Иван’, 100, ‘Яя’, ...}, {‘S1’, ‘Петр’, 50, ‘Ош’, ...}. Каковы имя, статус и город размещения поставщика S1? Эта информация утеряна. Контроль подобных ошибок невозможно возложить на систему.

         При добавлении новых кортежей в универсальное отношение возможен ввод противоречивых данных.

Аномалия вставки типа б).

В универсальное отношение невозможно вставить данные, например, о некотором поставщике, который пока еще не выполнил ни одной поставки. В самом деле, единственным возможным ключом этого отношения является подмножество атрибутов {S#, P#, J#, Dt}. Если новый поставщик еще не выполнил ни одной поставки, то значение подмножества {P#, J#, Dt} в соответствующем кортеже не определено.


Кортеж не имеет идентификатора. Либо мы не можем его вставить, либо должны нарушить требование целостности сущности.

         В универсальное отношение невозможно добавить кортеж, содержащий сведения о части объектов ПО.

Аномалия удаления. Аналогичное ограничение существует и на операцию удаления.  Пусть нам нужно удалить сведения о поставке детали P3

поставщиком S2. Она зарегистрирована ошибочно. Удалить сведения о поставке можно либо удалив весь кортеж, содержащий эти сведения, либо заменив в нем значения атрибутов, характеризующих поставку,  NULL-значениями. В последнем случае будет нарушено требование целостности сущности. Кортеж отношения можно удалить только полностью. Однако запись о поставке детали P3 поставщиком S2 – единственный кортеж в нашей БД, содержащий сведения о поставщике S2. Удалив его, мы утратим эти сведения.

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

Аномалия обновления значений. Пусть мы решили поднять статус поставщиков из Яи до 100. При этом нам придется отыскать все кортежи со значением Sci = ‘Яя’

и изменить в них значение St. Если при обновлении хотя бы  одного кортежа будет допущена ошибка, то информация будет утеряна.

         При обновлении значений атрибутов универсального отношения существует возможность утери информации.

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

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


Содержание раздела