Разработка логической и физической моделей БД в CASE- системе проектирования ERWIN: Методические указания

Министество Общего и Профессионального Образования РФ Томский политехнический университет УТВЕРЖДАЮ: Декан А В Т Ф _______Ю.С.Мельников

МЕТОДИЧЕСКИЕ УКАЗАНИЯ по лабораторной работе “РАЗРАБОТКА ЛОГИЧЕСКОЙ И ФИЗИЧЕСКОЙ МОДЕЛЕЙ БД В CASEСИСТЕМЕ ПРОЕКТИРОВАНИЯ ErWin“

Томск 2000

Лаб.работа 6 Разработка логической и физической моделей БД в CASEсистеме проектирования ErWin Цель: закрепение и более глубокое усвоение знаний по проектированию информационных моделей ИКСУ и навыков работы в CASE системе ERWIN. Введение CASE система ERWIN f .Logic Works предназначена для моделирования и создания баз данных (БД) на основе диаграмм “сущность - связь”. В процессе проектирования БД создаются логические и физические модели разного уровня представления Структурное проектирование проведенное в лабораторных работах с использованием IDEF позволяет построить так называемую модель требований (логическую модель) системы, состоящую из множества взаимоувязанных диаграмм, текстов и словаря данных. Эта модель описывает что должна делать проектируемая система без ссылок на то, как это достигается. В процессе проектирования системы разрабатываются последовательно ER (сущность- связь), KB (ключевой уровень), FA (третья нормальная форма) и физическая модели. Эти модели обеспечивают : - разработку документации базы данных; - разработку ссылочной целостности БД; - разработку логической модели БД независимой от конкретного типа СУБД; - разработку документирования физического проектирования БД в соответствии с бизнес требованиями. Физическая модель позволяет: - обеспечить администратору БД достаточность информации, чтобы создать эффективную БД; - создать контекст для процессов пределения и записи в словари данных; - ассистировать группам приложений в выборе физической структуры программы, которая будет запрашивать данные. При переходе от логической модели Erwin каждой ее опции ставит соответствующую опцию физической модели. 1 Описание проекта. Задание: разработать информационную модель журнала рекламаций промышленного производства. Целью данной информационной системы является хранение данных о рекламациях и замечаниях клиентов, которые в последующем будут использоваться для статистической обработки, другими словами проектируется электронный журнал, содержащий набор сведений представленные на рис. 1 Рисунок 1

Итак, центральной сущностью будущей модели данных является факт рекламации товара. В рекламации участвуют и клиент, и товар. В сходной сущности помимо атрибутов, идентифицирующих клиента и товар (которые, следовательно, могут повторяться), присутствуют атрибуты, характеризующие конкретный экземпляр данной сущности,- дата рекламации, ее форма выражения, статус (первичная или повторная рекламации) и причина. При проектировании данных желательно создать также уникальный первичный ключ (например, номер рекламации). это более удобно чем использовать комбинацию первичных ключей сущностей “Клиента” и “Товар”, к тому же у клиента могут возникнуть проблемы с одним тем же товаром из разных партий поставки (рис.2).

Рисунок 2 Учитывая возможную повторяемость значений атрибутов, характеризующих дефект и статус рекламации, целесообразно создать соответствующие дополнительные сущности, выполняющие роль справочников (другими словами, произведем нормализацию данных к первой форме). Теперь рассмотрим сущность “Клиент”. Очевидно, у предприятия может быть несколько клиентов, имеющих одну и ту же значимость для него как потребители товара, поэтому имеет смысл выделить “код значимости” в отдельную сущность и связать ее посредством внешнего ключа с сущностью “Клиент”. В результате получается логическая модель данных в виде (рис.3). Возникает вопрос, а как быть с атрибутами сущности “Товар”? Ведь очевидно, что атрибуты “Гарантия”и “N_партии” тоже повторяются. При рассмотрении вопроса о целессобразности создания для них справочников, примем во внимание то, что “Гарантия” имеет значения “Да” и “Нет”, а “N_партии” это просто число и хотя этот атрибут может быть вынесен в отдельный справочник, в данной лабораторной работе это не будет делаться из соображений достаточности (нормализуя модель, можно дойти до такого состояния, когда выполнение запросов к таблицам окажется весьма длительным из- за бльшого их числа). Теперь следует подумать о физическом проектировании данных, а именно о выборе СУБД, создании таблиц, соответствующих созданным сущностям, типах полей для хранения атрибутов, а также о создании других объектов БД, предназначенных для облегчения поиска в таблицах, контроля ссылочной целостности данных, обработки данных таких как индексы, триггеры, хранимые процедуры.

Рисунок 3 Для создания физической модели выбирается соответствующая платформа в используемом CASE- средстве и описываются характеристики таблиц, соответствующих в логической модели сущностям, и содержащихся в них полей, соответствующих их атрибутам (рис.4). Порядок выполнения работы. 1 Настройка работы. 1 Запускается CASE - система Erwin v 2.5 f. Logic Works: W\ERWIN21\ERWERX16.exe (File NEW). 2 Осуществляется настройка работы для работы с русским языком и конкретным СУБД. СУБД задается преподавателем (Использование серверных СУБД значительно сокращает сроки проектирования. Для создания физической модели выберите вариант согласно номеру в списке подгруппы: 1) ORACLE, 2) ACCESS, 3)PARADOX, 4FOXPRO, 5)INFORMIX,6)WATCOM.). Выбрать в меню

Рисунок 4 SERVER, TARGET SERVER, СУБД. Выбрать OPTION, DEFAULT FONT COLOR, войти в редактор , вкл тригер ALL OBJECT, ARRIAL CYR..., OK. 3 Осуществляется настройка Ссылочной Целостности (Referential Integrity). Для этого из скролинг- меню (Identifying) выбираются опции для отношений IDENTIFYING (Ch.Del- Par.Upd) соответственно (N, Restr., Restr., Restr., None, Restr.). ( Здесь опции Сascad указывает, что все атрибуты, указанные в сущности родителя для удаления, одновременно удаляются и у наследуемых сущностей). 2 Логическое (концептуальное) проектирование. Задача1. Проектирование ER диаграммы. Цель: построение диаграммы уровня “сущность- связь” и глоссария к ней. Последовательность действий: „ выделить сущности и присвоить им уникальные имена; „ занести в глоссарий модели формальное определение имен сущностей. Требования к диаграмме и глоссарию: „ сущности должны быть представлены на диаграмме только именами; „ допускаются зависимые и независимые сущности; „ глоссарий должен содержать краткие формальные определения сущностей. Порядок разработки ER диаграммы. 1 Выбирается из ErWin Toolbox тип сущности зависимая (если она потомок) или независимая (если она родитель). 2 Щелкнуть по месту расположения сущности на рабочем поле.

3 Выбрать в Toolbox стрелку Select. Дважды щелкнуть по полю сущности. В открывшимся редакторе Entity- Attribute Editor в окне Entity записать имя сущности. OK. Задача 2. Проектирование отношений. Цель: проектирование и осмысление характера взаимосвязей между сущностями. Последовательность действий: „ определить тип отношения; „ указать имя отношения. Требования к диаграмме: „ имена связей должны выбираться в глагольной форме, так, чтобы диаграмма читалась осмысленными фразами русского языка; „ при разработке допускаются определенные, неопределенные, связи типа “many- many” и категоризационные связи. Порядок проектирования диаграммы. 1 Устанавливаются в поле экрана сущности Родителя и Потомка. Щелкнуть по полю тип отношений ErWin Toolbox (определенное, неопределенное, неспецифическое). 2 Щелкнуть сначала по полю сущности Родителя, а затем по полю сущности Потомка. 3 Дважды щелкнуть по отношению. В открывшимся редакторе отношений в окне Verb Phrase вводят глагольную форму, связывающую обе сущности в смысловое предложение. Триггерами Кардинальности указывается мощность отношения (Р, Z или число). Обычно ставится максимальная. В дисплейном окне Rolename (можно изменить ролевое назначение ключа). В окне Foreign Key указывается (название ключа наследования). 4 Чтобы наблюдать на рабочем экране имя отношения необходимо выбрать в панели меню DISPLAY/ Verb Phrase. 5 В случае необходимости, чтобы добавить в схему отношение типа категории между Родителем и двумя Потомками необходимо: „ выбрать тип категории (категория с одной линией показывает, что имеются другие сущности категории которые не включены в схему, категория с двумя линиями указывает, что все категории учтены); „ щелкнуть последовательно сначала по сущности Родителя, а затем по сущности одного из Потомков; „ щелкнуть по месту установки знака отношения категории, а затем щелкнуть по оставшейся сущности. Задача 3. Проектирование КВ диаграммы. Цель: проектирование идентификаторов сущностей и уяснение логики взаимосвязей на уровне идентификаторов. Последовательность действий: „ преобразовать все неспецифические отношения в специфические; „ определить возможные ключи независимых сущностей и выделить первичные ключи; „ ввести формальные определения имен ключевых атрибутов в глоссарий; „ показать первичные и все возможные ключи на диаграмме; Требования к диаграмме :

„ на диаграмме допускаются только специфические и категоризационные связи;

„ глоссарий должен содержать формальные определения ключей. Порядок проектирования PK диаграммы. 1 Дважды щелкнуть по полю сущности. В открывшимся редакторе в окне Primary Key записывается имя первичного ключа. ОК. Задача 4. Проектирование FA- диаграммы. Цель: построение полноатрибутной диаграммы и глоссария к ней. Последовательность действий: „ дать в глоссарии формальное определение имен неключевых атрибутов; „ разместить не ключевые атрибуты на диаграмме в соответствии с их смыслом; „ проверить условия нормализации для каждой сущности. Требования к диаграмме: „ на диаграмме должны быть показаны все хранимые атрибуты; „ глоссарий должен содержать формальное определение всех сущностей, атрибутов и доменов; „ для каждого атрибута должны быть указаны домен и сущность владелец. Порядок проектирования FA диаграммы. 1 Выбирается стрелка SELECT, выбирается название сущности, при нажатой правой кнопке мышки выбирается редактор сущностей и атрибутов СУБД DATABASE SCHEMA. 2 Заносятся название атрибутов в окно Non- Key Attributes, OK. 3 Физическое проектирование. Задача 5. Физическое проектирование. Цель: разработка структуры реляционной базы данных для выбраннной СУБД. Последовательность действий: „ поставить в соответствие именам сущностей и атрибутов логической модели имена таблиц и полей БД (физические имена); „ разработать сопроводительную документацию. Требования к диаграмме: 1 Проектируются типы данных в соответствующем СУБД. Для этого включается в верхней линейке пиктограмма PHYSICAL VIEW, 2 Выбирается указателем мышки проектируемая сущность, нажатой правой выбирают Вариант СУБД DATABASE, в редакторе выбирают тип данных, размер записи, ОК. 3 Описываются свойства связей между таблицами, в частности, реакцию сервера на попытки нарушения ссылочной целостноти со стороны клиентского приложения. Для этого выделив связь, щекнуть правой кнопкой и выбрать в редакторе отношений опцию RELATIONSHIP INTEGRITY, при этом можно отредактировать ее VERB PHRASE, установить триггеры запрещения действий клиентскому приложению по удалению записей CHILD DELETE- NONE, PARENT DELETE- NONE, а все остальное - RESTRICT. После этого, можно создавать на сервере схему БД. Для этого отредактировать тип данных (войти в какую нибудь сущность и правой кнопкой щелкнуть, а затем выбрать Attribute Editors/ Access Database Schema ввести редактируемую сущность в окне Entity), введя Access- типы для атрибутов и

ключей: счетчик или длинное целое для кода, дата/время для даты, деньги- валюта, да/нет и т.п. Ввести определения атрибутов и имена владельца данных. Вызвать Domain Editor (Column Propery Editor/ Domain). Ввести имена доменов и присвоить им типы (длина) и определения: для доменов адрес- <индекс>, <город>, <улица>, <дом>, <квартира>; для имен последовательность букв какого нибудь алфавита; телефоны- <код города>, <номер телефона>; номера- последовательность цифр; значимость- ‘VIP’-очень значимый клиент; ‘IP’- значимый клиент, ‘М’- скорее менее значимый чем значимый; ‘N’- нейтральный. 4 Программа работы. Разработать в CASE - системе ErWin логическую и физическую модели бизнес- процесса согласно варианту курсового проекта . 5 Контрольные вопросы 1. В чем разница между концептуальной, реляционной и физической моделями данных ? 2. Объясните своими словами смысл терминов (реляционная модель данных, мощность отношения, тип отношения). 3. Что такое триггер БД ? 4. Объясните применение ограничительных условий, поддерживающих целостность данных. 6 Содержание отчета. В отчете дать ответы на контрольные вопросы. Отчет приготовить в виде ErWin - документов и распечатать на принтере. Для этого вызвать Entity Report чтобы подготовить таблицу соответствия физических и логических имен в виде: - таблицы Entity Option с содержанием Entity Name, Definition; таблицы Table Option с содержанием Table Name, Attribute Option (Attribute Name, Columns/Type, Primary Key). Форма вывода: Report Format/ Labeled. Результат записать в файл *.ere. Вызвать Attribute Report чтобы подготовить таблицу соответствия физических и логических имен в виде: - таблицы с содержанием Attribute Name, Domain, Attribute Type Definition; Column Option с содержанием Column Name, Column Data Type, Owned Attribute, Report Format/ Labeled. Результат записать в файл *.era. Relationship Report в виде - Relation Option: Verb Phrase, Parent Entity, Child Entity; Relationship Definition, Cardinality, Physical Name, Parent Table, Child Table, Report Format/Labeled записать в файл *.err. Оформить SQL отчет создания таблиц БД с помощью Schema Generation. Сохранить его в виде файла *.ers. Отредактировать полученные отчеты в Worde Литература. 1. ERwin Methods Guide Logic Works, Inc, University Square at Princeton, 111 Campus Drive, Princeton, NJ 08540, 1997, 104 с. 2. ERwin Reference Guide Logic Works, Inc, University Square at Princeton, 111 Campus Drive, Princeton, NJ 08540, 1997 3. ERwin Features Guide Logic Works, Inc, University Square at Princeton, 111 Campus Drive, Princeton, NJ 08540. 1997.117с.

4. ERwin Workgroup Modeling Guide Logic Works, Inc, University Square at Princeton, 111 Campus Drive, Princeton, NJ 08540, 1997, 100 с. 5. Гэри Хансен, Джеймс Хансен, Базы данных: разработка и управление, М: ЗАО “Издательство БИНОМ”, 1999, 704 с. 5. Logic Works RPTwin User’s Guide Logic Works, Inc, University Square at Princeton, 111 Campus Drive, Princeton, NJ 08540. 1997 РАЗРАБОТКА ЛОГИЧЕСКОЙ И ФИЗИЧЕСКОЙ МОДЕЛЕЙ БД В CASEСИСТЕМЕ ПРОЕКТИРОВАНИЯ ErWin Методические указания Составитель Евгений Иванович Громаков Подписано к печати Формат 60х84/16. Бумага писчая №2 Плоская печать Усл. печ. л. Уч.-изд. л. Тираж 50 экз. Заказ . Бесплатно. Ротопринт ТПУ. 634004, Томск, пр. Ленина,30