Отрицательные OO-утверждения

1. Relvars - это не домены.

2. Никакое значение не должно обладать каким-либо ID, отличным от самого этого значения.

Как видно, это очередной "наезд" на объектно-ориентированный мир. Но утверждение не слишком корректное, поскольку в объектном мире никто и никогда не утверждал, что у значений должны существовать ID. Говорится про "object identity", то есть про существование уникальной идентификации объектов. Но Д&Д вообще не хотят соглашаться с наличием понятия объекта.

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

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

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

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

   1. Если RX предназначено для определения выражения для некоторой виртуальной relvar R', то эти выводимые возможные ключи можно проверить на соответствие возможным ключам, явно определяемым для R'. Если конфликт не обнаруживается, то выводимые ключи становятся возможными ключами R';

   2. Сведения о выводимых ключах могут быть включены в информацию об R, доступную пользователям языка D (через "метазапрос").

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

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

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

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

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

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

   В следующий раз мы обсудим соответствующий механизм, предлагаемый Д&Д в их Tutorial D.

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

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

Назад | Содержание | Вперед