Сущность объектно-реляционного подхода к организации баз данных

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Введение

Эпоха объектно-реляционных баз данных началась десять лет назад, когда в декабре 1996 года компания Informix выпустила объектно-реляционную систему управления базами данных (ОРСУБД) Informix Universal Server. Вслед за ней в 1997 г. на рынке появились ОРСУБД компаний Oracle (Oracle8) и IBM (DB2 Universal Database). В течение примерно трех лет новая технология интенсивно обсуждалась. Многим (включая меня) в то время казалось, что ОРСУБД в корне изменят способы проектирования и разработки приложений баз данных.

Однако постепенно шум вокруг ОРСУБД затих. До конца 1990-х гг. Informix, Oracle и IBM совершенствовали свои ОРСУБД. В 1999 г. появился стандарт SQL:1999 , в котором были зафиксированы объектные расширения языка SQL. И, наконец, после выхода в 2003 г. стандарта SQL:2003 , уточнившего и дополнившего SQL:1999, в сообществе баз данных окончательно перестали обсуждать объектно-реляционную технологию баз данных.

Что это означает? Оказалось ли дитя мертворожденным? Или же наш мир еще не готов к приходу нового мессии? Я не знаю, многих ли в мире сейчас это волнует, но мне кажется, что тема заслуживает обсуждения. Слишком много материальных и интеллектуальных ресурсов затратило человечество на разработку ОРСУБД, чтобы можно было позволить себе о них забыть. Слишком много полезных возможностей кроется в объектно-реляционном подходе, чтобы проектировщики и разработчики приложений баз данных могли с чистой совестью им пренебрегать.

В этой статье я хочу, прежде всего, обсудить общее понятие объектно-реляционных баз данных. Затем я коротко проанализирую основные черты и различия первых версий ОРСУБД компаний Informix, Oracle и IBM. Далее мы обсудим (снова очень кратко) предпосылки появления ОРСУБД. В следующем разделе части статьи будут рассмотрены наиболее важные аспекты языка SQL, имеющие отношение к организации объектно-реляционных баз данных и управлению ими. Моя позиция состоит в том, что на сегодняшний день в стандарте языка SQL зафиксирована некоторая законченная модель данных, во многих отношениях близкая к реляционной модели данных, но в целом существенно от нее отличающаяся. Разработчики стандарта SQL выделяют «объектную» подмодель данных. Интересным вопросом является то, насколько эта подмодель гармонична общей модели языка. Наконец, мы рассмотрим, как реально используются ОРСУБД в настоящее время, и что препятствует их более широкому использованию. В действительности, по моему мнению, имеется несколько проблем, от решения которых зависит будущее ОРСУБД. Хочется надеяться, что эти проблемы удастся решить.

1. Понятие объектно-реляционных баз данных

Термин объектно-реляционные базы данных стал известен широким массам разработчиков и пользователей систем баз данных после выпуска компанией Informix в конце 1996 г. своего нового продукта Informix Universal Server (IUS). Компания Informix смогла быстро разработать IUS благодаря приобретению компании Illustra и переходу на работу в Informix ее основателя Майкла Стоунбрейкера. По сути дела, IUS был получен в результате «скрещивания» основного серверного продукта Informix Dynamic Server и СУБД Illustra.

В свою очередь, компания Illustra была основана, в основном, с целью коммерциализации известной СУБД Postgres, разработанной под руководством Майкла Стоунбрейкера в Калифорнийском университете в г. Беркли. (На основе Postgres позднее была создана СУБД PostrgreSQL, являющаяся в настоящее время одной из наиболее популярных СУБД категории Open Source.) Как известно, проект Postgres во многом представлял собой продолжение с использованием ряда новых идей (развитая система правил, поддержка темпоральных данных и т.д.) раннего проекта Майкла Стоубрейкера Ingres.

Уже в Ingres можно было заметить некоторые черты, которые в наше время многими принято относить к числу объектных (в частности, зачаточные возможности определения пользователями новых типов данных). Однако Стоунбрейкер не называл ни Ingres, ни Postgres объектно-реляционными системами. По отношению к Postgres он использовал эпитет «СУБД следующего поколения». Стоунбрейкер начал называть ОРСУБД только систему Illustra, которая, по сути, отличалась от Postgres только поддержкой языка SQL.

Тем самым, исторически IUS стало возможно именовать объектно-реляционной СУБД именно по той причине, что эта система основывалась на Illustra, которая уже называлась объектно-реляционной. Однако значит ли это, что IUS можно считать некоторой эталонной моделью ОРСУБД, а Майкла Стоунбрейкера - отцом этого термина и направления в целом? С моей точки зрения, это было бы неверно. Во-первых, у объектно-реляционного подхода имеются и другие предпосылки. Во-вторых в IUS имелись некоторые особенности (большей частью, весьма полезные), которые делают эту систему не слишком пригодной в качестве эталонной модели.

Так что же такое ОРСУБД? Что такое объектно-реляционная база данных? Если не зафиксировать какое-либо конкретное понимание этих терминов, то, очевидно, рассуждения на их тему становятся бессмысленными. Заметим, что банальное житейское толкование термина ОРСУБД как традиционной реляционной СУБД, расширенной основными объектными возможностями, является опасно упрощенным и искажающим действительность. Во-первых, имеющиеся сегодня на рынке ОРСУБД не являются «традиционными реляционными», поскольку в них не поддерживается реляционная модель данных. Они основаны на другой модели данных, представленной в стандарте языка SQL. Во-вторых, объектный мир определен в целом настолько расплывчато и нечетко, что невозможно однозначно говорить об основных объектных возможностях.

С моей точки зрения, сегодня под ОРСУБД следует понимать системы, которые следуют духу Манифеста систем баз данных третьего поколения и букве стандартов SQL:1999 и SQL:2003. В качестве примеров реализаций ОРСУБД можно использовать Oracle (начиная с Oracle 9i) и IBM DB2 (начиная с версии 7).

2. Коротко о предпосылках ОРСУБД

До появления 10 лет назад ОРСУБД ведущих компаний термин «объектно-реляционная СУБД» связывался с системами Postges-Illustra и UniSQL, разработанными под руководством Майкла Стоунбрейкера и Вона Кима соответственно. Про первое направление уже достаточно говорилось выше, поскольку оно лежит в основе IUS. Повторим лишь, что до основания компании Illustra сам Стоунбрейкер не использовал этого термина. Например, в говорилось, что в модели данных Postges сочетаются объектные и расширенные реляционные черты, но авторы не берутся присвоить ей какое-либо отдельное название.

С другой стороны, Вон Ким сразу стал называть СУБД UniSQL «единой реляционной и объектно-ориентированной системой баз данных». В соответствии с подходом UniSQL, в ОРСУБД должны поддерживаться следующие возможности:

· n-мерное объектно-ориентированное моделирование;

· двухмерное реляционное моделирование;

· наследование;

· инкапсуляция;

· постоянство существования объектов (object persistence);

· композиция классов;

· полиморфизм;

· навигационный доступ к объектам;

· реляционный доступ (соединения);

· непроцедурный доступ через запросы;

· интерфейсы для традиционных языков третьего поколения;

· интерфейсы для объектных языков третьего поколения;

· интерфейсы для языков четвертого поколения;

· независимое от языков хранение данных;

· независимость служб баз данных от файловых систем;

· поддержка оперативных служб СУБД.

Единая модель данных UniSQL опирается на следующее наблюдение. Если взять объектно-ориентированную модель данных и удалить из нее понятия наследования и инкапсуляции, то останется сетевая модель данных*. Далее, если удалить из нее понятия указателей и коллекций, то останется реляционная модель данных. В этом наблюдении имеется доля разумного смысла с учетом недостаточной точности определения объектно-ориентированной модели данных. В следующем разделе будет обсуждаться подход к сочетанию реляционных и объектных свойств в модели данных, представленной в современном стандарте языка SQL, и я приведу собственную точку зрения по этому поводу.

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

Вон Ким до создания СУБД UniSQL, в частности, активно занимался проектированием и разработкой чисто объектно-ориентированных СУБД. Под его руководством было разработано семейство ООСУБД Orion . Поэтому для него было естественно подходить к решению проблемы единой объектно-реляционной модели данных с позиций объектно-ориентированного мира. Как говорится в , ядро UniSQL проектировалось с целью полной поддержки надмножества базовой объектной модели (Core Object Model, COM) консорциума Object Management Group**. Реляционные свойства обеспечивались, фактически, путем специального использования объектных возможностей системы. По пути UniSQL впоследствии пошли многие компании, производившие не SQL-ориентированные (в частности, объектно-ориентированные) СУБД, для обеспечения поддержки языка SQL. Тем не менее, подход Вона Кима не оказал существенного влияния на «основной поток» ведущих коммерческих СУБД.

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

· помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечивать поддержку более богатых структур объектов и правил;

· СУБД третьего поколения должны включить в себя СУБД второго поколения;

· СУБД третьего поколения должны быть открыты для других подсистем.

Эти принципы развивались в тринадцати технических предложениях, включающих обеспечение развитой системы типов с поддержкой наследования и инкапсуляции. Если внимательно посмотреть на стандарты SQL:1999 и SQL:2003 , а также на возможности современных версий СУБД DB2 и Oracle, то можно увидеть отражение в них всех принципов и предложений Манифеста систем баз данных третьего поколения. Другой вопрос, насколько эти принципы и предложения можно считать объектными? Мы обсудим этот вопрос в контексте языка SQL в следующем разделе.

3. ОРСУБД и стандарт языка 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.

SQL как модель данных.

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

· структуры данных, которые могут существовать в базах данных, отвечающих модели;

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

· средства манипулирования данными, задающие критерий выразительной мощности любого конкретного языка баз данных, который может поддерживаться в соответствующих СУБД.

Для реляционной модели данных в структурной части модели говорится, что единственной «родовой» структурой данных является n-арное отношение, атрибуты которого содержат атомарные значения. В целостной части требуется поддержка целостности сущности (наличие у любого отношения хотя бы одного возможного ключа) и целостности ссылок (недопущение внешних ключей, содержащих не неопределенное значение, для которого отсутствует совпадающее с ним значение возможного ключа в отношении, в которое ведет ссылка). Наконец, в манипуляционной составляющей реляционной модели данных специфицировались эквивалентные механизмы реляционной алгебры и реляционного исчисления.

Достаточно очевидно, что:

· любой из перечисленных выше стандартов языка SQL определяет некоторую модель данных;

· с появлением каждого следующего варианта стандарта языка SQL соответствующая модель данных дополняется и уточняется;

· наконец (и это самое важное!), модель данных, определяемая языком SQL, никогда (!) не была и не является реляционной.

Действительно, начиная со стандарта SQL/89 было понятно, что SQL-ориентированная база данных состоит из таблиц, в столбцах которых могут содержаться данные типов, специфицированных в стандарте. Говорилось, что в таблицах могут определяться первичный и возможный ключи, и в этом случае СУБД должна поддерживать уникальность их значений. Некоторым образом требовалась поддержка ссылочной целостности. Наконец, в качестве «абстрактного» механизма манипулирования данными выступали средства самого языка SQL.

С другой стороны, только в стандарте SQL/92 были явно введены конструкции определения базовых таблиц, а тем самым, и возможности определения первичных и возможных ключей. Только в стандарте SQL:1999 был специфицирован полный набор параметризуемых, генерируемых и определяемых пользователями типов данных, значения которых могут присутствовать в столбцах таблиц SQL-ориентированных баз данных. По мере развития стандарта расширялись и уточнялись средства поддержки ссылочной целостности и манипулирования данными и т.д.

Наконец, начиная с SQL/89, определение хотя бы одного возможного ключа в таблице было необязательным, так что в таких таблицах могли присутствовать строки-дубликаты, они не являлись множествами строк; следовательно, они не были аналогами отношений реляционной модели данных. В заголовках таблиц присутствовал неявный порядок имен столбцов, следовательно, они не являлись аналогами заголовков отношений реляционной модели данных. В столбцах таблиц, наряду с типизированными значениями, могли храниться нетипизированные неопределенные значения, вызывающие необходимость в использовании трехзначной логики и приводящие к иногда парадоксальным ситуациям.

Трактовка стандарта SQL как спецификации некоторой особой модели данных (модели данных SQL) стала действительно актуальной после появления стандарта SQL:1999. До этого достаточно было говорить, что язык SQL во многом следует реляционной модели данных, но с некоторыми отклонениями, которые следует иметь в виду. Однако появление «объектных расширений» в SQL:1999 («объектность» этих расширений мы обсудим в следующем подразделе), в особенности, полной системы типов, во-первых, делает законченной собственную модель SQL, во-вторых, еще больше отдаляет модель SQL от классической реляционной модели данных Кодда и, в третьих, создает потребность в сопоставлении модели SQL с объектной моделью ODMG и «истинно реляционной» моделью Кристофера Дейта и Хью Дарвена .

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

4. Проблемы и перспективы ОРСУБД

инкапсуляция реляционный интерфейс полиморфизм

Как отмечалось во введении, в последние годы про ОРСУБД говорят и пишут очень мало. Я обсуждал вопросы использования расширенных возможностей SQL со многими разработчиками приложений, администраторами баз данных, сотрудниками ведущих компаний-производителей СУБД и пришел к следующим выводам.

Для большинства практических разработчиков приложений расширенные возможности SQL ограничиваются средствами серверного программирования с использованием хранимых процедур и функций. Мне не удалось найти пример недавно созданного независимыми разработчиками приложения баз данных, для которого в базе данных определялся бы специальный структурный UDT. Тем более, мне неизвестны базы данных, содержащие типизированные таблицы.

Казалось бы, естественно использовать расширенные возможности ОРСУБД самими компаниями, производящими эти системы, для включения в них новых функциональных возможностей (как это и происходило 10 лет назад). Однако и таких примеров крайне мало. Например, я был очень обрадован, узнав, что специалисты компании Oracle воспользовались объектными расширениями SQL для реализации в Oracle 10g функциональных возможностей управления многомерными данными, которые ранее поддерживались отдельным продуктом Oracle Express Server .

Почему же пользователи ОРСУБД и разработчики приложений пренебрегают развитыми средствами, которые обеспечиваются в этих системах? Можно было бы подумать, что людей из «реляционного» мира SQL отпугивают новые «объектные» возможности. Но в разд. 5 мы видели, что «объектные» расширения SQL совсем не являются объектными и не меняют модель данных SQL. Похоже, что причина кроется совсем в другом, а именно, в излишне обширном наборе возможностей.

Расширенные возможности SQL, в особенности, средства серверного программирования, обеспечивающие возможности определения UDT, хранимых процедур и функций, триггеров и т.д. позволяют переносить на сервер баз данных все большую часть логики приложений. Это в значительной степени противоречит учению Эвгара Кодда, в котором обосновывалась целесообразность независимости базы данных от приложений. Независимость базы данных от приложений часто выглядит очень привлекательной идеей, но для ее применения разумно отказаться от многих расширений SQL.

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

Заключение

Появление объектно-реляционного подхода к организации баз данных и СУБД явилось важным шагом на пути развития технологии баз данных. За 10 лет, прошедших с момента выхода первой коммерческой ОРСУБД, объектно-реляционный подход, с одной стороны, приобрел зрелость, утвердился в спецификациях стандарта SQL, но, с другой стороны, так и не завоевал широкого распространения среди разработчиков приложений баз данных.

Литература

1. Сергей Кузнецов. Наиболее интересные новшества в стандарте SQL:2003, 2004.

2. А. Грачев. Объектно-реляционная СУБД Informix Universal Server. СУБД, N 1-2, 1998.

3. В. Пржиялковский. Новые одежды знакомых СУБД: Объектная реальность, данная нам. СУБД, No. 2, 1995.

Размещено на Allbest.ru