МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ДЕРЖАВНИЙ ВИЩИЙ НАВЧАЛЬНИЙ ЗАКЛАД
«УЖГОРОДСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ»
Інженерно-технічний факультет
Кафедра комп’ютерних систем та мереж
КУРСОВА РОБОТА
з дисципліни «Організація баз даних»
на тему:
«Організація баз даних в середовищі програми MySQL-Front. Створення бази даних для туристично-готельного комплексу. Підсистема «Робота з клієнтами»»
студента 3-го курсу, групи КІ
Напрям підготовки 6.050102
«Комп’ютерна інженерія»
Товт О.В.
Науковий керівник:
ст. викл. Шпеник Т.Б.
Національна шкала________________
Кількість балів____ Оцінка ECTS____
Члени комісії: ________ ст. викл. Шпеник Т.Б.
________ доц. Пойда В.Ю.
Ужгород – 2015
ЗМІСТ
ІНДИВІДУАЛЬНЕ ТЕХНІЧНЕ ЗАВДАННЯ 3
ВСТУП 4
1 ТЕОРЕТИЧНА ЧАСТИНА 6
1.1 Загальні відомості про бази даних 6
1.2 Поняття про моделі даних 7
1.3 Таблиці баз даних 9
1.4 Зв’язки між таблицями 10
1.5 Нормалізація реляційної бази даних. 10
1.6 HeidiSQL. 11
2 ПРАКТИЧНА ЧАСТИНА 13
2.1 ER-діаграма. 13
2.2 Структура таблиць. 13
2.3 Створення бази даних. 14
2.4 Інструкція для користувача. 17
ВИСНОВКИ 22
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ 23
ДОДАТКИ 24
1 Створення таблиць. 24
2 Вихідні таблиці. 26
3 Лістинг програми web-додатку. 31
ІНДИВІДУАЛЬНЕ ТЕХНІЧНЕ ЗАВДАННЯ
Тема: Організація баз даних в середовищі програми MySQL-Front. Створення бази даних для туристично-готельного комплексу. Підсистема «Робота з клієнтами».
Мета: Закріплення і практичне застосування знань, вмінь та навичок, одержаних під час вивчення дисципліни, а також отримання досвіду роботи з вільною системою керування реляційними базами даних MySQL.
Вимоги до виконання роботи: Побудувати ER-діаграму, створити базу даних та продемонструвати роботу з нею в середовищі MySQL-Front.
ВСТУП
Метою виконання даної курсової роботи є закріплення практичних знань, вмінь та навичок, одержаних під час вивчення дисципліни, а також отриманих досвідом роботи з вільною системою керування реляційними базами даних MySQL.
База даних (БД) - впорядкований набір логічно взаємопов'язаних даних, що використовуються спільно та призначені для задоволення інформаційних потреб користувачів. Головним завданням бази даних є гарантоване збереження значних обсягів інформації (так звані записи даних) та надання доступу до неї користувачеві або ж прикладній програмі. Таким чином, БД складається з двох частин: збереженої інформації та системи керування нею. Для того, щоб мати можливість створення, збереження, оновлення та пошуку інформації в базах даних з контролем доступу до них використовують системи управління базами даних (СУБД).
Базою даних можна вважати не тільки таблиці, що індексують файли із знаннями різних форматів, але і самі ці файли, тому, що вони є сховищами знань, що не типізуються, в такій базі даних. Основною метою курсового проекту є закріплення, систематизація та поглиблення знань, отриманих під час вивчення дисципліни, а також розвинення практичних навичок з аналізу об’єктів дослідження, проектування баз даних, розробки та налагодження програмного забезпечення для організації роботи зі спроектованою базою даних.
Основними задачами курсового проекту є:
поглиблення знань з теорії баз даних;
постановка задачі та розв'язання питань інформаційного забезпечення програми;
освоєння методів проектування БД для вирішення конкретних задач;
одержання уміння виконувати логічне і фізичне проектування баз даних;
освоєння інструментальних засобів проектування СУБД і створення програмного забезпечення для обробки даних БД;
оформлення курсового проекту та його захист.
В ході виконання даної курсової роботи розроблена база даних туристично-готельного комплексу, яка спростить роботу адміністратора з клієнтами. Курсова робота складається з введення, двох розділів: теоретичного та практичного, додатку, списку використаної літератури та зроблених висновків.
1 ТЕОРЕТИЧНА ЧАСТИНА
1.1 Загальні відомості про бази даних
Людина в процесі інформаційної діяльності збирає й накопичує відомості про навколишній світ. До появи обчислювальної техніки вся інформація зберігалася звичайно в письмовому або друкованому виді. Однак чим більше були обсяги інформації, з якими приходилось оперувати людині, тим гостріше вставало питання збереження інформації та її обробки.
Однієї з важливих функцій інформатики є організація зберігання інформації з метою швидкого пошуку необхідних даних. Для цього вся збережена в комп'ютері інформація повинна бути розсортована по ряду ознак. Будь-яка зміна інформації повинна миттєво враховуватися. Щоб оперувати даними, що складають базу, необхідна окрема програма. Програми, які управляють зберіганням, обробкою й пошуком інформації в БД, називаються системами керування базами даних (СУБД).
Бази даних (БД) – це систематизоване сховище інформації певної предметної області.
Система керування базами даних (СУБД) – це програма, призначена для організації зберігання, обробки й пошуку інформації в БД. Є велика розмаїтість СУБД. Ці програми постійно вдосконалюються й обновляються.
Основні можливості СУБД:
• Поповнення, розширення та відновлення БД;
• Висока надійність зберігання інформації;
• Засоби захисту інформації в СУБД;
• Виведення повної й достовірної інформації на запити користувача.
1.2 Поняття про моделі даних
Основою бази даних є модель даних — фіксована система понять і правил для представлення даних структури, стану і динаміки проблемної області в базі даних. У різний час послідовне застосування одержували ієрархічна, мережна і реляційна моделі даних.
Ієрархічна модель даних - Концептуальна схема ієрархічної моделі являє собою сукупність типів записів, пов'язаних типами зв'язків в одне чи кілька дерев. Усі типи зв'язків цієї моделі належать до виду «один-до-багатьох» і зображуються у вигляді стрілок.
Таким чином, взаємозв'язки між об'єктами нагадують взаємозв'язки в генеалогічному дереві, за єдиним винятком: для кожного породженого (підлеглого) типу об'єкта може бути тільки один вхідний (головний) тип об'єкта. Тобто ієрархічна модель даних допускає тільки два типи зв'язків між об'єктами: «один-до-одного» і «один-до-багатьох». Ієрархічні бази даних є навігаційними, тобто доступ можливий тільки за допомогою заздалегідь визначених зв'язків.
При моделюванні подій, як правило, необхідні зв'язки типу «багато-до-декількох». Як одне з можливих рішень зняття цього обмеження можна запропонувати дублювання об'єктів. Однак дублювання об'єктів створює можливості неузгодженості даних.
Достоїнство ієрархічної бази даних полягає в тому, що її навігаційна природа забезпечує швидкий доступ при проходженні вздовж заздалегідь визначених зв'язків. Однак негнучкість моделі даних і, зокрема , неможливість наявності в об'єкта декількох батьків, а також відсутність прямого доступу до даних роблять її непридатною в умовах частого виконання запитів, не запланованих заздалегідь. Ще одним недоліком ієрархічної моделі даних є те, що інформаційний пошук з нижніх рівнів ієрархії не можна спрямувати по вище розміщених вузлах.
Мережна модель даних. Ієрархічні і мережні бази даних часто називають базами даних з навігацією. Ця назва відбиває технологію доступу до даних, використовувану при написанні програм обробки мовою маніпулювання даними. При цьому доступ до даних по шляхах, не передбачених при створенні бази даних, може потребувати нерозумно тривалого часу.
Підвищуючи ефективність доступу до даних і скорочуючи таким чином час відповіді на запит, принцип навігації разом з цим підвищує і ступінь залежності програм і даних. Програми обробки даних виявляються жорстко прив'язаними до поточного стану структури бази даних і повинні бути переписані при її змінах. Принцип навігації не дозволяє істотно підвищувати рівень мови маніпулювання даними, щоб зробити його доступним користувачу-непрограмісту чи навіть програмісту-непрофесіоналу. Для пошуку запису-мети в ієрархічній або мережній структурі програміст повинен спочатку визначити шлях доступу, а потім — крок за кроком переглянути всі записи, що трапляються на цьому шляху.
Наскільки складними є схеми представлення ієрархічних і мережних баз даних, настільки і трудомістким є проектування конкретних прикладних систем на їхній основі. Як показує досвід, тривалі терміни розроблення прикладних систем нерідко призводять до того, що вони постійно перебувають на стадії розроблення і доопрацювання. Складність практичної реалізації баз даних на основі ієрархічної і мережної моделей визначила створення реляційної моделі даних.
Реляційна модель даних - назва «реляційна» пов'язана з тим, що кожен запис у таблиці даних містить інформацію, яка стосується якогось конкретного об'єкта. Крім того, зв'язані між собою дані навіть різних типів в моделі можуть розглядатися як одне ціле.
Таблиця має такі властивості:
кожний елемент таблиці являє собою один елемент даних;
повторювані групи відсутні;
усі стовпці в таблиці однорідні; це означає, що елементи стовпця мають однакову природу;
стовпцям присвоєні унікальні імена;
у таблиці немає двох однакових рядків.
Порядок розміщення рядків і стовпців у таблиці довільний; таблиця такого типу називається відношенням. У сучасній практиці для рядка використовується термін «запис», а для стовпця термін «поле».
Основною відмінністю пошуку даних в ієрархічних, мережних і реляційних базах даних є те, що ієрархічні і мережні моделі даних здійснюють зв'язок і пошук між різними об'єктами за структурою, а реляційні — за значенням ключових атрибутів.
Оскільки реляційна структура концептуально проста, вона дозволяє реалізовувати невеликі і прості (і тому легкі для створення) бази даних, навіть персональні, сама можливість реалізації яких ніколи навіть і не розглядалася в системах з ієрархічною чи мережною моделлю.
Недоліком реляційної моделі даних є надмірність по полях (для створення зв'язків між різними об'єктами бази даних).
Практично всі існуючі на сьогоднішній день комерційні бази даних і програмні продукти для їх створення використовують реляційну модель даних.
1.3 Таблиці баз даних
Таблиця - це набір елементів даних (значень), які організовані з використанням моделі вертикальних стовпчиків (з різними іменами) і горизонтальних рядків. Таблиця має визначену кількість стовпчиків, в той час
як кількість рядків може різнитися в різні моменти. Кожен рядок ідентифікується особливим набором колонок який називається потенційним ключем. Ключ представляє собою комбінації полів, дані в яких однозначно визначають кожний запис в таблиці. Простий ключ складається з одного поля, складний відповідно з декількох полів. Поля, по яким будується ключ називаються ключовими. В таблиці може бути визначений тільки один ключ.
Неформально, в термінах реляційної моделі, таблиця це синонім для відношень. Але ці терміни не зовсім еквівалентні. Наприклад, SQL таблиця потенційно може містити однакові рядки, а відношення не може містити однакові кортежі. Також представлення таблиці має на увазі особливий порядок рядків і стовпчиків, тоді як відношення явно невпорядковане.
1.4 Зв’язки між таблицями
Організація зв'язків між таблицями називається зв'язуванням або об'єднанням таблиць. Зв'язки між таблицями можна встановлювати як при створення БД, так і при створення додатку використовуючи засоби, що представляються обраною СУБД. Для зв'язку таблиць використовуються поля зв'язку. Вони обов'язково повинні бути індексовані. В підпорядкованій таблиці для зв'язку з головною таблицею береться індекс, який називається зовнішнім ключем. Склад полів цього індексу повинен частково чи повністю співпадати зі складом полів індексу головної таблиці. Особливість використання індексів залежить від формату таблиці. Зв'язок між таблицями визначає відношення підпорядкованості.
1.5 Нормалізація реляційної бази даних.
Нормалізованою називається база даних, в якій виконуються як мінімум три умови нормалізації. Виконання умов називається приведенням БД до першої форми.
Перша нормальна форма вимагає, щоб кожне поле таблиці було неподільним і не містило груп, що повторюються.
Кожна таблиця повинна мати основний ключ: мінімальний набір колонок, які ідентифікують запис.
Уникнення повторень груп (категорії даних, що можуть зустрічатись різну кількість разів в різних записах) правильно визначаючи неключові атрибути.
Кожен атрибут повинен мати лише одне значення, а не множину значень.
Друга нормальна форма вимагає, щоб усі поля одної таблиці залежали від первинного ключа. Тільки в цьому випадку первинний ключ буде визначати унікальну інформацію.
Схема бази даних повинна відповідати вимогам першої нормальної форми.
Дані, що повторно з'являються в декількох рядках виносяться в окремі таблиці.
Третя нормальна форма вимагає, щоб дані в таблиці залежали винятково від основного ключа.
Схема бази даних повинна відповідати всім вимогам другої нормальної форми.
Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.
1.6 HeidiSQL.
HeidiSQL, перед тим відома як MySQL-Front — вільний відкритий клієнт, або фронтенд, для управління базами даних, розроблений німецьким програмістом Анзґаром Бекером та кількома іншими розробниками, Написаний на Delphi, підтримує з'єднання та роботу з MySQL, їхні форки, таких як MariaDB та Percona, а також Microsoft SQL Server, починаючи з версії 7.0. Щоб управляти базою даних з HeidiSQL, користувач має увійти на локальний або віддалений сервер MySQL з прийнятним паролем, створивши сесію. В рамках цієї сесії користувач може управляти базами даних MySQL на сервері MySQL, і від'єднатися після закінчення роботи. Можливості програми цілком достатні для більшості операцій із загальними та просунутими базами даних, таблицями та записами, але розробка залишається у активному стані, щоб забезпечити повну функціональність, котра очікується від фронтенду MySQL.
Через свій графічний інтерфейс HeidiSQL може виконувати такі операції з базами даних:
список всіх баз даних на сервері, з'єднання з обраною базою для роботи з її таблицями і даними;
перегляд підсумкової інформації про відкриті бази даних;
створення нових, зміна існуючих імен баз даних, кодових сторінок і символьного впорядкування, вилучення баз даних;
таблиці, види, процедури, тригери та події;
перегляд всіх об'єктів в середині бази даних; опорожнення, перейменування та вилучення об'єктів;
редагування стовбців, індексів та зовнішніх ключів таблиць, підтримуються віртуальні стовпці на серверах MariaDB;
редагування запитів та установок;
редагування тіла та параметрів SQL процедур;
редагування тіла та установок SQL тригерів;
редагування тіла та часових установок запланованих SQL подій.
2 ПРАКТИЧНА ЧАСТИНА
2.1 ER-діаграма.
/
Рисунок 1. ER-діаграма
2.2 Структура таблиць.
Таблиця
Поля
Client
ID INT(10), Name VARCHAR(128), Sex VARCHAR(10), Year_of_birth DATE, Phone VARCHAR(13), Passport INT (10)
Hotel_Room
ID INT(10), Name INT(10), Number INT(10), Check DATE, Days INT(10)
Type_of_room
Number INT(10), Category VARCHAR(128), Price INT(10)
Pool
ID INT(10), Name INT(10), Reservations TINYINT, Date DATE, Time TIME, Price INT(10)
Restaurant
ID INT(10), Name INT(10), Food INT(10)
Restaurant_Food
ID INT(10), Food VARCHAR(128),
Price INT(10)
Sauna
ID INT(10), Name INT(10), Reservations TINYINT, Date DATE, Time TIME, Price INT(10)
SPA
ID INT(10), Name INT(10), Reservations TINYINT, Date DATE, Time TIME, Price INT(10)
2.3 Створення бази даних.
Створюємо або підключаємось до вже існуючого сеансу.
/
Рисунок 2. Вікно створення нової сесії
Вказуючи полі «Ім’я серверу / IP» значення localhost, і дані користувача (ім’я, пароль) як показано на (Рис. 2).
Після підключення до сеансу, щоб створити нову базу даних, натискаємо праву кнопку мишки і вибираємо «Створити нову» «База даних» (Рис. 3).
/
Рисунок 3. Створення бази даних
Вказуємо ім’я бази даних, і натискаємо кнопку «Гаразд»(Рис.4). Базу даних можна було створити за допомогою SQL коду: CREATE DATABASE `Hotel`.
/
Рисунок 4. Назва бази даних
Для створення таблиць та їх полів, використовуємо SQL код, який пишемо у вкладці «Запит» і натискаємо кнопку «Виконати» або клавішу F9 як показано на (Рис. 5). Весь код прикріплений в додатку.
/
Рисунок 5. Створення таблиць за допомогою запиту
Після створення таблиць і їх поля, можемо почати вносити дані в таблицю, відкривши вкладку «Дані» і користуючись кнопками / для додавання запису і / для видалення рядку.
/
Рисунок 6. Таблиця заповнена даними
2.4 Інструкція для користувача.
Ми маємо створену бази даних для туристично-готельного комплексу для роботи з клієнтами. Спочатку нам потрібно записати дані клієнта в таблицю «Client» (Рис. 7).
/
Рисунок 7. Дані таблиці «Client»
Далі відкриваємо таблицю «Hotel_Room» де в полі «Name» вибираємо ID клієнта з випадаючого списку, в полі «Number» вибираємо номер кімнати і потрібний клас номеру. В полі «Check» вказуємо дату в’їзду клієнта в номер, в полі «Days» зазначаємо кількість днів бронювання номеру (Рис. 8).
/
Рисунок 8. Дані таблиці «Hotel_Room»
Потім відкриваємо таблицю «Pool» де як в попередній таблиці в полі «Name» вибираємо ID клієнта, в полі «Reservations» пишемо значення «0» або «1», де «1» означає що клієнт хоче скористатись басейном, за що йому треба окремо доплатити. Якщо вибране значення «1» тоді треба вказати дату і час коли, ціна за басейн стоїть по замовчуванню рівна «50», по бажанню її значення можна змінити (Рис. 9).
/
Рисунок 9. Дані таблиці «Pool»
Дані в таблицю «Sauna»(Рис. 10) і «SPA» (Рис. 11) вносимо так само як в попередню таблицю «Pool».
/
Рисунок 10. Дані таблиці «Sauna»
/
Рисунок 11. Дані таблиці «SPA»
Відкриваємо останню таблицю «Restaurant» і заповнюємо її, в полі «Name» вказуємо ID клієнта, в полі «Food» вибираємо з випадаючого списку потрібний нам режим харчування клієнта (Рис. 12).
/
Рисунок 12. Дані таблиці «Restaurant»
Таблиці «Type_of_room» (Рис. 13) і «Restaurant_Food» (Рис. 14) створені для того, щоб в них зберігались статичні дані які ми використовуємо і змінювати які не потрібно (принаймні часто). Ці таблиці допомагають швидше заповнювати інші таблиці, цьому сприяє зручне випадаюче меню і зменшення кількості даних які треба заповнити.
/
Рисунок 13. Статичні дані таблиці «Type_of_room»
/
Рисунок 14. Статичні дані таблиці «Restaurant_Food»
Для того, щоб вивести найголовніші дані в окрему таблицю, використаємо SQL код, вписавши його у вкладку «Запит»:
SELECT C.ID, C.Name, HM.Number, ToR.Category AS RoomType, HM.`Check`, HM.Days, RF.Food, P.Reservations AS Pool, S.Reservations AS Sauna, SPA.Reservations AS SPA,
((ToR.Price * HM.Days) + IF(P.Reservations=1, P.Price, 0) + RF.Price + IF(S.Reservations=1, S.Price, 0) + IF(SPA.Reservations=1, SPA.Price, 0)) AS TotalPrice
FROM `Client` AS C
LEFT JOIN Hotel_Room AS HM ON HM.Name=C.ID
LEFT JOIN Type_of_room AS ToR ON ToR.Number=HM.Number
LEFT JOIN Pool AS P ON P.Name=C.ID
LEFT JOIN Restaurant AS R ON R.Name=C.ID
LEFT JOIN Restaurant_Food AS RF ON RF.ID=R.Food
LEFT JOIN Sauna AS S ON S.Name=C.ID
LEFT JOIN SPA ON SPA.Name=C.ID;
Результат коду показаний на (Рис. 15). Ми вивели основні дані і підрахували в скільки обійдеться відпочинок кожному клієнту, вивівши значення в поле «TotalPrice».
/
Рисунок 15. Основні дані всіх таблиць
Для того, щоб зручно було переглядати та робити пошук в БД був розроблений web-додаток.
/
Рисунок 16. Зовнішній вигляд web-додатку
ВИСНОВКИ
Результатом даної курсової роботи є створена база даних туристично-готельного комплексу для роботи з клієнтами. База даних створена в середовищі MySQL-Front. Для того щоб максимально зручно розробити БД ми створили 8 таблиць, які логічно зв’язані між собою. Зручний інтерфейс програми дозволяє легко орієнтуватися в ній, не вимагаючи від користувача яких-небудь спеціальних навиків роботи.
Були закріплені і практично застосовані знання, вміння та навички, одержані під час вивчення дисципліни. Також був отриманий досвід роботи з системою керування реляційними базами даних MySQL.
СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ
Основы проектирования реляционных баз данных. Электронное учебное пособие.
Тихомиров Ю. В. Microsoft ® SQL Server 7.0: разработка приложений. – Спб.: БХВ – Санкт-Петербург, 1999. – 352 с.
Єрьоміна Н.В. Проектування баз даних: Навчальний посібник. – К.: КНЕУ, 1998 р.
Кузнецов С. Д. Основи баз даних. - М.: БИНОМ. 2007 р.
Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984 р.
Зрюмов Е.А., Зрюмова А.Г. - Базы данных для инженеров 2009.
Бойко В. В., Савинков В. М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989.
Кузин А.В., Левонисова С.В. - Базы данных (5-е изд.) 2012.
К. Дж. Дейт - SQL и реляционная теория. Как грамотно писать код на SQL 2010 р.
ДОДАТКИ
1 Створення таблиць.
CREATE TABLE `Client` (
ID INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name VARCHAR(128),
Sex VARCHAR(10),
Year_of_birth DATE,
Phone VARCHAR(13),
Passport INT (10)
);
CREATE TABLE Type_of_room (
Number INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Category VARCHAR(128),
Price INT(10)
);
CREATE TABLE Hotel_Room (
ID INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name INT(10),
Number INT(10),
`Check` DATE,
Days INT(10),
INDEX Hotel_Room_Client (`Name`),
CONSTRAINT Hotel_Room_Client FOREIGN KEY(Name) REFERENCES `Client`(ID),
INDEX Hotel_Room_Type_of_room (Number),
CONSTRAINT Hotel_Room_Type_of_room FOREIGN KEY(Number) REFERENCES `Type_of_room`(Number)
);
CREATE Table `SPA` (
ID INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name INT(10),
Reservations TINYINT,
`Date` DATE,
`Time` TIME,
Price INT(10),
INDEX SPA_Client (Name),
CONSTRAINT SPA_Client FOREIGN KEY(Name) REFERENCES `Client`(ID)
);
CREATE Table `Pool` (
ID INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name INT(10),
Reservations TINYINT,
`Date` DATE,
`Time` TIME,
Price INT(10),
INDEX Pool_Client (Name),
CONSTRAINT Pool_Client FOREIGN KEY(Name) REFERENCES `Client`(ID)
);
CREATE Table `Sauna` (
ID INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name INT(10),
Reservations TINYINT,
`Date` DATE,
`Time` TIME,
Price INT(10),
INDEX Sauna_Client (Name),
CONSTRAINT Sauna_Client FOREIGN KEY(Name) REFERENCES `Client`(ID)
);
CREATE TABLE Restaurant_Food (
ID INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Food VARCHAR(128),
Price INT(10)
);
CREATE Table `Restaurant` (
ID INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name INT(10),
Food INT(10),
INDEX Restaurant_Client (Name),
CONSTRAINT Restaurant_Client FOREIGN KEY(Name) REFERENCES `Client`(ID),
INDEX Restaurant_Restaurant_Food (Food),
CONSTRAINT Restaurant_Food FOREIGN KEY(Food) REFERENCES `Restaurant_Food`(ID)
);
2 Вихідні таблиці.
Таблиця 1. Дані про клієнта «Client».
/
Таблиця 2. Дані про резервування кімнати готелю «Hotel_room».
/
/
Таблиця 3. Дані про харчування клієнта «Restaurant».
/
Таблиця 4. Меню ресторану «Restaurant_Food».
/
Таблиця 5. Резервування басейну «Pool».
/
Таблиця 6. Резервування сауни «Sauna».
/
Таблиця 7. Запис на сеанс у СПА «SPA».
/
/
Таблиця 8. Тип кімнати готелю «Type_of_room».
/
Таблиця 9. Основні дані всіх таблиць.
/
3 Лістинг програми web-додатку.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Клієнт</title>
<style>
body{
background: url(images/7.jpg);
background-size: cover;
color: #E5FFFF;
}
</style>
<link href="style.css" rel="stylesheet">
</head>
<body>
<div>
<center>
<a href="index.php" class="button"/>Клієнт</a>
<a href="Client.php" class="button"/>Дані клієнта</a>
<a href="Hotel_room.php" class="button"/>Кімната готелю</a>
<a href="Restaurant.php" class="button"/>Ресторан</a>
<a href="Pool.php" class="button"/>Басейн</a>
<a href="Sauna.php" class="button"/>Сауна</a>
<a href="SPA.php" class="button"/>СПА</a>
</div>
</center>
<div>
<br>
<center>
<form action="search.php" method="post">
<font color="#FFF"><strong> Введіть ім'я клієнта </strong></font>
<br>
<input type="text" name="NameC" size="30" value="">
<input type="submit" name="submit" value="Шукати">
<input type="reset" name="reset" value="Очистити">
</form>
</center>
<br>
<center>
<?php
$db_host = 'localhost';
$db_name = 'Hotel';
$db_username = 'root';
$db_password = '2355';
// зєднуємось з сервером бази даних
$connect_to_db = mysql_connect($db_host, $db_username, $db_password)
or die("Could not connect: " . mysql_error());
// підключаємось до бази даних
mysql_select_db($db_name, $connect_to_db)
or die("Could not select DB: " . mysql_error());
$qr_result = mysql_query("SELECT Client.ID, Client.Name, Hotel_Room.Number, Type_of_room.Category AS RoomType, Hotel_Room.`Check`, Hotel_Room.Days, Restaurant_Food.Food AS Food, Pool.Reservations AS Pool, Sauna.Reservations AS Sauna, SPA.Reservations AS SPA,
((Type_of_room.Price * Hotel_Room.Days) + IF(Pool.Reservations=1, Pool.Price, 0) + Restaurant_Food.Price + IF(Sauna.Reservations=1, Sauna.Price, 0) + IF(SPA.Reservations=1, SPA.Price, 0)) AS TotalPrice
FROM Client AS Client
LEFT JOIN Hotel_Room AS Hotel_Room ON Hotel_Room.Name=Client.ID
LEFT JOIN Type_of_room AS Type_of_room ON Type_of_room.Number=Hotel_Room.Number
LEFT JOIN Pool AS Pool ON Pool.Name=Client.ID
LEFT JOIN Restaurant AS Restaurant ON Restaurant.Name=Client.ID
LEFT JOIN Restaurant_Food AS Restaurant_Food ON Restaurant_Food.ID=Restaurant.Food
LEFT JOIN Sauna AS Sauna ON Sauna.Name=Client.ID
LEFT JOIN SPA ON SPA.Name=Client.ID;")
or die(mysql_error());
// виводимо на сторінку сайту заголовки HTML-таблиці
echo '<table border="1" bgcolor="#3BA4C7">';
echo '<thead>';
echo '<tr>';
echo '<th>ID</th>';
echo '<th>Name</th>';
echo '<th>Number</th>';
echo '<th>RoomType</th>';
echo '<th>Check</th>';
echo '<th>Days</th>';
echo '<th>Food</th>';
echo '<th>Pool</th>';
echo '<th>Sauna</th>';
echo '<th>SPA</th>';
echo '<th>TotalPrice</th>';
echo '</tr>';
echo '</thead>';
echo '<tbody>';
// виводимо в HTML-таблицю всі дані клиентів з таблиці MySQL
while($data = mysql_fetch_array($qr_result)){
echo '<tr>';
echo '<td>' . $data['ID'] . '</td>';
echo '<td>' . $data['Name'] . '</td>';
echo '<td>' . $data['Number'] . '</td>';
echo '<td>' . $data['RoomType'] . '</td>';
echo '<td>' . $data['Check'] . '</td>';
echo '<td>' . $data['Days'] . '</td>';
echo '<td>' . $data['Food'] . '</td>';
echo '<td>' . $data['Pool'] . '</td>';
echo '<td>' . $data['Sauna'] . '</td>';
echo '<td>' . $data['SPA'] . '</td>';
echo '<td>' . $data['TotalPrice'] . '</td>';
echo '</tr>';
}
echo '</tbody>';
echo '</table>';
// закриваємо зєднання з сервером бази даних
mysql_close($connect_to_db);
?><code lang="php">
</center>
</div>
</body>
</html>