- •Содержание
- •1 Цель и порядок работы 134
- •1.1 Цель работы 134
- •1.2 Порядок выполнения работы 134
- •Введение
- •Системные требования к серверу базы данных
- •Требования к аппаратному обеспечению
- •Требования к программному обеспечению
- •Проверка выполнения системных требований
- •Инсталляция
- •Сеансы работы с базой данных
- •Советы по разрешению возникших проблем
- •Проверка правильности установки программного обеспечения и базы данных Oracle xe
- •Проверка работы служб, связанных с Oracle
- •Определение ключей
- •Внешний ключ может ссылаться на поля таблицы из другой схемы
- •Создание базы данных в графическом режиме. Создание таблиц в графическом режиме можно осуществить, выбрав в меню Object Browser-Create –Table (Рисунок №12)
- •1.1 Цель работы
- •1.2 Порядок выполнения работы
- •1.1 Цель работы
- •1.2 Порядок выполнения работы
- •Формирование условий отбора
- •Группировка данных
- •Группировка данных с помощью функций агрегирования
- •4 Контрольные вопросы
- •Лабораторная работа №5 Соединение таблиц и анализ данных.
- •1 Цель и порядок работы
- •1.1 Цель работы
- •1.2 Порядок выполнения работы
- •3. Задания для самостоятельной работы
- •4 Контрольные вопросы
- •Лабораторная работа №6 Представления в Oracle.
- •1 Цель и порядок работы
- •1.1 Цель работы
- •1.2 Порядок выполнения работы
- •1 Цель и порядок работы
- •1.1 Цель работы
- •1.2 Порядок выполнения работы
- •Способы именования ограничений
- •Ограничения ключей
- •Создание первичного ключа при создании таблицы
- •Создание первичного ключа на существующей таблице
- •Добавление внешнего ключа к существующей таблице
- •Coздание таблицы, ссылающейся на саму себя
- •3. Задания для самостоятельной работы
- •4 Контрольные вопросы
- •Лабораторная работа №8 Транзакции, пакеты и блокировки.
- •1 Цель и порядок работы
- •1.1 Цель работы
- •1.2 Порядок выполнения работы
- •Некоторые особенности выполнения транзакций в oracle:
- •Непротиворечивость считываемых данных
- •Непротиворечивость на уровне оператора.
- •Непротиворечивость на уровне транзакции.
- •Реализация блокирования
- •Виды блокировок:
- •Список рекомендованной литературы
4 Контрольные вопросы
Общая структура команды SELECT.
Где и для каких целей применяется выборка?
Как просмотреть результаты выборки?
Приведите примеры условий формирования условий отбора?
Перечислить операторы, которые могут применяться в предложении WHERE?
Дайте определения функции агрегирования.
Перечислить функции агрегирования, опишите их назначение?
Какое предложение применяется для сортировки данных выборки, условия его применения?
Каким образом осуществляется выборка из нескольких страниц?
Приведите пример создания таблицы на основе выборки.
Дайте определения триггеру.
Приведите примеры возможных триггеров?
Описать синтаксис набора команд создания триггеров?
Что необходимо учитывать при использовании триггеров?
Лабораторная работа №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 |
|
|
|
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.
