CC BY
113Технические науки УДК: 519.683.2, 004.4'22, 004.415.2.043
Романов С. С.
магистрант 2 курса
Хакасский Государственный Университет им. Н. Ф. Катанова
ОБ ИНФОЛОГИЧЕСКОМ МОДЕЛИРОВАНИИ БАЗ ДАННЫХ С ПОМОЩЬЮ
НОРМАЛИЗАЦИИ ER-ДИАГРАММ
В работе рассматривается проектирование баз данных посредством создания инфологической модели, выражаемой с помощью диаграмм методологии IDEF3 и ER-диаграмм. Представлен конкретный пример подобного проектирования вместе с описанием последовательной нормализации ER-диаграмм в три этапа для базы данных учета продаж.
Ключевые слова: ER-диаграммы, IDEF3, БД, проектирование, нормализация, сущности, инфологическая модель, моделирование.
Трудно представить сайт либо более-менее крупное приложение, особенно, если оно реализует какой-либо учет, которое бы не использовало базу данных (БД), создание которой, как правило, включает в себя этап проектирования.
Первым и самым главным этапом в процессе проектирования БД является создание инфологической модели. Важность и актуальность проектирования заключается в том, что с точки зрения затрат рабочего времени разработчиков ПО и, соответственно, затрат на оплату их работы, исправление ошибок, допущенных при проектировании, будет гораздо быстрее, проще и экономичнее, чем их исправление на дальнейших этапах процесса разработки.
Цель инфологического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой БД [3]. Для предварительного этапа в создании инфологической модели можно использовать нотацию IDEF0 методологии SADT. Нотация предоставляет достаточный набор используемых в ней видов объектов и связей для отражения предметной области.
IDEF0 — это методология функционального моделирования и нотация, предназначенная для формализации и описания бизнес-процессов в которой пристальное внимание уделяется соподчиненности объектов.
Чтобы построить инфологическую модель предметной области можно воспользоваться такими программными средствами как:
MS Visio — векторный графический редактор, редактор диаграмм и блок-схем для Windows. Является частью пакета MS Office;
IDEF0.EM Tool — мощное средство моделирования, в котором реализована данная методология, позволяет описывать, анализировать и совершенствовать сложные деловые процессы.
AllFusion Process Modeler 7 (ранее BPwin) — инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов;
Design/IDEF — комплексная система автоматизации проектирования ИС, объединяющая в себе несколько методологий.
Для создания инфологической модели в нотации IDEF0 был использован AllFusion Process Modeler 7. Соответствующие диаграммы представлены на рисунках ниже. Созданная концептуальная инфологическая модель отражает основные бизнес-процессы салона-магазина по продаже компьютерной техники. Процесс «Продажа товаров» был декомпозирован, т. к. он является наиболее важным в данной предметной области.
Рисунок 1. — Контекстная диаграмма
Рисунок 2. — Диаграмма первого уровня
Рисунок 3. — Диаграмма второго уровня (деятельность «Продажа товаров»)
Формирование логической модели данных, реализация ER диаграммы как прототипа схемы данных
В реляционной БД логическое проектирование является путем к разработке корректной схемы БД, в которой отсутствуют нежелательные зависимости между атрибутами сущностей. При этом можно расширить процесс проектирования с помощью декомпозиции. То есть последовательно проводить нормализацию отношений. Избавляясь, таким образом, от нежелательных зависимостей между атрибутами [1]. Чаще всего такие модели строятся с помощью диаграмм «сущность-связь» или Entity-Relationship (ER).
Для того чтобы построить логическую модель данных, выделим из инфологической модели данных сущности с учетом граничных условий, определенных ранее. Затем определим для каждой сущности первоначальный набор атрибутов и построим ненормализованную ER-диаграмму в программе AllFusion ERwin Data Modeler v7.2.
В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности — это имя типа, а не некоторого конкретного экземпляра этого типа.
В месте «стыковки» связи с сущностью используются:
• Трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много экземпляров сущности;
• Одноточечный вход, если в связи участвует один экземпляр сущности.
Тип линии может иметь особое значение. Обязательный конец связи изображается сплошной линией, а необязательный — прерывистой линией. В ERWin вместо трехточечного входа используется жирная точка.
Первоначальная ER-диаграмма представлена на рисунке ниже.
Рисунок 4. — Первоначальная ER-диаграмма до нормализации
Нормализация ЕЯ-диаграммы
Как и в случае схем реляционных БД, для ER-диаграмм вводится понятие нормальных форм. В первой нормальной форме ER-диаграммы устраняются атрибуты, содержащие множественные значения [3]. Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности. Далее приступим к процессу нормализации.
Первый этап нормализации
Здесь сразу можно отметить, что адрес следует декомпозировать в отдельную сущность, поскольку адрес сотрудника либо клиента имеет множество своих атрибутов: страна, регион, административная единица, населенный пункт, почтовое отделение (которое может быть центральным), улица, дом, корпус, секция, комната, и возможно другие.
С учетом правил нормализации можно сказать, что большая часть перечисленных атрибутов адреса не являются атомарными. Следовательно, сущность «Адрес» нужно декомпозировать на отдельные сущности. В целях нормализации, для однозначного определения каждого экземпляра сущностей и в целях отказа от использования составных первичных, будем назначать для каждой сущности уникальные идентификационные номера (ID) и назначать их первичными ключами.
Для связи декомпозированных сущностей следует добавить в атрибуты внешние ключи. При этом тип отношений между сущностями будет определяться по следующим принципам: 1 страна может включать в себя несколько регионов, 1 регион содержит несколько административных единиц, 1 административная единица — несколько населенных пунктов, населенный пункт — несколько почтовых отделений, почтовое отделение может обслуживать несколько улиц, одна и та же улица может входить в несколько адресов сотрудников или клиентов. Следовательно, нужно добавить сущности «Адрес сотрудника» и «Адрес клиента». Каждый экземпляр этой сущности будет связан с одной улицей и одним сотрудником/клиентом с помощью внешних ключей сущностей «Адрес клиента» и «Адрес сотрудника» к сущностям «Клиент» и «Сотрудник» соответственно и с внешним ключом к сущности «Улица» у обеих сущностей. К атрибутам этих двух сущностей следует добавить часть адреса, дополняющую адрес улицы до полного адреса. Она содержит номер дома, квартиры, корпуса, комнаты и т.д. Назовем этот атрибут «Адрес». Таким образом, мы отказались от полной нормализации сущности «Адрес», поскольку главная наша сущность — это заказы, а не адрес.
Нормализованная таким образом диаграмма представлена на рисунке 2. В процессе нормализации добавляются соответствующие атрибуты у создаваемых сущностей. Также были созданы внешние ключи. Для сущности «Заказы» это «Id сотрудник» и «Id клиент». В ERWin внешние ключи создаются автоматически и располагаются в той же области, что и первичный ключ с пометкой «(FK)», в случае выбора связи Identifying relationship (идентифицирующая связь). При этом возникает составной первичный ключ и осуществляется т.н. «миграция» первичного ключа из родительской сущности в дочернюю сущность. Нам это не нужно, поэтому используем тип связей Non-identifying relationship (не идентифицирующая связь). В ERWin необязательная не идентифицирующая связь обозначается пунктирной линией с жирной точкой на одном конце (дочернем) и ромбиком на другом (родительском).
Второй этап нормализации
Далее вынесем в отдельные сущности атрибуты, которые не характеризуют сущности, могут принимать значения из некоторого фиксированного списка значений и зачастую повторяются в разных экземплярах сущностей. Это такие атрибуты как: тип региона, тип административной единицы, тип населенного пункта, тип улицы, пол, фирма-клиент, марка, тип товара, тип заказа. Все эти вынесенные в отдельные сущности атрибуты будут присоединяться к соответствующим родительским сущностям путем добавления в родительские сущности внешних ключей. При этом тип связи для всех перечисленных сущностей будет «Один ко многим», поскольку один тип, либо пол, либо марка может быть назначен разным экземплярам родительских сущностей.
Рисунок 5. — ER-диаграмма после первого шага нормализации
Второй этап нормализации
Далее вынесем в отдельные сущности атрибуты, которые не характеризуют сущности, могут принимать значения из некоторого фиксированного списка значений и зачастую повторяются в разных экземплярах сущностей. Это такие атрибуты как: тип региона, тип административной единицы, тип населенного пункта, тип улицы, пол, фирма-клиент, марка, тип товара, тип заказа. Все эти вынесенные в отдельные сущности атрибуты будут присоединяться к соответствующим родительским сущностям путем добавления в родительские сущности внешних ключей. При этом тип связи для всех перечисленных сущностей будет «Один ко многим», поскольку один тип, либо пол, либо марка может быть назначен разным экземплярам родительских сущностей.
Затем атрибуты ФИО разбиваем на 3 отдельных атрибута, в целях приведения сущности к первой нормальной форме. Также разбиваем атрибут «Дата приема и увольнения» на 2 атрибута у сущности «Сотрудник». Должность и паспортные данные следует вынести в отдельные сущности, поскольку она является сущностью и может иметь свои атрибуты. Т.к. заказ должен оформлять сотрудник, принятый на должность, и на фоне возможного наличия в БД уволенных либо не еще не принятых на должность людей, то имеет смысл декомпозировать сущность «Сотрудник» на сущности «Сотрудник» и «Сотрудник на должности». При этом в атрибутах сотрудника оставляем те, которые закрепляются за человеком. А в сущности «Заказ» добавляем атрибут внешнего ключа к сущности «Сотрудник на должности». Атрибуты в «ФИО клиента/представителя фирмы» и «Наименование фирмы-клиента» удаляем и добавляем внешний ключ для связи с сущностью «Клиент».
Третий этап нормализации
Атрибуты «Средства связи» необходимо вынести в отдельные сущности — «Средства связи сотрудников» и «Средства связи клиентов» соответственно. Т.к. средства связи могут быть определенного вида, то сразу создаем сущность «Тип средств связи», которая имеет атрибут первичного ключа (ГО) и наименование типа средств связи. При этом тип связей и места создания внешних ключей задаются в соответствии с тем, что 1 сотрудник или клиент может иметь несколько средств связи. А несколько средств связи с разными номерами могут относиться к одному и тому же типу средств связи.
Атрибут «Фотографии сотрудника» необходимо вынести в отдельную сущность, в связи с тем, что в таком виде этот атрибут не удовлетворяет требованиям первой нормальной формы и будет отрицательно влиять на быстродействие при обновлении данных. Поскольку один сотрудник может иметь несколько фотографий, то связь будет «Один ко многим».
Затем нужно избавиться от отношения «Многие ко многим» между сущностями «Заказ» и «Товар». Это можно сделать путем ввода новой сущности «Состав заказа», которая будет иметь атрибуты ГО состав заказа, количество, стоимость за единицу, и внешние ключи для сущностей «Товар» и «Заказ». Типы связей при этом настраиваются по тому же принципу, что и у сущностей «Адрес сотрудника» и «Адрес клиента».
Осталось нормализовать сущность «Товар». В первую очередь нужно вынести в отдельную сущность атрибут «Характеристики». И назвать ее «Характеристика модели». Поскольку каждый экземпляр этой сущности — это характеристика определенного товара, то разумно, в том числе с позиций нормализации создать сущность «Характеристика». Также следует определить каждую характеристику к определенному типу товара. В числе атрибутов сущности задаем только первичный ключ, наименование характеристики и внешний ключ для связи с сущностью «Тип товара». Сущность «Характеристики модели» следует связать с сущностями «Характеристика» и «Товар». Поскольку один товар может иметь множество характеристик, то задаем связь «Один ко многим», между «Товар» и «Характеристика модели», с помощью создания внешнего ключа у сущности «Характеристика модели». Аналогично связываем эту же сущность с сущностью «Характеристика».
Рисунок 6. — ER-диаграмма после второго шага нормализации
Рисунок 7. — ER-диаграмма после третьего, завершающего шага нормализации
Литература
1. Баженова, И. Ю. Основы проектирования приложений баз данных / И. Ю. Баженкова — М.: Бином. Лаборатория знаний, 2009. — 328 с.
2. Базы данных. Вводный курс [Электронный ресурс] // citforum.ru. — URL: http://citforum.ru/database/advanced_intro/28.shtml. — (дата обращения 05.01.17).
3. Инфологическая модель баз данных «Сущность-связь» [Электронный ресурс] // Справочно-энциклопедический ресурс KM.RU. — URL: http://www.km.ru/referats/F376FF0C293847DB8E4A81EE56D18E53#. — (дата обращения 12.01.17).
