FULL OUTER JOIN
Повний зовнішнє з'єднання (FULL OUTER JOIN) є цілком включає. Воно повертає один рядок для кожної пари відповідних потоків і одну частково заповнений рядок для кожного рядка з кожного потоку, де відповідність не було знайдено. Дане з'єднання об'єднує поведінку правого і лівого з'єднань.
Мал. 22.4. Повний з'єднання
Ось оператор, який використовує ті ж вхідні потоки, що і наш приклад INNER JOIN:
FROM Table1 FULL JOIN Table2
ON Table1.PK = Table2.FK
На рис. 22.4 показано, як будуть об'єднані потоки для повного з'єднання.
перехресні з'єднання
Firebird не підтримує мовних елементів для перехресного з'єднання (CROSS JOIN), яке створює набір даних, що є декартовим твором двох таблиць. Тобто для кожного рядка лівого потоку вихідний потік буде містити кожен рядок з правого потоку. У рідкісних випадках, коли вам потрібно декартовій твір, ви можете використовувати синтаксис SQL-89 без будь-яких критеріїв з'єднання в реченні WHERE, наприклад:
SELECT T1. *, Т2. * FROM T1 TABLE1, T2 TABLE2;
Оброблювач запитів Firebird іноді внутрішньо створює перехресні з'єднання, коли конструює "річки" в процесі з'єднання операцій (див. Розд. "Теми оптимізації" цієї глави).
природні сполуки
Firebird не підтримує природне з'єднання (NATURAL JOIN), також відоме як еквісоедіненія (EQUI JOIN), яке створює набір даних, пов'язуючи два потоку на основі відповідності стовпців, що використовують загальні ідентифікатори стовпців з однаковими значеннями. В Firebird ви завжди повинні вказувати умови з'єднання.
Двозначність в запитах JOIN
У різних книгах по теорії баз даних сказано, що двозначність може існувати, тільки коли деякі імена стовпців з'являються в декількох потоках. Людина, практично працює з базами даних, може розповісти іншу історію. Питання усунення двозначності відпадає в залежності від способу, яким сервер бази даних реалізує синтаксичний розбір, створення потоків і сортування, які виконуються в процесі операції з'єднання.
InterBase був поблажливий до відхилень від недвозначності в синтаксисі з'єднань - іноді з невдалими результатами. Якщо ви переносите існуючий код вашої програми, який працював з InterBase, не лякайтеся винятків SQL, які видасть Firebird в процесі першого тестового виконання запитів з сполуками. Він покаже вам місця в вашому коді, де раніше допускалося виконання запитів, які могли повертати невірні результати.
Firebird не прийме запити з'єднання, які містять посилання на стовпці, які не мають повного кваліфікатора таблиці. Кваліфікатор таблиці може бути ідентифікатором таблиці або аліасом таблиці. Починаючи з версії 1.5 неприпустимо їх змішувати. Якщо ви використовуєте версію 1.0, будьте послідовні, якщо хочете уникнути переписування коду при переході на нові версії.
Попередні приклади використовували ідентифікатори таблиць. Використання алиасов таблиць елегантніше і компактно, а для деяких запитів (див. Розд. "Реєнтерабельним з'єднання") є обов'язковим.
аліаси таблиць
Якщо ім'я таблиці довге або заплутане, або якщо існує багато таблиць, використання алиасов таблиць буде корисним (і в деяких випадках необхідне) для більшої ясності операторів. Оброблювач запиту трактує алиас таблиці як синонім таблиці, яку алиас представляє. Аліаси таблиць обов'язкові в запитах, які формують безліч потоків з однієї і тієї ж таблиці.
ПОРАДА. У базі даних діалекту 3, яка була створена з використанням обмежених ідентифікаторів (delimited identifiers), комбінованих з символами в нижньому регістрі або при змішуванні регістрів в іменуванні об'єктів і / або з використанням "неправильних символів", написання запитів може стати досить виснажливим заняттям, часто породжує помилки, якщо не використовуються аліаси.
Аліас може бути використаний скрізь, де він допустимо для позначення імені таблиці, як кваліфікатор; імена всіх таблиць повинні бути замінені на аліаси. Змішування ідентифікаторів таблиць з аліасами в одному і тому ж запиті призведе до винятків в Firebird 1.5 і наступних версіях.
Наступний приклад використовує ідентифікатори таблиць:
AND С.SALESMAN_ID = '44'
Допустимі імена алиасов таблиць
Використовуйте будь-який рядок, що містить до 31 символу, які допустимі для імен метаданих (т. Е. Алфавітно-цифрові символи в кодуванні ASCII в діапазонах 35-38, 48-57, 64-90 і 97-122). Прогалини, діакритичні знаки, імена, укладені в лапки, і імена, що починаються з цифри, неприпустимі.
внутрішній курсор
Мал. 22.5. Внутрішній курсор для з'єднання двох таблиць
реєнтерабельним з'єднання
Умови проектування іноді вимагають формування об'єднаного набору з двох або більше потоків, які надходять з однієї і тієї ж таблиці. Часто таблиця проектується з ієрархічною, або деревовидної, структурою, де кожен рядок в таблиці логічно є нащадком батька в тій же таблиці. Первинний ключ таблиці вказує на вузол дерева рівня нащадка, в той час як колонка зовнішнього ключа зберігає батьківський ключ, що посилається на значення первинного ключа в іншому рядку.
Запит на "вирівнювання" відносини батько-нащадок вимагає з'єднання, яке витягує один потік для батьків, а інший - для нащадків з тієї ж таблиці. Звичайний термін для цього - посилається на себе з'єднання. Термін реєнтерабельним з'єднання морфологічно є більш відповідним, т. К. Існують інші типи реєнтерабельним запитів, які не використовують з'єднань. Пізніше в цій главі в розд. "Підзапити" обговорюються інші типи реєнтерабельним запитів.
Курсори для реєнтерабельним з'єднань
Для виконання реєнтерабельним з'єднання сервер підтримує один внутрішній курсор для кожного потоку в межах образу однієї таблиці. Концептуально він трактує контексти двох курсорів, як якщо б вони були окремими таблицями. У цій ситуації синтаксис посилань на таблицю обов'язково використовує аліаси для розрізнення курсорів двох потоків.
У наступному прикладі кожен підрозділ організації зберігається з батьківським ідентифікатором, який вказує на первинний ключ його керівного підрозділу. Наведений далі запит трактує підрозділи і батьківські підрозділи, як якщо б вони були двома таблицями:
D1.DESCRIPTION AS DEPARTMENT,