ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

РЯЗАНСКИЙ ГОСУДАРСТВЕННЫЙ РАДИОТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Автоматизация проектирования баз данных в среде

Sybase PowerDesigner

Методические указания к лабораторным работам

Рязань 2010

УДК 004.655.3 (078.8)

Автоматизация проектирования баз данных в среде Sybase PowerDesigner: Методические указания к лабораторным работам. / Рязан. гос. радиотехн. универ.; Сост. А.В. Благодаров, Р.В. Тишкин,

Рязань, 2010. 35 с.

Содержат рекомендации для проведения лабораторных работ, посвященных изучению CASE-средства проектирования баз данных

Sybase PowerDesigner.

Предназначены для студентов очной и заочной форм обучения специальностей 230101 «Вычислительные машины, комплексы, системы и сети», 230104 «Системы автоматизированного проектирования», 230105 «Программное обеспечение вычислительной техники и автоматизированных систем», 080801 «Прикладная информатика», по дисциплинам «Базы данных», «Проектирование баз данных», «Клиент-серверные приложения баз данных».

Автоматизация проектирования баз данных в среде Sybase PowerDesigner

Составитель

Бл а г о д а р о в Андрей Витальевич

Ти ш к и н Роман Валентинович

1

Автоматизация проектирования баз данных в среде Sybase PowerDesigner

Цель работы: Получить навыки проектирования реляционных баз данных с помощью программы Sybase PowerDesigner 15.

Основные возможности программы PowerDesigner

Программа Sybase PowerDesigner 15 представляет собой CASEсредство для проектирования баз данных и программных систем в целом. Термин CASE (Computer Aided Software Engineering) означает автоматизированное проектирование программного обеспечения, в данном случае баз данных. Использование PowerDesigner существенно сокращает время, затрачиваемое на проектирование БД.

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

•создание концептуальной модели БД;

•создание логической модели БД;

•создание физической модели БД;

•автоматическая генерация SQL-скрипта для создания структуры БД;

•обратное проектирование БД.

Концептуальная модель (CDM – Conceptual Data Model)

позволяет представить структуру БД в наиболее абстрактном виде. В рамках данной модели можно задавать сущности, их атрибуты и связи между сущностями.

Логическая модель (LDM – Logical Data Model) позволяет представить структуру БД в несколько менее абстрактном виде, чем CDM. В частности, в сущности добавляются атрибуты внешних ключей для связей c другими сущностями. LDM, как и CDM, совершенно не зависит от СУБД, на которой в дальнейшем будет реализовываться БД.

Физическая модель (PDM – Physical Data Model) позволяет представить структуру БД с учетом особенностей выбранной СУБД. Сущности заменяются таблицами, для некоторых связей также создаются таблицы. Можно задать необходимые частные ограничения

2

целостности. Для одной LDM можно создать произвольное число независимых PDM под разные СУБД.

Полная независимость концептуальной и логической моделей от конкретной СУБД и возможность создания произвольного числа физических моделей для разных СУБД является важным достоинством программы PowerDesigner.

К другим полезным возможностям программы по автоматизации процесса проектирования БД, не рассмотренным в данной работе, можно отнести:

•создание моделей многомерных БД;

•создание XML–моделей.

Порядок проектирования базы данных

Процесс проектирования БД с помощью программы PowerDesigner может выглядеть следующим образом.

1.Создание проекта для разрабатываемой БД.

2.Создание концептуальной модели (CDM), в которой указываются выявленные сущности, их ключи и связи между ними.

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

4.Создание физической модели (PDM), которая генерируется на основе LDM. При генерации PDM выбирается определенная СУБД, особенности которой учитываются при создании физической модели. Для полей таблиц при необходимости уточняются типы данных. Указываются частные ограничения целостности.

5.Генерация SQL-скрипта для создания структуры БД. Полученный скрипт можно исполнить средствами СУБД и получить готовую БД.

Будем рассматривать процесс проектирования БД на следующем примере. Пусть требуется спроектировать БД для хранения информации об учебном процессе в вузе. Краткое неформальное описание предметной области приведено ниже.

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

4

Сохраним проект, выполнив пункт меню File–Save All. Проект сохраняется в файле с расширением *.prj.

Создание концептуальной модели

Создадим концептуальную модель, выполнив пункт главного меню File–New Model. В открывшемся окне (рисунок 2) выберем значок ConceptualData и зададим имя модели, например «Вуз».

Рисунок 2 – Создание новой концептуальной модели

Сохраните модель, выполнив пункт меню File–Save All. Концептуальная модель сохранится в файле с расширением *.cdm.

Выполним некоторые необходимые настройки программы PowerDesigner. Зайдем в пункт меню Tools–Model Options (рисунок 3). Выберем тип нотации (Notation) Entity/Relationship. Данная нотация известна как Crow Foot (воронья лапа). При необходимости можно использовать и другие нотации, например: IDEF1X или Barker. Разрешим использование атрибутов с одинаковыми именами в разных сущностях, сняв флажок Data Item – Unique code. Если этого не сделать, то не удастся, например, атрибут ID использовать в двух разных сущностях.

5

Рисунок 3 – Настройка концептуальной модели

Зайдем в пункт меню Tool – Display Preferences (настройки отображения). Выберем категорию Content – Relationship (связи) и установим флажок Cardinality, чтобы на диаграмме отображалась кардинальность связи (0,1; 1,1; 0,n или 1,n).

В категории Content – Entity (сущности) уберем флажок Identifiers (рисунок 4), чтобы не отображались идентификаторы сущностей (на наш взгляд, идентификаторы сущностей излишни, достаточно показать ключ). Зададим отображение только ключевых атрибутов

(Attributes–Primary attributes). Уберем отображение типов данных

(Data types), признака обязательности атрибута (Mandatory).

6

Рисунок 4 – Настройка отображения сущностей концептуальной модели

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

Нарисуем ER-диаграмму для нашей БД.

Сначала создадим все сущности. Чтобы создать сущность, выберем в окошке Палитра (Palette) кнопку Entity и разместим сущность в требуемом месте области модели. Чтобы отобразить палитру следует выполнить действие Tools – Customize Toolbars и

установить флажок для пункта Palette.

Для сущности зададим имя и ключ. Для этого сделаем двойной щелчок по сущности или выполним для сущности пункт контекстного меню Properties (свойства).

В открывшемся окне (рисунок 5) зададим поля Name (имя сущности) и Code (имя сущности в коде). Различие просто имени и имени в коде заключается в том, что просто имя будет отображаться лишь на

7

диаграммах, а имя в коде будет использоваться в дальнейшем в SQLскрипте для создания таблицы БД. Просто имя пишут обычно на русском языке и делают максимально понятным для человека, а имя в коде обычно пишут латинскими буквами без пробелов и спецсимволов так, чтобы достичь максимальной совместимости с любой СУБД. При желании, конечно, можно сделать эти два поля одинаковыми. Для этого удобно использовать кнопки = справа от поля. Также зададим комментарий к сущности (поле Comment), который в дальнейшем может быть добавлен в SQL-скрипт. Например, зададим просто название сущности Занятие, и название в коде Lesson.

Рисунок 5 – Задание имени сущности

Затем перейдем на вкладку Attributes (атрибуты), представленную на рисунке 6. Настроим список отображаемых

сведений об атрибуте, нажав кнопку (Customize Columns and Filter). Выберем отображение лишь следующих данных:

•Name – имя атрибута;

•Code – имя атрибута в коде;

•Comment – комментарий;

•Data Type – тип данных;

8

•Primary Identifier – ключ;

•Displayed – отображаемое поле.

Рисунок 6 – Задание ключа сущности

Имя атрибута и имя атрибута в коде соотносятся так же, как и понятия «просто имя» и «имя в коде» для сущности. Настройка выполняется только один раз.

Зададим ключ сущности, создав новый атрибут, например, с именем ID, и задав ему свойство P (Primary Identifier ), а также выбрав подходящий тип данных, например Serial (счетчик). В результате получим следующее изображение сущности (рисунок 7).

Рисунок 7 – Изображение сущности

Аналогичным образом создадим все остальные сущности и их ключи, как показано в таблице 1.

9

Обратите внимание, что для сущностей Выпускающая кафедра и Общая кафедра ключи пока не задаются, так как они будут сформированы автоматически несколько позже.

Зададим связи между сущностями. Для этого выберем на палитре

инструмент – Relationship (связь). С помощью мыши проведем связь от главной сущности к подчиненной. Главной будем считать ту, которая связана к одному, а подчиненной – ко многим. Для связи многие ко многим направление, в котором проводится связь, не имеет значения. Например, проведем связь между сущностями Кафедра и Преподаватель. На одной кафедре может работать много преподавателей, преподаватель может работать не более, чем на одной кафедре. Получается связь, показанная на рисунке 8.

Рисунок 8 – Пример связи

Зададим характеристики связи. Для этого выполним двойной щелчок мыши по связи или выполним для нее пункт Properties (свойства) контекстного меню.

В открывшемся окне (рисунок 9) зададим имя связи (Name) и имя связи в коде (Code). Имя связи обычно задают в виде глагола или предлога, а имя связи в коде – в виде имен в кодах двух связываемых сущностей. В нашем примере это будет Работает и TeacherChair. Комментарий к связям обычно не пишут.

10

Рисунок 9 – Задание имени связи

Теперь перейдем на вкладку Cardinalities (кардинальность), изображенную на рисунке 10. Здесь задаются основные характеристики связи, к каковым относят следующее.

1.Степень связи, которая бывает: один к одному (One – One); один ко многим (One – Many); многие к одному (Many – One); многие ко многим (Many – Many).

2.Доминантная сущность (Dominant role) (только для связи один к одному). Показывает, какая из двух сущностей является главной (доминантной). В оставшейся подчиненной сущности в дальнейшем будет создан внешний ключ.

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

11

4.Зависимость (Dependent), является ли связь с данной сущностью идентифицирующей. Если признак установлен, то в дальнейшем внешний ключ сущности будет входить в состав ключа этой же сущности.

5.Кардинальность связи для каждого из двух направлений связи. Кардинальность A to B показывает, со сколькими экземплярами

сущности B может быть связан один экземпляр сущности A. Различают кардинальности: 0..1, 1..1, 0..n, 1..n. Например, кардинальность Преподаватель – Кафедра будет 0..1 (преподаватель может работать не более чем на одной кафедре). Кардинальность Кафедра – Преподаватель будет 0..n (на кафедре может работать множество преподавателей). Кардинальность зависит от степени и обязательности связи и наоборот.

Рисунок 10 – Задание кардинальности связи

На рисунке 11 приведены примеры обозначений связей с различными степенями связей, и соответственно, различными кардинальностями.

12

а)

б)

в)

г)

Рисунок 11 – Обозначения связей

На рисунке 11-а изображена связь один ко многим, на которой экземпляр сущности A может быть связан с несколькими экземплярами сущности B. Экземпляр сущности B обязательно связан с одним и только одним экземпляров сущности A.

На рисунке 11-б изображена связь один ко многим, на которой экземпляр сущности A может быть связан с несколькими экземплярами сущности B. Экземпляр сущности B может связан не более чем с одним экземпляров сущности A.

На рисунке 11-в изображена связь многие ко многим, на которой экземпляр сущности A может быть связан с несколькими экземплярами сущности B. Экземпляр сущности B может связан с несколькими экземплярами сущности A.

На рисунке 11-г изображена связь один к одному, на которой экземпляр сущности A может быть связан не более, чем с одним экземплярам сущности B. Экземпляр сущности B может быть связан не более, чем с одним экземплярам сущности A. Сущность А является доминантной.

Для реализации ролевых и обобщающих сущностей в PowerDesigner используется понятие наследования (Inheritance). В рамках наследования выделяется одна родительская сущность (Parent entity), являющаяся аналогом обобщающей сущности, и множество

13

дочерних сущностей (Child entity), являющиеся аналогом ролевых сущностей. Родительская сущность содержит общий набор атрибутов,

адочерние сущности – частные наборы атрибутов.

Внашем примере можно выделить родительскую сущность

Кафедра и две дочерние сущности: Выпускающая кафедра и Общая кафедра.

Для реализации наследования выберем на палитре инструмент

– Inheritance. С помощи мыши соединим дочернюю сущность Выпускающая кафедра с родительской сущностью Кафедра. Затем соединим вторую дочернюю сущность Общая кафедра с символом

наследования . Зайдя в свойства символа наследования, зададим имя наследования, которое обычно совпадает с именем родительской сущности. Полученный фрагмент диаграммы изображен на рисунке

12.

Рисунок 12 – Пример наследования Различают следующие виды наследования.

1.Обычное наследование. Обозначается символом

2.Взаимоисключающее наследование (Mutually exclusive inheritance). При таком наследовании экземпляр родительской сущности может быть связан с экземпляром только одной дочерней

сущности. Обозначается символом . На физическом уровне такое наследование обычно реализуется путем добавления специальных триггеров к таблицам дочерних сущностей. К сожалению, автоматическая генерация таких триггеров в PowerDesigner не предусмотрена, это придется сделать своими руками.

3. Законченное наследование (Complete inheritance). При таком наследовании экземпляр родительской сущности обязательно должен быть связан с экземпляром некоторой дочерней сущности. На физическом уровне такое наследование реализуется путем

использования механизма транзакций. Обозначается символом

14

4. Взаимоисключающее законченное наследование. Является

комбинацией видов 2 и 3. Обозначается символом .

Вид наследование задается на вкладке General свойств наследования (рисунок 13).

Рисунок 13 – Выбор вида наследования

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

На вкладке Generation необходимо задать особенности генерации сущностей при переходе к логической или физической модели. Установим флажки Generate parent (генерировать родительскую сущность) и Generate child (генерировать дочерние сущности), а также выберем радио-кнопку Inherit only primary attributes (наследовать только ключевые атрибуты), как показано на рисунке 14.

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

15

Рисунок 14 – Выбор вида наследования

На рисунке 15 показан фрагмент диаграммы после настройки наследования.

Рисунок 15 – Пример наследования

Создадим все остальные связи между сущностями, как показано на рисунке 16, тем самым получим готовую CDM.