Уважаемые читатели!

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

До скорой встречи, Сергей Кузнецов

---

Intelligent Enterprise, No 3, March 1999

Завершая обсуждение подъязыка Alpha

Data Sublanguage Alpha

C.J. Date

(www.intelligententerprise.com/990903/online2.shtml)

В предыдущей заметке мы обратились к подъязыку данных Кодда Alpha и привели обзор основных средств определения данных и операций манипулирования данными. Как и раньше, я использую в качестве основного первоисточника [5] (статью, которая ниже именуется "статьей про Alpha" или иногда просто "статьей Кодда"). Ссылки на [3] присутствуют только в тех случаях, когда этот материал имеет отношение к [5].

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

GET W1 (S.SNAME, S.CITY) :
ALL P SOME SP ( SP.S# = S.S# AND SP.P# = P.P# )

Но важно понимать, что здесь имя "S" не представляет отношение поставщиков S; это имя означает переменную S, определенную на отношении с тем же именем (то же касается имен P и SP). Такая сокращенная форма используется и в QUEL, и в SQL.

Дуальный подход: В [2] Кодд явно говорит о том, что теперь называется принципом дуального подхода. Любая операция над базой данных, которую можно выполнить в интерактивном режиме, может быть также вызвана из прикладной программы. "Язык [Alpha] направлен на то, чтобы быть подъязыком … языков, используемых всеми конечными пользователями" - пишет Кодд. "Этот язык ориентирован также на то, чтобы служить подъязыком таких основных языков программирования как PL/1, COBOL и FORTRAN". И это снова в первый раз, по моему мнению.

Каталог: В статье про Alpha явно демонстрируется признание Коддом понятия каталога. Утверждается, что сам каталог должен быть структуризован как набор отношений: "Каталог … может быть сам частью баз данных и должен состоять из … отношений". И дальше: "Вся информация, относящаяся к новому отношению -- имя отношения, имена атрибутов и доменов, спецификация первичного ключа и т.д. -- должна быть связана с отношениями, каталогизирующими отношения базы данных" (слегка перефразировано). И: "Ограничения авторизованного доступа должны составлять те отношения, которые описывают эти ограничения … Для новых отношений должно быть выбрано представление хранения (включающее решение о том, какие атрибуты следует индексировать), и эта описательная информация должна храниться в соответствующих отношениях".

Косвенные ссылки: Язык Alpha включает операцию "разыменования" (dereference), называемую PER, в соответствии с которой (например) операция

GET W2 PER (W1.X)

Выбирает в рабочее пространство W2 отношение, имя которого задается компонентом рабочего пространства W1. В языке QUEL имеется в чем-то похожее свойство; в SQL такой возможности не было до появления "динамического SQL".

Миграция доменов: В [3] имеются некоторые замечания, касающиеся того, что называется миграцией доменов. (Лучше было бы называть это миграцией атрибутов.) Основная идея состоит в том, что некоторый атрибут, говоря нестрого, может "мигрировать" из одного базового отношения в другое, и мы хотели бы иметь возможность корректного продолжения использования запросов и приложений при таких изменениях.

Другими словами. Кодд говорит об одном аспекте того, что теперь называется логической независимостью данных. Общее решение состоит в том, чтобы обеспечить представления, делающие новые отношения похожими на старые, пока к ним применимы эти запросы и приложения. И решение заключается в том, что предлагает Кодд (хотя он вообще не использует термин "представление"). В [5] он касается этих идей косвенным образом, не вдаваясь в детали.

Трехзначная логика: В статье про Alpha -- очень неудачно, по моему мнению -- допускается операция выборки с уточнением MAYBE_TOO, относящимся к тем кортежам, для которых условие выборки вырабатывает значение uknown (это истинностное значение в статье называется maybe), а также к тем кортежам, для которых значением условия является true. Другими словами, Кодд полагал, что система должна основываться на трехзначной логике и должна поддерживать некоторый род неопределенных значений (в статье они называются "отсутствующими значениями"). Он не развивает эту идею, кроме a) простого примера вставки кортежей с неспецифицируемыми компонентами ("сама система [внесет] отсутствующее значение [этих неспецифицированных компонентов]") и b) замечания относительно того, что "более подробная разработка [этого подхода] не является уместной".

Думаю, что это наблюдение правильно. Постоянные читатели этой серии знают, что мы с Коддом абсолютно не согласны с подходом неопределенных значений и трехзначной логики, и я сожалею о том, что он просто упомянул об этой возможности в 1971 г. Он ничего не делал по этому поводу до 1979 г. [7]; другими словами, реляционная модель прекрасно работала без неопределенных значений в течение десяти лет.

Уровни языка

До детального погружения в язык Alpha в [5] обсуждается общий вопрос уровней языка: "Системы баз [данных] могут классифицироваться в соответствии с моделью данных, с которой взаимодействует пользователь, и [уровнями] языка, обеспечивающими это взаимодействие пользователя". Моделями данных могут быть деревья, сети или отношения; уровень языка может быть низким (Кодд также называет этот уровень "процедурным"), промежуточным (основанным на алгебре) или высоким (основанным на исчислении). Снова заметим, что Кодд относится к модели и операциям как к разным вещам! Более того, он использует термин "модель данных" в смысле модели данных конкретной базы данных, а не в общем смысле.

Должен обратить внимание на некоторое недоразумение, связанное с использованием термина "процедурный"; некоторые люди используют этот термин в смысле "императивный". Хотя процедурные языки, конечно, являются императивными, императивный язык не обязательно процедурен. Например, можно представить себе язык, основанный на реляционной алгебре Кодда (непроцедурный), хотя по стилю являющийся императивным.

Кодд рассматривает преимущества и недостатки трехуровневой организации языка и приводит аргументы в пользу той своей позиции, что уровень исчисления стоит над алгебраическим, который, в свою очередь, выше процедурного уровня. Он правильно замечает, что эти аргументы "особенно уместны по отношению к внутрисистемной совместимости и стандартизованности"; он также замечает, что уже представленные в [4] аргументы (относящиеся к преимуществам реляционной модели в целом) подчеркивают приводимые в [5] доводы в пользу уровня исчисления и алгебраического уровня перед процедурным.

Аргументы этого раздела статьи Кодда демонстрируют большой уровень предсказательности. Приведем краткую сводку этих аргументов.

Защитить пользователей от суматохи представлений: "Обеспечение концептуально четкой модели данных и мощного, концептуально четкого языка манипулирования относится не только к эстетике. Если пользователи вынуждены выбирать и принимать решения относительно потенциально не требуемых деталей представления, последствия могут быть разнообразными и дорогостоящими … Это не только аргумент в пользу того, чтобы защитить пользователей от … низкоуровневых деталей физического представления; в равной степени этот аргумент против введения … надуманного, концептуально избыточного логического представления" (немного перефразировано). Эти аргументы сегодня настолько же сильны, действительны и правильны как во время их начального появления! Печально, что наша индустрия потеряла к ним внимание (конечно, я имею в виду бесчисленные попытки заменить реляционную модель некоторой разновидностью "объектной модели").

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

Понимание и модификация программ: Этот аргумент следует из двух предыдущих. "Важна ясность намерений, [особенно] когда требуется изменить прикладную программу [и в особенности тогда, когда это изменение должно производиться людьми], не писавшими эту программу." В связи с этим Кодд предлагает сравнить работу по изменению порядка двух кванторов в Alpha-программе c той работой, которая требуется для изменения Codasyl-программы для достижения того же результата. Хороший пример!

Эволюционное развитие методов поиска: "Применение подхода исчисления позволяет успешно совершенствовать общие алгоритмы поиска, которые могут внедряться в системы баз данных без затрагивания программ пользователей." (Я бы сказал, что то же относится и к алгебраическому подходу.) Другими словами, избавление пользовательских программ от заботы об эффективности означает, что эти программы автоматически выигрывают от эволюционного -- и даже революционного -- развития технологии физического доступа к данным.

Эволюционное развитие структур данных: Этот аргумент связан с предыдущем и похож на него (он тоже означает, что пользовательские программы могут получить автоматический выигрыш от развития технологии физического хранения.) Здесь под "структурами данных" Кодд в действительности понимает структуры хранения.

Поддержка специализированных языков запросов и обновления: "Многим пользователям требуются … языки, специализированные для их приложений. Высокая стоимость поддержки [таких] языков … предполагает, что нужно распознать [настолько много общих функций, насколько это возможно] и запрограммировать их раз и навсегда … [Исследования в области процессоров запросов на естественных языках] показывают, что языки, основанные на исчислении, ведут к достижению этой цели." И снова это очень правильно. Кстати, собственная более поздняя работа Кодда над системой запросов на естественном языке Rendezvous добавляет вес этому аргументу.

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

Я хотел бы завершить это обсуждение языка Кодда Alpha двумя замечаниями.

1. В статье про Alpha упоминаются несколько запланированных статей: "Цель [этой статьи] состоит в том, чтобы обеспечить основу последующих статей по принципам авторизации, тактике поиска и методов представления данных" (стр. 2). "Детальному обсуждению [каталога] будет посвящена другая статья" (стр. 35). "Желательны дополнительные возможности … [включая] блокировки, авторизацию доступа, поддержку целостности, виртуальные атрибуты, литеральные вставки … Умышленно опущены возможные типы ошибок и … информация обратной связи. Эти аспекты будут обсуждаться в следующей статье" (стр. 41). Печально, но ни одно из этих обещаний не было в действительности исполнено!
2. Вместе со своими тремя коллегами Кодд впоследствии работал над проектом низкоуровневой подсистемы Gamma-0, которая должна была стать основой реализации Alpha-подобного языка высокого уровня [2]. Более точно, Gamma-0 должна была стать основой реализации другого интерфейса, немного более высокого уровня, называвшегося Gamma-1, а уже Gamma-1 должна была явиться основой реализации Alpha-подобного языка высокого уровня. Принципиальным различием Gamma-0 и Gamma-1 было то, что Gamma-0 обеспечивала только однопользовательский интерфейс, а Gamma-1 - многопользовательский. Конечно, они проектировались согласованно: "Существенные аспекты Gamma-1 принимались во внимание и влияли на проектирование Gamma-0" [2].

Gamma-0 и Gamma-1 совместно демонстрируют большое сходство с подсистемой хранения System R [1], называемой RSS (Relational Storage System). Поэтому не удивительно, что один из коллег Кодда Ирв Трейджер позже был менеджером проекта RSS.

Литература

1. M.M. Astrahan et al. "System R: Relational Approach to Database Management". ACM Transactions on Database Systems 1, No. 2 (June 1976).
2. D. Bjorner, E.F. Codd, K.L. Deckert, and I.L. Traiger. "The GAMMA-0 n-ary Relational Data Base Interface: Specifications of Objects and Operatioins". IBM Research Report RJ1200 (April 11, 1973).
3. E.F. Codd. "Notes on a Data Sublanguage". IBM internal memo (January 19, 1970).
4. E.F. Codd. "A Relational Model of Data for Large Shared Data Banks". CACM 13, No. 6 (June 1970). Republished in Milestones of Research -- Selected Papers 1958-1982 (CACM 25th Anniversary Issue), CACM 26, No. 1 (January 1983).
5. E.F. Codd. "A Data Base Sublanguage Founded on the Relational Calculus". IBM Research Report RJ893 (July 26, 1971). Republished in Proc. 1971 ACM SIGFIDET Workshop on Data Description, Access and Control, San Diego, Calif. (November 1971).
6. E.F. Codd. "Seven Steps to Rendezvous with the Casual User". IBM Research Report RJ1333 (January 7, 1974). Republished in J.W. Klimbie and K.L. Koffeman (eds.), Data Base Management, Proc. IFIP TC-2 Working Conference on Data Base Management. New York, N.Y.: North-Holland (1974).
7. E.F. Codd. "Extending the Relational Database Model to Capture More Meaning". IBM Research Report RJ2599 (August 6, 1979). Republished in ACM Transactions on Database Systems 4, No. 4 (December 1979).