Учебная работа. Реферат: Объектно-ориентированные базы данных, работающие в распределенных сетях

ГОУ ВПО «АДЫГЕЙСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ФИЗИЧЕСКИЙ ФАКУЛЬТЕТ

КУРСОВАЯ РАБОТА

По дисциплине:
«Сетевые технологии»

«Объектно-ориентированные базы данных, работающие в распределенных сетях»

Выполнил:
студент группы 4А2

специальности 230102 (220200) АСОИУ

Хмиляр М.А.

Научный управляющий:

Алиев М.В.

Рецензент:

Кизянов
А.Ф.

Майкоп 2006 год

СОДЕРЖАНИЕ

ВВЕДЕНИЕ
5

1. ОБЩИЕ СВЕДЕНЬЯ ОБ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ

БАЗАХ ДАННЫХ 6

2. ОСОБЕННОСТИ БАЗ ДАННЫХ ПОСТРОЕННЫХ НА СУБД

РАЗНЫХ ФИРМ 9

2.1
ВВЕДЕНИЕ

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

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

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

Актуальность.

Невзирая на то, что направление объектно-ориентированных баз данных появилось сравнимо издавна и публикации появлялись уже посреди 1980-х. Но более интенсивно это направление сделалось развиваться в крайние годы. Это подтверждается тем, что с каждым годом возрастает число публикаций и реализованных коммерческих и экспериментальных систем.

Цель работы.

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

2. Обрисовать индивидуальности построения баз данных приложениями различных компаний.

3. Выявить достоинства.

4. Выявить недочеты.

1. ОБЩИЕ СВЕДЕНЬЯ ОБ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ БАЗАХ ДАННЫХ

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

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

В реляционных СУБД связи управляются юзером, создающим наружные ключи. Потом для обнаружения связей динамически во время выполнения система просматривает две (либо больше) таблицы, сравнивая наружные ключи до заслуги соответствия. Этот процесс, именуемый объединением (join), является слабенькой стороной реляционной технологии. Если наиболее 2-ух либо 3-х уровней объединений – сигнал, чтоб находить наилучшее решение. В ООСУБД юзер просто заявляет связь, и СУБД автоматом генерирует способы управления, динамически создавая, удаляя и пересекая связи. Ссылки при всем этом прямые, нет необходимости в просмотре и сопоставлении либо даже поиске индекса, который может очень сказаться на производительности. Таковым образом, применение объектной модели лучше для баз данных с огромным количеством сложных связей: перекрестных ссылок, ссылок, связывающих несколько объектов с несколькими (many-to-many relationships) двунаправленными ссылками[1].

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

И, в конце концов, ООСУБД подступают (снова же без трансляций меж объектной и реляционной моделями) для организации распределенных вычислений. Классические базы данных (в том числе и реляционные и некие объектные) построены вокруг центрального сервера, выполняющего все операции над базой. По существу, эта модель не много различается от мэйнфреймовой организации 60‑х годов с центральной ЭВМ (Электронная вычислительная машина — комплекс технических средств, предназначенных для автоматической обработки информации в процессе решения вычислительных и информационных задач) – мэйнфреймом (mainframe), выполняющей все вычисления, и пассивных терминалов. Таковая архитектура имеет ряд недочетов, основным из которых является вопросец масштабируемости. В истинное время рабочие станции (клиенты) имеют вычислительную мощность порядка 30 ‑ 50 % мощности сервера базы данных, другими словами большая часть вычислительных ресурсов распределена посреди клиентов. Потому все больше приложений, и сначала базы данных и средства принятия решений, работают в распределенных средах, в каких объекты (объектные программные составляющие) распределены по почти всем рабочим станциям и серверам и где хоть какой юзер может получить доступ к хоть какому объекту. Благодаря эталонам межкомпонентного взаимодействия все эти фрагменты кода комбинируются друг с другом независимо от аппаратного, программного обеспечения, операционных систем, сетей, компиляторов, языков программирования, разных средств организации запросов и формирования отчетов и динамически меняются при манипулировании объектами без утраты работоспособности[3].

2. ОСОБЕННОСТИ БАЗ ДАННЫХ ПОСТРОЕННЫХ НА СУБД РАЗНЫХ ФИРМ

2.1 технологии разработки баз данных есть некоторое количество препятствий, которые задерживают разрабов от принятия решения о переходе с реляционной технологии на объектную. Главным препятствием является значимый размер разработок, опирающихся на реляционные СУБД. Ведь при переходе на объектную технологию нужно почти все начинать «с нуля», и потому возникает вопросец необходимости такового перехода. Не считая того, объектная разработка, поддерживаемая в ряде постреляционных СУБД, не имеет развитого и стандартизированного языка генерации отчетов и анализа данных, каким является структурированный язык запросов SQL. Данные задачи были решены при разработке постреляционной СУБД технологии, да и дозволяет почти во всем облегчить переход с реляционной технологии на объектную, также может выступать в роле шлюза к реляционным базам данных[5].

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

БД Cache’ была первой базой данной, созданной для работы в сети Internet/Intranet. В версии Cache’ 4.0 реализована разработка сотворения динамических web-приложений технологии Weblink прошлых версий Cache’. Не считая этого, системная библиотека «%Net» предоставляет классы, реализующие протоколы SMTP, POP3, HTTP, FTP и др.

Главные составляющие СУБД



Набросок 1. Архитектура системы Cache’.

Главными компонентами СУБД системы, ориентирование на работу с транзакциями.

Сервер системы в виде объектов, инкапсулирующих как данные, так и способы их обработки.

Cache’ SQL. Представление многомерных структур данных в виде реляционных таблиц.

прямого доступа. Предоставление прямого доступа к многомерным структурам данных ядра системы.

Разглядим подробнее предназначение и многофункциональные способности главных компонент системы.

TMDM — многомерное ядро Cache’, направленное на работу с транзакциями.

Данные в Cache’ хранятся в виде разреженных массивов, носящих заглавие глобалей. количество индексов массива быть может произвольным, что дозволяет обрисовывать и хранить структуры данных случайного уровня трудности. Индексы глобалей не типизированы, т.е. они могут быть хоть какого литерального типа данных.

Применение разреженных массивов дозволяет улучшить внедрение размера твердого диска и уменьшить время, требуемое на выполнение операций ввода/вывода и извлечение данных.

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

Набросок 2. Объектная модель значения констант (литералов) и разрешают их надзирать. Литерал не может существовать независимо от собственного значения, в то время как объекты имеют неповторимую идентификацию.

Классы типов данных разделяется на два подкласса типов:

· атомарные;

· структурированные.

Атомарными литеральными типами в иной класс.

Главным преимуществом использования интегрированных классов является минимум издержек, связанных с вероятным в дальнейшем конфигурацией набора схожих параметров классов, представленных в виде встраиваемого объекта.

Хранимые классы наследуют свое память, удаление объекта и т.п. Любой экземпляр хранимого класса имеет 2 неповторимых идентификатора — OID и OREF. OID (object ID) охарактеризовывает объект, записанный в БД, т.е. на физическом носителе, а OREF (object reference) охарактеризовывает объект, который был подкачен из БД и находится в памяти.

2.2 GemStone

Данная система была разработана компанией Servio-Logic вместе с OGI. В начальном варианте системы создатели GemStone опирались на язык Smalltalk. Хотя в первых выпусках системы ее главный язык именовался Opal, сходу было видно, что в реальности этого всего только Smalltalk с поддержкой размеренного хранения объектов, и скоро заглавие языка было заменено на GemStone Smalltalk. Потом в GemStone была обеспечена поддержка языков C и C ++, но во все времена базисным языком оставался Smalltalk, а все другие интерфейсы строились поверх базисного. И серверная, и клиентская части системы могут работать под управлением всех главных веток ОС unix и всех развитых вариантов Windows. В истинное время продукт поддерживается, развивается и распространяется компанией GemStone Systems Inc[8].

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

Для управления мультидоступом употребляется механизм транзакций. Механизм основан на так именуемом жизнеутверждающем подходе, при котором любая сессия работает с своей локальной копией хранилища объектов, и слияние сделанных в сессиях конфигураций хранилища происходит при окончании транзакции. Если при окончании транзакции находится, что произведенные в ней конфигурации конфликтуют с переменами остальных ранее зафиксированных транзакций, то фиксация транзакции не делается, транзакция не заканчивается, и решение задачи возлагается на юзера. Автоматическая блокировка объектов не делается, но юзер может очевидно запросить блокировку, что увеличивает шансы на успешную фиксацию транзакции.

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

Для восстановления базы данных опосля сбоев аппаратуры употребляются механизмы репликации, запасного копирования и журнализации. Хоть какой авторизованный юзер может запросить выполнения полного либо частичного копирования. Восстановление базы данных опосля сбоя системы либо дисковых устройств начинается с использования крайней по времени запасной копии. Опосля этого с помощью данных, сохраненных в журнальных файлах, хранилище объектов приводится к состоянию, соответственному крайней до момента сбоя зафиксированной транзакции. Авторизованные юзеры могут также запросить поддержку реплицирования областей хранилища данных.

В системе поддерживается целостность по ссылкам меж всеми объектами, так как все ссылки основываются на использовании объектных идентификаторов, и объекты, для которых есть ссылки от остальных объектов, не могут быть удалены. Для увеличения скорости доступа к нередко применяемым коллекциям обеспечивается средство построения индексов.

Объекты делаются размеренными (т.е. сохраняются в базе данных) методом использования собственного рода размеренного корня, именуемого коннектором. Все объекты, прямо либо косвенно достижимые по объектным ссылкам от коннектора, являются размеренными. В GemStone у всякого класса, в каком существует хотя бы один размеренный объект, поддерживается эквивалентная серверная версия класса. Иными словами, один вариант класса служит классом в контексте программирования, а иной – в контексте базы данных. Такие пары поддерживаются автоматом: если создается класс в смысле Smalltalk, и некий объект этого класса становится размеренным, то автоматом создается серверный класс этого объекта (класс в смысле GemStone). Создание коннектора приводит к возникновению экземпляра класса GemStone, эквивалентного классу объекта, который должен быть изготовлен размеренным. Аналогично, хоть какой объект, достижимый от коннектора, автоматом становится размеренным.

В GemStone поддерживается динамическая сборка мусора (garbage collection). процесс-«мусорщик» автоматом высвобождает память, занимаемую объектами, на которые отсутствуют ссылки.

В среде GemStone можно применять разные реализации Smaltalk, также языки C и C++. Классы и объекты можно создавать с внедрением хоть какого из этих языков, и объекты, сделанные на одном языке можно применять в приложениях, написанных на любом другом языке. Реализация языка C представляет собой набор функций и набор компонент, модифицирующих объекты GemStone в указатели и литералы C и напротив. Реализация C++ включает препроцессор в незапятнанный С и библиотеку классов[7].

Подключения к реляционным системам (к примеру, Oracle либо IBM DB2) выполняются через шлюзы. Для синхронизации состояния локальной (управляемой GemStone) и наружных копий данных обеспечивается автоматическая модификация данных. Зависимо от среды и требований к уровню синхронизованности эти обновления производятся немедля либо же в пакетном режиме.

GemStone можно также применять для управления данными, надлежащими эталонам OLE и CORBA. Для работы с данными в реляционном стиле поддерживаются эталоны SQL и ODBC.

2.3 ITASCA

Распределенная ООСУБД ITASCA базирована на результатах проекта Orion, выполнявшегося в MCC. Разработка серии из 3-х прототипов закончилась выпуском системы, основанной на архитектуре «много клиентов — много серверов». Система была доведена до уровня коммерческого продукта начинающей техасской компанией, которая в 1995г. была приобретена компанией IBEX Corp[9].

В распределенной архитектуре ITASCA личные и вместе применяемые базы данных разнесены по узлам локальной unix -ориентированной сети. Каждой значение данных хранится в одном узле, но централизованное управление отсутствует; все серверы автономны. На любом сервере поддерживаются кэш страничек и кэш объектов, и любой сервер огромное количество клиентов с обеспечением мультидоступа на базе блокировок. На клиентах поддерживается лишь кэш объектов.

Для управления мультидоступом в ITASCA употребляется двухфазный протокол синхронизационных блокировок с сериализацией транзакций и обнаружением тупиков. Также поддерживаются долгие транзакции на базе перемещения объекта из вместе применяемой базы данных в личную базу данных (check -out). Для обеспечения совместной работы допускается роль нескольких юзеров в одной долгой транзакции.

Для всей распределенной базы данных поддерживается единая схема с внедрение подсхем для личных фрагментов базы данных. Модель данных включает последующие нюансы:

· множественное наследование;

· наличие параметров и операций классов;

· поддержка ограничений целостности;

· возможность перегрузки операций.

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

Восстановление базы данных опосля сбоев делается на базе журнальчика, созданного для аннулирования результата выполненных операций (undo log). Это дозволяет в процессе восстановления убрать эффект всех транзакций, не окончившихся к моменту сбоя. Фиксация транзакции состоит в том, что на сервере все объекты, модифицированные данной транзакцией, передвигаются из буфера объектов в буфер страничек.

Поддерживается механизм индексирования, основанный на использовании техники B +-деревьев. Можно создавать индексы для 1-го класса и 1-го характеристики либо для нескольких параметров нескольких классов.

Имеется возможность сотворения классов, поддерживающих оповещение. Имеются две формы оповещения – пассивная и активная. Пассивное оповещение заключается в том, что сохраняется информация о модификации либо удалении экземпляров класса. приложение может обратиться классу с запросом данных о таковых событиях. Активное оповещение приводит к вызову некой операции при выполнении операций модификации, удаления, сотворения версии, перемещения объекта из общей базы данных в личную базу данных (check -out) либо напротив (check -in). По дефлоту выполнение операции оповещения приводит к отправке электрической почты привилегированному юзеру (админу системы), но допускается подмена поведения данной для нас операции.

Допускается создание временной, рабочей либо «выпускной» версии объекта. Для динамического либо статического связывания различных версий поддерживается иерархия происхождения версий. При использовании динамического связывания версий иерархия автоматом модифицируется при разработке новейших версий.

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

При использовании C++ стабильность достигается методом доступа к библиотеке классов, поддерживающих стабильность. В CLOS (Common Lisp Object System) обеспечивается метакласс стабильности. Постоянные объекты должны быть экземплярами классов, являющихся экземплярами этого метакласса. Не считая того, можно указать, что некие характеристики размеренного класса являются недолговечными.

В ITASCA поддерживаются C, C++, Smalltalk, CLOS. Упор делается на способности динамического конфигурации схемы без остановки деяния системы и без потребности в массовой повторной компиляции и редактирования связей. Доступ к программкам на любом из языков делается через многофункциональный API. В случае использования C++ автоматом создается файл заголовков, который соединяется с начальными файлами программного кода при генерации приложения.

Свой механизм запросов ITASCA дозволяет запрашивать данные в личной базе данных, общей базе данных либо сходу в обеих базах данных. Для увеличения производительности используются оптимизация запросов и способы распараллеливания.

2.4 Objectivity /DB

Компания Objectivity была образована в 1988г. В 1990 г. была выпущена 1-ая версия системы, которая представляла собой распределенную СУБД, основанную на использовании объектной технологии, высокопропускных локальных сетей и симметричных мультипроцессоров. Система работает на всех главных unix -платформах и в среде Windows[10].

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

Поддерживается четырехуровневая структура хранения данных. Объекты содержатся в контейнерах, любой из которых представляет собой часть локальной базы данных. Локальные же базы данных могут комбинироваться в федеративную (распределенную) базу данных. Надежность хранения данных поддерживается механизмом репликации.

Обеспечивается возможность конфигурации классов и автоматического образования новейших версий имеющихся объектов. Поддерживается механизм управления иерархиями версий объектов.

Допускаются как недлинные, так и долгие транзакции. Управление маленькими транзакциями основано на синхронизационных блокировках и распознавании тупиков. Долгие транзакции и коллективная работа с базами данных основаны на многоверсионности объектов и механизме check -in / check -out.

В системе поддерживаются языки C++ и Smalltalk, но методы использования языков очень различаются. Это относится и к механизмам стабильности, и к средствам определения данных. В среде C++ размеренными являются объекты всех классов, являющихся наследниками специального системного класса. В среде Smalltalk размеренными являются все объекты, достижимые от именованных корневых объектов-словарей. Соответственно, в Smalltalk для удаления объектов употребляется механизм сборки мусора, а в C++ – очевидные операции.

естественно, базы данных, управляемые Objectivity /DB, основаны на одной объектной модели. Эта модель довольно близка к модели ODMG и, а именно, включает возможность определения двунаправленных связей. Поддерживается возможность управления составными объектами с распространением на подобъекты операции удаления. Но методы определения данных в средах C++ и Smalltalk различаются.

В C++ включено особое расширение языка, созданное для определения данных. Надлежащие конструкции обрабатываются особым препроцессором, который генерирует код C++, содержащий надлежащие воззвания к СУБД. В среде Smalltalk схема базы данных определяется как набор классов Smalltalk. Иными словами, при использовании Smalltalk приложения, работающие с базами данных Objectivity /DB, организуются наиболее прозрачным образом, чем в случае C++.

Имеется поддержка языка SQL /89 и, отчасти, SQL /92. Реляционный доступ к базам данных, управляемых Objectivity /DB, вероятен через интерактивный SQL-ориентированный интерфейс, через имеющийся драйвер ODBC и через API.

Крайняя версия Objectivity /DB совершенно, по заявлениям конторы, подступает для приложений, которые работают в распределенных средах, требуют гибкой модификации данных, организации сложных связей, также нуждаются в высочайшей производительности и работы с большенными размерами данных. Наиболее содержательно, Objectivity обеспечила интеграцию инвентаря СУБД и разработки приложений с таковыми средствами программирования, как SoftBench и C++. Благодаря интегрированному графическому интерфейсу разработки схемы БД и инструментам отладки и анализа упрощается задание модели базы данных и, соответственно, разработки приложений для Objectivity /DB.

2.5 ObjectStore

Компания Object Design была базирована в 1988 г. с критической целью создать и вывести на Рынок ООСУБД, которую стали именовать ObjectStore. В конце 90-х у Object Design установились тесноватые партнерские дела с IBM, что позволило привлечь к ObjectStore тыщи разрабов приложений. На базе технологии ObjectStore компанией был разработана одна из первых коммерческих СУБД – Excelon, направленная на управление XML -данными. С начала 2003г. компания является подразделением компании Progress Software[11].

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

Серверная часть спроектирована в расчете на внедрение механизма отображения виртуальной памяти, которая распространяется на всю сеть и может обхватывать несколько серверов. Извлекаемые из базы данных объекты могут объединяться в пакеты для передачи по сети, что дозволяет понизить размер сетевого трафика. Для сокращения времени доступа в серверах употребляется техника кластеризации. На каждой клиентской части имеется локальный кэш, в каком сохраняются применяемые объекты. Когда объект {перемещается} в адресное место клиента, ссылки на него перерабатываются таковым образом, что для всякого к объекту доступа довольно одной команды компа.

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

Надежность хранения данных обеспечивается за счет поддержания журнальчика сделанных конфигураций. Подсистема управления транзакциями отвечает за журнализацию всех сделанных конфигураций на базе протокола WAL (Write Agead Log – упреждающей записи в журнальчик). Добавочно поддерживается архивный журнальчик, в каком авторизованный юзер может произвести архивное копирование базы данных.

Имеется средство поддержки версий, которое обеспечивает возможность коллективной работы с базами данных на базе устройств check -in / check -out. На этом подходе основывается поддержка длительных транзакций. Для каждой конфигурации объектов можно сделать историю версий, независимую от типов объектов.

В ObjectStore стабильность хранения объектов поддерживается за счет наличия именованных корневых размеренных объектов класса база данных. База данных создается при помощи вызова способа new этого класса. Имеются способы для открытия и закрытия базы данных. Не считая того, в классе содержатся способы для сотворения размеренных корневых объектов, обычно являющихся коллекциями, в каких располагаются постоянные объекты.

Поддерживаются языки C, C++ и Smaltalk. Свойство стабильности обеспечивается за счет включения в библиотеку классов особых системных классов. Имеются классы, поддерживающие коллекции – списки, огромного количества, мультимножества и массивы. способы этих классов поддерживают подборку объектов из коллекций, вставку и удаление объектов.

Поддерживаются шлюзовые объекты, поддерживающие доступ к реляционным данным, также инструментальные средства для отображения реляционной схемы в эквивалентное объектно-ориентированное работать в интерфейсе ODBC на базе SQL либо в своем интерфейсе ObjectStore.

2.6 Versant

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

Архитектура Versant в основном нацелена на логическое управления данными, т.е. объектами, а не на физическое кэширование.

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

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

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

Фиксация распределенных транзакций основывается на двухфазном протоколе фиксации. Поддерживаются частичная фиксация кэшей, механизмы контрольных точек и точек сохранения. Обеспечивается и возможность образования вложенных транзакций. При реализации длительных транзакций употребляется механизм check -in / check -out с установкой размеренной блокировки на требуемые объекты, предотвращающей доступ к сиим объектам со стороны остальных транзакций до окончания данной долгой транзакции.

Имеется возможность регистрации на сервере событий, которые заинтересовывают приложения. При регистрации серверу сообщается вид действия и операция, которую следует делать при появлении действия. К событиям, которые разрешается регистрировать, относятся обновление и удаление классов, создание, обновление и удаление объектов.

Для увеличения надежности хранения баз данных поддерживаются два вида журналов – логический и физический. По мере необходимости восстановления базы данных по архивной копии все зафиксированные к моменту сбоя транзакции повторно воспроизводятся по логическому журнальчику.

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

Для представления связей меж объектами базы данных употребляется единый размеренный указательный тип. В системе поддерживаются сокрытые от юзеров преобразования указателей базы данных в обыденные указатели C ++ и напротив. Потому объекты создаются и ликвидируются при помощи обычных конструкторов и деструкторов классов.

Для программирования можно применять языки C++ и Smalltalk, при этом безо всяких расширений. Поддерживаются способности, специфичные для работы с базами данных. к примеру, имеется средство автоматической генерации схемы базы данных прямо по файлам заголовков C++. Это дозволяет обойтись без использования специализированных препроцессоров либо компиляторов. Особые системные классы разрешают работать со всеми разновидностями типов коллекций, специфицированными в эталоне ODMG. Хоть какой объект, сделанный в среде C++, доступен в среде Smalltalk и напротив.

Запросы к базам данных Versant можно задавать при помощи специального системного класса, позволяющего обходить объекты коллекций. Поддерживается расширенный вариант SQL /89. Имеется драйвер ODBC. Обеспечивается доступ из среды Versant к наружным реляционным базам данных.

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Андреев А.М. Среда и хранилище: ООБД. – М.: «Мир ПК (Персональный компьютер — компьютер, предназначенный для эксплуатации одним пользователем)», 1997.

2. Аткинсон М. Манифест систем объектно-ориентированных баз данных, СУБД, N 4, 1995, с.142-155.

3. Буч Г. Объектно-ориентированный анализ и проектирование. 2-ое издание. — М.: «Двучлен», 1997.

4. Замулин А.В. системы программирования баз данных и познаний. — Новосибирск: Наука; Сиб. отд-ние, 1993.

5. Кирстен В. СУБД разработка язык программирования C++. 3-е издание. — М.: «Двучлен», 1997.

8. Материалы с веб-сайта разраба. [Электронный ресурс]. – Режим доступа: HTTP://www.gemstone.com/.

9. Материалы с веб-сайта разраба. [электронный ресурс]. – Режим доступа: HTTP://www.ibex.ch/.

10. Материалы с веб-сайта разраба. [Электронный ресурс]. – Режим доступа: HTTP://www.objectivity.com/.

11. Материалы с веб-сайта разраба. [электронный ресурс]. – Режим доступа: HTTP://www.objectstore.net/.

12. Материалы с веб-сайта разраба. [Электронный ресурс]. – Режим доступа: HTTP://www.versant.com/.

]]>