3.2. Побудова концептуальної моделі проходження практики студентами
На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER–моделювання. Концептуальна модель наведена на наступному рисунку. Дамо декілька зауважень:
По–перше, ця модель не містить опису атрибутів сутностей у зв’язку з відсутністю місця для їх зображення. Передбачається, що атрибути сутностей разом з їх властивостями (бізнес–правилами) детально описані на етапі аналізу.
По–друге, мова ER–моделювання не передбачає детального представлення інформаційно–довідкових задач. Ми припускаємо, що вони мають звичайний текстовий опис, який представлений на етапі аналізу.
І, по-третє, наша концептуальна модель не містить інших складових, а саме, докладний і строгий опис сховищ даних, та детальний опис потоків даних. Це не було зроблено, так як опис цих складових концептуальної моделі виходить за рамки курсової роботи.
4. Логічне та фізичне проектування бази даних
Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.
Логічне проектування — це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..
Фізичне проектування – це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.
4.1. Логічне проектування
У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.
Для перетворення концептуальної моделі, представленої у вигляді мови ER–моделювання, у реляційну модель, був використаний наступний алгоритм.
Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.
Рис. Концептуальна ER-модель проходження практики студентами
Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.
Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.
Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.
Таблиця 1. Відношення сутності Ігри
GAME
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
25 |
Унікальний ID |
Первинний ключ |
NAME |
строка |
50 |
Назва гри |
Унікальний, обов’язковий |
Таблиця 2. Відношення сутності Команди
TEAMS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
25 |
Унікальний ID |
Первинний ключ |
NAME |
строка |
50 |
Повна назва команди |
Обов’язковий |
CLANTAG |
строка |
10 |
Скорочена назва команди |
Обов’язковий |
LEADER |
строка |
10 |
Лідер команди |
Обов’язково |
Таблиця 3. Відношення сутності ВИД Ігроки
PLAYERS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
LOGIN |
строка |
25 |
Логін ігрока |
Унікальний, обов’язковий |
PASSWORD |
Ціле число |
25 |
Пароль ігрока |
Обов’язковий |
NICKNAME |
строка |
20 |
Скорочене ім’я ігрока |
Унікальний, обов’язковий |
TEAM |
строка |
50 |
Назва команди |
Обов’язково |
Обмеження цілісності таблиці |
Вибирає унікальний TEAM(ID) |
|||
Таблиця 4. Відношення сутності Учасники ігор
GAME_REFERENCES
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
TEAM |
строка |
15 |
Назва команди |
Унікальний, обов’язковий. |
GAME |
строка |
50 |
Назва гри |
Обов’язків |
Обмеження цілісності таблиці |
Вибирає унікальний TEAM(ID) та GAME(ID) |
|||
Таблиця 5. Відношення сутності КОМАНДИ ЛІДЕРИ
LEADER_TEAM
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
GAME |
строка |
50 |
Унікальний ID |
Первинний ключ |
SCORE |
Ціле число |
255 |
бали |
Унікальний, обов’язковий. |
Таблиця 6. Відношення сутності ЛІДЕРИ НА ТЕХНИКІ
VEHICLE_LEADER_PLAYERS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
PLAYER |
строка |
20 |
Унікальний ID |
Первинний ключ |
VEHICLE |
строка |
25 |
Назва техніки |
Унікальний, обов’язковий. Певний вид техніки |
SCORE |
Ціле число |
255 |
бали |
Обов’язковий |
Обмеження цілісності таблиці |
Рахунок не повинен бути нулем |
|||
Таблиця 7. Відношення сутності Техніка
VEHICLE
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
15 |
Унікальний ID |
Первинний ключ |
Name |
строка |
25 |
Назва техніки |
Факультативний. |
ATTACK |
Ціле число |
50 |
Урон техніки |
Обов’язковий, унікальний. |
ARMOR |
Ціле число |
50 |
Броня техніки |
Обов’язковий, унікальний |
SPEED |
Ціле число |
50 |
Швидкість техніки |
Обов’язковий, унікальний |
Обмеження цілісності таблиці |
В строки (ATTACK, ARMOR, SPEED) не повинно бути дорівнювати чи бути меншим нуля. |
|||
Таблиця 8. Відношення сутності ЗБРОЯ
WEAPONS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
10 |
Повна назва |
Обов’язковий |
ATTACK |
ціле число |
50 |
Урон зброї |
Обов’язковий, унікальний |
ATTACK_SPEED |
ціле число |
50 |
Швидкість пострілу |
Обов’язковий, унікальний |
MAG_ROUNDS |
ціле число |
50 |
Об єм магазину |
Обов’язковий, унікальний |
ALL_ROUNDS |
ціле число |
50 |
Загальний обєм |
Обов’язковий, унікальний |
Таблиця 9. Відношення сутності КЛАСИ
CLASS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
15 |
Унікальний ID |
Первинний ключ |
NAME |
строка |
20 |
Скорочена назва |
Обов’язковий. |
Таблиця 10. Відношення сутності АТРИБУТИ КЛАСІВ
CLASSES_ATTRIBUTES
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
||
NAME |
ціле число |
15 |
Унікальний ID |
Первинний ключ |
||
CLASS_ID |
строка |
15 |
Скорочена назва |
Обов’язковий |
||
Обмеження цілісності таблиці |
CLASS_ID вибирає як ID так і NAME |
|
||||
Таблиця 11. Відношення сутності КАРТИ
MAPS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
ID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
NAME |
строка |
15 |
Назва карти |
Обов’язковий, унікальний. |
MAXPLAYERS |
Ціле число |
64 |
Максимальна кількість ігроків |
Обов’язковий, унікальний у межах картах. |
Таблиця 12. Відношення сутності ТЕХНІКА ДЛЯ ГРИ
VEHICLE
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
GAME_ID |
ціле число |
15 |
Унікальний ID |
Первинний ключ |
VEHICLE_ID |
ціле число |
15 |
Унікальний ID |
Обов’язковий, унікальний |
Таблиця 13. Відношення сутності ЗБРОЯ ДЛЯ ГРИ
GAME_WEAPONS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
GAME_ID |
ціле число |
15 |
Унікальний ID |
Первинний ключ |
WEAPON_ID |
ціле число |
15 |
Унікальний ID |
Обов’язковий, унікальний |
Таблиця 14. Відношення сутності КЛАСИ ДЛЯ ГРИ
GAME_CLASS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
GAME_ID |
ціле число |
15 |
Унікальний ID |
Первинний ключ |
CLASS_ID |
Ціле число |
15 |
Номер договору |
Обов’язковий, унікальний |
Таблиця 15. Відношення сутності КАРТИ ДЛЯ ГРИ
GAME_MAPS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
GAME_ID |
ціле число |
15 |
Унікальний ID |
Первинний ключ |
MAP_ID |
Ціле число |
10 |
Унікальний ID |
Обов’язковий, унікальний |
Таблиця 16. Відношення сутності ІГРОКИ ЛІДЕРИ В КАЛСАХ
CLASS_LEADER_PLAYERS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
PLAYER |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
CLASS_ID |
ціле число |
10 |
Унікальний ID |
Обов’язковий, унікальний |
SCORE |
Ціле число |
255 |
бали |
Обов’язковий |
Обмеження цілісності таблиці |
Бали (SCORE) не повинні дорівнювати нулю |
|||
Таблиця 17. Відношення сутності ІГРОКИ ЛІДЕРИ НА КАРТАХ
MAPS_LEADER_PLAERS
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
MAP_ID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
PLAYER |
строка |
20 |
Ім’я ігрока |
Обов’язковий, унікальний |
SCORE |
ціле число |
255 |
бали |
Обов’язковий |
Обмеження цілісності таблиці |
Бали (SCORE) не повинні дорівнювати нулю |
|||