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

       

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


  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 без нарушения каким-либо предписаний и запретов, составляющих данный манифест.



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