Предположим, надо получить справку об авариях, которые произошли:
• на нефтепроводах;
• на мазутопроводах;
• на бензопроводах;
• на продуктопроводах.
Мы предусмотрели практически все виды нефтепродуктов. Теперь построим соответствующий запрос.
Как обычно, сначала откройте пустой бланк запроса и введите туда все поля записи (последнее делать не обязательно – любые поля можно вносить в бланк и по отдельности). Критерий отбора сформулируйте так:
"*нефтепровод " OR «*бензопровод*» OR «*мазутопровод*» OR «*продуктопровод*».
Иначе говоря, вы выстраиваете логическую схему «ИЛИ». Теперь посмотрим, как она реализуется на практике.
Откройте окно конструктора запроса для таблицы Fiie1. Как и раньше, введите значение первого критерия – «*нефтепровод*» – в строку Условие отбора на ее пересечении со столбцом Характеристика ЧЭС. Следующие значения критериев вводятся в этом же столбце, но в строках, расположенных ниже по вертикали. Каждая из них помечена словом OR (Или) – рис. 11.21.
Рис. 11.21
Количество таких строк практически не ограничено, поэтому составной критерий может включать достаточно большое число операндов. Запустив запрос на выполнение, вы получите таблицу (см. рис. 11.22). Обратите внимание, что она похожа на результирующую таблицу, представленную на рис. 11.16, когда вы сформировали запрос с одним критерием. Однако в новой таблице отобрано уже не 8 записей, а 15, и среди аварийных объектов назван, в частности, мазутопровод.
Рис. 11.22
Наконец, открыв инструкцию SQL (см. рис. 11.23), вы можете лишний раз убедиться: все изменения, которые внесены вами в логические схемы критериев, точно отображаются в предложении с ключевым параметром WHERE.
Рис. 11.23
Надо сказать, что структуры критериев бывают самыми разнообразными. Но при их построении вам потребуются точность и аккуратность, чтобы отбор записей производился правильно. Например, у критериев, выведенных на рис. 11.21, неизменяемая часть слова – «*опровод*». Исключением является лишь «*нефтепровод*». Казалось бы, можно сократить условие в той его части, где вводятся критерии. Чтобы при этом исключить записи, связанные с авариями на газопроводах, сформулируем условие следующим образом:
(«*нефтепровод*» OR «*опровод*») AND Not «*газопровод*»
Если вы введете такое условие в запрос, а затем выполните его, то система действительно отберет записи, удовлетворяющие заданному критерию. Однако в их число попадут и сведения об авариях, связанных с повреждением водопровода или электропроводки. Поэтому учтите, что похвальное стремление к краткости и упрощению критериев запроса иногда приводит к нежелательным последствиям.
Запросы с параметрами
Иногда для получения какой-либо справки приходится неоднократно вводить различные значения одного и того же параметра. Такая справка называется параметрической. Например, на практике сведения об авариях на нефтепроводах обычно собираются по субъектам Российской Федерации – краям и областям. Для подобных случаев полезно иметь готовый типовой запрос: вы вводите в стандартное поле название края или области, а в результате получаете справку стандартного вида. Такой запрос несложно построить.
Откройте запрос, который был сохранен под именем Запрос4 (см. рис. 11.18). В поле Регион вместо значения Тюменская область поместите подсказку [Введите область] – рис. 11.24.
Рис. 11.24
Если теперь вы дадите команду на выполнение запроса (с помощью кнопки
или предварительно сохранив его в окне базы данных), то Access 2002 потребует сначала указать название области или края в диалоговом окне Введите значение параметра. Этот этап работы продемонстрирован на рис. 11.25.
Рис. 11.25
Вам следует ввести полное географическое наименование, а затем щелкнуть по кнопке ОК. Запрос будет выполнен для заданного региона. Например, вы вводите значение Тюменская область и получаете таблицу, которую уже видели на рис. 11.19. Понятно, что точно так же можно задать любой другой критерий. Как видите, типовой запрос оперативен и удобен в использовании.
На рис. 11.26 показана инструкция SQL для такого запроса. Вы можете вновь убедиться, что соответствующие изменения уже включены в предложение с ключевым параметром WHERE. В данном случае в этом предложении применяется логическая схема «И», которая содержит в качестве операндов и нефтепровод*", и приведенную выше подсказку. Иными словами, Access воспринимает ее как значение критерия.
Рис. 11.26
Запросы с участием нескольких связанных таблиц
Запросы этой группы применяются, если пользователю необходима информация, которая содержится не в одной, а в нескольких таблицах.
Для начала вернемся к уже рассмотренному примеру, когда вы создали запрос на выборку российских фирм из одной таблицы – Фирмы, а в качестве критерия использовали код России – «0 6» (см. рис. 11.12). Попробуем сформулировать этот же запрос более естественным образом, задав условием отбора название страны – Россия.
Откройте окно конструктора запроса и введите в него две таблицы: Фирмы и Страны. Как и раньше, вы используете таблицу Добавить таблицу, но теперь по очереди выбираете из нее две или более таблицы (см. рис. 11.3). Вы снова указываете в таблице Фирмы поле Название фирмы, а в таблице Страны – поле Страна; однако в ячейке Условие отбора столбца Страна вводите критерий Россия (см. рис. 11.27).
Рис. 11.27
Отправив запрос на выполнение, вы получите таблицу, содержащую отобранные сведения (см. рис. 11.28). Она похожа на таблицу с рис. 11.13, но вместо кода содержит название страны.
Рис. 11.28
Если вы теперь откроете инструкцию SQL (рис. 11.29), то увидите в ней новый элемент, который указывает на связь между таблицами Фирмы и Страны. Это ключевое слово INNER JOIN. Операция INNER JOIN доступна в любом предложении FROM и позволяет осуществить самое простое связывание – объединить записи двух таблиц, если их связующие поля содержат одинаковые значения. При этом INNER JOIN определяет объединяемые таблицы, а другое ключевое слово ON – объединяемые поля, которые имеют одинаковые значения.
Рис. 11.29
Теперь попробуем усложнить задачу и сформировать универсальный запрос. Предположим, вы постоянно работаете с той частью объединенного банка данных, которая включает сведения о контрольно-измерительных приборах. Иначе говоря, вы имеете дело с базой данных Контрольно-измерительные приборы. Вам приходится создавать запросы, очень разнообразные по своему построению. Однако вам некогда вникать в структуру таблиц и связей между ними, а также разбираться в том, какие таблицы нужны для подготовки ответа на какой-либо запрос. Необходимо более простое решение. Конечно, можно построить запрос с параметрами, но есть и другой путь. Он не противоречит первому варианту, а скорее дополняет его.
Введите в окно конструктора все таблицы базы данных Контрольно-измерительные приборы со всеми их связями (см. рис. 2.1). (Позднее дело дойдет и до других БД в составе объединенного банка данных.) Ничего не изменяя в ее структуре, в бланке запроса будем формировать запросы различных типов.
Допустим, вы хотите узнать, какие приборы используются для измерения тех или иных физических параметров. На рис. 11.30 показан бланк соответствующего запроса. В этом же окне конструктора вы видите макеты всех таблиц, содержащихся в нашей базе данных. (Отметим, что не все таблицы будут привлекаться в конкретных запросах.) На рис. 11.31 выведена результирующая выборка записей, полученная в ответ на ваш запрос.
Рис. 11.30
Рис. 11.31
На рис. 11.32 показана инструкция SQL для этого запроса. Мы видим, что все ключевые слова сохраняются, как и прежде, на своих местах, но их содержание становится богаче и разнообразнее.
Рис. 11.32
Предположим, что пользователь интересуется другой проблемой: какими приборами для измерения кислотности занимается менеджер по фамилии Флеминг. На рис. 11.33 показан заполненный бланк соответствующего запроса. Вы видите, что здесь в разных столбцах введено два условия отбора: «*кислотн*» и «Флеминг».
Рис. 11.33
В то же время перечень таблиц и схема связей между ними остаются неизменными. Результат выполнения этого запроса приведен на рис. 11.34. Отобраны сведения лишь о тех приборах для измерения кислотности, которыми ведает менеджер Флеминг. Если сравнить рис. 11.34 с рис. 11.31, то можно легко заметить, что число отобранных записей существенно сократилось – с 91 до 5.
