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