Ландшафт области управления данными

Ландшафт области управления данными: аналитический
обзор
С.Д. Кузнецов, М.Н. Гринев
Институт системного программирования РАН
Содержание
1. Введение
2. Реляционные производственные системы
2.1. SQL как практическая замена реляционной модели данных
2.2. Новые возможности основных коммерческих SQL-ориентированных СУБД
2.3. Российская SQL-ориентированная СУБД Линтер
2.4. Перспективы свободно доступных SQL-ориентированных СУБД
3. Объектно-ориентированные базы данных
3.1. История ООСУБД
3.2. Современное состояние дел и перспективы
4. Объектно-реляционные отображения
4.1. История проблемы impedance mismatch и подходы к ее решению
4.2. Почему объектно-ориентированных программистов не устраивают ни
объектные расширения SQL-ориентированных баз данных, ни ООСУБД?
4.3. Подходы к обеспечению объектно-реляционного отображения
4.4. Современное состояние и проблемы
5. Новые технологии для обработки потоковых и сенсорных данных
5.1. Требования реального времени
5.2. Прикладные области, в которых требуется обработка потоковых данных
5.3. История потоковых систем, существующие системы и их особенности
5.4. Проблемы управления данными в сенсорных сетях
5.5. История систем управления сенсорными данными и их особенности
6. Системы управления полуструктурированными и неструктурированными данными
6.1. XML как общепринятый формат представления полуструктурированных
данных, стандарты XML
6.2. Особенности и подходы систем управления XML-данными
6.3. Проблемы XML-СУБД
6.4. Системы текстового поиска и потребности в поддержке семантики
6.5. Краткая характеристика целей и методов направления Semantic Web
6.6. Проблемы семантически обогащенных систем
7. Фундаментальные проблемы управления данными
7.1. Интеграция текста, данных, кода и потоков
7.2. Интеграция информации
7.3. Сенсорные данные и сенсорные сети
7.4. Использование неточных данных
7.5. Самоадаптация
7.6. Безопасность и конфиденциальность данных
Литература
1. Введение
Программные средства управления данными составляют важнейшую часть системного
программного обеспечения. Сегодня, как и в прошлые годы, наиболее распространенной
категорией средств управления данными являются системы управления базами данных
(СУБД). Однако все чаще возникает потребность в программных средствах,
характеристики которых существенно отличаются от характеристик традиционных СУБД,
и которые применяются в приложениях, где универсальные SQL-ориентированные СУБД
слишком тяжеловесны и/или недостаточно функциональны и эффективны. Кроме того, и в
самих «традиционных» SQL-ориентированных СУБД появляется все больше совсем
нетрадиционных возможностей, предназначенных для расширения их областей
применения.
Тем самым, область управления данными непрерывно расширяется, и в ней все труднее
ориентироваться. Тем более трудно написать материал осмысленного объема, в котором
анализировались бы все интересные черты современного состояния этой области. В этом
обзоре мы ограничиваемся некоторой субъективной выборкой тем, относящихся к
области управления данными, которые кажутся нам наиболее существенными и
перспективными, оставляя вне рассмотрения ряд направлений, возможно, заслуживающих
внимания.
Во втором, самом объемном разделе обзора, обсуждаются наиболее интересные
возможности, появившиеся в последних версиях семи SQL-ориентированных СУБД: трех
ведущих коммерческих реляционных СУБД (Oracle, IBM DB2 и Microsoft SQL Server),
единственной российской коммерческой СУБД Линтер компании Релэкс и трех наиболее
развитых SQL-ориентированных СУБД с открытыми исходными текстами (MySQL,
PostgreSQL и Firebird). Конечно, имеется ряд других SQL-ориентированных СУБД,
которые, безусловно, заслуживают внимания, но в данном обзоре авторы приняли
решение ограничиться этой выборкой.
Третий раздел обзора посвящен объектно-ориентированным СУБД (ООСУБД), которые
были очень популярны до конца 1990-х гг. В начале этого века интерес к ним упал ниже
критической отметки, но в последние годы ООСУБД начинают заново набирать
популярность. Описываются основные черты наиболее известных ООСУБД прошлых лет
и рассматриваются текущие события, свидетельствующие о возрождении этого
направления.
В четвертом разделе обсуждается направление, целью которого является создание средств
промежуточного программного обеспечения, обеспечивающего так называемое объектнореляционное отображение, т.е. возможность работы с реляционными данными через
объектную модель, на основе которой строится приложение. Приводятся соображения
авторов по поводу причин неудовлетворенности объектно-ориентированных
программистов базовыми средствами SQL-ориентированных и объектноориентированных СУБД, описываются категории средств объектно-реляционного
отображения и присущие им проблемы.
В пятом разделе рассматривается состояние дел в направлении систем управления
сенсорными и потоковыми данными. Обсуждаются причины, по которым в
соответствующих прикладных областях непригодны универсальные СУБД. Описываются
некоторые исследовательские и коммерческие системы.
Шестой раздел посвящается системам управления неструктурированными и
полуструктурированными данными. В частности, обсуждается состояние дел в
направлении систем управления XML-данными.
Наконец, в седьмом разделе рассматривается несколько фундаментальных проблем
области управления данными. Некоторые из этих проблем частично решаются в системах,
рассматриваемых в предыдущих разделах, но в целом для их решения необходимо
проведение масштабных исследований и разработок.
2. Реляционные производственные системы
Основным видом систем управления данными, с которыми работают приложения,
являются «реляционные», а точнее SQL-ориентированные СУБД. В этом разделе
описываются текущее состояние и проблемы этой области.
2.1. SQL как практическая замена реляционной модели данных
Сегодня для большинства людей, не являющихся профессионалами в области баз данных,
язык SQL является практическим воплощением реляционной модели данных. В
действительности, в стандартах языка SQL определяется некоторая собственная модель
данных, в чем-то похожая на реляционную модель, но значительно от нее отличающаяся
[1].
SQL-ориентированная база данных представляет собой набор таблиц, каждая из которых в
любой момент времени содержит некоторое мультимножество строк, соответствующих
заголовку таблицы. В этом состоит первое и наиболее важное отличие модели данных
SQL от реляционной модели данных, в которой фундаментальная абстрактная «родовая»
структура данных отношение, представляет собой множество кортежей. Вторым
существенным отличием является того, что для таблицы поддерживается порядок
столбцов, соответствующий порядку их определения. В реляционной модели данных
атрибуты отношения не упорядочены. Другими словами, таблица – это вовсе не
отношение, хотя во многом они похожи.
Из этого, в частности, следует, что в модели данных SQL отсутствует обязательное
предписание об ограничении целостности сущности. В базе данных могут существовать
таблицы, для которых не определен первичный ключ. С другой стороны, если для
таблицы определен первичный ключ, то для нее ограничение целостности сущности
поддерживается точно так же, как это требуется в реляционной модели данных.
Ссылочная целостность в модели данных SQL поддерживается в обязательном порядке,
но в трех разных вариантах, лишь один из которых полностью соответствует реляционной
модели. Это связано с интенсивным использованием в SQL неопределенных значений.
Наличие модели данных SQL, похожей на реляционную модель данных, но
принципиально от нее отличающейся, затрудняет использование SQL-ориентированных
СУБД. Часто проектировщики баз данных не учитывают эти различия и производят схемы
SQL-ориентированных баз данных с иногда неожиданным поведением. После появления
стандартов SQL:1999 и SQL:2003 [1], в которых определены возможности определения
произвольно сложных «пользовательских» типов данных и «типизированных» таблиц,
ситуация с проектированием SQL-ориентированных баз данных еще больше усложнилась.
Требуется проведение исследовательских работ с целью выработки методологии
использования всех возможностей SQL, понятной разработчикам приложений баз данных.
2.2. Новые возможности основных коммерческих SQL-ориентированных
СУБД
Абсолютными лидерами на рынке коммерческих SQL-ориентированных СУБД являются
системы Oracle, IBM DB2 и Microsoft SQL Server. В 2007-2008 гг. вышли новые версии
этих продуктов: Oracle 11g [2], DB2 v.9 [3], SQL Server 2008 [4]. В совокупности в этих
системах поддерживается множество новых и полезных возможностей, некоторые из
которых кратко характеризуются ниже.
2.2.1. Поддержка параллельных баз данных
Все три компании поставляют варианты своих систем, пригодные для использования в
средах симметричных мультипроцессоров и кластеров и в той или иной мере
поддерживающие распараллеливание запросов. Принципы распараллеливания запросов на
симметричных мультипроцессорах во всех трех системах близки, но отчетливее всего
проявляются у Oracle. С каждым процессором жестко связывается один поток управления.
Отдельный процессор ведает планированием выполнения запросов и управлением
буферной основной памятью. При обнаружении части плана запроса, для которого
необходимые данные уже находятся в буферной основной памяти, эта часть запроса
привязывается к свободному потоку управления и обрабатывается на соответствующем
процессоре. Внутризапросное распараллеливание обеспечивается за счет преобразований,
производимых оптимизатором запросов, и разделения данных на дисковой памяти.
Та же идея перенесена Oracle в кластерную среду. В решении Oracle Real Application
Cluster (RAC) [5] узлы кластера имеют равноправный доступ к общей дисковой
подсистеме, и для всех узлов программным образом создается единое виртуальное
буферное пространство. Другими словами, логика организации RAC, фактически, не
отличается от логики построения параллельной СУБД для симметричных
мультипроцессоров, хотя для реализации RAC потребовалось решение многих сложных
технических проблем.
У компании IBM имеется кластерное решение DB2 Database Partitioning Feature (DPF) [6],
ранее обеспечивавшееся продуктом DB2 Parallel Edition. По своей организации DB2 c DPF
очень хорошо соответствует кластерной архитектуре: для работы системы не требуется
общая основная или дисковая память, при оптимизации запросов минимизируется
передача данных между узлами, система практически неограниченно масштабируется.
У каждого из этих решений имеются свои достоинства и недостатки, ни одно из них не
представляет универсальный подход к построению параллельных систем баз данных. По
всей видимости, требуется накапливать опыт реализации проектов параллельных систем
баз данных и продолжать поиск оптимальных подходов к их организации.
2.2.2. Встроенная поддержка хранилищ данных, OLAP и data mining
Параллельные версии всех трех семейств СУБД позволяют эффективно строить
хранилища данных терабайтного и даже петабайтного масштаба. (Конечно, для этого
требуется привлечение дорогостоящих аппаратных средств.) Однако при использовании
традиционной для этих СУБД табличной организации данных становится трудно, а иногда
и невозможно поддерживать специальные «аналитические» запросы к базам данных,
характерные для приложений оперативной аналитической обработки данных (Online
Analytical Processing, OLAP).
Для выполнения таких запросов требуется использовать «многомерные» модели данных,
позволяющие представлять данные в виде многомерных кубов. Традиционно для этих
целей использовались отдельные OLAP-серверы, однако в последние годы появилась
тенденция включать средства поддержки многомерных кубов данных в состав
программного обеспечения основных SQL-ориентированных СУБД. В частности, так
было сделано в Microsoft SQL Server 2005 и Oracle 10g. Но эта тенденция не является
безусловной. Например, после приобретения в 2007 г. компании Hyperion Oracle решила
вернуться к использованию отдельного OLAP-сервера Essbase от Hyperion.
Все три компании обладают развитыми инструментами интеллектуального анализа
данных (data mining) и продолжают активно развивать это направление. Средства data
mining интегрированы в основные СУБД. Однако интересно то, что доступ к этим
средствам во всех этих СУБД дается только при приобретении наиболее дорогостоящей
«корпоративной» лицензии (хотя, например, средства OLAP предоставляются
покупателям «стандартной» лицензии, ориентированной на предприятия малого и
среднего бизнеса). Похоже, что сами поставщики не имеют четкого представления о том,
кому и как следует пользоваться data mining. Требуются исследования практических
потребностей пользователей.
2.2.3. Адаптивная оптимизация запросов
С каждым новым выпуском рассматриваемых СУБД в них повышается качество
оптимизации запросов. Если еще 15 лет тому назад можно было серьезно относиться к
«оценочной» (cost-based) оптимизации запросов только в СУБД IBM DB2, то в настоящее
время развитые средства оптимизации запросов поддерживаются и в Oracle [7], и в
Microsoft SQL Server [8].
В этой работе невозможно привести сколько-нибудь подробный обзор и анализ
применяемых средств оптимизации запросов, поскольку это очень широкая и специальная
область, но нужно отметить, что больше всего усилий тратится на поддержание надежной
статистической информации о распределениях значений столбцов в таблицах, хранимых в
базах данных и динамически образуемых при выполнении запросов. В этой связи нельзя
не отметить влияние подхода IBM, реализованного в экспериментальном адаптивном
оптимизаторе LEO [9], на основе которого разрабатывались средства оптимизации
запросов в последующих выпусках DB2. В этом оптимизаторе статистическая
информация уточняется при выполнении каждого запроса, а запросы, планы которых к
моменту выполнения не соответствуют текущей статистической информации,
динамически перекомпилируются.
Другим важным направлением оптимизации запросов является динамическое создание
вспомогательных физических структур данных (индексов и материализованных
представлений) на основе анализа потока запросов к базе данных. Здесь заметную роль
сыграла группа исследователей компании Microsoft, лидером которой является Сураджит
Чаудхари (Surajit Chaudhuri) [10].
Оптимизация запросов к SQL-ориентированным базам данных остается важной
исследовательской областью, однако, по всей видимости, серьезный вклад в эти
исследования могут внести только специалисты компаний, разрабатывающих основные
SQL-ориентированные СУБД.
2.2.4. Управление транзакциями с поддержкой версий
Основной режим управления транзакциями в рассматриваемых СУБД основывается на
двухфазном протоколе синхронизационных блокировок объектов базы данных. Этот
подход был заложен еще в 1970-е годы в экспериментальном проекте System R компании
IBM [11] и очень хорошо технически проработан. Однако применение этого подхода
приводит к задержке выполнения транзакций, в которых данные только выбираются из
базы данных и никогда не обновляются.
Более 10 лет тому назад в СУБД Oracle 7.3 был реализован режим управления
транзакциями, в котором чтение объекта базы данных гарантированно не приводило к
блокировке транзакции. В этом режиме для каждой строки каждой таблицы
поддерживалось две версии, и читающей транзакции выдавалась версия, зафиксированная
последней по времени транзакцией, зафиксировавшей изменение этой строки.
Начиная с SQL Server 2005, режим неблокирующего чтения поддерживается и компанией
Microsoft [12]. Как и в Oracle 11g [13], в MS SQL Server, наряду с режимом
«блокировочного» управления транзакциями пользователями может быть выбран режим
«версионного» управления. Заметим, что IBM пока не следует примеру своих
конкурентов, утверждая, что поддержка версий неоправданно повышает накладные
расходы системы, не принося существенных преимуществ пользователям. По-видимому,
и здесь требуются дополнительные исследования.
2.2.5. Встроенные файловые системы
Относительно возможности встраивания функций файловой системы в СУБД много
говорилось еще до выхода Microsoft SQL Server 2005. Однако реальный шаг в этом
направлении был сделан компанией Oracle в выпуске 11g. В этой СУБД появился новый
тип данных SecureFiles [14], позволяющий создавать LOB-объекты, с которыми можно
работать в файловом интерфейсе с сохранением всех прочих возможностей СУБД, в
частности, журнализации и восстановления после сбоев. Oracle утверждает, что эта
встроенная в базу данных файловая система исключительно эффективна, и призывает
активно ей пользоваться для хранения обычных файлов.
В SQL Server 2008 Microsoft делает ответный ход, объявляя о поддержке типа данных
FILESTREAM [15]. В решении Microsoft пользователи получают возможность доступа
средствами SQL Server к файлам, хранящимся в файловой системе NTFS (при этом
сохраняется ограниченная возможность доступа к тем же файлам на основе интерфейса
Win32). Доступ к объектам типа FILESTREAM из SQL Server производится в
транзакционном режиме с поддержкой журнализации и восстановления.
По-видимому, организация файловых систем, интегрированных с базами данных, – это
только первый шаг на пути к созданию единой информационной среды с общими
средствами поддержки целостности данных и их поиска.
2.2.6. Средства расширения функциональных возможностей СУБД
Средства определения пользовательских типов данных, методов, функций и процедур
появились в ведущих СУБД (Informix Universal Server, Oracle8, DB2 Universal Database)
более десяти лет назад [16]. Тогда ожидалось, что эти средства будут активно
использоваться партнерами компаний для обеспечения новых классов приложений. В
течение примерно трех лет новая технология интенсивно обсуждалась. Многим в то время
казалось, что объектно-реляционные СУБД (ОРСУБД) в корне изменят способы
проектирования и разработки приложений баз данных.
Постепенно шум вокруг ОРСУБД затих. До конца 1990-х гг. Informix, Oracle и IBM
совершенствовали свои ОРСУБД. В 1999 г. появился стандарт SQL:1999 [1], в котором
были зафиксированы объектные расширения языка SQL. И, наконец, после выхода в 2003
г. стандарта SQL:2003, уточнившего и дополнившего SQL:1999, в сообществе баз данных
окончательно перестали обсуждать объектно-реляционную технологию баз данных.
Однако, по нашему мнению, накопленный за 10 лет багаж объектных расширений,
специфицированных в стандарте SQL и реализованных в передовых продуктах компаний
IBM и Oracle, не должен бесславно пропасть. Это было бы нерационально, учитывая
громадный объем человеческого труда, затраченного за создание этих расширений.
Хочется надеяться, что с помощью исследовательского сообщества баз данных удастся
решить упомянутые выше и другие проблемы и привлечь разработчиков к полноценному
использованию возможностей ОРСУБД.
2.2.7. Поддержка темпоральных возможностей
Традиционные СУБД поддерживают работу с базами данных, в которых сохраняется
только наиболее свежее состояние элементов данных. Идея «темпоральных» баз данных
состоит в том, чтобы сделать время полноценным измерением данных, чтобы
пользователи и приложения могли оперировать данными, соответствующими любому
моменту времени прошлого. Следует отметить, что, несмотря на широкое признание
полезности темпоральных баз данных, наличие большого числа выполненных
исследовательских работ и большой задел в области темпоральных вариантов языка SQL
[17], в ведущих SQL-ориентированных СУБД до последнего времени отсутствовала
поддержка темпоральных возможностей.
Однако уже в Oracle9i появился механизм Flashback Query, позволяющий пользователям
без внесения каких-нибудь структурных изменений в базу данных просмотреть состояние
базы данных на какой-либо момент в прошлом. Механизм Flashback Query позволял
получить доступ только к некоторому статическому снимку данных. В Oracle10g к этой
технологии добавились еще несколько средств: Flashback Version Query позволяет
просматривать все версии строк заданной таблицы в заданном интервале времени,
находить транзакции, которые изменили заданную строку; Flashback Transaction Query
дает возможность увидеть изменения, внесенные заданной транзакцией. Наконец, в Oracle
11g появилось средство Flashback Data Archive, позволяющее автоматически отслеживать
и сохранять изменения всех данных, сохраняемых в базах данных Oracle. Эти данные
могут сохраняться сколь угодно долго, и их можно запрашивать посредством Flashback
SQL [18].
Oracle позиционирует свои средства категории Flashback, прежде всего, как средства
восстановления баз данных после ошибок пользователей. Однако понятно, что их можно
использовать для обеспечения истинно темпоральных свойств баз данных. Как кажется,
компания Oracle двигается в направлении обеспечения полного спектра темпоральных
расширений. Заметим, что отсутствие стандарта темпоральных расширений SQL мешает
надеяться на то, что со временем все ведущие компании, производящие SQLориентированные СУБД, будут поддерживать унифицированные средства управления
темпоральными данными.
2.2.8. Поддержка XML, неструктурированных и мультимедийных данных
В СУБД всех трех ведущих компаний уже сравнительно давно обеспечивается поддержка
хранения XML-данных и доступа к ним. В последних выпусках систем поддерживается
язык XQuery [59], языки модификации фрагментов XML-документов и т.д. В СУБД IBM
DB2 v.9 и Oracle 11g для хранения XML-данных поддерживается отдельная подсистема
управления памятью. Более того, в DB2 в качестве основного интерфейса доступа к базам
данных можно использовать как SQL со встраиваемыми конструкциями XQuery, так и
XQuery со встраиваемыми конструкциями SQL.
Базовые механизмы управления неструктурированными и мультимедийными данными
опираются на поддержку типов данных BLOB и CLOB. Для работы с текстовыми
документами обеспечиваются интегрированные с СУБД средства полнотекстового
поиска: FullText Search в MS SQL Server 2005 [19], Oracle Text [20], начиная с Oracle8, Net
Search Extender [21], начиная с DB2 v.8. Качество средств полнотекстового поиска
повышается с каждым новым выпуском систем. В частности, с участием российских
партнеров компаний совершенствуются возможности поиска в документах,
представленных на русском языке.
Средства поддержки мультимедийных типов данных (геоинформационных, аудио- и
видеоданных) в СУБД компаний Oracle и DB2 появились сразу после выпуска этими
компаниями систем с объектными расширениями – Oracle8 и DB2 Universal Database.
Пожалуй, именно в этой области объектные расширения принесли наибольшую пользу.
Следует отметить, что Microsoft включает в свою систему поддержку
геоинформационных данных, только начиная с SQL Server 2008.
Одной из проблем поддержки неструктурированных и мультимедийных данных (да и
XML-данных) в SQL-ориентированных СУБД является то, что эти данные в них не
являются «жителями первого сорта». Они вторичны по отношению к данным встроенных
типов, поддерживаемым на уровне ядра СУБД. Отсюда следует неизбежное снижение
эффективности при работе СУБД с такими данными.
2.2.9. Применение систем управления базами данных в основной памяти
Рассматриваемые SQL-ориентированные СУБД предназначены и оптимизированы для
управления базами данных, хранящимися во внешней памяти. При работе с базами
данных этим СУБД приходится обращаться к внешней памяти (хотя бы для обеспечения
должного управления транзакциями), что ограничивает возможности повышения их
производительности.
Имеется альтернативный подход к организации баз данных, при котором база данных
целиком поддерживается в основной памяти, и все структуры данных оптимизированы в
расчете на это; журнализация изменений базы данных не производится, а поддержка
транзакционности обеспечивается за счет репликации данных. К категории таких систем
относится СУБД TimesTen [22], приобретенная Oracle вместе с одноименной компанией в
2005 г. После выпуска Oracle 11g этот продукт был переименован в Oracle In-Memory
Database Cache. Компания планирует интегрировать его с 11g для использования в
качестве кэширующего сервера при работе с основными базами данных. Можно
ожидать очень интересных результатов.
2.2.10. Заключение раздела
Как показывает краткий (и далеко не полный) обзор наиболее интересных возможностей
СУБД трех ведущих производителей, в них действительно удалось реализовать очень
развитые технологии управления данными. Однако этим системам свойственен ряд
проблем, все более затрудняющих их использование и дальнейшее развитие: чрезмерная
сложность и тяжеловесность, переизбыток возможностей, трудность внедрения средств
для поддержки новых приложений.
2.3. Российская SQL-ориентированная СУБД Линтер
СУБД Линтер является единственной существующей в настоящее время коммерческой
российской СУБД. Она разработана и развивается компанией Релэкс, г. Воронеж.
Конечно, по набору поддерживаемых возможностей, по производительности при работе
со сверхбольшими базами данных, по объему своего внедрения эта система значительно
уступает SQL-ориентированным СУБД, обсуждавшимся в разд. 2.2, но она обладает
рядом интересных особенностей, которые делают ее привлекательной для разработчиков
приложений, в особенности, в России.
2.3.1. Основные технические характеристики СУБД Линтер
В СУБД Линтер [23] полностью поддерживается стандарт SQL/92, включая средства
определения данных, выборки и манипулирования данными, определения ограничений
целостности, управления транзакциями и т.д. В последних выпусках системы имеется
поддержка некоторых средств, определенных в стандартах SQL:1999 и SQL:2003
(аналитические функции, предикаты similar и match и т.д) За счет использования
версионного метода управления транзакциями поддерживается режим неблокирующего
выполнения транзакций, в которых отсутствуют операции изменения базы данных.
Имеется возможность использования типа данных BLOB, позволяющего работать с
большими (объемом до двух Гб) неструктурированными объектами данных.
Поддерживаются средства определения хранимых процедур и триггеров.
В системе обеспечивается ряд средств, позволяющих создавать гибкую и надежную
систему безопасности и конфиденциальности информации (эти средства
сертифицированы Гостехкомиссией на соответствие 2-му классу защиты информации от
несканкционированного доступа).
В состав дистрибутива СУБД Линтер входят следующие компоненты:







ядро СУБД Линтер (подсистема управления данными, транслятор SQL, процессор
сортировки, компилятор хранимых процедур, сетевые драйверы, менеджер
распределённых транзакций);
программы обслуживания базы данных (генератор системной базы данных, тестер
физических структур);
организующие интерфейсы (инструментарий администратора, менеджер хранимых
процедур со встроенным отладчиком, интерактивный SQL-интерфейс);
средства разработки приложений (встроенный SQL для C/C++, исполняющая
система 4GL языка Intcom, средство интерактивной разработки Лакуна);
средства сохранения/восстановления данных (в том числе «горячее»
архивирование, быстрая загрузка/выгрузка всей базы данных или отдельных её
частей и т.п.);
средства миграции данных (импорт из DBF, ODBC-средство миграции и т.п.);
интерфейсы различного уровня (ODBC-драйвер, интерфейс прямого доступа к
Линтер из Delphi/Kylix/C++ Builder, интерфейс для Java-программ, API-интерфейс
Линтер, Call-интерфейс и т.д.).
2.3.2. Поддержка реального времени
Многие заказчики компании Релэкс используют в своей работе операционные системы
реального времени. СУБД Линтер изначально проектировалась так, чтобы удовлетворять
ограничениям, которые накладывает функционирование в таких операционных системах
[24]. Архитектура Линтер достаточно гибка для переноса в разные программноаппаратные среды. В настоящее время СУБД Линтер функционирует как на платформах
Windows CE и Linux, так и в средах различных операционных систем реального времени
(QNX 4, QNX6, VxWorks, ОС РВ, OS/9, OS9000) на разнообразных аппаратных
платформах (x86, PPC, Sparc, ARM, MIPS и т.д.). При этом обеспечивается полная
совместимость по протоколам взаимодействия между узлами под управлением разных
операционных систем, что позволяет использовать единую инфраструктуру и для
поддержки технологического оборудования, и для аналитических систем.
Использованию СУБД Линтер во встроенных системах реального времени способствуют
небольшие требования к оперативной памяти. Даже полный серверный вариант системы
может поместиться в 4Мб оперативной памяти. Важным фактором использования Линтер
в системах реального времени является постоянство используемых ресурсов, или
возможность ограничения ресурсов. Гарантируется постоянство использования
оперативной памяти (вне зависимости от объема базы данных, сложности выполняемых
запросов и количества одновременно работающих пользователей и приложений).
При создании базы данных имеется возможность гибкой конфигурации расположения
файлов базы данных. Допускается размещение файлов разных таблиц и типов на разных
устройствах. Это особенно актуально при эксплуатации СУБД во встроенной технике,
когда у разных устройств имеются разные характеристики скорости и надежности
хранения информации. Наличие журнала и механизмы восстановления базы данных
гарантируют восстановление базы данных после сбоев по питанию, что особенно важно
для технологических и встроенных необслуживаемых систем, которые обычно и
разрабатываются с использованием операционных систем реального времени.
Отличительной особенностью интерфейса СУБД Линтер является полная асинхронность.
Любой запрос, поданный ядру СУБД, будет выполняться асинхронно. В системах
реального времени возможность продолжать обработку данных вне зависимости от
реакции хранилища данных очень важна. Во время обработки запроса к базе данных
можно продолжать обработку входных данных или управлять исполнительными
устройствами. Интерфейс Линтер позволяет также функционировать многопотоковым
приложениям: вся синхронизация обмена с базой данных выполняются прозрачно для
программы. Потоки могут также работать асинхронно.
Дополнительной возможностью для повышения производительности является
предварительная трансляция запросов. В случае такой трансляции при выполнении
запроса уже не требуется его синтаксически разбирать, вырабатывать план выполнения и
т.п. В полностью готовый к исполнению запрос необходимо будет только подставить
параметры (если они есть), и его можно выполнить.
В системах реального времени особое внимание уделяется приоритетам исполнения
запросов. Возможность исполнения запросов с различными приоритетами была заложена
в Линтер, начиная с самых первых версий, и с тех пор была значительно
усовершенствована. Предлагаются три класса приоритетов исполнения запросов: обычные
приоритеты, приоритеты Round Robin и приоритеты реального времени. Приоритетами
исполнения запросов можно управлять в процессе работы системы через специальные
управляющие команды. Кроме изменения приоритета возможна отмена выполнения
запроса или приостановка его выполнения на некоторое время.
Очень мощным аппаратом СУБД Линтер, активно используемым в системах реального
времени, является аппарат событий. Событие представляет собой объект синхронизации
распределенных приложений или извещения приложений об изменении в данных.
Перспективным планом компании Релэкс является постепенная переделка ядра СУБД в
соответствии с микроядерной технологией. Новая архитектура должна обеспечить
возможности «горячего» обновления отдельных модулей и наращивания
функциональности без остановки СУБД. Конечно, для перехода на новую архитектуру
коллективу предстоит решить ряд опытно-конструкторских задач.
2.4. Перспективы свободно доступных SQL-ориентированных СУБД
Наряду с коммерческими системами в мире SQL-ориентированных СУБД существуют и
развиваются системы, разрабатываемые и распространяемые на основе подхода
«открытых исходных текстов» (open source). Среди них наиболее известны MySQL [25],
PostgreSQL [26] и Firebird [27]. В этих системах интересны не только способы их
разработки, технические особенности и области применения, но также и то, что в их
развитии и совершенствовании активно участвуют российские разработчики.
В этом разделе приводится общая характеристика систем, рассматриваются различия в их
организации и способах разработки. Обсуждается, в каких областях эти системы могут
конкурировать с коммерческими системами, и указываются основные проблемы, которые,
по мнению авторов обзора, предстоит решить для обеспечения надежной
жизнеспособности SQL-ориентированных СУБД с открытыми кодами.
2.3.1. MySQL
Особенностью СУБД MySQL является то, что, будучи системой с открытыми исходными
текстами, она разрабатывалась коммерческой компанией MySQL AB (в числе
сотрудников этой компании немало специалистов из России и Украины). Более того, в
действительности компания распространяла свою систему в двух вариантах: бесплатном и
корпоративном, под разработанной в самой MySQL AB коммерческой лицензии. До
августа 2007 г. исходные коды обоих вариантов находились в свободном доступе, но
затем доступ к текстам программ коммерческой версии был закрыт для всех, кроме
корпоративных клиентов, оплативших лицензию.
В начале 2008 г. компания MySQL AB была приобретена компанией Sun Microsystems.
Sum Microsystems официально утверждает, что «новая СУБД MySQL корпорации Sun
Microsystems является ключевым компонентом популярных программных комплексов для
создания приложений Web 2.0». [28]. Однако к середине 2008 г. не видно серьезного
воздействия перехода MySQL в собственность Sun Microsystems на дальнейшую
разработку MySQL. Пока все работы по развитию MySQL идут по ранее намеченному
плану.
Текущим выпуском системы является MySQL Enterprise Server 5.1 [29]. По сравнению с
предыдущей версией 5.0, вышедшей в октябре 2005 г., в MySQL 5.1 появился ряд новых
возможностей, которые компания MySQL AB относит к областям хранилищ данных и
интеллектуального анализа данных; средств обеспечения высокой доступности данных;
упрощенного управления и средств обеспечения высокой производительности.
В области хранилищ данных и интеллектуального анализа данных основным
нововведением является средство горизонтального разделения таблиц и индексов (по
диапазону значений, с хэшированием и т.д.). Разделение таблиц возможно для всех
подсистем хранения данных, используемых в MySQL: MyISAM, Archive, InnoDB и т.д.
Кроме того, к этой области относится новый подключаемый модуль, поддерживающий
полнотекстовый поиск, и поддержка XPath для работы с XML-данными с возможностью
выбора и модификации узлов XML-документов на стороне сервера баз данных.
Для повышения уровня доступности данных наряду с механизмом репликации на основе
операторов SQL, существовавшим в MySQL 5.0, в MySQL 5.1 обеспечивается средство
репликации таблиц на уровне строк. В MySQL Cluster появилась поддержка данных,
сохраняемых в дисковой памяти, и также обеспечивается возможность асинхронной
репликации данных из одного кластера в другой.
Для облегчения управления системами баз данных в MySQL 5.1 появился планировщик
событий, позволяющий администраторам базы данных создавать и запускать
запланированным образом задания, выполняющие различные функции на сервере баз
данных.
Достижению более высокой производительности содействует новое средство
параллельной загрузки базы данных, а также утилита стрессового тестирования, которая
моделирует поведение заданного числа пользователей, задающих запросы разного вида.
После завершения работы этой утилиты формируется отчет, содержащий статистические
данные о работе сервера.
На конец 2008 г. планируется выпуск MySQL 6.0, в котором будет внедрена новая
подсистема управления данными Falcom, обеспечивающая полную поддержку транзакций
со свойствами ACID. Эта подсистема не предназначена для замены транзакционной
подсистемы управления данными InnoDB, но, по мнению разработчиков, в ряде случаев
будет работать более эффективно. Кроме того, в MySQL 6.0 должны обеспечиваться
поддержка неблокирующих вариантов операций, изменяющих схему таблиц, а также
ожидается ряд нововведений в оптимизаторе запросов SQL.
2.3.2. PostgreSQL
Под названием PostgreSQL система существует с 1996 года. Это название отражает связь
PostgreSQL с оригинальным проектом Postgres и внедрением в систему поддержки языка
SQL [30]. Управление проектом осуществляет небольшая группа инициативных
пользователей и разработчиков, называемая PGDG (PostgreSQL Global Development
Group). В число основных разработчиков PostgreSQL входит ряд российских
специалистов.
В начале февраля 2008 г. была выпущена СУБД PostgreSQL 8.3 [31], в работе над которой
принимали участие десятки разработчиков из 18 стран. В течение 15 месяцев разработки и
тестирования были обработаны и успешно внедрены более 280 пакетов изменений
исходного кода. Основные изменения и новшества разработчики разбивают на три части:
средства, способствующие улучшению производительности; новые возможности для
программистов приложений баз данных; нововведения, предназначенные для
администраторов баз данных.
Основными новыми средствами, способствующими повышению производительности
СУБД PostgreSQL 8.3, являются механизм асинхронной фиксации транзакций и
синхронизованные просмотры таблиц. При асинхронной фиксации не происходит
немедленного выталкивания во внешнюю память записи о фиксации транзакции. Тем
самым, существенное повышение производительности сопровождается риском потери
результатов последних по времени транзакций при крахе системы. Синхронизированный
просмотр таблицы позволяет избежать нескольких просмотров одной таблицы при
одновременном выполнении нескольких однотипных запросов.
Наиболее существенным изменением PostgreSQL, затрагивающим интересы
разработчиков приложений, является миграция модуля полнотекстового поиска tsearch2 в
ядро системы. Другое заметное изменение — поддержка XML. Появился специальный
тип данных xml, встроенный в ядро. В соответствии со стандартом SQL:2003 реализован
набор функций для преобразования реляционных данных в XML (т. н., функции
публикации SQL/XML). Для ускорения выполнения запроса к XML-данным возможно
использование функциональных индексов и GIN-индексов, а также использования
полнотекстового поиска для XML-данных. Соответствующие программные средства были
разработаны российскими программистами.
Администраторам наиболее полезно новое средство EXPLAIN ANALYZE, позволяющее
узнать, какой именно алгоритм сортировки был выбран для выполнения запроса, и
сколько памяти было израсходовано. При определении функции теперь можно
переопределять переменные окружения, которые будут действовать только в рамках
выполнения данной функции (привязка к функциям значений переменных).
В настоящее время уточняется состав новых функциональных возможностей, которые
должны войти в следующую версию PostgreSQL 8.4. Работа над этой версией уже активно
ведется, и завершение планируется в начале 2009 г.
Продукты на основе исходных текстов PostgreSQL производит не только сообщество
PostgreSQL под управлением PGDG, но и коммерческие компании, наиболее известной
среди которых является EnterpriseDB Corporation [32]. Эта компания выпускает свободно
доступный продукт Postgres Plus и совместимую с Oracle коммерческую систему Postgres
Plus Advanced Server. Наиболее интересным и совершенно новым для мира PostgresSQL
является интегрированный с Postgres Plus продукт GridSQL, в котором реализуется
архитектура распределенных баз данных без общих ресурсов между узлами.
2.3.3. Firebird
Как говорится на официальном сайте проекта [27], «Firebird – это коммерчески
независимый проект программистов сообщества C/C++, технических консультантов и
спонсоров, разрабатывающих и совершенствующих мультиплатформенную реляционную
СУБД, основанную на исходных кодах, которые были переданы в свободное
использование 25 июля 2000 г. компанией Inprise Corp. (называемой теперь Borland
Software Corp)». Речь здесь идет про исходные тексты СУБД InterBase 6.0. Коммерческую
линию развития этой системы продолжает Borland.
В апреле 2008 г. после двухлетней работы команды разработчиков, значительную часть
которой составляют российские специалисты, была выпущена версия Firebird 2.1 [33]. В
этой версии улучшены средства администрирования баз данных, повышена
производительность системы и введена поддержка ряда новых средств языка SQL.
Упростить администрирование позволяют новые виртуальные таблицы мониторинга, на
основе которых администраторы могут увидеть статистическую информацию о сервере в
целом, а рядовые пользователи – только те данные, которые соответствуют их
соединению. Введена возможность аутентификации пользователей средствами Windows.
На уровне SQL появилась возможность определения триггеров, условием срабатывания
которых являются подключение к базе данных, начало, фиксация и откат транзакции и т.д.
Появилась возможность использования глобальных временных таблиц и общих
табличных выражений, которые, в частности, можно использовать для формулировки
рекурсивных запросов. Введена конструкция UPDATE OR INSERT, срабатывающая как
UPDATE, если условию оператора соответствует хотя бы одна строка целевой таблицы, и
как INSERT в противном случае. Наконец, поддерживается оператор MERGE,
позволяющий слить две таблицы. Следует заметить, что не все введенные средства SQL
присутствуют в стандарте языка.
Наконец, основным средством повышения производительности является новый сетевой
протокол, в котором, в частности, некоторые виды пакетов группируются и посылаются в
сеть вместе.
Ожидаемый в конце этого года выпуск Firebird 2.5 разработчики рассматривают как
важный шаг на пути к СУБД Firebird 3.0, которая будет представлять собой параллельный
масштабируемый сервер с универсальной архитектурой, ориентированной на
симметричные мультипроцессоры.
2.3.4. Плюсы и минусы SQL-ориентированных СУБД с открытыми кодами
СУБД этой категории активно используются в разных приложениях, в которых не
требуются качества, присущие коммерческим системам высшего класса. Одной из
наиболее важных заслуг этого направления является то, что оно дает возможность
приобретения мастерства разработки и сопровождения СУБД молодежи, в том числе, и
российским молодым специалистам. Открытость систем позволяет участвовать в их
разработке практически всем желающим при наличии соответствующих наклонностей и
способностей.
Проблемами сводобно доступных SQL-ориентированных СУБД, которые необходимо
решить для обеспечения их надежной жизнеспособности, являются отсутствие новых
идей и подходов, вечная погоня за «большой тройкой», недостаточная надежность,
производительность и масштабируемость. Все эти проблемы очень серьезны, и удастся ли
их преодолеть в полном объеме хотя бы в одном из проектов, покажет будущее.
3. Объектно-ориентированные базы данных
К объектно-ориентированным (ОО) СУБД проявлялся повышенный интерес в 1990-е гг. В
начале 21-го века казалось, что их время прошло. Однако к концу первого десятилетия
появились признаки активизации этой области.
3.1. История ООСУБД
Область ООСУБД возникла на основе ранее существовавшей области языков
программирования баз данных. В этой области было выполнено множество исследований,
и был разработан ряд интересных экспериментальных систем, включающих Атлант [34],
DBPL [35] и PS-algol [36]. В 1990-е гг. консорциум ODMG разработал несколько
стандартов объектно-ориентированной модели данных, последним среди которых был
опубликован стандарт ODMG 3.0 [37]. В конце 1980-х – начале 1990-х гг. было создано
несколько интересных ООСУБД, к которым относятся GemStone, Objectivity, Versant,
Object Store и т.д. [1]. Коротко обсудим основные архитектурные особенности этих
систем.
3.1.1. ООСУБД GemStone
ООСУБД GemStone была одной из первых коммерчески доступных ООСУБД. Система
была разработана компанией Servio-Logic совместно с OGI. В исходном варианте системы
разработчики GemStone опирались на язык Smalltalk. Хотя в первых выпусках системы ее
основной язык назывался Opal, было видно, что в действительности это Smalltalk с
поддержкой стабильного хранения объектов, и вскоре название языка было заменено на
GemStone Smalltalk. Впоследствии в GemStone была обеспечена поддержка языков C и
C++, но во все времена базовым языком оставался Smalltalk, а все остальные интерфейсы
строились поверх базового интерфейса. И серверная, и клиентская части системы могут
работать под управлением всех основных ветвей ОС UNIX и всех развитых вариантов
Windows. В настоящее время продукт поддерживается, развивается и распространяется
компанией GemStone Systems Inc. [38].
Система основана на трехзвенной архитектуре клиент-сервер, в которой прикладная
обработка данных производится на среднем уровне между процессом взаимодействия с
пользователем и процессом, поддерживающим хранилище данных. Важность этого
подхода состоит в том, что если в приложении используется много данных, то код
приложения целесообразно расположить на стороне хранилища данных, а если в
приложении производится много изменений над небольшим объемом данных, то имеет
смысл разместить код приложения на стороне пользователя. Тем самым, архитектура
позволяет уменьшить объем сетевого трафика без перегрузки сервера, что повышает
скорость обработки данных.
Архитектура поддерживается рядом системных взаимодействующих процессов, среди
которых доминирующими являются процессы Stone и Gem. Процесс Stone координирует
доступ к хранилищу объектов, состоящему из нескольких областей внешней памяти,
которые могут представлять собой файлы или разделы дисков, а также могут быть
разнесены по нескольким машинам. Процесс Stone синхронизирует другие процессы и
обеспечивает согласованность данных при фиксации транзакций. Кроме того, процесс
отвечает за распределение идентификаторов объектов, объектных страниц и объектных
блокировок.
Объекты делаются стабильными (т.е. сохраняются в базе данных) путем использования
своего рода стабильного корня, называемого коннектором. Все объекты, прямо или
косвенно достижимые по объектным ссылкам от коннектора, являются стабильными. В
GemStone для каждого класса, в котором существует хотя бы один стабильный объект,
поддерживается эквивалентная серверная версия класса. Другими словами, один вариант
класса служит классом в контексте программирования, а другой – в контексте базы
данных. Такие пары поддерживаются автоматически: если создается класс в смысле
Smalltalk, и некоторый объект этого класса становится стабильным, то автоматически
создается серверный класс этого объекта (класс в смысле GemStone). Создание
коннектора приводит к появлению экземпляра класса GemStone, эквивалентного классу
объекта, который должен быть сделан стабильным. Аналогично, любой объект,
достижимый от коннектора, автоматически становится стабильным.
3.1.2. ООСУБД Objectivity/DB
Компания Objectivity [39] была образована в 1988 г. В 1990 г. была выпущена первая
версия системы, которая представляла собой распределенную СУБД, основанную на
использовании объектной технологии, высокопропускных локальных сетей и
симметричных мультипроцессоров. Система работает на всех основных UNIXплатформах и в среде Windows.
Система основана на клиент-серверной архитектуре, в которой единицей обмена между
сервером и клиентом является блок базы данных. Тем самым, многие системные функции,
включая кэширование, поиск объектов и преобразование их форматов, выполняются на
стороне клиента. Объектные идентификаторы представляются в 64-разрядном формате,
что обеспечивает потенциальную возможность работы со сверхбольшими базами данных.
Поддерживается четырехуровневая структура хранения данных. Объекты содержатся в
контейнерах, каждый из которых представляет собой часть локальной базы данных.
Локальные же базы данных могут комбинироваться в федеративную (распределенную)
базу данных. Надежность хранения данных поддерживается механизмом репликации.
В системе поддерживаются языки C++ и Smalltalk, но способы использования языков
сильно различаются. Это относится и к механизмам стабильности, и к средствам
определения данных. В среде C++ стабильными являются объекты всех классов,
являющихся наследниками специального системного класса. В среде Smalltalk
стабильными являются все объекты, достижимые от именованных корневых объектовсловарей. Соответственно, в Smalltalk для удаления объектов используется механизм
сборки мусора, а в C++ – явные операции.
3.1.3. ООСУБД Versant
С 1988 г. компания Versant [40] предлагает решения, основанные на хорошо
масштабируемой объектно-ориентированной архитектуре и проприетарном алгоритме
кэширования. ООСУБД Versant является одной из немногих объектно-ориентированных
систем, допускающих масштабирование уровня любого предприятия. Решения на базе
Versant применяются в телекоммуникациях, обороне, на транспорте и т.д. Система
работает как на основных UNIX-платформах, так и в среде Windows.
Архитектура Versant в большей степени ориентирована на логическое управления
данными, т.е. объектами, а не на физическое представление данных в виде, например,
страниц. Управление размещением объекта осуществляется системой способом,
полностью прозрачным для пользователей. Для поддержки локальных хранилищ объектов
используется кэширование.
Система обладает свойством отказоустойчивости. Для этого допускается синхронная
репликация базы данных на двух серверах, которые могут находиться в одной локальной
сети или разнесены в разные точки глобальной сети. В одной базе данных Versant может
храниться около трехсот триллионов объектов, размер каждого из которых неограничен.
Для архивации данных может использоваться ленточная внешняя память с
автоматическим оповещением оператора в случае потребности извлечения объектов из
архива.
Поддерживаются кластеры совместно используемых объектов, причем встроенные
объекты хранятся внутри своих объектов-предков, что способствует уменьшению уровня
фрагментации памяти. Кластеризация применяется и при внешнем кэшировании. Кроме
того, в системе Versant поддерживается возможность использования персональных баз
данных, установленных на мобильных компьютерах. Они могут быть отсоединены от
сервера центральной базы данных, использоваться автономно и фиксировать свои
изменения в центральной базе данных после восстановления соединения.
Для представления связей между объектами базы данных используется единый
стабильный указательный тип. В системе поддерживаются скрытые от пользователей
преобразования указателей базы данных в обычные указатели C++ и наоборот. Поэтому
объекты создаются и ликвидируются с помощью стандартных конструкторов и
деструкторов классов.
Для программирования можно использовать языки C++ и Smalltalk, причем безо всяких
расширений. Поддерживаются возможности, специфичные для работы с базами данных.
Например, имеется средство автоматической генерации схемы базы данных прямо по
файлам заголовков C++. Это позволяет обойтись без использования специализированных
препроцессоров или компиляторов. Специальные системные классы позволяют работать
со всеми разновидностями типов коллекций, специфицированными в стандарте ODMG.
Любой объект, созданный в среде C++, доступен в среде Smalltalk и наоборот.
3.1.4. ООСУБД ObjectStore
Компания Object Design была основана в 1988 г. с целью ускоренной разработки и вывода
на рынок ООСУБД, которую стали называть ObjectStore. В конце 90-х у Object Design
установились тесные партнерские отношения с IBM, что позволило привлечь к созданию
ObjectStore тысячи разработчиков приложений. На основе технологии ObjectStore
компанией был разработана одна из первых коммерческих СУБД – Excelon,
ориентированная на управление XML-данными. С начала 2003 г. компания является
подразделением компании Progress Software [41].
ООСУБД ObjectStore основана на архитектуре клиент-сервер, в которой каждый сервер
отвечает за регулирование доступа к хранилищу объектов и управляет журнализацией
обновлений, блокировками, установкой контрольных точек, разрешением конфликтов по
данным, резервированием данных и восстановлением базы данных после сбоев. Каждый
сервер поддерживает множество клиентов. В клиентском процессе используется
представление данных более высокого уровня, и клиентская часть ObjectStore отвечает за
управление коллекциями, выполнение запросов и управление транзакциями.
Серверная часть спроектирована в расчете на использование механизма отображения
виртуальной памяти, которая распространяется на всю сеть и может охватывать несколько
серверов. Извлекаемые из базы данных объекты могут объединяться в пакеты для
передачи по сети, что позволяет снизить объем сетевого трафика. Для сокращения
времени доступа в серверах используется техника кластеризации. На каждой клиентской
части имеется локальный кэш, в котором сохраняются используемые объекты. Когда
объект перемещается в адресное пространство клиента, ссылки на него перерабатываются
таким образом, что для каждого доступа к объекту достаточно выполнить одну команду
компьютера.
В ObjectStore стабильность хранения объектов поддерживается за счет наличия
именованных корневых стабильных объектов класса база данных. База данных создается с
помощью вызова метода new этого класса. Имеются методы для открытия и закрытия
базы данных. Кроме того, в классе содержатся методы для создания стабильных корневых
объектов, обычно являющихся коллекциями, в которых размещаются стабильные
объекты.
3.2. Современное состояние дел и перспективы
В конце 20-го – начале 21-го веков в области ООСУБД наблюдался явный упадок.
Исчезли публикации, перестали проводиться конференции, и компании-производители
ООСУБД промышляли в основном разработкой приложений, не слишком афишируя, что в
их основе лежит технология объектных баз данных. Казалось, что сообщество
разработчиков программного обеспечения отвернулось от этой технологии, хотя, как
отмечалось в начале раздела, именно на них она была изначально ориентирована. Трудно
сказать, в чем точно состояли причины этого упадка. Возможно, что здесь важную роль
сыграла маркетинговая политика крупных компаний, производящих SQLориентированные СУБД, которые сумели внушить массовым потребителям должное
доверие к универсальности, надежности и масштабируемости своих систем.
С технической точки зрения, по нашему мнению, важными оказались два следующих
обстоятельства. Во-первых, хотя в принципе практически все ООСУБД поддерживали
несколько объектно-ориентированных языков программирования, в их основе, как
правило, находился какой-либо один исходный язык. Остальные языки поддерживались
на правах «жителей второго сорта». К концу 1990-х годов особую популярность набрал
язык Java (а за ним C#), и оказалось, что на рынке нет ни одной ООСУБД, которая
максимально ориентирована именно на этот язык. В то же время, производители SQLориентированных СУБД обращали на его поддержку пристальное внимание.
Во-вторых, в конце 1990-х гг. в СУБД компаний IBM, Oracle и Informix была обеспечена
поддержка «объектных» расширений языка SQL. В действительности, это была совсем не
та поддержка объектно-ориентированного подхода, которая предлагалась в ООСУБД (см.,
например, [42]), но наличие схожих по названию возможностей в СУБД, поддерживаемых
крупными производителями, наверняка отвлекло многих пользователей и разработчиков
приложений от использования ООСУБД.
В последние годы наблюдается повышение интереса к этой области. Об этом
свидетельствует появление в 2005 г. неформального консорциума ODBMS.ORG [43]. Как
отмечается на сайте этого консорциума, ODBMS.ORG был создан для поддержки
студентов, преподавателей и специалистов исследовательских институтов, в также
разработчиков объектно-ориентированного программного обеспечения из сообщества
open source и коммерческих компаний в связи с возрастающей потребностью в
информационных ресурсах, посвященных технологии объектных баз данных и
интеграции объектно-ориентированного программирования и баз данных. Одним из
основных членов ODBMS.ORG является молодая компания db4objects [44], работающая в
соответствии с принципами движения open source и поставляющая встраиваемую в
приложения ООСУБД, ориентированную исключительно на язык Java.
В 2008 г. после долгого перерыва была проведена (пока еще небольшая)
специализированная конференция, посвященная проблемам ООСУБД [45]. Под эгидой
ODBMS.ORG начата работа по созданию нового стандарта объектно-ориентированной
модели данных [46]. Пока непонятно, приведет ли эта активность к новому витку
популярности ООСУБД.
4. Объектно-реляционные отображения
Большая часть современных производственных приложений, связанных с потребностью в
обработке больших объемов данных, разрабатывается на различных объектноориентированных языках (C++, C#, Java и т.д.). Разработчики приложений работают в
терминах прикладной объектной модели данных, и им удобнее и проще представлять в
той же модели внешние данные. Хотя теоретически можно было бы воспользоваться
объектными расширениями SQL или средствами ООСУБД, разработчики часто
предпочитают использовать промежуточное программное обеспечение (middleware)
«объектно-реляционного» отображения (object/relational mapping) для манипулирования
прикладными объектами, размещаемыми в традиционных таблицах SQLориентированных СУБД.
4.1. История проблемы impedance mismatch и подходы к ее решению
В языках программирования и языках баз данных традиционно поддерживаются разные
системы типов, разные способы доступа к данным и т.д. Возникает «потеря соответствия»
(impedance mismatch) между системами типов и средствами доступа к данным языка
программирования и системы баз данных. Это затрудняет разработку приложений,
которые по своей специфике вынуждены часто обращаться к базе данных для доступа к
требуемым им данным [47].
Как отмечалось выше, проблему «потери соответствия» пытались решать разработчики
языков программирования баз данных, создатели ООСУБД и объектных расширений
языка SQL. Альтернативным путем к решению этой проблемы является создание средств
промежуточного программного обеспечения объектно-реляционного отображения.
4.2. Почему объектно-ориентированных программистов не устраивают ни
объектные расширения SQL-ориентированных баз данных, ни ООСУБД?
Ситуация, сложившаяся на стыке объектно-ориентированного программирования и
средств управления базами данных, кажется просто парадоксальной. Более 20 лет
сообщество баз данных пытается предоставить сообществу объектно-ориентированного
программирования средства управления данными, устраняющие потерю несоответствия.
На это были направлены исследования и разработки в области языков программирования
баз данных. Именно устранение потери соответствия с объектно-ориентированными
языками программирования постулировалась в качестве основного довода в пользу
ООСУБД в [49]. Вопросы сопряжения с объектно-ориентированными языками
программирования серьезно учитывались при разработке объектных расширений языка
SQL. И тем не менее, очень многие разработчики (а может быть, и подавляющее
большинство разработчиков) приложений, создаваемых с использованием языков и сред
объектно-ориентированного программирования, используют промежуточное программное
обеспечение объектно-реляционного отображения, которое само взаимодействует с
базами данных на основе базового подмножества языка SQL без использования какихлибо объектных расширений. Чем это можно объяснить?
Мы не готовы представить развернутый ответ на этот вопрос. Общая точка зрения по
этому поводу отсутствует как в сообществе баз данных, так и в сообществе объектноориентированных языков программирования. Однако рискнем предположить, что
основной причиной предпочтений подавляющего числа программистов является их
уровень квалификации. Безусловно, в мире имеется большое число программистов
высокой квалификации, обладающих широким кругозором и обширными знаниями в
разных областях программного обеспечения. Они выбирают для реализации своих
проектов наиболее подходящие для них программные средства, используют и ООСУБД, и
объектные расширения SQL, если это приносит пользу приложениям.
Однако большинство современных приложений создается разработчиками средней
квалификации. Обычно их учат грамотно и эффективно писать программы на одном языке
или в одной среде программирования с максимальным использованием существующих
компонентов. Программистам этой категории не по силам (да и не хочется) наряду с
известным им объектно-ориентированным языком использовать еще и дополнительный
язык баз данных, такой как SQL или язык запросов к объектно-ориентированным базам
данных OQL. Средства объектно-реляционного отображения позволяют им в той или
иной мере обойтись знанием одного языка.
Кроме того, наряду с проблемой разработки приложений имеется не менее важная
проблема их сопровождения. Как правило, сопровождением приложений занимаются не
разработчики приложений, а совсем другие люди. Вне всяких сомнений, этим
специалистам намного проще иметь дело с однородными текстами программ, полностью
написанных на одном языке программирования.
4.3. Подходы к обеспечению объектно-реляционного отображения
Как отмечается в [16], объектно-реляционные отображения могут существовать в
разнообразных формах, из которых проще всего понимаются средства автоматического
объектно-реляционного отображения. В самой развитой форме средство автоматического
объектно-реляционного отображения сохраняет в базе данных не только состояния
прикладных объектов, но и метаданные, например, определения классов, которые
прозрачным образом могут использоваться в приложении. По сути, средство объектнореляционного отображения такого уровня представляет собой специализированную
ООСУБД, язык запросов которой максимально приближен к средствам доступа к данным
базового языка программирования, а соответствующая SQL-ориентированная база данных
используется только как среда хранения.
В другой форме для организации объектно-реляционного отображения требуется
кодирование вручную с использованием инструментальных средств, таких как JDBC или
ADO.NET, ориентированных на работу с реляционными базами данных. Эти средства
обеспечивают доступ к реляционным данным и их извлечение «вручную» в форме, более
привлекательной для объектных разработчиков.
В третьей форме реляционные данные просто принимаются в качестве модели, с которой
следует работать, и объекты подстраиваются под этот подход. В этом случае проблема
потери соответствия решается средствами базового объектно-ориентированного языка.
4.4. Современное состояние и проблемы
Наиболее масштабным проектом, связанным с обеспечением расширяемых возможностей
объектно-реляционного отображения для целого ряда языков программирования, является
LINQ компании Microsoft [50]. Первые реализации были выполнены для языков C# и
Visual Basic.NET. Это очень крупный проект, на результаты которого компания делает
высокую ставку. Однако в литературе [48] отмечается ряд проблем, полностью решить
которые вряд ли удастся и в этом проекте.
5. Новые технологии для обработки потоковых и сенсорных
данных
Для некоторых прикладных областей традиционная технология управления данными,
основывающаяся на двух- или трехзвенной системной архитектуре с выделенным
сервером баз данных, размещении данных в медленной дисковой памяти и т.д.,
оказывается неприемлемой. К таким областям относятся, в частности, приложения
потоковых и сенсорных данных.
5.1. Требования реального времени
Основная особенность потоковых и сенсорных данных состоит в том, что такие данные
динамически генерируются с очень большой скоростью, ценность этих данных может
иногда стремительно падать со временем, и приложения должны успевать обрабатывать
эти данные в реальном времени, в темпе их генерации. При этом число приложений
потенциально очень велико, и по части базовой обработки данных между ними много
общего, так что наличие специализированных средств управления потоковых и сенсорных
данных ускоряет разработку новых приложений, делает их более надежными и
эффективными.
5.2. Прикладные области, в которых требуется обработка потоковых данных
Наиболее важной областью, в которой требуется обработка потоковых данных,
признается финансовая деятельность, связанная с использованием биржевой информации.
Биржи круглосуточно генерируют чрезвычайно интенсивные потоки данных,
отражающие текущие курсы акций, объемы и покупок и продаж, и анализ этих данных в
реальном времени исключительно актуален как для компаний, акции которых продаются
и покупаются на биржах, так и для различных финансовых организаций. До появления
специализированных средств управления потоковыми данными соответствующие
приложения делались на основе проприетарных технологий, и эти приложения часто не
выдерживали возрастающих темпов поступления данных.
5.3. История потоковых систем, существующие системы и их особенности
Исследования в области систем управления потоковыми данными и разработка
прототипов таких систем начались с начала 2000-х гг. в университетских проектах Aurora
[51] и TelegraphCQ [52]. В этих проектах исследовались основные проблемы систем
управления потоковыми данными, в частности, изучались возможности эффективного
выполнения «непрерывных» (continuous) запросов. В 2003 г. была создана компания
StreamBase Systems [53], которая вскоре выпустила инструментальную систему обработки
потоковых данных StreamBase [54]. В этой системе используются и развиваются
результаты предыдущих исследований, применяется подход к встраиванию средств
управления данными в приложения, используется специальное средство управления
данными в основной памяти и т.д.
5.4. Проблемы управления данными в сенсорных сетях
В настоящее время исследуются возможности использования сенсорных сетей в
приложениях мониторинга окружающей среды, медицинского мониторинга,
промышленной автоматизации, самоуправляемых групп роботов и интеллектуальных
домов. В этих приложениях основными ресурсами, которые требуется беречь, являются
пропускная способность и энергия. Кроме того, основная часть энергии тратится на
коммуникации, а не на обработку или сохранение данных. Требуется такой способ
управления сенсорными данными, который обеспечивал бы к ним доступ в реальном
времени без потребности массовой передачи данных в центральные узлы.
5.5. История систем управления сенсорными данными и их особенности
Управление сенсорными данными еще не вышло на производственный уровень. Наиболее
интересным и развитым является университетский проект TinyDB [55], выполненный в
университете Беркли совместно с исследовательской лабораторией компании Intel.
Основная идея этой системы состоит в том, что вся сенсорная сеть представляется как
огромная распределенная база данных, каждый узел которой (сенсор) хранит крохотный
объем данных. Запрос к этой базе данных компилируется таким образом, что на каждый
сенсор попадает компонент запроса, имеющий отношение к соответствующей порции
данных. Каждый сенсор сохраняет свой компонент запроса и обрабатывает его в
непрерывном режиме. Конечно, для построения системы, которую можно было бы
использовать в производственном режиме, здесь требуется выполнить ряд научноисследовательских и опытно-конструкторских работ.
6. Системы управления полуструктурированными и
неструктурированными данными
Наряду с наличием огромных объемов структурированных данных, хранимых и
обрабатываемых с использованием традиционных средств СУБД, в мире накоплен
колоссальный объем представленных в электронном виде полуструктурированных и
неструктурированных данных, для эффективной работы с которыми требуются
специальные программные средства.
6.1. XML как общепринятый формат представления полуструктурированных
данных, стандарты XML
В последние десять лет фактическим стандартом представления полуструктурированных
данных является расширяемый язык разметки XML [56]. XML применяется в качестве
формата сообщений в протоколе SOAP [57], являющемся основой технологии Webсервисов, на XML представляется большинство документов, публикуемых в Web, и т.д.
Консорциум World Wide Web [58] разрабатывает и публикует стандарты, определяющие
функциональные возможности средств управления XML-данными. Одной из проблем
XML является то, что эти стандарты очень часто изменяются, а иногда кажутся
перегруженными, как, например, в случае стандарта языка XQuery [59].
6.2. Особенности и подходы систем управления XML-данными
Развитые средства управления XML-данными поддерживаются в основных SQLориентированных СУБД. В Oracle 11g [2] и IBM DB2 v.9 [3] даже поддерживаются
специализированные хранилища XML-данных, позволяющие более эффективно их
обрабатывать. На основе ООСУБД ObjectStore была создана XML-СУБД eXcelon, которая
позже была приобретена компанией Progress Software и, в конечном счете, стала
называться Progress Sonic XML-Server [60].
Для более эффективной и менее тяжеловесной обработки XML-данных разработан ряд
специализированных XML-СУБД, базовым языком которых является XQuery. К числу
наиболее развитых и известных специализированных XML-СУБД относятся Marklogic
[61], X-Hive [62] и Sedna [63, 64]. СУБД Sedna разработана, развивается и внедряется
Институтом системного программирования РАН. У каждого из подходов имеются
собственные достоинства и недостатки, позволяющие эффективно выполнять только
некоторые операции манипулирования XML-данными.
6.3. Проблемы XML-СУБД
Для успешного применения систем управления XML-данными требуется решить ряд
проблем. Из-за потенциальной сложности структуры и различий в потребностях разных
приложений в разных ситуациях требуются разные методы хранения и индексации баз
XML-данных. Нужно понять, в каких ситуациях, и каким образом необходимо
оптимизировать запросы к базам XML-данных. В частности, до сих пор непонятно, нужны
ли XML-СУБД «стоимостные» оптимизаторы запросов наподобие тех, которые
используются в SQL-ориентированных СУБД. Остается открытым вопрос о требуемом
уровне изоляции данных при поддержке транзакционного доступа к базам XML-данных.
6.4. Системы текстового поиска и потребности в поддержке семантики
Традиционно применяемый в информационно-поисковых системах контекстный поиск по
ключевым словам перестает удовлетворять пользователей. Особенно это заметно в
поисковых средствах, ориентированных на работу в Web. Огромные объемы хранимых в
Web текстовых документов приводят к недопустимо высокому уровню погрешностей
поиска. Для решения этой проблемы при поиске должен использоваться не только
контекст, но и семантика документов в виде, например, тезаурусов, онтологий и т.д.
6.5. Краткая характеристика целей и методов направления Semantic Web
Практически параллельно с работами по стандартизации XML основатель консорциума
World Wide Web Тим Бернерс-Ли (Tim Berners-Lee) сформулировал понятие Semantic Web
и инициировал исследования в этом направлении. В основе предполагаемого им будущего
лежит способность машин не только читать, но и понимать содержание Web-сайтов,
причем достигнуть этого нужно не путем создания программ искусственного интеллекта,
моделирующих деятельность человека, а через использование средств выражения
семантики данных и их связей [65].
В начале развития направления Semantic Web предполагалось, что публикации в Internet
будут сопровождаться сравнительно формально представленными аннотациями,
позволяющими автоматически распознавать семантическое содержание текстов. Для этого
был разработаны язык описания RDF [66] и язык представления онтологий OWL [67].
Однако оказалось, что даже при наличии этих языковых средств и поддерживающих их
механизмов находится мало желающих вручную описывать семантику документов.
Поэтому стало активно развиваться направление интеллектуального анализа текстов (text
mining) для автоматического обнаружения их семантики [68]. Добываемая таким образом
семантика текстов представляется, например, на языке RDF и в дальнейшем используется
для обеспечения более качественного поиска.
6.6. Проблемы семантически обогащенных систем
Для выполнения анализа текстов и поддержки поиска с использованием семантики
приходится иметь дело с огромными объемами текстов. Для этого непригодны ни
традиционные файловые системы, ни традиционные СУБД. Первыми примерами систем
управления данными, специализированными для обработки текстов, являются MapReduce [69], Google File System [70] компании Google и конкурирующие с ними открытые
разработки компании Yahoo! Hadoop Map-Reduce, Hadoop Distributed File System [71].
Необходимо продолжать исследовать новые средства анализа текстов с целью извлечения
из них семантики, а также изучать требуемые свойства систем управления данными.
7. Фундаментальные проблемы управления данными
В соответствии с мнением ведущих исследователей сообщества баз данных [74-75] и
последними наиболее авторитетными международными конференциями в области
управления данными (International Conference on Very Large Data Bases [76], ACM
SIGMOD International Conference on Management of Data [77], International Conference on
Data Engineering [78]) в области управления данными имеется несколько
фундаментальных проблем.
7.1. Интеграция текста, данных, кода и потоков
Пора прекратить встраивать новые конструкции в старую реляционную архитектуру.
Нужно переосмыслить базовую архитектуру СУБД с целью поддержки
структурированных данных; текстовых, пространственных, темпоральных и
мультимедийных данных; процедурных данных, т.е. типов данных и инкапсулирующих
их методов; триггеров; потоков и очередей данных как равноправных компонентов
первого сорта внутри архитектуры СУБД (как на уровне интерфейсов, так и на уровне
реализации).
7.2. Интеграция информации
Требуется интеграция, возможно, миллионов информационных источников «на лету». В
связи с этим существует множество нерешенных проблем: семантическая
неоднородность; неполнота и неточность данных; ограниченность доступа к
конфиденциальным данным и т.д.
7.3. Сенсорные данные и сенсорные сети
При запросе данных у сенсорной сети часто более выгодным является полное
распределение вычислений по отдельным узлам: сеть становится своего рода машиной баз
данных. При вычислении запроса необходимо уметь изменять план запроса при
изменении сети по причине выхода из строя сенсора или его отключения от сети.
Усложняется и интеграция информации, потому что сенсоры обычно не являются
полностью калиброванными.
7.4. Использование неточных данных
СУБД должны обеспечивать встроенную поддержку неточных данных. Обработка
запросов должна базироваться на вероятностной, недетерминированной модели;
процессор запросов должен накапливать факты, чтобы обеспечивать все лучшие и лучшие
ответы на запросы пользователей. У пользователей должна иметься возможность задания
неточных запросов, и процессор запросов должен относиться к этому как к
дополнительному источнику неполноты и неточности. При выдаче неточного ответа на
запрос пользователя система должна характеризовать уровень его точности, чтобы
пользователи могли понять, достаточна ли она для их потребностей. Аналогом может
быть уровень релевантности ответа, выдаваемый информационно-поисковыми системами.
7.5. Самоадаптация
Задачей исследовательского сообщества является отказ от «ручек управления» в СУБД:
все настроечные решения должны приниматься системой автоматически под влиянием
принятой по умолчанию политики, такой как, например, относительная важность
реактивности и пропускной способности.
7.6. Безопасность и конфиденциальность данных
Решения о правомерности доступа должны основываться не только на том, кто
запрашивает данные, но и на том, что он собирается с ними делать. Сообщество баз
данных могло бы предложить декларативные системы, определяющие цели запроса
данных, поскольку уже имеется опыт разработки ориентированных на данные
декларативных спецификаций для других целей.
Как видно из предыдущих разделов, многие из этих фундаментальных проблем уже
частично решены или находятся в состоянии исследования. Тем не менее, до их полного
решения еще далеко, и требуется расширять и углублять исследовательскую работу.
Литература
1. С.Д. Кузнецов. Базы данных: языки и модели. Москва, Бином, 2008
2. Марк Ривкин. Новая версия СУБД Oracle - Oracle 11g. Oracle Magazine - Русское
издание (Май Июнь 2007).
3. К. М. Саракко. Что нового в DB2 Viper.
4. Мишель Дамлер. Microsoft SQL Server 2008. Общие сведения о продукте.
5. Oracle Real Application Clusters Administration and Deployment Guide. 11g Release 1
(11.1).
6. Whei-Jen Chen, Alain Fisher, Aman Lalla, Andrew D McLauchlan, Doug Agnew.
Database Partitioning, Table Partitioning, and MDC for DB2 9.
7. Query Optimization in Oracle Database10g Release 2. An Oracle White Paper June 2005.
8. Brian Babcock, Surajit Chaudhuri. Towards a Robust Query Optimizer: A Principled and
Practical Approach. Proceedings of the 2005 ACM SIGMOD International Conference
on Management of Data, pp. 119–130.
9. V. Markl, G. M. Lohman, and V. Raman. LEO: An autonomic query optimizer for DB2.
IBM Systems Journal, Volume 42, Number 1, 2003. Имеется перевод на русский язык.
Виджайшанкар Раман, Волкер Маркл, Гай Лохман. LEO: самонастраивающийся
оптимизатор запросов для DB2. Открытые системы, N 4, 2003
10. Surajit Chaudhuri, Vivek Narasayya. Self-Tuning Database Systems: A Decade of
Progress. Proceedings of the 33rd International Conference on Very Large Data Bases,
pp. 3-14.
11. С.Кузнецов. Развитие идей и приложений реляционной СУБД System R.
12. Иван Бодягин. Версионность в Yukon. RSDN Magazine #6-2003.
13. Oracle 11g Release 1 (11.1) Database Concepts. Chapter 13. 13 Data Concurrency and
Consistency.
14. Аруп Нанда. SecureFiles: новые большие объекты.
15. Электронная документация по SQL Server 2008. Общие сведения о FILESTREAM.
16. С.Д. Кузнецов. Объектно-реляционные базы данных: прошедший этап или
недооцененные возможности? Труды Института системного программирования, т.
13, часть 2, М., ИСП РАН, 2007, стр. 115-140.
17. Б.Б.Костенко, С.Д. Кузнецов. История и актуальные проблемы темпоральных баз
данных. Труды Института системного программирования, т. 13, часть 2, М., ИСП
РАН, 2007, стр. 77-114.
18. Oracle 11g. Oracle Flashback Technology.
19. Электронная документация по SQL Server 2005 (сентябрь 2007 г.). Основные
понятия компонента Full-Text Search.
20. Дуглас Шерер и Кэрол Бреннан. Изучение основ Oracle Text.
21. DB2 Net Search Extender.
22. Oracle TimesTen In-Memory Database. Обзор.
23. СУБД ЛИНТЕР. Технический обзор.
24. Павел Пасечник, Михаил Ермаков. Особенности функционирования СУБД
ЛИНТЕР в операционных системах реального времени. Труды Тринадцатой
технической конференций «Корпоративные базы данных-2008».
25. Официальный сайт MySQL.
26. Официальный сайт PostgreSQL.
27. Официальный сайт Firebird.
28. Корпорация Sun Microsystems завершила сделку по приобретению компании
MySQL. Пресс-релиз Sun Microsystems от 26 февраля 2008 г.
29. MySQL Enterprise Server 5.1.
30. Олег Бартунов. Что такое PostgreSQL?
31. Олег Бартунов, Федор Сигаев, Николай Самохвалов, Иван Золотухин, Российская
группа PostgreSQL. Труды Тринадцатой технической конференций
«Корпоративные базы данных-2008».
32. EnterpriseDB Corporation.
33. Владислав Хорсун. Firebird 2.1: новые возможности. 2-ая Российская Конференция
по Firebird и InterBase. 23 ноября 2007 г.
34. А.В.Замулин. Системы программирования баз данных и знаний Новосибирск:
Наука: Сиб. отд-е. 1990.
35. J.W. Schmidt and F. Matthes. The DBPL Project: Advances in Modular Database
Programming. Information Systems, 19(2):121-140, 1994
36. Atkinson, M.P., Bailey, P.J., Chisholm, K.J., Cockshott, W.P. & Morrison, R. “PS-algol:
A Language for Persistent Programming”. In Proc. 10th Australian National Computer
Conference, Melbourne, Australia (1983) pp 70-79.
37. The Object Data Standard: ODMG 3.0. Edited by R.G.G. Cattel, Douglas K. Barry.
Morgan Kauffmann Publishers, 2000
38. GemStone Systems Inc.
39. Objectivity, Inc.
40. Versant Corp.
41. Progress Software Corporation. Progress ObjectStore.
42. Сергей Кузнецов. «Объектны» ли объектные расширения языка SQL?
43. ODBMS.ORG: образовательный и исследовательский портал.
44. db4objects, Inc.
45. ICOODB: International Conference on Object Databases, March 13-14, 2008, Berlin.
46. Michael Card. Next-Generation Object Database Standardization. Object Database
Technology Working Group White Paper.
47. William Cook, Ali Ibrahim. Integrating Programming Languages and Databases: What is
the Problem?. Имеется перевод С.Д. Кузнецова. Вильям Кук, Али Ибрагим.
Интеграция языков программирования с базами данных: в чем состоит проблема?
48. Ted Neward. The Vietnam of Computer Science. Имеется пересказ С.Д. Кузнецова.
Тед Ньюард. Вьетнам компьютерной науки.
49. Malcolm Atkinson, Francois Bancilhon, David DeWitt, Klaus Dittrich, David Maier, and
Stanley Zdonik: “The Object-Oriented Database System Manifesto”, Proc. 1st
International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan
(1989). New York, N.Y.: Elsevier Science (1990). Имеется перевод на русский язык.
М. Аткинсон и др. «Манифест систем объектно-ориентированных баз данных»,
СУБД, No. 4, 1995.
50. The LINQ Project.
51. D. Abadi, D. Carney, U. Cetintemel, M. Cherniack, C. Convey, C. Erwin, E. Galvez, M.
Hatoun, J. Hwang, A. Maskey, A. Rasin, A. Singer, M. Stonebraker, N. Tatbul, Y. Zing,
R.Yan, and S. Zdonik. Aurora: A Data Stream Management System (demo description).
In Proceedings of the 2003 ACM SIGMOD Conference on Management of Data, San
Diego, CA, 2003.
52. S. Chandrasekaran, O. Cooper, A. Deshpande, M. J. Franklin, J. M. Hellerstein, W.
Hong, S. Krishnamurthy, S. R. Madden, V. Raman, F. Reiss, and M. A. Shah.
TelegraphCQ: Continuous Dataflow Processing for an Uncertain World. In Proc. of the
1st CIDR Conference, Asilomar, CA, 2003.
53. StreamBase Systems.
54. Michael Stonebraker, Uğur Çetintemel. «One Size Fits All»: An Idea Whose Time Has
Come and Gone. Имеется перевод С.Д. Кузнецова. Майкл Стоунбрейкер, Угур
Кетинтемел. «Один размер пригоден для всех»: идея, время которой пришло и
ушло.
55. S. Madden, M. Franklin, J. Hellerstein, and W. Hong. The Design of an Acquisitional
Query Processor for Sensor Networks. In Proceedings of SIGMOD, San Diego, CA,
2003.
56. Extensible Markup Language (XML) 1.0 (Fourth Edition). W3C Recommendation.
Имеется перевод на русский язык второй редакции описания. Расширяемый язык
разметки (XML) 1.0 (вторая редакция).
57. SOAP Version 1.2 specification.
58. Консорциум World Wide Web.
59. XQuery 1.0: An XML Query Language. W3C Recommendation 23 January 2007.
60. Progress Sonic XML Server.
61. Mark Logic.
62. X-Hive Corporation.
63. Sedna Native Database System.
64. М. Гринев, С. Кузнецов, А. Фомичев. XML-СУБД Sedna: технические особенности
и варианты использования. Открытые системы, N 8, 2004, стр. 36-43.
65. Tim Berners-Lee. Semantic Web Road map. Имеется перевод на русский язык. Тим
Бернерс-Ли. Дорожная карта семантического WEB'а.
66. Resource Description Framework.
67. OWL Web Ontology Language.
68. Владислав Рябышкин, Сергей Танков, Сергей Киселев, Николай Ильин.
Технологии извлечения знаний из текста. Открытые системы, N 6, 2006.
69. Jeffrey Dean and Sanjay Ghemawat. MapReduce: Simplified Data Processing on Large
Clusters.
70. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Google File System.
71. Hadoop Project Description.
72. Сергей Кузнецов. Крупные проблемы и текущие задачи исследований в области
баз данных.
73. The Lowell Database Research Self-Assessment Meeting.
74. International Conference on Very Large Data Bases.
75. ACM SIGMOD/PODS 2007 Conference.
76. 23rd International Conference on Data Engineering.