Информационная система ремонтной мастерской

Сущность «Ремонты» содержит следующие атрибуты: «Номер квитанции», «ФИО клиента», «Дата сдачи в ремонт», «Дата возвращения из ремонта», «Телефон клиента», «Адрес клиента», «Возможность гарантийного обслуживания», «Дата изготовления». Среди рассмотренных атрибутов в качестве ключевого можно принять атрибут номер квитанции, так как номер квитанции – уникальное числовое значение, присваиваемое каждому ремонту. Для связи с сущностью «Ремонтируемые объекты» необходимо ввести атрибут «Идентификатор ремонтируемого объекта». Для связи с сущностью «Типы ремонтов» необходимо ввести атрибут «Идентификатор типа ремонта». Для связи с сущностью «Сотрудники» необходимо ввести атрибут «Идентификатор мастера».

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

Сущность «Заказы на детали» содержит следующие атрибуты: «Номер заказа», «Поставщик», «Дата отправки заказа», «Дата приема заказа», «Стоимость заказа». Среди рассмотренных атрибутов в качестве ключевого можно принять атрибут «Номер заказа», так как «Номер заказа» – уникальное числовое значение, присваиваемое каждому отдельному заказу. Для связи с сущностью «Детали» необходимо ввести атрибут «Идентификатор детали».

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

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

 

Рисунок 2.1 - Связь между сущностями Сотрудники и Категории сотрудников

 

Необходимо  рассмотреть тип связи между сущностями «Ремонты» и «Сотрудники». Один сотрудник может выполнять несколько ремонтов, значит, тип связи – один-ко-многим.

 

Рисунок 2.2 –Связь между сущностями Сотрудники и Ремонты

 

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

 

Рисунок 2.3–Связь между сущностями Типы ремонтов и Ремонты

 

Необходимо  рассмотреть тип связи между сущностями «Ремонты» и «Ремонтируемые объекты». Каждый раз ремонтируется объект одного типа, значит тип связи – один-ко-многим.

 

Рисунок 2.4–Связь между сущностями Ремонтируемые объекты и Ремонты

 

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

 

Рисунок 2.5 – Связь между сущностями Ремонты и Информация о ремонтах

 

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

Рисунок 2.6–Связь между сущностями Детали и Заказы деталей

 

В сущности «Типы ремонтов» атрибут Детали будет представлен в виде строки, состоящей из перечисления значений, представляющих собой Идентификаторы деталей. Таким образом, сущности Детали и Заказы деталей не связаны ни с одной другой таблицей.

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

 

Рисунок 2.7 – ER-диаграмма предметной области «Ремонтная мастерская»

 

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

Необходимо  рассмотреть структуру отношения Сотрудники:

 

Таблица 2.1 – Структура отношения Сотрудники

Имя атрибута	Имя поля	Домен
Идентификатор сотрудника	ID	Числовой
Фамилия	Surname	Текстовый
Имя	Name	Текстовый
Отчество	Patronymic	Текстовый
Адрес клиента	Address	Текстовый
Категория	Category	Числовой
Телефон клиента	Telephone	Текстовый
Дата рождения	Birthdate	Дата/время
Специализация	Specialization	Текстовый
Дата приема на работу	HiringDate	Дата/время
Дата увольнения	FiringDate	Дата/время

 

Данное отношение  не имеет повторяющихся записей, в нём отсутствуют повторяющиеся группы полей, строки не упорядочены и столбцы не упорядочены. Значит, отношение находится в первой нормальной форме. Кроме того любое неключевое поле однозначно идентифицируется полным набором ключевых полей. Поэтому отношение находится во второй нормальной форме. В отношении ни одно из неключевых полей таблицы не идентифицируется с помощь другого неключевого поля. Следовательно, отношение находится в третьей нормальной форме.

Необходимо  рассмотреть структуру отношения Категории сотрудников:

 

Таблица 2.2 – Структура отношения Категории  сотрудники

Имя атрибута	Имя поля	Домен
Номер категории	Category#	Числовой
Минимальная оплата	Salary	Числовой

 

Данное отношение  не имеет повторяющихся записей, в нём отсутствуют повторяющиеся  группы полей, строки не упорядочены  и столбцы не упорядочены. Значит, отношение находится в первой нормальной форме. Кроме того любое  неключевое поле однозначно идентифицируется полным набором ключевых полей. Поэтому отношение находится во второй нормальной форме. В отношении ни одно из неключевых полей таблицы не идентифицируется с помощь другого неключевого поля. Следовательно, отношение находится в третьей нормальной форме.

Необходимо  рассмотреть структуру отношения Ремонты:

 

Таблица 2.3 – Структура отношения Ремонты

Имя атрибута	Имя поля	Домен
№ квитанции	Rec#	Числовой
№ модели	Object_code	Числовой
Тип ремонта	Repair_type	Числовой
ФИО клиента	Client_inits	Текстовый
Адрес клиента	Client_address	Текстовый
Телефон клиента	Client_phone#	Текстовый
Гарантия	IsGuarantee	Логический
Дата изготовления	Fabric_date	Дата/время
Дата сдачи в ремонт	Receipt_date	Дата/время
Дата возвращения из ремонта	Return_date	Дата/время
Идентификатор сотрудника	MasterID	Числовой

 

Данное отношение  не имеет повторяющихся записей, в нём отсутствуют повторяющиеся  группы полей, строки не упорядочены  и столбцы не упорядочены. Значит, отношение находится в первой нормальной форме. Кроме того любое  неключевое поле однозначно идентифицируется полным набором ключевых полей. Поэтому отношение находится во второй нормальной форме. В отношении ни одно из неключевых полей таблицы не идентифицируется с помощь другого неключевого поля. Следовательно, отношение находится в третьей нормальной форме.

Необходимо  рассмотреть структуру отношения Типы ремонтов:

 

Таблица 2.4 – Структура отношения Типы ремонтов

Имя атрибута	Имя поля	Домен
Идентификатор типа ремонта	Code	Числовой
Название	RepairName	Текстовый
Минимальная оплата	Payment	Денежный
Минимальное время ремонта	Repair_term	Числовой
Необходимые детали	Details	Текстовый

 

Данное отношение не имеет повторяющихся  записей, в нём отсутствуют повторяющиеся  группы полей, строки не упорядочены  и столбцы не упорядочены. Значит, отношение находится в первой нормальной форме. Кроме того любое неключевое поле однозначно идентифицируется полным набором ключевых полей. Поэтому отношение находится во второй нормальной форме. В отношении ни одно из неключевых полей таблицы не идентифицируется с помощь другого неключевого поля. Следовательно, отношение находится в третьей нормальной форме.

Необходимо  рассмотреть структуру отношения Ремонтируемые объекты:

 

Таблица 2.5 – Структура отношения Ремонтируемые объекты

Имя атрибута	Имя поля	Домен
Идентификатор модели	Code	Числовой
Производитель	Manufacturer	Текстовый
Маркировка	Model	Текстовый
Тип объекта	Object_type	Текстовый
Гарантийный срок	Guarantee_term	Числовой
Доступные ремонты	AvailRepairs	Текстовый

 

Данное отношение  не имеет повторяющихся записей, в нём отсутствуют повторяющиеся  группы полей, строки не упорядочены  и столбцы не упорядочены. Значит, отношение находится в первой нормальной форме. Кроме того любое  неключевое поле однозначно идентифицируется полным набором ключевых полей. Поэтому отношение находится во второй нормальной форме. В отношении ни одно из неключевых полей таблицы не идентифицируется с помощь другого неключевого поля. Следовательно, отношение находится в третьей нормальной форме.

Необходимо  рассмотреть структуру отношения  Информация о ремонте.

 

Таблица 2.6 – Структура отношения Ремонтируемые объекты

Имя атрибута	Имя поля	Домен
Номер квитанции	Rec	Числовой
Код детали	NumDet	Числовой
Количество деталей	Quantity	Числовой

 

Данное отношение  не имеет повторяющихся записей, в нём отсутствуют повторяющиеся  группы полей, строки не упорядочены  и столбцы не упорядочены. Значит, отношение находится в первой нормальной форме. Кроме того любое  неключевое поле однозначно идентифицируется полным набором ключевых полей. Поэтому отношение находится во второй нормальной форме. В отношении ни одно из неключевых полей таблицы не идентифицируется с помощь другого неключевого поля. Следовательно, отношение находится в третьей нормальной форме.

 

Необходимо  рассмотреть структуру отношения Детали:

 

Таблица 2.7 – Структура отношения Детали

Имя атрибута	Имя поля	Домен
Идентификатор детали	Code	Числовой
Название	Detail_name	Текстовый
Наличие	OnHand	Числовой
Цена	Price	Денежный

 

Данное отношение  не имеет повторяющихся записей, в нём отсутствуют повторяющиеся  группы полей, строки не упорядочены  и столбцы не упорядочены. Значит, отношение находится в первой нормальной форме. Кроме того любое  неключевое поле однозначно идентифицируется полным набором ключевых полей. Поэтому отношение находится во второй нормальной форме. В отношении ни одно из неключевых полей таблицы не идентифицируется с помощь другого неключевого поля. Следовательно, отношение находится в третьей нормальной форме.