Содержание
Модуль 1. Разработка и эксплуатация удаленных баз данных
1.1. Введение в дисцплину.
При размещении БД на ПК, который не находится в сети, БД всегда используется в монопольном режиме. Даже если БД используют несколько пользователей, они могут работать с БД только последовательно. Однако работа на изолированном ПК с небольшой БД в настоящий момент становится уже не характерной для большинства приложений. БД отражает информационную модель реальной ПО, она растет по объему => резко увеличивается количество задач, решаемых с помощью этой БД и в соответствии с этим увеличивается количество приложений, работающих с единой БД. ПК объединяются в локальные сети и необходимость распределения приложений, работающих с единой БД по сети, является несомненной.
Параллельный доступ к одной БД нескольких пользователей, в том случае, если БД расположена на одной машине, соответствует режиму распределенного доступа к центральной БД. Такие системы называются системами распределенной обработки данных.
Если же БД расположена на нескольких ПК, распределенных в сети, и к ней возможен параллельный доступ нескольких пользователей, то мы имеем дело с параллельным доступом к распределенным БД. Такие системы называются системами распределенных (удаленных) баз данных.
Режимы работы с базой данных.
1.2. Терминология УБД.
Пользователь БД - это программа или человек, обращающиеся к БД на языке манипулирования данными.
Запрос - это процесс обращения пользователя к БД с целью ввода, получения или изменения информации в БД.
Транзакция - это последовательность операций модификации данных в БД, переводящая БД из одного непротиворечивого состояния в другое непротиворечивое состояние.
Логическая структура БД - это определение БД на физически независимом уровне, ближе всего соответствующем концептуальной модели БД.
Топология БД (структура РБД) - это схема распределения физических БД по сети. Локальная автономность означает принадлежность локальному владельцу информации локальной БД и связанных с ней определенных данных.
Удаленный запрос - это запрос, который выполняется с использованием модемной связи.
Возможность реализации удаленной транзакции - это обработка одной транзакции, состоящей из множества SQL-запросов, на одном удаленном узле.
Поддержка распределенной транзакции допускает обработку транзакции, состоящей из нескольких SQL-запросов, которые выполняются на нескольких узлах сети (удаленных или локальных), но каждый запрос в этом случае обрабатывается только на одном узле, т.е. запросы не являются распределенными. При обработке одной распределенной транзакции разные локальные запросы могут обрабатываться в разных узлах сети.
1.3. Модель "клиент-сервер"
Модель "клиент-сервер" связана с принципом открытых систем. Термин "клиент-сервер" исходно применялся в архитектуре ПО, которое ориентировало распределение процесса выполнения по принципу взаимодействия 2-х программ, процессов, один из которых в этой модели назывался клиентом, а другой - сервером.
При этом предполагалось, что один серверный процесс может обслуживать множество клиентских процессов.
Ранее приложение (пользовательская программа) не разделялось на части, а выполнялось монолитным блоком, но при рациональном использовании ресурсов сети данный принцип не актуален. Теперь все ПК в сети обладают собственными ресурсами и разумно так распределить нагрузку на них, чтобы максимальным образом использовать их ресурсы. Основной принцип технологии "клиент-сервер" в БД заключается в разделении функций стандартного интерактивного приложения на 5 групп:
- Функция ввода и отображения данных (PL);
- Прикладные функции, определяющие основные алгоритмы решения задач приложения (BL);
- Функции обработки данных внутри приложения (DL);
- Функции управления информационными ресурсами (DML);
- Служебные функции, играющие роль связок между функциями 1-х и 4-х групп.
Структура типичного приложения, работающего с БД.
PL - это часть приложения, которая определяется тем, что пользователь видит на экране, когда работает приложение (интерактивные экранные формы, а также все то, что выводится пользователю на экран, результаты решения некоторых промежуточных задач, справочная информация).
Основные задачи PL:
- формирование экранных изображений;
- чтение и запись в экранные формы информации;
- управление экраном;
- обработка движений мыши и нажатий клавиш клавиатуры.
BL - это часть кода приложения, которая определяет алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования.
DL - это часть кода приложения, которая связана с обработкой данных внутри приложения (данными управляет собственно СУБД), где используется язык запросов и средства манипулирования данными стандартного языка SQL.
Процессор управления данными (Data Base Manager System Processing) - это собственно СУБД, которая обеспечивает управление и хранение данных. В идеале СУБД должна быть скрыта от BL-приложения. Однако для рассмотрения архитектуры приложения нам надо их выделить в отдельную часть приложения.
1.4. Двухуровневые модели.
Эти модели фактически являются распределением пяти указанных функций между двумя процессами, которые выполняются на двух платформах - клиенте и сервере.
Модель удаленного управления данными (модель файлового сервера).
В этой модели BL и PL располагаются на клиенте. На сервере располагаются файлы с данными и доступ к ним. Функции управления информационными ресурсами в этой модели находятся на клиенте.
Модель файл-сервера.
В этой модели файлы БД хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами (база метаданных (БМД)) находится на клиенте.
Достоинства:
- разделение монопольного приложения на два взаимодействующих процесса.
- сервер может обслуживать множество клиентов, которые обращаются к нему с запросами.
Алгоритм выполнения запроса клиента.
Запрос клиента формируется в командах ЯМД. СУБД переводит этот запрос в последовательность файловых команд. Каждая файловая команда вызывает перекачку блока информации на клиента. Далее на клиенте СУБД анализирует полученную информацию и если в полученном блоке не содержится ответ на запрос, то принимается решение о перекачке следующего блока информации до тех пор, пока не будет найдено ответа на запрос.
Модель удаленного доступа к данным.
В модели удаленного доступа (RDA) база данных хранится на сервере. На нем же находится и ядро СУБД. На клиенте располагаются PL и BL приложения. Клиент обращается к серверу с запросами на языке SQL.
Достоинства:
- перенос компонента представления и прикладного компонента на клиентский ПК существенно разгружает сервер БД, сводя к минимуму общее число процессов в ОС.
- процессор сервера целиком загружается операциями обработки данных, запросов и транзакций.
- резко уменьшается загрузка сети, запросы на ввод-вывод и на SQL уменьшаются в объеме, т.е. в ответ на запросы клиент получает только данные, удовлетворяющие данному запросу.
- унификация интерфейса клиент-сервер.
- стандартным при обращении приложения клиента и сервера становится язык SQL.
Недостатки:
- запросы на SQL при интерактивной работе клиента могут существенно загрузить сеть.
- на клиенте располагаются PL и BL, и если при повторении аналогичных функций в различных приложениях (других клиентов) их код должен быть повторен для каждого клиентского приложения, следовательно, дублирование кода приложения.
- сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте => это усложняет клиентское приложение.
Модель сервера баз данных.
Для того, чтобы избавиться от недостатков модели удаленного доступа должны быть соблюдены следующие условия:
- Данные, которые хранятся в БД в каждый момент времени должны быть непротиворечивы.
- БД должна отображать некоторые правила ПО, законы ПО.
- Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них.
- Возникновение некоторой ситуации в БД четко и оперативно должно влиять на ход выполнения прикладной задачи.
- Одной из важных проблем СУБД является контроль типов данных через язык описания данных (ЯОД).
Модель активного сервера.
Данную модель поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server.
Основу данной модели составляет механизм хранимых процедур (как средства программирования SQL-сервера), механизм триггеров (как механизм отслеживания текущего состояния информационного хранилища) и механизм ограничений на пользовательские типы данных (который иногда называется механизмом поддержки доменной структуры).
В этой модели бизнес логика разделена между клиентом и сервером. На сервере бизнес логика реализована в виде хранимых процедур - специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедурой, а сервер выполняет эту процедуру и регистрирует все изменения в БД, которые в ней предусмотрены. Сервер возвращает клиенту данные, релевантные его запросу.
Трафик обмена информацией между клиентом и сервером резко уменьшается.
Централизованный контроль в данной модели выполняется с использованием механизма триггеров, которые являются частью БД.
Триггер - механизм отслеживания специальных событий, которые связаны с состоянием БД. Триггер в БД является как бы некоторым тумблером, который срабатывает при возникновении определенного события в БД. Ядро СУБД проводит мониторинг всех событий, которые вызывают созданные и описанные триггеры в БД, и при возникновении соответствующего события сервер запускает соответствующий триггер => триггер - это программа, которая выполняется над БД и вызывает хранимые процедуры.
Данная модель сервера является активной, потому что не только клиент, но и сам сервер используют механизм триггеров.
Достоинства:
- Хранимые процедуры и триггеры хранятся в словаре БД и могут быть использованы несколькими клиентами => уменьшается дублирование алгоритмов обработки данных в разных клиентских приложениях.
Недостатки:
- Очень большая загрузка сервера.
Функции сервера:
- Осуществляет мониторинг событий, связанных с описанными триггерами;
- Обеспечивает автоматическое срабатывание триггеров при возникновении связанных с ними событий;
- Обеспечивает исполнение внутренней программы каждого триггера;
- Запускает хранимые процедуры по запросам пользователей;
- Запускает хранимые процедуры из триггеров;
- Возвращает требуемые данные клиенту;
- Обеспечивает все функции СУБД: доступ к данным, контроль и поддержка целостности данных в БД, контроль доступа, обеспечение корректной работы всех пользователей с единой БД.
Для разгрузки сервера была предложена 3-уровневая модель сервера:
Эта модель является расширением двухуровневой модели, т.е. вводится дополнительный промежуточный уровень между клиентом и сервером. В этой модели компоненты приложения делятся между тремя исполнителями:
- Клиент - обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы.
- Серверы приложений - составляют новый, промежуточный уровень архитектуры.
- Они спроектированы как исполнение общих не загружаемых функций для клиентов, поддерживают функции клиентов, поддерживают сетевую доменную операционную среду, хранят и исполняют общие правила бизнес логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов.
- Серверы этой модели занимаются исключительно функциями СУБД, функции создания резервных копий БД и восстановления БД после сбоев, управление выполнением транзакций и поддержки устаревших (унаследованных) приложений.
Достоинства:
- Обладает большей гибкостью, чем двухуровневая модель.
содержание вперед на
главную
|