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

управление буферами оперативной памяти; СУБД обычно работают с БД значительного размера. Если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. В развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.Существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Например, подход Data in Memory в версиях СУБД IBM DB2 для IBM eServer zSeries.

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

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

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

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

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

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

Процедуры, выполняемые на этапах жизненного цикла БД:

1)                     Проектирование(Анализ предметной области и запросов к БД; Интеграция пользовательских представлений; Выбор средств реализации; Логическое проектирование данных; Физическое проектирование)

2)                     Создание (Генерация схемы БД; Подготовка среды хранения; Первичный ввод и контроль данных; Загрузка и корректировка БД)

3)                     Эксплуатация(-Организация доступа к данным (Поиск и обновление; Разграничение доступа; Инициирование и завершение работы с СУБД); - Контроль состояния БД (Сбор и анализ статистики использования; Контроль целостности БД;

2)Метки доступа. Способ организации меток доступа для СУБД, не поддерживающих этот механизм.

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

Специальная привилегия, DOWNGRADE, позволяет изменять метки безопасности, ассоциированные с данными. Подобная возможность необходима, например, для коррекции меток, по тем или иным причинам оказавшихся неправильными.

3)Проблема «утраченного обновления». Способы разрешения.

Если имеет место изменение незафиксированных данных транзакции. Незафиксированные данные транзакции еще называют «грязными» (dirty data). Следует также отметить, что феномен потерянного обновления будет наблюдаться при следующих последовательностях завершения транзакций ((T1, commit) или (T1, rollback)) и ((T2, commit) или (T2, rollback)) в любом порядке. Таким образом, полное описание данного феномена будет включать все четыре варианта завершения транзакций T1 и T2.

Как возникает такая зависимость транзакций? Предположим, что система содержит информацию о положении точки на плоскости. Точка определяется двумя координатами (x,y). Пусть работают две транзакции, каждая их которых заносит информацию о точке, удовлетворяющей уравнению x = y. Выполняются операции модификации координаты x и модификации координаты y. Пусть T1 меняет значение v = (0,0) на v1 = (1,1), а T2 — на v2 = (2.2). Очевидно, что при выполнении операций в указанной ниже последовательности будет возникать рассогласование данных:<0,1> (->) (T1,W(y)) <0,1> (->) (T2,W(y)) <0,2> (->) (T2,W(x)) <1,2> (->) (T1,commit)(!!!) <1,2> (->) (!!!)(T2,W(x)) <2,2> (->) (T2,commit)(!!!) <2,2> (->)

Произошли два вида нарушений. Во-первых, изменения транзакции T1 оказались затерты по завершении транзакции T2. Во-вторых, в момент времени, помеченный (!!!), наблюдается рассогласование данных, а именно нарушение закона x = y. Эти данные оказались зафиксированными транзакцией T1 (она «ничего не знает» о параллельно работающей с ней T2). Это означает, что любая другая транзакция могла считать эти некорректные данные в момент времени (!!!); последствия рассогласования перестают быть контролируемыми. Кроме того, если потребуется откат данных, то система не сможет откатить изменения, просто восстановив старые значения. Рассмотрим историю <0,0> (->) (T1,W(y)) <0,1> (->) (T2,W(y)) <0,2> (->) (T2,rollback) Аннулирование (T1,W(y)) и восстановление предыдущего значения y не удовлетворяет правилам согласованности, потому что в результате такого восстановления уничтожится и модификация y, сделанная второй транзакцией (T2,W(y)). Если же не восстанавливать предыдущие значения y, и вторая транзакция тоже выполняет откат, то также невозможно аннулировать (T2,W(y)), просто восстановив значение y, которое было до выполнения этой операции записи.

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

 

Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 25 - Хранимые процедуры. Языки для написания хранимых процедур.
Часть 26 - Моделирование сетевых структур с использованием вспомогательной таблицы.
Часть 27 - Основные функции СУБД. Типовая организация СУБД. Жизненный цикл базы данных.
Часть 28 - Кластерные и распределенные СУБД. Пример: IBM DB2 Parallel Edition, MS SQL Server и Oracle. Применение триггеров
Часть 29 - Иерархическая СУБД IBM IMS и язык DL1. Особенности реализации для работы на кластере (Sysplex).
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и