- •1. Методы распределенной обработки данных
- •1.1. Цели распределенной обработки данных
- •1.3. Архитектура удаленного доступа
- •1.5. Многоуровневые модели. Модель сервера приложений
- •1.6. Физическая модель срод
- •Основные понятия сетевой терминологии
- •2. Распределенные базы данных
- •2.2. Режимы работы с бд
- •2.3. Классификация систем по способам обработки данных
- •2.6. Свойства распределенных баз данных
- •2.7. Функции и архитектура сурбд
- •2.8. Распределенная база данных на примере вуЗа
- •3. Параллельные процессы (или процесс транзакций)
- •3.1. Транзакции
- •Свойства транзакций
- •3.2. Параллелизм операций над бд
- •3.3. Проблемы параллельных процессов
- •3.4. Элементы блокировки.
- •3.5. Расписание транзакций Последовательное исполнение транзакции при использовании блокировок элементов замедляет процесс работы с бд, хотя и работает правильно. Т1: lock a; unlock a;
- •3.6. Модели с блокировками для чтения и записи
- •3.7. Блокировки в Visual FoxPro
- •4. Структурированный язык запросов sql
- •5. Безопасность бд
- •5.3. Целостность данных
- •5.4. Шифрование данных
- •6. Хранилище данных
- •6.1. Концепции хранилища данных
- •6.2. Многомерная модель данных
- •6.4. Интеллектуальный анализ данных
- •7. Базы данных в Интернете
- •7.1. Язык html
- •Гипертекстовые ссылки
- •7.3. Средства взаимодействия.
- •8.1. Архитектура сервера
- •8.2. Табличные пространства и файлы данных
1.3. Архитектура удаленного доступа
Сервер – это собственно СУБД. Он поддерживает все основные функции СУБД: определение данных, обработку данных, защиту и целостность данных. Клиент – это различные приложения, которые выполняются под СУБД. Приложения – это программы, написанные на языках программирования С, Pascal и т.д. Клиент и сервер запускаются на разных машинах.
Существуют 2 способа: 1. Клиент может получать доступ к любому количеству серверов, но лишь к одному в одно и то же время. При этом пользователь должен знать, на какой именно машине, какая часть данных содержится (рис.1.5а ).
2. Клиент может получать доступ к любому количеству серверов одновременно. В этом случае серверы рассматриваются клиентом как один (с логической точки зрения), и пользователь может не знать, на какой именно машине какая часть данных содержится (рис.1.5б).
а) б)
Рис.1.5. Модели взаимодействия “клиента” и “сервера”
Появилась возможность использовать ресурсы каждого компьютера в сети.
Основной принцип технологии «клиент-сервер» применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп:
1. Функции ввода и отображения данных (Presentation Logic); 2. Функции решения задач приложения (Business Logic); 3. Функции обработки данных внутри приложения (Database Logic); 4. Функции управления информационными ресурсами (Database Manager System); (СУБД) (DBMS) 5. Служебные функции (для связывания первых 4-х групп). Структура типового приложения, работающего с БД представлена на рис.1.6.
Рис.1.6. Структура типового приложения “клиента”
Функции 1-й группы Presentation Logic: • формирование экранных изображений; • чтение и запись в экранные формы информации; • управление экраном; • обработка движений мыши и нажатия клавиш клавиатуры.
Бизнес-логика определяет алгоритм решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как C, C++, Cobol, Visual-Basic.
Логика обработки данных - связана с обработкой данных внутри приложения. Данными управляет собственно СУБД (DBMS). Для обеспечения доступа к данным используется язык запросов и средства манипулирования данными стандартного языка SQL. Обычно операторы языка SQL встраиваются в языки 3-го или 4-го поколения (3GL, 4GL), которые используются для написания кода приложения.
1.4. Модели удалённого доступа
Модель файлового сервера “файл-сервер”(File Server, FS)
В этой модели презентационная логика и бизнес-логика располагаются на клиенте (рис.1.7). На сервере располагаются файлы с данными и поддерживается доступ к файлам. Функции управления информационными ресурсами находятся на клиенте.
Рис.1.7. Модель файлового сервера
В этой модели файлы БД хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база метаданных, находится на клиенте (метаданные – это данные о данных). Информация о хранимых данных: таблицы описания данных и связей, адресные таблицы и т.п. Достоинства этой модели в том, что мы имеем разделение монопольного приложения на два взаимодействующих процесса. При этом сервер может обслуживать множество клиентов, которые обращаются к нему с запросом. Собственно СУБД должна находиться в этой модели на клиенте.
Достоинства:
-
Простота логики
-
Низкие требования к аппаратному обеспечению
-
Малый объем требуемой памяти
-
Невысокая цена СУБД
Недостатки
-
Отсутствие многопользовательского режима • высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложениям; • узкий спектр операций манипулирования с данными; • отсутствие адекватных средств безопасности доступа к данным.
Модель «клиент-сервер» с бизнес-логикой на клиенте
Здесь БД хранится на сервере и ядро СУБД на сервере (рис.1.8). На клиенте располагаются презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL.
Рис.1.8. Модель “клиент-сервер”
Преимущества: Резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод/вывод файлов, а запросы SQL, а их объём существенно ниже. В ответ на запросы клиент получает только данные, релевантные запросу, а не блоки файлов, как в FS-модели. Недостатки: • SQL – запросы при интенсивной работе клиентских приложений могут существенно загрузить сеть;
* Дублирование кода приложения при одинаковых запросах для каждого клиентского приложения; • Сервер в этой модели играет пассивную роль.
Данная модель и предыдущие модели называются моделями с «толстым клиентом».
Модель «клиент-сервера» с бизнес-логикой на сервере
Данную модель поддерживает большинство современных СУБД: Informix, Ingres, SyBase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур (ХП) как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных (рис.1.9).
Рис.1.9. Модель “сервера БД”
В этой модели бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур – ХП. Хранимые процедуры это специальные программные модули, которые хранятся в БД и управляются непосредственно из СУБД. Клиент обращается к серверу с командой запуска ХП, а сервер выполняет эту процедуру и регистрирует все изменения в БД. Сервер возвращает клиенту данные, релевантные его запросу. Трафик обмена информацией резко уменьшается. Централизованный контроль выполняется и с использованием механизма триггеров. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определённого события в БД. При возникновении соответствующего события, сервер запускает соответствующий триггер. Триггеры могут вызывать ХП. Для написания ХП и триггеров используется расширение стандартного языка SQL, так называемый, встроенный SQL. Недостаток - большая загрузка сервера. Данную модель называют с «тонким клиентом» в отличие от предыдущих моделей.
Хранимые процедуры (ХП)
ХП – это подпрограммы, которые выполняются на сервере. ХП хранятся в БД. Удобство, что одна процедура может быть использована в любом количестве клиентских приложений. Хранимые процедуры могут быть активизированы как пользовательскими приложениями, так и триггерами.
ХП могут быть написаны на собственных ЯП СУБД. Так в СУБД Oracle для этого используется язык PL/SQL, а в MS SQL Server используется язык Transact SQL.
Пример.
Create proc pr1 As Select *
From stud
Where spec=”2201”
ХП вызывается оператором EXEC <имя проц.><значение входного параметра><имя переменной для выходного параметра>
EXEC pr1
Триггеры
Триггер – это специальный вид ХП, который вызывается при выполнении операций модификации соответствующих таблиц. Триггер автоматически активизируется при выполнении операции, с которой он связан. Для создания триггеров используется специальная команда:
Create trigger <имя триггера>
On <имя таблицы> For {[insert][update][.delete]} - [with encripting] AS
SQL – операторы (тело триггера)
Достоинства
-
Пониженные требования к пропускной способности сети.
-
Более простой процесс создания бизнес-логики.
Недостатки
-
Повышенные требования к серверу БД.
-
Требования большей памяти.
-
Невысокая переносимость (мобильность) системы на другие серверы БД.