Программа Access не предлагает какой-либо мощной поддержки при вводе выражений в строки Поле и Условие отбора конструктора запросов; она не проверяет синтаксис функций и парность скобок; она не предлагает простого способа извлечении имен полей, а ее сообщения об ошибках могут быть неопределенными.
Программа Access предлагает инструмент, который может в некоторой мере облегчить построение выражений. Эта функция так и называется – Построитель выражений, и работать с ней можно следующим образом:
-
Нужно щелкнуть на ячейке Поле или Условие отбора, в которую нужно вводить выражение.
-
После этого нужно щелкнуть на кнопке Построить панели инструментов. Откроется диалоговое окно построителя выражений.
-
В большом текстовом поле нужно ввести все выражение или его часть.
-
Для того чтобы в выражение добавить оператор, нужно щелкнуть на месте его предполагаемой вставки, щелкнуть на кнопке оператора или в категории Оператор дважды щелкнуть на нужном операторе.
-
Чтобы добавить в выражение объект базы данных, нужно щелкнуть на месте его предполагаемой вставки, а затем в оной из категорий (Таблицы, Запросы и т.д.) найти нужный объект и дважды щелкнуть на нем.
-
Для добавления в выражение функции нужно щелкнуть на месте ее предполагаемой вставки. Открыть папку Функции – Встроенные Функции, выбрать тип и дважды щелкнуть на названии нужной функции.
-
Повторять действия 4-6 до тех пор, пока создание выражения не будет закончено.
-
Щелкнуть на кнопке ОК.
Работа с многотабличными запросами
Большинство приложений работы с базами данных хранят свою информацию в нескольких таблицах. Несмотря на то, что многие из таблиц никак не связаны друг с другом, некоторые из них все же хранят взаимосвязанную информацию.
В процессе работы с несколькими связанными таблицами в одном запросе возникают некоторые сложности. Во-первых, база данных должна быть сконструирована таким образом, чтобы связанные данные были доступны. Во-вторых, нужно установить связи между таблицами так, чтобы можно было осуществлять выборку связанной информации и чтобы работа со связанными таблицами в конструкторе запросов была максимально удобной и быстрой.
Недостатки нереляционных конструкций
В табл. 5 показана структура простой таблицы (под названием Представители), хранящей информацию о торговых представителях различных компаний.
Таблица 5. Структура простой таблицы Представители
Поле
|
Описание
|
Ключ
|
Первичный ключ
|
Имя
|
Имя контактного лица
|
Фамилия
|
Фамилия контактного лица
|
Компания
|
Название компании
|
Адрес
|
Улица и номер дома в адресе
|
Город
|
Город в адресе
|
Область
|
Область в адресе
|
Индекс
|
Индекс в адресе
|
Телефон
|
Номер телефона компании
|
Факс
|
Номер факса компании
|
Регион
|
Откуда прибыл торговый представитель
|
Примечания
|
Комментарии или примечания
|
Эта структура будет хорошо работать до тех пор, пока не потребуется добавить второго и третьего представителя одной и той же компании. В этом случае все поля, связанные с адресом и реквизитами компании (Адрес, Город, Область, Индекс и др.) будут повторяться в нескольких записях таблицы.
Все эти повторения будут неоправданно раздувать размеры таблицы и приведут к двум следующим неудобствам в работе:
-
Во время ввода данных одну и ту же информацию придется вводить в несколько строк, относящихся к одной и той же компании.
-
Если какая-либо повторяющаяся информация изменяется, редактировать ее придется во всех записях, связанных с данной компанией.
Одним из способов решения проблемы повторяющихся данных и облегчения работы с ней является определение приоритета данных в таблице. Как и следует из названия, таблица будет содержать только по одной записи с реквизитами каждой из компаний, в которых будет добавлено по одной группе полей для каждого представителя. Новая структура будет выглядеть следующим образом (табл. 6):
Таблица 6. Структура таблицы Лидеры с приоритетом реквизитов компании
Поле
|
Описание
|
Ключ
|
Первичный ключ
|
Компания
|
Название компании
|
Адрес
|
Улица и номер дома в адресе
|
Город
|
Город в адресе
|
Область
|
Область в адресе
|
Индекс
|
Индекс в адресе
|
Телефон
|
Номер телефона компании
|
Факс
|
Номер факса компании
|
Имя_1
|
Имя первого контактного лица
|
Фамилия_1
|
Фамилия первого контактного лица
|
Регион_1
|
Откуда прибыло первое контактное лицо
|
Телефон_1
|
Телефон первого контактного лица
|
Примечания_1
|
Комментарии или примечания, относящиеся к первому контактному лицу
|
Имя_2
|
Имя второго контактного лица
|
Фамилия_2
|
Фамилия второго контактного лица
|
Регион_2
|
Откуда прибыло второе контактное лицо
|
Телефон_2
|
Телефон второго контактного лица
|
Примечания_2
|
Комментарии или примечания, относящиеся ко второму контактному лицу
|
Имя_3
|
Имя третьего контактного лица
|
Фамилия_3
|
Фамилия третьего контактного лица
|
Регион_3
|
Откуда прибыло третье контактное лицо
|
Телефон_3
|
Телефон третьего контактного лица
|
Примечания_3
|
Комментарии или примечания, относящиеся к третьему контактному лицу
|
При такой конструкции информация о компании появляется в таблице только единожды, а информация о контактных лицах образует несколько групп полей (например, Имя_1, Фамилия_1, Регион_1, Телефон_1 и Примечания_1). Эта модель решает проблему первой конструкции, однако только за счет возникновения новой сложности – в каждой из записей можно хранить информацию только о трех представителях. Совершенно очевидно, что крупные компании могут иметь гораздо больше агентов, вплоть до нескольких десятков.
Поділіться з Вашими друзьями: |