в соответствии с годом публикации, 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).
В Соединенных Штатах компьютерные стандарты находятся в ведении аккредитованного при 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: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:
cccccccSET 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: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 REFERENCINGOLD 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 и поэтому не могут иметь ассоциированных с ними структур).
Структурные типы имеют ряд характеристик, наиболее важными из которых являются следующие:
- Они могут определяться с одним или более атрибутами, каждый из которых может иметь любой допустимый в SQL тип, включая такие встроенные типы как INTEGER, такие типы коллекции как ARRAY или любой структурный тип (вложенный настолько, насколько это желательно).
- Все аспекты их поведения характеризуются методами, функциями и процедурами.
- Их атрибуты инкапсулированы через генерируемые системой функции наблюдения и изменения (функции "get" и "set"), единственные, обеспечивающие доступ к соответствующим значениям. Однако эти генерируемые системой функции нельзя перегружать; все остальные функции и методы могут быть перегружены.
- Сравнения их значений выполняются только через определяемые пользователями функции.
- Они могут участвовать в иерархиях типов, в которых более специализированные типы (подтипы) имеют все атрибуты и используют все функции, ассоциированные с более обобщенными типами (супертипами), но могут иметь новые атрибуты и подпрограммы.
Посмотрим на пример определения структурного типа:
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-типов
Вам не следует удивляться тому, что 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.
Переведено из ACM SIGMOD Record, Vol. 28, No. 1, Март 1999. Опубликовано с разрешения ACM и авторов. С авторами можно связаться по электронной почте по адресам andrew.eisenberg@sybase.com и jim.melton@acm.org.
Информация на Web
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
Где получить спецификацию?
Американский национальный институт стандартов (ANSI)
Attn: Customer Service
11 West 42nd Street New York, NY 10036 USA
Телефон: +1.212.642.4980
Национальные организации по стандартизации
Международная организация по стандартизации (ISO)
1, rue de Varembe, Case postale 56
CH-1211 Geneve 20 Switzerland
Телефон: +41.22.749.0111
Признание вклада отдельных участников
В течение этих лет в разработке SQL:1999 принимали участие многие и многие люди. Хотя по соображениям ограниченного объема статьи мы не в состоянии упомянуть всех, кто принимал участие в работе комитета, мы считаем правильным указать, по крайней мере, имена людей, которые написали существенное число изменений к предложениям или просто писали важные предложения: Минеа Андре (Франция; Sybase), Джон Бауэр (США, Digital и Oracle), Дэвид Бич (США, Oracle), Стефан Кэннан (Голландия, DCE Nederland и James Martin Consulting), Пол Коттон (Канада, IBM), Хью Дарвен (Англия, IBM), Линда деМичел (США, IBM), Джуди Диллман (США, CA), Рюдигер Эйзеле (Германия, Digital, Oracle, независимый консультант), Эндрю Эйзенберг (США, Digital, Oracle и Sybase), Крис Фэррар (США, Teradata и Compaq), Лен Гэллахер (США, NIST), Луиджи Джиури (Италия, Fondazione ugo Bordoni), Кейт Хэар (США, JCC), Брюс Горовитц (США, Bellcore), Билл Келли (США, UniSQL), Билл Кент (США, HP), Кришна Кулкарны (США, Tandem, Informix и IBM), Нельсон Маттос (США, IBM), Джим Мелтон (США, Digital и Sybase), Франк Пеллоу (Канада, IBM и США Microsoft), Баба Пипрани (Канада, независимый консультант), Петер Пистор (Германия, IBM), Майк Пиццо (США, Microsoft), Джефф Риччи (США, Sybase и IBM), Фил Шоу (США, IBM, Oracle и Sybase), Кохи Шибано (Япония, Токийский международный университет), Масаши Тучиба (Япония, Hitachi), Майк Юбел (США, Digital, Illustra и Informix), Мурали Венкатрао (США, Microsoft), Фред Земке (США, Oracle).
Каждый из этих людей внес существенный вклад. Некоторые из них разработали основные аспекты архитектуры SQL;1999, другие концентрировались на конкретных технологиях, таких как интерфейс уровня вызовов (SQL/CLI), третьи работали над очень специальными вопросами, такими, как безопасность. Мы поздравляем всех их - а также и тех людей, которые не упомянуты в приведенном списке - с успешным завершением большой работы.
Литература
[1] ISO/IEC 9075:1999, Information technology - Database Languages - SQL - Part 1: Framework (SQL/Framework), will be published in 1999.
[2] ISO/IEC 9075:1999, Information technology - Database Languages - SQL - Part 2: Foundation (SQL/Foundation), will be published in 1999.
[3] ISO/IEC 9075:1999, Information technology - Database Languages - SQL - Part 3: Call-Level Interface (SQL/CLI), will be published in 1999.
[4] ISO/IEC 9075:1999, Information technology - Database Languages - SQL - Part 4: Persistent Stored Modules (SQL/PSM), will be published in 1999.
[5] ISO/IEC 9075:1999, Information technology - Database Languages - SQL - Part 5: Host Language Bindings (SQL/Bindings), will be published in 1999.
[6] New Standard for Stored Procedures in SQL, Andrew Eisenberg, SIGMOD Record, Dec. 1996.
