Меню
Главная
УСЛУГИ
Авторизация/Регистрация
Реклама на сайте
Надзор при проведении работ, изменения в составе бригадыКак составить план работы?Состав субд и работа БДСостав документов, необходимых для решения вопроса о приеме на работуСостав группы и задачи работыСтатус судей, состав и организация работы конституционных (уставных)...Преступления против социально-политических прав и свобод....Преступления, выражающиеся в нарушении правил общей экологической...Состав и организация работы Конституционного Суда Российской ФедерацииСостав документов, необходимых для решения вопроса о приеме на работу
 
Главная arrow Информатика arrow Базы данных
< Предыдущая   СОДЕРЖАНИЕ   Следующая >

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

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

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

Схема РБД

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

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

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

Таблица 10.1

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

а) Служащий

N

Имя

Завод

Тариф

100

Иванов

1

6

101

Петров

1

6

102

Сидоров

2

10

103

Артемов

2

12

104

Печкин

3

5

105

Крамов

3

11

б) Завод

N

Расположение

1

С.-Петербург

2

Вологда

3

Сыктывкар

в) Сырье

N

Название

Количество

1

Картон

500

2

Картон

100

2

Открытки

940

3

Брошюры

75

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

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

Таблица 10.2

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

а) Служащий

N

Имя

Завод

Тариф

104

Печкин

3

5

105

Крамов

3

11

б) Завод

N

Расположение

1

С.-Петербург

2

Вологда

3

Сыктывкар

в) Сырье

N

Название

Количество

3

Брошюры

75

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

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

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

Таблица 10.3

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

Имя таблицы

Распределение фрагментов по узлам

Служащие

1

1. 2

1. з

Завод

1, 2, 3

I, 2, 3

1, 2, 3

Сырье

1

2

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. Архитектура клиент-сервер

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

ODBC в архитектуре клиент-сервер

Рис. 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 кбайт. Достигается этот результат за счет усложнения структуры.

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 
Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика