7.3. Управление доступом к данным в многопользовательской СУБД.
Так как к базе данных должны обращаться много пользователей, то СУБД должна обеспечивать множественный доступ к базе данных. К сожалению, однопользовательские СУБД не подходят для коллективной работы. Рассмотрим проблему взаимного влияния на примере картотеки. Вы хотите использовать ту же информацию с которой в данный момент работает кто-то еще. Если вы хотите увидеть результаты работы другого пользователя, то придется подождать. Если же эти результаты на вашу работу не повлияют, вы можете скопировать данные. Возникает неудобство. Картотека иллюстрирует проблемы параллельного доступа, возникающие при попытке нескольких пользователей одновременно работать с базой данных.
В многопользовательских СУБД говорят о проблеме конкуренции — попытках многих пользователей одновременно выполнять операции с одними и теми же данными. Фактически, задача обеспечения параллельного доступа к данным — одна из наиболее важных и наиболее очевидных задач сервера базы данных. Сервер базы данных должен управлять информацией таким образом, чтобы при сохранении целостности данных пользователи ожидали выполнения работы другими пользователями минимальное время. Если сервер базы не может удовлетворить одну из этих целей, то пользователи сразу заметят последствия. Когда многие транзакции конкурируют за одни и те же данные, то пользователи столкнутся с плохой производительностью или получат неточные результаты.
Это проблемы, но ORACLE7 решает эти проблемы. Рассмотрим как это он делает.
Предотвращение разрушающих взаимных влияний с помощью блокировок данных.
Когда две конкурирующие за одни и те же данные операции вмешиваются в работу друг друга, это может привести к неточным результатам или потере целостности данных. Это называется “ разрушающее взаимное влияние”. Для предотвращения таких ситуаций при одновременном доступе пользователей к данным применяются блокировки. Аналогично тому как “вертушка” в проходной не позволяет проходить через нее одновременно двоим, блокировка данных предотвращает в многопользовательской СУБД разрушающее влияние. Существуют исключающие и разделяемые блокировки.
Заперев ячейку камеры хранения на вокзале, вы получаете на нее исключительное право. Никто не сможет в нее положить, пока вы ее не освободите. Если же вы хотите, чтобы этой ячейкой воспользовался ваш знакомый, то сообщаете шрифт. Аналогично блокирует данные и ORACLE7.
Когда пользователь пытается выполнять операции с данными, с которыми работает кто-то еще, ORACLE7 автоматически их блокирует и предотвращает возможность разрушающего влияния. Если это возможно (то есть не приведет к разрушающему влиянию), всегда использует разделяемую блокировку. Однако, если такая блокировка оставляет возможность разрушающего влияния, устанавливается исключающая блокировка запрашиваемых вашей транзакцией данных. Исключающая блокировка предотвращает возможность блокировать те же данные с помощью блокировки любого типа и за счет устранения параллельного доступа к одним и тем же данным обеспечивает их целостность.
Получение точных данных при высокой степени доступа: запросы, согласованное чтение и поддержка версий.
Предыдущие примеры показывают, как Огасlе7 для одного и того набора данных обрабатывает две различные транзакции обновления. А что происходит в случае запросов, содержащих только операции чтения? Как Огaсlе7 обрабатывает конкурирующие запросы и запросы с операциями обновления, возвращая точные результаты ?
В зтих ситуациях Оraсlе7 использует следующий подход. Во-первых, транзакция не требует блокировки строк для любого типа запросов. Это означает , что две транзакции могут давать одновременно в точности один и тот же запрос без какой-либо конкуренции за один набор строк. Отсутствие блокировок чтения означает также, что такой запрос не может блокировать обновления и наоборот.
Как же Огасlе7 возвращает точные результаты, если он не устанавливает блокировки для запросов? Можно было бы полагать, что без блокировки строки для запросов конкурирующее с запросом обновление может дать для запроса неточный набор результатов.
Огасlе7 может обойтись без блокировок строк для запросов при сохранении точности результатов благодаря механизму выделения версий. Для каждого запроса ORACLE7 возвращает затребованную версию данных на текущий момент времени. На момент получения запросы Огасlе7 обеспечивает согласованность каждой строки в результате запроса.
Сегменты отката.
Используя хранимые в сегментах отката данные, Огасlе7 может создавать для запроса согласованные по чтению копии (наборы результатов) данных. Сегмент отката (или сегмент отмены транзакций) — это область памяти на диске, которую Оraclе7 использует для временного хранения старых значений данных, обновляемых транзакцией удаления или обновления строк. Если пользователь отменяет транзакцию, то Оraclе7 считывает присвоенный транзакции сегмент отката и возвращает измененные ею строки в исходное состояние. Кроме того, Оrасlе7 использует сегмент отката в механизме выделения версий. Если запросу требуются данные, которые в процессе его выполнения изменяются, то Оrасlе7 с помощью данных сегмента отката генерирует согласованный по чтению копию данных (заданный момент времени). Все это происходит автоматически.
При обеспечении параллельного доступа множества пользователей и приложений к одной базе данных при адекватной производительности системы и полной точности разработчики могут не беспокоиться о сложных механизмах блокировки и ведения версий. Однако, если они хотят выжать из производительности приложения все возможное, то Оrасlе7 предусматривает средства управления, переопределяющие применяемые по умолчанию механизмы блокировки.
Обеспечение защиты данных.
Неужели кто угодно может войти в базу данных Оrасlе7 и начать использовать данные, читать табличную информацию и модифицировать ее? Конечно, нет! Если бы это было так, то пользователи могли бы видеть данные, которые для них не предназначаются (такие как заработная плата их начальника), а злоумышленники могли бы легко стереть или изменить данные по своему усмотрению (например, повысить зарплату самим себе). Одной из обязанностей сервера базы данных является обеспечение защиты всей информации СУБД. Независимо от того, хотите или нет защитить свои данные от глаз неуполномоченных пользователей или злоумышленников, защита является важной функцией базы данных. Для обеспечения защиты Оrасlе7 использует систему выборочного управления доступом зто означает, что администратор присваивает пропуска для всех зарегистрированных в базе данных пользователей и дает им полномочия на выполнение в базе данных конкретных операций с конкретными данными. Различные методы управления защитой Оraclе7 описываются в следующих разделах.
Предоставление пользователям доступа к базе данных.
Доступ к базе данных Огасlе7 очень напоминает доступ к телефонной банковской системе. Во-первых, вам нужно получить общий доступ к базе данных. Чтобы предоставить кому-либо доступ к базе данных Оraclе7, администратор должен зарегистрировать его и создать в базе данных нового пользователя (определив его имя). Для обеспечения защиты доступа пароль должен соответствовать имени этого нового пользователя. Для подключения к базе данных пользователь должен ввести и имя, и пароль. Нового пользователя создает, например, следующий оператор SQL:
CREATE USER safеdorow IDENTIFID BY p1e
Как показывает этот пример, администраторам следует выбирать осмысленные имена пользователей (например, объединив имя и фамилию). Однако пользователи должны выбирать сложные и не несущие никакого смысла пароли. Это затруднит их определение злоумышленниками.
После получения пользователем доступа к базе данных Оraclе7 операции его в этой СУБД ограничивают другие средства контроля доступа.
Расширение и ограничение полномочий.
Как и в случае круглосуточной телефонной банковской системы, вы можете выполнять лишь ограниченные операции. Например, вы можете проверить свой чековый и накопительный счет, но не можете сделать это для счетов других пользователей. То есть вы имеете полномочия только на просмотр информации, относящейся к вашим счетам.
Система защиты Оraclе7 очень напоминает защиту телефонной банковской системы. Администратор может управлять всеми операциями с базой данных и доступом к данным, в том числе тем, какие пользователи могут создавать таблицы и представления, какие—создавать и модифицировать табличные области, а какие — считывать и модифицировать различные таблицы и представления базы данных. Это делается путем предоставления и отмены различных полномочий или прав доступа. Приведем примеры применяемых для этого команд SQL GRANT и REVOKE:
GRANT CREATE SESSION, CREATE TABLE TO safd
REVOKE CREATE TABLE FROM allin
Оператор GRANT дает пользователю SAFD полномочия на подключение к базе данных (то есть на инициализацию сеанса с базой данных) и создание таблиц. Оператор REVOKE отменяет полномочия пользователя ALLIN на создание таблиц.
Огас1е7 имеет два широких класса полномочий, о которых рассказывается в следующих двух разделах: полномочия на объекты и системные полномочия.
Системные полномочия: управление расширенными системными операциями.
Системные полномочия — это расширенные и мощные полномочия, которые дают пользователю право на выполнение операции в масштабе базы данных. .Приведем пример:
Пользователь с системными полномочиями ALTER DATABASE может изменять физическую структуру базы данных, добавляя к ней новые файлы.
Пользователь с системными полномочиями DROP TABLESPACE может удалять любую табличную область (за исключением табличной области SYSTEM).
Пользователь с системными полномочиями SELECT ANY TABLE может опрашивать любую таблицу базы данных.
Это лишь некоторые из множества системных полномочий Oracle7. Поскольку системные полномочия — это очень широкие полномочия, администраторам следует предоставлять их только другим администраторам.
Полномочия на объекты базы данных: управление доступом к данным.
Полномочия на объекты управляют работой базы данных с конкретным ее объектом. (Объект — это нечто, находящееся внутри базы данных: таблица, представление, роль, процедура, пользователь и т.д.). Например, администратор может управлять тем, кто опрашивает таблицу CUSTOMER. Для этого он предоставляет полномочия SELECT на эту таблицу только конкретным пользователям. Существуют и другие полномочия на объекты, о которых можно получить информацию в руководстве по применению Оracle7.
Управление защитой с помощью ролей.
Управление защитой в большой базе данных клиент/сервер — сложная задача. Множество работающих в системе полномочий и пользователей могут требовать обозначений конкретных полномочий. При отсутствии административного инструментального средства управление защитой может стать настоящим кошмаром. К счастью, Оracle7 предлагает решение, облегчающее управление полномочиями в большой и сложной системе клиент/сервер, — это роли. Роль представляет собой набор соответствующих полномочий, которые администратор может коллективно предоставлять пользователям и другим ролям. С помощью ролей администратор может значительно упростить управление полномочиями.
Простое управление полномочиями — это не единственное преимущество использования ролей. Возможно, более важно то, что разработчики могут применять роли для динамического изменения домена (текущего набора) полномочий пользователей при работе их с различными приложениями. Путем простого разрешения соответствующей роли при запуске приложение может гарантировать, что все его пользователи будут иметь корректный домен полномочий.
Схемы в Oracle7.
При работе с Oracle7 вы часто будете сталкиваться с термином “схема”. Это слово может иметь самый разный смысл. Аналогично тому как администраторы могут физически организовать таблицы Oracle7 с помощью табличных областей, логически они организуют таблицы и представления реляционной базы данных с помощью схем. Схема - это логический набор родственных таблиц и представлений, а также всех других объектов базы данных. Например, при добавлении к СУБД клиент/сервер нового приложения администратору для организации таблиц и представлений, которые будет использовать приложение, следует создать новую схему. На рис.4 показано приложение для учета продаж.
Oracle7 на самом деле схемы базы данных не реализует. Просто администратор создает нового пользователя базы данных, который в свою очередь эффективно порождает заданную по умолчанию схему базы данных. При создании пользователем базы данных нового представления или таблицы этот объект по умолчанию становится частью схемы. Фактически, с учетом схем базы данных вы можете сказать, что пользователь владеет всеми объектами в своей заданной по умолчанию схеме. Реляционные СУБД с более продвинутой реализацией схемы позволяют пользователям переключаться между заданной по умолчанию схемой и другими схемами базы данных и выполнять различные операции, соответствующие текущей схеме. Возможно, в будущих версиях Oracle такие средства будут реализованы.
Обеспечение доступности необходимых пользователям данных.
В любой компьютерной программе пользователь не сможет получить доступ к файлу, пока не запустит экземпляр открывающего этот файл приложения. Например, чтобы открыть созданный с помощью текстового процессора отчет, пользователю сначала нужно запустить этот текстовый процессор, а затем открыть в нем файл отчета. Как поясняется в следующих разделах, работа в СУБД Oracle7 в чем-то аналогична.
Управление общей доступностью базы данных при запуске и останове.
Как и при запуске многопользовательской ОС, в Oracle7 никто не может использовать данные, пока администратор не запустит сервер и не сделает базу данных доступной. Это требует нескольких шагов. Во-первых, администратору нужно запустить экземпляр базы данных. Экземпляр—это набор буферов памяти (временных кэш-буферов данных в оперативной памяти компьютера) и процессов ОС (планируемых ОС задач или заданий), совместно обеспечивающих множественный доступ к базе данных Oracle7 . В ходе выполнения фазы запуска базы данных Oracle7 открывает различные файлы, необходимые для того, чтобы сделать базу данных доступной.
Чтобы база данных стала недоступной для обычных пользователей, администратор ее закрывает, размонтирует, отсоединяя от экземпляра, а затем останавливает экземпляр. В процессе останова Oracle7 закрывает составляющие базу данных файлы ОС. Сервер базы данных Oracle7 выполняет запуск экземпляра, чтобы сделать систему доступной для использования, и останавливает его, чтобы перевести ее в автономное состояние.
После запуска администратором экземпляра базы данных и ее открытия привилегированные пользователи могут подключиться к базе и создать новый сеанс. Сеанс с базой данных можно рассматривать как время, прошедшее между подключением пользователя к экземпляру базы данных и отключением от него. Сеанс в базе данных аналогичен сеансу у врача — когда вы входите в кабинет, сеанс начинается, а когда выходите — заканчивается.
Файлы параметров и запуск экземпляра.
Каждый раз, когда администратор начинает новый сеанс, Oracle7 для настройки конфигурации нового экземпляра считывает файл параметров инициализации. Например, администратор может установить разные параметры для управления размером буферов памяти экземпляра.
Управление частичным доступом к базе данных с помощью оперативно доступных и автономных табличных областей.
Администратор может также управлять доступностью информации в открытой базе на базе табличных областей. Если табличная область оперативно доступна, то привилегированные пользователи могут опрашивать и модифицировать таблицы в табличной области, Однако, если табличная область находится в автономном состоянии, использовать данные в табличной области не может никто.
Управление доступностью табличной области Oracle7 может оказаться для многих административных операций весьма полезным.
Если все табличные приложения находятся в табличной области, то администратор может эффективно остановить приложение, переведя его табличную область приложения в автономное состояние.
Предположим, что табличная область содержит архивные данные, полезные лишь в очень редких случаях, а администратору понадобилась память на диске для хранения данных других табличных областей. Чтобы освободить на диске некоторое место, администратор может перевести табличную область с архивными данными в автономное состояние, а затем удалить с диска архивные данные. Администратор должен позаботиться о том, чтобы создать резервные копии файлов данных автономной архивной табличной области и сохранить их в надежном месте. Освободившееся на диске место он может использовать для хранения информации других табличных областей.
Администраторы СУБД Oracle7 должны быть единственными пользователями, управляющими доступностью базы данных и ее табличных областей.
... прав хозяйствующих субъектов. Таким образом, проведенные исследования создания и ведения земельного кадастра в Екатеринбурге позволяют сделать вывод о том, что достигнута главная цель дипломной работы, земельный кадастр выступает инструментом регулирования социально-экономического развития города, является экономической основой городского развития, служит гарантом его дальнейшего процветания. ...
... ресурсов и в своей основе предполагает выделение и описание земельных участков, их территориальных границ с последующим картографированием и представлением количественных и качественных характеристик. Государственный земельный кадастр ведется в целях защиты прав собственников земли и создания объективной основы для налогообложения, обеспечения рационального использования и охраны земель, ...
... функционально-пространственного развития города, сформулирован методически обоснованный подход и предложена 10 перспективная модель кадастровой оценки земель в городском секторе экономики, способствующая развитию предпринимательства в сфере управления земельными отношениями. Результаты, выносимые на защиту. В ходе проведенных исследований получены и выносятся на защиту следующие результаты: ...
... основополагающим показателем как информационных качеств управленческих решений, так и качества информационного обеспечения государственного и муниципального управления в целом. 2.2 Информационное обеспечение управления МО в современных условиях Информационное обеспечение муниципального управления в современных условиях невозможно без использования современных информационных технологий, ...
0 комментариев