Введение в системы БД (542480), страница 269
Текст из файла (страница 269)
в) Хорошему обычному оптимизатору известно, что, например, операторы "+" и "-" нейтрализуют друг друга (т.е. являются обратными). Например, выражение ОТУ + 500 — 500 сокращается просто до ОТУ. Поэтому лля нового оптимизатора также требуется информация, когда два определенных пользователем оператора являются обратными в этом смысле. 1014 Часть гз. Объектные и объектно-реляционные базы данньп ° Селективнасть. Булево выражение, такое как 0ТУ > 500, оптимизаторы обычно приблизительно оценивают на селективность, т.е.
определяют процент кортежей, для которых оно будет иметь значение ггие. Для обычных оптимизаторов информация о селективности, опять же, может быть "зашита" в оптимизатор. Для типов и операторов, определяемых пользователем, необходимо обеспечить способ перелачи информации оптимизатору с помощью вызова некоторого определяемого пользователем кода, позволяющего оценить селективность выражения. ° Стоимость формулы.
Оптимизатору необходимо знать, какова стоимость выполнения данного оператора, определяемого пользователем. Например, пусть задано выражение р ййО а, где р, скажем, — вызов оператора ййЕй, область определения которого представляет какой-то сложный многоугольник, а д — операция простого сравнения, такая как ОТУ > 500. По-видимому, предпочтительнее была бы такая система, которая вначале выполняет операцию а.
Тогда вызов р выполнялся бы только в том случае, когда результат выполнения операции сравнения а был бы равен ггие. В действительности некоторые классические эвристические алгоритмы преобразования выражений, которые всегда проверяют ограничение перед операцией соединения, не всегда пригодны для типов и операторов, определяемых пользователем (см. [25.7], [25.18]).
° Структуры хранения и методы доступа. Очевидно, оптимизатору необходимо знать, какие структуры хранения и методы доступа используются в системе (см. следующий подраздел). Структуры хранения Должно быть ясно, что для объектно-реляционных систем требуется больше способов, возможно, значительно больше способов хранения и доступа к данным на физическом уровне по сравнению с тем, что обычно предоставляется традиционными БО).- системами. Перечислим некоторые из новых подходов.
° Новые структуры хранения. Как уже отмечалось, системе может потребоваться поддержка новых структур хранения на внешних носителях (К-деревья и т.д.) и даже возможность вводить дополнительные структуры хранения и собственные методы доступа, предоставляемая достаточно подготовленным пользователям. ° Индексы для данных, тип которых определнетгн пользователем. Обычные индексы строятся для данных некоторого встроенного типа со встроенным "пониманием'*, что означает для них оператор "<".
В объектно-реляционных системах необходима возможность создавать индексы по данным, тил которых определяется пользователем и которые основываются на семантике соответствующего оператора "<", также определенного пользователем (конечно, подразумевается, что такой оператор определен в первую очередь). ° Индексы па резуяьтатаи выполнения оператора. Возможно, будет не слишком много пользы в построении индекса непосредственно ло значениям данных типа РОДИОН (многоугольник). Вероятнее всего, все, что удастся получить, — это такой индекс, в котором многоугольники будут упорядочены в соответствии с их 1015 Глава 25.
Объектно-реляционные базвг данных внутренним кодированным представлением в виде строк байтовз. Однако в действительности более полезен был бы индекс, построенный на основании областей, охватываемых этими многоугольниками. Замечание. В главе 21 мы назвали такие индексы функциональными. 25.5. Преимущества реального сближения двух технологий В 125.1) Стоунбрейкер предлагает "матрицу классификации" для СУБД (рис. 25.4). Квадрант 1 этой матрицы представляет приложения, которые обрабатывают простые данные и которым не требуется поддержка произвольных запросов (обычный текстовый процессор — неплохой пример для этого случая). Такие приложения на самом деле не являются приложениями баз данных в полном смысле этого слова. "СУБД*', которая лучше всего подойдет для подобных приложений, — встроенная файловая система, предоставляемая пользователю как часть операционной системы.
Рис. 25.4. Матрица кчассификации СУБК предложенная Стоунбрейкером Квадрант 2 представляет приложения, которые предусматривают ввод произвольных запросов, но все же имеют дело лишь с относительно простыми данными. В эту категорию попадает большинство современных бизнес-приложений. Подобные приложения довольно хорошо поддерживаются традинионными реляционными СУБД (или по крайней мере СУБД, используюшими язык БОЬ).
Квадрант 3 представляет приложения, в которых используются сложные данные и выполняется обработка запросов, но лишь заранее запланированных. К этой категории, например, могут принадлежать приложения САПР/АСУТП. Современные объектные СУБД первоначально нацеливались именно на этот сегмент рынка, поскольку традиционные СУБД не слишком хорошо справляются с задачами, характерными для данной категории приложений. Квадрант 4 представляет приложения, которые нужлаются как в поддержке сложных данных, так и в обработке произвольных запросов к этим данным.
В качестве примера Стоунбрейкер приводит базу данных, содержашую оцифрованные 35-миллиметровые слайды, и типичный запрос к этой базе — "Получить все снимки закатов, сделанные в пределах 20 миль от Сакраменто, Калифорния". Затем он продолжает приводить аргументы в поддержку своей познани; он считает, что объектно-реляционные СУБД необходимы для приложений, попадающих в этот квадрант, и через несколько лет в него бу- г Напочнилхь что, как укозыоачась в главе 24, традиционные системы предоставляют тип данны» ВДОВ для обработки "больизих даоичны«объектов'. В объектно-реляцнонных системах значения данных некоторых типов, определяемых пользователем, зюгут физически «раниться как данные типо ВВОВ.
1016 Часть И. Объектные и объектно-реляционные базы данных дет попадать илн перейдет большая часть приложений. Например, даже обычные приложения кадрового учета будут расширены для поддержки хранения фотографий сотрудников, звуковых записей (речевых сообщений) и т.п. Подводя итог, Стоунбрейкер утверждает (и мы с ним согласны), что "объектнореляционные системы в будущем потребуются всем" и что они — отнюдь не преходящая причуда, которая скоро будет заменена другим, таким же недолговечным, но модным веянием. Однако здесь следует напомнить, что, как мы выяснили, настоящая объектнореляционная система является просто настоящей реляционной системой.
В частности, это система, в которой не допущена ни одна из двух грубейших ошибок. Стоунбрейкер, похоже, не совсем согласен здесь с нашей позицией, по крайней мере в 125311 он об этом ни разу не упомянул, поэтому мы можем предполагать, что, с его точки зрения, смешивание указателей и отношений не только приемлемо, но даже желательно (фактически — требуется). Но как бы то ни было, мы могли бы согласиться, что истинная объектно-реляционная система могла бы решить все проблемы, которые (как мы это утверждали в предыдущей главе) являются проблемами именно объектных систем, а не систем объектнореляционных. Перечислим конкретные возможности, которые должны поддерживаться истинной объектно-реляционной системой без каких-либо ограничений.
° Произвольные запросы, определение представлений и поддержка декларативных ограничений целостности данных ° Методы. которые охватывают классы (нет необхолимости в выделении "целевого операнда") ° Динамически определяемые классы (для размещения результатов произвольных запросов) ° Двойственный режим доступа (в главе 24 мы подчеркивали этот вопрос, но в объектных системах обычно принцип двойственного режима не поддерживается; в них, как правило, используются разные языки лля программного и интерактивного доступа к базе данных) ° Отложенные проверки целостности (до момента фиксации) ° Ограничения переходов ° Семантическая оптимизация ° Связи, степень которых больше двух ° Правила внешних ключей (ОЕ йЕЬЕТЕ САБСлйЕ и т.п.) ° Возможности оптимизации И т.д. Кроме того, желательно следующее.
° Идентификаторы и указатели используются неявно и полностью скрыты от пользователя ° "Сложные" объектные вопросы (например, что означает соединение двух объектов?) больше не возникают ° Преимушества инкапсуляции как таковые используются, но по отношению к скалярным значениям в отношениях, а не к самим отношениям ° Реляционные системы теперь могут справляться с задачами в области "сложных" приложений, таких как САПР/АСУТП, которые нами уже обсуждались При этом реляционный подход остается концептуально чистым.
Глава 25. Объектно-реляционные базы Данных 1017 25.6. Резюме В этой главе вкратце были рассмотрены объектно-реляционные системы. Выяснилось, что такие системы в своей основе являются (или должны быть) просто реляционными системами, которые поддерживают реляционную концепцию доменов (т.е, типов) надлежащим образом, а это, в частности, означает, что пользователи имеют (илн должны иметь) возможность определять собственные типы. Для реляционной модели ничего не требуется, чтобы достичь необходимой нам объектной функциональности, кроме как реализовать такую молель. Затем обсуждались две грубейшие ошибки. Первая заключалась в отождествлении объектных классов и переменных-отношений (уравнение, которое, к сожалению, выглядит привлекательно). Мы выдвинули предположение, что ошибка возникла из-за путаницы с двумя совершенно различными интерпретациями термина объект.
Был подробно рассмотрен пример, который наглядно продемонстрировал, какой может быть система, в которой допущена первая грубейшая ошибка, а также показал, к каким последствиям приводит такая ошибка. Одним из последствий этой ошибки является то, что она приводит непосредственно ко второй грубейшей ошибке, а именно — к смешиванию указателей и отношений (хотя на самом деле вторая ошибка может быть допущена и без первой, и почти все системы на современном рынке, к сожалению, ее допускают). На наш взгляд, вторая грубейшая ошибка нарушает концептуальную целостность реляционной модели во многих отношениях.
В частности, она нарушает принцип взаииозаиепяемоств базовых и производных отношений. Далее бегло рассматривались некоторые вопросы реализации. Важнейший из них— добавление новых "пакетов типов" — влияет по крайней мере на компилятор и компоненты управления хранением данных в системе. Поэтому объектно-реляционные системы не могут быть реализованы простым добавлением нового уровня программ к уже сушествующей системе. Система должна быть перестроена с самого основания, чтобы каждый нз ее компонентов в случае необходимости был открытым.
И наконец мы познакомились с матрицеб кгассифвкаиии СУБД Стоуибрейкера и кратко обсудили те преимушества, которые могли бы быть получены от истинного сближения объектных и реляционных технологий (здесь под "истинным сближением" подразумевается, в частности, что не допущены две указанные выше грубейшие ошибки). Список литературы В последние годы было создано несколько обьектно-реляционных прототипов. Среди них наиболее известны система Розгягез, разработанная в университете штата Калифорния в Беркли ([25.2б[, [25.30), [25.32)), и система ЯагЬогзг, разработанная в корпорации !ВМ ([25.14), [25.17[, [25.21), [25.22)). Обратите внимание, что ни одна из них не может быть отнесена, по крайней мере в оригинальной версии, к системам, объектный подход которых основывался бы на "очевидно корректном" уравнении домен = класс.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
