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

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ВІДОКРЕМЛЕНИЙ СТРУКТУРНИЙ ПІДРОЗДІЛ

ХАРКІВСЬКИЙ КОМП'ЮТЕРНО - ТЕХНОЛОГІЧНИЙ ФАХОВИЙ КОЛЕДЖ НАЦІОНАЛЬНОГО ТЕХНІЧНОГО УНІВЕРСИТЕТУ

«ХАРКІВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ»

Циклова комісія «Комп'ютерних та інформаційних дисциплін»

КУРСОВИЙ ПРОЕКТ

з дисципліни: "Бази даних"

Тема проекту: " Розробка та ведення бази даних «Проектування та розробка БД Кінотеатру»"

М. ХАРКІВ 2023 Р.



РПЗ-320 Спеціальність:121 Інженерія програмного забезпечення Циклова комісія «Комп'ютерних та інформаційних дисциплін» Завдання на курсовий проект студента групи РПЗ - 320 Марченко

Тема: «Проектування та розробка БД. Кінотеатра»

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

Знайомство з літературою та основними проблемами сучасних баз даних
Аналіз вибраної предметної області та розробка системи бізнес правил
Вибір СУБД для реалізації проекту
Постановка задачі (опис ПрО)
Вибір інструментальних засобів для створення моделі проекту
Вибір засобів розробки проекту
2. Вимоги до програмного виробу
Розробка концептуальної моделі даних
Розробка EER - діаграми для заданої ПрО
Реалізація (заповнення) бази даних
Розробка уявлень для відображення результатів вибірки
Розробка збережених процедур
Розробка тригерів для управління даними
Адміністрування та забезпечення безпеки баз даних
3. Етапи виконання проекту
Етапи	Найменування	Термін	Примітки
1.	Розділ І Теоретична частина та вибір теми		02.2022	20%
2.	Розділ ІІ Моделювання даних ПрО		03.2022	30%
3.	Розділ ІІІ Реалізація програмного забезпечення для управління даними		04.2022	40%
4.	Оформлення пояснювальної записки		05.2022	10%
Завдання видано 25.01.2023 Термін захисту курсового проекту - травень 2023р.
Заступник з навчальної роботи Голова циклової комісії Керівник курсового проекту		Ігнатенко О. Коломієць П. Тищенко І.



Реферат

Ключові слова: БАЗА ДАНИХ, СУБД, MySQL, СЕРВЕР, КЛІЄНТ, ГРАФІЧНИЙ КЛІЄНТ, ТАБЛИЦЯ, ПОЛЕ, ІНДЕКСИ, ПЕРВИННИЙ КЛЮЧ, ЗОВНІШНІЙ КЛЮЧ, SQL, ПРОЦЕДУРИ, ЩО ЗБЕРІГАЮТЬСЯ, УЯВИ, МОДЕЛІ ДАНИХ, НОРМАЛІЗАЦІЯ, ЦІЛІСНІСТЬ, СКРИПТ, ТРИГЕРИ

Об'єктом дослідження являються реляційні бази даних, які зберігаються на сервері MySQL. У якості клієнта, для спрощення роботи з базою даних вибраний графічний клієнт MySQL Workbench.

Мета роботи - розробка проекту «клієнт-серверного» додатку “БД Кінотеатру”, який гарантує дотримання обмежень цілісності, виконує оновлення даних, виконує запити і повертає результати клієнту.

Для додатку “БД Кінотеатру” розроблені моделі даних, зокрема: концептуальна, логічна та фізична. Реалізовані прості та складні запити до бази даних, процедури, що зберігаються, уяви, тригери.

Даний проект розроблений на ПК з використанням серверу MySQL та локального клієнта MySQL Workbench.

Cтворена резервна копія бази даних для використання її у різних випадках, тобто переносі бази даних на інший комп'ютер, використання створених скриптів та інше.

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



Essay

Klyuchovі words: DATABASE, DBMS, MySQL, SERVER, CLIENT, GRAPHICAL CLIENT, TABLE, FIELD, INDEXES, PRIMARY KEY, FOREIGN KEY, SQL, STORED PROCEDURES, VIEWS, DATA MODELS, NORMALIZATION, INTEGRITY, SCRIPT, TRIGGER.

The object of the study are relational databases stored on the MySQL server. As a client, the MySQL Workbench graphical client was chosen to simplify work with the database.

The purpose of the work is to develop a client-server project of the Cinema Database application, which guarantees compliance with integrity restrictions, performs data updates, executes requests and returns results to the client.

Data models have been developed for the "Cinema Database" application, in particular: conceptual, logical, and physical. Implemented simple and complex database queries, stored procedures, imaginations, triggers.

This project was developed on a PC using the MySQL server and the local MySQL Workbench client.

A backup copy of the database was created for use in various cases, i.e., transferring the database to another computer, using created scripts, etc.

The developed application allows the database administrator to obtain informational help on the issues that interest him in a short period of time with satisfactory quality.



Зміст

база дані додаток система

Перелік умовних позначень

Вступ

1. Реляційні бази даних, основні принципи та сфери використання

1.1 Історія розробки СУБД для роботи із базами даних

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

1.3 Будування SQL запитів до БД

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

2. Проектування бази даних для ПО «Кінотеатр»

2.1 Розробка бізнес-правил для ПО

2.2 Нормалізація ER-моделі

2.3 Логічна модель бази даних

2.4 Середовище розробки

3. Проектування та розробка БД для предметної області

3.1 Створення запитів

3.2 Створення тригерів

Висновки

Перелік посилань

Додаток А

Додаток Б



Перелік умовних позначень

БД - база даних

БП - бізнес правила

СУБД, OODM - середовище керування базами даних

ПК - первісний ключ

ВК - зовнішній ключ



Вступ

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

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

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

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

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



1. Реляційні бази даних, основні принципи та сфери використання

1.1 Історія розробки СУБД для роботи із базами даних

Оскільки комп'ютери набирають популярність і стають економічно ефективними для використання приватними компаніями для збільшення обсягу зберігання даних, 60-і та середина 60-х років можна розглядати як новий напрямок у сфері баз даних (DuCharme, 2012). Введення терміну «база даних» збіглося з доступністю сховища з прямим доступом (диски та барабани) з середини 1960-х років. Цей термін представляв контраст із системами на основі стрічки минулого, дозволяючи спільне інтерактивне використання, а не щоденну пакетну обробку. Було розроблено дві основні моделі даних - мережева модель CODASYL (Conference on Data System Language) та ієрархічна модель IMS (Information Management System). Перше покоління систем баз даних було навігаційним. Програми зазвичай отримували доступ до даних, переходячи за вказівниками від одного запису до іншого. Деталі зберігання залежать від типу даних, які будуть зберігатися. Таким чином, для додавання додаткового поля до бази даних потрібно переписати базову схему доступу/модифікації. Акцент робився на записах, які підлягають обробці, а не на загальній структурі системи. Користувачеві потрібно знати фізичну структуру бази даних, щоб отримати інформацію. Однією з баз даних, яка виявилася комерційно успішною, була система SABRE, яка використовувалася IBM, щоб допомогти American Airlines [1] керувати даними про бронювання (Bercich, 2002). Ця система досі використовується основними туристичними службами для своїх систем бронювання.

Комерціалізація реляційних систем починається, коли бум купівлі комп'ютерів підживлює ринок БД (баз даних) для бізнесу. SQL (Structured Query Language) став міжгалактичним стандартом (Taylor, 2007). DB2 стала основним продуктом IBM. Мережні та ієрархічні моделі втратили свій шарм без подальшого розвитку цих систем, але деякі застарілі системи все ще використовуються сьогодні. Розробка ПК IBM породила багато компаній і продуктів DB, таких як RIM, RBASE 5000, PARADOX, OS/2 Database Manager, Dbase III, IV (пізніше FoxBASE і Visual FoxPRO) і Watcom SQL. Усі ці системи були представлені в 1980-х роках і базувалися на реляційній моделі. У цей період була розроблена концепція об'єктно-орієнтованої бази даних. Термін «об'єктно-орієнтована система баз даних» вперше з'явився приблизно в 1985 році. Об'єктна база даних, також об'єктно-орієнтована система управління базами даних, -- це та, в якій інформація представлена у формі об'єктів, що використовуються в об'єктно-орієнтованому програмуванні (Хааді, 2010). Об'єктні бази даних відрізняються від реляційних і належать до більш широкої системи управління базами даних. Основне використання об'єктної бази даних - об'єктно-орієнтовані області. Деякі об'єктно-орієнтовані бази даних розроблені для роботи з об'єктно-орієнтованими мовами програмування, такими як Delphi, Ruby, Python, Perl, Java, C# і Visual Basic.NET, C - - , Objective-C і Smalltalk. Інші мають власні мови програмування. OODBMS (об'єктно-орієнтована система управління базами даних) використовує точно таку ж модель, що й об'єктно-орієнтовані мови програмування. OODBMS підтримує моделювання та створення даних як об'єктів. OODBMS може ефективно керувати великою кількістю різних типів даних. Об'єкти зі складною поведінкою легко обробляти за допомогою успадкування та поліморфізму. Це також допомогло зменшити велику кількість зв'язків шляхом створення об'єктів. Найбільшою проблемою з OODBMS було перемикання існуючої бази даних на OODBMS, оскільки перехід вимагає повної зміни з нуля і, як правило, прив'язаний до певної мови програмування та API (інтерфейсу прикладного програмування), що знижує гнучкість бази даних. Щоб подолати проблеми OODBMS[2] та повною мірою скористатися перевагами реляційної та об'єктно-орієнтованої моделі, на початку 1990-х років була розроблена модель об'єктно-реляційної бази даних.

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

Використання єдиного OODM під час усього процесу проектування дозволяє будувати дизайн бібліотеки. Завдяки підтримці абстрактних часткових проектів компоненти таких бібліотек може бути більш загальним, ніж зазвичай припускають, але багаторазове використання цього не має передбачають повторне використання. Ми повинні підтримувати механізми для отримання максимальної кількості наявних для повторного використання компоненти бібліотеки для даного часткового дизайну. Це призводить до концепції повторного використання на основі варіацій, що розширює результати побудови варіантів у семантичних мережах[3].

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

Значення можна згрупувати за типами. Загалом, тип можна розглядати як незмінний набір значень однорідної структури разом з операціями, визначеними на таких цінності. Підтипи використовуються для зв'язку значень у різних типах. Концепція класу передбачає групування об'єктів, що мають однакову структуру, яка однорідно поєднує аспекти значення об'єкта та посилання. Об'єкти можуть належати до різних класів, що гарантує кожен об'єкт нашої абстрактної моделі об'єкта буде охоплений колекцією можливих класи. Що стосується значень, які визначаються лише через типи, об'єкти можуть бути визначені лише через класи. Таким чином, дизайн складається з визначення типу та класу[4].

Структурний вираз класу в схемі OODM може містити параметри. Вони виникають із параметризованих типів. Параметризовані класи дозволяють абстрагуватися від бетонних конструкцій. Дійсно, екземпляр параметризованого класу може розглядатися не як окремий набір пар, а як сімейство цих пар, індексованих можливим екземпляри. Давайте тепер поширимо та конкретизуємо це уявлення до довільних схем. Якщо ми знаємо, що об'єкти будуть мати деякі атрибути, але ми все ще не знаємо тип з відповідних значень, ми можемо залишити відповідний параметр невиявленим. Однак, якщо ми вже знаємо, що ми створимо цей параметр певним типом, ми можемо позначити цей параметр як параметр типу. Якщо ми знаємо, що такі будуть посилання Ci[5], але Ci невизначено, тоді ми маємо параметр класу. Для параметризованих класів є можливості визначення методів та обмежень обмежено. If є параметром типу, і ми нічого не знаємо про тип немає нетривіального способу виразити термін такого типу, але терміни є обов'язковими завдання, а також в обмеженнях. Проте ми можемо частково знати про це типу, напр. що це підтип якогось іншого типу, і в цьому випадку ми можемо використовувати терміни цей супертип.

Якщо C є параметром класу, то кожен виклик методу m на C дійсно невизначений.

Тому для доказу властивостей методу[6], що викликає, наприклад узгодженості, ми маємо лише можливість припустити довільне відношення введення-виведення для m, якщо ми не будемо повністю відкласти доведення.

1.3 Будування SQL запитів до БД

Для мене найкраща частина копання даних -- це не передумови збирання, завантаження чи очищення даних, але коли я справді доберусь опитування даних. Це ті моменти, коли я виявляю, чи є дані чисті чи брудні, чи вони повні, і, головне, яка історія дані можуть сказати. Подумайте про опитування даних як про процес, подібний до співбесіда з людиною, яка претендує на роботу. Ви хочете задати такі запитання виявити, чи відповідає реальність їхнього досвіду їхньому резюме. Інтерв'ю - це захоплююче, тому що ти відкриваєш істину. Наприклад, ви може виявитися, що половина респондентів забули заповнити поле електронної пошти анкети, або мер не сплачував податок на нерухомість за минуле п'ять років. Або ви можете дізнатися, що ваші дані брудні: імена написані непослідовно, дати неправильні або цифри не співпадають з вашими очікування. Ваші висновки стають частиною історії даних. У SQL опитування даних починається з ключового слова SELECT, яке витягує рядки та стовпці з однієї чи кількох таблиць у базі даних. Оператор SELECT може бути простим, отримувати все в одній таблиці, або він може бути досить складним, щоб зв'язати десятки таблиць при обробці кількох розрахунки та фільтрація за точними критеріями.

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

Іноді вам потрібно обмежити рядки, які повертає запит, лише тими, у яких є який один або кілька стовпців відповідають певним критеріям. Використання вчителів як Наприклад, ви можете знайти всіх вчителів, найнятих до певного року або всі вчителі, які заробляють понад 75 000 доларів США в початкових школах. Для цих завданнях ми використовуємо речення WHERE. Ключове слово WHERE дозволяє знайти рядки, які відповідають певному значенню, діапазон значень або кілька значень на основі критеріїв, що надаються через an оператор. Ви також можете виключити рядки на основі критеріїв.

Ви можете почати бачити, як навіть попередні прості запити дозволяють нам це зробити гнучко й точно вникайте в наші дані, щоб знайти те, що ми є шукаю. Ви можете об'єднати оператори оператора порівняння за допомогою Ключові слова І та АБО, щоб забезпечити декілька критеріїв для фільтрації, і ви можете включити речення ORDER BY для ранжирування результатів. Маючи на увазі попередню інформацію, давайте об'єднаємо поняття у цьому розділі в одне твердження, щоб показати, як вони поєднуються.

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

Постановка задачі курсового проекту бази даних кінотеатру може включати наступне:

1. Опис функцій, які має виконувати система бази даних кінотеатру. Наприклад, управління фільмами, сеансами, кінозалами, клієнтами, бронюваннями та іншими сутностями.

2. Розробка схеми бази даних кінотеатру, що включає всі необхідні таблиці, поля, зв'язки та інші відомості про базу даних.

3. Розробка діаграми ER (Entity-Relationship), яка зображає відносини між таблицями бази даних.

4. Розробка SQL-запитів для вставки, оновлення та видалення даних з таблиць бази даних.

5. Розробка SQL-запитів для запитів даних з таблиць бази даних, таких як вибірка даних про фільми, сеанси, клієнтів, бронювання, і т.д.

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

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

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

9. Розробка документації проекту, яка включає опис функцій, схему бази даних, ER-діаграму, SQL-запити, інтерфейс користувача та інші відомості про проект.

2. Проектування бази даних для ПО «Кінотеатр»

2.1 Розробка бізнес-правил для ПО

Розробка бізнес-правил для ПО бази даних кінотеатру є дуже важливою складовою процесу розробки ПО. Деякі можливі бізнес-правила, які можуть бути використані в цьому випадку, включають:

1. Назви фільмів мають бути унікальними.

2. Фільми можуть бути додані тільки директором кінотеатру.

3. Фільми можуть бути видалені тільки директором кінотеатру.

4. Сеанси повинні бути заплановані заздалегідь.

5. При зміні часу сеансу, користувач повинен бути повідомлений.

6. Кінозал повинен бути заброньований заздалегідь.

7. Кількість місць в кінозалі повинна відповідати кількості місць у квитках.

8. Клієнти повинні мати можливість бронювати квитки тільки на доступні сеанси та кількість місць.

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

10. Клієнти повинні мати можливість змінити кількість квитків під час бронювання.

11. За кожен проданий квиток повинна збільшуватись загальна кількість проданих квитків.

12. Кількість доступних квитків не може бути більше кількості місць у кінозалі.

13. Кінотеатр повинен забезпечувати відповідний рівень безпеки даних клієнтів та бронювання.

14. Доступ до бази даних повинен бути обмежений та контрольований, щоб забезпечити захист від несанкціонованого доступу до даних.

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

2.2 Нормалізація ER-моделі

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

В ER-моделі кінотеатру можна виділити наступні таблиці:

1. movie (movie_id, title, release_year, genre, director) - ця таблиця містить інформацію про фільми, які доступні в кінотеатрі.

2. screening (screening_id, movie_id, start_time, theater_num) - ця таблиця містить інформацію про сеанси фільмів, включаючи дату та час початку, а також номер залу, в якому відбувається показ.

3. theater (theater_num, capacity, location) - ця таблиця містить інформацію про кінозали, включаючи їх вмістимість та розташування.

4. customer (customer_id, name, email, phone_number) - ця таблиця містить інформацію про клієнтів, які здійснюють бронювання та придбання квитків.

5. booking (booking_id, customer_id, screening_id, num_tickets, total_cost) - ця таблиця містить інформацію про бронювання квитків, включаючи кількість квитків та загальну вартість.

Для нормалізації ER-моделі можна застосувати наступні кроки:

· Перша нормальна форма (1НФ) - кожна клітинка в таблиці повинна містити тільки атомарні значення. Це означає, що жоден рядок не може містити масиви значень або інші таблиці.

· Друга нормальна форма (2НФ) - кожна таблиця повинна містити тільки дані, які пов'язані з первинним ключем таблиці.

· Третя нормальна форма (3НФ) - кожна колонка таблиці повинна залежати тільки від первинного ключа таблиці, а не від інших неключових полів.

· Четверта нормальна форма (4НФ) - уникнення залежностей між неключовими полями.

· П'ята нормальна форма (5НФ) - уникнення повторювання інформації шляхом виділення спільних зв'язків в окремі таблиці.

Залежно від конкретної моделі даних можуть застосовуватися додаткові кроки нормалізації, такі як нормалізація до шостої нормальної форми (6НФ) або застосування правил Бойса-Кодда.

2.3 Логічна модель бази даних

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

Логічна модель бази даних для кінотеатру може виглядати наступним чином:

Таблиця "Movie"

· movie_id (INT, PRIMARY KEY)

· title (VARCHAR(255), NOT NULL)

· release_year (INT, NOT NULL)

· genre (VARCHAR(255), NOT NULL)

· director (VARCHAR(255), NOT NULL)

Таблиця "Screening"

· screening_id (INT, PRIMARY KEY)

· movie_id (INT, FOREIGN KEY REFERENCES Movie(movie_id))

· start_time (DATETIME, NOT NULL)

· theater_num (INT, NOT NULL)

Таблиця "Theater"

· theater_num (INT, PRIMARY KEY)

· capacity (INT, NOT NULL)

· location (VARCHAR(255), NOT NULL)

Таблиця "Customer"

· customer_id (INT, PRIMARY KEY)

· name (VARCHAR(255), NOT NULL)

· email (VARCHAR(255), NOT NULL)

· phone_number (VARCHAR(20), NOT NULL)

Таблиця "Booking"

· booking_id (INT, PRIMARY KEY)

· customer_id (INT, FOREIGN KEY REFERENCES Customer(customer_id))

· screening_id (INT, FOREIGN KEY REFERENCES Screening(screening_id))

· num_tickets (INT, NOT NULL)

· total_cost (DECIMAL(10,2), NOT NULL)

Ця логічна модель містить п'ять таблиць, які відповідають сутностям, описаним у постановці задачі та ER-моделі. Кожна таблиця містить відповідні поля та зв'язки між ними за допомогою первинних та зовнішніх ключів (рис 2.1.).



Рисунок 2.1 Розробка ER-моделі

2.4 Середовище розробки

MySQL - це реляційна система управління базами даних, яка підтримує мову запитів SQL. Ця система відкрита для використання та підтримується спільнотою розробників. MySQL підтримує багато операційних систем, таких як Windows, Linux, macOS та інші.

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

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

MySQL Workbench - це інтегроване середовище розробки для баз даних MySQL. Це безкоштовний та відкритий інструмент, який надає можливість проектування, розробки та адміністрування баз даних MySQL.

MySQL Workbench містить наступні компоненти:

· Моделювання та проектування баз даних за допомогою візуального інтерфейсу;

· Редактор SQL, що дозволяє створювати та виконувати SQL-запити;

· Адміністрування сервера баз даних;

· Автоматизовані засоби резервного копіювання та відновлення баз даних;

· Моніторинг та оптимізація продуктивності баз даних.

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

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

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

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



3. Проектування та розробка БД для предметної області

Для проектування та розробки БД кінотеатру, ми можемо використовувати наступний план:

1. Визначення вимог до системи:

i. Яка інформація повинна бути збережена в базі даних? Які операції повинні бути виконані над цією інформацією?

ii. Аналіз вимог та моделювання

iii. Створення моделі концептуальної (відносинної) БД

iv. Створення моделі логічної БД

v. Створення моделі фізичної БД Розробка та реалізація

vi. Створення бази даних за моделлю фізичної БД

vii. Реалізація запитів, збережених процедур, функцій та індексів

viii. Розробка програмного забезпечення для роботи з базою даних

2. Тестування та впровадження:

i. Тестування правильності та ефективності розробленої БД

ii. Впровадження БД та програмного забезпечення в експлуатацію

iii. Підтримка та розвиток

iv. Підтримка та оновлення бази даних та програмного забезпечення

v. Розвиток БД для задоволення нових вимог користувачів.

Основні сутності, які повинні бути у базі даних кінотеатру: Фільми (назва, рік випуску, жанр, режисер, тривалість) Сеанси (фільм, дата та час початку, номер залу) Зали (номер залу, кількість місць, місцезнаходження) Клієнти (ім'я, електронна пошта, номер телефону) Бронювання (клієнт, сеанс, кількість квитків, вартість)

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

Також можна створити додаткові таблиці для додаткової інформації, наприклад, таблицю "Ряди" та "Місця", які відображатимуть розташування місць у залі, або таблицю "Знижки", яка буде містити інформацію про різні види знижок на квитки.

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

3.1 Створення запитів

Запити MySQL - це команди, які використовуються для маніпулювання даними в базі даних MySQL. Запити MySQL можуть використовуватися для створення, оновлення, видалення і отримання даних з таблиць бази даних.

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

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

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

Отримати список фільмів, які будуть показуватися в конкретний день:

SELECT movie.title, screening.start_time, theater.location

FROM movie

JOIN screening ON movie.movie_id = screening.movie_id

JOIN theater ON screening.theater_num = theater.theater_num

WHERE DATE(screening.start_time) = '2023-05-01';

Отримати список клієнтів, які здійснили бронювання на певний фільм:

SELECT customer.name, customer.email, customer.phone_number, booking.num_tickets, booking.total_cost

FROM customer

JOIN booking ON customer.customer_id = booking.customer_id

JOIN screening ON booking.screening_id = screening.screening_id

JOIN movie ON screening.movie_id = movie.movie_id

WHERE movie.title = 'Avengers: Endgame';

Отримати список фільмів, які показувалися в певному залі в останні 7 днів:

SELECT movie.title, screening.start_time, screening.theater_num

FROM movie

JOIN screening ON movie.movie_id = screening.movie_id

WHERE screening.theater_num = 1 AND screening.start_time >= DATE_SUB(NOW(), INTERVAL 7 DAY);

Отримати список залів з їхньою місткістю та загальною кількістю проданих квитків за певний період часу:

SELECT theater.theater_num, theater.capacity, SUM(booking.num_tickets) AS total_tickets

FROM theater

JOIN screening ON theater.theater_num = screening.theater_num

JOIN booking ON screening.screening_id = booking.screening_id

WHERE screening.start_time BETWEEN '2023-04-01' AND '2023-04-30'

GROUP BY theater.theater_num;



3.2 Створення тригерів

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

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

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

Таким чином, тригери є потужним інструментом для автоматизації обробки даних і забезпечення цілісності бази даних в MySQL.

Нижче наведено приклади створення тригерів для бази даних кінотеатру:

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

CREATE TRIGGER update_available_seats

AFTER INSERT ON booking

FOR EACH ROW

UPDATE theater t

SET t.capacity = t.capacity - NEW.num_tickets

WHERE t.theater_num = (SELECT s.theater_num FROM screening s WHERE s.screening_id = NEW.screening_id);

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

CREATE TRIGGER check_available_seats

BEFORE INSERT ON booking

FOR EACH ROW

BEGIN

DECLARE available_seats INT;

SELECT (t.capacity - COALESCE(SUM(b.num_tickets), 0)) INTO available_seats

FROM theater t

LEFT JOIN screening s ON t.theater_num = s.theater_num

LEFT JOIN booking b ON s.screening_id = b.screening_id

WHERE s.screening_id = NEW.screening_id;

IF NEW.num_tickets > available_seats THEN

SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Not enough available seats';

END IF;

END;

Тригер для підрахунку вартості бронювання після додавання нового запису у таблицю бронювань:

CREATE TRIGGER update_booking_cost

BEFORE INSERT ON booking

FOR EACH ROW

SET NEW.total_cost = (SELECT (m.release_year >= YEAR(CURDATE()) - 2) * 10 - 5 * (NEW.num_tickets)

FROM movie m

WHERE m.movie_id = (SELECT s.movie_id FROM screening s WHERE s.screening_id = NEW.screening_id));

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



Висновки

У цій курсовій роботі ми розглянули проектування та розробку бази даних для кінотеатру. Ми визначили сутності, які повинні бути у базі даних кінотеатру, та створили таблиці для кожної з цих сутностей. Далі ми описали процес створення тригерів, які можуть бути корисні для забезпечення цілісності даних у базі даних кінотеатру. Наприкінці, ми навели загальний план проектування та розробки бази даних, який може бути використаний для розробки будь-якої бази даних.

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

Під час розробки інформаційної системи були відпрацьовані навички проектування реляційних баз даних у середовищі ER-Modeler, закріплені навички побудови SQL та DQL запитів, взаємодії проектування реляційних баз даних на базі будування ERмоделі; ознайомилися із середовищем розробки WorkBench.



Перелік посилань

1. Конноллі (2017). Т. Бази даних. Проектування, реалізація та супровід. Теорія і практика, 98-113.

2. Р.Д. Мюллер, М.Лорі (2013). Проектування баз даних та UML, 201-213.

3. Урма, Фуско., Майкрофт (2016). Сучасна мова Java. Лямбда-вирази, потоки та функціональне програмування, 210-311.

4. Kishori Sharan (2013). Learn JavaFX 8: building user experience and interfaces with Java 8, 45-48

5. Н.П. Стружкін, В.В. Годин, Люберци: Юрайт (2016). Н.П. Бази даних:проектування: Підручник для академічного бакалавріату, 18-20

6. Кемпбелл Л., Мейджорс Ч. (2020). Бази даних. Інженерінг надійності, 67-78



Додаток А

DELIMITER //

USE cinema //

CREATE TRIGGER bookings_delete_trigger

AFTER DELETE ON booking

FOR EACH ROW

BEGIN

UPDATE screening

SET available_seats = available_seats - OLD.num_tickets

WHERE screening_id = OLD.screening_id;

END //

DELIMITER ;

DELIMITER //

USE cinema //

CREATE TRIGGER bookings_insert_trigger

AFTER INSERT ON booking

FOR EACH ROW

BEGIN

UPDATE screening

SET available_seats = available_seats - NEW.num_tickets

WHERE screening_id = NEW.screening_id;

END //

DELIMITER ;

CREATE DATABASE cinema;

CREATE TABLE cinema.movie (

movie_id INT PRIMARY KEY,

title VARCHAR(255) NOT NULL,

release_year INT NOT NULL,

genre VARCHAR(255) NOT NULL,

director VARCHAR(255) NOT NULL

);

CREATE TABLE cinema.screening (

screening_id INT PRIMARY KEY,

movie_id INT NOT NULL,

start_time DATETIME NOT NULL,

theater_num INT NOT NULL,

FOREIGN KEY (movie_id) REFERENCES cinema.movie(movie_id)

);

CREATE TABLE cinema.theater (

theater_num INT PRIMARY KEY,

capacity INT NOT NULL,

location VARCHAR(255) NOT NULL

);

CREATE TABLE cinema.customer (

customer_id INT PRIMARY KEY,

name VARCHAR(255) NOT NULL,

email VARCHAR(255) NOT NULL,

phone_number VARCHAR(20) NOT NULL

);

CREATE TABLE cinema.booking (

booking_id INT PRIMARY KEY,

customer_id INT NOT NULL,

screening_id INT NOT NULL,

num_tickets INT NOT NULL,

total_cost DECIMAL(10,2) NOT NULL,

FOREIGN KEY (customer_id) REFERENCES cinema.customer(customer_id),

FOREIGN KEY (screening_id) REFERENCES cinema.screening(screening_id)

);

DELIMITER //

USE cinema //

CREATE PROCEDURE get_available_seats(IN screening_id INT)

BEGIN

SELECT theaters.capacity - SUM(bookings.num_tickets) AS available_seats

FROM screenings

INNER JOIN theaters ON screenings.theater_num = theaters.theater_num

LEFT JOIN bookings ON screenings.screening_id = bookings.screening_id

WHERE screenings.screening_id = screening_id

GROUP BY theaters.capacity;

END //

DELIMITER ;

DELIMITER //

USE cinema //

CREATE PROCEDURE get_customer_bookings(IN customer_id INT)

BEGIN

SELECT bookings.booking_id, movies.title, screenings.start_time, bookings.num_tickets

FROM bookings

INNER JOIN customers ON bookings.customer_id = customers.customer_id

INNER JOIN screenings ON bookings.screening_id = screenings.screening_id

INNER JOIN movies ON screenings.movie_id = movies.movie_id

WHERE customers.customer_id = customer_id;

END //

DELIMITER ;

DELIMITER //

USE cinema //

CREATE PROCEDURE get_movie_info(IN movie_id INT)

BEGIN

SELECT title, release_year, genre, director

FROM movies

WHERE movie_id = movie_id;

END //

DELIMITER ;

DELIMITER //

USE cinema //

CREATE TRIGGER screenings_update_trigger

BEFORE UPDATE ON screening

FOR EACH ROW

BEGIN

DECLARE conflict_count INT;

SELECT COUNT(*) INTO conflict_count

FROM screening

WHERE theater_num = NEW.theater_num

AND screening_id != NEW.screening_id

AND start_time <= NEW.start_time - INTERVAL 2 HOUR

AND start_time - INTERVAL 2 HOUR >= NEW.start_time;

IF conflict_count > 0 THEN

SIGNAL SQLSTATE '45000'

SET MESSAGE_TEXT = 'Screening time conflicts with another screening in the same theater.';

END IF;

END //

DELIMITER ;



Додаток Б

Презентаційний матеріал - 0.0

Презентаційний матеріал - 0.1



Презентаційний матеріал - 0.2

Презентаційний матеріал - 0.3

Презентаційний матеріал - 0.4

Презентаційний матеріал - 0.5

Презентаційний матеріал - 0.6

Презентаційний матеріал - 0.7



Презентаційний матеріал - 0.8

Презентаційний матеріал - 0.9

Презентаційний матеріал - 0.10

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