Internal level (внутренний уровень)

Данный уровень обеспечивает - physical storage structure (размещение данных на физических носителях). Он включает четыре элемента:

• 1) Physical implementation (описание физических устройств)

• 2) How the data are stored (как хранятся данные)

  • Allocation of space for data (распределение пространства)

  • Record description and placement (структура записей)

• 3) Interface with the Operating System - data structure, file organization. (программные интерфейсы с операционной системой).

• 4) Compression and encryption of data (сжатие и шифрация данных)

4.2. Состав комплекса бд. Функции субд

Ранние БД:

А) База данных содержит помимо собственно данных (data), также метаданные (Metadata), представляющие описание структуры хранимых данных. Эти метаданные называют - “Data dictionary” or system catalog. (Словарь данных или системный каталог). Это описание обеспечивает две цели:

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

• Примеры: описание полей таблиц и индексы

Б) Язык описания структуры БД и манипулирования данными.

В) Библиотека типовых процедур (пример, Clipper 5.0)

Современные БД:

А+

Б) Специальное программное обеспечение (система управления базами данных - СУБД), обеспечивающее

• Управление данными во внешней памяти. Data Manager.

• Управление данными в оперативной памяти. Buffers Manager.

• Механизм управления транзакциями. Transaction Manager.

  • Поддержание логически согласованного набора файлов;

  • Реально параллельная работа нескольких пользователей.

• Восстановление информации после разного рода сбоев. Journal Manager

• Поддержку универсального языка (SQL) работы с базой данных.

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

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

СУБД — это набор программ, применяемых для (1) управления большим набором структуриро­ванной информации, а также для (2) выполнения операций над этими данными по запросам пользователей

Управление данными во внешней памяти (Data Manager)

Эта функция включает (Internal Level– внутренний уровень):

• Безопасность и надежность хранения всех данных, входящих в БД:

  • собственная система именования объектов БД.

  • с точки зрения файловой системы: вся БД - это один файл.

• Убыстрение доступа к данным.

Почему недостаточно функций файловых систем? Скорость, безопасность.

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

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

Управление буферами оперативной памяти (Buffers Manager)

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

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

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

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

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

  • Система прогнозирования (аналог кэш процессоров).

  • Иллюстрация – скорость работы = скорости чтения из RAM и дисков

Существует отдельное направление развития СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД.

Управление транзакциями (Transaction Manager)

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

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

• Средства для обработки транзак­ций были включены в язык SQL и существенно повысили надеж­ность приложений БД.

Ключевой элемент любой современной системы управления базой данных.

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

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

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

Пример ограничений целостности БД:

• Возраст сотрудника не может быть меньше 18 и больше 65 лет.

• Каждый сотрудник имеет уникальный табельный номер.

• Сотрудник обязан числиться в одном отделе.

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

Таблицы СОТРУДНИКИ и ОТДЕЛЫ - единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию.

Пример реализации – ОПЕРАЦИИ ПОКУПКИ:

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

Три цели введения понятия транзакции:

(1) В однопользовательских системах транзакции - это логические единицы работы, после выполнения, которых база данных остается в целостном состоянии.

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

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

Транзакция обладает четырьмя важными свойствами (свойства АСИД):

• (А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.

• (С) Согласованность. Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность (например, по ссылкам!) БД может нарушаться.

• (И) Изоляция. Во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии.

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

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

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

Контроль ограничения целостности:

По способу реализации	На уровне языка описания базы данных SQL. Декларативная поддержка ограничений целостности. Домены и типы данных. На уровне операций работы с БД. Процедурная поддержка ограничений целостности
По времени проверки	Немедленно проверяемые ограничения. Уникальность ключа Ограничения с отложенной проверкой. В момент фиксации ТЗ в памяти
По области действия	Ограничения домена. Группа значений (имена, зарплата) Ограничения атрибута. Конкретное поле таблицы. Возраст сотрудника (18…65) Ограничения кортежа. На уровне записи. Сотрудник специального подразделения (25…40). Должность и зарплата. Ограничения отношения. На уровне таблиц. Не менее двух сотрудников в отделе. Ограничения базы данных. На уровне всей БД.

Транзакции и многопользовательские СУБД.

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

(А) ПРОСТЕЙШИЙ И ОЧЕВИДНЫЙ СПОСОБ - все поступающие транзакции выстраивать в единую очередь и выполнять строго по очереди. Очевидный недостаток - теряется преимущество параллельной работы.

(Б) ТРАНЗАКЦИИ НЕОБХОДИМО ВЫПОЛНЯТЬ ОДНОВРЕМЕННО, но так, чтобы результат был бы такой же, как если бы транзакции выполнялись по очереди.

Параллельно – а не последовательно!

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

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

Сериальный план – это план-график выполнения элементарных операций заданного набора транзакций.

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

Журнализация (менеджер журнала – Journal Manager)

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

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

• 1) Самый простой способ - это во время каждой операции сразу записывать все изменения на дисковые носители.

  • Способ не является удовлетворительным, т.к. имеется существенное различие в скорости работы с оперативной и с внешней памятью.

• 2) Единственный способ достичь приемлемой скорости работы состоит в буферизации страниц базы данных в оперативной памяти. Это означает, что данные попадают во внешнюю память не сразу после внесения изменений, а через некоторое (достаточно большое) время.

  • Тем не менее, что-что во внешней памяти должно оставаться, т.к. иначе неоткуда получить информацию для восстановления.

Три возможных вида сбоев:

1) Индивидуальный отказ транзакции.

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

2) Мягкий сбой системы (аварийный отказ программного обеспечения). Мягкий сбой характеризуется утратой оперативной памяти системы.

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

• Мягкий сбой может произойти, например, в результате аварийного отключения электрического питания или в результате неустранимого сбоя процессора.

3) Жесткий сбой системы (аварийный отказ аппаратуры). Жесткий сбой характеризуется повреждением внешних носителей памяти.

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

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

Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.

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

Стратегия ведения ЖУРНАЛА

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

• Система постоянно поддерживает список "грязных" страниц - dirty-список.

• Запись "грязных" страниц из буфера на диск называется выталкиванием страниц во внешнюю память.

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

• 1) Максимальную скорость выполнения транзакций.

  • Для этого необходимо выталкивать страницы как можно реже.

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

  • Для этого что-то выталкивать на диск все-таки необходимо, даже если мы обладали бы бесконечной оперативной памятью.

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

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

• Запись об изменении объекта БД должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти БД.

• Протокол журнализации называется Write Ahead Log (WAL) - "пиши сначала в журнал", и состоит в том, что если требуется вытолкнуть во внешнюю память измененный объект базы данных, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи о его изменении.

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

  • 2) Обратное неверно - если во внешней памяти журнала содержится запись о некотором изменении объекта, то во внешней памяти базы данных может и не быть самого измененного объекта.

Процедуры восстановления

1) Индивидуальный откат транзакции.Самая простая ситуация.

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

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