ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.11.2023
Просмотров: 187
Скачиваний: 5
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
71
Рисунок40 – Задание списка подстановки для поля
На рис. 41 показано окно режима непосредственного ввода данных в таблицу Бумаги,
Рисунок41 – Ввод данных в таблицу Бумаги
7.2.3 Создание схемы данных
Очевидно, что те действия, которые были подробно описаны для таб- лицы Бумаги, следует проделать и для остальных информационных масси- вов: Агенты, Портфели, Заявки. В результате мы получим систему таблиц базы данных TradeTest. Подчеркнем, именно систему, так как находящиеся в них данные тесно и содержательно связаны между собой. Действительно, данные, находящиеся в поле Код агента таблицы Портфели, должны быть согласованы по типу и размеру с данными, находящимися в одноименном поле таблицы Бумаги. Более того, логика рассматриваемой задачи требует, чтобы, работая с информацией, относящейся к портфелю, мы могли одно- временно обратиться к данным, характеризующим текущего агента, и т. д.
72
Механизм описания логических связей между таблицами в Access реа- лизован в виде объекта, называемого
1 2 3 4 5 6 7 8 9 ... 12
Схемой данных. Перейти к ее созда- нию можно из панели инструментов База данных, доступной из главного окна. Альтернативный вариант вызова данного режима доступен через меню
Сервис > Схема данных. Вид, который будет иметь схема данных для по- строенных на предыдущих шагах таблиц, представлен на рис. 42.
Рисунок42 – Создание схемы данных
Интерфейс задания связей между полями в схеме основан на «перетас- кивании» (перемещении при нажатой левой кнопки мыши) выбранного поля и «наложении» его на то поле, с которым должна быть установлена связь.
Для связывания сразу нескольких полей их следует перемещать при нажатой клавише Ctrl. Выделяют несколько типов связей между таблицами в схеме.
«Один к одному» (1:1) – одному значению поля в одной таблице соответст- вует только одно значение поля в другой. «Один ко многим» (1:М) – одному значению поля в одной таблице соответствует несколько (одно или более) значений в другой.
Важнейшей задачей, которую позволяет решать схема, является обес- печение логической целостности данных в базе. Так, в базе данных TradeTest нарушение целостности может возникнуть в случае удаления из таблицы Бу-
маги записей по тем бумагам, о которых существуют записи в таблицах
Портфели или Заявки, в результате чего в их составе окажутся ссылки на
«потерянные» коды. Очевидно, что это можно предотвратить, если каскадно удалить как записи из таблицы Бумаги, так и записи из связанных с ней таб- лиц. Такой эффект в Access может быть достигнут за счет задания опреде- ленных свойств для связи. Чтобы это сделать, необходимо щелкнуть кнопкой мыши, находясь на линии схемы, обозначающей связь. После этого появля-
73 ется диалоговое окно, предназначенное для изменения свойств связи. Как видно из рис. 4, в рамках режима обеспечения целостности данных можно по выбранной связи задать как каскадное обновление значений для связанных полей, так и каскадное удаление связанных записей.
Рисунок 43 – Задание свойств связи
Появление даже очень небольшой таблицы мгновенно приводит к возник- новению целого комплекса проблем, связанных с необходимостью обработки содержащихся в ней данных. К простейшим задачам обработки могут быть отне- сены:
поиск записи по условию (см. функцию меню Правка>Найти);
сортировка записей в требуемом порядке (см. функцию меню За-
писи>Сортировка);
получение выборки записей таблицы, удовлетворяющей заданному условию, или, как еще говорят, задание фильтра для таблицы (За-
писи>Фильтр).
7.2.4 Разработка запросов к базе данных
Перечисленные функции также доступны из контекстного меню, акти- визирующегося по нажатию правой клавиши мыши (рис. 44). Данный интер- фейс представляется особенно удобным при практической работе с таблица- ми Access. Однако этих возможностей явно недостаточно для задач обработ- ки данных, которые возникают в реальных экономических приложениях. Для их решения в СУБД Access служит развитой инструментарий запросов к базе данных. Понятие запроса в Access употребляется в расширительном плане.
Его следует трактовать как некоторую команду на выбор, просмотр, измене- ние, создание или удаление данных. Также нельзя не отметить значение за- просов для решения задач анализа данных.
Наиболее распространенным и, если так можно выразиться, естествен- ным типом запросов является запрос на выборку. Данный тип, собственно говоря, и устанавливается по умолчанию для вновь создаваемого запроса.
74
Рисунок 44– Контекстное меню работы с данными в таблице
При работе с системой данных очень часто возникает задача соедине- ния данных из различных связанных таблиц в одну. Так, в рамках нашего примера естественной представляется проблема построения таблицы, содер- жащей информацию по содержанию портфелей и имеющей следующую структуру:
Наименование бумаги;
Наименование агента;
Тип бумаги;
Номинальная стоимость пакета, вычисляемая как произведение номинальной цены на количество бумаг данного вида, которым об- ладает текущий агент.
Для ее решения следует перейти к разделу Запросы главного окна базы данных, нажать на кнопку Создать и выбрать режим Конструктор. Процесс создания запроса начинается с выбора таблиц (в том числе и Других запро- сов), на основе которых строится запрос. В дальнейшем состав этого набора может быть изменен. Наш запрос будет построен на основе данных таблиц
Портфели, Агенты и Бумаги. Заметим, что при добавлении таблиц к запросу по умолчанию добавляются и связи между ними, заданные в схеме. В про- цессе формирования запроса можно выделить ряд принципиальных этапов: описание структуры запроса (то есть указание того, какая информация должна выводиться в колонках таблицы запроса);
задание порядка, в котором данные должны выводиться при вы- полнении запроса;
задание условий вывода записей в запросе.
На рис. 5показано окно конструктора запроса.
Отметим, что колонки таблицы запроса на рис. 45 содержат как поля таблиц, так и выражения, построенные на основе полей. В частности, по- следняя колонка (ей присвоено имя НоминСтоим) содержит выражение
75
[Номинал]*[СуммОбъем], при этом записи будут выводиться отсортирован- ными по типу бумаг.
Рисунок 45 – Окно конструктора запроса
По аналогии с принципами организации интерфейса работы с таблица- ми данных, при конструировании запросов также существует возможность оперативного перехода из режима Конструктор в Режим таблицы. При первом входе в Режим таблицы появляется приглашение сохранить вновь созданный запрос. В данном случае ему дано имя Структура Портфелей. На рис. 46 показано окно, в котором выводятся записи, соответствующие этому запросу.
Рисунок46 – Вывод данных по запросу Структура Портфелей
Следует обратить внимание на исключительно важную роль механизма запросов в решении проблемы обеспечения минимальной избыточности со- храняемой в базе информации. Действительно, с их помощью мы можем по- лучать произвольное количество виртуальных таблиц, представляющих в са- мых различных видах и разрезах единственную реально хранимую совокуп- ность данных.
76
Рассмотрим еще один случай применения запросов для решения задач обработки данных. Достаточно типичной является проблема группировки данных по тому или иному признаку. Например, в рамках построенной нами базы данных может быть поставлена задача определения суммарного (или среднего) спроса и предложения по ценным бумагам, циркулирующим на рынке. Решить ее можно, построив запрос, содержащий групповые операции.
Для активизации возможности их задания в окне Конструктора запросов необходимо включить функцию меню Вид>Групповые операции.
Рисунок 47 – Создание запроса с групповыми операциями
На рис. 47 показано окно конструктора в процессе создания запроса, выводящего информацию по суммарному спросу и предложению на ценные бумаги. Операция свертки нескольких записей из таблицы Заявки в одну ре- зультирующую запись, осуществляемая для каждого наименования бумаги, определяется командой Группировка, расположенной в строке Групповая
операция. Для двух последующих колонок запроса (СуммСпрос и Сумм-
Предл) определены операции суммирования по группе (Sum), расположен- ные в той же строке, а в строке Поле находятся производные выражения, суммы которых мы хотим получить в запросе. В соответствии с ранее приня- тыми соглашениями объем суммарного спроса определяется совокупностью всех записей по данной бумаге, имеющих положительное значение в поле
ОбъемЗаявки, а объем суммарного предложения – записями, содержащими в данном поле отрицательную величину. Таким образом, для вычисления
СуммСпрос необходимо просуммировать:
If[ОбъемЗаявки]>=0; [Цена3аявки] * [0бъем3аявки];0), а для вычисления СуммПредл:
If[ОбъемЗаявки]<=0;-1* [Цена3аявки]*[0бъем3аявки];0).
77
ПРИМЕЧАНИЕ. Встроенная функция If(bArg; Arg1; Arg2) возвращает значение аргумента Arg1, если значение аргумента bArg, который может со- держать только логическую величину, является истинным (bArg = ИСТИ-
НА), и значение Arg2, если bArg = ЛОЖЬ.
Также следует обратить внимание на такие важные возможности кон- структора запросов, как:
задание параметров, запрашиваемых при открытии запроса;
встроенные статистические функции, доступные при задании груп- повых операций. Они делают запросы мощным инструментом ана- лиза хранимой информации.
В завершение обзора средств построения запросов в СУБД Access сле- дует указать также и на то, что в нее помимо мощного и эффективного визу- ального конструктора встроен также и режим непосредственного ввода SQL- выражений, определяющих запрос. Данный режим существует параллельно и доступен из меню Вид > Режим SQL (а также из пиктограммы Вид на пане- ли инструментов). Перейдя в него, в частности, можно просмотреть SQL- выражение, соответствующее ранее построенному запросу СводнСпрос-
Предл. Оно выглядит так:
SELECT Бумаги.НаимБум,
Sum(IIf([ОбъемЗаявки]>=0,[Цена3аявки]*[0бъем3аявки],0))
AS СуммСпрос,
Sum (IIf ([ОбъемЗаявки]<=0,-[ЦенаЗаявки]*[0бъемЗаявки],0))
AS
СуммПредл
FROM
Бумаги INNER JOIN
(
Агенты INNER JOIN Заявки ON Агенты.КодАг = Заявки.КодАг)
ON
Бумаги.КодБум = Заявки.КодБум
GROUP BY
Бумаги.НаимБум
ORDER BY
Бумаги.НаимБум;
Пользователь, владеющий синтаксисом языка SQL, может модифици- ровать данное выражение в ручном режиме. Очевидно, что такая техника ра- боты требует существенно большей квалификации, но одновременно она да- ет в руки разработчика мощный и универсальный аппарат управления дан- ными.
Говоря о связи между режимом визуального конструктора запросов и режимом построения SQL-выражений, необходимо отметить, что существует естественная и логичная связь между типами запросов и реализующими ихSQL-операторами. В частности, запросу на выборку соответствует опера- тор
SELECT
, запросу на создание –
CREATE
, запросу на обновление –
UP-
DATE
, запросу на удаление –
DELETE
и т. д.
78
7.2.5 Конструирование экранных форм для работы с данными
В 6.3.2 был рассмотрен режим непосредственного ввода данных в таб- лицу. Очевидно, что он имеет весьма ограниченное применение. Это обу- словливается как тем, что длина записи может оказаться достаточно большой и вводить информацию в нее в табличной форме будет технически неудобно, так и соображениями более принципиального характера:
во-первых, структура таблицы должна строиться на основе логики задач хранения информации, которая, вообще говоря, может суще- ственно отличаться от логики ее накопления и ввода;
во-вторых, важным показателем качества автоматизированной сис- темы является организация ее системы ввода/вывода в виде, мак- симально приближенном к традиционным формам представления информации на немашинных носителях. Такие формы, как прави- ло, делают программное обеспечение привлекательным для конеч- ного пользователя, уменьшают период его адаптации ко вновь вне- дряемой системе и позволяют быстро сосредоточиться на решении основных профессиональных задач;
в-третьих, в сложной и развитой автоматизированной информаци- онной системе должно обеспечиваться разделение доступа к раз- личным группам полей и записей для различных категорий пользо- вателей в зависимости от выполняемых ими функций. Также в оп- ределенных ситуациях требуется представить одну и ту же инфор- мацию либо в различных видах и разрезах, либо в различных соче- таниях с другой информацией.
Для решения как этих, так и многих других проблем организации интер- фейса ввода/ вывода данных в Access служит механизм электронных форм. Вы- берем вкладку Формы главного окна базы данных и нажмем кнопку Создать.
Появляющееся диалоговое окно позволяет выбрать как таблицу или запрос, для работы с данными которых составляется форма, так и режим ее создания. В за- висимости от квалификации пользователя и, естественно, сложности разраба- тываемой формы можно либо воспользоваться встроенными программными надстройками-мастерами, либо сразу начать ее создание с нуля в режиме Кон-
структора. Весьма плодотворным также оказывается комбинированный под- ход: сначала используется соответствующий мастер, а затем полученная форма дополнительно дорабатывается в «ручном режиме». Проиллюстрируем сказан- ное на примере. Создадим форму для работы с таблицей Бумаги, воспользовав- шись надстройкой Автоформа: в столбец. В результате получим окно сле- дующего вида (рис. 48).
По умолчанию форме было предложено присвоить такое же имя, как и у таблицы, на основе которой она была создана, то есть Бумаги. Как видно из рис. 47, при создании подписей полей программная надстройка использовала их соответствующие атрибуты, заданные при конструировании таблицы. По-