лишь сокращением для соответствующего предиката (например, PR). Действительно, команда выглядит так: INSERT кортеж t, где t должно удовлетворять предикату PR. Более того, переменная-отношение R может быть представлением, определенным, например, с помощью выражения типа А UNION В. Как говорилось в главе 9, очень желательно, чтобы системе было известно, куда вставлять новый кортеж: только в переменную-отношение А, только в переменную-отношение В или одновременно в обе эти переменные-отношения.

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

Прежде чем завершить обсуждение принципа ортогонального проектирования, необходимо сделать одну важную поправку. На рис. 12.8 показан еще один пример очевидно плохой, но вполне допустимой структуры представления данных о поставщиках. В этом случае две переменные-отношения сами по себе не имеют перекрывающегося смыслового значения, но их проекции по атрибутам {S#, SNAME} - имеют (на самом деле смысловые значения этих проекций идентичны). В результате попытка вставки некоторого кортежа (например, (S6, Lopez)) в представление, определенное как объединение этих двух проекций, приведет к вставке кортежа (S6, Lopez, t) в переменную-отношение SX и кортежа (S6, Lopez, с) - в переменную-отношение SY (где t и с - используемые по умолчанию значения). Ясно, что для устранения подобных проблем принцип ортогонального проектирования необходимо несколько расширить.

Puc. 12.8. Еще один неудачный, но вполне допустимый вариант представления данных о поставщиках

Принцип ортогонального проектирования {окончательная версия). Пусть А и В являются двумя базовыми переменными-отношениями в некоторой базе данных. Тогда для переменных-отношений А и В не должно существовать декомпозиций без потерь на такие проекции А1, Am и В1, Вт соответственно, что некоторая проекция Ai в множестве проекций А1, ..., Am и некоторая проекция Bj в множестве проекций В1, ..., Вт будут обладать перекрывающимися смысловыми значениями.

При этом необходимо сделать следующие дополнительные замечания.

1. Здесь термин декомпозиция без потерь означает в точности то, что он означает всегда, а именно - декомпозицию на множество таких проекций, которые обладают следующими свойствами:

исходная переменная-отнощение может быть восстановлена за счет обратной операции соединения проекций;

ни одна из проекций не является избыточной в процессе восстановления.

2. Данная версия принципа ортогонапьного проектирования подразумевает предыдущую версию, поскольку единственная декомпозиция без потерь, которая всегда существует для любой переменной-отнощения R, является идентичной проекцией для R (т.е. проекций по всем ее атрибутам).

Замечания

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

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

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

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

ACTIVITIES 1997 { ENTRY*, DESCRIPTION, AMOUNT, NEW BAL }

ACTIVITIES~1998 { ENTRY*, DESCRIPTION, AMOUNT, NEWBAL }

ACTIVITIES~1999 { ENTRY*, DESCRIPTION, AMOUNT, NEWBAL }

ACTIVITIES~2000 { ENTRY*, DESCRIPTION, AMOUNT, NEWBAL }

ACTIVITIESJOOl { ENTRY*, DESCRIPTION, AMOUNT, NEWJAL }

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

4. Если А и В являются базовыми отношениями одного типа, то следование принципам ортогонального проектирования будет означать следующее.

А UNION В Всегда является непересекающимся объединением

А INTERSECT В Всегда является пустым множеством А MINUS В Всегда равно А

12.7. Другие нормальные формы

Прежде чем завершить обсуждение вопросов нормализации, следует напомнить сделанное в главе 11 замечание о том, что, помимо уже описанных, существуют и другие нормальные формы. Дело в том, что теория нормализации и связанные с ней вопросы (в настоящее время эту область обычно называют теорией зависимостей) развились в значительную самостоятельную область знаний с обширной литературой. Исследования в данной области продолжаются и в настоящее время, причем довольно успешно. Однако сколько-нибудь углубленный обзор этих исследований выходит за рамки данной главы. Заинтересованный читатель найдет достаточно полный обзор полученных в этой области результатов в [12.17] (по состоянию на середину 1980-х годов). Ниже мы лишь кратко упомянем о некоторых из них.

1. Доменно-ключевая нормальная форма (ДКНФ). Эта форма была предложена Фейгином [12.15]. В отличие от рассмотренных выше нормальных форм, она не определяется в терминах функциональных зависимостей, многозначных зависимостей или зависимостей соединения. Вместо этого утверждается, что переменная-отношение R находится в ДКНФ тогда и только тогда, когда каждое наложенное на нее ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную-отношение R.

Ограничение домена в том смысле, в котором оно здесь употребляется, - это ограничение, предписывающее использование для определенного атрибута значений только из некоторого заданного домена. (В главе 8 это ограничение упоминается как ограничение атрибута, а не как ограничение домена.)

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

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

Фейгин в [12.15] показал, что любая переменная-отношение, находящаяся в ДКНФ, находится в 5НФ (а значит, в 4НФ и т.д.), а также в форме типа (3,3)НФ (подробнее, о ней рассказывается ниже). Однако не всегда можно привести переменную-! отношение к ДКНФ или получить ответ на вопрос Когда такое приведение может быть выполнено? .