Архитектура, основанная на объектах
Архитектура, «основанная на объектах», является сбалансированной конструкцией, в которой кэширование и поддержка функционирования осуществляется как в процессах приложений, так и в серверных процессах. Серверный процесс кэшируют страницы диска и управляет индексами, блокировками, запросам и транзакциями. Код пользовательского приложения компонуется с клиентскими библиотеками ООСУБД, обеспечивающими кэширование объектов, локальные блокировки и управление жизненным циклом объектов. Не требуется реализация каких-либо стратегий размещения объектов.
В этой архитектуре процесс сервера поддерживает очереди запросов блокировок на уровне объектов для управления параллельным доступом к одному и тому же объекту. Запрос блокировки для обновления образует очередь, если имеются читатели объекта. Этот запрос либо удовлетворяется, когда все читатели освобождают свои блокировки, либо отвергается по истечению предельно допустимого интервала времени. После образования очереди запросом блокировки для обновления все последующие запросы попадают в очередь за этим запросом для обновления. После выполнения обновления и снятия соответствующей блокировки с объекта все запросы блокировок для чтения удовлетворяются, и, если больше нет обновлений, очередь исчезает. Клиенты, кэшировавшие обновленный объект, должны обновить его в кэше при последующем чтении. В этой архитектуре блокировки устанавливаются на уровне объектов, поэтому ложные ожидания и ложные синхронизационные тупики не возникают.
В реализации архитектуры, основанной на объектах, используется процессор выполнения запросов, который выполняется в процессе сервера баз данных. Любой объект базы данных достижим через запрос, даже если у него отсутствует связь с другими объектами. Атрибуты объектов могут индексироваться при поддержке сервера баз данных. Запрос производится путем посылки серверу некоторого оператора, который выполняется на сервере с использованием оптимизатора и механизма индексации, и клиенту возвращается результирующий набор объектов. По сети передаются только оператор, который будет выполняться на сервере, и коллекция объектов, удовлетворяющих предикату, в качестве результата запроса. Эффективность выполнения запросов может обеспечиваться путем использования общесистемных идентификаторов, многопоточной, удаленной и распределенной обработки, агрегирования.
Для этой архитектуры единицей пересылки при запросе объекта являются объект или группа объектов в зависимости от заданной глубины связей, как проиллюстрировано ниже. Объект может являться коллекцией, и в этом случае при одном сетевом взаимодействии пересылается много объектов. В запросе объекта или коллекции может указываться глубина связей; тогда при одном сетевом взаимодействии вместе с указанным объектом будут пересылаться связанные с ним объекты в пределах указанной глубины связей. При пересылке объекта на него устанавливается блокировка. В случае коллекции или при указании глубины связей блокируются все объекты, посылаемые клиенту.
26.4 Архитектура клиент/сервер
Многие коммерческие ООСУБД используют архитектуру клиент/сервер для предоставления доступа к данным пользователям, приложениям и инструментам в распределенной вычислительной среде. Однако не во всех системах используется одинаковая модель "клиент/сервер". Применяемые модели можно разбить на три основных типа, отличающихся функциональностью их компонентов, как показано на рисунке ниже.
Сервер объектов (а)
В этом подходе предпринимается попытка распределить обработку между двумя компонентами. Обычно серверный процесс отвечает за управление хранилищем, блокировки, вывод данных на вторичные устройства хранения, регистрацию клиентов, процедуры восстановления, поддержку безопасности и обеспечение целостности, оптимизацию запросов и выполнение хранимых процедур. Клиент отвечает за управление транзакциями и взаимодействие с языком программирования. Это наилучший вариант архитектуры для кооперативной групповой обработки объектов и проектов в открытой распределенной среде.
Сервер страниц (б)
В этом подходе большая часть функций базы данных выполняется клиентом. Сервер отвечает за доступ к вторичным устройствам хранения и предоставление страниц по требованию клиента.
Сервер базы данных (в)
В этом подходе большая часть функций базы данных выполняется сервером. Клиент просто передает запросы серверу, получает результаты и передает их приложению. Такой подход используется во многих реляционных системах.
В каждом случае. сервер находится на том же компьютере, где располагается физическая база данных, а клиент может находиться на этом же или на другом компьютере. Если клиенту необходимо получить доступ к базам данных, распределенным среди нескольких компьютеров, то в таком случае ему придется обращаться к серверу на каждом из этих компьютеров. К одному серверу могут обращаться сразу несколько клиентов, представляющих отдельных пользователей или приложения.
Для управления методами могут использоваться два следующих подхода: хранение методов во внешних файлах:
И хранение методов в базе данных:
Первый подход аналогичен библиотекам функций или интерфейсам прикладного программирования (АРI) в традиционных СУБД, в которых прикладная программа взаимодействует с СУБД за счет компоновки с функциями, предоставляемыми фирмой-разработчиком СУБД. При использовании второго подхода методы хранятся в базе данных и динамически связываются с приложением во время выполнения программы. Второй подход обладает несколькими преимуществами:
1. Исключается избыточный код. Вместо размещения копии метода, обеспечивающего доступ к элементу данных в каждой программе, обрабатывающей эти данные, метод хранится в базе данных в единственном экземпляре.
2. Упрощаются модификации. При изменении метода все поправки потребуется внести только в одном месте. При этом все программы автоматически будут использовать обновленный метод. В зависимости от природы изменения, это позволяет исключить выполнение операции сборки, тестирования и повторного развертывания каждой из программ.
3. Методы защищены в большей степени. Хранение методов в базе данных позволяет применить к ним все меры безопасности, предоставляемые ООСУБД.
4. Методы могут совместно использоваться в параллельном режиме. В этом случае параллельный доступ также автоматически обеспечивается со стороны ООСУБД. Кроме того, эти же средства предотвращают одновременное внесение в некоторый метод различных изменений несколькими пользователями.
5. Повышенная целостность. Хранение методов в базе данных означает, что установленные ограничения целостности будут согласованно применяться ООСУБД по отношению ко всем приложениям.