2. Примеры разработки модели бд с помощью eRwin

2.1. Прямое проектирование

2.1.1. Постановка задачи

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

1. дата и время сделки,

2. количество покупаемых и/или продаваемых акций и их номинальная стоимость,

3. фамилии, имя, отчество клиента,

4. номер паспорта клиента

5. личный идентификационый код, если клиент − физическое лицо, или регистрационный номер доверенности, если клиент представляет юридическое лицо,

6. фамилия, инициалы и учетный номер личного дела кассира в отделе кадров.

Система должна позволять подводить итоги за произвольное количество дней, а также осуществлять поиск информации о сделках по личному идентификационному коду клиента или номеру доверенности. Задача состоит в проектировании структуры базы данных разрабатываемой автоматизированной ИС.

2.1.2. Создание логической модели бд

Проведем анализ предметной области с целью выделить основные сущности. Поскольку речь идет об учете сделок купли-продажи акций, ясно, что в модели должна присутствовать сущность СДЕЛКА (Тransaction). Понятие сделка подразумевает участие по крайней мере двух совершающих ее сторон, а также наличие предмета сделки. Так как участниками сделки являются клиент и кассир, а предметом сделки являются акции, необходимо ввести еще три сущности: АКЦИЯ (Share), КЛИЕНТ (Сustomer) и КАССИР (Teller). Поскольку клиенты могут быть двух категорий, имеем супертип КЛИЕНТ и его два подтипа − ФИЗИЧЕСКОЕ ЛИЦО (Natural person) и ЮРИДИЧЕСКОЕ ЛИЦО (Legal entity). Таким образом, получаем модель, состоящую из трех стержневых сущностей − АКЦИЯ, КЛИЕНТ и КАССИР и трех асоциативных – СДЕЛКА (связывает стержневые сущности), ФИЗИЧЕСКОЕ ЛИЦО и ЮРИДИЧЕСКОЕ ЛИЦО (уточняют сущность КЛИЕНТ).

Для создания новой модели в ERwin можно щелкнуть по кнопке Create Model на стандртной панели инструментов, в результате чего на экране появится диалоговое окно (рис. 9), в котором необходимо указать тип модели (группа New Model Type), используемый шаблон (группа Create Using Template) и тип СУБД (группа Target Database), если выбран тип модели Physical или Logical/Physical.

Р ис. 9. Диалоговое окно команды создания новой модели.

Выбрав тип модели − Logical/Physical, шаблон − Blank Logical/Physical Model и СУБД − SQL Server 2000, приступаем к созданию ER-диаграммы. Внесем перечисленные сущности в диаграмму, используя кнопку Entity на панели инструментов Toolbox (рис.10). Для редактирования свойств сущностей предназначен редактор сущностей, который можно вызвать, если щелкнуть правой клавишей мыши по любому из прямоугольников сущностей и во всплывающем меню выбрать команду Entity Properties. Названия сущностей и их атрибутов можно редактировать непосредственно на диаграмме, щелкнув левой клавишей мыши по прямоугольнику сущности и далее нажимая на клавишу <Tab>.

Р ис. 10. Создание новых сущностей на ER-диаграмме.

Теперь для каждой сущности необходимо указать первичный ключ и неключевые атрибуты. Кроме того, для некоторых, возможно, понадобится задание альтернативных ключей и инверсных входов. Источником информации в этом случае должен стать перечень требований, приведенных в задании. Рассмотрим каждую из сущностей.

Атрибутами сущности КЛИЕНТ будут ˂фамилия˃ (CustomerLastName), ˂имя˃ (CustomerFirstName), ˂отчество˃ (CustomerMiddleName) и ˂номер паспорта˃ (CustomerPassportNum), а первичным ключом можно выбрать ˂номер паспорта˃, поскольку он однозначно идентифицирует любой из экземпляров этой сущности. Остальные атрибуты сделаем инверсным входом, чтобы обеспечить возможность быстрого поиска информации о сделках, согласно заданию.

Первичными ключами сущностей ФИЗИЧЕСКОЕ ЛИЦО и ЮРИДИЧЕСКОЕ ЛИЦО будет, очевидно, ˂номер паспорта˃, поскольку эти сущности являются зависимыми по отношению к сущности КЛИЕНТ. Поэтому вводить первичные ключи для этих сущностей пока не будем (первичный ключ сущности КЛИЕНТ автоматически мигрирует при установлении связи категоризации с этими сущностями), а ограничимся пока вводом их атрибутов: ˂идентификационный код˃ (PersonID) для сущности ФИЗИЧЕСКОЕ ЛИЦО и ˂номер доверенности˃ (ProxyNum) для сущности ЮРИДИЧЕСКОЕ ЛИЦО. На основе этих атрибутов создадим инверсные входы.

Из атрибутов сущности КАССИР − ˂учетный номер˃ (TellerID) и ˂фамилия и инициалы˃ (TellerNameInitials) − первичным ключом будет, очевидно, ˂учетный номер˃.

Для сущности АКЦИЯ формально определим три атрибута: ˂код акции˃ (ShareCode), ˂наименование акции˃ (ShareName) и ˂номинал˃ (ShareFvalue), из которых первый будет первичным ключом.

Что касается сущности СДЕЛКА, то часть атрибутов она унаследует от родительских сущностей как дочерняя и остается лишь добавить следующие: ˂уникальный цифровой код сделки˃ (TransID) в качестве первичного ключа, ˂количество купленных акций˃ (PurchaseQuantity), ˂количество проданных акций˃ (SaleQuantity) и ˂дата и время сделки˃ (TransDateTime). Поскольку в задании указано, что создаваемая система должна позволять подводить итоги оборота акций за произвольное количество дней, целесообразно сделать атрибут ˂дата и время сделки˃ инверсным входом, т.к. он довольно часто будет использоваться для доступа к данным.

Для ввода первичных ключей и атрибутов сущностей необходимо использовать редактор атрибутов, а для задания альтернативных ключей и инверсных входов следует воспользоваться редактором ключей. Эти редакторы вызываются из того же всплывающего меню, что и редактор сущностей, но при этом следует выбирать команды Attributes и Key Groups.

Следующим шагом в процессе создания логической модели должно стать определение связей между сущностями. Напомним, что для задания связи между двумя сущностями необходимо указать тип связи, направление связи (родительская и дочерняя сущности), мощность связи, допустимость пустых (null) значений, требования по обеспечению ссылочной целостности, а в некоторых случаях и роли.

Для определния параметров связей между указанными сущностями сначала составим описание данной предметной области при помощи ряда истинных высказываний на естественном языке:

Любой КЛИЕНТ должен совершить одну или несколько СДЕЛОК.

Каждую СДЕЛКУ должен совершать только один КЛИЕНТ.

Любой КАССИР может обслуживать нуль, одну или несколько СДЕЛОК.

Каждую СДЕЛКУ должен обслуживать только один КАССИР.

Любая АКЦИЯ может покупаться и продаваться при разных СДЕЛКАХ.

При совершении СДЕЛКИ АКЦИИ могут только покупаться, только продаваться или покупается один тип АКЦИЙ и продается другой тип АКЦИЙ или наоборот.

Анализ приведенных высказываний позволяет выделить четыре связи:

1. КЛИЕНТ совершает (make a bargain) СДЕЛКА.

2. КАССИР обслуживает (serve) СДЕЛКА

3. АКЦИЯ покупается при (is purchased) СДЕЛКА.

4. АКЦИЯ продается при (is soled) СДЕЛКА.

Все четыре связи являются связями "один-ко-многим". Во всех четырех случаях сущность СДЕЛКА является дочерней. Все связи неидентифицирующие, т.к. любой экземпляр сущности СДЕЛКА может быть однозначно идентифицирован по коду сделки, т.е. вне зависимости от экземпляров других сущностей. Однако, при определении этих связей необходимо учесть, что любая сделка становится фактом только в том случае, если в наличии имеются действующие лица и предмет сделки. Отсюда следует, что во всех четырех связях внешние ключи, ссылающиеся на родительские сущности, не могут принимать пустые значения. В то же время могут быть экземляры родительских сущностей, на которые не ссылается ни один из экземпляров сущности СДЕЛКА, например, могут быть акции, которые не использовались ни в одной из сделок. Таким образом, все связи, кроме первой, могут иметь мощность 0, 1 или более. Первая связь не может иметь мощность 0, т.к. в данном случае любой человек становится КЛИЕНТОМ только тогда, когда он совершает хотя бы одну сделку.

Для установления связи между сущностями надо последовательно щелкнуть левой клавишей мыши по кнопке соотвтетсвующего типа на панели инструментов Toolbox, по прямоугольнику родительской сущности и затем − по прямоугольнику дочерней сущности.

Параметры связей задаются при помощи редактора связей. Вызвать этот редактор можно двойным щелчком левой клавиши мыши по линии связи.

Задание ограничений ссылочной целостности и ролей производится, соотвтетственно, на закладках RI Action и Rolename панели диалога редактора связей. Ограничения ссылочной целостности, задаваемые по умолчанию в ERwin, в данном случае оставим без изменений. Указание ролей понадобится лишь для связей между сущностями АКЦИЯ и СДЕЛКА.

После ввода всех перечисленных элементов ER-диаграмма будет выглядеть, как показано на рис. 11. И на этом процесс создания логической модели завершается.

Р ис. 11. Логическая модель базы данных.