Файл: Базы данных - уч. пособие.pdf

16

Глава 1. Обоснование концепции баз данных

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Основная особенность СУБД — это наличие процедур для ввода и хранения не

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

Приведенное выше определение отражает естественное развитие подхода к об-

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

Вторым по важности был неявно обозначенный выше принцип информацион-

ного моделирования некоторой предметной области в виде БД.

На более поздних этапах развития процессов обработки данных на ЭВМ, в свя-

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

Таким образом, необходимость применения концепции баз данных обусловле-

на следующими причинами [2]:

1) развитием подхода к обработке данных — от вычислительных задач к ин-

формационным;

2) объединением последних в комплексы (подсистемы) с постоянным их со-

вершенствованием, включающим расширение состава задач и ориентиро-
вание на широкий круг конечных пользователей;

3) противоречием между позадачным подходом в использовании исходных

данных и требованием их эффективной актуализации;

4) стремлением отобразить в системе хранимых данных информационную

модель определенной предметной области.

1.4 Функции СУБД

17

1.4 Функции СУБД

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

и перечень основных функций, поддержка которых в системе необходима для их
решения. В каждой конкретной СУБД имеется определенный набор функций, ко-
торый варьируется в зависимости от сложности системы. Однако для большин-
ства современных СУБД, относящихся к классу коммерческих систем, очевидна
поддержка нескольких базовых функций [1]:

1) управления данными во внешней и оперативной памяти компьютера;

2) управления транзакциями;

3) журнализации изменений БД;

4) поддержки языков доступа к данным;

5) обеспечения безопасности базы данных.

Управление данными во внешней (на жестком диске) и оперативной па-

мяти компьютера

Данная функция включает не только обеспечение необходимых структур внеш-

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

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

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

СУБД при работе с БД значительного размера должна обеспечивать обмен дан-

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

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Транзакция — это последовательность операций над БД, рас-
сматриваемых СУБД как единое целое.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Если вспомнить наш пример информационной системы с файлами СТУДЕНТЫ
и ГРУППЫ (см. подраздел 1.3), то единственным способом не нарушить целост-
ность БД при выполнении операции изменения номера группы является объедине-
ние элементарных операций над файлами СТУДЕНТЫ и ГРУППЫ в одну транзак-
цию. Таким образом, поддержание механизма транзакций является обязательным
условием даже для однопользовательских СУБД, но особенно важным и необхо-
димым — в многопользовательских СУБД [1].

В области обработки транзакций существует следующая классификация [4]:

18

Глава 1. Обоснование концепции баз данных

• первое поколение — единые монолитные системы, основанные на прими-

тивных моделях терминалов для взаимодействия с пользователем;

• второе поколение — поддержка продуктов многих поставщиков, интеллек-

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

• третье поколение — поколение новых систем, более тесно связанное с по-

требностями моделирования бизнес-процессов.

Любая транзакция основана на некотором наборе принципов, называемых ACID

(Atomicity, Consistency, Isolation, Durability) [5].

Атомарность (Atomicity). Как было указано выше, транзакция представляет

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

Целостность (Consistency). Каждая транзакция начинается при целостном со-

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

Изолированность (Isolation). Поскольку транзакция обновляет совместно ис-

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

Здесь следует отметить, что при соответствующем управлении параллельно

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Понятно, что если удается добиться действительно сериального выполнения

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

1.4 Функции СУБД

19

В современных СУБД наиболее распространены алгоритмы сериализации тран-

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

Долговременное хранение (Durability). Если транзакция зафиксирована, то ее

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

Существуют многочисленные модели транзакций, поддерживающие эти прин-

ципы, — от простейших, например плоских транзакций, до более сложных, таких
как вложенные и многозвенные транзакции. Подробная информация о моделях
транзакций и системах управления транзакциями изложена в [6].

Журнализация изменений БД

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Главным критерием при выборе СУБД является надежность хра-
нения информации.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Здесь под этим термином будем понимать возможность СУБД восстановить

последнее согласованное состояние БД после возникновения сбоя.

Различают два вида сбоев: программный и аппаратный. Эти сбои, в свою оче-

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

В некоторых СУБД журнал недоступен пользователям СУБД и может хранить-

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

20

Глава 1. Обоснование концепции баз данных

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

При мягком сбое в БД могут находиться данные, модифицированные транзак-

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

Процесс восстановления производится путем отката незавершенных транзак-

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

1. Архивная копия БД должна храниться на другом физическом носителе.

2. Архивная копия БД должна создаваться регламентно — по итогам опреде-

ленного периода наполнения БД, с заданной периодичностью, перед вне-
сением изменений в структуру БД и т. д.

Принцип восстановления БД состоит в том, что по архивной копии и следуя

журналу, должны быть отработаны все завершенные транзакции.

Поддержка языков доступа БД
Основной функцией любой СУБД, помимо хранения данных, является воз-

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

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

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