Главная » SQL, Базы данных » ОРТОГОНАЛЬНОЕ ПРОЕКТИРОВАНИЕ (НЕБОЛЬШОЕ ОТСТУПЛЕНИЕ ОТ ТЕМЫ)

0

В этом разделе, следуя описанию, приведенному в [13.12], кратко рассматривается еще один принцип проектирования баз данных, который напрямую не связан с принципом дальнейшей нормализации, но очень похож на него тем, что также является научно обоснованным. Он называется принципом  ортогонального  проектирования (principle of orthogonal design). Обратимся к рис. 13.7, на котором представлен, безусловно, плохой, но вполне допустимый проект представления данных о поставщиках. Здесь переменная отношения SA соответствует поставщикам, которые находятся в Париже, а переменная

отношения SB — поставщикам, которые либо не находятся в Париже, либо имеют статус выше 3 0 (т.е. предикаты этих переменных отношения имеют именно такой смысл). Как следует из данного рисунка, подобный проект характеризуется  некоторой избыточностью, точнее говоря, в нем дважды представлен кортеж для поставщика с номером S3 (по одному в каждой переменной отношения), а такая избыточность также приводит к аномалиям обновления.

Рис. 13.7. Плохой, но вполне допустимый проект представления данных о поставщиках Отметим, что данный кортеж с данными о поставщике S3 должен находиться в обеих

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

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

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

Из этого следуют приведенные ниже выводы.

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

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

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

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

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

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

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

Рис. 13.8. Еще один неудачный, но вполне допустимый вариант проекта отношений с данными о поставщиках

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

Из этого следуют приведенные ниже выводы.

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

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

■     ни одна из проекций в процессе такого восстановления не бывает избыточной (строго говоря, это второе условие не является необходимым для того, чтобы декомпозиция осуществлялась без потерь, но обычно оно желательно, как по казано в главе 12).

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

Дополнительные замечания

Ниже приведены дополнительные замечания, касающиеся принципа ортогонального проектирования.

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

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

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

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

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

ACTIVITIES_2001{ ENTRY#,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2 002{ ENTRY#,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2 003{ ENTRY*,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2004{ ENTRY*,DESCRIPTION,   AMOUNT, NEW_BAL }

ACTIVITIES_2005{ ENTRY*, DESCRIPTION,   AMOUNT, NEW_BAL }

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

5.     Если А И В  ЯВЛЯЮТСЯ базовыми переменными отношения одного типа, то привер женность принципам ортогонального проектирования будет равносильна соблю дению приведенных ниже требований.

■     A UNION в. Всегда является объединением непересекающихся отношений.

■     A INTERSECT в. Всегда является пустым отношением.

■     A MINUS в. Всегда равно А.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии