Классика баз данных - статьи
       

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


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

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

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

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

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

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

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

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


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


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

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

  • Наше намерение состоит в том, чтобы: (a) такие нарушающие инкапсуляцию операции использовались только в реализации других операций и (b) подобный эффект достигался с помощью системных механизмов авторизации. Иными словами, реальное представление значений домена должно быть скрыто от большинства пользователей.


  • Пусть V – некоторый домен. Отметим, что часто будет желательно определить набор операций, действие которых состоит в том, чтобы раскрыть одно возможное представление (possible representation) (не обязательно фактическое представление) для значений из V. При наличии таких операций пользователь по сути будет способен оперировать значениями из V точно так же, как если бы он имел дело с фактическим представлением.




  • Хотя реальные представления значений домена не существенны для спецификаций данного манифеста, может быть полезно указать, что, если v1 и v2 – разные значения из домена V, ничто в языке D не требует, чтобы реальные представления v1 и v2 были бы одной и той же формы. Например, V может быть доменом "текст", а v1 и v2 – двумя документами, подготовленными с использованием разных текстовых процессоров.


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


    THEN ..., IFF и т.д.).


  • Пусть H – некоторый заголовок кортежа (tuple heading) (см. РМ-предписание 9). Тогда должна существовать возможность определить домен, значения которого являются кортежами с заголовком H, – иными словами, TUPLE

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


  • Пусть H – некоторый заголовок отношения (см. РМ-предписание 10). Тогда должна существовать возможность определения домена, значениями которого являются отношениями с заголовком H. Иными словами, RELATION

    должен быть допустимым конструктором типов. Операции, определенные для такого домена, должны в точности представлять собой множество операций над отношениями, поддерживаемых D. В их число должна входить операция конструирования отношения из указанных кортежей, а также операция извлечения из отношения указанных кортежей. Должны иметься также возможности "вкладывания" и "выкладывания" ("nest"/"unnest") вложенных отношений, описанные в [16] (глава 6).

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

    • Заметим, что с точки зрения любого отношения, которое включает атрибут, определенный на таком домене, "скалярные" значения в этом домене (как и значения всех доменов) по-прежнему являются инкапсулированными. (Аналогичное замечание относится также к РМ-предписанию 6.) Мы не поддерживаем в явном виде отношения в форме NF2 ("NF в квадрате"), описанной, например, в [24], которая влечет существенные расширения классической реляционной алгебры.


  • Для каждого домена должен быть определен оператор сравнения на равенство (equals, "=").


    Пусть v1 и v2 – некоторые значения из какого- либо домена V. Тогда v1 = v2 должно быть истинно тогда и только тогда, когда v1 и v2 являются одним и тем же элементом V.


  • Кортеж t – это множество упорядоченных триплетов вида <A,V,v>, где:

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


    • V – имя (единственного) домена, соответствующего атрибуту A;


    • v – некоторое значение из домена V, называемое значением атрибута

      A в кортеже t.


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


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

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

    • Заметим, что каждый кортеж в R содержит в точности одно значение v для каждого атрибута A в H. Иными словами, R находится в первой нормальной форме – 1NF.


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


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


    Создание скалярной переменной S должно приводить к инициализации S некоторым начальным скалярным значением – либо значением, явно специфицированным в операции создания S, либо некоторым значением, зависящим от реализации, если никакое значение явно не указано.


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


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

    – объявленным заголовком для этой relvar.


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

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

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


  • Переменная базы данных (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).


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


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

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

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


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


    • Утверждение о том, что предикаты отношений должны удовлетворяться на границах операторов, в точности означает, что никакая реляционная операция присваивания не должна оставлять любую relvar в состоянии, в котором нарушается ее предикат отношения. Аналогично, утверждение о том, что предикаты базы данных должны удовлетворяться на границах транзакций, в точности означает, что никакая транзакция не должна оставлять соответствующую dbvar в состоянии, в котором нарушается ее предикат базы данных.


    • Из этого предписания, кроме того, следует, что должно быть невозможно обновлять "обновляемые представления" (т.е. производные relvar) таким образом, чтобы нарушалось определение этого представления. Иными словами, "обновляемые представления" всегда должны быть предметом того, что в SQL называется CASCADED CHECK OPTION [17].


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

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

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


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

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

    • Таким образом, должны быть абсолютно исключены произвольные ограничения, например, такие, как описаны в [8] (глава 12), [14] и [17], а также все другие случайные понятия и конструкции.



    • Содержание раздела