Разработка запросов к базе данных

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

· поиск записи по условию (см. функцию меню Правка > Найти)

· сортировка записей в требуемом порядке (см. функцию меню Записи Сортировка)

· получение выборки записей таблицы, удовлетворяющей заданному условию, или, как еще говорят, задание фильтра для таблицы (Записи > Фильтр).

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

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

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

· Наименование бумаги

· Наименование агента

· Тип бумаги

· Номинальная стоимость пакета, вычисляемая как произведение номинальной цены на количество бумаг данного вида, которым обладает текущий агент

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

· описание структуры запроса (то есть указание того, какая информация должна выводиться в колонках таблицы запроса)

· задание порядка, в котором данные должны выводиться при выполнении запроса

· задание условий вывода записей в запросе

На рис. показано окно конструктора запроса.

Отметим, что колонки таблицы запроса содержат как поля таблиц, так и выражения, построенные на основе полей. В частности, последняя колонка (ей присвоено имя НоминСтоим) содержит выражение [Номинал]*[СуммОбъем], при этом записи будут выводиться отсортированными по типу бумаг.

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

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

На рис. показано окно конструктора в процессе создания запроса, выводящего информацию по суммарному спросу и предложению на ценные бумаги. Операция свертки нескольких записей из таблицы Заявки в одну результирующую запись, осуществляемая для каждого наименования бумаги, определяется командой Группировка, расположенной в строке Групповая операция. Для двух последующих колонок запроса (СуммСпрос и СуммПредл) определены операции суммирования по группе (Sum), расположенные в той же строке, а в строке Поле находятся производные выражения, суммы которых мы хотим получить в запросе. В соответствии с ранее принятыми соглашениями объем суммарного спроса определяется совокупностью всех записей по данной бумаге, имеющих положительное значение в поле ОбъемЗаявки, а объем суммарного предложения - записями, содержащими в данном поле отрицательную величину. Таким образом, для вычисления СуммСпрос необходимо просуммировать:

46. Отчеты, назначение, процесс создания.(1)

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

· во первых, отчеты являются исключительно средством вывода информации

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

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

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

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

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

При работе с отчетами активно используются (это видно из рис. 7.24) встроенные переменные [Page] и [Pages], возвращающие номер текущей страницы отчета и общее, количество страниц в нем, а также функция NowQ, определяющая текущую дату и время по системному календарю.

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

· все бумаги

· тип бумаги

· агент

· предложения агента по данной бумаге

Также по каждому из уровней желательно предусмотреть вывод промежуточных итогов (или же соответствующих средних значений).

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

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

=Sum([ОбъемПродажи]* [ЦенаПродажи])