Управление версиями объектов в XSQL

Как мы отмечали в начале этого раздела, одним из требований САПР к системам управления базами данных является требование обеспечения доступа к данным, характеризующим предыдущее состояние проекта.

XSQL обеспечивает возможность образования версий объектов в общей базе данных. В соответствии с общим стремлением разработчиков к простоте и при решении этой проблемы они остановились на некотором относительно простом и не требующем переделок физического уровня системы варианте.

Следуя [66], рассмотрим общую модель управления версиями в XSQL. Прежде всего отметим, что в первой реализации механизма версий разработчики XSQL не стремились к экономии внешней памяти. Отмечается, что в дальнейшем, возможно, будет реализован более экономный механизм. Управление версиями производится на основе базового понятия сложного объекта. Для каждого объекта может существовать множество версий, составляющих объект проектирования. С объектом проектирования (ОП) связывается идентификатор.

Каждая версия идентифицируется номером версии внутри объекта проектирования, т.е. пара <идентификатор ОП, номер версии> уникально идентифицирует версию. Номера версий генерируются автоматически при создании версий. Внутри ОП номера версиям назначаются в порядке возрастания и никогда не используются повторно. Это отражает семантику версий: версия с большим номером является более новой; отсутствие версии с указанным номером (меньшим максимального) означает, что эта версия была уничтожена.

Одна и только одна версия ОП может быть помечена с помощью ключевого слова CURRENT (текущая). После связывания CURRENT с некоторой версией это ключевое слово является синонимом номера этой версии. Следовательно, пара <идентификатор ОП, CURRENT> однозначно идентифицирует версию.

Версию можно объявить замороженной (frozen). В общем случае в процессе проектирования создается несколько версий, пока не будет достигнут некоторый согласованный уровень, который можно отдать на использование другим проектировщикам. В этот момент версия замораживается, после чего не допускаются ее удаление и модификации до тех пор, пока ее явно не разморозит пользователь. Средства замораживания и размораживания версий доступны пользователям, и ими следует пользоваться осторожно. Замороженная версия ОП с максимальным номером идентифицируется парой <идентификатор ОП, LAST FROZEN> (последняя замороженная версия).

Диалект SQL, используемый в XSQL, включает следующие средства управления объектами проектирования и версиями:

- операторы создания и уничтожения объектов проектирования;

- операторы создания и уничтожения версий (допускается уничтожение указанной версии; текущей версии; всех версий, более "молодых", чем последняя замороженная; всех незамороженных версий; версий с номерами из указанного интервала);

- операторы замораживания и размораживания версий;

- операторы выборки объектов проектирования и их версий;

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

Следующий существенный аспект управления версиями связан с тем, что в одном объекте проектирования могут находиться ссылки на другие объекты проектирования. Пусть, например, существуют два объекта проектирования ОП1 и ОП2, и имеются ссылки из ОП1 на ОП2. Оказывается неудобным хранить в версиях ОП1 ссылки на версии ОП2. Это влечет накладные расходы и не позволяет разным пользователям ОП1 использовать в одной версии ОП1 разные версии ОП2.

Для решения этой проблемы предлагается техника, основанная на понятиях родовых ссылок и среды. Родовая ссылка - это ссылка на объект проектирования, в которой не уточняется, какая версия будет использвана.

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

Различаются два представления среды - начальное, определяемое пользователем, и рабочее, вырабатываемое в ходе активизации среды или заранее. Начальное определение среды состоит из трех разделов. Первый раздел включает прямо указываемые соответствия объектов проектирования и их версий в данной среде. Номер версии может указываться явно, либо с употреблением идентификаторов LF (последняя замороженная версия) или C (текущая версия). Второй раздел содержит пары вида <идентификатор ОП, имя среды>. При этом понимается, что соответствие должно быть установлено на основе информации из именованной среды. Наконец, третий раздел содержит список включения ранее определенных сред с указанием их приоритетов, т.е. указывает на необходимость использования соответствий (если они не определены явно в первых двух разделах) из именованных сред в соответствии с их приоритетами.

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

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

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

Использование кластеров допускается также при определении среды: пару <идентификатор ОП, номер версии> можно расширить до триплета <идентификатор ОП, идентификатор кластера, номер версии>. При этом номер версии может быть задан явно или с помощью идентификаторов LF и C, но понимается как номер версии в указанном кластере, а не в объекте проектирования в целом.

Отмечается, что механизм кластеров необязателен для использования, и если его не использовать, т.е. работать только на уровне версий объекта проектирования, то существование этого механизма не приводит к дополнительным накладным расходам.

Работа с версиями в текущей версии реализована над базовым уровнем XSQL. Как отмечается в [66], это позволило проверить правильность идей, после чего, если этого потребуют соображения эффективности, можно перенести некоторые части схемы ниже интерфейса XSQL. Из последнего замечания следует, что на момент публикации достаточного опыта XSQL с механизмом версии еще не было.

Завершая этот подраздел, заметим, что разработчиками XSQL предложен достаточно сложный механизм управления версиями (но все-таки гораздо более простой, чем описанный в [67]). Мы не исключаем, что спустя некоторое время появятся публикации, описывающие более простую, эффективно реализуемую схему управления версиями в этой же системы (последователи System R неоднократно проходили подобный путь в своих разработках).

Назад | Содержание | Вперед