Выбор среды разработки информационной базы интеллектуальной системы управления.

За исключением некоторых систем, иерархические СУБД почти полностью ушли с рыночной арены, а также и из сознания разработчиков приложений. Лидирующее положение два последних десятилетия занимает реляционная модель данных, представленная на рынке большими и маленькими коммерческими пакетами, такими как Oracle, Sybase, Access и др. Несмотря на полный коммерческий успех, многие эксперты ожидают изменений основополагающих принципов технологии БД в ближайшие пять лет.

В качестве недостатков реляционных СУБД отмечаются следующие:

- негибкость структуры для развивающихся БД;

- затруднения в построении концептуальной модели для объектов с многочисленными связями «многие - ко – многим»;

- неестественность табличного представления для разреженных массивов данных.

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

Что касается объектно-ориентированных СУБД, то можно сказать, что теоретическая модель для них на сегодняшний день не разработана, а прикладные коммерческие продукты, провозглашенные как объектно-ориентированные, либо таковыми не являются, либо незрелы. Заявления об их будущей конкурентоспособности носят явно предположительный характер. Крупнейшие разработчики СУБД стали встраивать в свои продукты поддержку объектной ориентации, по соображениям совместимости предполагая смешанный подход – объектно-реляционный.

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

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

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

Несмотря на все вышесказанные недостатки реляционной модели данных, всё же она является наиболее современной на сегодняшний день. Поэтому, нет смысла использовать ранние модели ввиду их неконкурентоспособности по сравнению с реляционными, и нет смысла использовать системы, провозгласившие себя ОО, ввиду того, что под ними нет теоретической основы. Но и строить БД на основе чисто реляционной структуры было бы то же неуместно, ввиду её нереальности отображения семантики мира. Поэтому необходимо найти систему, которая основывалась на реляционном подходе и имела определённые разработки в объектно-ориентированных направлениях. При этом реляционный подход к организации БД должен быть наиболее популярным. И такой подход уже давно развит. Он основан на использовании техники B-деревьев. С точки зрения внешнего логического представления B-дерево - это сбалансированное сильно ветвистое дерево во внешней памяти. Сбалансированность означает, что длина пути от корня дерева к любому его листу одна и та же. Ветвистость дерева - это свойство каждого узла дерева ссылаться на большое число узлов-потомков. Поиск в B-дереве - это прохождение от корня к листу в соответствии с заданным значением ключа. Заметим, что поскольку деревья сильно ветвистые и сбалансированные, то для выполнения поиска по любому значению ключа потребуется одно и то же (и обычно небольшое) число обменов с внешней памятью. Более точно, в сбалансированном дереве, где длины всех путей от корня к листу одни и те же, если во внутренней странице помещается n ключей, то при хранении m записей требуется дерево глубиной где вычисляет логарифм m по основанию n. Если n достаточно велико (обычный случай), то глубина дерева невелика, и производится быстрый поиск. Основной «изюминкой» B-деревьев является автоматическое поддержание свойства сбалансированности.

Одной из систем удовлетворяющих выше поставленным условиям является СУБД Cache.