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

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

Рис. 2.70. Типы связи и класс членства. Соответствие базовой модели

и Design/IDEF1X

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

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

Рис. 2.71. Изображение нескольких связей между парой сущностей

На самом деле, если посмотреть на соответствующее сгенериро­ванное системой описание объекта на SQL, в нем присутствуют оба атрибута связи:

CREATE TABLE игра

(дата DATE NOT NULL,

счет CHAR NULL,

код_команды CHAR NOT NULL,

код_команды CHAR NOT NULL).

Таким образом, в системе имеется некоторое несоответствие меж­ду графическим и аналитическим представлением сущности. Следу­ет также обратить внимание на некоторые неточности в полученном описании. Так, двум полям в таблице «Игра» дано одинаковое имя «код_команды», что недопустимо.

В связи с тем, что ER-модели играют несколько разных ролей в процессе проектирования информационных систем, среди которых важнейшей является «адекватное отображение предметной области и использование ER-модели для общения между всеми участниками (как проектировщиками, так и заказчиками) процесса создания ИС», при применении CASE-средств, не обладающих развитым многова­риантным алгоритмом проектирования, рекомендуется создавать по меньшей мере две модели:

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

• ER-модель, которая будет использоваться для генерации схемы базы данных.

Поскольку Design/IDEF не производит преобразование имен сущ­ностей и атрибутов в соответствии с требованиями целевой СУБД, то в модели, предназначенной для генерации схемы базы данных, имена сущностям и атрибутам следует давать такие, которые допустимы в целевой СУБД.

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

2.6. Особенности моделирования в ERWin

2.6.1. Общие замечания

Уточнение терминологии

В ERWin, как, впрочем, и в некоторых других CASE-системах, применяется терминология, отличающаяся от традиционно исполь­зуемой в теории баз данных. Так, понятие «физическая модель» тра­диционно использовалось в литературе по БД для описания способа хранения данных в запоминающей среде. В ERWin физической моде­лью называется описание (логической) структуры базы данных в сре­де выбранной целевой СУБД.

Нотации, используемые при построении

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

Для создания новой модели после запуска системы нужно выб­рать позицию меню File/New.

При изображении ER-модели в ERWin можно выбрать нотацию, которая будет использоваться. Для того чтобы осуществить переклю­чение между нотациями, следует выбрать позиции меню Options/ Preferences и в появившемся окне Preferences выбрать вкладку Methodology. Как видно из рис. 2.72, для логического представления ER-модели можно осуществлять выбор из двух нотаций: IDEF1X (Integration DEFinition for Information Modeling) и IE (Information Engineering).

Рис. 2.72. Выбор нотации для представления логической модели

Нотация IDEF1X является стандартной и, по сути, не отличается от соответствующей нотации, рассмотренной при описании Design/ IDEF.

Чтобы панель инструментов (ERWin Toolbox) для случая исполь­зования нотации IDEF1X появилась на экране, надо выбрать пози­цию меню Window/Toolbox (рис. 2.73).

Рис. 2.73. Вид панели инструментов

для случая использования нотации IDEF1X

Реализации систем, естественно, несколько отличаются друг от друга. Так, если в Design/IDEF вид связи задается при ее описании, то в ERWin имеются три кнопки , которые соответствуют идентифицирующей связи, связи «многие ко многим» и неидентифицирующей связи (в порядке их расположения на панели). Кнопка используется при создании обобщенного объекта.

Вид панели элементов для случая использования нотации IE пред­ставлен на рис. 2.74. Различия в этих нотациях относятся к классу несущественных (см. разд. 2.3). Разница заключается в том, что для обозначения множественного конца линии связи в нотации IDEF1X используется точка, а в нотации IE - «лапка», а также используется другой графический символ при отображении обобщенной сущ­ности.

Рис. 2.74. Вид панели инструментов

для случая использования нотации IE

Модель, построенная в одной нотации, может быть автома­тически преобразована в другую нотацию. Для этого следует опять вернуться в окно Preferences (см. рис. 2.72), выбрав меню Options/ Preferences, и выбрать на вкладке Methodology другую мето­дологию.

Далее рассмотрим создание логической модели в нотации IDEF1X.

2.6.2. Построение логической модели

Создание новой сущности

Для создания новой сущности следует воспользоваться кнопкой . После позиционирования создаваемой сущности на экране сле­дует перейти в Редактор сущности (Entity Editor) и задать требуе­мые характеристики (рис. 2.75). На последующую генерацию схемы базы данных окажут влияние имя сущности (Name) и признак Logical Only. Сущность, отмеченная как Logical Only, не будет переноситься в физическую модель.

Рис. 2.75. Вид окна описания сущности

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

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

После описания сущности следует перейти к описанию ее свойств (атрибутов). Для этого следует перейти в Редактор атрибутов (Attribute Editor) - появится соответствующее окно (рис. 2.76).

Рис. 2.76. Вид окна Редактор атрибутов

Для создания нового атрибута надо нажать кнопку New, после чего появится окно (рис. 2.77) New Attribute (Новый атрибут).

Рис. 2.77. Начальный вид окна Новый атрибут

При описании нового атрибута можно задать для него два имени: имя, которое будет указываться в логической модели (Attribute Name), и имя, используемое в физической модели (Column Name). Если вруч­ную не задавать Column Name, то при переходе к физической модели в зависимости от выбранной целевой СУБД Attribute Name будет ав­томатически преобразован в Column Name в соответствии с ограни­чениями СУБД на имена (длина, допустимость пробелов).

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

При описании атрибута можно поставить признак Logical Only (только логический). Это никак не скажется на логической модели, но окажет влияние на переход от логической к физической модели: атрибуты, отмеченные как Logical Only, не будут переноситься в фи­зическую модель.

Для атрибутов, соответствующих первичным ключам таблицы, следует установить признак Primary Key (рис. 2.78).

Рис. 2.78. Задание первичного ключа

Кроме того, для атрибута можно задавать свойство Required (обя­зательный). Для атрибута, выбранного первичным ключом, это свой­ство является неактивным (см. рис. 2.78), поскольку свойство обяза­тельности и так (по определению ключа) присуще элементам ключа.

Дополнительные свойства атрибутов

При создании реляционных баз данных по отдельным полям (совокупностям полей) могут быть построены индексы. По умолча­нию по полям, выбранным в качестве первичного ключа, строится уникальный индекс. По полям, которые являются альтернативными ключами таблицы, также можно построить уникальные индексы. По тем полям, по которым часто осуществляется выборочный поиск, для ускорения поиска также целесообразно провести индексирование. Если поле, по которому проводится индексирование, является неуни­кальным, то оно называется инверсным входом (Inversion Entry).

Как отмечалось ранее при общей характеристике инфологического моделирования, понятия ключа (первичного, альтернативного, внешнего) и индексирования не присущи предметной области. Поня­тие ключа относится к категориям реляционной модели данных, а индексирование — это способ логического упорядочения данных. Од­нако в ERWin и некоторых других CASE-системах эти вопросы реша­ются на стадии концептуального проектирования. Для того чтобы за­дать необходимость индексирования, можно, позиционируя на сущ­ности, нажать правую кнопку мыши и в появившемся контекстном меню (рис. 2.79) выбрать позицию Key Group Editor.

Рис. 2.79. Контекстное меню сущности

Предположим, что мы хотим задать инверсный вход для поля Фамилия в таблице «Сотрудник». В этом случае в окне Key Group Editor (рис. 2.80) нужно щелкнуть по кнопке New. В появившемся окне New Key Group следует выбрать переключатель Inversion Entry и щелкнуть по кнопке ОК.

Рис. 2.80. Задание инверсного входа. Экран 1

После этого в окне Available Attributes нужно выбрать поле, ко­торое определяется как инверсный вход, и перенести его в окно Key Group Members (рис. 2.81).

Рис. 2.81. Задание инверсного входа. Экран 2

Первичные и альтернативные ключи, инверсные входы можно задать и иным способом. Для этого в окне Редактор атрибутов (Attribute Editor) нужно выбрать вкладку Key Group (рис. 2.82), щелкнуть по кнопке после чего опять появится окно Key Group Editor.

Рис. 2.82. Окно описания атрибутов. Вкладка Key Group

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

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