Любая запись в одной таблице может быть связана с любой записью другой таблицы. Система управления базой данных, используемая в комплексе, позволяет организовать несколько различных типов связей между таблицами.
Связь "Один к одному"
Этот тип связи используется редко, обычно с целью оптимизации работы базы данных.
Например, чтобы постоянно "не таскать" все данные о сотруднике (а их достаточно много), таблица "Сотрудники" разбита на две - "Сотрудники " и "Сотрудники (расширение) ". Записи этих таблиц связаны между собой отношением "один к одному ". Для организации такой связи в обе таблицы помещается поле, содержащее адрес записи другой таблицы. Получается следующая схема:
Рис. 6-7 – Пример связи "Один к одному"
Связь "Один ко многим"/ "Многие к одному"
Данный тип связи является одним из самых распространённых.
Например, организации относятся к документам, как один ко многим. То есть одной организации соответствует несколько документов. Еще пример, наименования накладной относятся к накладной как многие к одному.
Реализуется этот тип связи следующим образом:
В таблице со стороны "один" помещается поле нулевой длины;
В таблице со стороны "многие" помещается поле, содержащее адрес связанной записи; в этой же таблице строится индекс по полю связи.
Например, связь таблицы "Документы" с таблицей "Организации" выглядит примерно так:
Рис. 6-8 – Пример связи "Один ко многим"
Условная связь
Очень часто у нескольких сущностей часть атрибутов одинакова, а часть различна. К примеру, документы всегда содержат номер и дату, но у накладной и акта приемки ОС есть, очевидно, и разные параметры. В таких случаях удобно использовать условную связь. Фактически, это отношение "один к одному" по условию.
Итак, есть таблица, в которой находятся общие части, и несколько таблиц, содержащих специальные для каждого типа данные. В таблице с общими данными помещается поле, содержащее адрес записи и номер таблицы (1 байт), в котором эту запись искать. В ответных таблицах есть просто поля с адресом записи.
В нашем примере общей является таблица "Документы", которая по условной связи связана с таблицами "Складские документы" и "Платёжные документы".
Иерархия
Это несколько специфичная связь, поскольку в ней участвует только одна таблица. Фактически это отношение записей "один ко многим", но внутри одной таблицы.
В таблицу помещается поле, содержащее адрес записи‑узла иерархии, в котором находится данная запись (4 байта) и, возможно, один байт, указывающий, является ли сама запись узлом (значение - 00 ) или листом (значение - FF ) иерархии. Напомним, что узел - это запись, на которую могут ссылаться другие записи, а лист - это запись, на которую не ссылается никакая другая запись иерархии. Например, в справочнике организаций раздел справочника - это узел, а карточка организации - это лист.
Записи, находящиеся в "корне " иерархии (то есть в самом верхнем уровне), содержат вместо адреса узла специальное зарезервированное значение - FFFFFFF6 (корень).
В программе Jinnee.exe узел иерархии помечается буквой "у " после адреса связанной записи. Если же запись ссылается на "корень" иерархии, то вместо шестнадцатеричного адреса будет стоять строка "корень ".
ERwinподдерживает следующие основные типы связей:
идентифицирующая/неидентифицирующая,
многие-ко-многим.
Идентифицирующая и неидентифицирующая связи
Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Дочерняя сущность при идентифицирующей связи всегда является зависимой.
Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Дочерняя сущность при неидентифицирующей связи обычно является относительно независимой от родительской.
Идентифицирующая связь изображается сплошной линией; неидентифицирующая – пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.
Таким образом, связи определяют, является ли сущность независимой или зависимой.
Связи типа «один-ко-одному», «один-ко-многим», «многие ко-многим»
Связи между сущностями могут быть типа
один-ко-одному;
один-ко-многим;
многие ко-многим.
Связь один-ко-одному означает, что один экземпляр первой сущности связан с одним экземпляром второй сущности и, наоборот, один экземпляр второй сущности связан с одним экземпляром первой сущности. Обычно такая связь возникает, когда одна сущность искусственно делится на две сущности.
Связь один-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности и один экземпляр второй сущности связан с одним экземпляром первой сущности. Причем первая сущность называется главной, а вторая – подчиненной.
Связь многие-ко-многим означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности и, наоборот, один экземпляр второй сущности связан с несколькими с несколькими экземплярами второй сущности. Связь многие ко многим обычно используются на начальной стадии разработки диаграммы и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах.
Так как отношения многие ко многим могут скрыть другие бизнес правила или ограничения, они должны быть полностью исследованы на одном из этапов моделирования. Например, иногда отношение многие ко многим на ранних стадиях моделирования идентифицируется неправильно, на самом деле представляя два или несколько случаев отношений один-ко-многим между связанными сущностями. Или, в случае необходимости хранения дополнительных сведений о связи многие-ко-многим, например, даты или комментария, такая связь должна быть заменена дополнительной сущностью, содержащей эти сведения. При моделировании необходимо быть увереным в том, что все отношения многие ко многим будут подробно обсуждены на более поздних стадиях моделирования для обеспечения правильного моделирования отношений.
Имя связи
Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями.
Для связи «один ко многим» достаточно указать имя, характеризующее отношение между родительской и дочерней сущности (Parent-to-Child).
Для связи «многие ко многим» следует указывать имя как Parent-to-Child, так иChild-to-Parent.
Мощность связи
Мощность связи (Cardinality) служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают 4 типа мощности, показанные на рис П5:
общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом;
символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
символом Zпомечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.
Рис. П5. Типы мощности
Примечание:
Во всех статьях текущей категории уроков по SQL используются примеры и задачи, основанные на учебной базе данных.
Практически всегда БД не ограничивается одной таблицей. Сложно представить себе какой-либо бизнес-процесс на предприятии, который мог бы сконцентрироваться только на одном предмете в плане информации.
Рассмотрим пример учебной базы данных. Имеется отдел, который занимается обработкой звонков, поступающих на различные линии. Линии обслуживаются конкретными операторами. Операторы состоят в разных группах под присмотром супервайзеров.
Только из данного краткого описания можно выделить несколько самостоятельных объектов:
- Телефонные линии обслуживания;
- Сотрудники отдела;
- Должности сотрудников;
- Группы, по которым распределены сотрудники;
- Звонки.
Ознакомившись с диаграммой базы данных, можно обратить внимание на то, что некоторая информация из одних таблиц присутствует в других, т.е. между ними имеются связи.
В нашем конкретном случае, все таблицы можно соединить между собой. Чтобы понять, как это правильно сделать, необходимо рассмотреть типы связей.
Логику соединения таблиц в БД важно понять с самого начала изучения SQL, так как наверняка Вы не будете писать запросы только к одной таблице.
Всего существует 3 типа связей:
Примечание:
В данном материале обозначения связей приводятся на примере MS SQL Server. В иных СУБД они могут обозначаться по-разному, но у Вас не должно возникнуть проблем с определением их типа, т.к. они либо очень похожи, либо интуитивно понятны.
Связь «Один к одному»
Связь один к одному образуется, когда ключевой столбец (идентификатор) присутствует в другой таблице, в которой тоже является ключом либо свойствами столбца задана его уникальность (одно и тоже значение не может повторяться в разных строках).
На практике связь «один к одному» наблюдается не часто. Например, она может возникнуть, когда требуется разделить данных одной таблицы на несколько отдельных таблиц с целью безопасности.
В учебной безе данных нет подходящего примера, но гипотетически могла бы существовать необходимость разделения таблицы сотрудников.
Пример:
Представьте, что базой данных пользуются несколько менеджеров и аналитиков, а таблица «Сотрудники» содержит те же столбцы, что и учебная база. Следовательно, доступ к персональным данным может получить любой из упомянутых работников.
Чтобы устранить возможность утечки конфиденциальной информации, принимается решение о переносе информации паспортных данных в отдельную таблицу, доступ к которой предоставляется ограниченному кругу лиц.
Связь «Один ко многим»
В типе связей один ко многим одной записи первой таблицы соответствует несколько записей в другой таблице.
Рассмотрим связь учебной базы данных между должностями и сотрудниками, которая относится к рассматриваемому типу.
Записи должностей в таблице «Должность» уникальны, так как нет смысла повторно создавать имеющуюся запись. Записи в таблице «Сотрудники» также уникальны, но несколько различных сотрудников могут находиться на одинаковой должностной позиции.
Символ ключа на конце связи указывает, что таблица, к которой этой конец прилегает, находится на стороне «один» (связанный столбец является первичным ключом), а символ бесконечности находится на стороне «многие» (такой столбец является внешним ключом ).
Связь «Многие ко многим»
Если нескольким записям из одной таблицы соответствует несколько записей из другой таблицы, то такая связь называется «многие ко многим» и организовывается посредством связывающей таблицы.
В нашей базе подобное наблюдается только между таблицами с сотрудниками и линиями.
Из диаграммы видно, что имеются две связи «один ко многим» (один сотрудник может обрабатывать несколько телефонных линий, и одну линию могут обрабатывать несколько сотрудников), но в совокупности они образуют связь «многие ко многим».
Для чего все это нужно?
Связи выполняют более важную роль, чем просто информация размещения данных по таблицам. Прежде всего они требуются разработчикам для поддержания целостности баз данных.
Правильно настроив связи, можно быть уверенным, что ничего не потеряется.
У Вас недостаточно прав для комментирования.
Иногда при работе с базой данных возникает потребность получить не полную, а частичную информацию об интересующем объекте. Например, в базе данных «Университет» имеется полная информация о преподавателях, студентах, дисциплинах, успеваемости, материальной базе и др. Безусловно, вся эта информация связана между собой, образуя своеобразную цепь. Если потащить за одно звено, то можно вытащить всю цепь. То же можно сказать и об информации по электродвигателям. Полная информация содержит сведения об электрических параметрах, о конструктивных параметрах, о заводах-изготовителях, о стоимости и др.
Если все эти сведения размещать в одной сплошной таблице, то в случае потребности получения информации только об электрических параметрах интересуемого электродвигателя, будет выдана полная информация о нем. Это не всегда нужно. Чтобы исключить такие случаи, всю информацию разделяют на отдельные логически обоснованные части и для каждой из этих частей создают отдельную таблицу. Реально база данных должна хранить информацию о нескольких взаимосвязанных сущностях, образующих предметную область, то есть быть представленной набором связанных таблиц. Эта связь должна быть синхронной. Это означает, что если удаляется, например, тип двигателя в одной таблице, то удаляется вся связанная с ним информация во всех таблицах и наоборот, если добавляется в базу данных какой-то двигатель, то автоматически во все таблицы добавляется соответствующая информация о нем.
При проектировании таблиц и определении связей между ними используют способ нормализации. Этот способ позволяет разделить исходную, сплошную таблицу на ряд элементарных таблиц, между которыми устанавливаются связи. Такая совокупность связанных таблиц создает единую информационную цепь объекта. Вместе с тем, из этой цепи можно выбирать частичную информацию об объекте, хранимую в отдельной таблице. В то же время связи позволяют осуществить и обратный процесс «сборки» информации по информации одной из таблиц.
Нормализация - это пошаговый процесс замены одной таблицы (или набора таблиц) другими, имеющими более простую структуру. Способ нормализации опирается на теорию множеств и реляционной алгебры. На каждом этапе нормализации таблицы приводятся к виду, который называется нормальной формой.
Существует четыре вида связей (отношений между таблицами):
- один к одному,
- один ко многим,
- многие к одному,
- многие ко многим.
Связь один к одному означает, что каждой записи первой таблицы соответствует только одна, связанная с ней запись второй таблицы и наоборот . Такой тип отношений используется крайне редко, так как фактически все данные могут быть помещены в одной таблице. Он полезен тогда, когда одну громоздкую таблицу целесообразно разделить на две с логически сгруппированными полями. Например, в одной таблице разместить электрические параметры электродвигателя, а в другой - его конструктивные параметры.Такое деление используют тогда, когда в одну таблицу выносятся секретные или очень важные данные с ограниченным доступом.
Связь один ко многим характерна тем, что запись одной таблицы связана с несколькими записями другой таблицы. В то же время запись второй таблицы не может быть связана более чем с одной записью первой таблицы. Например, один покупатель приобретает в магазине несколько различных товаров, но один конкретный экземпляр товара не может быть продан одновременно нескольким покупателям (купит кто-то один).
Связь многие ко многим или непрямая табличная связь определяет связь одной записи первой таблицы с несколькими записями второй таблицы, в то же время как одна запись второй таблицы может быть связана с несколькими записями первой таблицы. На практике такой сложный вид связи между двумя таблицами реализуется через промежуточную (связующую) таблицу . Она позволяет заменить одну связь вида многие ко многим на две последовательные связи: многие к одному и один ко многим , которые реализуются проще.
Из двух связанных таблиц одна выступает в роли главной (первичной), а другая - в роли подчиненной (вторичной). Например, таблица Дисциплины содержит перечень дисциплин, которые преподаются различными преподавателями. Сведения о преподавателях содержаться в другой таблице Преподаватели . Здесь таблица Дисциплины играет роль главной, а таблица Преподаватели - подчиненной.
На рис. 21.2 приведены две таблицы Дисциплины и Преподаватели. В этом примере первичным ключом таблицы Дисциплины является Код дисциплины, а первичным ключом таблицы Преподаватели - Код преподавателя. Для установления связи между этими таблицами в подчиненную таблицу Преподаватели добавлено поле внешнего ключа , роль которого играет поле Код дисциплины таблицы Дисциплины.
Из этого рисунка видно, что дисциплину Информатика преподают два преподавателя Петров И. С. и Серов Г. Л., так как их коды соответственно 2 и 3 связаны с кодом 2 таблицы Дисциплины. Таким образом, реализована связь один ко многим, где одна дисциплина Информатика таблицы Дисциплины связана с двумя преподавателями Петровым И. С. и Серовым Г. Л., таблицы Преподаватели.
Конкретный набор всех таблиц, необходимых для хранения и поиска информации, образует структуру базы данных . Разработка и создание структуры базы данных представляет собой самый важный и самый сложный этап. Эту работу, как правило, поручают высококвалифицированным специалистам в этой области.
Главная таблица
Поле первичного ключа таблицы Дисциплины .
Подчиненная таблица
Внешний ключ Первичный ключ таблицы Преподаватели
Рис. 21.2 Пример связи типа один - ко - многим
Представляю Вашему вниманию вольный перевод статьи SQL for Beginners Part 3
Сегодня мы продолжаем наше путешествие в мире SQL и реляционных систем управления базами данных. В этой части мы научимся работать с несколькими таблицами связанными между собой. Сначала мы познакомимся с базовыми концепциями, а потом начнем работать с запросами JOIN в SQL.
Предыдущие статьи
Вступление
При проектировании базы данных, здравый смысл подсказывает нам, что мы должны использовать различные таблицы для разных данных. Пример: клиенты, заказы, записи, сообщения и т.д. Так же мы должны иметь взаимосвязи между этими таблицами. Например, клиент имеет заказы, а у заказа есть позиции (товары). Эти взаимосвязи должны быть отражены в базе данных. А также, когда мы получаем данные с помощью SQL, мы должны использовать определенные типы запросов JOIN, чтобы получить нужный результат.
Вот несколько типов отношений в базе данных. Сегодня мы рассмотрим следующие:
- Один ко многим и многие к одному
- Многие ко многим
- Связь с самим собой
Когда данные выбираются из нескольких связанных таблиц, мы будем использовать запрос JOIN . Есть несколько типов присоединения, мы познакомимся с этими:
- Cross Joins (Перекрестное соединение)
- Natural Joins (Естественное соединений)
- Inner Joins (Внутреннее соединений)
- Left (Outer) Joins (Левое (внешнее) соединение)
- Right (Outer) Joins (Правое (внешнее) соединение)
Также мы изучим предложения ON и USING .
Связь один к одному
Допустим есть таблица покупателей (customers):
Мы можем расположить информацию о адресе покупателя в другой таблице:
Теперь у нас есть связь между таблицами покупателей (Customers) и адресами (Addresses). Если каждый адрес может принадлежать только одному покупателю, то такая связь называется "Один к одному". Имейте ввиду, что такой тип отношений не очень распространен. Наша первоначальная таблица, в которой информация о покупателе и его адресе хранилась вместе, в большинстве случаев работает нормально.
Обратите внимание, что теперь поле с названием "address_id", в таблице покупателей, ссылается на соответствующую запись в таблице адресов. Оно называется внешним ключом (Foreign Key) и используется во всех видах связей в базе. Мы рассмотрим этот вопрос позже в этой статье.
Вот так можно отобразить отношения между покупателями и адресами:
Обратите внимание, что существование данных отношений не обязательно, например, может существовать запись о покупателе без связанной записи о его адресе.
Связь один ко многим и многие к одному
Этот тип отношений наиболее часто встречающийся. Рассмотрим такой сайт интернет магазина:
- У покупателей может быть несколько заказов.
- Заказ может содержать несколько товаров.
- Товары могут иметь описание на нескольких языках.
В этих случаях нам потребуется создать связь "Один ко многим". Пример:
Каждый покупатель может иметь 0 или более заказов. Но каждый заказ может принадлежать только одному покупателю.
Связь многие ко многим
В некоторых случаях требуется многочисленные связи по обе стороны отношений. Например, каждый заказ может содержать множество товаров. И каждый товар может присутствовать во многих заказах.
Для такой связи нам потребуется создать дополнительную таблицу:
Назначение таблицы "Items_Orders" только одно - создать связь "Многие ко многим" между товарами и заказами.
Так можно представить этот тип отношений:
Если добавить записи items_orders к диаграмме, то она будет выглядеть так:
Связь с собой
Такой тип используется когда у таблицы должны быть связь с собой. Допустим у Вас есть реферальная программа. Покупатели могут ссылаться на других покупателей на вашем сайте интернет магазина. Таблица может выглядеть так:
Покупатели 102 и 103 ссылаются на покупателя 101.
Этот тип похож на связь "Один ко многим", поскольку один покупатель может ссылаться на несколько покупателей. Это можно представить как древовидную структуру:
Один покупатель может ссылаться на одного покупателя, на нескольких покупателей, или вообще не ссылаться ни на одного.
Если Вы хотите создать связь внутри таблицы "многие ко многим", то потребуется создать дополнительную таблицу, такую же как и в предыдущей части.
Внешние ключи
Пока что мы говорили только о базовых вещах. Пришло время применить полученные знания на практике, используя SQL. В данной часть нам нужно понять, что из себя представляют внешние ключи.
В отношениях, обсуждаемых выше, у нас всегда было поле вида "****_id", которое ссылалось столбец в другой таблице. В нашем примере столбец customer_id, в таблице Orders, является внешним ключом:
В таких базах как MySQL есть два способа создания внешних ключей:
Задать внешний ключ явно
Создадим простую таблицу с покупателями:
CREATE TABLE customers (customer_id INT AUTO_INCREMENT PRIMARY KEY, customer_name VARCHAR(100));
Теперь создадим таблицу заказов, которая будет содержать вторичный ключ:
CREATE TABLE orders (order_id INT AUTO_INCREMENT PRIMARY KEY, customer_id INT, amount DOUBLE, FOREIGN KEY (customer_id) REFERENCES customers(customer_id));
Оба столбца (customers.customer_id и orders.customer_id) должны быть одного типа. Если у первого тип INT, то второй не должен быть типа BIGINT, например.
Пожалуйста, помните, что в MySQL полностью поддерживает внешние ключи только подсистема InnoDB. Другие подсистемы хранения данных позволяют определять внешние ключи без каких либо ошибок. Столбцы с внешними ключами индексируются автоматически, если явно не задать другой индекс.
Без явного объявления
Некоторые таблицы заказов могут быть созданы без явного определения внешнего ключа:
CREATE TABLE orders (order_id INT AUTO_INCREMENT PRIMARY KEY, customer_id INT, amount DOUBLE, INDEX (customer_id));
Когда данные получают запросом JOIN , Вы можете использовать столбец как внешний ключ, хотя база данных не знает о этих связях.
SELECT * FROM orders JOIN customers USING(customer_id)
Мы подошли к изучению запросов JOIN , которые обсудим далее в статье.
Отображение связей
В данный момент, моей любимой программой для проектирования баз данных и отображения связей является MySQL Workbench .
После того как Вы спроектировали базу данных, ее можно экспортировать в SQL и выполнить на сервере. Это очень удобно при создании больших и сложных баз данных.
Запросы JOIN
Чтобы получить связанные данные из базы данных следует использовать запросы JOIN .
Прежде чем мы начнем, давайте создадим для работы тестовые таблицы и данные.
CREATE TABLE customers (customer_id INT AUTO_INCREMENT PRIMARY KEY, customer_name VARCHAR(100)); CREATE TABLE orders (order_id INT AUTO_INCREMENT PRIMARY KEY, customer_id INT, amount DOUBLE, FOREIGN KEY (customer_id) REFERENCES customers(customer_id)); INSERT INTO `customers` (`customer_id`, `customer_name`) VALUES (1, "Adam"), (2, "Andy"), (3, "Joe"), (4, "Sandy"); INSERT INTO `orders` (`order_id`, `customer_id`, `amount`) VALUES (1, 1, 19.99), (2, 1, 35.15), (3, 3, 17.56), (4, 4, 12.34);
У нас есть 4 покупателя. У одного из них два заказа, у двоих по одному заказу, и у одного вообще нет заказов. Теперь давайте посмотрим какие виды запросов JOIN мы можем выполнять с этими таблицами.
Это вид JOIN запроса по-умолчанию, если не определено условие.
Результатом будет, так называемое, "Декартово объединение" таблиц. Это означает, что каждая строка из первой таблицы сопоставляется с каждой строкой второй таблицы. Т.к. в каждой таблице по 4 строки, мы получили в результате 16 строк.
Ключевое слово JOIN можно заменить на запятую, в этом случае.
Конечно такой результат почти бесполезен. Давайте взглянем на другие виды объединений.
При таком виде запроса JOIN таблицы должны иметь совпадающие, по имени, столбцы. В нашем случае в обеих таблицах должен присутствовать столбец customer_id. MySQL объединит записи только в случае совпадения значений в этих столбцах.
Как Вы можете видеть, в этот раз столбец customer_id отображаются только один раз, потому что движок базы рассматривает этот столбец как общий. Мы видим два заказа Adam"а, и другие два заказа Joe и Sandy. Наконец мы получили некоторую полезную информацию.
Если условие объединения не указан, то выполняется внутреннее объединение. В этом случае хорошей идеей будет наличие совпадений по полю customer_id в обеих таблицах. Результат должен быть аналогичен естественному объединению.
Результат почти такой же. Столбец customer_id повторяется два раза, по разу для каждой таблицы. Объясняется это тем, что мы попросили базу сравнить значение по двум столбцам. При этом не знаю, что возвращают одну и туже информацию.
Добавим побольше условий к запросу.
На этот раз возвращается только те заказы, сумма которых превышает $15.
Предложение ON
Прежде чем перейти к другим видам объединяющих запросов, нам нужно рассмотреть предложение ON . Оно служит для вставки условий JOIN в отдельные предложения.
Теперь мы можем различать условия, относящиеся к JOIN и условия в части WHERE . Но еще есть небольшая разница в функционировании. Мы увидим это, когда перейдем к примерам с LEFT JOIN .
Предложение USING
Предложение USING немного похоже на конструкцию ON . Если столбцы в таблицах называется одинаково, можно указать их здесь.
На самом деле это очень похоже на NATURAL JOIN , т.е. объединяющий столбец (customer_id) не повторяется дважды.
LEFT JOIN это вид внешнего соединения. В следующем запросе, если не найдены совпадения во второй таблице, записи из первой таблице все равно отобразятся.
Хотя у Andy и нет заказов, эта запись все равно отображается. Значение из второй таблицы равно NULL.
Это полезно, когда нужно найти записи, у которых нет связей. Например, мы можем найти всех покупателей, которые ничего не заказывали.
Все что мы сделали - нашли все значения NULL для order_id.
Отметим, что ключевое слово OUTER не обязательно. Вы можете использовать просто LEFT JOIN вместо LEFT OUTER JOIN .
Условия
Теперь давайте посмотрим на запросы с условиями.
Так, что случилось с Andy и Sandy? LEFT JOIN подразумевает, что мы должны получить покупателей, у которых нет заказов. Проблема в том, что условие WHERE скрывает эти результаты. Чтобы получить их, мы можем попытаться включить условие с NULL.
Появился Andy, но нет Sandy. Выглядит неправильно. Для того чтобы получить то, что мы хотим, нужно использовать предложение ON .
Теперь мы получили всех, и все заказы более $15. Как я говорил ранее, предложение ON иногда работает не так как WHERE . В таких внешних объединениях как это, столбцы включаются всегда, даже если нет совпадений в условии предложения ON .
Объединение RIGHT OUTER JOIN работает также, только порядок таблиц меняется на обратный.
На этот раз мы не получили результатов с NULL, потому что каждый заказ имеет сопоставление с записью покупателя. Мы можем поменять порядок таблиц и получим тот же результат, что и с LEFT OUTER JOIN .
Теперь у нас появились значения NULL, потому что таблица покупателей с правой стороны от объединения.
Заключение
Спасибо за чтение статьи. Надеюсь Вам понравилось!
