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

На рынке баз данных господствует «Большая тройка» — IBM, Microsoft и Oracle. В начальной стадии в коммерческих РСУБД поддерживались реляционная модель данных с первой нормальной формой и язык запросов SQL, а также базовое управление транзакциями и средства авторизации доступа. Почти все системы выполнялись на нескольких Unix-платформах. За последние два десятилетия существенно расширились границы функциональных возможностей этих систем, возросла сложность, значительно повысилась производительность. Теперь они могут функционировать почти на всех моделях компьютеров под управлением большинства существующих операционных систем. Однако ведущие поставщики часто затрачивали недопустимо долгое время на устранение различных недостатков РСУБД, и в период их становления это привело к появлению решений, которые я буду называть технологиями «нишевых баз данных»1. Обычно нишевая технология появлялась на свет как средство преодоления одного крупного недостатка в имевшихся на тот момент РСУБД2. Разрабатывавшиеся поставщиками технологии и предпринимавшиеся ими усилия по продвижению этих технологий на рынок часто побуждали ведущих поставщиков к внедрению в свои продукты тех же технологий. Обладающие необходимыми финансовыми средствами, опирающиеся на поддержку клиентов и на свои маркетинговые возможности, крупные производители попросту вытесняли создателей нишевых технологий. В результате производители нишевых решений — за исключением около десяти компаний — так и не смогли превратиться в стабильные и крупные бизнес-структуры. Сегодня зрелость современных РСУБД, ожидания традиционных клиентов и господство на рынке «Большой тройки» делают выход на рынок новых производителей нишевых решений чрезвычайно затруднительным.

В данной статье я представлю ретроспективу нишевых технологий баз данных, приведя их краткие описания и рассказав о том, как они были (или не были) заимствованы ведущими системами. Рассмотрим следующие пять категорий нишевых технологий: ускорители (performance engines) для некоторых операций и сред баз данных; средства мониторинга и настройки производительности; расширения реляционной модели с первой нормальной формой; поддержка типов данных, не являющихся алфавитно-цифровыми; средства поддержки целостности данных. Различные типы вспомогательных средств баз данных, такие как инструменты для формирования запросов и генерации отчетов, средства проектирования баз данных, генераторы приложений, средства просмотра баз данных и т.п., обсуждаться не будут. Хотя они не являются приложениями конечных пользователей, я не считаю их и приложениями РСУБД.

Ускорители

На производительность РСУБД оказывали влияние, прежде всего, потребности приложений оперативной обработки транзакций (online transaction processing, OLTP). Обычно такие приложения извлекают малую часть содержимого большой базы данных, обновляют некоторые данные и сохраняют их в той же базе. Наличие большого числа одновременно выполняемых транзакций вынуждает запускать РСУБД на мощных серверах и мультикомпьютерных системах. В число методов повышения производительности, внедренных в РСУБД, входят, помимо прочих, методы доступа, оптимизация запросов на основе оценки затрат, архитектуры процессов, оптимизированное управление транзакциями, параметризованная настройка производительности, параллельная массовая загрузка данных. Методы доступа включают в себя индексы на базе B+-деревьев, хэш-таблицы, предварительно отсортированные таблицы и сегменты дисковых страниц. Таблица полностью сохраняется в одном сегменте дисковых страниц, и каждая дисковая страница форматируется таким образом, чтобы обеспечить быстрый доступ к отдельным записям, а также быструю «привязку» к другой странице. Метод оптимизации запросов на основе оценки затрат подразумевает расчет оценочной стоимости всех разумных «планов» обработки каждого заданного запроса, получаемых путем использования всех имеющихся методов доступа ко всем таблицам, которые затрагиваются запросом, и выбор плана с наименьшей стоимостью. В высокой степени оптимизированы применяемые при управлении транзакциями механизмы управления параллелизмом и восстановления. Минимизировано число команд, требуемых для проверки наличия и установки блокировок элементов данных. Для сокращения числа операций ввода/вывода минимизировано число записей об обновлении данных в журнал во вторичной памяти. В РСУБД имеется множество параметров, устанавливая которые нужным образом, администраторы баз данных могут оптимизировать производительность для своих сред приложений. В числе этих параметров — размер дискового сегмента, объем свободной памяти, резервируемой в каждой дисковой странице для обеспечения возможности в будущем вставлять новые записи, временной интервал «компактификации» дисковой памяти за счет ее очистки от записей, помеченных как удаленные, но не удаленных физически и т.д. Для обеспечения полного использования ресурсов центрального процессора при наличии обменов с дисками в РСУБД поддерживается многопроцессная и многопотоковая организация. Эта структура процессов также существенна для РСУБД, выполняемых на SMP-системах и на кластерах, когда имеется несколько центральных процессоров. В РСУБД внедрены методы параллельной обработки запросов, при применении которых сложный запрос декомпозируется на последовательность подзапросов так, что некоторые подзапросы обрабатываются параллельно на разных компьютерах, и для сокращения общего времени отклика подзапросы обрабатываются в конвейерном режиме. Кроме того, методы параллельной обработки применяются в РСУБД для массовой загрузки данных, резервного копирования данных, создания индексов и т.д.

Хотя работа по повышению производительности ведется уже свыше двух десятилетий, имеются, по меньшей мере, две особые ситуации, с которыми не справляются традиционные РСУБД. Имеются приложения, базы данных которых умещаются в основной памяти, и приложения, которым требуется, главным образом, «сканирующий» доступ к базе данных. Системы управления базами данных в основной памяти, такие как TimesTen, Altibase, Datablitz, Prisma и т.д. загружают данные из вторичной памяти в основную память и выполняют все операции с базой данных без потребности во вводе/выводе. В этих системах для большинства операций число команд сокращено за счет снятия проблемы доступа к вторичной памяти. В итоге, системы управления базами данных в основной памяти часто могут демонстрировать производительность, во много раз превосходящую производительность традиционных РСУБД. Конечно, традиционные РСУБД, выполняемые на компьютерах с основной памятью большего объема, могут обладать более высокой производительностью, чем системы, работающие на компьютерах с основной памятью меньшей емкости, и преимущества систем управления базами данных в основной памяти над традиционными системами могут быть частично компенсированы использованием основной памяти большей емкости. Технология систем управления базами данных в основной памяти обладает интересным потенциалом, который может быть реализован при наличии поддержки операционными системами 64-разрядной архитектуры, позволяющей добиться очень большого объема основной памяти, и при существенном снижении стоимости основной памяти. К числу проблем, которые требуется решить в данной области, относятся потребность в поддержке большей части возможностей языка запросов SQL и сопротивление со стороны системных администраторов, которые не испытывают желания администрировать еще одну систему вдобавок к традиционным РСУБД.

«Сканирующий» доступ к базам данных предполагает наличие потребности в однократном, а возможно, и многократном сканировании всей таблицы (или всей базы данных) для выполнения одной операции. В число примеров сканирующего доступа входят запросы, в которых требуется группирование всех записей таблицы в соответствии со значениями некоторого столбца; запросы, вычисляющие агрегатные функции на некоторых столбцах таблицы; запросы, для выполнения которых требуется предварительная сортировка таблицы; запросы с низкой селективностью; операции, реструктуризующие таблицу и т.д. Например, группирующий запрос может группировать все записи Person (человек) по значениям столбца Age (возраст). Агрегирующий запрос, может, например, вычислять Average Salary (среднюю зарплату) для всех записей Person. Запросом с низкой селективностью является, например, запрос, выбирающих записи, относящиеся ко всем некурящих людям. Операции, производящие реструктуризацию таблиц, включают, например, операцию разбиения столбца на два или большее число столбцов (например, один столбец Address (адрес) разбивается на столбцы StreetAddress (адрес на улице), City (город) и State (штат)) или операцию замены непрерывных числовых значений столбца (например, значение Salary 55400 долл.) на значения, определяющие категории (скажем, категорию Salary от 50000 до 59999 долл.).

Такие методы доступа, как индексы и хэш-таблицы, оказались весьма полезными при выполнении запросов для OLTP-приложений. Но они оказываются бесполезными при выполнении запросов, ориентированных на сканирование. Приложения оперативной аналитической обработки данных (online analytical processing, OLAP), обычно «анализируют» большие объемы данных, а не выбирают лишь небольшое число записей из большой базы данных. Как правило, для анализа данных требуется суммирование и агрегирование данных в соответствии с несколькими измерениями (грубо говоря, столбцами); в качестве примера можно привести общий объем продаж определенной модели компьютера по регионам (Region), месяцам (Month), по магазинам (Store) и т.д. По существу, для этого обычно требуется выборка и исследования содержимого всей таблицы. Такие программные продукты, как MaxScan и Sybase ASIQ, разработаны с целью обеспечения быстрого выполнения запросов, ориентированных на сканирование. С этой задачей они справляются, в среднем, в 10-20, а иногда и в 100 раз быстрее, чем традиционные РСУБД. Для достижения высокой производительности в системе MaxScan используются специальные схема компоновки памяти, схема сжатия данных и методы хэширования. В Sybase ASIQ все данные в таблицах кодируются чтобы уменьшить размеры таблиц и ускорить выполнение запросов. Несмотря на впечатляющие показатели производительности, с этими продуктами связаны те же проблемы, что и упоминавшиеся в связи с СУБД в основной памяти.

Потребность OLAP-приложений в суммировании данных по многим измерениям привела к появлению систем M-OLAP, таких как IRI Express (приобретена компанией Oracle), Arbor Essbase (приобретена компанией Hyperion) и Pilot Decision Support System (приобретена компанией Accrue). Системы M-OLAP представляют собой серверы OLAP, которые предварительно вычисляют сводки данных по всем возможным измерениям и сохраняют их в системе хранения, называемой многомерной системой управления базами данных. Поскольку сводки предварительно сохраняются, ответы на запросы поступают быстро. Однако предварительное вычисление сводок, как правило, занимает значительное время, а объем памяти, требуемой для хранения сводок (если не исключаются неопределенные значения), часто превышает размер исходных данных. Далее, обновления исходных данных делают сводки несостоятельными, и их нужно вычислять заново. В отличие от систем M-OLAP, для которых требуется особая система хранения, MicroStrategy, Cognos и другими компаниями были предложены системы R-OLAP. В качестве системы хранения данных в системах R-OLAP используется какая-либо РСУБД, но эти системы обычно являются гораздо более медленными, чем системы M-OLAP. В качестве аналитического сервиса своей СУБД SQL Server корпорация Microsoft предлагает как средства M-OLAP, так и R-OLAP.

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

Сложность современных РСУБД, операционных систем, под управлением которых они функционируют, приложений, объемность баз данных, многообразие и мощность ресурсов компьютеров исключительно затрудняют стоящую перед администраторами баз данных задачу обеспечения оптимальной производительности РСУБД и приложений. На производительность могут неблагоприятно влиять SQL-запросы, управление буферами баз данных, обмены с дисками, конкуренция за ресурсы базы данных (блокировки, семафоры, ожидания событий) и даже операционная система (ЦП, организация ввода/вывода и использование памяти). Наряду с ведущими поставщиками РСУБД, имеется несколько компаний, которые предлагают инструментальные средства, предназначенные для помощи администраторам в осуществлении мониторинга и настройки производительности РСУБД. В числе этих компаний — Computer Associates, BMC Software, Embarcadero, Quest Software и др.

Расширения модели с первой нормальной формой

На протяжении последних двадцати лет многие специалисты высказывали претензии к реляционной модели с первой нормальной формой, поддерживаемой в традиционных системах. Главный принцип реляционной модели с первой нормальной формой гласит, что каждый столбец каждой записи содержит атомарные данные. Атомарные данные — это данные, которые хранятся и извлекаются как единое и не разлагаемое на составляющие целое. Такой подход является весьма неестественным при управлении наборами данных или данными, которые можно описать с большей степенью детализации. Допустим, в столбце Children (дети) таблицы Person пользователь может сохранить имена двоих детей (Tom, Dick); но РСУБД трактует это как один элемент данных, а не как два отдельных элемента. Далее, в столбце Hobby (хобби) таблицы Person пользователь может сохранить детальную информацию об увлечении человека, например, (name: tennis, years-played: 5, hours-spent-a-month: 10). И снова РСУБД будет трактовать данные столбца Hobby как единое целое, не замечая компонентные элементы данных.

Потребность в естественном моделировании и запрашивании вложенной структуры некоторых данных, таких как данные в столбце Hobby, привела к появлению РСУБД, не соответствующим принципам первой нормальной формы. Примером может служить UniData (приобретена компанией Ascential Software)3.

Ограничения реляционной модели с первой нормальной формой вновь стали объектом пристального внимания в 80-е годы, когда различные поставщики и исследователи взялись за создание систем управления объектно-ориентированными базами данных (ООСУБД). На первых порах термин «объектно-ориентированная база данных» приводил к большой путанице, в особенности, в сообществе специалистов в области РСУБД. То, что понимали под ООСУБД первые поставщики, такие как Mosaic (позднее переименованная в Ontos), ObjectDesign (ныне именуется eXcelon) и Servio Logic, являлось всего лишь системой объектно-ориентированного программирования со стабильным хранением объектов. Ontos и ObjectDesign хотели предложить систему программирования C++ со стабильным хранением объектов, а Servio Logic — стабильную систему программирования Smalltalk. По сути дела, на первых порах основная идея состояла всего лишь в том, чтобы объекты C++ или Smalltalk сохранялись в «базе данных», чтобы пользователи извлекали их с помощью указателей на эти объекты и манипулировали извлеченными объектами в основной памяти. Объекты представляют собой совокупность элементов данных и методов вместе со связью наследования на классах. Исходная концепция ООСУБД была чужда членам сообщества РСУБД, которые были приучены считать, что система баз данных должна поддерживать язык запросов, основанный на SQL, и средства управления транзакциями. Это привело к тому, что в течение некоторого времени лагери ООСУБД и РСУБД обменивались довольно путаными упреками. Из лагеря РСУБД звучало, что ООСУБД — это не системы баз данных, поскольку в них не поддерживаются непредвиденные запросы, и пользователям навязывается навигация по базе данных на основе указателей, подход, от которого отказались при переходе технологии баз данных из эры иерархических баз данных в эру РСУБД. Лагерь ООСУБД отбивался, утверждая, что нет смысла применять неуклюжие SQL-запросы в то время, когда основанная на указателях навигация по объектам в основной памяти обеспечивает намного более высокую эффективность. Позднее производители ООСУБД (и пионеры этого направления, и те, кто присоединился к ним на более поздних этапах, например, O2) встроили в свои системы языки для непредвиденных запросов и средства управления транзакциями, что сделало ООСУБД более похожими на традиционные системы баз данных, хотя и сохранили навигацию на основе указателей по объектам, располагаемым в основной памяти )4.

Между тем, в компании UniSQL — а за ней и Illustra — осознавали бесплодность пикировки между двумя лагерями и искали возможность расширения реляционной модели с первой нормальной формой до объектно-ориентированной модели в том виде, в каком она воплощалась в объектно-ориентированных языках программирования. В начале 90-х годов они предложили идею объектно-реляционных систем (ОРСУБД). Объектно-реляционная модель включает в себя принцип вложения классов, уникальные идентификаторы объектов, методы, приписываемые к классу, наследование атрибутов и методов в соответствии с иерархией классов, а также связи обобщения/специализации между классами, расположенными на разных уровнях иерархии классов.

Illustra была позднее приобретена компанией Informix, которая, в свою очередь, перешла в собственность корпорации IBM. Технология Illustra была интегрирована в РСУБД Informix. Технология UniSQL позднее стала достоянием ряда различных корпораций в США и в странах Дальнего Востока. Работа, начатая в UniSQL и Illustra в 90-х годах, привела, в конце концов, к расширению языка SQL до SQL3 путем добавления к SQL объектных расширений, а также внедрению объектно-ориентированной модели Oracle 9i и DB2 8.1. Вполне вероятно, что в обозримом будущем и другие крупные РСУБД станут напрямую поддерживать SQL3 и тем самым перейдут в категорию ОРСУБД.

Далее, производители РБД в настоящее время поддерживают стабильное хранение объектов для объектно-ориентированных языков программирования, включая C++ и Java. В сущности, они обеспечивают обертку (wrapper) между объектно-ориентированной программой и ОРСУБД, сглаживающую различия между моделью объектно-ориентированного языка и моделью ОРСУБД.

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

Наряду с объектами, в течение долгого времени темой исследований являлась поддержка темпоральных данных. К темпоральным данным относятся исторические данные и данные временных рядов, а также понятия времени транзакции (transaction time) и времени действительности (valid time). Время транзакции — это время ввода данных, а время действия — это время, в течение которого данные сохраняют действенность. Имеется несколько прототипов, таких как T Helper, ORES и Tzolkin; кроме того, имеется также ряд предложений по расширению языка SQL, таких как SQL/Temporal, TSQL, TLSQL и т.д. Однако собственная поддержка темпоральных данных в ведущих РСУБД отсутствует. В нескольких крупных РБД для поддержки темпоральных данных используются модули data blade.

Поддержка типов, не являющихся алфавитно-цифровыми

На первом этапе традиционные РСУБД проектировались для поддержки алфавитно-цифровых типов данных. Позднее в них была внедрена поддержка больших бинарных объектов (binary large object, BLOB) и больших символьных объектов (character large object, CLOB). В Illustra была предложена идея встраивания в РСУБД программных модулей, которые обеспечивают поддержку специальных типов данных, не являющихся алфавитно-цифровыми. В Illustra такие программные модули получили название data blade («лезвие данных»). В Oracle появились модули data cartridge («картридж данных»), а IBM добавила к DB2 механизм database extender («расширитель баз данных»). Эти программные модули определяют и реализуют определенный тип данных и различные операции для этого типа данных.

Хотя модули data blade5 представляют собой важный шаг на пути к поддержке типов данных, не являющихся алфавитно-цифровыми, они не привносят в РСУБД полный набор средств для работы с такими типами данных: интегрированный язык запросов, оптимизация и обработка запросов, управление транзакциями и т.д.

Некоторые поставщики специализированных продуктов расширили процессоры реляционных баз данных путем добавления собственных средств поддержки пространственных типов данных и пространственных операций. В число пространственных типов данных входят точка, линия, прямоугольник, многоугольник, ломаная линия, круг и т.д. К числу пространственных операций относятся операции «частично перекрывает», «примыкает», «содержит», «выше», «ниже», «левее», «правее», «ближайший» и т.д. Для поддержки выполнения пространственных запросов, т.е. запросов, содержащих пространственные данные и пространственные операторы, в этих продуктах обычно применяется механизм индексирования, основанный на R*-дереве. Компания KT Data расширила процессор объектно-реляционных баз данных UniSQL пространственными типами данных и операциями. Компании Paradise и Monet поддерживают пространственные типы данных и операции, а также методы параллельной обработки запросов. Компания Intergraph предлагает MGE-GeoData Manager для управления пространственно-временными данными. Oracle также внедрила в свою РСУБД интегрированную поддержку пространственных типов данных и пространственных операций. Эти системы являются более амбициозными, чем РСУБД, которые поддерживают пространственные типы данных с использованием data blade и координируют обработку запросов средствами обычной РСУБД и отдельного пространственного модуля.

Расширяемый язык разметки XML является еще одним типом данных, не являющимся алфавитно-цифровым и привлекающим большое внимание. За последние несколько лет XML стал стандартным средством представления разнообразных данных, которым свойственна иерархическая структура. Вложенная структура XML естественным образом отображается на агрегационную иерархию объектной модели. Поэтому такие поставщики, как ObjectStore/eXcelon и Poet использовали свои объектно-ориентированные системы для хранения XML-данных и для обработки запросов к таким данным. В системе BADA IV корейской компании ETRI обеспечиваются собственные средства поддержки XML. Ведущие производители РСУБД первоначально поддерживали тип данных XML на основе модулей data blade. Однако теперь Oracle обеспечивает собственную поддержку XML, используя возможности вложенных таблиц.

Некоторые крупные поставщики РСУБД добавляют, также, поддержку некоторых мультимедийных типов данных, включая изображения и видео. В Informix, DB2 и Oracle для этих типов данных и операций над ними обеспечиваются модули data blades. В этих модулях реализованы технологии распознавания и индексирования мультимедийного контента, разработанные такими компаниями, как Excalibur (приобретена Convera) и Virage.

Средства обеспечения целостности данных

В РСУБД поддерживаются различные механизмы поддержания целостности хранимых данных, однако они не являются полностью достаточными. Механизмы поддержания целостности, напрямую поддерживаемые в РСУБД, включают управление транзакциями, ограничения типов данных и ограничения целостности6. Управление транзакциями включает контроль параллельного доступа к одним и тем же данным со стороны нескольких пользователей (или транзакций), восстановление после мягких сбоев (которые приводят к разрушению данных в основной памяти) и жестких сбоев (приводящих к разрушению данные во вторичной памяти). Ограничения типов данных —это ограничения на значения столбцов, определенных на заданном пользователем типе: целые числа, строки символов и т.д. Для некоторых столбцов таблицы пользователи могут указывать ограничения целостности. К ним относятся ограничение «первичный ключ — внешний ключ» на столбцы двух таблиц, ограничение UNIQUE на столбец первичного ключа, ограничение NULL, разрешающее использовать в столбце неопределенное значение.

Ограничения типов данных не являются достаточными для того, чтобы предотвратить ввод в базу данных неверных данных. Например, ограничение диапазона значений целочисленного типа данных (18..65) может предотвратить сохранение, например, в столбце Age таблицы Person целых значений, выходящих за пределы указанного диапазона. Однако РСУБД не может знать, является ли правильным значение 25 для столбца Age некоторой конкретной записи таблицы Person. Ограничение целочисленного типа данных не может ничего сказать о единицах измерения значения «125», хранимого, скажем, в столбце Weight (вес) таблицы Person. Аналогично, ограничение типа символьных строк не может предотвратить сохранение слов с орфографическими ошибками, например, в столбце Name таблицы Person. Далее, по причине накладных расходов, вызываемых проверкой ограничений, или из-за беспечности части пользователей, уместные ограничения типов данных и целостности часто не указываются. Например, вместо задания диапазона значений (18..65) для столбца Age таблицы Person пользователь может Integer, допуская тем самым появление в столбце Age любого целочисленного значения. Далее, такое ограничение, как «Средняя зарплата любого человека не должна быть более чем на 30% ниже, чем самая высокая зарплата», потребует вычисления (или, по крайней мере, поиска) среднего значения зарплаты всякий раз, когда обновляются данные в столбце Salary таблицы Person. Подобные «сложные и дорогостоящие» ограничения часто не определяются.

Важность наличия корректных данных и осознание того, что РСУБД в действительности не гарантируют корректности данных, привели к появлению нескольких инструментальных средств обеспечения качества данных. Среди поставщиков таких средств First Logic, Trillium Software, Vality/Ascential Software и т.д. Эти инструменты помогают пользователям выявлять неверные данные, например, имена и адреса людей на основе справочников имен и адресов, и исправлять ошибки. Требуется постоянно проводить проверку качества данных в корпоративных базах, но этим часто пренебрегают. Это одна из тех ниш, которые, как представляется, все еще открыты для производителей специализированных продуктов.

Заключительные замечания

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

Кроме того, на протяжении последних двадцати лет потребители продемонстрировали, что некоторые качества РСУБД не имеют для них особого значения. Это касается, в частности, выразительности (простоты кодирования) в API и недостаточно впечатляющего (меньшего, чем в два-три раза) повышения производительности. Иными словами, если нишевые технологии баз данных ориентированы на совершенствование упомянутых качеств, то шансы построить на их основе жизнеспособный бизнес невелики.

Вон Ким — президент и генеральный директор компаний Cyber Database Solutions и MaxScan. Декан Института науки и технологии Ewha в Сеуле (Корея). Председатель группы ACM Special Interest Group on Knowledge Discovery and Data Mining (www.acm.org/sigkdd).

Translated from «A Retrospection on Niche Database Technologies», by Won Kim in Journal of Object Technology (JOT), vol. 2, no. 2, March-April 2003, pages 35-42. Translated into Russian for Otkrytye Systemy under special permission of the original publisher. Copyright JOT, 2003. Original article see at http://www.jot.fm/issues/issue_2003_03/column4.

1 Использованный в оригинале оборот — niche database technology («нишевая технология баз данных») означает, скорее, не техническую, а маркетинговую специализацию. То есть, речь идет о технологиях, для которых можно найти незанятую «нишу» на рынке. — Прим. ред.

2 В оригинале широко используются сокращения RDB, OODB и ORDB, которые раскрываются как реляционная, объектно-ориентированная и объектно-реляционная база данных соответственно. На самом же деле имеются в виду соответствующие системы управления базами данных. Такие неформальные обороты позволительны, но мы хотели бы, чтобы читатели улавливали смысловые различия разных терминов. — Прим. ред.

3 В настоящее время принадлежит корпорации IBM. — Прим. ред.

4 На наш взгляд, д-р Ким слишком вольно толкует конфликт между лагерями ООСУБД и РСУБД в 80-е годы. Конечно, возврат к использованию навигации по указателям сильно возмущал сторонников реляционной модели данных. Но в действительности, оба лагеря больше всего не устраивало отсутствие общей объектной модели, которую можно было бы использовать при построении ООСУБД таким же образом, как используется реляционная модель при построении РСУБД. Только в конце 90-х годов появилась объектная модель ODMG, к которой, хотя и с многочисленными оговорками, можно относиться как к такой общей модели. И, несмотря на наличие стандарта SQL:1999 (а теперь и SQL:2003), который можно считать стандартом объектно-реляционных баз данных, до сих пор никто не смог предложить объектно-реляционную модель. — Прим. ред.

5 В переводе отставлен термин data blade во всех местах, где его использовал д-р Ким. Следует понимать, что в тех случаях, когда речь идет не о конкретной реализации объектных расширений в Informix Universal Server, имеется в виду некоторый аналогичный механизм, поддерживаемый в других объектно-реляционных СУБД. — Прим. ред.

6 То, что д-р Ким называет ограничениями типов данных, на самом деле является ограничениями использования типов данных. В приводимых примерах — это ограничения столбцов. Используемый в оригинале термин Data Integrity («целостность данных») в области баз данных имеет формальное и фиксированное значение — база данных находится в целостном состоянии, если на составляющих ее данных удовлетворяется заданное логическое условие. Автор же плавно переходит к семантической согласованности данных. Это очень важная, но другая тема. — Прим. ред.