6. Задания

1. На основе логической модели ПродажаТовара создать физическую базу данных.

2. На основе логической модели ПоставкаТовара создать физическую базу данных.

3. На основе объединенной логической модели создать физическую базу данных.

7. Контрольные вопросы

1. Какова цель создания физической модели?

2. Почему перед генерацией физической базы данных необходимо преобразовать связи многие-ко-многим?

3. Как осуществляется разрешение связей многие-ко-многим?

4. Что понимают под прямым проектированием?

5. Какие панели инструментов используются при работе с физической моделью БД?

6. Какие происходят изменения в инструментальной среде ERwin при переходе на физический уровень отображения модели?

Занятие № 5. Построение модели данных на основе базы данных

Цель занятия:

Преобразование физической базы данных, созданной в СУБД MS Access, в логическую модель данных.

1. Обратное проектирование

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

Восстановление информационной (логической) модели по существующей базе данных, используется при выборе оптимальной платформы (rightsizing) для существующей настольной (desktop) базы данных или базы данных на mainframe, а также при расширении (или модификации) существующей структуры, которая была построена без необходимой сопроводительной документации. После завершения процесса восстановления модели ERwin автоматически "раскладывает" таблицы на модели. Теперь можно выполнять модификации уже с использованием логической схемы – добавлять сущности, атрибуты, комментарии, связи и т.д. По завершении изменений одна команда – синхронизировать модель с базой данных – актуализирует все проведенные изменения. Построение модели может быть выполнено как на основании данных каталога базы данных, так и на основании пакета операторов SQL, с помощью которого была создана база данных.

Процесс обратного проектирования рассмотрим на примере двух ситуаций:

Ситуация 1. Физическая база для СУБД Access была сгенерирована ERwin на основе логической модели. В базу на уровне СУБД Access были внесены изменения и дополнения. Необходимо воссоздать логическую модель для скорректированной физической базы на уровне ERwin.

Ситуация 2. Физическая база изначально разрабатывается в СУБД Access. Необходимо создать логическую модель для скорректированной физической базы на уровне ERwin.

2. Порядок выполнения работы

Ситуация 1.

1. Средствами Windows создайте копию файла Info2.mdb с новым именем Info25.mdb.

2. Запустите СУБД Access.

3. Откройте файл Info25.mdb.

Рис. 109. База данных Info25.mdb

4. В появившемся рабочем окне базы данных (рис. 109) среди объектов Таблицы выберите таблицу Клиент.

5. В контекстном меню выберите Конструктор (рис. 110).

Рис. 110. Контекстное меню

6. В появившемся окне Клиент: таблица (рис. 111):

• в разделе Имя поля введите имя нового поля E-mail;

• в разделе Тип данных выберите Текстовый;

• в разделе Размер поля задайте 20.

Рис. 111. Окно Клиент: таблица

7. Среди объектов Таблицы (рис. 109) выберите таблицу Товар.

8. В контекстном меню выберите Конструктор (рис. 110).

9. В появившемся окне Товар: таблица (рис. 112):

Рис. 112. Окно Товар: таблица

• в разделе Имя поля введите имя нового поля Описание;

• в разделе Тип данных выберите Текстовый;

• в разделе Размер поля задайте 255.

10. Сохраните изменения в БД (файле Info25.mdb).

11. Закройте СУБД Access.

12. Запустите ERwin.

13. Создайте новую модель с именем Info25.er1.

14. Перейдите на физический уровень отображения моделей.

15. В ERwin выберите пункт меню Tools/Reverse Engineer (рис. 113) или щелкните мышью по кнопке Reverse Engineer на панели База данных (рис. 79).

Рис. 113. Выбор команды Reverse Engineer

16. Появиться диалог Template Selection (рис. 114). В окне Template Selection назначьте шаблон смешанного типа модели Logical/Physical и выберите тип СУБД Access, в которой расположена физическая БД. Нажмите кнопку Next.

Рис. 114. Выбор типа модели и базы данных

17. Откроется окно Set Options для задания параметров обратного проектирования (рис. 115). В диалоге Set Options можно задать следующие опции:

• Раздел Reverse Engineer From позволяет задать источник обратного проектирования – БД или SQL(DDL)-скрипт. При помощи кнопки Browse можно выбрать текстовый файл, содержащий SQL-скрипт;

• Раздел Items to Reverse Engineer позволяет задать объекты БД, на основе которых будет создана модель. При помощи списка выбора Option Set, a также кнопок New, Update и Delete можно создавать и редактировать именованные конфигурации объектов БД, которые могут быть использованы многократно при других сеансах обратного проектирования;

• Раздел Reverse Engineer позволяет включить в модель системные объекты (окно выбора System Objects) и установить фильтр на извлекаемые таблицы по их владельцу.

Рис. 115. Выбор параметров создаваемой модели

17.1. Применительно к нашему случаю в окне Set Options задайте режим обратного проектирования Update и выберите параметры обратного проектирования по умолчанию Default Option Set. Нажмите кнопку Next.

18. Откроется окно ввода параметров соединения с сервером БД (рис. 116).

19. В окне Установление связи с СУБД Access (рис. 116):

19.1. В разделе User Name введите Admin.

19.2. В разделе Datebase укажите маршрут расположения и имя файла Info25.mdb, в котором храниться база данных Access.

19.3. Пароль вводить не требуется/

19.4. Нажмите кнопку соединения Connect.

Рис. 116. Установление связи с СУБД Access

20. В результате выполнения вышеописанных действий, ERwin создаст структуру сущностей на логическом уровне (рис. 117), и структуру таблиц на физическом уровне (рис. 118).

Рис. 117. Преобразованная БД на уровне логической модели

21. Ход обратного проектирования отражается в окне Erwin/Access Reverse Engeneering (рис. 119). При наличии ошибок выдаются соответствующие сообщения, и процесс проектирования заканчивается. В случае успешного преобразования окно Erwin/Access Reverse Engeneering автоматически закрывается и в рабочем окне появлются модели.

Рис. 118. Преобразованная БД на уровне физической модели

Рис. 119. Окно Erwin/Access Reverse Engeneering

22. Erwin с целью экономии места очень компактно располагает модели, и использует шрифт малого размера. Для улучшения наглядности увеличьте полученные схемы моделей. На рис. 117 и рис. 118 модели показаны в увеличенном масштабе.

22. Сохраните модель под именем Info25.er1.

Замечание: При обратном преобразовании достаточно часто происходят различные ошибки по вине пользователя. К сожалению ERwin запоминает эти неверные действия, и как следствие не может завершить обратное преобразование. Рекомендуется создать базу данных в СУБД Access с новым именем, скопировать таблицы из старой базы данных во вновь созданную, и повторить процесс обратного преобразования, используя в качестве источника данных новую базу.

Ситуация 2

Ситуацию 2 рассмотрим на конкретном примере. Необходимо автоматизировать процесс отпуска товаров со склада. Товары отпускаются по накладной, вид которой приведен на рис. 120.

	Накладная № 123
Дата	Покупатель			Адрес
10.01.07	ТОО "Геракл"			г. Москва, ул. Стромынка, 20
Отпущен товар	Количество	Ед. изм.			Цена ед. изм.		Общая стоимость
Тушенка	1000000	банки			30		30 000 000
Сахар	50000	кг			20		1 000 000
Макароны	200000	кг			15		3 000 000
					Итого 34 000 000
Рис. 120. Вид накладной

Прежде чем создавать физическую БД ее необходимо подвергнуть процедуре нормализации [3, 4, 5].

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

Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных [4, 5].

Существует шесть нормальных форм – 1НФ, 2НФ, ЗНФ, 4НФ, 5НФ, нормальная форма Бойса-Кодда (БКНФ).

После выполнения нормализации все взаимосвязи данных будут правильно определены, модель данных становится легче поддерживать.

При практической разработке баз данных важны первые три – 1НФ, 2НФ, ЗНФ. БД приведенная к 3НФ получилп названия полной атрибутивной модели (FA).

В начале проектирования сведем имеющиеся поля накладной (рис. 120) в одну таблицу (рис. 121).

	ОтпускТоваровСоСклада
	Дата
	Покупатель
	Адрес
	Товар
	ЕдиницаИзмерения
	ЦенаЗаЕдиницуИзмерения
	ОтпущеноЕдиниц
	ОбщаяСтоимость
	НомерНакладной
Рис. 121. Поля исходной таблицы

Первая нормальная форма (1НФ) требует, чтобы каждое поле таблицы БД [5]:

• было неделимым;

• не содержало повторяющихся групп.

Неделимость поля означает, что значение поля не должно делиться на более мелкие значения.

Известно, что впоследствии будет необходимо производить анализ продаж по городам. Поэтому из поля Адрес (допускающего толкование как делимого поля) выделим отдельное поле Город (рис. 122).

Повторяющимися являются поля, содержащие одинаковые по смыслу значения.

Например, если требуется получить статистику продаж четырех товаров, можно создать поля для хранения данных о продаже по каждому товару Товар1, Товар2, Товар3, Товар4. Но, мы отлично понимаем, что реально таких товаров будут тысячи, а возможно и больше. Поэтому переборем искушение назначить каждому товару отдельное поле и выделим факт отпуска товара в отдельное поле Товар (рис. 122).

Преобразование отношения к первой нормальной форме может привести к увеличению количества полей отношения и изменению первичного ключа.

	ОтпускТоваровСоСклада
	Дата
	Покупатель
	Город
	Адрес
	Товар
	ЕдиницаИзмерения
	ЦенаЗаЕдиницуИзмерения
	ОтпущеноЕдиниц
	ОбщаяСтоимость
	НомерНакладной
Рис. 122. Поля таблицы, приведенной к 1НФ