Помимо производительности, контрольные тесты ТРС помогают также определять для баз данных соотношение цена/производительность. Организация ТРС определила цену , используемую в расчетах, как стоимость пятилетней эксплуатации базы данных, включая цену вычислительной системы, цену профаммного обеспечения базы данных, стоимость технического обслуживания и сопровождения в течение пяти лет и т.д. Соотношение цена/производительность измеряется в долларах на тест (например, $500-tpmC ) Если для результатов контрольных тестов чем больше показатель, тем лучше, то для соотношения цена/производительность привлекательнее меньшие показатели.

Длительное сушествование тестов ТРС, а также постоянный контроль над публикуемыми результатами привели к тому, что заявления поставшиков СУБД о производительности их продуктов стали гораздо более достоверными. Влияние тестов, очевидно, в ближайшее время сохранится. В целом результаты тестов могут помочь определить, насколько та или иная конфигурация СУБД и аппаратного обеспечения соответствует требованиям приложения. Однако небольшое преимушество одной СУБД над другой по результатам контрольного теста почти никогда не дает ей абсолютного преимущества, так как конечные пользователи обычно принимают во внимание множество других факторов.

Стандарты языка SQL

Принятие официального стандарта ANSI/ISO для языка SQL было одним из главны-х факторов, благодаря которым SQL в 80-е годы стал единственным языком реляционных баз данных Соответствие стандарту ANSI/ISO стало отправной точкой для оценки реляционных СУБД, поэтому каждый поставщик утверждал, что его профаммный продукт совместим с или основан на стандарте ANSI/ISO. В конце 80-х - начале 90-х годов все популярные СУБД усиливали поддержку тех частей стандарта, которые касались широко используемых элементов языка SQL. Другие части, такие как модульный язык, упорно игнорировались. Это привело к тому, что только ядро языка SQL в разных СУБД стало почти одинаковым.

Как уже говорилось в главе 3, стандарт SQL1 был довольно офаниченным: в нем имелось много пробелов, а также немало областей, оставленных на усмотрение разработчиков СУБД. Несколько лет комитет по стандартизации работал над стандартом SQL2, который устранял эти недостатки и расширял язык SQL. В отличие от первого стандарта, в котором описывались элементы языка, уже имевшиеся в большинстве СУБД, стандарт SQL2 на момент своей публикации в 1992 году был попыткой опередить разработчиков СУБД, а не следовать за ними. В этом стандарте описьгаались функции и особенности языка, которые еше не использовались широко в современных ему СУБД; наборы записей с произвольным доступом, стандартизированные системные каталоги, расширенное применение подчиненных запросов и новая схема обработки ошибок. С опубликованием стандарта SQL2 начался новый виток развития реляционных СУБД - в направлении поддержки этого стандарта. Но большинство поставщиков все еше работают над обеспечением полного соответствия своих СУБД стандарту SQL2. На практике собственные расширения (например, расширенная поддержка мультимедийных данных, хранимые процедуры или объектно-ориентированные возможности) часто ока-зьгаались для поставщиков СУБД более важными, чем максимальная совместимость со стандартом SQL2.

Деятельность комитетов по стандартизации языка SQL продолжилась в направлении создания стандарта SQL3. Работа была разделена на несколько направлений: ядро языка, интерфейс вызовов функций, постоянно хранимые модули (хранимые

процедуры), распределенные транзакции и т д Работы в некоторых из этих направлений привели к созданию отдельных стандартов или расширений стандарта SQL2 Например спецификация SQL/CL1 была выпущена в 1995 году как дополнение к SQL2.

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

Противоречия в определении базовых возможностей языка SQL оказали влияние на другие части стандарта SQL3. Например, спецификацию SQL/CLI следовало бы расширить, чтобы можно было манипулировать не только столбцами скалярных типов данных, но и сложными объектами Но это невозможно сделать до тех пор, пока не будут согласованы объектно-ориентированные расширения языка. По этой причине окончательное принятие стандарта SQL3 затягивается. Что касается ситуации на рынке, то большинство СУБД еще не достигли совместимости со стандартом SQL2 на уровне Full Level, поэтому их поставщики, скорее всего, будут ориентироваться на поддержку тех частей новых стандартов, которые способствуют развитию уже имеющихся в их продуктах возможностей.

SQL в следующем десятилетии

Вряд ли сегодня кто-нибудь возьмется предсказать развитие рынка баз данных и SQL в следующем десятилетии. Ведь мы стоим на пороге новой эры в жизни всего компьютерного мира - эры глобального перехода в среду Internet, влияние которой , еще не осознано до конца даже специалистами. Зато на примере появления персональных компьютеров, ознаменовавших начало эры систем клиент/сервер, мы видим, как изменения на рынке компьютерных систем влекут за собой кардинальные изменения в архитектуре систем, предназначенных для управления данными. Похоже, что влияние Internet будет не меньшим, если не большим. Тем не менее, отдельные тенденции в развитии систем управления базами данных уже сейчас прослеживаются достаточно четко. О них мы и поговорим ниже.

Распределенные базы данных

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

должны быть распределенными, но в то же время СУБД должна обеспечивать их целостность и координирование, чтобы гарантировать надежность и эффективность деловых операций.

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

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

Массивные хранилища данных

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

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

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