Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
МУ к ЛР.docx
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
3.42 Mб
Скачать

4 Контрольные вопросы

  1. Общая структура команды SELECT.

  2. Где и для каких целей применяется выборка?

  3. Как просмотреть результаты выборки?

  4. Приведите примеры условий формирования условий отбора?

  5. Перечислить операторы, которые могут применяться в предложении WHERE?

  6. Дайте определения функции агрегирования.

  7. Перечислить функции агрегирования, опишите их назначение?

  8. Какое предложение применяется для сортировки данных выборки, условия его применения?

  9. Каким образом осуществляется выборка из нескольких страниц?

  10. Приведите пример создания таблицы на основе выборки.

  11. Дайте определения триггеру.

  12. Приведите примеры возможных триггеров?

  13. Описать синтаксис набора команд создания триггеров?

  14. Что необходимо учитывать при использовании триггеров?

Лабораторная работа №5 Соединение таблиц и анализ данных.

1 Цель и порядок работы

1.1 Цель работы

Ознакомиться со структурой и синтаксисом основных конструкций формирования соединений.

1.2 Порядок выполнения работы

  • Ознакомиться с описанием работы;

  • Выполнить задание для самостоятельной работы;

  • Ответить на контрольные вопросы;

  • Представить результаты работы преподавателю.

2. Общие сведения

Для создателей стандарта SQL2 внешние объединения были серьезной пробле­мой. Так как внешние объединения — это единственный способ представления результатов ряда крайне необходимых запросов, было важно, чтобы стандарт SQL2 поддерживал данное понятие. Кроме того, внешние объединения поддерживались многими СУБД и становились все более важной частью SQL. Однако, как видно из предыдущей лабораторной работы, способы представления внешних объединений в различных СУБД сильно отличались друг от друга. Кроме того, все способы обозначения внешних объединений в коммерческих программных продуктах страдали недостат­ками и выбирались по принципу их минимального влияния на язык SQL, а не из соображений ясности и точности.

На этом фоне в стандарте SQL2 был определен совершенно новый метод поддержки внешних объединений, который не опирался ни на одну популярную СУБД. В спецификации стандарта SQL2 поддержка внешних объединений осуществляется в предложении FROM с тщательно разработанным синтаксисом, позволяю­щим пользователю точно определить, каким образом исходные таблицы должны быть объединены в запросе. Механизм поддержки внешних объединений, представленный в стандарте SQL2, обладает двумя преимуществами. Во-первых, с появлением стан­дарта SQL2 стало возможным создавать объединения самых сложных видов. Во-вто­рых, существующие СУБД могут без каких-либо конфликтов поддерживать имею­щиеся в стандарте SQL2 расширения стандарта SQL1 и в то же время сохранять поддержку своего собственного синтаксиса для внешних объединений.

Этих преимуществ удалось добиться за счет значительного усложнения прежде одного из самых простых разделов языка SQL. По сути, расширенная поддержка объ­единений является частью значительного расширения возможностей запросов в SQL2 в целом. Стало возможным выполнять операции над результатами запроса как над множествами (сложение, пересечение, вычитание таблиц) и применять выражения, манипулирующие строками, таблицами и подчиненными запросами.

Соединение - последний из трех операторов (выборка, проецирование и соединение), которые должен поддерживать любой язык реляционных запросов. С помощью операции соединения в одном операторе SELECT можно манипулировать данными из разных таблиц. Соединение таблиц сродни сборке из отдельных частей конструктора единого целого.

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

Концепции нормализации рассматриваются более подробно в следующей лабораторной работе. А на данный момент достаточно помнить, что по мере увеличения степени нормализации базы данных возрас­тает вероятность того, что для получения всех требуемых данных придется прибегать к соединению нескольких таблиц.

В данной лабораторной работе приведено вводное описание процесса комбинирования данных из нескольких таблиц в один результирующий набор с использованием различных форм конструкции JOIN.

В число этих конструкций входят следующие:

  • INNER JOIN—внутреннее соединение.

  • OUTER JOIN— внешнее соединение, как левое (LEFT), так и правое (RIGHT).

  • FULL JOIN— полное соединение.

  • CROSS JOIN—перекрестное соединение.

Конструкции JOIN

Во время работы с данными, хранящимися в нормализованной базе данных, часто приходится сталкиваться с ситуациями, в которых всю необходимую информацию невозможно получить только из одной таблицы. В других случаях вся информация, которая должна быть получена, находится в одной таблице, но выборка этих дан­ных должна осуществляться по условиям, подлежащим проверке по другой таблице. Конструкция JOIN предназначена для использования именно в таких ситуациях.

Конструкция JOIN выполняет именно ту задачу, на которую указывает смысл соот­ветствующего английского глагола, — соединяет информацию из двух таблиц в один результирующий набор. Результирующий набор можно рассматривать как «виртуаль­ную» таблицу. В него входят и столбцы, и строки, а сами столбцы характеризуются определенными типами данных. Ре­зультирующий набор можно использовать так, как если бы это была таблица, и обра­щаться к нему для выполнения других запросов.

Конкретные способы, применяемые в конструкции JOIN для соединения инфор­мации из двух таблиц в один результирующий набор, зависят от того, какие указания предусмотрены в этой конструкции, касающиеся сбора данных из разных таблиц, по­этому и предусмотрены четыре разных типа конструкции JOIN. Но все разности конструкций JOIN имеют одну общую отличительную особенность в том, что в них одна строка согласуется с одной или несколькими другими строками для получе­ния результирующей строки, представляющей собой надмножество, созданное путем соединения нолей из нескольких записей.

Например, предположим, что строки с данными о департаменте берутся из таблицы Departments (таблица 6).

Таблица 6 – Одна строка с данными из таблицы Departments.

Department_id

Department_name

Location_id

60

IT

1400

Теперь перейдем к рассмотрению строки из таблицы с данными сотрудниках, называемой employees (таблица 7).

Таблица 7 – Одна строка с данными из таблицы Emploees

First_name

Last_name

Department_id

Bruce

Ernst

60

Конструкция JOIN позволяет создать одну строку из двух строк, находящихся в полностью отдельных таблицах (таблица 8).

Таблица 8 – Строка, полученная в результате соединения строк с данными из таблиц Departments и Employees

Department_id

Department_name

Location_id

First_name

Last_name

60

IT

1400

Bruce

Ernst

С помощью этой конструкции JOIN строки соединяются на основании СВЯЗИ "один к одному" (по крайней мере такое впечатление складывается на основании приведен­иях данных). Одна строка из таблицы Departments соединяется с одной строкой из табли­цы Employees.

Немного дополним условия этого примера и рассмотрим, что при этом произойдет. Введем еще одну строку в таблицу Employees (таблица 9).

Таблица 9 - Две строки с данными из таблицы Emploees

First_name

Last_name

Department_id

Bruce

Ernst

60

David

Austin

60

Теперь рассмотрим, что произойдет после соединения дополненной таблицы Employees с той же таблицей Departments (содержащей только одну строку) (таблица 10).

Таблица 10 - Результаты соединения дополненной таблицы Employees с таблицей Department

Department_id

Department_name

Location_id

First_name

Last_name

60

IT

1400

Bruce

Ernst

60

IT

1400

David

Austin

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

Условия соединения синтаксически описываются следующим образом (заметьте, что типы соединения намеренно исключены из этого примера).

SELECT *

FROM имя_таблицы1 JOIN имя_таблицы2

ON имя_тоблицы1. столбец1 = имя_таблицы2.столбец2

{AND|OR} имя_таблицы1.столбецЗ = имя_таблицы2.столбец4

JOIN table_nameЗ

ON имя_таблицы1.столбецА = имя_таблицыЗ.столбецА

[{AND|OR} имя_таблицы1.столбецЗ = имя_таблицы2.столбец4

Для создания предложения JOIN с несколькими условиями используется оператор AND или OR.

КОНСТРУКЦИИ INNER JOIN

Бесспорно, конструкции INNER JOIN представляют собой наиболее распростра­ненную разновидность конструкции JOIN. С помощью этих конструкций осуществляется согласование строк по данным из одного или нескольких общих полей, как и в большинстве других конструкций JOIN, но в отличие от этого конструкция INNER JOIN возвращает только строки, согласованные по всем полям, которые обозначены как используемые для соединения. В предыдущих примерах в результирующий набор вошла по мень­шей мере один раз каждая строка, но на практике такая ситуация встречается редко.

Наиболее предпочтительный формат кода для конструкции INNER JOIN выглядит примерно таким образом:

SELECT *

FROM имя_таблицы1 INNER JOIN имя_таблицы2

ON имя_тоблицы1. столбец1 = имя_таблицы2.столбец2

{AND|OR} имя_таблицы1.столбецЗ = имя_таблицы2.столбец4

Отличительная особенность INNER JOIN состоит в том, что она возвращает только те строки, которые были согласованны по всем полям.

Пример 1:

SELECT departments.department_id, department_name, location_id, employee_id, first_name, last_name

FROM departments inner join employees

ON (departments.department_id = employees.department_id)

Рисунок №49 – Результат выборки

Рассмотрим еще один небольшой запрос, который позволяет ознакомиться с особенностя­ми конструкции JOIN:

Пример 2:

SELECT departments.department_id, department_name, location_id, employee_id, first_name, last_name

FROM departments inner join employees

ON (departments.department_id = employees.department_id)WHERE employee_id > 107

Рисунок №50 – Результат выборки из примера №2

Общие свойства конструкции INNER JOIN И КОНСТРУКЦИИ WHERE

До сих пор при описании особенностей конструкции INNER JOIN фактически за­трагивались только те концепции, которые применимы к соединениям любых других типов, поскольку принципы определения порядка расположения столбцов в результи­рующем наборе и применения псевдонимов являются полностью одинаковыми для конструкций JOIN любых типов. А то, в чем конструкция INNER JOIN отличается от конструкций JOIN других типов осталось не рассмотренным. Отметим, что ее помощью можно создавать исключительное со­единение, т.е. соединение, в котором исключены все строки, не имеющие опреде­ленного значения в обеих таблицах (в левой таблице, как называют таблицу, указанную в первую очередь, и в правой таблице, заданной во вторую очередь).

Рассмотрим несколько примеров того, как проявляется это свойство.

Допустим, что имеется таблица Departments, в которой собраны все данные о департаментах компании. Но наличие большого списка департаментов от­нюдь не означает, что на текущий момент в компании были увольнения во всех департаментах. Фактически можно смело предположить, что в текущий момент имеются такие департаменты, в которых не было увольнений. Например, требуется выполнить запрос, позволяющий отобрать информацию обо всех департаментах, в которых были увольнения.

Пример 3.

SELECT DISTINCT d.department_id, d.department_name

FROM departments d

inner join job_history j

on d.department_id=j.department_id

Рисунок №51 – Результат выборки из примера №3.

Обратите внимание на то, что в запросе используется ключевое слово DISTINCT, поскольку достаточно знать только количество департаментов, имевших уволенных сотрудников (причем достаточно только одно­го упоминания каждого департамента), а не количество увольнений. Если бы в этом запросе отсутствовало ключевое слово DISTINCT, то была бы возвращена отдельная строка, относящаяся к каждому департаменту для каждой строки из таблицы Jobs_History, в которой имеется информация об увольнениях в департаментах.

Теперь попытаемся получить информацию об общем количестве заказчиков и для этого вызовем на выполнение следующий простой запрос с агрегирующей функцией COUNT:

Пример 4.

SELECT COUNT (*) AS "No. Of Records" FROM departments

Рисунок №52 – Результат выборки из примера №4

Применение конструкции INNER JOIN приводит к исключению строк в связи с тем, что не обнаруживаются соответству­ющие им строки в другой таблице, а использование конструкции WHERE приводит к исключению строк из возвращаемого набора, поскольку эти строки не соответствуют сданным критериям.

Рассмотрим еще один пример – база данных имеет таблицы departments, Jobs и Employees (таблица 11).

Таблица 11 - Столбцы таблиц departments, Jobs и Employees.

Departments

Jobs

Employees

DEPARTMENT_ID

JOB_ID

EMPLOYEE_ID

DEPARTMENT_NAME

JOB_TITLE

FIRST_NAME

MANAGER_ID

MIN_SALARY

LAST_NAME

LOCATION_ID

MAX_SALARY

EMAIL

PHONE_NUMBER

HIRE_DATE

JOB_ID

SALARY

COMMISSION_PCT

MANAGER_ID

DEPARTMENT_ID

На этот раз нам предстоит задача составить запрос, который возвращает названия департаментов, входящих в компанию, и названия должностей, в компании. Прежде всего необходимо точно выяснить, какие данные должны быть получены из базы данных. В рассматриваемом задании речь идет о том, что должны быть воз­вращены два различных фрагмента информации — названия департаментов и названия должностей.

Теперь необходимо приступить к соединению двух указанных таблиц. Но для ИТОГО требуется найти столбец, по которому должно быть выполнено соединение. В связи с этим в ходе решения данной задачи возникает первая проблема - обнару­живается, что такой столбец отсутствует. Оказывается, что в этих двух таблицах нет общих столбцов, на которых можно было бы сформировать соединение с помощью конструкции JOIN. Теперь становится ясно, для чего нужна третья из таблиц, приведенных в таблице 6. Иногда соединения могут быть сформированы только с помощью такой таблицы, как employees, которая позволяет проложить связь между двумя другими таблицами. Для обозначения подобных таблиц, обеспечивающих возможность связать две другие таблицы, применяются разные термины, но чаще всего приходилось встречаться с терминами связующая таблица, или таблица ассоциации.

Связующей таблицей (иногда называемой также таблицей ассоциации, или таблицей сли­яния) называют любую таблицу, основным назначением которой является не хранение соб­ственных данных, а создание связей между данными, хранимыми в других таблицах. Такие таблицы можно рассматривать как средства "обеспечения взаимодействие", или "созда­ния связей" между двумя или несколькими таблицами. В частности, связующие таблицы позволяют найти выход в такой часто складывающейся ситуации, когда имеет место так называемая связь "многие ко многим" между таблицами. В такой ситуации две таблицы содержат связанные друг с другом данные, причем и в той и в другой таблице может на­ходиться большое количество строк, которые согласуются со многими строками в другой таблице. СУБД SQL Server не позволяет непосредственно реализовывать подобные свя­зи, поэтому применяются связующие таблицы, позволяющие разделить связь "многие ко многим" на две связи "один ко многим", а последние поддерживаются СУБД SQL Server.

Данная конкретная таблица, employees, не отвечает всем критериям определе­ния связующей таблицы в самом строгом смысле этого термина, но все же соответ­ствует общему назначению связующих таблиц, поэтому рассматривается именно как таковая. Применение указанной третьей таблицы, employees, позволяет косвенно соединить таблицы departments и jobs, фор­мируя соединения между каждой из этих таблиц и связующей таблицей. Соединение между таблицами departments и employees формируется на основе столбца department_id, a соединение между таблицами jobs и employees — на основе столбца job_id.

Введение указанной третьей таблицы в конструкции JOIN не составляет труда, этого достаточно снова указать в конструкции FROM таблицу, в которой находится требуемая информация, и задать ключевые слова JOIN.

Пример 5:

SELECT distinct d.department_name, j.job_title

FROM departments d

join employees e

on d.department_id = e.department_id join jobs j

on e.job_id = j.job_id

Рисунок №53 - Результат выборки из примера №5.

Обратите внимание на то, что таблицам присвоены псевдонимы, поэтому необ­ходимо вернуться в начало оператора и внести изменения в конструкцию SELECT с учетом использования псевдонимов, но на этом составление оператора SELECT с со­единением трех таблиц заканчивается.

КОНСТРУКЦИИ OUTER JOIN

Применение конструкции JOIN такого типа, как OUTER JOIN, скорее можно счи­тать исключением, а не правилом:

Чаще всего при выборке данных с использованием оператора соединения не­обходимо обеспечить, чтобы данные соответствовали всем заданным критери­ям, а этого позволяет добиться только конструкция INNER JOIN.

  • Многие разработчики, использующие язык SQL, осваивают лишь внутреннее соединение, осуществляемое с помощью конструкции INNER JOIN, но так и не заходят глубже; иными словами, многие разработчики просто не умеют пользо­ваться разновидностью оператора соединения с конструкцией OUTER.

  • Цели, которые позволяет достичь применение конструкции OUTER JOIN, часто достижимы с помощью других методов.

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

При использовании конструкции INNER JOIN исключают­ся все строки, не соответствующие всем заданным критериям, а при использовании конструкции OUTER существует возможность включить в результирующий набор строки, которые со­ответствуют хотя бы одному из заданных критериев.

Простой вариант оператора с конструкцией OUTER JOIN

Задача освоения первого варианта синтаксиса является несложной, и большин­ство разработчиков с ней успешно справляются:

SELECT *

FROM имя_таблицы1 LEFT|RIGHT OUTER JOIN имя_таблицы2

ON имя_тоблицы1. столбец1 = имя_таблицы2.столбец2

Следует отметить, что ключевое слово OUTER является необязательным, достаточно лишь включить ключевое слово LEFT или RIGHT (например, LEFT JOIN). Таблица, имя кото­рой упоминается перед ключевым словом JOIN, рассматривается как левая таблица, LEFT, а таблица, имя которой следует за ключевым словом JOIN, — как правая табли­ца, RIGHT.

Как уже было сказано, применение операторов с конструкцией OUTER JOIN приво­дит к получению не только тех данных, которые соответствуют всем критериям, но и данных, соответствующих лишь некоторым критериям, а то, какие именно строки, соответствующие лишь некоторым критериям, будут включены в результирующий на­бор, зависит от выбора той или иной стороны соединения. При использовании кон­струкции LEFT OUTER JOIN включается вся информация из таблицы, указанной слева ОТ ключевого слова JOIN, а при использовании конструкции RIGHT OUTER JOIN— вся информация из таблицы, указанной справа от этого ключевого слова. Рассмотрим практические примеры применения запросов с левым и правым внешним соедине­ниями, позволяющие лучше понять сказанное.

Предположим, что необходимо узнать, из каких департаментов состоит фирма, имеются ли уволенные, идентификационный номер сотрудника и занимаемой им должности. В базе данных находятся таблицы departments и job_history, которые определены следующим образом:

Departments

Job_history

DEPARTMENT_ID

EMPLOYEE_ID

DEPARTMENT_NAME

START_DATE

MANAGER_ID

END_DATE

LOCATION_ID

JOB_ID

DEPARTMENT_ID

Эти таблицы имеют общий столбец, department_id, поэтому можно попытаться непо­средственно выполнить их соединение. Оператор, составленный с применением обычной конструкции INNER JOIN, должен выглядеть примерно таким образом:

Пример 6:

SELECT d.department_id, department_name, job_id, employee_id

FROM departments d

inner join job_history jh

ON (d.department_id = jh.department_id)

Рисунок №54 - Результат выборки из примера №6.

Однако наше задание отнюдь нельзя назвать выполненным. Нам требовались ре­зультаты, в которых содержалась бы информация обо всех департаментах, а не только о тех, в которых были увольнения. Тем не менее выполнение данного запроса привело к получению только данных о департаментах компании, в которых были увольнения, а ответ на заданный вопрос не получен.

В действительности требуется такая конструкция, которая позволяет получить сведения обо всех департаментах. Для получения сведений о каждом департаменте, достаточно только изменить тип конструкции JOIN в запросе следующим образом:

Пример 7:

SELECT d.department_id, department_name, job_id, employee_id

FROM departments d

LEFT OUTER JOIN job_history jh

ON (d.department_id = jh.department_id)

Рисунок №55 - Результат выборки из примера №7.

Теперь рассмотрим, что произойдет после перехода к применению соединения типа RIGHT OUTER JOIN

Пример 8:

SELECT d.department_id, department_name, job_id, employee_id

FROM departments d

RIGHT OUTER JOIN job_history jh

ON (d.department_id = jh.department_id)

Рисунок №56 - Результат выборки из примера №8.

Даже несмотря на то, что эта модификация на первый взгляд кажется весьма не­значительной, фактически она приводит к резкому изменению состава результирую­щего набора. Если теперь оператор SELECT * будет выполнен применительно к таблице departments, то обнаружится, что в состав результатов запроса включены все строки из таблицы job_history, причем при наличии соответствующей строки в таблице departments отображается относящаяся к этой строке информация о должности. А во всех остальных слу­чаях столбцы, взятые из таблицы таблице job_history, заполняются NULL-значениями. Итак, если допустить, что таблица departments всегда будет упоминаться в запросе в первую очередь, а таблица таблице job_history — во вторую, то, чтобы получить информацию обо всех департаментах, нужно использовать конструкцию LEFT JOIN, а для ознакомления с инфор­мацией обо всех увольнениях - конструкцию RIGHT JOIN.

Просмотр содержимого таблиц, находящихся с обеих сторон от операции соединения, с помощью КОНСТРУКЦИИ FULL JOIN

Как и многие конструкции в языке SQL, конструкция FULL JOIN (применяемая также в форме FULL OUTER JOIN) по существу выполняет именно то действие, о ко­тором говорит ее название, — эта конструкция согласует данные в таблицах, имена которых находятся по обе стороны от ключевого слова JOIN, и вводит в окончатель­ные результаты все строки, независимо от того, с какой стороны соединения они определены.

Конструкции FULL JOIN относятся к числу тех языковых средств, которые вызы­вают восхищение во время их изучения, но в дальнейшем почти не применяются. Основное назначение этой конструкции состоит в том, что она позволяет увидеть полную связь между данными в таком виде, в котором не дается преимущество ни левой, ни правой стороне. Эта конструкция применяется, если есть необходимость ознакомиться с каждой строкой всех таблиц, вводящихся по обе стороны от ключевого слова JOIN, без каких-либо исключений. По-видимому, если одно и то же соединение может быть применено и в форме левого, и в форме правого соединения, то лучше всего использовать полное соединение, имеющее форму конструкции FULL JOIN. Эта конструкция не только дает возможность получить все согласующиеся строки с учетом того поля (полей), на котором основано соединение, но и те строки, которые имеются только в таблицах, находящихся на левой стороне, притом что столбцы, относящиеся к правой стороне заполняются NULL-значениями. Наконец, та же операция возвращает все строки, имеющиеся только в таблицах, заданных с правой стороны, а вместо значений полей таблиц, относящихся к левой стороне, подставляются NULL-значения.

Вначале выполним соединение двух первых таблиц с использованием конструкции FULL JOIN:

Пример 9:

SELECT d.department_id, department_name, job_id, employee_id

FROM departments d

FULL OUTER JOIN job_history jh

ON (d.department_id = jh.department_id)

Рисунок №57 - Результат выборки из примера №9.

Введем еще одну конструкцию JOIN:

Пример 10:

SELECT d.department_id, department_name, jh.job_id, employee_id, j.job_title

FROM departments d

FULL OUTER JOIN job_history jh

ON (d.department_id = jh.department_id)

FULL JOIN jobs j

on (jh.job_id = j.job_id)

Рисунок №58 - Результат выборки из примера №10.

Теперь в нашем распоряжении имеется оператор, позволяющий получить из рас­сматриваемых таблиц всю имеющуюся в них информацию.

Конструкция CROSS JOIN

Операторы с конструкциями CROSS JOIN обладают действительно необычными особенностями. Соединения CROSS JOIN отличаются от соединений других типов тем, что в них отсутствуют операции ON, а также тем, что в них происходит соедине­ние каждой строки таблиц, находящихся с одной стороны от ключевого слова JOIN, с каждой строкой таблиц, находящихся с другой стороны от ключевого слова JOIN. Короче говоря, в конечном итоге формируется декартово произведение всех строк, заданных по обе стороны от ключевого слова JOIN. Операторы с конструкцией CROSS JOIN имеют такой же синтаксис, как и любые другие операторы JOIN, за ис­ключением того, что в них используется ключевое слово CROSS (вместо INNER, OUTER или FULL), а операция ON отсутствует. Ниже приведен краткий пример.

Пример 11:

SELECT d.department_id, department_name, jh.job_id, employee_id

FROM departments d

CROSS JOIN job_history jh

Рисунок №59 - Результат выборки из примера №11.

Чаще всего формирование базы данных осуществляется с учетом того, что эта база войдет в состав более крупномасштабной системы, требующей существенной проверки. А при тестировании систем большого масштаба снова и снова возникает проблема, связанная с высокой трудоемкостью создания больших объемов данных, применяемых при испытаниях. Использование операции CROSS JOIN открывает та­кую возможность, что могут быть созданы две или несколько таблиц с количеством строк испытательных данных, намного меньшим по сравнению с требуемым. После этого к таким промежуточным таблицам можно применить операторы CROSS JOIN для создания гораздо более крупных наборов испытательных данных.

Операция UNION

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

Формируя запросы? содержащие конструкцию UNION следуют руководствоваться следующим соображениями:

  • Все запросы, результаты которых объединяются, должны иметь одинаковое количество столбцов в списке выборки, иначе СУБД выдаст ошибку, не выполнив запрос.

  • Заголовки для столбцов результирующего запроса берутся только из формулировки первого запроса.

  • Типы данных каждого столбца, указанного в любом запросе, должны быть неявно совместимы с типами данных столбцов, занимающих такое же относительное положение в списках выборки других запросов.

  • В запросах с конструкцией UNION в отличие от обычных запросов применяется использование опции DISTINCT, а не ALL. Из-за этого иногда происходит путаница, т.к. DISTINCT удаляет все повторяющиеся строки данных в результирующем запросе.

Пример 12:

SELECT department_name

FROM departments

union select job_id

from employees

Рисунок №60 - Результат выборки из примера №12.

Однако, заметим в результирующей таблице присутствует только одна запись с фамилией Иванов, т.к. при применении операции UNION были удалены все повторяющиеся строки. Чтобы вывести все строки, добавим ключевое слово ALL после ключевого слова UNION.

Пример 13:

Рисунок №61 - Результат выборки из примера №13.