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

Анализ ситуации: Oracle Payroll

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

Решение, рекомендованное одним из авторов этой книги и принятое группой проектировщиков, заключалось в хранении правил расчета в виде PL/SQL-выражений в пользовательских таблицах. Необходимо также было реализовать метасловарь внутри приложения, чтобы выражение возраст служащего или уровень квалификации в формуле, можно было преобразовать в имя таблицы, имя столбца и первичный ключ. Во время выполнения соответствующая формула выбиралась и просматривалась на предмет того, какие переменные для нее необходимы. Эти переменные затем выбирались из базы данных. Формулу затем можно было выполнять как анонимный блок PL/SQL. В организации со сложными правилами начисления зарплаты для одного служащего пришлось бы выполнять более чем 100 формул, и в Oracle версии 6 единственный способ, которым можно было выполнять этот PL/SQL, заключался в выполнении его как анонимного блока.

С функциональной точки зрения данный подход был почти идеальным. I Мы говорим почти, так как из-за его сложности конечные пользователи! испытывали серьезные трудности с настройкой и ее часто приходилось выполнять силами собственных специалистов или с привлечением консультантов по зарплате. Кроме того, на ранних стадиях эксплуатации возникали большие проблемы с производительностью. В главе 14 мы описываем некоторые приемы, которые позволили достичь в данном случае приемлемой производительности.

Расширяемость, управляемая представлениялт

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

к сожалению, при этом существуют весьма реальные проблемы. Задача определения необходимых представлений может быть трудной, а во многих случаях создать эффективное представление вообще невозможно. Чтобы дополнить представление, пользователи не только должны обладать хорощи-ми знаниями SQL и структур данных, но и иметь как минимум некоторые DDL-привилегии. Наконец, даже при наличии этих расширений в последних версиях Oracle очень немногие представления, содержащие соединения, поддаются обновлению.

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

Расширяемость, управляемая процедурами и функциями

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

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

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

CREATE PACKAGE acc values AS CREATE PACKAGE acc values AS

FUNCTION max acno len RETURN NUMBER;

END; -- acc values

CREATE PACKAGE BODY acc values AS

FUNCTION max acno len RETURN NUMBER IS BEGIN

IF (SYSDATE >= Ol-JAN-98) THEN RETURN 10; ELSE RETURN 8; END IF; END;

END; - accjvalues body

С синтаксической точки зрения функции без аргументов ничем не отличаются от глобальных переменных пакета. В данном примере значение можно получить с помощью глобальной переменной пакета и конструктора в этом пакете (полагая, что в О часов 1 января 1998 года к базе данных не подключено ни одно приложение). Однако функциональный подход имеет более общий характер, так как позволяет заменять константу значением, требующим поиска в базе данных, несмотря на то, что во многих слугаях поиск в базе данных потребует наличия параметров. Они всегда должны передаваться как часть вызова функции или выбираться внутри функции путем вызова других функций. Например, acc values.curr acno возвращает номер счета, который в данный момент обрабатывает приложение.

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

Традиционный подход

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

Расширяемость: заключение

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

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