Використання баз даних у роботі автосервісу. Проектування баз даних станція технічного обслуговування автомобілів. Технологія створення База даних «Автосервіс»

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

Якщо ця робота Вам не підійшла внизу сторінки, є список схожих робіт. Також Ви можете скористатися кнопкою пошук

Міністерство освіти та науки Російської Федерації

Федеральна державна бюджетна освітня установа

вищої професійної освіти

Рязанський державний університетімені С.А. Єсеніна

Факультет Фізико-математичний

Спеціальність Математичне забезпечення та адміністрування
інформаційних систем

Кафедра Інформатики та ВТ

Курсова робота з дисципліни

«Бази даних та СУБД»
на тему:

«Проектування бази даних

"Станція технічного обслуговування автомобілів"»

Виконав студент 3 курсу ФМФ

Макаров Дмитро

Науковий керівник:

Богданова Н аталья Володимирівна

Рязань 2015 р.

Вступ

У зв'язку із збільшенням обсягу інформації та необхідністю її перетворення, зростає потреба в автоматизації існуючих процесів обробки даних. До таких процесів можна віднести аналіз, систематизацію, відображення та редагування інформації.

Сучасні технології розробки прикладних програмроблять побудову баз даних швидким та якісним. Кваліфікований користувач за допомогою Microsoft Accessсьогодні може за один вечір створити на персональному комп'ютеріте, що у ранніх ЕОМ вимагало місяців роботи. Крім того, тепер значно легше знаходити помилки, усувати їх і змінювати проект безпосередньо в процесі створення бази даних.

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

Проектована база даних "Станція технічного обслуговування автомобілів" дозволяє систематизувати швидкий пошукнеобхідної інформації у цій предметної області.

У БД повинні зберігатися відомості про автомобілі: виробник, модель, держ. номер, рік випуску, країна-виробник, номер паспорта власника, газове обладнання; відомості про власників: ПІБ, адреса, телефон, а також номер паспорта; відомості про працівників: ПІБ Працівника, ідентифікаційний номер працівника; інформацію про роботах: код роботи, опис, дата виконання, тривалість, держ. номер.

Метою даної курсової роботи є проектування бази даних "Станція технічного обслуговування автомобілів".

Найважливіші завдання , що стоять перед нами у процесі виконання роботи, наступні:

В· Вивчення особливостей предметної області «Станція технічного обслуговування автомобілів»;

· Розробка схеми БД;

· Реалізація розробленої схеми у конкретній СУБД (MS Access);

· Створення форм для введення даних, звітів, запитів.

Створення будь-якої бази даних починається з вибору структури бази даних. У нашому випадку зручніше використовувати п'ять таблиць із даними. Далі зробимо кілька запитів на вибірку за різними параметрами та звіти до них. Для зручності роботи з даними створимо кілька форм та кнопки переходів між ними.

Курсова робота складається з вступу, двох розділів, висновків, списку використаної літератури.

РОЗДІЛ 1. Проектування бази даних

У базі даних « Станція технічного обслуговування автомобілів» мають бути такі атрибути:

• Виробник
• Модель
• Рік випуску
• Газове обладнання
• Країна виробник
• Держ. номер авто
• ПІБ власника
• Номер паспорта власника
• Адреса власника
• Телефон власника
• ПІБ Працівника
• Код роботи
• Опис роботи
• Дата виконання роботи
• Тривалість роботи

Виділимо 4 сутності: "Авто", "Власники", "Працівники", "Роботи".

Сутність «Авто» має такі атрибути:

Виробник

Модель

Держ. номер

Країна виробник

Газове обладнання

Рік випуску

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

Сутність «Власники» має такі атрибути:

ПІБ власника

Адреса власника

Телефон власника

Номер паспорта власника

Оскільки всі вихідні атрибути сутності «Режисери» можуть мати значення, що повторюються, то додамо атрибут індивідуальний номер режисера, який не повинен мати повторюваних значень.

Сутність «Працівники» має такі атрибути:

ПІБ працівника

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

Сутність «Роботи» має такі атрибути:

Опис роботи

Дата виконання роботи

Тривалість роботи

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

Приймемо угоди.

Угода 1:

Кожен власник може мати декілька автомобілів, отже ступінь зв'язку для сутності «Авто» дорівнює N . У свою чергу, будь-яке авто належить одному власнику, отже рівень зв'язку для сутності «Власники» дорівнює 1.

Угода 2:

Кожен автомобіль обов'язково належить власнику, отже, клас власності для сутності «Авто» є обов'язковим. Кожен власник обов'язково володіє хоча б одним автомобілем, отже клас приналежності для сутності «Власники» обов'язковий.

Рис.1.1 ER -діаграма зв'язку сутностей Авто та Власники

Таким чином, у нас є бінарний зв'язок один до багатьох з обов'язковим класом приналежності для обох сутностей, для його реалізації необхідно створити два відносини (по одному для кожної сутності), причому щодо багатозв'язної сутності «Авто» необхідно додати для встановлення зв'язку первинний ключоднозв'язної сутності "Власники" номер паспорта.

Угода 3:

Над одним авто може бути виконана тільки одна робота, отже, ступінь зв'язку для сутності «Авто» дорівнює 1. У свою чергу кожна робота може виконуватися над кількома авто, отже, ступінь зв'язку для сутності «Роботи» дорівнює N.

Угода 4:

Над автомобілем виконується робота. Роботи виконуються над автомобілями.

Рис.1.2 ER -діаграма зв'язку сутностей Авто та Роботи

Таким чином, у нас є бінарний зв'язок один до багатьох з обов'язковим класом приналежності для обох сутностей, для його реалізації необхідно створити два відносини (по одному для кожної сутності), причому щодо багатозв'язної сутності «Роботи» необхідно додати для встановлення зв'язку первинний ключ однозв'язної сутності «Авто» держ. номер.

Угода 5:

Будь-який працівник може виконувати будь-яку роботу, отже, ступінь зв'язку для сутності «Роботи» дорівнює N . У свою чергу будь-яка робота може бути виконана будь-яким працівником, отже, ступінь зв'язку для сутності «Працівники» N.

Угода 6:

Працівники виконують роботи. Роботи виконуються працівниками.

Рис.1.3 ER -діаграма зв'язку сутностей Працівники та Роботи

Таким чином, є бінарний зв'язок «багато хто до багатьох», для його реалізації необхідно створити три відносини: по одному для кожної сутності з відповідними атрибутами та первинними ключами і 3е для зв'язку; як атрибути - первинні ключі обох сутностей; первинний ключ складової.

Таблиця зв'язку (код роботи, індивідуальний номер працівника)

Функціональна залежність сутності «Авто»

Рис.1.4 Функціональна залежність сутності «Авто»

Держ. номер  Виробник

Держ. номер  Модель

Держ. номер  Рік випуску

Держ. номер  Країна виробник

Держ. номер  Газ

Держ. номер  Номер паспорта

Держ. номер | детермінант, держ. номер можливий ключ, значить відношення «Авто» знаходиться в БКНФ.

Функціональна залежність сутності «Власники»

Рис.1.5 Функціональна залежність сутності «Власники»

Номер паспорта  ПІБ

Номер паспорта  Адреса

Номер паспорта  Телефон

Номер паспорта детермінант, номер паспорта можливий ключ, значить ставлення «Власники» знаходиться в БКНФ.

Функціональна залежність сутності «Роботи»

Рис.1.6 Функціональна залежність сутності «Роботи»

Код роботи  Опис

Код роботи  Дата виконання

Код роботи  Тривалість

Код роботи  Держ. номер

Код роботи - детермінант; Код роботи - можливий ключ, отже відношення «Роботи» знаходиться в БКНФ.

Функціональна залежність сутності «Працівники»

Рис.1.7 Функціональна залежність сутності «Власники»

Ідентифікаційний номер ПІБ

Ідентифікаційний номер - детермінант, Ідентифікаційний номер - можливий ключ, означає відношення «Працівники» знаходиться в БКНФ.

Розглянемо реалізацію БД засобами MS ACCESS.

«Авто» (виробник, модель, держ. номер, рік випуску, газове обладнання, країна-виробник, номер паспорта власника)

AVTO ”

Рис.1.8 Конструктор таблиці “ AVTO”.

Рис.1.9 Таблиця сутності «Авто»

«Власники» (ПІБ, адреса, телефон, номер паспорта).

Відношенню у реляційній базі відповідає таблиця “ VLADELCY ”

Рис.1.10 Конструктор таблиці “ VLADELCY”.

Рис.1.11 Таблиця сутності «Власники»

«Роботи» (Код роботи, опис роботи, дата виконання, держ. номер).

Відношенню у реляційній базі відповідає таблиця “ RABOTU”.

Рис.1.12 Конструктор таблиці"RABOTU" .

Рис.1.13 Таблиця сутності «Роботи»

Таблиця зв'язку (Код роботи, ідентифікаційний номер працівника).

Відносно у реляційній базі відповідає таблиця" DLYSVYZI "

Рис.1.14 Конструктор таблиці “ DLYSVYZI”.

Рис.1.15 Таблиця з вязі

«Працівники» (ПІБ, ідентифікаційний номер працівника).

Відношенню у реляційній базі відповідає таблиця “ RABOTNIKI”.

Рис.1.16 Конструктор таблиці"RABOTNIKI" .

Рис.1.17 Таблиця сутності «Працівники»

Схема даних

Рис.1.18 Схема даних

ГЛАВА 2. Опис БД та системи управління

2.1 Запити

1. Моделі автомобілів виробника Lexus

SELECT MODEL FROM AVTO

WHERE PROIZV = "Lexus";

1. Виробники авто та всі моделі

SELECT PROIZV, MODEL

FROM AVTO;

1. Виробник, модель та держ. номер авто, що належать Кузину Валерію Валентиновичу

SELECT AVTO.PROIZV, AVTO.MODEL, AVTO.GOSNOMER

FROM VLADELCY INNER JOIN AVTO ON VLADELCY.PASPORTNOMER = AVTO.PASPORTNOMER

WHERE VLADELCY. FIO = "Кузін Валерій Валентинович";

1. Виробник, модель, рік випуску та держ.номер авто, випущеного раніше 2005 року з сортуванням за датою випуску

SELECT PROIZV, MODEL, GOSNOMER, GODVIPUSKA

FROM AVTO

WHERE GODVIPUSKA< 2005 order by GODVIPUSKA;

1. Дата виконання та опис робіт, виконаних Зміновим Едуардом Вікторовичем.

SELECT RABOTU.DATAV, RABOTU.OPISANIE

FROM RABOTU INNER JOIN (RABOTNIKI INNER JOIN DLYSVYZI ON RABOTNIKI.IDR = DLYSVYZI.IDR) ON RABOTU.KODRABOTU = DLYSVYZI.KODRABOTU

WHERE RABOTNIKI . FIO = "Змін Едуард Вікторович";

1. Список марок авто, держ. номерів та робіт, які над ними проводились

SELECT AVTO.PROIZV, AVTO.GOSNOMER, RABOTU.OPISANIE

FROM AVTO INNER JOIN RABOTU ON AVTO.GOSNOMER = RABOTU. GOSNOMERAVTO;

1. Виробники, рік випуску та моделі найновіших авто (за роком випуску)

SELECT PROIZV, MODEL

FROM AVTO

WHERE GODVIPUSKA = (SELECT MAX (GODVIPUSKA) AS MAXGV FROM AVTO);

1. Вивести всю інформацію про 3 найтриваліші роботи

SELECT TOP 3*

FROM RABOTU

ORDER BY PRODOLG DESC;

1. Імена власників, виробники та держ. номери авто, що належать їм

SELECT VLADELCY.FIO, AVTO.PROIZV, AVTO.GOSNOMER

FROM VLADELCY INNER JOIN AVTO ON VLADELCY.PASPORTNOMER = AVTO.PASPORTNOMER;

1. Вся інформація про всіх працівників

SELECT *

FROM RABOTNIKI;

1. ПІБ, телефон та адреса власників авто з Рязані

SELECT FIO, TELEFON, ADRES

FROM VLADELCY

WHERE ADRES LIKE "Рязань";

1. Список країн-виробників авто

SELECT DISTINCT STRANA

FROM AVTO;

1. ПІБ власника, який має найбільша кількістьавто, і ця кількість

SELECT Temp.FIO, Temp.MaxAVTO

FROM. AS Temp INNER JOIN. AS Temp0 ON Temp.MaxAVTO=Temp0.Maxim;

1. Кількість годин, витрачених на роботи у певні дні

TRANSFORM SUM(PRODOLG)

SELECT KODRABOTU

FROM RABOTU

GROUP BY KODRABOTU

PIVOT DATAV;

1. Опис та тривалість самої короткострокової роботи

SELECT OPISANIE, PRODOLG

FROM RABOTU

WHERE PRODOLG = (SELECT MIN (PRODOLG) FROM RABOTU);

1. Вивести всіх виробників авто

SELECT PROIZV

FROM AVTO;

1. Виробник та рік випуску авто, що мають газове обладнання.

SELECT PROIZV, GODVIPUSKA

FROM AVTO

WHERE GAZ;

1. Додати інформацію про нового працівника в автосервісі.

INSERT INTO RABOTNIKI

VALUES ("Джейсон Стетхем", 7);

Додавання:

Рис.2.18 Таблиця “ RABOTNIKI ” до додавання нового запису

Запит:

Після додавання:

Рис.2.20 Таблиця “ RABOTNIKI ” після додавання нового запису

1. Змінити адресу Логінова Єгора Юрійовича

UPDATE VLADELCY SET ADRES = "Рязань, Московське шосе, 15"

WHERE PASPORTNOMER = "34 88 336882";

До зміни:

Рис.2.21 Таблиця “ VLADELCY ” до зміни запису

Запит:

Після зміни:

Рис.2.24 Таблиця “ VLADELCY ” після зміни запису

1. Видалити запис про автомобіль з держномером е244вв 23.

DELETE *

FROM AVTO

WHERE GOSNOMER = "е 244 вв 23";

До видалення:

Рис.2.25 Таблиця “ AVTO ” до видалення запису

Запит:

Після видалення:

Рис.2.28 Таблиця “ AVTO ” після видалення запису

2.2. Форми

Загальна форма бази даних "Станція технічного обслуговування автомобілів"

На формі розташовані кнопки для відкриття підлеглих форм (Авто, Власники, Роботи, Працівники), кнопки виконання запитів, і навіть кнопка закриття головної форми.

У режимі «Форма»

Рис.2.29 Загальна форма бази даних "Станція технічного обслуговування автомобілів"

У режимі "Конструктор"

Рис.2.30 Загальна форма бази даних «Станція технічного обслуговування автомобілів» як конструктор

Форма "Авто"

Рис.2.31 Форма "Авто"

У режимі "Конструктор"

Рис.2.32 Форма «Актори» як конструктор

Запити для полів зі списком

Запити для полів зі списком

Запити для полів зі списком

Форма «Власники»

Рис.2.36 Форма «Власники»

У режимі "Конструктор"

Рис.2.37 Форма «Власники» як конструктор

Форма «Роботи»

Рис.2.38 Форма «Роботи»

У режимі "Конструктор"

Рис.2.39 Форма «Роботи» як конструктор

Запити для полів зі списком

Форма зв'язку «Робота-Працівники»

Рис.2.41 Форма зв'язку «Робота-Працівники»

У режимі "Конструктор"

Рис.2.42 Форма зв'язку «Робота-Працівники» у режимі конструктор

Запити для полів зі списком

Висновок

У цьому проекті було створено реляційну базу даних «Станція технічного обслуговування автомобілів», яка містить п'ять таблиць з даними: таблицю по автомобілям, таблицю для власників, таблицю для робіт, таблицю для працівників та таблицю для зв'язку робіт та працівників.

Основні етапи розробки:

1. Визначення мети створення бази даних
2. Визначення необхідних полів у базі даних
3. Визначення таблиць, які має містити база даних.
4. Визначення таблиць, до яких належать поля.
5. Визначення первинних ключів.
6. Визначення зв'язків між таблицями.
7. Вдосконалення структури бази даних.
8. Введення даних та створення інших об'єктів бази даних (наприклад, форм та запитів).

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

З роботою даної БД може розібратися навіть програміст-початківець, так як вона зроблена максимально зручною і зрозумілою.

Список використаної літератури

1. Бекаревич Ю., Пушкіна Н. Microsoft Access за 21 заняття. – М.: Олма-Прес, 2006. – 544с.

2. Лорі Ульріх Фуллер, Кен Кук, Джон Кауфельд. Microsoft Office Access 2007 для чайників. – М.: Вільямс, 2007. – 384с.

3. Міхєєва В., Харитонова І. Microsoft Access 2003. – М.: Нова, 2005. – 1072с.

4. Хомоненко О.Д., Циганков В.М., Мальцев М.Г. Бази даних. Підручник для ВНЗ / за ред. проф. А.Д. Хомоненко // СПб.: КОРОНАпринт, 2000. 416 с.

5. Хомоненко А., Гридін В. В. Microsoft Access. Швидкий старт. – М., 2008. – 304с.

6. Корнєєв В.В. та ін Бази даних. Інтелектуальна обробка інформації М.: Нолідж, 2000. 352 с.

Авто

N : 1

Власники

Авто

1: N

Роботи

Працівники

N : N

Роботи

Держ. номер

Виробник

Модель

Рік випуску

Країна виробник

Газ

Номер паспорта

Номер паспорта

ПІБ

Адреса

Телефон

Код

роботи

Опис

Дата

виконання

Тривалість

Держ.

номер

Ідентифікаційний номер

ПІБ

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

УВАГА! Є пояснювальна записка (21 стор)

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

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

Таблиця "Автомобілі" - База даних Access Автосервіс

Таблиця «Майстри» — База даних 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 завантажити; ремонт автомобілів; ремонт авто; автомобільний салон; сервіс з ремонту автомобілів

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

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

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

• ? люди,
• ? матеріали,
• ? комп'ютери,
• ? верстати,
• ? будівлі.

Розроблена та створена База даних «Автосервіс» є сукупністю взаємопов'язаних компонентів та відображає різні напрямки ремонту автомобіля.

Малюнок 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. У роботі відображено покрокову технологію створення Бази даних. Наведено приклад бази даних "Автосервіс". Ця база була апробована на СТО. Система була протестована. У ході роботи внесено корективи та наведено в роботі остаточний варіант бази даних «Автосервіс».

Вступ 3
РОЗДІЛ 1. Розробка бази даних 4

Постановка задачі 4
Аналіз предметної галузі 5

ВСТУП

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

визначення та аналіз предметної області;
розробка концептуальної моделі бази даних;
побудова таблиць бази даних "Автосервіс";
побудова форм, запитів та звітів цієї БД.

РОЗДІЛ 1. Розробка бази даних

Постановка задачі

ПІБ, серія та № технічного паспорта автомобіля, рік випуску та марка виробника;
інформація про дату прийому цього замовлення, із зазначенням вартості ремонтних робіт, відповідального майстра та дату оплати замовлення;
перелік усунених несправностей у автомобіля цього власника;
ПІБ працівника автосервісу, який усував цю несправність автомобіля даного власника та його посаду.

додати або змінити інформацію про замовлення;
додати або змінити інформацію про працівника;
видалити інформацію про працівника автосервісу.

Аналіз предметної галузі

Надання великої сукупності інформації як таблиць бази даних.
Формування різних запитів за:

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

марки автомобілів, що ремонтуються, із зазначенням кількості заїздів на автосервіс;

кількість неоплачених замовлень;
загальна калькуляція ремонтних робіт за певний час автосервісу.

РОЗДІЛ 2. Моделювання структур даних

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

При побудові концептуальної моделі БД скористаємося рекомендаціями Карпової І.П. . Як зазначає автор, концептуальна модель бази даних - це високорівнева об'єктно-орієнтована модель предметної області, що представляє об'єктну область у вигляді набору об'єктів, що володіють певними властивостями і знаходяться в деяких відносинах. Основна мета розробки високорівневої моделі даних полягає у створенні моделі користувальницького сприйняття даних та узгодженні великої кількості технічних аспектів, пов'язаних із проектуванням бази даних. Концептуальна модель даних не прив'язана до конкретної фізичної реалізації баз даних і залежить від конкретної СУБД. Концептуальна модель створюється на основі уявлень про предметну область кожного типу користувачів, що являють собою набір даних, необхідних користувачеві для вирішення своїх завдань.
Концептуальна модель для бази «Автосервіс» проектувалась як модель «сутність-зв'язок».
Основні концепції моделі включають такі поняття: як сутність (об'єкт), відношення (зв'язок), типи сутностей, типи зв'язків та атрибути.
Сутність - реальний або об'єкт, що представляється, інформація про який повинна зберігатися і бути доступна. У діаграмах ER-моделі сутність представляється як прямокутника, що містить ім'я сутності. Кожна сутність визначається набором атрибутів.
Атрибут - названа характеристика сутності. Його найменування має бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутності. Атрибутом сутності є будь-яка деталь, яка служить для уточнення, ідентифікації, класифікації, числової характеристики чи виразу стану сутності. Імена атрибутів заноситимемо в прямокутник, що позначає сутність, і записуватимемо під ім'ям сутності.
Між сутностями встановлюються зв'язки.
Зв'язок - це асоціація, що графічно зображується, що встановлюється між двома сутностями. Ця асоціація завжди є бінарною і може існувати між двома різними сутностями або між сутністю і їй самою (рекурсивний зв'язок). Зв'язки – позначимо лініями.
Таким чином, з опису предметної області вилучимо всі типи
сутностей:
- Замовники;
- Замовлення;
- Майстри;
- Перелік робіт.
Кожною із сутностей визначимо свій набір атрибутів.
Сутність Замовник визначається наступним набором атрибутів:

код замовника;
П.І.Б.;
паспортні данні;
серія та № тех. паспорти;
Марка автомобіля;
колір;
№ шасі;
№ двигуна;
рік випуску.

код замовника;
код замовлення;
дата прийому та оплати;
калькуляція ремонтних робіт;
відповідальний майстер;
зауваження.

№ майстра;
ПІБ;
посаду цьому підприємстві;

код запиту;
код робіт;
деталізація.

2.2. Розробка логічної моделі даних

Перетворення локальної концептуальної моделі даних у локальну логічну модель полягає у видаленні з концептуальних моделей небажаних елементів та перетворення отриманих моделей у локальні логічні моделі. До небажаних елементів належать:
– зв'язки типу «багатьом-багатьом»;
- Рекурсивні зв'язки;
- Зв'язки з атрибутами.
У створеній концептуальній моделі перерахованих вище небажаних елементів не виявлено.
Логічна схема даних наведено на рис.2.

Мал. 2. Логічна схема даних.

Перетворення моделі «сутність-зв'язок» на реляційну модель даних

РОЗДІЛ 3. Проектування бази даних

Розробка таблиць

створення таблиць у режимі дизайну;
використання майстра до створення таблиці;
створення уявлення.

Визначення необхідних таблиць та полів.

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

Таблиця Замовники (рис.3) призначена для введення інформації про власника автомобіля, що ремонтується. Ця таблиця містить такі атрибути:

П.І.Б. (Тип поля - текстове, довжина - 50, обов'язкове);
паспортні дані (тип поля - текстове, довжина - 100, обов'язкове);
серія та № тех. паспорти (тип поля – текстове, довжина – 15, обов'язкове);
Марка автомобіля (тип поля – текстове, довжина – 100, обов'язкове);
колір автомобіля (тип поля - текстове, довжина - 100, не обов'язкове);
№ шасі (тип поля - текстове, довжина - 100, не обов'язкове);
№ двигуна (тип поля - числове, довжина - 100, не обов'язкове);
рік випуску (тип поля - дата, обов'язкове).

Таблиця Замовлення (рис. 4) призначена для введення інформації про замовлення: коли замовили, хто замовив, відповідальний майстер, вартість ремонтних робіт, зауваження. Ця таблиця містить такі атрибути:

код замовлення (тип поля – ціле, довжина – 10, обов'язкове);

код замовника (тип поля - текстове, довжина - 10, не обов'язкове);
дата замовлення (тип поля - дата, не обов'язкова);
загальна калькуляція ремонтних робіт (тип поля – десяткове, довжина – 100, необов'язкове);
відповідальний майстер (тип поля - ціле, довжина - 10, не обов'язкове);
дата оплати (тип поля – дата, необов'язкова);
дата прийому (тип поля - дата, не обов'язкове);
зауваження (тип поля - тестове, довжина - 100, не обов'язкове).

Таблиця Ремонтні роботи (рис. 5) призначена для опису всіх видів ремонтних робіт, які були виконані на цьому підприємстві.

код робіт (тип поля – ціле, довжина – 10, обов'язкове);
код замовлення (тип поля – ціле, довжина – 10, обов'язкове);
деталювання (тип поля - текстове, довжина - 100, не обов'язкове).

Майстри (рис. 6). Таблиця майстра варта введення інформації про співробітників. Ця таблиця містить такі атрибути:

№ майстра (тип поля – ціле, довжина – 10, обов'язкове);

П.І.Б. майстри (тип поля - текстове, довжина - 100, не обов'язкове);
посада (тип поля - текстове, довжина - 100, не обов'язкове).

Встановлення первинних ключів.

сутність Замовники має ключове поле Код замовника;
сутність Замовлення визначається ключем Код замовлення;
сутність Майстра має ключове поле № майстра;
сутність ремонтних робіт визначається ключем Код запиту;

Формування зв'язків між таблицями.

Розробка форм введення інформації

Рис.7. Форма Замовник.

Рис.8. Форма Замовлення.

Рис.9. Перелік робіт.

Рис.10. Майстри.
Складова форма містить головну форму та підлеглу їй форму - субформу. Субформа - це за своїм змістом та ж форма, але використовувана не самостійно, а завжди завантажується з будь-якої форми при відкритті або створенні документа. У субформі можна робити практично все те ж, що і у формі, за винятком, що не можна вставити в неї іншу субформу.
При створенні полів у субформах обов'язково слід враховувати, що імена всіх полів мають бути унікальними в межах форми разом із усіма субформами, які в ній використовуються одночасно.
Завдяки складеним формам з'являється можливість одночасно заповнювати різні таблиці.
Приклади субформ представлені на рис. 11-13.

Мал. 11. Форма Замовник із субформою Замовлення.
Форма Замовник із субформою Замовлення - забезпечує введення необхідних даних для ідентифікації замовника та перегляду виконаних робіт на дане замовлення. Ця форма дозволяє вносити інформацію до таблиць Замовник та Замовлення.

Мал. 12. Форма Замовлення із субформою Ремонтні роботи.
Ця форма дозволяє вносити інформацію до таблиць Замовлення та Ремонтних робіт.

Мал. 13. Форма Майстра із субформою Замовлення.
Форма Майстра із субформою Замовлення дозволяє контролювати виконання робіт конкретним майстром.

Розробка запитів до бази даних

Запит на вибірку. Запит на вибірку є типом запиту, що найчастіше використовується. Запити цього типу повертають дані з однієї або кількох таблиць і відображають їх у вигляді таблиці, записи якої можна оновлювати (з деякими обмеженнями). Запити на вибірку можна також використовувати для групування записів та обчислення сум,
і т.д.................