Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
PAGE \* MERGEFORMAT2
ЗАТВЕРДЖЕНО
Наказ Міністерства освіти і науки,
молоді та спорту України
29 березня 2012 року № 384
Форма № Н-6.01
Вінницький національний технічний університет
(повне найменування вищого навчального закладу)
Кафедра програмного забезпечення
(повна назва кафедри, циклової комісії)
КУРСОВА РОБОТА
з дисципліни «Бази даних»
(назва дисципліни)
на тему: Розробка бази даних «Автосалон» в середовищі MS Access
Студентки IV курсу 1ПІ-10б (д/н) групи
напряму підготовки 6.050103 «Програмна інженерія»
Піддубецької М.П.
(прізвище та ініціали)
Керівник: ас. Денисюк А.В.
(посада, вчене звання, науковий ступінь, прізвище та ініціали)
Національна шкала ________________
Кількість балів: __________Оцінка: ECTS _____
Члени комісії __________ ____________________
(підпис) (прізвище та ініціали)
__________ ____________________
(підпис) (прізвище та ініціали)
__________ ____________________
(підпис) (прізвище та ініціали)
м. Вінниця – 2013 рік
Анотація
У курсовій роботі описано розробку базу даних «Автосалон» за допомогою СУБД Microsoft Access 2010.
База даних дозволяє отримати дані про діяльність автомобільного салону, а саме: містить дані про автомобілі, виробників автомобілів, продавців та клієнтів автосалону. Дозволяє вести облік роботи автосалону: скільки автомобілів було продано за певний період часу, кількість завершених операцій продажу кожним працівником автосалону, містить інформацію про клієнтів.
Побудована база даних коректно та зрозуміло відображає дані, дозволяє збільшити ефективність роботи автомобільного салону.
ЗМІСТ
|
[1] Вступ [2] 1 аналіз ПРЕДМЕТНОЇ ГАЛУЗІ [3] 2 розробка структури бази даних [3.1] 2.1 Розробка універсального відношення [3.2] 2.2 Розробка ER-моделі предметної області [3.3] 2.3 Проектування нормалізованих відношень [3.4] 2.4 Одержання початкових відношень за методом “суть – зв'язок” [3.5] 2.5 Нормалізація відношень методом декомпозиції [3.6] 2.6 Оцінка спроектованих НФБК відношень [4] 3 розробка форм
[5] [6] 5 розробка звітів [7] 6 ТЕСТУВАННЯ РОБОТИ БД [8] висновки [9] перелік посилань [10] додатки [10.1] Додаток А [10.2] Додаток Б
[10.3]
[11] |
Система керування базами даних (СКБД) – комп'ютерна програма чи комплекс програм, що забезпечує можливість створення, збереження, оновлення, пошук інформації та контролю доступу в базах даних.
Реляційна база даних – це база даних, побудована на основі реляційної моделі, тобто база даних, що має табличний спосіб представлення даних, а на зовнішньому рівні задається набором однорідних таблиць. Кожний об'єкт записується рядком у таблиці. Рядок називається записом. Запис складається з полів різного типу. Реляційна база даних створюється й потім управляється за допомогою спеціальних засобів – реляційних систем керування базами даних (РСУБД) [1]. Вони дозволяють зберігати дані в багатьох таблицях, зв’язаних один з одним індексами. Оскільки дані можуть бути рознесені по декількох таблицях, реляційні бази даних працюють швидше; їх достатньо легко підтримувати.
Microsoft Access об'єднує відомості з різних джерел в одній реляційній базі даних. Створювані форми, запити і звіти дозволяють швидко і ефективно оновлювати дані, отримувати відповіді максимально швидко, здійснювати пошук потрібних даних, аналізувати їх, друкувати звіти, діаграми і поштові наклейки. Відомості з кожного джерела зберігаються в окремій таблиці. При роботі з даними з декількох таблиць встановлюються зв'язки між таблицями. При побудові запитів Microsoft Access дає можливість використовувати засоби SQL та QBE. Microsoft Access досить потужний механізм для роботи з базами даними, саме тому даний продукт досить довго займає провідне місце в розробці і проектуванні реляційних баз даних.
Мета виконання курсової роботи – побудова бази даних «Автосалон» засобами Microsoft Access 2010. База даних повинна містити відомості про автомобілі, компанії – виробники автомобілів, продавців та клієнтів автосалону.
Мета курсової роботи – створення автоматизованої системи обслуговування бази даних автосалону. Її призначення полягає в наданні користувачам інформації автомобільного салону: марка проданого автомобіля, виробник, колір і дата виготовлення автомобіля, його вартість, покупець, дата продажу та продавець, інформація про продавця і виробника автомобіля.
База даних «Автосалон» повинна забезпечувати наступні функції:
База даних міститиме всю необхідну інформацію, яка може бути корисною для користувача і дає вичерпні знання про роботу автосалону.
База даних «Автосалон» розробляється в середовищі Microsoft Office Access 2010 для використання на IBM-сумісних комп’ютерах. Введення вищевказаної інформації здійснюється з клавіатури комп’ютера з використанням вбудованого редактора баз даних. Виведення інформації виконується на екран монітора, також за допомогою принтера.
Універсальне відношення – це таке відношення в яке включаються всі необхідні атрибути . Воно може містити всі дані , які передбачається розміщувати в БД.
При використанні універсального відношення виникають дві проблеми: надмірність даних та потенційна суперечливість (аномалії) [1].
Під надмірністю розуміють повторення даних в різних рядках однієї таблиці або в різних таблицях БД.
Аномалії – це проблеми, що виникають в даних через дефекти проектування БД. Існують три види аномалій: вставки, видалення та модифікації.
Аномалії вставки проявляються при введенні даних в дефектну таблицю. Якщо ввести дані, що не відповідають наявним в таблиці, буде не ясно, яка з рядків БД містить правильну інформацію.
Аномалії видалення виникають при видаленні даних з дефектною схемою. Наприклад, якщо всі автомобілі марки «Тойота» продали в один і той же день то після видалення записів цих автомобілів в БД більше не буде жодного запису, що містить інформацію про марку автомобілів «Тойота».
Аномалії модифікації виникають при зміні даних дефектної схеми. Наприклад, якщо один із продавців автосалону змінив своє прізвище необхідно змінити відповідні дані про кожний проданий ним автомобіль. Якщо хоча б один запис буде пропущено, виникне аномалія модифікації [1].
В універсальне відношення потрібно включити атрибути, що описують наступні інформаційні об’єкти: автомобіль, покупець, виробник, продавець.
Наведений перелік найбільш суттєвих характеристик кожного інформаційного об’єкту.
Автомобіль (код автомобіля; марка автомобіля; колір; дата виготовлення; вартість автомобіля; дата продажу). Покупці (код покупця; ПІБ покупця; паспорт; адреса покупця). Виробники (код виробника; назва виробника; країна виробника). Продавці (код продажу; ПІБ продавця; посада продавця).
Кожний об’єкт характеризується набором атрибутів. Перелік цих атрибутів представлений в таблиці 2.1:
Таблиця 2.1 - Перелік атрибутів, що містить універсальне відношення
|
Назва атрибута |
Ім’я поля |
Коментар |
|
Код автомобіля |
Код автомобіля |
Код автомобіля, що надійшов до бази даних |
|
Марка автомобіля |
Марка автомобіля |
Марка відповідного автомобіля |
|
Колір |
Колір |
Колір автомобіля |
|
Дата виготовлення |
Дата виготовлення |
Дата виготовлення відповідного автомобіля |
|
Вартість автомобіля |
Вартість автомобіля |
Вартість автомобіля |
|
Дата продажу |
Дата продажу |
Дата, коли автомобіль був проданий |
|
Код покупця |
Код покупця |
Код покупця, який додається в базу даних |
|
ПІБ покупця |
ПІБ покупця |
Повне ім’я покупця |
|
Паспорт |
Паспорт |
Паспортні дані покупця |
|
Адреса покупця |
Адреса покупця |
Адресні дані покупця |
|
Код продавця |
Код продавця |
Код кожного продавця |
|
ПІБ продавця |
ПІБ продавця |
Продавець, який продав автомобіль |
|
Посада продавця |
Посада продавця |
Посада продавця у автосалоні |
|
Код виробника |
Код виробника |
Код виробника кожного автомобіля |
|
Назва виробника |
Назва виробника |
Повна назва виробника |
|
Країна виробник |
Країна виробник |
Країна-виробника автомобіля |
Універсальне відношення R: (код автомобіля, марка автомобіля, колір, дата виготовлення, вартість автомобіля, дата продажу, код покупця, ПІБ покупця, паспорт, адреса покупця, код виробника, назва виробника, країна виробник, код продавця, ПІБ продавця, посада продавця) – потужність універсальної множини 16.
Семантичне моделювання являє собою моделювання структури даних, спираючись на зміст цих даних. В якості інструменту семантичного моделювання використовуються різні варіанти діаграм суть-зв'язок (ER – Entity - Relationship).
Суть – це клас однотипних об'єктів, інформація про які повинна бути врахована в моделі. Кожна суть повинна мати найменування, виражене іменником в однині. Прикладами суті можуть бути такі класи об'єктів як "Постачальник" , "Співробітник " , "Накладна" [2].
Атрибут суті – це іменована характеристика , що є деякою властивістю суті. Найменування атрибуту має бути виражене іменником в однині (можливо прикметником). Прикладами атрибутів суті " Співробітник" можуть бути такі атрибути як "Табельний номер" , "Прізвище " , "Ім'я" , "По батькові " , " Посада " , "Зарплата " і т.п.
Ключ суті – це не надлишковий набір атрибутів, значення яких в сукупності є унікальними для кожного екземпляра суті. Не надлишковість полягає в тому, що видалення будь-якого атрибуту з ключа порушує його унікальність. Суть може мати кілька різних ключів.
Зв'язок – це деяка асоціація між двома сутностями. Одна суть може бути пов'язана з іншою сутністю або сама з собою. Зв'язки дозволяють за допомогою одної суті знаходити інші, пов'язані з нею.
Кожний зв'язок має два кінця і одне або два найменування. Найменування зазвичай виражається в невизначеній дієслівної формі : "мати" , "належати" і т.п. Кожне з найменувань відноситься до свого кінця зв'язку. Іноді найменування не пишуться зважаючи на їх очевидність.
Зв'язок типу один-до-одного означає, що один екземпляр першої суті пов'язаний з одним примірником другої суті. Зв'язок один-до-одного найчастіше свідчить про те , що насправді існує всього одна суть, яка неправильно розділена на дві [2].
Зв'язок типу один-до-багатьох означає, що один екземпляр першої суті пов'язаний з декількома екземплярами другої суті. Це найбільш часто використовуваний тип зв'язку. Ліва суть (з боку "один") називається батьківською, права (з боку "багато") – дочірньою.
Зв'язок типу багато-до-багатьох означає , що кожен екземпляр першої суті може бути пов'язаний з декількома екземплярами другої суті, і кожен примірник другої суті може бути пов'язаний з декількома екземплярами першої суті. Тип зв'язку багато-до-багатьох є тимчасовим типом зв'язку, допустимим на ранніх етапах розробки моделі. Надалі цей тип зв'язку повинен бути замінений двома зв'язками типу один-до-багатьох шляхом створення проміжної суті [2].
Для кожної суті необхідно вибрати атрибут чи сукупність атрибутів, що ідентифікують її однозначно і виступають ключем відповідного відношення. Необхідно враховувати, що ключ повинен включати в свій склад мінімальне число атрибутів, а не тільки виконувати завдання ідентифікації. У базі даних «Автосалон» наступні атрибути:
Автомобіль <Код автомобіля>
Покупець <Код покупця>
Продавець <Код продавця>
Продажі <Код>.
Зв'язок Виробники – Автомобілі показано на рис. 2.1, який показує, що клас належності суті Виробник не є обов’язковим, можливо, що виробник внесений у базу даних, але автомобілі цього виробника ще не було продано у автосалоні. Тип зв’язку 1:N, оскільки виробнику можуть належати декілька автомобілів, але автомобіль не може бути вироблений декількома підприємствами.
Рисунок 2.1 – ER-діаграма екземплярів сутностей Виробники і Автомобілі
Зв'язок Продавці – Автомобілі показано на рис. 2.2, що показує, що клас належності суті Продавець не є обов’язковим, можливо, що продавець ще не продав на даний момент автомобіля. Тип зв’язку 1:N, оскільки продавець може продати декілька автомобілів, але автомобіль не може бути проданий декількома продавцями.
Рисунок 2.2 – ER-діаграма екземплярів сутностей Продавці і Автомобілі
Аналогічним є зв'язок Покупці – Автомобілі представлений діаграмою
екземплярів на рис. 2.3. Клас належності суті Покупець є обов’язковим, адже якщо покупець внесений у базу даних, він уже здійснив покупку автомобіля.
Рисунок 2.3 – ER-діаграма екземплярів сутностей Покупці і Автомобілі
Результати проведеного аналізу наведемо в таблиці 2.2.
Таблиця 2.2 – Зв’язки предметної області «Автосалон»
|
Суть 1 |
Суть 2 |
Тип зв’язку |
Ім’я зв’язку |
Тип належності |
|
Виробник |
Автомобіль |
1 : N |
виробляє |
Не обов.; Обов. |
|
Продавець |
Автомобіль |
1 : N |
продає |
Не обов.; Обов. |
|
Покупець |
Автомобіль |
1 : N |
купує |
Обов.; Обов. |
Використовуючи таблицю 2.2, будуємо результуючу ER-модель предметної області «Автосалон», показану на рис. 2.4.
Рисунок 2.4 – Результуюча ER-модель предметної області “Автосалон”
Визначення 1НФ: відношення знаходиться в 1НФ, якщо воно не має повторюваних кортежів
Властивості відношення, що перебуває в 1НФ:
Відношення знаходиться в другій нормальній формі (2НФ) тоді і тільки тоді, коли відношення знаходиться в 1НФ і немає не ключових атрибутів, залежних від частини складного ключа (не ключовий атрибут – це атрибут, який не входить до складу жодного потенційного ключа). Атрибути називаються взаємно незалежними, якщо жоден з них не є функціонально залежним від іншого.
Відношення знаходиться в третій нормальній формі (3НФ) тоді і тільки тоді, коли відношення знаходиться в 2НФ і всі не ключові атрибути взаємно незалежні.
Алгоритм нормалізації (тобто алгоритм приведення відношень до 3НФ) описується наступним чином.
Крок 1 (приведення до 1НФ). На першому кроці задається одне або декілька відношень, що відображають поняття предметної області. За моделлю предметної області виписуються виявлені функціональні залежності. Всі відношення автоматично знаходяться в 1НФ.
Крок 2 (приведення до 2НФ). Якщо в деяких відношеннях виявлена залежність атрибутів від частини складного ключа, то проводиться декомпозиція цих відношень на кілька відношень таким чином: ті атрибути, які залежать від частини складного ключа виносяться в окреме відношення разом з цією частиною ключа.
Крок 3 (приведення до 3НФ). Якщо в деяких відношеннях виявлена залежність деяких не ключових атрибутів від інших не ключових атрибутів, то проводиться декомпозиція цих відносин таким чином: ті не ключові атрибути, які залежать від інших не ключових атрибутів виносяться в окреме відношення [3].
Систематизовані та узагальнені дані про нормалізацію відношень наведено в таблиці 2.3, дана таблиця дає оцінку впливу логічного моделювання даних на якість фізичних моделей даних і продуктивність бази даних. Можна помітити, що відношення, приведені до 3НФ набагато спрощують розробку і супровід бази даних, забезпечують більшу швидкість виконання операцій вставки, оновлення та видалення, сприяють адекватності бази даних предметної області. Недоліком можна вважати повільнішу, порівняно з відношеннями в 1НФ, 2НФ, швидкість виконання вибірки даних.
Таблиця 2.3 – Оцінка впливу логічного моделювання даних
|
Критерій |
Відношення нормалізовані в 1НФ, 2НФ |
Відношення нормалізовані в 3НФ |
|
Адекватність бази даних предметної області |
– |
+ |
|
Легкість розробки і супроводу бази даних |
Складніше (-) |
Простіше (+) |
|
Швидкість виконання вставки, оновлення, видалення |
Повільніше (-) |
Швидше (+) |
|
Швидкість виконання вибірки даних |
Швидше (+) |
Повільніше (-) |
Для побудови бази даних «Автосалон» універсальне відношення R розбивається на чотири відношення, які перебувають у 3НФ:
R1 <Код автомобіля> Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу;
R2<Код покупця> Прізвище, Паспорт, Адреса покупця;
R3<Код продавця> ПІБ продавця, Посада продавця;
R4<Код виробника> Назва виробника, Країна виробник.
Модель "суть-зв'язок" ґрунтується на важливій семантичній інформації про реальний світ і призначена для логічного представлення даних. Вона визначає значення даних в контексті їх взаємозв'язку з іншими даними. Важливим є той факт, що з моделі "суть-зв'язок" можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найбільш загальною. Загальний підхід до проектування баз даних на основі ER-метода що включає в себе наступні кроки:
– побудова діаграми ER - типа, що включає в свій склад всі суті і зв'язки даної предметної області;
– побудова набору попередніх відношень з вказуванням передбачуваного початкового ключа для кожного відношення;
Для побудови моделі «суть-зв'язок» для бази даних «Автосалон» використовуються наступні правила: правило 4.
Правило 1. Якщо ступінь бінарних зв'язків 1:1 і клас належності обов'язковий для обох сутей, то гарантується однократне появлення кожного значення сутей в будь-якому екземплярі відношень. Тобто у відношенні ніколи не буде ні порожньої інформації, ні груп надлишкових даних, що повторюються.
Правило 2. Якщо степінь бінарного зв'язку 1:1 і клас належності однієї суті являється обов’язковим, а інший необов'язковим, то необхідна побудова двох відношень. При цьому ключ суті повинен служити первинним ключем для відповідного відношення. Крім того, ключ суті, для котрого клас належності являється обов'язковим, додається у якості атрибута у відношення, що виділене для суті з обов'язковим класом належності [4].
Правило 3. Якщо степінь бінарного зв'язку 1:1 і клас належності обох сутей не являється обов'язковим, то необхідно використовувати три відношення: по одному для кожної суті, ключі котрих служать у якості первинних ключів відповідних відношень, і одне для зв'язку. Первинним ключем цього відношення може бути будь-яка з двох сутей. Серед своїх атрибутів відношення, що виділяється для зв'язку, повинно мати по одному ключу для кожної суті.
Правило 4. Якщо степінь бінарного зв'язку 1:N, і клас належності n-зв'язаної суті є обов'язковим, то досить використати по одному відношенню на кожну суть, при умові, що ключ кожної суті служить у якості первинного ключа для відповідного відношення. Додатково, ключ 1-зв’язаної суті повинен бути добавлений як атрибут у відношення, що відводиться n-зв'язаній суті.
Очевидно, що використання двох відношень в цьому випадку дозволяє встановити дублювання інформації (багатократний опис атрибута 1-зв’язаної суті, зв'язаного з n атрибутами n-зв'язаної суті).
Використовуючи приведене правило, перелік атрибутів з універсального відношення та сформованої ER-моделі предметної області, отримуються попередні відношення, які приведені в таблиці 2.4:
Таблиця 2.4 - Попередні відношення для предметної області “Автосалон”
|
Ім’я зв’язку |
Правило |
Попередні відношення |
Додаткові атрибути |
|
виробляє |
4 |
R1 (Код виробника) |
Назва виробника Країна виробник |
|
*R4 (Код автомобіля) |
Марка автомобіля Колір Дата виготовлення Вартість автомобіля Дата продажу Код виробника |
||
|
продає |
4 |
R2 (Код продавця) |
ПІБ продавця Посада продавця |
|
*R4 (Код автомобіля) |
Марка автомобіля Колір Дата виготовлення Вартість автомобіля Дата продажу Код виробника Код продавця |
||
|
купує |
4 |
R3 (Код покупця) |
ПІБ покупця Паспорт Адреса покупця |
|
R4 (Код автомобіля) |
Марка автомобіля Колір Дата виготовлення Вартість автомобіля Дата продажу Код виробника Код продавця Код покупця |
У таблиці 2.4 знаком “*” помічені відношення, які потрібно видалити.
Кінцеві відношення, що описують базу даних “Автосалон” представлені наступним набором:
Автомобілі (Код автомобіля, Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу).
Покупці (Код покупця, Прізвище, Паспорт, Адреса покупця).
Продавці (Код продавця, ПІБ продавця, Посада продавця).
Виробники (Код виробника, Назва виробника, Країна виробник).
При операції декомпозиції з одного відношення отримується два або більше відношень, кожне з яких містить частину атрибутів вихідного відношення. В отриманих нових відношеннях необхідно видалити дублікати рядків, якщо такі виникли. Це означає, що декомпозиція відношень є не що інше, як взяття однієї або декількох проекцій вихідного відношення так, щоб ці проекції в сукупності містили (можливо, з повтореннями) всі атрибути вихідного відношення. Тобто, при декомпозиції не повинні губитися атрибути відношень. Але при декомпозиції також не повинні загубитися і самі дані. Дані можна вважати не втраченими в тому випадку, якщо можлива зворотна операція – по декомпозованому відношенню можна відновити вихідне відношення в точності попередньому вигляді. Операцією, зворотною до операції проекції, є операція з'єднання відношень. Існує велика кількість видів операції з'єднання: при відновленні вихідного відношення шляхом з'єднання проекцій не повинні з'явитися нові атрибути, а отже необхідно використовувати природне з'єднання [5].
Власні проекції і відношення називаються декомпозицією без втрат, якщо відношення точно відновлюється з них за допомогою природного з'єднання для будь-якого стану відношень.
Для отримання відношення в НФБК проведемо послідовність операцій декомпозиції на основі правил декомпозиції.
Розглянемо попереднє універсальне відношення R:
R: (<Код автомобіля, Код покупця, Код виробника, Код продавця>, Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу, ПІБ покупця, Паспорт, Адреса покупця, Назва виробника, Країна виробник, ПІБ продавця, Посада продавця).
Спроектуємо відношення R, яке породжується всіма функціональними залежностями, що містять атрибут Код покупця. В результаті отримаємо відношення R1 і R2:
R1: (<Код автомобіля, Код виробника, Код продавця>, Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу, Назва виробника, Країна виробник, ПІБ продавця, Посада продавця);
R2: (<Код покупця>, ПІБ покупця, Паспорт, Адреса покупця);
Виконаємо декомпозицію R1 шляхом проектування, породжуваного всіма функціональними залежностями, що містять атрибут Код виробника. Отримаємо відношення R3, R4.
R3: (<Код автомобіля, Код продавця>, Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу, ПІБ продавця, Посада продавця);
R4: (< Код виробника>, Назва виробника, Країна виробник).
Виконаємо декомпозицію R3 шляхом проектування, породжуваного всіма функціональними залежностями, що містять атрибут Код продавця. Отримаємо відношення R5, R6.
R5: (<Код автомобіля>, Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу);
R6: (<Код продавця>, ПІБ продавця, Посада продавця).
Відношення R2, R4, R5, R6 знаходяться в НФБК, що свідчить про закінчення процедури декомпозиції.
Кінцеві відношення знайдені за допомогою методу декомпозиції, мають наступний вигляд:
R2: (<Код автомобіля>, ПІБ покупця, Паспорт, Адреса покупця);
R4: (< Код виробника>, Назва виробника, Країна виробник);
R5: (<Код автомобіля>, Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу);
R6: (<Код продавця>, ПІБ продавця, Посада продавця).
Розглянемо функціональні залежності, які присутні між атрибутами універсального відношення, що описує предметну область «Автосалон» (рис.2.5).
Рисунок 2.5 – Діаграма функціональної залежності
Розглядаючи отримані при проектуванні бази даних “Автосалон” відношення, необхідно переконатись, що :
- жодна функціональна залежність не повторюється більше одного разу;
- цей набір функціональних залежностей є мінімальним.
Аналіз відношень показує, що не можна вказати серед них жодного, всі атрибути якого були би підмножиною атрибутів іншого відношення. Крім того, неможливо об’єднати будь-які три відношення так, щоб у результаті були отримані всі атрибути четвертого відношення. Отже, жодне з відношень не є надлишковим.
Кінцеві НФБК відношення є такими:
R2: (Код автомобіля, ПІБ покупця, Паспорт, Адреса покупця);
R4: (Код виробника, Назва виробника, Країна виробник);
R5: (Код автомобіля, Марка автомобіля, Колір, Дата виготовлення, Вартість автомобіля, Дата продажу);
R6: (Код продавця, ПІБ продавця, Посада продавця).
Форма – це об'єкт БД, призначений для введення і відображення інформації. Форми дозволяють виконати перевірку коректності даних при введенні, проводити обчислення, забезпечують доступ до даних у зв'язаних таблицях за допомогою підлеглих форм.
Форми надають додаткові можливості роботи з даними БД, дають змогу відображати дані у великій кількості різноманітних форматів. Форми нагадують паперові бланки і часто розробляються для відображення одного запису таблиці даних або запиту на екрані. В формах Access можна відображати дані з кількох пов’язаних між собою таблиць [6].
Використання форм для введення і редагування даних має деякі переваги перед введенням даних в саму таблицю даних. При використанні таблиць даних перегляд всіх полів окремого запису (якщо в ньому багато полів) часто неможливий, а форми дають змогу вибрати зручне розміщення полів на екрані і забезпечити перегляд графічних об’єктів (наприклад, рисунків), що зберігаються в полях об’єкта.
Access дозволяє швидко створювати форми за допомогою майстра форм. Можна також розробляти форми вручну, відкривши пусту форму і перетягнувши об’єкти (наприклад, поля, текст і графіку) в потрібне місце форми. Можна поєднувати автоматизовану і ручну розробку. Наприклад, за допомогою майстра форм можна створити основу форми, а потім відкрити форму в режимі Конструктор форми і внести зміни вручну [6].
Для структурування даних, а також підвищення зручності роботи було розроблено 6 форм: «Головна форма», «Форма для додавання даних», «Додавання даних про автомобіль», «Додавання даних про виробника», «Додавання даних про покупців», «Додавання даних про продавців». Розглянемо детальніше всі перераховані форми, їх призначення та спосіб створення.
«Додавання даних про виробника» – дана форма розроблена вручну за допомогою Конструктора форм. Форма дозволяє користувачу вводити нові дані, а саме записи про нових виробників у таблицю «Виробники». Форма містить наступні елементи: поля для вводу назви та країни виробника, кнопка для додання даних у таблицю.
«Додавання даних про автомобіль» забезпечує введення користувачем даних про автомобіль, який було продано в автосалоні. Форма розроблена вручну за допомогою Конструктора форм. Форма дозволяє вводити дані про автомобіль: марку, колір, дату виготовлення, вартість, дату продажу. Форма містить поля для вводу інформації та кнопку для додання даних у таблицю.
«Додавання даних про покупців» – форма розроблена вручну за допомогою Конструктора форм. Форма передбачає можливість додавання нових даних у таблицю «Покупці», користувач може ввести ПІБ, адресу та паспортні дані покупця.
«Додавання даних про продавців» – передбачає введення нових даних про працівників автосалону: ПІБ продавця, посаду продавця. Форма створена у Конструкторі форм. Дозволяє вводити нові записи у таблицю «Продавці».
Форми «Головна форма» та «Форма для додавання даних» також створені за допомогою Конструктора форм та мають вигляд меню для вибору дій.
«Форма для додавання даних» має наступні кнопки (рис. А.1 додатку А):
Конструктор форми «Форма для додавання даних» зображено на рис. 3.1.
Форма містить наступні елементи: 5 кнопок та напис, також при розробці форми використано тематичне фонове зображення.
Рисунок 3.1 – Конструктор форми «Форма для додавання даних»
«Головна форма» має наступні кнопки (рис. А.2 додатку А):
Для кожної кнопки форм, за винятком «Закрити форму», «Головна форма» та «Форма для додавання даних» створено макрос для виклику відповідних форм та звітів. Було створено наступні макроси: макрос «Додавання продавця», макрос «Додавання виробника», макрос «Додавання покупця», макрос «Додавання автомобіля», макрос «Дохід за день», макрос «Завершені продажі», макрос «Запит за маркою», макрос «Продані автомобілі за вказаний період». На рис. 3.2 показано режим Конструктора макросу «Додавання автомобілів».
Рисунок 3.2 – Макрос «Додавання автомобілів»
Отже, для полегшення роботи над базою даних було розроблено чотири форми, які дозволяють додавати нові дані у всі таблиці. Також розроблено зручні головні форми, які дозволяють викликати форми додання даних, а також запити. Усі описані вище форми показано у додатку А, схема даних бази даних «Автосалон» наведена в додатку Д.
Запити – це гнучкий і зручний засіб доступу до даних, важливою властивістю якого є те, що при створенні результуючої таблиці можна не тільки вибирати інформацію з бази, але й обробляти її.
При роботі запиту дані можуть упорядковуватися (сортуватися), фільтруватися (відсіюватися), об'єднуватися, розділятися, змінюватися, і при цьому ніяких змін у базових таблицях може не відбуватися [6].
В Access для побудови запиту до БД використовується метод QBE (query-by-example – запит за зразком) – метод створення запитів, винайдений IBM ще в 1970-ті роки. Запити забезпечують простий доступ до визначеної підмножини полів і записів однієї або кількох таблиць.
Запит-вибірка – запит, який вибирає потрібні дані, а результати вибірки відтворює у формі динамічного набору. Даний запит зовні схожий на таблицю, але фактично є динамічним (або віртуальним) набором записів, побудованим за структурою запиту. Записів у динамічному наборі фактично не існує, тому, коли цей набір стає не активним, записи зникають (однак дані, на яких був побудований набір, залишаються у вихідних таблицях). Запит можна зберегти, але дані, що відтворюються під час його виконання, в ньому не зберігаються. При збереженні запиту у вигляді оператора SQL зберігається тільки структура запиту [6].
Запити на зміну змінюють дані в таблицях відповідно до умов, визначених у самому запиті. Ці запити звичайно використовуються для внесення великої кількості змін в БД.
Під час розробки бази даних «Автосалон» розроблено наступні запити: «Автомобілі за маркою», «Дохід за вказаний день», «Завершені продажі», «Продані автомобілі за вказаний період».
Один з вище наведених запитів розроблено з використанням QBE-запиту та три запити розроблено з використанням SQL-інструкцій. Використання SQL-інструкцій допомагає розробити складні, багатофункціональні запити, в яких можлива фільтрація даних за кількома параметрами, а також виконання елементарних математичних операцій: знаходження суми, різниці параметрів, які знаходяться у різних таблицях.
Запит «Автомобілі за маркою» вимагає від користувача ввести назву марки автомобіля у відповідне поле і натиснути клавішу виконання запиту. Після перерахованих дій запит виконує вибірку в таблиці «Автомобілі» та виводить на екран всі автомобілі заданої марки. Запит створено за допомогою конструктора запитів з використанням QBE-запиту. Створено відповідний зв'язок між таблицями Автомобілі та Виробники (рис. 4.1) та обрано поля, які будуть виводитись на екран при виконанні запиту.
Рисунок 4.1 – Конструктор запиту «Автомобілі за маркою»
Запит «Дохід за вказаний день» дозволяє виводити на екран суму проданих за вказаний користувачем день автомобілів. Запит створено за допомогою інструкцій SQL. Вікно конструктора запиту із SQL-кодом зображено на рис. 4.2.
Рисунок 4.2 – SQL-код запиту «Дохід за вказаний день»
Запит «Завершені продажі» вимагає від користувача ввести ПІБ продавця, початкову, кінцеву дату та виводить на екран дані про всі завершені успішні продажі продавця за певний період. Запит створено за допомогою конструктора запитів з використанням інструкцій SQL:
SELECT Продавці.[ПІБ продавця], Продавці.[Посада продавця], Покупці.[ПІБ покупця], Автомобілі.[Марка Автомобіля], Автомобілі.[Вартість автомобіля], Автомобілі.[Дата продажу]
FROM Покупці INNER JOIN (Продавці INNER JOIN Автомобілі ON Продавці.[Код продавця] = Автомобілі.[Код продавця]) ON Покупці.[Код покупця] = Автомобілі.[Код покупця]
WHERE (((Продавці.[ПІБ продавця])=[Введіть ПІБ продавця] AND (Автомобілі.[Дата продажу])>=[Введіть початкову дату] And (Автомобілі.[Дата продажу])<=[Введіть кінцеву дату] ));
Результат роботи запиту для продавця ПІБ якого: Іванов Іван Іванович за період з 01.09.2013 по 01.12.2013 показано на рис. 4.3.
Рисунок 4.3 – Демонстрація роботи запиту «Завершені продажі»
Запит «Продані автомобілі за вказаний період» дозволяє виводити на екран дані про всі продані автомобілі за певний термін. Користувач повинен ввести початкову та кінцеву дату терміну, який його цікавить.
Запит створено за допомогою інструкцій SQL:
SELECT Автомобілі.[Дата продажу], Автомобілі.[Марка Автомобіля], Автомобілі.[Колір автомобіля], Автомобілі.[Вартість автомобіля],
Покупці.[ПІБ покупця], Покупці.[Паспорт], Продавці.[ПІБ продавця]
FROM Продавці INNER JOIN (Покупці INNER JOIN Автомобілі ON Покупці.[Код покупця]=Автомобілі.[Код покупця]) ON Продавці.[Код продавця]=Автомобілі.[Код продавця]
WHERE (((Автомобілі.[Дата продажу])>=[Введіть початкову дату] And (Автомобілі.[Дата продажу])<=[Введіть кінцеву дату]));
В результаті виконання курсової роботи було розроблено запити: «Автомобілі за маркою», «Дохід за вказаний день», «Завершені продажі», «Продані автомобілі за вказаний період». Запити «Дохід за вказаний день» та «Продані автомобілі за вказаний період» створені за допомогою інструкцій SQL. Запити «Автомобілі за маркою» та «Завершені продажі», розроблено з використанням QBE-запиту. Усі запити показано у додатку В, усі розроблені таблиці подано у додатку Б.
Звіти в Access використовуються для подання підсумкової інформації у вигляді, сформованому користувачем.
Форми призначені для інтерактивного використання, тоді як звіти – для відтворення або друкування окремих і підсумкових значень для груп записів; введення даних та їх редагування виконується тільки у формах [7].
Групові звіти – це звіти, які ще називаються табличними, дані відтворюються за рядками, причому дані кожного поля вміщуються в окрему графу.
Колончаті звіти – всі поля відтворюються в одній графі і вирівнюються по лівому краю. Звіти дуже схожі на форми, але вони використовуються тільки для відтворення або друкування даних, а не для їх введення і редагування [7].
Поштові наклейки – ці звіти використовуються для друкування поштових наклейок (тобто поштових адрес тих, кому адресована пошта). В Access передбачена функція Майстер звіту, призначена спеціально для створення поштових наклейок в найрізноманітніших форматах.
У курсовій роботі розроблено наступні звіти: «Автомобілі за ціною» та «Покупці».
Звіт «Автомобілі за ціною» виводить на екран інформацію про всі продані автомобілі. Звіт створено за допомогою Майстра звітів, який також дозволяє виводити дані з використанням функцій сортування, у даному звіті автомобілі сортуються за ціною: від меншої до найбільшої. Режим конструктора звіту зображено на рис. 5.1. Звіт виводить на екран наступну інформацію: вартість автомобіля, номер автомобіля, колір автомобіля, дата виготовлення і дата продажу автомобіля.
Рисунок 5.1 – Конструктор звіту «Автомобілі за ціною»
Звіт «Покупці» виводить на екран інформацію про всіх покупців автосалону. Звіт створено за допомогою Майстра звітів. Звіт виводить на екран наступну інформацію: ПІБ, адресу та паспортні дані всіх покупців (рис. 5.2).
Рисунок 5.2 – Конструктор звіту «Покупці»
Отже, за допомогою Майстра звітів було створено наступні звіти: «Автомобілі за ціною» та «Покупці», передбачено перегляд звіту на екрані або друк звіту, друк здійснюється при натисненні правою кнопкою миші по назві звіту і виборі з випадаючого списку «Друк». Роботу звітів продемонстровано в додатку Г.
Тестування БД дає можливість виявити переважну більшість критичних місць розроблюваної БД та перевірити всі механізми, що повинні забезпечити цілісність та конфіденційність даних. Воно проводиться не лише під час розробки системи та схеми БД, але також на етапі супроводу, що пояснюється зміною вимоги до системи зі сторони замовника або виявленням помилок в роботі [8].
Основні види тестування БД наводяться нижче.
Тестування логічної схеми даних:
Тестування бази даних на можливості роботи:
Результат тестування спроектованих відношень бази даних «Автосалон»: жодна функціональна залежність не повторюється більш одного разу, не спостерігається надлишковість даних, усі відношення приведено до нормальної форми, декомпозиція проведена коректно.
Результат тестування інформації показав, що усі введені у таблиці дані є коректними, не надлишковими. Зв’язки між таблицями та ключові поля визначено правильно.
Тестування форм показало, що усі форми розробленої бази працюють коректно, підтримується функція додавання даних, також за допомогою головної форми здійснюється запуск усіх наявних запитів.
Розглянемо тестування запитів на прикладі запиту «Завершені продажі». На рис. 6.1 показано вікно запиту, у якому користувач повинен ввести ПІБ продавця, результати продажів якого хоче побачити в результаті виконання запиту.
Рисунок 6.1 – Введення ПІБ продавця
На рисунку 6.2 показано вікно запиту у якому необхідно ввести початкову дату терміну.
Рисунок 6.3 – Введення початкової дати терміну
На рисунку 6.3 показано вікно запиту у якому необхідно ввести кінцеву дату терміну.
Рисунок 6.3 – Введення кінцевої дати терміну
На рисунку 6.4 показано виведення інформації: показано список автомобілів, які було продано у вказаний термін. Всі дані відображаються коректно, отже запит працює правильно.
Рисунок 6.4 – Результат виконання запиту
Тестування звітів показано на прикладі тестування роботи звіту «Автомобілі за ціною». В результаті запуску відповідного звіту на екран виводиться звіт, зображений на рис. 6.5.
Рисунок 6.5 – Виконання звіту «Автомобілі за ціною»
На рис. 6.5 помітно, що на екран виведені усі продані автомобілі, також дані відсортовано в порядку зростання за ціною автомобіля, отже звіт працює коректно.
Отже, у ході тестування роботи бази даних «Автосалон» не було виявлено жодних проблем, усі елементи бази даних працюю коректно, дані нормалізовано, ключові поля та зв’язки розроблено правильно.
У курсовій роботі засобами СКБД MS Access 2010 розроблено базу даних «Автосалон». База даних повністю відповідає вимогам та може бути використана для полегшення роботи автомобільного салону.
У ході виконання курсової роботи виявлено суті та їх атрибути, створено універсальне відношення, проведено розробку ER-моделі предметної області, спроектовано нормалізовані відношення, проведено нормалізацію відношень методом декомпозиції. Усі відношення було приведено до 3НФ, визначено ключові поля та встановлено зв’язки між відношеннями.
Для забезпечення роботи бази даних засобами MS Access 2010 створено таблиці: Автомобілі, Виробники, Продавці, Покупці. База даних містить форми, які дають змогу користувачам додавати нові дані у таблиці та форми, які дозволяють проводити запуск усіх запитів. Форми структурують та полегшують роботу з інформацією, мають зрозумілий користувацький інтерфейс. Запити дозволяють виконувати вибірку за марками автомобілів та за успішними операціями продажу автомобілів продавцями. Створено запит, який дозволяє вирахувати суму доходу автосалону за вказаний день, а також запит який проводить вибірку проданих автомобілів за вказаний користувачем термін. Звіти бази даних надають можливість переглядати інформацію про усіх покупців, а також відсортовану інформацію про продані автомобілі.
Проведене тестування показало, що усі елементи розроблено коректно, усі функції працюють без збоїв.
Була розроблена база даних «Автосалон», яка має зрозумілий інтерфейс та полегшує роботу користувачів.
Форми
Рисунок А.1 – Форма для додавання даних
Рисунок А.2 – Головна форма
Рисунок А.3 – Форма «Додавання даних про автомобіль»
Рисунок А.4 – Форма «Додавання даних про виробника»
Рисунок А.5 – Форма «Додавання даних про покупців»
Рисунок А.6 – Демонстрація коректної роботи форми «Додавання даних про покупців»
Рисунок А.7 – Форма Додавання даних про продавців
Таблиці
Рисунок Б.1 – Таблиця «Автомобілі»
Рисунок Б.2 – Таблиця «Виробники»
Рисунок Б.3 – Таблиця «Покупці»
Рисунок Б.4 – Таблиця «Продавці»
Запити
Рисунок В.1 – Запит «Автомобілі за маркою»
Рисунок В.2 – Демонстрація роботи запиту «Автомобілі за маркою»
Рисунок В.3 – Запит «Дохід за вказаний день»
Рисунок В.4 – Результат виконання запиту «Дохід за вказаний день»
Рисунок В.5 – Перше вікно запиту «Завершені продажі»
Рисунок В.6 – Друге вікно запиту «Завершені продажі»
Рисунок В.7 – Третє вікно запиту «Завершені продажі»
Рисунок В.8 – Перше вікно запиту «Продані автомобілі за вказаний період»
Рисунок В.9 –Друге вікно запиту «Продані автомобілі за вказаний період»
Рисунок В.10 – Результат виконання запиту «Продані автомобілі за вказаний період»
Додаток Г
Звіти
Рисунок Г.1 – Звіт «Автомобілі за ціною»
Рисунок Г.2 – Звіт «Покупці»
Схема даних
Рисунок Д.1 – Схема даних
11ввв
Код виробника
Назва виробника
Країна виробник
Код покупця
ПІБ покупця
Паспорт
Адреса покупця
од автомобіля
Марка автомобіля
Колір автомобіля
Дата виготовлення
Вартість автомобіля
Дата продажу
Код продавця
ПІБ продавця
Посада продавця