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

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

Их поддерживает еще меньшее число средств создания нерегламентированных запросов (а, скорее всего, именно здесь нам понадобится максимально эффективная поддержка).

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

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

Массивная выборка с помощью процедур поддерживается только в последних версиях PL/SQL.

Даже если синтаксис предикатов согласован, то процедура должна использовать динамический SQL внутри PL/SQL. Эта возможность доступна начиная с версии 7.1, но очень утомительна и трудна для программирования.

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

Впрочем, прежде чем окончательно разочароваться, вернемся к теме представлений и продемонстрируем, что начиная с версии 7.1 можно вызывать функции PL/SQL из SQL-предложений. В версии 7.1 в этой области существуют некоторые трудности (дефекты), но начиная с версии 7.2 можно смело использовать в SQL-предложениях вызовы пользовательских функций и заставлять эти функции выдавать SQL-запросы. Это иллюстрируется следующим примером;

CREATE VIEW v payroll AS SELECT id

, name

, dept

, payment period FROM payroll

WHERE v util.check access(dept code => dept) = Y WITH CHECK OPTION;

Здесь мы предполагаем, что пользователь ранее вызывал другую часть пакета vj.itil для регистрации своего идентификатора. Огромное преимущество этого метода состоит в том, что он не зависит от того, какое пользовательское имя применялось для подключения к базе данных. Полагая, что в этой главе уже достаточно много SQL-кода, мы не привели текст функции y ufil.check access, но хотим отметить, что, в зависимости от конкретных целей, он может быть как простым, так и сложным.

Резервное копирование

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

Стратегия резервного копирования

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

Саман сложная ситуация

Некоторые системы по самой своей природе требуют круглосуточной работы семь дней в неделю (так называемые системы 24x7). Любой простой обходится организации в большую сумму. В таких случаях необходимо вкладывать значительные средства в избыточные аппаратные средства. Если главная система отказывает, то резервная аппаратура немедленно принимает на себя управление. На работу пользователей этот переход влияет очень мало (если вообще влияет). В такой ситуации механизм резервного копирования должен обеспечивать непрерывную передачу транзакций с действующей машины на резервную, чтобы последняя всегда содержала актуальные данные. Эффективным, хотя и дорогостоящим способом такого резервного копирования является технология симметричной репликации, реализованная в Oracle? (см. главу 12). Если для организации приемлема потеря данных за последние несколько

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

Самая простая ситуация

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

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

Вопросы к пользователям:

В какое время суток и в какие дни недели система должна быть полностью доступна для работы?

Приемлемы ли нерегулярные периоды запланированного простоя?

Приемлемы ли периоды, когда доступ к системе ограничен?

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

Если данные получить можно, то каков объем данных, которые необходимо будет ввести повторно в случае серьезной неисправности?

Каковы приемлемые временные рамки для возврата системы в рабочее состояние в случае отказа?

Вопросы к обслуживающему персоналу:

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

Когда система будет (если будет) укомплектована обслуживающим и вспомогательным персоналом?

Какие еще приложения работают на этом же оборудовании или в этой же сети?

Существует ли план восстановления на случай аварии, и охвачена ли им данная система?

Имеются ли резервные аппаратные средства или аппаратные средства с запасом мощности?