Користувач системи

Гість

Адміністратор

Логін

Пароль

Пароль

Розробник

Логін

Затверджувач

Логін

Пароль

Рис.2.6. Діаграма класу – Користувачі системи.

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

• користувач-розробник;

• користувач-затверджувач;

• користувач-адміністратор;

• користувач-гість.

Користувач-адміністратор має права на зміну бази даних (додавання, редагування, видалення сторінок, а також додавання і видалення користувачів) та перегляд даних системи.

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

Користувач-затверджувач має права на на зміну бази даних про затвердження методичного забезпечення(додання матеріалів про затвердження) та перегляд даних системи.

Всі вони проходять аутентифікацію (логін і пароль).

Користувач-гість має право тільки на перегляд даних системи .

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

Адмін Розробник

Гість Затверджувач

Рис.2.7. Діаграма використання системи.

2.2. Розробка структури бази даних

Для зберігання, накопичення та обробки даних необхідно використовувати базу даних. Базами даних (БД) називають електронні сховища інформації, доступ до яких здійснюється за допомогою одного чи декількох комп’ютерів.

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

Для забезпечення логічної цілісності збережених даних установимо зв'язки між таблицями і визначимо типи цих зв'язків. Тут типи зв'язків обмежують можливість користувача вносити ті або інші дані. Так, при встановленні типу «один до багатьох» (1  n) у таблицю, який відповідає «1» зв'язне поле є ключем і, отже у стовбці не можуть повторюватися значення. Таким чином, логічна структура БД представлена на рисунку 2.8.

settings

id

page

plan

id

tema

kol

file_pzvr

file_recenz

subjects

id

subject

np

cval

teachers

id

name

pos

img

timetable

id

gr

autor

date

bio

time

subject

title

text

date

autor

status

file

userlist

id

user

file_pzk

file_pzi

pass

priv

Рис.2.8. Логічна структура бази даних.

Таблиці бази даних системи з наступними полями:

• таблиця settings мал.(2.9);

• таблиця plan мал. (2.10);

• таблиця teachers мал. (2.11);

• таблиця subjects мал. (2.12);

• таблиця timetable мал. (2.13);

• таблиця userlist (2.14).

Рис.2.9. Таблиця settings.

Рис.2.10. Таблиця plan.

Рис.2.11 Таблиця teachers.

Рис.2.12. Таблиця subjects.

Рис.2.13. Таблиця timetable

Рис.2.14.Таблиця userlist

Конфігураційна інформація моєї MySQL бази даних :

Host Name = localhost;

MySQL User Name = jackson;

MySQL Password = jackson;

MySQL Database Name = system;

Для створення бази даних мій вибір зупинився на phpMyAdmin 3.1.3.1.

PhpMyAdmin - веб-додаток з відкритим кодом, написаний на мові PHP і представляє собою веб-інтерфейс для адміністрування СУБД MySQL. phpMyAdmin дозволяє через браузер здійснювати адміністрування сервера MySQL, запускати команди SQL і переглядати вміст таблиць і баз даних. Додаток користується великою популярністю у веб-розробників, оскільки дозволяє управляти СУБД MySQL без безпосереднього введення SQL команд, надаючи дружній інтерфейс.

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

Додаток розповсюджується під ліцензією GNU General Public License і тому багато іншіх розробників інтегрують його у свої розробки, наприклад XAMPP, Denwer, AppServ. Проект на даний момент часу локалізований на більш ніж 50 мовах.

Одиницею збереження інформації в БД являється таблиця. Кожна таблиця представляє собою сукупність рядків і стовпців, де рядки відповідають зразку об’єкта, конкретній події чи явищу, а стовпчики атрибутам (признакам, характеристикам, параметрам) об’єкту, події, явища.

Бази даних, між окремими таблицями яких існують зв’язки, називаються реляційними (від relation- відношення, зв’язок). Зв’язки таблиці взаємодіють по принципу головна і дочірня. У кожної таблиці може існувати первинний ключ – поле або набір полів, однозначно ідентифікуючи запис. Значення первинного ключа таблиці повинне бути унікальним, тобто в таблиці не повинно існувати двох чи більше записів з однаковими значеннями первинного ключа. Вторинні ключі ставляться по на полях,які часто використовуються при пошуку і сортуванні даних: вони позволяють системі значно швидше знайти потрібні дані. Поля вторинних ключів можуть містити не унікальні дані.

Відношення «один – до-багатьох» використовується у випадку, коли один запис у батьківській таблиці відповідає декільком записам в дочірній. Розрізняють два види зв’язків «один – до-багатьох» :

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

• у другому випадку – деякі записи в батьківській таблиці не обов’язково повинні мати зв’язані з ними записи в дочірній таблиці.

Клієнт формує запит до сервера на мові запитів SQL, (Structured Query Language - структурована мова запитів), що є промисловим стандартом для реляційних БД. SQL - сервер забезпечує інтерпретацію запиту, його виконання, формування результату і видачу цього результату клієнтові. При цьому ресурси клієнтського комп'ютера не беруть участь у фізичному виконанні запиту, клієнтський комп'ютер лише посилає запит до серверної БД і отримує результат, після чого інтерпретує його необхідним чином і надає користувачеві. Оскільки клієнтському застосуванню посилається результат виконання запиту, по мережі передаються лише ті дані, які насправді потрібні клієнтові. У результаті знижується навантаження на мережу. Крім того SQL-сервер, якщо це можливо, оптимізує отриманий запит так, щоб він був виконаний за мінімально можливий час. Все це підвищує швидкодію системи і знижує час чекання результату запиту. При виконанні запитів сервером істотно підвищується міра безпеки даних, оскільки правила цілісності даних визначаються на сервері і є єдиними для всіх застосувань, що використовують цю БД. В результаті унеможливлюється визначення суперечливих правил підтримки цілісності. Потужний апарат транзакцій, підтримуваний SQL-серверами блокує одночасну зміну одних і тих же даних різними користувачами і надає можливість відкотів до первинних значень при внесенні в БД змін, що закінчилися аварійно.

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

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

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

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