СУБД / УМК СУБД

Ведущими поставщиками СУБД сформулированы следующие свойства идеальной

системы управления распределенными БД:

прозрачность относительно расположения данных – СУБД должна представлять все данные так, как если бы они были локальными;

гетерогенность системы – СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью;

прозрачность относительно сети – СУБД должна одинаково работать в условиях разнородных сетей;

поддержка распределенных запросов – пользователь должен иметь возможность объединять данные из любых баз, даже размещенных в разных системах;

поддержка распределенных изменений – пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права;

поддержка распределенных транзакций – СУБД должна выполнять транзакции,

выходящие за рамки одной вычислительной системы, и поддерживать целостность БД при

возникновении отказов как в системах, так и в сети;

безопасность – СУБД должна обеспечивать защиту всей распределенной БД от несанкционированного доступа;

универсальность доступа – СУБД должна обеспечивать единую методику доступа ко всем данным.

Ни одна из существующих СУБД не достигает этого идеала поскольку:

низкая и несбалансированная производительность сетей снижает общую производительность обработки в распределенных транзакциях;

обеспечение целостности данных в распределенных транзакциях базируется на принципе «все или ничего» и требует специального протокола, что приводит к длительной блокировке изменяемых данных;

необходимо обеспечить совместимость данных, для хранения которых в разных системах используются разные форматы и кодировки;

если каталог хранится в одной системе, то удаленный доступ будет замедлен; если будет размножен – изменения придется синхронизировать;

необходимо обеспечить совместимость СУБД разных типов и поставщиков;

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

Эти причины определили поэтапность введения в СУБД возможностей распределенной обработки. В простейшем случае пользователь может обращаться по сети

75

к записям в БД на других компьютерах. В других случаях СУБД сама проводит аутентификацию удаленного клиента и устанавливает сетевое соединение.

Изучая тенденции развития технологий обработки данных, можно выделить два класса систем:

системы распределенной обработки данных;

системы распределенных баз данных.

Системы распределенной обработки данных базировались на многопользовательских операционных системах с БД на центральном компьютере. Клиентские места реализовались в виде терминалов, не имеющих собственных ресурсов. Развитие сетевых технологий, распространение персональных ЭВМ и стандартов открытых систем привело к появлению систем распределенных БД, размещенных в сети разнотипных компьютеров.

Система состоит из узлов, каждый из которых является СУБД. БД любого узла доступна пользователю.

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

презентационная логика (PL – Presentation Logic): ввод и отображение данных – внешний (пользовательский) уровень реализации функциональной обработки и представления;

бизнес-логика (BL – Business Logic): функциональная обработка, реализующая алгоритм решения задач пользователя;

манипулирование данными БД в рамках приложения, которое обычно реализуется средствами SQL (DL – Database Logic);

управление данными и другими ресурсами БД, реализуемое внутренними средствами конкретной СУБД обычно в рамках файловой системы ОС;

управление процессами обработки: связывание и синхронизация процессов обработки данных разного уровня.

9.1. Базовые архитектуры распределенной обработки

По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:

Взаимодействие пользователя с БД строится на основе модели «клиент – сервер».

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

76

функционируют на отдельных компьютерах, т. е. к серверу БД с помощью сети подключены компьютеры клиентов.

Разделение процесса на клиентскую и серверную компоненты позволяет:

одновременно использовать БД различным прикладным программам;

централизовать функции управления, такие как защита информации, обеспечение целостности данных, управление совместным использованием ресурсов;

обеспечивать параллельную обработку запроса в распределенных БД;

высвобождать ресурсы рабочих станций и сети;

повышать эффективность управления данными за счет использования специальных серверов баз данных.

Вархитектуре «файл-сервер» (рис. 38) средства организации и управления БД (в том числе СУБД) располагаются на машине клиента, а БД, представляющая собой набор специализированных файлов, – на машине-сервере.

Файл - сервер

- хранение

- обработка

Передача данных БД для обработки

Рабочие станции Рисунок 37. Схема обработки информации в БД по принципу файл-сервер

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

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

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

•Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно.

Недостатки архитектуры:

77

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

•низкий уровень защиты данных, так как доступ к файлам БД управляется общими средствами ОС сервера;

•бизнес-правила функциональной обработки, сосредоточенные в клиентской части,

могут быть противоречивыми.

Для схемы характерно наибольшее суммарное время обработки информации.

В архитектуре «выделенный сервер базы данных» (рис. 39) средства управления базой данных и база данных размещены на машине-сервере (DB-сервер).

	Сервер	- хранение данных
	БД
		- основная обработка
	Транспортировка извлеченных данных	- частичная обработка
		данных

Рабочие станции Рисунок 38 . Схема обработки информации в БД по принципу клиент-сервер

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

•Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере.

•Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту.

•Спецификой архитектуры клиент-сервер является использование языка запросов SQL.

Достоинства архитектуры:

•снижение нагрузки на машины сервера и клиентов;

•снижение сетевого трафика и повышение эффективности обработки за счет оптимизации и буферизации ввода-вывода;

•защита данных средствами СУБД, позволяющая блокировать не разрешенные пользователю действия;

78

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

Недостатки архитектуры:

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

•бизнес-правила функциональной обработки, сосредоточенные на клиентской части,

могут быть противоречивыми.

В архитектуре «активный сервер баз данных» (рис. 40) непротиворечивость бизнес-

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

Клиент		Сервер
			Управление данными
Представление
данных			Функциональная
			обработка
			(триггеры, хранимые	БД
Функциональная			процедуры)
обработка
			СУБД

Рисунок 39. Архитектура «активный сервер баз данных» Хранимые процедуры и триггеры могут быть использованы любыми клиентскими

приложениями, работающими с БД. Это снижает дублирование программных кодов и исключает необходимость компиляции каждого запроса. Недостатком архитектуры становится возрастающая загрузка сервера.

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

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

79

Клиент		Сервер		Сервер БД
		приложений
Представление		Управление
данных		данными

СУБД

БД

Функциональная Бизнес-логика обработка

Рисунок 40. Трехзвенная архитектура сервера приложений Связь клиентских рабочих станций с прикладными программами на сервере

приложений устанавливается через интерфейс API (Application Programming Interface).

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

Кдостоинствам трехзвенной архитектуры относятся:

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

•централизованное ведение бизнес-логики (при внесении изменений их не нужно тиражировать в клиентских приложениях);

•на клиентских машинах не следует устанавливать компоненту программного обеспечения управления доступом к данным;

•оптимизация доступа к БД (диспетчеризация запросов выполняется сервером приложений);

•возможность отложенного обновления БД при изменении данных в автономном режиме (данные будут обновлены в БД при следующем соединении);

•повышение скорости и надежности за счет дублирования ПО на нескольких серверах приложений, которые могут заменять друг друга;

•перенос проверки полномочий пользователей с сервера БД на сервер приложений.

•уменьшение мощности сервера приложений за счет параллельной работы сервера приложений и сервера БД.

Тема 10. Транзакции

Транзакция – это законченная совокупность действий над БД, которая переводит ее из одного целостного состояния в другое. Если операторы транзакции выполняются,

происходит ее нормальное завершение и БД переходит в обновленное (целостное)

состояние (ситуация COMMIT на рис. 42). При сбое происходит откат к исходному состоянию БД (ситуация ROLLBACK на рис. 42).

80

Рисунок 41. Выполнение и откат транзакции

К транзакциям предъявляется набор требований, известный под названием ACID

(Atomicity, Consistency, Isolation, Durability).

Атомарность (atomicity). Транзакция представляет собой набор законченных действий. Система обеспечивает их выполнение по принципу «все или ничего» – либо выполняются все действия, тогда транзакция фиксируется, либо (при сбое) транзакция откатывается назад, а БД остается в исходном состоянии.

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

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

либо начнут выполняться после ее завершения.

Долговечность (durability). Если транзакция зафиксирована, то ее результаты должны быть долговечными. Новые состояния всех объектов сохранятся даже в случае аппаратных или системных сбоев.

Рассмотрим две модели транзакций, используемые в большинстве коммерческих СУБД: модель автоматического выполнения транзакций и модель управляемого выполнения транзакций, основанные на инструкциях языка SQL – COMMIT и

ROLLBACK.

Автоматическое выполнение транзакций. Модель создана на основе схемы, принятой в СУБД DB2. Транзакция автоматически начинается с выполнения пользователем или программой первой инструкции. Далее происходит последовательное выполнение инструкций, пока транзакция не завершится (рис. 43).

Транзакция заканчивается одним из двух способов:

81

•инструкцией COMMIT, которая выполняет завершение транзакции (внесенные в БД изменения становятся постоянными, а новая транзакция начинается сразу после инструкции COMMIT);

•инструкцией ROLLBACK, которая отменяет выполнение текущей транзакции (БД возвращается к состоянию начала транзакции, новая транзакция начинается сразу после инструкции ROLLBACK).

	Непротиворечивая БД
INSERT	INSERT
COMMIT	COMMIT
	Непротиворечивая БД
UPDATA	UPDATA
COMMIT	ROLLBACK
	Непротиворечивая БД

Рисунок 42. Модель автоматического выполнения транзакций

Управляемое выполнение транзакций. Модель используется в СУБД Sybase, где применяется диалект Transact-SQL, в котором для обработки транзакций служат четыре инструкции (рис. 44):

•инструкция BEGIN TRANSACTION сообщает о начале транзакции (начало транзакции задается явно);

•инструкция COMMIT TRANSACTION сообщает об успешном выполнении транзакции

(при этом новая транзакция автоматически не начинается);

•инструкция SAVE TRANSACTION позволяет создать внутри транзакции точку сохранения и присвоить сохраненному состоянию имя точки сохранения, указанное в инструкции;

•инструкция ROLLBACK отменяет выполнение текущей транзакции и возвращает БД к состоянию, где была выполнена инструкция SAVE TRANSACTION (если в инструкции указана точка сохранения – ROLLBACK TO имя_точки_сохранения) или к состоянию начала транзакции.

82

Тема 11. Проблема сжатия больших информационных массивов.

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

Применение в СУБД экономного кодирования без потерь информации приводит к ряду положительных результатов. Наиболее очевидным эффектом является уменьшение физического размера базы данных, журнальных и архивных файлов. Но также часто достигается увеличение скорости выполнения запросов и снижение требований к объему оперативной памяти. Эффективная реализация поддержки сжатия данных существенно улучшает качество СУБД.

Интерес к задаче сжатия данных в СУБД изначально был обусловлен стремлением уменьшить физический объем баз данных. Цена подсистемы ввода-вывода составляла основную часть стоимости аппаратуры. Поэтому при надлежащем интегрировании в СУБД методов безущербного сжатия данных достигалась значительная экономия.

Небольшое увеличение числа используемых тактов процессора для кодирования-

декодирования более чем компенсировалось снижением затрат на подсистему ввода-

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

Использование сжатия данных в СУБД связано с решением множества задач.

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

Проблема реализации сжатия в СУБД имеет также такие аспекты, как оптимизация выполнения запросов к сжатым данным, эффективное сжатие результатов выполнения запросов, экономное кодирование метаданных, оценка целесообразности сжатия отдельных элементов, выбор алгоритма сжатия и его параметров с учетом типовых запросов и характера данных.

83

Основные методы сжатия без потерь.

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

соответствии с теоремой Шеннона о кодировании источника информации, такое событие выгоднее всего кодировать словом длиною –log2p битов. Методы сжатия данных явно или неявно опираются на этот факт.

В результате процесса экономного кодирования единице исходных данных

(символу, слову, строке, числу и т. п.) ставится в соответствие так называемое кодовое слово. Кодовое слово состоит из последовательности цифр, обычно двоичных.

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

является безущербным, без потерь.

Эффективность сжатия как характеристика сокращения размера представления информации относительно исходного будет в данном обзоре определяться степенью сжатия. Степень сжатия принимается равной отношению объема исходных данных к объему соответствующих им сжатых данных и измеряется в разах.

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

Статистическое кодирование.

Методы статистического кодирования опираются на теорему Шеннона. Такие методы включают в себя два этапа: оценка вероятности кодируемых элементов

(моделирование) и собственно кодирование. На этапе кодирования выполняется замещение элемента Si с оценкой вероятности появления cc кодовым словом длиной – log2p q(Si) битов. Этот этап иногда называется энтропийным кодированием. Оценки q(Si)

могут быть получены из безусловных частот встречаемости элементов, условных частот,

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

84