Поколения СУБД и направления исследований

Принято выделять три поколения СУБД:

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

1. Эти системы активно использовались в течение многих лет, дольше, чем используется какая-либо из реляционных СУБД.
2. Все ранние системы не основывались на каких-либо абстрактных моделях. Понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
3. В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД.
4. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
5. После появления реляционных систем большинство ранних систем было оснащено «реляционными» интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.

II. Поколение. В 80-е годы системы первого поколения были существенно потеснены современным семейством реляционных СУБД, называемых системами БД второго поколения. Типичные представители многопользовательских профессиональных систем второго поколения – DB2, INGRES, ORACLE, Informix и др.

В нашей стране представление о реляционных СУБД у большинства программистов сложилось на основе опыта использования систем на платформе персональных компьютеров, таких как dBASE, FoxBASE, FoxPro, Paradox, Clipper, Clarion, а позже Access. Причины такой популярности можно видеть как в широком распространении персональных компьютеров, так и в относительной простоте и легкости изучения и освоения самих персональных СУБД. Очень часто персональные СУБД использовались (да и сейчас кое-где используются) для автоматизации таких задач, например, в финансовой сфере, которые требуют многопользовательских профессиональных систем.

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

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

Осознавая эти ограничения и недостатки реляционных систем, исследователи в области баз данных выполняют многочисленные проекты, основанные на идеях, выходящих за пределы реляционной модели данных

III. Поколение. Термин «системы следующего (или третьего) поколения» вошел в жизнь после опубликования группой известных специалистов в области БД «Манифеста систем баз данных третьего поколения». В целом можно сказать, что СУБД следующего поколения - это прямые наследники реляционных систем. В число требований к СУБД третьего поколения входят полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность управления сложными объектами и т.д.

Основными направлениями систем третьего поколения, обладающими некоторыми разными характеристиками, являются:

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

- Генерация систем баз данных, ориентированных на приложения. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами. Существуют два экспериментальных прототипа «генерационных» систем - Genesis и Exodus. Обе эти системы основаны прежде всего на принципах модульности и точного соблюдения установленных интерфейсов. По сути дела, системы состоят из минимального ядра (развитой файловой системы в случае Exodus) и технологического механизма программирования дополнительных модулей. В проекте Exodus этот механизм основывается на системе программирования E, которая является простым расширением С++, поддерживающим стабильное хранение данных во внешней памяти. Вместо готовой СУБД предоставляется набор "полуфабрикатов" с согласованными интерфейсами, из которых можно сгенерировать систему, максимально отвечающую потребностям приложения

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

- Объектно-ориентированные СУБД. Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х. Однако наиболее активно это направление развивается в последние годы. В настоящее время ведется очень много экспериментальных и производственных работ в области объектно-ориентированных СУБД. На рынке представлено свыше 25 систем ООБД. Среди них — система GemStone компании Servio, ONTOS компании Ontos, ObjectStore компании Object Design, O2, ORION, Iris. Кроме того, системы управления реляционными базами данных, разработанные компаниями Oracle, Microsoft, Borland, Informix, включали объектно-ориентированные средства. Многие из этих продуктов появились еще во второй половине 80-х годов, и сегодня, по прошествии почти полутора десятилетий разработки они все еще не вступили в пору зрелости; в этом — одна из причин того, что по сей день мировой рынок реальных приложений не торопится принимать системы ООБД.

Широкое использование Интернет в различных сферах деятельности ставит перед разработчиками СУБД следующие проблемы:

1. Интеграция текста, данных, кода и потоков. В области СУБД основное внимание всегда уделялось организации, хранению, анализу и выборке структурированных данных. Развитие Web-приложений продемонстрировало важность более сложных типов данных: текстов, изображений, темпоральных, аудио- и видеоданных.

2. Интеграция информации. Типичным подходом к интеграции информации в масштабах предприятия является построение хранилищ (DataWarehouse) витрин (data mart) данных на основе извлечения операционных данных, их трансформации к единой схеме и загрузке данных в хранилище (процедура ETL - extraction, transfotamation, loading). Этот подход пригоден для использования на предприятии с несколькими десятками операционных баз данных, находящихся под единым контролем. В Интернет требуется производить интеграцию информации между несколькими предприятиями. Как правило, организации не позволят в массовом порядке извлекать данные из своих операционных баз данных, к ним можно будет адресовать лишь одиночные запросы. В результате потребуется интеграция, возможно, миллионов информационных источников «на лету». В связи с этим существует множество нерешенных проблем: семантическая неоднородность; неполнота и неточность данных; ограниченность доступа к конфиденциальным данным и т.д.

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