Конспект лекций теоретического курса

Тесты

Заключение

Если обратиться к истории, то обнаружится, что попытки расширения функциональности СУБД, изначально основанных на реляционном подходе, предпринимались уже на ранних стадиях разработки таких систем. Классическими примерами являются проекты System R

(IBM), где пытались обеспечить возможности работы со сложными объектами путем расширения SQL, и Ingres (университет Беркли), где Майкл Стоунбрейкер предлагал механизм определения пользовательских типов данных на основе представлений и хранимых процедур. Однако новый толчок к расширению SQL-ориентированных СУБД объектными свойствами был получен со стороны объектного мира после публикации Первого манифеста.

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

Развитие объектно-реляционного подхода отразилось в соответствующем развитии языка SQL. Гигантский стандарт SQL:1999 позволяет хотя бы сопоставлять отдельные реализации, хотя ни одна компания полностью его не поддерживает. Как можно заметить, разработчики стандарта SQL пошли на существенно большее сближение с объектно-ориентированным подходом к организации систем баз данных, чем это предполагалось во Втором манифесте. В особенности это проявляется в механизмах типизированных таблиц, ссылочных типов и ссылочных значений: типизированные таблицы похожи на экстенты классов, а ссылочные значения – на объектные идентификаторы. Однако во многом это сходство является внешним – за путевыми выражениями в стиле ODMG по-прежнему скрываются операции соединения таблиц.

Данная лекция содержит весьма пестрый материал, объединенный только очень общей идеей расширения РСУБД объектными возможностями. К сожалению, это вынужденная пестрота, поскольку, как представляется автору данного курса, большая часть расширений выполнялась без предварительной проработки не только общей модели, но даже и концепции языка. В результате мы можем оказаться в ситуации, когда язык SQL, в лучшем случае, будет полностью понятен только главному редактору стандарта.

И последнее замечание, на котором мы закончим этот курс. Несмотря на некоторую критику в адрес языка SQL, высказанную в начале Лекции 11, мы потратили на обсуждение этого языка почти половину курса и больше его практически не критиковали. Не означает ли это, что язык все-таки очень хорош, или что автор курса питает к нему особую привязанность? Конечно же, нет! В языке SQL имеется множество слабых мест, неточностей и даже прямых ошибок. Если бы мы задались целью демонстрировать все промахи языка SQL, то этот курс никогда бы не закончился, а его читатели так и не узнали бы, что представляет собой язык в целом.

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

1 (1) Пусть имеются следующие два определения индивидуальных типов:

CREATE TYPE EMP_NO_I AS INTEGER FINAL;

CREATE TYPE EMP_NO_C AS CHAR(6);

Значениями обоих типов являются номера служащих, но в первом случае для представления номеров используются целые числа (по всей видимости, натуральные целые), а во втором – строки символов, изображающие натуральные числа. Предположим, что в таблице T1 определен столбец EMP_NO_1 типа EMP_NO_I, а таблице T2 – столбец EMP_NO_2 типа EMP_NO_C. Требуется выполнить эквисоединение таблиц T1 и T2 по значениям столбцов EMP_NO_1 и EMP_NO_2. Какие из приводимых ниже выражений являются правильными?

(а) -

CAST (EMP_NO_1 TO INTEGER) = CAST (EMP_NO_2 TO INTEGER)

(б) +

CAST (EMP_NO_1 TO INTEGER) =
CAST (CAST (EMP_NO_2 TO CHAR(6)) AS INTEGER)

(в) -

CAST (EMP_NO_1 AS INTEGER) = CAST (EMP_NO_2 AS INTEGER)

1 (2) Для определения индивидуальных и структурных UDT используется один и тот же оператор CREATE TYPE. Каким образом, глядя на определение типа, можно точно сказать, к какой из двух категорий относится это определение?

(а) -

только в определении структурного типа может содержаться раздел инстанциируемости

(б) +

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

(в) +/- это верно для SQL:1999, но изменится в будущем

в определении структурного типа должна содержаться спецификация NOT FINAL, а в определении индивидуального типа – FINAL.

1 (3) Пусть структурный тип T является непосредственным не максимальным супертипом типа T’. Какие из следующих утверждений относительно определений T и T’ являются верными?

(а) -

в определении типа T’ не должен содержаться раздел AS

(б) -/+ это верно всегда в SQL:1999, но не характеризует данную ситуацию

в определении типа T не должна содержаться спецификация FINAL

(в) +

в определении типа T должен содержаться раздел UNDER, в определении типа T’ должен содержаться раздел UNDER с указанием типа T.

2 (1) Для определения базовых и типизированных таблиц используется один и тот же оператор CREATE TABLE. Каким образом, глядя на определение таблицы, можно точно сказать, к какой из двух категорий относится это определение?

(а) -

в определении типизированной таблицы присутствует раздел UNDER

(б) -

в определении типизированной таблицы присутствует определение самоссылающегося столбца

(в) +

в определении типизированной таблицы присутствует раздел OF

2 (2) Пусть типизированная таблица R является непосредственной максимальной супертаблицей типизированной таблицы R’. Какие из следующих утверждений относительно R и R’ являются верными?

(а) -

структурный тип таблицы R является максимальным супертипом структурного типа таблицы R’

(б) +

в определении таблицы R отсутствует раздел UNDER, в определении таблицы R’ присутствует раздел UNDER с указанием таблицы R; структурный тип таблицы R является непосредственным супертипом структурного типа таблицы R’

(в) -/+ это верно, но не характеризует данную ситуацию

в определении таблицы R’ отсутствуют определения первичного ключа и самоссылающегося столбца

2 (3) Пусть A – это самоссылающийся столбец типизированной таблицы R. Какая спецификация является первичной для генерации значений этого столбца?

(а) -

определение самоссылающегося столбца в таблице R

(б) -

определение самоссылающегося столбца в максимальной супертаблице таблицы R

(в) +

спецификация ссылочного типа в определении максимального супертипа структурного типа таблицы R

Повторим для удобства определения структурных типов и типизированных таблиц из разд. 19.3:

CREATE TYPE EMP_T AS (
EMP_NAME VARCHAR(20),
EMP_BDATE DATE,
EMP_SAL SALARY,
DEPT REF (DEPT))
INSTANTIABLE
NOT FINAL
REF IS SYSTEM GENERATED
INSTANCE METHOD age ()
RETURNS DECIMAL (3,1);

CREATE TYPE PROGRAMMER_T UNDER EMP_T AS (
PROG_LANG VARCHAR (10))
INSTANTIABLE
NOT FINAL;

CREATE TYPE DEPT_T AS (
DEPT_NO INTEGER,
DEPT_NAME VARCHAR(200),
DEPT_MNG REF (EMP))

INSTANTIABLE
REF IS SYSTEM GENERATED
NOT FINAL;

CREATE TABLE EMP OF EMP_T
(REF IS DEPT_ID SYSTEM GENERATED,
DEPT WITH OPTIONS SCOPE DEPT);

CREATE TABLE PROGRAMMER OF PROGRAMMER_T UNDER EMP;

CREATE TABLE DEPT OF DEPT_T
(REF IS EMP_ID SYSTEM GENERATED,
DEPT_MNG WITH OPTIONS SCOPE EMP);

3 (1) Какая из приведенных ниже формулировок правильно соответствует запросу “выдать имена начальников отделов, в которых работает хотя бы один программист”?

(а) +

SELECT DISTINCT DEPT -> DEPT_MNG -> EMP_NAME
FROM PROGRAMMER

(б) -

SELECT EMP_NAME
FROM EMP, DEPT
WHERE DEPT = DEPT_ID
AND DEPT_MNG = EMP_ID
AND EXISTS (SELECT *
FROM PROGRAMMER
WHERE DEPT = DEPT_ID);

(в) +

SELECT EMP_NAME
FROM EMP, DEPT
WHERE DEPT_MNG = EMP_ID
AND EXISTS (SELECT *
FROM PROGRAMMER
WHERE DEPT = DEPT_ID);

3 (2) Какая из приведенных ниже формулировок правильно соответствует запросу “выдать имена начальников отделов, в которых работает исключительно программисты”?

(а) -

SELECT DISTINCT DEPT -> DEPT_MNG -> EMP_NAME
FROM PROGRAMMER

(б) +

SELECT DEPT_MNG -> EMP_NAME
FROM DEPT
WHERE NOT EXISTS (SELECT *
FROM ONLY (EMP)
WHERE DEPT = DEPT_ID);

(в) -

SELECT DEPT_MNG -> EMP_NAME
FROM DEPT
WHERE DEPT IN (SELECT DEPT
FROM PROGRAMMER);

3 (3) Какая из приведенных ниже формулировок правильно соответствует запросу “выдать имена начальников отделов, в которых работает хотя бы один не программист”?

(а) +

SELECT DISTINCT DEPT -> DEPT_MNG -> EMP_NAME
FROM ONLY (EMP);

(б) -

SELECT DISTINCT DEPT -> DEPT_MNG -> EMP_NAME
FROM PROGRAMMER
WHERE DEPT IN (SELECT DEPT
FROM ONLY (EMP));

(в) +

SELECT DEPT_MNG -> EMP_NAME
FROM DEPT
WHERE DEPT IN (SELECT DEPT
FROM ONLY (EMP));

4 (1) Для определения всех разновидностей представлений используется один и тот же оператор CREATE VIEW. Каким образом, глядя на определение представления, можно точно сказать, что оно является допустимым определением типизированного представления?

(а) -

присутствует раздел OF

(б) +

присутствуют разделы OF и UNDER

(в) -

присутствует раздел UNDER

4 (2) Как должны соответствовать структурный тип типизированного представления со структурным типом базисной типизированной таблицы этого представления?

(а) +

эти типы должны совпадать

(б) -

тип представления должен являться подтипом (не обязательно несобственным) типа базисной таблицы

(в) -

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

4 (3) Пусть представление V’ c базисной типизированной таблицей R’ является непосредственным собственным подпредставлением представления V c базисной типизированной таблицей R. Какое из следующих утверждений является правильным?

(а) -

тип представления V’ должен являться непосредственным подтипом типа представления V, а таблица R’ должна являться непосредственной подтаблицей таблицы R

(б) +

тип представления V должен являться непосредственным супертипом типа представления V’, а таблица R должна являться супертаблицей таблицы R’

(в) -

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

** Напомним, что S′ является собственным подмножеством множества S в том и только в том случае, когда S′ входит в S, но не совпадает с S (это обозначается как S′ Ì S).

* В Лекции 12 мы обсудим различия между первичными и возможными ключами в языке SQL.

* Если он является сторонником классического реляционного подхода; в языке SQL допускается определение таблиц без первичного и возможных ключей.

**. Кстати, заметим, что в классической реляционной модели, если при определении переменной отношения явно не указывается ее первичный ключ, то по умолчанию первичным ключом считается полный набор атрибутов заголовка отношения. Конечно, в этом случае такая переменная отношения может принимать любое значение-отношение, соответствующее заголовку, и первичный ключ не играет роль ограничения.

* Эти ограничения все более ослабляются в последовательности стандартов языка SQL

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

* Как показывает опыт автора, не всегда и не все студенты помнят базовые логические операции. Для гарантии приведем таблицы истинности операций AND (“&” – конъюнкция), OR (“Ú” – дизъюнкция) и NOT (“ù” – отрицание):

AND	true	false		OR	true	false		NOT	true	false
true	true	false		true	true	true			false	true
false	false	false		false	true	false

* В языке SQL допускается несколько вариантов определения внешнего ключа, только один из которых полностью соответствует классическому подходу. Более подробно мы обсудим это в следующих лекциях.

* Легко убедиться, что A INTERSECT B = A MINUS (A MINUS B) = B MINUS (B MINUS A).

* Здесь A.c и B.c представляют собой так называемые квалифицированные (уточненные) имена атрибутов (часто такой способ именования называют точечной нотацией). Мы будем использовать подобную нотацию в тех случаях, когда требуется явно показать, схеме какого отношения принадлежит данный атрибут.

* Здесь необходимо пояснить, что отношение ЗАРП_11000 в действительности представляет собой литеральную константу соответствующего типа отношений. Мы не вводим здесь строгого понятия типа отношения; для понимания данного подраздела нужно всего лишь осознать, что по своей природе отношение ЗАРП_20000 и числовой литерал 20000.00 не различаются.

** Отношение ЗАРП_БОЛЬШЕ_20000 – это тоже литеральная константа того же типа отношения, что и ЗАРП_20000, однако мощность тела этого литерального отношения в общем случае (если бы мы не ввели ограничения на множество значений домена СЛУ_ЗАРП) могла бы быть очень большой.

* Особенность этого случая состоит в том, что число кортежей в теле литеральной константы ЗАРП_НЕ_22000всего лишь на единицу меньше мощности множества значений домена СЛУ_ЗАРП. Конечно, эта мощность конечна, поскольку мы имеем дело с компьютерными типами данных, но в общем случае может быть очень большой. Поэтому принципиальная возможность выражения операции ограничения через операцию реляционной конъюнкции не означает, что было бы разумно реализовывать ее таким образом на практике.

* Конечно, тот же результат даст и выражение СЛУЖАЩИЕ_1<AND> ((((СЛУЖАЩИЕ_1<REMOVE> СЛУ_РУК) <REMOVE> СЛУ_ИМЯ) <REMOVE> СЛУ_ЗАРП) <RENAME> (СЛУ_НОМЕР, РУК_НОМ)).

** Конечно, в общем случае мощность тела такого константного отношения будет равна мощности соответствующего домена.

* Легко убедиться, что в общем случае, если мощность общего домена атрибутов A и B равняется n, то мощность тела константного отношения A_БОЛЬШЕ_B будет составлять (n+1)n/2.

* Это “константное” отношение, тело которого не зависит от текущего содержания тела отношения СЛУЖАЩИЕ.

* И конечно, в Алгебре A, как и в алгебре Кодда, должна присутствовать операция присваивания переменной отношения.

* Это совсем не означает, что для понимания этой лекции требуется знание исчисления предикатов. Автор стремился к тому, чтобы материал лекции был в основном самодостаточным.

* Через IF … THEN здесь обозначается одна и важных логических функций – импликация. По определению, IF a THEN b º NOT a OR b. Хотя операция импликации является избыточной, она явно вводится в реляционное исчисление, поскольку часто требуется на практике для выражения условий.

* Упражнение для читателей. Почему в первой формуле (с EXISTS) использовано условие СЛУ1.СЛУ_ЗАРП > СЛУ2.СЛУ_ЗАРП, а второй формуле (с FORALL) – СЛУ1.СЛУ_ЗАРП ³ СЛУ2.СЛУ_ЗАРП?

* К сожалению, классическая статья Армстронга – W.W. Armstrong. “Dependency Structures of Data Base Relationships”, Proc. IFIP Congress, Stockholm, Sweden, 1974 – так и не переведена на русский язык (на самом деле, ее нелегко найти и в оригинале). Поэтому я не могу рекомендовать ее для дополнительного чтения, хотя обязан сослаться.

* Мы используем здесь знаки операций проверки включения множеств, что не совсем корректно, поскольку если, например, множество B состоит из одного элемента, то для его обозначения используется имя соответствующего атрибута, и в этом случае правильнее было бы использовать знак “Î” (проверка вхождения элемента во множество).

* FD с минимальным детерминантом называется минимальной слева.

* Напомним из Лекции 2, что атомарность значения трактуется в том смысле, что значение типизировано, и с этим значением можно работать только с помощью операций соответствующего типа данных.

* Неключевым атрибутом называется атрибут, не входящий ни в один возможный ключ.

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

* Очевидно, что FD называется нетранзитивной тогда и только тогда, когда она не является транзитивной.

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

* Теоретически возможная третья декомпозиция отношения СЛУЖ на отношения СЛУЖ2{СЛУ_НОМ, СЛУ_ЗАРП}и УРОВ {СЛУ_УРОВ, СЛУ_ЗАРП}не является декомпозицией без потерь. Чтобы убедиться в этом, рассмотрите случай, когда для двух разных разрядов сотрудников назначен один и тот же размер зарплаты. Покажите также, что для этой декомпозиции не выполняются условия теоремы Хита.

** Т.е. выводится на основе аксиом Армстронга.

* Единственным возможным ключом отношения СЛУЖ_НОМ_ЗАДАН является {СЛУ_НОМ, СЛУ_ЗАДАН}, и в этом отношении отсутствуют нетривиальные FD.

* Упражнение по ходу лекции. Пусть имеется отношение r с атрибутами A, B, C (в общем случае, составными), в котором существует FD A ® B. Что в этом случае можно сказать про зависимость атрибутов A и C?

* FD с минимальным детерминантом называется минимальной слева.

* Т.е. выводится на основе аксиом Армстронга.

* Начиная с этой лекции, мы переходим к использованию терминов таблица, строка и столбец вместо строгих реляционных терминов отношение, атрибут и таблица, поскольку здесь под “реляционными” базами данных понимаются, главным образом, SQL-ориентированные базы данных, для которых эта упрощенная терминология более естественна.

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

* Позволю себе одно терминологическое замечание, которое может показаться несколько наивным для специалистов в области инженерии программного обеспечения (software engineering), к числу которых не принадлежу. Издавна существует отдельный класс программных систем, предназначенных для автоматизации проектирования новых продуктов в разных областях промышленности – автомобилестроении, аэрокосмической промышленности, электронной промышленности и т.д. Очевидно, что процесс проектирования автомобиля принципиально отличается от процесса проектирования микропроцессора, но, тем не менее, для обозначения любой Системы Автоматизации ПРоектирования используется собирательный термин САПР (CAD – Computer Aided Design). Это оправдывается тем, что разные подклассы САПР имеют гораздо больше общих черт, чем различий. Так вот, по моему мнению, система автоматизации проектирования БД по своему назначению и строению в большей степени является системой класса САПР, чем системой класса CASE (Computer Aided Software Engineering). По всей видимости, средства автоматизированной поддержки проектирования стали в свое время называть CASE-средствами, поскольку они обычно включали не только инструменты для поддержки проектирования, но инструменты, поддерживающие проектирование и разработку приложений баз данных. В последние годы такие инструменты все реже производятся в виде одного пакета, и сам термин CASE-средство почти вышел из употребления. Тем не менее, поскольку не появилось какое-либо другое собирательное название средств поддержки прроектироавния баз данных, мы будем продолжать использовать именно этот термин.

* Понятно, что это “определение” на самом деле является тавтологией, поскольку, во-первых, мы пытаемся определить термин “сущность” через не определенный термин “объект”, а во-вторых, попытки определения термина “объект” настолько же безнадежны. Обычно авторы пытаются оправдываться тем, что в подобном контексте они имеют в виду “житейское”, а не сколько-нибудь формализованное понятие объекта. Конечно, от этого не становится легче, поскольку понятие сущности должно пониматься в достаточно точном смысле. Но эта тавтология не изобретена автором этого курса; она традиционна для области семантического моделирования. В этой области стремяться максимально избегать формальностей.

* Хотя было бы правильнее всегда использовать термины тип сущности и экземпляр типа сущности, для избежания многословности (и следуя традиции) в тех случаях, где это не приводит к двусмысленности, мы будем использовать термин сущность в значении типа сущности.

** Тем не менее, как и в случае типа сущности, мы будем часто использовать термин связь в значении типа связи.

* В некоторых вариантах ER-модели конец связи называют ролью связи в данной сущности. Тогда можно говорить об имени роли, степени роли и обязательности роли связи в данной сущности.

* Здесь мы полагаемся на предположение, что ни один автор не способен выпустить в течение одного года два издания одной своей книги в одном и том же издательстве.

* Как отмечалось в начале Лекции 6, вопросы определения индексов и других вспомогательных структур данных, относится в этапу физического, а не логического проектирования данных. Конечно, на практике эти этапы часто перекрываются во времени. Заметим, кстати, что в SQL-ориентированных СУБД индексы для всех возможных и внешних ключей, как правило, создаются системой автоматически.

* Этот аспект тоже относится к этапу физического проектирования, поскольку связан с особенностями реализации конкретной СУБД.

** Хотя в большинстве SQL-ориентированных СУБД хранение одного неопределенного значения вызывает минимальные накладные расходы; это снова аспект физического проектирования.

* В этой лекции мы используем термин сущность настолько же неформально, как в предыдущей лекции использовали термин объект. В UML претендует на обеспечение более точного и формального понятия объекта (UML обычно называют языком объектно-ориентированного моделирования). В спецификации языка UML даже присутствует определение понятия объекта средствами самого UML. Однако, по нашему глубокому убеждению, несмотря на эти попытки, понятие объекта в UML остается таким же нечетким, как и понятие сущности в ER-модели. По-прежнему, в основном приходится опираться на интуицию и здравый смысл.

** В UML, как и в модели ER-диаграмм, для родового обозначения связей используется термин relationship. Во многих переводах книг про UML на русский язык вместо термина связь применяется термин отношение. Как и в предыдущей лекции, мы используем термин связь.

*** Язык OCL является частью общей спецификации UML, но, в отличие от других частей языка, имеет не графическую, а линейную нотацию.

* Как кажется, здесь можно провести некоторую аналогию с ситуацией, по причине наличия которой в реляционной алгебре (см. Лекции 3 и 4) была введена операция RENAME.

* Если под “реляционными” базами данных понимать SQL-ориентированные БД.

** Напомним, что в варианте ER-модели, рассмотренном нами в предыдущей ликции, допускались только бинарные связи. В свое время компания Oracle обосновывала это решение тем, что наличие бинарных ассоциаций всегда является достаточным. Здесь мы также ограничимся обсуждением бинарных ассоциаций.

* Поскольку UML – это высокоуровневый язык моделирования, в нем не уточняется, что такое навигация в реализационном смысле. Но очевидно, что само появление понятия навигации связано с объектно-ориентированной природой UML. Термин навигация является почти ругательным в мире реляционных БД, но для мира объектно-ориентированных БД он вполне естественен, поскольку в этом мире на модельном уровне присутствует понятие ссылки, или указателя.

** С точки зрения реляционных БД ассоциации с однонаправленной навигацией можно считать указанием на необходимость ограничения видимости объектов БД. Соответствующую (но существенно более общую) возможность в SQL-ориентированных БД обеспечивает механизм представлений (view). Подробнее об этом см. в следующих лекциях.

* Хотя язык OCL формально считается частью UML, он специфицирован в отдельном документе, в котором присутствуют ссылки на другие части спецификации UML, а также вводятся собственные понятия и определения.

** Следует заметить, что ни в спецификации UML, ни в описании какой-либо другой объектной модели никогда прямо не говорится, что в операциях над множествами объектов в действительности участвуют идентификаторы объектов. Но другого понимания не существует.

*** Обратите внимание, что хотя, вообще говоря, в UML допускаются n- арные связи, в OCL речь идет только об уже привычном для нас бинарном варианте.

* В контексте проектирования реляционных БД (если не иметь в виду использование объектно-реляционных СУБД) последняя разновидность типа коллекции является бессмысленной, поскольку в реляционных БД упорядоченность не поддерживается. Поэтому мы не будем обсуждать детали операций над последовательностями.

** Если снова не иметь в виду использование объектно-реляционных СУБД.

* Очевидным аналогом класса является тип сущности, а аналогом связи-ассоциации – связь в смысле ER-модели. Кстати, различия и беспорядок в терминологии действительно удручают. В ER-модели связь (relationship) – это ассоциация (association) между двумя типами сущности. В UML ассоциация (association) – это один из видов связи (relationship). Да еще зачем-то в UML введен специальный термин link для обозначения экземпляра ассоциации. И снова хотелось бы использовать в качестве русского эквивалента термин связь, но он уже безнадежно занят, и приходится переводить link как соединение. Это, конечно, не противоречит смыслу, но тоже очень плохо, поскольку в области реляционных БД термин соединение и без этого имеет два разных смысла – операции соединения и соединения с сервером баз данных. Очень мне жаль переводчиков книг, посвященных UML.

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

* В этом абзаце применяется терминология, которая использовалась в публикациях, посвященных System R.

** Как это ни странно, компания IBM, имевшая уникальный и положительный опыт реализации экспериментальной реляционной СУБД System R, не стала первой компанией, выпустившей на рынок коммерческую реляционную СУБД. Компанию IBM опередила на два года незадолго до того образованная компания Oracle, выпустившая свою первую систему в 1979 г. Современные эксперты по разному объясняют причины этой “заторможенности” IBM, но, по всей видимости, основная причина кроется в традиционном консерватизме руководства компании.

* Например, одной из выигрышных черт SQL System R являлось то, что в одной транзакции разрешалось комбинировать все возможные операторы SQL. Поскольку технически это обеспечить достаточно трудно, почти во всех сегодняшних SQL-ориентированных СУБД имеются ограничения на состав операторов, которые можно выполнять в одной транзакции.

* Это практически обесценивает стандарт с точки зрения программистов приложений баз данных, поскольку не дает возможности создавать приложения, не привязанные к особенностям конкретных СУБД.

** Среди прочих достижений System R нельзя не отметить то, что в базах данных, управляемых этой СУБД, хранились как данные, так и метаданные – описатели отношений, их полей, представлений, ограничения целостности и т.д. Для хранения метаданных использовались специальные служебные отношения, которые стали называть отношениями-каталогами. Из отношений-каталогов можно было выбрать данные с помощью обычных средств языка SQL. Конечно, организация служебных данных – это вопрос реализации SQL, но этот вопрос непосредственно касается потенциальных пользователей SQL-ориентированных СУБД, и поэтому стандартизация представления пользователю отношений-каталогов (в стандарте SQL, информационной схемы базы данных) является исключительно важным делом.

* К сожалению, приходится использовать термин строка в двух смыслах: строка таблицы (table row) и символьная или битовая строка (character or bit string). Постараемся обеспечить правильное понимание смысла термина в контексте его использования.

** Спецификация предопределенного типа данных битовых строк была удалена в стандарте SQL:2003. Но поскольку эта спецификация повилась только в SQL:1999, мы сочли уместным оставить в курсе обсуждение этого типа данных.

* См. ниже Булевский тип.

** Следует подчеркнуть, что в стандарте SQL не определяется число байт, занимаемых при хранении в памяти значений целых типов. Не следует думать, что в SQL для хранения значения типа INTEGER требуется четыре байта, а SMALLINT требует двух байтов.

* В контексте локализации SQL-ориентированной СУБД (средства локализации входят в стандарт языка) можно определить еще три типа символьных строк – NATIONAL CHARACTER, NATIONAL CHARACTER VARYING и NATIONAL CHARACTER LARGE OBJECT. Аспекты интернационализации и локализации составляют отдельное измерение языка и не обсуждаются в данном курсе.

** Именно пробелами, а не “ пустыми ” символами!

*** Максимально допустимая длина строк постоянного и переменного размера (значение параметра x) определяется в реализации.

* Поскольку значения z могут быть очень большими, допускается сокращенная форма их задания в виде nK, nM и nG, где n – положительное целое число, а K, M и G означают кило, мега и гига соответственно.

* В литерале BLOB всегда должно содержаться четное число шестнадцатиричных цифр.

* Конечно, на практике такие ограничения устанавливаются в документации конкретной используемой СУБД, либо даже администратором конкретной базы данных.

** В тексте стандарта SQL:1999 используется термин anonymous row type. Следуя соглашениям предыдущего пункта, мы должны были бы использовать термин анонимные типы строк. Но тогда уж точно возникла бы путаница с типами символьных строк. Конечно, можно было бы радикально отказаться от использования термина строка таблицы и вернуться к кортежам отношений. Но, к сожалению, этого сделать нельзя, покольку в SQL таблицы – это не совсем (а иногда и совсем не) отношения, а строки таблиц – не совсем (совсем не) кортежи.

* Соответствующие определения сохраняются как часть метаданных базы данных (другими словами, являются частью схемы базы данных).

** Требуется, чтобы в определении структурного типа A использовались только те типы, которые были определены ранее.

* Начиная с этого места мы будем приводить более или менее точный синтаксис конструкций языка SQL (не злоупотребляя излишествами). Без этого текст был бы менее точным и более объемным. Прописными буквами показываются “терминалы” – ключевые слова языка SQL.

** Здесь мы в первый раз сталкиваемся с именем объекта базы данных. Не будем углубляться в детали, но в общем случае имена объектов SQL-ориентированных баз данных имеют вид имя_каталога.имя_схемы.имя_объекта. Этот подход к именованию объектов базы данных позволяет независимо создавать объекты в разных схемах, не заботясь о том, чтобы эти объекты имели разные простые имена. При использовании в операторе SQL простого имени объекта система должна автоматически уточнить это имя, исходя из идентификатора пользователя, от имени которого выполняется оператор.

*** Это значение будет использоваться в качестве значения по умолчанию для любого столбца, определенного на данном домене, для которого не определено собственное значение по умолчанию (см. следующую лекцию).

* { element₁, | element₂, |…| element_n } означает, что в данной синтаксической конструкции должен присутствовать один и только один element_i.

** Значение niladic_function “вычисляется” в тот момент, когда требуется значение по умолчанию (обычно при вставке в таблицу новой строки, значение соответствующего столбца которой явно не указано). Смысл CURRENT_DATE, CURRENT_TIME и CURRENT_TIMESTAMP очевиден. USER (или, что то же, CURRENT USER), SESSION_USER и SYSTEM_USER задают идентификатор пользователя, от имени которого выполняется текущая транзакция, текущая сессия, и идентификатор операционной системы, в которой работает пользователь, соответственно. В стандарте не определяется представление этих идентификаторах, но в реализациях они обычно представляются в виде символьных строк.

*** Более подробно мы обсудим допустимые в SQL виды условных выражений в следующих лекциях.

* В SQL не используются термины заголовок и тело таблицы. Здесь мы временно пользуемся этой терминологией только для целей сопоставления модели SQL с реляционной моделью данных.

* В круглых скобках указывается список определений элементов базовой таблицы (должно присутствовать определение хотя бы одного столбца), разделенных запятыми.

* Заметим, что хотя столбец может получить значение NULL по умолчанию как явным, так и неявным образом, эти два случая не являются эквивалентными. Явное задание NULL в качестве значения по умолчанию запрещает наследование столбцом значения по умолчанию домена.

** В этом случае SQL опирается на семантику неопределенных значений, отличную от используемой в большинстве других случаев. Считается, что (NULL = NULL) = true и что (a = NULL) = (NULL = a) = false для любого значения a, отличного от NULL.

* С учетом замечания по поводу особого толкования семантики неопределенных значений, сделанного в предыдущей сноске.

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

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

* Другими словами, это естественное ограничение требует, чтобы значения столбца DEPT_EMP_NO были “правильными”, т.е. действительно соответствовали числу служащих, работающих в данном отделе.

** По этой причине мы ввели в предыдущей лекции такую большую верхнюю границу – 20000000.00 – значений домена SALARY.

*** Другими словами, это естественное ограничение требует, чтобы размер фонда заработной платы отдела никогда не был меньше суммарной зарплаты, получаемой служащими этого отдела.

* Не считая те табличные ограничения целостности, которые (a) определены в составе определения базовой таблицы, содержащей данный столбец и (b) не содержат ссылок на какие-либо другие столбцы.

* Хотя формально требуется указывать одно из этих ключевых слов в любом действии DROP CONSTRAINT.

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

* Не считая те ограничения целостности, которые (a) определены в составе определения данной базовой таблицы и (b) не ссылаются на какие-либо другие базовые таблицы.

* Если бы мы этого не сделали, то значением оператора SELECT MIN (B_DATE) … могло бы быть NULL. Тогда при вычислении логического выражения мы получили бы значение uknown, которое не является запрещающим значением ограничения целостности, и в результате могли бы допустить наличие слишком старого служащего.

* Это означает, что cand_pro_no является допустимым значением внешнего ключа.

* Не следует воспринимать этот и следующие абзацы как описание того, как на самом деле выполняются подобные запросы в SQL-серверах. Это наиболее прямолинейный и малоэффективный способ выполнения запроса (хотя, в принципе, его можно применять и на практике). Мы выбрали этот способ описания, поскольку он максимально соответствует подходу к описанию семантики языка SQL, применяемому в стандарте языка. Кстати, основным отличием более практичных способов выполнения запросов с соединением является стремление к тому, чтобы избежать явного декартова произведения.

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

** Мы снова вынуждены забегать вперед. Средства SQL для управления транзакциями более подробно обсуждаются в следующих лекциях.

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

**** Для некоторых ограничений целостности режим отложенной проверки не имеет смысла. К таким ограничениям относятся, например, ограничения домена, ограничения NOT NULL и ограничения возможного ключа (хотя при их определении допускается указание DEFFERABLE). Если же возможный ключ используется в некотором определении внешнего ключа, то в стандарте SQL требуется, чтобы ограничение этого возможного ключа было NOT DEFFERABLE.

* В стандарте языка SQL в качетсве общего термина для обозначения таких выражения используется термин value expression. Однако в менее формальных публикациях обычно применяется более понятный термин scalar expression, для которого, вдобавок, существует адекватный русский эквивалент скалярное выражение. В этом курсе мы также предпочитаем использовать именно этот термин.

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

* Для набора типов T1, T2, …, Tn будем называть тип T наименьшим общим по приводимости, если значения каждого из типов T1, T2, …, Tn неявно приводимы к типу T, и не существует типа T’ такого, что значения типов типов T1, T2, …, Tn неявно приводимы к типу T’, и значения типа T’ неявно приводимы к типу T.

* Мы сознательно используем здесь термин набор, поскольку в общем случае результатом выполнения оператора выборки не является таблица.

** Не следует понимать эту схему таким образом, что запросы к SQL-ориентированной базе данных действительно должны выполняться именно таким образом. Более того, ни одна реализация SQL не придерживается в точности этой схеме. Но как бы реально ни выполнялся оператор выборки, результат должен быть таким же, как если бы он получался при точном следовании описываемой схеме выполнения.

*** A, B, … C не обязаны являться базовыми таблицами. См. следующий подраздел.

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

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

* Обратите внимание, что в выражении элемента выборки не обязательно должно содержаться хотя бы одно имя столбца. Допускается наличие чисто контантного выражения, значение которого будет повторяться в данном столбце всех строк таблицы TF. Кроме того, заметим, что в соответствии с определением value_expression элемент списка выборки может быть запросом, возвращающим таблицу из одной строки с одним столбцом.

** Заметим, что любой элемент Z. a_i этого неявно заданного списка может быть явно включен в список элементов выборки. Кстати, если в списке выборке присутствует явно или неявно заданный элемент вида Z. a, то в пределах запроса соответствующий столбец таблицы T4 получает то же имя.

* Мы снова проигнорируем спецификацию раздела collate, связанную с использованием национальных наборов символов.

* В связи с введением в стандарте SQL:2003 конструктора типов мультимножеств, в качестве элемента списка ссылок на таблицы раздела FROM теперь можно использовать и выражение со значением-мультимножеством. Однако в этом курсе мы не будем подробно рассматривать эту возможность.

* Мы использовали кавычки, поскольку таблицы, к которым применяются операции, в общем случае могут содержать строки-дубликаты, т.е. являться мультимножествами.

* Другими словами, при отсутствии спецификации CORRESPONDING требуется, чтобы заголовки таблиц-операндов совпадали за исключением, возможно, порядка следования столбцов.

** С учетом возможности неявного приведения типов.

* В следующей лекции мы более подробно обсудим подзапросы. Пока заметим, что row_subquery – это запрос, результирующая таблица которого состоит из одной строки.

* По крайней мере, так это следует понимать в соответствии с семантикой представлений в языке SQL. При реальной обработке запросов над представлениями такая явная “материализация” представления выполняется крайне редко. Вместо этого используется техника подстановки тела представления в тело запроса с гарантией того, что результат модифицированного запроса будет в точности таким же, что и результат исходного запроса над материализованным представлением. Но это уже относится к тематике оптимизации SQL-запросов, выходящей за пределы этого курса.

** Конструкция ALTER VIEW в языке SQL не поддерживается.

* Мы не обсуждаем в этом курсе предикаты, основанные на использовании выражений типа мультимножества, введенные в стандарте SQL:2003.

* Здесь снова идет речь о семантике выполнения оператора SELECT. В стандарте, естественно, не требуется, чтобы в реализации языка запросы с корреляционными подзапросами выполнялись в точности так, как описывается ниже. Суть в том, что какой бы реальный алгоритм выполнения такого запроса не использовался, результат выполнения должен быть точно таким же, как если бы запрос выполнялся по описываемой схеме.

* Кстати, в этом случае можно было бы обойтись введением одного псевдонима, оставив в качестве неявного второго псевдонима имя таблицы – EMP.

* Покажем это в развернутой форме. Пусть s текущая строка таблицы EMP, просматриваемой в цикле внешнего запроса, и пусть s. DEPT_NO содержит неопределенное значение. Тогда для строки s условие первого подзапроса будет иметь вид NULL = EMP1.DEPT_NO, и значением этого условия будет uknown для любой строки таблицы EMP (EMP1), просматриваемой в цикле этого подзапроса. Поскольку uknown не является разрешающим условием, результирующая таблица подзапроса будет пуста, и агрегатная функция AVG выдаст значение NULL. По этому поводу значением условия внешнего запроса будет uknown, и строка s не войдет в его результирующую таблицу.

* В стандарте SQL:1999 разрешается применять предикат LIKE только для битовых строк типа BLOB. Битовые строки типов BIT и BIT VARYING не допускаются.

* Мы не обсуждаем в этом курсе предикаты, основанные на использовании выражений типа мультимножества, введенные в стандарте SQL:2003.

* Здесь снова идет речь о семантике выполнения оператора SELECT. В стандарте, естественно, не требуется, чтобы в реализации языка запросы с корреляционными подзапросами выполнялись в точности так, как описывается ниже. Суть в том, что какой бы реальный алгоритм выполнения такого запроса не использовался, результат выполнения должен быть точно таким же, как если бы запрос выполнялся по описываемой схеме.

* Кстати, в этом случае можно было бы обойтись введением одного псевдонима, оставив в качестве неявного второго псевдонима имя таблицы – EMP.

* Покажем это в развернутой форме. Пусть s текущая строка таблицы EMP, просматриваемой в цикле внешнего запроса, и пусть s. DEPT_NO содержит неопределенное значение. Тогда для строки s условие первого подзапроса будет иметь вид NULL = EMP1.DEPT_NO, и значением этого условия будет uknown для любой строки таблицы EMP (EMP1), просматриваемой в цикле этого подзапроса. Поскольку uknown не является разрешающим условием, результирующая таблица подзапроса будет пуста, и агрегатная функция AVG выдаст значение NULL. По этому поводу значением условия внешнего запроса будет uknown, и строка s не войдет в его результирующую таблицу.

* В стандарте SQL:1999 разрешается применять предикат LIKE только для битовых строк типа BLOB. Битовые строки типов BIT и BIT VARYING не допускаются.

* Здесь мы прибегаем к компромиссу между реляционной терминологией и моделью данных SQL: конечно, в реляционной модели кортеж из неопределенных значений не может соответствовать заголовку отношения, поскольку NULL не является значением ни одного типа данных.

* Оба термина являются приемлемыми. Речь идет об агрегатных функциях, поскольку аргументом функции является агрегатное (составное) значение. Речь идет о функциях над множествами, поскольку аргументом функции является множество (в общем случае, мультимножество) значений. Но более правильно было бы говорить о групповых функциях, поскольку в большинстве случаев такие функции работают на значениях столбцов групп строк.

* Обратите внимание на то, что это еще один вид различения строк в SQL и еще одна скрытая интерпретация неопределенного значения. COUNT (*) работает так, как если бы выполнялось соотношение (NULL = NULL) º false. Тем самым, в SQL применяются все три возможные интерпретации NULL. При вычислении логических выражений полагается (NULL = NULL) º uknown; при определении строк-дубликатов неявно считается, что (NULL = NULL) º true; наконец, при вычислении агрегатной функции COUNT (*) неявно полагается, что (NULL = NULL) º false. Конечно, в такой “тройственности” нет ничего хорошего, но в контексте языка SQL приходится мириться с этим и другими негативными последствиями наличия неопределенных значений.

* Интересно, что для этого запроса возможна альтернативная формулировка с использованием операции CROSS JOIN: SELECT * FROM table1 CROSS JOIN table2. Может возникнуть естественный вопрос: зачем вводить специальную конструкцию для декартова произведения? По мнению автора, эта конструкция была введена, главным образом, для повышения уровня общности языка SQL. Кроме того, использование явного ключевого слова CROSS JOIN является подтверждением того, что пользователь действительно желает получить декартово произведение, а не опустил по ошибке раздел WHERE.

* Для удобства читателей напомним, что по определению выражение COALESCE (V1, V2) эквивалентно следующему выражению с переключателем: CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END.

** Совпадают в строгом смысле, т.е. значение столбца table1.c совпадает со значением столбца table2.c тогда и только тогда, когда значение операции сравнения table1.c = table2.c является true.

* За очевидностью мы опустим пример CROSS JOIN.

* Конечно, предлагаемый русский вариант термина lateral слишком громоздок. По всей видимости, если этот механизм войдет в практику пользователей SQL, нужно будет использовать качестве термина что-то вроде латеральной порождаемой таблицы. Но здесь для нас главным является не обеспечение хорошей новой терминологии, а обеспечение понимания материала.

** Тем самым, ссылка на LD-таблицу не может быть первой в списке раздела FROM. Кстати, может возникнуть естественный вопрос: почему разрешаются ссылки только на таблицы, находящиеся в списке раздела FROM только слева LD-таблицы? Стандарт отвечает на этот вопрос весьма просто и бесхитростно. Если разрешить использовать ссылки, находящиеся и слева, и справа от спецификации ссылки на LD-таблицу, то это может привести к зацикливанию при выполнении раздела FROM. Поэтому нужно было выбирать одно из направлений, и было выбрано направление слева направо.

* Конечно, мы показали строки результирующей таблицы, расположенными в удобном для нас порядке только для упрощения объяснений. В действительности, строки результирующая таблицы (как обычно) будут расположены в порядке, определяемом системой. Чтобы добиться в точности такого порядка расположения строк, как это показано на рис. 16.1, к формулировке запроса из примера 16.1 нужно добавить раздел
ORDER BY DEPT_NO, EMP_BDATE.

* Мы опять искусственным образом упорядочили результат запроса для удобства пояснений.

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

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

* Обратите внимание, что формально эта формулировка не отвечает требованиям SQL/92 для спецификаций запросов, допускающих применение операций обновления. Но в действительности здесь вложенный подзапрос вычисляется в единственное значение при отсутствии какой-либо корреляции с внешним вхождением таблицы EMP.

* Множество, элементы которого невозможно различить, может быть либо пустым, либо содержать только один элемент.

** В этом случае таблица соответствует понятию мультимножества.

* Определение выражения COALESCE (V1, V2) см. в разд. 12.2 Лекции 12.

* Напомним из Лекции 13, что в соответствии с семантикой оператора выборки в результат раздела WHERE входят все строки результата раздела FROM, для которых результатом вычисления логического условия раздела WHERE является true.

* Напомним из Лекции 13, что на вход раздела HAVING подается результат раздела GROUP BY, если этот раздел присутствует в спецификации запроса, иначе – результат раздела WHERE, если этот раздел присутствует в спецификации запроса, иначе – результат раздела FROM.

* Будем считать, что тем, кто пользуется представлением MORE_RICH_EMP, неизвестно ограничение EMP_SAL < 20000.00, на котором основывается представление MIDDLE_RICH_EMP.

* Непонятно, откуда происходит это ограничение. Скорее всего, в будущих версиях стандарта оно будет снято.

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

* Для читателей, которые имеют хотя бы минимальный опыт работы с продуктами компании Oracle, заметим, что во многих своих чертах SQL/PSM напоминает PL/SQL. Одной из причин, на основании которых мы отказались от описания SQL/PSM в этой книге, является то, что до сих пор (первый вариант стандарта SQL/PSM был опубликован в 1996 г.) нет ни одной реализации SQL, в которой этот стандарт был бы реализован полностью (точнее, ни одна такая реализация не известна автору).

* Во многом на этих возможностях основываются механизмы SQL:1999, предназначенные для определения на уровне пользователя новых типов данных и их операций. Эта тематика также выходит за пределы данной книги (хотя мы немного затронем соответствующие вопросы в последних лекциях этого курса).

** На самом деле, для написания процедур, функций и методов допускается использование не только языка SQL/PSM, но и традиционных языков программирования, для которых в стандарте определены правила связывания с SQL. В последних лекциях курса мы немного затронем и эту тему.

*** Для упрощения будем считать, что идентификаторы уволенных служащих не используются повторно.

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

* Здесь мы опять честно пересказали стандарт SQL:1999. И снова предложенное решение выглядит простым, но не убедительным.

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

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

* Обратите внимание, что формально эта формулировка не отвечает требованиям SQL/92 для спецификаций запросов, допускающих применение операций обновления. Но в действительности здесь вложенный подзапрос вычисляется в единственное значение при отсутствии какой-либо корреляции с внешним вхождением таблицы EMP.

* Множество, элементы которого невозможно различить, может быть либо пустым, либо содержать только один элемент.

** В этом случае таблица соответствует понятию мультимножества.

* Определение выражения COALESCE (V1, V2) см. в разд. 12.2 Лекции 12.

* Напомним из Лекции 13, что в соответствии с семантикой оператора выборки в результат раздела WHERE входят все строки результата раздела FROM, для которых результатом вычисления логического условия раздела WHERE является true.

* Напомним из Лекции 13, что на вход раздела HAVING подается результат раздела GROUP BY, если этот раздел присутствует в спецификации запроса, иначе – результат раздела WHERE, если этот раздел присутствует в спецификации запроса, иначе – результат раздела FROM.

* Будем считать, что тем, кто пользуется представлением MORE_RICH_EMP, неизвестно ограничение EMP_SAL < 20000.00, на котором основывается представление MIDDLE_RICH_EMP.

* Непонятно, откуда происходит это ограничение. Скорее всего, в будущих версиях стандарта оно будет снято.

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

* Для читателей, которые имеют хотя бы минимальный опыт работы с продуктами компании Oracle, заметим, что во многих своих чертах SQL/PSM напоминает PL/SQL. Одной из причин, на основании которых мы отказались от описания SQL/PSM в этой книге, является то, что до сих пор (первый вариант стандарта SQL/PSM был опубликован в 1996 г.) нет ни одной реализации SQL, в которой этот стандарт был бы реализован полностью (точнее, ни одна такая реализация не известна автору).

* Во многом на этих возможностях основываются механизмы SQL:1999, предназначенные для определения на уровне пользователя новых типов данных и их операций. Эта тематика также выходит за пределы данной книги (хотя мы немного затронем соответствующие вопросы в последних лекциях этого курса).

** На самом деле, для написания процедур, функций и методов допускается использование не только языка SQL/PSM, но и традиционных языков программирования, для которых в стандарте определены правила связывания с SQL. В последних лекциях курса мы немного затронем и эту тему.

*** Для упрощения будем считать, что идентификаторы уволенных служащих не используются повторно.

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

* Здесь мы опять честно пересказали стандарт SQL:1999. И снова предложенное решение выглядит простым, но не убедительным.

* Напомним, что в этом курсе мы не касаемся вопросов интернационализации и локализации языка SQL.

* Как будет показано в следующем подразделе, термин роль в языке SQL полностью соответствует своему житейскому смыслу. И в мире баз данных люди большей частью играют чью-то роль, а не представляют себя лично.

* В соответствии со стандартом любые зарегистрированные в системе пользователь или роль автоматически являются владельцами части схемы базы данных, имена объектов которой начинаются с соответствующего идентификатора, за которым следует символ “.”.

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

* Чтобы хотя бы немного облегчить чтение данного подраздела, забегая вперед, заметим, что понятия сессии и подключения относятся к сеансу работы клиентского приложения с некоторым сервером SQL-ориентированной базы данных.

* Кстати, это один из тех случаев, когда иметь право не означает автоматически иметь возможность реализации своего права. SQL допускает, например, наличие привилегии INSERT для представления, к которому операция INSERT не применима.

* Кстати, стандарт полностью отдает на волю реализации способ того, каким образом сделать неопределенным значение текущего пользовательского идентификатора SQL-сессии.

* В действительности, как видно из приведенных описаний, варианты операторов GRANT и REVOKE для привилегий и ролей настолько близки, что непонятно их синтаксическое разделение, которое, очевидно, усложняет реализацию. Как кажется, это разделение не обосновано в стандарте SQL:1999.

** В общем случае состав и порядок выполнения операций, выполняемых внутри транзакции, становится известным только на стадии выполнения.

*** Читателей может смутить параллельное использование терминов согласованность и целостность. С точки зрения автора этого курса, в контексте баз данных эти два термина эквивалентны. Единственным критерием согласованности данных является их удовлетворение ограничениям целостности, т.е. база данных находится в согласованном состоянии тогда и только тогда, когда она находится в целостном состоянии.

**** Здесь мы опять сталкиваемся с терминологической трудностью, существующей уже много лет. В англоязычной терминологии имеется замечательный термин concurrent, который соответствует как реально параллельному, так и квазипараллельному выполнению транзакций (или процессов). Русский эквивалент одновременный не совсем точно соответствует смыслу оригинала, но лучшего варианта пока нет.

* Правильнее было бы говорить SQL-транзакции, но в этом курсе мы не обсуждаем другие модели транзакций и поэтому будем использовать термин транзакция в смысле SQL-транзакция.

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

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

* В действительности, этот подход был введен еще в проекте System R.

* Правильнее было бы сказать почти всегда, поскольку в SQL предусматривается особый способ терминации транзакций, ини

Дата добавления: 2014-01-03