Базы Данных - Сибилев, 2007

61

Определения данных всех уровней сохраняются в системном ката-

логе СУБД. Он представляет собой внутреннюю базу данных СУБД, пред-

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

талоге сохраняются:

− определения типов концептуальных, внутренних и внешних запи-

сей;

−описания отображений;

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

−сведения о программных и аппаратных ресурсах системы;

−и другие сведения, необходимые для управления системой.

Т.о., системный каталог СУБД – это информационное ядро системы,

обеспечивающее согласованную работу всех её компонентов.

4.1.5 Независимость приложений от данных

Основное назначение трёхуровневой архитектуры – обеспечить неза-

висимость приложений от данных.

Требование независимости от данных означает, что никакие изме-

нения на нижних уровнях не должны влиять на верхние уровни представ-

ления данных.

Различают два типа независимости от данных: логическую и физиче-

скую.

Логическая Полная защищённость существующих внешних схем от

независимость любых изменений, вносимых в концептуальную схему.

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

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

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

63

4.2 Дисциплина доступа приложений к хранимым данным

В соответствии с архитектурной концепцией ANSI/SPARC приложе-

ния получают доступ к данным, хранящимся в ФБД только через посред-

ство СУБД.

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

мулированный в терминах внешней модели. СУБД (средствами ОС) извле-

кает нужные физические записи, помещает их в свой рабочий буфер, вы-

полняет в буфере требуемую обработку и передаёт результат приложению.

Более подробно этот процесс изображён на следующем рисунке.

ФБД

Рис. 4.4 Схема доступа к хранимым данным

Шаг 1. СУБД получает запрос прикладной программы (ПП) в тер-

минах внешней модели.

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

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

них записей.

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

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

64

Шаг 4. СУБД выдает ОС запрос на считывание в свои буферы необ-

ходимых записей физической базы данных (ФБД).

Шаг 5. ОС считывает затребованные записи и помещает их в сис-

темные буферы СУБД.

Шаг 6. На основании схем и описаний отображений СУБД формиру-

ет в своем буфере затребованные внешние записи.

Шаг 7. СУБД пересылает сформированные внешние записи в рабо-

чую область (РО) ПП.

Шаг 8. СУБД передает в ПП сообщение о результатах выполнения

запроса.

4.3 Операции обработки данных

В процессе исполнения запросов приложений СУБД выполняет че-

тыре разновидности высокоуровневых (описанных средствами входного ЯМД) операций обработки данных.

Следует иметь в виду, что каждая из них на уровне реализации пред-

ставляется последовательностью низкоуровневых операций чтения/записи.

То есть, то, о чём мы говорим как об элементарной операции, на самом де-

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

Извлечение записей (RETREIVE) – считывание в рабочий буфер со-

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

жет выполнять сортировку и группирование записей по указанным прило-

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

поиск макс./мин. значения поля и т.п. При этом никаких изменений в фи-

зической базе данных не происходит.

Извлечённое множество записей может обновляться приложением.

СУБД выполняет следующие операции обновления.

65

Добавление записей (INSERT) – создание в рабочем буфере новых записей, содержащих введённые приложением новые значения данных.

Изменение значений (UPDATE) – замена существующих значений некоторых полей в извлечённом множестве записей новыми значениями,

введёнными приложением.

Удаление записей (DELETE) – уничтожение в рабочем буфере под-

множества извлечённых записей, указанного приложением. При этом за-

писи могут либо физически уничтожаться, либо помечаться как удалён-

ные, но физически сохраняться в буфере.

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

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

лостности данных.

4.4 Дисциплина обменов с внешней памятью

Записи ФБД, считанные в рабочий буфер СУБД по запросу какого-

либо приложения, не удаляются из буфера по исполнении запроса. Они могут потребоваться и, как правило, требуются тому же или другому при-

ложению. СУБД поддерживает определённую дисциплину обменов дан-

ными с внешней памятью.

СУБД, приняв запрос приложения, проверяет, есть ли в буфере дан-

ные, необходимые для его исполнения. Они могли содержаться в физиче-

ских записях, извлечённых по предшествующим запросам. Если данные есть, то они не извлекаются повторно.

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

Если места достаточно, то нужные записи извлекаются, и запрос приложения исполняется. В противном случае содержимое рабочего буфе-

ра выталкивается во внешнюю память и буфер частично очищается. Из не-

го удаляются те данные, которые редко используются приложениями. Для

66

того чтобы иметь возможность сделать это, система накапливает статисти-

ку обращений к данным.

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

нее время реакции системы на запрос приложения.

4.5 Операции обновления и целостность данных.

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

теля, хранящегося в ФБД (состояния БД). Это – одно из основных требова-

ний к СУБД. Целостность состояния БД может нарушаться операциями обновления. Поэтому при завершении каждой операции СУБД должна ав-

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

стности состояния БД.

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

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

да денег с одного банковского счёта на другой. Чтобы выполнить перевод,

нужно

а) извлечь запись счёта-источника (RETREIVE),

б) уменьшить его остаток на переводимую сумму S (UPDATE),

в) извлечь запись счёта-приёмника (RETREIVE),

г) увеличить его остаток на сумму S (UPDATE).

Только по завершении операции г) состояние счетов окажется согласован-

ным.

Другая ситуация – удаление экземпляра родительской записи, с ко-

торым связаны экземпляры записи-потомка. Предположим, что приказом ректора ТУСУРа расформирована студенческая группа 431-4. Соответст-

вующая строка должна быть удалена из таблицы ГРУППА БД ТУСУРа

(операция DELETE). Однако в таблице СТУДЕНТ существуют записи о студентах, зачисленных в эту группу. Допустим, все они тем же приказом переводятся в группу 431-3. Значит, следует обновить значение поля

67

№Группы во всех строках таблицы СТУДЕНТ, в которых №Группы = 431-4 (операция UPDATE).

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

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

чески завершённой последовательности операций обновления.

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

4.6 Понятие транзакции.

В широком смысле транзакция – это последовательность действий над базой данных, выполняемая по запросам одного пользователя или при-

ложения. Транзакция является логической единицей работы в базе данных.

Она может быть представлена отдельной программой, частью программы,

последовательностью операторов ЯМД, вводимых в интерактивном режи-

ме, или даже отдельным оператором.

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

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

на. Прикладной программист или пользователь, работающий в интерак-

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

ции. Транзакция должна начинаться и завершаться при согласованном (це-

лостном) состоянии БД.

Теперь можно уточнить понятие транзакции.

Транзакция – это последовательность действий над базой данных,

выполняемая по запросам одного пользователя или приложения и перево-

дящая БД из согласованного начального состояния в согласованное ко-

нечное состояние.

Это – основное требование к транзакции. Оно означает, что система должна гарантировать

а) целостность состояния БД к моменту начала очередной транзак-

ции,

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

68

Подчеркнём, что промежуточные состояния БД могут быть несогла-

сованными.

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

– фиксацией или откатом.

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

чения целостности, то новое состояние БД фиксируется (COMMIT TRANSACTION).

Если к моменту завершения транзакции состояние БД не удовлетво-

ряет хотя бы одному ограничению целостности, то все обновления данных,

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

ется откатом транзакции (ROLLBACK TRANSACTION).

Напомним, что все операции обновления данных применяются к со-

держимому рабочего буфера СУБД. Поэтому фиксация транзакции означает,

что система должна в дальнейшем воспринимать новое состояние буфера как часть согласованного состояния БД.

Откат транзакции означает, что система должна восстановить то со-

стояние буфера, которое существовало на момент начала транзакции.

4.7 Свойства транзакции.

Механизм транзакций – важнейший механизм технологии БД. Тран-

закция обладает следующими свойствами.

1)Она является неделимой единицей работы в БД – атомарность.

2)Она начинается и завершается при согласованном состоянии БД –

согласованность.

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

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

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

рая исключала бы их взаимное влияние. Это называется изолированностью транзакции.

69

3) Система гарантирует эквивалентность результатов параллельного исполнения любого набора транзакций результатам независимого испол-

нения транзакций того же набора в какой-либо последовательности – изо-

лированность.

Современные СБД – высоконадёжные системы, но абсолютной на-

дёжностью они не обладают. В любой момент может возникнуть аварий-

ная ситуация, которая приведёт к частичному или даже полному разруше-

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

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

нять её повторно, что бы ни случилось с системой.

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

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

4.8 Управление доступом к данным

4.8.1 Принципы ограничения доступа.

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

приятия, а с другой – надёжно защищён от попыток похищения и фальси-

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

вать систему мер защиты баз данных.

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

нировании) доступа к данным компьютерными средствами.

70

Право служащего предприятия получать данные из БД и манипули-

ровать ими естественно ограничивается его служебными обязанностями.

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

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

2.Служащий имеет право выполнять только те манипуляции дос-

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

4.8.2 Авторизация пользователей.

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

там.

Пользователем считается зарегистрированный в системном каталоге

идентификатор авторизации (user’s ID), который может быть присвоен лицу, группе лиц или прикладной программе.

Привилегия – это право пользователя выполнять определённое дей-

ствие над определённым объектом БД: запускать приложение, просматри-

вать таблицу, вставлять строки в таблицу и т.п.

Ответственность за авторизацию пользователей возлагается на адми-

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

пользователей. В учётной записи указывается

−идентификатор авторизации – имя, под которым пользователь будет известен системе;

−тип пользователя – лицо, группа или прикладная программа;

−описание – ФИО, должность лица, наименование группы, имя про-

граммы, её назначение и т.п.

Учётные записи сохраняются в системном каталоге.