Восстановление после жесткого сбоя

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

При восстановлении после жёсткого сбоя восстанавливается состояние ФБД на момент последнего копирования, а затем по текущему журналу регистрации повторно исполняются все транзакции, успешно завершившиеся до момента сбоя.

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

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

ЯЗЫК ДАННЫХ SQL

Обзор основных понятий SQL

Назначение и этапы развития

Язык РБД SQL (Structured Query Language) предназначен для определения ресурсов данных, манипулирования данными и управления доступом к данным на концептуальном уровне. SQL не является языком программирования и не содержит никаких процедурных средств. Строго говоря, это подъязык данных.

Первая версия SQL была разработана фирмой IBM в начале 70-х годов[5] и использовалась в качестве входного языка экспериментальной СУБД System-R. Описание языка было впервые опубликовано в 1974 году. К середине 80-х годов многие производители коммерческих СУБД создали свои реализации SQL. Во избежание «вавилонского смешения языков» в мире реляционных СУБД Международная Организация Стандартизации и Американский Национальный Институт Стандартов (ISO/ANSI) приняли в 1986 году первый стандарт SQL1. В 1989 году этот стандарт был пересмотрен. Сейчас на него ссылаются как на SQL1 или SQL-89. В 1992 году принят новый стандарт, известный ныне под названиями SQL2, SQL-92, SQL/92. Распространенные в настоящее время коммерческие СУБД, за исключением наиболее «продвинутых», ориентированы на стандарт SQL1. Мы при изложении возможностей языка будем в основном придерживаться требований SQL2, т.к. этот стандарт практически полностью включает SQL1 и является основой для перспективных разработок.

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

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

Реализации

Стандарт предусматривает использование языка в виде трех прикладных реализаций – интерактивной, статической и динамической (рис 6.1).

Интерактивный SQL дает возможность пользователю работать с базой данных в интерактивном режиме. Вводимые пользователем команды SQL немедленно исполняются.

Статический SQL – записанный заранее код SQL, используемый в прикладных программах. Предусмотрены две версии статического SQL.

Рис. 6.1 Варианты прикладных реализаций SQL

· Встроенный SQL – код SQL, включённый в код исходного текста прикладной программы на одном из ЯВУ. Эта версия является расширением базового ЯВУ за счет операторов SQL.

· Модульный SQL не предполагает включения операторов SQL в базовый язык. Приложение состоит из отдельных модулей SQL-операторов, скомпонованных с модулями других языков.

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

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

Категории операторов

Операторы языка группируются в три основных категории:

· язык определения данных (DDL – Data Definition Language) включает все операторы, используемые для определения схемы БД и объектов схемы;

· язык манипулирования данными (DML – Data Manipulation Language) содержит операторы, используемые для выборки и обновления данных;

· операторы управления данными (DCS – Data Control Statements) используются для определения привилегий пользователей.

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

Объект

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

Объект создается пользователем, имеющим соответствующую привилегию CREATE. Этот пользователь является владельцем объекта и может распоряжаться им по своему усмотрению. В частности, он может передавать привилегии другим пользователям. Объект может быть уничтожен только его владельцем. Исполняя оператор уничтожения объекта, система удалит из своего каталога его имя и определение.

В таблице 6.1 перечислены типы объектов, определенные стандартом SQL-92. Все коммерческие SQL-системы поддерживают объекты TABLEи VIEW. Остальные объекты могут не поддерживаться конкретными реализациями.

Таблица 6.1 – Типы объектов SQL

Стандартное имя	Русское название	Подробности
ASSERTION	Утверждение	6.1.11, 6.3.9
CHARACTER SET	Набор символов	6.1.12
COLLATION	Сравнение	6.1.12
DOMAIN	Домен	6.1.8, 6.3.2 – 6.3.4
SCHEMA	Схема	6.1.14, 6.3.10
TABLE	Таблица	6.1.9, 6.3.5 – 0
TRANSLATION	Трансляция	6.1.12
VIEW	Представление	6.1.10, 6.3.8, 6.4

Идентификатор авторизации

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

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

Идентификатор авторизации (ID) – идентификатор источника операторов SQL и одновременно объект, с которым связаны привилегии. Может быть пользователем или модулем, владельцем схемы SQL и ее содержимого.

Сеанс

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

Сеанс – набор SQL-операторов, исполняемых от имени определенного ID с момента его подключения к системе до момента отключения.

SQL-агенту разрешено выполнять несколько подключений. Поэтому одновременно могут существовать несколько сеансов одного и того же ID. В каждом из них могут использоваться различные источники данных. Активным в любой момент времени является только один сеанс – текущий. Пользователь может изменять текущий сеанс.

Тип данных

Все значения любого столбца в любой SQL-таблице должны принадлежать одному и тому же типу данных. Тип данных должен быть частью определения самого столбца или частью определения домена, из которого выбираются значения столбца. Стандарт определяет шесть категорий типов данных (см. таблицу 6.2). Каждый тип имеет собственное имя и может быть только простым. Допускаются синонимы имен, например, CHARACTER эквивалентно CHAR. Имена типов или их синонимы используются в определениях столбцов и доменов.

Таблица 6.2 – Категории типов данных SQL

Категория	Описание
CHARACTER STRING	Символьные строки.
BIT STRING	Строки битов.
EXACT NUMERIC	Числа, точно соответствующие цифровой записи.
APPROXIMATE NUMERIC	Числа, выраженные в форме «мантисса плюс порядок» и имеющие приближенное значение.
DATETIME	Дата, время и комбинация их значений.
INTERVAL	Период времени между двумя временными отсчетами, выраженными в форме даты и времени.

Многие производители СУБД не следуют стандарту в части типов данных. По этой причине мы не приводим стандартных определений в настоящем пособии. В примерах используются (как правило, без особых пояснений) такие определенные стандартом типы данных, как CHARACTER, NUMERIC, DATE, TIME.

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

Домен

Понятие домена в SQL отличается от аналогичного понятия в РМД. Стандарт не определяет домен как логическую категорию значений, которые можно сравнивать. Согласно стандарту, домен есть просто именованная совокупность значений данных. Имя и определение домена (см. п. 6.3.2) сохраняются в специальной таблице системного каталога. На имя домена можно ссылаться внутри определения таблицы как на тип данных.

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

Таблица

Таблица в SQL является аналогом отношения РМД. Однако в отличие от отношения, схема таблицы может не содержать уникального подмножества атрибутов (столбцов). Стандарт не требует обязательного указания первичного и альтернативных ключей при определении таблицы. С точки зрения SQL-системы в этом нет необходимости. Она автоматически присваивает каждой строке уникальный внутренний номер – суррогатный ключ. Однако этот ключ пользователю не виден и вне системы смысла не имеет. Это приводит к тому, что в таблицах SQL могут (с точки зрения пользователя) содержаться дубликаты строк и совершенно непонятно, как их следует интерпретировать.

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

Можно выделить две категории таблиц – именованные и неименованные (рис. 6.2).

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

Именованные таблицы являются объектами в смысле п. 6.1.4. Их заголовки явно определяются операторами DDL. Имена и определения сохраняются в системном каталоге.

Именованные таблицы могут быть базовыми или представлениями.

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

Рис. 6.2 Иерархия таблиц SQL2

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

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

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

Объявленная временная таблица создаётся как объект схемы прикладной программой. Для этого используется специальный оператор DDL DECLARE LOCAL TEMPORARY TABLE. Это определение действительно только внутри создавшей его ПП. При завершении ПП оно автоматически уничтожается. Таким образом, объявленная временная таблица, в отличие от других видов именованных таблиц, не является постоянной частью схемы.

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

Представление

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

Представление имеет собственное имя, зарегистрированное в системном каталоге. На него можно ссылаться как на имя таблицы в операторах манипулирования данными. Заголовок представления, в отличие от заголовка таблицы, не определяется явно путём специфицирования столбцов. Определение представления содержит запрос к другим таблицам, который связывается с именем представления и сохраняется в системном каталоге. Запрос исполняется при обработке оператора манипулирования данными, в котором встретилась ссылка на представление. Результат запроса и является содержимым представления. Таким образом, представление, в отличие от временной таблицы, всегда отражает текущее состояние базовых таблиц, существующее в момент исполнения запроса.

Представление (VIEW) есть объект, содержащий именованный запрос, на который можно ссылаться в операторах манипулирования данными.

Механизм представлений обеспечивает возможность предъявления хранимых данных в удобной и привычной для конечного пользователя форме. Кроме того, он является средством ограничения доступа к данным.

Утверждение

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

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

Утверждение (ASSERTION) есть объект, содержащий проверку ограничения, записанного в виде предиката, ссылающегося на столбцы таблиц.

Другие типы объектов

Объекты типов CHARACTER SET, COLLATION и TRANSLATION определяют соответственно набор символов, порядок сортировки символьных строк и преобразование строки одного набора символов в строку другого набора.

В каждом SQL-приложении по умолчанию определены один или более стандартных наборов символов, которые обычно соответствуют национальному алфавиту. Пользователь может создать с помощью оператора CREATE CHARACTER SET для своего приложения новый набор символов путем изменения существующих определений.

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

В каждой SQL-системе реализованы некоторые правила преобразования строк одного набора символов в строки другого – правила трансляции. Оператор CREATE TRANSLATION предоставляет пользователю возможность определения собственных правил трансляции на базе встроенных.