МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
Таврійський державний агротехнологічний університет Кафедра “Комп’ютерні науки”
КОМПЛЕКСНА КУРСОВА РОБОТА
з дисципліни «Організація баз даних та знань», «Веб-технології»
(назва дисципліни)
на тему: «Розробка веб-сайту Транспортної компанії»
15ІТК.130.000000ПЗ
Студента 2 курсу 21 КН групи
Спеціальність 122 Комп’ютерні науки
________ Д.О. Акулов
(підпис)
Керівник ___________________ ________
(ініціали та прізвище) (підпис)
Національна шкала: __________
Кількість балів: _____ Оцінка ECTS _____
Члени комісії ________ __________________
(підпис)
________ __________________
(підпис)
________ __________________
(підпис) (ініціали та прізвище)
РЕФЕРАТ
Курсовий проект: 24 сторінки, 4 малюнка, 11 таблиць, 10 джерел.
Об'єкт дослідження: програмний комплекс по автоматизації предметної області.
Метою курсового проекту є набуття практичних умінь при виконанні студентами розробки динамічного веб-сайту зі зберіганням інформації в базі даних.
Висновок: в ході виконання курсової роботи ми набули навичок зі створення та роботи з базою даних SQL в середовищі phpMyAdmin та написанні сайту для цієї БД.
Ключові слова: БД, ТАБЛИЦЯ, МОДЕЛЬ, ВІДНОШЕННЯ, АТРИБУТ, ДАНІ, НОРМАЛІЗАЦІЯ.
ЗМІСТ
ВИСНОВКИ 23
СПИСОК ЛІТЕРАТУРИ 24
Вступ
Завданням курсового проекту є створення бази даних «Транспортної компанії», автоматизація предметної області, поповнення, редагування, перегляд і аналіз даних предметної області, обраної для автоматизації.
В наш час Інтернет - це одне з найбільш важливих засобів масової інформації та комунікації, яке знаходиться за своєю значимістю в одному ряду з пресою, телефоном і телебаченням. Починаючи з 1969 року, світова мережа - Інтернет стрімко розвивалася, в наш час перетворилася в один з основних засобів, що використовуються для спілкування, розваг, реклами, торгівлі і джерело різноманітної корисної інформації для будь-якої категорії користувачів. Швидко зростає кількість видань, присвячених мережі Інтернет, що віщує широке її розповсюдження навіть у далекі від техніки областях.
На сьогоднішній день будь-яка людина, у якого є комп'ютер, може завантажити з його допомогою новини, ілюстрації, відео - або аудіо інформацію за якою цікавій для його темі. Він може отримувати цю інформацію тоді, коли він цього забажає.
Створення Web-сайту - це для будь-якої компанії комерційна необхідність і умова виживання. При такій швидкості розвитку Інтернету, жодна компанія, яка поставила перед собою мету поступального розвитку, не зможе обійтися без сайту. Інтернет зараз - це найпопулярніший засіб масової інформації, а створення сайтів - серйозний інструмент вирішення маркетингових стратегій, здатних дієво і найбільш ефективно з точки зору фінансової привабливості, технічних можливостей і в рекламних цілях використовувати досягнення світової комп'ютерної мережі.
В якості СУБД використовувався програмний комплекс PhpMyAdmin. Тепер PhpMyAdmin - не просто засіб для створення класичних баз даних. Цей простий інструмент дозволяє швидко створювати веб-додатки для роботи з базами даних.
Метою створення веб-сайту транспортної компанії є розвиток в країні доступних та надійних перевезень, що дозволить компанії розвиватися доволі швидко та бути близько до кожної людини, щоб в будь-який час приїхати та допомогти людині в її потребі перевезення чогось.
АНАЛІЗ ВИМОГ
Постановка завдання
Завдання даної курсової роботи в тому, щоб створити базу даних для сайту транспортної компанії. Перед початком проектування моделей бази даних, треба обумовити, що будь-яка база даних є не лише місцем зберігання всіх даний, а й їх місцем їх обробки. Треба створити таку базу даних, щоб вона була зручна для використання як адміністраторами, так і користувачами. При проектуванні треба врахувати усі можливі види забезпечення безпеки цієї БД та сайту.
Метою курсової роботи є формування теоретичних знань з проектування Web-сайту, роботи з базою даних і практичних навичок по їх розробці.
Об'єктом дослідження є процес розробки сайту.
Розробка моделі варіантів використання веб-сайту
Діаграма варіантів використання (сценаріїв поведінки, прецедентів) є вихідним концептуальним поданням системи в процесі її проектування і розробки. Дана діаграма складається з акторів, варіантів використання і відносин між ними. При побудові діаграми можуть використовуватися також загальні елементи нотації: примітки і механізми розширення.
Суть даної діаграми складається в наступному: проектована система представляється у вигляді безлічі акторів, що взаємодіють з системою за допомогою так званих варіантів використання. При цьому актором називається будь-який об'єкт, суб'єкт або система, що взаємодіє з моделюється системою ззовні. У свою чергу варіант використання - це специфікація сервісів (функцій), які система надає актору. Іншими словами, кожен варіант використання визначає деякий набір дій, що здійснюються системою при взаємодії з актором. При цьому в моделі ніяк не відбивається те, яким чином буде реалізовано цей набір дій.
Рисунок 1.2.1 – Діаграма використання «Транспортна компанія»
Замовник може обрати компанію, яка йому подобається та оформити онлайн заявку на перевезення свого вантажу та передати на обробку цієї заявки до розгляду адміністратору. Після отримання замовлення, адміністратор приступає до обробки та розрахунку вартості, часу витрачених на цей вантаж. Також адміністратор розподілить заявку між перевізниками для виконання замовлення.
Предметна область
Варіанти використання: Подача заявки перевезення
Короткий опис:
Клієнт подає заявку на перевезення вантажу
Головні актори:
Клієнт
Адміністратор
Перевізник
Другорядні актори:
Немає
Передумови:
Клієнт зареєстрований в Системі
Перевізник має обраний клієнтом маршрут
Основний потік:
Варіант використання починається коли Клієнт вводить команду створення нової заявки.
Клієнт вибирає тип вантажу, який йому треба виконати.
Клієнт описує детально вантаж, його напрям та час
Система встановлює поточну дату та час подачі заявки.
Система присвоює заявці статус - "На розгляді".
Пост умови:
Перевізник отримує заявку клієнта на обробку.
Перевізник розраховує найкоротший маршрут та час для перевезення
Альтернативні потоки:
За відсутності у перевізника можливості перевезення за даним маршрутом або відмова від перевезення за деякими причинами, клієнту пропонується альтернатива від іншої компанії, яка має можливість перевезення за тими ж умовами або майже такими.
РОЗРОБКА БАЗИ ДАНИХ
Опис моделі даних
Приклад опису моделі даних інформаційної системи «Транспортна компанія».
Початковий етап – створення текстового опису цієї системи.
ER-модель (Entity-relationship model) – це семантична модель даних, яка призначена для спрощення процесу проектування бази даних. Це представлення бази даних у вигляді наочних графічних діаграм. ER-модель візуалізує процес, який визначає деяку предметну область. З ER-моделі можуть бути породжені всі види баз даних: реляційні, ієрархічні, мережеві, об'єктні. В основі ER-моделі лежать поняття «сутність», «зв'язок» і «атрибут». [5]
Для великих баз даних побудова ER-моделі дозволяє уникнути помилок проектування, які надзвичайно складно виправляти, особливо, якщо база даних вже експлуатується або на стадії тестування. Помилки в розробці структури бази даних можуть привести до переробки коду програмного забезпечення керуючого цією базою даних. В результаті час, кошти і людські ресурси будуть використані неефективно. [4]
Дані про всі перевезення накопичують і зберігаються протягом всього часу існування сайту. Далі вони вже зберігаються на фізичний зовнішній носій або заносяться до хмари. [2]
Рисунок 2.1.1 – Діаграма сутностей і зв’язків
Розглянемо на Рис. 2.1.1 – діаграму бази даних “Транспортна компанія”. Ця діаграма буде в дійсності відповідати кожній таблиці та кожному атрибуту бази даних. При створенні бази даних слід враховувати, що при її створенні треба використовувати латинські символи та рекомендоване кодування UTF8. Для зручності користування треба використовувати короткі назви атрибутів та таблиць.
Для більш докладного розуміння предметної області приведемо приклади даних в реляційних відношеннях.
Таблиця 2.1.1 - Реляційне відношення "clients"
| id_client | last_name | first_name | otchestvo | address | n_phone | bank_acc | passporf |
| 1 | Миронов | Олег | Геннадиевич | ул. Макаренко 50, кв. 6 | 988273279 | 7320966085244586 | O2TSPJSO |
| 2 | Паловчен | Игорь | Викторович | бул. Пива 33/4, 175 | 678389464 | 2031505720146142 | K1XPT98O |
Таблиця 2.1.2 - Реляційне відношення "clients"
| id_car | brand | tonnage | habarites | gos_nomer |
| 1 | 4 | 1 | 1 | AP9999AK |
| 2 | 3 | 2 | 2 | AE2414KK |
Нормалізація реляційних відношень
Схема реляційних відношень повинна відповідати шістьом нормальним формам:
Перша нормальна форма (1НФ);
Друга нормальна форма (2НФ);
Третя нормальна форма (3НФ);
Нормальна форма Бойса-Кодда (БКНФ);
Четверта нормальна форма (4НФ);
П'ята нормальна форма (5НФ).
Відношення знаходяться у 1НФ, тому що не має повторюваних рядків, усі атрибути прості, всі значення скалярні;
Відношення знаходяться у 2НФ, тому що знаходяться у 1НФ, мають первинний ключ, всі атрибути повністю описують первинний ключ;
Відношення знаходяться у 3НФ, тому що знаходяться у 2НФ, не мають залежностей одних не ключових атрибутів від інших;
Відношення знаходяться у БКНФ, тому що знаходяться у 3НФ, відсутні залежності атрибутів первинного ключа від не ключових атрибутів;
Відношення знаходяться у 4НФ, тому що знаходяться у БКНФ, його багатозначні залежності представляються функціональними залежностями від ключа;
Відношення знаходяться в 5НФ, якщо воно знаходиться в 4НФ і відсутні складні залежні з'єднання між атрибутами. [7] Це дуже жорстка вимога, яку можна виконати лише при додаткових умовах. На практиці важко знайти приклад реалізації цієї вимоги в чистому вигляді.
Кожна наступна нормальна форма в деякому розумінні поліпшує властивості попередньої. [1]
Рисунок 2.2.1 – Діаграма сутностей і зв’язків після приведення до 5НФ
Визначення типів даних
Визначення типів даних є дуже важливим на етапі створення бази даних. Неправильно обраний тип даних атрибутів може призвести до порушення роботи користувача з базою даних.
Для атрибутів реляційних відношень необхідно визначити:
Значення типів даних та їхніх розмірів (обов'язкова властивість);
Обов'язковість значення атрибута;
Дублювання значення атрибута;
Значення за замовчуванням.
Рисунок 2.3.1 – Діаграма сутностей і зв'язків з зовнішніми ключами
Таблиця 2.3.1 - Типи даних реляційного відношення "brand_car"
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_brand | int | 15 | первинний |
| name_brand | text | - | обов’язковий |
Таблиця 2.3.2 - Типи даних реляційного відношення "cars"
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_car | int | 15 | первинний |
| brand | int | 15 | зовнішній ключ |
| tonnage | int | 15 | зовнішній ключ |
| habarites | int | 15 | зовнішній ключ |
| gos_nomer | text | - | обов’язковий |
Таблиця 2.3.3 - Типи даних реляційного відношення "clients"
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_client | int | 15 | первинний |
| last_name | text | - | обов’язковий |
| fist_name | text | - | обов’язковий |
| otchestvo | text | - | обов’язковий |
| adress | text | - | обов’язковий |
| n_phone | int | 15 | обов’язковий |
| bank_acc | text | - | обов’язковий |
| passport | text | - | обов’язковий |
Таблиця 2.3.4 - Типи даних реляційного відношення "drivers "
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_driver | int | 15 | первинний |
| last_name | text | - | обов’язковий |
| fist_name | text | - | обов’язковий |
| otchestvo | text | - | обов’язковий |
| prava_nomer | int | 15 | обов’язковий |
| category | text | - | обов’язковий |
| insurance | int | 15 | обов’язковий |
Таблиця 2.3.5 - Типи даних реляційного відношення "habarites "
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_habarite | int | 15 | первинний |
| name_habarite | text | - | обов’язковий |
Таблиця 2.3.6 - Типи даних реляційного відношення " orders "
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_order | int | 15 | первинний |
| id_client | int | 15 | зовнішній ключ |
| type_goods | int | 15 | зовнішній ключ |
| brand | int | 15 | зовнішній ключ |
| tonnage_goods | text | - | обов’язковий |
| habarites_goods | text | - | обов’язковий |
| gos_nomer | text | - | обов’язковий |
| id_driver | int | 15 | зовнішній ключ |
| date | date | - | обов’язковий |
| route | int | 15 | зовнішній ключ |
Таблиця 2.3.7 - Типи даних реляційного відношення "routes "
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_route | int | 15 | первинний |
| name_route | text | - | обов’язковий |
Таблиця 2.3.8 - Типи даних реляційного відношення "tonnage "
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_tonnage | int | 15 | первинний |
| name_tonnage | text | - | обов’язковий |
Таблиця 2.3.9 - Типи даних реляційного відношення "type_goods "
| Атрибут | Тип даних | Розмір | Додаткові обмеження цілісності |
| id_goods | int | 15 | первинний |
| name_goods | text | - | обов’язковий |
Обмеження цілісності даних
Забезпечення цілісності БД складає необхідна умова успішного функціонування БД, особливо при її мережевому використанні.
Цілісність БД - це властивість бази даних, що означає, що в ній міститься повна, несуперечлива і адекватно відображає предметну область інформація. Цілісний стан БД описується за допомогою обмежень цілісності у вигляді умов, яким повинні задовольняти збережені в базі дані.
Цілісність сутностей описується сукупністю обмежень які повинні виконуватися для будь-яких відносин в будь-яких реляційних базах даних.
Підтримка цілісності бази даних може розглядатися як захист даних від невірних змін або руйнувань. Сучасні СКБД мають ряд засобів для забезпечення підтримки цілісності. [3]
Виділяють три групи правил цілісності:
Цілісність по сутностях;
Цілісність по посиланнях;
Цілісність, що визначається користувачем.
Обмеження цілісності між атрибутами:
CONSTRAINT `cars_ibfk_1` FOREIGN KEY (`habarites`) REFERENCES `habarites` (`id_habarite`),
CONSTRAINT `cars_ibfk_2` FOREIGN KEY (`tonnage`) REFERENCES `tonnage` (`id_tonnage`),
CONSTRAINT `cars_ibfk_3` FOREIGN KEY (`brand`) REFERENCES `brand_car` (`id_brand`);
CONSTRAINT `orders_ibfk_1` FOREIGN KEY (`brand`) REFERENCES `brand_car` (`id_brand`),
CONSTRAINT `orders_ibfk_3` FOREIGN KEY (`id_client`) REFERENCES `clients` (`id_client`),
CONSTRAINT `orders_ibfk_4` FOREIGN KEY (`id_driver`) REFERENCES `drivers` (`id_driver`),
CONSTRAINT `orders_ibfk_5` FOREIGN KEY (`route`) REFERENCES `routes` (`id_route`),
CONSTRAINT `orders_ibfk_7` FOREIGN KEY (`type_goods`) REFERENCES `type_goods` (`id_goods`);
Індекси
Одним з найважливіших шляхів досягнення високої продуктивності БД є використання індексів. Індекс прискорює процес запиту, надаючи швидкий доступ до рядків даних в таблиці.
Індекси створюються для стовпців таблиць і представлень. Індекси надають шлях для швидкого пошуку даних на основі значень в цих стовпцях. [3]
Зробимо індекси для тих таблиць, де є потреба в частому та швидкому пошуку:
ALTER TABLE `clients` ADD INDEX( `last_name``, `fist_name`,`otchestvo`);
ALTER TABLE `drivers` ADD INDEX(`last_name`, `fist_name`, `otchestvo`);
ALTER TABLE `orders` ADD INDEX( `id_client`, `id_driver`, `otchestvo`);
Тригери
Тригери є однією з різновидів процедур. Їх виконання відбувається при виконанні для таблиці будь-якого оператора мови маніпулювання даними. Тригери використовуються для перевірки цілісності даних, а також для відкату транзакцій.
Тригер – це відкомпільована SQL-процедура, виконання якої обумовлено настанням певних подій всередині реляційної бази даних. Застосування тригерів здебільшого зручно для користувачів бази даних. І все ж їх використання часто пов'язано з додатковими витратами ресурсів на операції введення/виводу. У тому випадку, коли тих же результатів можна домогтися за допомогою збережених процедур або прикладних програм, застосування тригерів недоцільно.
Тригери - особливий інструмент SQL-сервера, який використовується для підтримки цілісності даних в базі даних. За допомогою обмежень цілісності, правил і значень за замовчуванням не завжди можна домогтися потрібного рівня функціональності. Часто потрібно реалізувати складні алгоритми перевірки даних, що гарантують їх достовірність і реальність. Крім того, іноді необхідно відстежувати зміни значень таблиці, щоб потрібним чином змінити пов'язані дані. Тригери можна розглядати як свого роду фільтри, котрі вступають в дію після виконання всіх операцій відповідно до правил, стандартними значеннями і т.д. [6]
Тригер являє собою спеціальний тип збережених процедур, що запускаються сервером автоматично при спробі зміни даних в таблицях, з якими тригери пов'язані. Кожен тригер прив'язується до конкретної таблиці. Всі вироблені їм модифікації даних розглядаються як одна транзакція. У разі виявлення помилки або порушення цілісності даних відбувається відкат цієї транзакції. Тим самим внесення змін забороняється. Скасовуються також всі зміни, вже зроблені тригером. [6]
Створює тригер тільки власник бази даних. Це обмеження дозволяє уникнути випадкового зміни структури таблиць, способів зв'язку з ними інших об'єктів і т.п.
Тригер являє собою дуже корисне і в той же час небезпечний засіб. Так, при неправильній логіці його роботи можна легко знищити цілу базу даних, тому тригери необхідно дуже ретельно налагоджувати.
На відміну від звичайної підпрограми, тригер виконується неявно в кожному випадку виникнення тригерної події, до того ж він не має аргументів.
Створимо тригер, який при неправильному вводі прізвища в таблицю driver запише повідомлення про помилку
CREATE TRIGGER ln_driver
BEFORE INSERT ON drivers
FOR EACH ROW
when last_name=’’
Set last_name=’ERROR Last Name, CHANGE!’
End
Реалізація SQL-скрипту
Create database ‘Transport_company’ character set utf8 collate utf8_bin.
CREATE TABLE `brand_car` (
`id_brand` int(15) NOT NULL,
`name_brand` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `cars` (
`id_car` int(15) NOT NULL,
`brand` int(15) NOT NULL,
`tonnage` int(15) NOT NULL,
`habarites` int(15) NOT NULL,
`gos_nomer` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `clients` (
`id_client` int(15) NOT NULL,
`last_name` text NOT NULL,
`fist_name` text NOT NULL,
`otchestvo` text NOT NULL,
`adress` text NOT NULL,
`n_phone` int(15) NOT NULL,
`bank_acc` text NOT NULL,
`passport` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `drivers` (
`id_driver` int(15) NOT NULL,
`last_name` text NOT NULL,
`fist_name` text NOT NULL,
`otchestvo` text NOT NULL,
`prava_nomer` int(15) NOT NULL,
`category` text NOT NULL,
`insurance` int(15) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
REATE TABLE `habarites` (
`id_habarite` int(15) NOT NULL,
`name_habarite` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `orders` (
`id_order` int(15) NOT NULL,
`id_client` int(15) NOT NULL,
`type_goods` int(15) NOT NULL,
`brand` int(15) NOT NULL,
`tonnage_goods` text NOT NULL,
`habarites_goods` text NOT NULL,
`gos_nomer` text NOT NULL,
`id_driver` int(15) NOT NULL,
`date` date NOT NULL,
`route` int(15) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `routes` (
`id_route` int(15) NOT NULL,
`name_route` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `tonnage` (
`id_tonnage` int(15) NOT NULL,
`name_tonnage` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `type_goods` (
`id_goods` int(15) NOT NULL,
`name_goods` text NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ALTER TABLE `brand_car`
ADD PRIMARY KEY (`id_brand`),
MODIFY `id_brand` int(15) NOT NULL AUTO_INCREMENT;
ALTER TABLE `cars`
ADD PRIMARY KEY (`id_car`),
MODIFY `id_car` int(15) NOT NULL AUTO_INCREMENT,
ADD KEY `habarites` (`habarites`),
ADD KEY `tonnage` (`tonnage`),
ADD KEY `brand` (`brand`);
ALTER TABLE `clients`
ADD PRIMARY KEY (`id_client`),
MODIFY `id_client` int(15) NOT NULL AUTO_INCREMENT;
ALTER TABLE `drivers`
ADD PRIMARY KEY (`id_driver`),
MODIFY `id_driver` int(15) NOT NULL AUTO_INCREMENT;
ALTER TABLE `habarites`
ADD PRIMARY KEY (`id_habarite`),
MODIFY `id_habarite` int(15) NOT NULL AUTO_INCREMENT;
ALTER TABLE `orders`
ADD PRIMARY KEY (`id_order`),
MODIFY `id_order` int(15) NOT NULL AUTO_INCREMENT,
ADD KEY `brand` (`brand`),
ADD KEY `id_client` (`id_client`),
ADD KEY `id_driver` (`id_driver`),
ADD KEY `route` (`route`),
ADD KEY `type_goods` (`type_goods`);
ALTER TABLE `routes`
ADD PRIMARY KEY (`id_route`),
MODIFY `id_route` int(15) NOT NULL AUTO_INCREMENT;
ALTER TABLE `tonnage`
ADD PRIMARY KEY (`id_tonnage`),
MODIFY `id_tonnage` int(15) NOT NULL AUTO_INCREMENT;
ALTER TABLE `type_goods`
ADD PRIMARY KEY (`id_goods`),
MODIFY `id_goods` int(15) NOT NULL AUTO_INCREMENT;
ВИСНОВКИ
Результатом цієї курсової роботи стала розроблена база даних для сайту «Транспортна компанія», a також розроблений сайт для роботи c базою даних. Вони є актуальними на сьогоднішній день. Сайт допомагає в роботі з клієнтами сайту та обробкою перевезень. В ході виконання даної курсової роботи нами були освоєні основні прийоми створення і роботи з SQL базами даних.
База даних - це сукупність відомостей про реальні об'єкти, процеси, події чи явища, що відносяться до певної теми або завдання, організована таким чином, щоб забезпечити зручне представлення цієї сукупності, як в цілому, так і будь-який її частини. Реляційна база даних являє собою безліч взаємопов'язаних таблиць, кожна з яких містить інформацію про об'єкти певного типу.
В результаті виконання даного курсового проекту були вирішені завдання, поставлені на початку роботи. Була розроблена структура бази даних; в програму були включені функції пошуку, виконання різних запитів. При цьому були враховані всі вимоги, висунуті на початку виконання даного проекту.
База даних була нормалізована за шістьома нормальними формами та була зроблена перевірка. Для неї зроблені тригери задля забезпечення цілісності. Налагоджені зовнішні ключі, зв’язки між таблицями, щоб не виникало проблем при роботі з базою даних. Для максимально швидкого пошуку по таблицям бази даних, де потрібно, заздалегідь були встановлені індекси, за якими виконується швидких пошук серед великої кількості даних.
СПИСОК ЛІТЕРАТУРИ
Введення в реляційні бази даних / В.В. Кирилов, Г.Ю. Громов. - СПб .: БХВ-Петербург, 2012. - 464 c.
Голіцина, О.Л. Бази даних / О.Л. Голіцина, Н.В. Максимов, І.І. Попов. - М .: Форум, 2004. - 352 c.
Белоногов, Г.Г. Автоматизація процесів накопичення, пошуку і узагальнення інформації / Г.Г. Белоногов, А.П. Новосьолов. - М .: Наука, 2017. - 256 c.
Вікіпедія. База даних [Електронний ресурс] – https://uk.wikipedia.org/wiki/База_даних
Ульман, Дж. Основи систем баз даних / Дж. Ульман. - М .: Фінанси і статистика, 2017. - 292 c.
Тригер. База даних [Електронний ресурс] – http://um.co.ua/10/10-7/10-75188.html
Нормалізація відношень. [Електронний ресурс] – https://life-prog.ru/ukr/1_331_normalizatsiya-vidnoshen.html
Сучасний підручник JavaScript [Електронний ресурс] –http://learn.javascript.ru/
Агальцов, В.П. Бази даних. У 2-х т. Т. 2. Розподілені і віддалені бази даних: Підручник / В.П. Агальцов. - М .: ИД ФОРУМ, НДЦ ИНФРА-М, 2013. – 272
Пирогов, В.Ю. Інформаційні системи та бази даних: організація та проектування: Навчальний посібник / В.Ю. Пирогов. - СПб .: БХВ-Петербург, 2009. - 528 c.
Мелітополь – 2019