- •Харківський національний Економічний університет
- •Факультет економічної інформатики
- •Кафедра інформаційних систем
- •Пояснювальна записка
- •Харківський національний економічний університет
- •З а в д а н н я на дипломний проект студенту
- •6. Консультанти розділів дипломного проекту
- •Календарний план
- •Подання голові державної екзаменаційної комісії щодо захисту дипломного проекту
- •Довідка про успішність
- •Аналіз предметної області «розроблення модуля для проведення вікторини на базі мобільних технологій. Створення модуля вікторини в одно-користувацькому режимі»
- •1.1. Коротка характеристика об’єктів управління «Nix Solutions»
- •1.2. Опис предметної області
- •1.3. Аналіз існуючих програмних продуктів
- •1.4. Висновки
- •Специфікація вимог до модуля «розроблення модуля для проведення вікторини на базі мобільних технологій. Створення модуля вікторини в одно-користувацькому режимі»
- •2.1. Глосарій
- •2.2. Розроблення варіантів використання
- •2.2.1. Діаграма варіантів використання.
- •2.2.2. Специфікація варіантів використання.
- •2.2.3. Розкадровка варіантів використання.
- •2.3. Специфікація функціональних та не функціональних вимог
- •2.3.1. Функціональні вимоги.
- •2.3.2. Не функціональні вимоги.
- •2.4. Висновки
- •Проекті та технічні рішення
- •3.1. Логічна постанова задачі
- •3.2. Проектування структури бази даних
- •3.2.1. Опис вхідної та вихідної інформації, що обробляється в рамках автоматизованих функцій.
- •3.3.2 Концептуальне інфологічне проектування
- •3.2.3. Проектування глобальної логічної моделі даних.
- •3.2.4. Проектування фізичної моделі даних.
- •3.4.1. Регресійне тестування.
- •Охорона праці.
- •4.1. Джерела світла для організації штучного освітлення
- •4.2. Виконати розрахунок світлового потоку ламп, що забезпечують нормативну штучну освітленість в приміщенні
- •4.3. Ергономічні вимоги до організації робочих місць
- •4.4. Пожежна безпека
- •4.5. Висновки
- •Висновки
- •Додатки додаток а
- •Додаток б
- •Додатов в
3.2.3. Проектування глобальної логічної моделі даних.
Структура логічної моделі даних (рис. 3.2) відображає структуру елементів які знаходяться у базі даних.
Вона описує семантику предметної області і не враховує особливості конкретної СУБД. За даною логічною схемою побудована фізична модель (рис. 3.3), в якій враховані такі особливості СУБД, як припустимі типи і найменування полів.
Основна перевага реляційної моделі – порівняльна простота інструментальних засобів її підтримки. Реляційна даталогічна модель містить набір відносин або записів, явно не зв'язаних між собою. Зв'язки виражаються в наявності однакових атрибутів у різних відносин, які (атрибути) дозволяють при виконанні операції природного об’єднання відносин одержати цільну картину даних про об'єкт бази даних.
Розроблена реляційна схема даних не вимагає подальшої нормалізації. Отримана модель бази даних є основою для генерації структур даних, індексів і тригерів на фізичному етапі проектування. Враховано цілісність даних, тобто стійкість збережених даних до руйнування й знищення, пов'язаних з несправністю технічних засобів, системними помилками й помилковими діями користувачів, яка передбачає: відсутність неточно введених даних або двох однакових записів про один і той самий факт, захист від помилок при оновленні бази даних, каскадне видалення зв’язаних даних різних таблиць та збереження даних при відмовах і збоях техніки (відновлення даних).
Ефективність забезпечена вибором комплексу технічних засобів, вибором СУБД, проектуванням оптимальної логічної й фізичної моделі даних в процесі фізичного проектування БД.
Таблиця 3.4
Обмеження унікальності
№ п/п |
Атрибут або група атрибутів |
Серед яких примірників, якої сутності або зв'язку має місце унікальність |
1 |
Користувач.Ид_користувача |
Для всіх примірників сутності «Користувач» |
2 |
Багатокористувальницький_режим.ИД_БК_гри |
Для всіх примірників сутності «Багатокористувальницький_режим» |
3 |
Однокористувальницький_режим.ИД_ОК_гри |
Для всіх примірників сутності «Однокористувальницький_режим» |
4 |
Тема_вікторини.ИД_теми |
Для всіх примірників сутності «Тема_вікторини» |
5 |
Питання_вікторини.ИД_питання |
Для всіх примірників сутності «Питання_вікторини» |
6 |
Вид_вікторини.ИД_виду |
Для всіх примірників сутності «Вид_вікторини» |
Таблиця 3.5
Динамічні обмеження
№ п/п |
Група атрибутів |
Обмеження |
1 |
2 |
3 |
1 |
Користувач.Ид_користувача |
Ид_користувача = Ид_користувача +1 - значення атрибута курс може лише збільшуватися на одиницю. |
Закінчення табл. 3.5
1 |
2 |
3 |
2 |
Багатокористувальницький_режим.ИД_БК_гри |
ИД_БК_гри = ИД_БК_гри +1 - значення атрибута курс може лише збільшуватися на одиницю. |
3 |
Однокористувальницький_режим.ИД_ОК_гри |
ИД_ОК_гри = ИД_ОК_гри +1- значення атрибута курс може лише збільшуватися на 1. |
4 |
Тема_вікторини.ИД_теми |
ИД_теми = ИД_теми +1 - значення атрибута курс може лише збільшуватися на одиницю. |
5 |
Питання_вікторини.ИД_питання |
ИД_питання = ИД_питання +1 - значення атрибута курс може лише збільшуватися на одиницю. |
6 |
Вид_вікторини.ИД_виду |
ИД_виду = ИД_виду +1 - значення атрибута курс може лише збільшуватися на одиницю. |