Изучаем.SQL

гично, если некоторые сотрудники зарегистрированы в отделе с ID 99, которого нет в таблице department, эти сотрудники не попадут в резуль тирующий набор. Если требуется включить все строки той или иной таблицы независимо от наличия соответствия, можно воспользоваться внешним соединением (outer join), но мы рассмотрим это в главе 10.

В предыдущем примере в блоке from я не указал тип используемого со единения. Однако если требуется соединить две таблицы путем внут реннего соединения, это следует явно указать в блоке from. Вот тот же пример с добавлением типа соединения (обратите внимание на ключе вое слово INNER (внутренний)):

+ + + + 18 rows in set (0.00 sec)

Если тип соединения не задан, сервер по умолчанию проведет внутрен нее соединение. Однако, как выяснится в главе 10, есть несколько ти пов соединений, поэтому указание точного типа требуемого соедине ния должно войти в привычку.

Если имена столбцов, используемых для соединения двух таблиц, сов падают (что имеет место в предыдущем запросе), можно вместо под блока on применить подблок using:

mysql> SELECT e.fname, e.lname, d.name

> FROM employee e INNER JOIN department d> USING (dept_id);

+ + + +

| fname | lname | name | + + + +

+ + + + 18 rows in set (0.01 sec)

Поскольку using – сокращенная запись, которая может использовать ся только в определенной ситуации, во избежание путаницы я всегда предпочитаю подблок on.

ANSI синтаксис соединения

Нотация, используемая в данной книге для соединения таблиц, была введена в версии SQL92 стандарта ANSI SQL. Во всех основных СУБД (Oracle Database, Microsoft SQL Server, MySQL, IBM DB2 Universal Da tabase, Sybase Adaptive Server) принят синтаксис соединения SQL92. Поскольку многие серверы существовали еще до выхода специфика ции SQL92, все они включают и старый синтаксис соединения. Напри мер, всем этим серверам был бы понятен такой вариант предыдущего запроса:

mysql> SELECT e.fname, e.lname, d.name

> FROM employee e, department d> WHERE e.dept_id = d.dept_id;

+ + + + | fname | lname | name | + + + +

+ + + + 18 rows in set (0.01 sec)

Этот старый метод описания соединений не включает подблок on. Таб лицы указаны в блоке from через запятую, а условия соединения вклю чены в блок where. Хотя можно игнорировать синтаксис SQL92 в поль зу старого синтаксиса соединений, у синтаксиса ANSI есть следующие преимущества:

•Условия соединения и фильтрации разнесены в два разных блока (подблок on и блок where соответственно), что упрощает понимание запроса.

•Условия соединения для каждой пары таблиц содержатся в собст венном блоке on, что уменьшает вероятность ошибочного исключе ния части соединения.

•Запросы, использующие синтаксис соединения SQL92, портируют ся на разные серверы БД, тогда как старый синтаксис немного от личается для каждого сервера.

Преимущества синтаксиса соединения SQL92 заметнее в сложных за просах, включающих как условия соединения, так и условия фильт рации. Рассмотрим следующий запрос, по которому возвращаются все счета, открытые опытными операционистами (нанятыми до 2003 го да), в настоящее время приписанными к отделению Woburn:

> WHERE c.cust_type_cd = 'B';

+ + + | account_id | fed_id | + + + | 20 | 04 1111111 | | 21 | 04 1111111 | | 22 | 04 2222222 | | 23 | 04 3333333 | | 24 | 04 4444444 | + + + 5 rows in set (0.06 sec)

Этот запрос, возвращающий ID счета и идентификационный номер фе дерального налога для всех бизнес счетов, на данный момент должен быть абсолютно понятным. Однако если добавить в запрос таблицу emp loyee для получения имени операциониста, открывшего каждый из сче тов, он примет следующий вид:

|21 | 04 1111111 | Theresa | Markham |

|23 | 04 3333333 | Theresa | Markham |

| 24 | 04 4444444 | John | Blake | + + + + + 5 rows in set (0.03 sec)

Теперь имеется три таблицы, два типа соединений и два подблока on, перечисленные в блоке from. Таким образом, все немного усложняется. На первый взгляд из за порядка перечисления таблиц может пока заться, что таблица employee соединяется с таблицей customer, посколь ку таблица account указана первой. Однако если изменить порядок рас положения таблиц, результаты будут абсолютно аналогичными:

+ + + + + | account_id | fed_id | fname | lname | + + + + + | 20 | 04 1111111 | Theresa | Markham |

|21 | 04 1111111 | Theresa | Markham |

|23 | 04 3333333 | Theresa | Markham |

| 24 | 04 4444444 | John | Blake | + + + + + 5 rows in set (0.00 sec)

Теперь таблица customer стоит первой, за ней идут таблицы account и employee. Поскольку подблоки on не изменились, результаты такие же.

Запрос, использующий три или более таблиц, можно представить как снежный ком, катящийся с горы. Первые две таблицы запускают этот ком, а каждая последующая таблица вносит в него свою лепту. Снеж ный ком можно рассматривать как промежуточный результирующий набор (intermediate result set), который подбирает все больше и больше столбцов по мере соединения с последующими таблицами. Поэтому таблица employee в действительности была соединена не с таблицей ac count, а с промежуточным результирующим набором, созданным при соединении таблиц customer и account. (Если интересно, откуда взялся снежный ком: я писал эту главу глубокой новоанглийской зимой – уже выпало 110 дюймов и завтра будет еще. Вот радость то!)

Применение подзапросов в качестве таблиц

Вы уже посмотрели несколько примеров запросов с тремя таблицами, но хочется особо отметить одну из разновидностей таких запросов. Что делать, если некоторые таблицы формируются подзапросами? Подза просам посвящена глава 9, но концепция подзапроса в блоке from уже была представлена в предыдущей главе. Вот другая версия приведен ного ранее запроса (выбор всех счетов, открытых опытными операцио нистами, в настоящее время работающими в отделении Woburn), в ко тором таблица account соединяется с подзапросами к таблицам branch (отделение) и employee:

4FROM employee

5WHERE start_date <= '2003 01 01'

6 AND (title = 'Teller' OR title = 'Head Teller')) e 7 ON a.open_emp_id = e.emp_id

8INNER JOIN

9 (SELECT branch_id

10FROM branch

11WHERE name = 'Woburn Branch') b

12ON e.assigned_branch_id = b.branch_id;

Первый подзапрос, начинающийся в строке 3 и имеющий псевдоним e, находит всех опытных операционистов. Второй подзапрос, начинаю щийся в строке 9 и имеющий псевдоним b, выбирает ID отделения Wo burn. Сначала таблица account соединяется с подзапросом по опытным

операционистам с помощью ID сотрудников, а затем результирующая таблица соединяется с подзапросом по отделению Woburn на основе ID филиала. Результаты аналогичны предыдущей версии запроса (по пробуйте и убедитесь сами), но на вид запросы очень отличаются друг от друга.

На самом деле здесь нет ничего необычного, но осознать происходящее можно не сразу. Обратите внимание, например, на отсутствие блока where в основном запросе. Поскольку все условия фильтрации касаются таблиц employee и branch, они находятся в подзапросах. В основном за просе никакие условия фильтрации не нужны. Единственный способ проиллюстрировать происходящее – выполнить подзапросы и посмот реть на результирующие наборы. Вот результаты выполнения первого подзапроса к таблице employee:

mysql> SELECT emp_id, assigned_branch_id

Таким образом, результирующий набор состоит из набора ID сотруд ников и ID соответствующих им отделений. Соединив таблицу account посредством столбца emp_id, имеем промежуточный результирующий набор, содержащий все строки таблицы account и дополнительный столбец с ID отделения, в котором работает сотрудник, открывший каж дый из счетов. Вот результаты второго подзапроса к таблице branch:

mysql> SELECT branch_id

По этому запросу возвращается одна единственная строка с одним столбцом: ID отделения Woburn. Эта таблица соединена со столбцом assigned_branch_id промежуточного результирующего набора, что по зволяет отсеять из окончательного результирующего набора все счета, открытые несотрудниками отделения Woburn.

Повторное использование таблицы

При соединении нескольких таблиц может обнаружиться, что требует ся неоднократно соединять одну и ту же таблицу. В нашем примере БД внешние ключи к таблице branch присутствуют как в таблице account (отделение, в котором был открыт счет), так и в таблице employee (отде ление, в котором работает сотрудник). Если в результирующий набор должны войти оба отделения, таблицу branch можно включить в блок from дважды, в первый раз соединив ее с таблицей employee, а второй раз – с таблицей account. Это сработает, если каждому экземпляру таб лицы branch присвоить свой псевдоним, чтобы сервер знал, на какой экземпляр делается ссылка:

+ + + + + | account_id | emp_id | open_branch | emp_branch | + + + + +

|1 | 10 | Woburn Branch | Woburn Branch |

|4 | 10 | Woburn Branch | Woburn Branch |

|6 | 13 | Quincy Branch | Quincy Branch |

|11 | 16 | So. NH Branch | So. NH Branch |

|15 | 16 | So. NH Branch | So. NH Branch |

|20 | 16 | So. NH Branch | So. NH Branch |

| 23 | 16 | So. NH Branch | So. NH Branch | + + + + + 10 rows in set (0.07 sec)

Этот запрос показывает, кто открыл каждый текущий счет, в каком от делении это произошло и к какому отделению приписан в настоящее время сотрудник, открывший счет. Таблица branch включена дважды под псевдонимами b_a и b_e. Благодаря присваиванию разных псевдо нимов каждому экземпляру таблицы branch, сервер сможет определить экземпляр, на который делается ссылка, – соединенный с таблицей

account или с таблицей employee. Таким образом, имеем пример запроса, в котором использование псевдонимов таблиц является обязательным.

Рекурсивные соединения

Можно не только несколько раз включать одну и ту же таблицу в один запрос, фактически можно соединить таблицу с самой собой. Поначалу это может показаться странным, но для этого есть веские основания. В таблице employee, например, есть рекурсивный внешний ключ (self referencing foreign key). Это означает, что она включает столбец (supe rior_emp_id), указывающий на первичный ключ в рамках той же табли цы. Этот столбец указывает на начальника сотрудника (если только это не сам босс – тогда столбец имеет значение null). С помощью рекур сивного соединения (self join) можно создать запрос, в результате вы полнения которого выводится список всех сотрудников с указанием имен их начальников:

Этот запрос включает два экземпляра таблицы employee: из одного (под псевдонимом e) извлекаются имена сотрудников, а из другого (под псев донимом e_mgr) – имена начальников. Подблок on использует эти псев донимы для соединения таблицы employee с самой собой посредством внешнего ключа superior_emp_id. Это еще один пример запроса, для ко

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

Хотя в таблице employee 18 строк, по запросу было возвращено только 17. У президента банка, Майкла Смита (Michael Smith), нет начальника (его столбец superior_emp_id имеет значение null), поэтому для данной строки соединение не сработало. Чтобы включить Майкла Смита в ре зультирующий набор, необходимо использовать внешнее соединение, которое будет рассмотрено в главе 10.

Сравнение эквисоединений с неэквисоединениями

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

ON e.assigned_branch_id = b.branch_id

Подавляющее большинство запросов использует эквисоединения, но можно также соединять таблицы посредством диапазонов значений, называемых неэквисоединениями (non equi joins). Вот пример запроса, осуществляющего соединение по диапазону значений:

SELECT e.emp_id, e.fname, e.lname, e.start_date

FROM employee e INNER JOIN product p

ON e.start_date >= p.date_offered

AND e.start_date <= p.date_retired

WHERE p.name = 'no fee checking';

Этот запрос соединяет две таблицы, между которыми нет взаимосвя зей по внешним ключам. Задача – найти всех сотрудников, принятых в банк в то время, когда предлагалась услуга беспроцентного текущего вклада. Таким образом, дата начала работы сотрудника должна нахо диться между датами начала и конца этой акции.

Также может понадобиться рекурсивное неэквисоединение (self non equi join), которое означает, что таблица соединяется сама с собой с ис пользованием неэквисоединения. Например, управляющий операция ми решил провести шахматный турнир между всеми операциониста ми банка. Требуется создать список всех пар игроков. Можно попробо вать получить список всех операционистов (title = 'Teller'), соединив таблицу employee с самой собой, и выбрать из него все строки с разными значениями emp_id (поскольку игрок не может составить пару с самим собой):

mysql> SELECT e1.fname, e1.lname, 'VS' vs, e2.fname, e2.lname

> FROM employee e1 INNER JOIN employee e2