Різниця між об'єднанням тета, еквіджойн та природним з'єднанням


95

У мене проблеми з розумінням реляційної алгебри, коли йдеться про тета-об’єднання, екві-об’єднання та природні об’єднання. Чи може хтось допомогти мені краще зрозуміти це? Якщо я використовую знак = на об'єднанні тета, це точно так само, як просто використання природного об'єднання?


повторна цитата, про яку йдеться з баунті ... він там не цитує Кодда, він цитує мою відповідь, що його коментар з'являється під.
heisenberg

Відповіді:


141

Тета приєднатися допускає довільні відносини порівняння (таких як ≥).

Еквісоедіненія є тета приєднатися з допомогою оператора рівності.

Природне з'єднання є еквісоедіненія атрибутів , які мають таке ж ім'я , в кожному відносинах.

Крім того, природне об’єднання видаляє повторювані стовпці, що беруть участь у порівнянні рівності, тому залишається лише 1 з кожного порівняного стовпця; в грубій реляційній алгебраїчній формі: ⋈ = πR,S-as ○ ⋈aR=aS


13
природне об’єднання видалить однойменні стовпці
Богдан Гаврил MSFT

2
Всі вони, або всі, крім одного?
Крістофер Шроба

Equijoin також видалить стовпець рівності, якщо вони мають однакові назви в обох таблицях.
Vishal R

1
@outis, Що означає "theta" у "theta join"?
Пейс’єр

2
@Pacerier: Історично thetaприєднання in theta стосується довільної умови, яка використовується як критерій приєднання. (див. Системи баз даних: Повна книга Гарсії-Моліни, Уллман, Відом, глава 2, Theta Join)
Рам Раджамоні,

57

Хоча відповіді, що пояснюють точні відмінності, прекрасні, я хочу показати, як реляційна алгебра перетворюється на SQL і яке фактичне значення мають 3 поняття.

Ключовим поняттям у вашому запитанні є ідея приєднання. Щоб зрозуміти об'єднання, потрібно зрозуміти декартовий продукт (приклад заснований на SQL, де еквівалент називається перехресним з'єднанням, як вказує onedaywhen);

На практиці це не дуже корисно. Розглянемо цей приклад.

Product(PName, Price)
====================
Laptop,   1500
Car,      20000
Airplane, 3000000


Component(PName, CName, Cost)
=============================
Laptop, CPU,    500
Laptop, hdd,    300
Laptop, case,   700
Car,    wheels, 1000

Декартовим продуктом Продукт x Компонент буде - скрипка нижче або sql . Ви бачите, що існує 12 рядків = 3 х 4. Очевидно, що рядки на зразок "Ноутбук" із "колесами" не мають ніякого значення, саме тому на практиці декартовий продукт використовується рідко.

|    PNAME |   PRICE |  CNAME | COST |
--------------------------------------
|   Laptop |    1500 |    CPU |  500 |
|   Laptop |    1500 |    hdd |  300 |
|   Laptop |    1500 |   case |  700 |
|   Laptop |    1500 | wheels | 1000 |
|      Car |   20000 |    CPU |  500 |
|      Car |   20000 |    hdd |  300 |
|      Car |   20000 |   case |  700 |
|      Car |   20000 | wheels | 1000 |
| Airplane | 3000000 |    CPU |  500 |
| Airplane | 3000000 |    hdd |  300 |
| Airplane | 3000000 |   case |  700 |
| Airplane | 3000000 | wheels | 1000 |

РЕЄСТРАЦІЇ тут, щоб додати більше цінності цим продуктам. Насправді ми хочемо «приєднати» товар до пов'язаних з ним компонентів, оскільки кожен компонент належить до товару. Це можна зробити за допомогою об'єднання:

Продукт JOIN Component ON Pname

Пов’язаний запит SQL буде таким (ви можете пограти з усіма прикладами тут )

SELECT *
FROM Product
JOIN Component
  ON Product.Pname = Component.Pname

і результат:

|  PNAME | PRICE |  CNAME | COST |
----------------------------------
| Laptop |  1500 |    CPU |  500 |
| Laptop |  1500 |    hdd |  300 |
| Laptop |  1500 |   case |  700 |
|    Car | 20000 | wheels | 1000 |

Зверніть увагу, що результат має лише 4 ряди, оскільки ноутбук має 3 компоненти, автомобіль - 1, а літак - жодного. Це набагато корисніше.

Повертаючись до ваших запитань, усі об’єднання, про які ви запитуєте, - це варіанти JOIN, який я щойно показав:

Natural Join = об'єднання (пропозиція ON) виконується у всіх стовпцях з однаковим ім'ям; він видаляє повторювані стовпці з результату, на відміну від усіх інших об’єднань; більшість СУБД (системи баз даних, створені різними постачальниками, такими як SQL Server Microsoft, MySQL Oracle та ін.), навіть не намагаються це підтримати, це просто погана практика (або навмисне вирішили не реалізовувати її). Уявіть, що розробник приходить і змінює назву другого стовпця в Продукт з Ціна на Вартість. Тоді всі природні об'єднання виконувались би за PName AND on Cost, в результаті виходило б 0 рядків, оскільки жодне число не збігається.

Theta Join = це загальне об’єднання, яке всі використовують, оскільки воно дозволяє вказати умову (речення ON у SQL). Ви можете приєднатися майже за будь-якої умови, яка вам подобається, наприклад, у Продуктах, у яких перші 2 букви схожі, або у яких інша ціна. На практиці це трапляється рідко - в 95% випадків ви приєднуєтесь за умови рівності, що веде нас до:

Equi Join = найпоширеніший, що використовується на практиці. Наведений вище приклад - приєднання. Бази даних оптимізовані для цього типу об’єднань! Протилежність рівномірного з'єднання є нееквівалентним, тобто коли ви приєднуєтесь за умови, відмінної від "=". Бази даних для цього не оптимізовані! Обидва вони є підмножинами загального тета-об'єднання. Природне з'єднання також є тета-об'єднанням, але умова (тета) є неявною.

Джерело інформації: університет + сертифікований розробник SQL Server + нещодавно завершив МОО "Вступ до баз даних" від Стенфорда, тому смію стверджувати, що я маю на увазі реляційну алгебру.


1
Ви використовуєте термін "декартовий продукт" дещо вільно. Продукт реляційного оператора призводить до відношення (спільно з усіма реляційними операторами!) CROSS JOINОперація в SQL приводить до виразу таблиці (рядки стовпців). Операція множин декартового добутку приводить до набору пар.
день, коли

1
Коли ви говорите "Бази даних", ви насправді маєте на увазі "СУБД", що є суттєвою відмінністю при розгляді "понять".
одного дня, коли

2
onedaywhen - дякую за всі корисні коментарі! відчуває себе оглядом коду :). Я виправив проблеми декартового продукту та СУБД. Я дотримуюся своєї думки, що природні об’єднання представляють лише академічний інтерес, і важливі СУБД, такі як SQL Server, не реалізують це навмисно - додавання умови явно веде до кращого розуміння та обслуговування коду. Пов’язане запитання: stackoverflow.com/questions/4826613/natural-join-in-sql-server
Богдан Гаврил MSFT

1
@HLGEM: можна навести подібні аргументи проти SELECT * FROM...(і, можливо, ви це робите). Але це в мові, воно є в кожному впровадженні SQL, і я часто його використовую (і я впевнений, що ви теж це робите!) Підказка: не весь код є виробничим кодом.
одного дня, коли

1
Справжня проблема "природного" об'єднаного стовпця полягає не в зміні імен, а в додаванні нових, які не повинні суперечити між усіма, можливо, об'єднаними таблицями в системі. Візьміть дуже поширені стовпці, такі як "ім'я", "опис", ... Використання "природного об'єднання" зробить їх об'єднаними, тоді як це створює нісенітницю, а інше суперечить бізнес-логіці та призводить до помилок. Так що так, "природне приєднання" небезпечно. Це змушує вас мати різні імена, за винятком (первинних / зовнішніх) ключових слів і втратити "інтервал між іменами".
LoganMzz

14

Відповідь @ outis хороша: стисла та правильна щодо стосунків.

Однак ситуація дещо складніша щодо SQL.

Розглянемо звичайну базу даних постачальників та деталей, але реалізовану в SQL:

SELECT * FROM S NATURAL JOIN SP;

поверне набір результатів ** зі стовпцями

SNO, SNAME, STATUS, CITY, PNO, QTY

З'єднати здійснюється на колонці з тим же ім'ям в обох таблицях, SNO. Зверніть увагу, що набір результатів має шість стовпців і містить лише один стовпець для SNO.

Тепер розглянемо тета-екзіоїн, де імена стовпців для об’єднання повинні бути явно вказані (плюс змінні діапазону Sта SPобов’язкові):

SELECT * FROM S JOIN SP ON S.SNO = SP.SNO;

Набір результатів матиме сім стовпців, включаючи два стовпці для SNO. Імена набору результатів - це те, що стандарт SQL називає "залежним від реалізації", але може виглядати так:

SNO, SNAME, STATUS, CITY, SNO, PNO, QTY

або, можливо, це

S.SNO, SNAME, STATUS, CITY, SP.SNO, PNO, QTY

Іншими словами, NATURAL JOINв SQL можна розглянути можливість видалення стовпців із дубльованими іменами із набору результатів (але, на жаль, повторювані рядки не видаляти - ви повинні пам'ятати, щоб змінити SELECTна SELECT DISTINCTсебе).


** Я не зовсім знаю, який результат SELECT * FROM table_expression;. Я знаю, що це не відношення, оскільки, крім інших причин, воно може мати стовпці з повторюваними іменами або стовпець без імені. Я знаю, що це не набір, оскільки, крім інших причин, порядок стовпців є значним. Це навіть не таблиця SQL або вираз таблиці SQL. Я називаю це результатом.


Те саме стосується JOIN ... USING(...).
Бенуа

Чому ви говорите "Я не зовсім знаю, що це результат SELECT * FROM table_expression;" ?
Pacerier

@Pacerier: е-м, бо я не знаю, що це! Востаннє я дивився, що стандарт SQL уникав визначення, що це таке. Я знаю, що це не (ні відношення, ні набір, ні таблиця, ні табличний вираз). Тож для зручності посилань я застосував власний термін „набір результатів”. Зауважимо, що в реляційній моделі результатом операції, що включає два відношення, є відношення. Для SQL AFAIK неможливо зробити еквівалентну заяву.
день, коли

11

Природний - це підмножина Equi, яка є підмножиною Theta.

Якщо я використовую знак = на об'єднанні тета, це точно так само, як просто використання природного об'єднання ???

Не обов’язково, але це був би екві. Природно, це означає, що ви відповідаєте всім однаково названим стовпцям.

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


Я підозрюю, що коли ви говорите "реляційні бази даних", я підозрюю, що ви маєте на увазі щось інше, наприклад "SQL".
onedaywhen

Робота, яка не є академічним середовищем, з реляційними базами даних, які не є SQL? То які продукти ви маєте на увазі?
день, коли

3
В оригінальній алгебрі Кодда природне з'єднання є основним типом з'єднання, тоді як екві- або тета- "з'єднання" є скороченням для NJ (наприклад, перехресний добуток) з наступним обмеженням. "Природне - це підмножина Екі, яка є підмножиною Тета", мабуть, це означає, що кожен НД також може бути виражений як ЕД або ТД. Я припускаю, що це правда, якщо σ 1 = 1 (A x B) вважається еквіод'єднанням, і в цьому випадку кожна операція реляційної алгебри може бути виражена як еквіод'єд у цій формі. Неоднозначність тут полягає в тому, що для RA існує більше одного можливого набору основних операторів.
nvogel

2
@EricFail: sqlvogel просто цитує відповідь кекекели, а не що-небудь від Кодда. Якщо ви хочете дізнатись більше про твори Кодда про приєднання (θ чи інше), ви можете спробувати "Реляційну модель для управління базами даних" або переглянути його бібліографію .
outis 05.03.13

1
... Питання, на яке ви посилаєтесь, має відповідь, яка наближається до того, що ви шукаєте, можливо, якомога ближче. Це посилання на реляційну повноту підмов мов бази даних . Стор. 10 описує зв’язок між θ, = та природними об’єднаннями (хоча природні не є суворо підмножинами = у формулюванні Кодда, а, швидше, проекцією = -’єднань).
outis 05.03.13

7

Theta Join: Коли ви робите запит на приєднання за допомогою будь-якого оператора (наприклад, =, <,>,> = тощо), тоді цей запит на приєднання потрапляє під Theta join.

Equi Join: Коли ви робите запит на приєднання, використовуючи лише оператор рівності, тоді цей запит на приєднання потрапляє під Equi join.

Приклад:

> ВИБЕРІТЬ * ІЗ Emp ПРИЄДНАЙТЕСЬ Відділ Увімкнути Emp.DeptID = Dept.DeptID;
> ВИБЕРІТЬ * ІЗ ВНУТРІШНЬОГО ПРИЄДНАННЯ Відділ ВИКОРИСТАННЯ (DeptID)
Це покаже:
 _________________________________________________
| Emp.Name | Emp.DeptID | Назва відділу | Dept.DeptID |
| | | | |

Примітка: Equi join також є тета-з'єднанням!

Natural Join: тип об’єднання Equi, який відбувається неявно шляхом порівняння всіх однакових стовпців імен в обох таблицях.

Примітка: тут результат об’єднання має лише один стовпець для кожної пари однакових іменованих стовпців.

Приклад

 ВИБЕРІТЬ * ВІД Emp НАТУРАЛЬНЕ ПРИЄДНАННЯ Відділ
Це покаже:
 _______________________________
| DeptID | Emp.Name | Назва відділу |
| | | |

1

Декартовий добуток двох таблиць дає всі можливі комбінації кортежів, як приклад з математики, перехресний добуток двох множин. оскільки багато разів є деякі непотрібні значення, які також займають непотрібний простір у пам'яті, тому тут виручають об'єднання, які дають комбінацію лише тих значень атрибутів, які є необхідними та мають значення.

внутрішнє об'єднання дає повторне поле в таблиці двічі, тоді як натуральне об'єднання тут вирішує проблему, просто фільтруючи повторювані стовпці та відображаючи його лише один раз. else, обидва працюють однаково. природне об'єднання є більш ефективним, оскільки воно зберігає пам'ять. Крім того, надмірності видаляються в натуральному об'єднанні.

З'єднання equi двох таблиць є таким, що вони відображають лише ті кортежі, які відповідають значенню в іншій таблиці. наприклад: нехай new1 та new2 будуть двома таблицями. якщо для запиту sql виберіть * з new1 приєднати new2 на new1.id = new.id (ідентичний стовпець у двох таблицях), то почніть з таблиці new2 і приєднайтесь, що відповідає ідентифікатору у другій таблиці. крім того, нерівневі об’єднання не мають оператора рівності, вони мають <,> та між оператором.

theta приєднання складається з усіх операторів порівняння, включаючи рівність та інших <,> операторів порівняння. коли він використовує оператор рівності (=), він відомий як equi join.


0

Природне приєднання: Природне приєднання може бути можливим, коли є принаймні один загальний атрибут у двох відносинах.

Theta Join: Theta join може бути можливим, коли двоє діють за певних умов.

Equi Join: Equi може бути можливим, коли двоє діють за умовою власного капіталу. Це один із видів тета-приєднання.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.