Разработка и эксплуатация удаленных баз данных - Общее - Операционные системы - Каталог статей

Архив

Главная » Статьи » Операционные системы » Общее

Разработка и эксплуатация удаленных баз данных

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-уровневая модель сервера:

Эта модель является расширением двухуровневой модели, т.е. вводится дополнительный промежуточный уровень между клиентом и сервером. В этой модели компоненты приложения делятся между тремя исполнителями:

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

Достоинства:

Обладает большей гибкостью, чем двухуровневая модель.

Категория: Общее | Добавил: Admin (24.07.2012)

Просмотров: 3659 | Теги: разработка, удаленных баз данных, эксплуатация | Рейтинг: 5.0/1

Всего комментариев: 0

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]

Полезное в сети

Всегда в теме

Статистика

Свежий софт

Рекомендуем

Архив

Поиск

Вход

Читаемое

Категории

Заходи не жди