Рис. 2.7. Диалог задания уровня перемещения сущностей
Например, если в модели сущность Клиент связана с сущностью Заказ, а та в свою очередь с сущностью Предмет заказа, то при перемещении сущности Клиент со связанными сущностями уровня 2 (потомки) будут перемещены все три сущности.
ERwin позволяет разбить модель на несколько Subject Area, каждая из которых может соответствовать определенной задаче, например финансовой, производственной, маркетинговой и т. д. Для перехода от одного подмножества к другому служит список выбора на панели инструментов (см. табл. 2.1). Subject Area можно создавать как в логической, так и в физической модели данных.
Хранимое отображение (Stored Display) - представление подмножества модели, отображающее специфический аспект структуры данных. Одна Subject Area может включать в себя несколько хранимых отображений. В хранимое отображение входят те же самые сущности и связи, что и в Subject Area, но они могут по-разному располагаться на экране, иметь разные уровни (см: табл. 2.2), различный масштаб и цвет объектов или фона.
Для создания хранимого отображения служит диалог Stored Display Editor (меню Edit/Stored Display).
При определении нового хранимого отображения следует задать его имя, автора, описание и свойства как для логической, так и для физической модели.
При создании Subject Area в нее могут не входить либо родительская, либо дочерняя сущность. По умолчанию связи с сущностями, которые не вошли в Subject Area ("висящие связи"), не показываются. Для отображения таких связей следует включить опцию Show Dangling Relationship в закладке General диалога Stored Display Editor (рис. 2.8).
Хранимое отображение позволяет отобразить линии связей не только ортогональными, но и диагональными. Для представления связей диагональными линиями следует в закладке General выбрать опцию Diagonal (по умолчанию установлена опция Orthogonal).
Рис. 2.8. Диалог Stored Display Editor
Для переключения между хранимыми отображениями служат закладки в нижней части диаграммы (рис. 2.9).
Рис. 2.9. Переключение между хранимыми отображениями
2.2. Создание логической модели данных
2.2.1. Уровни логической модели
Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
диаграмма сущность-связь (Entity Relationship Diagram, ERD);
модель данных, основанная на ключах (Key Based model, KB);
полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах, - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.
Полная атрибутивная модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
2.2.2. Сущности м атрибуты
Основные компоненты диаграммы Erwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту -колонка таблицы.
Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических" наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущность Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address.
Для внесения сущности в модель необходимо (убедившись предварительно, что вы находитесь на уровне логической модели - переключателем между логической и физической моделью служит раскрывающийся список в правой части панели инструментов) "кликнуть" по кнопке сущности на панели инструментов (ERwin Toolbox) , затем "кликнуть" по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности (рис. 2.10).
Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В прежних версиях ERwin закладкам Note2 и Note3 соответствовали окна Query и Sample.
Закладка Definition используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name).
Закладка Note позволяет добавлять дополнительные замечания о сущности, которые не были отражены в определении, введенном в закладке Definition. Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-правило или соглашение по организации диаграммы.
В закладке Note 2 можно задокументировать некоторые возможные запросы, которые, как ожидается, будут использоваться по отношению к сущности в БД. При переходе к физическому проектированию, записанные запросы помогут принимать такие решения в отношении проектирования, которые сделают БД более эффективной.
Рис. 2.10. Диалог Entity Editor
Закладка Note 3 позволяет вводить примеры данных для сущности (в произвольной форме).
В закладке Icon каждой сущности можно поставить в соответствие изображение, которое будет отображаться в режиме просмотра модели на уровне иконок (см. табл. 2.2). В этой закладке можно задать как большую иконку, которая будет отображаться на уровне Icon, так и малую иконку, которая будет отображаться на всех уровнях просмотра модели. Для связывания изображения с сущностью необходимо щелкнуть по кнопке
, в появившемся диалоге ERwin Icon Editor щелкнуть по кнопке Import и выбрать соответствующий файл формата bmp. После выбора иконки она отображается в закладке Icon диалога Entity Editor (рис. 2.11).
Рис. 2.11. Закладка Icon диалога Entity Editor
Использование свойств, определяемых пользователем (UDP), аналогично их использованию в BPwin (см. гл. 1.4). Для определения UDP служит диалог User-Defined Property Editor (вызывается из меню Edit/UDPs). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т. д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке “+”, и внести имя, тип данных, значение по умолчанию и определение.
ERwin поддерживает для UDP шести типов данных:
Date. Дата. Используется формат MM/DD/YY. Для выбора значения даты можно использовать контекстный календарь;
Int. Целое число;
Real. Действительное число;
Text. Строка (ASCII);
List. Список. При задании списка в диалоге User-Defined Property Editor значения следует разделять запятой, значение по умолчанию выделяется символом "~" (рис. 2.12);
Command. Команда - выполняемая строка. На рис. 2.11 свойство Document имеет тип Command.
Рис. 2.12. Диалог User-Defined Property Editor
Значение свойств, определяемых пользователем, задается в закладке UDP диалога Entity Editor. Если присвоить сущности значение свойства Document "D:MSOffice97OfficeWINWORD.EXE part3.doc" (рис. 2.13), то из закладки можно редактировать документ part3 (кнопка “…” в строке таблицы UDP).
