По определению, таблицы R и R1 удовлетворяют заданному ограничению по ссылкам, если для каждой строки s таблицы R такой, что все значения столбцов, идентифицируемых списком A, не являются неопределенными, существует строка s1 таблицы R1 такая, что значения столбцов s1, идентифицируемых списком A1, позиционно равны значениям столбцов s, идентифицируемых списком A. Другими словами, это можно сформулировать так: ограничение по ссылкам удовлетворяется, если для каждой корректной ссылки существует объект, на который она ссылается. В понятной (привычной) программистам терминологии ограничение по ссылкам не позволяет производить "висячие" ссылки, не ведущие ни к какому объекту.

Проверочное ограничение (CHECK)

Проверочное ограничение специфицирует условие, которому должна удовлетворять в отдельности каждая строка таблицы R. Это условие не должно содержать подзапросов (см. пункт 5.3), спецификаций агрегатных функций (см. пункт 4.4), а также ссылок на внешние переменные или параметры. В него могут входить только имена столбцов данной таблицы и литеральные константы.

Таблица удовлетворяет проверочному ограничению целостности в том и только в том случае, когда вычисление условия для каждой строки таблицы дает true.

Замечание. В некоторых реализациях допускаются расширенные механизмы ограничений по ссылкам и проверочных ограничений. Однако такое предоставляют только немногие СУБД.

3.2. Определение представлений (VIEW обзоров)

Механизм представлений (view) является средством языка SQL, позволяющим скрыть реальную структуру БД от пользователей за счет определения представления БД, которое реально является некоторым хранимым в БД запросом с именованными столбцами, а для пользователя ничем не отличается от базовой таблицы БД (с учетом технических ограничений). Любая реализация должна гарантировать, что состояние представляемой таблицы точно соответствует состоянию базовых таблиц, на которых определено представление. Обычно вычисление представляемой таблицы (актуализация соответствующего запроса) производится каждый раз при использовании представления.

Реально обзоры не являются таблицами, но упоминаются здесь, так как во многих случаях они трактуются как таблицы. Обзоры - это "запомненные запросы", которые представляются в формате таблиц. Таким образом, обзор может содержать (как и таблица) необходимое число столбцов (обычно до 254 столбцов). Ссылки на обзоры и таблицы во многих SQL -операторах идентичны (особенно в операторах языка манипулирования данными (DML) и запросах), в других же случаях использование обзоров запрещено. Обзоры, скрывая физическое представление данных, обеспечивают их независимость от приложений, которые заботит только логическая структура данных.

Обзоры полезны во многих случаях, включая удобство и безопасность. Например - обзоры, используемые для изменения и созданные с опцией WITH CHECK, могут дополнять проверки данных в столбцах, подразумеваемые при создании таблицы с помощью оператора CREATE TABLE. Использование обзоров для безопасности здесь не рассматриваются.

Обзоры не требуют физической памяти на диске, кроме строк в словаре данных, используемых для запоминания определения обзора (сохраненный запрос). Напомним, что словарь данных - это базовая системная таблица, создаваемая СУБД в момент исполнения оператора CREATE DATABASE, в которой фиксируются и созданные, и сохраненные обзоры.

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

В стандарте SQL оператор определения представления имеет следующий синтаксис:

<view definition> ::=

CREATE VIEW <table name> [(<view column list>)]

AS <query specification> [WITH CHECK OPTION]

<view column list> ::= <column name> [{,<column name>}...]

Определяемая представляемая таблица V является изменяемой (т.е. по отношению к V можно использовать операторы DELETE и UPDATE - глава 6) в том и только в том случае, если выполняются следующие условия для спецификации запроса:

•в списке выборки не указано ключевое слово DISTINCT;

•каждое арифметическое выражение в списке выборки представляет собой одну спецификацию столбца, и спецификация одного столбца не появляется более одного раза;

•в разделе FROM указана только одна таблица, являющаяся либо базовой таблицей, либо изменяемой представляемой таблицей;

•в условии выборки раздела WHERE не используются подзапросы;

•в табличном выражении отсутствуют разделы GROUP BY и HAVING.

Замечание. Эти ограничения являются очень сильными. В реализациях они могут быть ослаблены. Но, если стремиться к мобильности, не следует пользоваться расширенными возможностями.

Если в списке выборки спецификации запроса имеется хотя бы одно арифметическое выражение, состоящее не из одной спецификации столбца, или если одно имя столбца участвует в списке выборки более одного раза, определение представления должно содержать список имен столбцов представляемой таблицы. Более просто, нужно явно именовать столбцы представляемой таблицы, если эти имена не наследуются от столбцов таблиц раздела FROM спецификации запроса.

Требование WITH CHECK OPTION в определении представления имеет смысл только в случае определения изменяемой представляемой таблицы, которая определяется спецификацией запроса, содержащей раздел WHERE. При наличии этого требования не допускаются изменения представляемой таблицы, которые приводят к появлению в базовых таблиц строк, не видимых в представляемой таблице (т.е. таких строк, которые не удовлетворяют условию поиска раздела WHERE спецификации запроса). Если WITH CHECK OPTION в определении представления отсутствует, такой контроль не производится.

3.3.Определение прав доступа (привилегий)

Всоответствии с идеологией языка SQL контроль прав доступа данного пользователя к таблицам БД производится на основе механизма привилегий. Фактически, этот механизм состоит в том, что для выполнения любого действия над таблицей пользователь должен обладать соответствующей привилегией (реально все возможные действия описываются фиксированным стандартным набором привилегий). Пользователь, создавший таблицу, автоматически становится владельцем всех

возможных привилегий на выполнение операций над этой таблицей. В число этих привилегий входит привилегия на передачу всех или некоторых привилегий по отношению к данной таблице другому пользователю, включая привилегию на передачу привилегий. Иногда поддерживается и обратная операция изъятия привилегий от пользователя, ранее их получившего.

Практически каждая СУБД решает проблемы, связанные с определением прав доступа своими уникальными средствами [17, 20, 22, 25], и по понятным причинам не афиширует эти средства. Однако мы должны понимать, что эти средства должны позволять обеспечить необходимую нам информационную безопасность.