|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #01/96
|
|
С.В. Горин, А.Ю. Тандоев
Фирма AlconsSoft
(095) 362-5138; 918-1380, alcons@glas.apc.org
Продукт S-Designor фирмы SDP (приобретенной недавно фирмой Powersoft) адресован разработчикам информационных систем. Это графический инструмент для проектирования структур реляционных баз данных [1]. S-Designor реализует стандартную методологию информационного моделирования и сочетает такие свойства, как концептуальная стройность и богатство возможностей. При проектировании в S-Designor используется двухуровневый подход [2, 3]. Первый уровень - концептуальная модель данных (КМД) или модель сущность-связь (ER-диаграмма). Второй уровень - физическая модель данных (ФМД). При переходе на второй уровень S-Designor автоматически генерирует соответствующую физическую модель данных для заданной СУБД, учитывая специфику последней.
По завершении разработки ФМД S-Designor генерирует пакеты SQL-предложений для широкого набора СУБД, включая Oracle, Ingres, Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase, Access и Paradox. Для поддерживаемых СУБД автоматически генерируются триггеры, обеспечивающие ссылочную целостность. Предусмотрена возможность редактировать хранимые процедуры непосредственно при подготовке физической модели. Для обеспечения сопровождения существующих систем S-Designor позволяет проводить восстановление модели по структуре базы данных. В течение всего цикла разработки модели (Рис. 1) с помощью S-Designor могут быть получены разнообразные отчеты по модели.
Рисунок 1.
Цикл разработки в S-Designor
На этапе работы с ФМД S-Designor дает возможность определить элементы пользовательского интерфейса будущих приложений, работающих с проектируемой базой данных. Это достигается редактированием словарей систем 4GL. В качестве средств разработки поддерживается PowerBuilder [4], TeamWindows, Progress, Uniface и другие. Для PowerBuilder выполняется прямая генерация шаблонов приложений.
S-Designor работает в среде Microsoft Windows. В S-Designor присутствуют элементы, характерные для программ редактирования, - линейка инструментов, интерфейс "drag-and-drop", импорт/экспорт графических файлов, инструменты для создания произвольных изображений, управление цветом и шрифтовым выделением.
На диаграмме сущность изображается прямоугольником. Атрибуты располагаются внутри прямоугольника, обозначающего сущность. Атрибуты, составляющие идентификатор сущности, выделяются подчеркиванием (Рис. 2).
Рисунок 2.
Диаграмма для концептуальной модели (пример).
Связь (relationship) изображается линией, соединяющей сущности. Мощность связи показывается окончаниями линии. Мощность "один" изображается простой линией, мощность "много" - разветвленной линией. Если связь присутствует для всех экземпляров сущности, то линия перечеркивается, в противном случае - изображается окружностью на линии. Треугольник на линии связи обращен вершиной к родительской сущности (Рис. 3).
Рисунок 3.
Элементы диаграммы концептульной модели.
Физическая модель данных строится после окончания работы над КМД. Необходимость построения ФМД как отдельного шага проектирования объясняется требованием приведения описания сущностей и связей, определенных на стадии построения КМД, к структурам физической СУБД с учетом специфики последней. При генерации физической модели из КМД сущности становятся таблицами, атрибуты - колонками, для альтернативных ключей генерируется уникальный индекс, а идентификаторы становятся первичными ключами. Уникальный индекс автоматически назначается для каждого первичного ключа. Связь "один ко многим" приводит к генерации внешнего ключа и автоматической миграции атрибутов. На Рис. 4 показан фрагмент диаграммы ФМД для сущностей "отдел" и "сотрудник".
Рисунок 4.
Связь один ко многим на диаграмме физической модели.
Связь "многие ко многим" (Рис. 5) порождает новую таблицу. Таким образом обеспечивается автоматическая нормализация модели. Идентификаторы сущностей, участвующих в связи, мигрируют в новую таблицу. При этом первичный ключ новой таблицы объединяет колонки первичных ключей таблиц, участвующих в связи.
Рисунок 5.
Исходная концептуальная модель.
На Рис. 6 показан результат автоматического преобразования этой модели в физическую модель. Автоматически сгенерированная таблица может быть изменена разработчиком.
Рисунок 6.
Результат автоматического преобразования в физическую модель.
Для управления уникальностью строк и ускорения доступа к данным могут назначаться индексы. Для первичных и внешних ключей индексы формируются автоматически.
В S-Designor существует несколько вариантов правил, которые могут применяться для обеспечения ссылочной целостности.
Каскадное удаление: удаление записи из родительской таблицы вызывает удаление всех записей из дочерней таблицы, ссылающихся на соответствующее значение ключа.
· Каскадное обновление - модификация ключа в родительской таблице вызывает модификацию атрибутов внешнего ключа в соответствующих записях дочерней таблицы.
· Запрет удаления - запрещается удаление тех записей из родительской таблицы, на которые существуют ссылки из дочерней таблицы.
· Запрет модификации - запрещается модификация значения ключа в родительской таблице для записи, на которую существуют ссылки из дочерней таблицы.
Установка пустого значения: атрибуты внешнего ключа в дочерней таблице устанавливаются в NULL при удалении соответствующих записей из родительской таблицы.
Создадим в S-Designor модель данных для распределения заданий между сотрудниками предприятия. Сотрудники объединены в отделы и работают по определенным проектам для заказчиков. По каждому проекту выделяются задачи, над которыми работают группы сотрудников. Каждый сотрудник использует в своей работе один или несколько типов материалов.
Исходя из постановки задачи, выделяем список сущностей: "сотрудник", "заказчик", "отдел", "проект", "задача", "материал". Создание сущности на диаграмме проводится выбором соответствующей кнопки на линейке инструментов и щелчком мыши на диаграмме. Для каждой сущности задается список атрибутов и соответствующих имен колонок (Рис. 7).
Рисунок 7.
Редактирование списка атрибутов.
В списке для каждого атрибута показывается его код (при переходе к физической модели код становится именем колонки), тип данных, а также входит ли атрибут в идентификатор ("I" - Identifier), допускает ли атрибут пустые значения ("M" - Mandatory), требуется ли отображать колонку на диаграмме ("D" - Display).
При определении типов колонок указываются внутренние типы S-Designor. Далее при генерации пакета SQL-предложений внутренние типы преобразуются в типы целевой СУБД (описание соответствия типов данных, а также прочей информации, специфичной для каждой СУБД, хранится во внешних текстовых файлах).
Из этого диалога можно перейти к определению ограничений на колонку (кнопка "check"), где пользователь определяет ограничения, проверяемые сервером СУБД для данной колонки. Здесь задаются такие параметры, как минимальное и максимальное значения, умалчиваемое значение, список допустимых значений (Рис. 8).
Рисунок 8.
Определение ограничений на колонку.
Атрибуту может быть приписан домен (кнопка "Domain"). Домен - логическое понятие, действующее для всей модели. Использование доменов позволяет назначать однотипным атрибутам сразу группу параметров - таких как тип данных, условия проверки со стороны сервера, проверки со стороны клиента. Далее указываются связи между сущностями. Для этого достаточно выбрать на линейке инструментов кнопку "связь" и "протянуть" с помощью мыши линию.
Готовая диаграмма приведена на Рис. 2.
Для изменения параметров любого объекта диаграммы, в том числе связи, используется щелчок правой кнопки мыши, активизирующей контекстно-зависимое "всплывающее" меню. На Рис. 9 показан диалог определения характеристик связи со стороны каждой из двух сущностей.
Рисунок 9.
Определение параметров связи.
Сущность "участвует" содержит информацию о задачах, в которых участвует сотрудник. Один сотрудник может участвовать во многих задачах (many). Связь является необязательной (optional); сущность "сотрудник" является независимой (не отмечена кнопка "Is dependent").
Каждому экземпляру сущности "участвует" соответствует один экземпляр сущности "сотрудник" (one); связь обязательна (mandatory), т.к. не бывает записей об участии без соответствующего сотрудника; сущность зависима, т.к. ее экземпляры идентифицируются через данную связь.
S-Designor предлагает множество параметров выдачи отчетов по концептуальной модели и управляет набором и видом представления информации в зависимости от поставленных целей (Рис. 10). Разработчик может определить собственные стили выдачи отчетов.
Рисунок 10.
Параметры генерации отчета.
Отчет может быть подготовлен в формате ASCII-текста или в формате RTF для программ MS Word, Ami Pro, Page Maker, WordPerfect.
После того, как S-Designor выполнил автоматическую генерацию ФМД (Рис. 11), ее можно модифицировать. Необходимые изменения касаются назначения индексов и правил поддержания ссылочной целостности.
Рисунок 11.
Диаграмма для физической модели.
На Рис. 12 приведен диалог определения правил поддержания ссылочной целостности между таблицами EMPLOYEE и DIVISION.
Рисунок 12.
Правила для ссылочной целостности.
В зависимости от указанных опций S-Designor сгенерирует соответствующие триггеры на операции обновления и удаления для таблицы DIVISION и на операцию вставки для таблицы EMPLOYEE.
Изменения, проведенные в ФМД, не пропадают после выполнения повторной генерации физической модели из концептуальной.
База данных создается непосредственно из S-Designor, который выполняет подключение к серверу СУБД через интерфейс ODBC. Другой вариант - подготовка пакета SQL-предложений для создания структуры базы данных. В S-Designor предусмотрено множество параметров генерации структуры базы данных, например: выполнять ли оператор удаления таблицы (DROP TABLE) перед оператором создания таблицы (CREATE TABLE), создавать ли триггеры, процедуры, представления (view) и т.д. Набор параметров генерации может быть сохранен под определенным именем для последующего использования (Рис. 13).
Рисунок 13.
Параметры генерации структуры.
S-Designor поддерживает внесение изменений в существующую структуру базы данных. При развитии системы можно расширить концептуальную модель, затем сгенерировать физическую модель (фактически генерируются только изменения) и выполнить команду Update database для актуализации проведенных изменений в физической базе данных.
В S-Designor можно переопределить встроенные в систему триггеры, поддерживающие ссылочную целостность. Пользователь может также создать новые триггеры.
Имеется встроенный редактор хранимых процедур. Таким образом, все функции, касающиеся структуры базы данных, выполняются в одном приложении, что исключает возможность ошибок и "потери", например файла с текстом триггера или процедуры.
При работе с ФМД можно определить представления (view). Редактирование представления выполняется в мощном визуальном инструменте - редакторе SQL-предложений. На Рис. 14 показан вид окна редактирования запроса, по которому создается представление.
Рисунок 14.
Редактирование SQL-запроса для представления.
Часто перед разработчиками встает задача анализа и расширения существующих информационных систем, для которых не существует информационной модели. При расширении подобных систем и переводе их на технологию клиент-сервер требуется провести обратное проектирование информационной модели существующей базы данных. S-Designor, подключившись к базе данных, генерирует физическую модель данных по структуре базы данных. На основании полученной ФМД можно затем выполнить автоматическую генерацию концептуальной модели.
При создании базы данных требуется оценить отводимый для нее размер дисковой памяти. Как правило, разработчик указывает грубую верхнюю оценку. S-Designor позволяет выполнить более точное вычисление размера будущей СУБД, базируясь на оценках количества записей в таблицах, вводимых разработчиком.
Диаграммы информационных моделей больших систем могут занимать несколько десятков листов. Работать с такой диаграммой неудобно. При проектировании с использованием S-Designor разработчик может выделить в модели логически законченные части и поместить в каждую из них подмножество объектов (таблиц, представлений, связей). Ядро информационной модели (базовые таблицы) может быть помещено во все логические части. Разработчик имеет возможность вызвать на экран и редактировать диаграмму для любой логической части модели. Такой подход позволяет организовать раздельное проектирование логически обособленных частей.
S-Designor взаимодействует со словарями систем 4GL, что предоставляет возможность определять внешний вид элементов данных в будущих приложениях еще на стадии построения модели. Так, для каждой колонки таблицы можно определить правило контроля введенных значений (выполняемое клиентской частью), шрифт, цвет, метку, формат отображения, маску редактирования, значение по умолчанию (подставляемое клиентской частью), список значений для выбора.
Представления, определенные в модели, сохраняются в исходных библиотеках системы 4GL и могут использоваться при подготовке запросов в приложении. S-Designor поддерживает восстановление расширенных атрибутов PowerBuilder и TeamWindows из базы данных. Кроме того, поддерживается прямое обновление библиотек PowerBuilder и TeamWindows.
В S-Designor определены стандартные шаблоны для триггеров, обеспечивающие поддержку ссылочной целостности. Шаблоны кодируются на языке SQL с использованием специальных макросимволов, которые управляют генерацией кода триггера при его использовании. Макросимволы включают такие конструкции, как, например, цикл по колонкам (родительской или дочерней сущности), вложенный вызов фрагментов шаблона. Пример шаблона триггера, вызывающегося при удалении записей из родительской таблицы приведен ниже.
/* Delete trigger "%TRIGGER%" for table "%TABLE%" */ create trigger %TRIGGER% on %TABLE% for delete as begin declare .DeclDeleteParentRestrict .DeclDeleteParentCascade .DeclDeleteParentSetNull @numrows int, @errno int, @errmsg varchar(255) select @numrows = @@rowcount if @numrows = 0 return .DeleteParentRestrict .DeleteParentCascade .DeleteParentSetNull return /* Errors handling */ error: raiserror @errno @errmsg rollback transaction end go
В S-Designor модель может быть разбита на логически законченные части (подмодели). Каждая из таких подмоделей может проектироваться отдельным разработчиком.
При групповой разработке модели хранятся не в файлах, а в базе данных. Базой данных здесь может выступать любая SQL-СУБД, например та же, для которой ведется разработка.
Каждый разработчик имеет доступ только к своей подмодели, для определения полномочий используется парольная защита. Администратор проекта имеет возможность отслеживать процесс разработки по каждой подмодели, а по завершении - объединить подмодели и сгенерировать структуру базы данных.
S-Designor обладает уникальной возможностью генерировать законченные приложения PowerBuilder непосредственно на основании физической модели данных.
Генерируется MDI-приложение. Для каждой таблицы в физической модели создается соответствующий пункт меню в меню "File". В открывающемся окне редактируется таблица. При этом обеспечивается дополнительный сервис, как, например, фильтрация записей и модификация запроса средствами QBE. Для каждой связи генерируется окно, обеспечивающее базовую функциональность типа "master-detail". При щелчке мышью над записью в таблице-родителе считываются соответствующие данные из таблицы-потомка. На Рис. 15 показаны простейшая ER-диаграмма и вид приложения, сгенерированного автоматически на основе этой модели.
Рисунок 15.
Физическая модель и автоматически сгенерированное приложение.
S-Designor 4.2 по своим функциональным возможностям и стоимости близок к другому мощному средству проектирования структур баз данных - пакету ERwin 2.1 фирмы LogicWorks. Внешне их отличает используемая на диаграммах нотация. Пакет S-Designor, в отличие от ERwin, позволяет проектировать представления (view) в составе модели. В ERwin концептуальная и физическая модели данных являются визуальными представлениями единого целого [3], тогда как в S-Designor последовательно проведено различие между ФМД и КМД и обеспечена логически стройная связь между ними.
ERwin взаимодействует с поддерживаемыми СУБД напрямую; в S-Designor работа с СУБД ведется через ODBC-интерфейс с использованием внешних файлов для описания специфики конкретной СУБД. Этим объясняется большее число СУБД, с которыми может работать S-Designor. S-Designor может импортировать модели, подготовленные в ERwin.
|
|