Реферат Курсовая Конспект
Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств. - раздел Право, Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств…………………………………………………….12 Семейство Программных Продуктов Powersoft Powerdesigner Является Современным ...
|
Семейство программных продуктов Powersoft PowerDesigner является современным средством моделирования и построения баз данных и приложений в архитектуре клиент-сервер, которое могут использовать в своей работе аналитики, проектировщики, разработчики приложений и баз данных, а также администраторы баз данных. Модульная структура PowerDesigner позволяет организациям выбрать конфигурацию, отвечающую именно их требованиям и размерам разрабатываемого проекта. Широкие возможности по анализу и проектированию информационных систем обеспечивают гибкий структурный подход, повышающий эффективность работы создаваемых баз данных и приложений без необходимости "слепого" следования выбранной однажды методологии.
Продукт PowerDesigner фирмы Powersoft адресован разработчикам информационных систем. Это графический инструмент для проектирования структуры реляционных баз данных. PowerDesigner реализует популярную методологию информационного моделирования, основанную на представлении информационных объектов и взаимосвязей между ними в виде ER-диаграммы ("сущность-связь"). Используемая в PowerDesigner нотация - IE (Information Engineering).
В S-Designer эффективно реализована связь как со множеством современных СУБД, так и со средствами разработки приложений. По завершении разработки модели данных PowerDesigner генерирует пакеты SQL-предложений для широкого набора СУБД, включая Oracle, Ingres, Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase, Access и Paradox. Имеется встроенный ISQL. Для поддерживаемых СУБД автоматически генерируются триггеры, обеспечивающие ссылочную целостность. Предусмотрена возможность редактировать хранимые процедуры непосредственно при подготовке физической модели. Для обеспечения сопровождения существующих систем PowerDesigner позволяет проводить восстановление модели по структуре базы данных (БД). В течение всего цикла разработки модели данных (рисунок 21) с помощью PowerDesignor могут быть получены разнообразные отчеты по модели.
На этапе проектирования модели данных PowerDesigner дает возможность определить элементы пользовательского интерфейса будущих приложений, работающих с проектируемой базой данных. Это достигается редактированием репозиториев систем 4GL. В качестве средств разработки поддерживается PowerBuilder, TeamWindows, Progress, Uniface и другие.
PowerDesigner работает в среде Microsoft Windows и Windows NT. В PowerDesigner присутствуют элементы, характерные для программ редактирования - линейка инструментов, интерфейс "drag-and-drop", импорт/экспорт графических файлов, инструменты для создания стандартных графических элементов, управление цветом и шрифтовым выделением.
При работе с PowerDesigner сразу заметны очень высокая скорость отрисовки диаграммы и эффективная реализация интерфейса к СУБД.
Развитые средства быстрого редактирования объектов модели и достаточно полный набор средств управления расположением объектов на диаграмме - характерные черты, делающие PowerDesignor особенно привлекательным.
Цикл разработки в PowerDesigner
При проектировании в PowerDesigner используется двухуровневый подход. Первый уровень - концептуальная модель данных (ER-диаграмма). Второй уровень - физическая модель данных. При переходе на второй уровень PowerDesigner автоматически генерирует соответствующую физическую модель данных для заданной СУБД, учитывая специфику последней.
Концепция PowerDesigner - реализация классической теории информационного моделирования, включающей четкое разделение между концептуальной моделью данных (представление объектов реального мира и их взаимосвязи) и физической (отображение этих объектов в терминах, близких к физическому представлению). Например, связи многие ко многим. Согласно теории информационного моделирования и проектирования баз данных, такая связь при реализации должна быть детализирована добавлением третьей уточняющей таблицы. PowerDesigner позволяет представлять такие связи на концептуальном уровне модели. При генерации физической модели PowerDesigner автоматически добавляет промежуточную таблицу, таким образом детализируя эту связь.
Рисунок 2 - Цикл разработки в PowerDesigner
Особенность реализации цикла разработки в PowerDesigner заключается в том, что он позволяет выполнять "сквозное проектирование". Это значит, что разработав концептуальная модель можно автоматически сгенерировать физическую и после этого выполнить генерацию структуры БД. При обратном проектировании последовательность действий прямо противоположная. Можно получить физическую модель на основе структуры БД и после этого автоматически сгенерировать концептуальную модель. Разумеется на каждом этапе можно вносить изменения в модели концептуального и физического уровней.
PowerDesigner четко отслеживает соответствие между концептуальным и физическим уровнем и "помнит" не только изменения в структуре объектов модели (уточнения связей, выполненные при переходе на физический уровень), но и их расположение на ER- диаграмме. При генерации этим "учетом изменений" можно управлять. Таким образом, автоматическая генерация - процесс, выполняемый в PowerDesigner очень эффективно и качественно.
Последовательность проектирования модели данных в PowerDesigner
Процесс построения информационной модели данных состоит из следующих шагов:
- определение сущностей;
- определение зависимостей между сущностями;
- задание первичных и альтернативных ключей;
- определение атрибутов сущностей;
- переход к физическому описанию модели (выполняется автоматически);
- редактирование имен таблиц и их атрибутов на физическом уровне (если в модели имеются, например, связи "многие ко многим" или иерархические рекурсивные связи и их надо уточнить);
- проектирование триггеров, процедур и ограничений;
- генерация базы данных.
Четкое разделение между концептуальной и физической моделями в PowerDesigner выражается в том, что на каждом уровне действуют соответствующие четко выраженные правила. На концептуальном уровне не выполняется миграция атрибутов первичного ключа в дочернюю сущность, так как это было бы уже не отображение реального мира.
Графические элементы диаграммы концептуальной модели
На диаграмме сущность изображается прямоугольником. Атрибуты располагаются внутри прямоугольника, обозначающего сущность. Атрибуты, составляющие идентификатор сущности, выделяются подчеркиванием
Связь (relationship) изображается линией, соединяющей сущности. Мощность связи показывается окончаниями линии. Мощность "один" изображается простой линией, мощность "много" - разветвленной линией. Если связь присутствует для всех экземпляров сущности, то линия перечеркивается, в противном случае - изображается окружностью на линии. Треугольник на линии связи обращен вершиной к родительской сущности (рисунок 22).
Рисунок 22 - Элементы диаграммы концептуальной модели
Создание физической модели данных
Физическая модель данных строится после окончания работы над КМД. Необходимость построения ФМД как отдельного шага проектирования объясняется требованием приведения описания сущностей и связей, определенных на стадии построения КМД, к структурам физической СУБД с учетом специфики последней. При генерации физической модели из КМД сущности становятся таблицами, атрибуты - колонками, для альтернативных ключей генерируется уникальный индекс, а идентификаторы становятся первичными ключами. Уникальный индекс автоматически назначается для каждого первичного ключа. Связь "один ко многим" приводит к генерации внешнего ключа и автоматической миграции атрибутов. На рисунке 23 показан фрагмент диаграммы ФМД для сущностей "отдел" и "сотрудник".
Рисунок 23 - Связь один ко многим на диаграмме физической модели
Связь "многие ко многим" (рисунок 24) порождает новую таблицу. Таким образом обеспечивается автоматическая нормализация модели. Идентификаторы сущностей, участвующих в связи, мигрируют в новую таблицу. При этом первичный ключ новой таблицы объединяет колонки первичных ключей таблиц, участвующих в связи.
Рисунок 24 - Исходная концептуальная модель
На рисунке 25 показан результат автоматического преобразования этой модели в физическую модель. Автоматически сгенерированная таблица может быть изменена разработчиком.
Для управления уникальностью строк и ускорения доступа к данным могут назначаться индексы. Для первичных и внешних ключей индексы формируются автоматически.
Рисунок 25 - Результат автоматического преобразования в физическую модель
Описание ссылочной целостности
В PowerDesigner существует несколько вариантов правил, которые могут применяться для обеспечения ссылочной целостности.
Каскадное удаление: удаление записи из родительской таблицы вызывает удаление всех записей из дочерней таблицы, ссылающихся на соответствующее значение ключа.
Каскадное обновление - модификация ключа в родительской таблице вызывает модификацию атрибутов внешнего ключа в соответствующих записях дочерней таблицы.
Запрет удаления - запрещается удаление тех записей из родительской таблицы, на которые существуют ссылки из дочерней таблицы.
Запрет модификации - запрещается модификация значения ключа в родительской таблице для записи, на которую существуют ссылки из дочерней таблицы.
Установка пустого значения: атрибуты внешнего ключа в дочерней таблице устанавливаются в NULL при удалении соответствующих записей из родительской таблицы.
– Конец работы –
Эта тема принадлежит разделу:
На сайте allrefs.net читайте: Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств…………………………………………………….12...
Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств.
Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:
Твитнуть |
Новости и инфо для студентов