21.Представление моделей доступа в КИСП (Документация по КСАМ (КИСП))

Представление моделей доступа к данным в КИСП

21. Представление моделей доступа к данным

в КИСП

В разделе "Модели доступа к данным" обсуждались основные способы доступа к базам данных. Ниже рассматриваются схемы описания в КИСП систем, которые поддерживают архитектуру клиент/сервер.

1. Модель сервера базы данных (рис. 21.1).

Рис. 21.1. Схема описания системы, поддерживающей модель

сервера базы данных

Здесь приложения (транзакции) выполняются, в основном, на рабочих станциях. Доступ к транзакции осуществляется из того же узла, где эта транзакция выполняется. Описание транзакции может содержать определения запросов к базе данных (то есть описания SQL-операторов), обращения к триггерам и хранимым процедурам, которые выполняются на сервере базы данных, обращения к другим транзакциям узла. В КИСП вызов триггера осуществляется из транзакции, хотя в реальной системе к триггеру обращается ядро СУБД при наступлении какого-либо события (например до или после обновления таблицы, при выполнении некоторого логического условия). В данном случае методическая ошибка моделирования связана только с передачей двух кадров (вход и выход) с пустыми пакетами.

В дальнейшем на рисунках отрезком прямой обозначена корпоративная сеть, которая может включать в себя взаимосвязанные LAN-, MAN- и WAN-сети. Правила описания топологии сети и других её характеристик приведены в разделе "Описание архитектуры сети".

Ясно, что при описании этой модели можно определить несколько транзакций различных типов, множество рабочих станций, серверов баз данных, по которым распределены таблицы базы данных.

2. Модель сервера приложений (рис. 21.2).

Рис. 21.2. Схема описания системы, поддерживающей модель

сервера приложений

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

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

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

В рассматриваемой модели допускается выполнение транзакций и на рабочих станциях.

3. Технология Internet/Intranet.

А. Доступ к базе данных из CGI- или ISAPI-программы (рис. 21.3).

Рис. 21.3. Схема описания системы, поддерживающей модель

доступа к базе данных из CGI- или ISAPI-программы.

Здесь можно считать, что все HTML-документы как бы хранятся в некоторой таблице (например, с именем "HTML-документы"). Схема таблица состоит из двух атрибутов: первый атрибут (индексированный) - это имя документа, его длина равна длине DET-элемента каталога файлов сервера, второй атрибут - это содержимое документа, его нечёткая длина равна размеру соответствующего HTML-файла. При поиске (Select) одной записи будет читаться блок индекса (элемент каталога) и блок(и) данных (файл с документом).

Сервер базы данных и Web-сервер могут функционировать на одной станции.

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

Б. Доступ к базе данных из Java- или JavaScript -программы (рис. 21.4).

Рис. 21.4. Схема описания системы, поддерживающей модель

доступа к базе данных из Java- или JavaScript -программы.

Как и в предыдущем случае здесь также можно считать, что все HTML-документы и Java-апплеты хранятся в таблицах. Если обращение к базе данных выполняется из фрагмента на языке JavaScript (или VBScript), встроенного в HTML-документ, то обращение к транзакции "Чтение Java-апплета" не требуется.

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

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

131