1. Объектно-реляционные базы данных

2. Объектно-ориентированные базы данных

Объектно-реляционные базы данных представляют собой реля­цион­ные базы дан­ных, дополненные надстройкой, пред­ставляющей эти дан­ные как объекты. Все по-прежнему хранится в ви­де таблиц. Этот под­ход позволяет плавно перейти от технологии хра­ни­лища таблиц к технологии хранилища объектов. Остается воз­можность выборки данных с помощью SQL-запросов. Сам SQL расширен командами работы с объ­ектами. Наиболее известным про­дуктом, в котором реализован подоб­ный подход является Oracle ver.8. Комитет ANSI X3H2, разработавший стан­дарт SQL–92, сейчас ра­бо­та­ет над SQL3. Основными усо­вер­шен­ство­ваниями в SQL3 должны стать возможность процедурного доступа на­равне с декларативным и под­держка объектов. Основным недос­тат­ком объ­ект­но-реляционных СУБД является необходимость разбирать объ­екты для размещения их в таблицах и собирать их для передачи поль­зователю из таблиц [2].

Объектно-ориентированные базы данных хранят объекты цели­ком. Для выборки объектов с помощью запросов разра­батывается язык OQL (Object Query Language), в который был вклю­чен стандарт SQL'92. Единство описания структуры БД достигается при­менением языка определения объектов ODL (Object Definition Language), пред­ло­женного ODMG (Object Database Management Group), являющегося расширением языка IDL. Эти виды баз данных обладают высокой произ­води­тель­но­стью, часто в несколько раз более высокой, чем реляционные базы дан­ных. Наиболее известными ООСУБД явля­ются Jasmine, ObjectStore и POET.

Из отечественных разработок в области пост­реляционных баз дан­ных достоверно извест­но лишь о существовании ООСУБД ODB-Jupiter. Похоже, она была написана специ­ально для создания продукта ODB-Text. По крайней мере, ни о каких других приложениях написанных на ODB-Jupiter ничего не известно. Также в Internet было обнаружено опи­сание некой отечественной объектно-ориентированной базы данных вер­сии 1.2. Точнее, это был модуль, предоставляющий функции объектно-ориен­ти­ро­ван­ной СУБД. Доку­мент даже не имел названия. В нем деталь­но рассматривалась орга­низа­ция хранения данных и принцип работы. Похоже, разработка обос­новывалась лишь на принципах, которым долж­на удовлетворять СУООБД. Наиболее интересная идея: назначение строкам уникальных идентификаторов и удаление строк только при упаковке базы. Это дает существенный выигрыш в сравнении строк, так как объекты-строки с одинаковым содержанием имеют одинаковые идентификаторы.

1.3 Краткий сравнительный анализ постреляционных и традиционных баз данных

Постреляционные базы данных вобрали в себя все лучшие черты иерархических, сетевых и реляционных баз данных.

Хотя существуют некоторые сходства, как, например, исполь­зование указателей и вложенная структура записей в сетевой модели. Однако надо отметить, что СУООБД используют логические указатели для обеспечения целостности, а также поддерживают иерархию классов, наследование и методы. Таких средств нет в иерархических и сете­вых моделях [4].

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

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

1.4 Основания дипломной работы

В отношении избранных математических моделей

Значительная часть этой дипломной работы основывается на двух мате­мати­чес­ких моделях.

Модель единого представления данных поведений и сообщений в объектно-ориентированной базе данных

Модель [17] замечательна тем, что не только описывает что пред­став­ляют из себя объекты и как они взаимодействуют между собой, но и является замкнутой, само­доста­точной. Она позволяет описать качест­венно новый вид взаимодействия в объектно-ори­ен­ти­ро­ван­ной сис­теме: алгебру объ­ектов. Эта алгебра является по своей сущности и важ­ности аналогом реля­ционной алгебры в теории реляционных баз дан­ных. В этой алгебре объ­ектов определяется что представляют из себя такие операции, как селекция, проекция и другие хорошо из­вест­ные из теории реляционных баз данных операции. Таким обра­зом, эта модель объединяет два спо­соба получения информации: по­сыл­ка сообщения объекту (что типично для объектно-ори­енти­рован­ного программирования) и выполнение за­проса над совокупностью хранимых данных (что типично для реля­ционных баз данных).

Модель согласованного управления в объектно-ориентированной базе данных

Эта модель [19] также оказала значительное влияние на данную работу, поскольку дополнила собой модель представления данных. Ни одна современная система управ­ления базой данных не может обойтись без подсистемы транзакций. Природа тран­зак­ций в таких при­ложениях, как CAD, мультимедийные базы данных, является весь­ма раз­лич­ной. Эти приложения характеризуются совместно выпол­ня­емыми продол­житель­ными транзакциями с произвольными опера­ци­ями. У продолжительных поль­зова­тель­ских транзакций время выпол­не­ния может быть растянуто на часы, а то и дни. Это усло­вие при­водит к тому, что хорошо извест­ный, и ставший уже классическим для тра­ди­ци­он­ных баз данных, кри­те­рий сериализуемости становится непри­меним непосредственно.

О са­мом критерии сериализуемости и спо­собах реализации меха­низ­ма транзакций достаточно подробно из­ло­жено в [9] и [22].

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

Другие работы, также повлиявшие на организацию структуры системы управления

В статье [20] излагается довольно интересная точка зрения на сос­тояние объектно-ориентированного программирования, а также рас­ска­зывается о применении несколько отличного от традиций объ­ект­но-ориентированного программирования подхода. В част­ности, насле­до­ва­ние реализуется с помощью механизмов включения и деле­гиро­вания. Это позволяет решить проблему множественного насле­дова­ния. Вводит­ся поня­тие филь­тров, представляющих собой продукции, кото­рые могут обрабатывать входя­щие сооб­ще­ния и даже пере­нап­рав­лять их на другие объ­екты, сохраняя в теле этих со­обще­ний ссыл­ку на перво­на­чаль­ный объ­ект, к которому было послано сообщение. При­чем, фильтры мо­гут реа­гировать не только на входящие, но и на исхо­дящие от объекта сообщения.