В качестве недостатков реляционных СУБД отмечаются следующие:
- негибкость структуры для развивающихся БД;
- затруднения в построении концептуальной модели для объектов с многочисленными связями «многие - ко – многим»;
- неестественность табличного представления для разреженных массивов данных.
В качестве конкурентов реляционных СУБД, иерархические СУБД уже не рассматриваются, сетевые СУБД рассматриваются как конкурент, частично сдавший свои позиции и объектно-ориентированные СУБД как возможный потенциальный конкурент следующего десятилетия.
Что касается объектно-ориентированных СУБД, то можно сказать, что теоретическая модель для них на сегодняшний день не разработана, а прикладные коммерческие продукты, провозглашенные как объектно-ориентированные, либо таковыми не являются, либо незрелы. Заявления об их будущей конкурентоспособности носят явно предположительный характер. Крупнейшие разработчики СУБД стали встраивать в свои продукты поддержку объектной ориентации, по соображениям совместимости предполагая смешанный подход – объектно-реляционный.
Однако, это существенно ограничивает заявленную мощь объектно-ориентированного программирования, т.к. реляционное наследие сказывается на всей работе СУБД: новые типы данных требуют специального тестирования и вставки в ядро СУБД, что не является лучшим способом наращивания функциональных возможностей, сами ядра таких СУБД оптимизированы для выполнения операций над таблицами, сомнителен также успех работы с запросами, в которые включено большое количество пользовательских объектов. Обобщая вышесказанное, можно предположить, что конец карьеры реляционных СУБД достаточно очевиден, а вот что придет им на смену - совершенно не очевидно.
Причина неэффективности СУБД состоит в противоречии между результатами проектирования БД, отражающими статичное состояние предметной области окружающего мира и реальными взаимодействиями пользователей с БД, отражающими состояние предметной области в ее динамике. При превышении системой некоторого критического уровня сложности попытки внесения в нее изменений будут приводить к сбоям и ошибкам, исправление которых, в свою очередь, будет порождать новые сбои и ошибки с коэффициентом размножения больше единицы. Собственно именно реляционные СУБД здесь не при чем – та же граница эффективности будет иметь место для БД, построенных на основе любой парадигмы, если эта парадигма будет предусматривать стадию проектирования как отражение проектировщиком предметной области в концептуальную схему. На сегодняшний день к таковым парадигмам относятся и иерархическая, и реляционная, и сетевая, и объектно-ориентированная (в той ее части, которая на сегодня имеется).
В объектно-ориентированных СУБД ставится задача (в числе других) создания модели данных, позволяющей отражать сложные аспекты объектов и связей предметного мира, для чего, в свою очередь, создаются не менее сложные структуры их физического хранения, манипулирования и поддержания целостности. Напрашивается очевидная мысль о том, что стоит ли вообще учитывать семантику предметного мира при хранении данных и не достаточно ли будет существующих физических структур, если несколько изменить взгляд на принципы построения СУБД.
Несмотря на все вышесказанные недостатки реляционной модели данных, всё же она является наиболее современной на сегодняшний день. Поэтому, нет смысла использовать ранние модели ввиду их неконкурентоспособности по сравнению с реляционными, и нет смысла использовать системы, провозгласившие себя ОО, ввиду того, что под ними нет теоретической основы. Но и строить БД на основе чисто реляционной структуры было бы то же неуместно, ввиду её нереальности отображения семантики мира. Поэтому необходимо найти систему, которая основывалась на реляционном подходе и имела определённые разработки в объектно-ориентированных направлениях. При этом реляционный подход к организации БД должен быть наиболее популярным. И такой подход уже давно развит. Он основан на использовании техники B-деревьев. С точки зрения внешнего логического представления B-дерево - это сбалансированное сильно ветвистое дерево во внешней памяти. Сбалансированность означает, что длина пути от корня дерева к любому его листу одна и та же. Ветвистость дерева - это свойство каждого узла дерева ссылаться на большое число узлов-потомков. Поиск в B-дереве - это прохождение от корня к листу в соответствии с заданным значением ключа. Заметим, что поскольку деревья сильно ветвистые и сбалансированные, то для выполнения поиска по любому значению ключа потребуется одно и то же (и обычно небольшое) число обменов с внешней памятью. Более точно, в сбалансированном дереве, где длины всех путей от корня к листу одни и те же, если во внутренней странице помещается n ключей, то при хранении m записей требуется дерево глубиной
где вычисляет логарифм m по основанию n. Если n достаточно велико (обычный случай), то глубина дерева невелика, и производится быстрый поиск. Основной «изюминкой» B-деревьев является автоматическое поддержание свойства сбалансированности.Одной из систем удовлетворяющих выше поставленным условиям является СУБД Cache.
Глава 2 Технология создания баз данных
1. Понятие предметной области
Каждая информационная система в зависимости от ее назначения имеет дело с частью реального мира, которую принято называть предметной областью (ПО) системы. ПО может относится к любому типу организации: банк, университет, завод, магазин и т. д.
Предметная область информационной системы – это совокупность реальных объектов (сущностей), которые представляют интерес для пользователей.
Объект (сущность) – предмет, процесс или явление, о котором собирается информация, необходимая для решения задачи. Объектом может быть человек, предмет, событие.
Каждый объект характеризуется рядом основных свойств – атрибутов. Атрибутом называется поименованная характеристика объекта. Атрибут показывает, какая информация должна быть собрана об объекте. Например, объект – клиент банка; Атрибуты – номер счета, адрес, сумма вклада.
2. Технология анализа предметной области
Первым этапом проектирования базы данных любого типа является анализ предметной области, который заканчивается построением информационной структуры (концептуальной схемы). На данном этапе анализируются вопросы пользователей, выбираются информационные объекты и их характеристики, которые предопределяют содержание проектируемой базы данных. На основе проведенного анализа структурируется предметная область. Анализ предметной области не зависит от программной и технической сред, в которых будет реализовываться база данных.
Анализ предметной области целесообразно разбить на три фазы:
1. анализ концептуальных требований и информационных потребностей;
2. выявление информационных объектов и связей между ними;
3. построение концептуальной модели предметной области и проектирование концептуальной схемы базы данных.
3. Анализ концептуальных требований и информационных потребностей
Требования пользователей к разрабатываемой базе данных представляют собой список запросов с указанием их интенсивности и объемом данных. Эти сведения разработчики базы данных получают в диалоге с ее будущими пользователями. Здесь же выясняются требования к вводу, обновлению и корректировке информации. Требования пользователей уточняются и дополняются при анализе имеющихся и перспективных задач:
Пример 1.Предлагается разработать БД для учета учащихся школы.
Анализ предметной области:
1. Сколько учащихся учится в школе?
2. Сколько классов в школе?
3. Какие распределены учащиеся по тем или иным направлениям в классах?
4. Какие профилирующие дисциплины используются в том или ином классе?
5. Сколько в школе медалистов и какие?
6. Сколько победителей олимпиад и по каким предметам?
7. Участники тех или иных школьных, городских, областных, региональных или российских конкурсов? Победители, призеры?
8. Количество учащихся, поступивших в ВУЗ и в какие?
9. Как часто обновляется информация в БД?
10. Сколько кабинетов в школе? Компьютерных классов?
11. Сколько преподавателей в школе?
12. Как информация, представленная в п. п. 1-11, используется в настоящее время (расписание уроков, факультативов и т. д.) и как собираются ее использовать?
13. Сколько раз в день, сколько человек и кто используются БД?
4. Выявление информационных объектов и связей между ними.
Вторая фаза анализа предметной области состоит в выборе информационных объектов, задании необходимых свойств для каждого объекта, выявление связей между объектами, определении ограничений, накладываемых на информационные объекты, типы связей между ними, характеристики информационных объектов.
Проанализируем предметную область на примере БД учета учащихся в школе. При выборе информационных объектов постараемся ответить на ряд вопросов:
¾ На какие классы можно разбить данные, подлежащие хранению в БД?
¾ Какое имя можно присвоить каждому классу данных?
¾ Какие наиболее интересные характеристики (с точки зрения пользователя) каждого класса данных можно выделить?
¾ Какие имена можно присвоить выбранным наборам характеристик?
Пример: