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

       

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


  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 должен быть не определен.



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