Автоматизация автосервиса

Для дальнейшего совершенствования  отношения необходимо преобразовать  его в ЗНФ.

Отношение находится в ЗНФ, если оно находится  в 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

Существует  и альтернативное определение. Отношение  находится в ЗНФ в том и  только в том случае, если все  неключевые атрибуты отношения взаимно  независимы и полностью зависят  от первичного ключа.

Усиленная ЗНФ или нормальная форма Бойса-Кодда (БКНФ).

Отношение находится в БКНФ, если оно находится  в ЗНФ и в нем отсутствуют  зависимости ключей (атрибутов составного ключа) от не ключевых атрибутов.

Четвертая нормальная форма.

Отношение R находится в четвертой нормальной форме (4НФ) в том и только в  том случае, когда существует многозначная зависимость А=>В, а все остальные атрибуты R функционально зависят от А.

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

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

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

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

При решении поставленной задачи разработано  5 таблиц для хранения информации.

Таблица Avto предназначена для хранения полной информации о автомобиле и содержит следующие поля, табл. 6:

Таблица 6

Описание  входных данных для таблицы Avto

Имя поля	Тип поля	Размер поля	Описание
CodeAuto	Числовой, ключ	10	* Код автомобиля
TMAuto	Текстовый	40	Марка авто
StateSign	Текстовый	12	Регистр. знак
Tpassport	Текстовый	12	Тех. паспорт
ColourAuto	Текстовый	40	Цвет авто
Year	Дата		Год выпуска
MotorNum	Текстовый	12	Двигатель №
BodyNum	Текстовый	12	Кузов №
Info	Текстовый	255	Примечание

В таблице Owners содержится информация о владельцах автомобилей (табл. 7).

Таблица 7

Описание  входных данных для таблицы Owners

Имя поля	Тип поля	Размер поля	Описание
CodeOwner	Числовой, ключ	10	* Код владельца, обеспечивает  уникальность записей
OLastName	Текстовый	50	Фамилия
OFirstName	Текстовый	50	Имя
OSecondName	Текстовый	50	Отчество
OPassportNum	Текстовый	6	Паспорт №
ODrvLicence	Текстовый	12	Права №
Phone	Числовой		Телефон
Info	Текстовый	255	Примечание

Таблица AOrders предназначена для хранения подробных данных по заказам на проведение ремонта автомобиля. Данная таблица содержит следующие поля:

Таблица 8

Описание  входных данных для таблицы AOrders

Имя поля	Тип поля	Размер поля	Описание
OrderNum	Числовой, ключ	12	* Номер заказа
CodeAuto	Числовой, ключ	12	* Код автомобиля
CodeOwner	Числовой, ключ	12	* Код владельца
ActDate	Дата		Дата поступления
Info	Текстовый	255	Примечание

Услуги  заказа (OrderWork). Вспомогательная таблица для организации вычислений.

Таблица 9

Описание  входных данных для таблицы OrderWork

Имя поля	Тип поля	Размер поля	Описание
OrderNum	Числовой, ключ	12	* Номер заказа
CodeWork	Числовой, ключ	12	* Код работы

Установка запчастей (PutInPart). Вспомогательная таблица для организации вычислений.

Таблица 10

Описание  входных данных для таблицы PutInPart

Имя поля	Тип поля	Размер поля	Описание
OrderNum	Числовой, ключ	12	* Номер заказа
CodePart	Числовой, ключ	12	* Код автозапчасти

Таблицы Avto (Автомобили), Owners (Владельцы) и AOrders (Заказ) связанны между собой для обеспечения целостности БД. Данные таблицы нормализованы по требованиям и приведены в 4НФ. Таблицы Avto и AOrders имеют связь один-ко-многим. Этот же тип связи имеют между собой и таблицы Owners и AOrders. Это достигается путем введения в каждой таблицы ключевых полей, которые обеспечивают не повторяемость записей. Для осуществления целостности данных таблицы связаны по индексным полям.

Аналогичную связь имеют таблицы заказы и запчасти, и заказы и виды работ. Где установлена связь один-ко-многим, т.е. один заказ может содержать несколько видов работ.

Для описания видов работ в таблице разработаны следующие поля:

Таблица 11

Описание  входных данных для таблицы Work

Имя поля	Тип поля	Размер поля	Описание
CodeWork	Числовой, ключ	12	* Код работы
KindWork	Числовой		Стоимость работы
CostWork	Дата		Срок выполнения
PeriodEx	Текстовый	255	Вид работы
Guarantee	Дата		Гарантия

 

В таблице запчасти имеются следующие поля, табл. 12:

Таблица 12

Описание  входных данных для таблицы NewPart

Имя поля	Тип поля	Размер поля	Описание
CodePart	Числовой, ключ		* Код автозапчасти
PartName	Текстовый	255	Наименование
CostPart	Числовой		Стоимость
Guarantee	Дата		Гарантия

Третий этап разработки автоматизированной системы – тестирование автоматизированной системы по обработке заявок предприятия автосервиса ООО «АЛЬФА-М»

Тестирование  работоспособности автоматизированной системы по обработке заявок предприятия  автосервиса ООО «АЛЬФА-М» на наличие ошибок, тестирование программы на корректность работы в различных версиях операционной системы Windows.

 Четвертый этап разработки  автоматизированной системы – сдача программы в эксплуатацию

Финальное тестирование проекта. Обучение персонала  работе с автоматизированной системой по обработке заявок предприятия автосервиса ООО «АЛЬФА-М».

Пятый этап разработки автоматизированной системы – внедрение системы в работу по обработке заявок предприятия автосервиса ООО «АЛЬФА-М».

2.1.2 Ожидаемые риски  на этапах жизненного цикла  и их описание

Среди факторов риска при внедрении технологий электронного бизнеса можно отметить следующие:

• Неготовность персонала;
• Проблемы безопасности при передаче данных;
• Наличие коммерческих данных, которые не могут быть общедоступными;
• Неготовность контрагентов.

Риски на подэтапе «Определение требований к  ИС». Основной риск на данном подэтапе это недостаточное определение свойств ИС, требуемых для решения задачи и неправильный выбор задач проектирования (чрезмерно большой или недостаточный объем задач автоматизации). Это может потребовать, на этапе эксплуатации, дополнительной доработки ИС, что приведет к финансовому риску. Риск предотвращается использованием современных case-средств при моделировании бизнес-процессов. При возникновении такого риска проводится дополнительное моделирование с использованием современных case-средств.

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

Риски на подэтапе «Разработка проекта автоматизации». Основной риск это разработка неэффективного плана-графика автоматизации: использование  лишних ресурсов или недостаточность  ресурсов. Данный риск является финансовым, предотвращается использованием современных  автоматизированных средств проектирования. В случае возникновения, риск устраняется повторной корректировкой плана-графика автоматизации.

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

На подэтапе «Подготовка к разработке ПО»  основной риск это неправильная формализация расчетов показателей. Риск устраняется  тестированием программных модулей  на этапе внедрения.