Функции субд. Типовая организация субд

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

1) Непосредственное управление данными во внешней памяти.

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

2) Управление буферами, оперативной памяти.

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

3) Управление транзакциями.

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

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

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

4) Журнализация.

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

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

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

5) Поддержка языков баз данных.

Для работы с базами данных используются специальные языки, имеющие общее название – языки баз данных. В ранних СУБД поддерживались несколько специализированных по своим функциям языков. Чаще всего выделялось два языка: язык определения схемы, язык манипулирования данными. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД. Стандартным языком наиболее распространенных СУБД является SQL.

Типовая организация СУБД

В современных СУБД логически можно выделить следующие основные компоненты:

─ ядро СУБД;

─ компилятор языка БД;

─ подсистема поддержки времени выполнения;

─ набор утилит.

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

Функции всех компонентов ядра взаимосвязаны и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, недоступным пользователям напрямую и используемым в программах, созданных средствами SQL, а также в утилитах БД. При использовании архитектуры клиент-сервер ядро является основным составляющим серверной части системы. Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую управляемую программу. Основной проблемой реляционной СУБД является то, что языки этих систем являются непроцедурными, поэтому компилятор должен решить, каким образом выполнить оператор языка, прежде чем воспроизвести программу. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинонезависимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, которая представляет собой интерпретатор внутреннего языка СУБД. В отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка баз данных. Например, загрузка и выгрузка баз данных, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а в некоторых случаях с проникновением внутрь ядра.