Intelligent Enterprise, June 1, 1999, Volume 2, Number 8

Реляционная модель выдержит испытание временем

The relational model will stand the test of time

C.J. Date

(www.intelligententerprise.com/992206/online1.html)

Я посвятил несколько заметок историческому обзору и анализу нескольких статей Кодда о реляционном подходе (по крайней мере, наиболее важных статей). Более конкретно, обсуждались следующие статьи:

Время от времени я касался и других статей.

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

Цели реляционного подхода

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

  1. Независимость данных
  2. Простейшая из числа возможных структура, согласованная с семантическими соображениями
  3. Обеспечение унифицирующего принципа, упрощающего язык, требуемый для взаимодействия, и анализ операций, требуемый для авторизации доступа и оптимизации поиска
  4. Сравнительно легкий анализ согласованности [данных].

Позже в своей статье про "Великое Сражение" [3] Кодд пишет: "Реляционный подход разрабатывался как ответ на следующие требования, которые были сравнительно новыми в 1968 г.":

  1. Независимость данных
  2. Интеграция файлов в базы данных
  3. Разнообразные типы пользователей
  4. Наличие многих терминальных пользователей с оперативным доступом к данным
  5. Возрастающий уровень совместного использования данных
  6. Сети удаленных баз данных.

В приглашенном докладе на конгрессе IFIP 1974 [4] (в том же году, когда была опубликована статья про Великое Сражение) Кодд перечисляет следующее как "цели [реляционного подхода]":

  1. Обеспечить высокий уровень независимости данных
  2. Обеспечить спартанскую простоту представления данных, чтобы разнообразные пользователи (от новичков в области компьютеров до самых опытных) могли взаимодействовать с данными на основе общей модели (не запрещая добавлять пользовательские представления в специальных целях)
  3. Упростить потенциально огромную работу администратора базы данных
  4. Ввести теоретическую основу (хотя бы небольшую) в управление базами данных (область, в которой, к сожалению, отсутствуют надежные принципы и руководства)
  5. Объединить области выборки фактов и управления файлами, чтобы впоследствии можно было обеспечить соответствующие услуги в мире коммерции
  6. Переместить прикладное программирование с использованием баз данных на новый уровень - уровень, на котором множества (и, более конкретно, отношения) трактуются как операнды, а не обрабатываются поэлементно.

И он добавляет: "В связи со второй [из перечисленных целей] важно помнить, что базы данных появились, чтобы приносить пользу конечным пользователям, а не для прикладных программистов, которые сегодня выступают в качестве посредников (middle-men [sic]) при удовлетворении потребностей обработки данных".

Кодд повторяет те же цели в статье про Великое Сражение и добавляет, что реляционный подход состоит из "четырех основных компонентов":

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

"Обсуждения реляционного подхода часто замыкаются на первом [из этих компонентов] в ущерб остальным трем... Для обоснования этого подхода все четыре компонента должны рассматриваться в одном пакете." [3]

Наконец, в статье, написанной по поводу получения Тьюринговской премии (вполне заслуженной) в 1981 г. за работы Кодда в связи с реляционной моделью [5], он утверждает, что истинная реляционная система может:

  1. Сделать многие приложения доступными для непрограммистов в тех случаях, когда ранее программисты бы необходимы
  2. Увеличить производительность программистов во многих (хотя и не всех) приложениях баз данных (немного перефразировано).

Мне кажется, что эти разные списки целей и связанных с ними предметов совместно составляют впечатляющее свидетельство огромных достижений Кодда. Я не думаю, что кто-либо может серьезно утверждать, что (a) какая-либо из этих целей нежелательна и (b) реляционная модель - за одним исключением - не может их достичь. Возможным исключением является "добавление впоследствии соответствующих услуг для мира коммерции". Обеспечение таких услуг все еще является (насколько мне известно) вопросом, адресуемым рынку СУБД. Тем не менее, имеются все основания считать, что реляционная модель действительно обеспечивает правильную основу для таких услуг по причине отмечавшейся в предыдущей заметке тесной связи с логикой предикатов.

Итак, что же такое реляционная модель?

В предыдущей заметке я отмечал, что, как это не странно, Кодд не определял термин "реляционная модель" до 1979 г. [1] Возможно, еще более странно, что он не определял более общий термин "модель данных" до 1981 г. ! В статье под названием "Модели данных в управлении базами данных" [6] он определяет модель данных как комбинацию трех компонентов:

  1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели
  2. Коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов, которые законным образом могут появиться в любой такой базе данных
  3. Коллекции операций, применимых к таким экземплярам объектов для выборки и других целей (немного перефразировано).

Кстати, замечу, что здесь слово "объект" используется не в современном ограниченном смысле.

Строго говоря, такого рода замечания не слишком осмысленны. Если учесть, что отсутствует точное определение термина объект в "современном ограниченном смысле", то тем более непонятно, что означает этот термин (или это не термин?) в старом добром смысле Кодда. (Примечание С.Кузнецова.)

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

Но, видимо, возникает вопрос: "Что же в точности представляет собой реляционная модель?". Если внимательно просмотреть серию статей Кодда, то можно заметить, что его собственные определения эволюционизировали с 70-х до начала 80-х гг. (И на самом деле, изменялись.) Одним из последствий этого было то, что критики смогли обвинить самого Кодда и реляционный подход в целом в том, что "створки ворот раздвигаются" слишком сильно. Например, Майкл Стоунбрейкер написал [7], что "можно видеть четыре разных версии" модели:

Вероятно, по причине того, что нас немного задела такая критика, мы с Хью Дарвеном постарались привести в Третьем Манифесте свою собственную аккуратную формулировку того, что такое реляционная модель (или чем она должна быть!). Действительно, мы хотели, чтобы Манифест отчасти рассматривался бы как такая определительная формулировка. За подробностями следует обращаться к самой книге; здесь же хотелось бы только сказать, что мы видим свой вклад в этой области прежде всего как расстановку всех точек над i и черточек на t, которые не были расставлены должным образом в работах Кодда. Мы не нисколько не отклонились от видения Кодда в каких-либо существенных аспектах; весь Манифест в очень большой степени следует духу идей Кодда и развивает основанное им направление.

В каком направлении развивается реляционная модель?

В первой заметке из этой серии я говорил, что ожидаю, что в течение сотен лет системы баз данных будут основываться на реляционном фундаменте, заложенном Коддом. И я надеюсь, что в течение нескольких последних месяцев вы увидели, на чем основаны мои ожидания. Реляционный подход действительно является надежной основой, опираясь на математику и логику предикатов. (Конечно, я не имею в виду, что модель разрешает все известные проблемы и не нуждается в каких-либо расширениях; как мы видели в прошлом месяце, расширения, конечно, возможны и иногда желательны. Я имею в виду только то, что это надежная основа.)

Мне хочется закончить сводкой аргументов, который представил сам Кодд (под заголовком "Whther Database Management?") в статье про Великое Сражение, рассматривая возможные альтернативы будущего систем баз данных. Начнем с предположения наличия простейшего ориентированного на программиста интерфейса с базой данных (интерфейса на уровне записей). Тогда:

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

Заключение очевидно.

Литература

  1. 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.
  2. Codd, E.F. "A Data Sublanguage Founded on the Relational Calculus." IBM Research Report RJ893 (July 26th, 1971). Republished in Proc. 1971 ACM SIGFIDET Workshop on Data Description, Access and Control, San Diego, November 1971.
  3. Codd, E.F. "Interactive Support for Nonprogrammers: The Relational and Network Approaches." IBM Research Report RJ1400 (June 6th, 1974). Republished in Randall J. Rustin (ed.), Proc. ACM SIGMOD Workshop on Data Description, Access, and Control, Vol. II, Ann Arbor, Michigan, May 1974. Also in C.J. Date, Relational Database: Selected Writings. Reading, Mass.: Addison-Wesley, 1986.
  4. Codd, E.F. "Recent Investigations into Relational Data Base Systems". IBM Research Report RJ1385 (April 13rd, 1974). Republished in Proc. 1974 Congress (Stockholm, 1974). New York, N.Y.: North-Holland, 1974.
  5. Codd, E.F. "Relational Database: A Practical Foundation for Productivity." IBM Research Report RJ3339 (December 21st, 1981. Republished in CACM 25(2), February 1982.
  6. Codd, E.F. "Data Models in Database Management. Proc. Workshop in Data Abstraction, Databases, and Conceptual Modelling (Michael L. Brodie and Stephen N. Zilles, eds.), Pingree Park, Colo. (June 1980): ACM SIGART Newsletter No. 74 (January 1981); ACM SIGMOD Record 11(2), February 1981; ACM SIGPLAN Notices 16(1), January 1981.
  7. Stonebraker, Michael. Introduction to Chapter 1 ("The Roots"). Readings in Database Systems (2nd edition). San Mateo, Calif.: Morgan Kaufmann, 1994.
  8. Codd, E.F. "A Relational Model of Data for Large Shared Data Banks." CACM 13(6), June 1970. Republished in Milestones of Research -- Selected Papers 1958-1982 (CACM 25th Anniversary Issue), CACM 26(1), January 1983.
  9. Codd, E.F. "Is Your DBMS Really Relational?"; "Does Your DBMS Run By The Rules?" Computerworld (October 14th, 1985; October 21st, 1985).
  10. Codd, E.F. The Relational Model For Database Management Version 2. Reading, Mass.: Addison-Wesley, 1990.
  11. Date, C.J. and Hugh Darwen. Foundation for Object/Relational Databases: The Third Manifesto. Reading, Mass.: Addison-Wesley, 1998.