До появления 10 лет назад ОРСУБД ведущих компаний термин «объектно-реляционная СУБД» связывался с системами Postges-Illustra и UniSQL, разработанными под руководством Майкла Стоунбрейкера и Вона Кима соответственно. Про первое направление уже достаточно говорилось выше, поскольку оно лежит в основе IUS. Повторим лишь, что до основания компании Illustra сам Стоунбрейкер не использовал этого термина. Например, в [9] говорилось, что в модели данных Postges сочетаются объектные и расширенные реляционные черты, но авторы не берутся присвоить ей какое-либо отдельное название.
С другой стороны, Вон Ким сразу стал называть СУБД UniSQL «единой реляционной и объектно-ориентированной системой баз данных» [10]. В соответствии с подходом UniSQL, в ОРСУБД должны поддерживаться следующие возможности [11]:
n-мерное объектно-ориентированное моделирование;
двухмерное реляционное моделирование;
наследование;
инкапсуляция;
постоянство существования объектов (object persistence);
композиция классов;
полиморфизм;
навигационный доступ к объектам;
реляционный доступ (соединения);
непроцедурный доступ через запросы;
интерфейсы для традиционных языков третьего поколения;
интерфейсы для объектных языков третьего поколения;
интерфейсы для языков четвертого поколения;
независимое от языков хранение данных;
независимость служб баз данных от файловых систем;
поддержка оперативных служб СУБД.
Как отмечалось в [11], единая модель данных UniSQL опирается на следующее наблюдение. Если взять объектно-ориентированную модель данных и удалить из нее понятия наследования и инкапсуляции, то останется сетевая модель данных*. Далее, если удалить из нее понятия указателей и коллекций, то останется реляционная модель данных. В этом наблюдении имеется доля разумного смысла с учетом недостаточной точности определения объектно-ориентированной модели данных. В следующем разделе будет обсуждаться подход к сочетанию реляционных и объектных свойств в модели данных, представленной в современном стандарте языка SQL, и я приведу собственную точку зрения по этому поводу.
Пожалуй, наиболее существенные различия в подходах Майкла Стоунбрейкера и Вона Кима состояли в выборе отправной точки для построения объектно-ориентированных систем баз данных и в акцентах, которые делались при выполнении этой работы. Стоунбрейкер двигался от реляционной модели данных и от собственных реализаций СУБД, основанных на этой модели. Для него было наиболее важно сохранить в объектно-реляционной системе возможности реляционных систем, добавив, по мере возможности, средства, свойственные объектным системам. Понятно, что этот подход оказался привлекательным для компаний, производивших SQL-ориентированные СУБД, поскольку позволял им наращивать функциональные возможности своих систем без потребности в их коренной перестройке.
Вон Ким до создания СУБД UniSQL, в частности, активно занимался проектированием и разработкой чисто объектно-ориентированных СУБД. Под его руководством было разработано семейство ООСУБД Orion [13]. Поэтому для него было естественно подходить к решению проблемы единой объектно-реляционной модели данных с позиций объектно-ориентированного мира. Как говорится в [10], ядро UniSQL проектировалось с целью полной поддержки надмножества базовой объектной модели (Core Object Model, COM) консорциума Object Management Group**. Реляционные свойства обеспечивались, фактически, путем специального использования объектных возможностей системы. По пути UniSQL впоследствии пошли многие компании, производившие не SQL-ориентированные (в частности, объектно-ориентированные) СУБД, для обеспечения поддержки языка SQL. Тем не менее, подход Вона Кима не оказал существенного влияния на «основной поток» ведущих коммерческих СУБД.
С методологической точки зрения на развитие основного объектно-реляционного подхода и соответствующих средств, специфицированных в стандарте языка SQL, важнейшее влияние оказал Манифест систем баз данных третьего поколения, опубликованный группой авторов под очевидным руководством Майкла Стоунбрейкера в 1990 г. [3]. В этом документе постулировались три основных принципа систем следующего поколения:
помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечивать поддержку более богатых структур объектов и правил;
СУБД третьего поколения должны включить в себя СУБД второго поколения;
СУБД третьего поколения должны быть открыты для других подсистем.
Эти принципы развивались в тринадцати технических предложениях, включающих обеспечение развитой системы типов с поддержкой наследования и инкапсуляции. Если внимательно посмотреть на стандарты SQL:1999 и SQL:2003 [1,2], а также на возможности современных версий СУБД DB2 и Oracle, то можно увидеть отражение в них всех принципов и предложений Манифеста систем баз данных третьего поколения. Другой вопрос, насколько эти принципы и предложения можно считать объектными? Мы обсудим этот вопрос в контексте языка SQL в следующем разделе.
5. ОРСУБД и стандарт языка SQL
В процессе стандартизации языка баз данных SQL можно выделить, по моему мнению, три основных этапа. Первый этап начался в середине 1980-х гг. и завершился принятием международного стандарта SQL/89, наиболее важным достижением которого явилась языковая спецификация базовых средств запросов и механизмов ссылочной целостности. Результатом второго этапа явилось принятие стандарта SQL/92, в котором были полностью специфицированы средства определения и эволюции схемы базы данных, поддержки ссылочной целостности, манипулирования данными, связывания SQL с языками программирования и ряд других возможностей, позволяющих использовать стандарт SQL для реализации полнофункциональной РСУБД.
С точки зрения основной темы данной статьи для нас основной интерес представляет третий этап, важным промежуточным финишем которого явилось появление стандарта SQL:1999, развитого и уточненного в стандарте SQL:2003. Сейчас (в феврале 2007 г.) трудно сказать, закончился ли этот этап и происходит ли новый этап, связанный с интеграцией в SQL средств управления XML-данными. Ответ на этот вопрос можно будет дать только после принятия следующего стандарта.
В этой статье в стандартах SQL:1999 и SQL:2003 (на которые далее я буду обобщенно ссылаться, как на стандарт SQL) меня, главным образом, интересуют система типов SQL, возможности определения типов пользователями и средства определения и использования так называемых типизированных таблиц (typed tables), составляющие, по мнению разработчиков стандарта, объектную модель SQL.
5.1 SQL как модель данных
Конечно, любой вариант стандарта языка SQL можно было трактовать как определение модели данных в соответствии с критериями Эдгара Кодда [16]. Для полноты картины напомню, что по Кодду модель данных представляет собой некий абстрактный эталон, которому должны соответствовать все реализации, претендующие на соответствие общей модели. В спецификации модели данных Кодд выделял структурную, целостную и манипуляционную составляющие, определяющие, соответственно:
структуры данных, которые могут существовать в базах данных, отвечающих модели;
базовые ограничения целостности, определение и поддержка которых должны обеспечиваться в системах баз данных, поддерживающих эту модель;
средства манипулирования данными, задающие критерий выразительной мощности любого конкретного языка баз данных, который может поддерживаться в соответствующих СУБД.
Для реляционной модели данных в структурной части модели говорится, что единственной «родовой» структурой данных является n-арное отношение, атрибуты которого содержат атомарные значения. В целостной части требуется поддержка целостности сущности (наличие у любого отношения хотя бы одного возможного ключа) и целостности ссылок (недопущение внешних ключей, содержащих не неопределенное значение, для которого отсутствует совпадающее с ним значение возможного ключа в отношении, в которое ведет ссылка). Наконец, в манипуляционной составляющей реляционной модели данных специфицировались эквивалентные механизмы реляционной алгебры и реляционного исчисления.
Достаточно очевидно, что
любой из перечисленных выше стандартов языка SQL определяет некоторую модель данных;
с появлением каждого следующего варианта стандарта языка SQL соответствующая модель данных дополняется и уточняется;
наконец (и это самое важное!), модель данных, определяемая языком SQL, никогда (!) не была и не является реляционной.
Действительно, начиная со стандарта SQL/89 было понятно, что SQL-ориентированная база данных состоит из таблиц, в столбцах которых могут содержаться данные типов, специфицированных в стандарте. Говорилось, что в таблицах могут определяться первичный и возможный ключи, и в этом случае СУБД должна поддерживать уникальность их значений. Некоторым образом требовалась поддержка ссылочной целостности. Наконец, в качестве «абстрактного» механизма манипулирования данными выступали средства самого языка SQL.
С другой стороны, только в стандарте SQL/92 были явно введены конструкции определения базовых таблиц, а тем самым, и возможности определения первичных и возможных ключей. Только в стандарте SQL:1999 был специфицирован полный набор параметризуемых, генерируемых и определяемых пользователями типов данных, значения которых могут присутствовать в столбцах таблиц SQL-ориентированных баз данных. По мере развития стандарта расширялись и уточнялись средства поддержки ссылочной целостности и манипулирования данными и т.д.
Наконец, начиная с SQL/89, определение хотя бы одного возможного ключа в таблице было необязательным, так что в таких таблицах могли присутствовать строки-дубликаты, они не являлись множествами строк; следовательно, они не были аналогами отношений реляционной модели данных. В заголовках таблиц присутствовал неявный порядок имен столбцов, следовательно, они не являлись аналогами заголовков отношений реляционной модели данных. В столбцах таблиц, наряду с типизированными значениями, могли храниться нетипизированные неопределенные значения, вызывающие необходимость в использовании трехзначной логики и приводящие к иногда парадоксальным ситуациям [17].
Трактовка стандарта SQL как спецификации некоторой особой модели данных (модели данных SQL) стала действительно актуальной после появления стандарта SQL:1999. До этого достаточно было говорить, что язык SQL во многом следует реляционной модели данных, но с некоторыми отклонениями, которые следует иметь в виду. Однако появление «объектных расширений» в SQL:1999 («объектность» этих расширений мы обсудим в следующем подразделе), в особенности, полной системы типов, во-первых, делает законченной собственную модель SQL, во-вторых, еще больше отдаляет модель SQL от классической реляционной модели данных Кодда и, в третьих, создает потребность в сопоставлении модели SQL с объектной моделью ODMG [15] и «истинно реляционной» моделью Кристофера Дейта и Хью Дарвена [18]*.
Понимание отличий модели данных SQL от реляционной модели данных очень важно для проектировщиков, администраторов и разработчиков приложений SQL-ориентированных баз данных. Похоже, что сегодняшняя модель данных SQL включает классическую реляционную модель данных [16], хотя расходится в части механизма типов данных с «истинно реляционной» моделью [18]. Очевидным преимуществом классической реляционной модели данных является ее собственная простота и следующая из нее простота баз данных и их приложений. Поэтому при использовании SQL нужно явно отдавать себе отчет в реальной потребности использования возможностей, выходящих за пределы классической реляционной модели данных.
5.2 Объектная подмодель SQL
В самом стандарте языка SQL, естественно, вообще ничего не говорится о моделях данных. Однако главный редактор стандарта SQL Джим Мелтон в [1] утверждает, что объектная подмодель SQL включает два основных отличительных набора механизмов: средства определения и использования структурных типов данных (User Defined Type – UDT ) и типизированных таблиц (typed table).
Первый компонент позволяет определять новые типы данных, которые могут быть гораздо более сложными, чем встроенные типы данных языка SQL. При определении структурного UDT требуется специфицировать не только содержащиеся в нем элементы данных, но и семантику типа данных, т.е. его поведение на основе интерфейса вызовов методов. UDT являются полностью инкапсулированными. Доступ к значениями UDT возможен только через методы этого типа.
Для каждого атрибута UDT автоматически определяются два метода: наблюдатель (observer) и мутатор (mutator). Метод-наблюдатель применятся к значению UDT и возвращает значение соответствующего атрибута этого структурного значения. Метод-мутатор действует над местоположением (столбцом строки некоторой таблицы, переменной или параметром) значения UDT и заменяет это структурное значение новым значением с указанным значением соответствующего атрибута. Синтаксические правила вызова методов-наблюдателя и мутатора таковы, что позволяют манипулировать с атрибутами значений UDT в привычной «точечной» нотации.
Для определения структурных UDT поддерживается механизм одиночного наследования. При определении подтипа можно добавлять к структуре супертипа новые атрибуты, специфицировать новые методы или изменять реализацию методов супертипа (с сохранением сигнатуры). Соответственно, поддерживаются полиморфизм по включению (значение любого UDT является значением любого своего супертипа) и отложенное связывание.
Второй компонент – типизированные таблицы – позволяет определять таблицы, строки которых являются экземплярами (или значениями) UDT , с которым явно ассоциируется таблица. При определении типизированной таблицы можно объявить ее подтаблицей некоторой другой типизированной таблицы. Супертаблица должна быть ассоциирована со структурным типом, являющимся непосредственным супертипом определяемой подтаблицы. Каждый столбец указанной супертаблицы наследуется подтаблицей; наследуются и характеристики столбцов супертаблицы – значения по умолчанию, ограничения целостности и т.д. Эти столбцы называются унаследованными столбцами подтаблицы, и они соответствуют атрибутам UDT подтаблицы, унаследованным от UDT супертаблицы. Кроме того, подтаблица будет содержать по одному столбцу для каждого собственного атрибута ассоциированного структурного типа. Такие столбцы подтаблицы называются заново определенными.
В определении максимальной супертаблицы (не являющейся подтаблицей какой-либо другой супертаблицы) должна присутствовать спецификация «самоссылающегося» (self -referencing ) столбца, и самоссылающийся столбец, определенный в максимальной супертаблице, наследуется любой ее подтаблицей. Эта спецификация не может входить в определение подтаблицы. Значения самоссылающегося столбца относятся к ссылочному типу, ассоциированному с UDT, на котором определена данная типизированная таблица. Значения ссылочного типа, или ссылочные значения могут генерироваться одним из трех способов (указываемых при определении UDT):
задаваться приложением как значения некоторого встроенного типа SQL каждый раз при сохранении экземпляра структурного типа как строки типизированной таблицы;
порождаться из одного или нескольких атрибутов UDT;
автоматически генерироваться системой.
Любой ссылочный тип можно использовать для объявления типа любого местоположения, в том числе, столбца другой типизированной или обычной таблицы. Поскольку любое действующее ссылочное значение является уникальным идентификатором соответствующей строки типизированной таблицы, в объектной подмодели SQL оно считается аналогом объектного идентификатора в обычных объектных моделях (в частности, в модели ODMG), и в SQL-запросах можно использовать «стрелочную» нотацию для перехода от одного «объекта» к другому по ссылочному значению. При использовании этой возможности SQL-запросы почти неотличимы синтаксически от запросов на языке OQL [15].
Эта синтаксическая близость может привести к впечатлению о близости самих объектных моделей SQL и ODMG. Обманчивость этого впечатления обосновывается в [20]. Я не буду говорить об этом в данной статье, хотя некоторые утверждения в [20] уже кажутся мне слишком категоричными. Но здесь мне хочется затронуть другой вопрос: насколько гармонирует объектная подмодель SQL с общей моделью данных SQL?
Заметим, что средства определения структурных UDT можно считать частью стандарта SQL, относящегося к системе типов данных. В стандарте SQL поддерживаются
При определении типа коллекции можно использовать любой тип элементов, включая типы коллекций и UDT. Элементы анонимных строчных типов и атрибуты структурных UDT могут также иметь любой тип данных. Для значений любого типа данных определена операция сравнения по равенству, так что с точки зрения модели данных SQL осмысленными являются столбцы, определенные на любом типе данных (по крайней мере, работают наиболее важные в модели SQL, как и в реляционной модели, операции экви- и естественного соединения). Так что система типов SQL вполне гармонична модели данных SQL. Более того, я не стал бы считать, что в системе типов SQL имеются «объектные расширения»: подобные средства свойственны любому полнотиповому языку, не обязательно объектно-ориентированному.
Вообще говоря, нет ничего особенно «объектного» и в типизированных таблицах. По сути дела, объявляется таблица с двумя столбцами, один из которых определен на структурном UDT, а другой содержит уникальные идентификаторы (суррогатные, если они генерируются системой). По сути дела, «объектность» в стандарте SQL появляется, когда мы начинаем считать строки типизированной таблицы объектами, а идентификаторы этих строк объектными идентификаторами. В этом случае на свет выходит «стрелочная нотация», заменяющая эквисоединения. Но мы должны отдавать себе отчет, что это всего лишь синтаксическая замена: чтобы добраться от строки одной таблицы до строки другой таблицы по ссылочному значению, требуется, чтобы это ссылочное значение хранилось в обеих строках, т.е. переход от одной строки к другой делается, фактически, путем эквисоединения.
Таким образом, «объектные расширения» SQL не выводят язык за пределы общей модели SQL. При этом обеспечиваются функциональные возможности, которые специалисты из объектного мира считают «объектными» (см., например, разд. 4 относительно подхода Вона Кима к организации UniSQL).
6. Проблемы и перспективы ОРСУБД
Как отмечалось во введении, в последние годы про ОРСУБД говорят и пишут очень мало. Я обсуждал вопросы использования расширенных возможностей SQL со многими разработчиками приложений, администраторами баз данных, сотрудниками ведущих компаний-производителей СУБД и пришел к следующим выводам.
Для большинства практических разработчиков приложений расширенные возможности SQL ограничиваются средствами серверного программирования с использованием хранимых процедур и функций. Мне не удалось найти пример недавно созданного независимыми разработчиками приложения баз данных, для которого в базе данных определялся бы специальный структурный UDT. Тем более, мне неизвестны базы данных, содержащие типизированные таблицы.
Казалось бы, естественно использовать расширенные возможности ОРСУБД самими компаниями, производящими эти системы, для включения в них новых функциональных возможностей (как это и происходило 10 лет назад). Однако и таких примеров крайне мало. Например, я был очень обрадован, узнав, что специалисты компании Oracle воспользовались объектными расширениями SQL для реализации в Oracle 10g функциональных возможностей управления многомерными данными, которые ранее поддерживались отдельным продуктом Oracle Express Server [21].
Почему же пользователи ОРСУБД и разработчики приложений пренебрегают развитыми средствами, которые обеспечиваются в этих системах? Можно было бы подумать, что людей из «реляционного» мира SQL отпугивают новые «объектные» возможности. Но в разд. 5 мы видели, что «объектные» расширения SQL совсем не являются объектными и не меняют модель данных SQL. Похоже, что причина кроется совсем в другом, а именно, в излишне обширном наборе возможностей.
Расширенные возможности SQL, в особенности, средства серверного программирования, обеспечивающие возможности определения UDT, хранимых процедур и функций, триггеров и т.д. позволяют переносить на сервер баз данных все большую часть логики приложений. Это в значительной степени противоречит учению Эвгара Кодда, в котором обосновывалась целесообразность независимости базы данных от приложений. Независимость базы данных от приложений часто выглядит очень привлекательной идеей, но для ее применения разумно отказаться от многих расширений SQL.
Кроме того, даже если не принимать во внимание упомянутую идеи, при проектировании приложения базы данных имеется три альтернативы: можно реализовать логику приложения на стороне клиента, на сервере приложений и на сервере баз данных. Очевидно, что каждая альтернатива имеет право на жизнь, и каждая из них может оказаться выигрышной в конкретной ситуации. Однако отсутствует методология, не говоря уже про технологию, выбора наиболее выгодного проектного решения. Для расширения области использования ОРСУБД требуются дополнительные исследования и разработки в этом направлении.
Другой проблемой, не связанной с возможностями серверной реализации логики приложений, является использование в базах данных типов коллекций. Поддержка в стандарте SQL типов мультимножеств, элементами которых могут быть значения анонимных строчных типов, обеспечивает теперь возможность определения вложенных таблиц с произвольным (теоретически, неограниченным) уровнем вложенности. Поскольку все значения, хранимые в базе данных, продолжают оставаться строго типизированными, такая возможность не противоречит базовому требованию первой нормальной формы, унаследованному из реляционной модели данных, но, по существу, обеспечивает подход к прямому моделированию иерархических структур.
Разработчики приложений баз данных в течение многих лет порицали SQL за отсутствие прямой поддержки иерархий. Теперь эта возможность появилась и многих поставила в тупик. В каких случаях действительно выгодно пользоваться вложенными таблицами? Нужно ли разработчикам приложений понимать, что на уровне хранения данных в реализации SQL-ориентированных СУБД, скорее всего, физическая вложенность поддерживаться не будет? В действительности, проблема выбора способа представления иерархических данных свойственна не только современному SQL, аналогичные проблемы возникают, например, и при проектировании баз XML-данных. Здесь тоже требуются исследования с целью выработки обоснованных рекомендаций и методологий проектирования*.
Другими словами, аскетичность подхода Кодда, выраженная в классической реляционной модели данных, оказывается пока понятнее и полезнее богатства современной модели данных SQL (думаю, что это равно применимо к объектной модели ODMG и «истинно реляционной» модели Дейта и Дарвена). Для полноценного использования этого богатства требуются понятные и обоснованные методологии.
Я думаю, что накопленный за 10 лет багаж объектных расширений, специфицированных в стандарте SQL и реализованных в передовых продуктах компаний IBM и Oracle, не должен бесславно пропасть. Это было бы нерационально, учитывая громадный объем человеческого труда, затраченного за создание этих расширений. Мне хочется надеяться, что с помощью исследовательского сообщества баз данных удастся решить упомянутые выше и другие проблемы и привлечь разработчиков к полноценному использованию возможностей ОРСУБД.
7. Заключение
Появление объектно-реляционного подхода к организации баз данных и СУБД явилось важным шагом на пути развития технологии баз данных. За 10 лет, прошедших с момента выхода первой коммерческой ОРСУБД, объектно-реляционный подход, с одной стороны, приобрел зрелость, утвердился в спецификациях стандарта SQL, но, с другой стороны, так и завоевал широкого распространения среди разработчиков приложений баз данных.
В этой статье, посвященной юбилею ОРСУБД, были обсуждены история подхода, его современное состояние и проблемы, препятствующие его широкому использованию
* Модель данных COM лежала в основе архитектуры CORBA и являлась в начале 1990-х гг. единственной объектной моделью данных, для которой существовала независимая от производителей спецификация. Впоследствии на модели COM во многом основывалась стандартная объектная модель данных ODMG (Object Data Management Group) [15].
* Замечу, что некоторое сопоставление этих моделей делается в [18] и вышедшем в 2006 г. новым изданием этой книги [19]. Однако авторы этих книг не трактуют стандарт SQL как модель данных и вообще относятся к SQL подчеркнуто и категорически отрицательно. Поэтому, с моей точки зрения, сравнения, приводимые в [18, 19] не вполне объективны. Так что потребность в объективном сопоставлении понятий, возможностей и недостатков этих трех моделей данных остается.
* В этом списке умышленно отсутствует тип данных XML, поскольку соответствующие аспекты языка SQL в данной статье не рассматривается.
* Замечу, что здесь не могут выручить средства концептуального моделирования баз данных, такие как E/R-диаграммы или диаграммы классов UML, поскольку в них также допускаются различные альтернативы моделирования иерархических данных.
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
