step* NUMBER NOT NULL op CHAR(l) NOT NULL

CONSTRAINT rule element op CHECK (op IN (+, /, %

type CHAR(l) NOT NULL

CONSTRAINT rule element type CHECK (type IN (literal, column literal NUMBER

CONSTRAINT rule element literal CHECK

( (type = literal AND literal IS NOT NULL)

OR (type <> literal AND literal IS NULL))

colname VARCHAR2(30)

CONSTRAINT rule element colname CHECK

{ (type = column AND colname IS NOT NULL)

OR (type <> column AND colname IS NULL))

CONSTRAINT rule element pk PRIMARY KEY (rule#, step*)

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

Такую реализацию обьино осуществляют с помощью простого, написанного специально под конкретный проект генератора кода, выдающего динамический SQL или динамический PL/SQL. Скорее всего, интерпретатор PL/SQL использует центральный процессор менее интенсивно, чем динамический PL/SQL. Однако, если в больщинстве случаев будет генерироваться один и тот же анонимный блок, то вам окажет услугу разделяемая SQL-область. Это вряд ли будет иметь место, если значения столбцов вставляются в сгенерированный код буквально (как литеральная константа), и, к сожалению, очень немногие специальные генераторы кода поддерживают связанные переменные.

Гораздо более серьезной проблемой при таком подходе является то, что пользователей приходится учить, как сопровождать таблицу RULE ELE-MENTS, поскольку они, скорее всего, хотят выразить свое требование так, как это делается в электронной таблице. Возможно, легче научить их писать на SQL и PL/SQL, чем объяснить, как разлагать рещение на элементы. Если вы и впрямь хотите потратить деньги впустую, можете также написать компилятор, который будет брать выражения, записанные в какой-то изобретенной вами нотации, и преобразовывать их в таблицу RULE ELE-MENTS. Однако не забывайте, что вам уже пришлось написать программу преобразования элементов RULE ELEMENTS в SQL.

Надеемся, что этот материал ясно иллюстрирует невозможность использования такого метода на уровне проектов. И стоимость, и время реализации

заказа слишком велики, а гарантия, что пользователи смогут реализовать каждое расширение, которое может потребоваться, отсутствует.

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

Таблица Б. 1. Хранимый PL/SQL и SQL для реализации правил скидок <

formulae

Formula Params

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

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

полезным только при условии, что какой-то пользователь сможет аккуратно выполнить все этапы разработки этого мини-проекта, реализующего новое правило. Конечно, это:

анализ;

проектирование;

реализация;

тестирование;

внедрение.

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

Анализ сипи/ации: просктироваипс шраииых фор.ч

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

Одному из авторов недавно достался в наследство код, который вполне можно считать примером программной перегрузки . Каждое поле экранной формы размещалось в одном и том же месте и имело один и тот же размер. Войдя в редактор экранных форм, он сразу же воскликнул: Как странно выглядит эта экранная форма! После долгих поисков в коде стало очевидно, что размер и положение каждого поля изменялись динамически. Размер определялся размером соответствующего столбца базы данных, а код, выполняющий позиционирование полей, обеспечивал плотное их размещение. Название поля в экранной форме образовывалось из его имени. Этот код работал и давал определенное преимущество: можно было изменить размер столбца в базе данных или добавить в экранную форму новый столбец, не беспокоясь о размещении полей. Тем не менее, он работал очень медленно, и его невозможно было сопровождать. Структура и последовательность меню в это системе хранились в таблицах базы данных, а все меню создавались динамически, даже несмотря на то, что в самом инструментальном средстве имелась программа сопровождения меню. Настоящее расточительство!

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