Предложения, касающиеся увеличения функциональных возможностей СУБД
Как уже отмечалось, системы третьего поколения не должны делать шаг назад, то есть они должны вобрать в себя все возможности, предоставляемые системами второго поколения. Особого внимания заслуживают язык запросов, спецификация множеств элементов данных и независимость данных. Следующие четыре предложения, касаются перечисленных вопросов.
Предложение 2.1: Все виды программируемого доступа к базам данных должны осуществляться через непроцедурный язык доступа высокого уровня.
В литературе, посвященной ООБД, как правило, недооценивается критическая важность высокоуровневых языков доступа к данным, по выразительной силе не уступающих реляционному языку запросов. Например, в Первом манифесте
выдвигается предложение, что СУБД должна предоставлять возможность интерактивного доступа к данным в любой удобной форме. Авторы Второго манифеста делают более сильное утверждение: выразительная сила языка запросов должна присутствовать в любом интерфейсе программируемого доступа; не должно быть других способов доступа к данным СУБД. В перспективе такой сервис может быть обеспечен путем добавления конструкций языка запросов к различным языкам программирования со стабильным хранением данных. В ближайшем будущем этот сервис может быть обеспечен путем встраивания языка запросов в обычные языки программирования.
Многие исследователи OODB утверждают, что для приложений, ради которых они разрабатывают свои системы, желательна навигация к искомым данным с использованием низкоуровневого процедурного интерфейса. В частности, им требуется интерфейс с СУБД, с помощью которого можно получать доступ к определенным записям. Один или более элементов данных записи будет иметь тип “ссылка на запись в каком-то другом наборе”, обычно представляемым своего рода указателем на запись другого набора, то есть идентификатором объекта. Далее, приложение выберет один из указателей для создания новой текущей записи. Этот процесс будет продолжаться до тех пор, пока приложение не доберется до искомых данных.
По мнению авторов Второго манифеста, подобные интерфейсы неудобны, и использовать их не следует. Во-первых, когда программист осуществляет навигацию к искомым данным, он заменяет функции оптимизатора запросов написанными вручную вызовами более низкого уровня. История наглядно продемонстрировала, что хорошо написанный и хорошо настроенный оптимизатор почти во всех случаях добивается лучших результатов, чем написанные вручную вызовы. Далее, если изменится некоторое число индексов или данные в кластере будут реорганизованы, навигационный интерфейс не сможет автоматически приспособиться к переменам. Значит, если изменятся физические пути доступа к данным, программисту придется модифицировать программу. С другой стороны, оптимизатор запросов просто создает новый план, который оптимизируется для новой среды.
Авторы Второго манифеста утверждают, что их подход приносит выигрыш в производительности по сравнению с использованием низкоуровневых интерфейсов. Это утверждение, на первый взгляд, противоречит интуиции и нуждается в объяснениях. Подавляющее большинство энтузиастов ООБД считает, что указатель должен быть мягким, т.е. его значение не должно меняться, даже если элемент данных, на который он указывал, был передвинут. Эта характеристика, называемая позиционной независимостью, является желательной, так как она позволяет перемещать элементы данных, не меняя при этом структуры базы данных. Перемещения элементов данных часто неизбежны при реорганизации базы данных или восстановлении после сбоев. Таким образом, энтузиасты ООБД рекомендуют использовать в качестве указателей позиционно независимые уникальные идентификаторы. В этом случае для перехода по указателю необходим доступ к хэшированной или индексированной структуре уникальных идентификаторов.
В SQL -представлении, пара (имя-отношения, ключ) в точности является позиционно независимым уникальным идентификатором, задающим тот же хэшированный или индексированный просмотр. Все накладные расходы, связанные с синтаксисом SQL , с высокой степенью вероятности придутся на время компиляции.
Поэтому авторы Второго манифеста утверждают, что использование интерфейсов низкого уровня для возвращения единственного элемента данных дает в лучшем случае лишь микроскопический выигрыш в производительности. Если же возвращается несколько элементов данных, то замещение запроса высокого уровня множеством вызовов низкого уровня может снизить производительность из-за расходов на организацию вызовов от приложения к СУБД.
Наконец, энтузиасты ООБД часто утверждают, что программисты, например, САПР, хотят собственноручно осуществлять навигацию, и поэтому система должна поощрять ее при помощи интерфейсов низкого уровня. Да, некоторые программисты могут предпочитать навигацию. Были такие, которые отказывались переходить с языка ассемблера на языки высокого уровня, были и те, кто отказывался переходить к реляционным системам – на новых системах задачи были не столь сложными, а, значит, работа не столь интересная. Эти программисты думали, что смогут работать лучше, чем компиляторы и оптимизаторы. Авторы манифеста считают, что аргументы против навигации достаточно убедительны и что некоторым программистам просто не мешает подучиться.
Предложение 2.2: Должно быть по крайней мере два способа спецификации наборов: посредством перечисления членов и путем использования языка запросов для задания членов.
В литературе по ООБД предлагается задание множеств перечислением, средствами связанного списка или массива идентификаторов членов. Авторы манифеста полагают, что такая спецификация не является лучшим выбором.
Имеются, по меньшей мере, два способа задания наборов, таких как множества, массивы, последовательности и т.д. Их можно определять “экстенсионально” при помощи набора указателей или “интенсионально” при помощи выражения. Интенсиональная спецификация поддерживает автоматическое определение принадлежности к множеству, что желательно для большинства приложений. Экстенсиональная спецификация предпочтительна лишь в тех случаях, когда между членами множества отсутствует структурная связь или когда автоматическое определение членства нежелательно.
При интенсиональной спецификации оптимизатор запросов может производить семантические преобразования. Это позволяет выбирать пути доступа, лучшие для данного запроса. Никаких ограничений, налагаемых структурами указателей, не существует. Таким образом, полномочия по принятию решений по вопросам физического представления делегируются администратору базы данных. Администратор может решать, какие способы доступа следует поддерживать (например, связанные списки или массивы указателей).
Оба представления необходимы, но предпочтение должно отдаваться интенсиональному. С другой стороны, энтузиасты ООБД, как правило, рекомендуют использовать лишь экстенсиональные методы. В середине 70-х годов преимуществам автоматического задания множеств посвящалось немало внимания. Чтобы не сделать шаг назад, системы третьего поколения должны отдавать предпочтение автоматическим множествам.
Предложение 2.3: Существенно наличие обновляемых представлений.
Существует очень немного статических баз данных – большая часть данных постоянно изменяется. При изменениях наборов данных может потребоваться модификация программ. Очевидно, что инкапсуляция доступа к базе данных в функции и инкапсуляция функций в один набор была бы полезным шагом. Это позволило бы легко выявлять функции, в которые необходимо внести изменения. Однако это решение не является достаточным. Если изменяется схема базы данных, то на переписывание затронутых этими изменениями функций могут уйти недели или даже месяцы. В это время база данных не может просто перестать работать.
Гораздо лучшим подходом является поддержка виртуальных наборов (представлений). В системах второго поколения поддерживались некоторые возможности в данной области, что было продвижением вперед по сравнению с системами первого поколения. К сожалению, обновление реляционных представлений часто оказывается невозможным. Системы третьего поколения должны демонстрировать лучшее поведение при обновлении представлений.
Традиционным способом поддержки обновления представлений заключается в том, что для каждого набора элементов данных, над которым может быть построено обновляемое представление, поддерживается группа функций, посредством которых осуществляется весь доступ к набору.
Автор определения представления должен вносить необходимые изменения в каждую из этих функций. Это влечет за собой значительные расходы на сопровождение программ, а также не позволяет выполнять обновление с помощью языка запросов. В качестве альтернативы такому подходу можно выдвинуть подходящую систему правил. Преимущество второго подхода заключается в том, что для обеспечения семантики обновления снимка требуется задать только одно (или несколько) правил. Это намного проще, чем внесение изменений в набор функций.66
Элементы виртуального набора не обязаны иметь уникальный идентификатор, так как физически их не существует. Следовательно, вряд ли можно требовать, чтобы каждая запись в наборе обладала уникальным идентификатором, как это делается во многих существующих прототипах ООБД.67
Предложение 2.4: Показатели производительности не имеют почти ничего общего с моделями данных и не должны в них проявляться.
Основными параметрами, по которым оценивается производительность работы с использованием как SQL , так и спецификаций более низкого уровня, являются следующие показатели:
Эти вопросы не имеют ничего общего с моделью данных или с использованием языков высокого уровня типа SQL вместо навигационного интерфейса низкого уровня. Например, тактика кластеризации связанных объектов представляется как важная черта ООБД. Однако эта тактика использовалась в системах баз данных уже многие годы, например, являлась основным средством в большинстве методов доступа IMS . Следовательно, кластеризация является вопросом физического представления и не имеет ничего общего с моделью данных СУБД. Аналогично, с моделью данных не связаны решения о том, должна ли система строить индексы для уникальных идентификаторов, и следует ли ей буферизовать записи базы данных на клиентской машине или даже в пользовательском пространстве прикладной программы.При известном потоке запросов к базе данных следует пытаться достичь максимальной производительности. Действенность конкретных методов зависит от специфики приложений. Эти методы пригодны для любой системы баз данных.
