12.6. Ортогональное проектирование (небольшое отступление от темы)

В этом разделе мы кратко рассмотрим другой принцип проектирования баз данных, который напрямую не связан с дальнейшей нормализацией, но очень похож на нее тем, что также является научным. Он называется принципом ортогонального проектиро­вания (principle of orthogonal design). Обратимся к рис. 12.7, на котором представлена безусловно плохая, но вполне допустимая структура представления данных о поставщи­ках. Здесь переменная-отношение SA соответствует поставщикам, которые находятся в Париже, а переменная-отношение SB соответствует поставщикам, которые либо не нахо­дятся в Париже, либо имеют статус выше 30 (т.е. предикаты этих переменных-отноше­ний имеют именно такой смысл). Как следует из рисунка, подобная структура характери­зуется некоторой избыточностью, точнее говоря, в ней дважды представлен кортеж для поставщика с номером 'S3' (по одному в каждой переменной-отношении).

Отметим, что данный кортеж должен находиться в обеих переменных-отношениях. Допустим обратное, т.е. что он находится в переменной-отношении SB, но отсутствует в переменной-отношении SA. Применив допущение замкнутости мира к переменной-отношению SA, можно сделать вывод, что поставщик с номером ' S3' не находится в Па­риже. Однако данные в переменной-отношении SB свидетельствуют об обратном, т.е. о том, что он находится в Париже. Иначе говоря, мы получили противоречие и, следова­тельно, база данных находится в противоречивом состоянии.

SB

???§

Рис. 12.7. Плохая, но вполне допустимая структура представления данных о поставщиках

Недостаток показанной на рис. 12.7 структуры данных очевиден: один и тот же кор­теж может дублироваться в каждой из двух переменных-отношений. Иначе говоря, две переменные-отношения имеют перекрывающееся смысловое значение и это приводит к тому, что один и тот же кортеж может удовлетворять предикатам обеих переменных-отношений. Поэтому достаточно очевидным является следующее правило.

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

Здесь можно сделать следующие дополнительные замечания.

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

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

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

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

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

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

SX

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

s#	SNAME	STATUS	SY	s#	SNAME	CITY
SI	Smith	20		SI	Smith	London
S2	Jones	10		S2	Jones	Paris
S3	Blake	30		S3	Blake	Paris
S4	Clarck	20		S4	Clarck	London
S5	Adams	30		S5	Adams	Athens

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, NEW~BAL }

ACTIVITIES~1999 { ENTRY*, DESCRIPTION, AMOUNT, NEW~BAL }

ACTIVITIES~2000 { ENTRY*, DESCRIPTION, AMOUNT, NEW~BAL }

ACTIVITIES~2001 { ENTRY*, DESCRIPTION, AMOUNT, NEW~BAL }

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

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

A UNION В

A INTERSECT В

A MINUS В

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