Глава 10

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

УПРАВЛЕНИЕ БАЗАМИ ДАННЫХ В РЕАЛЬНОМ МИРЕ

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

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

Безопасность целесообразно рассматривать лишь в многопользовательской среде: наделение полномочиями других пользователей имеет смысл только тогда, когда они работают в системе совместно. Управление транзакциями позволяет системе баз данных решить проблему устранения коллизий при одновременном поступлении нескольких запросов от разных пользователей на получение одних и тех же данных (иногда эту функцию называют контролем совпадений (concurrency control)). Кроме того, управление транзакциями требуется системам управления базами данных для целей восстановления (recovery) - на случай сбоя программного обеспечения или носителя информации. Восстановление имеет большое значение как для однопользовательских, так и для многопользовательских систем.

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

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

Реляционные модели также часто критикуют за то, что они не обеспечивают надлежащих гарантий целостности данных. Однако в отличие от большинства критиков производительности, те, кто горячее всех обсуждает вопросы целостности, являются последовательными приверженцами реляционной модели. Как вы, наверное, помните из главы 1, д-р И.Ф. Кодд, автор реляционной модели, включил в свои двенадцать правил для систем реляционных баз данных весьма жесткие требования к целостности данных. Поэтому стандарт ANSI SQL-92 включает язык для определения некоторых ограничений на целостность, а большинство разработчиков усилили свои SQL с целью реализации повышенных требований к целостности.

БЕЗОПАСНОСТЬ ДАННЫХ

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

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

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

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

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

Идентификация пользователя и особые пользователи

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

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

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

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

Большинство многопользовательских систем управления базами данных распознают по крайней мере два вида пользователей, наделенных особыми привилегиями: суперпользователя, которого зачастую называют DBA (database administrator - администратор базы данных), или системным администратором, и владельцев объектов базы данных. Некоторые системы баз данных распознаигг дополнительные типы пользователей и устанавливают иерархию, в которой привилегии на выполнение различных команд назначаются пользователям в зависимости от их места в этой иерархии.

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

DBA, как правило, наделяется рядом особых привилегий; кроме того, на него возлагается ответственность за нормальное функционирование прикладного программного обеспечения базы данных. С точки зрения нашего обсуждения вопросов безопасности, DBA (в большинстве систем) располагает всеми полномочиями по всем объектам базы данных и для всех команд. Какие из этих разрешений DBA может передавать другим пользователям, зависит от каждой конкретной системы.

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

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

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

Команды GRANT и REVOKE

Фразы наделение полномочиями или назначение разрешений часто ассоциируются с обсуждением команд GRANT и REVOKE. В большинстве реализаций SQL вы не имеете права делать того, на что у вас нет явно выраженной санкции.

Команды GRANT и REVOKE указывают, каким пользователям можно выполнять определенные операции в отношении определенных таблиц, курсоров и столбцов. В некоторых версиях SQL разрешение на выполнение таких команд, как CREATE TABLE и DROP INDEX, также должно выдаваться явным образом (как правило, администратором базы данных).

Операции, выполнение которых контролируется с помощью GRANT и REVOKE, включают SELECT, UPDATE, INSERT, DELETE и REFERENCES. Объектами базы данных, к которым применимо разрешение на выполнение этих