Базы данных. Учебное пособие

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

3.2. Типовая организация современной СУБД

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

üвнутреннюю часть – ядро СУБД (Data Base Engine);

üкомпилятор языка базы данных (обычно SQL);

üнабор утилит.

Рисунок. Организация типичной СУБД

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

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

51

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

Основная функция компилятора языка баз данных – из операторов языка SQL, понятных пользователю, компилиру- ется программа, «понятная» ЭВМ.

Результатом компиляции является выполнимая про- грамма. Довольно редко эта программа пишется в машинных кодах, т. к. слишком велика в этом случае зависимость от ап- паратной платформы. Гораздо чаще программа компилирует- ся в каком-то внутреннем коде, независимом от аппаратной платформы. В последнем случае для выполнения этой про-

граммы привлекается интерпретатор этого внутреннего кода (он называется подсистемой поддержки времени выполне- ния).

Утилиты обычно выделяют такие процедуры, кото-

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

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

3.3.Пользователи БД

Работающие с базами данных пользователи обладают различными навыками и знаниями и сталкиваются с решени- ем различных задач. Спектр пользователей достаточно ши- рок:

žконечные пользователи;

žразработчики БД;

žразработчики приложений;

žадминистраторы БД.

52

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

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

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

Порядок работы разработчиков при создании базы дан-

ных.

1.Интенсивные консультации с пользователями для опреде- ления круга решаемых задач.

2.Анализ всевозможных документов, чтобы определить, какую информацию и как надо ее хранить в базе данных.

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

4.Создание спецификации (перечня) содержимого базы

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

5.Написание программного обеспечения.

Разработчики приложений проектируют и разрабаты-

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

Администраторы баз данных — это люди, управляющие базами данных. Они отвечают за предоставление и контроль

53

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

3.4. Ограничения целостности

Целостность БД – понимается как правильность дан- ных в любой момент времени. Но эта цель может быть дос- тигнута лишь в определенных пределах: СУБД не может кон- тролировать правильность каждого отдельного значения, вво- димого в базу данных (хотя каждое значение можно прове- рить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его от- вергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору [1,2,3,4,5,6,7].

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

Различается логическая и физическая целостность. Поддержка логической целостности (непротиворечиво-

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

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

Нарушения логической целостности могут быть свя-

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

Проблема физической целостности БД возникает в связи с ее возможным разрушением в результате сбоев и от-

54

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

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

С точки зрения пользователей СУБД, основными сред- ствами поддержания целостности данных являются:

∙ограничения;

∙правила.

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

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

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

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

55

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

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

ные СУБД имеют ряд средств для обеспечения поддержания целостности. Они контролируют:

žцелостность по сущностям,

žцелостность по ссылкам,

žцелостность, определяемая пользователем.

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

a)Не допускается, чтобы какой-либо атрибут, участвую- щий в первичном ключе, принимал неопределенное значение.

b)Значение внешнего ключа должно либо:

üбыть равным значению первичного ключа цели;

üбыть полностью неопределенным, то есть каждое зна- чение атрибута, участвующего во внешнем ключе должно быть неопределенным.

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

üуникальность тех или иных атрибутов,

üдиапазон значений (экзаменационная оценка от 2 до 5),

üпринадлежность набору значений (пол "М" или "Ж").

3.5. Общие принципы восстановления базы данных

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

Типичная СУБД должна предоставлять такие функции восстановления, как:

56

1)механизм резервного копирования, предназначенный для периодического создания копий базы данных;

2)средства ведения журнала, в котором фиксируются теку- щее состояние транзакций и вносимые в базы данных из- менения;

3)функция создания контрольных точек, обеспечивающая перенос выполняемых в базе данных изменений во вто- ричную помять с целью сделать их постоянными;

4)менеджер восстановления, обеспечивающий восстановле-

ние согласованного состояния базы данных, нарушенного

врезультате отказа.

Возможны следующие ситуации, при которых требуется

производить восстановление состояния базы данных:

1.Индивидуальный откат транзакции. Типичной ситуацией

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

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

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

3.Восстановление после поломки основного внешнего носи-

теля базы данных (жесткий сбой). Эта ситуация в совре-

менных условиях при высокой надежности устройств внешней памяти может встретиться крайне редко, но все-

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

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

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

57

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

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

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

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

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

2)результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы дан- ных.

3.6.1.Файл журнала

В файл журнала может помещаться следующая инфор- мация:

üзаписи о транзакциях (идентификатор транзакции, тип за- писи журнала;

üидентификатор элемента данных, вовлеченного в опера- цию обработки базы данных;

üкопия элемента данных до и после операции);

üзаписи о контрольных точках.

Основой восстановления является избыточное хранение данных; эти данные хранятся в журнале, содержащем после- довательность записей об изменении базы данных. Возможно два варианта ведения журнальной информации.

В первом варианте - для каждой транзакции поддержи-

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

58

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

3.6.2. Журнализация и буферизация

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

венный способ достижения удовлетворительной работы СУБД.

Если бы запись об изменении базы данных, которая

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

страница выталкивается во внешнюю память журнала только при полном заполнении буфера записями.

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

можность восстановления состояния базы данных после сбоев.

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

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

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

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

59

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

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

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

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

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

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

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

новить прямой список записей об изменениях базы данных определенной транзакции.

Индивидуальный откат транзакции выполняется сле- дующим образом:

60