Cтандартизация SQL: следующие шаги

В последних нескольких выпусках журнала мы посвящали материалы этой колонки главным образом выяснению смысла слова «стандарт», представлению актуальной информации о состоянии разработки долгожданного стандарта SQL третьего поколения (прежде известного как SQL3, а теперь называемого SQL:1999), а также ознакомлению читателей с двумя из трех частей спецификаций SQLJ.

Состояние стандартов SQL

Прежде, чем перейти к этому, необходимо сделать замечание относительно доступности стандарта SQL:1999. В марте 1999 г. мы сообщили (см. [1]) заголовки частей SQL стандарта, которые предполагалось опубликовать в 1999 г. и указали адреса организаций, в которых можно было бы приобрести документы стандарта. К сожалению, в заголовках каждой из этих частей имелась незначительная, но, вероятно, важная типографская ошибка. Поэтому мы здесь ее исправляем (см. [2-6]). Более того, мы располагаем теперь более точной информацией относительно возможности приобретения копий этих документов.

Многие из Вас несомненно обнаруживали в прошлом, что стандарты были доступны для приобретения только при готовности преодолевать всю скуку общения с бюрократией, владеющей ими, и уплачивать, по всей вероятности, непомерно высокую цену. Например, стандарт SQL-92 можно все еще приобрести (в печатной форме) лишь за 220 долларов! Это, возможно, кажется большой суммой, особенно если Вы - студент или интересуетесь этими материалами в индивидуальном порядке.

Поэтому будет приятно узнать, что теперь можно скачать пять томов документации стандарта SQL:1999 из электронного магазина стандартов ANSI (ANSI?s Electronic Standards Store: http://webstore.ansi.org), а также из электронного магазина NCITS (NCITS? Standards Store: http://www.cssinfo.com/ncits.html) по 20 долларов за каждый том. Эти цены на порядок меньше стоимости печатных копий. Но нужно заметить, что материалы доступны только в формате (PDF). (Печатная копия также доступна из NCITS, но не из ANSI, за «немного более высокую цену» ... около 540 долларов за пять томов!)

Еще одно замечание заключается в том, что ANSI также одобрил принятые ISO/IEC документы в конце 1999 г. Поэтому их можно теперь считать также документами ANSI/ISO/IEC.

Ожидаемые прелести

Процесс стандартизации SQL продолжается уже примерно пятнадцать или шестнадцать лет. За этот период были опубликованы три основных редакции стандарта SQL (и одна с небольшими отличиями¹), а также две дополнительные части: SQL-86, SQL-89, SQL-92, CLI-95, PSM-96, и теперь SQL:1999.

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

Когда пишутся эти строки, разрабатываются некоторые дополнительные части, которые охватывают несколько широко распространенных средств для языка SQL. Самыми близкими к завершению и публикации являются Часть 9, Управление внешними данными (Management of External Data, SQL/MED) и Часть 10, Связывания для объектных языков (Object Language Bindings, SQL/OLB).

Помимо дополнительных частей, можно вносить поправки в опубликованный стандарт путем добавления к нему новых возможностей. Текст таких поправок читается в большой мере подобно тексту дополнительной части, но предполагается, что спецификации этих поправок будут отражены в тексте документа (или документов) по стандарту, которые он улучшает, когда будет выпускаться следующая его (или их) публикация. (Напротив, для дополнительных частей можно ожидать, что при указанных обстоятельствах они будут оставаться отдельными документами.) Первая поправка к SQL:1999 находится в настоящее время в стадии подготовки и называется «Интерактивной аналитической обработкой» (On-Line Analytical Processing, SQL/OLAP).

Давайте теперь рассмотрим каждый из этих трех документов по очереди.

Связывания для объектных языков

К тому времени, когда Вы будет читать эти строки, завершится работа над Частью 10, Связывания для объектных языков (Object Language Bindings, SQL/OLB). SQL/OLB соответствует SQLJ Части 0, которая рассматривалась в статье [7], опубликованной в конце 1998 г. Версия этой спецификации, согласованная с SQL-92 была принята как новая дополнительная часть стандарта ANSI SQL [8] в конце 1998 г. Более или менее одновременно с этим было инициировано международное голосование по Заключительному проекту комитета (Final Committee Draft, FCD²) соответствующей новой дополнительной части стандарта ISO SQL. Голосование по этому FCD завершилось в начале 1999 г. с рядом существенных замечаний. Наиболее важные из них сводились к тому, что необходимо согласовать этот документ не с SQL-92, а с SQL:1999, а также со спецификациями JDBC 2.0, публикация которых тогда предстояла.

Комитет, ответственный за стандартизацию SQL (ISO/IEC JTC1/ SC32/WG3), провел три заседания по вопросам редактирования проекта стандарта, чтобы принять решение по этим замечаниям. Последнее из них состоялось в январе 2000 года в Санта-Фе (штат Нью-Мексико, США). На этом заседании были успешно разрешены вопросы, касающиеся последних замечаний, и участники рекомендовали перейти к стадии голосования по Заключительному проекту международного стандарта (Final Draft International Standard). Это голосование должно завершиться в июне или июле 2000 года). В результате будет опубликована новая часть стандарта SQL:1999, идентифицируемая как ISO/IEC 9075-10:2000.

В нашей статье [7] было подробно рассмотрено техническое содержание этой спецификации, которая стала стандартом ANSI SQL/OLB. Основные технические различия между этим документом и стандартом ISO OLB:2000 полностью связаны с новыми возможностями SQL:1999 и JDBC 2.0. Главными из них являются:

• поддержка позиционируемых (scrollable) и удерживаемых (holdable) курсоров;
• поддержка типов, определяемых пользователем;
• поддержка обновляемых результирующих наборов и пакетных обновлений;
• расширенные средства подключения (connection) и транзакций.

Помимо этих технических усовершенствований, было значительно повышено также редакционное качество документа. Если для Вас представляет интерес, можно найти копию этого (пока еще не законченного и не защищенного авторскими правами) документа по адресу: ftp://jerry.ece.umassd.edu/SC32/WG3/ Progression_Documents/ FCD/fcdi2-olb-1999-11.pdf.

Там же хранятся также копии этого документа в текстовом и Postscript форматах (одноименные файлы с расширениями .ps и .txt).

Управление внешними данными

В течение последних нескольких лет становится все более и более очевидно, что разработчики приложений больше не способны сосредоточить все их усилия на создании новых приложений, в которых для управления данными используются SQL системы базы данных. Им все в большей мере необходимо интегрировать все эти SQL данные с унаследованными ими данными (объем которых, по мнению некоторых экспертов, на порядок превышает количество данных, содержащихся в SQL базах данных!).

Имеется огромное количество данных, которые содержатся в обычных файлах, хранимых на архивных носителях типа магнитных лент, данных в не реляционных базах данных (например, в иерархических типа IMS или сетевых, управляемых системами типа CODASYL или поддерживающих другие «сетевые» модели данных) и даже не сохраняемых данных, генерируемых в реальном масштабе времени разнообразными датчиками. И приложения должны быть способны обращаться ко всем этим данным, используя их вместе для принятия соответствующих деловых решений.

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

Например, компания Oracle предлагает Open Transparent Gateway и те сервисы для неоднородного доступа, которые этот продукт обеспечивает. Компания Sybase поставляет продукт OmniConnect, который поддерживает SQL-доступ ко многим различным источникам данных. IBM предоставляет продукт DataJoiner для обеспечения доступа к традиционным и нетрадиционным данным. Другие поставщики, в том числе и главные поставщики программного обеспечения для баз данных и некоторые более мелкие игроки в этой нише рынка, также предлагают аналогичные программные продукты.

В конце 1998 года в ISO было инициировано голосование по (еще не заключительному) проекту комитета (CD), содержащему новую часть стандарта SQL, которая является ответом на это требование рынка. Эта новая часть 9 называется «Управление внешними данными» (Management of External Data, SQL/MED) и обеспечивает API между SQL-сервером (т.е. некоторой «локальной» SQL системой управления базами данных) и другим объектом, называемым адаптером внешних данных (foreign-data wrapper). Локальный SQL-сервер и этот адаптер обмениваются информацией, которая позволяет локальному SQL-серверу осуществлять выборку и, возможно, вставку, обновление и удаление данных, которые фактически управляются некоторым внешним сервером (foreign server). Функции, обеспечиваемые адаптером внешних данных, заключаются в том, чтобы позволить локальному SQL-серверу интерпретировать данные, управляемые внешним сервером, как если бы это были табличные данные, независимо от того, представлены ли они на самом деле в табличной форме. Следовательно, локальный SQL-сервер имеет дело с внешними таблицами.

Данные, управляемые внешним сервером, могут быть различными не SQL данными, например, плоскими файлами или базами данных системы IMS, но они могут также быть и SQL данными, управляемыми средствами программных продуктов других поставщиков. Локальный SQL-сервер мог бы предпочесть декомпозицию выданного ему клиентским приложением оператора SQL таким образом, чтобы ряд составных частей этого оператора выполнялся бы одним или несколькими адаптерами внешних данных, а другие компоненты выполнялись бы в то же время в локальном режиме. Предоставляя такой «бесшовный» (или в максимально возможной степени «бесшовный») доступ к различным источникам данных, можно наконец обеспечить стандарт для управления неоднородными федеративными базами данных!

Специальная цель SQL/MED состоит в том, чтобы определить открытый интерфейс, позволяющий каждому (неважно, поставщик ли это существующих SQL-систем или какой-либо предприниматель, понимающий характеристики некоторого источника данных, необходимых приложению) создавать адаптеры внешних данных, которые могут распространяться в «упакованной» (shrink-wrappered) форме таким образом, чтобы они работали с любой системой SQL баз данных (конечно же, на заданной аппаратной и операционной платформе) и обеспечивали бы SQL-интерфейс для других источников данных. Мы полагаем, что благодаря созданию рынка таких интерфейсов способность приложений осуществлять доступ к данным, хранимым в любом формате, будет значительно повышаться. При этом плата будет значительно более низкой, чем та, с которой сталкиваются разработчики приложений в настоящее время.

Разработка SQL/MED стала полезной, главным образом, благодаря новому духу сотрудничества среди поставщиков SQL-продуктов, особенно в Соединенных Штатах. Хотя все мы по-прежнему энергично конкурируем друг с другом, мы делаем нечто прежде необычное в стандартизации баз данных - работаем вместе над созданием новых возможностей языка SQL, которые бы удовлетворяли требованиям всех поставщиков и, следовательно, (мы твердо уверены) - более широкого сообщества пользователей. Представляется, что такого рода сотрудничество приведет в результате к разработке стандартизированных возможностей, которые будут фактически реализованы взамен многочисленных средств, многие из которых представляют интерес только для какого-либо отдельного поставщика, и которые, как казалось, были ранее результативными.

Голосование проекта комитета по SQL/MED вызвало очень большое количество замечаний, которые были преодолены в ходе ряда редакционных заседаний, состоявшихся в течение 1999 г. Предложения по устранению этих замечаний привели в результате к созданию пересмотренного документа по SQL/MED, который был предложен для голосования в статусе заключительного проекта комитета в начале 2000 г. Предполагается, что в процессе этого голосования будет получено значительное количество дополнительных замечаний. Позднее в 2000 г. состоятся редакционные заседания для их обсуждения. Цель заключается в том, чтобы опубликовать SQL/MED как международный стандарт ISO/IEC 9075 9:2001 в 2001 г.

Заинтересованные лица могут найти копию этого (пока еще не законченного и не защищенного авторскими правами) документа по адресу: ftp://jerry.ece.umassd.edu/SC32/WG3/ Progression_Documents/ FCD/fcd1-med-1999-11.pdf.

Там же хранятся также копии этого документа в текстовом и Postscript форматах (одноименные файлы с расширениями .ps и .txt).

Интерактивная аналитическая обработка

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

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

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

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

Весьма тесное сотрудничество между поставщиками продуктов SQL, о котором шла речь при рассмотрении SQL/MED, как представляется, даже в большей мере имеет место в разработке SQL/OLAP. IBM и Oracle особенно настойчиво поддерживали необходимость разработки предложений по изменениям, которые бы удовлетворяли самый широкий диапазон требований к аналитическим и статистическим инструментальным средствам. Другие же поставщики, например, Informix и Microsoft, активно принимали участие в разработке и рецензировании предложений. Результат представляет собой элегантную спецификацию нового синтаксиса и семантики языка SQL, которые вместе были созданы удивительно быстро.

Фактически голосование по предложенному заключительному проекту поправки (Final Proposed Draft Amendment, FPDAM) к SQL/OLAP было инициировано в начале 2000 г. Поскольку качество представленного для голосования документа - относительно высокое, можно предположить, что потребуется не более одного редакционного заседания, и последующее голосование по заключительному проекту поправки должно завершиться публикацией SQL/OLAP несколько позднее в 2000 г. как документа ISO/IEC 9075-1/AMD1:2000. Этот заголовок еще не окончательный, но он должен быть примерно таким: Amendment 1 to ISO/IEC 9075-1:1999, ISO/IEC 9075-1:1999, On-Line Analytical Processing (SQL/OLAP). Кстати, этот документ вносит поправки в несколько частей SQL:1999, и поэтому было бы вполне уместно рассматривать его как поправку к части 1, SQL/Framework.

SQL/OLAP включает несколько инструментальных средств, широко используемых в анализе данных. Прежде всего, он содержит ряд новых числовых функций, например: LN (натуральный алгоритм заданного аргумента); EXP (возводит e в степень аргумента); POWER (возводит один аргумент в степень, указываемую другим аргументом); SQRT (извлекает квадратный корень из аргумента); FLOOR и CEILING (возвращает наибольшее целое, не превышающее значения аргумента, и наименьшее целое, большее или равное значению аргумента); функцию ранжирования (возвращает ранжирование аргумента на мультимножестве значений), а также функцию процентиля (возвращает ранжирование аргумента как значения его процентилей на мультимножестве значений).

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

Хотя эти функции необходимы, они становятся значительно более мощными благодаря введению понятия окон для SQL. Окно - это некоторая выборка строк в (виртуальной) таблице, определенной либо путем группирования всех строк этой таблицы таким образом, чтобы в одну группу попали строки, которые имеют общие значения в определенном столбце или наборе столбцов, либо путем группирования строк на основе их близости к идентифицированной строке (указанное число строк, предшествующих данной строке и следующих за ней, или указанное число групп строк, связанных по значениям в некоторых столбцах). Для аналитических целей часто желательно исключать из окна идентифицированную строку или даже исключать все строки, которые имеют с идентифицированной строкой общие значения в идентифицированных столбцах. Поэтому SQL/OLAP обеспечивает синтаксис для таких исключений.

Неожиданный полезный эффект SQL/OLAP заключается в том, что он оказывает влияние на обычные операции SQL с курсором. Давнишние пользователи SQL должны знать, что предложение ORDER BY для SQL курсора сортирует строки на основе значений столбцов или выражений, специфицированных в этом предложении. При этом строки, для которых столбцы или результаты вычисления выражений имеют неопределенное значение, оказываются все после сортировки или в начале результата или в конце результата. В различных реализациях этот выбор между началом и концом может различаться.

Поскольку существует потребность управлять интерпретацией неопределенных значений для целей OLAP, в SQL/OLAP предусматриваются синтаксические конструкции, которые позволяют приложению специфицировать, где должны в результате сортировки оказаться неопределенные значения: NULL FIRST (НЕОПРЕДЕЛЕННЫЕ ЗНАЧЕНИЯ СНАЧАЛА) и NULL LAST (НЕОПРЕДЕЛЕННЫЕ ЗНАЧЕНИЯ В КОНЦЕ). Этот новый синтаксис был добавлен к обычным спецификациям курсора, и поэтому приложения могут управлять рассматриваемым аспектом упорядочения их курсоров.

Копию рассматриваемого документа (пока еще не законченного и не защищенного авторскими правами) можно найти по адресу: ftp://jerry.ece.umassd.edu/SC32/WG3/ Progression_Documents/ FPDAM/fpdam-olap-1999-11.pdf.

Там же хранятся также копии этого документа в текстовом и Postscript форматах (одноименные файлы с расширениями .ps и .txt).

Теперь о времени

Этот заголовок - своего рода каламбур, поскольку мы будем еще обсуждать затрагиваемую здесь тему в будущих публикациях колонки стандартов.

Несколько лет назад начались работы над другой дополнительной частью SQL - частью 7, которая кратко называется SQL/Temporal. Для тех, кто не использовал подобную терминологию, поясним, что временные данные - это то, что позволяет Вам позвонить в Ваш банк, выразить неудовольствие относительно отсутствия контрольной выписки из вашего счета с июля 1998 г. и фактически получить потерянную выписку по почте несколько дней спустя. Иными словами, они позволяют Вам «путешествовать во времени» в вашей базе данных. К сожалению, Вы можете перемещаться во времени только в обратном направлении. У нас нет такой технологии, которая бы давала возможность обрабатывать запросы в системе базы данных, чтобы выяснить, что «происходило» с фондовым рынком в 2010 г.!

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

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

Работа над SQL/Temporal затормозилась уже три года назад по трем причинам. Во-первых, не проявляли большого энтузиазма поставщики продуктов SQL - или, в действительности, их заказчики - в вопросе о включении средств поддержки временных данных в механизмы систем управления базами данных. Во-вторых, специалисты, занимающиеся стандартами SQL были вынуждены сконцентрироваться на завершении проекта SQL3 (отчасти потому, что они потребовали намного больше времени и оказались намного более трудными, чем ожидалось) и избегать отвлечения сил для работы над проектом, на который, по-видимому, не было большого спроса со стороны рынка. Наконец, имеется фундаментальное расхождение между двумя лагерями относительно того, какие в точности возможности должен предоставлять SQL/Temporal и каким образом эти возможности следует обеспечивать (т.е., и синтаксис и семантика).

Когда разработка SQL3 подошла к завершению, результатом которого должна была стать публикация SQL:1999, участники работы выяснили, что рынок проявляет все более возрастающую информированность относительно преимуществ поддержки временных данных и, по крайней мере, некоторые из поставщиков продуктов SQL стали интересоваться этой проблемой. Поэтому работы над SQL/Temporal недавно начали возрождаться, и можно надеяться увидеть публикацию этой дополнительной части стандарта SQL, вероятно, в течение 2002-2003 гг.

Перетасовка бумаг

В заключение лишь из соображений точности следует обратить внимание на изменения в совокупности частей, составляющих стандарт SQL. Части, указанные в [2-6], составляют SQL:1999. Однако, часть 5 (SQL/Bindings) значительно более тесно связана с частью 2 (SQL/Foundation), чем мы предполагали. В результате добавление любых новых возможностей к языку - или, в действительности, понимание языка в том виде, как он опубликован - очень часто потребует рассмотрения одновременно обоих документов. Иначе говоря, мы осознали ... , но довольно поздно ..., что материал из SQL/Bindings должен в действительности быть интегрирован в SQL/Foundation.

Напротив, спецификация представлений (view) и базовых таблиц Информационной схемы и Схемы определения, в настоящее время составляющая раздел части SQL/Foundation, легко отделяется и редко должна рассматриваться одновременно с изучением или добавлением некоторой возможности к языку SQL. Таким образом, этот материал можно было бы легко выделить в отдельный другой документ.

Поэтому в спецификациях следующего поколения стандарта SQL (который мы называем «SQL:200n», а не «SQL4»!), часть 5 будет исключена, а ее содержание объединено с SQL/Foundation. Будет учреждена также новая часть 11, SQL/Schemata, которая содержит спецификации Информационной схемы и Схемы определения, выделенные из SQL/Foundation.

Резюме

В таблице показаны ожидаемые сроки завершения рассмотренных «следующих шагов».

Совершенно очевидно, что стандартизация SQL отнюдь не завершена - ни в коем случае. Хотя SQL:1999 обладает многочисленными возможностями, которые уже широко реализованы (и немалое число из которых в то же время представляется в малой степени полезными, хотя они и реализованы более чем одним поставщиком), рынок продолжает предъявлять новые и стимулирующие требования к поставщикам и их способностям поставлять программные продукты. Поставщики также продолжают искать новые и привлекательные способы конкурировать друг с другом, предлагая своим заказчикам полезные новые возможности. По мере того, как возникает необходимость в новых возможностях, осуществляется их рассмотрение и доказывается их полезность широкому сообществу, они будут становиться предметом для дополнительной работы по стандартизации.

Будет ли когда-либо «завершен» SQL? Конечно! Каждый язык (даже КОБОЛ) в итоге исчерпывает свою полезность. SQL от них ничем не отличается. Но сегодня не видно чего-либо на горизонте (даже XML и его спутники, подобные языку XML Query), что позволяло бы решать те же самые проблемы, которые решает SQL, и делать это настолько же хорошо, как и SQL.

До тех пор, пока не изменятся потребности или радикальным образом не изменятся доступные технологии, мы полагаем, что SQL продолжит быть (как назвал его Майкл Стоунбрекер) «межгалактическим языком данных («Intergalactic Dataspeak»). И ... стандарт SQL будет, вероятно, продолжать развиваться и совершенствоваться.

Andrew Eisenberg (Progress Software), Jim Melton (Oracle). SQL Standardization: The Next Steps. SIGMOD Record, Vol. 29, No. 1, March 2000. Пер. с англ. М.Р. Когаловского.

¹ Имеется в виду версия стандарта SQL-89, которая отличается от предшествующей, главным образом, введением поддержки ограничений целостности по ссылкам. - Прим. пер.

² В соответствии с регламентом деятельности ISO, процедура разработки международных стандартов предусматривает несколько стадий, каждая из которых заключается в подготовке очередной версии документа или комплекта документов, содержащих спецификации проекта стандарта. После подготовки некоторой версии проекта по ней в течение установленного срока проводится голосование (рассмотрение) среди определенного круга экспертов, высказывающих свои замечания. Для принятия решений по этим замечаниям и внесения необходимых поправок в текст проекта созываются редакционные заседания подразделения ISO, ответственного за разработку стандарта. Серия документов, рождающихся в процессе разработки спецификаций стандарта, включает (в порядке их создания): Рабочий проект (Working Draft, WD), Проект комитета (Committee Draft, CD), Заключительный проект комитета (Final Committee Draft, FCD), Проект международного стандарта (Draft Internetional Standard, DIS), Заключительный проект международного стандарта (Final Draft International Standard, FDIS) и , наконец, Международный стандарт (International Standard, IS). - Прим. пер.

Литература

[1] Eisenberg A., Melton J. SQL:1999 early known as SQL3. SIGMOD Record, Vol. 28, No. 1, 1999. Есть русск. пер.: Эйзенберг Э., Мелтон Дж. SQL:1999, ранее известный как SQL3. Открытые системы, 1, 1999, с. 52-57.

[2] ISO/IEC 9075-1:1999, Information technology - Database language - SQL - Part 1: Framework (SQL/Framework), 1999.

[3] ISO/IEC 9075-2:1999, Information technology - Database language - SQL - Part 2: Foundation (SQL/Foundation), 1999.

[4] ISO/IEC 9075-3:1999, Information technology - Database language - SQL - Part 3: Call-Level Interface (SQL/CLI), 1999.

[5] ISO/IEC 9075-4:1999, Information technology - Database language - SQL - Part 4: Persistent Stored Modules (SQL/PSM), 1999.

[6] ISO/IEC 9075-5:1999, Information technology - Database language - SQL - Part 5: Host Language Bindings (SQL/Bindings), 1999.

[7] Eisenberg A., Melton J. SQLJ Part 0, now known as SQL/OLB (Object-Language Bindings). SIGMOD Record, Vol. 27, No. 4, December 1998. Есть русск. пер.: Э. Эйзенберг, Д. Мелтон. SQLJ Часть 0, называемая теперь SQL/OLB (связывания для объектных языков). Открытые системы, 4, 1999.

[8] ANSI X3.135.10-1998, Information Systems - Database Languages - SQL - Part 10: Object Language Bindings (SQL/OLB), 1998.