ЗАПРОС “ЛЮКС”

Вернемся к нашему первому запросу — запросу “Люкс”. В самом начале работы с этим запросом следует сказать, что этот запрос нам не будет нужен в дальнейшем. В конце концом мы даже удалим его. Кстати, для удаления запроса или таблицы (или любого другого объекта Access) достаточно выбрать нужный объект и нажать клавишу <DEL>. Но, несмотря на полную никчемность, этому запросу суждена в нашей жизни благородная роль – он должен, погибнув, научить нас очень многому, что есть в за­просах.

Итак, выбрав (по-прежнему единственный) запрос «Люкс», нажмем на кнопку «Конструктор». Мы могли бы нажать и на кнопку «Открыть», задав табличный режим работы с запросом. Находясь в запросе, мы можем перехо­дить из режима в режим, когда нам это потребуется. При создании запроса мы начинаем работу в режиме конструк­тора.

Чтобы посмотреть, что же мы сконструировали в нашем запросе в режиме конструктора, мы можем либо перейти в режим таблицы, нажав на соответствующую кнопку, либо нажать на кнопку “Выполнить” (на ней изображен восклицательный знак). Будем говорить, что мы выполняем запрос (кнопка “Выполнить”), или просмат­риваем запрос (находясь в табличном режиме).

Для запроса типа выборки безразлично: выполняете ли Вы, или просматриваете запрос – в любом случае Вы получите тот же результат – на экране отобразятся поля с данными, которые Вы сконструировали в запросе. Для других же типов запросов (удалить, создать таблицу и др.) их просмотр и выполнение приводят к различным резуль­татам .

Добавьте в запрос еще два поля-столбца: “Код кате­гории” и “Число мест”. Выполните (или просмотрите) за­прос — Вы увидите три записи в трёх полях. Затем верни­тесь в режим конструктора и, выделив третий столбец (стрелка вниз над именем столбца, щелчок), удалите его, нажав клавишу <DEL>. Теперь мы умеем и вставлять, и удалять поля-столбцы в запросе.

Оставив в запросе два столбца: “Номер комнаты” и “Код категории”, поработаем со строкой “Условие отбора”. Добавим в эту строку букву “Л” (код категории люкс) в столбце “Код категории”:

Поле Номер комнаты Код категории
Условие отбора 101 Or 201 Or 301 Л
Или    

Выполнив запрос, мы увидим знакомые поля:

Номер комнаты Код категории
101 Л
201 Л
301 Л

Ничего не изменилось. И это понятно: все три номера комнаты, перечисленные в условии отбора, принадлежат к категории люкс. Точно такой же результат мы получим, если вообще уберём номера комнат и в условии отбора оставим только букву “Л”:

Поле Номер комнаты Код категории
Условие отбора   Л
Или    

Все, что мы с Вами получили, достаточно очевидно. Но, допустим, что мы ошиблись и вместо “Л” набрали “П” (код первой категории), а номера комнат люкс в условии тоже остались:

Поле Номер комнаты Код категории
Условие отбора 101 Or 201 Or 301 П
Или    

Выполнив запрос, мы увидим, что оба поля таблицы пусты:

Номер комнаты Код категории
   

Это получилось потому, что все критерии отбора, указанные в одной строке, объединяются оператором AND и в результате Вы получаете только те записи, которые удовлетворяют всем условиям, точнее – одновременно удовлетворяют условиям во всех полях строки. В нашем случае запись должна содержать одну из трёх комнат: 101, 201 или 301 и в то же время эти номера должны принадлежать первой категории. В итоге мы и получили пустую таблицу, т.к. ни одной записи, одновременно отвечающей этим двум условиям, у нас нет.

Но совершенно другой результат мы получим, если “П” перенесём строкой ниже (в строку “или”):

Поле Номер комнаты Код категории
Условие отбора 101 Or 201 Or 301  
Или   П

Выполнив запрос, мы увидим следующий результат:

Номер комнаты Код категории
101 Л
102 П
103 П
201 Л
202 П
203 П
301 Л
302 П
303 П

У нас в таблице объединились записи, представляющие и номера люкс и номера первой категории. Это произошло потому, что каждая строка в критериях отбора анализируется отдельно и строки объединяются оператором OR. В нашем случае в таблицу попадают записи, в которых есть номера комнат 101, 201, 301 или те номера, в которые относятся к первой категории (“П”).

Закрыв запрос и вновь открыв его в режиме конструктора, мы увидим, что буква “П” не переходит из строки “или” в строку “Условие отбора”. Вспомните, что в аналогичной ситуации номера 201 и 301 в самом конце главы 1.13 перебрались из строк “или” в “Условие отбора”. Правда, аналогичность ситуации здесь только в закрытии и открытии запроса.

Чтобы ещё лучше понять механизм отбора записей, объединим “П” и “Л” оператором OR:

Поле Номер комнаты Код категории
Условие отбора 101 Or 201 Or 301 Л Or П
Или    

Выполнив запрос, мы увидим в таблице только комнаты категории люкс. Мы уверены, что следующее логическое выражение, объясняющее результат, не вызовет у Вас ни малейшего недоумения:

(101 OR 201 OR 301) AND (Л OR П)

Действительно, в правой скобке у нас множество комнат, принадлежащих категориям люкс и первой, а в левой – множество комнат люкс. Объединив эти множества оператором AND, мы, конечно же получаем только множество люкс.

И, наконец, чтобы окончательно расставить всё по местам и проверить себя, прибавьте к номерам комнат 102:

Поле Номер комнаты Код категории
Условие отбора 101 Or 201 Or 301 Or 102 Л Or П
Или    

Мы поместим ответ-таблицу ниже, чтобы дать Вам возможность не спешить и подумать, что получится после выполнения запроса. Если Ваш ответ (без помощи Access) совпал с таблицей, помещённой в конце главы 1.16, знайте, что Вы уже не новичок в логике.

Теперь добавим в запрос таблицу “Гости”, чтобы посмотреть, кто же живёт в номерах люкс. При этом уберём условие отбора из поля “Номера комнат”, а оставим только “Л” в столбце “Код категории”, одновременно запретив вывод этого поля на экран (убрав крестик в соответствующей строке).

В третий столбец запроса занесём поле “Фамилия” из таблицы “Гости” и выполним запрос. Мы увидим, что записей не три, а две. Запись, соответствующая 101-й комнате, пропала. Сейчас пропажа записи для нас уже не тайна: т.к. в 101-й комнате никто не живёт, то поля “Фамилия”, соответствующего этой комнате, нет, т.е. значение этого поля для записи со 101-й комнатой ложно. А значит и вся запись ложна (т.к. мы знаем, что критерии отбора в строке соединяются оператором AND), поэтому и не выводится на экран.

Чтобы запись со 101-й комнатой вновь появилась, поселите в эту комнату своего лучшего друга. Именно друга, т.к. никто другой не выдержит всего того, что выпадет на его долю. Ему придётся неоднократно въезжать и выезжатьв этот номер, пока мы будем решать множество своих проблем. Мы уверены, что на время отселения Вы поделитесь с другом своим номером. При этом у нас к Вам просьба не заносить друга в таблицу “Гости” (конечно же, это не требование администрации гостиницы, не позволяющей вдвоём проживать в одноместном номере, а наше пожелание не вносить лишней путаницы в базу данных на этапе её изучения).

Выполнив запрос, мы увидим три записи – друг пока в своём номере.

Конечно, дружба – великая вещь, но истина дороже. Мы можем увидеть запись со 101-й комнатой в нашем запросе и не поселяя в этот номер своего друга (мытарства друга только начинаются).

Обратим внимание на связь между таблицами. Таблицы связывают линии, не имеющие на своих концах никаких значков, кроме маленьких точек. Это означает, что объединяются только те записи, в которых связанные поля обеих таблиц совпадают. Вы можете убедиться в этом, щелкнув правой кнопкой мыши на линии связи и в появившемся контекстно-зависимом меню выполнить команду “Параметры объединения”. В открывшемся окне Вы увидите, что установленная по умолчанию первая опция и задаёт такие параметры объединения полей двух таблиц.

Теперь вполне понятно, что мы не видели в запросе третьей записи – поля с такими данными (101) в таблице “Гости” не было. А теперь в окне “Параметры объединения” зададим опцию, когда объединяются все записи из таблицы “Этажи” и только те записи из таблицы “Гости”, в которых связанные поля совпадают. У линии связи появляется стрелка, направленная в сторону таблицы “Гости”.

Выполнив запрос “Люкс”, Вы увидите, что даже не поселяя друга, все три номера люкс будут выведены. Но если друг не живёт в номере, то поле в столбце “Фамилия” будет конечно пусто. После этого вновь поселите друга в его номер.

Не огорчайтесь, если Вам что-то пока неясно в механизме связи в Access – мы ещё не раз вернёмся к нему. А сейчас нам пора расставаться с запросом “Люкс”. Но не удаляйте его, он нам ещё пригодится. А сейчас (пока друг немного отдохнёт) идём дальше.

Ссылка на основную публикацию
Adblock
detector