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

содержание

Введение 3

1 Исследование и анализ предметной области 4

1.1 Обзор предметной области 4

1.2 Обзор существующих аналогичных информационных систем 5

1.3 Актуальность разрабатываемой информационной системы 7

1.4 Требования к информационной системе 8

2 проектирование модели базы данных 10

2.1 Инфологическое проектирование модели базы данных 10

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

2.3 Физическое проектирование модели базы данных 19

3 РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ 24

3.1 Реализация функций информационной системы 24

3.2 Формирование и реализация выходной информации 29

заключение 33

Список использованной литературы 34

приложение а 35

Введение

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

1.1 Обзор предметной области 

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

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

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

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

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

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

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

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

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

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

1.2 Обзор существующих аналогичных информационных систем

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

1. «Учёт в ремонтной мастерской» –программа, предназначенная для автоматизации работы Сервисных Центров и других компаний, занимающихся ремонтом аппаратуры. Основные функции:

• учёт принятых заказов (изделий в ремонте);

• печать акта о приёмке (приёмной квитанции);
• автоматическое и ручное ведение склада деталей;
• печать акта выполненных работ;
• обслуживание, как разовых клиентов, так и фирм-заказчиков;
• формирование всевозможных отчётов;
• ведение архива;
• печать бухгалтерских документов.

Рисунок 1.1 – Окно учета заданий программы  «Учет в ремонтной мастерской»

2. «WinServicePro»–программа для учета заказов в сервисном центре (ремонтной мастерской). Она позволяет вести журнал заказов по приему техники в ремонт, выписывать квитанцию и акт выполненных работ. Имеет возможность настройки печатных форм. Показывает отчет по ремонту за период по клиентам и мастерам, расчету прибыли при учете стоимости затрат на ремонт. В программе предусмотрена возможность заведения справочников: клиенты, фирмы производители, модели, детали, неисправности, комплектации.

Рисунок 1.2 – Окно учета заданий программы  «WinServicePro»

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

Рисунок 1.3 – Окно добавления задания программы  «Корс Сервис-Центр»

1.3 Актуальность разрабатываемой информационной системы

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

1.4 Требования к информационной системе

Требуется разработать  информационную систему в виде клиент-серверного приложения. Клиентская часть – Windows-приложение, реализованное средствами Visual Studio 2005. Серверная часть – база данных, реализованная средствами Microsoft Access.

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

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

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

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

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

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

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

Требуется выводить информацию в виде отчетов «Справка о приеме», «Квитанция», «Отчет о доходах», «Зарплатная ведомость».

Отчет «Справка о приеме» должен содержать следующую информацию: ФИО клиента, ФИО мастера, № квитанции, наименование объекта, тип ремонта, дату приема.

Отчет «Квитанция»  должен содержать следующие поля: № квитанции, ФИО клиента, дата приема, дата сдачи, стоимость ремонта, перечисление использованных деталей, стоимость деталей, итоговую оплату.

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

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

Просматривать разрешено будет список мастеров, список заданий (за период времени).

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

Должна будет  обеспечиваться целостность данных.

2 проектирование  модели базы данных

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

В предметной области «Ремонтная мастерская»  можно выделить:

• объекты: сотрудники, типы ремонтов, модели техники, детали, магазины;
• процессы: ремонты, заказы деталей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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