КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
78
потом выделить соответствующую связь для редактирования и в описании супертипа ука-
зать, какой атрибут является дискриминатором. Тогда название этого атрибута повторяет-
ся рядом со знаком дискриминатора.
Анализируя CASE-средства, мы обращали внимание только на те характеристики,
которые оказывают непосредственное влияние на проектирование структуры базы дан-
ных. Однако функции CASE-средств этим не ограничиваются. Многие системы позволя-
ют задавать в модели ограничения целостности и генерируют программы (триггеры, хра-
нимые процедуры), проверяющие эти ограничения при эксплуатации БД. Кроме того,
CASE-средства могут генерировать программы ведения БД.
Многие CASE-средства позволяют экспортировать модели в другие системы и, на-
оборот, импортировать из других систем.
Отметим некоторые частные особенности конкретных CASE-средств.
В Design / IDEF (v. 3.5) при описании атрибута указывается, является ли он пер-
вичным ключом (Primary Key – PK), инвертированным входом (Inventory Entry – IE). Под-
ход, при котором эти вопросы приходится решать на стадии моделирования Предметной
Области, представляется не удачным, так как:
• «ключ» – понятие, относящееся к реляционной модели, а не к предметной области;
• что выбрать в качестве ключа, надо решать на стадии проектирования даталогиче-
ской модели, а не инфологического моделирования, и желательно – автоматически;
• специалисту, строящему ER-модель, необходимо знать, что такое «ключ»,
«внешний ключ», «альтернативный ключ», уметь их определять и выбирать,
что не так уж просто, особенно, если речь идет о составном ключе (как отмеча-
лось выше, желательно активное участие специалистов предметных областей в
разработке ER-модели, и требовать ото всех их знания таких специфических
вопросов теории баз данных нежелательно);
• для нескольких атрибутов можно указать, что он является PK. На самом деле
это означает, что каждый из таким образом обозначенных атрибутов является
элементом составного ключа, а не самим ключом, что с точки зрения реляцион-
ной теории принципиально важно различать;
• термин «инвертированный вход» вообще очень не подходит для ER-модели, так
как определяет способ организации хранения данных (для «инвертированных
входов» строится индекс);
• система не проверяет ошибочные с точки зрения реляционной модели опреде-
ления атрибутов. Так, можно объявить какой-то атрибут одновременно и пер-
вичным, и вероятным ключом, или объявить один атрибут первичным ключом
(т.е. ключ простой) и его же включить в состав составного альтернативного
ключа, или можно не задать длину атрибута, и при этом генерируется описание
таблицы БД без указания длины поля.
Если в Design / IDEF вы изобразили объект и установили с ним связь 1 : М от другого
объекта, то сразу в «подчиненный» объект мигрирует ключ из родительского объекта. Это же
закладывается автоматически и в алгоритм проектирования, что далеко не всегда целесооб-
разно (то же самое наблюдается и в ERwin и многих других системах). Недостатками такого
подхода является то, что вместо инфологического моделирования на самом деле как бы сразу
происходит проектирование отношения (таблицы БД), но: во-первых, связь 1 : M может быть
отражена в БД разными путями (см. описание алгоритма), а, во-вторых, на уровне ER-модели
происходит дублирование информации (наличие связи между сущностями отображается
дважды: линией на схеме и повторением ключа «родительской» сущности).
В системе имеется целый ряд ошибок, связанных с преобразованием ER-модели в
целевую схему БД. Так, например, если изобразить связь М : М (которая называется не-