[Назад] [Оглавление] [Вперед]

3.1 Второй манифест

Авторы Второго манифеста относят к первому поколению систем баз данных предшествовавшие РСУБД иерархические и сетевые системы, а существовавшие во время написания манифеста реляционные системы – ко второму поколению. В документе рассматриваются характеристики, которыми должны обладать менеджеры баз данных следующего, уже третьего поколения. Требования состоят из трех основных принципов и тринадцати детальных предложений.

Введение

Сетевые и иерархические системы баз данных, широко распространенные в 70-е годы, получили название систем баз данных первого поколения. Действительно, это были первые системы, предлагавшие развитую функциональность СУБД в рамках единой системы, с языками определения и манипулирования данными для наборов записей. Типичными представителями первого поколения являются сетевые системы, основанные на предложениях CODASYL , и иерархическая СУБД IMS .

В 80-е годы системы первого поколения были существенно потеснены семейством реляционных СУБД, называемых в манифесте системами баз данных второго поколения. Их появление стало важным шагом вперед для многих приложений, так как в этих системах использовались непроцедурные языки манипулирования данными и предусматривалась значительная степень независимости данных. Типичными представителями систем второго поколения во время написания Второго манифеста являлись DB 2, INGRES , NON -STOP SQL , ORACLE и Rdb /VMS ⁵³.

Однако системы второго поколения были сфокусированы на приложениях обработки бизнес-данных и не являлись адекватными решениями для более широкого класса приложений. Системы автоматизации проектирования (САПР), системы CASE и гипертекстовые приложения часто выделяются как примеры, в которых можно было бы эффективно использовать различные СУБД, обладающие специализированными возможностями. Например, для обеспечения работоспособности издательской системы  необходимо хранить элементов данных, встречаемых в гипертекстовых средах. Поддержка таких элементов данных системами второго поколения обычно сопряжена с немалыми трудностями.

Но в действительности системы второго поколения не особо хороши и для поддержки большинства бизнес-приложений. Например, для страхового приложения, обрабатывающего требования о выплатах, требуются традиционные типы данных, такие как имя человека и размер причитающейся ему страховой выплаты, но желательно также хранить и образы фотографий события, к которому относится требование о выплате, и факсимиле оригинального рукописного требования о выплате. Подобные элементы данных неудобно хранить в СУБД второго поколения. Более того, вся информация, имеющая отношение к определенному требованию о выплате, объединяется в папку, содержащую традиционные данные, образы и, возможно, процедурные данные. Структура папки часто бывает настолько сложной, что в сравнении с ней элементы данных и агрегированные данные САПР и CASE -систем кажутся довольно простыми.

Большинство современных поставщиков СУБД работают над значительным расширением функций своих СУБД второго поколения. Они единодушны в отношении желаемых возможностей систем следующего, третьего поколения. Во Втором манифесте авторы предлагают три основных принципа, которыми, по их мнению, следует руководствоваться при создании систем третьего поколения. Кроме этого, приводятся 13 предложений, в которых требования к новым системам обсуждаются более детально. Авторы полагают целесообразным сопоставить их работу с Манифестом систем объектно-ориентированных баз данных, в котором предлагаются другие наборы принципов.

Принципы СУБД третьего поколения

Первый принцип касается определения СУБД третьего поколения: помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечивать поддержку более богатых структур объектов⁵⁴ и правил.

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

Для успешного решения большинства задач СУБД должна предоставлять услуги в области данных, объектов и правил. Хотя, возможно, на рынке найдется ниша и для систем с меньшими возможностями, для достижения коммерческого успеха в 90-е годы СУБД должна предоставлять сервисы во всех трех перечисленных областях.⁵⁵

Второй принцип: СУБД третьего поколения должны включить в себя СУБД второго поколения.

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

Существует точка зрения, что имеются приложения, которым никогда не потребуется выполнять запросы из-за присущей им простоты доступа к СУБД. В качестве примера часто предлагаются САПР. Делается вывод, что будущим системам язык запросов не потребуется и, следовательно, отпадает необходимость включения систем второго поколения. Авторы Второго манифеста беседовали со многими разработчиками САПР, интересующимися базами данных, и все они отмечали необходимость языка запросов.

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

Третий принцип состоит в том, что СУБД третьего поколения должны быть открыты для других подсистем.

Иными словами, любая СУБД, рассчитывающая на широкую сферу применения, должна быть оснащена языком четвертого поколения (4GL )⁵⁶, разнообразными инструментами поддержки принятия решений⁵⁷, дружественным доступом из многих языков программирования, дружественным доступом из популярных подсистем, таких как LOTUS 1-2-3, интерфейсами с графическими бизнес-пакетами, возможностью запуска приложений из базы данных на другой машине и возможностью организации распределенной базы данных. Весь набор инструментов и СУБД должен эффективно функционировать на разнообразных аппаратных платформах с различными операционными системами.

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

Тринадцать предложений

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

Предложения, касающиеся управления объектами и правилами

Создатели СУБД не в состоянии предвидеть все виды элементов данных, которые могут потребоваться приложениям. СУБД третьего поколения должны управлять разнообразными объектами, и авторы манифеста выдвигают четыре предложения, относящиеся к управлению объектами, конструкторам типов, наследованию, функциям и уникальным идентификаторам.

Предложение 1.1: Система типов СУБД третьего поколения должна быть богатой и разнообразной.

Все перечисленные механизмы являются желательными:

1)      система абстрактных типов данных для создания новых базовых типов;

2)      конструктор типа массив;

3)      конструктор типа последовательность;

4)      конструктор типа запись;

5)       конструктор типа множество;⁵⁸

6)      функции как тип;

7)      конструктор типа объединение;

8)      рекурсивная композиция всех перечисленных выше конструкторов.

Первый механизм позволяет конструировать новые базовые типы в дополнение к стандартному набору типов, имеющемуся в большей части систем. Должно быть возможно определять типы битовых строк, точек, линий, комплексных чисел и т.д. Второй механизм позволяет использовать массивы элементов данных. Обычным свойством массивов является отсутствие возможности вставить новый элемент в середину, сдвинув все последующие элементы. В некоторых приложениях такая вставка бывает необходимой, и конструктор третьего вида поддерживает подобные последовательности. Четвертый механизм позволяет группировать элементы данных в записи. Пятый механизм требуется для создания неупорядоченных наборов элементов данных или записей. Шестой механизм – функции (методы) – обсуждается в предложении 1.3; желательно, чтобы СУБД поддерживала такие конструкции. Следующий механизм позволяет создавать элементы данных, которые могут принимать значения одного из нескольких типов.⁵⁹ Последний механизм позволяет рекурсивно комбинировать конструкторы типов для поддержки сложных объектов, обладающих внутренней структурой. Более того, в отличие от систем второго поколения, последний примененный конструктор типов не обязан быть конструктором множеств.⁶⁰

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

Системы второго поколения обладают лишь частью перечисленных конструкторов типов, и сторонники объектно-ориентированных баз данных утверждали, что для поддержки всех этих возможностей должны появиться качественно новые СУБД. Авторы манифеста придерживались другой точки зрения. В манифесте утверждается, что все обсуждаемые конструкторы типов можно добавить к реляционным системам как естественное расширение, и что технология этого расширения достаточно хорошо продумана. Более того, уже в то время начали появляться коммерческие реляционные системы с некоторыми из перечисленных возможностей.

Предложение 1.2: Наследование – хорошая идея.

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

Желательно также иметь наборы, для которых не задаются дополнительные поля. Например, набор TEENAGER (подросток) можно было бы определить как набор, состоящий из таких же элементов данных, что и PERSON , но обладающий ограничениями на возраст. Опять-таки, уже создавались прототипы, демонстрирующие, как добавлять эти возможности к реляционным системам, и авторы манифеста ожидали, что коммерческие реляционные системы будут развиваться в этом направлении.⁶¹

Предложение 1.3: Функции, в том числе процедуры и методы баз данных, и инкапсуляция – хорошие идеи.

В системах второго поколения имеется лишь ограниченная поддержка функций и инкапсуляции. Например, в SQL над таблицами возможны только операции, осуществляемые функциями create , alter и drop .⁶² Абстракция таблицы доступна только путем выполнения одной из перечисленных функций.

Очевидно, что выгоды, предоставляемые инкапсуляцией, должны стать доступными для разработчиков приложений, чтобы те могли ассоциировать функции с пользовательскими наборами данных. Например, должна иметься возможность ассоциировать функции HIRE ( EMPLOYEE ) , FIRE ( EMPLOYEE ) и RAISE - SAL ( EMPLOYEE ) (нанять, уволить служащего и повысить ему зарплату) с уже знакомым набором данных EMPLOYEE . Если пользователям не разрешен прямой доступ к набору EMPLOYEE , а вместо этого предоставлены упомянутые функции, то вся информация о внутренней структуре объектов класса EMPLOYEE инкапсулируется внутри этих функций.⁶³

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

В защищенных или распределенных системах применение инкапсуляции часто дает выигрыш в производительности. Например, функции HIRE ( EMPLOYEE ) в процессе выполнения несколько раз может потребоваться доступ к базе данных. Если HIRE ( EMPLOYEE ) задана как функция, которая должна быть выполнена сервером базы данных внутренним образом, то между приложением и СУБД состоится только один цикл обмена сообщениями. С другой стороны, если функция запускается из программы пользователя, один цикл обмена сообщениями потребуется для каждого доступа. ⁶⁴

Наконец, такие функции могут быть унаследованы и, возможно, переопределены в иерархии наследования. Другими словами, функция HIRE ( EMPLOYEE ) может быть автоматически применена к набору STUDENT - EMPLOYEE . Если воспользоваться возможностью переопределения, функцию HIRE для набора STUDENT - EMPLOYEE можно переписать. Словом, использование инкапсулированных функций крайне желательно. Однако авторы манифеста приводят три замечания.

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

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

Последнее замечание касается коммерческого рынка. Все крупнейшие поставщики СУБД второго поколения уже поддерживают функции, написанные на языке программирования высокого уровня (обычно на поддерживаемом поставщиком 4GL ), которые могут производить обращения к СУБД в терминах SQL . Более того, эти функции могут быть использованы для инкапсуляции доступа к данным, которыми они управляют. Поставщикам коммерческих реляционных систем осталось поработать над поддержкой наследования функций.

Предложение 1.4: Уникальные идентификаторы (UID ) записей должны задаваться СУБД только в том случае, когда недоступен определенный пользователем первичный ключ.

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

Предложение 1.5: Правила (триггеры, ограничения) станут одной из ключевых характеристик будущих систем.

Правила не следует ассоциировать с определенными функциями или наборами. Исследователи объектно-ориентированных баз данных обычно игнорировали необходимость правил. На вопрос о правилах энтузиасты ООБД отвечали либо молчанием, либо предложением внедрять их путем включения кода для их поддержки в одну или несколько функций, работающих с набором.

С точки зрения авторов манифеста, имеется только одно разумное решение: правила должны поддерживаться СУБД, но не быть привязаны ни к какой функции и ни к какому набору. Из этого положения следуют два факта. Во-первых, парадигма ООБД “все выражается методами” просто не применима к правилам. Во-вторых, нельзя предоставлять непосредственный доступ к внутренним интерфейсам СУБД ниже уровня активации правил (иначе пользователи смогут обходить систему, включающую правила в нужное время).

Ко времени написания Второго манифеста уже существовали продукты поставщиков систем второго поколения, отвечающие приведенному предложению. Тем самым, в вопросах, касающихся этого предложения, коммерческий реляционный рынок опередил уровень исследований ООБД.

Предложения, касающиеся увеличения функциональных возможностей СУБД

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

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

В литературе, посвященной ООБД, как правило, недооценивается критическая важность высокоуровневых языков доступа к данным, по выразительной силе не уступающих реляционному языку запросов. Например, в Первом манифесте выдвигается предложение, что СУБД должна предоставлять возможность интерактивного доступа к данным в любой удобной форме. Авторы Второго манифеста делают более сильное утверждение: выразительная сила языка запросов должна присутствовать в любом интерфейсе программируемого доступа; не должно быть других способов доступа к данным СУБД. В перспективе такой сервис может быть обеспечен путем добавления конструкций языка запросов к различным языкам программирования со стабильным хранением данных. В ближайшем будущем этот сервис может быть обеспечен путем встраивания языка запросов в обычные языки программирования.

Многие исследователи OODB утверждают, что для приложений, ради которых они разрабатывают свои системы, желательна навигация к искомым данным с использованием низкоуровневого процедурного интерфейса. В частности, им требуется интерфейс с СУБД, с помощью которого можно получать доступ к определенным записям. Один или более элементов данных записи будет иметь тип “ссылка на запись в каком-то другом наборе”, обычно представляемым своего рода указателем на запись другого набора, то есть идентификатором объекта. Далее, приложение выберет один из указателей для создания новой текущей записи. Этот процесс будет продолжаться до тех пор, пока приложение не доберется до искомых данных.

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

Авторы Второго манифеста утверждают, что их подход приносит выигрыш в производительности по сравнению с использованием низкоуровневых интерфейсов. Это утверждение, на первый взгляд, противоречит интуиции и нуждается в объяснениях. Подавляющее большинство энтузиастов ООБД считает, что указатель должен быть мягким, т.е. его значение не должно меняться, даже если элемент данных, на который он указывал, был передвинут. Эта характеристика, называемая позиционной независимостью, является желательной, так как она позволяет перемещать элементы данных, не меняя при этом структуры базы данных. Перемещения элементов данных часто неизбежны при реорганизации базы данных или восстановлении после сбоев. Таким образом, энтузиасты ООБД рекомендуют использовать в качестве указателей позиционно независимые уникальные идентификаторы. В этом случае для перехода по указателю необходим доступ к хэшированной или индексированной структуре уникальных идентификаторов.

В SQL -представлении, пара (имя-отношения, ключ) в точности является позиционно независимым уникальным идентификатором, задающим тот же хэшированный или индексированный просмотр. Все накладные расходы, связанные с синтаксисом SQL , с высокой степенью вероятности придутся на время компиляции. Поэтому авторы Второго манифеста утверждают, что использование интерфейсов низкого уровня для возвращения единственного элемента данных дает в лучшем случае лишь микроскопический выигрыш в производительности. Если же возвращается несколько элементов данных, то замещение запроса высокого уровня множеством вызовов низкого уровня может снизить производительность из-за расходов на организацию вызовов от приложения к СУБД.

Наконец, энтузиасты ООБД часто утверждают, что программисты, например, САПР, хотят собственноручно осуществлять навигацию, и поэтому система должна поощрять ее при помощи интерфейсов низкого уровня. Да, некоторые программисты могут предпочитать навигацию. Были такие, которые отказывались переходить с языка ассемблера на языки высокого уровня, были и те, кто отказывался переходить к реляционным системам – на новых системах задачи были не столь сложными, а, значит, работа не столь интересная. Эти программисты думали, что смогут работать лучше, чем компиляторы и оптимизаторы. Авторы манифеста считают, что аргументы против навигации достаточно убедительны и что некоторым программистам просто не мешает подучиться.

Предложение 2.2: Должно быть по крайней мере два способа спецификации наборов: посредством перечисления членов и путем использования языка запросов для задания членов.

В литературе по ООБД предлагается задание множеств перечислением, средствами связанного списка или массива идентификаторов членов. Авторы манифеста полагают, что такая спецификация не является лучшим выбором.

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

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

Оба представления необходимы, но предпочтение должно отдаваться интенсиональному. С другой стороны, энтузиасты ООБД, как правило, рекомендуют использовать лишь экстенсиональные методы. В середине 70-х годов преимуществам автоматического задания множеств посвящалось немало внимания. Чтобы не сделать шаг назад, системы третьего поколения должны отдавать предпочтение автоматическим множествам.

Предложение 2.3: Существенно наличие обновляемых представлений.

Существует очень немного статических баз данных – большая часть данных постоянно изменяется. При изменениях наборов данных может потребоваться модификация программ. Очевидно, что инкапсуляция доступа к базе данных в функции и инкапсуляция функций в один набор была бы полезным шагом. Это позволило бы легко выявлять функции, в которые необходимо внести изменения. Однако это решение не является достаточным. Если изменяется схема базы данных, то на переписывание затронутых этими изменениями функций могут уйти недели или даже месяцы. В это время база данных не может просто перестать работать.

Гораздо лучшим подходом является поддержка виртуальных наборов (представлений). В системах второго поколения поддерживались некоторые возможности в данной области, что было продвижением вперед по сравнению с системами первого поколения. К сожалению, обновление реляционных представлений часто оказывается невозможным. Системы третьего поколения должны демонстрировать лучшее поведение при обновлении представлений.

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

Элементы виртуального набора не обязаны иметь уникальный идентификатор, так как физически их не существует. Следовательно, вряд ли можно требовать, чтобы каждая запись в наборе обладала уникальным идентификатором, как это делается во многих существующих прототипах ООБД.⁶⁷

Предложение 2.4: Показатели производительности не имеют почти ничего общего с моделями данных и не должны в них проявляться.

Основными параметрами, по которым оценивается производительность работы с использованием как SQL , так и спецификаций более низкого уровня, являются следующие показатели:

• объем работ по оптимизации настройки СУБД с целью повышения ее эффективности;
• использование в СУБД методов компиляции;
• местонахождение буферного пула (в адресном пространстве клиента или СУБД);
• доступные типы индексирования;
• производительность интерфейса клиент СУБД;
• поддерживаемая кластеризация.

Эти вопросы не имеют ничего общего с моделью данных или с использованием языков высокого уровня типа SQL вместо навигационного интерфейса низкого уровня. Например, тактика кластеризации связанных объектов представляется как важная черта ООБД. Однако эта тактика использовалась в системах баз данных уже многие годы, например, являлась основным средством в большинстве методов доступа IMS . Следовательно, кластеризация является вопросом физического представления и не имеет ничего общего с моделью данных СУБД. Аналогично, с моделью данных не связаны решения о том, должна ли система строить индексы для уникальных идентификаторов, и следует ли ей буферизовать записи базы данных на клиентской машине или даже в пользовательском пространстве прикладной программы. При известном потоке запросов к базе данных следует пытаться достичь максимальной производительности. Действенность конкретных методов зависит от специфики приложений. Эти методы пригодны для любой системы баз данных.

Предложения, следующие из необходимости открытости системы

Обратим внимание на прикладной программный интерфейс (Applications Programming Interface – API ), посредством которого программа пользователя будет общаться с СУБД.

Предложение 3.1: СУБД третьего поколения должны быть доступны из различных языков программирования высокого уровня.

Некоторые разработчики систем утверждают, что СУБД должна быть тесно привязана к определенному языку программирования. Например, они говорят, что функция должна возвращать один и тот же результат независимо от того, была ли она выполнена в программе пользователя для временных данных или внутри СУБД для стабильных данных. Этого можно достичь только в том случае, если модель выполнения СУБД идентична модели выполнения конкретного языка программирования. Авторы манифеста считают, что это неверный подход.

Во-первых, невозможно договориться, какой именно язык программирования следует использовать. Приложения кодируются и будут кодироваться на различных языках, и на горизонте пока не видно языка программирования Esperanto . Отсюда следует необходимость в многоязычной СУБД.

Имеется еще одна причина, по которой открытая СУБД должна быть многоязычной. СУБД должна предоставлять доступ для различных внешних прикладных подсистем, например, Lotus 1-2-3. Такие подсистемы будут кодироваться на различных языках программирования – вот еще один аргумент в пользу многоязычности.

Предложение 3.2: Язык “X с поддержкой стабильных данных” (для различных X ) является хорошей идеей. Языки будут поддерживаться над единой СУБД благодаря расширениям компилятора и (более или менее) сложной системе времени выполнения.

В интерфейсах систем второго поколения с языками программирования препроцессор использовался отчасти потому, что на ранней стадии разработчики СУБД не сотрудничали с разработчиками компиляторов. Более того, у сохранения независимости языка СУБД от языков программирования есть свои преимущества (например, СУБД и языки программирования можно независимо расширять и тестировать). Однако получавшиеся интерфейсы не отличались дружественностью и уже в 1977 году были охарактеризованы как “попытки приклеить яблоко к блину”. Поставщики обычно концентрировали свои усилия на создании элегантного интерфейса между своими языками четвертого поколения и сервисами баз данных. Очевидно, что не менее элегантные интерфейсы можно создать и для универсальных языков программирования.

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

Как отмечалось ранее, функции должны кодироваться путем включения вызовов к СУБД, выраженных на языке запросов. Следовательно, и для “X с поддержкой стабильных данных” также требуются средства выражения на языке запросов. Такие запросы могут быть выражены в нотации, соответствующей специфике языка программирования. Системы времени выполнения должны принимать и обрабатывать такие запросы и доставлять результаты обратно в программу.

Будет создано множество разнообразных “X с поддержкой стабильных данных”. Для каждого из них потребуются свои модификации компилятора и системы времени выполнения. Все системы времени выполнения будут подключены к общей СУБД.⁶⁸ Очевиден вопрос “Как выражать запросы к этой общей СУБД?”. Ответ дается в следующем предложении.

Предложение 3.3: Хорошо это или плохо, но SQL становится интергалактическим языком данных.

На сегодня SQL предоставляет универсальный способ выражения запросов. При создании первых коммерческих объектно-ориентированных баз данных этот факт не учитывался, и потом пришлось встраивать в продукты запросные системы на основе запросов SQL . К сожалению, многие продукты не дожили до окончания этой работы. Хотя перед SQL и стоит множество мелких проблем, он необходим для коммерческой жизнеспособности. Любая компания-производитель объектно-ориентированных систем баз данных, желающая, чтобы ее продукт оказывал влияние на рынок, должна понять, что покупатели голосуют своими долларами за SQL . Более того, SQL является разумной кандидатурой для новых функций, предлагаемых в этой работе. Конечно, для некоторых приложений и языков программирования могут оказаться адекватными и другие языки запросов.

Предложение 3.4: Запросы и ответы на них должны образовывать нижний уровень коммуникаций между клиентом и сервером.

В условиях, когда пользователь находится за рабочей станцией и взаимодействует с данными на удаленном сервере, встает вопрос о протоколах взаимодействия рабочей станции и сервера. Энтузиасты ООБД обсуждают, должны ли посылаться запросы на единичные записи, единичные страницы или должен использоваться иной механизм. Точка зрения авторов манифеста крайне проста: выражения на языке запросов должны образовывать нижний уровень коммуникаций. Конечно, если набор запросов можно упаковать в функцию, пользователь может использовать удаленный вызов для выполнения функции на сервере. Эта возможность желательна, поскольку она позволяет обойтись менее чем одним сообщением на запрос.

Заключение Второго Манифеста

Авторы Манифеста баз данных следующего поколения во многом согласны с энтузиастами ООБД. Среди общих тем выделяются выгодность использования богатой системы типов, функций, наследования и инкапсуляции. Однако во многих областях позиции прямо противоположны. Во-первых, Манифест объектно-ориентированных баз данных слишком узко сфокусирован на вопросах управления объектами. Авторы Второго манифеста обращаются к более широкому кругу вопросов, включающих поддержку управления данными, правилами и объектами на основе полного набора инструментов при наличии интеграции СУБД и языка запросов в многоязычную среду. Предлагаемые многими энтузиастами ООБД одноязычные системы, не поддерживающие SQL , привлекательны лишь для довольно узкого рынка.

Во-вторых, представляется, что доступ к СУБД должен осуществляться при помощи языка запросов, и история подтверждают правильность такой точки зрения. Следует избегать физической навигации, выполняемой программами пользователей или происходящей внутри функций. В-третьих, необходимо всячески поощрять использование автоматических наборов, так как они предоставляют массу преимуществ по сравнению с явно поддерживаемыми наборами. В-четвертых, свойство стабильности данных может быть добавлено ко многим языкам программирования. Поскольку не существует языка программирования, аналогичного эсперанто, этого следует достигать путем изменения компилятора и написания специфичной для языка системы времени выполнения, взаимодействующей с единой СУБД. Таким образом, языки программирования с поддержкой стабильных данных мало связаны с моделями данных. В-пятых, уникальные идентификаторы должны задаваться либо пользователем, либо системой (здесь наличествует противоречие с одним из принципов Первого манифеста).

Основной вопрос, по которому авторы Второго манифеста расходились во мнениях с большей частью сообщества ООБД, – это возможность естественной эволюции современных реляционных систем к системам, поддерживающим возможности, обсуждаемые в данной работе. Авторы данного манифеста верили в такую возможность. Уже в то время продукты основных поставщиков реляционных систем удовлетворяли принципам 1, 2 и 3 и обеспечивали хорошую поддержку предложений 1.3, 1.4, 1.5, 2.1, 2.3, 2.4, 3.1, 3.3 и 3.4. Для превращения в СУБД третьего поколения в эти продукты оставалось добавить наследование и дополнительные конструкторы типов и внедрить языки программирования с поддержкой стабильных данных. Существовали прототипы систем, указывающие пути включения и этих средств.

С другой стороны, современные (в то время) системы, провозглашаемые объектно-ориентированными, обычно не соответствуют провозглашаемым во Втором манифесте принципам и поддерживают лишь предложения 1.1 (частично), 1.2, 1.3 и 3.2. Для превращения в подлинные СУБД третьего поколения таким системам не хватает языка запросов и оптимизатора запросов, системы правил, поддержки SQL в архитектуре клиент-сервер, поддержки представлений и языков программирования со стабильными данными. Кроме того, в них должны быть отменены любые жесткие требования наличия уникальных идентификаторов и прекращено поощрение навигации. Более того, в них необходимо построить языки четвертого поколения, внедрить поддержку распределенных баз данных и осуществить настройку системы для эффективного управления данными.

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

[Назад] [Оглавление] [Вперед]