Среда визуального программирования баз данных Access

Microsoft Access в настоящее время является одной из самых популярных среди настольных (персональных) программных систем управления базами данных Среди причин такой популярности следует отметить:
- высокую степень универсальности и продуманности интерфейса визуального программирования, который рассчитан на работу с пользователями самой различной квалификации. В частности, реализована система управления объектами базы данных, позволяющая гибко и оперативно переходить из режима конструирования в режим их непосредственной эксплуатации;
- глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав Microsoft Office, а также с любыми программными продуктами, поддерживающими технологию OLE;
- богатый набор визуальных средств разработки.
Нельзя не отметить, что существенной причиной такого широкого распространения MS Access является и мощная рекламная поддержка, осуществляемая фирмой Microsoft. В процессе разработки данного продукта на рынок представлялись его различные версии. Наиболее известными (в некотором смысле этапными) стали Access 2.0, Access 7.0 (он впервые был включен в состав программного комплекса MS Office 95). Позже появились версии Access 97 (в составе MS Office 97 и Access 2000 (в составе MS Office 2000). Самой свежей версией является MS Access 2010, входящая в комплект MS Office.
Очевидно, что отправной точкой в процессе работы с любой СУБД является создание файла (или группы файлов) базы данных. На рис. 4 показано окно, которое появляется после создания новой базы.

Основные разделы главного окна соответствуют типам объектов, которые может содержать база данных Access. Это Таблицы, Запросы, Отчеты, Макросы и Модули. Заголовок окна содержит имя файла базы данных. В данном случае он называется TradeTest.
Интерфейс работы с объектами базы данных унифицирован. По каждому из них предусмотрены стандартные режимы работы:
- Создать - предназначен для создания структуры объектов;
- Конструктор - предназначен для изменения структуры объектов;
- Открыть (Просмотр, Запуск) - предназначен для работы с объектами базы данных.
Важным средством, облегчающим работу с Access для начинающих пользователей, являются мастера - специальные программные надстройки, предназначенные для создания объектов базы данных в режиме последовательного диалога. Для опытных и продвинутых пользователей существуют возможности более гибкого управления ресурсами и возможностями объектов СУБД в режиме конструктора.
Специфической особенностью СУБД Access является то, что вся информация, относящаяся к одной базе данных, хранится в едином файле. Такой файл имеет расширение *.mdb. Данное решение, как правило, удобно для непрофессиональных пользователей, поскольку обеспечивает простоту при переносе данных с одного рабочего места на другое. Внутренняя организация данных в рамках mdl формата менялась от версии к версии, но фирма Microsoft поддерживала их ее вместимость снизу вверх, то есть базы данных из файлов в формате ранних вер сии Access могут быть конвертированы в формат, используемый в версиях боле поздних.

Основные этапы разработки базы данных в среде MS Access

Как нетрудно догадаться, процесс разработки конкретного программного приложения в среде Access в первую очередь определяется спецификой автоматизируемой предметной области. Однако для большинства из них можно выделить ряд типичных этапов. Это:
- разработка и описание структур таблиц данных;
- разработка схемы данных и задание системы взаимосвязей между таблицам
- разработка системы запросов к таблицам базы данных и (при необходимости их интеграция в схему данных;
- разработка экранных форм ввода/вывода данных;
- разработка системы отчетов по данным;
- разработка программных расширений для базы данных, решающих специфические задачи по обработке содержащейся в ней информации, с помощью иструментария макросов и модулей;
- разработка системы защиты данных, прав и ограничений по доступу.
Очевидно, что между перечисленными этапами существует большое количеств обратных связей, подразумевающих возврат к более ранним шагам, исходя из вновь открывшихся обстоятельств, которые невозможно было заранее учесть ил предвидеть.
Еще раз подчеркнем, что описанная последовательность этапов разработки баз данных в MS Access не является безусловным эталоном. Однако очень часто отклонения от нее свидетельствуют не столько об оригинальности хода мысли разработчика, сколько о погрешностях, допущенных им при планировании процесс разработки, или вообще об отсутствии у него какого-либо плана.

Экономические приложения СУБД MS Access

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

Создание таблиц и схем данных

Как уже отмечалось ранее, процесс разработки базы данных в СУБД MS Access начинается с задания описания структур таблиц. Рассмотрим этот процесс более подробно для таблиц примера, описанного в 2.3.
Итак, для начала нам необходимо создать описание таблицы Бумаги. Нажав кнопку Создать и выбрав в появившемся вслед диалоговом окне режим Конструктор, мы попадаем в окно, предназначенное для ввода описания структуры создаваемой таблицы. Оно изображено на рис. 5.
При создании баз данных, предназначенных для решения финансовых и экономических задач, процесс описания атрибутов полей в создаваемой таблице приобретает особое значение. Как видно из рис. 5, процесс описания атрибутов поля начинается с присвоения ему имени (идентификатора). Желательно, чтобы это имя было, с одной стороны, информативным, а с другой - кратким, что обеспечивает несомненные удобства при дальнейших манипуляциях с ним. Далее необходимо определить тип поля, что, очевидно, должно делаться, исходя из содержания тех данных, которые будут в нем храниться.

Рис. 5. Создание описания структуры таблицы Бумаги

Обратим внимание на тип Счетчик, присвоенный полю КодБум (код бумаги). Он означает, что СУБД будет самостоятельно помещать в это поле некоторое числовое значение для каждой вновь создаваемой записи таблицы, обеспечивая таким образом его уникальность.
Выбор типа данных в Access одновременно определяет набор дополнительных атрибутов соответствующего поля. В частности, поле ДатаЭм (дата эмиссии) имеет тип Дата и, как это показано на рис. 5, может иметь дополнительные атрибуты:
- формат поля, определяющий условия вывода данных из этого поля (по умолчанию);
" Маска ввода, определяющая условия ввода данных в поле;
- подпись - содержит расширенный заголовок;
- значение по умолчанию - позволяет указать значение, автоматически присваиваемое полю при создании новой записи. В нашем случае по умолчанию будет задаваться текущая дата, возвращаемая встроенной функцией Date();
- условие на значение - определяет требования к данным, вводимым в поле. Например, для выполнения требования, чтобы дата эмиссии предшествовала текущей, следует задать выражение <=Date();
- сообщение об ошибке - определяет текст сообщения, которое будет выводиться в случае нарушения заданного выше условия;
- обязательное поле - указывает, требует или нет поле обязательного ввода значения;
- индексированное поле - определяет индекс, создаваемый по данному полю. Индекс ускоряет выполнение запросов, в которых используются индексированные поля, и операции сортировки и группировки.
Основываясь на опыте проектирования различных баз, необходимо заметить, что не следует пренебрегать возможностями управления данными, которые открывают дополнительные атрибуты полей. Их грамотное и продуманное использование позволяет организовать централизованный и эффективный контроль за корректностью и целостностью данных.
На завершающем этапе процесса проектирования структуры таблицы происходит задание ключей и индексов. В первом случае достаточно выделить строки, которые должны составить ключевое выражение, и щелкнуть мышью по пиктограмме Ключ на панели инструментов (рис. 6). В таблице Бумаги роль уникального ключевого идентификатора выполняет поле КодБум.

Рис. 6. Панель инструментов конструктора таблиц

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

Рис. 8. Задание списка подстановки для поля

Эффективным методом решения задач контроля корректности входных данных является ограничение множества допустимых значений поля некоторым списком. Рассмотрим это более подробно на примере поля ТипБум (тип бумаги), которая, допустим, в рассматриваемой торговой системе может быть либо акцией, либо облигацией. Нетрудно заметить, что будет разумным присвоить типу Акция код 1, а типу Облигация - код 2. Это позволит существенно сэкономить место за счет уменьшения объема хранимой информации (особенно при большом количестве записей). Однако с точки зрения восприятия вводимой информации пользователем гораздо удобнее иметь дело с осмысленным текстом, чем запоминать, какие коды ему соответствуют.
Средством решения этой проблемы в Access является задание подстановочного списка значений для поля. Для этого следует выбрать вкладку Подстановка в окне Свойства поля, далее для свойства Тип элемента управления задать значение Список. На рис. 8 показано, как описать другие свойства элемента управления Список, чтобы организовать заполнение поля ТипБум требуемыми значениями.
После создания описания структуры таблицы можно перейти в режим непосредственного ввода в нее данных. Как уже говорилось, важным преимуществом интерфейса СУБД Access является продуманная гибкая система перехода от режима Конструктора к режиму ввода данных в таблицу (Режим таблицы). Такой переход можно осуществить, щелкнув мышью по пиктограмме Вид, расположенной на панели инструментов, либо выбрав функцию меню Вид > Режим таблицы.
На рис. 9 показано окно режима непосредственного ввода данных в таблицу Бумаги,

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

Создание схемы данных

Очевидно, что те действия, которые были подробно описаны для таблицы Бумаги, следует проделать и для остальных информационных массивов: Агенты, Портфели, Заявки. В результате мы получим систему таблиц базы данных TfadeTest. Подчеркнем, именно систему, так как находящиеся в них данные тесно и содержательно связаны между собой. Действительно, данные, находящиеся в поле Код агента таблицы Портфели, должны быть согласованы по типу и размеру с данными, находящимися в одноименном поле таблицы Бумаги. Более того, логика рассматриваемой задачи требует, чтобы, работая с информацией, относящейся к портфелю, мы могли одновременно обратиться к данным, характеризующим текущего агента, и т. д.
Механизм описания логических связей между таблицами в Access реализован в виде объекта, называемого Схемой данных. Перейти к ее созданию можно из панели инструментов База данных, доступной из главного окна. Альтернативный вариант вызова данного режима доступен через меню Сервис > Схема данных. Вид, который будет иметь схема данных для построенных на предыдущих шагах таблиц, представлен на рис. 10.

Интерфейс задания связей между полями в схеме основан на "перетаскивании" (перемещении при нажатой левой кнопки мыши) выбранного поля и "наложении" его на то поле, с которым должна быть установлена связь. Для связывания сразу нескольких полей их следует перемещать при нажатой клавише Ctrl. Выделяют несколько типов связей между таблицами в схеме. " Один к одному" (1:1) - одному значению поля в одной таблице соответствует только одно значение поля в другой. "Один ко многим" (1:?) - одному значению поля в одной таблице соответствует несколько (одно или более) значений в другой.
Важнейшей задачей, которую позволяет решать схема, является обеспечение логической целостности данных в базе. Так, в базе данных TradeTest нарушение целостности может возникнуть в случае удаления из таблицы Бумаги записей по тем бумагам, о которых существуют записи в таблицах Портфели или Заявки, в результате чего в их составе окажутся ссылки на "потерянные" коды. Очевидно, что это можно предотвратить, если каскадно удалить как записи из таблицы Бумаги, так и записи из связанных с ней таблиц. Такой эффект в Access может быть достигнут за счет задания определенных свойств для связи. Чтобы это сделать, необходимо щелкнуть кнопкой мыши, находясь на линии схемы, обозначающей связь. После этого появляется диалоговое окно, предназначенное для изменения свойств связи. Как видно из рис. 11, в рамках режима обеспечения целостности данных можно по выбранной связи задать как каскадное обновление значений для связанных полей, так и каскадное удаление связанных записей.

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

Появление даже очень небольшой таблицы мгновенно приводит к возникновению целого комплекса проблем, связанных с необходимостью обработки содержащихся в ней данных. К простейшим задачам обработки могут быть отнесены:
o поиск записи по условию (см. функцию меню Правка > Найти);
o сортировка записей в требуемом порядке (см. функцию меню Записи > Сортировка);
o получение выборки записей таблицы, удовлетворяющей заданному условию, или, как еще говорят, задание фильтра для таблицы (Записи > Фильтр).

Рис. 12. Контекстное меню работы с данными в таблице

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

Отметим, что колонки таблицы запроса на рис. 13 содержа? как поля таблиц, так и выражения, построенные на основе полей. В частности, последняя колонка (ей присвоено имя НоминСтоим) содержит выражение [Номинал]*[СуммОбъем], при этом записи будут выводиться отсортированными по типу бумаг.
По аналогии с принципами организации интерфейса работы с таблицами данных, при конструировании запросов также существует возможность оперативного перехода из режима Конструктор в Режим таблицы. При первом входе в Режим таблицы появляется приглашение сохранить вновь созданный запрос. В данном случае ему дано имя СтруктураПортфелей. На рис. 14 показано окно, в котором выводятся записи, соответствующие этому запросу.
Следует обратить внимание на исключительно важную роль механизма запросов в решении проблемы обеспечения минимальной избыточности сохраняемой в базе информации. Действительно, с их помощью мы можем получать произвольное количество виртуальных таблиц, представляющих в самых различных видах и разрезах единственную реально хранимую совокупность данных.

Рис. 14. Вывод данных по запросу СтруктураПортфелей

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

Рис. 15. Создание запроса с групповыми операциями

На рис. 15 показано окно конструктора в процессе создания запроса, выводящего информацию по суммарному спросу и предложению на ценные бумаги. Операция свертки нескольких записей из таблицы Заявки в одну результирующую запись, осуществляемая для каждого наименования бумаги, определяется командой Группировка, расположенной в строке Групповая операция. Для двух последующих колонок запроса (СуммСпрос и СуммПредл) определены операции суммирования по группе (Sum), расположенные в той же строке, а в строке Поле находятся производные выражения, суммы которых мы хотим получить в запросе. В соответствии с ранее принятыми соглашениями объем суммарного спроса определяется совокупностью всех записей по данной бумаге, имеющих положительное значение в поле ОбъемЗаявки, а объем суммарного предложения - записями, содержащими в данном поле отрицательную величину. Таким образом, для вычисления СуммСпрос необходимо просуммировать If[0бъем3аявки]>=0; [Цена3аявки]*[0бъем3аявки];0), а для вычисления СуммПредл - If[ОбъемЗаявки]<=0;-1* [Цена3аявки]*[0бъем3аявки];0).

ПРИМЕЧАНИЕ
Встроенная функция lf(bArg; Arg1; Arg2) возвращает значение аргумента Arg1, если значение аргумента bArg, который может содержать только логическую величину, является истинным (bArg = ИСТИНА), и значение Агд2, если bArg = ЛОЖЬ.

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

SELECT Бумаги.НаимБум,
Sum(IIf([ОбъемЗаявки]>=0,[Цена3аявки]*[0бъем3аявки],0))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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", "Акции", "Облигации"),
Бумаги.НаимБум;

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

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

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

Средства макропрограммирования в MS Access

Access, как и любая другая развитая программная система, обладает средствами разработки программных приложений, ориентированных на конечных пользователей. Эти средства базируются на инструментах двух типов: макросах и модулях. Само понятие макроса подразумевает наличие набора некоторых стандартных команд системы, или макрокоманд (допустим, таких, как открытие формы, выполнение запроса, вывод отчета), из которых и конструируется сам макрос.
Макрос может быть как собственно макросом, состоящим из последовательности макрокоманд, так и группой макросов. Группой макросов называют их набор, сохраняемый под общим именем. В некоторых случаях для решения, должна ли в запущенном макросе выполняться определенная макрокоманда, может применяться условное выражение.
Особый интерес вызывает механизм вызова макросов в Access. Для этого существует две принципиальных возможности:
вызов макроса по команде пользователя (либо непосредственно из раздела Макросы главного окна базы данных, либо с помощью меню или панели инструментов, с которыми он также может быть ассоциирован);
вызов макроса по некоторому системному событию (открытие или закрытие формы, изменение управляющего элемента и т. п.).
Весьма полезной представляется возможность организовать автоматическое выполнение ряда действий при открытии базы данных. Для этого они должны быть описаны в специальном макросе с именем Autoexec.
Возможности применения макросов при работе в среде СУБД Access можно наглядно продемонстрировать на следующем примере. Предположим, что в ранее созданную форму Бумаги мы хотим добавить процедуру дополнительного контроля вводимых значений дат эмиссии ценных бумаг, которая должна будет выдавать предупреждающее сообщение, если вводится слишком "ранняя" дата. Допустим, что к таковым относятся даты, предшествующие 1 января 1991 года.

Технически решение представляется удобным реализовать в виде макроса, вызываемого по событию "до обновления", ассоциированному с полем ДатаЭм в форме Бумаги.
На рис. 28 показан процесс разработки данного макроса (ему дано имя КонтрольДатаЭм). Из него видно, что макрос содержит три макрокоманды:
- Первая, ОстановитьМакрос - прерывает работу, если введена дата более поздняя, чем 1 января 1991 года.
- Вторая, ОстановитьМакрос - выполняется, если пользователь считает, что несмотря на сделанное предупреждение введенная дата является верной. Для вывода предупреждения используется встроенная функция MsgBox.
- Третья - отменяет событие ввода данных, если они после предупреждения признаются ошибочными.
Хорошим стилем разработки макросов является снабжение их комментариями, располагаемыми в соответствующей колонке.

На рис. 29 показана привязка разработанного макроса к событию "до обновления" поля ДатаЭм формы Бумаги.

Разработка программных приложений для MS Access

Модули, в отличие от макросов, являются более тонким и мощным средством создания программных расширений в среде Access, максимально приближающимся по своим функциональным возможностям к таким профессиональным инструментам, как Delphi, Visual Basic или Power Builder. Одновременно применение модулей требует от пользователя навыков и квалификации программиста, а также знания основных принципов объектно-ориентированного программирования.
Для программирования в Access используется процедурный язык Visual Basic для приложений (VBA - Visual Basic for Applications) с добавлением объектных расширений и элементов SQL. Сам процесс создания программных расширений в среде Access предполагает активное использование технологии объектно-ориентшрованного программирования (ООП). В основе ООП лежит идея "упакованной функциональности", в соответствии с которой программа строится из фундаментальных сущностей, называемых объектами. Каждый из объектов характеризуется набором свойств (англ, -property) и операций, которые он может выполнять (англ,- method). Реализация взаимодействий между объектами ложится на исполняющую cpеду того средства разработки, на котором пишется программа, и поэтому работа программиста в рамках технологии ООП сводится к созданию объектов, описанию их свойств и реакций на те иди иные внешние события.
Фундаментальным понятием ООП является класс. Класс - это шаблон, на основе которого может быть создан конкретный программный объект. Созданный объект в таком случае становится экземпляром класса. К основополагающим принципам ООП относятся:
" инкапсуляция - объединение свойств и действий, присущих объекту, в едином пакете и сокрытие подробностей их реализации от окружающего мира. Это означает, что пользовательский доступ к объекту допускается только через его свойства и методы;
" наследование - предусматривает создание новых классов на базе существующих, что дает возможность классу-потомку иметь (наследовать) все свойства класса-родителя;
" полиморфизм - (от греч. "многоликость") означает, что порожденные объекты обладают информацией о том, какие методы они должны использовать в зависимости от того, где они находятся в цепочке наследования;
" модульность - объекты заключают в себе полное определение их характеристик, никакие определения методов и свойств объекта не должны располагаться вне его, что делает возможным свободное копирование и внедрение одного объекта в другие.
Многие программные объекты в Access совпадают с физическими объектами базы данных, такими как таблицы, формы, отчеты. Для названия составных объектов, которые включают в себя совокупность более простых объектов, используется термин семейство. Например, объект отчет входит в семейство отчеты. Помимо "видимых" объектов существует и большое количество "скрытых" объектов, управлять которыми можно только из программных приложений.
В Access существуют два типа модулей: стандартные и модули класса.
Стандартные модули содержат процедуры и функции, которые могут быть вызваны из любого окна базы данных. Как правило, такие модули содержат программный код универсального характера, предназначенный для применения в различных местах текущего приложения или даже в различных приложениях.
Модули класса используются, для создания новых классов объектов. При создании конкретного объекта, являющегося экземпляром такого класса, любые процедуры, определенные в модуле, становятся свойствами и методами этого объекта.
Модули форм и модули отчетов являются модулями класса, связанными с определенной формой или отчетом. Заметим, что в ранних версиях Access они являлись единственно возможным инструментом объектно-ориентированного программирования. Эти модули содержат процедуры обработки событий, запускаемых в ответ на их возникновение в форме или отчете. Процедуры обработки событий используются для управления поведением формы или отчета и их откликом на события, например такие, как нажатие кнопки.
Важнейшей областью применения объектно-ориентированного программирования в Access является программирование доступа к данным. Для решения данной задачи фирмой Microsoft был разработан специальный интерфейс - ОАО (Data Access Objects). DAO - это набор объектных классов, которые моделируют структуру реляционной базы данных. Они обеспечивают свойства и методы, которые позволяют выполнять такие операции, как создание базы данных, определение таблиц и индексов, задание связей между таблицами, формирование запросов и отчетов и т. п. Существенным достоинством объектной модели ОАО является ее универсальный характер: она доступна для большинства средств разработки программного обеспечения, поддерживаемых Microsoft, в частности, для Visual Basic. Классы объектов доступа к данным организованы по иерархической схеме. На ее вершине находится объект DbEngine, представляющий собой ядро базы данных. Далее следуют объекты, отвечающие за управление сеансами доступа пользователя к данным, - Workspace (от англ, "рабочая область"). Каждая рабочая область включает один или несколько объектов класса база данных - Database, а они, в свою очередь, содержат семейства объектов таблиц (TableDef), запросов (QueryDef), наборов записей (RecordSet) и т. д.
В заключение раздела, посвященного модулям, отметим, что мы сознательно не затрагиваем собственно вопросы теории и практики создания программ на VBA в среде Access, так как они являются весьма обширными. В случае необходимости читатели могут ознакомиться с ними в специальных профессиональных изданиях и руководствах.

Знаете ли Вы, что cогласно релятивистской мифологии "гравитационное линзирование - это физическое явление, связанное с отклонением лучей света в поле тяжести. Гравитационные линзы обясняют образование кратных изображений одного и того же астрономического объекта (квазаров, галактик), когда на луч зрения от источника к наблюдателю попадает другая галактика или скопление галактик (собственно линза). В некоторых изображениях происходит усиление яркости оригинального источника." (Релятивисты приводят примеры искажения изображений галактик в качестве подтверждения ОТО - воздействия гравитации на свет)
При этом они забывают, что поле действия эффекта ОТО - это малые углы вблизи поверхности звезд, где на самом деле этот эффект не наблюдается (затменные двойные). Разница в шкалах явлений реального искажения изображений галактик и мифического отклонения вблизи звезд - 10¹¹ раз. Приведу аналогию. Можно говорить о воздействии поверхностного натяжения на форму капель, но нельзя серьезно говорить о силе поверхностного натяжения, как о причине океанских приливов.
Эфирная физика находит ответ на наблюдаемое явление искажения изображений галактик. Это результат нагрева эфира вблизи галактик, изменения его плотности и, следовательно, изменения скорости света на галактических расстояниях вследствие преломления света в эфире различной плотности. Подтверждением термической природы искажения изображений галактик является прямая связь этого искажения с радиоизлучением пространства, то есть эфира в этом месте, смещение спектра CMB (космическое микроволновое излучение) в данном направлении в высокочастотную область. Подробнее читайте в FAQ по эфирной физике.

Системы управления базами данных