Тема: Создание модели данных средствами ERwin.
ПЛАН ЗАНЯТИЯ
Дисциплина: МДК 03.02 Инструментальные средства разработки ПО
Преподаватель: Машарова Р.В.
Курс: 4
Группа: 1 ПКС-19
Специальность: Программирование в компьютерных системах
Дата: 17.03.2023
Время проведения: 09.50-11.20, 2 пара
Тема: Создание модели данных средствами ERwin
Цель занятия:
Дидактическая: познакомиться с созданием модели данных средствами ERwin
Развивающая: развивать логическое и критическое мышление, умение обобщать и синтезировать знания
Вид занятия лекция
Литература:
1. Буч Г, Рамбо Джеймс, Джекобсон Айвар. Язык UML. Руководство пользователя. – М.: ДМК Пресс; СПб.: Питер, 2004
2. Гагарина Л. Г., Кокорева Е. В., Виснадул Б. Д. Г12 Технология разработки программного обеспечения: учебное пособие / под ред. Л. Г Гагариной. — М.: ИД «ФОРУМ»: ИНФРА-М, 2008
3. Жоголев Е.А., Технология программирования. М.: Научный мир, 2004
4. Крылов Е.В., Острейковский В.А., Типикин Н.Г. Техника разработки программ. Книга 2. Технология, надежность и качество программного обеспечения — М.: Высшая школа. – 2009
5. Крылова Г.Д. Основы стандартизации, сертификации, метрологии. – М.: ЮНИТИ-ДАНА, 2003
6. Лифиц И.М. Основы стандартизации, метрологии, сертификации. – М.: Юрайт, 2003
7. Маклаков С.В.. BPwin, ERwin – CASE-средства разработки информационных систем. – М., «ДИАЛОГ-МИФИ», 2010
8. Немилостива Н.И. Стандартизация, сертификация и метрология. – Владивосток: Изд-во ВГУЭС, 2002
9. Павловская Т. А. С/С++. Программирование на языке высокого уровня: Учебник для студентов вузов. - Москва [и др.]: Питер, 2012
10. Сергеев А.Г., Латышев М.В., Терегеря В.В. Метрология. Стандартизация. Сертификация. –М.: Логос, 2003
11. Сьерра К. Бейтс Б. Изучаем java. 2012
12. Файн Я. Программирование на java / Я. Файн. – 3-е изд. – США, 2011
13. Шилдт Герберт Java. Полное руководство. 8-издание / Г.Шилдт. – 8-е изд. –2012
Тема: Создание модели данных средствами ERwin.
1. Нормализации схем отношений.
2. Физическая и логическая модели данных.
1. Нормализации схем отношений.
Для построения модели данных Computer Associates предлагает мощный и удобный инструмент – ERwin версии 4.0. ERwin имеет два уровня представления модели – логический и физический. На логическом уровне данные не связаны с конкретной системой управления базами данных (СУБД), поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных – это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования базы данных (БД). Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Реализация моделирования в ERwin базируется на теории реляционных баз данных и на методологии IDEFIX. Методология IDEF1X была разработана для ВВС США и теперь используется, в частности, в правительственных, аэрокосмических и финансовых учреждениях, а также в большом числе частных компаний. Методология IDEFIX определяет стандарты терминологии, используемой при информационном моделировании, и графического изображения типовых элементов на диаграммах.
Построение модели данных определяет все последующие этапы разработки. Сначала осуществляют разработку логической модели, которая включает в себя следующие этапы:
- выделение сущностей;
- выявление связей между сущностями и построение модели «сущность-связь» (ER Diagram);
- определение первичных ключей (Primary Key) и внешних ключей (Foreign Key);
- определение атрибутов сущностей и построение полной модели (Fully Attributed Model).
В процессе построения все сущности (отношения) должны быть приведены к третьей нормальной форме, после чего приступают к построению физической модели.
Примечание. Введено пять уровней нормализации схем отношений и соответственно пять нормальных форм отношений.
Каждая нормальная форма:
- ограничивает определенный тип функциональной зависимости;
- устраняет соответствующие аномалии при выполнении операций над отношениями БД.
Все формы подчиняются правилу вложенности по возрастанию номеров. Иными словами, если отношение находится в 4НФ, то оно будет соответствовать и 3НФ, и 2НФ, и 1НФ.
1НФ. Отношение находится в первой нормальной форме в том случае, если не первичные элементы отношения функционально зависят от первичных (ключевых) элементов или схема отношения находится в первой нормальной форме тогда и только тогда, когда все входящие в нее атрибуты являются атомарными (т.е. значения соответствующих доменов рассматриваются как неделимые, а не как множества или кортежи из более элементарных доменов).
2НФ. Отношение находится во второй нормальной форме, если оно находится в 1НФ и каждый не первичный элемент функционально полно зависит от каждого ключевого элемента или когда все элементы первичны или каждый ключ содержит один элемент.
3НФ. Отношение находится в третьей нормальной форме, если оно входит во 2НФ и каждый не первичный атрибут не транзитивно зависит от первичного ключа. Иными словами в отношении отсутствуют транзитивные зависимости не ключевых атрибутов от ключа.
4НФ. Отношение находится в четвертой нормальной форме, если оно находится в 3НФ и в нем присутствуют многозначные функциональные зависимости.
5НФ. Отношение находится в пятой нормальной форме, если оно находится в 4НФ и в нем устранена избыточность в отношениях со многими многозначными зависимостями, а также устранена аномалия обновления.
Перед построением физической модели необходимо определиться с тем, на какой платформе будет функционировать система, поскольку от этого зависит, какие типы данных она будет поддерживать, и какой диалект SQL использовать. Последующая работа разбивается на этапы: определение таблиц, определение и полей и их типов данных, определение ограничений на значения полей, определение связей между таблицами, разработка хранимых процедур (если они требуются).
2.Физическая и логическая модели данных.
ERwin имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.
Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.
Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС. Заметим, однако, что формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать.
Контрольные вопросы.
1. Нормализации схем отношений.
2. Физическая и логическая модели данных.