Мы представляем манифест о направлениях будущего развития систем управления данными и СУБД. Этот манифест состоит из ряда предписаний, запретов и "весьма настоятельных предложений".

Введение

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

Назад к будущему

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

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

Допустим, что такой язык имеется и называется D¹⁾.

Язык D будет предметом определенных предписаний и запретов. Некоторые из этих предписаний проистекают из реляционной модели данных, и мы будем называть их предписаниями реляционной модели, или для краткости – РМ-предписаниями. Предписания, которые не происходят из реляционной модели, назовем остальными ортогональными предписаниями, или для краткости – ОО-предписаниями. Подобным же образом мы категоризируем запреты для языка D.

Перейдем теперь к более подробному обсуждению предписаний и запретов языка D. Следует заметить, что РМ-предписания и запрещеты не могут быть предметом компромисса²⁾. К сожалению, этого совсем нельзя сказать по поводу ОО-предписаний и запрещетов, поскольку не существует (во время написания этой работы) ясной и общепринятой модели, на которой они могли бы базироваться. На самом деле мы полагаем, что ОО может внести значительный вклад в области типов данных, определяемых пользователями, и наследования. Однако пока не достигнут какой-либо консенсус относительно абстрактной модели даже относительно этих важных предметов. Поэтому мы вынуждены дать наши собственные определения в этих областях. И лишь справедливо будет предупредить читателя, что наследование, по меньшей мере, порождает ряд вопросов, на которые, как нам представляется, пока еще нет удовлетворительных ответов в доступной литературе. В результате в настоящее время наши предложения в этой области должны по необходимости быть в некотором роде предварительными (см. ОО-предписания 2 и 3).

Наряду с предписаниями и запретами этот манифест включает также некоторые весьма настоятельные предложения, также подразделяющиеся на РМ- и ОО-категории.

Три последние предварительные замечания.

1. Если говорить совсем точно, то версия реляционной модели, которую мы поддерживаем, – это версия, впервые описанная в [16] (глава 15) и позже уточненная (в небольшой степени) в [11] (часть II). Заметим, однако, что определения кортежа и отношения в данной работе представляют собой немного улучшенные варианты определений, приведенных в указанных ранних публикациях.
2. В следующих разделах этой работы мы преднамеренно не вдаемся в многочисленные подробности различных предписаний, запретов и предложений. (В действительности, иногда мы предоставляем некоторые пояснительные комментарии по определенным вопросам, однако все такие комментарии можно было бы удалить, не затрагивая техническое существо нашего предложения). Намерение авторов состоит в том, чтобы представить вслед за этим манифестом ряд специальных статей, в которых различные аспекты нашего предложения были бы описаны более глубоко.
3. В тех случаях, когда это недостаточно очевидно, мы хотели бы, чтобы было предельно ясно, что главная сфера наших интересов – это абстрактная модель, а не вопросы реализации (хотя в целях обеспчения ясности пояснительные комментарии касаются иногда и таких вопросов).

РМ-предписания

1. Домен – это именованное множество значений. Манипулирование такими значениями, которые могут быть произвольной сложности, должно быть возможно исключительно посредством операций, определенных для этого домена (этих доменов) (см. РМ-предписание 3 и ОО-предписание 3), т.е. значения домена должны быть инкапсулированы (за исключением тех случаев, которые отмечаются в РМ-предписании 4). Для каждого домена должна быть доступна нотация, позволяющая явно специфицировать (или "конструировать") произвольное значение из этого домена.

   Комментарии:

   • Мы интерпретируем термины домен и тип данных (для краткости тип) как синонимичные и взаимозаменяемые. В том же самом смысле используется иногда термин объектный класс, но мы не используем этот более поздний термин.
   • Обобщенно мы называем значения домена скалярными значениями (или для краткости скалярами). Заметим, следовательно, что мы явно допускаем "скалярные" значения произвольной сложности. Таким образом, например, массив стеков списков и т.д. в соответствующих обстоятельствах может рассматриваться как скалярное значение.


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


3. Для каждого упорядоченного списка n доменов, не обязательно различных (n ≥ 0), в D должны поддерживаться определения допустимых n-адических операций, которые применимы к соответствующим упорядоченным спискам из n значений, взятых по одному из каждого из этих n доменов. Определение каждого такого оператора должно включать спецификацию домена результата этой операции. Определения таких операций должны быть логически отделены от определений доменов, к которым они относятся (а не быть "встроенными" в эти определения).

Комментарии:

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


4. Пусть V – некоторый домен. В состав определенных для V операций должны обязательно входить такие операции, явным назначением которых является раскрытие действительных представлений (actual representation) значений из V. Заметим, что эти операции – и только они – нарушают, таким образом, инкапсуляцию значений из V.

   Комментарии:

   • Наше намерение состоит в том, чтобы: (a) такие нарушающие инкапсуляцию операции использовались только в реализации других операций и (b) подобный эффект достигался с помощью системных механизмов авторизации. Иными словами, реальное представление значений домена должно быть скрыто от большинства пользователей.
   • Пусть V – некоторый домен. Отметим, что часто будет желательно определить набор операций, действие которых состоит в том, чтобы раскрыть одно возможное представление (possible representation) (не обязательно фактическое представление) для значений из V. При наличии таких операций пользователь по сути будет способен оперировать значениями из V точно так же, как если бы он имел дело с фактическим представлением.
   • Хотя реальные представления значений домена не существенны для спецификаций данного манифеста, может быть полезно указать, что, если v1 и v2 – разные значения из домена V, ничто в языке D не требует, чтобы реальные представления v1 и v2 были бы одной и той же формы. Например, V может быть доменом "текст", а v1 и v2 – двумя документами, подготовленными с использованием разных текстовых процессоров.


5. D должен поставляться оснащенным некоторыми стандартными (встроенными) доменами, включающими, в частности, домен истинностных значений (true и false). Для этого домена должны поддерживаться обычные операции (NOT, AND, OR, IF ... THEN ..., IFF и т.д.).


6. Пусть H – некоторый заголовок кортежа (tuple heading) (см. РМ-предписание 9). Тогда должна существовать возможность определить домен, значения которого являются кортежами с заголовком H, – иными словами, TUPLE должен быть допустимым конструктором типов. Определенные для такого домена операции должны в точности составлять набор операций над кортежами (tuple operators), поддерживаемых D. Он включает операцию конструирования кортежа из указанных скаляров, а также операцию извлечения из кортежа указанных скаляров. Должны также включаться средства "вкладывания" и "выкладывания" ("nest"/"unnest") кортежей, аналогичные подобным средствам для отношений, описанным в [16] (глава 6).


7. Пусть H – некоторый заголовок отношения (см. РМ-предписание 10). Тогда должна существовать возможность определения домена, значениями которого являются отношениями с заголовком H. Иными словами, RELATION должен быть допустимым конструктором типов. Операции, определенные для такого домена, должны в точности представлять собой множество операций над отношениями, поддерживаемых D. В их число должна входить операция конструирования отношения из указанных кортежей, а также операция извлечения из отношения указанных кортежей. Должны иметься также возможности "вкладывания" и "выкладывания" ("nest"/"unnest") вложенных отношений, описанные в [16] (глава 6).

   Комментарии:

   • Заметим, что с точки зрения любого отношения, которое включает атрибут, определенный на таком домене, "скалярные" значения в этом домене (как и значения всех доменов) по-прежнему являются инкапсулированными. (Аналогичное замечание относится также к РМ-предписанию 6.) Мы не поддерживаем в явном виде отношения в форме NF² ("NF в квадрате"), описанной, например, в [24], которая влечет существенные расширения классической реляционной алгебры.
   
   
8. Для каждого домена должен быть определен оператор сравнения на равенство (equals, "="). Пусть v1 и v2 – некоторые значения из какого-либо домена V. Тогда v1 = v2 должно быть истинно тогда и только тогда, когда v1 и v2 являются одним и тем же элементом V.


9. Кортеж t – это множество упорядоченных триплетов вида <A,V,v>, где:
   • A – имя атрибута t. Никакие два различных триплета в t не должны содержать одно и то же имя атрибута;
   • V – имя (единственного) домена, соответствующего атрибуту A;
   • v – некоторое значение из домена V, называемое значением атрибута A в кортеже t.
   Множество упорядоченных пар <A,V>, которое получается в результате исключения компонента (значения) v из каждого триплета в t, представляет собой заголовок t. При заданном заголовке кортежа должна быть доступна нотация, позволяющая явно специфицировать (или "сконструировать") произвольный кортеж с таким заголовком.


10. Отношение R состоит из заголовка и тела. Заголовок R – это заголовок кортежа H, определенный в РМ-предписании 9. Тело R – это множество B кортежей таких, что все они имеют заголовок H. Атрибуты и соответствующие домены, указанные в H, – это атрибуты и соответствующие им домены R. При заданном заголовке отношения должна быть доступна нотация, позволяющая явным образом специфицировать (или "сконструировать") произвольное отношение с этим заголовком.

    Комментарии:

    • Заметим, что каждый кортеж в R содержит в точности одно значение v для каждого атрибута A в H. Иными словами, R находится в первой нормальной форме – 1NF.
    • Мы проводим строгое различие между отношениями самими по себе и переменными отношений (см. РМ-предписание13). Аналогичное различие относится также и к базам данных (см. РМ-предписание15). Мы осознаем, что эти терминологические различия будут, к сожалению, непривычны большинству читателей. Тем не менее мы принимаем их в интересах точности.


11. Скалярная переменная типа V – это переменная, допустимыми значениями которой являются скаляры из указанного домена V – объявленного домена (declared domain) для этой скалярной переменной. Создание скалярной переменной S должно приводить к инициализации S некоторым начальным скалярным значением – либо значением, явно специфицированным в операции создания S, либо некоторым значением, зависящим от реализации, если никакое значение явно не указано.


12. Кортежная переменная (tuple variable) типа H – это переменная, допустимыми значениями которой являются кортежи со указанным заголовком кортежа H – объявленным заголовком (declared heading) для этой кортежной переменной. Создание кортежной переменной T должно приводить к инициализации T некоторым начальным кортежным значением – либо значением, явно специфицированным в операции создания T, либо некоторым значением, зависящим от реализации, если никакое значение явно не указано.


13. Переменная отношения (relation variable) – для краткости R-переменная (relvar) – типа H – это переменная, допустимыми значениями которой являются отношения с указанным заголовком отношения H – объявленным заголовком для этой relvar.


14. Relvar могут быть базовыми (base) либо производными (derived). Производная relvar – это такая relvar, значение которой в любой заданный момент времени представляет собой отношение, определяемое посредством заданного реляционного выражения (см. РМ-предписания 18-20). Это реляционное выражение должно быть таким, чтобы производная relvar обновлялась в соответствии с правилами и принципами, описанными в [11] (глава 17) и [18-19]. Базовая relvar – это relvar, которая не является производной. Создание базовой relvar должно приводить к инициализации этой базовой relvar некоторым пустым отношением.

    Комментарии:

    • Базовые и производные relvar соответствуют тому, что обычно называется "базовыми отношениями" и "обновляемыми представлениями" соответственно. Заметим, однако, что мы считаем обновляемыми значительно более широкую категорию представлений по сравнению с традиционными подходами [18-19].


15. Переменная базы данных (database variable) – для краткости dbvar – это именованное множество relvar. Каждая dbvar является предметом набора ограничений целостности (см. РМ-предписания 23 и 24). Значение данной dbvar в любой заданный момент времени представляет собой множество упорядоченных пар <R,r> (где R – имя relvar, а r – текущее значение этой переменной) таких, что: a) в этой dbvar существует одна такая упорядоченная пара для каждой relvar; b) эти значения relvar одновременно удовлетворяют соответствующим ограничениям. Такое значение dbvar называется базой данных (иногда состоянием базы данных, но мы не используем этот более поздний термин).

    Комментарии:

    • Стоит обратить внимание на то, что мы явно не считаем, что домены относятся к какой-либо конкретной dbvar.
    
    
    • Каждая транзакция взаимодействует в точности с одной dbvar. Однако разные транзакции могут взаимодействовать с разными dbvar, и разные dbvar не обязательно являются непересекающимися. Кроме того, транзакция может динамически изменять ассоциированную с нею dbvar, добавляя и/или удаляя relvar (см. РМ-предписание 17).

      Комментарии:

      • Одно из назначений понятия dbvar заключается в том, чтобы определить область действия реляционных операций. Другими словами, если dbvar X ассоциирована с транзакцией T, то в T не должны использоваться ссылки на какую-либо relvar, которая входит в какую-либо иную dbvar, а не в dbvar X.
      • Множество всех базовых relvar может рассматриваться как "базовая" dbvar. Однако отдельные транзакции взаимодействуют с "производными" или "пользовательскими" dbvar, которые, вообще говоря, состоят из комбинации базовых и производных relvar.
      • В данном манифесте не специфицируется механизм установления и разрыва связей между транзакцией и соответствующей ей единственной dbvar.
    
    
    • В языке D должен обеспечиваться операции для создания (create) и разрушения (destroy) доменов, переменных (в том числе relvar) и ограничений целостности. Каждые явно созданные домен, переменная или ограничение целостности должны быть именованными. Каждая базовая relvar должна иметь, по крайней мере, один возможный ключ (candidate key), явно специфицированный в той операции, которая создает эту базовую relvar.

      Комментарии:

      • Создание и разрушение dbvar (которые, как мы предполагаем, должны быть "стабильными" (persistent) осуществляется вне среды языка D.
    
    
    • Выразительные средства реляционной алгебры в том виде, как она определена в [11] (часть II), должны быть избавлены от чрезмерной многоречивости.

      Комментарии:

      • "Отсутствие чрезмерной многоречивости" предполагает, помимо прочего, что:
        • должны в равной мере легко выражаться кванторы всеобщности и существования. Например, если язык D включает специальную операцию реляционной проекции (projection) отношения, то он должен также включать и специальную операцию для поддержки общей формы реляционного деления (division) отношений, описанной (как DIVIDEBY PER) в работе [16] (глава 11);
        • должны также в равной мере легко выражаться проекция на указанные атрибуты и проекция на все атрибуты, кроме указанных.
    
    
    • Как имена relvar, так и явные ("сконструированные") значения отношений, должны быть допустимыми реляционными выражениями.
    • Язык D должен предоставлять операции для создания и разрушения именованных функций, значения которых в любой заданный момент времени являются отношениями, определяемыми посредством указанного реляционного выражения. Вызовы таких функций должны допускаться в реляционных выражениях везде, где допускаются явные значения отношений.

      Комментарии:

      • Функции такого рода соответствуют тому, что обычно называется "представлениями только для чтения" (read-only views), за исключением того, что мы допускаем параметризацию реляционных выражений, определяющих подобного рода "представления". Такие параметры представляют собой скалярные значения и допустимы в определяющем реляционном выражении везде, где допускаются в явном виде скалярные значения. (Вероятно, окажется возможно поддерживать также параметры – кортежи и отношения. См. Весьма настоятельное РМ-предложение 7).
    
    
    • В языке D должны допускаться:
      1. присваивание значения кортежного выражения кортежной переменной;
      2. присваивание значения реляционного выражения relvar
      с обеспечением в обоих случаях удовлетворение требований совместимости типов (type compatibility) в том виде, как они описаны в [11] (глава 19).

      Комментарии:

      • Это предписание, конечно, не отвергает возможности дополнительного обеспечения удобных кратких обозначений такого рода, как INSERT, UPDATE и DELETE, описанных в [11} (часть II).
      
      
    • В языке D должны поддерживаться определенные операции сравнения. Операциями, определенными для сравнения кортежей, должны быть лишь "=" и "≠". Операции, определенные для сравнения отношений, должны включать "=", "≠", "является подмножеством" и т.д. Также должна поддерживаться операция "∈" , позволяющая проверить, является ли кортеж элементом отношения. Во всех случаях должны удовлетворяться требования совместимости типов, описанные в [11] (глава 19).


16. Любое выражение, значением которого является истинностное значение, называется условным выражением (conditional expression). Любое условное выражение, которое является замкнутой правильно построенной формулой (closed WFF) реляционного исчисления (или логически эквивалентно ей) [11] (часть II), должно быть допустимо в качестве спецификации ограничения целостности. Ограничения целостности должны классифицироваться в соответствии со схемой, описанной в [11] (глава 16) и [18-19], как ограничения доменов, атрибутов, отношений и базы данных, и в языке D должен полностью поддерживаться механизм вывода ограничений (constraint inference), предусматриваемый этой схемой.


17. У каждой relvar имеется соответствующий предикат отношения (relation predicate), и у каждой dbvar – соответствующий предикат базы данных (database predicate), которые разъясняются в [11] (глава 16) и [18-19]. Предикаты отношений долны удовлетворяться на границах операций. Предикаты базы данных должны удовлетворяться на границах транзакций.

    Комментарии:

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


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

    Комментарии:

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


19. 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 являются двумя разными его кортежами, в R должен существовать некоторый атрибут A такой, что значение атрибута A в t1 не равно значению атрибута A в t2.

   Комментарии:

   • Иными словами, "строки-дубликаты" являются незаконными абсолютно, категорически и однозначно. То, что мы сказали здесь три раза, – справедливо.


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

   Комментарии:

   • Иными словами, больше никаких неопределенных значений и больше никакой многозначной логики!


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


6. Язык D не должен включать никаких конструкций, которые связаны с "физическим" уровнем, уровнем "среды хранения" или "внутренним" уровнем системы либо логически подвергаются их воздействию (иных, чем функции, которые явно раскрывают реальное представление значений домена – см. РМ-предписание 4). Если разработчик имеет желание или потребность ввести какого-либо рода "язык определения структуры хранения", операторы этого языка и отображения dbvar в физическую среду хранения должны быть полностью отделены от всего, что выражается в 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, то такая возможность должна соответствовать некоторой ясно определенной и общепринятой модели.

   Комментарии:

   • Наша надежда заключается в том, что такая "ясно определенная и общепринятая" модель наследования когда-нибудь будет действительно найдена. Термин "общепринятая" призван здесь подчеркнуть, что авторы настоящего манифеста наряду с другими выступают в поддержку такой модели. От такой поддержки нет оснований отказываться.
   • Отметим, что поддержка наследования подразумевает некоторые расширения определений скалярной переменной, кортежной переменной, отношения и relvar. Представляется также, что в этой связи потребуется, вероятно, несколько ослабить ОО-предписание 1. Набросок возможной модели наследования, которая бы интегрировала эти соображения, приводится в готовящемся к изданию приложении к данному манифесту (предварительную его версию можно получить в настоящее время у авторов).


3. (Множественное наследование (Multiple Inheritance) Если в языке D допускается определение некоторого домена V' как поддомена какого-либо супердомена V, то не следует препятствовать также и тому, чтобы V' мог быть дополнительно определен как поддомен и некоторого другого супердомена W, который не совпадает с V и не является каким-либо его супердоменом (если только требования ОО-предписания 2 не исключают такую возможность).


4. Язык D должен обладать вычислительной полнотой. Это означает, что D может (но не обязан) поддерживать вызовы из так называемых "основных программ" (host program), написанных на языках, отличных от D. Подобным же образом, D может (но не обязан) поддерживать использование других языков программирования для реализации функций, определяемых пользователем.

   Комментарии:

   • Этим предписанием мы не намерены чрезмерно подрывать такую возможность, как оптимизируемость D. Мы не намерены также выдавать его за рецепт по использованию процедурных конструкций, подобных циклам, для выполнения запросов к базе данных или проверки целостности данных. Идея, скорее, состоит в том, что вычислительная полнота будет будет требоваться (в общем случае) для реализации функций, определяемых пользователем. Более удобно было бы иметь возможность реализовать такие функции в самом D, чем по необходимости совершать экскурсы в некоторые другие языки – экскурсы, которые в любом случае должны, по-видимому, порождать трудные проблемы для оптимизаторов. Мы, конечно, согласны с тем, что может оказаться желательным запретить использование некоторых возможностей D вне кода, который реализует такие функции. С другой стороны, такой запрет может слишком жестко ограничить то, что позволяет сделать "самостоятельная" прикладная программа (т.е. программа, которая не требует вызова из какой-либо программы, написанной на некотором другом языке). Эта проблема требует дополнительного изучения.


5. Инициирование транзакции должно производиться только с помощью явного оператора "начать транзакцию" (start transaction). Завершение транзакции должно осуществляться только с помощью операторов "зафиксировать" (commit) или "откатить" (rollback). Оператор "зафиксировать" должен быть явным, в то время как оператор "откатить" может быть и неявным (в случае, когда транзакция завершается неудачно, хотя в самой транзакции не было никаких сбоев).

   Комментарии:

   • Если транзакция T завершается оператором "зафиксировать" ("нормальное завершение"), то изменения, произведенные T в соответствующей dbvar, фиксируются. Если же транзакция T завершается оператором "откатить" (аварийное завершение), то изменения, произведенные T в соответствующей dbvar, анулируются. Иными словами, dbvar (и только они) обладают свойством "стабильности" ("persistence").


6. В языке D должны поддерживаться вложенные транзакции (nested transactions) – т.е. должно допускаться, чтобы какая-либо транзакция T1 могла начать другую транзакцию T2 до завершения собственного выполнения, и в этом случае:
   1. T2 и T1 должны взаимодействовать с одной и той же dbvar (как это фактически предусматривается РМ-предписанием16).
   2. D не должен препятствовать возможности асинхронного исполнения T1 и T2. Однако T1 не должна иметь возможности завершиться, прежде чем завершится T2 (иными словами, T2 должна полностью содержаться в T1).
   3. Откат T1 должен включать отмену результатов T2, даже если T2 была зафиксирована.


7. Пусть A – некоторая агрегатная (aggregate) операция (например, операция вычисления суммы, SUM), которая, по существу, является просто краткой записью некоторой повторяемой диадической операции θ – (в случае SUM такой диадической операцией является "+"). Если аргумент A оказывается пустым, то:
   1. если для θ существует значение тождественности (в случае "+" значением тождественности является 0), то результатом такого вызова A должно быть это значение тождественности;
   2. в противном случае результат такого вызова A должен быть не определен.

ОО-запреты

1. Relvar не являются доменами.

   Комментарии:

   • Иными словами, мы категорически отвергаем равенство вида "отношение = объектный класс" (более точно, равенство "relvar = объектный класс"), отстаиваемое, например, в [23]).


2. Никакое значение (скалярное или любого другого вида) не должно обладать какого-либо рода идентификатором (ID), который как-либо отличается от значения самого по себе.

   Комментарии:

   • Иными словами, мы отвергаем идею "объектных идентификаторов" (object ID). Как следствие этого, мы отвергаем: a) идею о том, что "объекты" могли бы использовать такие идентификаторы для совместного использования "подобъектов"; b) идею о том, что пользователи могли бы вынуждаться "разыменовывать" (dereference) такие идентификаторы (либо явно, либо неявно), чтобы получать значения.
   • Мы отвергаем также идею "идентификаторов кортежей" (tuple ID) (некоторые авторы, как нам кажется, отождествляют идентификаторы кортежей и объектные идентификаторы).
   • Этот запрет не препятствует тому, чтобы объекты вне dbvar обладали идентификаторами, которые являются "каким-либо образом отличными" от самих объектов. Он также не препятствует появлению таких идентификаторов в dbvar. (Мы должны подчеркнуть, что термин "объект" используется здесь в его общем смысле, а не в специализированном смысле объектно-ориентированного подхода.) Поэтому, например, домен имен файлов базовой операционной системы является допустимым доменом.


3. Любая нотация "публичной переменной экземпляра" (public instance variable), обеспечиваемая для оперирования значениями в доменах, должна быть всего лишь сокращенной синтаксической формой для вызова некоторых специальных функций (и возможно, “ссылок на псевдопеременные”, если такие переменные экземпляра могут появляться в левой части операций присваивания). Какая-либо непосредственная взаимосвязь между такими переменными экземпляра и реальным представлением значений из соответствующего домена не должна иметь обязательного характера.


4. В D не должна поддерживаться ни концепция "защищенных" (protected) переменных экземпляра (в отличие от приватных (private)), ни концепция "друзей" (friends). Пояснение этих понятий см. [20].

   Комментарии:

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

Весьма настоятельные РМ-предложения

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

   Комментарии:

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


2. В язык D следует включить поддержку системно-генерируемых ключей, как это описано в [16] (глава 5) и [7] (глава 19).


3. В язык D следует включить какие-нибудь удобные краткие декларативные обозначения для выражения: a) ссылочных ограничений (referential constraints); b) ссылочных действий (referential actions), таким как "каскадное удаление".


4. Для системы желательно, хотя и в полной мере не осуществимо, обладать способностью выводить (независимые от времени) возможные ключи для каждого отношения R, выразимого в языке D, таким образом, что:
   1. возможные ключи R становятся возможными ключами R', когда R присваивается R';
   2. сведения о возможных ключах R могут включаться в информацию об отношении R, которая доступна пользователю D.
   В языке D следует обеспечивать такие функциональные возможности, но без какой-либо гарантии относительно того, что выведенные ключи не являются собственными надмножествами фактических ключей, или даже что для каждого фактического ключа обнаруживается некоторое надмножество (собственное или иное). Реализации языка D могут, таким образом, состязаться друг с другом в степени успеха обнаружения возможных ключей.

   Комментарии:

   • Рекомендация о том, что следует выводить возможные ключи для производных отношений (насколько это возможно), была фактически предложена в RM-предписании 23, в котором требовалась поддержка общего механизма вывода ограничений. Возможные ключи упоминаются здесь явным образом, поскольку считаются важным частным случаем по причинам, обсуждаемым в [16] (глава 10).


5. В D следует предоставлять какие-либо удобные (непроцедурные) средства выражения запросов с квотой (quota query) (например "найти трех самых молодых служащих"). Такая возможность не должна увязываться с механизмом, который конвертирует отношение в упорядоченный список (см. РМ-запрет 2).


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


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

   Комментарии:

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


8. В D обеспечить механизм для того, чтобы иметь дело с "отсутствующей информацией" в духе схемы значений по умолчанию, описанной в [16] (глава 21), но основанной на доменах, а не на атрибутах.

   Комментарии:

   • Термин "значение по умолчанию" может привести к заблуждению, поскольку он предполагает такую интерпретацию, которая вовсе не имеется в виду – а именно то, что данное значение появляется настолько часто, что оно может быть с таким же успехом задано по умолчанию. Намерение же, скорее, заключается в том, чтобы использовать уместное значение "по умолчанию", отличное от всех возможных истинных значений, когда ни одно из подлинных значений не может быть использовано. Например, если подлинные значения атрибута ОТРАБОТАННЫЕ_ЧАСЫ – это положительные целые числа, то задание значения по умолчанию "?" может использоваться для того, чтобы показать, что (по каким-то причинам) никакое подлинное значение не известно. Следовательно, домен для атрибута ОТРАБОТАННЫЕ_ЧАСЫ – это не просто домен положительных целых чисел.


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

   Комментарии:

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

Весьма настоятельные ОО-предложения

1. Следует поддерживать некоторую форму наследования типов (см. ОО-предписания 2 и 3). В соответствии с этим предложением не следует допускать включения в D: a) концепции неявного преобразования типов; b) концепции, предусматривающей, что функции имеют специальный "отмеченный" (distinguished) параметр или параметр-"получатель" (receiver).

   Комментарии:

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


2. Следует поддерживать конструкторы типов-"коллекций", такие как LIST (список), ARRAY (массив) и SET (множество), подобно тому, как это сделано в языках, поддерживающих развитые системы типов. (См. также РМ-предписание 7.)


3. Пусть С – конструктор типа “коллекции”, отличный от RELATION. Тогда следует обеспечивать функцию преобразования, скажем C2R, для конвертирования значений типа C в отношения, а также обратная функция, скажем R2C, такие, что:
   1. C2R(R2C(r)) = r для каждого отношения r, выразимого в D;
   2. R2C(C2R(c)) = c для каждого выразимого в D значения c типа C.


4. DD следует основывать на модели "одноуровневого хранения", как это описано, например, в [15]. Другими словами, в этой модели не должно производиться какое-либо логическое различие между ситуациями, когда порция данных располагается в основной памяти или во вторичной или третичной (tertiary) памяти и т.д.

Заключительные замечания

Мы представили манифест относительно будущих направлений развития систем управления данными и СУБД. Теперь, вероятно, пришло время признаться, что мы действительно ощущаем некоторый дискомфорт в связи с идеей назвать некоторый по сути своей технический документ "манифестом". В соответствии со словарем XX века Чемберса, манифест – это "представленная в письменной форме декларация намерений, мнений или мотивов" некоторого лица или группы (например политической партии). Данная же конкретная декларация, напротив, является, как мы надеемся, предметом науки и логики, а не просто "намерениями, мнениями или мотивами". Однако если принять во внимание исторические прецеденты, которые привели нас к написанию этого документа, то в действительности выбор этого заголовка был предопределен.

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

РМ-предписания

1. Домены
2. Типизированные скаляры
3. Скалярные операторы
4. Реальное представление
5. Истинностные значения
6. Конструктор типов TUPLE
7. Конструктор типов RELATION
8. Оператор сравнения
9. Кортежи
10. Отношения
11. Скалярные переменные
12. Кортежные переменные
13. Переменные отношений (relvar)
14. Базовые и производные relvar
15. Переменные баз данных (dbvar)
16. Транзакции и dbvar
17. Операции создания/разрушения
18. Реляционная алгебра
19. Имена relvar и явные значения отношений
20. Реляционные функции
21. Присваивание отношений и кортежей
22. Сравнения
23. Ограничения целостности
24. Предикаты отношений и баз данных
25. Каталог
26. Разработка языка

РМ-запреты

1. Никакого упорядочения атрибутов
2. Никакого упорядочения кортежей
3. Никаких дубликатов кортежей
4. Никаких неопределенных значений
5. Никаких ошибок, связанных с пустыми отношениями
6. Никаких конструкций внутреннего уровня
7. Никаких операций на уровне кортежей
8. Никаких составных столбцов
9. Никаких подавлений проверки доменов
10. Не SQL

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

1. Проверка типов на стадии исполнения
2. Простое наследование (условное)
3. Множественное наследование (условное)
4. Вычислительная полнота
5. Явные границы транзакций
6. Вложенные транзакции
7. Агрегаты и пустые множества

ОО-запреты

1. Relvar не являются доменами
2. Никаких идентификаторов объектов
3. Никаких "публичных переменных экземпляра"
4. Никаких "защищенных переменных экземпляра" или "друзей"

Весьма настоятельные РМ-предложения

1. Возможные ключи для производных relvar
2. Системно-генерируемые ключи
3. Ссылочная целостность
4. Вывод возможных ключей
5. Запросы с квотой
6. Транзитивное замыкание
7. Параметры кортежей и отношений
8. Значения по умолчанию
9. Миграция SQL

Весьма настоятельные ОО-предложения

1. Наследование типов
2. Конструкторы типов-коллекций
3. Конвертирование в и из отношений
4. Одноуровневое хранение

Благодарности

Мы благодарны многочисленным друзьям и коллегам за их поддержку и за технические дискуссии, а также за полезные замечания по ранним версиям этого манифеста: Тенджу Беннету (Tanj Bennett), Чарли Бонтемпо (Charley Bontempo), Кейту Черрингтону (Keith Charrington), Линде ДеМишель (Linda DeMichiel), Винсенту Дьюпюису (Vincent Dupuis), Марку Эвансу (Mark Evans), Рону Фейгину (Ron Fagin), Орису Фрезену (Oris Friesen), Майклу Джексону (Michael Jackson), Джону Нейлингу (John Kneiling), Адриану Лернеру (Adrian Larner), Брюсу Линдсею (Bruce Lindsay), Альберту Майеру (Albert Maier), Карлу Маттоксу (Carl Mattocks), Нельсону Маттосу (Nelson Mattos), Дэвиду МакГоверану (David McGoveran), Сержу Миранде (Serge Miranda), Джиму Пантья (Jim Panttaja), Мэри Пантья (Mary Panttaja), Стефану Перенту (Stephane Parent), Фабиану Паскалю (Fabian Pascal), Рону Россу (Ron Ross), Артуру Райману (Arthur Ryman), Майку Сайксу (Mike Sykes), Стефану Тодду (Stephen Todd), Рику ван дер Лансу (Rick van der Lans), Антону Верстигу (Anton Versteeg) и Фреду Райту (Fred Wright).

Хью Дарвин добавляет: "В ноябре 1994 года Отделение программных решений фирмы IBM (IBM"s Software Solutions Division) объявило о консолидации своей деятельности в области исследований и разработок, что привело к закрытию ее лаборатории по разработке программного обеспечения в Варвике (Англия). С 1987 года я был служащим этой лаборатории, где техническая мысль процветала и преуспевала. И я бы хотел выразить мою признательность за поддержку, которую мне оказывал директор лаборатории Тони Темпл (Tony Temple) и некоторые ее руководители в сверхплановых занятиях, таких как этот манифест. Особую благодарность выражаю моему первому руководителю Стюарту Колвину (Stuart Colvin) и последнему – Дику Чепмену (Dick Chapman)".

Ссылки и библиография

1. 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.
2. David Beech: "Collections of Objects in SQL3", Proc. 19th International Conference on Very Large Data Bases, Dublin, Ireland (August 1993).
3. Jon Bentley: "Little Languages", CACM 29, 8 (August 1986).
   Иллюстрируются и обсуждаются следующие "критерии качества проекта языка": ортогональность, общность, экономичность, полнота, сходство, расширяемость и открытость.
4. 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).
5. 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.
6. E.F.Codd: "Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks", IBM Research Report RJ599 (August 19th, 1969).
   Предварительная версия работы [5].
7. Hugh Darwen (подписана именем Andrew Warden): "Adventures in Relationland".
   Статья, специально подготовленная для [8].
8. C.J.Date, Relational Database Writings 1985-1989. Reading, Mass.: Addison-Wesley (1990).
9. C.J.Date, "We Don"t Need Composite Columns", Database Programming & Design 8, 5 (May 1995, to appear).
10. C.J.Date: "Oh Oh Relational...", Database Programming & Design 7, 10 (October 1994).
    Поясняется, почему равенство "домен = класс объектов" правильное, а равенство "R-переменная = класс объектов" – ошибочное. Описываются те выгоды, которые можно было бы извлечь из пропагандируемого в настоящем манифесте истинного сближения между принципами реляционного и объектно-ориентированного подходов. Примерами работ, в которых отстаивается равенство "R-переменная = класс объектов", являются [2] и [23].
11. C.J.Date: An Introduction to Database Systems (6th edition). Reading, Mass.: Addison-Wesley (1995).
    Имеется несколько расхождений (весьма незначительных) между версией реляционной модели, описанной в части II этой книги, и версией, описанной в работе [16] (глава 15). Там, где встречаются такие расхождения, предпочтение следует отдавать этой книге.
12. C.J.Date: "How We Missed the Relational Boat" (публикуется под заголовком "How SQL Missed the Boat"), Database Programming & Design 6, 9 (September 1993).
13. C.J.Date: "The Primacy of Primary Keys: An Investigation", InfoDB 7, 3 (Summer 1993).
14. 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).
15. 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).
16. C.J.Date and Hugh Darwen: Relational Database Writings 1989-1991. Reading, Mass.: Addison-Wesley (1992).
17. C.J.Date and Hugh Darwen: A Guide to the SQL Standard (3rd edition). Reading, Mass.: Addison-Wesley (1993).
    Эта книга представляет собой учебное справочное пособие по текущему стандарту "SQL/92". В ней содержится ряд примеров нарушения принципов проекта хорошего языка. В частности, она включает приложение (Приложение D), в котором описаны "многие аспекты этого стандарта, которые представляются определенными неадекватно или даже некорректно определенными в настоящее время".
18. C.J.Date and David McGoveran: "Updating Joins and Other Views", Database Programming & Design 7, 8 (August 1994).
19. C.J.Date and David McGoveran: "Updating Union, Intersection, and Difference Views", Database Programming & Design 7, 6 (June 1994).
20. Margaret A.Ellis and Bjarne Stroustrup: The Annotated C++ Reference Manual. Reading, Mass.: Addison-Wesley (1990).
21. Nathan Goodman: "Bill of Materials in Relational Database", InfoDB 5, 1 (Spring/Summer 1990).
22. 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).
23. 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).
24. Mark A. Roth, Henry F. Korth, and Abraham Silberschatz: "Extended Algebra and Calculus for Nested Relational Databases", ACM TODS 13, 4 (December 1988).
25. Michael Stonebraker et al.: "Third Generation Database System Manifesto", ACM SIGMOD Record 19, 3 (September 1990).
    Есть русский перевод: "Системы баз данных третьего поколения: Манифест". СУБД, 2, 1995.

---

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

2) Это высказывание некоторые могут счесть крайне догматичным. Мы имеем в виду лишь,что предписания и запреты, которые проистекают из реляционной модели, настолько же являются предметом компромисса, насколько таковой является и сама реляционная модель.