6.1.Ограничения реляционных баз данных.
Появление реляционных СУБД стало важным шагом вперед по сравнению с иерархическими и сетевыми
СУБД, в этих системах стали использоваться непроцедурные языки манипулирования данными и
была достигнута значительная степень независимости данных от обрабатывающих программ. В то же
время, выяснился ряд недостатков реляционых систем. Во-первых, сама реляционная модель
ограничена в представлении данных:
- Как мы уже видели (см. п.5.5.3) реляционная модель данных не
допускает естественного представления данных со сложной (иерархической) структурой,
поскольку в ее рамках
возможно моделирование лишь с помощью плоских отношений (таблиц). Все отношения
принадлежат одному уровню, многие значимые связи между данными либо теряются, либо их
поддержку приходится осуществлять в рамках конкретной прикладной программы.
- По определению в реляционной модели поля кортежа могут содержать лишь атомарные значения.
Однако, в таких приложениях как САПР (системы автоматизироваанного проектирования), ГИС
(геоинформационные системы), искусственный интеллект системы оперируют со сложно -
структурированными объектами.
Пример:
Пусть нам необходимо создать базу данных земельных участков. Каждый участок задается
координатами узлов ломаной линии, ограничивающей его по периметру. В этом случае
спроектировать реляционную таблицу невозможно, т.к. заранее не известно количество
узлов для всех участков. Также невозможно написать общие процедуры (вычисление площади,
нахождение пересечения и т.д.) для всех случаев.
Кроме того, даже в том случае, когда сложный объект удается "уложить" в реляционную
базу данных, его данные распределяются, как правило, по многим таблицам. Соответственно,
извлечение каждого такого объекта требует выполнения многих операций соединения (join),
что значительно замедляет работу СУБД.
Обойти это и предыдущее ограничения можно было бы в том случае, если бы реляционная модель
допускала
- возможность определения новых типов данных
- определение наборов операций, связанных с данными определенного типа
Во-вторых, имеются определенные недостатки и в релизации тех возможностей, которые прямо не
предусматриваются реляционной моделью, но стали непременным атрибутом всех современных СУБД:
- Цикл существования реляционной базы данных состоит в переходе от одного целостного
состояния к другому. Однако, нельзя избежать такой ситуации, когда пользователь
вводити данные, формально удовлетворяющие ограничениям целостности, но не соответствующие
реальному состоянию предметной области. В этом случае предыдущее "истинное" значение
данных будет утеряно.
- Реляционная СУБД выполняет над данными не только те действия, которые задает пользователь,
но и дополнительные операции в соотвествии с правилами, заложенными в базу данных. Этот
механизм реализуется с помощью триггеров, однако аппарат триггеров весьма сложен в
отладке и полностью не реализован ни в одной системе.
Первые работы, в которых отмечались эти и ряд других недостатков, появились уже в начале 80-х
годов. Одна из наиболее ярких статей была опубликована в 1990 г. -
Системы баз данных третьего поколения: Манифест.
Вслед за первым манифестом последовали
Манифест систем объектно-ориентированных баз данных.
(М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С.Здоник, СУБД № 4 1995) и
Третий манифест (Х.Дарвин, К.Дэйт, СУБД № 1 1996).
Из названия этих публикаций ясно, что революционная ситуация в области хранения и управления
данными назрела. В следующих разделах мы рассмотрим некоторые способы преодоления указанных
недостатков. Кроме того, много полезной информации содержится в следующих публикациях:
Литература:
Следующая глава: 6.2.Постреляционные СУБД.
Введение в базы данных. (c) Зеленков
Ю.А. (yz@yars.free.net) 1997 г.
(c) Центр Интернет ЯрГУ