Предложения, следующие из необходимости открытости системы
Обратим внимание на прикладной программный интерфейс (Applications Programming Interface – API ), посредством которого программа пользователя будет общаться с СУБД.
Предложение 3.1: СУБД третьего поколения должны быть доступны из различных языков программирования высокого уровня.
Некоторые разработчики систем утверждают, что СУБД должна быть тесно привязана к определенному языку программирования. Например, они говорят, что функция должна возвращать один и тот же результат независимо от того, была ли она выполнена в программе пользователя для временных данных или внутри СУБД для стабильных данных. Этого можно достичь только в том случае, если модель выполнения СУБД идентична модели выполнения конкретного языка программирования. Авторы манифеста считают, что это неверный подход.
Во-первых, невозможно договориться, какой именно язык программирования следует использовать. Приложения кодируются и будут кодироваться на различных языках, и на горизонте пока не видно языка программирования Esperanto . Отсюда следует необходимость в многоязычной СУБД.
Имеется еще одна причина, по которой открытая СУБД должна быть многоязычной. СУБД должна предоставлять доступ для различных внешних прикладных подсистем, например, Lotus 1-2-3. Такие подсистемы будут кодироваться на различных языках программирования – вот еще один аргумент в пользу многоязычности.
Предложение 3.2: Язык “X с поддержкой стабильных данных” (для различных X ) является хорошей идеей. Языки будут поддерживаться над единой СУБД благодаря расширениям компилятора и (более или менее) сложной системе времени выполнения.
В интерфейсах систем второго поколения с языками программирования препроцессор использовался отчасти потому, что на ранней стадии разработчики СУБД не сотрудничали с разработчиками компиляторов. Более того, у сохранения независимости языка СУБД от языков программирования есть свои преимущества (например, СУБД и языки программирования можно независимо расширять и тестировать). Однако получавшиеся интерфейсы не отличались дружественностью и уже в 1977 году были охарактеризованы как “попытки приклеить яблоко к блину”.
Поставщики обычно концентрировали свои усилия на создании элегантного интерфейса между своими языками четвертого поколения и сервисами баз данных. Очевидно, что не менее элегантные интерфейсы можно создать и для универсальных языков программирования.
Во-первых, очень важно установить более точное соответствие между системами типов. Именно в этом состоит основная проблема современных реализаций встроенного SQL , а не синтаксиса SQL . Во-вторых, было бы хорошо предоставить возможность сделать любую переменную в программе пользователя стабильной. Значения стабильных переменных не утрачиваются даже после окончания работы программы. В последнее время проявляется большая заинтересованность в подобных интерфейсах.
Как отмечалось ранее, функции должны кодироваться путем включения вызовов к СУБД, выраженных на языке запросов. Следовательно, и для “X с поддержкой стабильных данных” также требуются средства выражения на языке запросов. Такие запросы могут быть выражены в нотации, соответствующей специфике языка программирования. Системы времени выполнения должны принимать и обрабатывать такие запросы и доставлять результаты обратно в программу.
Будет создано множество разнообразных “X с поддержкой стабильных данных”. Для каждого из них потребуются свои модификации компилятора и системы времени выполнения. Все системы времени выполнения будут подключены к общей СУБД.68 Очевиден вопрос “Как выражать запросы к этой общей СУБД?”. Ответ дается в следующем предложении.
Предложение 3.3: Хорошо это или плохо, но SQL становится интергалактическим языком данных.
На сегодня SQL предоставляет универсальный способ выражения запросов. При создании первых коммерческих объектно-ориентированных баз данных этот факт не учитывался, и потом пришлось встраивать в продукты запросные системы на основе запросов SQL . К сожалению, многие продукты не дожили до окончания этой работы. Хотя перед SQL и стоит множество мелких проблем, он необходим для коммерческой жизнеспособности. Любая компания-производитель объектно-ориентированных систем баз данных, желающая, чтобы ее продукт оказывал влияние на рынок, должна понять, что покупатели голосуют своими долларами за SQL .
Более того, SQL является разумной кандидатурой для новых функций, предлагаемых в этой работе. Конечно, для некоторых приложений и языков программирования могут оказаться адекватными и другие языки запросов.
Предложение 3.4: Запросы и ответы на них должны образовывать нижний уровень коммуникаций между клиентом и сервером.
В условиях, когда пользователь находится за рабочей станцией и взаимодействует с данными на удаленном сервере, встает вопрос о протоколах взаимодействия рабочей станции и сервера. Энтузиасты ООБД обсуждают, должны ли посылаться запросы на единичные записи, единичные страницы или должен использоваться иной механизм. Точка зрения авторов манифеста крайне проста: выражения на языке запросов должны образовывать нижний уровень коммуникаций. Конечно, если набор запросов можно упаковать в функцию, пользователь может использовать удаленный вызов для выполнения функции на сервере. Эта возможность желательна, поскольку она позволяет обойтись менее чем одним сообщением на запрос.
