Теория и практика построения баз данных (1088289), страница 85
Текст из файла (страница 85)
Ключевые курсоры (!геузег сцгзогз) соединяют в себе некоторые свойства статических и динамических курсоров. При открытии такого курсора для каждой строки в наборе записей сохраняется значение первцчного ключа. Когда приложение устанавливает курсор на некоторую строку, СУБД по ключу считывает текущее значение этой строки. Если приложение собирается обновить строк, року, которая была удалена другим курсором в этой же транзакции либо другой транзакцией, СУБД создает новую строку со старым значением ключа и помещает в нее обновленные значения (если, конечно, заполнены все требуемые поля).
Новые строки, вставленные други«ш курсорами данной транзакции или другими транзакциями, невидимы для клгочевого курсора. Данный курсор видит лишь сохраненные обновления п удаления, если только уровень изоляции транзакции не допускает «грязное» чтение. Динамический курсор (г!упапис сшзог) — это полнофункциональцьш курсор.
В се вставки, ооновления, удаления и изменения в порядке строк являются видимыми для динамического курсора. Как и в случае ключевых курсоров, если уровень изоляции транзакции не допускает «грязное» чтение, курсор может видеть только сохраненные изменения. Количество потребляемых ресурсов и необходимый объем обработки зависит от типа курсора, В общем случае, чем ниже находится тип курсора в табл. 11.1, тем выше расходы. Поэтому, чтобы увеличить производительность СУБД, разработчик приложения должен создавать курсоры, имеющие ровно столько возможностей, сколько требуется для выполнения поставленной задачи. Также весьма важно представлять, каким образом курсоры реализуются в конкретной СУБД и где они размещаются — ца сервере илн на клиенте, Иногда бывает выгоднее иметь динамический курсор па клиенте, чем статический — на сервере. Никакого общего правила сформулировать невозможно, поскольку производительность зависит от способа реализации курсора в СУБД п требований приложения.
Предостережение: если вы це укажете уровень изоляции транзакции плн тип курсора, СУБД будет использовать уровень пли тип, предусмотренный по умолчанию. Заданные по умолчанию параметры могут идеально подходить для вашего приложения, а могут оказаться п совершенно непригодными. Таким образом, хотя эти вопросы можно игнорировать, последствий избежать все равно не удастся. Изучите возможности вашей СУБД и используйте их рационально. Безопасность базы данных Защита безопасности базы данных заключается в том, что право выполнять некоторые действия дается только определенным пользователям н в определенное премя, Эта цель труднодостижима, и чтобы хоть в какой-то степени к ней приблизиться, команда разработчиков базы данных должна на стадии определения ~ ребований к проекту установить для всех пользователей права и обязанности по обработке (ргосезз!пя г!я)ггз апг! гезропзйй!!Г!сз).
Реализация этих требований безопасности может обеспечиваться соответствующими возможностями СУБД, и при их недостаточности — логикой прикладных программ. Права и. обязанности по обработке Таблица 11.2. Права и обязанности по обработке в галерее Удеу«П!Осе ууоги Запрос Агвет Запрос Снегогпег Вставка, Изменение, Тгапеаобоп Вставка, Запрос Продавцы ЗапРос Вставка, Вставка, Изменение, Вставка, Менеджеры Вставка, Изменение, Запрос Вставка, Изменение, Изменение, Запрос Вставка.
Запрос Вставка, Запрос Вставка, Системный администратор Измене»ме, Запрос, Удаление, Выделение прав, Модификация, Структуры Изменение, Запрос, Удаление, Выделение прав, Модификация, Структуры Изменение, Запрос, Удаление, Выделение прав Модификация, Структуры Изменение, Запрос, Удаление, Выделение прав, Модификация, Структуры !'ассмотрим для примера потребности галереи У1ег«К!г)яс, описанной в главе 10. У базы данных галереи есть трп типа пользователей: продавцы, менеджеры и системные адмигшстраторы. Продавцы могут регистрировать новых покупателей и вводить данные транзакций, изменять данные покупателей и запрашивать любые данные.
Оци не могут пп вводить данные о новом художнике цли произведении, нп удалять данные. Менеджеры имеют все права, которые предоставлены продавцам, но помимо пгго им разрешено вводить данные о новых художпгнсах и пропзведещшх, а также модифицировать данные транзакций. Хотя менеджеры имеют право удалять данные, в данном приложении им ие дается таких полномочий. Это сделано для того, чтобы исключить возможность случайной потери данных.
Системному администратору предоставлен неограниченный доступ к данным. Он может создавать, обновлять, читать и удалять любую информацию из базы данных. Администратор может также предоставлять права по обработке другим пользователям и менять структуру элементов базы данных — таблиц, индексов, хранимых процедур и т. п. Полномочпя всех пользователей базы данных галереи У!ец В!г)яе перечислены в табл. 11.2, 400 Глава 11.Многопользовательские базы данных Безопасность базы данных 401 В атой таблице полномочия даются не индивидуальным пользователям, а различным типам, или круппом пользователей (цэег ягоирэ).
Это является обычным, но не обязательным. Можно оыло бы указать, например, что пользователь по имени Бенджамин Франклин имеет определенные права по.обработке. Обратите также внимание, что прн работе с группамп необходимо иметь какой-то способ распределения пользователей по группам. Когда в систему входит пользователь по имени Мэри Смит, лолжен быть некоторый способ, позволяющий определить, к какой группе или группам относится данный пользователь. Мы обсудим это подроонее в следующем разделе. По ходу изложения мы использовали фразу «права и обязанности по обработке».
Эта фраза подразумевает, что любое право влечет за собой некотор)чо обязанность. Если, например, системный алминистратор удаляет данные транзакций, он отвечает за то, чтобы эти удаления не оказали неблагоприятного воздействия на функционирование галереи, целостность данных ее бухгалтер1ш и т. д. Обязанности по обработке не могут выполняться СУБД пли приложениями базы данных.
Эти обязанности возлагаются на пользователей и разъясняются им при обу тенин работе с системой. Данная тема относится к курсу системной разработки, и мы не будел1 здесь в нее углубляться. Повторим лишь, что любые права всегда сопровождаются обязанностями. Эти обязанности должны документироваться и выполняться. В соответствии с рис. 11.1, в задачи администратора базы данных входит управление правами и обязанностями по обработке. Это полразумевает, что права и обязанности могут меняться с течением времени. В холе работы с базой данных, по мере внесения изменений в приложения н в структуру СУБД возникает потребность во введении новых или изл~енении существующих прав и обязанностей.
Лдм~шистратор базы данных играет ведущую роль в обсуждении и реализации таких изменений. Когда права по обработке определены, необходимо их реализовать. Эта задача может быть возложена на различные элементы: операционную систему, сеть, луеЬ-сервер, СУБД цли приложение. В последующих двух разделах мы рассмотрим реализацию прав по обработке средствами СУБД и приложения. Описание остальных возможностей выходит за рамки данной книпс Обеспечение безопасности средствами СУБД Терминология, возможности и функшш безопасности СУБД варьируются от продукта к продукту.
В принципе, во всех СУБД суьцествует возможность ограничить выполнение определенных действий определенным временем и кругом пользователей. Общая модель безопасности СУБД представлена на рис. 11.9. Пользователю может быть назначена одна или несколько ролей, а роль может принадлежать одному или многим пользователям. Как пользователи, так и роли могут иметь много различных полномочий.
С каждым объектом (в широком Бухгалтерия может обновлять таблицу СОЗТОМЕН Элеанор Ву мажет запускать приложение МапспЕпо Джеймс Джонсон мажет менять все таблицы Пользователь Ричард Энт Элеанор Ву Джеймс Джонсон Полномочие Объект Таблица Представление Процедура Приложение Раль Бухгвпгерия Кассиры Менеджеры Неизвестная публика Рис. 11.9. модель безопасности СУБД Как правило, пользователи самостоятельно вводят свое имя н пароль, а в некоторых приложениях имя пользователя и пароль вводятся системой от лица пользователя. например, Ууг!пг!оцгз 2000 может непосредственно передать имя пользователя н пароль для входа в систему СУБД 91з1 Яегуег.
В других случаях имя пользователя и пароль предоставляются прикладной программой. В интернет-приложениях обычно определяется группа под названием вроде «!) пкполуп Рцййс» (неизвестная публика), и в эту группу записываготся анонимные пользователи, входящие в систему. Таким образом, компании типа Пе!! Сошршег избегают необходимости вводить каждого пользователя в систему пол собственным именем и паролем. Модели систем безопасности, используемые в Огас1е и БО1 Яегуег, изображены на рис. 11.10, 11.11, 11.12 и 11.13. Как вы можете видеть, обе они представляют собой варианты обшей модели, показанной на рис.
11.9, В соответстщш с моделью Огас!е на рис. 11.10, а, у каждого пользователя есть профиль, который указывает, какие системные ресурсы может задействовать данный пользователь. Г!ример определения профиля показан на рис. 11.10, б. Пользователю может бгнть назначено много ролей, и одна и та же роль может быть назначена многим пользователям. Каждый пользователь или роль имеет множество привилегий. смысле этого слова) связаны определенные полномочия. Каждое полномочие от~юсится к одному пользователю или группе и одному объекту. Когда пользователь входит в систему базы данных, СУБД ограничивает его действия полномочиями, определенными индивидуально для данного пользователя, а также для роли, назначенной данному пользователю. Определить, является ли пользователь тем, за кого он себя выдает, — задача, вообще говоря, сложная, Во всех коммерческих СУБД используется тот или иной вариант парольной зашиты, даже при том, что такой л1етод обеспечения безопасности можно легко обойти, если пользователи небрежно относятся к свопм личным иден- гпгрикатораль Безопасность базы данных 403 402 Глава 11.
Многопользовательские базы данных Есть два вида привилегий. Объектные привилегии определяют действия, кото- рые могут быть предприняты по отношениго к объектам базы данных — табли- цам, представлениям и индексам. Системные привилегии определяют возмож- ные действия с использованием команд Огас1е. Рио. 11.10. Безопасность в Огас!е; е — модель безопасности ОгасГе; б — определение профиля Пример такой системы безопасности представлен на рис. 11.11. Пользователю ОК даны роли СОМКЕСТ (соединение) и ВЕ500ВСЕ (ресурс). Просматривая список дальше, мы обнаружим, что с ролью СОММЕСТ связаны такие системные принплегии, как АСТЕВ 5Е5510й (смена сессии), СйЕАТЕ СС05ТЕМ (создание кластера) и другие, включая СКЕАТЕ ТАВСЕ (создание таблицы).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
