Пользователи должны вводить код только один раз и не должны ничего запоминать или записывать при переходе от одной экранной формы к другой.

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

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

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

Проектирование отчетов

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

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

установленные законом (обязательные);

периодические (например, по состоянию на конец месяца, на конец года и т.д.);

отчеты на готовых бланках (например, счета-фактуры);

письма;

нерегламентированные и срочные;

графические;

мультимедийные со встроенными аудио- и видеоклипами.

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

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

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

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

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

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

Можно столкнуться с проблемой противоречивости производных данных, если во время работы программы извлечения выполняется обновление данных и для извлечения требуется более одного SQL-предложения. Конечно, вы всегда можете выбрать непротиворечивый набор данных, указав команду SET TRANSACTION READ ONLY. Однако такой подход вряд ли возможен, если вы задаете процесс извлечения, осуществляющий непосредственную загрузку данных в производные таблицы.

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

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

Если вы не можете предложить механизм отслеживания изменений, то должны обеспечить очистку производных таблиц перед каждым извлечением. Для этой цели идеально подходит SQL-оператор TRUNCATE...REUSE STORAGE, особенно если производные таблицы не индексированы (желательно избегать массовой загрузки в индексированные таблицы).

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

Примечание

Стратегия кооперативной блокировки работает лищь в случае, когда все пользователи (в данном случае - программы) играют по объявленным правилам. Стратегия обязательной блокировки работает даже тогда, когда некоторые пользователи пытаются игнорировать ее. Так, если один сеанс выдаст SQL-оператор LOCK TABLE contracts IN EXCLUSIVE MODE, то ни один из других сеансов не сможет вносить изменения в эту таблицу до тех пор, пока сеанс, установивщий эту блокировку, не выполнит фиксацию или откат транзакции.

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