Лабораторная работа №1. Логические и физические модели данных

 

Цель работы

1. Ознакомиться с процессами создания логической и физической моделей данных.

2. Освоить способ установления связей между сущностями.

3. Изучить процессы прямого и обратного проектирования в ERwin.

Задачи

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

2. Установление связей между сущностями типа 1: М и М: М.

3. Создание подмножеств модели и хранимых отображений.

4. Формирование новых доменов, альтернативных ключей и инверсионных входов.

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

6. Выполнение с помощью мастеров процессов прямого и обратного проектирования.

Методические указания

 

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

 

Реляционная алгебра (логическая модель)	Реляционная база данных (физическая модель)
Сущность Кортеж Атрибут Домен	Таблица Строка (Запись) Столбец (Поле) Тип данных

 

Сущность – это объект предметной области, которая исследуется и моделируется.

Кортеж – это экземпляр объекта предметной области (экземпляр сущности).

Атрибут отражает определенное свойство, качество, признак сущности.

Домен задает множество допустимых значений атрибута.

Смысл доменов состоит в том, что они ограничивают сравнения и позволяют правильно моделировать предметную область.

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

· Модель уровня сущностей

· Модель данных, основанная на ключах

· Полная атрибутивная модель.

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

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

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

Эти разновидности моделей, представленные в графической форме, называются диаграммами «сущность-связь» или ER‑диаграммами (Entity – сущность, Relation – связь). Существуют различные варианты ER‑диаграмм, отличающиеся способами графического изображения сущностей и связей. Первый вариант был предложен Питером Ченом в 1976 г. (нотация Чена). Затем появились другие варианты (нотация Мартина, нотация IDEFIX, нотация Баркера и др.).

Впоследствии был создан целый ряд программных средств для автоматизированного построения ER-диаграмм, например: ERwin, SilverRun, Design/IDEF, Power Designer и др. Все они относятся к классу CASE-технологий (C omputer- A ssisted S ystems E ngineering – компьютеризированное проектирование систем).

Эти CASE-средства удобны тем, что в них процесс выделения сущностей, связей, а затем и атрибутов, является итерационным (повторяющимся). Разработав первый приближенный вариант ER-диаграммы, далее его уточняют, опрашивая экспертов предметной области, после чего все повторяется. При этом документацией, в которой фиксируются результаты опросов, являются сами ER-диаграммы. Попутно выполняется нормализация данных. Процесс заканчивается получением ER-диаграммы, соответствующей полной атрибутивной модели.

Рассмотрим работу с ER-диаграммами в нотации IDEFIX, используемой в CASE-средстве ERwin. Изучив конкретную предметную область, строим исходную ER‑диаграмму, соответствующую модели уровня сущностей (рис. 1.1).

 

Клиент размещает Заказ выполняется Сотрудник

 

 

Отдел состоит из

 

Рис. 1.1. ER‑диаграмма модели уровня сущностей

 

На рис. 1.1 связи между сущностями обозначены следующим образом:

 

сильная или идентифицирующая связь типа 1: М

слабая или неидентифицирующая связь типа 1: М

связь типа М: М

 

В случае связи 1: М (один ко многим) одна из связываемых сущностей выступает в роли родительской или главной, а другая – в роли дочерней или подчиненной. Эта связь каждому кортежу родительской сущности ставит в соответствие любое (в том числе нулевое) число кортежей дочерней сущности, однако каждый кортеж дочерней сущности может быть связан только с одним кортежем родительской сущности.

Механизм реализации связи «один ко многим» состоит в том, что в дочернюю сущность добавляются атрибуты, дублирующие ключевые атрибуты родительской сущности (т.е. атрибуты, входящие в первичный или альтернативный ключ). Эти атрибуты получают название внешнего ключа (Foreign Key, сокращенно FK) и с их помощью устанавливается связь между кортежами родительской сущности – с одной стороны – и подмножествами кортежей дочерней сущности – с другой. Еще такие атрибуты называют мигрирующими из родительской сущности. Если дочерняя сущность является зависимой от родительской сущности, то мигрирующие атрибуты включаются в состав первичного ключа дочерней сущности, в противном случае – в состав ее неключевых атрибутов.

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

Возвращаясь к рассмотрению примера, строим на следующем итерационном шаге ER‑диаграмму, соответствующую модели данных, основанной на ключах (рис. 1.2).

 

Клиент размещает Заказ выполняется Сотрудник

Таб. №

№ заказа Код клиента (FK) Таб. № (FK) Код товара (FK)

Код клиента

№ отдела (FK)

//

 

Товар заказывается Отдел состоит из

			№ отдела

 

 

Рис. 1.2. ER‑диаграмма модели, основанной на ключах

 

Далее, на очередном итерационном шаге, получаем ER‑диаграмму, соответствующую полной атрибутивной модели данных (рис. 1.3).

 

Клиент Заказ Сотрудник

Таб. №

Код клиента

	Фамилия Адрес Телефон
		№ отдела (FK) Фамилия Имя Отчество

размещает выполняется

 

 

Товар

Код товара

Отдел

Наименование Ед. измерения Цена ГОСТ

№ отдела

Название

заказывается состоит из

 

 

Рис. 1.3. ER‑диаграмма полной атрибутивной модели

 

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

Если логическая модель представлена в виде ER-диаграммы, то переход к физической модели значительно упрощается. В этом случае с помощью CASE-средства, например ERwin, можно выбрать нужную СУБД и автоматически создать соответствующую физическую модель данных. Затем на ее основе ERwin может сгенерировать системный каталог базы данных или соответствующий SQL-скрипт (описание базы данных на языке SQL). Этот процесс называется прямым проектированием. Тем самым достигается масштабируемость – создав один раз логическую модель данных, можно генерировать физические модели данных под любую СУБД, которую поддерживает ERwin. С другой стороны, ERwin способен по содержимому системного каталога базы данных или SQL-скрипту воссоздать физическую и логическую модели данных. Этот процесс называется обратным проектированием. На основе логической модели, полученной в процессе обратного проектирования, можно сгенерировать физическую модель и системный каталог базы данных для другой СУБД. Тем самым решается задача по переносу структуры базы данных с одной СУБД на другую, например с SQL Server на Oracle или с Access на Sybase и т.д.

 

Задание к работе