Автоматизация процесса подбора запчастей для ремонта и предварительной описи по выполненным работам автомобилей

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

2.2 Цели и методы моделирования системы

Только небольшие организации могут осуществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы). Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений [8].

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

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

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

Таким образом, каждый из рассмотренных подходов к проектированию воздействует на результаты проектирования в разных направлениях. Желание достичь их гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной - для ее совершенствования с целью повышения эффективности обработки данных.

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

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

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

Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними, а также их свойства (атрибуты) [20].

Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром - Москва, Киев и т.д.

Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Здесь также существует различие между типом и экземпляром. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет - это только атрибут продукта производства, а для лакокрасочной фабрики цвет - тип сущности.

Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.

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

При построении инфологических моделей используют язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь) или принцип декомпозиции.

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

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

2.3 Проектирование базы данных

Система управления базами данных (СУБД) -- это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями. Обычно СУБД различают по используемой модели данных. Так, СУБД, основанные на использовании реляционной модели данных, называют реляционными СУБД.

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

Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

Остальные модели, показанные на рис. 2.1, являются компьютеро-ориентированными. С их помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных [3].

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

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

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

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

Выделяют следующую основную последовательность нормальных форм:

- первая нормальная форма (1НФ);

- вторая нормальная форма (2НФ);

- третья нормальная форма (ЗНФ);

- усиленная третья нормальная форма, или нормальная форма Бойса-Кодда (БКНФ);

- четвертая нормальная форма (4НФ);

Первая нормальная форма. Отношение находится в 1НФ, если все его атрибуты являются простыми (имеют единственное значение). Исходное отношение таким образом, чтобы оно было в 1НФ.

Перевод отношения в следующую нормальную форму осуществляется путем «декомпозиции без потерь». Такая декомпозиция должна обеспечить то, что запросы (выборка данных по условию) к исходному отношению и к отношениям, получаемых в результате декомпозиции, дадут одинаковый результат.

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

Для устранения частичной зависимости и перевода отношения в 2НФ необходимо, используя операцию проекции, разложить его на несколько отношений следующим образом:

- построить проекцию без атрибутов, находящихся в частичной функциональной зависимости от первичного ключа;

- построить проекции на части составного первичного ключа и атрибуты, зависящие от этих частей.

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

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

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

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

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

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

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

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

Различают физическую и логическую целостность [3]. Физическая целостность означает наличие физического доступа к данным и то, что данные не утрачены. Логическая целостность означает отсутствие логических ошибок в базе данных, к которой относятся нарушение структуры БД или ее объектов, удаление или изменение установленных связей между объектами. В дальнейшем речь будем вести о логической целостности.

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

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

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

Данные в таблице хранятся в строках и столбцах. Каждый столбец имеет свое имя и присвоенный столбцу тип данных. Данные в столбце могут быть только одного типа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.1 Построение ER - диаграмм экземпляров сущностей и ER - диаграмм типа

На данном этапе проектирования необходимо выделить сущности и связи между объектами. Ранее были выделены и описаны следующие сущности:

Avto (Код автомобиля, марка авто, регистр. знак, тех. паспорт, цвет авто, год выпуска, двигатель №, кузов №, примечание);

Owners (Код владельца, фамилия, имя, отчество, паспорт №, права №, телефон, примечание);

AOrders (номер заказа, код автомобиля, код владельца, дата поступления, примечание);

OrderWork (номер заказа, код работы);

PutInPart (номер заказа, код автозапчасти);

АWork (код работы, стоимость работы, срок выполнения, вид работы, гарантия);

NewPart (код автозапчасти, наименование, стоимость, гарантия).

Рассмотрим связи между ними:

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

Дальше идет непосредственное построение ER - диаграммы с учетом всех необходимых сущностей и связей между ними (рис.2.2).

Размещено на http://www.allbest.ru/

Рисунок 2.2 - ER-диаграмма

2.3.2 Инфологическая модель данных «Сущность-связь»

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

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

Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности.

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

Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.

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

автоматизированный система информация автомобиль

2.4 Расчет годовой программы ТО и ТР

2.4.1 Корректирование периодичности ТО и ТР

Для расчета предварительно необходимо для данного автотранспортного предприятия выбрать нормативные значения пробегов подвижного состава периодичности ТО-1 и ТО-2, которые установлены для определенных условий, а именно: категории условий эксплуатации, базовых моделей автомобилей и холодного климатического района [15].

Для конкретного автотранспортного предприятия эти условия могут отличаться, поэтому в общем случае нормируемые пробег до списания и периодичность ТО-1 и ТО-2 определяются с помощью коэффициентов, учитывающих категорию условий эксплуатации К1, модификацию подвижного состава К2 и климатический район К3.

Пробеги до ТО-1 L1, ТО-2 L2 , км, рассчитываются по формулам.

, (2.1)

где , ,- нормативные пробеги соответственно до ТО-1 и ТО-2.

Откорректированный пробег до ТО-1 делим на принятый к расчету среднесуточный пробег и получаем принятый к расчету пробег до ТО-1.

Откорректированный пробег до ТО-2 делим на принятый к расчету пробег до ТО-1 и получаем принятый к расчету пробег до ТО-2.

Трудоемкость корректируется в зависимости от модификации автомобиля и от числа технологически совместимого подвижного состава.

, (2.2)

где - скорректированная трудоемкость, чел-ч;

- нормативная удельная трудоемкость, чел-ч;

- коэффициент, учитывающий модификацию автомобиля;

- коэффициент, учитывающий число технологически совместимого подвижного состава.

, (2.3)

где - скорректированная удельная трудоемкость ТР чел-ч/1000 км;

- нормативная удельная трудоемкость ТР, чел-ч/1000 км;

- коэффициент, учитывающий условия эксплуатации;

- коэффициент, учитывающий модификацию автомобиля;

- коэффициент, учитывающий природно-климатические условия;

- коэффициент, учитывающий пробег сначала эксплуатации;

- коэффициент, учитывающий число технологически совместимого

подвижного состава.

Коэффициент технической готовности рассчитываем по формуле:

(2.4)

где Lcc - среднесуточный пробег а/м

Дор - продолжительность простоя а/м в ТО-2 и ТР

Кґ4 - коэффициент корректировки продолжительности простоя в ТО и ремонте в зависимости от пробега с начала эксплуатации

Годовую трудоемкость работ по ТР рассчитываем по формуле:

где L - суммарный годовой пробег автомобилей в группе, км;

tТР - скорректированная трудоемкость ТР.

L = Аu * Lcc* Дкг * би, (2.6)

где Аu - списочное количество а/м,

Дкг - дни календарные в году, 365

би - коэффициент использования парка а/м

бт - коэффициент технической готовности

Дрг - дни рабочие в году, 249.

би = бт * Дрг / Дкг. (2.7)

Годовую трудоемкость электроцеха Ттр.эл. рассчитываем по формуле:

ТТР.эл.= Т ТР * 7 %. (2.8)

Годовой производственный фонд времени рабочего места при 5-ти дневной рабочей неделе рассчитываем по формуле:

Фрм = Тсм * (Дкг - Дв - Дп - Дпп), (2.9)

где Тсм - продолжительность рабочей смены; Тсм =8

Дкг - число календарных дней в году; Дкг =365

Дв - число выходных дней в году; Дв =104

Дп - число праздничных дней в году; Дп =11

Дпп - число предпраздничных дней в году.

Дпп =1Фрм =8*(365-104-11-1)=1992 часа в году.

Рассчитываем количество явочных рабочих по формуле:

Рассчитываем количество списочных рабочих по формуле:

Фпр= (Фрм - t отп) * кув, (2.12)

где t отп = 32 дня * 8 час =256 часов;

кув - коэффициент невыхода на работу по уважительной причине, кув = 0.96.

Принимаем одного человека на замещение двух должностей слесаря-электрика

2.4.2 Расчет производственной площади

Производственную площадь рассчитываем по формуле:

Fу = Кпл * ? Fоб, (2.13)

где Fу - площадь участка;

Кпл - коэффициент плотности расстановки постов;

Fоб - площадь, занимаемая оборудованием.

2.5 Вывод

Для расчета предварительно необходимо для данного автотранспортного предприятия выбрать нормативные значения пробегов подвижного состава периодичности ТО-1 и ТО-2, которые установлены для определенных условий, а именно: категории условий эксплуатации, базовых моделей автомобилей и холодного климатического района.

Для конкретного автотранспортного предприятия эти условия могут отличаться, поэтому в общем случае нормируемые пробег до списания и периодичность ТО-1 и ТО-2 определяются с помощью коэффициентов, учитывающих категорию условий эксплуатации К1, модификацию подвижного состава К2 и климатический район К3.

Раздел 3. Описание программного продукта

3.1 Среда Delphi как средство разработки ПО баз данных

Реализация дипломной работы проводится в системе программирования Delphi 7.0, располагающей широкими возможностями по созданию приложений баз данных [4, 19]. Уже с более ранних версии система Delphi снабжена необходимым набором драйверов для доступа к самым известным форматам баз данных, удобными и развитыми средствами для доступа к информации, расположенной как на локальном диске, так и на удаленном сервере. В поставку продукта входит большое количество коллекций визуальных компонент для построения отображаемых на экране окон, что необходимо для создания удобного интерфейса между пользователем и исполняемым кодом.

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

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

Среда программирования представляет собой несколько отдельных окон: меню и инструментальные панели, Object Inspector (в котором можно видеть свойства объекта и связанные с ним события), окна визуального построителя интерфейсов (Visual User Interface Builder), Object Browser (позволяющее изучать иерархию классов и просматривать списки их полей, методов и свойств), окна управления проектом (Project Manager) и редактора [21].

Projeсt Manager - это отдельное окно, где перечисляются модули и формы, составляющие проект. При каждом модуле указывается маршрут к каталогу, в котором находится исходный текст. Жирным шрифтом выделяются измененные, но еще не сохраненные части проекта. В верхней части окна имеется набор кнопок: добавить, удалить, показать исходный текст, показать форму, задать опции и синхронизировать содержимое окна с текстом файла проекта, т. е. с головной программой на языке Pascal.

Visual Component Library (VCL) Богатство палитры объектов для построения пользовательского интерфейса - один из ключевых факторов при выборе инструмента визуального программирования. При этом для пользователя имеет значение как число элементов, включенных непосредственно в среду, так и доступность элементов соответствующего формата на рынке [4, 22].

Вероятно, то обстоятельство, что Delphi позиционируется как средство создания приложений, взаимодействующих с базами данных, и ориентировано преимущественно на рынок инструментальных средств клиент/сервер, где до настоящего момента доминируют интерпретируемые языки, позволило его авторам не задумываться над созданием оптимизирующего компилятора, способного использовать все достоинства архитектур современных процессоров [22].

Основной упор этой модели в Delphi делается на максимальном повторном использовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды Delphi. Никаких ограничений по типам объектов, которые могут создавать разработчики, не существует. Действительно, все в Delphi написано на нем же, поэтому разработчики имеют доступ к тем же объектам и инструментам, которые использовались для создания среды разработки. В результате нет никакой разницы между объектами, поставляемыми Borland или третьими фирмами, и объектами, которые можно создать самостоятельно.

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. На Delphi можно одинаково хорошо писать как приложения к корпоративным базам данных, так и, к примеру, игровые программы. Во многом это объясняется тем, что традиционно в среде Windows было достаточно сложно реализовывать пользовательский интерфейс. Событийная модель в Windows всегда была сложна для понимания и отладки. Но именно разработка интерфейса в Delphi является самой простой задачей для программиста.

Delphi предлагает разработчикам - как в составе команды, так и индивидуальным - открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе. Разработчики могут добавлять CASE-инструменты, кодовые генераторы, а также авторские help'ы, доступные через меню Delphi [23].

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

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

Формы - это объекты, в которые помещаются другие объекты для создания пользовательского интерфейса любого приложения. Модули состоят из кода, который реализует функционирование приложения, обработчики событий для форм и их компонент.

Информация о формах хранится в двух типах файлов - .dfm и .pas, причем первый тип файла - двоичный - хранит образ формы и ее свойства, второй тип описывает функционирование обработчиков событий и поведение компонент. Оба файла автоматически синхронизируются Delphi, так что если добавить новую форму проект, связанный с ним файл .pas автоматически будет создан, и его имя будет добавлено в проект.

Такая синхронизация и делает Delphi two-way-инструментом, обеспечивая полное соответствие между кодом и визуальным представлением. Как только добавляется новый объект или код, Delphi устанавливает т.н. «кодовую синхронизацию» между визуальными элементами и соответствующими им кодовыми представлениями.

Two-way tools - однозначное соответствие между визуальным проектированием и классическим написанием текста программы. Это означает, что разработчик всегда может видеть код, соответствующий тому, что он построил при помощи визуальных инструментов и наоборот.

Визуальный построитель интерфейсов (Visual User-interface builder) дает возможность быстро создавать клиент-серверные приложения визуально, просто выбирая компоненты из соответствующей палитры. В процессе построения приложения разработчик выбирает из палитры компонент готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы - после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде [4, 23].

Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). В принципе, сейчас не различают эти два названия (BDE и IDAPI) и считают их синонимами. BDE позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный «ODBC socket», который позволяет встраивать их в BDE.

Библиотека объектов содержит набор визуальных компонент, значительно упрощающих разработку приложений для СУБД с архитектурой клиент-сервер. Объекты инкапсулируют в себя нижний уровень - Borland Database Engine.

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

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

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.

Масштабируемость на практике - одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов [19, 21].

3.2 Описание логической структуры системы

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

Далее приведено описание основных модулей.

Модуль «Главная форма» Unit1.pas - главная форма приложения. Содержит элементы выбора действий.

Модуль «Регистрация клиентов» Unit2.pas - форма для просмотра всех клиентов Автосервиса, а также есть возможность регистрации новых.

Модуль «Заказы» Unit3.pas - форма для создания заказа.

Модуль «Просмотр заказов» Unit5.pas - форма для просмотра, редактирования и печати заказов.

Модуль «Услуги автосервиса» Unit4.pas - форма для отображения базы данных по услугам и запчастям, есть возможность редактирования.

Логическая структура автоматизированной системы «Автотехсервис» представлена на рисунку 3.1.

3.3 Руководство пользователя автоматизированной системы «АВТОТЕХСЕРВИС»

Система «Автотехсервис» предназначена для автоматизации работы с клиентами на Станциях Технического Обслуживания.

Программа устанавливается на компьютер. После установки программа запросит путь к базе данных (avtoserves1.dbf), ее необходимо настроить с помощью приложения BDE Administrator. После этого программа готова к использованию. Запуск программы осуществляется путем запуска на выполнение файла «Project.exe» из каталога в который была установлена программа.

После чего загрузится главная форма программы (рис. 3.2). Есть кнопки «Регистрация клиентов», «Заказы», «Просмотр заказов», «Услуги автосервиса» и стандартная кнопка завершения работы приложения.

«Регистрация клиентов», на которой Работник СТО - пользователь системы может просмотреть, а также зарегистрировать клиента СТО. Используя кнопку «Добавить клиента» поля очищаются и пользователь заносит новые данный по клиенту. Есть возможность «Редактировать» существующие записи, а также «Удалить» либо «Сохранить» новые данные (рис. 3.3).

При нажатии кнопки «Добавить автомобиль» предлагается ввести данные автомобиля (рис. 3.4, рис. 3.5). Также имеется возможность «Сохранить» новые данные, «Удалить», «Редактировать», или «Вернуться к просмотру».

При нажатии на кнопку «Закрыть» возвращаемся на главную форму системы (рисунок 3.2). Нажимаем кнопку «Заказы» переходим на форму оформления заказа, где клиенту предоставляется возможность подобрать работы и запасные части к его автомобилю (рис. 3.6).

Для связи заказчика с автомобилем (это сделано для того, что один заказчик может иметь несколько автомобилей), из таблицы «ФИО заказчика, телефон» по фамилии выбираем курсором заказчика, ниже в поле отображается его код. Из таблицы «Данные автомобиля» выбираем нужный автомобиль, вводим в поле код заказа и нажимаем кнопку «Создать заказ» (рис. 3.7).

Из таблицы «Виды работ» пользователь выбирает требуемую работу для клиента и нажимает на кнопку «Выбрать вид работы» и так до тех пор пока не выберет перечень необходимых работ. Если клиент согласен то по аналогичной схеме производиться заказ автозапчастей.

Нажимаем на кнопку «Просмотр» для предварительного заказа на выполнение работ (рис.3.8).

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

Кнопка «Просмотр заказов» на главной форме. Это форма управления заказами, при выборе кнопки «Выполнен», заказ считаеся выполненным и в поле «статус» в таблицу заносится метка (рис. 3.9).

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

Документ «Заказ - наряд на работы», который сформировывает система «Автотехсервис» выглядит следующим образом (рис. 3.10).

Документ «Счет - фактура», который сформировывает система «Автотехсервис» выглядит следующим образом (рис. 3.11).

Рисунок 3.10 - Заказ - наряд на работы



Рисунок 3.11 - Счет - фактура

После печати заданных документов работа с одним клиентом считается окончена. Пользователь должен нажать на кнопку «Close», и система перейдет на главную форму (рис. 3.2). При нажатии кнопки «Услуги автосервиса» открывается окно с перечнем услуг, и запчастей предоставляемых Автотехсервисом (рис.3.12).

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

В данном разделе разработана логическая структура автоматизированной системы «Автотехсервис». Разработано руководство пользователя системы.

Выводы

В выпускной работе бакалавра исследован вопрос разработки автоматизированных рабочих мест. Определены методические основы создания АСУ «Автотехсервис».

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

Разработана автоматизированная система «Автотехсервис», которая включает в себя:

1) регистрацию клиентов;

2) прием заказа на оказание услуг;

3) справочную информацию о доступных услугах;

4) справочную информацию о сделанном заказе;

5) отчет о проделанных работах и расчет стоимости предоставленных услуг.

Данные программы написаны в среде объектного программирования Delphi7.0.

При создании разработаны модели баз данных с использованием СУБД, данные нормализованы в соответствие современными требованиям.

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

При написании программы основное внимание было уделено удобству работы пользователя с программой и построению дружественного интерфейса.

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

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

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

Список использованных источников

1. Абчук В.А., Лифшиц А.Л., Федулов А.А., Куштина Э.И., Автоматизация управления, Москва «Радио и связь», 1984г.

2. Аппак М.А., Автоматизированные рабочие места на основе персональных ЭВМ, М.: Радио и связь, 1989 г.

3. Ахаян Р., Горев А., Макашарипов С. "Эффективная работа с СУБД", Санкт-Петербург, 1997г.

4. Баас Р., Фервай М., Гюнтер Х., Delphi 5: для пользователей: пер с нем.- К.: Издетельская группа BHV, 2000. -496 c.:ил.

5. Бадд Т. Обьектно-ориентированное программирование в действии: Пер. с англ. - Спб: Питер паблишинг, 1997.

6. Береза А. М. Основы создания информационных систем: Навч. пособие. -К.: КНЕУ, 1998.

7. Бєгун А.В. Технология программирования: объектно-ориентированный подход: Навч.-метод. пособие для самост. вивч. дисц. - К.: КНЕУ, 2000.

8. Вендров А.М. CASE - технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998.

9. Гэри Хансен, Джэймс Хансен. Базы данных: разработка и управление : Пер. с англ. - М.: ЗАО «Издательство БИНОМ», 2000. - 704 с.

10. Дж.Ульман, "Основы систем баз данных", М.:Финансы и статистика,1983 г.

11. Дейт К., Введение в системы баз данных, М.: Hаука, 1980 г.

12. Кириллов В.В. Структуризованный язык запросов (SQL). - СПб.: ИТМО, 1994. - 80 с.

13. Клейнер Б.С., «Техосмотр и ремонт автомобилей, организация, управление».

14. Крамаренко Г.В., Барашков И.В., Техническое обслуживание автомобилей: Учебник для автотранспортных техникумов. - М.: Транспорт, 1982.-368с.,ил.

15. Ландсберг И.Д., Соколин Л.З., Каманин В.Н., Ремонт электрооборудования автомобилей / И.Д. Ландсберг Л.З. Соколин В.Н. Каманин В.Н.-М.:Транспорт. 1981.-317 с., ил.

16. Мамиконов А. Г. "Проектирование АСУ" (учебник для вузов), Москва "Высшая школа".

17. Hаумов А.H., Вендров А.М.и др., Системы управления базами данных и знаний, М.:Финансы и статистика, 1991г.

18. Понимание SQL (Understanding SQL). [SQL.RU] http://www.sql.ni/docs/sql/u sqI/index.shtml.

19. Сван Том. Секреты 32-разрядного программирования в Delphi. - К.: Диалектика, 1997. - 480 с., ил.

20. Ситнік В.Ф., Писаревська Т.А., Єрьоміна Н.В. та ін. Основи інформаційних систем. Навчальний посібник. - К.: КНЕУ, 2001.

21. Тайксера, Стив, Пачеко, Ксавье. Delphi 5. Руководство разработчика, том 1. Основные методы и технология программирования: Пер. с англ._ М.: Издательство дом «Вильямс», 2001. - 832 с.: ил. - Парал. тит. англ.

22. Фленов М.Е. Библия Delphi. -2-e изд., БВХ-Петербург, 2008 г.

23. Хомоненко А., Delphi 7 в подлиннике.. СПб: BHV, 2003 - 1216 стр.

24. Хохлачев Е.Н. "Теоретические основы создания и применения АСУ", Москва, Министерство обороны, 1987г.

Размещено на Allbest.ru