1. База данных

Генерация реляционной базы данных по модели классов UML в настоящее время является широко распространенной практикой и поддерживается практически во всех популярных CASE-пакетах.

Отметим лишь некоторые особенности, присущие нашей реализации:

• Автоматическая генерация суррогатных ключей. В REAL-ГГ для идентификации записей в таблицах применяется подход на основе использования суррогатных ключей. В каждую таблицу генератор добавляет столбец «И» и объявляет его первичным ключом. По каждой ассоциации «многие к одному» генерируется поле, которое объявляется вторичным ключом. Поскольку эти поля генерируются автоматически, разработчик не должен определять их как атрибуты класса. Этим REAI.- 1Т отличается от большинства подходов, в которых при моделировании данных в атрибуты класса приходится заносить все поля таблицы.

• Сохранение метаданных. Помимо создания таблиц по классам, определенным разработчиками системы, генератор создает специальные таблицы для сохранения метаданных, т.е. исходной модели классов. Эю позволяет приложению, при необходимости, получать доступ к данной информации. Конечно, сама СУБД обычно позволяет получить метаинформацию о ее схеме, но по схеме сгенерированной базы невозможно однозначно восстановить исходную модель классов, поскольку ряд важных параметров в ней отсутствуют. Например, логические имена классов и атрибутов, типы данных в модели (это особенно актуально для перечислений, и т.д.). Кроме того, в отдельной таблице сохраняются некоторые параметры 6а 1Ы, в частности, номер версии и контрольная суммы схемы данных, способ генерации первичных ключей и т.д.

1. Поддержка итеративного процесса

В данном разделе рассматривается реализация механизма миграции данных, обсуждавшегося в п.5.3. По результатам выполнения ряда промышленных проектов с использованием REAL-ГГ нами был выявлен набор наиболее типичных модификаций схемы базы данных. К ним относятся:

1. Добавление в схему новых таблиц.

2. Добавление новых а1рнбутов в существующие таблицы.

3. Добавление новых связей между существующими таблицами.

4. Замена одной таблицы двумя связанными (при этом атрибуты старой тэблицы делятся между новыми).

5. Удапснис таблиц, связей и атрибутов.

6. Изменение типа атрибута, при котором все значения старого типа можно автоматически привести к новому типу. Наиболее распространенные случаи - это замена числового типа на строковый или добавление новых значений в перечислимый тип.

7. Изменение типа атрибута с логического на перечислимый.

8. Переименование неудачно выбранного идентификатора атрибу1 а.

Модификации, перечисленные в пунктах 1, 2, 3, 5, 6 мы будем называть тривиальными. В REAL-ГГ входит компонента UniMigrator, содержащая общую для всех приложений функциональность по миграции данных. При эгом переносится информация из всех таблиц и их полей, имеющихся как в новой, так и в старой базе данных. Значение каждого атрибута автоматически приводится к сто типу в новой базе. Тем самым, осуществляются все тривиальные преобразования. Кроме того, UniMigrator осуществляет перенос информации о предопределенных объектах по алгоритму, изложенному в п.5.3.

Для осуществления других видов преобразовании данных разработчики ИС могут расширить UniMigrator путем встраивания в него соответствующей компоненты — мигратора приложения. UniMigrator является частью стандартной библиотеки поддержки периода исполнения REAL-IT, он автоматически загружается при запуске системы и при каждом открытии базы данных проверяет совпадение версии схемы базы данных, сохраненной в базе и в коде программы. В случае, если открывается более старая версия, пользователю предлагается выполнить'ее обновление. При этом база данных замещается на шаблонную базу (пустую), и осуществляется перенос информации. При копировании данных UniMigrator предоставляет СОМ- интерфейс, содержащий набор событий, позволяющий мигратору приложения влиять на процесс копирования. Мигратор приложения создается или модифицируется при каждом нетривиальном изменении схемы и содержит код, преобразующий данные в соответствии с этим изменением.

6.2 REAL-IT/VB