Ранние версии Oracle, как правило, страдали от чрезмерного трафика сетевых сообщений при работе в конфигурациях клиент/сервер, и в версии 7.0 было формально введено понятие составных (compound) вызовов. (Они в разных формах присутствовали в ряде ранних версий.) Значение этой поддержки рассматривается в главе И.

Другие существенные особенноспш

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

Первая - это расщиренная поддержка больших двоичных объектов {BLOB), что позволяет хранить в столбце до двух гигабайт данных. BLOB обеспечивает хранение элементов данных, например, графики и документов текстовых процессоров, без искусственного разбиения их на отдельные строки. Тем не менее, хотя в версии 7.0 и поддерживалась порционная выборка, весь BLOB нужно было вставлять сразу, вследствие чего для него фактически существовал лимит размера - где-то один мегабайт. Подпрограммы управления пространством базы данных не были настроены на обработку BLOB, что влекло за собой дополнительные трудности.

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

Версия 7.1

Основываясь на опыте эксплуатации версии 7.0, корпорация Oracle ввела в версии 7.1 ряд новых возможностей, ориентированных как на администраторов, так и на разработчиков. Эти средства оказались весьма важными для эффективного проектирования.

Динамический SQL в PL/SQL

Одним из направлений использования хранимых процедур PL/SQL в версии 7.0 была инкапсуляция прикладных функций - то есть клиентское приложение не должно было выдавать весь необходимый SQL-код, а могло для достюкения результата вызвать одну-единстве иную процедуру. Обнаружилось, что при обновлениях данных это работает хорошо, а при запросах - плохо, потому что вызывающему приложению всегда приходилось задавать критерии выбора. В результате процедура PL/SQL включала большое число SQL-запросов - на все случаи жизни. Чтобы решить эту проблему, в версии 7.1 был предложен механизм, позволяющий хранимым процедурам (и функциям) PL/SQL реализовать настоящий динамический SQL. Процедура может формировать свой SQL-запрос в VARCHAR2, а затем выполнять его

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

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

Поддержка множества триггеров

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

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

Функции PL/SQL внутри SQL

Как упоминалось выше, процессор PL/SQL практически не зависит от процессора SQL. В версии 7.1 можно вызывать функции PL/SQL из SQL. Например:

CREATE OR REPLACE FUNCTION cube (x IN NUMBER)

RETURN NUMBER IS

BEGIN

RETORN X ** 3;

END;

Это позволяет создавать на SQL-запросы наподобие следующего:

SELECT е.emp name , е.basic , t.gross FROM employees e

, emp year totals t WHERE e.emp# = t.empt AND t.year = 1997 AND t.gross >= СОВЕ(e.basic) ORDER BY t.gross/e.basic DESC;

Однако при этом возникает ряд проблем, поскольку в PL/SQL есть переменные, сохраняющие свое состояние в пределах сессии, и, кроме того, он может выдавать DML-команды. Oracle обеспечила механизмы для объявления уровня чистоты функции PL/SQL, т.е. степени возможных побочных эффектов, например таких, как внесение изменений в БД.

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

Тп&ттчные пространства только для чтения

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

Чтобы сократить время резервного копирования (и восстановления) баз данных с большими объемами статических данных, в версии 7.1 была реализована возможность установки для табличного пространства статуса только для чтения . После резервного копирования такого табличного пространства его больше не нужно копировать, потому что программа восстановления знает, что данные в этом пространстве не могли измениться с момента предыдущего резервного копирования, и не будет применять архивные журналы к файлам этого табличного пространства. Это идеальный вариант для больших таблиц архивных данных, и благодаря этой возможности на некоторых узлах объем регулярно копируемых данных сократился более чем на 90%. Здесь есть и недостаток: для того чтобы организовать раздел данных, которые могут быть объявлены как неизменяемые, мохсет потребоваться секционирование данных. Проектируя физическое размещение базы данных, вы можете разделить изменяющиеся и неизменяющиеся данные и поместить неизменяющиеся данные в табличное пространство только для чтения. Учтите это размещение при планировании стратегии резервного копирования с администратором БД.

Parallel Query Option !

Oracle всегда обладала достаточно масштабируемой архитектурой - в силу того, что у каждого пользователя, помимо фоновых процессов, выпол- няющих административные задачи и запись в БД, был выделенный серверный процесс. В симметричной многопроцессорной среде (СМП-системе) ; это позволяет распределить обработку, выполняемую для разных пользователей, на все центральные процессоры. Однако такая архитектура мало влияет на одиночный процесс, выполняющий большой и сложный SQL-запрос. Средство Parallel Query Option (PQO) в версии 7.1 позволяет разбивать запрос, требующий полного сканирования таблицы, и распределять его на несколько центральных процессоров. Для любого запроса, требующего полного сканирования таблицы, Parallel Query Option должно попытаться