Лабораторная работа № 11

Проектирование информационного обеспечения информационной системы компьютерной фирмы средствами ERwin

(продолжительность работы 4 часа)

Цель работы: разработать модели данных в инструментальном средстве ERwin для проектирования информационной системы компании.

Указания по выполнению лабораторной работы

Исходные данные: Проектирование в среде ERwin состоит из следующих этапов:

• составление диаграммы СУЩНОСТЬ – СВЯЗЬ – логической модели БД;

• создание на ее основе физической модели, т.е. структуры БД для конкретной СУБД – локальной или клиент-серверной (MS Access, Oracle, FoxPro, InterBase и т.д.)

• создание отчетов для созданных моделей.

Логический уровень – это абстрактный взгляд на данные, когда данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами.

Логическая модель данных разрабатывается на основе существующих моделей данных (например, реляционной), но никак не связана с конкретной реализацией системы управления базы данных (СУБД) и прочих физических условий реализации. Она может быть построена на основе другой логической модели, например, на основе модели потоков данных или процессов.

Логическая модель данных является источником информации для фазы физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительное значение для выбора действительно эффективного проектного решения.

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей.

На физическом уровне объекты БД должны называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы — имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Такое соответствие позволяет лучше документировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

После описания логической модели проектировщик может выбрать необходимую СУБД, и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering).

---

Интерфейс ERwin выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен (рис. 1.1).

Рис. 1.1. Окно отображения логической модели

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

Рис. 1.2. Палитра инструментов

Таблица 1.1 – Палитра инструментов

На логическом уровне палитра инструментов имеет следующие значения кнопок (табл. 1.1).

На физическом уровне палитра инструментов имеет:

- вместо кнопки категорий – кнопку внесения представлений (view);

- вместо кнопки связи "многие-ко-многим" – кнопку связей представлений.

Запустите ERwin. Откроется главное окно области диаграммы со значением переключателя страниц LOGICAL и палитрой инструментов.

Если вам не понятно, как выполнить то или иное действие, вы можете вызвать помощь - клавиша F1 или меню Help.

Задание 1. Создание логической модели данных. Сущности.

Для создания моделей данных в ERwin можно использовать две нотации IDEF1X и IE. Переключение между нотациями выполняется Methodology меню Option/Preferences.

Различают три уровня логической модели, отличающихся по глубине представления информации о данных:

• диаграмма сущность-связь (Entity Relationship Diagram, ERD);

• модель данных, основанная на ключах (Key Based model, KB);

• полная атрибутивная модель (Fully Attributed model, FA).

Диаграмма сущность-связь представляет собой модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи "многие-ко-многим" и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.

Модель данных, основанная на ключах – более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.

Полная атрибутивная модель – наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.

ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями можно с использованием кнопок панели инструментов. Переключиться на другие уровни отображения можно при помощи контекстного меню, которое появляется, если нажать правую кнопку мыши на любом месте диаграммы, не занятой объектами модели. В контекстном меню следует выбрать пункт Display Level и затем необходимый уровень отображения.

---

Сущности и атрибуты

Основные компоненты диаграммы ERwin – это сущности, атрибуты и связи. Сущность можно определить как объект, событие или концепцию, информация о которой должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, фактически это имя ее экземпляра. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы.

Entity Editor в контекстном меню для сущности позволяет определить имя, описание, комментарии, иконку. Для описания атрибутов сущности выбирается пункт Attribute Editor. Здесь можно указать имя нового атрибута и домен, который будет использоваться при определении типа колонки на уровне физической модели. Атрибуты должны именоваться в единственном числе, иметь четкое смысловое значение и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Каждый атрибут должен быть определен (закладка Definition), при этом следует избегать циклических определений и производных атрибутов. Для внесения дополнительных комментариев и определений к сущности служат свойства, определенные пользователем (UDP). Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов.

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

Указания к выполнению задания

Для создания моделей данных использовать нотацию IDEF1X. Осуществить практическое моделирование деятельности компании АО «Компреал», которая занимается сборкой персональных компьютеров (КПК) и установкой на них программного обеспечения (ПО). Основные процедуры компании:

• продавцы принимают заказы клиентов;

• операторы группируют заказы по типу работ;

• операторы собирают КПК;

• операторы устанавливают ПО на КПК;

• операторы упаковывают КПК согласно заказам;

• кладовщик отгружает клиентам заказы.

Для начала представим модель базы данных компании. Модель должна содержать 8 сущностей: Заказ, Заказчик, Оператор, КПК, ПО, Кладовщик, Готовый товар, Продавец. Каждая из представленных сущностей имеет свой набор атрибутов.

1. Щелкните по кнопке и на рабочем поле программы. Появится окошко сущности с названием Е/1. Окошко сущности разделено на две части. В верхнюю часть входят атрибуты, которые являются ключами сущности, а в нижнюю - не ключевые атрибуты (см. рис. 1.1).

---

Рис. 1.1. Сущность

2. Двойной щелчок по сущности открывает окно Attributes (рис. 1.2).

Рис. 1.2. Диалоговое окно Attributes

3. В верхнем правом углу окна расположена кнопка, которая открывает диалоговое окно Entities (рис. 1.3), где в поле Name имеется возможность изменить имя сущности. Измените имя сущности на «Заказ». После завершения ввода нажмите кнопку ОК.

4. Нажатием на кнопку New … в левом нижнем углу окна открывается диалоговое окно создания нового атрибута сущности (рис. 1.4).

Рис. 1.3. Диалоговое окно Entities

Рис. 1.4. Диалоговое окно New Attribute

5. В поле Attribute Name:* введите название атрибута «Код_заказа», в окошке Domain выберите тип вводимых данных. Для завершения процедуры ввода нажмите ОК. Для задания первичного ключа в окне Attributes для выделенного атрибута «Код_заказа» установите галочку Primary Key.

Первичный ключ (primary key) – это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения – это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (рис. 1.1).

В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key).

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

Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду требований:

- уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа.

- компактность. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т.е. ключам, содержащим меньшее количество атрибутов. Атрибуты ключа не должны содержать нулевых значений. Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности.

Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь более одного возможного ключа. Тогда один из них становится первичным, а остальные – альтернативными ключами. Альтернативный ключ (Alternate Key) – это потенциальный ключ, не ставший первичным.

6. Возможен так же и другой способ ввода атрибутов в поля сущности. Чтобы заполнить окошко сущности атрибутами, нужно выбрать сущность левой кнопкой мыши и нажать клавишу «Tab». После ввода названия атрибута надо нажать «Enter», если необходимо остаться в верхней части и продолжить заполнять ключевые атрибуты, или «Tab» если необходимо приступить к заполнению других атрибутов. Клавиша «Tab» перемещает курсор между тремя полями ввода: названием сущности, ключевыми атрибутами и не ключевыми атрибутами. Задайте еще три атрибута в сущности Заказ: «Стоимость», «Дата_заказа» и «Дата_выдачи». Результат показан на рис. 1.5.

---

Рис. 1.5. Сущность Заказ

7. Одним из предложенных способов создайте и заполните все необходимые сущности компании, описанные в таблице 1.1.

Таблица 1.1 – Сущности и атрибуты компании «Компреал»

Сущности	Атрибуты
Клиент	- Код клиента (РК) - Фамилия - Имя - Отчество - Адрес - Номер счета
Заказ	- Код заказа (РК) - Дата заказа - Дата выдачи - Стоимость
Сотрудник	- Код сотрудника (РК) - Фамилия - Имя - Отчество - Дата рождения - Должность - Зарплата
КПК	- Код КПК (РК) - Процессор - Память - Дисплей - Модем - Интерфейс
ПО	- Код ПО (РК) -ОС - Мультимедиа - Интернет - Антивирус - Игры
Товар	- Код товара (РК)
Продавец	- Код продавца (РК)
Кладовщик	- Код кладовщика (РК)
Оператор сборки	- Код оператора сборки (РК)
Оператор установки	- Код оператора_установки (РК)

Задание 2. Установка связей в логической модели данных

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases). Имя связи облегчает чтение диаграммы, например (рис. 2.1):

Рис. 2.1. Пример связей

По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню (нажать правую кн. «мыши») для свободного места диаграммы выбрать пункт Display Option/Relationship и включить опцию Verb Phrase.

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

Различают несколько типов зависимых сущностей.

Характеристическая – зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности.

Ассоциативная – сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей.

Именующая – частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа).

Категориальная – дочерняя сущность в иерархии наследования.

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности и помечается в дочерней сущности как внешний ключ (FK). Эта операция называется миграцией атрибутов. В дальнейшем, при генерации схемы БД, атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента.

---

Смотрите также файлы

• 11 раб.doc

• Раб_Лб_ERWin.doc

• реферат по ФП.docx

• физика атомная1.docx

• лТеоретические основы таможенной экспертизы╗ 2 семестр.docx