Тенденции в
мире систем управления базами данных
Тенденции в
мире систем управления базами данных
Сергей Кузнецов
Системы управления
базами данных (СУБД) играют исключительную
роль в организации современных
промышленных, инструментальных и
исследовательских информационных систем.
Тематика СУБД поистине безгранична. В
предлагаемом коротком обзоре описываются
наиболее интересные направления исследований
и разработок.
1. Реляционные
системы
Хотя многие
полагают, что реляционные СУБД,
являясь наиболее распространенным
современным аппаратом построения информационных
систем, не представляют уже интереса
в научном отношении, остается еще много
нерешенных или решенных не полностью
проблем. Об этом свидетельствует поток
статей, посвященных тематике чисто реляционных
систем, а также активная деятельность
компаний-производителей коммерческих
реляционных систем, стремящихся улучшать
свои продукты и придавать им новые качества.
Продолжающаяся
работа исследователей затрагивают
вопросы оптимизации запросов, новых
алгоритмов выполнения реляционных операций,
оптимизации структур хранения данных
и другие аспекты, непосредственно определяющие
эффективность СУБД. Те же самые вопросы
занимают и разработчиков коммерческих
СУБД, которые, кроме того озабочены и
более прикладными проблемами. Рассмотрим
немного более подробно (но без технических
деталей) существо некоторых из этих вопросов
и то, каким образом они решаются в наиболее
развитых коммерческих продуктах.
1.1. Стандартизация
языка SQL
Для всех
современных коммерческих реляционных
СУБД основным языком доступа к базам
данных является SQL. В 1989 г. появился первый
международный стандарт этого языка, и
большинство производителей СУБД объявляют
свои системы соответствующими этому
стандарту. Но стандарт 1989 г. был довольно
ограниченным (например, в него не входили
средства манипулирования схемой БД, динамический
SQL и т.д.), а многие вошедшие в стандарт
аспекты языка были специфицированы недостаточно
строго. Поэтому разные реализации различаются
в достаточно важных вопросах.
В 1992 г.
был принят новый стандарт SQL-92.
Этот язык существенно более
сложен, чем SQL-89, а конструкции
SQL-92 специфицированы в стандарте
существенно более полно. Первой
компанией, которая объявила о
соответствии своего продукта
новому стандарту, была компания
Oracle со своей седьмой версией (это произошло
прямо в 1992 г.). Теперь и все остальные компании
обещают вскоре выпустить продукты, соответствующие
стандарту SQL-92.
Кроме того,
как это бывает всегда, производители
стремятся добавить к своим
продуктам качества, превышающие требования
стандарта. Например, современные версии
Oracle и Ingres содержат возможности определения
тригеров (подробнее об этом см. ниже),
в системе uniVerse компании VMark поддерживается
расширенная ненормализованная реляционная
модель и т.д. Другими словами, компании
стремятся смотреть в будущее, предвидя
требования следующего стандарта SQL (его
условно называют SQL-3; ожидалось принятие
этого стандарта в 1995 г., но теперь уже
говорят про 1997 г.).
1.2. Использование
мультипроцессорных организаций
Уже довольно
давно развитые коммерческие
СУБД основываются на архитектуре
"клиент-сервер". При этой организации
наиболее трудоемкие операции
над базами данных выполняются
на выделенном компьютере-сервере,
который должен быть достаточно
мощным и обладать соответствующим набором
ресурсов основной и внешней памяти. До
поры серверная часть СУБД обладала простой
организацией: запросы, поступающие из
клиентских частей системы, обрабатывались
последовательно с небольшой оптимизацией
для совмещения процессорной работы с
работой устройств внешней памяти.
Однако с
появлением на рынке мультипроцессорных
симметричных аппаратных архитектур,
производители СУБД были вынуждены
пересмотреть организацию своих
серверов, допустив в них внутреннюю
параллельность. Естественно, это требует
очень основательного перепроектирования
системы с ее существенным усложнением.
Заметим, что в большинстве случаев компании
пошли на это после появления в ОС UNIX механизма
"легковесных" процессов (threads).
О серьезности
этой работы говорит тот факт, что, например,
в компании Informix было образовано новое
подразделение, занимающееся исключительно
вопросами распараллеливания работы серверов.
1.3. Интеграция
и интероперабильность
Чтобы убедить
новых потенциальных пользователей
использовать новые продукты, компании-
производители должны обеспечить решение
проблемы использования старых баз данных.
В принципе эта проблема является частным
видом проблемы включения в открытые системы
компонентов, которые не были на это рассчитаны
с самого начала.
В большинстве
случаев предлагаемые решения
основываются на использовании
индустриальных стандартов распределенных
объектных систем (например, стандарта
CORBA, разработанного OMG). Тем не менее
производители СУБД вынуждены
решать многочисленные проблемы для вхождения
их систем в новые интегрированные среды.
2. Постреляционные
системы
В этом
разделе очень кратко рассматриваются
основные направления исследований
и разработок в области так
называемых постреляционных систем,
т.е. систем, относящихся к следующему
поколению (хотя термин next-generation DBMS зарезервирован
для некоторого подкласса современных
систем).
2.1. Базы сложных
объектов, реляционная модель с
отказом от первой нормальной
формы
Одним из
основных положений реляционной
модели данных является требование нормализации
отношений: поля кортежей могут содержать
лишь атомарные значения. Для традиционных
приложений реляционных СУБД - банковских
систем, систем резервирования и т.д. -
это вовсе не ограничение, а даже преимущество,
позволяющее проектировать экономные
по памяти БД с предельно понятной структурой.
Запросы с соединениями в таких системах
сравнительно редки, для динамической
поддержки целостности используются соответствующие
средства SQL.
Однако с
появлением эффективных реляционных
СУБД их стали пытаться использовать и
в менее традиционных прикладных системах
- САПР, системы искусственного интеллекта
и т.д. Такие системы обычно оперируют
со сложно структурированными объектами,
для реконструкции которых из плоских
таблиц реляционной БД приходится выполнять
запросы, почти всегда требующие соединения
отношений. В соответствии с требованиями
разработчиков нетрадиционных приложений
появилось направление исследований баз
сложных объектов. Это очень обширная
область исследований, в которой затрагиваются
вопросы моделей данных, структур данных,
языков запросов, управления транзакциями,
журнализации и т.д. Во многом эта область
соприкасается с областью объектно-ориентированных
БД.
2.2. Активные
базы данных
По определению
БД называется активной, если СУБД по отношению
к ней выполняет не только те действия,
которые явно указывает пользователь,
но и дополнительные действия в соответствии
с правилами, заложенными в саму БД.
Легко видеть,
что основа этой идеи содержалась
в языке SQL времени System R. На самом деле,
что есть определение триггера или условного
воздействия как не введение в БД правила,
в соответствии с которым СУБД должна
производить дополнительные действия?
Плохо лишь то, что на самом деле триггеры
не были полностью реализованы ни в одной
из известных систем, даже и в System R. И это
не случайно, потому что реализация такого
аппарата в СУБД очень сложна, накладна
и не полностью понятна.
Среди вопросов,
ответы на которые до сих
пор не получены, следующие. Как
эффективно определить набор вспомогательных
действий, вызываемых прямым действием
пользователя? Каким образом распознавать
циклы в цепочке "действие-условие-действие-..."
и что делать при возникновении таких
циклов? В рамках какой транзакции выполнять
дополнительные условные действия и к
бюджету какого пользователя относить
возникающие накладные расходы?
Масса проблем
не решена даже для сравнительно
простого случая реализации триггеров
SQL, а задача ставится уже гораздо
шире. По существу, предлагается
иметь в составе СУБД продукционную
систему общего вида, условия и действия
которой не ограничиваются содержимым
БД или прямыми действиями над ней со стороны
пользователя. Например, в условие может
входить время суток, а действие может
быть внешним, например, вывод информации
на экран оператора. Практически все современные
работы по активным БД связаны с проблемой
эффективной реализации такой продукционной
системы.
Вместе с
тем, по нашему мнению, гораздо
важнее в практических целях
реализовать в реляционных СУБД
аппарат триггеров. Заметим, что в проекте
стандарта SQL3 предусматривается существование
языковых средств определения условных
воздействий. Реализация и будет первым
практическим шагом к активным БД (как
мы отмечали в разд.1, уже появились соответствующие
коммерческие реализации).
2.3. Дедуктивные
базы данных
По определению,
дедуктивная БД состоит из
двух частей: экстенсиональной, содержащей
факты, и интенсиональной, содержащей
правила для логического вывода
новых фактов на основе экстенсиональной
части и запроса пользователя.
Легко видеть,
что при таком общем определении
SQL-ориентированную реляционную
СУБД можно отнести к дедуктивным
системам. Действительно, что есть
определенные в схеме реляционной
БД представления как не интенсиональная
часть БД.
Основным отличием
реальной дедуктивной СУБД от реляционной
является то, что и правила интенсиональной
части БД, и запросы пользователей могут
содержать рекурсию. Именно возможность
рекурсии делает реализацию дедуктивной
СУБД очень сложной и во многих случаях
эффективно неразрешимой проблемой.
Мы не будем
здесь более подробно рассматривать
конкретные проблемы, применяемые
ограничения и используемые методы
в дедуктивных системах. Отметим
лишь, что обычно языки запросов
и определения интенсиональной
части БД являются логическими (поэтому
дедуктивные БД часто называют логическими).
Имеется прямая связь дедуктивных БД с
базами знаний (интенсиональную часть
БД можно рассматривать как БЗ). Более
того, трудно провести грань между этими
двумя сущностями; по крайней мере, общего
мнения по этому поводу не существует.
Какова же
связь дедуктивных БД с реляционными
СУБД, кроме того, что реляционная
БД является вырожденным частным
случаем дедуктивной? Основным
является то, что для реализации
дедуктивной СУБД обычно применяется
реляционная система. Такая система выступает
в роли хранителя фактов и исполнителя
запросов, поступающих с уровня дедуктивной
СУБД. Между прочим, такое использование
реляционных СУБД резко актуализирует
задачу глобальной оптимизации запросов.
При обычном
применении реляционной СУБД запросы
обычно поступают на обработку по одному,
поэтому нет повода для их глобальной
(межзапросной) оптимизации. Дедуктивная
же СУБД при выполнении одного запроса
пользователя в общем случае генерирует
пакет запросов к реляционной СУБД, которые
могут оптимизироваться совместно.
Конечно,
в случае, когда набор правил
дедуктивной БД становится велик
и их невозможно разместить
в оперативной памяти, возникает
проблема управления их хранением
и доступом к ним во внешней
памяти. Здесь опять же может быть применена
реляционная система, но уже не слишком
эффективно. Требуются более сложные структуры
данных и другие условия выборки. Известны
частные попытки решить эту проблему,
но общего решения пока нет.
2.4. Темпоральные
базы данных
Обычные БД
хранят мгновенный снимок модели
предметной области. Любое изменение
в момент времени t некоторого
объекта приводит к недоступности
состояния этого объекта в
предыдущий момент времени. Самое
интересное, что на самом деле
в большинстве развитых СУБД предыдущее
состояние объекта сохраняется в журнале
изменений, но возможности доступа со
стороны пользователя нет.
Конечно,
можно явно ввести в хранимые
отношения явный временной атрибут
и поддерживать его значения
на уровне приложений. Более того,
в большинстве случаев так и поступают.
Недаром в стандарте SQL появились специальные
типы данных date и time. Но в таком подходе
имеются несколько недостатков: СУБД не
знает семантики временного поля отношения
и не может контролировать корректность
его значений; появляется дополнительная
избыточность хранения (предыдущее состояние
объекта данных хранится и в основной
БД, и в журнале изменений); языки запросов
реляционных СУБД не приспособлены для
работы со временем.
Существует
отдельное направление исследований
и разработок в области темпоральных БД.
В этой области исследуются вопросы моделирования
данных, языки запросов, организация данных
во внешней памяти и т.д. Основной тезис
темпоральных систем состоит в том, что
для любого объекта данных, созданного
в момент времени t1 и уничтоженного в момент
времени t2, в БД сохраняются (и доступны
пользователям) все его состояния во временном
интервале [t1,t2].