Введение в системы БД (542480), страница 268
Текст из файла (страница 268)
Отсюда следует, что смешивание указателей и отношений представляет ЗНАЧИТЕЛЬНОЕ отклонение от реля»ионной моде»и, вводя совершенно новый вид переменной. Как отмечалось в предыдушем разделе, мы бы могли доказать, что это серьезное нарушение концептуальной целостности реляционной модели. В [24.21[ и [25.11[ можно найти дополнительные аргументы в поддержку этой позиции. А в [25.8)-[25.10[ и [25.13] обсуждается важное связанное понятие суигествениасти (конструкций данных в модели данных).
Из приведенного выше аргумента следует, что большинство (а может быть, и все) современных объектно-реляционных продуктов и даже те, в которых нет первой грубейшей ошибки, все же смешивают указатели и отношения, как это ранее объяснялось. Когда Колд впервые определил реляционную молель„он умышленно исключил указатели. Вот цитата из его работы [5.2].
"С уверенностью можно считать, чта все группы пальзаватечей и, в частности, конечные пользователи, понимают действие сравнения з»ачеиий, иа атнаситечьно немногие понимают счажнасть использовиния указателей. Рек»вивана» .»одечь асновываетси на этом фундамента»ином принципе... Обработка указатачей в большей опепвни подвержена ошибкам, чем выполнение сравнения значений, долге если пользователям понятны все тонкости рабаты суказапштями.
" Обработка указателей часто требует их кэширования, а это, как известно, процесс, в котором довольно легко допустить ошибку. Как уже отмечалось в ~лаве 24, именно этот аспект объектных систем дает повод для критики, которая в некоторых случаях формулируется в выражениях, прямо утверждаюших, что "такие системы выглядят, как избитый СОВАЯ'т'1.". Как возникла вторая грубейшая ошибка В литературе трудно найти действительное объяснение второй грубейшей ошибки (имеются всякие технические объяснения, но есть основания полагать, что это вовсе не технические, а политические объяснения).
Конечно, учитывая тот факт, что все объектные системы и языки включают указатели [в виде идентификаторов объектов), можно считать, что идея смешивания указателей и отношений почти наверняка возникла от желания сделать реляционные системы более "объектно-подобными", но такое "объяснение" просто передвигает проблему на другой уровень. Мы уже разъясняли, и. на наш взгляд, более чем достаточно, что объектные системы предоставляют пользователям указатели именно потому, что в них модель недостаточно отличается от реализации.
Поэтому мы можем только предположить, что главная причина широкого распространения идеи смешивания указателей и отношений, в первую очередь, состоит в том, что слишком мало пользователей понимают, почему указатели были исключены из отношений. Как говорил Сантаяна, те, «та ие помнят прошяога, обречены повторить ега. Мы совершенно согласны с точкой зрения Мориса Вилкеса, который писал следуюшее [25.35[. 1О1г Часть )Х Объектные и объектно-реляционные базы данньп "<1<не хотелось бы рассчатривать множество относящихся к компьютерным наукам предметов непреиенно в историческо.и конп<ексте...
Студентач необходимо попинать, как возникла настоящая сип<уация, что было опробовано, что работа<о, а что нет и какой воз ножен прогресс за счет усовершенствования аппаратного обеспечения. Отсутствие исторического аспекта в их обучении приводит к тому, что студенты пытаюп<ся реи<ить калсдую проблему, исходя из начазы<ых условий. Они способны предложить реи<ения, которые можно было бы считать подходящими в прои<лом. Виесто того чтобы опираться на своих преди<ественников, они пытаются идти в одиночку." 25.4.
Вопросы реализации Одним из важных следствий надлежащей поддержки типов данных является то, что сторонние изготовители, а также сами изготовители СУБД могут встраивать и продавать отдельно пакеты "типов данных", которые могут эффективно включаться в СУБД. Примерами таких пакетов могут служить пакеты для поддержки сложной обработки текстов, пакеты для обработки финансовых хронологических рядов данных, анализа геокосмических (картографических) данных и т.л. Такие пакеты называются по-разному: "да<а Ыадез" ("пластинь< данных") в СУБД 1п<опп!х, "дага сап<!дяез" ("кассеть< данных") в СУБД Огас1е, "ге1абопа1 ех<еп<1егз" ("реляпионные расширители") в СУБД РВ2 корпорации !ВМ< и т.д, Мы же здесь будем использовать термин пакеты типов. Однако добавление в систему нового пакета типов — это нетривиальная задача, и возможность такого добавления оказывает сушественное влияние и иа проектирование, и на структуру самой СУБД.
Чтобы разобраться, почему так происходит, рассмотрим, что случится, если, например, некоторые запросы включают ссылки на данные некоторого типа, определенного пользователем, или вызовы некоторых операторов, определенных пользователем (или то и другое). ° Во-первых, транслятор языка запросов должен уметь выполнять грамматический разбор и проверку запрашиваемого типа, поэтому он должен кое-что знать о типах и операторах, определяемых пользователем.
° Во-вторых, оптимизатор должен уметь решать соответствующие запросные схемы лля таких запросов, поэтому ему также должны быть известны определенные свойства этих определяемых пользователем типов и операторов. В частности, ему должно быть известно, как физически хранятся соответствуюшие данные (см. следующий абзап). ° В-третьих, компонент, который контролирует физическое хранение данных, должен поддерживать новые структуры хранения 1О-деревья, К-деревья и т.д.), уже упоминавшиеся в разделе 25.1. Ему может также потребоваться поддержка возможности вводить новые структуры хранения и собственные методы доступа, предоставляемой достаточно подготовленным пользователям (см.
!25.21], [25.33]). Все это вместе приводит к тому, что фактически система должна быть открытой или расширяемой, причем на нескольких уровнях. Далее мы рассмотрим каждый из этих уровней. По нашечу.чненню, совершенно несоответствующий л<ермин. 1О1З Глава 25. Объектно-реляционные базы данных Анализ запросов и проверка типа В обычных системах, где все допустимые операторы и типы встроены, информация относительно них может быть (обычно так и есть в действительности) "зашита" в компиляторе языка запросов.
В системе, где пользователи могут определять собственные типы и операторы, наоборот, такой жесткий подход, очевидно, не годится. Поэтому в них необходимо реализовать следующее. 1. Информация относительно типов и операторов, определяемых пользователем, а также, возможно, и относительно встроенных типов и операторов хранится в системном каталоге. Поэтому такой каталог должен быть перепроектирован или по крайней мере расширен. Очевидно, что при установке нового пакета типов потребуются многочисленные изменения в каталоге.
(В терминах языка Тп1опа! О такое обновление каталога может быть выполнено неявно, как часть процесса выполнения соответствующих операторов определения — ТУРЕ и ОРЕРлТОЕ.) 2. Сам компилятор должен быть переписан, чтобы иметь доступ к каталогу с целью получения необходимых данных о типах и операторах. Зги данные будут использоваться компилятором для проверки типа во время компиляции, как описано в главах 5, 8 и 19.
Оптимизация Хотя проблема оптимизации включает множество вопросов, мы можем затронуть ее здесь лишь в самых общих чертах. Перечислим некоторые из этих вопросов. ° Преобразование выражения ("переписывание запроса"). Как указывалось в главе 17, обычный оптимизатор переписывает запросы, используя определенные законы преобразования. Исторически так сложилось, что все эти законы "зашиты" в оптимизатор, поскольку все типы и операторы встроены.
В объектно-реляционной системе, напротив, соответствующие правила (по крайней мере для того, чтобы использовать типы и операторы, определяемые пользователем) должны храниться в каталоге. Поэтому требуется дополнительное расширение каталога, а также переработка оптимизатора. Приведем несколько конкретных примеров. а) Пусть имеется выражение НОТ (ОТУ > 500). Хороший обычный оптимизатор преобразует его в выражение ЯТУ < 500, поскольку в этом виде индекс ЯТУ можно использовать, а в первоначальном — нет.
По аналогичным причинам новому оптимизатору необходимо знать, когда один определенный пользователем оператор является отрицанием другого. б) Хорошему обычному оптимизатору известно, что, например, выражения ЦТУ > 500 и 500 < ОТУ логически эквивалентны. Поэтому для нового оптимизатора также требуется информация, когда два определенных пользователем оператора являются противоположными в этом смысле.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
