Экономия времени и сил благодаря совместному использованию операторов GRANT и REVOKE

Предоставление множеству пользователей множества полномочий на выбранные столбцы таблицы сопряжено с вводом большого количества кодов. Проанализируйте следующий пример. Вице-президент по продажам хочет, чтобы все те, кто занимается продажами, могли просматривать все содержимое таблицы CUSTOMER (клиент). Но обновлять, удалять или вставлять строки должны только менеджеры по продажам. И никто не должен обновлять поле CustID (идентификатор клиента). Соответствующие полномочия можно предоставить с помощью следующих операторов GRANT:

GRANT SELECT, INSERT, DELETEON CUSTOMERTO Tyson, Keith, David;GRANT UPDATEON CUSTOMER (Company, CustAddress, CustCity,CustState, CustZip, CustPhone, ModelLevel)TO Tyson, Keith, David;GRANT SELECTON CUSTOMERTO Jenny, Valerie, Melody, Neil, Robert, Sam,Brandon, MichelleT, Allison, Andrew,Scott, MishelleB, Jaime, Linleigh, Matt, Amanda;

А теперь попробуем упростить этот код. Все пользователи обладают полномочиями просмотра таблицы CUSTOMER. Менеджеры по продажам имеют на эту таблицу полномочия вставки и удаления, а также могут обновлять любой ее столбец, кроме CustlD. Поэтому тот же результат, что и в предыдущих операторах, можно получить более легким способом:

GRANT SELECTON CUSTOMERTO SalesRepsGRANT INSERT, DELETE, UPDATEON CUSTOMERTO Tyson, Keith, David;REVOKE UPDATEON CUSTOMER (CustlD)FROM Tyson, Keith, David;

Это та же защита, что и в предпоследнем примере, и для нее также надо использовать три оператора. Никто не может изменить данные в столбце CustlD. Полномочия INSERT, DELETE и UPDATE имеют только Тайсон, Кейт и Дэвид. Как видно, три последних оператора значительно короче, так как в них не приходится вводить имя каждого сотрудника отдела продаж и перечислять каждый столбец таблицы.

 

Защита данных

В этой главе…

· Как избежать повреждения базы данных

· Проблемы, вызванные одновременными операциями

· Решение этих проблем с помощью механизмов SQL

· Задание требуемого уровня защиты с помощью команды set transaction

· Защита данных, не препятствующая нормальной работе с ними

Каждый слышал о законе Мерфи, который формулируется обычно так: "Если какая-нибудь неприятность может случиться, она случается". Большую часть времени дела идут хорошо, и мы потешаемся над этим псевдозаконом. Временами нам даже кажется, что мы из тех немногих счастливчиков, над кем не властен один из основных законов мироздания. Даже если неприятности все-таки происходят, то мы обычно легко с ними справляемся.

Однако в очень сложной структуре вероятность возникновения проблем резко возрастает (как сказал бы математик, "приближенно описывается квадратичной зависимостью от сложности системы"). Поэтому большие программные разработки почти всегда появляются с опозданием и часто с немалым количеством невыявленных ошибок. Реальное многопользовательское приложение СУБД является большой и сложной структурой. Во время работы этого приложения существует большая вероятность сбоев. И хотя были разработаны специальные методы разработки приложений, направленные на то, чтобы свести последствия этих сбоев к минимуму, полностью исключить их невозможно. Это хорошая новость для профессионалов, занятых поддержкой баз данных, и специалистов по ремонту. Автоматика, скорее всего, никогда их не заменит.

Угрозы целостности данных

Киберпространство (в том числе ваша собственная сеть) может быть прекрасным местом для посещения, но для размещенных в нем данных это отнюдь не райский уголок. Данные могут быть повреждены или совсем испорчены самыми разными способами. В главе 5 рассказывалось о проблемах, возникающих в результате ввода неправильных данных, ошибок оператора, злонамеренного повреждения данных и одновременного доступа. "Неаккуратные" команды SQL и неправильно спроектированные приложения также могут повредить данные, и не нужно иметь много фантазии, чтобы представить, как это может произойти. Впрочем, данным угрожают и две очевидные опасности: нестабильность платформы и аппаратные сбои. В данном разделе как раз говорится об этих двух опасностях, а также о неприятностях, связанных с одновременным доступом.

Нестабильность платформы

Нестабильность платформы относится к таким неприятностям, которых даже быть-то не должно, но, увы, они существуют. Чаще всего она проявляется при запуске одного или множества новых и относительно непроверенных компонентов системы. Проблемы могут "притаиться" в новом выпуске СУБД, в новой версии операционной системы или же в новом оборудовании. Проявляются они обычно тогда, когда вы запускаете очень важное задание. В результате система блокируется, а данные – портятся. И вам больше ничего не остается, кроме как ругать последними словами свой компьютер и тех, кто его сделал, – особенно, если не осталось резервной копии.

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

Аппаратный сбой

Даже хорошо проверенное, высоконадежное оборудование иногда отказывает, отправляя данные на тот свет. Все материальное со временем изнашивается, даже современные полупроводниковые схемы. Если такой отказ происходит тогда, когда база данных открыта, то данные можно потерять, даже не осознавая этого. Опыт показывает – рано или поздно это произойдет. Уж если закон Мерфи и проявляет себя, так только в самое неподходящее время.

Одним из способов защитить данные от отказов оборудования является резервное копирование. Сохраняйте лишние копии всего подряд. Если ваша организация может себе это позволить, для обеспечения максимальной безопасности можно продублировать аппаратные средства вместе с их настройками с таким расчетом, чтобы, если потребуется, можно было быстро установить и запустить резервные копии базы данных и приложений на резервном оборудовании. Ну а если ограниченность в средствах не позволяет дублировать все подряд, включая расходы? Тогда, по крайней мере, делайте достаточно часто резервные копии вашей базы данных и приложений – причем настолько часто, чтобы вам после неожиданного отказа не пришлось заново вводить слишком много данных.

Другой способ избежать наихудших последствий аппаратных сбоев – использование транзакций. Это основная тема данной главы. Транзакция – это неделимая единица работы. Или транзакция выполняется целиком, или не выполняется вовсе. Если этот подход "все или ничего" кажется вам слишком радикальным, примите к сведению, что самые большие проблемы возникают в результате неполного выполнения операции с базой данных.

Одновременный доступ

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