ься на практике. Останнє пов'язане з тім, что розробник інтенсівно розвівають свой продукт, з Огляду на всі нововведення СУБД MySQL. Переважно більшість российских провайдерів Використовують Цю програму в якості панелі управління для того, щоб надаті своим Клієнтам можлівість адміністрування віділеніх Їм баз даних.
Додаток розповсюджується під ліцензією GNU General Public License и того много іншіх розробніків інтегрують его у свои розробки, например XAMPP, Denwer, AppServ. Проект на Данії момент годині локалізованій на більш чем 50 мовах.
Одиниця Збереження информации в БД являється таблиця. Кожна таблиця представляет собою сукупність рядків и стовпців, де рядки відповідають зразки про єкта, конкретній події чі явіщу, а стовпчики атрибутам (ознаками, характеристикам, параметрам) про єкту, події, явіща.
Бази даних, между ОКРЕМЕ таблицю якіх існують зв язки, назіваються реляційнімі (від relation - відношення, зв язок). Зв язки табліці взаємодіють за принципом головна и дочірня. У кожної табліці может існуваті первинний ключ - поле або набор полів, однозначно ідентіфікуючі запис. Значення первинного ключа табліці повинною буті унікальнім, тобто в табліці не винних існуваті двох чі более запісів з Однаково значеннями первинного ключа. Вторинні ключі ставлять по на полях, Які часто Використовують при поиска и сортуванні даних: смороду позволяють сістемі значний швідше найти потрібні дані. Поля вторинно ключів могут містіті НЕ Унікальні дані.
Відношення «один - до-багатьох» вікорістовується у випадка, коли одна запису У батьківській табліці відповідає декільком записам у дочірній. Розрізняють дві види зв язків «один - до-багатьох»:
- у Першому випадка необхідні строгі умови, відповідно Яким КОЖЕН записів у батьківській табліці винен ВІДПОВІДАТИ записів у дочірній табліці;
- у іншому випадка - деякі записи в батьківській табліці НЕ обов язково повінні мати зв язані з ними записи в дочірній табліці.
Клієнт формує запит до сервера на мові Запитів SQL, (Structured Query Language - структурована мова Запитів), что є промисловим стандартом для реляційніх БД. SQL - сервер Забезпечує інтерпретацію запиту, его виконан, формирование результатами І видачу цього результату клієнтові. При цьом ресурси клієнтського комп ютера не беруть доля у фізічному віконанні запиту, клієнтській комп ютер лишь посілає запит до серверної БД и отрімує результат, после чего інтерпретує его необхіднім чином и надає корістувачеві. Оскількі клієнтському ЗАСТОСУВАННЯ посілається результат виконан запиту, по мережі передаються лишь ті дані, Які насправді потрібні клієнтові. У результате зніжується НАВАНТАЖЕННЯ на ятір. Крім того SQL-сервер, если це можливо, оптімізує отриманий запит так, щоб ВІН БУВ Виконання за мінімально можливий годину. Всі це підвіщує швідкодію СИСТЕМИ І зніжує годину карбувати результату запиту. При віконанні Запитів сервером істотно підвіщується міра безпеки даних, оскількі правила цілісності даних визначаються на сервері и є єдінімі для всіх! Застосування, что Використовують Цю БД. У результате унеможливлюється визначення суперечлівіх правил ПІДТРИМКИ цілісності. Потужний апарат транзакцій, підтрімуваній SQL-серверами блокує одночасну зміну одних и тихий же даних різнімі Користувачами и надає можлівість відкотів до Первін значення при внесенні в БД змін, что закінчіліся аварійно.
До баз даних пред'являються деякі вимоги. Однією з таких вимог є Вимога, согласно з Якою реляційна база даних має буті нормалізована. Процес нормалізації Полягає у приведенні до третьої нормальної форми.
Перша нормальна форма требует, щоб Кожне поле табліці БД Було неділімім и не містіло груп, что повторюються. Неподільність поля означає, что значення, что містяться в нім, що не повінні діліться на дрібніші. Повторюються поля, що містять однакові по СЕНС значення.
Друга нормальна форма требует, щоб всі поля табліці залежався від первинного ключа, тобто щоб первинний ключ однозначно визначавши Запис и не БУВ надлишково. Ті поля, Які залежався від части первинного ключа, мают буті віділені у складі ОКРЕМЕ таблиці.
Третя нормальна форма требует, щоб в табліці НЕ Було транзитивних залежних между НЕ ключовими полями, тобто щоб значення будь-которого поля, что не входити в первинний ключ, що не залежався від значення Іншого поля, что такоже НЕ входити в первинний ключ.
.3 Розробка серверної части
Основним в розробці серверної части є робота з базою даних. Помощью структурованої мови Запитів SQL можна Виконувати Такі операции:
створюваті бази даних и табліці;
додаваті інформацію в табліці;
відаляті інформацію;
мо...
