Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 20)

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

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

Описание связи

После того как были определены хотя бы две сущности, можно задавать связи между ними. Для определения связи можно щелкнуть по четвертой кнопке сверху (линия с точкой на конце) на панели ин­струментов, изображенной слева на экране (или выполнить команду Create/Relationship, или нажать комбинацию клавиш [Ctrl]+[R]). По­сле этого курсор с «прикрепленной» к нему линией со стрелочкой надо позиционировать на значке того объекта, от которого должна начинаться связь, и, не отпуская левую клавишу мыши, протянуть связь до того объекта, на котором она должна оканчиваться.

После этого появится окно определения связи Define Relationship (рис. 2.51). В первой строке этого окна (Entity) указывается имя ис­ходного объекта, от которого идет связь; в третьей строке с таким же названием (Entity) - имя объекта, к которому направлена связь. В окне Relationship обязательно должно быть указано имя связи в пря­мом направлении (в нашем примере это связь от объекта ГРУППА к объекту СТУДЕНТ и назвать ее можно, например, «включает» или «состоит»). В окне Inverse можно (но не обязательно) задать имя свя­зи в обратном направлении (для нашего примера это может быть имя «учится»). Переключатель Separate Lines становится активным только в том случае, если имя обратной связи задано. Этот переключатель определяет только то, как на экране располагаются надписи прямой и обратной связи.

Для каждой связи должен быть определен тип связи (Relationship Туре) и кардинальное число (Relationship Cardinality).

Рис. 2.51. Вид окна описания связи между объектами

В Design/IDEF различают следующие типы связи:

• Identifying (идентифицирующая);

• Non-Identifying (неидентифицирующая);

• Non-Specific (неспецифическая).

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

На рис. 2.52 изображены все возможные виды связи в Design/IDEF. Идентифицирующая (сплошная линия) и неидентифицирующая (пунк­тирная линия) связи отличаются не только видом линии, но и тем, куда мигрирует ключ исходной сущности: в первом случае он становится ча­стью ключа «целевой» сущности, а во втором - неключевым атрибутом (но в том и в другом случае он является внешним ключом - FK).

Рис. 2.52. Виды связи в Desing/IDEF1X

На рис. 2.53 приведены примеры использования идентифициру­ющей и неидентифицирующей связи. Выбор варианта будет опреде­ляться тем, как обозначаются участки в конкретной предметной об­ласти. Если выбрана неидентифицирующя связь, то возможно зада­ние дополнительной характеристики этой связи - разрешаются ли «пустые», неопределенные значения внешнего ключа (Null Allowed). На рис. 2.53 изображены ситуации и с разрешенными (рис. 2.53, б), и с запрещенными (рис. 2.53, а) Null-значениями. Но это сделано для того, чтобы показать, как графически различается изображение в каж­дой из этих ситуаций. Выбор Null Allowed означает, что возможно наличие участков, не приписанных ни к какому цеху, что в реальных предметных областях скорее всего недопустимо.

Если к сущности идет идентифицирующая связь, то сущность называется зависимой по идентификации. Такая сущность, как мы видим, изображается прямоугольником с закругленными углами. Ключ зависимой по идентификации сущности чаще всего бывает состав­ным, одним из элементов которого является ключ исходного объекта (рис. 2.53, в). Идентифицирующую связь нельзя провести, если у ис­ходного объекта не задан ключ. Знак зависимой по идентификации сущности нельзя внести в схему непосредственно; углы закругляют­ся автоматически, при объявлении соответствующей связи.

Рис. 2.53. Примеры изображения связи между объектами:

а - неидентифицирующая (не разрешено «пустое» значение);

б - неидентифицирующая («пустое» значение разрешено);

в - идентифицирующая

Кроме указания типа связи для каждой связи задается кардиналь­ное число (см. рис.2.51), указывающее количественные характерис­тики связи. В IDEF1X могут быть выражены следующие мощности связей:

• каждый экземпляр сущности-родителя может иметь нуль, один или более одного связанного с ним экземпляра сущности-потомка (Zero, One or Many);

• каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка (Zero or One [Z]);

• каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка (One or Many [P])

• каждый экземпляр сущности-родителя связан с некоторым фик­сированным числом экземпляров сущности-потомка (Exactly).

В последнем из рассмотренных случаев кроме того, что в него устанавливается переключатель, в окне следует указать число. На­пример, если набираются группы для обучения в компьютерных клас­сах и занятия не начинаются, пока не наберется 10 человек, но и большее число учащихся недопустимо, то следует выбрать вариант Exactly и поставить число 10.

На рис. 2.54 приведены графические представления всех допус­тимых в IDEF1X типов мощности связи, на рис. 2.55 - примеры ис­пользования разной кардинальности связи.

Рис. 2.54. IDEF1X. Виды мощности связи:

cв₁ - Zero, One or Many; св₂ - Zero or One [Z];

св₃ - One or Many [P]; св₄ – Exactly

Рис. 2.55. Фрагмент ER-модели

(пример использования разной кардинальности связи)

Описание обобщенного объекта

В Design/IDEF нет специального графического значка для обо­значения обобщенного объекта. Но возможность отображать обоб­щенные объекты есть. Для этого следует изобразить сначала родовую сущность. Для нее нужно указать все идентификаторы изображаемо­го объекта, общие атрибуты, присущие всем объектам класса, а так­же тот атрибут, по которому класс разбивается на подклассы (такой атрибут следует обозначить как дискриминатор). На рис. 2.56 пока­зан вид экрана описания родовой сущности, а на рис. 2.57 - соответ­ствующее ему графическое представление. Как видно из рис. 2.57, дискриминатор на схеме изображается окружностью с прилегающи­ми к ней двумя параллельными линиями. При объявлении дискрими­натора всегда первоначально появляется такой знак. Он означает пол­ное разбиение класса на подклассы (т.е. каждый элемент класса обя­зательно относится к одному из выделенных подклассов). Если это не так, то нужно выделить значок дискриминатора, после чего вос­пользоваться переключателем «Полный-неполный дискриминатор» (шестая кнопка сверху в инструментальном меню) или позицией меню Create/Toggle Discriminator.

Рис. 2.56. Вид экрана описания родового объекта

Рис. 2.57. Графическое представление родового объекта

Далее необходимо изобразить сущности, соответствующие видо­вым объектам. При этом ключевые поля описывать не надо. В каче­стве атрибутов этих сущностей следует описывать те атрибуты, кото­рые присущи именно этому подклассу (рис. 2.58). Затем нужно про­вести связи от значка дискриминатора к значкам видовых объектов, после чего схема примет вид, показанный на рис. 2.59. При этом клю­чи родового объекта автоматически мигрируют в видовые объекты, а значки видовых объектов станут иметь закругленные углы.

Рис. 2.58. Графическое представление видовых сущностей

(промежуточный этап)

Рис. 2.59. IDEF1X ERD. Пример изображения обобщенного объекта

Изображение обобщенного объекта может выглядеть по-разному (рис. 2.60). Если дискриминатор имеет вид окружности (рис. 2.60, а), подчеркнутой двойной линией, это означает, что подклассы в сово­купности составляют полный класс. Если дискриминатор изображен в виде окружности (рис. 2.60, б), подчеркнутой одинарной линией, - значит, подклассы в совокупности не составляют полный класс. На рис. 2.60, в представлен вариант, показывающий возможность клас­сификации сущностей по разным несоподчиненным признакам.

Рис. 2.60. Варианты изображения обобщенного объекта:

а - полный класс; б - неполный класс; в - классификация

по несоподчиненным признакам

На рис. 2.61 изображен пример обобщенного объекта, классифи­цированного по нескольким признакам.

Рис. 2.61. Пример изображения обобщенного объекта,

классифицированного по нескольким признакам

2.5.2. Методология построения ER-модели при использовании Design/IDEF

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

В разд. 2.3.4 были изложены в общем виде рекомендации по по­строению ER-модели в зависимости от изобразительных средств и алгоритмов перехода от ER-модели к логической модели реляцион­ной базы данных. Здесь эти рекомендации конкретизированы для си­стемы Design/IDEF.

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

Характеристики

Список файлов книги