Конструирование экранных форм для работы с данными

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

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

Для решения как этих, так и многих других проблем организации интерфейса ввода/ вывода данных в Access служит механизм электронных форм. Выберем вкладку Формы главного окна базы данных и нажмем кнопку Создать. Появляющееся диалоговое окно позволяет выбрать как таблицу или запрос, для работы с данными которых составляется форма, так и режим ее создания. В зависимости от квалификации пользователя и, естественно, сложности разрабатываемой формы можно либо воспользоваться встроенными программными надстройками-мастерами, либо сразу начать ее создание с нуля в режиме Конструктора. Весьма плодотворным также оказывается комбинированный подход: сначала используется соответствующий мастер, а затем полученная форма дополнительно дорабатывается в "ручном режиме". Проиллюстрируем сказанное на примере. Создадим форму для работы с таблицей Бумаги, воспользовавшись надстройкой Автоформа: в столбец. В результате получим окно следующего вида.

По умолчанию форме было предложено присвоить такое же имя, как и у таблицы, на основе которой она была создана, то есть Бумаги. Как видно из рис.17, при создании подписей полей программная надстройка использовала их соответствущие атрибуты, заданные при конструировании таблицы. Последнее не всегда бывает удобным с точки зрения интерфейса пользователя. Для устранения этих и подобных недостатков нам придется вернуться в режим изменения макета формы (кнопка Конструктор либо пиктограмма Вид на панели инструментов). На рис. 18 показана та же форма в режиме Конструктор. Технология процесса проектирования форм в среде Access сводится к добавлению управляющих элементов и изменению их свойств. В связи с этим при переходе в режим Конструктор >;на Экране по умолчанию появляются два дополнительных окна:
Окно Панель элементов, которое предназначено для выбора очередного добавляемого к проектируемой форме управляющего элемента. В конструктор форм Access встроены такие элементы управления, как надпись, поле, кнопка, флажок, переключатель, список, набор вкладок и др. Помимо этого к форме можно подключать специальные (дополнительные) элементы управления OLE, что значительно расширяет возможности развития интерфейса управления данными. Окно Свойств текущего элемента управления, предназначенное для изменения его атрибутов и настроек, например, цвета, шрифта, размера и т. п.

Рис.18. Форма Бумаги в режиме конструктора

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

1. Удалим фоновый рисунок: очистим свойство Рисунок, когда текущим выбранном элементом является вся форма.
2. Изменим цвет фона: выберем элемент ОбластьДанных и изменим у нее атрибут Цвет фона (рис.19).
3. Изменим внешний вид полей: выделим группу полей (поля выбираются с помощью мыши при нажатой клавише Shift) и в окне свойств изменим значение атрибута Оформление на Утопленное.
4. Отредактируем подписи полей и несколько изменим их расположение друг относительно друга: для этого достаточно воспользоваться возможностями визуального редактирования элементов.
5. Добавим разделительную линию после поля НаимБум (наименование бумаги): для этого следует воспользоваться элементом Линия.
6. Добавим кнопку завершения работы с формой: в большинстве ситуаций эту и подобные операции проще и удобнее делать в режиме мастера (нажата соответствующая кнопка на панели Элементы управления). В этом случае от пользователя требуется лишь ввести минимальное количество параметров для добавляемого программного компонента. Добавленную кнопку поместим в область Примечания формы.

Рис. 19. Окно свойств элемента управления

В результате отредактированная форма Бумаги примет вид, показанный на рис 20.

Рис. 20. Форма Бумаги после редактирования

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

- создание основной (главной) формы. Для этого осуществляются действия, аналогичные тем, которые выполнялись при создании формы Бумаги;
- создание подчиненных форм. Для этого в созданную главную форму добавляется элемент управления Подчиненная форма. При создании подчиненной формы в Access существует две принципиальные возможности:
- создать новую форму на базе некоторой таблицы или запроса;
- воспользоваться уже существующей формой, сделав ее подчиненной.
В данном случае созданы две новые подчиненные формы. Причем созданы они на базе специальных запросов. Такое решение позволяет выделить по отдельности из общей таблицы Заявки записи с заявками на продажу и на покупку. В частности, запрос ЗаявПрод, возвращающий выборку из заявок на продажу ценных бумаг, имеет структуру, показанную на рис.22. В качестве преимуществ такого подхода к организации источника данных для подчиненной формы следует отметить следующие моменты:
- во вспомогательном запросе достаточно просто обработать условие, идентифицирующее тип заявки (если объем заявки меньше нуля, то это заявка на продажу). Более того, для конечного пользователя в качестве объема заявки вместо отрицательных величин выводятся выглядящие более естественно положительные значения -1*[0бъем3аявки];
- данные выводятся отсортированными по возрастанию предлагаемых цен, что несомненно упрощает процесс работы с ними в экранной форме.

Рис. 22. Структура запроса ЗаявПрод (заявки на продажу)

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

Конструирование отчетов

Неотъемлемой функцией любых программных систем, так или иначе связанных с обработкой данных, является представление обетов по хранимой информации. Под отчетом традиционно понимается специальным образом структурированное представление хранимых данных, выводимое (как правило) на бумажный носитель. Перечислим принципиальные отличия отчетов от экранных форм, обусловившие выделение их в отдельный программный объект СУБД Access:
- во-первых, отчеты являются исключительно средством вывода информации;
- во-вторых, организация данных в отчетах предполагает возможность их сложного, многоуровневого структурирования;
- в-третьих, структура информации, выводимой в отчете, должна быть согласована со структурой носителя.

Например, разбиение отчета на страницы предполагает организацию вывода регулярных элементов в начале и конце каждого листа (колонтитулов), дублирование шапок таблиц и т.д. Также на внешний вид отчета значительное влияние оказывают параметры конкретного печатающего устройства, которое будет использовано для его вывода.
В то же время, к числу важных достоинств Access относится то, что идеология работы как с экранными формами, так и с отчетами максимально универсализирована. В частности, интерфейс режима конструирования макета отчета аналогичен режиму конструктора для экранных форм. Рассмотрим способы решения задач разработки отчетов, которые могут возникать в рамках описываем9Й нами программной системы управления торгами ценными бумагами. Простейшие отчеты, которые, скорее всего, будут необходимы пользователям системы, - это распечатанные списки бумаг и агентов. Для их создания можно воспользоваться надстройками Автоотчет в столбец или Автотчет ленточный. На рис. 24 показан макет отчета по агентам, созданный в режиме Автоотчет ленточный.

Рис.24. Отчет по агентам в режиме конструктора

Из рис. 24 видно, что в процессе конструирования в макет отчета могут быть добавлены те же самые управляющие элементы, что и при конструировании макета экранной формы. В то же время следует отметить, что структура отчета как объекта базы данных имеет свою специфику. Во-первых, она определяется уровнями группировки данных, выводимых в отчет, а во-вторых, содержит секции, соответствующие регулярным элементам, помещаемым в начале и конце каждого листа - верхнему и нижнему колонтитулам. Для задания уровней группировки данных используется функция меню Вид > Сортировка и группировка или же одноименная пиктограмма на панели инструментов Конструктор отчетов.
При работе с отчетами активно используются (это видно из рис. 24) встроенные переменные [Page] и [Pages], возвращающие номер текущей страницы отчета и общее, количество страниц в нем, а также функция NowQ, определяющая текущую дату и время по системному календарю.
Остановимся теперь на более сложном примере. Поставим задачу построить отчет, выводящий сведения о спросе и предложении по ценным бумагам с учетом их типа, то есть записи должны быть структурированы по следующим уровням:

- все бумаги;
- тип бумаги;
- агент;
- предложения агента по данной бумаге.
Также по каждому из уровней желательно предусмотреть вывод промежуточных итогов (или же соответствующих средних значений).
Информация для данного отчета (назовем его РаспределЗаявок) должна браться из различных таблиц, поэтому в качестве источника данных для него целесообразно использовать специально построенный запрос. Для наглядности приведем SQL-выражение, соответствующее данному запросу:

SELECT

IIf([ТипБум]= "1", "Акции", "Облигации") AS Тип,
Заявки.КодБум,
Бумаги.НаимБум,
Бумаги.Номинал,
Агенты.НаимАг,
IIf ([0бъем3аявки]<0,-1*[0бъем3аявки],0) AS
ОбъемПродажи,
IIf ([ОбъемЗаявки]<0,[ЦенаЗаявки],0) AS ЦенаПродажи,
IIf ([0бъем3аявки]>0,[0бъем3аявки],0) AS ОбъемПокупки,
IIf ([ОбъемЗаявки]>0, [ЦенаЗаявки],0) AS ЦенаПокупки,
FROM Бумаги
INNER JOIN (Агенты INNER JOIN Заявки ON Агенты.КодАг = Заявки.КодАг) ON
КодБум = Заявки.КодБум
ORDER BY IIf ([ТипБум]="1", "Акции", "Облигации"),
Бумаги.НаимБум;

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

Рис.25. Задание уровней группировки и сортировки

Важным этапом при создании многоуровневого отчета является задание уровней группировки выводимых данных. Это делается в окне, показанном на рис. 25, которое вызывается из меню Вид > Сортировка и группировка. Для каждого из заданных уровней группировки данных могут быть определены раздел типа Заголовок, выводимый в начале каждой группы, и раздел типа Примечание, формируемый, когда группа заканчивается.
Задачи получения средих и итоговых значений по группам данных решаются с помощью встроенных функций Sum() и Avg(). Например/для получения среднего значения цены продажи бумаги в соответствующем элементе управления свойство Данные содержится строка =Avg([ОбъемПродажи]), а для определения итогового спроса используется формула =Sum([ОбъемПродажи]* [ЦенаПродажи]). Распределение заявок

⇐ Предыдущая123456789Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: