Современное CASE-средство S-Designor фирмы PowerSoft

Александр Науменко, Компания АлконсCофт

Введение

Продукт S-Designor фирмы Powersoft адресован разработчикам информационных систем. Это графический инструмент для проектирования структуры реляционных баз данных. S- Designor реализует популярную методологию информационного моделирования, основанную на представлении информационных объектов и взаимосвязей между ними в виде ER-диаграммы ("сущность-связь"). Используемая в S-Designor нотация - IE (Information Engineering).
В S-Designer эффективно реализована связь как со множеством современных СУБД, так и со средствами разработки приложений. По завершении разработки модели данных S-Designor генерирует пакеты SQL-предложений для широкого набора СУБД, включая Oracle, Ingres, Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase, Access и Paradox. Имеется встроенный ISQL. Для поддерживаемых СУБД автоматически генерируются триггеры, обеспечивающие ссылочную целостность. Предусмотрена возможность редактировать хранимые процедуры непосредственно при подготовке физической модели. Для обеспечения сопровождения существующих систем S-Designor позволяет проводить восстановление модели по структуре базы данных (БД). В течение всего цикла разработки модели данных ( Рис. 1) с помощью S- Designor могут быть получены разнообразные отчеты по модели.
На этапе проектирования модели данных S-Designor дает возможность определить элементы пользовательского интерфейса будущих приложений, работающих с проектируемой базой данных. Это достигается редактированием репозиториев систем 4GL. В качестве средств разработки поддерживается PowerBuilder [4], TeamWindows, Progress, Uniface и другие.
S-Designor работает в среде Microsoft Windows и Windows NT. Для его использования достаточно компьютера с процессором 386SX и объемом памяти от 4 мегабайт. В S-Designor присутствуют элементы, характерные для программ редактирования - линейка инструментов, интерфейс " drag-and-drop", импорт/экспорт графических файлов, инструменты для создания стандартных графических элементов, управление цветом и шрифтовым выделением.
При работе с S-Designor сразу заметны очень высокая скорость отрисовки диаграммы и эффективная реализация интерфейса к СУБД.
Развитые средства быстрого редактирования объектов модели и достаточно полный набор средств управления расположением объектов на диаграмме - характерные черты, делающие S- Designor особенно привлекательным.

Цикл разработки в S-Designor

При проектировании в S-Designor используется двухуровневый подход [2, 3]. Первый уровень - концептуальная модель данных (ER-диаграмма). Второй уровень - физическая модель данных. При переходе на второй уровень S-Designor автоматически генерирует соответствующую физическую модель данных для заданной СУБД, учитывая специфику последней.
Концепция S-Designor - реализация классической теории информационного моделирования, включающей четкое разделение между концептуальной моделью данных (представление объектов реального мира и их взаимосвязи) и физической (отображение этих объектов в терминах, близких к физическому представлению). Например, связи многие ко многим. Согласно теории информационного моделирования и проектирования баз данных, такая связь при реализации должна быть детализирована добавлением третьей уточняющей таблицы. S-Designor позволяет представлять такие связи на концептуальном уровне модели. При генерации физической модели S-Designor автоматически добавляет промежуточную таблицу, таким образом детализируя эту связь.

Рис. 1. Цикл разработки в S-Designor

Особенность реализации цикла разработки в S-Designor заключается в том, что он позволяет выполнять "сквозное проектирование". Это значит, что разработав концептуальная модель можно автоматически сгенерировать физическую и после этого выполнить генерацию структуры БД. При обратном проектировании последовательность действий прямо противоположная. Можно получить физическую модель на основе структуры БД и после этого автоматически сгенерировать концептуальную модель. Разумеется на каждом этапе можно вносить изменения в модели концептуального и физического уровней.
Часто возникает вопрос: "Если генерация физической модели из концептуальной и концептуальной модели из физической выполняется автоматически, надо ли каждый раз корректировать модель соответствующего уровня"? Ответ - нет. S-Designor четко отслеживает соответствие между концептуальным и физическим уровнем и "помнит" не только изменения в структуре объектов модели (уточнения связей, выполненные при переходе на физический уровень), но и их расположение на ER- диаграмме. При генерации этим "учетом изменений" можно управлять. Таким образом, автоматическая генерация - процесс, выполняемый в S-Designor очень эффективно и качественно.

Последовательность проектирования модели данных в S- Designor

Процесс построения информационной модели данных состоит из следующих шагов:

Четкое разделение между концептуальной и физической моделями в S-Designor выражается в том, что на каждом уровне действуют соответствующие четко выраженные правила. На концептуальном уровне (Рис.2. Исходная концептуальная модель)не выполняется миграция атрибутов первичного ключа в дочернюю сущность, так как это было бы уже не отображение реального мира (в данном случае перечня атрибутов конкретного объекта).

Миграция выполняется на физическом уровне (Рис.3. Результат автоматического преобразования в физическую модель).

Необходимость построения физической модели как отдельного шага проектирования объясняется требованием приведения описания сущностей и связей, определенных на стадии построения концептуальной модели, к физической структуре с учетом специфики целевой СУБД. При генерации физической модели из концептуальной сущности становятся таблицами, атрибуты - колонками, для альтернативных ключей генерируются уникальные индексы, а идентификаторы становятся первичными ключами.
При генерации физической модели S-Designor, если это необходимо, детализирует связи. Связь "многие ко многим" порождает новую таблицу. Таким образом обеспечивается автоматическая нормализация модели. Идентификаторы сущностей, участвующих в связи, мигрируют в новую таблицу. Первичный ключ в зависимой таблице составляет теперь сумму атрибутов первичных ключей родительских таблиц. При уточнении иерархической рекурсивной связи S-Designor автоматически добавляет новую колонку, являющуюся внешним ключом, которую при необходимости можно переименовать.
Для управления уникальностью строк и ускорения доступа к данным могут назначаться индексы. Для первичных и внешних ключей индексы формируются автоматически.
На Рис.3 показан результат автоматического преобразования концептуальной модели данных в физическую. Заметим, что на данном уровне уже нет различий между идентифицирующими и неидентифицирующими связями, так как в физической структуре данных такие типы связей действительно неразличимы, поскольку, реализуются одними и теми же общими механизмами СУБД.

Наиболее примечательные возможности S-Designor

Чем хорош и примечателен S-Designor? В первую очередь тем, что это - профессиональное средство информационного моделирования и разработки структур данных. Помимо "широко известных" функций для CASE-средств такого уровня добавлены мощные средства групповой разработки и генерация приложений для целевых средств разработки. Примечателен S- Designor тем, что концептуально целостно построен и имеет строгую практическую направленность. Ниже освещены некоторые наиболее интересные возможности S-Designor.

Работа c источником данных в виде пакета SQL- предложений (DDL)

Данная возможность позволяет проектировать структуру данных и выполнять генерацию SQL- предложений не подключаясь к SQL-серверу. Генерация пакета SQL-предложений выполняется в обычный текстовый файл. На основании содержимого файла можно выполнить обратное проектирование - создать модель данных. Практическая польза - своеобразная "отладка" модели данных. Это дает возможность лишний раз убедиться в правильности действий, предполагаемых выполнить с реальной структурой БД. Поскольку, в данном случае нет необходимости подключаться к серверу БД - проектирование можно выполнять автономно. Например, в домашних условиях, если у Вас дома нет SQL-сервера.

Идентификация модели заголовком (Title)

Данный заголовок поддерживается в S-Designor специальным образом и служит не только для того, чтобы как-то приукрасить модель. Заголовок содержит идентифицирующую информацию, которая также хранится в центральном словаре данных и используется как при организации групповой разработки модели данных, так и в других целях.

Типизация данных

Реализованная в S-Designor типизация данных - средство достижения универсальности типов данных, используемых в модели. На уровне концептуальной модели разработчик оперирует с внутренними типами данных S-Designor. Эти типы данных представлены достаточно широким набором и, что важно, независимы от целевой СУБД. При переходе на физический уровень эти типы данных заменяются типами данных целевой СУБД. Правила соответствия универсальных типов данных и целевых определяются во внешнем текстовом файле, доступном для редактирования. В нем же определяются все правила кодирования SQL-предложений для конкретной СУБД. Соответствие типов данных и конструкции SQL-предложений для конкретной СУБД можно переопределять, хотя такая необходимость возникает крайне редко.

Архивирование модели и модификация структуры данных

Интересно и очень эффективно реализован механизм модификации структуры данных на основе архивной копии модели данных. Архивная копия - сохраненная в специальном формате модель данных.
Суть механизма заключается в следующем. После окончания проектирования первой редакции модели данных, ее можно заархивировать. При изменении модели данных, эти изменения необходимо внести и в структуру таблиц базы данных. Если к этому моменту в таблицах уже есть данные, их желательно сохранить. В S-Designor для этого необходимо только выполнить команду "Модифицировать БД". В результате, на основе архивной копии S-Designor автоматически модифицирует структуру таблиц БД, сохранив данные в таблицах вне зависимости от типа изменений.
При выполнении модификации структуры таблиц БД S-Designor, во-первых, выбирает наиболее эффективную стратегию модификации структуры объектов БД (по возможности наименьшим количеством операторов), а, во-вторых, сохраняет данные в таблицах (создает временную таблицу, перегружает в нее данные из модифицируемой таблицы, модифицирует таблицу, возвращает данные в модифицированную таблицу). Процессом модификации структуры таблиц БД можно управлять, поскольку, имеется возможность сгенерировать пакет SQL-предложений, выполняющий данную модификацию.
Примечательно также то, что S-Designor очень "чувствителен" к изменениям модели данных. Даже такое, на первый взгляд, незначительное изменение как допустимость значений null для отдельной колонки будет "опознано" и структура данных будет автоматически модифицирована. На pис.4 приведен пример пакета SQL-предложений, выполняющий модификацию структуры таблицы hourly_employee при изменении допустимости значения null для колонки hours_per_week(первоначально было null, модифицировано на not null).

Рис. 4

Рис. 4. Пример пакета SQL-предложений, модифицирующего структуру базы данных

Средства проектирования представлений (View)

При разработке информационных систем со сложной структурой данных эффективно использовать представления (View). Цель создания представлений - структурировать и в итоге упростить построение сложных запросов к базе данных.
Эффективность средств проектирования представлений заключается в том, что для разного уровня сложности представлений в S-Designor можно использовать наиболее подходящие для этого конструкторы. Для быстрого проектирования наиболее простых представлений, например эквисоединения двух таблиц, достаточно, выделив необходимые таблицы, выполнить команду "построить представление". Для более сложных представлений можно использовать графический конструктор запросов (аналогичный конструктору в PowerBuilder [4]). И, наконец, при необходимости можно использовать конструктор для создания представления на языке SQL.

Проверка правильности спроектированной модели

Данная возможность связана с тем, что проектирование в S-Designor можно выполнять в свободном порядке. Например, проектировать сначала сущности и связи, потом атрибуты сущностей. Такой подход в ряде случаев удобен и возможен потому, что S-Designor ведет общий словарь данных, используемых в модели. При проверке правильности структуры объектов (в основном сущностей и взаимосвязей между ними), S-Designor формирует протокол об ошибках, в котором содержится полная идентификация ошибок в модели данных.

Расчет необходимой внешней памяти под БД

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

Средства генерации отчетов

S-Designor, как и большинство аналогичных средств такого класса позволяет готовить отчеты по структуре данных модели. Цель подготовки отчетов - документирование разработанной модели данных. Можно создать любое количество стилей отчетов и после этого генерировать отчеты согласно выбранному стилю. Пример использования различных стилей - краткий и полный отчеты по модели. Подготовленный отчет можно напечатать или сохранить в формате, например, текстового процессора Microsoft Word. Впоследствии, отчет можно отредактировать средствами Microsoft Word. В отчет может быть включено графическое изображение модели данных, расположенной как на отдельных страницах, так и смасштабированной так, чтобы вся модель размещалась на одной странице. Отчет можно произвольным образом настраивать. Например, включать или исключать различные элементы отчетов, автоматическое формирование оглавления, переопределять содержимое заголовка и подвала страницы.
Привлекательность подготовки отчетов в S-Designor заключается в том, что разработчики данного продукта предоставили не только средства подготовки отчетов по модели данных, но и тщательно продуманную стартовую структуру отчетов. В результате подготовка отчетов в S- Designor выполняется автоматически и не требует никаких дополнительных действий.

Интеграция со средствами разработки 4GL

S-Designor поддерживает широкий спектр средств разработки 4GL. Поддержка средств разработки 4GL заключается в том, что на этапе проектирования модели данных обеспечивается возможность проектировать отображение элементов объектов, связанных с базой данных. Данную возможность проиллюстрируем на примере интеграции S-Designor со средством разработки приложений PowerBuilder фирмы PowerSoft [4].
При создании окон данных (DataWindow) в PowerBuilder элементы окна отображаются согласно расширенным атрибутам, назначенным этим элементам. Либо действуют установки по умолчанию, если элементам окна расширенные атрибуты не назначены. Таким образом, расширенные атрибуты - это спецификации, которые управляют изображением DataWindow при его конструировании. Поэтому, использование расширенных атрибутов на этапе проектирования модели данных позволяет значительно ускорить разработку отдельных объектов в приложении, например, подготовку окон данных и стандартизовать пользовательский интерфейс.
Расширенные атрибуты хранятся в репозитории средств разработки. Для PowerBuilder репозиторий представлен пятью таблицами, которые создает PowerBuilder в целевой БД при первом подключении к ней.
Это таблицы:

В S-Designor имеются возможности как импорта расширенных атрибутов в репозиторий целевого средства разработки, так и экспорта из репозитория в модель. Расширенные атрибуты можно сохранять в файлах и впоследствии при разработке новой модели данных загружать спроектированные ранее расширенные атрибуты в новую модель.
В качестве расширенных атрибутов можно использовать выпадающие списки (окна данных типа Drop Down DataWindow). Можно создать ряд окон данных, например, для словарей. После этого необходимым колонкам таблиц в модели данных назначить стиль редактирования - Drop Down DataWindow, где этими окнами данных будут спроектированные ранее окна данных для словарей. После этого всегда, когда будет проектироваться основное DataWindow, в котором какие-либо колонки должны быть представлены в виде выпадающих списков, содержащих данные словарей, - это будет делаться автоматически.
Значительно ускорить разработку приложений позволяет использование доменов. В терминах модели данных домен - именованный набор атрибутов объекта, который можно назначить колонке таблицы. Набор атрибутов домена логически делится на две части. Первую часть составляют расширенные атрибуты. Они используются при разработке приложений. Вторую - правила и ограничения, связанные с физической структурой таблиц БД. Можно определить, например, домен My_Date_Code для типа данных date и назначить его на колонки таблиц, имеющие такой тип данных. Таким образом, один раз сконструировав необходимый именованный набор атрибутов его можно многократно использовать и централизованно редактировать. При импорте расширенных атрибутов в репозиторий средств разработки S- Designor разложит "сам" эти атрибуты для тех колонок, на которые назначен домен My_Date_Code. Пример конструирования домена My_Date_Code. приведен на pис.5
Рис. 5

Рис. 5. Конструктор домена расширенных атрибутов

Генерация приложений

Современная версия S-Designor позволяет автоматически генерировать приложения. Приложения генерируются в интерфейсе MDI (многодокументный интерфейс). Обеспечивается возможностью генерации связанных окон данных (master-detail). Приложения генерируются на основе template, который поставляется с S-Designor. Окна данных в приложении генерируются согласно выбранным таблицам модели данных. Для генерации приложения достаточно указать только ряд необходимых параметров, таких как имя библиотеки в которой будет сохранено приложение, источник данных в терминах ODBC, с которым будет работать приложение, имя библиотеки, содержащей template, а также некоторые другие параметры.
Имеется возможность автоматически генерировать запросы (Query) как объекты в терминах целевых средств разработки на основе представлений (View).

Средства групповой разработки модели данных

При разработке крупных корпоративных систем особое значение приобретает организация групповой разработки общей модели данных. При этом, каждый разработчик разрабатывает "свою" часть общей модели. Для обеспечения эффективности такой работы необходимо хранение модели данных в месте, доступном для каждого разработчика, и механизмы, поддерживающие актуализацию модели, оперативное внесение изменений и контроль доступа к модели данных. S-Designor обеспечивает все необходимые для этого возможности.
Принцип организации коллективной разработки в S-Designor - использование централизованного словаря метабазы, который хранит модели данных, и обеспечение доступа к нему. Для организации работы со словарем и управления коллективной разработкой предназначена отдельная компонента - S-Designor Dictionary. Компонента служит для создания и администрирования централизованного словаря.
Словарь метабазы - это ряд таблиц, которые создаются на SQL-сервере из среды S-Designor Dictionary. Технология работы с централизованным словарем метабазы построена на двух ключевых понятиях: Consolidation (консолидация/слияние модели с моделью в словаре) и Extraction (операция извлечения модели данных из словаря).
Перед тем, как внести изменения в модель данных необходимо выполнить операцию Extraction. По этой операции модель данных либо извлекается из словаря и загружается в S-Designor, либо сохраняется в файл. По операции Consolidation выполняется консолидация метаданных измененной модели с метаданными в словаре. Так вносятся изменения в модель в словаре.
Консолидировать можно всю модель целиком и отдельные подмодели. Консолидация выполняется по следующим правилам. Сначала проверяются полномочия выполняющего операцию консолидации. При конфликтных ситуациях, например, если после последней операции Extraction объект модели был изменен - S-Designor предлагает вариант принятия решения. После консолидации можно сразу выполнить операцию Extraction для того, чтобы получить гарантированно актуальную модель в файле.
Начало работы с централизованным словарем - это создание словаря администратором и регистрация пользователей, которые будут работать с центральным словарем. После этого администратор создает первый проект - только он имеет право это делать и назначает пользователям полномочия доступа к моделям и подмоделям данных.
Права доступа делятся на следующие группы:
ADMI - пользователи данной группы могут выполнять любые действия со словарем и с хранимыми в нем моделями.
Upgrade - пользователи данной группы могут оперировать со своими моделями и подмоделями с атрибутом Public.
Read-only - пользователи данной группы могут только читать информацию из словаря.
Lock - пользователи данной группы в данный момент не имеют никаких полномочий.
Структура проекта следующая: проект (project) - модель (model: концептуальная и/или физическая) - подмодель (sub-model). Для создания проекта в словаре администратор выполняет консолидацию модели в режиме Create (Рис.6).

Рис. 6

Рис. 6. Консолидация модели данных с моделью в словаре

Возможные режимы консолидации в S-Designor:

Consolidate - консолидировать модель с моделью в словаре.
Simulate - имитировать консолидацию без внесения реальных изменений в словарь метабазы.
Create - создать проект или модель в словаре.
Replace - заменить существующую модель. Данный режим эффективно использовать в случае, если консолидируемая модель значительно отличается от модели в словаре.
Создавая проект администратор может указать имя пользователя, который станет владельцем этого проекта или сделать это после создания проекта. Так назначается владелец проекта.
Проект может включать несколько моделей данных (Рис.7). Обеспечивается возможность одновременно разрабатывать отдельные модели отдельными разработчиками. Консолидацию выполняет администратор проекта или пользователь, имеющий соответствующие полномочия.
Рис. 7

Рис. 7. Список моделей проекта

Создав проект, администратор назначает пользователям полномочия, например, на отдельные подмодели. Полномочия действуют в момент консолидации. Модели или подмодели, на которые пользователи не имеют полномочий, недоступны для редактирования.
Реализуя функцию управления доступом для моделей и подмоделей данных, S-Designor обеспечивает возможность руководителю проекта контролировать все изменения, которые влияют на проект в целом. При этом, модель данных всегда доступна, актуальна и гарантированно целостна.

Заключение

В заключении хочется отметить, что стройное концептуальное построение S-Designor выгодно отличает его от CASE-средств такого класса. Богатство возможностей и простота использования S-Designor позволяет эффективно использовать его как для разработки моделей данных небольших информационных систем, так и для разработки моделей данных больших корпоративных систем. Возможно, именно поэтому на рынке CASE-средств информационного моделирования S-Designor занимает все более прочную позицию.

Список литературы

  1. Кодд Е.Ф. Реляционная модель данных для больших совместно используемых банков данных. СУБД № 1, 1995.
  2. Chen P.P. The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on Database Systems, vol.1., № 1, 1976.
  3. Горин С.В., Тандоев А.Ю. Применение CASE-средства ERwin 2.1 для информационного моделирования в системах обработки данных. СУБД, N 3, 1995.
  4. Горин С.В., Тандоев А.Ю. Среда разработки приложений PowerBuilder. DBMS/Russian Edition, № 1, 1995.

Александр Науменко
AlconsSoft
tel: +7 (095) 362-5138, 918-1380
e-mail: alcons@glas.apc.org

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