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

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

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

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

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

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

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

Языки: DDL – Data Definition Language, DML - Data Manipulation Language, DCL - Data Control Language.

Организация современной субд

Можно выделить следующие основные функции СУБД:

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

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

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

4. Журнализация и восстановление

5. Поддержка языков БЖ

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

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

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

Ранние подходы (дореляционные) к организации бд

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

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

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

Иерархическая модель данных (пример). IMS, IBM.

Структуры данных

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

1. Атрибут – наименьшая структура единица структуры данных, имеющее имя (еще называют поле).

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

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

Пример:

Отдел 1

Заказчик 1

Контракт 1

Сотруд 2

Исполнитель 1

Сотруд 1

Контракт 2

Контракт 1

Контракт 2

Исполнитель 1

Исполнитель 2

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

В обобщенной структуре дерева типы записей обычно упорядочены внутри структуры.

B

S

P

B3

C

SG5

SG14

SG23

SG37

PG4

PG16

PG21

PG36

CR76

CR36

CR56

При работе с обобщенной структурой используются два метода доступа ко всем узлам внутри дерева: прямой порядок обхода начинается с доступа к корню с последующей обработкой всего дерева, с доступом к поддеревьям в порядке слева направо. Пример прямого доступа: B3->SG5->SG14->SG23->SG37->PG4->CR76->CR36->PG16->PG21->PG36->CR56.

Обратный порядок обхода: начинается с доступа к самым нижним узлам постепенным восходящим переходом от одного поддерева к другому слева направо с завершением обработки в корне. Пример: SG5->SG14->SG23->SG37->CR76->CR36->PG4->PG16->PG21->CR56->PG36->B3.

Операции над данными в иерархической модели

1. Добавить в базу новую запись. Для корневой записи обязательно формировать значение ключа.

2. Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

3. Удалить некоторую запись и все подчиненные ей записи.

4. Извлечь: 1) корневую запись по ключевому значению. Допускается также последовательный просмотр корневых записей. 2) извлечь следующую запись в порядке левостороннего обхода дерева. Команды типа: Get Next. Допускается задание условий выборки.

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

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