Давние читатели SIGMOD Record, вероятно, знают, что эту колонку еще совсем недавно вел Лен Галлахер (Len Gallagher) из Национального института стандартов и технологии (National Institute of Standards and Technology, NIST) США. Однако характер работы Лена в NIST несколько месяцев назад изменился, и его большой талант нашел применение в иных областях, чем разработки стандартов де-юре. Однако с его уходом осталась довольно большая незаполненная ниша, и это стало отчасти причиной того, что вы видите здесь два наших имени. *2)

Для Джима Мелтона деятельность в области стандартизации была основной работой в течение более чем десятилетия. Он представлял в это время Digital Equipment Corporation и Sybase, Inc. в Техническом комитете X3H2 ANSI (ANSI Technical Committee X3H2), называемом теперь Техническим комитетом H2 NCITS (National Committee for Information Technology Standards), представлял США в соответствующем комитете Международной организации по стандартизации (The International Standards Organization, ISO), а также был редактором материалов стандартов SQL-92, CLI-95, PSM-96 и всех частей разрабатываемого следующего поколения стандарта SQL - SQL3. Регулярную колонку Джима "Обновление SQL" ("SQL Update") можно видеть в журнале "Программирование и проектирование баз данных" ("Database Programming & Design"). Он является также автором книг "Понимание Нового SQL: Полное Руководство" ("Understanding the New SQL: A Complete Guide") и "Понимание хранимых процедур SQL: Полное руководство по SQL/PSM" ("Understanding SQL"s Stored Procedures: A Complete Guide to SQL/PSM").

Эндрю Айзенберг работал в области стандартизации баз данных еще дольше. Помимо выполнения функций представителя Digital и Sybase в ANSI X3H2, Эндрю выступал также от имени Computer Corporation of America (CCA) и Oracle. В настоящее время он принимает также участие в работе нескольких других организаций по стандартизации, в том числе Object Management Group (OMG) и Transaction Processing Performance Council (TPC). Эндрю уже публиковался на страницах этого журнала ранее, когда Лен Галлахер был ведущим этой колонки. В декабре 1996 года появилась его статья "Новый стандарт хранимых процедур в SQL" [1].

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

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

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

Что такое стандарт?

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

Прежде всего, существуют "стандарты де-юре". Это такие стандарты, которые публикуются признанными официальными организациями, занимающимися стандартизацией. Наиболее известная такая организация в Соединенных Штатах - Американский национальный институт стандартов (American National Standards Institute, ANSI). Хотя ANSI сотрудничает с другими организациями, которые разрабатывают стандарты в США, он имеет официальный статус как главный разработчик стандартов в стране, включая стандарты по информационным технологиям. На самом деле, ANSI сам по себе фактически не разрабатывает стандарты, а аккредитует для разработки стандартов другие органы, которые функционируют под эгидой и по правилам ANSI.

ANSI опубликовал ряд стандартов по информационным технологиям, изданных несколькими различными аккредитованными организациями-разработчиками стандартов (Standards Developing Organizations, SDO), в число которых входят, в частности, IEEE (Institute of Electrical and Electronical Engineers) и группа, называемая NISO (National Information Standards Organisation). Однако большинство стандартов, связанных с информационными технологиями, опубликованных ANSI, разрабатывается группой, ранее называвшейся X3 (это название не имеет какого-либо специального смысла). Эта группа, которая называется теперь Национальным комитетом по стандартам информационных технологий (National Committee for Information Technology Standards, NCITS), образовала ряд технических комитетов для разработки специальных стандартов, являющихся результатом учрежденных для них проектов. Например, Технический комитет H2, ранее называвшийся X3H2, реализует ряд проектов в области технологии баз данных, в том числе, стандарт SQL и некоторые другие связанные с ним стандарты, например, Удаленный доступ к базам данных (Remote Database Access, RDA) или Мультимедийные и прикладные пакеты SQL (SQL Multimedia and Application Packages, SQL/MM).

В международном масштабе главным органом, учреждающим стандарты, является Международная организация по стандартизации (The International Standards Organization, ISO). Подобно ANSI, ISO также сотрудничает с другими организациями. Одной из основных таких организаций является Международная электротехническая комиссия (The International Electrotechnical Commission, IEC). Несколько лет назад, ISO признала, что не только она, но и IEC разрабатывала стандарты в области информационных технологий. Поэтому для объединения их усилий был образован Совместный технический комитет (Joint Technical Committee) JTC1.

JTC1 руководит разработкой стандартов для информационных технологий по правилами ISO. В его рамках образованы различные подкомитеты (Subcommittees, SC) для специфических областей стандартизации информационных технологий. До недавнего времени (примерно год назад), за стандарты, связанные верхними уровнями (включая уровень приложений) Соединения открытых систем (Open System Interconnection, OSI), был ответственен подкомитет SC21. Однако, сформировалось широко распространенное мнение о коммерческой неудаче OSI. Поэтому SC21 был аннулирован JTC1, и наиболее важные его проекты, в частности, и SQL, были поручены другим подкомитетам, некоторые из которых были вновь образованы, а другие уже существовали. Разработка нового стандарта SQL, наряду с RDA, SQL/MM и несколькими другими проектами, была возложена на новый подкомитет SC32, названный подкомитетом по Управлению и обмену данными.

Не единственная игра в городе

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

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

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

"Ландшафт" стандартизации засорен стандартами, предназначенными для решения таких проблем, которые никто не считает проблемами, стандартами, возникшими прежде, чем проблема была осознана, или разработка которых была завершена (часто из-за стремления к совершенству) намного позже того, как индустрия избрала другое решение.

К счастью, ни ISO, ни ANSI (и аналогичные им организации в других странах, такие как BSI в Великобритании, AFNOR во Франции и JSA в Японии), не обладают монополией на создание стандартов. Реальные стандарты исходят из различных источников - стандарты де-факто - это такие стандарты, которые фактически применяются на рынке, независимо от того, санкционированы они или нет каким-либо официальным органом.

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

Примеры стандартов консорциумов очень легко найти в настоящее время. Так, консорциум Object Management Group (OMG) опубликовал ряд спецификаций, которые были приняты крупными сегментами бизнеса в области информационных технологий. Широко реализуется совокупность спецификаций для управления распределенными транзакциями, которая была опубликована X/Open (ставшего теперь частью Open Group). Набор символов Unicode, предложенный консорциумом Unicode, стал общепринятым как лучший набор символов для целей интернационализации.

Наконец, что можно сказать относительно других спецификаций, которые широко используются или реализуются, даже если они могут исходить из отдельной корпорации? Например, о программном продукте Microsoft Windows 95 часто говорят как о "стандартной операционной системе". Мы, мягко говоря, не согласны с тем, чтобы называть Windows 95 "стандартом", так как мы резервируем это слово для спецификаций, а не для программных продуктов. Однако нельзя считать безосновательным применение данного термина в рассматриваемой ситуации в духе нашего его понимания. В конце концов, для любого столь широко используемого программного продукта предполагается, что широкое многообразие пользователей стандартизировано на его использовании.

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

Изменяющийся ландшафт стандартизации

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

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

Другими словами, эти процессы задуманы таким образом, чтобы они были хотя и медленными и утомительными, но основательными.

К сожалению, в наши дни вся индустрия информационных технологий, не говоря уже о бизнесе ее клиентов, стремительно мчится по "реке времени". Медленно текущие процессы часто оказываются неспособны обеспечить такие спецификации, в которых нуждаются коммерческие предприятия, и в те сроки, когда они действительно необходимы. Рынку как можно быстрее нужны "достаточно хорошие" спецификации, в значительно большей мере, чем превосходные стандарты "в конечном счете". Это означает что ANSI и ISO не могут ориентироваться на выпуск стандартов, которые требуют годы на разработку, с тщательным решением вопросов, связанных с каждым возражением каждого несогласного, с внимательной расстановкой всех точек над каждым "i" и перекладинок для каждого "t".

Но каковы же альтернативы? Обычный здравый смысл подсказывает, что значительно более подвижными являются консорциумы. Они могут значительно быстрее выпускать спецификации, которые являются достаточно хорошими. Однако, как показывает наш опыт, это только кажется, что консорциумы более подвижны. Они часто начинают свою работу с почти завершенной спецификации, разработанной одним или несколькими их членами, а первоначальные создатели этой спецификации могли затратить несколько лет, работая над нею неофициально. Иными словами, такой результат часто требует примерно столько же времени, сколько требуется ANSI или ISO, но работа выполнялась в неофициальном порядке благодаря проявленным к ней специальным интересам и без участия других лиц (что привело бы к необходимости решения неприятной проблемы достижения консенсуса).

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

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

То же самое можно сказать и относительно "стандартов", подобных Java (или Windows), которые разработаны отдельными компаниями. Такие спецификации не рождаются сразу вполне зрелыми, однако, создаются они иногда в течение длительных периодов времени. Публика не информирована о них в период разработки, и узнает о существовании такого "стандарта", только когда работа над ним была в значительной мере завершена и опубликована соответствующая информация. И это плохо. Конечно, хорошие идеи обычно оказываются жизнеспособными, а плохие - отмирают. Однако все мы знаем хорошие идеи, которые не нашли применения из-за недостатка маркетингового мастерства, и они не стали все же стандартами из-за недостаточно широкого использования.

Необходимо здесь высказать, однако, следующее предостережение. Стандарты, разработанные специальными группами по интересам - независимо от того, в рамках ли консорциумов или отдельных организаций - часто являются недостаточно "открытыми". Это означает, что они могут удовлетворять прежде всего потребности их создателя, а не индустрии в целом. Вам, вероятно, известно, что ISO решила признать компанию JavaSoft как организацию, предложившую "общедоступные спецификации" (Public-available specifications, PAS), связанные с языком Java. Более подробно об этом пойдет речь ниже. Это событие стало большой удачей для компаний Sun и JavaSoft, поскольку впервые отдельные компании получили такой статус. Ранее только консорциумы удостаивались подобной привилегии. В свою очередь, страны-члены ISO потребовали согласия компании JavaSoft с тем, что ISO берет на себя ответственность за сопровождение (читайте "расширение") любого стандарта, полученного на основе одного из их предложений. Предполагалось благодаря этому гарантировать, чтобы будущие изменения Java определялись в открытом процессе, а не за закрытыми дверями. К сожалению, как нам недавно стало известно, Sun по просьбе важного для нее заказчика внесла в Java Development Kit некоторые существенные расширения, связанные с библиотеками классов двумерной графики, но без какого-либо публичного обсуждения такой необходимости, пусть хотя бы в значительно меньшей мере, чем это предусматривается процессом стандартизации в ISO. Возможно, этот вопрос может показаться незначительным. Однако он отражает собственнический характер таких частным образом разработанных "стандартов" и опасности рассмотрения их как "открытых стандартов". Это вообще может неблагоприятно подействовать на вас - вы можете быть вполне счастливы результатам внесенных изменений, однако, как быть со следующим набором изменений? Помогут ли они вам или осложнят разработку ваших приложений?

Последнее замечание по этому поводу: качество на риске покупателя. Вы получаете именно то, за что платите. (Это справедливо - вы, конечно, не получите того, что вы не оплатили!) Всегда следует разобраться с тем, каким образом появился стандарт и как он поддерживается, а не только с его техническим содержанием.

Теперь несколько слов относительно общедоступных спецификаций и ускоренной разработки. Группы стандартизации, подобные ISO, - организации-разработчики стандартов де-юре - признали, что они не являются единственными компетентными источниками стандартов. В результате они учредили процессы, которые позволяют превратить в стандарт де-юре опубликованную общедоступную и широко принятую спецификацию (которую они называют "публично доступной спецификацией" - PAS), используя процедуру, включающую единственный цикл анализа и голосования (review-and-vote). Такая процедура используется в настоящее время для того, чтобы придать статус стандартов ISO некоторым стандартам ANSI и другим национальным стандартам, превратить спецификации X/Open в стандарты де-юре, а теперь и спецификации Java в стандарт ISO.

Состояние релевантных стандартов и групп стандартов

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

"Хорошо, что есть так много стандартов - можно из них выбирать." - Иногда приписывается Грейсу Хопперу, а иногда Эндрю С. Таненбауму.

NCITS H2 и ISO/IEC JTC1/SC32/WG3

NCITS H2 - Технический комитет по базам данных (США). SC32 - Подкомитет по управлению и обмену данными Совместного технического комитета JTC1. WG3 - Рабочая группа по языкам баз данных, функционирующая в составе JTC1/SC32. Эти организации совместно разработали за прошедшие годы несколько стандартов SQL. Стандартам SQL-86 и SQL-89 впоследствии пришел на смену SQL-92. Эти стандарты определяют модель данных, лежащую в основе языка SQL, операторы языков определения данных (DDL) и манипулирования данными (DML), встраивание операторов SQL во включающие языки программирования, а также динамическое исполнение операторов.

SQL-92/CLI

В 1995 году было принято дополнение к стандарту SQL-92 для Интерфейса уровня вызовов (Call-Level Interface) - SQL-92/CLI, которое иногда называют CLI-95. Спецификации CLI-95 представляют собой подмножество популярного интерфейса ODBC (являющегося стандартом де-факто), разработанного компанией Microsoft и другими. Он функционирует как вызываемый интерфейс к SQL-системам баз данных, обеспечивая высоко динамичные возможности, в отличие от относительно статических средств, предоставляемых встроенным SQL. Средства CLI (и, конечно, ODBC) предназначены прежде всего для использования функционально нерегламентированными (ad hoc) приложениями, связанными, например, с поддержкой принятия решений, в то время как встроенный SQL, по всей вероятности, должен использоваться приложениями "тепличного" характера, значительно менее динамичными по их функциям.

SQL-92/PSM

В 1996 году было принято другое дополнение к SQL-92 для поддержки хранимых процедур - SQL-92/PSM, Долговременно хранимые модули (Persistent Stored Modules), которое иногда называют PSM-96. С принятием SQL-92/PSM добавились следующие возможности:

  • Многооператорные процедуры: группы операторов SQL могут теперь выполняться вместе; предоставляются операторы управления логикой исполнения, локальные переменные, а также средства реакции на исключительные ситуации
  • Хранимые программы и модули: процедуры, функции и модули могут храниться на сервере базы данных
  • Внешние программы: процедуры и функции, написанные на включающих языках программирования, могут вызываться из оператора SQL.

Стандарт SQL-92/PSM подробно обсуждался в декабрьском выпуске журнала SIGMOD Record 1996 года [1].

SQL3

В настоящее время два указанные выше комитета работают над стандартом SQL3, который после его принятия придет на смену SQL-92. Разработка SQL3 перешла в октябре 1997 года в стадию заключительного голосования по проекту комитетов (Committee Draft ballot, CD ballot). Заседание, посвященное обсуждению редакции документа, состоялось в марте 1998 года. Дополнительные заседания по его редактированию запланированы на июнь и ноябрь 1998 года. Если эти заседания пройдут успешно, то стандарт SQL3 будет, возможно, принят в начале 1999 года.

В SQL3 значительно расширена система типов данных SQL-92. Добавлены некоторые новые встроенные типы данных, например, булевский (BOOLEAN), большой символьный объект (CHARACTER LARGE OBJECT) и строка (ROW), а также тип коллекций массив (ARRAY).

Одно из самых крупных дополнений в SQL3 - это типы данных, определяемые пользователем (User Defined Type, UDT). Пользователи получают возможность определять их собственные типы данных, каждый из которых имеет некоторое конкретное представление, методы и свойства упорядочения. Эти UDT могут всюду использоваться точно так же, как и встроенные типы данных (как тип данных столбца, например).

UDT может также использоваться и некоторым новым способом. Он может быть ассоциирован с базовой таблицей так, что каждый атрибут UDT отображается в столбец этой базовой таблицы. Новый тип данных REF может при этом использоваться для того, чтобы ссылаться на строки в такой таблице. Как для базовых таблиц, так и для UDT поддерживается отношение наследования. Остается лишь выяснить, будет ли в конечном счете принят вариант простого или множественного наследования.

К числу некоторых других возможностей, которые будет обеспечивать SQL3, относятся:

  • Рекурсивный запрос - создает результирующую таблицу путем обхода строк, в соответствии с некоторым ориентированным графом
  • Предикат подобия - расширение предиката LIKE, которое допускает регулярные выражения
  • Роль - полномочия могут быть предоставлены некоторой роли, и пользователи могут затем брать на себя различные роли в разное время
  • Триггер - могут быть определены операторы, которые должны выполняться каждый раз, когда над заданной таблицей выполняются операторы вставки, обновления или удаления. Операторы триггера могут выполняться один раз для всего оператора манипулирования данными или индивидуально для каждой строки, на которую воздействует этот оператор.
  • Удерживаемый курсор (Holdable Cursor) - курсоры могут быть определены таким образом, что они остаются открытыми после того, как транзакция будет зафиксирована.

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

Вероятно, мы посвятим SQL3 специальную публикацию, когда приблизится к концу процесс его принятия, и он станет более стабильным.

Object Data Management Group (ODMG)

ODMG - некоммерческий консорциум, который был образован в 1991 году с тем, чтобы "разрабатывать и поддерживать стандарты хранения объектов".*3)

Самая последняя публикация ODMG - "The Object Database Standard: ODMG 2.0" [2]. Эта спецификация содержит описание объектной модели, спецификации языка определения объектов (Object Definition Language, ODL), объектного языка запросов (Object Query Language, OQL), а также связываний для языков Java, C++, и Smalltalk. Объектная модель ODMG является надмножеством объектной модели OMG. Она предусматривает дополнительно связи между объектами, экстенты, классы коллекций и управление параллелизмом. Спецификации связывания для указанных языков позволяют программисту разрабатывать в одной и той же среде как собственно приложение, так и его компоненты для работы с базой данных.

ODMG 2.0 расширил предыдущие версии стандарта:*4)

  • Спецификациями связывания для языка Java
  • Стандартизацией внешней формы как данных, так и метаданных.

Совет по производительности обработки транзакций

Совет по производительности обработки транзакций (Transaction Processing Performance Council, TPC) - некоммерческая корпорация, образованная с целью "определить эталонные тесты для обработки транзакций и баз данных, а также распространять для индустрии объективные, верифицируемые данные TPC о производительности". За прошедшее время TPC опубликовал ряд эталонных тестов. Поставщики используют эти эталонные тесты, сертифицированные аудиторы изучают тесты и полученные результаты, и результаты представляются на рассмотрение TPC, после чего они могут быть опубликованы. Имеется Технический консультативный совет (Technical Advisory Board, TAB), который рассматривает претензии на соответствие эталонным тестам.

TPC-C

TPC-C - это используемый в настоящее время эталонный тест OLTP. Он содержит некоторую смесь транзакций только на чтение и транзакций обновления для того, чтобы имитировать сложную среду приложений OLTP. Тест TPC-C использует в качестве метрик число транзакций в минуту (transactions-per-minute-C, tpmC) и отношение стоимости к числу транзакций в минуту (price-per-tpm-C, $/tpmC).

Текущей версией теста TPC-C является версия 3.3.2. В настоящее время в стадии разработки находится версия 4.0, в которой, вероятно, будут следующие изменения:

  • Повышенная стоимость для некоторых типов транзакций
  • Учет ограничений целостности по ссылкам.

TPC-D

TPC-D - эталонный тест для сложной среды, обеспечивающей поддержку принятия решений. Запросы в этом эталонном тесте предусматривают задействование многотабличных соединений, сортировки и агрегирования данных. Эталонные тесты TPC-D могут исполняться при одном из размеров базы данных, который может быть выбран из специфицированного набора в диапазоне от 1 Гб до 10 000 Гб.

Текущей версией эталонного теста TPC-D является версия 1.3.1. Поток запросов содержит 17 запросов. Предусматривается использование двух метрик. Метрика мощности (QppD@размер) основана на однопотоковом тесте мощности. Метрика пропускной способности (QthD@размер) может основываться на фактическом многопотоковом исполнении или она может вычисляться с использованием результатов однопотокового теста.

В начале 1999 года ожидается принятие версии 2.0. Некоторые из изменений, которые планируется внести для этой новой версии эталонного теста TPC-D:

  • Шесть новых видов запросов (в том числе, левое внешнее соединение, использование функции SUBSTRING)
  • Необходимый многопотоковый тест пропускной способности с минимальным числом потоков для каждого размера базы данных.

TPC-W

TPC-W - эталонный тест для среды розничной электронной торговли, базирующейся на WWW. Он находится в настоящее время в стадии разработки, и принятие его ожидается в начале 1999 года.

Этот эталонный тест моделирует работу магазина в среде WWW. Он может исполняться для одного из размеров базы данных, который может быть выбран из диапазона от 1K товаров до 1M товаров. Эталонный тест TPC-W измеряет взаимодействия клиентов с WWW-сервером, осуществляемые с помощью браузера, допуская при этом, что некоторые передачи данных могут прерываться пользователем. Главными метриками для TPC-W будут число взаимодействий с WWW-сервером в секунду (Web-Interactions-Per-Second, WIPS@размер) и отношение стоимости к WIPS (Price-Per-WIPS, $/WIPS@размер).

Группа SQLJ

SQLJ - это неофициальная группа компаний, которая исследует способы совместного использования языков SQL и Java. В результате этих усилий появилось три документа, которые предполагается представить на рассмотрение официальным органам стандартизации.

SQLJ: Часть 0 - SQL, встроенный в Java

SQL-92 определяет встроенные операторы SQL для таких языков программирования, как C или КОБОЛ. Точно так же рассматриваемая часть SQLJ определяет встраивание статических операторов SQL в Java-программу. Представление запросов пользователя средствами SQLJ будет обычно более компактным и удобочитаемым, чем в терминах JDBC.

Операторам SQLJ в Java-программах должен предшествовать символ "#sql", который не является допустимым в языке Java. Для обмена значениями со средой SQL могут использоваться переменные и выражения языка Java. Этим переменным и выражениям должен предшествовать префикс ":", позволяющий отличать их от идентификаторов SQL. В SQLJ используется отображение типов данных Java в типы данных SQL, специфицированное в JDBC.

Написанная на SQLJ программа может далее обрабатываться транслятором SQLJ, который дает возможность генерировать либо чистую Java-программу, содержащую вызовы JDBC, либо программу, которая содержит другие операторы Java, реализующие взаимодействие с базой данных SQL.

Транслятор SQLJ позволяет осуществлять некоторую верификацию операторов SQL. Если транслятору задана фактическая схема, которая будет использоваться на стадии исполнения, или "примерная" схема (близкая к схеме, используемой на стадии исполнения), то в таком случае может быть проведена дополнительная верификация операторов SQL.

Часть 0 SQLJ только что была представлена на рассмотрение NCITS H2 [3] для принятия ее в качестве новой части стандарта SQL - Спецификации связывания с объектными языками (Object Language Bindings, SQL/OLB).

SQLJ: Часть 1 - Хранимые процедуры Java

Часть 1 SQLJ [4] позволяет пользователям SQL вызывать статические методы Java. Она определяет процедуру sqlj.install_jar, которая позволяет сделать известным для SQL файл Jar, содержащий Java-программы. Далее могут определяться процедуры и функции SQL, которые могут использовать в качестве их тел содержащиеся в этих программах статические методы Java (этот процесс может быть автоматизирован благодаря включению описателей в файл Jar). Как и в Части 0, здесь используется специфицированное в JDBC отображение типов данных Java в типы данных SQL. Пользователь SQL может вызывать эти функции и процедуры, не заботясь о том, содержат ли их тела операторы SQL или методы Java.

SQLJ: Часть 2 - Типы данных Java

Часть 2 SQLJ [5] позволяет определять предусматриваемые в SQL3 типы определяемые пользователем (User Defined Type, UDT), которые используют классы Java в своих определениях. Как уже говорилось ранее, типы определяемые пользователями в SQL3 могут использоваться в определениях переменных, параметров или столбцов.

Как и в случае Части 1, процедура sqlj.install_jar позволяет сделать содержимое файла Jar известным для SQL. Далее благодаря этому UDT SQL3 могут определяться таким образом, чтобы каждый такой UDT отображался в некоторый класс, а атрибуты и методы UDT отображались в атрибуты и методы этого класса. При этом данный класс Java должен поддерживать (implement) интерфейс java.io.Serializable.

Когда в атрибуте такого UDT сохраняется некоторое значение, физически запоминается сериализуемая форма Java-экземпляра. Впоследствии, когда это значение используется в вызове какого-либо метода, хранимое значение десериализуется, а затем вызывается нужный метод.

Части 1 и 2 SQLJ будут вскоре также рассмотрены NCITS, возможно, в соответствии с его правилами ускоренной процедуры.

Литература

[1] New Standard for Stored Procedures in SQL, Andrew Eisenberg, SIGMOD Record, Dec. 1996. Есть русский перевод: Э. Айзенберг. Новый стандарт хранимых процедур в языке SQL //Системы управления базами данных, 5-6/1996, с.126-135.
[2] The Object Database Standard: ODMG 2.0, Rick Cattell and Douglas Barry, Morgan Kaufmann Publishers, Inc. 1997.
[3] SQLJ: Embedded SQL for JAVA Part 0: Translator Specification, Dan Coyle, H2-98-227, May 15, 1998.
[4] SQLJ Part 1: Java Stored Procedures, Working Draft, Phil Shaw, June 10, 1998.
[5] SQLJ Part 2: Java Data Types, Working Draft, Phil Shaw, June 10, 1998.

Ссылки на ресурсы Web

American National Standards Institute (ANSI) http://www.ansi.org/
National Committee for Information Technology Standards (NCITS) http://www.ncits.org/
JTC 1 Information Technology http://www.iso.ch/meme/JTC1.html
Object Data Management Group http://www.odmg.org/
Transaction Processing Performance Council http://www.tpc.org/

Эндрю Айзенберг, Джим Мелтон

*1) Andrew Eisenberg (Sybase, Burlington), Jim Melton (Sybase, Sandy). Standards In Practice. SIGMOD Record, Vol.27, No.3, September 1998. (c) Пер. с англ. М.Р.Когаловского.

*2) Начиная с данного номера (Vol.27, No.3, 1998), в журнале "SIGMOD Record" возобновляется публикация специальной колонки с материалами, посвященными проблемам стандартизации в области систем баз данных, редакторами которой будут авторы данной статьи. Колонка стандартов не публиковалась в журнале с конца 1996 года после того, как редакционную коллегию покинул ее прежний редактор Лен Галлахер, о котором здесь идет речь. - Прим. пер.

*3) Следует здесь уточнить, что первоначально декларированной целью ODMG была разработка и поддержка стандартов для объектных систем управления базами данных. Результаты работы группы в этом направлении были зафиксированы в ряде версий созданного ею стандарта, опубликованных в 1993-1997 годах (ODMG-93, ODMG-93 Release 1.1, ODMG-93 Release 1.2 и, наконец, ODMG 2.0). Однако в апреле 1998 года ODMG объявила о расширении своего поля деятельности таким образом, что ее основной задачей становится разработка "универсальных спецификаций для хранения объектов". По мнению руководителей ODMG, возникла срочная необходимость в стандартизации хранения объектов, а также в обеспечении универсального интерфейса для упрощения доступа к базам данных из среды объектных языков программирования. Главной причиной такого развития событий послужило активное распространение языка Java. В соответствии с этими намерениями, группа изменила свое прежнее название "Object Database Management Group" на "Object Data Management Group", сохранив аббревиатуру "ODMG". - Прим. пер.

*4) Если более полно характеризовать нововведения в стандарте ODMG 2.0, то следует прежде всего заметить, что в нем радикальным образом, но, к сожалению, далеко не безупречно, переработана объектная модель. Внесены соответствующие поправки в синтаксис языков ODL и OQL. Введены концепции репозитория ODL-схемы как совокупности метаобъектов, специфицируемых средствами того же языка ODL, специфицирован специальный обменный формат для дампа текущего состояния объектных баз данных в файл или во множество файлов и для загрузки из таких файлов в базу данных. Уточнены спецификации связывания для объектных языков программирования C++ и Smalltalk. Включены также спецификации связывания для языка Java. Для каждого из этих языков стандартизованы средства доступа к репозиторию схемы базы данных. - Прим. пер.