Главная Другое
Экономика Финансы Маркетинг Астрономия География Туризм Биология История Информатика Культура Математика Физика Философия Химия Банк Право Военное дело Бухгалтерия Журналистика Спорт Психология Литература Музыка Медицина |
страница 1 Порай Д.С., Голоусикова А.А. АннотацияОписывается опыт создания среды хранения объектов, реализованного над иерархической СУБД Ника. Механизмы работы с объектами основаны на технологии Component Object Model фирмы Microsoft. Хранилище позволяет одновременно хранить в БД экземпляры классов разных версий, экземпляры классов, которых не существовало на момент написания прикладной программы, обладает интерфейсом с языками программирования C++, VisualBasic, Pascal with Objects, Java, позволяет строить программы из самостоятельных модулей, обрабатывать существующие COM-объекты (без переписывания их кода). 1. ВведениеВ настоящее время в области разработки программного обеспечения для баз данных сложилась сложная ситуация. С одной стороны, большинство программ пишется с привлечением идей объектно-ориентированного программирования [1]. Считается, что это наиболее прогрессивный из всех известных сейчас подходов к построению сложных систем. Он позволяет создавать продукт из модулей, допускающих повторное использование, причем степень повторного использования превышает результат, получаемый при процедурном проектировании. Характерной особенностью такого продукта является большое количество взаимосвязанных типов данных (классов) со сложной структурой. Для языков программирования, поддерживающих сложные структуры, требуется адекватная модель базы данных. С другой стороны, большинство современных СУБД являются реляционными системами. Теория реляционных СУБД была разработана, в основном, в 70-х и 80-х годах и нынешние реализации слабо приспособлены к хранению данных со сложной структурой. Слабая приспособленность выражается, главным образом, в низкой скорости обработки запросов. Таким образом, на стыке объектных языков программирования и современных средств хранения данных сложилась противоречивая ситуация. Исправить эту ситуацию призваны объектно-ориентированные СУБД. 2. Предметная область2.1. Задача хранения объектовОдна из задач, неизбежно встающих в процессе разработки любой программы –сохранение данных в долговременной памяти (например, на жестких дисках) и восстановление обратно. Для программ, написанных на объектно-ориентированных языках, это означает способность сохранять и восстанавливать объекты. Предложено несколько способов решения этой задачи:
Следует отметить, что первый способ идейно является самым простым, но является недостаточно гибким (связи между объектами можно указывать лишь для тех объектов, которые сохраняются в одном потоке) и требует написания дополнительного кода для каждого нового класса (в отличие от двух других способов). Третий способ имеет один существенный недостаток – система получается замкнутой (т.е. нет регулярного способа экспортировать объекты вовне, например, на сменных носителях или по сети, а также импортировать объекты, пришедшие извне). Особенный интерес представляет второй способ (объектно-ориентированные базы данных). Рассмотрим его более подробно. 2.2. Объектно-ориентированные базы данныхНаправление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х. Однако наиболее активно это направление развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных коммерческих и экспериментальных систем. Большое число работ не означает, что все проблемы ООБД полностью решены. Современная ситуация с ООБД напоминает ситуацию с реляционными системами середины 1970-х. При наличии большого количества экспериментальных проектов (и даже коммерческих систем) отсутствует общепринятая объектно-ориентированная модель данных, и не потому, что нет ни одной разработанной полной модели, а по причине отсутствия общего согласия о принятии какой-либо модели. На самом деле, имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д. Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования. 2.3. Объектная модельДля того чтобы СУБД могла сохранять и восстанавливать состояние объектов, ей необходима некоторая информация (список переменных объекта и его методов), а также способность считывать и устанавливать значения переменных объекта, являющегося экземпляром любого класса. Также СУБД должна уметь самостоятельно создавать экземпляры произвольного класса и уничтожать их. Все эти дополнительные возможности – это и есть объектная модель. В некоторых языках программирования (например, в JAVA), объектная модель – неотъемлемая часть самого языка, в других (таких, как C++) язык не предоставляет таких возможностей и объектную модель приходится реализовывать на уровне библиотек. Фактически, объектная модель – это иерархия классов, которые предоставляют весь необходимый сервис. Наиболее распространены сейчас следующие объектные модели: OMG Object Model (предлагаемая организацией Object Management Group) [9], Component Object Model (предлагаемая Microsoft), объектная модель языка JAVA (набор классов java.lang.* и java.lang.reflect.*) [2], иерархия классов библиотеки Visual Component Library (доступная из сред программирования Delphi и C++ Builder компании Inprise, известной ранее как Borland). 2.4. Языки программирования ООБДРазработчики объектно-ориентированных СУБД стремятся сократить разрыв между традиционными языками программирования и СУБД. Есть два пути решения этой задачи: двигаться от языка программирования (встраивать в существующий язык средства общения с СУБД или же создавать новый с теми же возможностями) и, наоборот, двигаться от СУБД (оперировать на уровне библиотек). Первый путь очень интересен. Он приводит к созданию фактически новых языков, в которых доступ к базе осуществляется максимально простым путём. Однако он сопряжен с большими затратами на создание своего транслятора, его поддержку (обеспечение совместимости с новыми стандартами на язык, на базе которого построен данный), переносом на другие платформы и т.д. Новый язык строится, как правило, на основе какого-либо из существующих объектно-ориентированных языков: Smalltalk, Java, C++, ObjectLisp, Modula, Oberon и т.д. Такой способ избрали, например, создатели Модула-90К [5]. Второй значительно проще из-за того, что он не требует затрат на создание своего транслятора. Зато обеспечивается возможность совместной работы с существующими и будущими версиями трансляторов сторонних производителей. Он не завязан на единственный язык программирования, а предоставляет выбор между некоторым количеством, обеспечивая возможность разработки модулей программы, работающих с одной и той же базой, на различных языках. Наибольшее распространение получил второй подход, поэтому на нём остановимся подробнее. Традиционно язык программирования СУБД состоит из трех частей: язык описания данных, язык манипулирования данными и язык запросов. Существует два способа задания структуры БД:
И в том, и в другом случае, на выходе получаются два вида модулей: программные, в которых описание данных – это классы и структуры в терминах языка, и модули описания в формате СУБД (благодаря им она не связана с конкретным языком программирования). Манипулирование данными кодируется непосредственно на целевом языке. В программах используются объекты и структуры, которые помещаются в базу данных, и для их хранения не требуется прикладывать особые усилия. Создатели объектных СУБД стараются максимально облегчить жизнь программисту, поэтому сохранение объектов обеспечивается прозрачным образом. Благодаря применению одного языка программирования для создания логики приложения, разработки интерфейса и общения с базой данных, прикладные программы могут быть выполнены с минимальными затратами средств и времени. Запросы к базе разделяются на два вида и реализуются, соответственно, двумя способами:
Существуют три подхода к построению языков запросов:
Независимо от подхода, применяемого для разработки языка запросов, перед разработчиками встает одна концептуальная проблема, решение которой не укладывается в традиционное русло объектно-ориентированного программирования. Понятно, что основой для формулирования запроса должен служить класс, представляющий в ООБД множество однотипных объектов. Но что может представлять собой результат запроса? Набор основных понятий объектно-ориентированного подхода не содержит подходящего к данному случаю понятия. Обычно из положения выходят, вводя концепцию множества объектов, и полагая, что результатом запроса является некоторое подмножество объектов-экземпляров класса. Это ограничительный подход, поскольку автоматически исключает возможность наличия в языке запросов средств, аналогичных реляционному оператору соединения. 2.5. Управление доступомВо всех современных СУБД в той или иной мере встроена поддержка механизмов безопасности. Все они удовлетворяют стандарту (или близки к этому), описанному в «The Orange Book» [10]. Он описывает «действующих лиц» системы: пассивные объекты (защищаемая информация), активные субъекты (пользователи, которые хотят получить доступ к информации) и механизмы предоставления доступа («правила игры»). На сегодняшний день существует два вида таких механизмов:
Очевидно, что первый из этих двух методов обладает значительно меньшими накладными расходами, а второй существенно более гибкий. Поэтому в современных системах чаще всего применяется именно избирательное управление доступом. Однако для ускорения работы подсистемы безопасности, разработчики базы зачастую создают неизменный список достаточно обобщенных действий. Такой подход недостаточно гибок, и пользоваться им неудобно. 2.6. Другие методы хранения информации. СУБД Ника.В настоящее время наибольшее распространение получили реляционные СУБД. Однако существуют также системы, относящиеся к так называемой «дореляционной эпохе». Это иерархические и сетевые СУБД. Они практически вытеснены с коммерческого рынка реляционными системами, однако существуют несколько удачных реализаций. К ним относится иерархическая СУБД Ника [6]. Ника является оригинальной отечественной разработкой, при ее создании использовался опыт разработки и массового внедрения системы ИНЕС [4]. Ника имеет богатое окружение и поставляется в виде набора программных продуктов, основными из которых являются конструктор схемы БД, редактор БД и библиотеки функций для создания прикладных программ. Программное обеспечение системы открыто пользователю на всех уровнях, отдельные ее части могут использоваться независимо от других. СУБД Ника позволяет работать со сколь угодно сложными (иерархическими) объектами, имеющими произвольные (сетевые) связи. База данных состоит из двух файлов – файла описания данных и файла данных. Каждый из них представляет собой простое дерево. Рассмотрим его подробнее. Основной способ хранения информации в Нике – простое дерево (метод доступа TREE). Он позволяет работать с данными, имеющими иерархическую структуру. Никаких ограничений на глубину иерархии и количество вершин не накладывается. Единственное ограничение – объем памяти на диске. Основное понятие системы TREE – вершина. Вершина состоит из ключа, идентифицирующего эту вершину, и данного. Данное может быть либо простым (целое или вещественное число, текст, бинарное данное), либо составным (последовательность вершин, подчиненных данной). Размещение информации на диске организовано следующим образом: файл состоит из отдельных страниц, которые образуют иерархическую структуру. Дерево страниц согласовано с деревом данных в следующем смысле: всякое поддерево исходного дерева хранится в некотором поддереве дерева страниц. Такая организация обеспечивает физическую кластеризацию данных – вершины, расположенные в непосредственной близости друг от друга (например, на одном уровне или одна в подчинении у другой) с большой вероятностью окажутся в одном блоке и в файле. Это существенно уменьшает количество обращений к диску и повышает скорость работы прикладных программ. Ника позволяет работать с базой данных не только как с целым (схемой и данным), но и использовать метод доступа TREE отдельно. Это позволяет использовать его независимо от СУБД Ника, например, для создания других СУБД. Существует сетевая версия СУБД Ника. Она обеспечивает работу в режиме клиент/сервер. Возможен доступ к удаленным файлам как в режиме базы данных, так и с помощью метода TREE. Для поддержки целостности используется механизм транзакций. Одновременно может быть открыто сколь угодно много транзакций на чтение или одна транзакция на запись. В систему включены утилиты для проверки целостности, упаковки БД, редактор схемы и самой БД. Недостатками Ники являются:
3. Положение в данной области3.1. СтандартыВ современных технологиях без стандартов не обойтись, особенно разработчикам приложений. Не составляют исключения и технологии объектных СУБД. Поэтому в 1992 г. ведущие разработчики объектных СУБД образовали группу ODMG (Object Database Management Group) по выработке и согласованию стандартов. Специфика ее деятельности заключается не в создании новых стандартов, а в развитии уже существующих в OMG (Object Management Group ANSI, группа выработки стандартов объектного программирования) и разработке порядка их использования для достижения совместимости конечных прикладных программ с интерфейсом любой объектной СУБД. К настоящему времени выработаны стандарты языка описания объектов ODL (Object Definition Language), языка запросов OQL (Object Query Language), дополнения языков программирования C++, Smalltalk, Java. Объектная модель, установленная ODMG, базируется на модели группы OMG, созданной несколькими годами ранее. В дополнение к известным объектным концепциям в новом стандарте предложены расширения для обмена с базой данных, например, вводятся понятия транзакций, отношений между объектами. Язык описания объектов ODL, являющийся расширением языка определения интерфейсов IDL (Interface Definition Language), предназначен только для описания интерфейса объекта с внешним миром, а реализацию базы он никак не затрагивает и не ограничивает. Следует иметь в виду, что IDL принят в качестве стандарта описания объектных интерфейсов в CORBA. Язык запросов OQL включает объектное расширение языка SQL-92 таким образом, что большинство запросов, адресованных реляционной СУБД, будут выполняться и в объектных базах данных. Стандарт ODMG осуществляет поддержку операций над стабильными объектами, помогает встраивать в программы на C++, Smalltalk, Java выражения на языке OQL и содержит средства управления транзакциями и средства навигации по объектам базы данных. Прямым конкурентом OMG является фирма Microsoft, разработавшая собственную объектную модель Component Object Model. COM не является стандартом в том смысле, что ее развитием и продвижением на рынке занимается единственная компания, а не консорциум. Она не обладает той многоплатформенностью, которая изначально заложена в CORBA, а рассчитана почти исключительно на рынок, где главенствующее положение занимают операционные системы семейства Windows. Она поставляется со всеми современными версиями ОС этого семейства, причем часть модулей Windows написаны с её привлечением. Благодаря такой тесной интеграции с операционной системой COM является стандартом де-факто на этом рынке. Многие разработчики прибегают к этой модели как к средству построения модульных программ, способных интегрироваться с другими системами. COM является языково-нейтральным стандартом. В нем присутствуют механизмы совместной работы с динамически распределяемой памятью, сборка мусора (методом подсчета ссылок), язык описания данных (Interface Definition Language – IDL, не путать с одноименным языком OMG), а также большой набор интерфейсов. Существует версия COM, предназначенная для распределенной работы – DCOM (Distributed COM). Сама COM не имеет прямого отношения к объектно-ориентированным СУБД, однако среди стандартных интерфейсов есть и те, которые специально предназначенные для сохранения и последующего восстановления состояния объектов. Они работают с потоками байт (IStream) и структурированными хранилищами (IStorage - иерархия потоков). 3.2. Существующие реализацииНиже представлена таблица ([7]), в которой кратко описаны существующие коммерческие объектно-ориентированные СУБД (объектно-реляционные намеренно опущены).
4. Цель данной работыЦель данной работы состоит в создании системы хранения объектов, обладающей следующими преимуществами перед существующими СУБД:
Работа проводится в рамках разработки полноценной объектно-ориентированной СУБД. Система хранения объектов обладает меньшими возможностями, чем СУБД, однако уже пригодна для решения ряда задач, не требующих поддержки длительных транзакций и языка запросов. 5. Реализация среды хранения объектов5.1. Объектная модельВ качестве объектной модели выбрана Microsoft COM, т.к. она является наиболее распространенной на платформе Windows. Важной особенностью COM является возможность получать информацию о внутренней структуре класса через интерфейсы IDispatch, ITypeInfo, IProvideClassInfo. Эти интерфейсы используются следующим образом:
5.2. Методы сохранения стандартных COM-объектовДля сохранения объектов используются стандартные интерфейсы IDispatch, IPersistStream, IPersistStorage, IPersistPropertyBag. IPersistStream, IPersistStorage, IPersistPropertyBag являются надежными в том смысле, что если объект реализует какой-либо из них, то он гарантирует свою способность сохранять свое состояние и восстанавливать его из IStream, IStorage или IPropertyBag. Следует отметить, что из этих трех интерфейсов самыми необходимыми являются IPersistStream и IPersistStorage, т.к. они является самым распространенными. Недостатком IPersistStream и IPersistStorage является то, что объект сохраняется целиком, и при этом нет возможности просмотреть или исправить его внутреннюю структуру. Более предпочтительный вариант – IDispatch. Он позволяет сохранять в базе структуру объектов, открывает возможности для прозрачного хранения ссылок и рекурсивных структур. Однако для корректного использования IDispatch COM-класс должен обладать таким свойством: состояние объекта – это совокупное состояние всех его свойств. Т.е. не каждый объект, реализующий IDispatch, окажется после восстановления из БД в том же состоянии, что и перед сохранением в нее. Это серьезная проблема, но есть частичное решение: интерфейс IDispatch проверяется в последнюю очередь (после IPersistObject, IPersistStorage, IPersistStream, IPersistPropertyBag). Следует отметить, что если объект не реализует ни одного IPersist-интерфейса, а реализует лишь IDispatch и, при этом, не выполняется сформулированное выше свойство, то такой объект не может быть сохранен в БД. 5.3. Организация ссылокОбъект, на который имеется ровно одна ссылка, сохраняется в дереве непосредственно под объектом, который на него ссылается. Сохранение объекта, на который имеется более чем одна ссылка, происходит следующим образом: он сохраняется под одним из объектов, который на него ссылается, а под остальными объектами «подвешиваются» ссылки. Выбор выделенного объекта осуществляется простым способом - это первый в последовательности сохранения. Несмотря на простоту, такая схема достаточно эффективна, т.к. чаще всего объект «сильно» связан только с одним объектом, и «слабо» - с остальными (обычно это ссылки из индексов). При этом обеспечивается физическая кластеризация (объект хранится в непосредственной близости от того объекта, с которым он сильно связан), что положительно сказывается на времени доступа как при чтении, так и при записи. 5.4. Доступ к рекурсивным структурам. Загрузка по требованию.До тех пор, пока все поля объекта являются экземплярами простых типов, загрузку объекта из БД можно производить последовательной загрузкой всех его полей. Если же одним из полей является объект, то его загрузка может привести к попытке загрузить в память значительную часть (или даже всю) БД и, в конечном итоге, к краху системы по причине нехватки оперативной памяти. Решение этой проблемы состоит в том, чтобы не загружать подобъект сразу, а отложить эту операцию до момента, когда он действительно потребуется. Если же он не вообще не будет востребован, то никаких лишних операций выполнено не будет. Этот механизм называется загрузка по требованию. Загрузка по требованию реализуется следующим образом: в библиотеке есть класс-посредник PDS.OnDemandDispatch, реализующий IDispatch. В процессе загрузки из БД создается экземпляр класса PDS.OnDemandDispatch, и он отдается пользователю вместо настоящего объекта. При этом посредник запоминает вершину в БД, в которой лежит настоящий объект. И лишь когда произойдет реальное обращение к данным (метод Invoke), посредник загрузит настоящий объект из базы и передаст управление его методу Invoke. 5.5. Хранение неограниченных массивов.Для хранения неограниченных массивов введена дополнительная структура данных – класс PDS.SimpleUnlimitedArray. Это ключевой массив, в котором в качестве ключа может выступать только простое данное (целое, вещественное, булевское, строка), а в качестве данного – любой COM-объект. Этот объект может включать в себя произвольную иерархию подобъектов, а также другие объекты типа PDS.SimpleUnlimitedArray. Элементы массива всегда загружаются только при обращении к ним, т.е. массив может состоять из большого количества элементов, общий объем которых может многократно превышать объем оперативной памяти. 5.6. Методы сохранения «своих» объектовВсе объекты, которые «знают» о существовании СУБД, реализуют интерфейс IPersistObject. Они могут делать это полностью самостоятельно или с помощью агрегации класса PDS.PersistObject. 5.7. Схема БДВ данной системе фактически не существует «схемы базы данных» в классическом понимании этого термина. Описания COM-классов хранятся в библиотеках вместе с программным кодом самих классов. То есть схема – это совокупность описаний, находящихся во всех библиотеках (являющихся COM-серверами), проинсталлированных на данном компьютере. А в базе хранятся лишь данные экземпляров. При этом объект любого типа можно сохранить в любую точку базы. Данные сохраняются вместе с информацией о классе, позволяющей в последствии восстановить объект. Запись в БД происходит следующим образом: в базу помещается идентификатор COM-класса (ProgID), экземпляром которого является данный объект, и данные объекта. В случае IPersistStream это бинарные данные, IPersistStorage – иерархия бинарных данных, IDispatch – список свойств с их идентификаторами и значениями. Для получения этих списков используется описание данных COM (доступное в TypeLibrary). При таком подходе существенно облегчается процесс разработки большого приложения. Каждый программист работает со своими модулями (COM-классами), фактически это «подсхема» всей базы данных. В процессе сборки компоненты переносятся на одну машину, и все они автоматически приобретают возможность сохраняться в общую базу программы. Процесс разработки сложных систем (в котором участвуют несколько человек) существенно упрощается благодаря распараллеливанию. При этом благодаря большей модульности повышается качество программ и скорость их разработки. Кроме того, появляется возможность сохранять в БД классы, которых не существовало на момент написания прикладной программы. Это очень актуально в настоящее время, когда все больше и больше разработчиков создают расширяемые пакеты прикладных программ. В таких системах существует возможность разрабатывать дополнения (Extensions или Plugins), которые создаются независимыми производителями программного обеспечения и распространяются отдельно от самого продукта. Эти дополнения тесно взаимодействуют с основной программой, в частности, они могут оперировать со своими собственными данными, которые необходимо сохранять в базу данных. Применение данной разработки позволяет построить систему так, чтобы о хранении объектов заботилась основная программа, а не дополнения к ней. 5.8. Версии классовИдентификатор класса (ProgID) состоит из двух частей – собственно имя класса и его версия. Такая структура позволяет одновременно хранить в базе экземпляры разных версий одного и того же класса. При этом сам класс должен поддерживать совместимость «снизу вверх». Это позволит производить конвертацию лишь при необходимости (если точнее, то при операции «открыть экземпляр, созданный старой версией класса» - «изменить его» - «сохранить»). Например, на одной машине установлен Microsoft Word 95. С его помощью был создан документ и сохранен в базе. Этот документ – экземпляр класса Word.Document.6. На другой машине установлен Microsoft Word 97. С его помощью был создан второй документ и также сохранен в базе. Этот документ – экземпляр класса Word.Document.8. Два документа одновременно находятся в одном и том же хранилище и не противоречат друг другу. Если со второй машины кто-то попытается открыть первый документ, то он успешно это сделает (т.к. Microsoft Word поддерживает совместимость «снизу вверх»). Если же, наоборот, с первой машины попытаться открыть второй документ, то это закончится неудачей, т.к. совместимость «сверху вниз» обычно не обеспечивают (хотя в случае Microsoft Word существует специальный конвертор, который позволит это сделать; но это все же исключение из правила). 5.9. Клиент/серверный режимСреда хранения объектов имеет слоеную архитектуру (подробнее см. «6.2. Классы и их взаимоотношения»). Принципиально система может работать с разными типами хранилищ. Механизмы работы с конкретным хранилищем обеспечиваются нижним слоем (например, Никой). Система не имеет четких представлений о том, является ли она посредником при работе с удаленной или локальной базой. Основным хранилищем системы является Ника, а она обеспечивает работу в режиме клиент/сервер, поэтому при работе с ней и сама система становится клиент/серверной. 5.10. БлокировкиЗаблокировать можно только объекты, реализующие IPersistObject. Фактическую блокировку осуществляет нижний слой системы (подробнее см. «6.2. Классы и их взаимоотношения»). В случае Ники используются возможности, предоставляемые Ника-сервером. 6. Описание библиотеки классов для программного доступа к системе хранения объектовСреда хранения объектов состоит из нескольких модулей:
В настоящее время в качестве сервисных утилит используются программы НИКИ:
6.1. Требования к COM-объектамДля того чтобы система могла сохранить данный COM-объект в базу, он должен реализовать хотя бы один из интерфейсов:
6.2. Классы и их взаимоотношенияВсе классы библиотеки разбиты на три группы. Программист, использующий библиотеку, работает с верхним уровнем (за исключением класса - наследника BackEndDescription, который описывает параметры конкретного хранилища). Средний уровень – абстрактные классы, описывающие некоторое хранилище. Нижний уровень – конкретная реализация хранилища.
7. Реализованные хранилища нижнего уровня7.1. Хранилище над реестром WindowsКласс называется PDS.RegistryBackEnd. Он сохраняет данные в реестре Windows под ключом с заданным именем, что позволяет использовать систему для удобного хранения настроек программ (settings). IRegistryBackEndDescription – описатель параметров подключения к реестру. Свойства:
7.2. Хранилище над Никой.Класс называется PDS.NikaBackEnd. Это основное хранилище, которое используется в библиотеке. В качестве метода доступе используется простое дерево (TREE). Выбор именно простого дерева, а не полноценной СУБД Ника (метод доступа ACCESS) объясняется следующими причинами:
INikaBackEndDescription – описатель параметров подключения к базе. Свойства:
8. Исследование скоростных характеристикЦелью данного исследования является измерение основных скоростных показателей данной разработки и их сравнение с аналогичными показателями других СУБД. В сравнительном анализе участвовали следующие программы:
Работа проводилась с базами данных, имеющими следующую структуру: Объектно-ориентированные – БД состоит из коллекции однотипных объектов. Каждый объект имеет десять переменных-членов:
При занесении в коллекцию строится индекс по переменной I1. В последствии выполняется поиск по этой же переменной. Реляционные – БД состоит из одной таблицы, которая, в свою очередь, состоит из 10 полей, описанных выше. Поле I1 является первичным ключем в таблице. Программа тестирования состояла из трех задач:
Исследование проводилось на компьютере следующей конфигурации:
Результаты тестирования представлены на графиках: ![]() ![]() ![]()
На графиках видно, что на основных тестах (запись в БД и произвольная выборка данных - самая частая операция в реальных задачах) данная разработка опережает как объектно-ориентированную СУБД POET, так и реляционные ACCESS и INTERBASE. 9. Перспективы развитияАвтоматическое построение индексовВ систему будет встроена возможность создания индексов на массивы объектов, реализующих IDispatch. В индексы будут автоматически заноситься ссылки на оригинальные объекты. Управление доступомВсе механизмы управления доступом будут реализованы в виде отдельной библиотеки, состоящей из нескольких COM-классов. Субъектами будут являться пользователи Windows NT, объектами – все COM-объекты, реализующие IPersistObject. ТранзакцииНедостатком Ники является отсутствие параллельных транзакций на запись. Предлагается исправить этот недостаток собственной надстройкой над Никой, которая обеспечивала бы возможность многовариантной блокировки: одновременно выполняются сколь угодно много транзакций на чтение и сколь угодно много непересекающихся транзакций на запись (которые не «трогают» одни и те же данные) [3]. ШифрованиеПланируется встроить механизмы шифрования данных как при хранении, так и при передаче по сети (в клиент/серверном режиме). Языки запросовПланируется реализовать подмножество языка OQL (Object Query Language). ЗаключениеВ данной работе создана принципиально новая среда хранения объектов, которая в дальнейшем будет развиваться до полноценной объектно-ориентированной СУБД. Преимущества перед СУБД, построенными на других моделях:
Преимущества перед реляционными СУБД:
Преимущества перед «чистой» Никой:
В настоящий момент среда хранения объектов используется в качестве СУБД в системе электронного документооборота. Практика подтвердила небольшое время написания программ с использованием данной разработки и высокую скорость этих программ. Список литературы
- - Смотрите также: Создание среды хранения объектов над иерархической субд
315.78kb.
1 стр.
Краткое содержание курса Теория баз данных Модели данных и языки запросов Транзакции и согласованность
32.52kb.
1 стр.
CloudScape. Любой разработчик, занимающийся разработкой приложений, которым нужно иметь дело с базами данных, не раз задумывался над выбором подходящей субд
142.01kb.
1 стр.
Коллекции объектов
79.63kb.
1 стр.
BeanShells: Интеграция cae-пакетов в gpe
26.11kb.
1 стр.
Охрана окружающей среды
1441.07kb.
11 стр.
Программа дисциплины "управление данными" Рекомендуется Министерством образования РФ для направления подготовки
110.43kb.
1 стр.
Оптимизация информационных систем на основе субд oracle
510.54kb.
7 стр.
Акт обследования объектов социальной инфраструктуры в г. Кондрово с целью обеспечения среды доступности для маломобильных групп населения
47.48kb.
1 стр.
Лекция 6 в первой лекции мы рассмотрении функции хранения, обмена. Теперь рассмотрим изменение баз данных, включая сортировку, выбор
58.65kb.
1 стр.
Дисциплина. «Базы данных и субд»
127.3kb.
1 стр.
2. Дисциплина «Операционные среды». Основные разделы и их содержание, выносимые на экзамен 66.07kb.
1 стр.
|