Когда расширение не является расширением?

1999 г

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

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

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

Intelligent Enterprise, June 1, 1999, Volume 2, Number 8
Когда расширение не является расширением?

When's an extension not an extension?

C.J. Date

(www.intelligententerprise.com/990106/online1.shtml)

С самого начала по отношению к реляционной модели наблюдался необычайно высокий уровень критики. Более конкретно, в течение многих лет утверждалось, что (a) в модели не хватает тех или иных возможностей и, следовательно, (b) ее необходимо некоторым образом расширять. В этой заметке я хочу достаточно детально исследовать суть дел, связанных с "расширением реляционной модели". В частности, мне хочется представить свои соображения по поводу собственной расширенной версии Кодда, известной под названием RM/T.

Ложные и истинные расширения

Некоторые утверждения о недостатках реляционной модели правильны, другие - нет. Соответственно некоторые предложенные расширения являются правильными в том смысле, что они действительно добавляют полезную функциональность; однако имеются и ложные расширения в том смысле, что они либо (a) не добавляют никакую новую функциональность, либо (b) функциональность, которую они добавляют, не является полезной. В число примеров правильных расширений входят операции EXTEND и SUMMARIZE, операции реляционного сравнения и теория обновления базы данных через представления. (Уверен, что можно согласиться с тем, что все эти примеры действительно обеспечивают новую полезную функциональность.) Примеры ложных расширений включают такие вещи как запросы с квотами, поддержку дат и времени и "тип данных REF" (REF = reference). Позвольте развить эту мысль:

Запросы с квотами полезны с прагматической точки зрения, но по существу они являются всего лишь синтаксической сокращенной записью для уже существующей функциональности. Если говорить более точно, то имея в виду ложные расширения, я не утверждал, что это обязательно плохо - я всего лишь имел в виду, что это на самом деле не расширение модели.
Поддержка дат и времени также полезна. Более того, это не просто сокращенная синтаксическая запись для того, что уже существует - действвительно обеспечивается новая функциональность. Однако это все-таки не расширение модели, поскольку вопрос о том, какие типы данных поддерживаются, не имеет ничего общего с моделью ("типы ортогональны таблицам").
Но "тип данных REF" является ложным расширением, поскольку он бесполезен! На самом деле, это возвращает в модель все эти указатели и связанные с ними вещи. Кодд сознательно отказался от этого много лет тому назад [1]. Ложные расширения - когда они действительно провозглашаются расширениями - приводят к искаженному пониманию истинной сути модели. Конечно, это в особенности свойственно сообществу SQL; конечно, из этого происходят недостатки SQL; многие проблемы SQL пытаются связать с "недостатками реляционной модели", а решение пытаются искать в "расширениях объектной модели". (Как я уже много раз писал раньше, наибольшей проблемой SQL является как раз то, что в этом языке не поддерживается реляцтонная модель.) Самым свежим и, видимо, наиболее вопиющим примером является так называемая объектно/реляционная модель, которая кратко обсуждается в следующем разделе.

"Объектно/реляционная" модель

Несколько поставщиков основанных на SQL СУБД пытаются (должен заметить, что с разной степенью успеха) расширить свои продукты, внедрив в них некоторую разновидность объектной функциональности. Они заявляют, что при этом расширенные продукты поддерживают "расширенную" версию реляционной модели, которую они называют "объектно/реляционной моделью" (для краткости - O/R).

Но это заявление абсурдно! Как мы вместе с Хью Хагеном показали в Третьем манифесте [2], объектная функциональность и реляционная модель полностью ортогональны. Цитирую: "Реляционная модель не нуждается в расширении, коррекции и дополнительных допущениях, и это не противоречит возможности [поддержки объектной функциональности]. Все, что требуется, это должная поддержка доменов отношений (что никогда не делалось в SQL) с пониманием того, что, по своей сути, это абстрактные типы данных (ADT). Другими словами, так называемая O/R модель - это всего лишь реляционная модель, чистая и простая; для нее не требуются какие-либо (истинные) "расширения реляционной модели".

Статья про RM/T: основные идеи

Обратимся к некоторым интересным истинным расширениям модели. В 1979 г. Кодд опубликовал еще одну важную статью под названием "Extending the Relational Database Model to Capture More Meaning" [3]. Я буду называть эту статью статьей про RM/T по причинам, которые скоро станут понятны. Как следует из названия статьи, ее основной задачей является введение набора "семантических" расширений исходной модели. Однако статья начинается с обзора базовой модели (по состоянию на 1979 г.), и мне хотелось бы сделать по этому поводу несколько замечаний, прежде чем переходить к деталям предложенных расширений.

Прежде всего, думаю, что не ошибусь, утверждая, что статья про RM/T была первой статьей Кодда, где было введено явное определения термина реляционная модель! Вот это определение:

Реляционная модель состоит из:

Коллекции изменяемых во времени табличных отношений (с отмеченными выше свойствами - особо отметим ключи и домены)
Правил вставки-обновления-удаления (Правила 1 и 2, упомянутых выше)
Реляционной алгебры, описываемой ... ниже.

Отклоняясь от основной темы, я хочу привести несколько комментариев по поводу этого определения:

Может быть, это не столь важно, но мне кажется немного странным, когда говорят, что реляционная модель включает "коллекцию ... отношений" (разве коллекция отношений это не база данных?). Мне кажется более правильным говорить, что модель включает генератор типов RELATION, который дает пользователям возможность определения значений и переменных отношений (конечно, я предпочитаю термин "переменная отношения" термину Кодда "изменяемое во времени табличное отношение".
"Правила 1 и 2, умомянутые выше" - это правила целостности сущности и ссылочной целостности. В более ранних статьях эти правила использовались более или менее неявно, не формулировались и не получали названий. Замечание: В действительности, формулировка правила ссылочной целостности была несколько дефектной, поскольку в ней не упоминалась возможность вхождения в состав внешнего ключа неопределенных значений. Но конечно, это не является важным для вас, как и для меня, если мы не считаем появление понятия первичного ключа событием первостепенной важности.
Реляционная алгебра, "описываемая ниже", включает обычные операции, а также дополнительные операции для работы с "неопределенными значениями" [sic]. В статье определяются следующие дополнительные операции: MAYBE O-JOIN, MAYBE DIVIDE, OUTER O-JOIN, NATURAL O-JOIN, OUTER NATURAL JOIN и OUTER UNION ("аналогичным образом можно было бы определить также OUTER-версии для INTERSECTION и DIFFERENCE"). Этот список операций порождает много вопросов - например, вопросы, связанные с ортогональностью и полнотой - но опять же, я не думаю, что это очень важно, поскольку считаю неопределенные значения и все, что с ними связано, ошибкой (по моему мнению, единственной большой ошибкой Кодда за все время его работы).

Также в статье про RM/T Кодд впервые явно упоминает идею реляционного присваивания. Однако это делается только в связи с предлагаемыми семантическими расширениями: присваивание не является частью приведенного определения "базовой реляционной модели", хотя, конечно, это часть базовой модели в ее современном понимании. Более того, не обсуждается тот факт, что операции INSERT, UPDATE и DELETE представляют собой лишь сокращенную форму записи некоторых реляционных присваиваний.

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

В четвертых, в статье про RM/T Кодд также впервые использует идею суррогатов - т.е. определяемых системой идентификаторов. (Снова эта идея подается только в связи с предлагаемыми семантическими расширениями, хотя нет никаких оснований не использовать ее в базовой модели, и в пользу этого имеется много веских аргументов.) Однако, к сожалению, в статье утверждается, что суррогаты должны быть скрыты от пользователей - очевидное нарушение приведенного ранее в этой статье определения реляционной базы данных, в котором говорится, что все данные в базе данных должны быть доступны (авторизованным) пользователям. На самом деле, можно было привести тот аргумент, что сокрытие суррогатов нарушает собственный Информационный Принцип Кодда, который устанавливает, что вся информация в базе данных должна явно представляться в терминах отношений и никак иначе.

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

Наконец, в статье про RM/T отведен один краткий (слишком краткий) раздел связи между реляционной моделью и логикой предикатов: "База данных [представляет собой] набор [высказываний] логики предикатов первого порядка... [Мы можем] вынести за скобки предикат, общий для набора простых высказываний, и затем трактовать [высказывания] как n-арное отношение, а этот предикат - как имя отношения". Кодд далее называет "пропозициональную" часть базы данных экстенсиональной, а предикатную часть - интенсиональной (оба эти слова являются техническими терминами логики). "Можно ... представлять интесиональную часть как набор ограничений целостности." И далее кратко сравниваются интерпретации замкнутого и открытого миров. (В интерпретации замкнутого мира отсутствие данной строки в данном отношении означает, что соответствующее высказывание ложно; в интерпретации открытого мира это означает, что мы не знаем, истинно высказывание или ложно.)

Статья про RM/T: Расширения

Как уже отмечалось, основная часть [3] посвящена расширенной версии реляционной модели, названной RM/T ("T - в честь Тасмании, где эти идеи были впервые представлены"). Статья начинается несколькими интересными предварительными замечаниями по поводу семантических расширений и "семантического моделирования данных" вообще:

"В действительности, задача поддержания смысла данных бесконечна. Поэтому термин "семантический" не должен интерпретироваться в каком-либо абсолютном смысле. Более того, модели баз данных, разработанные ранее (и иногда подвергаемые критике как "синтаксические"), не лишены семантических черт (возьмите, например, домены, ключи и функциональные зависимости). Цель [семантического моделирования], тем не менее, исключительно важна, поскольку даже незначительный успех может способствовать пониманию и порядку в области проектирования баз данных."

(Как приятно это отличается от преувеличенных заявлений, так часто встречаемых в области семантического моделирования!)

Далее Кодд делает другое хорошее замечание:

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

Хорошая аналогия!

Вернемся конкретно к RM/T. RM/T в целом относится к той же широкой категории, что и более хорошо известная "модель сущность/связь" (для краткости - E/R модель) [5]. Хотя и не реализованная в свое время (и, насколько мне известно, никогда позже), модель RM/T может служить - как и модель E/R - основой систематизированной методологии проектирования баз данных; на самом деле, лично я для использования в этих целях предпочитаю ее модели E/R, поскольку считаю, что она более точно определена. Некоторые очевидные различия между двумя этими моделями состоят в следующем:

В RM/T не проводится излишнее различие между сущностями и связями - связь рассматривается как специальный тип сущности.
Структурные и целостные аспекты RM/T являются более мощными и более точно определенными, чем в модели E/R.
RM/T включает собственные специальные операции, дополняющие набор операций базовой реляционной модели (хотя в этой области требуется дополнительная работа).

Коротко говоря, RM/T работает следующим образом:

Сущности (включая "связи") представляются E-отношениями и P-отношениями, которые являются специальными формами n-арных отношений общего вида. E-отношения используются для регистрации того факта, что некоторая сущность существует, P-отношения используются для регистрации свойств этих сущностей (все E-отношения имеют степень один, степень P-отношений не меньше двух).
Между сущностями может существовать множество связей; например, типы сущностей A и B могут быть связаны в ассоциацию (термин RM/T для обозначения связи многие-ко-многим), или тип сущности Y может быть подтипом типа сущности X. RM/T включает формальную структуру каталога, с помощью которого такие связи могут быть сделаны известными системе. Тем самым система получает возможность поддержки различных ограничений целостности, порождаемых существованием таких связей.
Как уже отмечалось, обеспечивается ряд операций высокого уровня для манипулирования различными объектами RM/T (E-отношениями, P-отношениями, отношениями-каталогами и т.д.).

В RM/T также обеспечивается схема классификации сущностей, которая во многих отношениях представляет собой наиболее значительный аспект - или, по крайней мере, наиболее видимый аспект - всей модели. Более конкретно, сущности классифицируются (хотя, заметьте, только неформально) в три категории, называемые ядрами, характеристиками и ассоциациями:

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

Кроме того:

Сущности (все зависимости от их категории) могут обладать свойствами; например, детали имеют цвет, пункты заказа - стоимость, у поставок имеется объем поставки.
В частности, любая сущность (снова вне зависимости от категории) может иметь свойство, указывающие на некоторую другую связанную сущность; например, заказы указывают на клиентов. Указание представляет связь многие-к-одному между двумя сущностями. Замечание: В действительности, идея указаний была добавлена позже [6] - ее не было в первой статье про RM/T.
Поддерживаются супертипы и подтипы сущностей. Если B является подтипом A, то B - это ядро, характеристика или ассоциация в зависимости от того, представляет ли собой A ядро, характеристику или ассоциацию. Замечание: Однако в статье про RM/T абсолютно ничего не говорится по поводу связанного (и важного!) понятия наследования. Понятие супертипов и подтипов в RM/T больше похоже на понятие "супертаблиц и подтаблиц", предлагаемое в SQL3, чем на истинное наследование типов, обсуждаемое, например, в Третьем Манифесте.

Упомянутые понятия можно связать (не слишком точно) с их аналогами в E/R следующим образом: Ядро соответствует "регулярной сущности" E/R; характеристика - "слабой сущности" E/R; ассоциация - "связи" E/R (только для связей многие-ко-многим).

Замечание: В дополнение к аспектам, кратко обсужденным выше, RM/T также включает поддержку (а) временного измерения и (b) различных видов агрегации данных. Более подробное обсуждение можно найти в статье Кодда [3] или во вводном описании RM/T [6].

Литература

Date, C.J. "Don't Mix Pointers and Relations!" and "Don't Mix Pointers and Relations - Please!". In C.J.Date, Hugh Darwen, and David McGoveran: Relational Database Writings 1994-1997. Reading, Mass.: Addison-Wesley, 1998.
Date, C.J. and Hugh Darwen. Foundation for Object/Relational Databases: The Third Manifesto. Reading, Mass.: Addison-Wesley, 1998.
Codd, E.F. "Extending the Relational Database Model to Capture More Meaning." IBM Research Report RJ2599 (August 6th, 1979). Republished in ACM Transactions on Database Systems 4(4), December 1979.
Codd, E.F. The Relational Model for Database Management Version 2. Reading, Mass.: Addison-Wesley, 1990.
Pin-Shan Chen. :The Entity-Relationship Model - Toward a Unified View of Data". ACM Transactions on Database Systems 1(1), March 1976. Republished in Michhael Stonebraker (ed.): Readings in Database Systems (2nd edition), San Mateo, Calif.: Morgan Kaufmann, 1994.
Date, C.J. "The Extended Relational Model RM/T." In C.J.Date, Relational Database Writings 1991-1994. Reading, Mass.: Addison-Wesley, 1995.
Date, C.J. and Hugh Darwen. A Guide to the SQL Standard (4th edition). Reading, Mass.: Addison-Wesley, 1997.