2.2 Разработка базы данных проектируемого программного средства

В теории баз данных существует ряд методов разработки моделей БД, отображающих разные уровни ее архитектуры. Распространены два основных подхода к проектированию систем баз данных: «нисходящий» и «восходящий».

«Восходящее» проектирование – это достаточная сложная и устаревшая методика, требующая значительного объема мероприятий по нормализации схем реляционных отношений и подходящая для проектирования небольших баз данных [17].

При «нисходящем» проектировании осуществляется структурное проектирование сверху-вниз. Такой процесс называется анализом – происходит изучение описания предметной области, а затем разделение целого на составные части с последующим изучением. Начинается этот подход с разработки моделей данных, которые содержат несколько высокоуровневых сущностей и связей, затем работа продолжается в виде серии нисходящих уточнений низкоуровневых сущностей, связей и относящихся к ним атрибутов.

Таким образом, для проектирования базы данных необходимо использовать «нисходящий» подход, содержащий ряд этапов:

- анализ предметной области. На основе анализа предметной области получают описание внешнего уровня БД, являющееся исходными данными для следующего этапа;

- разработка инфологической модели (ИЛМ). По полученному на предыдущем этапе описанию строится модель данных использующая модель «сущность-связь»;

- разработка даталогической модели (ДЛМ). На основе ИЛМ предметной области строится ДЛМ БД;

- нормализация. Этап представляет собой нормализацию полученной модели;

- формирование физической модели БД на языке описания данных СУБД. На заключительном этапе проектирования строится физическая модель данных с учетом особенностей используемой СУБД.

2.2.1 Формализованное описание предметной области

Формализованное описание предметной области содержит описание классов объектов (сущностей), выявленных на этапе анализа предметной области и связей (отношений) между ними. Оно необходимо для того, чтобы определить, какие данные будут в таблицах разрабатываемой БД, а также логические ограничения полей этих таблиц [18].

Формализованное описание предметной области представлено в таблице 2.2

Таблица 2.2 – Формализованное описание предметной области

Объект	Ключ	Физические характеристики	Обязательность значения	Логические ограничения	Процессы
ПОМЕЩЕНИЕ
ID помещения	УК, ПК	Целое 5	непустое	>0		Г, Пр
Имя		Символьное 30	непустое			Вв,Пр,У

Продолжение таблицы 2.2

Номер

Символьное 4

непустое

>0

Вв,Пр,У

Этаж

Целое 1

непустое

>0

Вв,Пр,У

ID типа помещения

Целое 5

непустое

>0

Пр

ТИПЫ ПОМЕЩЕНИЙ

ID типа помещения

УК, ПК

Целое 5

непустое

>0

Г, Пр

Тип

Символьное 30

непустое

Вв,Пр,У

Описание

Символьное 10

непустое

Вв,Пр,У

ОБОРУДОВАНИЕ

ID оборудования

УК, ПК

Целое 5

непустое

>0

Г, Пр

ID типа оборудования

Целое 5

непустое

>0

Пр

ID помещения

Целое 5

непустое

>0

Пр

Инвентарный номер

Символьное 10

непустое

>0

Пр

Объект

Ключ

Физические характеристики

Обязательность значения

Логические ограничения

Процессы

Серийный номер

Символьное 10

непустое

>0

Пр

Ввод в эксплуатацию

Дата

непустое

дд.мм.ггг

Вв,Об,Пр,У

Имя

Символьное 30

непустое

Вв,Пр,У

Продолжение таблицы 2.2

ТИП ОБОРУДОВАНИЯ
ID типа оборудования	УК, ПК	Целое 5	непустое				>0			Г, Пр
Тип оборудования		Символьное 30	непустое							Вв,Пр,У
Описание		Символьное 100	непустое							Вв,Пр,У
КЛАССЫ ОБОРУДОВАНИЯ
ID класса	УК, ПК	Целое 5			непустое			>0	Г, Пр
Класс оборудования		Символьное 30			непустое			>0	Вв,Пр,У
Описание		Символьное 100			непустое				Вв,Пр,У
ПОЛЬЗОВАТЕЛИ
ID пользователя	УК, ПК	Целое 5		непустое		>0					Г, Пр
ID типа пользователя		Целое 5		непустое		>0					Пр, Об
Объект	Ключ	Физические характеристики		Обязательность значения		Логические ограничения					Процессы
Логин		Символьное 20		непустое							Вв,Об,Пр,У
Пароль		Символьное 20		непустое							Вв,Об,Пр,У
Фамилия		Символьное 30		непустое							Вв,Об,Пр,У
Имя		Символьное 20		непустое							Вв,Об,Пр,У

Продолжение таблицы 2.2

Отчество		Символьное 20		непустое				Вв,Об,Пр,У
Инициалы		Символьное 20		непустое				Г
ТИП ПОЛЬЗОВАТЕЛЯ
ID типа пользователя	УК, ПК	Целое 5	непустое			>0	Г, Пр
Тип пользователя		Символьное 15	непустое				Вв,Пр,Об,У
ЗАЯВКИ
ID заявки	УК, ПК	Целое 5		непустое	>0			Г, Пр
ID пользователя		Целое 5		непустое	>0			Пр, Об
ID помещения		Целое 5		непустое	>0			Пр, Об
ID устройства		Целое 5		непустое	>0			Пр, Об
Объект	Ключ	Физические характеристики		Обязательность значения	Логические ограничения			Процессы
ID класса устройства		Целое 5		непустое	>0			Пр, Об
Дата создания		Дата		непустое	дд.мм.ггг			Вв,Об,Пр,У
Дата выполнения		Дата		непустое	дд.мм.ггг			Вв,Об,Пр,У
ID статуса		Целое 5		непустое	>0			Пр, Об

Продолжение таблицы 2.2

СТАТУС ЗАЯВКИ
ID статуса	УК, ПК	Целое 5	непустое	>0	Г, Пр
Статус		Символьное 15	непустое		Вв,Пр,Об,У

В таблице 2.2 использованы следующие сокращения: УК – уникальный ключ, ПК – первичный ключ Г – генерация данных, Вв – ввод данных, Пр –просмотр данных, Об – обновление, У – удаление.

Теперь необходимо выявить взаимосвязи сущностей предметной области.

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

Существующие типы связей:

- первый тип – связь один-к-одному (1:1). В каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В;

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

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

Связи между сущностями, их тип и описание связи отражены в таблице 2.3.

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

Таблица 2.3 – Связи между сущностями

Название связи	Тип связи	Сущность 1	Сущность 2
соответствует	М:1	Помещение	Определенному типу помещения
соответствует	М:1	Тип оборудования	Определенному классу оборудования
соответствует	М:1	Пользователь	Определенному типу пользователя
соответствует	М:1	Оборудование	Определенному помещению
соответствует	1:М	Пользователь	Различное множество заявок
соответствует	М:1	Оборудование	Определенному типу оборудования
соответствует	1:М	Помещение	Различному множеству заявок
имеют	М:1	Заявки	Определенный статус
соответствует	М:1	Заявки	Определенное оборудование