РМ-запреты
Внимательный читатель заметит, что многие из запрещений в этом разделе являются логическими следствиями РМ-предписаний. Однако в связи с теми ошибками, которые были, к сожалению, допущены в SQL, мы чувствуем, что для большей ясности здесь необходимо описать некоторые из этих следствий.
- Язык D не должен включать никаких конструкций, которые зависят от определения какого-либо упорядочения атрибутов отношения. Вместо этого для каждого отношения R, выразимого в D, атрибуты отношения должны быть различимы по именам.
Комментарии:
- Этот запрет означает, что более не допускается никаких анонимных столбцов, таких как в операторе SQL SELECT X + Y FROM T, и никаких дубликатов имен столбцов, как в операторах SQL SELECT X, X FROM T и SELECT T1.X, T2.X FROM T1, T2.
- Язык D не должен включать никаких конструкций, которые зависят от определения какого-либо упорядочения кортежей отношения.
Комментарии:
- Из этого запрета вовсе не следует, что такое упорядочение не может быть установлено, например, для целей представления. Скорее, имеется в виду, что в результате такого упорядочения отношение конвертируется в нечто, что не является отношением (возможно, в последовательность или упорядоченный список).
- Для каждого отношения R, если t1 и t2 являются двумя разными его кортежами, в R должен существовать некоторый атрибут A такой, что значение атрибута A в t1 не равно значению атрибута A в t2.
Комментарии:
- Иными словами, "строки-дубликаты" являются незаконными абсолютно, категорически и однозначно. То, что мы сказали здесь три раза, – справедливо.
- Каждый атрибут каждого кортежа каждого отношения должен иметь значение, которое является значением из соответствующего домена.
Комментарии:
- Иными словами, больше никаких неопределенных значений и больше никакой многозначной логики!
- В D не следует забывать как то, что отношения с нулем атрибутов заслуживают внимания и представляют интерес, так и то, что возможные ключи с нулем компонентов подобным же образом заслуживают внимания и интересны.
- Язык D не должен включать никаких конструкций, которые связаны с "физическим" уровнем, уровнем "среды хранения" или "внутренним" уровнем системы либо логически подвергаются их воздействию (иных, чем функции, которые явно раскрывают реальное представление значений домена – см. РМ-предписание 4). Если разработчик имеет желание или потребность ввести какого-либо рода "язык определения структуры хранения", операторы этого языка и отображения dbvar в физическую среду хранения должны быть полностью отделены от всего, что выражается в D.
- Над отношениями не должно быть никаких покортежных операций.
Комментарии:- Операции INSERT, UPDATE и DELETE, если они обеспечиваются, вставляют, обновляют или удаляют (соответственно применяемой операции) всегда множество кортежей. Множество, состоящее из одного кортежа, является просто частным случаем (хотя для такого случая может оказаться удобным предусмотреть специальный синтаксис).
- Покортежный поиск (аналогичный выполняемому оператором FETCH языка SQL через курсор), хотя он и запрещается, и вообще в корне осуждается, может эффективно выполняться, если это желательно, путем конвертирования этого отношения в упорядоченный список кортежей и выполнения операций над этим списком.
- Категорически запрещается покортежное обновление (аналогичное операциям SQL UPDATE и DELETE, выполняемым с помощью курсора).
- Язык D не должен включать какой-либо специальной поддержки "составных доменов" или "составных столбцов" (как предлагается, например, в [4]), поскольку такие функциональные возможности могут достигаться, если это желательно, с помощью уже описанной поддержки доменов. См. [9].
- Операторы подавления проверки доменов (в том, например, виде, как они описаны в [4]) являются случайными и не необходимыми. Они не должны поддерживаться.
- Язык D не должен называться SQL.
