22. Системная архитектура "клиент-сервер"

Чтобы прикладная программа, выполняющаяся на рабочей станции, могла запросить услугу у некоторого сервера, как минимум требуется некоторый интерфейсный программный слой, поддерживающий такого рода взаимодействие. Из этого и вытекают основные принципы системной архитектуры "клиент-сервер". Система разбивается на две части, которые могут выполняться в разных узлах сети, - клиентскую и серверную части. Прикладная программа или конечный пользователь взаимодействуют с клиентской частью системы, кот в простейшем случае обеспечивает просто над сетевой интерфейс. Клиентская часть системы при потребности обращается по сети к серверной части. В развитых системах сетевое обращение к серверной части может и не понадобиться, если система может предугадывать потребности пользователя, и в клиентской части содержатся данные, способные удовлетворить его следующий запрос. Интерфейс серверной части определен и фиксирован. Поэтому возможно создание новых клиентских частей существующей системы.

Осн проблема систем, основанных на архитектуре "клиент-сервер": в соответствии с концепцией открытых систем от них требуется мобильность в как можно более широком классе аппаратно-программных решений открытых систем. Еще более сложный аспект этой проблемы связан с возможностью использования разных представлений данных в разных узлах неоднородной локальной сети. В разных компьютерах может существовать различная адресация, представление чисел, кодировка символов и т.д. Это особенно существенно для серверов высокого уровня: телекоммуникационных, вычислительных, бд. Общие решение проблемы мобильности систем, основанных на архитектуре "клиент-сервер": опора на програм пакеты, реализующие протоколы удаленного вызова процедур. При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в кот содержится вся информация о специфике аппаратуры локальной сети и сетевых протоколов, переводит вызов в последова сетевых взаимодействий. специфика сетевой среды и протоколов скрыта от прикладного программиста. Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.

24. Бд на инвертированных списках

Организация доступа к данным на основе инвертированных списков использ практически во всех современных реляц СУБД, но в этих системах пользователи не имеют непосредственного доступа к инвертированным спискам (индексам). Вну интерфейсы реляц СУБД очень близки к пользовательским интерфейсам систем, основ на инвертированных списках. 1. Структуры данных. Бд, организов с помощью инвертированных списков, похожа на реляц БД, но с тем отличием, что хранимые таблицы и пути доступа к ним видны пользователям. При этом: a. Строки таблиц упорядочены системой в некоторой физической послед-ти. b. Физическая упорядоченность строк всех таблиц может опред-ся и для всей БД. c. Для каждой таблицы можно опр-ть произвольное число ключей поиска, для кот строятся индексы. Эти индексы автоматически поддерживаются системой, но явно видны пользователям. 2. Манипулирование данными. Поддерживаются два класса операторов: a. Операторы, устанавливающие адрес записи, среди кот: • прямые поисковые операторы (например, найти первую запись таблицы по некоторому пути доступа); • операторы, находящие запись в терминах относительной позиции от предыдущей записи по некоторому пути доступа. b. Операторы над адресуемыми записями. Типичный набор операторов: • LOCATE FIRST - найти первую запись таблицы в физическом порядке; возвращает адрес записи; • LOCATE FIRST WITH SEARCH KEY EQUAL - найти первую запись таблицы с заданным значением ключа поиска; возвращает адрес записи; • LOCATE NEXT - найти первую запись, следующую за записью с заданным адресом в заданном пути доступа; возвращает адрес записи; • LOCATE NEXT WITH SEARCH KEY EQUAL - найти следующую запись таблицы в порядке пути поиска с заданным значением ключа; должно быть соответствие между используемым способом сканирования и ключом; возвращает адрес записи; • LOCATE FIRST WITH SEARCH KEY GREATER - найти первую запись таблицы в порядке ключа поиска cо значением ключевого поля, большим заданного значения ключа; возвращает адрес записи; • RETRIVE - выбрать запись с указанным адресом; • UPDATE - обновить запись с указанным адресом; • DELETE - удалить запись с указанным адресом; • STORE - вкл запись в указанную таблицу; операция генерирует адрес записи. 3. Ограничения целостности. Общие правила определения целостности БД отсутствуют. В некоторых системах поддерживаются ограничения уникальности значений некоторых полей, но в основном все возлагается на прикладную программу.