Хоча відповіді, що пояснюють точні відмінності, прекрасні, я хочу показати, як реляційна алгебра перетворюється на 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 + нещодавно завершив МОО "Вступ до баз даних" від Стенфорда, тому смію стверджувати, що я маю на увазі реляційну алгебру.