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

После выхода в свет летом 1998 г. книги Криса Дейта и Хью Дарвена Foundation for Object/Relational Databases: The Third Manifesto все свои колонки в журнале Database Programming & Design Дейт основывает на материалах этой книги с добавлением критических замечаний, для книги не очень пригодных. Конечно, я рекомендовал бы всем вам прочитать эту книгу. Но поскольку я понимаю, что это возможно не для всех, то предлагаю хотя бы ознакомиться с основными идеями, читая мои пересказы заметок Дейта. Хочу предупредить, что эти идеи, с моей точки зрения, не бесспорны. Но для понимания сути современных баз данных знакомство с ними очень полезно.

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

Приятного вам чтения, Сергей Кузнецов

---

Intelligent Enterprise's

Database Programming & Design OnLine
October 1998

According to Date
C.J.Date

Persistence Not Orthogonal to Type

(http://www.dbpd.com/vault/9810/date.html)

Третий манифест не соглашается с объектным миром

В сентябрьском выпуске я объяснял, почему я чувствую, что для концентрации объектного мира на инкапсуляции имеются недостаточные основания. В этом месяце я хочу обратить внимание на другое хорошо известное утверждение мира объектов -- а именно, то утверждение, что постоянство хранения (persistence) ортогонально типу (для краткости я буду ссылаться на это утверждение как на POTT). POTT означает, что (a) любая структура данных, которая может быть создана традиционной прикладной программой -- например, массив, ссылочный список или стек -- может быть сохранена как объект в объектной базе данных и (b) структура таких объектов является видимой для пользователя. Например, объект EX, который является коллекцией служащих данного отдела. EX может быть реализован как список или как массив, и пользователи будут должны знать, как это сделано на самом деле (поскольку соответственно будут различаться операции доступа).

Одной из наиболее ранних статей, если не в самой ранней, выражающей позицию POTT, была статья "Types and Persistence in Database Programming Languages" Малькольма Аткинсона (Malcolm Atkinson) и Питера Бьюнмана (Peter Buneman) (ACM Computing Surveys 19(2), June 1987). Аткинсон был также одним из авторов манифеста "The Object-Oriented Database System Manifesto" [1], предлагавшего набор возможностей, который, по мнению авторов, должна поддерживать СУБД, если она объявляется "объектно-ориентированной". Конечно, среди прочего было включено и свойство POTT.

В последствии манифест "The Third Generation Database System Manifesto" также провозглашал POTT как цель будущих систем баз данных ("Постояноство хранение X для различных X является хорошей идеей") [2]. И авторы The Object Database Standard: ODMG 2.0 также согласны с этим: "[Мы] определяем объектную СУБД как СУБД, интегрирующую возможности базы данных с возможностями объектно-ориентированного языка программирования". Объктная СУБД делает объекты базы данных такими как если бы они были объектами языка программирования… [она] расширяет язык прозрачно постоянно хранимыми данными… и другими возможностями базы данных". [3] (курсив К.Дейта).

Однако занятая мной и Хью Дарвеном позиция в Третьем Манифесте весьма отличается:

"Для постоянного хранения предназначены базы данных (и ничто другое)… [Поскольку] единственным видом переменной, которую мы допускаем в базе данных, является [реляционная переменная] или relvar, единственным видом переменной, которая может обладать свойством постоянного хранения, является relvar".

POTT нарушает независимость данных

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

При принятии этого предположения мы можем охарактеризовать различия между этими двумя подходами следующим образом:

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

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

Одним из последствий этого положения дел, как уже говорилось -- в противоречии с традиционным здравым смыслом -- является то, что объектные системы могут поддерживать меньшую независимость данных, чем реляционные системы. Например, предположим, что в некоторой объектной базе данных реализация упоминавшегося ранее объекта EX (коллекции служащих данного отдела) изменяется из массива в список со ссылками. Что произойдет с существующим программным кодом, обращающимся к объекту EX? Он сломается.

Возможно, мне следует задать еще один вопрос: Зачем нам нужно менять реализацию EX таким способом? Конечно, в основе ответа лежит эффективность. В идеале изменение не должно затрагивать ничего, кроме эффективности; однако на деле это не так.

На самом деле, мне кажется, что возможность наличия всех этих разных способов представления данных на логическом уровне является примером того, что я называю ложной общностью. Я бы даже сказал, что вся эта идея проистекает из неудачи четкого разделения модели и реализации (может понадобиться множество разных представлений на физическом уровне, но они не нужны на логическом уровне). Помню, как однажды сказал Э.Ф. Кодд (E.F. Codd) (в ответ на вопрос на панельной дискуссии): "Если вы скажете, что имеете в своей системе 50 разных способов представления данных [на логическом уровне, конечно], то я скажу вам, что 49 из них - лишние".

POTT порождает дополнительную сложность

Очевидно, что POTT действительно приводит к дополнительной сложности -- под "сложностью" я прежде всего понимаю сложность для пользователя, хотя порождаются большие сложности и для системы. Например, реляционная модель поддерживает только один "генератор типа коллекции" -- RELATION -- совместно с набором операций -- соединение, проекция и т.д. -- которые применимы ко всем "коллекциям" этого типа (другими словами, ко всем отношениям). В отличие от этого, в соответствии с предложениями ODMG поддерживаются четыре генератора типа коллекции - SET, BAG, LIST и ARRAY, для каждого из которых имеется набор операций, применимых ко всем коллекциям данного типа. И я утверждаю, что операции ODMG одновременно сложнее реляционных и обладают меньшей можностью. Вот, например, операции ODMG для списков:

IS_EMPTY
IS_ORDERED
ALLOWS_DUPLICATES
CONTAINS_ELEMENT
INSERT_ELEMENT
REMOTE_ELEMENT
CREATE_ITERATOR
CREATE_BIDIRECTIONAL_ITERATOR
REMOTE_ELEMENT_AT
RETRIEVE_ELEMENT_AT
REPLACE_ELEMENT_AT
INSERT_ELEMENT_AFTER
INSERT_ELEMENT_BEFORE
INSERT_ELEMENT_FIRST
INSERT_ELEMENT_LAST
REMOVE_FIRST_ELEMENT
REMOTE_LAST_ELEMENT
RETRIEVE_FIRST_ELEMENT
RETRIEVE_LAST_ELEMENT
CONCAT
APPEND

Между прочим, стоит заметить мимоходом, что ODMG не поддерживает генератор типа RELATION. Авторы The Object Database Standard: ODMG 2.0 утверждают, что "модель данных ODMG включает реляционную модель данных за счет наличия типа TABLE", но тип TABLE строго недостаточен во многих отношениях; в частности, отсутствуют многие из критических реляционных операций -- например, соединение. В связи с тем утверждением, что модель ODMG "включает реляционную модель" или "является более мощной", имеется много дополнительных проблем, но ограничения размера этой заметки не позволяют рассмотреть их здесь.

Далее, ODMG поддерживает язык запросов OQL - язык только для выборки (операции обновления отсутствуют), который в свободном стиле срисован с SQL. Более конкретно, OQL:

• Обеспечивает средства составления запросов в стиле SQL - SELECT-FROM-WHERE для множеств, мультимножеств, списков и массивов
• Обеспечивает аналоги конструкций SQL GROUP BY, HAVING и ORDER BY
• Поддерживает объединение, пересечение и вычитание, а также специальные операции для списков и массивов (например, "получить первый элемент")
• Поддерживает "выражения пути" (path expressions) для прохода по связям между объектами.

В The Object Dtabase Standard: ODMG 2.0 содержится ряд утверждений про OQL. Вот пара из них (в обоих случаях курсив добавлен К. Дейтом):

• "Там, где это возможно, в качестве основы OQL мы используем реляционный стандарт SQL, хотя OQL поддерживает более мощные возможности."
• "OQL обладает большей мощностью [чем реляционный язык запросов]."

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

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

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

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

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

Все эти проблемы прямо конфликтуют с Принципом Информации Кодда. Я уверен, что Кодд не случайно назвал его "фундаментальным принципом реляционной модели". Этот принцип можно сформулировать следующим образом: "Вся информация в базе данных должна быть явно представлена в терминах отношений и никак иначе". В своей книге The Relational Model for Database Management Version 2 (Addison-Wesley, 1997) Кодд приводит ряд аргументов в пользу поддержки этого принципа (аргументов, с которыми я, конечно, согласен). Как мы утверждаем в Третьем Манифесте, отношения являются необходимыми и достаточными для представления любых данных (на логическом уровне). Другими словами, мы должны иметь отношения и нам не требуется ничего, кроме отношений.

Так откуда же возникла идея POTT? Мне кажется, здесь мы имеем (как это часто случается) фундаментальную путаницу в понятиях модели и реализации. Более точно, было замечено, что некоторые SQL-продукты не слишком хорошо выполняют некоторые операции (в особенности соединения); на основе этого было сделано предположение, что эффективность была бы улучшена, если бы мы могли использовать, скажем, списки или массивы вместо отношений. Но в этой идее содержится серьезна путаница; в ней смешиваются логический и физический уровни. Никто не утвержает, что, например, списки не могли бы быть полезны на физическом уровне; вопрос в том, должны ли списки и тому подобное демонстрироваться на логическом уровне. И очень строгой позицией защитников реляционного подхода и, частности, авторов Третьего Манифеста является то, что ответом на этот вопрос является "нет".

Литература

1. Atkinson, Malkolm et al. "The Object-Oriented Dtabase System Manifesto". Proc. First International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan (1989). Elsevier Science, 1990.
2. Stonebraker, Michael et al. "Third Generation Database System Manifesto". ACM SIGMOD Record 19, No. 3. September, 1990.
3. Cattell, R.G.G. and Douglas K. Barry (eds.). The Object Database Standard: ODMG 2.0. Morgan Kaufmann, 1997.