Файл: Базы данных - уч. пособие.pdf

76

Глава 4. Технология проектирования реляционных баз данных

Атрибут может быть либо обязательным, либо необязательным. Обязатель-

ность атрибута означает, что атрибут не может принимать неопределенных зна-
чений (null values) (рис. 4.14).

Рис. 4.14 – Сущность «Студент» с набором атрибутов

Атрибут может быть либо описательным (т. е. обычным дескриптором сущно-

сти), либо входить в состав уникального идентификатора сущности. При создании
ER-модели необходимо учитывать требование уникальности экземпляров сущно-
сти, т. е. каждая сущность должна обладать уникальным идентификатором — мини-
мально допустимым набором атрибутов, однозначно характеризующих экземпляр
сущности. На рисунке 4.15 представлена сущность «Студент» с набором атрибу-
тов, часть из которых является обязательными (<M> — mandatory), атрибут «№ за-
четной книжки» является уникальным идентификатором сущности. Отметим, что
в среде PowerDesigner на этапе концептуального моделирования для каждого ат-
рибута задается тип данных.

Рис. 4.15 – Сущность «Студент» с набором атрибутов

В концептуальной модели данных, представленной в виде ER-диаграммы, сущ-

ности могут быть связаны между собой.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Связь — это графическая ассоциация между сущностями.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Одна сущность может быть связана с другой сущностью или сама с собою.

Связи обозначаются линиями с именами, место соединения связи и сущности
определяет кардинальность связи (0:1, 1:1, 0:М, 1:М, М:N).

В месте стыковки связи с сущностью используются трехточечный вход, если

для этой сущности в связи могут использоваться много (many) экземпляров сущно-
сти, и одноточечный вход, если в связи может участвовать только один экземпляр

4.2 Моделирование данных с помощью диаграмм «сущность-связь»

77

сущности. Обязательный конец связи изображается сплошной линией (или име-
ет символ |), а необязательный — прерывистой линией (или имеет символ o). На
концах связи указывается имя конца связи, обязательность связи, при необходи-
мости также указывается степень конца связи, то есть количество связываемых
экземпляров данной сущности.

На рисунке 4.16 представлен фрагмент ER-диаграммы предметной области

ВУЗ, отражающий связь между сущностями «Студент» и «Задолженность за обу-
чение», которая связывает студентов с их задолженностями. Конец связи с именем
«Для» позволяет связывать с одним студентом несколько задолженностей, причем
каждый экземпляр сущности «Задолженность за обучение» должен быть связан
хотя бы с одним студентом (конец связи обозначается именем «Имеет»), при этом
не каждый студент может иметь задолженность за обучение. Другими словами,
каждый студент может иметь задолженности за обучение и каждая задолженность
характерна только для одного студента.

Рис. 4.16 – Пример связи между сущностями ER-модели

4.2.2 Принцип нормализации ER-диаграмм

Нормальные формы ER-диаграмм имеют много общего с нормализацией реля-

ционных отношений.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Для первой нормальной формы ER-схемы характерно отсут-
ствие повторяющихся атрибутов. Производится выявление так
называемых неявных сущностей и образование на их основе новых
сущностей.

Для второй нормальной формы характерно отсутствие атри-
бутов, зависящих от части уникального идентификатора сущно-
сти. На основе этой части уникального идентификатора выде-
ляется отдельная сущность.

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

Нормальные формы более высоких порядков в ER-моделях не находят практи-

ческого применения.

78

Глава 4. Технология проектирования реляционных баз данных

4.2.3 Дополнительные элементы ER-модели

В ряде случаев при проектировании модели предметной области основных

понятий ER-модели недостаточно, тогда используются расширенные возможно-
сти технологии создания ER-моделей, среди них можно выделить следующие кон-
струкции:

1) домены. Под термином домен в данном случае следует понимать поимено-

ванный набор правил, которые являются общими для атрибутов, на кото-
рые распространяется действие этого домена. Преимущества использова-
ния доменов очевидны: определив правило один раз, можно добавлять его
к атрибутам различных сущностей с целью стандартизации их характери-
стик;

2) супертипы сущностей. Этот элемент модели присутствует не во всех

средствах проектирования ER-диаграмм, однако наличие его обеспечивает
возможность наследования типа сущности исходя из одного или несколь-
ких так называемых супертипов;

3) подтипы сущностей. Любая сущность ER-диаграммы может быть разде-

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

4.2.4 Получение схемы реляционной базы данных из
ER-диаграммы

Как мы отмечали выше, большинство средств проектирования ER-диаграмм,

среди которых можно выделить такие пакеты, как PowerDesigner, ERwin, IDEF-
Designer и другие, обеспечивают возможность генерации физической модели БД на
основе спроектированной концептуальной. Физическая модель может быть преоб-
разована в физическую базу данных практически любого, известного в настоящее
время формата. Процесс преобразования концептуальной модели в физическую,
т. е. фактически процесс перехода от ER-диаграммы к схеме реляционной базы
данных, можно разделить на этапы.

Этап 1. Каждая простая сущность преобразуется в плоскую таблицу (отноше-

ние). Имя сущности становится именем этой таблицы. Простой называется сущ-
ность, не являющаяся подтипом и не имеющая подтипов.

Этап 2. Каждый атрибут сущности преобразуется в поле таблицы (атрибут

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

Этап 3. Атрибуты, входящие в состав уникального идентификатора сущности,

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

Этап 4. Связи между сущностями типа «один-ко-многим» преобразуются во

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

4.2 Моделирование данных с помощью диаграмм «сущность-связь»

79

идентификатора с конца связи «один» и соответствующие поля являются внешним
ключом. Необязательные связи соответствуют полям, допускающим неопределен-
ные значения, обязательные связи — полям таблицы, не допускающим неопреде-
ленные значения.

Этап 5. Индексы в таблицах создаются для первичного ключа (уникальный

индекс) и внешних ключей. Также допускается возможность создания индексов на
основе других атрибутов сущности.

На рисунке 4.17 представлен фрагмент физической модели данных, сгенери-

рованной на основе концептуальной модели (рис. 4.16), и схемы БД в СУБД MS
Access, сгенерированной на основе этой физической модели. Заметим, что здесь
произошла миграция уникального идентификатора «№ зачетной книжки» сущно-
сти «Студент» в сущность «Задолженность за обучение», где этот атрибут вошел
в состав уникального идентификатора и стал также внешним ключом. Таким об-
разом, очевидно, что при создании концептуальной модели с помощью средств
моделирования внешние ключи создавать нет необходимости — они будут сгенери-
рованы автоматически в физической модели, а затем и в схеме базы данных.

Рис. 4.17 – Пример сгенерированной физической ER-модели и схемы БД

Очевидно, что использование средств автоматизированного моделирования спо-

собно значительно облегчить труд разработчиков баз данных. Современные сред-
ства моделирования позволяют не только проектировать ER-диаграммы различ-
ных уровней сложности, но и позволяют вести процесс эволюции моделей данных
с последующей эволюцией схем БД без разрушения созданных ранее объектов БД.
Также возможно построение глоссария модели данных с описанием всех объектов,
созданных в модели. Кроме этого, существует возможность реинжиниринга моде-
ли данных — когда на основе схемы БД строятся физическая и концептуальная ER-
диаграммы — это бывает очень полезно в случае необходимости модифицировать
созданную ранее БД, для которой отсутствует ее описание.

80

Глава 4. Технология проектирования реляционных баз данных

4.3 CASE-средства

4.3.1 Назначение и классификация CASE-средств

Как отмечалось выше, разработку любой информационной системы следует

начинать с проектирования концептуальной модели выбранной предметной об-
ласти. Значительно сэкономить временные ресурсы и создать нормализованную
структуру БД помогают CASE-средства (Computer Aided Software Engineering) ав-
томатизированного проектирования. В более широком понимании CASE-средства
предназначены для автоматизации процессов проектирования информационных
систем. В этом разделе мы остановимся на тех частях CASE-средств, которые от-
вечают за проектирование структурной части информационных систем, а именно
за построение концептуальной и физической моделей данных.

Большинство существующих на рынке CASE-средств можно классифициро-

вать по типам и категориям. Так, классификация по типам отражает функциональ-
ную ориентацию CASE-средств на те или иные процессы жизненного цикла. Клас-
сификация по категориям определяет степень интегрированности по выполняемым
функциям и включает отдельные локальные средства, решающие небольшие авто-
номные задачи (tools), набор частично интегрированных средств, охватывающих
большинство этапов жизненного цикла информационных систем (toolkit), и полно-
стью интегрированные средства, поддерживающие весь жизненный цикл информа-
ционных систем и связанные общим репозиторием [12]. По типам CASE-средства
можно классифицировать следующим образом [12]:

• CASE-средства, предназначенные для анализа и проектирования. Резуль-

татом использования CASE-средств этого типа являются предварительные
спецификации компонентов и интерфейсов информационной системы, ал-
горитмов и структур данных. К таким системам можно отнести Vantage
Team Builder (Cayenne), Designer/2000 (Oracle), Silverrun (CSA);

• CASE-средства, назначение которых состоит в построении и анализе кон-

цептуальной модели предметной области (PowerDesigner (Sybase), Design/
IDEF (Meta Software), BPwin (Logic Works));

• CASE-средства, предназначенные непосредственно для проектирования

структуры баз данных на основе спроектированной концептуальной мо-
дели предметной области в идеологии конкретной СУБД (AllFusion ERwin
Data Modeler, S-Designor (Powersoft), DataBase Designer (Oracle));

• CASE-средства реинжиниринга — наиболее современные CASE-средства,

предоставляющие возможности проведения широкомасштабного анализа
программных кодов и схем баз данных и формирования на их основе раз-
личных моделей и предварительных проектных спецификаций (Rational
Rose (Rational Software), Object Team (Cayenne)).

4.3.2 Обзор CASE-средств

Рассмотрим наиболее часто встречающиеся на российском рынке CASE-сред-

ства, в функции которых входит создание концептуальной и физической моделей
данных и проектирование на их основе схем БД. При этом будем оперировать
сведениями, представленными в [12–15].