Возможность использования модели ERwin одновременно для логического и физического представления данных позволяет по окончании работы получить полностью документированную модель. ERwin, как и инструмент моделирования бизнес-процессов BPwin, интегрирован с генератором отчетов фирмы CA/Logic Works - RPTwin. Это средство позволяет получать подробные отчеты по модели, освещая самые разJ1ичные ракурсы и аспекты. Инструмент RPTwin поставляется вместе с ERwin и имеет богатый набор встроенных отчетов, позволяющих получать многогранную информацию по модели. Документирование структуры данных является очень важной частью моделирования, Т.К. это позволяет другим разработчикам или лицам, которые будут сопровождать систему, быстрее начать ориентироваться во внутренней структуре и понимать назначение компонентов.
ERwin имеет средство, выполняющее задачу, обратную генерации, что называется «обратная разработка» (reverse engineering). Т.е. ERwin может присоединиться к СУБД получить всю информацию о структуре базы данных и отобразить ее в графическом интерфейсе, сохранив все сущности, связи, атрибуты и прочие свойства. Таким образом, можно переносить существующую структуру данных с одной платформы на другую, а также исследовать структуру существующих баз данных.
Начиная с версии 3.5 ERwin, поддерживает многомерное моделирование, которое используется при построении хранилищ данных. Производительность ОLАР-приложений определяется, в основном, качеством дизайна хранилища данных, поэтому критически важно при разработке хранилища иметь инструмент, который бы поддерживал распространенные технологии. ERwin поддерживает две технологии моделирования хранилищ данных: звезда (star) и снежинка (snowf1ake).
Словарь данных, созданный при анализе бизнес-процессов при помощи инструмента BPwin, может быть использован как основа для построения модели базы данных. Однако взаимосвязь между этими двумя инструментами двусторонняя, модели BPwin и ERwin можно постоянно поддерживать в согласованном состоянии. Интеграция этих двух продуктов очень важна с точки зрения их совместного использования при разработке программного обеспечения, т.к. отпадает необходимость в повторном выполнении действий и процесс создания словаря данных становится практически автоматическим.
3.1 Логическая модель
Логическая модель включает в себя:
· ЕRD-диаграммы;
· Модель данных, основанная на ключах;
· Физическая модель.
Первым шагом при создании логической модели БД является построение диаграммы ERD. ЕRD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты − прилагательными или модификаторами, взаимосвязи − глаголами.
ЕRD-диаграммы
ЕRD-диаграмма графически представляет структуру данных проектируемой ИС. Сущности отображаются при помощи прямоугольников, содержащих имя. Имена принято выражать существительными в единственном числе, взаимосвязи - при помощи линий, соединяющих отдельные сущности. Взаимосвязь показывает, что данные одной сущности ссылаются или связаны с данными другой.
Сущности и Атрибуты ERwin
Сущность служит для представления набора реальных или абстрактных предметов (людей, мест, событий и т.п.), которые обладают общими атрибутами или характеристиками. Сущность «логический» объект, который в физической среде СУБД представлен таблицей. Сущность в ERwin обычно описывает три части информации: атрибуты, являющиеся первичными ключами, неключевые атрибуты и тип сущности.
Логические взаимосвязи
Связями называются логические соединения или ассоциации между двумя сущностями.
Данные, относящиеся к связям, очень важны и часто являются критическими данными, которые мы используем в повседневном бизнесе. Например, важно знать о каком-то типе инструмента, но знание того, к кому относится конкретный инструмент (связь между человеком и инструментом) может иметь критическую важность. Связь - это соотношение либо между двумя сущностями, либо между сущностью и этой же сущностью. Связь - «логический» объект, представленный одним или несколькими атрибутами - внешними ключами. Связь в ERwin обычно содержит пять типов информации: тип связи, родительский конец связи, дочерний конец связи, ERwin toolbox содержит два типа сущностей: независимые и зависимые. Независимая СУЩНОСТЬ это сущность, экземпляры которой могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью. Она представляется в ERwin в виде прямоугольника. Первичный ключ независимой сущности не включает в себя первичных ключей других сущностей. Зависимая СУЩНОСТЬ - это сущность, экземпляры которой не могут быть уникальным образом идентифицированы без определения ее связи с другой сущностью или сущностями. Она представляется на ЕR-диаграмме в виде прямоугольника с закругленными углами. Первичный ключ зависимой сущности включает первичные ключи одной или более родительских сущностей.
Связи в IDEFIX представляют собой ссылки; соединения и ассоциации между сущностями. Связи это глаголы, которые показывают, как соотносятся сущности между собой.
Модель данных, основанная на ключах
Каждая сущность содержит горизонтальную линию, разделяющую атрибут на две группы.
Атрибуты, расположенные над линией, называются первичным ключом. Первичный ключ предназначен для уникальной идентификации экземпляра сущности.
При создании сущности необходимо выделить группу атрибутов, которые потенциально могут стать первичным ключом (потенциальные ключи), затем произвести отбор атрибутов для включения в состав первичного ключа, следуя следующим рекомендациям:
· Первичный ключ должен быть подобран таким образом, чтобы по значениям атрибутов, в него включенных, можно было точно идентифицировать экземпляр сущности.
· Никакой из атрибутов первичного ключа не должен иметь нулевое значение.
· Значение атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.
При выборе первичного ключа можно внести в сущность дополнительный атрибут и сделать его ключом. Так, для определения первичного ключа часто используют уникальные номера, которые могут автоматически генерироваться системой при добавлении экземпляра сущности в БД. Применение уникальных номеров облегчает процесс индексации и поиска в БД.
Первичный ключ, выбранный при создании логической модели, может быть неудачным для осуществления эффективного доступа к БД и должен быть изменен при проектировании физической модели.
Потенциальный ключ, не ставший первичным, называется альтернативным ключом (Alternate Кеу). ERwin позволяет выделить атрибуты альтернативных ключей, и по умолчанию в дальнейшем при генерации схемы БД по этим атрибутам будет генерироваться уникальный индекс. При создании альтернативного ключа на диаграмме рядом с атрибутом появляются символы (АК).
Атрибуты, участвующие в неуникальных индексах, называются инверсионными входами (Inversion Entries).
Инверсионные входы − это атрибут или группа атрибутов, которые не определяют экземпляр уникальным образом, но часто используются для обращения к экземплярам сущности. ERwin генерирует неуникальный индекс для каждого инверсионного входа.
Мы экспортировали созданную нами в BPwin модель в Erwin и для ее открытия создаем новый проект в Erwin. Необходимо определить также сущности и атрибуты. В данной модели сущностями являются «Организация» «Инвесторы» «Договоры» «Реквизиты», так как инвестиции направляются в организацию, и она же реализует проект, то есть все сущности будут зависимы от сущности «Организация».
В таблице 6 указаны атрибуты и типы создаваемой модели.
Таблица 6
Типы атрибутов
| Атрибут | Тип | Атрибут | Тип |
| ИНН_организации | Number | Адрес_орг | String |
| ФИО_руководителя | String | Тел_орг | Number |
| Реквизиты | Number | ФИО_инвестора | String |
| Форма_собст_орг | String | Дата_заключения | Data |
| Адрес_инв | String | Н_договора | Number |
| Телефон_инв | Number | ИНН_инв | String |
| Форма_собст_ин | String | Подписи | Number |
| Сумма_инвестиций | Number | Адрес_КБ | String |
| Корр_счет | Number | Тел_КБ | Number |
| Лиц_счет | Number | ФИО_гл_бух | String |
| Объект_инвест | String | КПП_КБ | Number |
Необходимо определить ключевые атрибуты для каждой сущности. Ключевыми атрибутами для «Организации» являются «ИНН организации», для «Инвестора» «ИНН_инвестора», для «Договора »«Н_договора» и для сущности Реквизиты ключевым атрибутом будет «ИНН_орг», «ИНН_КБ», «КПП_КБ». Для приведения БД к первой нормальной форме нужно выполнить условие, при которой все атрибуты содержат атомарные значения. В сущностях «Организация» «Реквизиты» и «Инвестор» может быть несколько телефонных номеров, что является нарушением первой нормальной формы. Нужно создать отдельные сущности «Телефон» и связать их с указанными сущностями.
Проверим соответствие БД второй нормальной форме. Все неключевые атрибуты должны зависеть от первичного ключа. Это условие выполняется для всех сущностей БД. Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов, условие соблюдается.
Полученная БД в третьей нормальной форме изображена на рис. 17.
3.2 Физическая модель
Нормализация
Нормализация – процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционного модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, значительно сократить объем памяти для хранения данных.