Введение в системы БД (542480), страница 121
Текст из файла (страница 121)
12.7, на котором представлена безусловно плохая, но вполне допустимая структура представления данных о поставщиках. Здесь переменная-отношение ЯВ соответствует поставщикам, которые находятся в Париже, а переменная-отношение БВ соответствует поставщикам, которые либо не находятся в Париже, либо имеют статус выше 30 (т.е. предикаты этих переменных-отношений имеют именно такой смысл). Как следует из рисунка, подобная структура характеризуется некоторой избыточностью, точнее говоря, в ней дважды представлен кортеж для поставщика с номером 'ЯЗ' (по одному в каждой переменной-отношении).
Отметим, что данный кортеж должен находиться в обеих переменных-отношениях. Допустим обратное, т.е. что он находится в переменной-отношении ЯВ, но отсутствует в переменной-отношении БА. Применив допущение замкнутости мира к переменной- отношению Бй, можно сделать вывод, что поставщик с номером 'Б3' не находится в Париже, Однако данные в переменной-отношении БВ свидетельствуют об обратном, т.е. о том, что он находится в Париже. Иначе говоря, мы получили противоречие и, следовательно, база данных находится в противоречивом состоянии.
486 Часть 111 Проектирование базы данных Рис.!2.7, Плохая, но вполне допустимая структура представления данных о поставщиках Недостаток показанной на рис. 12.7 структуры данных очевиден: один и тот же кортеж может дублироваться в каждой из двух переменных-отношений. Иначе говоря, две переменные-отношения имеют перекрывающееся смысловое значение и это приводит к тому, что один и тот же кортеж может удовлетворять предикатам обеих переменных- отношений.
Поэтому достаточно очевидным является следуюшее правило. ° Принцип ортогонального проектирования (исходная версия). Никакие две переменные-отношения в базе данных не должны иметь перекрываюшихся смысловых значений. Здесь можно сделать следуюшие дополнительные замечания. 1. Как говорилось в главе 9, с точки зрения пользователя, всв переменные-отношения являются базовыми (за исключением тех представлений, которые определяются им для упрошения записи запросов).
Иначе говоря, этот принцип применим для проектирования всех "выражаемых", а не только "реальных" баз данных. Здесь нам вновь приходится иметь дело с принципом относительности баз данных. (Безусловно, аналогичные замечания применимы и к принципам нормализации.) 2. Обратите внимание, что две переменные-отношения могут иметь перекрываюшееся смысловое значение только в том случае, если они имеют одинаковые типы (т.е.
одинаковые заголовки). 3, Использование принципа ортогонального проектирования подразумевает, что вставка кортежа рассматривается как операция вставки кортежа в базу данны», а не в какую-то конкретную переменную-отношение, поскольку сушествует не более одной переменной-отношения, предикату которой этот кортеж удовлетворяет. Однако в настояшее время при вставке кортежа обычно требуется указывать имя той переменной-отношения й, в которую кортеж вставляется. Но это нисколько не противоречит предыдушему высказыванию, так как, по сути, имя В является всего Глава 12. Дальнейиазя нормализация: более высокие нормальные формы 487 лишь сокращением для соответствующего предиката (например, РК).
Действительно, команда выглядит так: 1МЯЕКТ кортеж С, где г далжно удовлетворять предикату РК. Более того, переменная-отношение К может быть представлением, определенным, например, с помощью выражения типа А ВК10К В. Как говорилось в главе 9, очень желательно, чтобы системе было известно, куда вставлять новый кортеж: только в переменную-отношение й, только в переменную-отношение В или одновременно в обе эти переменные-отношения. На самом деле замечания, аналогичные приведенным выше, относятся ко всем типам операций, а не только к операциям 1МЯЕКТ. Во всех этих случаях указываемые имена переменных-отношений в действительности являются лишь сокращениями для их предикатов.
Это зачвчаиие вряд ли .можно выразить более строго, если проста сказать, что семантика данных представлена именно првдикатачи переменных-отношений, а не их иченачи. Прежде чем завершить обсуждение принципа ортогонального проектирования, необходимо сделать одну важную поправку. На рис. 12.8 показан еше один пример очевидно плохой, но вполне допустимой структуры представления данных о поставщиках.
В этом случае две переменные-отношения сами по себе не имеют перекрывающегося смыслового значения, но их проекции по атрибутам (БЗ, ЯКАМЕ)— имеют (на самом деле смысловые значения этих проекций идентичны). В результате попытка вставки некоторого кортежа(например, ('Бб', 'Ьорвг')) в представление, определенное как объединение этих двух проекций, приведет к вставке кортежа ('Яб', '(орег', с) в переменную-отношение ЯХ и кортежа ('Яб', '1орег', с)— в переменную-отношение Я1 (где г и с — используемые по умолчанию значения). Ясно, что для устранения подобных проблем принцип ортогонального проектирования необходимо несколько расширить. Рис.
!2.8. Еще один неудачный, но вполне доп»стичый вариант представления данных о поставщиках ° Принцип ортогонального проектирования (окончательная версия). Пусть й и В являются двумя базовыми переменными-отношениями в некоторой базе данных. Тогда для переменных-отношений А и В не должно существовать декомпозиций без потерь на такие проекции А1, ..., Ая и В1, ..., Вд соответственно, что некоторая проекция АТ в множестве проекций А1, ..., Ая и некоторая проекция В1 в множестве проекций В1, ..., Вя будут обладать перекрывающимися смысловыми значениями.
488 Часть ЕЕЕ. Проектирование базы данных При этом необходимо сделать следующие дополнительные замечания. 1. Здесь термин "декомпозиция без потерь" означает в точности то, что он означает всегда, а именно — декомпозицию на множество таких проекций, которые обладают следующими свойствами; ° исходная переменная-отношение может быть восстановлена за счет обратной операции соединения проекций; ° ни одна из проекций не является избыточной в процессе восстановления. 2. Данная версия принципа ортогонального проектирования подразумевает прелыдушую версию, поскольку единственная декомпозиция без потерь, которая всегда существует для любой переменной-отношения К, является идентичной проекцией для К (т.е.
проекций по всем ее атрибутам). Замечания 1. Предположим, что нашу традиционную переменную-отношение Я с данными о поставщиках для улучшения структуры информации решено разделить на несколько фрагментов. Тогда в соответствии с принципом ортогонального проектирования необходимо обеспечить, чтобы полученные фрагменты не пересекались, в том смысле, что каждый кортеж с данными о некотором поставщике может появиться не более чем в одном из фрагментов. Назовем такое разбиение ортогональной декомпозицией. Замечание. Термин ортогонильность выбран, исходя из тех соображений, что данный принцип проектирования на самом деле декларирует полную взаимную независимость базовых переменных-отношений (т.е.
отсутствие перекрытия их смысловых значений). Безусловно, этот принцип отражает очевидные соображения здравого смысла, но позволяет выразить их в формальном виде (подобно принципам нормализации). 2. Общее назначение ортогонального проектирования заключается в сокрашении избыточности и, следовательно, в исключении аномалий обновления (вновь аналогия с принципами нормализации).
По сути, ортогональное проектирование дополняет нормализацию в том смысле, что, выражаясь нестрого, нормализация сокращает избыточность данных внутри переменных-отношений, тогда как ортогональное проектирование сокращает избыточность данных между переменными-отношениями. 3. Несмотря на то что принципы ортогональности очевидны с точки зрения здравого смысла, они часто игнорируются на практике (причем иногда их даже рекомендуется игнорировать). Например, приведенный ниже пример структуры данных весьма распространен в финансовых базах ланных. АСТ1Ч1Т1ЕЯ 1997 ( ЕМТКУ$, ОЕЯСК1РТ10М, АМООИТ, ИЕИ ВАЬ ) АСТ1Ч1Т1ЕЯ 1990 ( ЕМТК14, ОЕЯСК1РТ10И, АМООИТ, ИЕИ ВАБ ) АСТ1ЧТТ1ЕЯ 1999 ( БИТКАМ, ОЕЯСК1РТ10М, АМООИТ, МЕИ ВАЬ ) АСТ1Ч1Т1ЕЯ 2000 ( ВИТКАМ, ОЕЯСК1РТ10И, АМООИТ, ИЕИ ВАЬ ) АСТ1Ч1Т1ЕЯ 2001 ( ЕИТК19, ОЕЯСК1РТ10М, АМООИТ, ИЕИ ВАБ ) По сути, внесение смыслового значения в имена переменных-отношений или других объектов нарушает принцип информации, который гласит, что вся информация в базе данных должна быть явно представлена в виде значений данных и никак иначе.
Глава 12. Дальнейшая нормализация: более высокие нормальные формы 489 4. Если А и В являются базовыми отношениями одного типа, то следование прииципам ортогонального проектирования будет означать следующее. А 0И10И В А 1ИТЕИЯЕСТ В А И1808 В Всегда является непересекающимся объединением Всегда является пустым множеством Всегда равно А 12.7. Другие нормальные формы 1. Домеиио-ключевая нормальная форма (ДКНФ).
Эта форма была предложеиа Фейгииом [12.15]. В отличие от рассмотренных выше нормальных форм, оиа ие определяется в терминах функциональных зависимостей, многозначных зависимостей или зависимостей соединения. Вместо этого утверждается, что перемеииаяотношение И иахолится в ДКНФ тогда и только тогда, когда каждое наложенное иа иее ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных иа данную переменную-отношение И. ° Ограничение домена в том смысле, в котором оио здесь употребляется, — это ограничение, предписывающее использование для определенного атрибута зиачеиий только из некоторого заданного домена. (В главе 8 это ограничение упоминается как ограничение атрибута, а ие как ограничение домена.) ° Ограничение кчюча — это ограничение, утверждающее, что некоторый атрибут или комбинация атрибутов представляет собой потенциальный ключ.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
