А. Эйзенберг, Дж. Мелтон
Уже несколько лет вы слышите и читаете о грядущем стандарте, который все называют SQL3. Предназначенный для того, чтобы стать существенной модернизацией текущего стандарта языка SQL второго поколения, повсеместно называемого SQL-92 в соответствии с годом публикации, SQL3 первоначально планировался к выпуску в 1996 г. ... но дела шли не так, как планировалось.
Возможно, вы знаете, что SQL3 характеризуется как "объектно-ориентированный SQL" и является основой нескольких объектно-реляционных систем управления базами данных (включая, среди прочих, ORACLE8 компании Oracle, Universal Server компании Informix, DB2 Universal Database компании IBM и Cloudscape компании Cloudscape). Широко распространена точка зрения, что это хорошо, но имеется и обратная сторона: работа заняла около семи лет, вместо планировавшихся трех-четырех.
Как мы покажем, SQL:1999 означает намного больше, чем просто SQL-92 плюс объектная технология. Он включает дополнительные средства, которые мы считаем соответствующими наследию SQL, а также структура самих документов стандарта полностью пересмотрена в соответствии со стремлением добиться более эффективной работы в области стандартизации в будущем.
Двумя юридически признанными организациями, активно вовлеченными в процесс стандартизации SQL и тем самым разработки SQL:1999, являются ANSI и ISO.
Более точно, международное сообщество работает через ISO/IEC JTC1 (Joint Technical Committee 1), комитет, сформированные Международной организацией по стандартизации совместно с Международной электротехнической комиссией. В сферу ответственности JTC1 входит разработка и поддержка стандартов, связанных с информационными технологиями. Внутри JTC1 недавно был образован подкомитет CS32, названный Data Management and Interchange (управление и обмен данными), чтобы принять дела в связи с несколькими стандартами, связанными с базами данных и метаданными и разработанными другими организациями (такими, как распущенным подкомитетом SC21). В свою очередь, CS32 сформировал ряд рабочих групп для реального выполнения технической работы - WG3 (языки баз данных) отвечает за стандарт SQL3, а WG4 развивает SQL/MM (SQL Multi-Media, набор стандартов, определяющих библиотеки типов с использованием объектно-ориентированных средств SQL3).
В Соединенных Штатах стандарты IT находятся в ведении аккредитованного при ANSI комитета NCITS (National Committee for Information Technology Standardization), ранее называвшегося просто "X3". Технический комитет NCITS H2 (раньше "X3H2") отвечает за несколько стандартов, связанных с управлением данными, включая SQL и SQL/MM.
Когда был разработан SQL первого поколения (SQL-86 и его незначительное развитие SQL-89), большая - а возможно, и основная -- часть работы была выполнена в США в X3H2, а остальные страны широко участвовали в работе в режиме обзоров и критики предложений ANSI. Но ко времени опубликования SQL-89 международное сообщество начало очень активно действовать в написании предложений для спецификации того, что стало SQL-92; ситуация не изменилась во время разработки SQL:1999, и мы надеемся, что не изменится и в будущем -- SQL - это действительно совместная международная работа.
Некоторых пояснений требуют неформальные названия, которые мы применяем к разным редакциям стандарта SQL. Первые версии стандарта широко известны под названиями SQL-86 (или SQL-87, поскольку версия ISO не публиковалась до начала 1987 г.), SQL-89 и SQL-92, в то время версию, разработка которой сейчас завершается, следует называть SQL:1999. Откуда это отличие? … почему не "SQL-99"? Просто потому, что мы должны начать думать о том, как будет называться следующее поколение, и "SQL-02" вполне можно спутать с "SQL2" (название проекта, в рамках которого разрабатывался SQL-92) … не принимая во внимание тот факт, что "02" на самом деле не больше "99". Другими словами, мы не хотим, чтобы название стандарта SQL страдало от проблемы 2000-го года!
При наличии приведенной исходной информации самое время дать обзор реального содержания SQL:1999. Хотя мы понимаем, что большинство читателей этого раздела не знает точного содержания даже SQL-92, ограничения на объем статьи не позволяют нам представить полный набор свойств SQL:1999. Поэтому мы собираемся ограничить свой обзор теми свойствами, которые являются новыми в этом самом современном поколении стандарта SQL.
Свойства SQL:1999 можно грубо разделить на "реляционные" и "объектно-ориентированные". Для удобства мы опишем их в такой последовательности.
Хотя мы называем эту категорию свойств "реляционными", вы быстро поймете, что их более правильно характеризовать как "свойства, связанные с традиционной ролью и моделью данных SQL" … в чем-то менее сильная фраза. Эти свойства не ограничены строго реляционной моделью, но также не связаны с объектной ориентацией.
Часто эти свойства разбиваются примерно на пять групп: новые типы данных, новые предикаты, улучшенная семантика, дополнительная безопасность и активная база данных. Мы рассмотрим их по порядку.
В SQL:1999 имеется четыре новых типа данных (хотя для одного из них имеются некоторые опознаваемые варианты). Первым из этих типов является тип LARGE OBJECT, или LOB. Это тип с вариантами: CHARACTER LARGE OBJECT (CLOB) и BINARY LARGE OBJECT (BLOB). CLOB'ы ведут себя во многом подобно символьным строкам, но ограничены тем, что запрещено их использование в предикатах PRIMARY KEY и UNIQUE, в FOREIGN KEY, а также в сравнениях, отличных от чистых равенства или неравенства. Для BLOB'ов действуют аналогичные ограничения. (Косвенным образом, LOB'ы нельзя также использовать в разделах GROUP BY и ORDER BY.) Обычно приложениям не требуется пересылать весь LOB целиком в базу данных и из базы данных (конечно, после исходного их размещения); следует манипулировать LOB-значениями через специальный тип на стороне клиента, называемый LOB-локатором. В SQL:1999 локатор - это уникальное двоичное значение, которое действует как вид суррогата значения, сохраняемого в базе данных; локаторы могут использоваться в операциях (таких, как SUBSTRING) без привлечения накладных расходов для пересылки всего LOB-значения через интерфейс клиента и сервера.
Другим новым типом является тип BOOLEAN, который дает возможность в SQL непосредственно записывать истинностные значения true, false и unknown. Сложные комбинации предикатов можно также выразить способами, которые в чем-то более дружественны к пользователям, чем этого можно добиться обычными методами реструктуризации:
WHERE COL1 > COL2 AND
COL3 = COL4 OR
UNIQUE (COL6) IS NOT FALSE
В SQL:1999 имеются также два новых составных типа: ARRAY и ROW. Тип ARRAY позволяет хранить коллекции данных непосредственно в столбце таблицы базы данных. Например, определение
WEEKDAYS VARCHAR (10) ARRAY[7]
позволило бы хранить названия всех семи дней недели в одной строке базы данных. Означает ли это, что SQL:1999 допускает базы данных, не удовлетворяющие первой нормальной форме? Действительно, допускает, в том смысле, что разрешаются "повторяющиеся группы", запрещаемые первой нормальной формой. (Однако некоторые утверждают, что тип ARRAY в SQL:1999 всего лишь допускает хранение информации, которую можно декомпозировать, во многом подобно тому, как функция SUBSTRING может декомпозировать символьные строки -- и поэтому в действительности не противоречит духу первой нормальной формы.)
Тип ROW в SQL:1999 является расширением (анонимного) строчного типа, который всегда был в SQL и от наличия которого язык зависел. Этот тип обеспечивает разработчиков баз данных дополнительной возможностью хранения структурированных значений в одном столбце базы данных:
CREATE TABLE employee (
EMP_ID INTEGER,
NAME ROW (
GIVEN VARCHAR (30),
FAMILY VARCHAR (30) ),
ADDRESS ROW (
STREET VARCHAR (50),
CITY VARCHAR (30),
STATE CHAR (2) ),
SALARY REAL )
SELECT E.NAME.FAMILY
FROM employee E
Хотя можно было бы утверждать, что здесь также нарушается первая нормальная форма, многие считают, что это всего лишь еще один "декомпозируемый" тип данных.
В SQL:1999 добавлена еще одна связанная с типами данных возможность, называемая "индивидуальными типами" (distinct types). Учитывая, что в общем случае маловероятно, что в приложении потребуется непосредственно сравнивать, например, размер обуви служащего со значением его или ее IQ, программистам SQL позволяется объявить типы SHOE_SIZE и IQ, основанные на INTEGER, и запрещается непосредственное перемешивание этих двух типов в выражениях. Так, выражение вида
WHERE MY_SHOE_SIZE > MY_IQ
(где имя переменной соответствует ее типу данных) было бы опознано как синтаксическая ошибка. Каждый из этих двух типов может быть "представлен" как INTEGER, но SQL не разрешает перемешивать их в выражениях -- и не один из них не допускает, скажем, умножения на INTERGER:
SET MY_IQ = MY_IQ * 2
Взамен этого в программах должно явно выражаться продуманное намерение допускать такое смешение:
WHERE MY_SHOE_SIZE > CAST (MY_IQ AS SHOE_SIZE) SET MY_IQ = MY_IQ * CAST (2 AS IQ)
В дополнение к этим типам в SQL:1999 также введены определяемые пользователями типы, но они попадают в список объектно-ориентированных свойств.
В SQL:1999 имеются три новых предиката, один из которых мы будем рассматривать среди объектно-ориентированных свойств. Другими двумя являются предикат SIMILAR и DISTINCT.
С первой версии стандарта SQL поиск через символьные строки был ограничен очень простыми сравнениями (типа =, > или <>) и довольно рудиментарными возможностями сопоставления с образцами предиката LIKE:
WHERE NAME LIKE '%SMIT_'
В данном случае значения столбца NAME сопоставляются со значениями, включающими ноль или более символов перед четырьмя символами 'SMIT' и в точности один символ за ними (такими, как SMITH или HAMMERSMITS).
В связи с пониманием того, что приложениям часто требуются более усложненные возможности, которые, тем не менее, не совпадают с полным набором операций над текстами, в SQL:1999 был введен предикат SIMILAR, где в образцах сопоставления можно использовать регулярные выражения в стиле UNIX. Например:
WHERE NAME SIMILAR TO ' (SQL- (86|89|92|99) ) | (SQL (1|2|3))'
Этот предикат произвел бы сопоставление образца с различными названиями, присваивавшимися когда-либо стандарту SQL. Слегка неудачно то, что регулярные выражения, используемые в предикате SIMILAR, не совсем следуют синтаксису регулярных выражений UNIX, но некоторые символы UNIX уже используются в SQL для других целей.
Другой новый предикат DISTINCT очень похож по своему действию на обычный предикат SQL UNIQUE; важным отличием является то, что два неопределенных значения считаются неравными одно другому и поэтому удовлетворяют предикату UNIQUE, но это желательно не для всех приложений. Предикат DISTINCT рассматривает два неопределенных значения как неотличающиеся одно от другого (хотя, конечно, они не являются равными и в то же время не являются неравными), и поэтому два неопределенных значения не удовлетворяют предикату DISTINCT.
Трудно точно провести грань, говоря о новой семантике SQL:1999, но мы приведем краткий перечень того, что мы считаем наиболее важными поведенческими аспектами языка.
В течение долгого времени разработчики приложений испытывали потребность в допущении операций обновления к более широкому классу представлений. Во многих средах представления активно использовались как механизм безопасности и/или средство упрощения взгляда на базу данных со стороны приложения. Однако, если большая часть представлений не допускает операций обновления, то эти приложения часто вынуждаются "отстраниться" от механизма представлений и полагаться на прямое обновления определяющих базовых таблиц; эта ситуация весьма неудовлетворительна.
В SQL:1999 существенно расширен диапазон представлений, над которыми напрямую могут выполняться операции обновления с использованием только средств, обеспечиваемых стандартом. Этот диапазон сильно зависит от функциональных зависимостей для определения того, к каким дополнительным представлениям могут применяться операции обновления, и того, как изменять данные определяющих базовых таблиц при выполнении операций обновления представлений.
Другим широко порицаемым недостатком SQL является невозможность выполнения рекурсии для приложения типа обработки инвентарных ведомостей. Для удовлетворения этой категории требований SQL:1999 обеспечивает средство, называемое рекурсивными запросами. Написание рекурсивного запроса вовлекает написание выражения запроса, которое вы хотите включить в рекурсию и присвоение ему имени, а затем использование этого имени в соответствующем выражении запроса:
WITH RECURSIVE
Q1 AS SELECT … FROM … WHERE …,
Q2 AS SELECT … FROM … WHERE …
SELECT … FROM Q1, Q2 WHERE …
Мы уже упоминали локаторы как значение на стороне клиента, которое может представлять LOB-значение, хранимое на стороне сервера. Таким же образом локаторы могут быть использованы для представления ARRAY-значений, если принять во внимание тот факт, что (подобно LOB'ам) ARRAY-значение часто может быть слишком велико, чтобы обычным образом передаваться между приложением и базой данных. Локаторы также могут использоваться для представления значений определяемых пользователем типов -- обсуждаемых далее -- которые тоже могут потенциально быть большими и громоздкими.
Наконец, в SQL:1999 добавлено понятие точек сохранения (savepoints), реализованных во многих приложениях. Точка сохранения немного похожа на подтранзакцию в том смысле, что приложение может выполнить откат действий, выполненных после начала точки сохранения, не откатывая все действия транзакции целиком. SQL:1999 допускает выполнение операций ROLLBACK TO SAVEPOINT и RELEASE SAVEPOINT, которыет во многом действуют подобно фиксации подтранзакции.
Новым средством безопасности SQL:1999 основано на понятии роли (role). Привилегии могут предоставляться ролям таким же образом, как если бы они были индивидуальными идентификаторами авторизации, и роли могут предоставляться идентификаторам авторизации и другим ролям. Эта вложенная структура может в громадной степени упростить зачастую трудную работу управления безопасностью в среде баз данных.
В последние несколько лет роли реализованы во многих SQL-продуктах (хотя иногда под другими названиями); в конце концов роли попали и в стандарт.
В стандарте SQL:1999 отдается должное активным базам данных, хотя и на несколько лет позже появления их реализаций. Эта возможность обеспечивается через средство, называемое триггерами (triggers). Как известно многим читателям, триггер - это предоставляемое разработчикам базы данных средство заставить систему баз данных выполнять некоторые операции каждый раз, когда приложение запрашивает выполнение определенных операций над указанными таблицами.
Например, триггеры можно использовать для журнализации всех операций, которые изменяют значение заработной платы в таблице служащих:
CREATE TRIGGER log_salupdate
BEFORE UPDATE OF salary
ON employees
REFERENCING OLD ROW as oldrow
NEW ROW as newrow
FOR EACH ROW
INSERT INTO log_table
VALUES (CURRENT_USER,
oldrow.salary,
newrow.salary)
Триггеры могут использоваться для многих целей, не только для журнализации. Например, можно написать триггеры для балансировки бюджета путем сокращения капиталовложений при найме новых служащих … и возбуждения исключительной ситуации, если денежных средств для этого недостаточно.
В дополнение к более традиционным возможностям SQL, обсуждавшимся до сих пор, разработка SQL:1999 была в большой степени ориентирована -- некоторые наблюдатели сказали бы, что в слишком большой степени -- на добавление в язык поддержки объектно-ориентированных концепций.
Некоторые из возможностей, относящихся к этой категории, были впервые определены в стандарте SQL/PSM, опубликованном в конце 1996 г. -- конкретно, поддержка функций и процедур, вызываемых из операторов SQL. В SQL:1999 это средство, называемое вызываемыми из SQL подпрограммами, развивается за счет добавления третьего класса подпрограмм, именумых методами, к рассмотрению которых мы скоро перейдем. Мы не хотели бы копаться здесь в вызываемых из SQL функциях и процедурах, и отсылаем читателей к более раннему выпуску SIGMOD Record [6].
Наиболее фундаментальным средством SQL:1999, поддерживающим объектную ориентацию, являются структурные определяемые пользователями типы; слово "структурный" отличает это средство от индивидуальных типов (которые тоже являются "определяемыми пользователями" типами, но в SQL:1999 могут базироваться только на встроенных типах SQL и поэтому не могут иметь ассоциированных с ними структур).
Структурные типы имеют ряд характеристик, наиболее важными из которых являются следующие:
Посмотрим на пример определения структурного типа:
CREATE TYPE emp_type
UNDER person_type
AS ( EMP_ID INTEGER,
SALARY REAL )
INSTANIABLE
NOT FINAL
REF ( EMP_ID )
INSTANCE METHOD
GIVE_RAISE
( ABS_OR_PCT BOOLEAN,
AMOUNT REAL )
RETURNS REAL
Этот новый тип является подтипом другого структурного типа, который можно было бы использовать для определения людей вообще, включая такие общие атрибуты как имя и адрес; новые атрибуты типа emp_type включают такие вещи, которые нехарактерны для "простых пожилых людей", такие как идентификатор служащего и размер заработной платы. Мы объявляем, что этот тип немедленно пригоден для прямого использования (instantiable) и ему разрешается иметь подтипы (NOT FINAL). Дополнительно к этому мы говорим, что любая ссылка на этот тип (см. ниже обсуждение REF-типов) порождаются из значений идентификаторов служащих. Наконец, мы определяем метод (подробнее об этом ниже), который может быть применен к экземплярам этого типа (его значениям).
После интенсивного флирта с множественным наследованием (когда у подтипов допускается наличие более одного непосредственного супертипа) теперь в SQL:1999 обеспечивается модель типов, тесно соответствующая одиночному наследованию в языке Java. При определении типа разрешается указать либо, что тип является пригодным для немедленного использования (другими словами, что могут создаваться значения этого типа), либо, что тип непригоден для немедленного использования (аналогично абстрактным типам в других языках программирования). И естественно, в любом месте -- например, в столбце -- где допускается появление значения некоторого структурного типа, может появиться и значение любого из его подтипов; это обеспечивает в точности тот тип заменяемости, который свойственен объектно-ориентированным программам.
Кстати, в некоторых объектно-ориентированных языках программирования, таких, как C++, при определении типа допускается спецификация степени инкапсуляции типа: уровень инкапсуляции атрибута PUBLIC означает, что любой пользователь этого типа может иметь доступ к атрибуту, PRIVATE означает, что к атрибуту может иметь доступ только тот программный код, который реализует методы типа, и PROTECTED означает, что к атрибуту могут иметь доступ только методы типа и методы любых его подтипов. В SQL:1999 этот механизм отсутствует, хотя предпринимались попытки его определить; мы ожидаем предложений по поводу этого механизма для будущего пересмотра стандарта.
В SQL:1999 проводится важное различие между "обычным" вызываемыми из SQL функциями и вызываемыми из SQL методами. Коротко говоря, метод - это функция с несколькими ограничениями и усилениями. Коротко охарактеризуем различия между этими двумя типами подпрограмм:
И функции, и методы могут быть написаны на SQL (с использованием вычислительно полных операторов SQL/PSM) или на любом из нескольких более традиционных языков программирования, включая Java.
Доступ к атрибутам определяемых пользователем типов может быть произведен с использованием одной из двух нотаций. Во многих ситуациях приложения могут выглядеть более естественно при использовании "точечной нотации":
WHERE emp.salary > 10000
а в других ситуациях может быть более естественной функциональная нотация:
WHERE salary (emp) > 10000
В SQL:1999 поддерживаются обе нотации; в действительности, они определяются как синтаксические вариации одного и того же -- если "emp" является сущностью хранения (например, столбцом или переменной) с объявленным типом некоторого структурного типа с атрибутом, именуемым "salary" … или существует функция с именем "salary" с единственным аргументом, тип данных которого является (соответствующим) структурному типу данных emp.
В этому случае методы являются немного менее гибкими, чем функции: Для вызовов методом может использоваться только точечная нотация -- по крайней мере, для целей указания особого аргумента. Если метод salary был бы методом, тесно связанным с типом, скажем, employee, который, в свою очередь, был бы объявленным типом столбца emp, то метод можно было бы вызвать только с использованием конструкции
emp.salary
В другом методе, скажем, give_raise, могут комбинироваться точечная и функциональная нотации:
emp.give_raise (amount)
Внимательные читатели заметят, что до сих пор мы избегали использования слова "объект" в своем описании структурных типов. Это потому, что в духе некоторых характеристик, таких как иерархии типов, инкапсуляция и т.д., экземпляры структурных типов SQL:1999 являются просто значениями, подобно экземплярам встроенных типов языка. Конечно, значение employee гораздо более сложное (по представлению и по поведению), чем экземпляр INTEGER, но это всего лишь значение без какой-либо идентификации, кроме той, которая обеспечивается значением экземпляра.
Чтобы получить незначительную характеристику, которая позволила бы SQL обеспечивать объекты, требуется наличие некоторой разновидности идентификации, которую можно применять в разных ситуациях. В SQL:1999 эта возможность обеспечивается за счет того, что разработчикам базы данных разрешается указывать, что некоторые таблицы определяются как "типизированные таблицы" … т.е. их определения столбцов порождаются из атрибутов структурного типа:
CREATE TABLE empls OF employee
Такие таблицы содержат один столбец для каждого атрибута определяющего структурного типа. Функции, методы и процедуры, определенные для оперирования экземплярами типа, теперь применимы к строкам таблицы! Тогда строки таблицы являются значениями -- или экземплярами -- типа. Каждой строке присваивается уникальный идентификатор, который ведет себя подобно OID (идентификатор объекта) … он уникален в пространстве (т.е. внутри базы данных) и во времени (жизни базы данных).
SQL:1999 обеспечивает специальный тип, называемый REF-типом, значениями которого являются уникальные идентификаторы. Данный REF-тип всегда ассоциируется в указанным структурным типом. Например, если мы собирались определить таблицу, содержащую столбец с именем "manager", значения которого являются ссылками на строки типизированной таблицы служащих, то это выглядело бы подобно следующему:
manager REF (emp_type)
Значение типа REF либо идентифицирует строку типизированной таблицы (конечно, конкретного структурного типа), либо не идентифицирует вообще ничего -- что могло бы означать "никуда не указывающую ссылку", оставшуюся после удаления строки, которая идентифицировалась этой ссылкой.
Все типы REF обладают "областью видимости", так что таблица, на которую они ссылаются, известна во время компиляции. При разработке SQL:1999 предпринимались усилия для того, чтобы придать типам REF более общий характер (чтобы, например, в область видимости могли попадать несколько таблиц или чтобы любая таблица соответствующего структурного типа могла бы содержаться в области видимости, даже если эта таблица была создана после создания REF-типа), но были обнаружены некоторые проблемы, которые не удавалось разрешить без дальнейшего откладывания публикации стандарта, поэтому эти ограничения были приняты. Один из побочных эффектов ограничения, возможно, являющимся благотворным, состоит в том, что REF-типы теперь ведут себя во многом подобно ссылочным ограничениям, что может облегчить реализацию этого средства в некоторых продуктах!
Вам не следует удивляться тому, что REF-типы можно использовать немного более сложным способом, чем только хранить и выбирать их значения.
В SQL:1999 обеспечивается синтаксис для "перехода по ссылке" для доступа к атрибутам значения структурного типа:
SELECT emps.manager -> last_name
Указательная нотация (->) применяется к значению некоторого REF-типа и позволяет затем "перейти" к идентифицируемому значению ассоциированного структурного типа -- которое, конечно, является строкой типизированной таблиц, входящей в область видимости REF-типа. Этот структурный тип является и типом, ассоциированным с REF-типом столбца manager таблицы emps, и типом этой другой таблицы (имя которой не требуется и не содержится в приведенном выражении). Однако этот структурный тип должен содержать атрибут с именем last_name, и типизированная таблица, таким образом, содержит столбец с таким именем.
SQL:1999 - это еще не стандарт, хотя находится на пути к этому. В прошлом году было проведено голосования по поводу Final Committee Draft (FCD), содержащего четыре части спецификаций SQL (см. [1], [2], [4] и [5]). В ноябре 1998 г. состоялось заключительное редакторское собрание по поводу этих частей. Изменения спецификаций были представлены редактором (Джимом Мелтоном) и теперь рассматриваются участниками редакторского собрания. После завершения этого рассмотрения эти четыре части будут представлены для окончательного голосования (называемого голосованием по поводу Final Draft International Standard, или FDIS), результатом которого будет либо "одобрить и опубликовать без изменений", либо "не обобрять и вернуться к статусу FCD". В настоящее время все участники ожидают, что результатом будет "одобрить и опубликовать", что приведет к появлению пересмотренного стандарта где-то в середине 1999 г.
Другая часть SQL -- SQL/CLI (см. [3]) -- также пересматривается и только что подверглась голосованию как FCD. Ожидается, что она будет опубликована позже в 1999 г. как пересмотренный вариант стандарта CLI-95.
Трудно знать, что принесет будущее, но группы и в ANSI, и в ISO договорились избегать затяжных процессов типа того, который привел к SQL:1999. Мы все уверены, что шесть лет - это просто слишком много, особенно, если учитывать тот факт, что весь мир работает все больше и больше "во времени Web". Разрабатываются планы, в соответствии с которыми пересмотренные варианты стандарта должны появляться примерно через каждые три года, даже если технические усовершенствования будут более скромными, чем в SQL:1999.
В дополнение к развитию основных частей стандарта SQL разрабатываются дополнительные части стандарта, посвященные таким вопросам, как темпоральные базы данных, связь с языком Java (эти вопросы разъяснялись в предыдущем выпуске SIGMOD Record) и управление внешними данными наряду с данными SQL.
В течение этих лет в разработке SQL:1999 принимали участие многие и многие люди. Хотя по соображениям ограниченного объема статьи мы не в состоянии упомянуть всех, кто принимал участие в работе комитета, мы считаем правильным указать, по крайней мере, имена людей, которые написали существенное число изменений к предложениям или просто писали важные предложения.
Каждый из этих людей внес существенный вклад. Некоторые из них разработали основные аспекты архитектуры SQL;1999, другие концентрировались на конкретных технологиях, таких как интерфейс уровня вызовов (SQL/CLI), третьи работали над очень специальными вопросами, такими, как безопасность. Мы поздравляем всех их -- а также и тех людей, которые не упомянуты в приведенном списке -- с успешным завершением большой работы.
American National Standards Institute (ANSI)
http://web.ansi.org
International Organization for Standardization (ISO)
http://www.iso.ch
JTC1 SC32 - Data Management and Interchange
http://bwonotes5.wdc.pnl.gov/SC32/JTC1SC32.nsf
National Committee for Information Technology Standards (NCITS)
http://www.ncits.org
NCITS H2 - Database
http://www.ncits.org/tc_home/h2.htm
Перевод: Серегей Кузнецов
Оригинал: A. Eisenberg and J. Melton. SQL:1999, formerly known as SQL3. ACM SIGMOD Record, Volume 28, Number 1, March 1999