Х. Дарвин и К. Дэйт2)
- РМ-предписания
- РМ-запрещения
- ОО-предписания
- ОО-запрещения
- ВЕСЬМА НАСТОЯТЕЛЬНЫЕ РМ-предложения
- ВЕСЬМА НАСТОЯТЕЛЬНЫЕ ОО-предложения
Мы представляем манифест о направлениях будущего развития систем управления данными и СУБД. Этот манифест состоит из ряда предписаний, запрещений и "весьма настоятельных предложений".
Эта работа представляет собой манифест, касающийся будущего систем управления данными и СУБД. В нем выражено намерение следовать двум предшествующим манифестам [1,25] и, как мы надеемся, заменить их. Отсюда наш выбор названия. Работа [1], презрительно отвергая реляционную модель данных, игнорирует ее важность и значимость. Вместе с тем, как мы полагаем, она терпит неудачу в попытке определить какую-либо четкую линию. Вторая работа [25] вежливо отдает должное реляционной модели, но в слишком оптимистической погоне за ее идеалами тем не менее не упоминает и не подчеркивает безнадежности продолжения следования широко принятому извращению этой модели, воплощенному в SQL. Вопреки этому, мы твердо убеждены - любая попытка двигаться вперед для того, чтобы выдержать испытание временем, должна недвусмысленно отвергнуть SQL. Однако мы все-таки должны уделить некоторое внимание вопросу о том, что следует делать с сегодняшним наследием SQL.
Назад к будущему
Мы ищем прочные основы для будущего данных. При этом не считаем, что такие основы способен обеспечить язык баз данных SQL. Вместе с тем мы полагаем, что любые такие основы должны твердо корениться в реляционной модели данных, впервые представленной миру Э.Ф.Коддом в 1969 году в работе [6].
Мы в полной мере сознаем желательность поддержки некоторых возможностей, активно обсуждавшихся в последнее время, в частности, ряда таких возможностей, которые обычно считаются присущими объектной ориентации. Мы полагаем, что такие возможности являются ортогональными реляционной модели. И в силу этого, следовательно, реляционная модель не нуждается ни в каком расширении, ни в какой коррекции или категоризации, а самое главное, ни в каких извращениях для того, чтобы приспособить указанные возможности к какому-либо языку баз данных, способному представлять те основы, которые мы ищем.
Допустим, что такой язык имеется и называется D3).
Язык D будет субъектом определенных предписаний и запрещений. Некоторые из этих предписаний проистекают из реляционной модели данных, и мы будем называть их предписаниями реляционной модели, или для краткости - РМ-предписаниями. Предписания, которые не происходят из реляционной модели, назовем остальными ортогональными предписаниями, или для краткости - ОО-предписаниями. Подобным же образом, мы категоризируем запрещения для языка D.
Перейдем теперь к более подробному обсуждению предписаний и запрещений языка D. Следует заметить, что РМ-предписания и запрещения не могут быть предметом компромисса4). К сожалению, этого совсем нельзя сказать по поводу ОО-предписаний и запрещений, поскольку не существует (во время написания этой работы) ясной и общепринятой модели, на которой они могли бы базироваться. Мы в действительности полагаем, что ОО-предписания могут внести значительный вклад в области, связанные с типами данных, определяемых пользователем, а также с наследованием. Однако пока не достигнут какой-либо консенсус по абстрактной модели даже относительно этих важных вопросов. Поэтому мы предпринимаем усилия, чтобы дать наши собственные определения в этих областях. И единственный честный шаг - предупредить читателя, что наследование, по меньшей мере, порождает ряд вопросов, на которые, как нам представляется, пока еще нет удовлетворительных ответов в доступной литературе. В результате наши предложения в этой области должны по необходимости быть в значительной мере предварительными (см. ОО-предписания2 и 3). Наряду с предписаниями и запрещениями, этот манифест включает также некоторые весьма настоятельные предложения, также подразделяющиеся на РМ-и ОО-категории.
Три заключительные предварительные замечания.
1. Версия реляционной модели, которую мы поддерживаем, если быть точными, это - версия, впервые описанная в работе [16, глава 15] и уточненная далее (в небольшой степени) [11, часть II]. Заметим, однако, что определения кортежа и отношения в данной работе представляют собой незначительно улучшенные варианты определений, приведенных в указанных ранних публикациях.
2. В следующих разделах этой работы мы преднамеренно не вдаемся в многочисленные подробности относительно различных предписаний, запрещений и предложений. (В действительности, мы предоставляем иногда некоторые пояснительные комментарии по определенным вопросам, однако все такие комментарии можно было бы удалить, не затрагивая техническое существо нашего предложения). Намерение авторов состоит в том, чтобы представить вслед за этим манифестом ряд специальных статей, в которых различные аспекты нашего предложения были бы описаны более глубоко.
3. В тех случаях, когда это недостаточно очевидно, мы хотели бы, чтобы было предельно ясно, что главная сфера наших интересов - это абстрактная модель, а не проблемы реализации (хотя пояснительные комментарии касаются иногда таких проблем в целях достижения ясности).
РМ-предписания
1. Домен - это именованное множество значений. Манипулирование такими значениями, которые могут быть произвольной сложности, должно быть возможно исключительно посредством операторов, определенных для этого домена (доменов) в запросе (см. РМ-предписание 3 и ОО-предписание 3), т.е. значения домена должны быть инкапсулированы (за исключением тех случаев, которые отмечаются в РМ-предписании 4). Для каждого домена должна быть доступна совокупность условных обозначений, позволяющих явно специфицировать (или "конструировать") произвольное значение из этого домена.
КОММЕНТАРИИ.
Мы интерпретируем термины домен и тип данных (для краткости тип) как синонимичные и взаимозаменяемые. В том же самом смысле используется иногда термин класс объектов, но мы не используем этого более позднего термина.
Мы называем значения домена вообще скалярными значениями (или для краткости скалярами). Заметим, следовательно, что мы явно допускаем "скалярные" значения произвольной сложности. Таким образом, например, массив стеков списков 3/4 и т.д. может рассматриваться как скалярное значение в подходящих обстоятельствах.
2. Скалярное значение всегда должно появляться (по крайней мере, концептуально) с некоторой сопутствующей идентификацией того домена, к которому относится это значение в запросе. Иными словами, скалярные значения должны быть типизированы.
3. Для каждого упорядоченного списка из n-доменов, не обязательно различных (n >= 0), D должен поддерживать определения допустимых n-арных операторов, которые применимы к соответствующим упорядоченным спискам из n-значений, взятых по одному в каждом из этих n-доменов. Определение каждого такого оператора должно включать спецификацию домена результата этого оператора. Определения таких операторов должны быть логически отделены от определений доменов, к которым они относятся (а не быть "встроенными" в эти определения).
КОММЕНТАРИИ.
Мы интерпретируем термины операторы и функции как синонимичные и взаимозаменяемые. В этом же смысле иногда применяется термин метод, однако мы не используем этого более позднего термина.
Функция, которая непосредственным образом или косвенно присваивает значение одному из своих аргументов, называется мутатором (mutator) или просто функцией с побочным эффектом. Такие функции вызывают всеобщее возражение, но они не могут быть запрещены, но могут быть необходимы в связи с наследованием.
4. Пусть V - некоторый домен. В состав определенных для V-операторов должны по необходимости входить такие операторы, явная цель которых - раскрывать фактические представления значений из V. Заметим, что эти операторы - и только они - нарушают, таким образом, инкапсуляцию значений из V.
КОММЕНТАРИИ.
Наше намерение состоит в том, чтобы: а) такие нарушающие инкапсуляцию операторы использовались только в реализации других операторов и б) подобный эффект достигался с помощью системных механизмов авторизации. Иными словами, фактическое представление значений домена должно быть скрыто от большинства пользователей.
Пусть V - некоторый домен. Отметим, что часто будет желательно определить множество операторов, действие которых состоит в том, чтобы предъявлять одно из возможных представлений (не обязательно фактическое представление) для значений из V. Если заданы такие операторы, пользователь действительно будет способен оперировать значениями из V, точно так же, как если бы он имел дело с фактическими представлениями.
Хотя фактические представления значений домена не релевантны спецификациям данного манифеста, может быть полезно указать, что, если v1 и v2 - различные значения из домена V, ничто в языке D не требует, чтобы фактические представления v1 и v2 были бы одной и той же формы. Например, V может быть доменом "текст", а v1 и v2 - двумя документами, подготовленными с использованием различных текстовых процессоров.
5. D должен поставляться оснащенным некоторыми стандартными (встроенными) доменами, включающими, в частности, домен значений истинности (истина и ложь). Для этого домена должны поддерживаться обычные операторы (NOT, AND, OR, IF 3/4 THEN 3/4, IFF, и т.д.).
6. Пусть H - некоторый заголовок кортежа (a tuple heading) (см. РМ-предписание 9). Тогда должна существовать возможность определить домен, значения которого являются кортежами с заголовком H, - иными словами, TUPLE должен быть допустимым конструктором типов. Определенные для такого домена операторы должны в точности составлять множество кортежных операторов (tuple operators), поддерживаемых D. Оно включает оператор для конструирования кортежа из специфицированных скаляров, а также оператор для выделения специфицированных скаляров из кортежа. Должны также включаться средства сборки и разборки ("nest"/"unnest") вложенных кортежей, аналогичные подобным средствам для отношений, описанным в работе [16, глава 6].
7. Пусть H - некоторый заголовок отношения (см. РМ-предписание 10). Тогда должна существовать возможность определения домена, значения из которого являются отношениями с заголовком H. Иными словами, RELATION должно быть допустимым конструктором типов. Операторы, определенные для такого домена, должны в точности представлять собой множество реляционных операторов, поддерживаемых D. В их число должен входить оператор для конструирования отношения из специфицированных кортежей, а также другой оператор для выделения специфицированного кортежа из отношения. Должны иметься также возможности сборки и разборки ("nest"/"unnest") вложенных отношений, описанные в [16, глава 6].
КОММЕНТАРИИ.
Заметим, что с точки зрения любого отношения, которое включает атрибут, определенный на таком домене, "скалярные" значения в этом домене (как и значения всех доменов) являются все еще инкапсулированными. (Аналогичное замечание относится также к РМ-предписанию6.) Мы не поддерживаем в явном виде отношений в форме NF2 ("NF в квадрате"), описанной, например, в [24], которая вовлекает главные расширения классической реляционной алгебры.
8. Для каждого домена должен быть определен оператор сравнения на равенство (equals, "="). Пусть v1 и v2 - некоторые значения из какого-либо домена V. Тогда v1 = v2 должно быть истинно тогда и только тогда, когда v1 и v2 являются одним и тем же элементом V.
9. Кортеж t - это множество упорядоченных триплетов вида
A - имя атрибута из t. Никакие два различных триплета в t не должны содержать одно и то же имя атрибута;
V - имя (единственного) домена, соответствующего атрибуту A;
v - некоторое значение из домена V, называемое значением атрибута для атрибута A в кортеже t.
Множество упорядоченных пар
10. Отношение R состоит из заголовка и тела. Заголовок R - это заголовок кортежа H, определенный в РМ-предписании 9. Тело R - это множество B-кортежей таких, что все они имеют заголовок H. Атрибуты и соответствующие домены, указанные в H, - это атрибуты и соответствующие им домены R. При заданном заголовке отношения должна быть доступна совокупность обозначений, которая бы позволяла явным образом специфицировать или"построить") произвольное отношение с этим заголовком.
КОММЕНТАРИИ.
Заметим, что каждый кортеж в R содержит в точности одно значение v для каждого атрибута A в H. Иными словами, R находится в первой нормальной форме - 1NF.
Мы проводим строгое различие между отношениями самими по себе и переменными-отношениями (см. РМ-предписание13). Аналогичное различие относится также и к базам данных (см. РМ-предписание15). Мы осознаем, что эти терминологические различия будут, к сожалению, непривычны большинству читателей. Тем не менее мы принимаем их в интересах точности.
11. Скалярная переменная типа V - это переменная, допустимыми значениями которой являются скаляры из специфицированного домена V - объявленного домена (the declared domain) для этой скалярной переменной. Создание скалярной переменной S приводит в результате к присваиванию S некоторого начального скалярного значения - либо значения, явно специфицированного как часть операции, которая создает S, либо некоторого значения, зависящего от реализации, если никакое явное значение для этой цели не указано.
12. Переменная-кортеж (a tuple variable) типа H - это переменная, допустимыми значениями которой являются кортежи со специфицированным заголовком кортежа H - объявленным заголовком (the declared heading) для этой переменной-кортежа. Создание переменной-кортежа T приводит в результате к присваиванию T некоторого начального значения-кортежа - либо значения, явно специфицированного как часть операции, которая создает T, либо некоторого значения, зависящего от реализации, если никакое явное значение для этой цели не указано.
13. Переменная-отношение (a relation variable) - для краткости R-переменная (relvar) - типа H - это переменная, допустимыми значениями которой являются отношения со специфицированным заголовком отношения H - объявленным заголовком для этой R-переменной.
14. R-переменные могут быть базовыми либо производными. Производная R-переменная - это такая R-переменная, значение которой в произвольный заданный момент времени представляет собой отношение, которое определяется посредством специфицированного реляционного выражения (см. РМ-предписания18-20). Реляционное выражение в запросе должно быть таким, чтобы производная R-переменная обновлялась в соответствии с правилами и принципами, описанными в работах [11, глава 17] и [18-19]. Базовая R-переменная - это R-переменная, которая не является производной. Создание базовой R-переменной должно привести в результате к присваиванию этой базовой R-переменной в качестве начального значения некоторого пустого отношения.
КОММЕНТАРИИ.
Базовая и производная R-переменных соответствуют тому, что обычно называется "базовыми отношениями" и "обновляемыми представлениями". Заметим, однако, что мы считаем значительно более широкую категорию представлений обновляемыми, по сравнению с традиционными подходами [18-19].
15. Переменная-база данных - для краткости DB-переменная - это именованное множество R-переменных. Каждая DB-переменная является субъектом для множества ограничений целостности (см. РМ-предписания 23 и 24). Значение данной DB-переменной в любой заданный момент времени представляет собой множество упорядоченных пар
КОММЕНТАРИИ.
Стоит обратить внимание на то, что мы явно не рассматриваем домены, как относящиеся к какой-либо конкретной DB-переменной.
16. Каждая транзакция взаимодействует в точности с одной DB-переменной. Однако различные транзакции могут взаимодействовать с различными DB-переменными, и различные DB-переменные не обязательно являются непересекающимися. Кроме того, транзакция может динамически изменять ассоциированную с нею DB-переменную, добавляя и/или удаляя R-переменные (см. РМ-предписание 17).
КОММЕНТАРИИ.
Одна из целей концепции DB-переменной заключается в том, чтобы определить область действия реляционных операций. Если DB-переменная X ассоциирована с транзакцией T, то T не должна упоминать какую-либо R-переменную, которая является частью какой-либо иной DB-переменной, а не частью DB-переменной X.
Множество всех базовых R-переменных может рассматриваться как "базовая" DB-переменная. Отдельные транзакции взаимодействуют, однако с "производными" или "пользовательскими" DB-переменными, которые, вообще говоря, состоят из комбинации базовых и производных R-переменных.
Механизм для установления и разрыва связей между транзакцией и соответствующей ей единственной DB-переменной не специфицируется в данном манифесте.
17. Язык D должен обеспечивать операторы для создания (create) и разрушения (destroy) доменов, переменных (в том числе R-переменных) и ограничений целостности. Каждый явно созданный домен, каждые переменная или ограничение целостности должны быть именованными. Каждая базовая R-переменная должна иметь, по крайней мере, один возможный ключ (candidate key), явно специфицированный как часть той операции, которая создает эту базовую R-переменную.
КОММЕНТАРИИ.
Создание и разрушение DB-переменных (которые, как мы предполагаем, должны быть долгоживущими ("persistent")) осуществляется вне среды языка D.
18. Выразительные средства реляционной алгебры в том виде, как она определена в работе [11, часть II], должны быть избавлены от чрезмерной многоречивости.
КОММЕНТАРИИ.
"Без чрезмерной многоречивости" предполагает наряду с другими вещами, что:
- должны быть в равной мере легко выразимы кванторы всеобщности и существования. Например, если язык D включает специальный оператор для проекции (projection) отношения, то он должен также включать и специальный оператор для общей формы деления (division) отношений, описанной (как DIVIDEBY PER) в работе [16, глава 11];
- должны быть также в равной мере легко выразимы проекция на специфицированные атрибуты и проекция на все атрибуты, кроме специфицированных.
19. Как имена R-переменных, так и значения явных ("сконструированных") отношений, должны быть допустимыми реляционными выражениями.
20. Язык D должен предоставлять операторы для создания и разрушения именованных функций, значения которых в любой заданный момент времени являются отношениями, определяемыми посредством специфицированного реляционного выражения. Обращения к таким функциям должны быть допустимы в реляционных выражениях везде, где допускаются явные значения отношений.
КОММЕНТАРИИ.
Функции такого рода соответствуют тому, что обычно называется "представлениями только для чтения" (read-only views), за исключением того, что мы допускаем параметризацию реляционных выражений, определяющих подобного рода "представления". Такие параметры представляют собой скалярные значения и допустимы всюду в определяющем реляционном выражении, где допускаются в явном виде скалярные значения. (Вероятно, имеется также возможность поддерживать параметры кортежей и отношений. См. Весьма настоятельное РМ-предложение 7).
21. Язык D должен допускать:
а) присваивание значения кортежного выражения переменной-кортежу;
б) присваивание значения реляционного выражения R-переменной, обеспечивая в обоих случаях удовлетворение требований совместимости типов (type compatibility) в том виде, как они описаны в работе [11, глава 19].
КОММЕНТАРИИ.
Это предписание, конечно, не отвергает возможности дополнительного обеспечения удобных кратких обозначений такого рода, как INSERT, UPDATE и DELETE, описанных в работе [11, часть II].
22. Язык D должен поддерживать определенные операторы сравнения. Операторами, определенными для сравнения кортежей, должны быть лишь "=" и "#". Операторы, определенные для сравнения отношений, должны включать "=", "#", "является подмножеством" и т.д. Должен поддерживаться также оператор "к" , позволяющий проверять, является ли кортеж элементом отношения. Во всех случаях должны удовлетворяться требования совместимости типов, описанные в работе [11, глава 19].
23. Любое выражение, которое вычисляет значение истинности, называется условным выражением (conditional expression). Любое условное выражение, которое является замкнутой правильно построенной формулой (closed WFF) реляционного исчисления (или логически эквивалентно ей) [11, часть II], должно быть допустимо в качестве спецификации ограничения целостности. Ограничения целостности должны классифицироваться в соответствии со схемой, описанной в работах [11, глава 16] и [18-19], как ограничения на домены, атрибуты, отношения и базу данных, и язык D должен полностью поддерживать механизм вывода ограничений (constraint inference), предусматриваемый этой схемой.
24. Каждая R-переменная обладает соответствующим предикатом отношения, а каждая DB-переменная - соответствующим предикатом базы данных, которые поясняются в работах [11, глава 16] и [18-19]. Предикат отношения должен удовлетворяться на границах операторов. Предикат базы данных должен удовлетворяться на границах транзакций.
КОММЕНТАРИИ.
На эти понятия, которые как мы полагаем, являются и весьма существенными, и фундаментальными, к сожалению, в прошлом не обращалось должного внимания, и поэтому мы немного затрагиваем здесь эту тему. Предикат отношения представляет собой, по существу, конъюнкцию всех ограничений целостности, которые налагаются на R-переменную в запросе, а предикат базы данных - это конъюнкция всех ограничений целостности, которые налагаются на DB-переменную в запросе. К этому пункту не следует относиться слишком строго, поскольку это предикаты, а не имена, которые представляют семантику базы данных.
Утверждение о том, что предикаты отношений должны удовлетворяться на границах операторов, в точности означает, что никакая реляционная операция присваивания не должна оставлять любую R-переменную в состоянии, в котором нарушается ее предикат отношения. Аналогично утверждение о том, что предикаты базы данных должны удовлетворяться на границах транзакций, в точности означает, что никакая транзакция не должна оставлять соответствующую DB-переменную в состоянии, в котором нарушается ее предикат базы данных.
Это предписание, кроме того, предполагает, что должно быть невозможно обновлять "обновляемые представления" (т.е. производные R-переменные) таким образом, чтобы нарушалось определение этого представления. Иными словами, "обновляемые представления" всегда должны быть субъектом того, что называется в SQL возможностью каскадной проверки (CASCADED CHECK OPTION) [17].
25. Каждая DB-переменная должна включать множество R-переменных, которое составляет каталог этой DB-переменной. Должна быть возможность осуществлять присваивание R-переменным каталога.
КОММЕНТАРИИ.
Это предписание предполагает, что каталог должен представлять собой нечто, что обычно называется "самоописываемым".
26. D должен быть построен в соответствии с четко обоснованными принципами хорошего проекта языка, описанными, например, в работе [3].
КОММЕНТАРИИ.
Должны быть, таким образом, абсолютно исключены произвольные ограничения, например, такие, как описаны в [8, глава 12], [14] и [17], а также все другие случайные понятия и конструкции.
РМ-запрещения
Внимательный читатель заметит, что многие из запрещений в этом разделе являются логическими следствиями РМ-предписаний. Однако в связи с теми ошибками, которые были, к сожалению, допущены в SQL, мы чувствуем, что необходимо описать здесь некоторые из этих следствий в целях пояснения.
1. Язык D не должен включать никаких конструкций, которые зависят от определения какого-либо упорядочения атрибутов отношения. Вместо этого для каждого отношения R, выразимого в D, атрибуты отношения должны быть различимы по имени.
КОММЕНТАРИИ.
Это запрещение означает, что не допускается более никаких анонимных столбцов, таких как в операторе SQL SELECT X + Y FROM T, и никаких дубликатов имен столбцов, как в операторах SQL SELECT X, X FROM T и SELECT T1.X, T2.X FROM T1, T2.
2. Язык D не должен включать никаких конструкций, которые зависят от определения какого-либо упорядочения кортежей отношения.
КОММЕНТАРИИ.
Этим запрещением вовсе не предусматривается, что такое упорядочение не может быть установлено, например, для целей представления. Оно предполагает, скорее, что в результате установления такого упорядочения отношение конвертируется в нечто, что не является отношением (возможно, в последовательность или упорядоченный список).
3. Для каждого отношения R, если t1 и t2 являются двумя различными его кортежами, должен существовать атрибут A из R такой, что значение атрибута A в t1 не равно значению атрибута A в t2.
КОММЕНТАРИИ.
Иными словами, "строки-дубликаты" являются незаконными абсолютно, категорически и однозначно. То, что мы сказали здесь три раза, - справедливо.
4. Каждый атрибут каждого кортежа каждого отношения должен иметь значение, которое является значением из подходящего домена.
КОММЕНТАРИИ.
Иными словами, больше никаких неопределенных значений и больше никакой многозначной логики!
5. В D не следует забывать как того, что отношения с нулем атрибутов заслуживают внимания и представляют интерес, так и того, что возможные ключи с нулем компонентов подобным же образом заслуживают внимания и интересны.
6. Язык D не должен включать никаких конструкций, которые связаны с "физическим" уровнем, уровнем "среды хранения" или "внутренним" уровнем системы либо логически подвергаются их воздействию (иных, чем функции, которые явно раскрывают фактическое представление значений домена - см. РМ-предписание4). Если разработчик имеет желание или ему необходимо ввести какого-либо рода "язык определения структуры хранения", операторы этого языка и отображения DB-переменных в физическую среду хранения должны быть полностью отделены от всего, что выражено в D.
7. Не должно быть никаких покортежных операций над отношениями.
КОММЕНТАРИИ.
Операторы INSERT, UPDATE и DELETE, если они предусматриваются, вставляют, обновляют или удаляют (соответственно применяемому оператору) всегда множество кортежей. Множество, состоящее из одного кортежа, является просто частным случаем (хотя и может оказаться удобным предусмотреть для такого случая специальный синтаксис).
Покортежный поиск (аналогичный выполняемому оператором FETCH языка SQL через курсор), хотя он и запрещается, и вообще в корне осуждается, может эффективно выполняться, если это желательно, путем конвертирования этого отношения в упорядоченный список кортежей и выполнения операций над этим списком.
Категорические возражения вызывает покортежное обновление (аналогичное операторам SQL UPDATE и DELETE, выполняемым с помощью курсора).
8. Язык D не должен включать какой-либо специальной поддержки для "составных доменов" или "составных столбцов" (как предлагается, например, в работе [4]), поскольку такие функциональные возможности могут достигаться, если это желательно, с помощью уже описанной поддержки доменов. См. работу [9].
9. Операторы подавления проверки доменов (в том, например, виде, как они описаны в работе [4]) являются случайными и не необходимыми. Они не должны поддерживаться.
10. Язык D не должен называться SQL.
ОО-предписания
1. Язык D должен допускать проверку типов на стадии компиляции.
КОММЕНТАРИИ.
В этом предписании имеется в виду, что в той мере, в какой это осуществимо, следует выполнять проверку на стадии компиляции с тем, чтобы на стадии исполнения никакие ошибки типов не имели места. Это требование не исключает возможности "скомпилировать и исполнить" ("compile and go"), а также реализаций по методу интерпретации.
2. Простое наследование (Single Inheritance). Если язык D позволяет определять некоторый домен V" как поддомен некоторого супердомена V, то такая возможность должна соответствовать некоторой ясно определенной и общепринятой модели.
КОММЕНТАРИИ.
Наша надежда заключается в том, что такая "ясно определенная и общепринятая" модель наследования когда-нибудь будет действительно найдена. Термин "общепринятая" призван здесь подчеркнуть, что авторы настоящего манифеста наряду с другими выступают в поддержку указанной модели. От такой поддержки нет оснований отказываться.
Отметим, что поддержка наследования подразумевает некоторые расширения определений скалярной переменной, переменной-кортежа, отношения и R-переменной. Представляется также, что в этой связи потребуется, вероятно, несколько ослабить ОО-предписание 1. Набросок возможной модели наследования, которая бы интегрировала эти соображения, приводится в готовящемся к изданию приложении к данному манифесту (предварительную его версию можно получить в настоящее время у авторов).
3. Множественное наследование (Multiple Inheritance). Если в языке D допускается определение некоторого домена V" как поддомена какого-либо супердомена V, то не следует препятствовать также и тому, чтобы V" мог быть дополнительно определен как поддомен и некоторого другого супердомена W, который не совпадает с V и не является его супердоменом (в случае, если требования ОО-предписания 2 не препятствуют такой возможности).
4. Язык D должен обладать вычислительной полнотой. Это означает, что D может (но не обязан) поддерживать вызовы из так называемых "программ на включающем языке" ("host programs"), записанных на языке, ином, чем D. Подобным же образом, D может (но не обязан) поддерживать использование других языков программирования для реализации функций, определяемых пользователем.
КОММЕНТАРИИ.
Этим предписанием мы не намерены чрезмерно подрывать такую возможность, как оптимизируемость D. Мы не намерены также рассматривать его как рецепт по использованию процедурных конструкций, подобных циклам, для выполнения запросов к базе данных или проверки целостности данных. Идея, скорее, состоит в том, что вычислительная полнота будет необходима (вообще) для реализации функций, определяемых пользователем. Иметь возможность реализовать такие функции в самом D, вероятно, было бы более удобным, чем по необходимости совершать экскурсы в некоторые другие языки - экскурсы, которые в любом случае должны, по-видимому, порождать трудные проблемы для оптимизаторов. Мы, конечно, согласны с тем, что может оказаться желательным запретить использование некоторых возможностей D вне кода, который реализует такие функции. С другой стороны, такой запрет может слишком жестко ограничить то, что позволяет сделать "самостоятельная" прикладная программа (т.е. программа, которая не требует вызова из какой-либо программы, написанной на некотором другом языке). Эта проблема требует дополнительного изучения.
5. Инициирование транзакции должно осуществляться только с помощью явного оператора "начать транзакцию" ("start transaction"). Завершение транзакции должно осуществляться только с помощью оператора "зафиксировать" ("commit") или "откатить" ("rollback"). Оператор "зафиксировать" должен быть явным, в то время как оператор "откатить" может быть и неявным (в случае, когда транзакция завершается неудачно, хотя не было никаких неудачно завершившихся операторов в самой транзакции).
КОММЕНТАРИИ.
Если транзакция T завершается оператором "зафиксировать" (случай нормального завершения), сделанные T изменения в применяемой DB-переменной фиксируются. Если же транзакция T завершается оператором "откатить" (случай аварийного завершения), сделанные T изменения в применяемой DB-переменной подвергаются откату. Иными словами, DB-переменные (и только они) обладают свойством "долгожития" ("persistency").
6. Язык D должен поддерживать вложенные транзакции (nested transactions) - т.е. он должен позволять транзакции T1 начинать другую транзакцию T2 прежде, чем выполнение самой T1 будет закончено, и в этом случае:
а) T2 и T1 будут взаимодействовать с одной и той же DB-переменной (как это фактически предусматривается РМ-предписанием16);
б) D не должен препятствовать возможности асинхронного исполнения T1 и T2. Однако T1 не должна иметь возможности завершиться, прежде чем завершится T2 (иными словами, T2 должна полностью содержаться в T1);
в) откат T1 должен включать отмену результатов T2, даже если T2 была зафиксирована.
7. Пусть A - некоторый агрегатный (aggregate) оператор (например, оператор вычисления суммы SUM), который, по существу, является просто краткой записью некоторого повторяемого диадического оператора - (в случае SUM таким диадическим оператором является "+"). Может оказаться, что аргумент A пуст. Тогда:
а) если для Q существует значение тождественности (в случае "+" значением тождественности является 0), то результатом такого обращения к A должно быть это значение тождественности;
б) в противном случае результат такого обращения к A должен быть не определен.
ОО-запрещения
1. R-переменные не являются доменами.
КОММЕНТАРИИ.
Иными словами, мы категорически отвергаем равенство вида "отношение = класс объектов" (более точно, равенство "R-переменная = класс объектов"), отстаиваемое, например, в работе [23]).
2. Никакое значение (скалярное или любого другого вида) не должно обладать какого-либо рода идентификатором (ID), который как-либо отличается от значения самого по себе.
КОММЕНТАРИИ.
Иными словами, мы отвергаем идею "идентификаторов объектов" ("object ID"). Как следствие этого, мы отвергаем: а) идею о том, что "объекты", возможно, должны использовать такие идентификаторы для совместного использования "подобъектов"; б) идею о том, что пользователи, возможно, должны "разыменовывать" ("dereference") такие идентификаторы (либо явно, либо неявно) для того, чтобы получать значения.
Мы отвергаем также идею "идентификаторов кортежей" (некоторые авторы, как нам кажется, отождествляют идентификаторы кортежей и идентификаторы объектов).
Это запрещение не препятствует тому, чтобы объекты вне DB-переменной обладали идентификаторами, которые являются "каким-либо образом отличными" от самих объектов. Оно не препятствует также появлению таких идентификаторов в DB-переменной. (Мы должны подчеркнуть, что термин "объект" используется здесь в его общем смысле, а не в специализированном смысле объектно-ориентированного подхода.) Поэтому, например, домен имен файлов базовой операционной системы является допустимым доменом.
3. Любое обозначение "общедоступной экземплярной переменной" ("public instance variable"), предоставляемое для оперирования значениями в доменах, должно быть простой и краткой синтаксической записью для вызова определенных специальных функций (и, возможно, "ссылок на псевдопеременные", если такие экземплярные переменные могут появляться в левой части операторов присваивания). Какая-либо непосредственная взаимосвязь между такими экземплярными переменными и фактическим представлением значений из домена в запросе не должна иметь обязательного характера.
4. В языке D не должна поддерживаться ни концепция "защищенных" ("protected") экземплярных переменных - в отличие от приватных ("private"), ни концепция "друзей" ("friends"). Пояснение этих понятий см. в работе [20].
КОММЕНТАРИИ.
Мы полагаем, что проблемы, в связи с которыми возникли намерения обратиться к таким концепциям, решаются лучшим образом с помощью системного механизма авторизации.
ВЕСЬМА НАСТОЯТЕЛЬНЫЕ РМ-предложения
1. Должна существовать возможность спецификации одного или более возможных ключей для каждой производной R-переменной. Вместе с тем для каждой R-переменной (базовой или производной), для которой специфицированы возможные ключи, должна иметься возможность назначения в точности одного из них первичным ключом.
КОММЕНТАРИИ.
Каждая R-переменная действительно обладает одним или более возможных ключей (из которых, по крайней мере, один, а было бы предпочтительнее, чтобы все, должен быть так определен пользователем в случае базовых R-переменных, как это требуется РМ-предписанием 17). Назначение одного из конкретных возможных ключей в качестве первичного является, однако, факультативным по причинам, обсуждаемым в работе [13].
2. Язык D должен включать поддержку для системно-генерируемых ключей с возможностями, описанными в работах [16, глава 5] и [7, глава 19].
3. Язык D должен включать какие-либо удобные краткие декларативные обозначения для выражения: а) ограничений по ссылкам (referential constraints); б) действий по ссылкам (referential actions), таким как "каскадное удаление".
4. Для системы желательно, хотя и в полной мере не осуществимо, обладать способностью выводить (независимые от времени) возможные ключи для каждого отношения R, выразимого в языке D таким образом, что:
а) возможные ключи R становятся возможными ключами R", когда R присваивается R";
б) сведения о возможных ключах R могут включаться в информацию об отношении R, которая доступна пользователю D.
Язык D должен обеспечивать такие функциональные возможности, но без какой-либо гарантии относительно того, что выведенные ключи не являются собственными надмножествами фактических ключей, или даже что некоторое надмножество (собственное или иное) обнаруживается для каждого фактического ключа. Реализации языка D могут, таким образом, состязаться друг с другом в степени успеха обнаружения возможных ключей.
КОММЕНТАРИИ.
Рекомендация о том, что возможные ключи для производных отношений должны выводиться (настолько, насколько это возможно), была фактически предложена в РМ-предписании 23, в котором высказывалось требование поддержки общего механизма вывода ограничений. Возможные ключи упоминаются здесь явным образом, поскольку мы рассматриваем их как важный частный случай по причинам, обсуждаемым в работе [16, глава 10].
5. Язык D должен предоставлять какие-либо удобные (непроцедурные) средства выражения запросов с квотой (например "найти трех самых молодых служащих"). Такая возможность не должна ассоциироваться с механизмом, который конвертирует отношение в упорядоченный список (см. РМ-запрещение2).
6. Язык D должен обеспечивать какие-либо удобные (непроцедурные) средства для выражения обобщенного транзитивного замыкания графового отношения, в том числе для выполнения обобщенных операций конкатенации и аггрегирования, описанных в работе [21].
7. Язык D должен допускать использование параметров в функциях, значениями которых являются отношения, для представления кортежей, отношений, а также скаляров.
КОММЕНТАРИИ.
Мы рассматриваем это просто как предложение, а не предписание, поскольку полагаем, что в настоящее время данный вопрос требует дальнейшего изучения.
8. Язык D должен обеспечивать механизм для того, чтобы иметь дело с "пропущенной информацией" в духе схемы значений по умолчанию, описываемой в работе [16, глава 21], но основанной, однако, на доменах, а не на атрибутах.
КОММЕНТАРИИ.
Термин "значение по умолчанию" является, вероятно, ложно ориентирующим, поскольку он предполагает такую интерпретацию, которая вовсе не имеется в виду - а именно: то, что значение в запросе появляется настолько часто, что оно может быть с таким же успехом задано по умолчанию. Намерение же, скорее, заключается в том, чтобы использовать уместное значение "по умолчанию", отличное от всех возможных истинных значений, когда ни одно из истинных значений не может быть использовано. Например, если истинные значения атрибута ОТРАБОТАННЫЕ_ЧАСЫ - это положительные целые, то задание значения по умолчанию "?" может использоваться для того, чтобы показать, что (по некоторым причинам) никакое истинное значение не известно. Заметим, следовательно, что домен для ОТРАБОТАННЫЕ-ЧАСЫ - это не просто домен положительных целых чисел.
9. SQL должен быть реализуемым в среде D - не потому, что это желательно само по себе, а чтобы обеспечить безболезненный переход для текущих пользователей SQL. С той же целью существующие базы данных SQL должны быть конвертируемы в такую форму, чтобы с ними безошибочно могли оперировать программы на языке D.
КОММЕНТАРИИ.
В сказанном выше подразумевается вовсе не то, что язык D должен быть надмножеством SQL, а скорее, возможность написания внешнего интерфейсного слоя кода D - надстройки над реляционными средствами D, который:
а) будет воспринимать операции в терминах SQL, связанные с конвертированными данными SQL;
б) будет давать результаты, которые бы давали операции SQL, если бы они выполнялись над первоначальными неконвертированными данными SQL.
Следует подчеркнуть, что мы полагаем возможным конструирование такого внешнего интерфейса для SQL, причем таким образом, чтобы это не противоречило каким-либо предписаниям и запрещениям, составляющим данный манифест.
ВЕСЬМА НАСТОЯТЕЛЬНЫЕ ОО-предложения
1. Должны поддерживаться некоторые формы наследования типов (см. ОО-предписания 2 и 3). В соответствии с этим предложением не следует допускать включения в D: а) концепции неявного преобразования типов; б) концепции, предусматривающей, что функции имеют специальный "помеченный" ("distinguished") параметр или параметр "получатель" ("receiver").
КОММЕНТАРИИ.
Неявные преобразования типов противоречили бы цели замещаемости; помеченные параметры вводили бы искусственную и не необходимую степень асимметрии. Обе эти проблемы более подробно анализируются в готовящемся к выходу приложении относительно наследования, упомянутом в ОО-предписании 2.
2. Должны поддерживаться конструкторы типов-"коллекций", такие как LIST (список), ARRAY (массив) и SET (множество), подобно тому, как это сделано в языках, поддерживающих развитые системы типов. (См. также РМ-предписание 7.)
3. Пусть С - конструктор типа "коллекции", иной чем RELATION. Тогда должна обеспечиваться функция преобразования, скажем C2R, для конвертирования значений типа C в отношения, а также обратная функция, скажем R2C такая, что:
а) C2R(R2C(r)) = r для каждого отношения r, выразимого в D;
б) R2C(C2R(c)) = c для каждого выразимого в D значения типа C.
4. Язык D должен базироваться на модели "одноуровневого хранения", которая описана, например, в работе [15]. Иными словами, она не должна делать никакого логического различия в зависимости от того, будет ли задана порция данных, хранимая в основной памяти, вторичной или третичной (tertiary) памяти и т.д.
ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
Мы представили манифест относительно будущих направлений развития систем управления данными и СУБД. Теперь, вероятно, пришло время признаться, что мы действительно ощущаем некоторый дискомфорт в связи с идеей назвать некоторый по сути своей технический документ "манифестом". В соответствии со словарем XX века Чемберса, манифест - это "представленная в письменной форме декларация намерений, мнений или мотивов" некоторого лица или группы (например политической партии). Данная же конкретная декларация, напротив, является, как мы надеемся, предметом науки и логики, а не просто "намерениями, мнениями или мотивами". Однако если принять во внимание исторические прецеденты, которые привели нас к написанию этого документа, то в действительности выбор этого заголовка был предопределен.
В качестве резюме мы представляем краткий мнемонический список всех предписаний, запрещений и весьма настоятельных предложений, которые обсуждались в предыдущих разделах.
РМ-предписания
- Домены
- Типизированные скаляры
- Скалярные операторы
- Фактическое представление
- Значения истинности
- Конструктор типов TUPLE
- Конструктор типов RELATION
- Оператор сравнения
- Кортежи
- Отношения
- Скалярные переменные
- Переменные-кортежи
- Переменные-отношения (R-переменные)
- Базовые R-переменные против производных
- Переменные-базы данных (DB-переменные)
- Транзакции и DB-переменные
- Операции создания/разрушения
- Реляционная алгебра
- Имена R-переменных и явные значения отношений
- Реляционные функции
- Присваивание отношений и кортежей
- Сравнения
- Ограничения целостности
- Предикаты отношений и баз данных
- Каталог
- Проект языка
РМ-запрещения
- Никакого упорядочения атрибутов
- Никакого упорядочения кортежей
- Никаких дубликатов кортежей
- Никаких неопределенных значений
- Никаких ошибок, связанных с неопределенными значениями
- Никаких конструкций внутреннего уровня
- Никаких операций на уровне кортежей
- Никаких составных столбцов
- Никаких подавлений проверки доменов
- Не SQL
ОО-предписания
- Проверка типов на стадии исполнения
- Простое наследование (условное)
- Множественное наследование (условное)
- Вычислительная полнота
- Явные границы транзакций
- Вложенные транзакции
- Статистические операторы и пустые множества
ОО-запрещения
- R-переменные не являются доменами
- Никаких идентификаторов объектов
- Никаких "общедоступных экземплярных переменных"
- Никаких "защищенных экземплярных переменных" или "друзей"
ВЕСЬМА НАСТОЯТЕЛЬНЫЕ РМ-предложения
- Возможные ключи для производных R-переменных
- Системно-генерируемые ключи
- Целостность по ссылкам
- Вывод возможных ключей
- Запросы с квотой
- Транзитивное замыкание
- Параметры кортежей и отношений
- Значения по умолчанию
- Миграция SQL
ВЕСЬМА НАСТОЯТЕЛЬНЫЕ ОО-предложения
- Наследование типов
- Конструкторы типов-коллекций
- Конвертирование в и из отношений
- Одноуровневое хранение
БЛАГОДАРНОСТИ
Мы благодарны многочисленным друзьям и коллегам за их поддержку и за технические дискуссии, а также за полезные замечания по ранним версиям этого манифеста: Тенджу Беннету, Чарли Бонтемпо, Киту Черрингтону, Линде ДеМишель, Винсенту Дьюпюису, Марку Эвансу, Рону Фейгину, Орису Фрезену, Майклу Джексону, Джону Нейлингу, Адриану Лернеру, Брусу Линдсею, Альберту Майеру, Карлу Маттоксу, Нельсону Маттосу, Дэвиду МакГоуверану, Сержу Миранде, Джиму Пантья, Мэри Пантья, Стефану Перенту, Фабриану Паскалю, Рону Россу, Артуру Райману, Майку Сайксу, Стефану Тодду, Рику ван дер Лансу, Антону Верстигу и Фреду Райту.
Хью Дарвин добавляет: "В ноябре 1994 года Отделение программных решений фирмы IBM (IBM"s Software Solutions Division) объявило о консолидации своей деятельности в области исследований и разработок, что привело к закрытию ее лаборатории по разработке программного обеспечения в Варвике (Англия). С 1987 года я был служащим этой лаборатории, где техническая мысль процветала и преуспевала. И я бы хотел выразить мою признательность за поддержку, которую мне оказывал директор лаборатории Тони Темпл и некоторые ее руководители в сверхплановых занятиях, таких как этот манифест. Особую благодарность выражаю моему первому руководителю Стюарту Колвину и последнему - Дику Чепмену".
Ссылки и библиография
- Malcolm Atkinson et al.: "The Object-Oriented Database System Manifesto", Proc. First International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan (1989). New York, N.Y.: Elsevier Science (1990). Есть русский перевод: М.Аткинсон, Ф.Бансилон, Д. ДеВитт, К.Диттрих, Д. Майер, С. Здоник, "Манифест систем объектно-ориентированных баз данных", СУБД, 4, 1995.
- David Beech: "Collections of Objects in SQL3", Proc. 19th International Conference on Very Large Data Bases, Dublin, Ireland (August 1993).
- Jon Bentley: "Little Languages", CACM 29, 8 (August 1986). Иллюстрируются и обсуждаются следующие "критерии качества проекта языка": ортогональность, общность, экономичность, полнота, сходство, расширяемость и открытость.
- E.F.Codd: The Relational Model for Database Management Version 2. Reading, Mass.: Addison-Wesley (1990). Кодд инвентаризирует многие из результатов пересмотра и расширений его первоначальной модели (которую он называет теперь "Реляционной моделью версии 1 или RM/V1"), осуществленных в конце 80-х годов, и данная книга является результатом этой работы. Он описывает "Реляционную модель версии 2 или RM/V2". Мы включаем эту ссылку, главным образом, с тем, чтобы было ясно, что версия реляционной модели, представленная в этом манифесте, в действительности не является ни RM/V2, ни RM/V1, как их определяет Кодд в настоящее время. Скорее, это версия, описанная в работах [11, часть II] и [16, глава 15].
- E.F.Codd: "A Relational Model of Data for Large Shared Data Banks", CACM 13, 6 (June 1970). Повторно опубликована в "Milestones of Research-Selected Papers 1958-1982" (Выпуск Communications of ACM, посвященный 25-й годовщине ACM), CACM 26, 1 (January 1983). Первое широкодоступное описание первоначальной реляционной модели, представленное ее автором. Есть русский перевод: Е.Ф.Кодд, "Реляционная модель данных для больших совместно используемых банков данных", СУБД, 1, 1995.
- E.F.Codd: "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", IBM Research Report RJ599 (August 19th, 1969). Предварительная версия работы [5].
- Hugh Darwen (подписана именем Andrew Warden): "Adventures in Relationland". Статья, специально подготовленная для работы [8].
- C.J.Date, Relational Database Writings 1985-1989. Reading, Mass.: Addison-Wesley (1990).
- C.J.Date, "We Don"t Need Composite Columns", Database Programming & Design 8, 5 (May 1995, to appear).
- C.J.Date: "Oh Oh Relational...", Database Programming & Design 7, 10 (October 1994). Поясняется, почему равенство "домен = класс объектов" правильное, а равенство "R-переменная = класс объектов" - ошибочное. Описываются те выгоды, которые можно было бы извлечь из пропагандируемого в настоящем манифесте истинного сближения между принципами реляционного и объектно-ориентированного подходов. Примерами работ, в которых отстаивается равенство "R-переменная = класс объектов", являются [2] и [23].
- C.J.Date: An Introduction to Database Systems (6th edition). Reading, Mass.: Addison-Wesley (1995). Имеется несколько расхождений (весьма незначительных) между версией реляционной модели, описанной в части II этой книги, и версией, описанной в работе [16, глава 15]. Там, где встречаются такие расхождения, предпочтение следует отдавать этой книге.
- C.J.Date: "How We Missed the Relational Boat" (публикуется под заголовком "How SQL Missed the Boat"), Database Programming & Design 6, 9 (September 1993).
- C.J.Date: "The Primacy of Primary Keys: An Investigation", InfoDB 7, 3 (Summer 1993).
- C.J.Date: "A Critique of the SQL Database Language", ACM SIGMOD Record 14, 3 (November 1984). Повторно опубликована в C.J.Date, Relational Database: Selected Writings. Reading, Mass.: Addison-Wesley (1986).
- C.J.Date: "An Architecture for High-Level Language Database Extensions", Proc. ACM SIGMOD International Conference on Management of Data, Washington, D.C. (June 1976).
- C.J.Date and Hugh Darwen: Relational Database Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
- C.J.Date and Hugh Darwen: A Guide to the SQL Standard (3rd edition). Reading, Mass.: Addison-Wesley (1993). Эта книга представляет собой учебное справочное пособие по текущему стандарту "SQL/92". В ней содержится ряд примеров нарушения принципов проекта хорошего языка. В частности, она включает приложение (Приложение D), в котором описаны "многие аспекты этого стандарта, которые представляются определенными неадекватно или даже некорректно определенными в настоящее время".
- C.J.Date and David McGoveran: "Updating Joins and Other Views", Database Programming & Design 7, 8 (August 1994).
- C.J.Date and David McGoveran: "Updating Union, Intersection, and Difference Views", Database Programming & Design 7, 6 (June 1994).
- Margaret A.Ellis and Bjarne Stroustrup: The Annotated C++ Reference Manual. Reading, Mass.: Addison-Wesley (1990).
- Nathan Goodman: "Bill of Materials in Relational Database", InfoDB 5, 1 (Spring/Summer 1990).
- P.A.V.Hall, P.Hitchcock, and S.J.P.Todd: "An Algebra of Relations for Machine Computation", Conference Record of the 2nd ACM Symposium on Principles of Programming Languages, Palo Alto, Calif. (January 1975).
- William Kelley and Won Kim, "Observations on the Current SQL3 Object Model Proposal (and Invitation for Scholarly Opinions)", available from UniSQL, Inc., 9390 Research Blvd., Austin, Texas 78759 (1994).
- Mark A. Roth, Henry F. Korth, and Abraham Silberschatz: "Extended Algebra and Calculus for Nested Relational Databases", ACM TODS 13, 4 (December 1988).Michael Stonebraker et al.: "Third Generation Database System Manifesto", ACM SIGMOD Record 19, 3 (September 1990). Есть русский перевод: "Системы баз данных третьего поколения: Манифест. Комитет по развитию функциональных возможностей СУБД", СУБД, 2, 1995.
1) Hugh Darwen and C.J.Date. The Third Manifesto. //SIGMOD Record, Vol. 24, No. 1, March 1995. - pp.39-49.
Пер. с англ. М.Р.Когаловского.
2) Адреса авторов: Hugh Darwen, IBM United Kingdom Limited, P.O. Box 31, Warwick CV345JL, England
(e-mail: darwen@vnet.ibm.com); C.J.Date, P.O. Box 1000, Healdsburg, CA 95448, USA (fax: (1)-707-433-7322).
Авторы будут благодарны за замечания и, в частности, приглашают читателей кратко сообщить, поддерживают
ли они высказанные здесь идеи или возражают против них.
3) Этому выбору названия языка не придается никакого особого смысла. Он используется лишь для обозначения вообще любого языка, который соответствует изложенным в последующих разделах принципам.
4) Это высказывание некоторые могут счесть крайне догматичным. Мы имеем в виду лишь,что предписания и запрещения, которые проистекают из реляционной модели, настолько же являются предметом компромисса, насколько таковой является и сама реляционная модель.