Появление реляционных систем управления базами данных представляло значительный прогресс в технологии управления базами данных. Эти системы оказались очень успешными при обработке данных для определенного класса приложений, но из-за требования нормализации и скудного репертуара поддерживаемых типов данных, они оказались неудобными для приложений, которые манипулируют данными более сложной структуры. Существо проблемы в том, что для представления данных сложной структуры из-за вышеупомянутых причин приходится создавать много отношений, в результате чего от пользователя ускользает семантика данных. Некоторые типы данных трудно представить в реляционном виде. Указанные недостатки привели к созданию объектно-ориентированных систем управления базами данных. Объектно-ориентированная модель данных поднимает уровень абстракции и позволяет пользователю манипулировать более естественными сущностями реального мира, а не записями, полями, кортежами.
Как естественное следствие появления поколения систем управления базами данных, основанных на объектно-ориентированной модели, возникает желание пользователей использовать преимущества этих систем для работы с уже существующими данными.
Похожая проблема возникает и в неоднородных системах ([13, 14, 16, 18, 19]), которые содержат различные типы систем управления базами данных. Возникают многие трудности для пользователей, если они хотят оперировать данными, хранимыми в системах с разными моделями данных и языками запросов. Поэтому в неоднородных системах должны существовать механизмы преодоления этих трудностей.
В принципе, существуют три подхода к применению объектно-ориентированной технологии для реляционных баз данных: создание объектно-ориентированного интерфейса над реляционной системой управления базами данных, миграция в объектно-реляционные системы управления базами данных ([22]), конверсия реляционной базы данных в объектно-ориентированную. Какой из этих подходов применить, зависит от конкретной ситуации.
Первый подход часто применяется в неоднородных системах. В нем используется реляционная база данных и создается объектно-ориентированный интерфейс над ней (см. например [23]). При этом подходе нет миграции данных и нет потери семантики. Но с другой стороны, эффективность использования такой системы сильно снижается из-за различий между двумя парадигмами. При втором подходе ответственность за выполнение миграции данных несет система управления базами данных (например, Oracle 7 в Oracle 8), и объектно-ориентрованные концепты могут использоваться только в случае расширения или модификации схемы. Третьим подходом является полная семантическая конверсия существующей реляционной базы данных в объектно-ориентированную. В данной работе рассматриваются вопросы, связанные с третьим подходом.
Процесс конверсии базы данных из одной модели в другую можно разделить на две фазы ([1, 29]): трансформация схемы базы данных из одной модели в другую, конверсия данных в соответствии с трансформацией схемы.
При конверсии приложений, работающих с базой данных, основанной на одной модели, в приложения, работающие с базой данных, основанной на другой модели, возникают разные проблемы, одной из которых является трансляция запросов.
Цель работы состоит в изучении проблем, связанных с процессом конверсии реляционной базы данных в объектно-ориентированную и в построении алгоритмов, которые автоматически, т. е. без вмешательства пользователя, выполняют этот процесс и соответствующую трансляцию SQL-запросов в объектно-ориентированные запросы. В работе предлагаются алгоритмы трансформации схемы, два алгоритма конверсии данных и алгоритмы трансляции SELECT-, DELETE-, INSERTи UPDATE-запросов.
Для задачи конверсии реляционной базы данных в объектно-ориентированную весьма важен выбор исходной реляционной и целевой объектно-ориентированной модели. Существует много реляционных моделей (базовая модель Кодда, RM/2, RM/T, SQL-89, SQL-92, дополнения к SQL-92,. [24, 26, 27, 2, 7, 10, 17]) и объектно-ориентированных моделей (OMG, ODMG, С++, SmallTalk,. [7, 8, 32, 15]). Каждая модель из этих двух семейств обладает некоторыми особенностями, преимуществами и недостатками по отношению к другим моделям из своего семейства. Чем более богатыми модели являются, т. е. чем больше концептов они содержат, тем больше существует дополнительных возможностей отображения базы данных из одной модели в другую (см. например [9, 11], где используется концепт зависимости по включению). Использование каждой дополнительной возможности может существенно усложнить задачу конверсии. Кроме того, дополнительные возможности иногда не приносят никакой существенной пользы, а иногда делают совсем невозможной автоматизацию всего процесса конверсии. Нашей целью является теоретическое исследование и иллюстрация реальной возможности автоматического проведения процесса конверсии реляционной базы данных в объектно-ориентированную, а также соответствующей трансляции запросов, вместе с изучением связей между фазами этого процесса.
По всем этим причинам в работе используются только те наборы существенных базовых концептов, которые определяют принадлежность некоторой модели данных к семейству реляционных или объектно-ориентированных моделей.
С реляционной стороны, в работе используется базовые реляционные концепты — отношение, атрибуты, внешние и возможные ключи, и т. п. (см. п. 1). Что же касается языка запросов, для SELECT-, DELETE-, INSERTи UPDATE-запросов используются соответствующие конструкции языка SQL в рамках стандарта SQL-92.
С объектно-ориентированной стороны в работе рассматривается так называемое ядро объектно-ориентированной модели (см. п. 2, [8]). Ядро объектно-ориентированной модели — это множество концептов, которые приняты большинством исследователей и которые являются фундаментально важными концептами моделирования данных. Ядро включает следующие концепты: объект и объектный идентификатор, атрибуты, методы и передача сообщений, инкапсуляция, класс, а также иерархия классов и наследование. Практически все существующие объектно-ориентированные модели данных поддерживают тем или иным образом концепты ядра и добавляют некоторое число вариаций на конкретные интерпретации этих концептов. Концепты ядра не изменяются, так как ядро является относительно малым множеством фундаментальных и простых концептов. В качестве языка запросов объектно-ориентированной модели в данной работе принимается язык, описанный в п. 2.3 (см. 5]), так как он достаточно хорошо использует концепт выражения пути, который является важным свойством объектно-ориентированной модели. В данной работе реляционные SQL-запросы без выражений пути транслируются в запросы объектно-ориентированной системы, которые содержат выражения пути.
Так как практически все существующие реляционные и объектно-ориентированные модели данных поддерживают тем или иным образом концепты, использованные в работе, перенос предложенных в работе алгоритмов на другие модели не потребует значительных усилий. При конкретном применении предложенных алгоритмов, можно учитывать все особенности и дополнительные возможности конкретных моделей и, если это окажется полезным, дополнять предложенные алгоритмы.
При вышеуказанных ограничениях в работе комплексно исследована проблема конверсии реляционной базы данных в объектно-ориентированную базу вместе с трансляцией запросов и рассмотрены связи между фазами этого процесса.
В работе построен алгоритм трансформации схемы реляционной базы данных в объектно-ориентированную, который автоматически (в отличие от, например, [20, 30]) анализирует семантику схемы реляционной базы данных и трансформирует ее в объектно-ориентированную без помощи пользователя. В этом алгоритме отношения отображаются в классы, а связи между классами идентифицируются с помощью взаимосвязей возможных и внешних ключей. При наличии других концептов как в реляционной так и в объектно-ориентированной модели данных возможны и другие способы отображения. Отношения можно непосредственно отображать в классы (см. например [21]), но при этом теряется семантика реляционной базы данных. Целью предложенного в работе алгоритма является получение из реляционной схемы тех объектно-ориентированных концептов, которые адекватны действительной семантике базы данных (в отличие от [28, 31] где полученная объектно-ориентированная схема является почти реляционной). Из использованных семи наиболее информативных случаев взаимосвязей внешних и возможных ключей пять случаев известны из литературы ([3]), а два предлагаются автором. В работе все случаи детально проанализированы и предложен порядок их обработки, разрешающий значительное число конфликтов, которые могут возникнуть. Порядок обработки случаев изменяется только в некоторых специально оговоренных ситуациях. Кроме того, в этом алгоритме в соответствующих структурах сохранена вся информация, необходимая для следующих фаз процесса конверсии.
Для создания целевой объектно-ориентированной базы данных, необходимо провести конверсию данных в соответствии с трансформацией схемы. Так как отношения отображаются в классы, в рамках использованных моделей естественным является отображение кортежей реляционной базы данных в экземпляры классов целевой объектно-ориентированной базы данных. В работе построены два алгоритма для решения проблемы конверсии данных в соответствии с трансформацией схемы. Первый из них является более медленным, но он не создает никакой избыточной информации в целевой объектно-ориентированной базе данных и является эффективным в смысле объема базы данных. Второй из них является эффективным в смысле скорости, но в некоторых ситуациях может создавать значительную по объему избыточную информацию.
Первый алгоритм конверсии данных, в отличие от второго, основан на предположении, что классы в объектно-ориентированной схеме содержат точно те атрибуты, которые описаны в процессе трансформации, т. е. не существует никаких дополнительных атрибутов, содержащих избыточную информацию. Этот факт является проблемой при конверсии данных, так как в некоторых ситуациях нет возможности однозначно идентифицировать нужный экземпляр класса. Чтобы позже изменять экземпляры, необходимо иметь возможность однозначно идентифицировать тот экземпляр, который мы хотим изменять. Это изменение, конечно, может выполнить только целевая объектно-ориентированная система, и потому алгоритм конверсии данных должен в качестве результата иметь последовательность INSERTи UPDATE-запросов объектно-ориентированного языка запросов, которые ООСУБД может непосредственно выполнить, в результате чего получается объектно-ориентированная база данных, эквивалентная исходной реляционной базе данных.
Второй алгоритм основан на предположении, что каждый класс в объектно-ориентированной схеме содержит не только те атрибуты, которые описаны в процессе трансформации схемы, но и все остальные атрибуты исходного отношения реляционной базы данных, из которого возник этот класс в процессе трансформации. Это касается атрибутов, которые в конце процесса трансформации схемы удалены из описания классов. Основной идеей этого алгоритма является дополнение классов атрибутами, которые содержат все необходимые данные для идентификации экземпляров этого класса. Тогда связывание экземпляров этого класса с экземплярами иных классов может быть сделано с использованием этих атрибутов. Сначала создаются все экземпляры всех классов, и потом они связываются. Когда создается экземпляр некоторого класса, ему объектно-ориентированная система управления базами данных присваивает уникальный OID. Экземпляр всегда можно идентифицировать, так как теперь он содержит нужные атрибуты соответствующего отношения, а экземпляры можно связывать в любом порядке, т. е. порядок их создания не имеет значения.
В работе рассматривается и проблема трансляции реляционных SQL-запросов в соответствующие запросы объектно-ориентированной системы. Как уже отмечено, эта проблема возникает при конверсии приложений, работающих с базой данных, основанной на одной реляционной модели, в приложения, работающие с базой данных, основанной на объектно-ориентированной модели,.
Предлагаются методы трансляции SELECT-, DELETE-, UPDATEи INSERT-запросов языка SQL в соответствующие объектно-ориентированные запросы.
В работе предполагается, что и реляционные и объектно-ориентированные SELECT-запросы имеют вид SELECT-FROM-WHERE. Главной проблемой трансляции реляционных SELECT-запросов в эквивалентные объектно-ориентированные запросы является трансляция WHERE-части запроса, потому что реляционный и объектно-ориентированный WHERE-предикат сильно отличаются друг от друга. Реляционные предикаты, которые состоят из выражений соединения и селекции и которые не содержат выражений пути, транслируются в объектно-ориентированные предикаты, содержащие выражения пути. Трансляция WHERE-предиката реализуется в три шага. Сначала, из реляционного предиката создается граф реляционного предиката. На втором шаге этот граф трансформируется в соответствующий граф объектно-ориентированного предиката. Наконец, из графа объектноориентированного предиката получается сам объектно-ориентированный предикат. В ходе трансляции реляционного WHERE-предиката производится трансляция и SELECT-, и FROM-частей запроса в вид, который является эквивалентным начальному реляционному запросу.
Для трансляции DELETE-, UPDATEи INSERT-запросов в работе вводится понятие дерева атрибута отношения. Эти деревья используются для вычисления выражений пути для тех атрибутов, которые в трансформированной объектно-ориентированной схеме играют роль атрибутов реляционных запросов. С помощью этих выражений пути формируются эквивалентные объектно-ориентированные DELETE-, UPDATEи INSERT-запросы.
Построены соответствующие программы и проведены компьютерные эксперименты с конверсией экспериментальных баз данных на ряде представительных примеров.
Работа организована следующим способом. После введения в главе 1 и в главе 2 даются короткие обзоры реляционной и объектно-ориентированной моделей данных на уровне, достаточном для дальнейшего изложения. В главе 3 описывается процесс трансформации схемы. В главе 4 описывается процесс конверсии данных, а в главе 5 процесс трансляции реляционных SQL-запросов в эквивалентные объектно-ориентированные запросы. В конце работы приведены заключение, в котором перечисляются основные результаты и список литературы. Работа содержит и два приложения. В первом приложении приводится псевдокод алгоритма трансформации схемы, а во втором приложении приводится псевдокод первого алгоритма конверсии данных. Эти псевдокоды, т. е. более подробные описания алгоритмов на полуформальном языке, основанном на Паскале, приложены к работе с целью лучшего объяснения некоторых аспектов и деталей предложенных алгоритмов.
Заключение
.
В этом пункте перечислим основные результаты диссертационной работы. Они состоят в следующем:
Создан комплекс взаимосвязанных алгоритмов, основанный на детальном изучении проблем, которые возникают при конверсии реляционных баз данных в объектно-ориентированные.
Построен алгоритм трансформации схемы реляционной базы данных в объектно-ориентированную, который автоматически анализирует семантику схемы реляционной базы данных и трансформирует ее в объектно-ориентированную без помощи пользователя.
Построены два алгоритма для решения задачи конверсии данных в соответствии с трансформацией схемы: один экономичен по объему базы данных, второй — по скорости.
Построены алгоритмы трансляции реляционных SELECT-, UPDATE-, DELETEи INSERT-запросов в соответствующие объектно-ориентированные запросы.
Построены соответствующие программы, содержащие около 8000 строк з среде программирования Delphi, и проведены компьютерные эксперименты с конверсии экспериментальных баз данных в: а ряде представительных примеров.
Содержание работы опубликовано в 5 (пяти) печатных работах ([34, 35, 36,37, 38]).
К работе приложены псевдокоды алгоритма трансформации схемы и первого алгоритма конверсии данных.
Благодарности.
В конце этого заключения я хочу поблагодарить своего научного руководителя, профессора др. Гордану Павлович-Лажетич, за поддержку и полезные советы. Она определила направление моего научного исследования.
Большую благодарность за многочисленные советы и огромную помощь при написании работы и статей я выражаю своему научному руководителю, чл.-корр. РАН профессору Л. Н. Королеву. Это человек, благодаря которому я в России себя чувствовал как дома.
