База данных Access Автосервис предназначена для автоматизации работы компании, занимающейся ремонтом автомобилей. В базе таблицы заполнены данными, выполнены простые и перекрестные запросы, а также на добавление, обновление и удаление. Также сделаны формы для работы с данными и отчеты, которые можно выводить на печать.
База данных Access Автосалон содержит 6 таблиц , 9 запросов, 7 форм + главная кнопочная форма, 5 отчетов. Данная база данных Access оптимально подходит для дальнейшей оптимизации и доработки под собственные нужды.

ВНИМАНИЕ! Есть пояснительная записка (21 стр)

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

Цель практических заданий – приобретение навыков анализа предметной области, проектирования базы данных, ее физической реализации в СУБД Access.
Результат выполнения работы представляется в виде базы Access, который должен содержать:
структуру спроектированных таблиц,
схему данных со связями между таблицами,
примеры форм, обеспечивающих интерфейс пользователя,
запросы (в режиме Конструктора и на языке SQL),
отчеты (в режиме отчета и в режиме Конструктора),
главную кнопочную форму.

Таблица «Автомобили» — База данных Access Автосервис

Таблица «Мастера» — База данных Access Автосервис

Запрос «Стоимость работ» — База данных Access Автосервис

Перекрестный запрос — База данных Access Автосервис

Форма «Клиенты» — База данных Access Автосервис

Форма «Склады» — База данных Access Автосервис

Отчет «Сумма с запчастью и работой» — База данных Access Автосервис

Главная кнопочная форма — База данных Access Автосервис

Готовая база данных База данных Access Автосервис доступна для скачивания по ссылке ниже.

. Готовая база данных Access «Автосервис»

Скачать базу данных (БД) MS Access; БД Access Автосервис; продажа автомобилей access; база данных access; бд access; субд access; базы данных access; access пример; программирование access; готовая база данных; создание база данных; база данных СУБД; access курсовая; база данных пример; программа access; access описание; access реферат; access запросы; access примеры; скачать бд access; объекты access; бд в access; скачать субд access; база данных ms access; субд access реферат; субд ms access; преимущества access; базу данных; скачать базу данных на access; базы данных; реляционная база данных; системы управления базами данных; курсовая база данных; скачать базу данных; база данных access скачать; базы данных access скачать; ремонт автомобилей; ремонт авто; автомобильный салон; сервис по ремонту автомобилей

Автоматизация технологии формирования документов об окончании университета в рамках АСУ МИИТа

База данных "Автосервис"

Связи таблиц: Таблица custumers связана с таблицей masters с помощью связи 1:N по полю vin_number Таблица custumers связана с таблицей calculation с помощью связи 1:1 по полю...

База данных "Студенты"

Программа начинается с подключения библиотек необходимых для работы определенных функций. #include - для работы с файлами, структурами и функциями. #include - для функции strcmp(). #include - для функции очистки экрана. ...

База данных ГИБДД

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

База данных по учету металлопродукции на платформе SQL Server

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

Организация внедрения информационной системы ООО "MensFormat"

Проектирование блока обработки данных в структурном базисе серии К1804ВС2

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

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

Для создания базы данных используется СУБД MySQL менеджер. Так как мы проживаем в России было решено выбрать кодировку cp_1251. Что бы была возможность использовать внешние ключи будет использован движок InnoDB...

Разработка информационно-справочной системы "Отдел кадров Шарковщинского РОО"

Отдел образования, спорта и туризма Шарковщинского райисполкома находится в городском поселке Шарковщина, ул. Комсомольская, 15. Отдел образования...

Разработка программного продукта "Отдел кадров завода"

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

Разработка системы учета и движения кадров на предприятии

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

Разработка системы учета оплаты обучения студентами

Для создания БД будет использоваться СУБД Microsoft SQL Server 2005 Express Edition. Выполняем следующие действия: Осуществление этого этапа будет производить при помощи Microsoft Visual Studio 2005. При нажатии на кнопку Tools в панели меню, выпадет список команд...

Создания сайта на примере ЗАГСа Еловского района

Существует несколько основных структур сайта: - линейная - web-страницы располагаются в определенном порядке. Переход с одной web-страницы на другую строго определен. Такая структура обоснована, например, при обучении...

Электронный классный журнал

В спроектированной согласно заданию техническому заданию базе данных получилось 3 таблицы: Анкета, Успеваемость, Предмет...

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

 Разработать информационно – логическую модель БД «Автосервис»

 Реализовать ее в СУБД MS Access.

 Составить «Пояснительную записку» к курсовому проекту в соответствии со следующим планом:

Назначение базы данных

База данных « «Автосервис» предназначена для реализации приема и оформления заказов на работы предприятием автосервиса.

На высокое звание АСУ – конечно не претендует. В силу отсутствия в ней целых блоков, необходимых для комплексной автоматизированной системы управления:

 Бухгалтерии,

 Экономического блока

 Планового

 Снабжения

 И целого ряда других блоков.

Реализуется только один из блоков АСУ – рабочее место «Прием заказов»: работа с заказчиками: прием и фиксирование заказов, организация их выполнения, отчетность о результатах работы.

Выполняемые базой данных функции

База данных выполняет следующие функции

1. Учет и хранение сведений о сотрудниках автосервиса. «Mechanic s »

2. Ввод и хранение сведений о видах выполняемых работ. «Order s »

3. Ввод сведений о заказчиках, о автомобилях заказчиков и данных о них. «Request s »

4. Форма «Ввод сведений о заказах» обеспечивает ввод собственно заказа, выбор ФИО заказчика (из списка), выбор типа автомобиля заказчика и ввод сведений о нем.

Там же – вводится состав выполняемых работ и ФИО сотрудников автосервиса, их выполняющих. А также – сведения о составе и количестве использованных запчастей.

5. В базе данных предусмотрены и различные отчеты, позволяющие анализировать состояние дел на предприятии автосервиса.

Категории пользователей

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

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

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

Введем следующие понятия и условные обозначения :

Сущности

СУЩНОСТЬ

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

Сущности будем обозначать прямоугольниками,

Атрибуты сущности

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

СУЩНОСТЬ

Атрибуты

Имена атрибутов будем заносить в прямоугольник,

обозначающий сущность , под именем сущности, и писать

малыми буквами.

Взаимосвязи

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

Связи – обозначим линиями, над которыми будем проставлять степень связи (« 1 » или « ∞ » , обозначающую "много") и ее характеристики.

Ключевые поля

Определим понятие первичных и внешних ключей

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

Один из них принимается за первичный ключ .

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

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

Внешние ключи

Если сущность С связывает сущности А и В , то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

Если сущность В обозначает сущность А , то она должна включать внешний ключ, соответствующий первичному ключу сущности А .

Примечание:

1. Поскольку разработчики СУБД MS Access изначально учли проблемы, возникающие с первичными и внешними ключами , в Access был введен специальный тип поля – КЛЮЧЕВОЕ ПОЛЕ. Его тип – СЧЕТЧИК.

Access не требует его обязательного включения в таблицу. Но настоятельно предлагает .

Особенности этого типа поля таковы:

При вводе новой записи – в этом поле АВТОМАТИЧЕСКИ формируется новое, уникальное, неповторяющееся числовое значение.

Поле не может принимать неопределенное значение.

Поле – автоматически индексируется.

Ручное изменение значения этого поля невозможно .

Поэтому проблема ключевых полей и внешних ключей в Access решается просто:

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

В подчиненные таблицы вводим его копию (с тем же названием). Это будет их внешний ключ .

Связываем по этим полям главную и подчиненную таблицы. Вот и все. Связь реализована!

2. Ввели в Access разработчики и инструмент, который называется « Схема данных »

Которая позволяет не только связать таблицы, но и указать для каждой связи:

ее тип («один – к – одному», «один – ко – многим» и т.д.)

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

Что необходимо указывать и при построении ER – модели базы данных.

В частности, именно поэтому Access идеально подходит в качестве системы программирования для реализации ER – моделей.

При реализации нашей ER – модели в Access мы всеми этими возможностями и воспользуемся.

Введение 3
РАЗДЕЛ 1. Разработка базы данных 4

РАЗДЕЛ 2. Моделирование структур данных 7
2.1. Разработка концептуальной модели базы данных 7
2.2. Разработка логической модели данных 9
2.3. Преобразование модели «сущность-связь» в реляционную
модель данных 10
РАЗДЕЛ 3. Проектирование базы данных 12
3.1. Разработка таблиц 12
3.2. Разработка форм для ввода данных 17
3.3. Разработка запросов к базе данных 21
3.4. Разработка отчетов 27
ЗАКЛЮЧЕНИЕ 30
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 31
ПРИЛОЖЕНИЯ 32

ВВЕДЕНИЕ

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

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

РАЗДЕЛ 1. Разработка базы данных

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

Оператор СУБД может вносить следующие изменения:

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

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

Вывод информации в виде отчетов:

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

РАЗДЕЛ 2. Моделирование структур данных

2.1. Разработка концептуальной модели базы данных

При построении концептуальной модели БД воспользуемся рекомендациями Карповой И.П. . Как отмечает автор концептуальная модель базы данных - это высокоуровневая объектно-ориентированная модель предметной области, представляющая объектную область в виде набора объектов, обладающих определенными свойствами и находящимися в некоторых отношениях. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Концептуальная модель данных не привязана к конкретной физической реализации баз данных и не зависит от конкретной СУБД. Концептуальная модель создается на основе представлений о предметной области каждого типа пользователей, представляющих собой набор данных, необходимых пользователю для решения своих задач .
Концептуальная модель для базы «Автосервис» проектировалась, как модель «сущность-связь».
Основные концепции модели включают такие понятия: как сущность (объект), отношение (связь), типы сущностей, типы связей и атрибуты .
Сущность - реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. Каждая сущность определяется набором атрибутов.
Атрибут - поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Имена атрибутов будем заносить в прямоугольник, обозначающий сущность, и записывать под именем сущности.
Между сущностями устанавливаются связи.
Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Связи - обозначим линиями.
Таким образом, из описания предметной области извлечем все типы
сущностей:
– Заказчики;
– Заказы;
– Мастера;
– Перечень работ.
Каждой из сущностей определим свой набор атрибутов.
Сущность Заказчик определяется следующим набором атрибутов:

Атрибуты сущности Заказы определяются следующим образом:

Сущность Мастера документируется на основании следующих атрибутов:

Сущность Перечень работ определяется следующим набором атрибутов:

В соответствии с моделью предметной области, представляется следующая концептуальная модель базы данных «Автосервис» (рис. 1).
Рис.1 Концептуальная модель базы данных «Автосервис».

2.2. Разработка логической модели данных

Преобразование локальной концептуальной модели данных в локальную логическую модель заключается в удалении из концептуальных моделей нежелательных элементов и преобразование полученных моделей в локальные логические модели . К нежелательным элементам относятся :
– связи типа «многие-ко-многим»;
– рекурсивные связи;
– связи с атрибутами.
В созданной концептуальной модели вышеперечисленных нежелательных элементов не обнаружено.
Логическая схема данных приведена на рис.2.

Рис. 2. Логическая схема данных.

Преобразование модели «сущность-связь» в реляционную модель данных
осуществляется путем последовательного выполнения ряда шагов :
– каждой сущности ставится в соответствие отношение реляционной модели данных;
– каждый атрибут сущности становится атрибутом соответствующего отношения;
– первичный ключ сущности становится первичным ключом соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом.
Этот процесс рассмотрен ниже.

РАЗДЕЛ 3. Проектирование базы данных

Таблица - это объект, предназначенный для хранения данных в виде записей (строк) и полей (столбцов) .
В программе OpenOffice.org Base предусмотрено три различных способа создания таблицы базы данных:

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

Таблица является основой базы данных, поэтому при разработке таблиц рекомендуется руководствоваться следующими основними принципами :

Каждая таблица содержит сведения по конкретной теме, а каждое поле в таблице содержит конкретный факт по теме таблицы. Для каждой таблицы в базе данных необходимо определить свойства содержащихся в них.
База данных «Автосервис» содержит четыре таблицы:

Рис. 3. Таблица Заказчики.

Рис. 4. Таблица Заказы.

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

Рис. 5. Перечень работ.

Рис. 6. Мастера.

Определим, для каждой сущности первичный ключ, при этом надо учитывать, что сильные сущности имеют только одно ключевое поле, а слабые - столько же, сколько и связей. При выборе первичного ключа будем руководствоваться правилами :
– ключ должен содержать минимальный набором атрибутов;
– использовать следует тот ключ, вероятность изменения значений которого минимальна;
– значение ключа должно иметь минимальную длину.
Исходя из вышесказанного, у имеющихся сущностей определим такие ключевые поля:

После разбиения сведений на таблицы и определения ключевых полей необходимо выбрать способ, которым СУБД будет объединять связанные сведения. Для этого не обходимо определить связи между таблицами базы данных.
OpenOffice.org BASE поддерживает четыре типа отношений между таблицами :
– один-к-одному (каждая запись в одной таблице соответствует только одной записи в другой таблице);
– один-ко-многим (каждая запись в одной таблице соответствует многим записям в другой таблице);
– много-к-одному (аналогична записи «один-ко-многим);
– много-ко-многим (одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы либо одна запись из второй таблицы может быть связана болеечем с одной записью из первой таблицы).
Связи, установленные в БД «Автосервис» уже были представленны в предыдущем разделе на рис. 2.

Форма - объект, предназначенный для ввода, редактирования и просмотра табличных данных в удобном виде.
Формы содержат так называемые элементы управления, с помощью которых осуществляется доступ к данным в таблицах. Элементами управления являются текстовые поля для ввода и правки данных, кнопки, флажки, переключатели, списки, надписи. Создание форм, содержащих необходимые элементы управления, существенно упрощает процесс ввода данных и позволяет предотвратить ошибки.
Формы OpenOffice.org Base предоставляют функциональные возможности для выполнения многих задач, которые нельзя выполнить другими средствами, они позволяют выполнять проверку корректности данных при вводе, проводить вычисления, и обеспечивают доступ к данным в связанных таблицах с помощью подчиненных форм.
OpenOffice.org Base предлагает несколько способов создания форм. Самым простым из них является использование средств автоматического создания форм на основе таблицы или запроса .
Для базы данных «Автосервис» предусмотрены четыре простые формы и три субформы.
Примеры простых форм приведены на рис.7-10.

Рис.7. Форма Заказчик.

Рис.8. Форма Заказы.

Рис.9. Перечень работ.

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

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

Рис. 12. Форма Заказы с субформой Ремонтные работы.
Эта форма позволяет вносить информацию в таблицы Заказы и Ремонтные работы.

Рис. 13. Форма Мастера с субформой Заказы.
Форма Мастера с субформой Заказы позволяет контролировать выполнения работ конкретным мастером.

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

Технология создания База данных «Автосервис»

Для создания базы данных были поставлены цели и задачи базы данных «Автосервис»:

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

? люди,
? материалы,
? компьютеры,
? станки,
? здания.

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

Рисунок 14. База данных «Автосервис»

Система делится на две подсистемы и одно расширение:

? Ремонт технической части автомобиля.
? Расширение - ремонт салона автомобиля.

Основная система «Ремонт технической части автомобиля» состоит из четырех таблиц (см. рис. 15):

«Заказ » - включающая в себя необходимую информацию о заказе на ремонт и диагностику автомобиля, то есть:

? Автомобиль.
? Владелец.
? Причина обращения на СТО.

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

? Ремонт двигателя.
? Ремонт КПП.
? Ремонт ходовой части.
? Ремонт топливной системы.

Рисунок 15. Заказ на ремонт технических частей

Таблица «Диагностика », связанна с «Заказом » и распределяет автомобили на диагностику определенных частей автомобиля, т.е. двигатель, КПП, ходовая часть и топливная система.

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

? Диагностика двигателя.
? Диагностика КПП.
? Диагностика ходовой части.
? Диагностика топливной системы.

Основная система работает на основе “Каскадной модели” и ссылается на стандарт ГОСТ 21624 -76

ГОСТ 18507 -73

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

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

1) обращение с претензией,
2) оформление гарантии,
3) заказ запчастей, и включает 11 таблиц, одна из которых общая для IT-сервиса. (см рис. 16).

Рисунок 16. IT-сервис

IT-сервис - делит весь сервис на 3 части:

? обращение по гарантии,
? оформление гарантии,
? заказ запчастей.

Данные 1 и 2 - содержат информацию о заказчиках.

Получение 1 - таблица содержит данные о времени обращения и цене оказанных услуг.

Причина обращения - таблица, в которой содержится информация о причине обращения в СТО по гарантии. Имеет связь, с таблицами: согласие СТО 1 и Итог 1, где отмечены данные о согласии СТО с претензией и возможности решения проблемы, соответственно.

Расширение представляет собой некое увеличение услуг ремонта автомобиля. Теперь система имеет ремонт кузова и ремонт салона, которыми также занимается СТО.

Подсистема-расширения состоит из двух таблиц и оказывает влияние на 2-ю таблицы из основной системы. (см. рис. 17)

Рисунок 17. Расширение

Таблицы «ремонт кузова и ремонт салона» включают в себя информацию о видах услуг.

Ремонт кузова:

? Замена деталей.
? Шпатлевка.
? Покраска.
? Лакировка.
? Полировка.

Ремонт салона:

? Замена составляющих.
? Ремонт составляющих.

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

Функционал:

? наряд заказы,
? работы,
? услуги,
? бригады,
? норма-часы.

Ресурсы базы данных:

? люди,
? оборудование,
? материалы,
? компьютеры,
? станки,
? здания.

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

В базе данных это представлено таким образом:

? прием заказа на ремонт,
? диагностика автомобиля,
? ремонт автомобиля,
? выпуск автомобиля с СТО.

Рисунок 18. Модель базы данных

Фаза анализа

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

Фаза проектирования

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

Фаза реализации и внедрения

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

Фаза сопровождения

На данном этапе производится выписывание гарантии на ремонт и подсчет средств, которые были затрачены на диагностику и ремонт автомобиля, после выплат которых машину отдают хозяину.

Свойства системы

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

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

Целостность - несмотря на то, что система делима, при полной работоспособности, она не будет работать, если нарушить функциональность одной из ее подсистем.

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

Стандарты

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

ГОСТ 18507 -73 - настоящий стандарт распространяется на автобусы и легковые автомобили (далее - автомобили) и устанавливает методы их контрольных испытаний после капитального ремонта, произведенного авторемонтными предприятиями.

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

Технические задания

1. Сделать общую базу всех услуг на СТО для конкретного автомобиля.

Рисунок 19. Общая база всех услуг на СТО

2. Данные по необходимым инструментам и материалам.

Рисунок 20. Данные по инструментам и материалам

3. Связи со сторонними системами.

Рисунок 21. Сторонние системы

Рисунок 22. Автоцентры

Рисунок 23. Страховщики

Рисунок 24. Поле Страховщики

4. Комментарии по качеству обслуживания.

Рисунок 25. Комментарии

Рисунок 26. Отзывы посетителей

Рисунок 27. Отзывы

В ходе работы была создана база данных в системе управления базами данных MS Access. В работе отображена пошаговая технология создания Базы данных. Приведен пример базы данных «Автосервис». Данная база была апробирована на СТО. Система была протестирована. В ходе работы внесены коррективы и приведен в работе окончательный вариант базы данных «Автосервис».