Natural Join - реляционная теория и SQL

Question

Этот вопрос возник из моих прочтений SQL и Реляционной теории CJ Date: Как написать точный код SQL и поисков соединений в Интернете (что включает в себя несколько публикаций здесь о ЕСТЕСТВЕННЫХ СОЕДИНЕНИЯХ об отсутствии поддержки SQL Server))

Так вот моя проблема ...

С одной стороны, в теории отношений естественные объединения - это единственные объединения, которые должны произойти (или, по крайней мере, крайне предпочтительны).

С другой стороны, в SQL не рекомендуется использовать NATURAL JOIN и вместо этого использовать альтернативные средства (например, внутреннее соединение с ограничением).

Является ли примирение этих:

• Натуральные объединения работают в настоящей СУБД. Однако SQL не может полностью воспроизвести реляционную модель, и ни одна из популярных СУБД SQL не является настоящей СУБД.

и / или

• Хороший / лучший дизайн таблицы должен устранить / минимизировать проблемы, которые создает естественное объединение.

Answer 1

ряд вопросов относительно вашего вопроса (даже если я боюсь, что я не отвечаю на все ваши вопросы),

"С одной стороны, в теории отношений естественные объединения - это единственные объединения, которыедолжно произойти (или, по крайней мере, крайне предпочтительны). "

Похоже, что вы интерпретируете теорию так, будто она запрещает" другие виды "объединений ... Это не совсем так.Реляционная теория не говорит: «у вас не может быть антисоединений», «вы никогда не должны использовать антисоединения», или что-то в этом роде.Что он говорит, так это то, что в реляционной алгебре можно идентифицировать набор примитивных операторов, в которых естественное соединение является единственным оператором, подобным соединению.Все остальные операторы, подобные соединению, всегда могут быть эквивалентно выражены через определенные примитивные операторы.Например, декартово произведение является частным случаем естественного объединения (где набор общих атрибутов пуст), и если вы хотите, чтобы декартово произведение двух таблиц, у которых do было общее имя атрибута,Вы можете решить эту проблему, используя RENAME.Например, Semijoin - это естественное соединение первой таблицы с некоторой проекцией на вторую.Например, Antijoin (SEMIMINUS или NOT MATCHING в книге Дейта) - это реляционная разница между первой таблицей и SEMIJOIN из двух.и т. д. и т. п.

"С другой стороны, в SQL не рекомендуется использовать NATURAL JOIN и вместо этого использовать альтернативные средства (например, внутреннее объединение с ограничением)."

Где рекомендуются такие вещи?В стандарте SQL?Я так не думаю.Важно различать язык SQL как таковой, который определяется стандартом ISO, и некоторую (/ любую) конкретную реализацию этого языка, созданную каким-то конкретным поставщиком.Если Microsoft советует своим клиентам не использовать NJ в SQL Server 200x, то этот совет имеет совершенно иной смысл, нежели совет кого-либо вообще не использовать NJ в SQL.

"Естественные объединения работают в настоящей СУБД.Однако SQL не может полностью воспроизвести реляционную модель, и ни одна из популярных СУБД SQL не является истинной СУБД. "

Несмотря на то, что сам по себе SQL не в состоянии точно соответствовать реляционной теории, на самом деле очень малоделать с вопросом NJ.

Дает ли реализация 1020 * хорошую производительность для вызовов NJ, является характеристикой этой реализации , а не языка или«степень достоверности» «R» в «RDBMS».Очень легко построить TRDBMS, которая не использует SQL, и которая дает нелепые времена выполнения для NJ.Язык SQL сам по себе имеет все необходимое для поддержки NJ.Если реализация поддерживает NJ, то NJ будет работать и в этой реализации.Дает ли она хорошую производительность, является характеристикой этой реализации, и низкую производительность какой-то конкретной реализации не следует «экстраполировать» на другие реализации или рассматривать как характеристику языка SQL как такового.

»Хороший / лучший дизайн таблицы должен устранить / минимизировать проблемы, которые создает естественное объединение. "

Проблемы, которые создает естественное объединение?Управление столбцами, которые появляются в аргументах объединения, легко выполняется путем добавления явных проекций (и, при необходимости, переименования) в нужные столбцы.Так же, как вы также хотите избегать SELECT *, насколько это возможно, по той же причине ...

Answer 2

Во-первых, выбор между теорией и практичностью является ошибкой. Цитируя Криса Дейта: «Истина в том, что теория - по крайней мере, теория, о которой я здесь говорю, а именно теория отношений - действительно определенно очень практична».

Во-вторых, учтите, что естественное объединение зависит от именования атрибутов. Пожалуйста (перечитайте) прочитайте следующие разделы Точного кода SQL книга:

6,12. Опора на имена атрибутов. Существенная цитата:

Операторы реляционной алгебры ... все сильно зависят от атрибута именование.

3,9. Наименование столбцов в SQL. Существенная цитата:

Сильная рекомендация:… если два столбца в SQL представляют «один и тот же вид» информации, "дать им то же имя, где это возможно. (Это почему, например, два столбца номера поставщика в База данных поставщиков и запасных частей называется СНО, а не, скажем, СНО в одна таблица и SNUM в другой.) И наоборот, если два столбца представляют различные виды информации, обычно это хорошая идея, чтобы дать им разные имена.

Я хотел бы остановиться на замечании @kuru kuru pa (тоже неплохо) о добавлении столбцов в таблицу, над которой у вас нет контроля, например, о «веб-службе, которую вы используете». Мне кажется, что эту проблему эффективно решить, используя стратегию, предложенную датой в разделе 3.9 (ссылка выше): цитата:

• Для каждой базовой таблицы определите представление, идентичное этой базовой таблице, за исключением, возможно, переименования некоторых столбцов.
• Убедитесь, что определенный набор представлений соответствует дисциплине именования столбцов, описанной выше.
• Работать в терминах этих представлений вместо базовых базовых таблиц.

Лично я считаю "естественное соединение, которое считают опасным" расстраивающим. Не желая звучать самодовольно, но мое собственное соглашение об именах, которое следует руководству ISO 11179-5 Принципы именования и идентификации , приводит к схеме, очень подходящей для естественного объединения.

К сожалению, естественное объединение, возможно, не будет поддерживаться в ближайшее время в продукте СУБД, которым я профессионально пользуюсь (SQL Server): запрос соответствующей функции в Microsoft Connect в настоящее время закрыт как "не исправит", несмотря на то, что в настоящее время имеет респектабельный +38 / -2 счет был вновь открыт и получил респектабельный 46 / -2 балл (проголосуйте за это сейчас:)

Answer 3

Основная проблема с синтаксисом NATURAL JOIN в SQL заключается в том, что он обычно слишком многословен.

В синтаксисе Tutorial D я могу очень просто написать естественное соединение как:

R{a,b,c} JOIN S{a,c,d};

Но в SQL оператору SELECT требуются либо производные подзапросы таблицы, либо предложение WHERE и псевдонимы для достижения того же результата. Это связано с тем, что один «оператор SELECT» на самом деле является нереляционным составным оператором, в котором операции компонента всегда выполняются в заранее определенном порядке. Проекция наступает после того, как объединения и столбцы в результате объединения не обязательно имеют уникальные имена.

например. Приведенный выше запрос может быть записан в SQL как:

SELECT DISTINCT a, b, c, d
FROM
(SELECT a,b,c FROM R) R
NATURAL JOIN
(SELECT a,c,d FROM S) S;

или

SELECT DISTINCT R.a, R.b, R.c, S.d
FROM R,S
WHERE R.a = S.a AND R.c = S.c;

Люди, скорее всего, предпочтут последнюю версию, потому что она короче и «проще».

Answer 4

Теория против реальности ...

Естественные объединения не практичны.
Насколько мне известно, не существует такой вещи, как чистая (т.е. практика идеальна для теории) СУБД.

Я думаю, что Oracle и некоторые другие действительно поддерживают естественные объединения, а TSQL - нет.

Рассмотрим мир, в котором мы живем - вероятность того, что две таблицы, каждая из которых имеет столбец с одинаковым именем, довольно высока (например, может быть [имя] или [идентификатор] или [дата] и т. Д.). Возможно, эти шансы немного сузятся, сгруппировав только те таблицы, к которым вы, возможно, захотите присоединиться. Но независимо от того, без тщательного изучения структуры таблицы, вы не узнаете, является ли «естественное объединение» хорошей идеей или нет. И даже если в этот момент это может произойти не через год, когда приложение получит обновление, которое добавляет столбцы к определенным таблицам и т. Д., Или веб-служба, которую вы используете, добавляет поля, о которых вы не знали, и т.д.

Я думаю, что "чистой" системой должна быть та, над которой вы как минимум имеете 100% -ный контроль, а также система, которая будет иметь хорошую проверку в процессе изменения таблицы / создания таблицы, которая будет предупреждать / предотвращать вас от создания нового столбца в некоторой таблице, который может быть «естественным образом» соединен с другой таблицей, вы, возможно, не предполагаете, что он может быть присоединен.

Полагаю, что в итоге я бы оценил мою работоспособность, пожелал, чтобы у моих приложений было максимальное время безотказной работы, оценил быструю / чистую поддержку и обновления и т. Д. (когда-либо).