Фуфаев - Разработка и эксплуатация удалённых БД (1084483), страница 46
Текст из файла (страница 46)
%ЯВЬ-документ является динамически создаваемым и будет автоматически отображать любые изменения класса %еЬ- зевсе; ° ГОАР-с1)епг открывает доступный %еЬ-вегу)се, запрашивая %ЯЭ1;документ, который, в свою очередь, посылает запрос СасЬесерверу. Используя эту информацию в %ЯЭ).-документе, эОАР- сйепг активизирует определенный метод с помощью создания ХМЬ- сообщения и посылки его (с помощью НТТР) ГОАР-серверу; ° ГОАР-сервер Сасйе получает вызов эОАР с помощью СасЬе (СэР) НТТР Оагеюау. Сервер распаковывает сообщение, проверяет его правильность и вызывает определенный %еЬ-метод. Перед вызовом %еЬ-метода эОАР-сервер Сасйе конвертирует все входные параметры к соответствующему представлению СасЬе; ° %еЬ-метод выполняет свой код и возвращает ответ.
Этот ответ может быть простой строковой константой, может быть ХМЬ- объектом или массивом. Система Сасйе обеспечивает возможность создания класса бОАР-зету)се сйепг, содержащего методы, которые вызывает %еЬ- вегу(се, используя ГОАР-протокол. Для каждого %еЬ-вегу)се (набора связанных методов ГОАР), который вы желаете вызвать, необходимо создать новое определение класса СасЬе, которое получено от %ГОАР.%еЬС11еш, находящегося в библиотеке СасЬе. Класс эОАР-с1)епг содержит один или более методов, соогветствующих методам %еЬ-зету)се. При компиляции класса ГОАР-с11епг транслятор класса Сасйе автоматически транслирует информацию катапога, описание содержания ГОАР и создает интерфейс ГОАР-с)1епг для каждого %еЬ-вегу)се; Интерфейс ГОАР-с11еш для %еЬ-вегу)се — это сгенерированный класс, который исполняет работу преобразования запроса ГОАР в определенный запрос %еЬ-вегу(се, используя технологию перевода объекта в формат ХМ1.. 227 БОАР-зег?1се обнаруживает доступный %еЬ-зегт1се с помощью запроса %БРЬ-документа от %еЬ-сервера, который, в свою очередь, запрашивает его у Сасйе-сервера.
Используя эту информацию в %БОЬ-документе, ГОАР-с11епг вызывает определенный метод, создавая ХМ1,-сообщение н отправляя его через НТТР на ГОАР-сервер, как определено в %ЯЭ1.-документе. ГОАР-сервер получает запрос БОАР, распаковывает сообщение, проверяет его и вызывает указанную операцию. Контрольные вопросы 1. Чем принципиально отличается СУБД Сасйе ст реляционных СУБД? 2. Как осуществляется в системе Сасйе прямой доступ к данным? 3. Какие протоколы передачи информации в сети Интернет поддерживаются в системе Сасйе? 4. Перечислите особенности среды разработки приложений У1ьца! Вах1с.?ЧЕТ. ГЛА ВА 17 СИСТЕМЫ БАЗ ДАННЫХ, ОСНОВАННЫЕ НА ПРАВИЛАХ 17.1.
Структура базы данных В базе данных хранится три вида информации. 1. Информация, характеризующая структуры пользовательских данных (описание структурной части схемы базы данных). В реляционных базах данных такая информация сохраняется в системных отношениях-каталогах и содержит главным образом имена базовых отношений, имена и типы данных их атрибутов. 2. Наборы кортежей пользовательских данных, сохраняемых в определенных пользователями отношениях. 3. Правила, определяющие ограничения целостности базы данных, триггеры базы данных и представляемые (виртуальные) отношения. В реляционных системах правила также сохраняются в системных таблицах-каталогах, хотя плоские таблицы далеко не идеально подходят для этой цели. Информация первого и второго видов в совокупности явно описывает объекты (сущности) реального мира, моделируемые в базе данных. Другими словами, это явные факты, предоставленные пользователями для хранения в БД.
Эту часть базы данных принято называть энстенциональной. Информация третьего вида служит для руководства СУБД при выполнении различного рода операций, задаваемых пользователями. Ограничения целостности могут блокировать выполнение операций обновления базы данных, триггеры вызывают автоматическое выполнение специфицированных действий при возникновении специфицированных условий, определения представлений вызывают явную или косвенную материализацию представляемых таблиц при их использовании.
Эту часть базы данных принято называть ингненциональной; она содержит не непосредственные факты, а информацию, характеризующую семантику предметной области. В реляционных базах данных наиболее важное значение имеет экстенциональная часть, а интенциональная часть играет в основном вспомогательную раль. В системах баз данных, основанных на правилах, эти две части, как минимум, равноправны. 229 17.2. Активные базы данных База данных называется активной, если СУБД по отношению к ней выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД. Основа идеи создания активной БД содержалась в языке Я НЬ.
Действительно, есть определение триггера или условного воздействия, как не введение в БД правила, в соответствии с которым СУБД должна производить дополнительные действия. Плохо лишь то, что триггеры не были полностью реализованы ни в одной из известных систем. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна и не совсем понятна. Среди вопросов, ответы на которые до сих пор не получены, следующие. Как эффективно определить набор вспомогательных действий, вызываемых прямым действием пользователя? Каким образом распознавать циклы в цепочке действие — условие — действие — .
и что делать при возникновении таких циклов? В рамках какой транзакции выполнять дополнительные условные действия и к бюджету какого пользователя относить возникающие накладные расходы? Масса проблем не решена даже для сравнительно простого случая реализации триггеров Я )Ь, а задача ставится уже гораздо шире. Предлагается иметь в составе СУБД продукционную систему общего вида, условия и действия которой не ограничиваются содержимым БД или прямыми действиями с ее данными пользователя. Условие может содержать время суток, а действие может быть внешним, например вывод информации на экран оператора. Практически все современные работы по активным БД связаны с проблемой эффективной реализации такой продукционной системы.
Намного важнее в практических целях реализовать в реляционных СУБД аппарат триггеров. В проекте стандарта БОЬЗ предусматривается существование языковых средств определения условных воздействий. Их реализация и будет первым практическим шагом к содержанию активных БД (уже имеются соответствующие коммерческие реализации).
17.3. Дедуктивные базы данных Дедуктивная БД состоит из двух частей: экстенциональной, содержащей факты, и интенциональной, содержащей правила для логического вывода новых фактов на основе экстенциональной части и запроса пользователя. 230 При таком общем определении БО -ориентированную реляционную СУБД можно отнести к дедуктивным системам. Действительно, что есть определенные в схеме реляционной БД представления, как не интенциональная часть БД. Не так уж важно, какой конкретный механизм используется для вывода новых фактов на основе существующих, В случае использования Я)) основным элементом определения представления является оператор выборки языка Я.)1., что вполне естественно, поскольку с его помошью создается таблица.
Обеспечивается при этом и необходимая расширяемость, поскольку представления могут определяться не только над базовыми таблицами, но и над запросами. Основным отличием реальной дедуктивной СУБД от реляционной является то, что в ней и правила интенциональной части БД, и запросы пользователей могут содержать рекурсию. При этом можно спорить о том, что всегда ли это хорошо. С одной стороны, возможность определения рекурсивных правил и запросов обеспечивает простое решение в дедуктивных базах данных проблем, которые вызывают большие трудности в реляционных системах (например, проблемы разборки сложной детали на примитивные составляющие).
С другой стороны, именно возможность рекурсии делает реализацию дедуктивной СУБД очень сложной и во многих случаях неразрешимой проблемой. Не будем подробно рассматривать конкретные проблемы, применяемые ограничения и используемые методы в дедуктивных системах. Отметим лишь, что обычно языки запросов и определения интенциональной части БД являются логическими (поэтому дедуктивные БД часто называют логическими). Имеется прямая связь дедуктивных БД с базами знаний (интенциональную часть БД можно рассматривать как базу знаний — БЗ). Более того, трудно провести грань между этими двумя сущностями; по крайней мере, общего мнения по этому поводу не существует. Какова же связь дедуктивных БД с реляционными СУБД, кроме того, что реляционная БД является частным случаем дедуктивной? Связь заключается в том, что для реализации дедуктивной СУБД обычно применяется реляционная система, которая выполняет роль хранителя фактов и исполнителя запросов, поступающих с уровня дедуктивной СУБД.
Такое использование реляционных СУБД резко актуализирует задачу глобальной оптимизации запросов. При применении реляционной СУБД запросы обычно поступают на обработку по одному, поэтому нет повода лля их глобальной (межзапросной) оптимизации. Дедуктивная же СУБД при выполнении одного запроса пользователя в общем случае генерирует паке~ запросов к реляционной СУБД, которые могут оптимизироваться совместно. 231 Конечно, когда набор правил дедуктивной БД становится большим и их невозможно разместить в оперативной памяти, возникает проблема управления их хранением и доступом к ним во внешней памяти.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
