Глушаков С.В., Ломотько Д.В. Базы данных

Подождите немного. Документ загружается.

Часть I. Теория баз данных

Дальнейшая нормализация отношений, подобных отношению

ПРЕДМЕТЫ, основывается на проецировании без потерь. Здесь

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

ния, при котором исходное отношение полностью и без избыточ-

ности восстанавливается путем естественного соединения полу-

ченных отношений.

Таким образом, Отношение находится в 4НФ в том случае,

если в случае существования многозначной зависимости

А —*—* В все остальные атрибуты отношения функционально

зависят от А.

В нашем примере можно произвести декомпозицию отноше-

ния ПРЕДМЕТЫ в два отношения ПРЕДМЕТЫ-КУРСЫ и

ПРЕДМЕТЫ-ЗАДАНИЯ, как показано на рис. 1.18

PQ (ПРЕДМЕТЫ-КУРСЫ)

PNAME

PZ (ПРЕДМЕТЫ-ЗАДАНИЯ)

PZAN

Рис. 1.18. Декомпозиция отношения PR (ПРЕДМЕТЫ)

Оба полученных отношений находятся в 4НФ и свободны от

отмеченных выше проблем.

Во всех рассмотренных до этого момента нормализация про-

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

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

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

Рассмотрим отношение Р1 (ПРЕПОДАВАТЕЛИ), структура ко-

торого приведена на рис. 1.!9.

Р1 (ПРЕПОДАВАТЕЛИ)

TEACHER KAFEDRA

PNAME

Рис. 1.19. Структура отношения Р1 (ПРЕПОДАВАТЕЛИ)

Предположим, что один и тот же преподаватель может рабо-

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

учебным предметам. Первичным ключом этого отношения явля-

ется полная совокупность его атрибутов, то есть {TEACHER.

KAFEDRA, PNAME}. В отношении отсутствуют функциональ-

ные и многозначные зависимости. Поэтому отношение находится

в 4НФ. Однако в нем могут существовать проблемы, которые

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

Глава 1.4. Функции защиты базы данных

Введем понятие зависимости соединения. Отношение R (X, Y,

.... Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) толь-

ко в том случае, когда R восстанавливается без потерь путем со-

единения своих проекций на X, Y,..., Z.

Тогда отношение находится в 5НФ (НФПС) только в том

случае, когда любая зависимость соединения в отношении

следует из существования некоторого возможного ключа в

данном отношении.

Введем следующие имена составных атрибутов:

ТК = {TEACHER, KAFEDRA}

ТР = {TEACHER, PNAME}

КР - {KAFEDRA, PNAME}

Предположим, что в отношении ПРЕПОДАВАТЕЛИ сущест-

вует зависимость соединения: • (ТК, ТР, КР)

На примерах легко показать, что при вставках и удалении

кортежей из ПРЕПОДАВАТЕЛИ могут возникнуть проблемы. Их

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

три новых отношения, представленных на рис. 1.20.

ТК

TEACHER KAFEDRA

ТР

TEACHER PNAME

КР

KAFEDRA

PNAME

Рис. 1.20. Декомпозиция отношения Р1 (ПРЕПОДАВАТЕЛИ)

5НФ - это последняя нормальная форма, которую можно по-

лучить путем декомпозиции. Ее условия достаточно нетривиаль-

ны, и на практике 5НФ используется достаточно редко.

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

лизации отношений:

Отношение в 1НФ необходимо разбить на проекции для

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

Как результат в итоге будет получен набор отношений в 2НФ.

Отношение, находящееся в 2НФ следует разбить на проекции

для исключения "двойных'

функциональных •зависимостей. В

результате будет получен набор отношений в ЗНФ.

Часть I. Теория баз данных

Полученные отношения в ЗНФ следует разбить на проекции

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

рых детерминанты не являются потенциальными ключами. В ре-

зультате такого приведения будет получен набор отношений в

НФБК.

Отношения, находящиеся в НФБК. необходимо разбить на

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

которые не являются функциональными. В итоге получим набор

отношений в 4НФ.

Отношения в 4НФ разбивают на проекции с целью исключе-

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

потенциальными ключами. Таким образом будет получен набор

отношений в 5НФ.

Объектное моделирование

Теперь необходимо остановиться на том факте, что СУБД об-

ладают достаточно ограниченными сведениями о смысловом

значении тех данных, которые хранятся в БД. Широкое распро-

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

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

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

ко проектирование реляционной БД в терминах отношений на

основе изложенной выше методологии нормализации довольно

часто представляет собой сложный и неудобный для проекти-

ровщика процесс.

При этом проявляется ограниченность реляционной модели

данных в следующих моментах:

• реляционная модель не дает проектировщику достаточ-

ных средств для представления смысла данных. Семанти-

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

модели способом как бы вырисовываться в голове проек-

тировщика. Например, это относится к упоминавшейся

выше проблеме представления ограничений целостности;

• для многих приложений трудно моделировать предмет-

ную область на основе простейших таблиц. В ряде случа-

ев на начальной стадии проектировщику приходится

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

ную область в виде одной (возможно, даже ненормализо-

ванной) таблицы-отношения;

• хотя весь процесс проектирования БД происходит на ос-

нове учета зависимостей между данными, реляционная

Глава 1.4. Функции защиты базы данных

модель не дает каких-либо средств для представления

этих зависимостей;

• несмотря на то, что процесс проектирования начинается с

выделения некоторых существенных для приложения

объектов предметной области ("сущностей") и выявления

связей между этими сущностями, реляционная модель

данных не располагает какого-либо аппарата для разде-

ления сущностей и связей.

Необходимость в более удобных и мощных средствах моде-

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

ками БД задачу семантического моделирования данными.

Наиболее часто на практике семантическое моделирование

используется на первой стадии проектирования БД. При этом в

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

схема БД, которая затем преобразуется к реляционной схеме.

Этот процесс выполняется под управлением методик, в которых

достаточно четко оговорены все этапы такого преобразования. В

результате производится реляционная схема БД в ЗНФ.

В настоящее время проводятся исследовательские разработки

над БД в семантической модели, то есть СУБД, основанной на

семантической модели данных. При этом рассматриваются два

варианта - обеспечение пользовательского интерфейса на основе

семантической модели данных с автоматическим отображением

отношений в реляционную модель данных и прямая реализация

СУБД, основанная на какой-либо семантической модели данных.

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

объектно-ориентированные СУБД, модели данных которых по

многим параметрам близки к семантическим моделям.

Рассмотрим одну из наиболее важных и распространенных

семантических моделей данных - модель "Сущность-Связи"

(часто ее называют кратко ER-моделью). На использовании

разновидностей ER-моделей основано большинство современ-

ных подходов к проектированию реляционных БД.

Моделирование предметной области базируется на использо-

вании диаграмм, включающих небольшое число разнородных

компонентов. В связи с наглядностью представления концепту-

альных схем БД ER-модели получили широкое распространение

в системах, поддерживающих автоматизированное проектирова-

ние реляционных БД.

Основными понятиями ER-модели являются сущность, связь

и атрибут.

Часть I. Теория баз данных

Сущность - это реальный или представляемый объект, ин-

формация о котором должна сохраняться и быть доступна. В диа-

граммах ER-модели сущность представляется в виде прямо-

угольника, содержащего имя сущности. При этом имя сущности -

это имя типа, а не некоторого конкретного элемента этого типа

Например, на рис. 1.21 приведена сущность ИНСТИТУТ с при-

мерными объектами Политехнический и Железнодорожный.

ИНСТИТУТ

Политехнический,

Железнодорожный

Рис. 1.21. Сущность ИНСТИТУТ

Каждый элемент сущности должен быть отличим от любого

другого элемента той же сущности, что аналогично требованию

отсутствия кортежей-дубликатов в отношениях.

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

ливаемая между двумя сущностями. Эта ассоциация всегда

является бинарной и может существовать между двумя разны-

ми сущностями или между сущностью и ей же самой - послед-

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

ются два конца, на каждом из которых указывается имя конца

связи, степень конца связи (сколько элементов данной сущно-

сти связывается) и обязательность связи (то есть любой ли

элемент данной сущности должен участвовать в этой связи)

Связь представляется в виде линии, соединяющей две сущно-

сти или ведущей от сущности к ней же самой. При этом в месте

соприкосновения связи с сущностью используются трехточечный

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

сколько элементов, и одноточечный вход, если в связи может

участвовать только один элемент сущности. Обязательный конец

связи изображается сплошной линией, а необязательный - преры-

вистой линией.

На рис. 1.22 приведен пример связи между сущностями ЗА-

ДАЧА и СТУДЕНТ. При этом конец связи с именем "для" позво-

ляет соединить с одним студентом более одной задачи, причем

каждая задача должна быть «вязана с каким-либо студентом. Ко-

нец сущности с именем "решает" означает, что каждая задача

может решаться только одним студентом, причем студент может

и не иметь задачи.

Глава 1.4. Функции защиты базы данных

СТУДЕНТ

для

ЗАДАЧА

решает-

Рис. 1.21. Связь сущностей ЗАДАЧА-СТУДЕНТ

Трактовка изображенной диаграммы следующая: каждая за-

дача предназначена для одного студента, однако каждый студент

может иметь одну или более задач.

На рис. 1.22 изображена рекурсивная связь, соединяющая

сущность ЧЕЛОВЕК с ней же самой. Конец связи с именем

"учащийся" устанавливает тот факт, что человек может высту-

пать один или несколько раз в жизни в роли учащегося. Конец

связи с именем "студент" означает, что не каждый человек был

студентом.

учащийся

студент

Рис. 1.22. Рекурсивная связь сущностей

Атрибутом сущности является любой элемент, который слу-

жит для уточнения, идентификации, классификации, числовой

характеристики или выражения состояния сущности. Имена ат-

рибутов заносятся в прямоугольник, обозначающий сущность, и

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

с примерами.

Как и в реляционных схемах БД, в ER-схемах вводится по-

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

ветствует смыслу реляционных нормальных форм. Заметим,

что формулировки нормальных форм ER-схем делают более

понятным смысл нормализации реляционных схем. Приведем

только очень краткие и неформальные определения трех пер-

вых нормальных форм.

• В 1НФ ER-схемы устраняются повторяющиеся атрибуты или

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

сущностей, "замаскированных" под атрибуты.

Часть I Теория баз данных

Во 2НФ устраняются атрибуты, зависящие только от части

уникального идентификатора. Эта часть уникального идентифи-

катора определяет отдельную сущность.

В ЗНФ устраняются атрибуты, зависящие от атрибутов, не

входящих в уникальный идентификатор. Они являются основой

отдельной сущности.

К числу более сложных элементов ER-модели относятся

следующие:

• подтипы и супертипы сущностей. Как в языках объект-

но-ориентированного программирования, вводится воз-

можность наследования типа сущности, исходя из одного

или нескольких супертипов;

• связи "многие-со-многими". Иногда бывает необходимо

связывать сущности таким образом, что с обоих концов

связи могут присутствовать несколько экземпляров

сущности;

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

делить возможное количество экземпляров сущности,

участвующих в данной связи. Для выражения этого огра-

ничения разрешается указывать на конце связи ее макси-

мальную или обязательную степень;

• каскадные удаления экземпляров сущностей. Некоторые

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

опорного экземпляра сущности (соответствующего концу

связи "один") нужно удалить и все экземпляры сущности,

соответствующие концу связи "многие" Соответствую-

щее требование "каскадного удаления" можно сформули-

ровать при определении сущности;

• домены. Как и в случае реляционной модели данных,

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

но допустимого множества значений атрибута сущно-

сти (домена).

Эти и другие более сложные элементы модели данных "Сущ-

ность-Связи" делают ее существенно более мощной, но одновре-

менно серьезно усложняют ее использование. Например, сущ-

ность может быть расщеплена на два или более взаимно исклю-

чающих подтипа, каждый из которых включает общие атрибуты.

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

Сущность.' на основе которой определяются подтипы, называется

супертипом.

Получение реляционной схемы из ER-схемы осуществляется

СЮДУЮЩИМ

образом:

Глава 1.4. Функции защиты базы данных

каждая простая сущность превращается в отношение.

Простая сущность - сущность, не являющаяся подтипом и

не имеющая подтипов. Имя сущности становится именем

отношения;

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

же именем; может выбираться более точный формат.

Столбцы, соответствующие необязательным атрибутам,

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

ответствующие обязательным атрибутам - не могут;

компоненты уникального идентификатора сущности пре-

вращаются в первичный ключ отношения. Если имеется

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

бирается наиболее удобный. Если в состав уникального

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

ного ключа добавляется копия уникального идентифика-

тора сущности, находящейся на дальнем конце связи

(этот процесс может продолжаться рекурсивно). Для

именования этих столбцов используются имена концов

связей и/или имена сущностей;

связи "многие к одному" и "один к одному" становятся

внешними ключами. То есть делается копия уникального

идентификатора с конца связи "один", и соответствую-

щие столбцы составляют внешний ключ. Необязательные

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

ленные значения; обязательные связи - столбцам, не до-

пускающим неопределенные значения;

индексы создаются для первичного ключа, внешних клю-

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

вать в запросах;

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

то возможны два способа: все подтипы в одной таблице

или для каждого подтипа - отдельная таблица. При при-

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

более внешнего супертипа, а для подтипов могут созда-

ваться представления. В отношение добавляется по край-

ней мере один столбец, содержащий код ТИПА; он ста-

новится частью первичного ключа. При использовании

второго метода для каждого подтипа первого уровня (для

более нижних - представления) супертип воссоздается с

помощью представления:

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

связей: общий домен и явные внешние ключи. Если ос-

тающиеся внешние ключи все в одном домене, то есть

Часть 1. Теория баз данных

имеют общий формат, то создаются два столбца: иденти-

фикатор связи и идентификатор сущности. Столбец иден-

тификатора связи используется для различения связей,

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

ра сущности используется для хранения значений уни-

кального идентификатора сущности на дальнем конце со-

ответствующей связи. Во втором случае, если результи-

рующие внешние ключи не относятся к одному домену,

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

создаются явные столбцы внешних ключей; все эти

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

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

ном этапе правильно спроектировать логическую структуру БД.

Глава 1.4

Функции защиты базы данных

Транзакции и параллелизм

При работе СУБД возникает необходимость защиты БД от

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

существует вероятность потери данных. Например, при доступе к

БД сразу нескольких пользователей возможно повреждение или

неправильная запись данных, что в свою очередь может привести

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

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

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

Поддержание^механизма транзакций - показатель уровня раз-

витости СУБД. Корректное поддержание транзакций одновре-

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

ции также составляют основу изолированности пользователей во

многопользовательских системах.

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

действия на БД последовательность операторов манипулирова-

ния данными (чтения, удаления, вставки, модификации) такая,

что возможны два итога:

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

ответствующим образом отображаются в БД;

• воздействие всех этих операторов полностью отсутствует.

Глава 1.4. Функции зашиты базы данных

В СУБД транзакция начинается с оператора BEGIN. При

этом если транзакция завершена оператором COMMIT, то ре-

зультаты фиксируются во внешней памяти; при завершении

транзакции оператором ROLLBACK результаты отсутствуют

во внешней памяти.

Оператор COMMIT устанавливает так называемую точку

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

ница работы. Следовательно, БД будет находиться в согласо-

ванном (целостном) состоянии как в начале, так и в конце тран-

закции. При завершении транзакции оператором ROLLBACK

БД тоже будет находиться в согласованном состоянии, так как

никакого влияния на данных такая транзакция не окажет. Здесь

под согласованностью будем понимать тот факт, что транзакции

переводят БД из одного согласованного состояния в другое, то

есть в такое, что выполняются все условия ограничения целост-

ности и.т.п.

В свою очередь, понятие восстановление СУБД - процесс, под-

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

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

принципе избыточности БД, при этом по части хранимых данных

имеется возможность восстановления всей информации полностью.

Система должна обеспечивать восстановление как после не-

больших нарушений (например, после неудачно завершенных

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

глобальными), например, сбоев питания.

Глобальный сбой полиостью действует на СУБД и обычно

выделяют два вида: сбой системы, нарушающий все выполняе-

мые в данный момент транзакции, но не нарушающий БД физи-

чески, и сбой носителей, который представляет собой физиче-

скую угрозу для данных.

Восстановление системы после первого вида глобального сбоя

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

заносится информация о транзакциях, начавших свое выполне-

ние, и транзакциях, успешно завершившихся. Если после переза-

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

шиеся до сбоя, но не закончившиеся, то для всех них выполняет-

ся оператор ROLLBACK, в результате чего БД снова будет нахо-

диться в целостном состоянии.

Процесс восстановления после сбоя носителей принципиаль-

но иной. Восстановление в этом случае осуществляется с резерв-

ной копии БД. Понятно, что для реализации этого процесса необ-

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

ние с помощью соответствующей программной реализации.

Часть I. Теория баз данных

Понятие транзакции имеет непосредственную связь с поня-

тием целостности БД. Очень часто БД может обладать такими

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

нарушить, выполняя изменение только одним оператором.

Например, в базе данных СТУДЕНТЫ - ПРЕДМЕТЫ -

ОЦЕНКИ (см. рис. 1.11) очевидным ограничением целостности

является совпадение значения атрибута SN в кортеже

отношения СТУДЕНТЫ с аналогичным атрибутом отношения

ОЦЕНКИ. В этом случае возникает проблема с добавлением

новому студенту оценки по экзамену. Независимо от того, какая

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

отношение СТУДЕНТЫ или в отношение ОЦЕНКИ, после

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

Для поддержания подобных ограничений целостности допус-

кается их нарушение внутри транзакции с тем условием, чтобы к

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

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

ния и контроля целостности каждая транзакция начинается при

целостном состоянии БД и должна оставить это состояние цело-

стным после своего завершения. Несоблюдение этого условия

приводит к тому, что вместо фиксации результатов транзакции

происходит ее отмена (то есть откат транзакции, когда она вместо

оператора COMMIT завершается оператором ROLLBACK), и БД

остается в таком состоянии, в котором находилась к моменту на-

чала транзакции.

В многопользовательских системах с одной БД, вообще гово-

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

прикладных программ. Одной из основных задач СУБД является

обеспечение изолированности пользователей, то есть создание

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

лось, что он работает с БД в одиночку. Такую задачу СУБД при-

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

При параллельной обработке БД возникает три основных

проблемы:

• проблема потери результатов обновления - заключается в

первую очередь в том. что транзакция может быть неза-

вершена из-за того, что данные, которые она обрабатыва-

ет, могут быть модифицированы другой транзакцией;

• проблема незафиксированности зависимости - состоит в

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

ные, которые в настоящий момент модифицируются дру-

гой транзакцией. Понятно, что первая из них вполне мо-

Глава 1.4. Функции защиты базы данных

жет работать с данными, которые по завершению второй

транзакции в БД просто будут отсутствойать;

• проблема несовместимого анализа - связана с тем. что в

результате модификации БД транзакцией, другая тран-

закция может внести в БД некую информацию, которая

не будет соответствовать целостному состоянию БД.

Для решения этих проблем используют блокировку - метод

управления параллельными процессами, при котором объект БД.

например, кортеж не может быть модифицирован без ведома

транзакции. То есть результатом блокировки есть блокирование

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

ется непредсказуемое изменение объекта.

Различают два вида блокировки:

• блокировка записи - при этом транзакция блокирует кор-

теж таким образом, что запрос другой транзакции к этому

кортежу будет отменен;

• блокировка чтения - в этом случае транзакция блокирует

кортеж так, что запрос со стороны другой транзакции на

блокировку записи этого кортежа будет отвергнут, а на

блокировку чтения - принят.

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

щий избежать проблем параллелизма. Его суть заключается в

следующем:

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

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

ния на этот кортеж;

• транзакция, предназначенная для модификации кортежа,

обязана наложить блокировку записи на этот кортеж:

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

вергается из-за того, что на кортеж уже наложена блоки-

ровка, то транзакция переводится в режим ожидания до

тех пор, пока блокировка не будет снята.

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

нения транзакции, то есть до выполнения операторов

COMMIT или ROLLBACK.

Решение проблем, параллельной обработки БД, заключается в

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

фицирующие этот кортеж, отвергаются и переводятся в режим

ожидания.

В связи со свойством сохранения целостности БД транзакции

являются подходящими единицами изолированности пользовате-

Часть I. Теория баз данных

лей. Действительно, если каждый сеанс работы с БД реализуется

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

ванным состоянием БД, то есть с таким ее состоянием, в котором

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

ней в одиночку.

Безопасность и целостность баз данных

Вопросы безопасности и целостности! - еще одна из важней-

ших сторон работы СУБД. Под безопасностью понимают защиту

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

кации. Систему можно считать безопасной только в том случае,

если пользователю допускается выполнять только разрешенные

действия. Целостность БД связана с корректным выполнением

этих действий.

В СУБД традиционно поддерживаются избирательный или

обязательный подходы обеспечения безопасности данных. При

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

пользователь обладает различными правами (полномочиями) при

работе с тем или иным объектом БД. В случае обязательного

подхода каждому объекту БД присваивается уровень доступа, а

пользователям - уровни допуска. Разумеется, для получения дос-

тупа к объекту пользователь должен обладать соответствующим

уровнем допуска.

Оба подхода реализуются в СУБД в виде особых правил безо-

пасности, предусматривающих опознание источника запроса. По

этой причине в начале работы пользователь вводит свой иденти-

фикатор (логин) и пароль для подтверждения своих полномочий.

Избирательное управление доступом задается правилами,

которые должны включать следующее:

• имя правила - представляет собой структуру, по которой

это правило идентифицируется системой;

• собственно правила или привилегии - набор директив, со-

ставляющих способ и возможность доступа, модифика-

ций и т. п. объектов БД;

• диапазон применения привилегий;

• идентификаторы пользователей, обладающих вышепере-

численными привилегиями;

• действие при нарушении правила - здесь указывается по-

ведение системы в случае, если пользователь нарушил

правило безопасности. Как правило, оно заключается в

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

Глава 1.4. Функции защиты базы данных

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

ния Р структуры, приведенной на рисунке 1.11.

СОЗДАТЬ ПРАВИЛО БЕЗОПАСНОСТИ RULE1

ДЛЯ МОДИФИКАЦИИ И УДАЛЕНИЯ Р

(PN, PNAME, TEACHER, KAFEDRA)

ДЛЯ KAFEDRA-"ФИЗИКА"

ПОЛЬЗОВАТЕЛИ: Ivan, Denis, Andrew

НЕ ВЫПОЛНЯТЬ ПРИ НАРУШЕНИИ ПРАВИЛА

Приведенное выше правило содержит все пять оговоренных

элементов. Фактически создано правило безопасности с именем

RULE1, позволяющее модификацию и удаление кортежей (PN,

PNAME, TEACHER, KAFEDRA) отношения Р. относящихся к

кафедре физики для пользователей с идентификаторами Ivan,

DENIS и Andrew. Если правило будет нарушено (например, за-

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

Petr), то в запрашиваемом действии будет отказано.

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

полнении следующих правил:

• пользователь имеет возможность работы (но не модифи-

кации) с объектом, если уровень его допуска больше или

равен уровню доступа объекта;

• пользователь имеет возможность модифицировать объ-

ект, если уровень его допуска равен уровню доступа

объекта.

Правило безопасности в этом случае для пользователя с иден-

тификатором DENIS можно, например, сформулировать следую-

щим образом:

СОЗДАТЬ ПРАВИЛО БЕЗОПАСНОСТИ RULE2

ДЛЯ ПОЛЬЗОВАТЕЛЯ Denis

УСТАНОВИТЬ УРОВЕНЬ ДОПУСКА = 5

А для отношения Р, например, вот так:

СОЗДАТЬ ПРАВИЛО БЕЗОПАСНОСТИ RULE3

ДЛЯ МОДИФИКАЦИИ И УДАЛЕНИЯ Р

(PN, PNAME, TEACHER, KAFEDRA)

УСТАНОВИТЬ УРОВЕНЬ ДОПУСКА - 5

НЕ ВЫПОЛНЯТЬ ПРИ НАРУШЕНИИ ПРАВИЛА

Часть I. Теория баз данных

Тогда-пользователь DENIS имеет доступ для модификации и

удаления кортежей отношения Р, поскольку уровень его допуска

и уровень доступа к отношению соответствуют друг другу.

Для обеспечения высокого уровня безопасности СУБД ведут

журнал выполняемых операций. По этому журналу - с одной сто-

роны можно осуществить восстановление данных, с другой -

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

ционированные действия над БД.

Обычно в файле журнала хранится следующая информация:

исходный текст запроса;

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

идентификатор пользователя, подавшего запрос;

дата и время осуществления запроса;

используемые запросом отношения, кортежи и атрибуты;

значения данных, с которыми работали до их модификации;

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

сле их модификации.

• Помимо вышесказанного, довольно часто для защиты

данных используется хранение и передача шифрованных

данных. Открытый (незашифрованный) текст шифруется

при помощи специальных алгоритмов.

Другой стороной проблемы безопасности и целостности БД яв-

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

этот вопрос решают с помощью ограничений целостности.

Традиционно различают два вида ограничений целостности:

немедленно проверяемые и откладываемые. К немедленно прове-

ряемым ограничениям целостности относятся такие офаничения.

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

ний период. Примером такого офаничения. проверку которого

откладывать бессмысленно, являются офаничения домена -

оценка по экзамену не может быть менее 1 и более 5 или возраст

преподавателя не может превышать 100 лет. Более сложным ог-

раничением, проверку которого невозможно отложить, является

следующее: студент не может сдавать экзамен и получить оцен-

ку, если у него к этому моменту не сданы все зачеты. Немедленно

проверяемые офаничения целостности соответствуют уровню

отдельных операторов языкового уровня СУБД При их наруше-

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

ветствующий оператор.

Откладываемые офаничения целостности - это офаничения

на БД. а не на какие-либо отдельные операции. Обычно такие

офаничения проверяются в конце транзакции, и их нарушение

Глава 1.4. Функции защиты базы данных

вызывает завершение транзакции оператором ROLLBACK. В

некоторых СУБД поддерживается" специальный оператор провер-

ки офаничений целостности внутри фанзакции. Если после вы-

полнения такого оператора обнаруживается, что условия целост-

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

тор ROLLBACK или постараться усфанить причины нецелост-

ного состояния БД внутри фанзакции.

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

лостности БД возможны следующие уровни изолированности

транзакций:

• первый уровень - отсутствие потерянных изменений. Рас-

смофим следующий пример совместного выполнения

двух транзакций. Транзакция 1 изменяет объект базы

данных S. До завершения транзакции 1 транзакция 2 так-

же изменяет объект S. Транзакция 2 завершается опера-

тором ROLLBACK, например, по причине нарушения ог-

раничений целостности. Тогда при повторном чтении

объекта S транзакция 1 не видит изменений этого объек-

та, произведенных ранее. Возникает ситуация потерян-

ных изменений. Понятно, она противоречит требованию

изолированности пользователей. Чтобы избежать такой

ситуации в транзакции 1 требуется, чтобы до завершения

фанзакции 1 никакая другая транзакция не могла изме-

нять объект S;

• второй уровень - отсутствие чтения данных, модифици-

руемых другой фанзакцией. Рассмотрим такой пример

совместного выполнения фанзакции 1 и 2. Транзакция 1

изменяет объект базы данных S. Параллельно с этим

фанзакция 2 читает объект S. Поскольку операция изме-

нения еще не завершена, транзакция 2 видит несогласо-

ванные данные. В частности, операция фанзакции 1 мо-

жет быть отвернута при контроле немедленно проверяе-

мого офаничения целостности. Это тоже не соответству-

ет требованию изолированности пользователей (каждый

пользователь начинает свою транзакцию при согласован-

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

ные данные). Чтобы избежать ситуации чтения таких

данных, до завершения фанзакции 1, изменившей объект

S, никакая другая фанзакция не должна читать объект S;

• третий уровень - отсутствие неповторяющихся чтений.

Рассмофим следующий сценарий. Транзакция 1 читает

объект базы данных S. До завершения транзакции 1 фан-

закция 2 изменяет объект S и успешно завершается one-

Часть I. Теория баз данных

ратором COMMIT. Транзакция 1 повторно читает объект

S и видит его измененное состояние. Чтобы избежать не-

повторяющихся чтений, до завершения транзакции 1 ни-

какая другая транзакция не должна изменять объект S.

Как уже было сказано выше, существует возможность обеспе-

чения разных уровней изолированности для той или иной тран-

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

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

транзакций называется сериальным, если результат совместного

выполнения транзакций эквивалентен результату некоторого по-

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

Сериализация транзакций - это такой механизм их выполнения

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

уровне основных функций СУБД, ответственных за управление

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

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

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

риализации набора транзакций, который не слишком ограничивал

бы их параллельность. Простейшим решением является действи-

тельно последовательное выполнение транзакций. Но существу-

ют ситуации, в которых можно выполнять операторы разных

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

мерами могут служить только читающие транзакции, а также

транзакции, не конфликтующие по объектам БД.

Обычно ограничения целостности применяют для описания

базовых отношений - последние содержат данные, отражающие

реальную действительность, поэтому их обрабатывают таким

образом, чтобы данные были корректными.

В общем случае ограничение целостности должно содержать

три основные части:

• имя ограничения - представляет собой структуру, по ко-

торой это ограничение идентифицируется системой;

• собственно ограничения -набор директив и команд, со-

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

ляющий в конечном итоге логическое выражение. Огра-

ничение удовлетворяется, если оно истинно, и нарушает-

ся - если оно ложно;

• действие при нарушении ограничения - здесь предписы-

вается действие системы при нарушении ограничения.

Например, ограничение целостности для отношения SP.

приведенного на рис. 1.11. можно сформулировать следующим

образом:

Глава 1.4. Функции защиты базы данных

СОЗДАТЬ ОГРАНИЧЕНИЕ ЦЕЛОСТНОСТИ RULE4

ДЛЯ ВСЕХ SP(SP.OCENKA>0 И SP.OCENKA<6)

НЕ ВЫПОЛНЯТЬ ПРИ НАРУШЕНИИ ПРАВИЛА

В данном примере ограничение целостности накладывается на

атрибут OCENKA отношения SP таким образом, что игнориру-

ются все попытки установить оценку менее 1 и более 5. Точнее

говоря, в ограничении оговорен допустимый интервал оценок

(больше 0 и меньше 6).

При создании ограничения целостности система сначала про-

веряет, удовлетворяет ли текущее состояние БД новому ограни-

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

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

принимается и в дальнейшем используется системой.

Различают четыре типа ограничений целостности:

• ограничение целостности домена - им определяется

множество значений, из которых состоит домен. Особен-

ности ограничения такого рода заключаются в том. что

его имя должно совпадать с именем домена. Кроме того,

поскольку домены сами по себе не обновляются, то отпа;

дает необходимость предусматривать реакцию на нару-

шение ограничения. Более того, эти ограничения можно

устранить только за счет устранения самого домена;

• ограничение целостности атрибута - это фактически

определение домена, из которого берутся значения для

данного атрибута. Имя такого ограничения должно сов-

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

то есть с именем домена. Проверка осуществляется не-

медленно, и попытка выполнить действие, нарушающее

ограничение, будет отвергнута сразу же. Наконец, огра-

ничения целостности атрибута снимаются только с по-

мощью устранения самого атрибута;

• ограничение целостности отношения - правило, задаваемое

только для данного отношения БД. Ограничение целостно-

сти отношения всегда проверяется немедленно, то есть при

любой попытке модификации отношения осуществляется

контроль всех заданных условий. Действие такого ограни-

чения происходит в том случае, когда ограничение (задан-

ное логическим выражением) становится ложным;

• ограничение целостности БД - задается для двух или бо-

лее связанных между собой отношений. В отличие от

других ограничений, эта их разновидность помимо тра-

диционных частей обязательно должно содержать, по

Часть I. Теория баз данных

крайней мере, одно условие соединения отношений:

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

определенные в двух разных отношениях. Следовательно,

ограничение приводит к тому, что отношения будут свя-

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

веряются немедленно, а их выполнение откладывается до

конца выполнения транзакции. В качестве действия на

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

шинстве случаев используется завершение транзакции

оператором ROLLBACK.

Разновидностью традиционных ограничений целостности явля-

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

том. что достаточно часто возникает потребность рассмотреть не

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

ний из одного состояния в другое. Рассмотрим пример такого огра-

ничения для модифицированного отношения S (СТУДЕНТЫ), куда

добавлен атрибут KURS - курс, на котором учится студент:

СОЗДАТЬ ОГРАНИЧЕНИЕ ЦЕЛОСТНОСТИ RULE5

ДЛЯ ВСЕХ S(S.KURS >= S'.KURS)

НЕ ВЫПОЛНЯТЬ ПРИ НАРУШЕНИИ ПРАВИЛА

Такое ограничение накладывается на атрибут соответственно

S'.KURS - до и S.KURS - после выполнения обновления. Приве-

денный пример ограничивает курс, чвпжэтором учится студент

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

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

уменьшаться. Ограничения состояния и перехода используют

только для отношения или БД.

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

ности как БД в целом, так и ее элементов позволяют сформулиро-

вать и определить хоответствующие ограничения целостности, что.

в свою очередь, помогает решить проблему несовместимых данных.

Глава 1.5

Дополнительные аспекты

реляционной технологии

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

Механизм представлений (view) является мощным средством

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

Глава 1.5. Дополнительные аспекты реляционной технолоеии

рых пользователей за счет определения представления БД. Ре-

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

сом, а для пользователя ничем не отличается от базового отноше-

ния БД. Любая реализация представления должна гарантировать,

что состояние представляемого отношения точно соответствует

состоянию данных, на которых определено это представление.

Обычно вычисление представления производится каждый раз при

его использовании. Рассмотрим эти аспекты подробнее.

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

шения SP (Оценки), приведенного на рис. 1. 11

СОЗДАТЬ ПРЕДСТАВЛЕНИЕ VIEW1

ДЛЯ (SP.OCENKA >= 3) [NAME, SN, OCENKA]

При создании представления информация о нем записывается

в каталог БД под собственным именем (в нашем примере -

VIEW1), а у пользователя создастся полное впечатление того, что

в БД реально существует отношение с таким именем. При этом

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

нии - в этом есть его отличие от запроса к БД, на которое пред-

ставление очень похоже. В то же время запросы представляют

собой как бы "мгновенную фотографию" данных и при измене-

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

, В примере создается представление VIEW1, которое состоит

из трех атрибутов - NAME, SN и OCENKA, причем будут выби-

раться только те кортежи, для которых оценка будет больше или

равна 3 - грубо говоря, информация по успевающим студентам. С

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

но существующим.

Наличие представлений в БД необходимо для обеспечения логи-

ческой независимости данных. Если система обеспечивает физиче-

скую независимость данных, то изменения в физической структуре

БД не влияют на работу пользовательских программ. Логическая

независимость подразумевает тот факт, что при изменении логиче-

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

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

мы, связанные с ростом и реструктуризацией БД.

••, Очевидно, что с увеличением количества данных, хранимых в

БД, возникает необходимость в расширении за счет добавления но-

вого атрибута или отношения - это мы и будем называть ростом БД.

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

тается та же, но изменяется ее расположение, например, за счет

перегруппировки атрибутов отношений. Предположим, что от-