База данных

Важным свойством модели «сущность-связь» является её графическое представление в виде ER-диаграммы. Краткая ER-диаграмма содержит набор сущностей без указания их атрибутов и набор действий, отражающих связи между сущностями. Для всех связей отмечается тип и класс принадлежности.

Краткая ER-диаграмма базы повреждений цифрового оборудования показанная на рисунке 3.1.

 

 

Рисунок 3.1 – Краткая ER-диаграмма

Примерная или краткая ER-диаграмма содержит ряд сущностей, связанных между собой определенными действиями и связями.

Сущности «Виды аппаратуры», «Характер повреждения», «По названию», «Неисправность/отказ», «Номер РЦС» представляют собой сильные сущности. На их основе реализуется главная сводная база всех повреждений цифрового оборудования, а так же осуществляются запросы по различным параметрам. Они являются однотипными и, главным образом,  предназначены для перечня типов оборудования и характера повреждения. Сущность «Номер РЦС» содержит перечень главных региональных центров.

Данные сущности характеризуются  двумя атрибутами. К числу атрибутов вышеперечисленных сущностей относятся: идентификатор или условное обозначение (ID), а так же непосредственно сама характеристика (тип оборудования, тип повреждения, название аппаратуры, неисправность/отказ, номер РЦС).

 Зависимая сущность «База повреждений цифрового оборудования» строится на основе сильных сущностей, а также поступающих заявок на регистрацию повреждений. Она представляет собой единую главную единицу, в которой осуществляется сбор всех зарегистрированных повреждений. К числу атрибутов данной сущности относятся: идентификатор, дата повреждения, номер РЦС, станция, время устранения, тип повреждения, тип аппаратуры, оборудование по названию, неисправность/отказ, описание и конкретная причина.

Остальные сущности строятся на основе запросов из общей базы, а так же сущностей «Виды аппаратуры», «Характер повреждения», «По названию», «Неисправность/отказ» и «Номер РЦС». На их основе выполняется подсчёт общего количества повреждений по различным критериям (типу оборудования, названию аппаратуры и т.д.) как по всей базе в целом, так и за отдельный требуемый период.

Например, в зависимой  сущности «общее количество повреждений  за весь период» выполняется расчёт количества повреждений по четырём  критериям. Так, в сущности «общее количество повреждений за весь период по типу аппаратуры» будут присутствовать следующие атрибуты: тип аппаратуры, всего по РЦС, РСЦ-1, РЦС-2, РЦС-3, РЦС-4, РЦС-5, ШЧ-2. Остальные сущности имеют идентичный набор атрибутов в соответствии с характером запроса.

Действия, связывающие  сущности, также могут быть охарактеризованы некоторыми атрибутами. Действие «Регистрация повреждения» содержит следующие атрибуты: дата повреждения, номер РЦС, станция, время устранения, тип повреждения, тип аппаратуры, оборудование по названию, неисправность/отказ, описание и конкретная причина.

Спроектированная по такой схеме база данных должна обладать различными функциями и свойствами:

– обеспечивать доступ к разнообразным данным, позволять из просматривать, а в случае необходимости – редактировать;

– обеспечение ссылочной целостности;

– реализации часто встречающихся запросов в готовом виде;

– предоставление возможность сформировать готовый запрос;

– предоставление возможности  построения сводной диаграммы.

3.2 Логическое  проектирование базы данных

Первым шагом при  логическом проектировании выполняется  преобразование ER-диаграммы в схему  базы данных. Схема данных, как и  диаграмма, отражает связи между  отношениями базы, но вместе с этим она дополнительно обеспечивает условие ссылочной целостности. Для преобразования ER-диаграммы в схему БД приведём уточнённую ER-диаграмму, содержащую атрибуты сущностей. Уточнённая ER-диаграмма показана на рисунке 3.2.

Рисунок 3.2 – Полная ER-диаграмма

Для сущностей «Виды аппаратуры», «Характер повреждения», «По названию», «Неисправность/отказ», «Номер РЦС» атрибут «ID» будем использовать в качестве первичного ключа. Для остальных сущностей введём суррогатные первичные ключи, не несущие полезную информацию.

Преобразование ER-диаграммы в схему БД выполняется путём сопоставления отношения каждой сущности и каждой связи, имеющей атрибуты. Cвязи 1:M не имеют дополнительных атрибутов, поэтому отношения будем создавать только для сущностей.

Схема данных базы повреждений цифрового оборудования показана на рисунке 3.3.

Рисунок 3.3 – Схема данных базы повреждений цифрового оборудования

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

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

Для удобства ввода данных определим некоторые атрибуты отношений. Их перечень, тип данных и основные характеристики представлены в таблице 3.1 – таблице 3.6.

Таблица 3.1 – Атрибуты отношения «Характер повреждения»

Содержание поля	Имя поля	Тип данных	Дополнительно
Условное обозначчение	Id_povregd	Счётчик	Первичный ключ
Тип повреждения	tip_povregdeniya	Текстовый	Обязательное поле

 

Таблица 3.2 – Атрибуты отношения «Виды аппаратуры»

Содержание поля	Имя поля	Тип данных	Дополнительно
Условное обозначчение	id_apparatura	Счётчик	Первичный ключ
Тип аппаратуры	tip_apparatury	Текстовый	Обязательное поле

 

Таблица 3.3 – Атрибуты отношения «По названию»

Содержание поля	Имя поля	Тип данных	Дополнительно
Условное обозначчение	id_nazvanie	Счётчик	Первичный ключ
По названию	po_nazvaniu	Текстовый	Обязательное поле

 

Таблица 3.4 – Атрибуты отношения «Неисправность/отказ»

Содержание поля	Имя поля	Тип данных	Дополнительно
Условное обозначение	id_neispravnost	Счётчик	Первичный ключ
Неисправность/отказ	neispravnost	Текстовый	Обязательное поле

 

Таблица 3.5 – Атрибуты отношения «Номер РЦС»

Содержание поля	Имя поля	Тип данных	Дополнительно
Условное обозначчение	id_RCS	Счётчик	Первичный ключ
Номер РЦС	nomer_RCS	Текстовый	Обязательное поле

 

Таблица 3.6 – Атрибуты отношения «База повреждений  цифрового оборудования»

Содержание поля	Имя поля	Тип данных	Дополнительно
Номер п/п	id_RCS	Счётчик	Первичный ключ
Дата	data	Дата/время	Краткий формат даты, 00.00.0000г.
Номер РЦС	RCS	Числовой	Внешний ключ к «Номер РЦС»
Станция	station	Текстовый
Время	time	Дата/время	Краткий формат времени, 00:00
Тип повреждения	povregdenie	Числовой	Внешний ключ к «Характер  повреждения»
Продолжение таблицы 3.6
Тип аппаратуры	apparatura	Числовой	Внешний ключ к «Виды  аппаратуры»
По названию	nazvanie	Числовой	Внешний ключ к «По  названию»
Неисправность/отказ	neisprav_otkaz	Числовой	Внешний ключ к «Неисправность/отказ»
Описание	opisanie	Поле МЕМО
Конкретная причина повреждения	prichina	Поле МЕМО

Чтобы убедиться в правильности логического проектирования, необходимо проверить её на соответствие требованиям  нормализации минимум до третьей  нормально формы (3 НФ) включительно. Процесс проектирования БД с использованием метода нормальных форм является итерационным и заключается в последовательном переводе отношений из первой нормальной формы в нормальные формы более высокого порядка по определённым правилам. Каждая следующая нормальная форма ограничивает определённый тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями БД и сохраняет свойства предшествующих нормальных форм.

Достижение нормальных форм (НФ) производилось  постепенно по мере проектирования базы данных, поэтому стоит только указать на принадлежность базы повреждений оборудования к начальным формам.

1НФ. Для приведения таблиц к  1НФ требуется составить прямоугольные  таблицы (один атрибут – один  столбец) и разбить сложные  атрибуты на простые, а многозначные атрибуты вынести в отдельные отношения. Такое представление данных позволяет производить поиск по отдельной части атрибута. В отношениях, приведённых в таблице 3.1 – таблице 3.6, сложные и многозначные атрибуты отсутствуют, следовательно, требования 1 НФ выполняются.

2НФ. Отношение находится в 2НФ, если оно находится в 1НФ  и каждый неключевой атрибут  функционально полно зависит  от первичного ключа (составного). В нашем случае все ПК простые, а неключевые атрибуты полностью от них зависят, поэтому можно утверждать, что БД находится во 2 НФ.

3НФ. Отношение находится в 3НФ, если оно находится в 2НФ  и каждый неключевой атрибут  нетранзитивно зависит от первичного  ключа. Т.е. отношение находится  в 3НФ в том и только в  том случае, если все неключевые  атрибуты отношения взаимно независимы и полностью зависят от первичного ключа. В полученных нами отношениях это условие соблюдается, следовательно, логическая модель БД удовлетворяет требованиям 3 НФ.

3.3 Физическое проектирование базы данных

Физическое проектирование базы данных осуществляется с помощью пакета Microsoft Access.

Этап физического проектирования заключается в увязке логической структуры БД и физической среды  хранения с целью наиболее эффективного размещения данных. С помощью конструктора таблиц для каждого реляционного отношения (таблица 3.1 – таблица 3.5) создаём таблицу, определяем количество, имена и типы полей, дополнительные ограничения на значения. Полученные отношения связываем в окне схемы данных в соответствии с логической моделью базы данных (рисунок 3.3). Физическая реализация в Microsoft Access логической модели приведена на рисунке 3.4.

Рисунок 3.4 – Схема  данных в Microsoft Access 2003

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

База данных представлена в виде единой главной формы (рисунок 3.5), посредствам которой осуществляется выполнение требуемых функций, а  также осуществляется переход на интересующие формы.