Принято выделять три поколения СУБД:
I. Поколение. Сетевые и иерархические системы БД, широко распространенные в 70-е годы, получили название - системы БД первого поколения. Это были первые системы, предлагавшие развитую функциональность СУБД в рамках единой системы, с языками определения и манипулирования данными для набора записей. Назовем некоторые наиболее общие характеристики ранних систем:
- Эти системы активно использовались в течение многих лет, дольше, чем используется какая-либо из реляционных СУБД.
- Все ранние системы не основывались на каких-либо абстрактных моделях. Понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
- В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД.
- Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
- После появления реляционных систем большинство ранних систем было оснащено «реляционными» интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.
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. Мультимедийные запросы. Очевидно, что объем мультимедийных данных (изображения, аудио, видео и т.д.) значительно возрастает. Проблемой сообщества баз данных является создание простых способов анализа, обобщения, поиска и обозрения электронных подборок мультимедийнойинформации, относящейся к некоторому объекту.