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

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

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

Давайте сначала рассмотрим операторов ввода данных. Стоит потратить время и понаблюдать за тем, как они работают в действующей системе. Скорость, с которой они вводят данные, может быть просто впечатляющей! Если планируется заменить старую систему, то лучше сделать так, чтобы не повлиять на производительность труда операторов, особенно если их зарплата зависит от объема введенной информации. Вполне вероятно, что они пользуются архаичным символьным экраном, который им так полюбился за долгие годы работы. Тут вдруг приходим мы, этакие рыцари в сверкающих доспехах, и говорим: вам нужно не что иное, как ГПИ!

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

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

Вот общие принципы проектирования экранных форм:

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

Для отчетов существует широкий набор требований. Среди них часто встречаются не только новые, но и "старомодные" требования. Вот основные типы отчетов:

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

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

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

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

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

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

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

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

CREATE TABLE run_log
  ( run_id          NUMBER         NOT NULL /* из запроса */
  , task_name       VARCHAR2 (16)  NOT NULL /* возможно, требуется путевое имя */
  , command_line    VARCHAR2 (255) NOT NULL /* выдает список аргументов */
  , invoked_by      VARCHAR2 (30)  NOT NULL /* запрашивающий пользователь */
  , started_at      DATE           NOT NULL
  , ended_at        DATE
  , completion_code VARCHAR2(72)
  , rows_processed  NUMBER /* из управляющей таблицы */
  , cpu_used        NUMBER /* если есть */
  , memory_used     NUMBER /* " */
  , io_used         NUMBER /* " */
  , CONSTRAINT run_log_pk PRIMARY KEY (run_id)
  );

CREATE TABLE run_step
  ( run_id          NUMBER         NOT NULL /* из запроса */
  , stage           VARCHAR2 (16)  NOT NULL
  , rows_processed  NUMBER         NOT NULL
  , reached_at      DATE           NOT NULL
  , cpu_used        NUMBER /* если есть */
  , memory_used     NUMBER /* " */
  , io_used         NUMBER /* " */
  , CONSTRAINT run_step_pk
        PRIMARY KEY (run_id, stage, rows_processed)
  , CONSTRAINT run_step_pk
        FOREIGN KEY (run_id) REFERENCES run_log
  );

debug_flag = getenv ("DEBUG")
...
...
IF (*debug_flag == 'Y')
  {
    /* диагностика */
    fprintf(f_logfile, "About to call function lb_commit");
  }

IF l_degug.debug_mode THEN
-- диагностика
   DBMS_OUTPUT.PUT_LlNE("About to insert 100 new orders");
END IF;

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

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

UPDATE emp
SET sal = round(sal * (1 + :increase_pct/100);

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

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

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

INSERT TABLE live_orders
SELECT *
  FROM orders
 WHERE dead_flag IS NULL
UNRECOVERABLE;

INSERT TABLE live_orders
SELECT *
  FROM orders
 WHERE dead_flag IS NULL
/* UNRECOVERABLE нам нужна возможность восстановления */;

DECLARE
  CURSOR c1 IS
  SELECT deptno
       , dname
    FROM dept
   ORDER BY dname; -- благодаря этому журнал регистрации выглядит логичнее
BEGIN
  INSERT INTO run_log (id, start_at)
        VALUES ('XX',SYSDATE);
  FOR this_dept IN c1
LOOP
  INSERT INTO new_emp
  SELECT * FROM emp WHERE deptno = this_dept.deptno;
  INSERT INTO run_steps (id, step, ended_at)
        VALUES ('XX', this_dept.dname, SYSDATE);
  COMMIT;
END LOOP;
UPDATE run_log SET ended_at = SYSDATE
  WHERE id = 'XX';
COMMIT;
END;
/

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

В данном случае гораздо проще и эффективнее поместить условие (подразделение активно) в предложение WHERE.

Большинство из нас, конечно, сталкивались с "радостными" сообщениями вроде Unexpected condition has occurred ("Возникла непредвиденная ситуация") или даже 04FD63-unknown reference ("Неизвестная ссылка"). Мы ломали голову над тем, что они означают, и расстраивались, так как не знали, что именно сделали не так — если мы вообще делали что-нибудь не так. Тем не менее, мы считали ошибки такого типа неизбежным злом и обычно повторяли свои попытки. Однако сегодня пользователи требуют сообщений, по которым можно идентифицировать ошибки и на которые можно реагировать. К тому же, если два программиста будут обрабатывать одну и ту же исключительную ситуацию, не имея схемы, указывающей, как обрабатывать эту ситуацию, то вряд ли они сделают это одинаково и наверняка предложат разные тексты сообщения об ошибке. Отсюда и необходимость в общем и согласованном подходе.

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

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

Второй, еще более забавный, просчет заключается в регистрации действий приложения в базе данных для содействия устранению фатальной ошибки. Очевидно, что когда программа производит откат транзакции, то она выполняет откат и для всех элементов журнала регистрации. Решения просты: выполнить фиксацию вместо отката транзакции (разве можно без шуток?) или выполнять регистрацию в файлах, а не в базе данных. В версии 7.3 реализовать файловое решение несколько проще, чем в предыдущих, так как из PL/SQL теперь можно выполнять запись в файлы на сервере. Хотя безопасность при этом оставляет желать лучшего, поскольку эти файлы могут содержать в диагностической информации важные данные, на которые может случайно натолкнуться пользователь. В более ранних версиях регистрацию в файлы можно выполнять, посылая сообщения посредством DBMS_PIPE в выделенный серверный процесс, если обработка ошибок производится в основном через хранимые процедуры. Не поддавайтесь искушению использовать DBMS_ALERT, поскольку соответствующие механизмы имеют транзакционный характер, т.е. подвержены фиксации и откату.

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

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

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

Чтобы правильно организовать перемещение между окнами приложения, необходимо иметь полное представление о методах работы пользователей, особенно о документообороте. Мы настоятельно рекомендуем вам протестировать (отмакетировать) все интерфейсы между различными средствами, чтобы обеспечить их техническую реализуемость, оценить производительность и решить вопросы с лицензированием ПО. Если вы вызываете одно средство из другого, то столкнетесь со следующей проблемой: каждое из них потребует соединения с Oracle. Даже если это не превышает лицензионные лимиты, возможен значительный расход оперативной памяти на сервере БД.