Язык баз данных SQL со средствами поддержания целостности

9. Уровни SQL

Этот стандарт специфицирует два уровня и отдельные средства поддержания целостности данных.

Средства поддержания целостности данных образуют следующие синтаксические конструкции вместе с Синтаксическими правилами и Общими правилами:

<Раздел умолчаний> (<default clause>)

все опции <ограничения на столбец> (<column constraint>), отличные от NOT NULL и NOT NULL UNIQUE

все опции <определения ограничения на таблицу> (<table constraint definition>), кроме опции UNIQUE <список столбцов уникальности> (UNIQUE (<unique column list>)).

<действие> REFERENCES <список столбцов передачи> (<action> REFERENCES [ (<grant column list>)])

Уровень 2 - это полный язык базы данных SQL, не включающий средства улучшения целостности данных. Уровень 1 - это подмножество уровня 2, которое подчиняется следующим дополнительным правилам.

4.16, "Транзакции":
а) Первое предложение параграфа 1 заменяется следующим:
Транзакция - это последовательность операций, включающая операции над базой данных, которые являются атомарными по отношению к восстановлению.
b) Параграф 2 удаляется.
c) Второе предложение параграфа 3 удаляется.

5.3, "Лексемы (<token>):
<Идентификатор> (<identifier>) не должен состоять более чем из 12 символов.

5.4, "Имена":
<Имя таблицы> (<table name>) не должно содержать <идентификатор полномочий> (<authorization identifier>).

5.6, "<Спецификация значения> (<value specification>) и <спецификация цели> (<target specification>)":
а) <Спецификация значения> (<value specification>) не должна содержать USER.
b) <Спецификация параметра> (<parameter specification>) не должна специфицировать <парамететр-индикатор> (<indicator parameter>).
c) <Спецификация переменной> (<variable specification>) не должна специфицировать <переменную-индикатор> (<indicator variable>).

5.7, "<Спецификация столбца> (<column specification>)" :
К синтаксическому правилу 4 добавляется следующее:

<Спецификация столбца> (<column specification>) не должна быть внешней ссылкой.

5.8, "<Спецификация функции над множеством> (<set function specification>)" 5.24, <Подзапрос> (<subquery>), и 5.25, <Cпецификация запроса> (<query specification>):

<Функция надо всеми элементами множества> (<all set function>), <подзапрос> (<subquery>) и <спецификация запроса (<query specification>) не должны содержать ALL.

Замечание: на уровне 1 сохранение дубликатов специфицируется отсутствием DISTINCT.

5.8, "<Спецификация функций над множеством> (<set function specification>)":

<Функция над различными элементами множества> (<distinct set function>) не должны включать AVG, MAX, MIN или SUM.

5.11, "<Предикат сравнения> (<comaprison predicate>)" : <Оператор сравнения> (<comp op>) не должен включать "<>". Замечание: на уровне 1 сравнение в форме "A <> B" выражается через эквивалент "NOT A=B".

5.14, "<предикат like> (<like predicate>):
а) <Предикат like> (<like predicate>) не должен специфицировать ESCAPE <символ escape> (<escape character>).
b) <Предикат like> (<like predicate>) не должен специфицировать NOT.
Замечание: на уровне 1 <предикат like> (<like predicate>), содержащий NOT, может быть выражен в эквивалентной форме <условия поиска> (<search condition>): "NOT <like predicate>".

5.17, "<предикат exists> (<exists predicate>)":

<Предикат> (<predicate>) не должен специфицировать <предикат exists> (<exists predicate>).

5.22, "<раздел group by>" (<group by clause>)":
Следующее предложение добавляется к Общему правилу 2:

Группирование строк, в которых значения одного или нескольких столбцов группировки являются неопределенными, определяется в реализации.

5.25, "<Спецификация запроса> (<query specification>)":
Синтаксическое правило 11 заменяется на следующее:

Распознавание того, является ли <спецификация запроса> (<query specification>) изменяемой или только читаемой, определяется в реализации.

6.1, "<Схема> (<schema>)":
<Схема> (<schema>) не должна специфицироваться.
Уровень 1 реализации должен обеспечивать некоторый механизм связи <идентификатора полномочий> (<authorization identifier>) с <определением таблицы> (<table definition>), <определением представления> (<view definition>) или <определением привилегий> (<privileges definition>).

6.2, "<Определение таблицы> (<table definition>)":
<Определение таблицы> (<table definition>) не должно содержать <определение огpаничения уникальности> (<unique constraint definition>). Уровень реализации 1 должен обеспечивать некоторый механизм спецификации ограничения таблицы, связанного с уникальностью.

6.3, "<Определение столбцов> (<column definition>):
а) <Тип данных> (<data type>) в <определении столбца> (<column definition>) не должен включать REAL, DOUBLE, PRECISION и NUMERIC.
b) <Определение столбца> (<column definition>) столбца не должно специфицировать NOT NULL.
c) <Определение столбца> (<column definition>) столбца не должно специфицировать UNIQUE.

6.9, "<Определение представления> (<view definition>):
<Определение представления> (<view definition>) не должно содержать WITH CHECK OPTION.

6.10, "<Определение привилегий> (<privilege definition>)" :
<Определение привилегий> (<privileges definition>) не должно содержать WITH GRANT OPTION.

7.3, "<Процедура> (<procedure>):
а) Cинтаксическое правило 8 (a) (2) заменяется на следующее:
Любой <тип данных> (<data type>) в <объявлении параметра> (<parameter declaration>) должен специфицировать тип CHARACTER.
b) В общем правиле 3 случай (a) каждое вхождение числа "100" заменяется на слова "положительное число со значением, определяемым реализацией"
c) Общее правило 3 (b) (1) заменяется на следующее:
В реализации определяется, аннулируются ли при выполнении S изменения, произведенные в базе данных.

8.3, "<Объявление курсора> (<declare cursor>)":
а) <Спецификация сортировки> (<sort specification>) не должна содержать <целых без знака> (<unsigned integer>).
b) <Спецификация сортировки> (<sort specification>) не должна содержать ASC.
Замечание: на уровне 1 порядок по возрастанию специфицируется отсутствием опции DESC.
c) <Выражение запроса> (<query expression>) не должно содержать UNION.
Замечание: на уровне 1 функция объединения не поддерживается.

8.7, "<Оператор вставки> (<insert statement>) :
<Оператор вставки> (<insert statement>) не должен содержать <спецификацию запроса> (<query specification>).

8.11, "<Оператор модификации: позиционный> (<update statement: positioned>)" и <оператор удаления: поизиционный> (<delete statement: positioned>):
<Оператор SQL> (<SQL statement>) не должен специфицировать <оператор модификации: позиционный> (<update statement: positioned>) или <оператор удаления: позиционный> (<delete statement: positioned>).

Знаете ли Вы, как разрешается парадокс Ольберса?
(Фотометрический парадокс, парадокс Ольберса - это один из парадоксов космологии, заключающийся в том, что во Вселенной, равномерно заполненной звёздами, яркость неба (в том числе ночного) должна быть примерно равна яркости солнечного диска. Это должно иметь место потому, что по любому направлению неба луч зрения рано или поздно упрется в поверхность звезды.
Иными словами парадос Ольберса заключается в том, что если Вселенная бесконечна, то черного неба мы не увидим, так как излучение дальних звезд будет суммироваться с излучением ближних, и небо должно иметь среднюю температуру фотосфер звезд. При поглощении света межзвездным веществом, оно будет разогреваться до температуры звездных фотосфер и излучать также ярко, как звезды. Однако в дело вступает явление "усталости света", открытое Эдвином Хабблом, который показал, что чем дальше от нас расположена галактика, тем больше становится красным свет ее излучения, то есть фотоны как бы "устают", отдают свою энергию межзвездной среде. На очень больших расстояниях галактики видны только в радиодиапазоне, так как их свет вовсе потерял энергию идя через бескрайние просторы Вселенной. Подробнее читайте в FAQ по эфирной физике.

{DATA}