Министерство образования российской федерации московский государственный институт электроники и математики (Технический университет)
 Скачать 1.02 Mb.
|
|
автоматической и явной. Если запускается но- вая транзакция, СУБД сначала проверяет, не заблокирована ли другой транзак- цией строка, требуемая этой транзакции: если нет, то строка автоматически блокируется и выполняется операция над данными; если строка заблокирована, транзакция ожидает снятия блокировки. Явная блокировка, накладываемая ко- мандой LOCK (SQL), обычно используется тогда, когда транзакция затрагивает существенную часть отношения. Блокировки могут стать причиной бесконечного ожидания и тупиковых ситуаций. Бесконечное ожидание возможно в том случае, если не соблюдается очерёдность обслуживания транзакций и транзакция, поступившая раньше дру- гих, всё время отодвигается в конец очереди. Решение этой проблемы основы- вается на выполнении правила FIFO: "первый пришел – первый ушел". Тупиковые ситуации (deadlocks) возникают при взаимных блокировках транзакций, выполняющихся на пересекающихся множествах данных. На рис. 7.2 приведён пример взаимной блокировки трех транзакций T i на отноше- ниях R j R 1 R 2 R 3 T 1 T 3 T 2 B 1 B 2 B 3 Рис. 7.2. Взаимная блокировка трех транзакций Транзакция T 1 заблокировала данные B 1 в отношении R 1 и ждёт освобож- дения данных B 2 в отношении R 2 , которые заблокированы транзакцией T 2 , ожи- дающей освобождения данных B 3 в отношении R 3 , заблокированных транзак- цией T 3 , которая не может продолжить выполнение из-за транзакции T 1 Существует много стратегий разрешения проблемы взаимной блокиров- ки, в частности: 1. Транзакция запрашивает сразу все требуемые блокировки. Такой метод снижает степень параллелизма в работе системы. Кроме того, он не может применяться в тех случаях, когда заранее неизвестно, какие данные потре- – 64 – буются, например, если выборка данных из одной таблицы осуществляется на основании данных из другой таблицы, которые выбираются в том же за- просе. 2. СУБД отслеживает возникающие тупики и отменяет одну из транзакций. Этот метод требует дополнительных накладных расходов. 3. Вводится таймаут (time-out) – максимальное время, в течение которого транзакция может находиться в состоянии ожидания. Если транзакция нахо- дится в состоянии ожидания дольше таймаута, считается, что она находится в состоянии тупика, и СУБД инициирует её откат с последующим рестартом через случайный промежуток времени. 8. СПЕЦИАЛЬНАЯ ОБРАБОТКА БАЗЫ ДАННЫХ Большинство СУБД имеют в своем составе специальные средства обра- ботки БД, такие как контроль достоверности данных и обеспечение защиты данных от сбоев технических средств и несанкционированного использования. 8.1. Обеспечение целостности данных Обеспечение целостности данных касается защиты от внесения непред- намеренных ошибок и предотвращения последних. Оно достигается за счёт проверки ограничений целостности – условий, которым должны удовлетворять значения данных. Рассмотрим различные типы ограничений целостности: 1. Уникальность значения первичного ключа (PRIMARY KEY). 2. Уникальность значения комбинации ключевых полей: UNIQUE(A), где A – атрибут или комбинация атрибутов. (1,2 – структурные ограничения.) 3. Задание диапазона значений атрибута: BETWEEN min_value AND max_value 4. Задание взаимоотношений между значениями атрибутов: A @ B, где @ – оператор отношения (например, знак ">"). 5. Задание списка возможных значений: IN (value1, value2,… valueN) 6. Определение формата атрибута (например, даты или числа). 7. Определение домена атрибута на основе значений другого атрибута: множе- ство значений некоторого атрибута отношения является подмножеством значений другого атрибута этого или другого отношения. 3.-7. – ограничения на значения данных. 8. Ограничения на обновление данных (например, каждое следующее значение атрибута должно быть больше предыдущего). 9. Ограничения на параллельное выполнение операций (механизм транзакций) и проверка ограничений целостности после окончания внесения взаимосвя- занных изменений. – 65 – Реализация ограничений целостности возлагается на СУБД или выполня- ется с помощью специальных программных модулей. СУБД проверяет выпол- нение ограничений целостности при каждой операции модификации БД, если эта операция может нарушить целостность БД. Эта проверка проводится либо сразу после выполнения оператора DML, либо после выполнения всей транзак- ции. (По стандарту ISO этим можно управлять. По умолчанию проверка прово- дится после каждой операции DML). 8.2. Обеспечение защиты данных Термин защита данных означает предупреждение случайного или не- санкционированного доступа к данным, их изменения или разрушения со сто- роны пользователей или при сбоях аппаратуры. Защита включает в себя две ос- новные функции: обеспечение безопасности данных и обеспечение секретности данных. 8.2.1. Безопасность данных (обеспечение физической защиты) Под функцией безопасности данных подразумевается предотвращение разрушения или искажения данных при случайном доступе или в результате аппаратного сбоя. Обеспечение безопасности является внутренней задачей БД, поскольку связано с её нормальным функционированием, и решается на уровне СУБД. Цель восстановления БД после сбоя – обеспечить, чтобы результаты всех подтверждённых транзакций были отражены в восстановленной базе дан- ных, и вернуться к нормальному продолжению работы как можно быстрее, в то же время изолируя пользователей от проблем, вызванных сбоем. Наиболее типичными сбоями являются следующие: 1. Пользовательские ошибки. Ошибки пользователей могут потребовать восстановления базы данных в состояние на момент возникновения ошибки. Например, пользователь может случайно удалить таблицу. 2. Сбой предложения. Сбой происходит при логической ошибке предложения во время его обра- ботки (например, предложение нарушает ограничение целостности табли- цы). Когда возникает сбой предложения, результаты этого предложения (ес- ли они есть) должны автоматически отменяться СУБД, а управление – воз- вращаться пользователю. 3. Сбой процесса. Это ошибка в пользовательском процессе, обращающемся к БД, например, аварийное разъединение или прекращение процесса. Сбившийся процесс пользователя не может продолжать работу, тогда как СУБД и процессы дру- гих пользователей могут. Система должна откатить неподтверждённые тран- закции сбившегося пользовательского процесса и освободить все ресурсы, занятые этим процессом. 4. Сбой экземпляра базы данных (сервера). Этот сбой происходит при возникновении проблемы, препятствующей про- должению работы сервера. Сбой может быть вызван аппаратной проблемой, – 66 – такой как отказ питания, или программной проблемой, такой как сбой опе- рационной системы. Восстановление после такого сбоя может потребовать перезагрузки БД с откатом всех незавершённых транзакций. 5. Сбой носителя (диска). Эта ошибка может возникнуть при попытке записи или чтения файла, тре- буемого для работы базы данных. Типичным примером является отказ дис- ковой головки, который приводит к потере всех файлов на данном устройст- ве. Этот тип сбоя может касаться различных типов файлов, поддерживаемых СУБД. Кроме того, поскольку сервер не может продолжать работу, данные из буферов оперативной памяти не могут быть записаны в файлы данных. Таким образом, после некоторых сбоев система может восстановить БД автоматически, а ошибка пользователя или сбой диска требуют участия в вос- становлении человека (обычно, администратора). В качестве средств физической защиты данных чаще всего применяются резервное копирование и журналы транзакций. Резервное копирование означает периодическое сохранение на ВЗУ файлов БД в момент, когда их состояние является непротиворечивым. Резерв- ная копия не должна создаваться на том же диске, на котором находится сама БД, т.к. при аварии диска базу невозможно будет восстановить. Периодичность резервного копирования определяется администратором системы и зависит от многих факторов: объём БД, интенсивность запросов к БД, интенсивность об- новления данных и др. В случае сбоя (или аварии диска) БД восстанавливается на основе последней копии. Все изменения, произведённые в данных после по- следнего копирования, утрачиваются; но при наличии журнала транзакций их можно выполнить ещё раз, обеспечив полное восстановление БД. Общая стратегия восстановления БД заключается в переносе на рабочий диск резервной копии БД (или той её части, которая была повреждена), и по- вторном проведении всех транзакций, зафиксированных после выполнения данный резервной копии и до момента возникновения сбоя. В зависимости от типа повреждения данных восстановление может проводиться частично или полностью автоматизировано. Полная резервная копия включает всю базу данных (все файлы БД, в том числе, вспомогательные, состав которых зависит от СУБД). Частичная ре- зервная копия включает часть БД, определённую пользователем. В резервную копию входят только те блоки памяти, которые реально содержат данные (т.е. пустые блоки, выделенные под объекты БД, в резервную копию не входят). Резервное копирование может быть полным и инкрементным. Полная копия (level 0 backup) включает все блоки данных БД или табличной области. Инкрементная копия состоит только из тех блоков, которые изменились со времени последнего резервного копирования. Создание инкрементной копии происходит быстрее, чем полной, но возможно только после проведения полно- го резервного копирования. Обычно технология проведения резервного копирования такова: раз в неделю (день, месяц) осуществляется полное копирование; – 67 – раз в день (час, неделю) проводится обновление копии (инкрементное копи- рование). Журнал транзакций – это служебный файл (или группа файлов), в кото- ром хранятся записи обо всех завершённых транзакциях с привязкой по време- ни (системному или относительному). Рассмотрим структуру журнала транзак- ций на примере СУБД Oracle8 (рис.8.1). Группа журнала транзакций Группа регистрации Переключатель группы регистрации Группа регистрации Архивный журнал транзакций Переключатель группы регистрации Рис. 8.1. Структура журнала транзакций СУБД Oracle8 Каждая группа регистрации состоит из одного или нескольких идентич- ных файлов ОС, в которые записываются записи завершённых транзакций. Размер группы регистрации неизменен. Одна из этих групп является текущей. Когда она заполняется информацией, система автоматически вызывает пере- ключение на другую группу. После заполнения группа регистрации записыва- ется в архивный журнал транзакций, над которым проводится резервное копи- рование (обычно на внешнее по отношению к системе БД устройство хранения информации). Отключение режима архивирования журнала транзакций повы- шает производительность системы, но снижает уровень её защищенности. Для оптимизации регистрации изменений СУБД (в том числе, Oracle) может записывать в журнал информацию о незавершённых транзакциях, пред- видя из завершение. Более того, не дожидаясь подтверждения транзакции, СУБД переписывает в БД модифицированные блоки (при формировании кон- трольной точки). Поэтому в каждый момент времени в журнале транзакций и в БД может находиться небольшое число записей, модифицированных незавер- шёнными транзакциями. Эти записи помечаются соответствующим образом и не участвуют в восстановлении БД. С другой стороны, т.к. изменения сначала попадают в журнал транзакций и только потом в файл базы данных, в любой момент времени БД может не содержать блоков данных, модифицированных подтверждёнными транзакциями. Поэтому после сбоя могут возникнуть две потенциальных ситуации: Блоки, содержащие подтверждённые модификации, не были записаны в файлы данных, так что эти изменения отражены лишь в журнале транзакций. Следовательно, журнал транзакций содержит подтверждённые данные, ко- торые должны быть переписаны в файлы данных. Журнал транзакций и блоки данных, возможно, содержат изменения, кото- рые не были подтверждены. Изменения неподтверждённых транзакций во время восстановления должны быть удалены из файлов данных. – 68 – Для того чтобы разрешить эту ситуацию, СУБД применяет два этапа при восстановлении после сбоев: прокрутку вперед и прокрутку назад. 1. Прокрутка вперед. Это первый этап восстановления. Он заключается в применении к файлам данных всех изменений, зарегистрированных в журнале транзакций. Про- крутка вперед обрабатывает столько файлов журнала транзакций, сколько необходимо, чтобы привести БД в состояние на требуемый момент времени. Если вся необходимая информация повторения находится в активном жур- нале транзакций, СУБД выполняет этот шаг восстановления автоматически при запуске базы данных. После прокрутки вперед файлы данных содержат все как подтверждённые, так и неподтверждённые изменения, которые были зарегистрированы в журнале транзакций. 2. Прокрутка назад. Этот этап заключается в отмене всех изменений, которые не были подтвер- ждены. Для этого используются сегменты отката, информация из которых позволяет идентифицировать и отменить те транзакции, которые не были подтверждены, хотя и попали в журнал. 8.2.2. Защита от несанкционированного доступа Под функцией секретности данных понимается защита данных от пред- намеренного искажения и/или доступа пользователей или посторонних лиц. Для этого вся информация делится на общедоступные и конфиденциальные данные, доступ к которым разрешен только для отдельных групп лиц. Решение этого вопроса относится к компетенции юридических органов или администра- ции предприятия, для которого создаётся БД, и является внешней функцией по отношению к БД. Рассмотрим техническую сторону обеспечения защиты данных в БД. Бу- дем считать, что СУБД не должна разрешать пользователю выполнение какой- либо операции над данными, если он не получил на это права. Санкционирова- ние доступа к данным осуществляется администратором БД (АБД). В обязан- ности АБД входит: классификация данных в соответствии с их использованием; определение прав доступа отдельных групп пользователей к отдельным группам данных; организация системы контроля доступа к данным; тестирование вновь создаваемых средств защиты данных; периодическое проведение проверок правильности работы системы защиты, исследование и предотвращение сбоев в её работе. Для каждого пользователя система поддерживает паспорт пользователя, содержащий его идентификатор, имя процедуры подтверждения подлинности и перечень разрешённых операций. Подтверждение подлинности заключается в доказательстве того, что пользователь является именно тем человеком, за кото- рого себя выдаёт. Чаще всего подтверждение подлинности выполняется путём парольной идентификации. Перечень операций обычно определяется той груп- пой, к которой принадлежит пользователь. В реальных системах иногда преду- – 69 – сматривается возможность очень ограниченного доступа постороннего челове- ка к данным (доступ типа "гость"), не требующая идентификации. Парольная идентификация заключается в присвоении каждому пользо- вателю двух параметров: имени (login) и пароля (password). При входе в систе- му она запрашивает у пользователя его имя, а для подтверждения того, что это имя ввел его владелец, система запрашивает пароль. Имя выдаётся пользовате- лю при регистрации администратором, пароль пользователь устанавливает сам. При задании пароля желательно соблюдать следующие требования: длина пароля должна быть не менее 6-и символов; пароль должен содержать комбинацию букв и цифр или специальных зна- ков, пароль не может содержать пробелы; пароли должны часто меняться. Для обеспечения выполнения этих требований обычно применяются специаль- ные программы. В общем случае вопрос о доступе к БД разрешает специальная привиле- гированная программа на основании паспорта пользователя, набора прав и кон- кретных значений данных в базе. Управление доступом к данным осуществляется через СУБД, которая и обеспечивает защиту данных. Но такие данные вне СУБД становятся общедос- тупны. Если известен формат БД, можно осуществить к ней доступ с помощью другой программы (СУБД), и никакие ограничения при этом не помешают. Для таких случаев предусмотрено кодирование данных. Используются различные методы кодирования: перекомпоновка символов в кортеже, замена одних символов (групп символов) другими символами (группами символов) и т.д. Кодирование может быть применено не ко всему кортежу, а только к клю- чевым полям. Декодирование производится непосредственно в процессе обра- ботки, что, естественно, увеличивает время доступа к данным. Поэтому к коди- рованию прибегают только в случае исключительной важности конфиденци- альности данных. 8.2.3. Управление доступом к базе данных Предоставление прав доступа (привилегий) в системах, поддерживающих язык SQL, осуществляется с помощью двух команд: 1. GRANT – предоставление одной или нескольких привилегий пользователю (или группе пользователей). 2. REVOKE – отмена привилегий. Синтаксис этих команд зависит от СУБД. Для того чтобы упростить процесс управления доступом, многие СУБД предоставляют возможность объединять пользователей в группы или опреде- лять роли. Роль – это совокупность привилегий, предоставляемых пользовате- лю и/или другим ролям. Такой подход позволяет предоставить конкретному пользователю определённую роль или соотнести его определённой группе пользователей, обладающей набором прав в соответствии с задачами, которые на неё возложены. – 70 – 9. ПЕРСПЕКТИВЫ РАЗВИТИЯ ТЕХНОЛОГИИ БАЗ ДАННЫХ В настоящее время базы данных являются одной из одной из наиболее широко востребованных информационных технологий. Некоторые авторы ут- верждают [1], что появление баз данных стало самым важным достижением в области программного обеспечения. Системы баз данных коренным образом изменили работу многих организаций, и практически нет такой области дея- тельности, которую они бы не затронули. Ежегодный прирост объёмов продаж СУБД и вспомогательного программного обеспечения составлял в период 1995–2000 гг. более 25%. К числу важнейших перспективных направлений развития БД следует отнести следующие: 1. |