2.5. Использование Design/idef для проектирования баз данных

2.5.1. Построение er-модели при использовании Design/idef Общая характеристика

Design/IDEF является комплексной системой автоматизации про­ектирования ИС. Она объединяет в себе несколько методологий, каж­дая из которых предназначена для построения моделей определенно­го типа. Для построения ER-модели используется методология IDEF1X.

Нотация языка ER-моделирования, алгоритм проектирования це­левой реляционной модели и, как следствие, подход к моделирова­нию существенно отличаются от базовой модели. Изобразительные средства нотации языка ER-моделирования в Design/IDEF более бед­ные, чем в базовой модели. Процесс построения ER-модели в Design/ IDEF практически сводится к описанию реляционной модели данных другими изобразительными средствами (каждому объекту ER-моде­ли в Design/IDEF соответствует таблица реляционной базы данных). В связи с этим рекомендуется сначала изучить главу 3, а потом, ис­пользуя эти знания, строить ER-модель в нотации Design/IDEF.

Укрупненная схема работы с Design/IDEF при построении ER-модели показана на рис. 2.39.

После загрузки Design/IDEF и выбора команды File/New экран имеет вид, изображенный на рис. 2.40. В окне Methodology будет высвечиваться название той методологии, с которой работали в пре­дыдущем сеансе. Если это не методология IDEF1X, то следует на­жать на кнопку в правой стороне этого окна, из ниспадающего спис­ка выбрать требуемую методологию (рис. 2.41).

Начальный экран проектирования после выбора методологии IDEF1X изображен на рис. 2.42.

После этого можно приступить к построению ER-модели, а мож­но сначала выбрать целевую СУБД - ту СУБД, для которой ведется проектирование базы данных. Для этого следует выбрать команду Edit/ Set Options. В появившемся окне IDEF Options следует активизиро­вать переключатель IDEF1X (рис. 2.43) и в окне Target Datadase выб­рать нужную СУБД из ниспадающего списка поддерживаемых систе­мой СУБД. Выбор целевой СУБД окажет влияние на список допусти­мых типов данных при описании атрибутов. На методологию построения модели этот выбор влияния не оказывает. Выбор целевой СУБД можно провести на любом этапе проектирования. При этом типы данных будут автоматически преобразованы в соответствующие им типы в новой целевой СУБД.

Описание сущности

Построение новой ER-модели можно начать только с создания новой сущности. Для того чтобы построить новую сущность, надо щелкнуть по третьей кнопке сверху (прямоугольник, разделенный на два сектора) на панели инструментального меню, изображенного слева на экране (или выполнить команду Create/Entity, или нажать комбинацию клавиш [Ctrl] +[Е]), и, позиционировав курсор с «прикреплен­ным» к нему квадратом в нужном месте экрана, нажать левую кнопку мыши. На экране появится окно определения сущности (Define Entity), изображенное на рис. 2.44. Система автоматически присваи­вает каждой создаваемой сущности уникальный идентификатор (Entity ID). В поле Name следует указать имя сущности. Кроме ос­новного имени можно задать еще и Aliases (псевдоним) - имя, ис­пользуемое в качестве синонима

Рис. 2.39. Укрупненная схема создания модели Design/IDEF

Рис. 2.40. Вид экрана после загрузки системы Design/IDEF

и выбора команды File/New

Рис. 2.41. Вид окна при выборе методологии

Рис. 2.42. Начальный вид окна проектирования

после выбора методологии IDEF1X

Рис. 2.43. Вид окна задания опций

.

Рис. 2.44. Вид окна определения сущности

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

После этого следует перейти к описанию атрибутов сущности и щелкнуть по кнопке Add в окне определения сущности. При этом появится окно определения атрибута (Define Attribute), изображен­ное на рис. 2.45.

Рис. 2.45. Вид окна определения атрибута

В поле Name следует записать наименование атрибута, в поле Data Туре - выбрать тип, присущий данному атрибуту. Список доступных типов полей зависит от выбранной целевой СУБД. Как известно, не­которые типы полей имеют фиксированную длину, и для них нет нуж­ды указывать длину (Length), для других - должна указываться дли­на; для числовых полей с дробной частью нужно указывать точность (Precision).

В реляционной теории есть понятия «ключ» и «вероятный ключ». Эти понятия характеризируют не предметную область, а именно таб­лицу реляционной базы данных. При преобразовании ER-модели в схему реляционной базы данных в Design/IDEF каждой сущности ста­вится в соответствие таблица реляционной базы данных, и при опи­сании сущности требуется определить, какой атрибут (или несколько атрибутов) выбран в качестве первичного ключа. Эти атрибуты дол­жны быть помечены галочкой в переключателе Primary Key.

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

Если есть несколько альтернативных (вероятных) ключей, то нуж­но все остальные описать как альтернативные. Вероятные ключи по­мечаются галочкой в переключателе Alternate Key. Так как вероят­ных ключей может быть несколько, то в поле справа от свойства Alternate Key необходимо поставить порядковый номер. Если аль­тернативный ключ является составным, то все составляющие его ат­рибуты следует пометить одним и тем же номером в поле рядом с переключателем Alternate Key.

При проектировании баз данных учитывается множество разных факторов, и в том числе характер запросов. Если по какому-либо полю часто осуществляется выборочный поиск, то по такому полю обычно проводят индексирование. Такие проиндексированные поля иногда называют «инверсным входом». При описании сущности именно та­кие атрибуты следует пометить галочкой в переключателе Inversion Entry. Инверсных входов, так же как и вероятных ключей, может быть несколько. Поэтому в поле справа от свойства Inversion Entry необ­ходимо поставить порядковый номер.

Как известно (см. разд. 2.2), объекты бывают не только просты­ми, но и обобщенными. То свойство, по которому классы делятся на подклассы, в Design/IDEF называется «дискриминатором» (Discriminator). При описании соответствующего свойства следует это отметить галочкой в переключателе Discriminator.

Назначение свойств Name и Aliases в окне определения атрибута аналогично соответствующим характеристикам, задаваемым при опи­сании самого объекта в окне определения сущности.

После описания очередного атрибута следует опять щелкнуть по кнопке Add и задать описание следующего атрибута. После того как определены все атрибуты описываемого объекта, щелкните по кнопке ОК.

На рис. 2.46 приведен фрагмент описания сущности СОТРУДНИК. Если на этом завершить описание атрибутов и щелкнуть по кнопке ОК, то получим графическое представление описанного объекта (рис. 2.47).

Рис. 2.46. Экран описания объекта (пример)

Рис. 2.47. Пример изображения объекта (вариант 1)

В общем виде графическое представление сущности отражено на рис. 2.48. Для обозначения сущности используют прямоугольник, раз­деленный на два сектора; в верхнем секторе записываются ключевые атрибуты, в нижнем - все остальные. Рядом с атрибутами, являющи­мися альтернативными ключами, в скобках ставятся буквы (АК).

Рис. 2.48. IDEF1X ERD. Обозначение объекта

Если вы уверены, что ФИО вместе с Датой_рождения является уни­кальной совокупностью атрибутов и их следует описать как вероятный ключ, то графическое представление подобного объекта будет таким, как это показано на рис. 2.49. Несмотря на то, что в данном примере ФИО вошло в альтернативный ключ, его следует оставить и как инвер­сный вход, поскольку по ФИО часто осуществляется поиск.

Рис. 2.49. Пример изображения объекта (вариант 2)

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

Альтернативных ключей у одной сущности может быть несколь­ко (рис. 2.50). Обратите внимание на разницу в изображении сущно­стей на рис. 2.49 и 2.50. В первом случае сущность имеет один со­ставной альтернативный ключ, во втором - два простых.

Рис. 2.50. Изображение сущности КАФЕДРА