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

Необхідно створити базу даних аксес «Автосервіс»

Мал. 1 Головна кнопкова форма готової бази даних «Автосервіс»

Форма "Власники" з підлеглою формою "Автомобілі"

Мал. 2 Форма «Автомобілі»

Форма «Співробітники»

Мал. 4 Форма «Сервіс»

Мал. 5 Сторінка «Запити»

Запит «Угруповання з робіт та співробітників»

Запит «На прізвище механіка»

Запит «Пошук за держномером»

Мал. 6 Звіти

Звіт «Угруповання з робіт та співробітників»

Рис.7 Звіт «Пошук за держномером»

Мал. 8 Звіт «На прізвище механіка»

Мал. 9 Схема даних готової бази даних «Автосервіс» відображає зв'язки таблиць: Власники, Автомобілі, Сервіс, Категорія роботи, Співробітники.

Структура таблиці "Автомобілі": держ. номер, марка, власник.

Структура таблиці «Власники»: № власника, ПІБ, стільниковий телефон, № посвідчення водія.

Структура таблиці "Сервіс": № сервісу, автомобіль, категорія роботи, дата готовності замовлення, співробітник.

Структура таблиці «Співробітники»: № співробітника, стільниковий телефон, адреса, ПІБ.

або тут:

Завантажити звіт по базі даних з екранними формами безкоштовно

Орієнтовна ціна 763 руб.

Точна ціна залежить від способу оплати.

Способи оплати бази даних Access: WebMoney, Термінали оплати, Пошта Росії, QIWI, Білайн, MTC, Мегафон, Debit or Credit Card, WeChat Pay, Alipay (China), UnionPay, Яндекс.Гроші, Подарунковий сертифікат та інші.

Завантажити бази даних Access подібної тематики:

  1. База даних access Автосервіс 2
  2. Формування рахунків на оплату в автосервісі
  3. Облік автомобілів у автотранспортному підприємстві.
  4. АТП (автотранспортне підприємство).
  5. АТП 2007 (автотранспортне підприємство)
  6. Авторемонтні майстерні
  7. «Облік експлуатації транспортних засобів»
  8. «Облік дорожньо-транспортних пригод»
  9. Облік автопорушників у ДАІ.
  10. «Облік порушень правил дорожнього руху»
  11. «Заміна автозапчастин на СТО»
  12. Міський транспорт
  13. «Продаж авіаквитків»
  14. «Автовокзал»
  15. "Прокат автомобілів"
  16. Прокат автомобілів 2
  17. Автошкола
  18. Фірма з продажу запчастин
  19. Автосалон
  20. Облік амортизації автотранспорту по МОЛ та групам автотранспорту
  21. Таксі
  22. Пасажирське автопідприємство
  23. Розклад маршруток
  24. Облік автотранспортних перевезень по марках автомобілів

Ключові слова: база даних; програма бази даних; база даних; база даних курсової; завантажити базу даних access; access; готова база даних access; бази даних у access; приклад бази даних access; створити базу даних у access; приклади баз даних access; створення бази даних у access; основи access; запити у access; access звіти; таблиці access; макроси в access; access курсової; приклади бд access; форми access; бази даних microsoft access; купити базу даних; створення БД; приклади БД; скачати БД; курсова робота з СУБД; база даних приклади; готова курсова робота бази даних. Курсова база даних «Автосервіс» створена в access 2010 і перетворена на access 2003, тому відкриється в access 2003, 2007, 2010.

Необхідно створити базу даних аксесуар «Автосервіс». Головна форма кнопки готової бази даних «Автосервіс». Форма "Власники" з підлеглою формою "Автомобілі". Форма "Автомобілі". Форма "Категорія роботи". Форма "Співробітники". Форма "Сервіс". Сторінка "Запити". Запит «Угруповання з робіт та співробітників». Запит «На прізвище механіка». Запит "Пошук за держномером". Звіт «Угруповання з робіт та співробітників». Звіт «На прізвище механіка». Звіт «На прізвище механіка». Схема даних готової бази даних "Автосервіс" відображає зв'язки таблиць: Власники, Автомобілі, Сервіс, Категорія роботи, Співробітники. Структура таблиці "Автомобілі": держ. номер, марка, власник. Структура таблиці «Власники»: № власника, ПІБ, стільниковий телефон, № посвідчення водія. Структура таблиці "Категорія роботи": код роботи, найменування роботи, опис, вартість роботи. Структура таблиці "Сервіс": № сервісу, автомобіль, категорія роботи, дата готовності замовлення, співробітник. Структура таблиці «Співробітники»: № співробітника, стільниковий телефон, адреса, ПІБ. Структура запиту «Угруповання по роботам та співробітникам» у режимі конструктора. Структура запиту "На прізвище механіка" в режимі конструктора. Структура запиту "Пошук за держномером" в режимі конструктора. Макроси у режимі конструктора.

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

      Постановка задачі 4
      Аналіз предметної галузі 5
РОЗДІЛ 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 передбачено три різних способустворення таблиці бази даних:
    створення таблиць у режимі дизайну;
    використання майстра до створення таблиці;
    створення уявлення.
У цьому роботі таблиці створювалися з допомогою майстра.
p align="justify"> Для кожної реляційної таблиці БД наводиться її структура: склад полів, їх імена, тип даних і розмір кожного поля, ключі таблиці та інші властивості полів.
Розробка таблиць бази даних проводиться послідовно:
    Визначення необхідних таблиць та полів.
Таблиця є основою бази даних, тому розробки таблиць рекомендується керуватися такими основними принципами :
    відомості не повинні дублюватися у таблиці або між таблицями;
    дані, що зберігаються лише в одній таблиці, оновлюються лише у цій таблиці;
    кожна таблиця має містити інформацію лише одну тему.
Кожна таблиця містить відомості з конкретної теми, а кожне поле таблиці містить конкретний факт по темі таблиці. Для кожної таблиці в базі даних необхідно визначити властивості, що містяться в них.
База даних «Автосервіс» містить чотири таблиці:
    Таблиця Замовники (рис.3) призначена для введення інформації про власника автомобіля, що ремонтується. Ця таблиця містить такі атрибути:
    П.І.Б. (Тип поля - текстове, довжина - 50, обов'язкове);
    паспортні дані (тип поля - текстове, довжина - 100, обов'язкове);
    серія та № тех. паспорти (тип поля – текстове, довжина – 15, обов'язкове);
    Марка автомобіля (тип поля – текстове, довжина – 100, обов'язкове);
    колір автомобіля (тип поля - текстове, довжина - 100, не обов'язкове);
    № шасі (тип поля - текстове, довжина - 100, не обов'язкове);
    № двигуна (тип поля - числове, довжина - 100, не обов'язкове);
    рік випуску (тип поля - дата, обов'язкове).
Мал. 3. Таблиця Замовники.
    Таблиця Замовлення (рис. 4) призначена для введення інформації про замовлення: коли замовили, хто замовив, відповідальний майстер, вартість ремонтних робіт, зауваження. Ця таблиця містить такі атрибути:
    код замовлення (тип поля – ціле, довжина – 10, обов'язкове);
    код замовника (тип поля - текстове, довжина - 10, не обов'язкове);
    дата замовлення (тип поля – дата, не обов'язкова);
    загальна калькуляція ремонтних робіт (тип поля – десяткове, довжина – 100, необов'язкове);
    відповідальний майстер (тип поля - ціле, довжина - 10, не обов'язкове);
    дата оплати (тип поля – дата, необов'язкова);
    дата прийому (тип поля - дата, не обов'язкова);
    зауваження (тип поля - тестове, довжина - 100, не обов'язкове).
Мал. 4. Таблиця Замовлення.
    Таблиця Ремонтні роботи (рис. 5) призначена для опису всіх видів ремонтних робіт, які були виконані на цьому підприємстві.
Ця таблиця містить такі атрибути:
    код робіт (тип поля – ціле, довжина – 10, обов'язкове);
    код замовлення (тип поля – ціле, довжина – 10, обов'язкове);
    деталювання (тип поля - текстове, довжина - 100, не обов'язкове).
Мал. 5. Перелік робіт.
    Майстри (рис. 6). Таблиця майстра варта введення інформації про співробітників. Ця таблиця містить такі атрибути:
    № майстра (тип поля – ціле, довжина – 10, обов'язкове);
    П.І.Б. майстри (тип поля - текстове, довжина - 100, не обов'язкове);
    посада (тип поля - текстове, довжина - 100, не обов'язкове).
Мал. 6. Майстри.
    Встановлення первинних ключів.
Визначимо, кожної сутності первинний ключ, у своїй треба враховувати, що сильні сутності мають лише одне ключове полі, а слабкі - стільки ж, як і зв'язків. При виборі первинного ключа керуватимемося правилами:
– ключ повинен містити мінімальний набір атрибутів;
- Використовувати слід той ключ, ймовірність зміни значень якого мінімальна;
– значення ключа має мати мінімальну довжину.
Виходячи з вищесказаного, у існуючих сутностей визначимо такі ключові поля:
    сутність Замовники має ключове поле Код замовника;
    сутність Замовлення визначається ключем Код замовлення;
    сутність Майстра має ключове поле № майстра;
    сутність Ремонтні роботи визначається ключем Код запиту;
    Формування зв'язків між таблицями.
Після розбиття відомостей на таблиці та визначення ключових полів необхідно вибрати спосіб, яким СУБД об'єднуватиме пов'язані відомості. Для цього необхідно визначити зв'язок між таблицями бази даних.
OpenOffice.org BASE підтримує чотири типи відносин між таблицями:
- Один-до-одному (кожний запис в одній таблиці відповідає тільки одного запису в іншій таблиці);
- один-до-багатьом (кожний запис в одній таблиці відповідає багатьом записам в іншій таблиці);
- багато-до-одному (аналогічна запису «один-до-багатьом);
- багато-багатьом (один запис з першої таблиці може бути пов'язана більш ніж з одним записом з другої таблиці або один запис з другої таблиці може бути пов'язаний більш ніж з одним записом з першої таблиці).
Зв'язки, встановлені в БД «Автосервіс», вже були представлені в попередньому розділі на рис. 2.
      Розробка форм введення інформації
Форма - об'єкт, призначений для введення, редагування та перегляду табличних даних у зручному вигляді.
Форми містять звані елементи управління, з допомогою яких здійснюється доступ до даних у таблицях. Елементами управління є текстові поля для введення та редагування даних, кнопки, прапорці, перемикачі, списки, написи. Створення форм, що містять необхідні елементи управління, суттєво спрощує процес введення даних та дозволяє запобігти помилкам.
Форми OpenOffice.org Base надають функціональні можливості для виконання багатьох завдань, які не можна виконати іншими засобами, вони дозволяють виконувати перевірку коректності даних під час введення, проводити обчислення та забезпечують доступ до даних у зв'язаних таблицях за допомогою підлеглих форм.
OpenOffice.org Base пропонує кілька способів створення форм. Найпростішим із них є використання засобів автоматичного створення форм на основі таблиці чи запиту.
Для бази даних «Автосервіс» передбачено чотири прості форми та три субформи.
Приклади простих форм наведено на рис.7-10.

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

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

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

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

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

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

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

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

 Вивчити специфіку обраної предметної галузі.

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

 Реалізувати її у СУБД MS Access.

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

Призначення бази даних

База даних «Автосервіс»призначена для реалізації прийому та оформлення замовлень на роботи підприємством автосервісу.

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

 Бухгалтерії,

 Економічний блок

 Планового

 Постачання

 І цілого ряду інших блоків.

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

Функції, що виконуються базою даних

База даних виконує такі функції

1. Облік та зберігання відомостей про співробітників автосервісу. «Mechanics»

2. Введення та зберігання відомостей про види виконуваних робіт. «Orders»

3. Введення відомостей про замовників, про автомобілі замовників та даних про них. «Requests»

4. Форма "Введення відомостей про замовлення" забезпечує введення власнезамовлення, вибір ПІБ замовника (зі списку), вибір типу автомобіля замовника та введення відомостей про нього.

Там же – вводиться склад виконуваних робіт та ПІБ співробітників автосервісу, що їх виконують. А також – відомості про склад та кількість використаних запчастин.

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

Категорії користувачів

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

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

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

Введемо такі поняття і умовні позначення :

Сутності

СУТНІСТЬ

Сутність - реальний або репрезентований об'єкт , інформація про яку повинна зберігатися та бути доступна. У діаграмах ER-моделі сутність представляється як прямокутника, що містить ім'я сутності.

Сутностібудемо позначати прямокутниками,

Атрибути сутності

Атрибут - Поіменована характеристика сутності . Його найменування має бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутності. Атрибутом сутності є будь-яка деталь, яка служить для уточнення, ідентифікації, класифікації, числової характеристики чи виразу стану сутності.

СУТНІСТЬ

Атрибути

Імена атрибутівбудемо заносити в прямокутник,

позначає сутність, під ім'ям сутності, та писати

малі літери.

Взаємозв'язки

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

Зв'язки– позначимо лініями, над якими проставлятимемо ступінь зв'язку 1 » або « » , Що позначає "багато") та її характеристики.

Ключові поля

Визначимо поняття первиннихі зовнішніхключів

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

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

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

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

Зовнішні ключі

    Якщо сутність Зпов'язує сутності Аі У, вона повинна включати зовнішні ключі, що відповідають первинним ключам сутностей А і В.

    Якщо сутність Упозначає сутність А, то вона повинна включати зовнішній ключ, що відповідає первинному ключу сутності А.

Примітка:

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

Access не вимагаєйого обов'язкового включення до таблиці. Але наполегливо пропонує.

Особливості цього поля такі:

    При введенні нового запису– у цьому полі АВТОМАТИЧНО формується нове, унікальне, неповторне числове значення.

    Поле не може приймати невизначенезначення.

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

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

Тому проблема ключових поліві зовнішніх ключівв Access вирішується просто:

    У головній таблиці(сутності) створюємо спеціальне ключове поле. Воно й буде у нас первинним ключем .

    У підлеглі таблиці вводимо його копію (з тією самою назвою). Це буде їх зовнішній ключ .

    Зв'язуємо по цих полях головну та підлеглу таблиці. От і все. Зв'язок реалізований!

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

Яка дозволяє не тільки зв'язатитаблиці, а й вказати кожному зв'язку:

    її тип(«один – до – одного», «один – до – багатьох» тощо)

    і її Характеристики: забезпечення цілісності, а також каскадного оновлення та видалення інформації зі зв'язаних таблиць та полів.

Що необхідно вказувати і при побудові ER– моделібази даних.

Зокрема, саме тому Access ідеально підходить як система програмування для реалізації ER – моделей.

При реалізації нашоїER- моделі вAccessми всі ці можливості і скористаємося.

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

Студенти, аспіранти, молоді вчені, які використовують базу знань у своєму навчанні та роботі, будуть вам дуже вдячні.

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

ПЕРШИЙ ВИЩИЙ ТЕХНІЧНИЙ ЗАКЛАД РОСІЇ

МІНІСТЕРСТВО ОСВІТИ І НАУКИ РОСІЙСЬКОЇ ФЕДЕРАЦІЇ

Федеральна державна бюджетна освітня установа вищої професійної освіти

«НАЦІОНАЛЬНИЙ МІНЕРАЛЬНО-СИРОВИНИЙ УНІВЕРСИТЕТ «ГІРСЬКИЙ»

Курсова робота

«База даних – автосервіс»

З дисципліни: Прикладне програмування

Виконав: Степанова К.А.

Перевірив: Матюхін С.А.

Санкт-Петербург 2013 рік

Вступ

1. Опис предметної області

2. Опис структури БД

3. Таблиці

4. Технічне завдання

5. Опис програми

6. Компоненти

7. Схема для користувача

8. Інтерфейс

Висновок

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

додаток

Вступ

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

1. Опис предметної області

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

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

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

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

Жодних спеціальних знань для роботи з програмою в галузі програмування не потрібно.

2. Опис структури БД

Зв'язки таблиць:

Таблиця custumers пов'язана з таблицею masters за допомогою зв'язку 1:N по полю vin_number

Таблиця custumers пов'язані з таблицею calculation з допомогою зв'язку 1:1 з поля vin_number

3. Таблиці

Таблиця 1: Клієнти (провідна таблиця)

Таблиця 2: Майстри (відома)

Таблиця 3: Майстри (відома)

програмний автосервіс база редагування

4. Технічне завдання

Підстава для розробки:

Завдання викладача для проведення практичних занять та виконання курсової роботи.

Призначення розробки:

Програма призначена для автоматизації роботи операторів автосервісу.

Вимоги до програми:

· Повинна автоматизувати роботу оператора автосервісу

· Інформація повинна постійно зберігатися на жорсткому диску ЕОМ

· Повинен бути забезпечений перегляд бази даних із можливістю видалення з неї зазначеної інформації.

Вимоги до надійності:

· Програма повинна обробляти помилкові дії користувача та повідомляти йому про це.

· Програма має забезпечувати контроль вхідної інформації.

5. Опис програми

private void Form1_Load(object sender, EventArgs e) () // завантаження основних компонентів

private void b_add_Click(object sender, EventArgs e) () // додавання нового запису

private void b_replace_Click(object sender, EventArgs e) () // редагування запису

private void b_cancel1_Click(object sender, EventArgs e) () // скасування дії

private void b_save_Click(object sender, EventArgs e) () // збереження змін

private void b_record1_Click(object sender, EventArgs e) () // записати дані

private void b_delete_Click(object sender, EventArgs e) () // видалити дані

private void b_exit_Click(object sender, EventArgs e) () // вихід із програми

6. Компоненти

7. Схема длякористувача

Таблиця 1 «Клієнти» та таблиця 2 «Майстра» пов'язані ставленням «Один-багатьом» по полю vin_number.

Таблиця 1 «Клієнти» та таблиця 3 «Ціна» пов'язані ставленням «Один-до-одного» по полю vin_number.

8. Інтерфейс

Додавання нового запису

Редагування старого запису

Видалення запису

Сортування за датою візиту

Підписані таблиці

Головна таблиця програми «Автосервіс» включає:

1. Список автомобілів клієнтів

2. Дату звернення власника автомобіля

3. Несправність

4. Телефон клієнта

5. Vin номер

6. Управління списком клієнтів здійснюється кнопками (Додати/Замінити/Видалити)

7. Відображення та запис клієнтів салону

8. Сортування

10. Вибір майстрів

11. Найменування таблиць

12. Вихід із програми

Висновок

Результатом роботи стало створення програмного забезпечення, що обслуговує робоче місце оператора автосервісу

У процесі виконання курсової роботи було придбано навички у сфері побудови та програмування баз даних мовою програмування C#.

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

1. Матюхін С.А «Програмування на С# об'єктно-орієнтований підхід» - навчально-методичний комплекс 2013 р.

2. А. Хейлсберг, М. Торгерсен, С. Вілтамут, П. Голд Мова програмування C #. Класика Computers Science. 4-те видання = C# Programming Language (Covering C# 4.0), 4th Ed. - СПб.: «Пітер», 2012. - 784 с. -- ISBN 978-5-459-00283-6

3. Е. Стілмен, Дж. Грін Вивчаємо C #. 2-ге видання = Head First C#, 2ed. - СПб.: «Пітер», 2012. - 704 с. -- ISBN 978-5-4461-0105-4

4. Ендрю Троелсен Мова програмування C# 5.0 і платформа. - М.: "Вільямс", 2013. - 1312 с. -- ISBN 978-5-8459-1814-7

5. Джозеф Албахарі, Бен Албахарі C# 5.0. Довідник Повний опис мови = C# 5.0 в Nutshell: The Definitive Reference. - М.: "Вільямс", 2013. - 1008 с. -- ISBN 978-5-8459-1819-2

6. Герберт Шілдт. C# 4.0: повне керівництво= C # 4.0 The Complete Reference. - М.: "Вільямс", 2010. - С. 1056. - ISBN 978-5-8459-1684-6

додаток. Кодпрограми

використовуючи System.Collections.Generic;

використовуючи System.ComponentModel;

використовуючи System.Data;

використовуючи System.Drawing;

використовуючи System.Linq;

використовуючи System.Text;

використовуючи System.Threading.Tasks;

using System.Windows.Forms;

public partial class Form1: Form

InitializeComponent();

groupBox1.Visible = false;

groupBox2.Visible = false;

private void customersBindingNavigatorSaveItem_Click_1(object sender, EventArgs e)

this.Validate();

this.customersBindingSource.EndEdit();

this.tableAdapterManager.UpdateAll(this.db_autoDataSet);

private void Form1_Load(object sender, EventArgs e)

// TODO: Ця лінія code loads data в "db_autoDataSet.masters" table. Ви можете move, або remove it, as needed.

this.mastersTableAdapter.Fill(this.db_autoDataSet.masters);

// TODO: Ця лінія code loads data в "db_autoDataSet.calculation" table. Ви можете переміщатися, або повертати його, як потрібно.

this.calculationTableAdapter.Fill(this.db_autoDataSet.calculation);

// TODO: Ця лінія code loads data в "db_autoDataSet.customers" table. Ви можете переміщатися, або повертати його, як потрібно.

this.customersTableAdapter.Fill(this.db_autoDataSet.customers);

private void b_exit_Click(object sender, EventArgs e)

private void button5_Click_1(object sender, EventArgs e)

private void b_add_Click(object sender, EventArgs e)

groupBox1.Visible = true;

b_replace.Visible = false;

b_delete.Visible = false;

b_exit.Visible = false;

b_add.Visible = false;

b_exit2.Visible = false;

b_save.Visible = false;

textBox1.Text = "";

textBox2.Text = "";

textBox3.Text = "";

textBox4.Text = "";

textBox5.Text = "";

private void b_replace_Click(object sender, EventArgs e)

textBox10.Text = customers DataGridView.CurrentRow.Cells.Value.ToString();

textBox9.Text = customers DataGridView.CurrentRow.Cells.Value.ToString();

textBox8.Text = customers DataGridView.CurrentRow.Cells.Value.ToString();

textBox7.Text = customers DataGridView.CurrentRow.Cells.Value.ToString();

textBox6.Text = customers DataGridView.CurrentRow.Cells.Value.ToString();

textBox6.ReadOnly = true;

groupBox2.Visible = true;

b_add.Visible = false;

b_delete.Visible = false;

b_exit.Visible = false;

b_exit2.Visible = false;

b_replace.Visible = false;

b_save.Visible = false;

private void b_cancel1_Click(object sender, EventArgs e)

b_add.Visible = true;

b_delete.Visible = true;

b_exit.Visible = true;

b_exit2.Visible = true;

b_replace.Visible = true;

b_save.Visible = true;

groupBox1.Visible = false;

private void b_cancel2_Click(object sender, EventArgs e)

b_add.Visible = true;

b_delete.Visible = true;

b_exit.Visible = true;

b_exit2.Visible = true;

b_replace.Visible = true;

b_save.Visible = true;

groupBox2.Visible = false;

private void b_save_Click(object sender, EventArgs e)

customersBindingNavigatorSaveItem_Click_1(sender, e);

private void b_record1_Click(object sender, EventArgs e)

DataTable table = db_autoDataSet.Tables;

DataRow row = table.NewRow();

row=textBox1.Text;

row = Convert.ToDateTime(textBox2.Text);

row=textBox3.Text;

row=textBox4.Text;

row = textBox5.Text;

table.Rows.Add(row);

groupBox1.Hide();

b_replace.Visible = true;

b_delete.Visible = true;

b_exit.Visible = true;

b_add.Visible = true;

b_exit2.Visible = true;

b_save.Visible = true;

private void b_record2_Click(object sender, EventArgs e)

DataTable table = db_autoDataSet.Tables;//12 зв'язали динаміч. табл. table з першим файлом із бази даних

vinRab = Convert.ToInt64 (customersDataGridView.CurrentRow.Cells.Value.ToString());//13 отримали vin поточного запису

DataRow row = table.Rows.Find(vinRab); // 14 поєднали динаміч. рядок row із записом файлу vin c shifrRab і перевели набір даних DataSet у стан "редагування", у якому дозволяє змінювати значення полів

row = textBox10.Text;//15 записали у друге поле рядка row дане з вікна

row = Convert.ToDateTime(textBox9.Text); // 15 записали в третє поле рядка row

row=textBox8.Text; //15 записали у четверте поле рядка row row = textBox7.Text;

row = textBox6.Text;

table.AcceptChanges();//15 команда AcceptChanges дозволяє прийняти змінені значення полів

groupBox2.Hide();//16

b_replace.Visible = true;

b_delete.Visible = true;

b_exit.Visible = true;

b_add.Visible = true;

b_exit2.Visible = true;

b_save.Visible = true;

private void b_delete_Click(object sender, EventArgs e)

// Видалення рядка під курсором

// Спершу будуємо попередження, щоб не зробити помилкового видалення

string s1, s2, s3, s4, s5, message;

DialogResult result;// 18

int ind = customersDataGridView.CurrentRow.Index;

s1 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s2 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s3 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s4 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s5 = customersDataGridView.CurrentRow.Cells.Value.ToString();

message = "Марка авто = " + s1 + "\nДата візиту = " + s2 + "\n Несправність = " + s3 + "\n Тел. клієнта= " + s4 + "\n vin номер" + s5;

// змінна result може приймати значення DialogResult.Yes, або DialogResult.No

result = MessageBox.Show(message, "Видалити наступний запис?",

MessageBoxButtons.YesNo, MessageBoxIcon.Question);

if (result == DialogResult.Yes)//Рядок видаляється

(// 20 У буферну таблицю записується поточна таблиця з customersDataGridView типу DataGrid

CurrencyManager CurMng = (CurrencyManager)customersDataGridView.BindingContext;

if (CurMng.Count > 0) // якщо таблиця не порожня

CurMng.RemoveAt(CurMng.Position); // видалення зазначеної позиції

// тут result == DialogResult.No і видалення відкидається

// Виходимо з процедури

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

Подібні документи

    Створення бази даних. Пошук, зміна та видалення записів. Обробка та обмін даними. Проектування баз даних. Визначення формул для обчислюваної частини бази. Редагування полів та записів. Форми подання інформації, що міститься у базі даних.

    курсова робота , доданий 23.02.2009

    Розробка програмного продукту - бази даних "Екскурсія" в інтегрованому середовищі програмування C++ Builder 6. Визначення порядку перегляду даних бази, їх редагування та видалення. Особливості посібника користувача та загального інтерфейсу програми.

    курсова робота , доданий 03.11.2013

    Обґрунтування необхідності систем керування базами даних на підприємствах. Особливості розробки програмного забезпечення управління базою даних, що забезпечує перегляд, редагування, вставку записів бази даних, формування запитів і звітів.

    курсова робота , доданий 23.01.2010

    Створення бази даних та опис програми "Навчальна база даних", призначеної для угруповання відомостей про учнів. Характеристика функціональних можливостейпрограми: додавання записів до бази, редагування, видалення записів та сортування даних.

    курсова робота , доданий 25.04.2011

    Розробка програми "База даних спортивного інвентарю". Опис алгоритму роботи модулів та блоків. Структурна схема представлення проекту. Процес пошуку необхідної інформації. Автоматичне сортування даних. Додавання та редагування записів.

    курсова робота , доданий 15.08.2013

    Створення простих форм-довідників. Редагування властивостей форми як конструктора. Додавання та редагування властивостей елементів керування. Проектування звітів для бази даних. Приведення таблиці до нормальній форміта побудова схеми даних.

    реферат, доданий 23.11.2008

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

    курсова робота , доданий 20.01.2010

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

    Лабораторна робота, доданий 10.10.2012

    Аналіз предметної галузі. Вимоги, що пред'являються під час упорядкування бази даних готелю. Реалізація процесу пошуку необхідної інформації. Формування таблиць, запитів, звітів та виведення їх на друк. Редагування, додавання та зберігання даних.

    курсова робота , доданий 07.02.2016

    Обґрунтування вибору засобів розробки програми. Додавання, видалення, редагування інформації. Відображення інформації із бази даних. Пошук інформації по вибраній таблиці. Проекти Data, Entity, Logic, Firm. Схема взаємодії проектів програми.




Top