Состав и работа РБД

Схема РБД может быть представлена в виде, показанном на рис. 10.2. В ней выделяют пользовательский, глобальный (концептуальный), фрагментарный (логический) и распределенный (локальный) уровни представления данных (рис. 10.3), определяющие сетевую СУБД [11].

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

Рис. 10.2. Схема РБД.

Рис. 10.3. Уровни представления данных в РБД.

Таблица 10.1

Данные в РБД (глобальный уровень)

а) Служащий

б) Завод

в) Сырье

В табл. 10.1 разными шрифтами выделены фрагменты БД.

Не все данные глобального уровня доступны конкретному пользователю. Наиболее полные данные (пользовательский, внешний уровень) имеются в узле 1 головного предприятия. В узлах (участках) 2, 3 данные менее полные. Так, в узле 3 они имеют вид, показанный в табл. 10.2.

Таблица 10.2

Пользовательский уровень в РЕД

а) Служащий

б) Завод

в) Сырье

Пользовательский уровень состоит из фрагментов (например, строки 1, 2, 3 таблица «Завод» табл. 10.1) глобальною уровня, которые составляют фрагментарный, логический уровень.

Выделяют горизонтальную и вертикальную фрагментации (расчленение). Горизонтальная фрагментация связана с делением данных по узлам. Горизонтальные фрагменты нс перекрываются. Вертикальная фрагментация связана с группированием данных по задачам.

Фрагментация чаще всего не предполагает дублирования информации в узлах. В то же время при размещении фрагментов по узлам (локализации) распределенного уровня в узлах разрешается иметь копии той или иной части РБД. Так, например, локализация для примера в табл. 10.1 может иметь вид, показанный в табл. 10.3.

Таблица 10.3

Локализация данных

Очевидно, что для таблицы «Завод» осуществляется дублирование, а для таблицы «Сырье» — расчленение.

После размещения данных каждый узел имеет локальное, узловое представление (локальная логическая модель). Физическую реализацию (логического) фрагмента называют хранимым фрагментом.

Рис. 10.4. Схема работы РБД Иначе говоря, РБД можно представить в виде, показанном на рис. 10.3.

Сеть в РБД образуют сетевые операционные системы (например, Windows NT, Novell NetWare). В качестве СУБД, изначально предназначавшихся для использования в сети, следует назвать BTrieve, Oracle, InterBase, Sybase, Informix.

В силу распределенности данных особую значимость приобретает словарь данных (справочник) РБД, который в отличие от словаря централизованной БД имеет распределенную, многоуровневую структуру.

В общем случае могут быть выделены сетевой, общий внешний, общий концептуальный, локальные внешние, локальные концептуальные и внутренние составляющие словаря РБД.

Естественно, что для работы в РБД необходимы администраторы РБД и локальных БД, рабочими инструментами которых являются перечисленные словари.

Схема работы РБД показана на рис.

10.4.

Пользовательский запрос, определяемый приложением, поступает в систему управления распределенной базы данных (СУРБД), через сетевую и локальную операционные системы попадает в локальную СУБД. Если запрос связан с локальными данными, СУБД осуществляет вызов данных из локальной БД, которые поступают пользователю. Если часть данных для выполнения приложения находится в другой локальной БД, локальная СУБД дополнительно через локальные и сетевую операционные системы осуществляет удаленный вызов процедуры (Remote Procedure Call — PRC), после выполнения которой данные передаются пользователю.

Возможны четыре стратегии хранения данных: централизованная (часто обеспечиваемый архитектурой клиент-сервер), расчленение (фрагментации), дублирование, смешанная.

Сравнительные характеристики стратегий хранения приведены в табл. 10.4. На ее основе может быть построен простейший алгоритм выбора стратегии, приведенной на рис. 10.5.

Таблица 10.4

Стратегии хранения данных

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

Рис. 10.5. Алгоритм выбора стратегии хранения:

А — запрос локален В связи с этим часто используют архитектуру клиент-сервер (рис. 10.6) — структуру локальной сети, в которой применено распределенное управление сервером и рабочими станциями (клиентами) для максимально эффективного использования вычислительной мощности.

В этой структуре один из компьютеров, имеющий самый большой объем памяти и наиболее высокое быстродействие, становится приоритетным, называемым сервером. На сервере чаще всего хранятся только данные, запрашиваемые клиентами.

К клиентам не предъявляются столь жесткие требования по памяти и быстродействию. На них располагаются словари и приложения, служащие своеобразными фильтрами для данных сервера. В связи с этим обмен информацией в архитектуре (рис. 10.6) фактически минимизируется.

Работа в архитектуре клиент-сервер может поддерживаться и с помощью схемы Open DataBase Connectivity (ODBC), как показано на рис. 10.7. В этом случае сеть образуется путем соединения серверов. Такое соединение обеспечивается или средствами СУБД (SQL Server) или мониторами транзакций (TUXEDO).

Рис. 10.6. Архитектура клиент-сервер Обсудим более подробно вариант реализации РБД — архитектуру клиент-сервер.

Рис. 10.7. ODBC в архитектуре клиент-сервер Совместно с термином «клиент-сервер» используются три понятия.

• 1. Архитектура: речь идет о концепции построения варианта РБД.
• 2. Технология: говорят о последовательности действий в РБД.
• 3. Система: рассматриваются совокупность элементов и их взаимодействие.

Об архитектуре клиент-сервер говорилось ранее.

Технология клиент-сервер позволяет повысить производительность труда:

• • сокращается общее время выполнения запросов за счет мощного сервера;
• • уменьшается доля и увеличивается эффективность использования клиентом (для вычислений) центрального процессора;
• • уменьшается объем использования клиентом памяти «своего» компьютера;
• • сокращается сетевой трафик.

К таким крупномасштабным системам предъявляются следующие требования: I) гибкость структуры; 2) надежность; 3) доступность данных; 4) легкость обслуживания системы; 5) масштабируемость приложений; 6) переносимость приложений (на разные платформы); 7) многозадачность (возможность выполнения многих приложений).

Отметим, что архитектуре клиент-сервер предшествовала архитектура файл-сервер, в которой возможны следующие варианты.

• 1. На компьютерах-клиентах имеется копия БД. Работа по такому варианту имеет следующие сложности: синхронизация данных различных копий в конце работы БД; высокий трафик (потоки данных между сервером и клиентами, поскольку передается в любом случае содержимое всей БД).
• 2. В СУБД Access, которая изначально создана как локальная, предусмотрен режим деления базы данных. Таблицы остаются на сервере (back-end), а остальные объекты (запросы, отчеты) передаются клиентам (front-end). В этом случае по-прежнему большой трафик, в силу чего при использовании файл-серверов количество подключаемых клиентов — при их надежной работе — до четырех.

В то же время требовалось подключение десятков и даже сотен клиентов [1−3]. Этого удалось достичь в архитектуре (режиме, технологии) клиент-сервер. В этом режиме трафик резко уменьшается, поскольку по сети передаются только те данные, которые соответствуют запросам клиентов [2].

Для этого пришлось построить СУБД, изначально предназначенные для работы в сети. Фирма Microsoft [27−29] вынуждена была — в дополнение к СУБД Access, которая использовалась с помощью приложения ODBC только для клиентских целей — предложить в качестве сервера Microsoft SQL Server. Такая структура оказалась тяжеловесной и неудобной, так как разработчику требовалось знать уже две СУБД.

Из других предложений очень удачным оказался программный продукт Delphi [30−36], в рамках которого могут использоваться СУБД dBase, Paradox, и, при отдельной инсталляции, InterBase (режим клиент-сервер). При этом СУБД InterBase поддерживается, наряду с языком программирования SQL, мощным, понятным, простым и широко распространенным языком программирования (Object) Pascal [11], построенным с применением объектно-ориентированного подхода [33].

Последнее обстоятельство позволяет легко строить объектно-реляционные базы данных (см. гл. 9). Высокая степень автоматизации программирования дает возможность резко упростить и снизить трудоемкость процедур создания интерфейса пользователя, и особенно алгоритма приложения.

В системе клиент-сервер возможно выделить следующие составляющие: сервер, клиент, интерфейс между клиентом и сервером, администратор.

Сервер осуществляет управление общим для множества клиентов ресурсом. Он выполняет следующие задачи:

• • управляет общей БД;
• • осуществляет доступ и защиту данных, их восстановление;
• • обеспечивает целостность данных.

К БД на сервере предъявляются те же требования, как и к централизованной многопользовательской БД.

Следует отметить, что результаты запросов клиента помещаются в рабочую область памяти сервера, которая в ряде СУБД (например, Oracle) называют «табличная область». Поскольку она не занимает много места, для каждого клиента-пользователя целесообразно создавать свою табличную область. В этом случае исходные таблицы становятся для пользователя недоступными, а архивация (копирование) БД приложения клиента упрощается.

Клиент хранит в компьютере свои приложения, с помощью которых осуществляется запрос данных на сервере. Клиент решает следующие задачи:

• • предоставляет интерфейс пользователю;
• • управляет логикой работы приложений;
• • проверяет допустимость данных;
• • осуществляет запрос и получение данных с сервера.

Средством передачи данных между клиентом и сервером является сеть (коаксиальный кабель, витая пара) с сетевым (сетевая операционная система — СОС) и коммуникационным программным обеспечением.

В качестве СОС могут использоваться Windows NT, Novell NetWare. Коммуникационное программное обеспечение позволяет компьютерам взаимодействовать на языке специальных программ — коммуникационных протоколов.

В общем случае такое взаимодействие осуществляется с помощью семиуровневой схемы ISO с соответствующими протоколами. Для локальных сетей схема упрощается. Протоколоми для Windows NT служит Transmission Control Program/Internet Program (TCP/IP), для NetWare — Sequenced Packed eXchange/Intemet Packed eXchaned (SPX/IPX).

Разнообразие сетевых средств делает необходимым создание стандартного промежуточного программного обеспечения клиент-сервер, находящегося на сервере и клиентах. Говорят о прикладном программном интерфейсе (Application Programming Interface — API). Сюда относятся Open DataBase Connectivity (ODBC) и Integrated Database Application Programming Interface (IDAPI), используемый в приложении Delphi и СУБД InterBase.

Взаимодействие клиентов и сервера можно представить себе следующим образом.

При обращении пользователя к приложению компьютер-клиент запрашивает у пользователя имя и пароль. После этого — при правильном ответе — приложение может быть запущено клиентом. Приложение дает возможность подключиться к серверу, которому сообщается имя и пароль пользователя.

Если подключение осуществлено, начинает работать сервер, выполняющий два вида процессов: переднего раздела и фоновые.

Процессы переднего раздела непосредственно обрабатывают запросы, фоновая составляющая связана с управлением процессом обработки.

Работа сервера может иметь такой порядок.

• 1. После поступления запроса диспетчер ставит его в очередь по схеме «первым пришел — первым обслужен» .
• 2. Процесс переднего раздела выбирает «самый старый» запрос и начинает его обработку. После завершения результаты помещаются в очередь для передачи клиенту.
• 3. Диспетчер посылает результаты из очереди соответствующему клиенту.

При обработке запроса фоновые процессы выполняют другие важные операции, основными из которых являются следующие:

• • запись данных из БД в промежуточную (буферную) память рабочей области (при чтении) и обратно (при обновлении);
• • запись в журнал транзакций;
• • архивация (копирование) групп транзакций;
• • аварийное завершение транзакций;
• • периодическая запись на диск контрольных точек для обеспечения восстановления данных в РБД после аппаратного сбоя.

Администратор РБД (АРБД) должен решать следующие задачи [39].

• 1. Планирование РБД и распределение памяти.
• 2. Настройка конфигурации сети.
• 3. Создание РБД.
• 4. Работа с разработчиками приложений.
• 5. Создание новых пользователей и управление полномочиями.
• 6. Регулярная архивация БД и выполнение операций по ее восстановлению.
• 7. Управление доступом к БД с помощью ОС и СОС, средств защиты и доступа.

В больших системах AРБД может состоять из ряда лиц, отвечающих, например, за ОС, сеть, архивацию, защиту.

Таким образом, система клиент-сервер своеобразна: с одной стороны, ее можно считать разновидностью централизованной многопользовательской БД, с другой стороны, она является частным случаем РБД.

В связи с этим имеется специфика и в процессе проектирования. Оно по-прежнему начинается с создания приложения, затем — интерфейса и БД. Однако в силу специфики системы этапы фрагментации и размещения отсутствуют и есть свои особенности.

Основное ограничение для работы такой системы — минимальный трафик. Поэтому при разработке приложения, помимо обычных задач (уяснения цели приложения, логики обработки, вида интерфейса) особое внимание следует обратить на разработку DLLсценария и распределение функций между клиентами и сервером.

Использование для составления сценария CASE-средств значительно сокращает трудоемкость работ по проектированию. Иначе эта процедура выполняется вручную с помощью команд языка SQL.

Важнейшей является задача распределения функций. По самой сути технологии на сервере расположена БД, а на компьютерахклиентах — приложения. Однако при прямолинейных процедурах обеспечения целостности и запросах в сети может возникнуть объемный сетевой трафик.

Чтобы его снизить, возможно использовать следующие рекомендации.

• 1. Обеспечение целостности для всех приложений лучше централизовать и осуществлять на сервере. Это позволит не только сократить трафик, но и рационально использовать СУРБД, улучшив управление целостностью (ссылочной, ограничений, триггеров) данных.
• 2. Целесообразно использовать на сервере хранимые процедуры, совокупность которых можно инкапсулировать в виде пакета (модуля). В результате трафик уменьшится: клиент будет передавать только вызов процедуры и ее параметры, а сервер — результаты выполнения процедуры.
• 3. В ряде случаев клиентам следует получать уведомления базы данных (например, заведующему складом — о нижнем уровне запасов, при котором следует выполнять новый заказ). Если уведомление производится по запросу клиента, трафик увеличивается. Проще эту (хранимую) процедуру разместить на сервере, который будет автоматически уведомлять клиента о возникновении события. В то же время клиент при необходимости может получать информацию с помощью простых вызовов процедур.

В режиме клиент-сервер выделяют две разновидности структуры: одноуровневую, о которой шла речь до сих пор, и многоуровневую (рис. 10.8).

При использовании режима «толстого» клиента (одноуровневая структура) клиентские приложения находятся непосредственно на машинах пользователей, либо частично на сервере в виде системы хранимых процедур. Сложность клиентской части порой требует ее.

Рис. 10.8. Одноуровневая — «толстый» клиент (а) и многоуровневая — «тонкий» клиент (б) структуры клиент-сервер администрирования. Использование системы хранимых процедур в значительной мере снижает нагрузку на сеть. При использовании «тонкого» клиента (многоуровневая структура) приложения пользователей лежат и выполняются на отдельном мощном сервере (сервере приложений, который может быть и на одном компьютере с сервером БД), что в значительной мере снижает требования к пользовательским машинам.

Так, в СУБД InterBase в одноуровневой структуре в каждом клиенте имеется утилита Borland Database Engine (BDE — ядро Delphi) объемом 8 Мбайт. В многоуровневой структуре BDE-утилита имеется только в сервере приложений, а объем памяти, занимаемой клиентом, снижается до 212 кбайт. Достигается этот результат за счет усложнения структуры.