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

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

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

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

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

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

• письма;

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

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

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

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

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

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

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

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

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

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

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

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

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

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