4.1 Третий манифест

Статья [3] представляет собой манифест, касающийся будущего систем управления данными и СУБД. Д&Д следуют традициям первых двух манифестов [1 – 2] и надеются, что данный манифест сможет их заменить. Это обосновывает выбор названия. В [1] презрительно отвергается реляционная модель данных, игнорируется ее важность и значимость. Вместе с этим, как считают Д&Д, эта работа терпит неудачу в попытке определить какую-либо четкую линию. В [2] вежливо отдается должное реляционной модели, но в погоне за идеалами этой модели не упоминается и не подчеркивается безнадежность продолжения следования извращению этой модели, воплощенному в SQL . В отличие от этого, Д&Д твердо убеждены, что любая попытка двигаться вперед, чтобы выдержать испытание временем, должна сопровождаться полным и недвусмысленным отказом от SQL . При этом должно уделяться некоторое внимание вопросу, что следует делать с наследством SQL .

Основы будущих систем баз данных не способен обеспечить язык SQL . Д&Д полагают, что любые такие основы должны корениться в реляционной модели данных, впервые представленной миру Э.Ф. Коддом в 1969 г. [4]

Д&Д в полной мере осознают желательность поддержки некоторых активно обсуждавшихся возможностей, в частности, тех возможностей, которые считаются присущими объектной ориентации. Однако они полагают, что эти возможности ортогональны реляционной модели. И поэтому реляционная модель не нуждается в каком-либо расширении, в какой-либо коррекции, и самое главное, в каких-либо извращениях, чтобы можно было связать эти возможности с некоторым языком баз данных, способным представлять искомые основы. Предположим, что такой язык существует и называется D”.⁹⁶

В Третьем манифесте язык D является предметом формулируемых предписаний и запретов.⁹⁷ Некоторые предписания проистекают из существа реляционной модели, и Д&Д называют их RM -предписаниями. Предписания, не связанные с реляционной моделью, называются OO -предписаниями (от Other Orthogonal ). Аналогичным образом разделяются запреты.

RM -предписания и RM -запреты абсолютны и не могут быть предметом компромисса. К сожалению, этого нельзя сказать про OO -предписания и OO -запреты, поскольку ко времени написания статьи не существовало общепринятой модели, на которой они могли бы базироваться.⁹⁸ Д&Д полагают, что OO -предписания могут внести значительный вклад в областях определяемых пользователями типов данных и наследования. Д&Д предпринимают усилия, чтобы привести в этих областях собственные определения, и предупреждают читателя, что наследование порождает ряд вопросов, на которые в доступной литературе отсутствуют ответы. Поэтому в этой области предписания необходимо могут быть только предварительными. Наряду с предписаниями и запретами, Третий манифест включает некоторые весьма строгие суждения, которые также подразделяются на RM - и OO -категории.

RM -предписания

RM -предписание 1

Скалярный тип данных – для краткости, скалярный тип – это именованное множество скалярных значений. Два скалярных типа одинаковы в том и только в том случае, когда на самом деле являются одним и тем же типом (что подразумевает, в частности, наличие у них одного и того же имени; если типы не одинаковы, их имена должны различаться). Язык D должен обеспечивать пользователям возможности определять собственные скалярные типы (определяемые пользователями скалярные типы); другие скалярные типы должны обеспечиваться системой (встроенные или определяемые системой скалярные типы). Должна иметься возможность уничтожения определенных пользователями скалярных типов. Значениями заданного скалярного типа и переменными, значения которых должны принадлежать данному скалярному типу, можно оперировать только с помощью операций, определенных для этого типа (говорится, что операция “определена для” данного типа T , или “ассоциирована с” ним, если и только если хотя бы один ее параметр объявлен с указанием типа Т – см. RM -предписание 3). Для каждого скалярного типа и каждого объявленного возможного представления его значений (см. RM -предписание 4) в состав этих операций должны входить:

Операция selector, служащая для выборки произвольного значения данного скалярного типа (см. RM-предписание 4);
Набор операций для раскрытия рассматриваемого возможного представления (см. RM-предписание 5).

В состав определяемых системой скалярных типов должен входить тип truth value (с ровно двумя значениями, true и false). Для этого типа должны прямо или косвенно определяться и поддерживаться все четыре унарные и 16 бинарных логических операций.⁹⁹

Термины домен и тип данных (для краткости тип) интерпретируются как синонимичные и взаимозаменяемые. В том же самом смысле иногда используется термин объектный класс, но Д&Д не используют этот термин.
Д&Д обобщенно называют значения домена скалярными значениями (для краткости скалярами). Тем самым явно допускаются “скалярные” значения произвольной сложности. Например, при определенных обстоятельствах массив стеков списков … и т.д. может рассматриваться как скалярное значение.

RM -предписание 2

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

RM -предписание 3

Скалярная операция - это операция, которая возвращает скалярное значение или обновляет скалярную переменную. Язык D должен обеспечивать для пользователей возможности определения собственных скалярных операций (определяемых пользователями скалярных операций); другие такие операции (встроенные или определяемые системой скалярные операции) должны обеспечиваться системой. В общем случае должно быть возможно уничтожать определенные пользователями скалярные операции (хотя операции, требуемые RM-предписаниями 5, 8 и 21, слегка нарушают это предписание в том отношении, что их можно уничтожить только посредствам уничтожения ассоциированного типа, и то же верно для операций выборки). Кроме того:

Определение скалярной операции должно включать спецификацию типа каждого параметра этой операции, объявленный тип параметра. Если операция Op имеет параметр P объявленного типа T, то аргумент A, соответствующий P, в каждом вызове Op должен иметь тот же тип T.
Каждая скалярная операция представляет из себя либо операцию обновления, либо операцию только чтения. Скалярная операция обновления – это такая скалярная операция, по меньшей мере один аргумент которой должен быть задан путем указания скалярной переменной, а не произвольного скалярного выражения, и вызов операции приводит к присваиванию значений таким аргументам (по крайней мере, потенциально); параметры, соответствующие подобным аргументам, называются подлежащими обновлению. Скалярная операция только чтения – это скалярная операция, не являющаяся скалярной операцией обновления.
Вызов скалярной операции только чтения должен возвращать (скалярный) результат. Вызов скалярной операции обновления – нет.
В определении скалярной операции только чтения должна содержаться спецификация типа результата этой операции, объявленного типа этого результата (в просторечии, объявление типа собственно операции).
В определение скалярной операции обновления должно указываться, какие аргументы являются подлежащими изменению. Аргументы, соответствующие таким параметрам, должны передаваться по ссылке. Все остальные аргументы операции обновления и все аргументы операции только чтения должны передаваться по значению.
Пусть X - скалярное выражение. По определению X специфицирует вызов некоторой скалярной операции только чтения Op (где Op может быть операцией выборки, и где аргументы этого вызова Op , если они есть, специфицируются, в свою очередь, как скалярные выражения). Тогда X имеет объявленный тип, а именно объявленный тип операции Op .¹⁰⁰

Комментарии

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

RM -предписание 4

Пусть T – скалярный тип, а v – вид (в некотором контексте) некоторого значения этого типа. Тогда по определению у v имеется в точности одно реальное представление и одно или более возможных представлений (по крайней мере, одно, так как, очевидно, одно возможное представление всегда существует и совпадает с реальным представлением). Реальные представления, связанные с типом T, должны определяться средствами некоторого языка определения структуры хранения и не должны быть видимы в языке D (см. RM-предписание 6). По крайней мере одно возможное представление (не обязательно совпадающее с реальным представлением), связанное с типом T, должно быть объявлено как часть определения T и, следовательно, должно быть видимо в языке D. Для каждого объявленного возможного представления PR типа T должна автоматически обеспечиваться операция selector S со следующими свойствами:

Для определенности предположим, что компоненты PR (см. RM-предписание 5) и параметры S представлены в виде упорядоченных списков. Тогда эти два списка должны содержать одно и то же число элементов, скажем n, и объявленные типы i-тых элементов списков (i = 1, 2, ..., n) должны быть одинаковы.
Каждое значение типа T должно производиться путем некоторого вызова S.
Каждый (успешный) вызов S должен производить некоторое значение типа T. ¹⁰¹

RM -предписание 5

Пусть некоторое объявленное возможное представление PR для скалярного типа T определено в терминах компонентов C1, C2, ..., Cn (у каждого компонента имеются имя и объявленный тип). Пусть v – значение типа T, а PR(v) обозначает соответствующее возможное представление. Тогда PR(v) должно быть раскрываемым – иначе говоря, должен автоматически обеспечиваться набор операций только чтения и обновления, такой что:

Для всех таких значений v и для всех i (i = 1, 2, ..., n) можно “выбрать” (т.е. прочитать значение) компонента Ci из PR(v).
Для любой переменной V объявленного типа T и для всех i (i = 1, 2, ..., n) можно обновить V таким образом, что если значениями V до и после обновления являются v и v’ соответственно, то возможные представления PR(v) и PR(v’) отличаются самое большее в их компонентах Ci.

Такой набор операций должен обеспечиваться для каждого возможного представления, объявленного в определении T.

RM -предписание 6

Должен поддерживаться генератор типов TUPLE .¹⁰² То есть при наличии некоторого заголовка кортежа H (см. RM-предписание 9) должна быть возможность использовать генерируемый тип TUPLE {H} как основу определения (или, в случае значений, выборки):

значений и переменных этого генерируемого типа (см. RM-предписания 9 и 12);
значений атрибутов кортежей и атрибутов заголовка кортежей этого генерируемого типа (снова см. RM-предписание 9);
компонентов объявленных возможных представлений этого генерируемого типа (RM-предписание 5).

Генерируемый тип TUPLE {H} называется типом кортежей; имя этого типа – TUPLE {H}. Терминология степени, атрибутов и заголовков, вводимая в RM-предписании 9, должна применяться, с необходимыми изменениями,к этому типу кортежей, а также к значениям и переменным этого типа (см. RM -предписание 12). Типы кортежей TUPLE {H1} и TUPLE {H2} одинаковы в том и только в том случае, когда H1 = H2. В состав применимых операций должны входить аналоги операций реляционной алгебры RENAME, project, EXTEND и JOIN (см. RM-предписание 18), а также операции присваивания кортежей (см. RM-предписание 21) и сравнения кортежей (RM-предписание 22); кроме того, в состав операций должны входить (a) операция выборки кортежей (RM-предписание 9), (b) операция извлечения из указанного кортежа значения указанного атрибута (степень этого кортежа должна равняться единице – см. RM-предписание 9) и (c) операции “вкладывания” и “выкладывания” кортежей.

RM -предписание 7

Должен поддерживаться генератор типов RELATION. То есть при наличии некоторого заголовка отношения H (см. RM-предписание 10) должна иметься возможность использования генерируемого типа RELATION {H} как основы для определения (или, в случае значений, для выборки):

значений и переменных этого генерируемого типа (RM-предписания 10 и 13);
значений атрибутов кортежей и атрибутов заголовка кортежей этого генерируемого типа (см. RM-предписание 9);
компонентов объявленных возможных представлений этого генерируемого типа (RM-предписание 5).

Генерируемый тип RELATION {H} называется типом отношения, и имя этого типа – RELATION {H}. Терминология степени, атрибутов и заголовков, вводимая в RM-предписании 10, должна применяться, с необходимыми изменениями,к этому типу отношения, а также к значениям и переменным этого типа (см. RM -предписание 13). Типы отношения RELATION {H1} и RELATION {H2} одинаковы в том и только в том случае, когда H1 = H2. В состав применимых операций должны входить операции реляционной алгебры (см. RM-предписание 18), а также операции реляционного присваивания (см. RM-предписание 21) и реляционного сравнения (RM-предписание 22); кроме того, в состав операций должны входить (a) операция выборки отношений (RM-предписание 10), (b) операция извлечения единственного кортежа из указанного отношения мощности один (RM-предписание 10), и (c) операции “вкладывания” и “выкладывания” отношений.

Комментарии

С точки зрения любого отношения, которое включает атрибут, определенный на таком домене, “скалярные” значения в этом домене (как и значения всех доменов) являются все еще инкапсулированными. (Аналогичное замечание относится также к RM -предписанию 6.) В Третьем манифесте не поддерживаются в явном виде отношения в форме NF ² (“NF в квадрате”¹⁰³), введение которых влечет существенные расширения классической реляционной алгебры.

RM -предписание 8

Для каждого типа должна поддерживаться операция сравнения по равенству, “=”. Пусть выражения X1 и X2 имеют значения v1 и v2 соответственно, причем v 1 и v 2 принадлежат одному и тому же типу T . Тогда операция X1 = X2 вырабатывает значение true в том и только в том случае, если v1 и v2 в действительности являются одним и тем же элементом T (то есть тогда и только тогда, когда X1 и X2 имеют одно и то же значение). Кроме того, пусть Op – это операция с параметром P объявленного типа T. Тогда для всех таких операций Op, если значением сравнения X1 = X2 является true , последствия двух (успешных) вызовов Op, которые отличаются только тем, что в одном из них аргументом, соответствующим P, является X1, а в другом – X2, должны быть неразличимы. Или, по-другому, если существует такая операция Op, что последствия двух (успешных) вызовов Op, которые отличаются только тем, что в одном из них аргументом, соответствующим P, является X1, а в другом – X2, различимы, то значением сравнения X1 = X2 должно быть false.

RM -предписание 9

Значение кортежа t (или для краткости кортеж) – это множество упорядоченных триплетов вида <A, T, v>, где:

A – имя атрибута кортежа t. Никакие два различных триплета в t не должны содержать одно и то же имя атрибута;
T – имя типа атрибута A кортежа t.
v – значение типа T, называемое значением атрибута A кортежа t.

Мощность множества триплетов в t, или число атрибутов t называется степенью t. Множество упорядоченных пар <A, T>, получающихся путем удаления компонента v (значения) из каждого триплета, является заголовком t. Кортеж t называется соответствующим этому заголовку (принадлежит к соответствующему типу кортежа – см. RM-предписание 6). Степенью заголовка является степень кортежа, а атрибутами и соответствующими типами заголовка являются атрибуты и соответствующие типы кортежа t. При заданном заголовке H должна быть доступна операция selector для выборки произвольного кортежа, соответствующего H.

RM -предписание 10

Значение отношения r (для краткости – отношение) состоит из заголовка и тела, где:

Заголовком r является заголовок кортежа H как определяется в RM-предписании 9. Отношение r называется соответствующим этому заголовку (принадлежит к соответствующему типу отношения – см. RM-предписание 7), а степенью r является степень этого заголовка. Атрибутами и соответствующими типами r являются атрибуты и соответствующие типы H.
Тело r – это множество B кортежей, каждый из которых имеет заголовок H; мощность тела называется мощностью r.

При заданном заголовке отношения H должна быть доступна операция selector для выборки произвольного отношения, соответствующего H.

Комментарии

Каждый кортеж в R содержит в точности одно значениеv для каждого атрибута A в H . Иными словами, R находится в первой нормальной форме, 1NF .
Проводится строгое различие между отношениями как таковыми и переменными-отношениями (см. РМ-предписание13).¹⁰⁴

RM -предписание 11

Скалярная переменная типа T – это переменная, допустимыми значениями которой являются скаляры указанного скалярного типа T, объявленного типа этой переменной. Язык D должен обеспечивать для пользователей возможности определения скалярных переменных. При определении скалярной переменной должна производиться инициализация переменной некоторым значениям – явно указанным в операции определения переменной или не указанным явно, а определенным в реализации.

RM -предписание 12

Переменная кортежа типа TUPLE {H} – это переменная, допустимыми значениями которой являются кортежи, соответствующие указанному заголовку кортежа H. Объявленный тип этой переменной кортежа есть TUPLE {H}. Атрибутами переменной кортежа являются атрибуты H, соответствующими типами – объявленные типы этих атрибутов, степенью переменной кортежа является степень H. Язык D должны обеспечивать для пользователей возможности определения переменных кортежей. При определении переменной кортежа должна производиться инициализация переменной некоторым значением – явно указанным в операции определения переменной или не указанным явно, а определенным в реализации.

RM -предписание 13

Переменная отношения (relation variable , для краткости – relvar) типа RELATION {H} – это переменная, допустимыми значениями которой являются отношения, соответствующие указанному заголовку отношения H. Объявленный тип relvar есть RELATION {H}. Атрибутами relvar являются атрибуты H, соответствующими типами – объявленные типы этих атрибутов, степенью relvar является степень H. Язык D должен обеспечивать для пользователей средства определения и уничтожения переменных relvar базы данных (для тех relvar, которые принадлежат базе данных, а не приложению – см. RM-предписание 16). Язык D должен также поддерживать возможности определения relvar на уровне приложений.

RM -предписание 14

Переменные r elvar базы данных могут быть реальными или виртуальными. Виртуальная relvar – это relvar базы данных, значением которой в любой момент времени является результат вычисления некоторого реляционного выражения, указываемого при определении этой relvar. Реальная relvar – это relvar базы данных, которая не является виртуальной. При определении реальной relvar должна производиться ее инициализация пустым отношением (т.е. отношением мощности нуль).

Комментарии

Реальные и виртуальные relvar соответствуют тому, что обычно называют “базовыми отношениями” и “обновляемыми представлениями” соответственно. Однако Д&Д полагают, что обновляемые представления составляют значительно более широкую категорию представлений, чем это принято считать при использовании традиционных подходов.

RM -предписание 15

По определению у каждой relvar имеется по меньшей мере один возможный ключ. По меньшей мере один такой ключ должен быть определен при определении relvar, и не должна иметься возможность ликвидировать все возможные ключи данной relvar (кроме как ликвидировав саму relvar).

RM -предписание 16

База данных – это именованный контейнер relvar; содержимое базы данных в любой момент времени – это набор relvar базы данных. Операции, необходимые для определения и ликвидации баз данных, не должны являться частью языка D (другими словами, определение и ликвидация баз данных должна производиться “за пределами среды D”).

RM -предписание 17

Каждая транзакция должна взаимодействовать в точности с одной базой данных. Однако разные транзакции должны иметь возможность взаимодействия с разными базами данных, и разные базы данных не обязательно должны быть разъединенными. Кроме того, транзакции должны иметь возможность определять новые и уничтожать существующие relvar внутри соответствующей базы данных (RM-предписание 13).

RM -предписание 18

В языке D должны поддерживаться обычные операции реляционной алгебры (или их некоторые логические эквиваленты). Конкретно, должны прямо или косвенно поддерживаться, по меньшей мере, операции RENAME, restrict (WHERE), project, EXTEND, JOIN, UNION, INTERSECT, MINUS, (обобщенная) DIVIDEBY PER и (обобщенная) SUMMIRIZE PER. Все такие операции должны выражаться без чрезмерного многословия. В языке D должен также обязательно поддерживаться механизм вывода типов отношения, благодаря чему заголовок результата вычисления произвольного реляционного выражения должен быть правильно определенным и известным как системе, так и пользователю (RM-предписание 7).¹⁰⁵

Комментарии

Оборот “без чрезмерного многословия” предполагает наряду с другими вещами, что:

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

RM -предписание 19

Имена relvar и вызовы селектора отношений должны быть допустимыми реляционными выражениями. В реляционных выражениях должна допускаться рекурсия.¹⁰⁶

RM -предписание 20

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

RM -предписание 21

В D должно допускаться:

присваивание (значения) скалярного выражения скалярной переменной;
присваивание (значения) кортежного выражения переменной кортежа;
присваивание (значения) реляционного выражения relvar.

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

RM -предписание 22

В D должны поддерживаться некоторые операции сравнения, а именно:

Операции сравнения скаляров должны включать “=”, “¹ ” и, возможно, “<”, “>” и т.д. (в зависимости от данного скалярного типа);
Операции сравнения кортежей должны включать “=” и “¹ ” (и только);
Операции сравнения отношений должны включать “=”, “¹ ”, “Í ”, “является подмножеством” и т.д.;
Должна поддерживаться операция “Î ” для проверки вхождения кортежа в отношение.

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

RM -предписание 23

Выражение, при вычислении которого вырабатывается истинностное значение, называется логическим выражением (также называемое истинностным, условным или булевским выражением). Ограничением целостности является логическое выражение, которое: a) именовано; b) является замкнутой WFF (Well Formed Formula – правильно построенной формулой) реляционного исчисления или ее логическим эквивалентом; с) при вычислении должно вырабатывать значение true. Язык D должен обеспечивать возможности для определения и уничтожения ограничений целостности. Такие ограничения должны классифицироваться на ограничения типа, атрибута, relvar и базы данных, и в D должен поддерживаться механизм вывода ограничений, ассоциированный с этой схемой классификации (насколько это осуществимо).

RM -предписание 24

Для каждой relvar имеется соответствующий предикат relvar, и для каждой базы данных имеется соответствующий предикат базы данных. Все такие предикаты должны удовлетворяться в границах оператора.¹⁰⁷

Комментарии

Предикат отношения представляет собой, по существу, конъюнкцию всех ограничений целостности, которые налагаются на соответствующую relvar , а предикат базы данных – это конъюнкция всех ограничений целостности, которые налагаются на соответствующую dbvar . Это исключительно важный момент – предикаты, а не имена представляют семантику базы данных.
Утверждение о том, что предикаты отношений должны удовлетворяться на границах операторов, означает в точности то, что никакая реляционная операция присваивания не должна оставлять какую-либо relvar в состоянии, в котором нарушается ее предикат отношения.
Из этого предписания, кроме того, следует, что должно быть невозможно обновлять “обновляемые представления” (т.е. виртуальные relvar ) таким образом, чтобы нарушалось определение этого представления. Иными словами, “обновляемые представления” всегда должны быть предметов того, что называется в SQL CASCADED CHECK OPTION [23].

RM -предписание 25

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

Комментарии

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

RM -предписание 25

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

Комментарии

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

RM-запреты

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

RM -запрет 1

D не должен включать концепцию “отношения”, атрибуты которого различаются своими порядковыми позициями. Для каждого отношения r, выражаемого средствами D, атрибуты r должны различаться своими именами.

Комментарии

Из этого запрета следует, что не допускаются никакие анонимные столбцы, такие как в операторе SQL SELECT X + Y FROM T , и никакие дубликаты имен столбцов, как в операторах SQL SELECT X , X FROM T и SELECT T 1.X , T 2.X FROM T 1, T 2.

RM -запрет 2

D не должен включать концепцию “отношения”, в котором кортежи различаются своими порядковыми позициями. Для каждого отношения r, выражаемого средствами D, кортежи r должны различаться своими значениями.

Комментарии

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

RM -запрет 3

D не должен включать концепцию “отношения”, содержащего два различных кортежа t1 и t2 таких, что результатом сравнения кортежей “t 1 = t 2” является true . Отсюда следует, что (как уже утверждалось в RM -запрете 2) кортежи r должны различаться своими значениями.

Комментарии

Другими словами, “строки-дубликаты” являются незаконными абсолютно, категорически и однозначно незаконными.

RM -запрет 4

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

Комментарии

Другими словами – никаких неопределенных значений и никакой многозначной логики!

RM -запрет 5

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

RM -запрет 6

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

RM -запрет 7

В D не должны поддерживаться покортежные операции над relvar или отношениями.

Комментарии

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

RM -запрет 8

D не должен включать какую-либо специальную поддержку “составных”, или “сложных” атрибутов, поскольку подобной функциональности можно достичь, если это желательно, более понятным образом на основе уже предписанной поддержки типов.

RM -запрет 9

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

RM -запрет 10

D не должен называться SQL.

OO-предписания

OO -предписание 1

В D должна допускаться проверка типов во время компиляции.

Комментарии

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

OO -предписание 2

Если в языке D поддерживается наследование типов, то такая поддержка должна подчиняться модели наследования, определенной в Части IV этой книги.¹⁰⁸

OO -предписание 3

D должен быть вычислительно полным. То есть в D могут поддерживаться (но не должны требоваться) вызовы из так называемых “основных программ”, написанных на языках, отличных от D. Аналогично, в D может поддерживаться (но не должно требоваться) использование других языков программирования для реализации определяемых пользователями операций.

OO -предписание 4

Инициация транзакций должны производиться только посредством явного выполнения операции “begin transaction”. Завершение транзакции должно производиться только посредством выполнения операций “commit” или “rollback”; фиксация всегда должна быть явной, а откат может быть неявным (в том и только в том случае, когда транзакция завершается неуспешно не по своей вине). Если транзакция TX завершается фиксацией (“нормальное завершение”), то изменения, произведенные TX в соответствующей базе данных, должны быть зафиксированы. Если транзакция TX завершается откатом (“аварийное завершение”), то изменения, произведенные транзакцией TX в соответствующей базе данных, должны быть аннулированы.

OO -предписание 5

В D должны поддерживаться вложенные транзакции, т.е. должна допускаться инициация транзакцией-предком TX транзакции-потомка TX’ до завершения транзакции TX. При этом:

TX и TX’ должны взаимодействовать с одной и той же базой данных (что в действительности требуется RM-предписанием 17);
Потребуется ли задержка выполнения TX на время выполнения TX’, должно определяться в зависимости от реализации. Однако TX не должна завершаться до завершения TX’; другими словами, TX’ должна полностью содержаться в TX.
Откат TX должен включать откат TX’, даже если TX’ завершилась фиксацией. Другими словами, “фиксация” всегда интерпретируется в контексте предка (если он существует) и может быть отменена транзакцией-предком (опять же, если она существует).

OO -предписание 6

Пусть AggOp – агрегатная операция, такая как SUM. Если аргумент AggOp является пустым, то:

Если AggOp является сокращенной формой некоторой итеративной скалярной бинарной операции Op (в случае SUM это операция “+”), и если для Op существует начальное значение (0 в случае SUM), то результатом вызова AggOp должно быть это начальное значение.
В противном случае результат вызова AggOp s должен быть неопределенным.

OO-запреты

OO -запрет 1

Переменные relvar – это не домены.

Комментарии

Категорически отвергается равенство вида “отношение = объектный класс” (более точно, равенство “relvar = объектный класс”)¹⁰⁹.

OO -запрет 2

Никакая relvar базы данных не должна содержать атрибут типа pointer (указатель ).¹¹⁰

Комментарии

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

Очень строгие RM -суждения

Очень строгое RM -суждение 1

В языке D следует обеспечить механизм, в соответствии с которым значения некоторого указанного возможного ключа (или некоторых его компонентов) для некоторой указанной relvar поставляются системой. Следует также обеспечить механизм, в соответствии с которым произвольное отношение может быть расширено атрибутом, значения которого: a) уникальны внутри этого отношения (или внутри некоторых разделов этого отношения) и b) поставляются системой.

Очень строгое RM -суждение 2

В D следует включить некоторую декларативную сокращенную форму для выражения ссылочных ограничений (называемых также ограничениями внешнего ключа).

Очень строгое RM -суждение 3

Если RX – реляционное выражение, то по определению RX можно считать обозначением relvar R — либо определенной пользователем (если RX состоит только из имени relvar), либо определяемой системой (в противном случае). Желательно, хотя и не всегда возможно, чтобы система была в состоянии выводить возможные ключи R таким образом, что (кроме всего прочего):

Если RX является определяющим выражением для некоторой виртуальной relvar R’, то эти выводимые возможные ключи можно проверить на соответствие возможным ключам, явно определяемым для R’. Если конфликт не обнаруживается, то выводимые ключи становятся возможными ключами R’.
Сведения о выводимых ключах могут быть включены в информацию об R, доступную (в ответ на “метазапрос”) пользователям языка D.

В языке D следует поддерживать такие функциональные возможности, но без какой-либо гарантии того, что: a) эти выводимые ключи не являются точными надмножествами реальных возможных ключей; b) выводимый возможный ключ обнаруживается для каждого реального возможного ключа.

Очень строгое RM -суждение 4

В языке D следует поддерживать ограничения переходов, т.е. ограничения на допустимые изменения значения relvar или базы данных.

Очень строгое RM -суждение 5

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

Очень строгое RM -суждение 6

Для работы с “отсутствующей информацией” в D следует обеспечить некоторый механизм специальных значений.¹¹¹

Очень строгое RM -суждение 9

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

Очень строгие OO-суждения

Очень строгое OO -суждение 1

В языке D следует поддерживать некоторый уровень наследования типов (см. OO-предписания 2 и 3). В соответствии с этим суждением в D не следует поддерживать принуждения (т.е. неявные преобразования типов).

Комментарии

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

Очень строгое OO -суждение 2

Определениям операций следует быть логически отличимыми от определений типов их параметров и/или результатов; эти определения не следует связывать в один узел (хотя селекторы и операции, требуемые в RM-предписании 5 можно рассматривать как исключения по отношению к этому суждению).¹¹²

Очень строгое OO -суждение 3

Следует поддерживать генераторы типов “коллекций”, такие как LIST, ARRAY и SET, распространенные в языках с развитыми системами типов.

Очень строгое OO -суждение 4

Для любого генератора типа коллекции С, отличного от RELATION, следует обеспечить операцию преобразования (скажем, C2R) для преобразования значений заданного типа, сгенерированного C, в отношения, и обратную операцию (скажем, R2C) такую, что:

C2R(R2C(r)) = r для любого выразимого r;
R2C(C2R(c)) = c для любого выразимого значения c типа C.

Очень строгое OO -суждение 4

Язык D следует основывать на одноуровневой модели хранения.

[Назад] [Оглавление] [Вперед]