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

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

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

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

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

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

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

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

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

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

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

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

Сериальный план выполненных транзакций- это такой план, который приводит к сериализации транзакций.

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

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

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

Журнализация

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

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

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

При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.

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

Поддержка языков БД

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

Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL.

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

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

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

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