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

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

Проектирование отчетов (машинограмм) состоит из следующих этапов:

• Проектирование содержания отчета;
• Проектирование формы отчета;
• Программное обеспечение формирования отчета.

Рассмотрим первый этап.

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

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

Основное содержание отчета составляют реквизиты файлов базы данных.

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

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

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

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

Таблица 2.6.

Перейдем к проектированию формы отчета.

Структура формы отчета, как и первичного документа, содержит заголовок, предметную часть и основание.

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

Предметная часть печатается в табличной форме, часто на нескольких страницах. Предметная часть не разлиновывается, а иногда и не разграфляется. Горизонтальными линиями выделяются лишь шапка таблицы и итоговые строки.

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

Современные СУБД (Access, Oracle, MS SQL Server и др.) содержат средства автоматизации проектирования меню, экранных форм и отчетов. Эти средства направлены на упрощение проектирования формы, а также автоматизируют программное обеспечение указанных компонентов пользовательского интерфейса.

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

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

Проектирование фактографических баз данных

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

Итоговая задача предпроектной стадии – разработка инфологической модели предметной области без привязки к конкретной СУБД.

Основой конкретной инфологической модели является модель «сущность-связь» (Entity-Relationship – ER-модель), описывающая взаимосвязь объектов (сущностей) предметной области.

Конечным этапом даталогического проектирования является описание логической структуры базы данных на языке описания данных конкретной СУБД. При даталогическом проектировании нужно учитывать типы моделей данных, поддерживаемые выбранной СУБД: иерархические, сетевые, реляционные.

!!!!!!!!!!

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

При ручном методе проектирования базы данных строится графическое изображение структуры базы данных.

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

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

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

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

Методы автоматизированного проектирования базы данных предусматривают использование CASE-средств.

Так, CASE-средство Silverrun американской фирмы Silverrun Technologies, Inc. содержит модуль концептуального (инфологического) моделирования данных (ERX-Entity Relationship Expert), который обеспечивает построение моделей данных «сущность-связь», не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать инфологическую модель данных посредством ответов специалистов в данной предметной области на вопросы о взаимосвязи данных. Результаты работы этого модуля передаются в модуль реляционного моделирования (RDM – Relational Data Modeler) для проектирования даталогической реляционной модели данных.