KursovaBD E25ouob3.zp2

ЗМІСТ
ВСТУП..........................................................................................................................6
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ........................................................................7
1.1 Предметна область......................................................................................7
1.2 Поняття реляційної бази даних та СУБД..................................................8
1.3 Обґрунтування вибору СУБД..................................................................17
1.4 Обґрунтування вибору мови програмування..........................................20
1.5 Висновки....................................................................................................21
2 ПРОЕКТУВАННЯ БАЗИ ДАНИХ.......................................................................22
2.1 Проектування методом сутність-зв'язок.................................................22
2.2 Проектування ER-моделі..........................................................................26
2.3 Метод нормалізації відношень.................................................................29
2.4 Висновки....................................................................................................33
3 ПРАКТИЧНА РЕАЛІЗАЦІЯ БАЗИ ДАНИХ.......................................................34
3.1 Розробка таблиць.......................................................................................34
3.2 Розробка запитів........................................................................................38
3.3 Розробка форм...........................................................................................43
3.4 Розробка звітів...........................................................................................47
3.5 Висновки....................................................................................................54
ВИСНОВКИ...............................................................................................................55
ПЕРЕЛІК ПОСИЛАНЬ.............................................................................................56
ДОДАТКИ..................................................................................................................57
Додаток А Лістинг створення контексту бази даних...................................58
Додаток Б Форма для ведення журналу........................................................59
Додаток В Лістинг обробки форми для ведення журналу..........................60
Додаток Д Головне вікно програми...............................................................64
6
ВСТУП
Однією з проблем сучасного ВНЗ є контроль. У зв'язку з великою кількістю

студентів університету та безліччю дисциплін є необхідність вести облік за
даними, які супроводжують навчальний процес груп та студентів. В даний час
існують безліч видів обліку і контролю за даними про студентів. Це такі види
контролю як:
1) поточна успішність студента;
2) інформація про успішність студента за кожен місяць;
3) відомості про академічні заборгованості і успішність;
4) результати іспитів і заліків;
5) накази про зарахування студентів на стипендію;
6) облік відвідуваності студентами занять.
Ці дані зберігаються в журналах груп, екзаменаційних та залікових
відомостях, довідках, наказах, списках і т.д. Дані про студентів одночасно можуть
знадобитися старості та викладачам. Складнощі обліку успішності обумовлюють
значну кількість документації та розподіленість споживачів та інформації.
Актуальність виконання курсової роботи полягає у вирішенні
вищеперерахованих проблем обліку успішності студентів та відвідування. Метою
виконання курсової роботи є створення бази даних «Електронний журнал
викладача» для обліку викладачами успішності студентів та відвідування, а також
програмного додатку для зручної роботи з базою даних. Завданням бази даних та
програмного додатку, що будуть розроблені, є спрощення роботи викладачів з
відвідуванням та успішністю студентів.
7
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
База даних (англ. database) – це сукупність даних, організованих відповідно

до концепції, яка описує характеристику цих даних і взаємозв'язки між їх
елементами; ця сукупність підтримує щонайменше одну з областей застосування
(за стандартом ISO/IEC 2382:2015).
В розділі буде проаналізовано предметну область теми «Електронний
журнал користувача», буде наведено теоретичні відомості про моделі даних, бази
даних та системи управління ними. Буде проаналізовано недоліки альтернативних
СУБД та обгрунтовано вибір СУБД для виконання проектування бази даних
відповідно до індивідуального завдання. Також буде обгрунтовано вибір мови
програмування для створення клієнтського додатку для роботи з розробленою
базою даних.
1.1 Предметна область
При аналізі предметної області теми «Електронний журнал викладача» слід

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

певному уроці та отримав або не отримав оцінку. Також студент входить до
певної групи, яка в свою чергу належить до структурного підрозділу навчального
закладу, наприклад, до факультету. Водночас урок може відбуватись для однієї
або декількох груп, що дещо ускладнює моніторинг присутності студентів та
ведення журналу їх успішності, оскільки кількість студентів може бути великою.
Вважається, що урок відбувся, якщо минув час, відведений на його
проведення та викладач відзначив присутніх. Відсутній на уроці студент не може
отримати відмітку про бал. Присутній може отримати дві відмітки – про
присутність, та, можливо, отриманий бал.
1.2 Поняття реляційної бази даних та СУБД
База даних (англ. database) – це сукупність даних, організованих відповідно

до концепції, яка описує характеристику цих даних і взаємозв'язки між їх
елементами; ця сукупність підтримує щонайменше одну з областей застосування
(за стандартом ISO/IEC 2382:2015). В загальному випадку база даних містить
схеми, таблиці, подання, збережені процедури та інші об'єкти. Дані у базі
організовують відповідно до моделі організації даних. Таким чином, сучасна база
даних, крім саме даних, містить їх опис та може містити засоби для їх обробки. [1]
Ядром будь-якої бази даних є модель даних. Модель даних – це сукупність
структур даних та операцій їх обробки. За допомогою моделі даних можуть бути
представлені інформаційні об'єкти і взаємозв'язки між ними. Основними типами
моделей є:
1) ієрархічна;
2) мережна;
3) реляційна.
Ієрархічна модель даних являє собою сукупність елементів даних,
розташованих в порядку їх підпорядкування, що утворюють дерево (рис. 1.1). До
основних понять ієрархічної моделі даних відносяться: рівень, вузол і зв'язок.
9
Вузол - це сукупність атрибутів даних, що описують інформаційний об’єкт.

Ієрархічна структура повинна відповідати таким вимогам:
1) кожен вузол на більш низькому рівні пов'язаний лише з одним
вузлом, що знаходиться на більш високому рівні;
2) існує тільки один кореневий вузол на найвищому рівні, підлеглий
ніякому іншому вузлу;
3) до кожного вузла існує рівно один шлях від кореневого вузла.
Рисунок 1.1 – Графічне зображення ієрархічної структури даних
В мережній моделі зв'язок "один до багатьох" (1:N) означає, що значенню

елемента А відповідають багато (більше одного) значень, пов'язанню з ним
елементів В. Наприклад, поміж елементами даних "код виробу" (елемент А) і
"кодом матеріалів" (елементи В) існує такий взаємозв'язок бо на виготовлення
одного виробу використовується багато різних матеріалів.
Мережна модель даних (рис. 1.2) представляє собою орієнтований граф з
пойменованими вершинами і дугами. Вершини графа - записи, які представляють
собою по іменовану сукупність логічних взаємозв'язаних елементів даних або
агрегатів даних. Під агрегатом даних розуміють сукупність елементів даних, які є
усередині запису. Для кожного типу записів може бути кілька екземплярів
конкретних значень його інформаційних елементів Два записи, взаємозв'язані
дугою, створюють набір даних. Запис, з якого виходить дуга, називається
власником набору, а запис, до якого вона направлена, - членом набору. [2]
10
Рисунок 1.2 – Графічне зображення мережної структури даних
В реляційній моделі зв'язок "багатьох до багатьох" (N:N) указує на те, що

декільком значенням елементів даних А відповідає декілька значені елементів
даних В. Наприклад, між елементами даних "код операції технологічного
процесу" і "табельний номер працівника" існує зазначений взаємозв'язок, так як
багато операцій технологічного процесу можуть виконувати різні працівники
(табельні номери) і навпаки.
Реляційна модель даних являє собою набір двомірних плоских таблиць, що
складаються з рядків і стовпців. Первинний документ або лінійний масив являє
собою плоску двомірну таблицю. Така таблиця називається відношенням, кожний
стовбець-атрибутом, сукупність значень одного типу (стовпця) – доменом, а рядка
– кортежем. Таким чином, стовпці таблиці являються традиційними елементами
даних, а рядки – записами. Таблиці (відношення) мають імена. Імена також
присвоюються і стовпцям таблиці. Кожний кортеж (запис ) відношення має ключ.
Ключі є прості і складні. Простий ключ-це ключ, який складається з одного
атомарного атрибуту, значення якого унікальне (яке не повторюються). Складний
ключ складається з двох і більше атрибутів. Для зв’язків відношень друг з другом
в базі даних є зовнішні ключі. Атрибут або комбінація атрибута відношення є
зовнішнім ключем, якщо він не є основним (первинним) ключем цього
відношення, але являється первинним ключем для другого відношення. [3]
СУБД - це програмне забезпечення, за допомогою якого користувачі
можуть визначати, створювати і підтримувати базу даних, а також здійснювати до
11
неї контрольований доступ. За ступенем універсальності розрізняють два класи

СУБД - системи загального призначення і спеціалізовані системи.
СУБД загального призначення не орієнтовані на якусь конкретну
предметну область або на інформаційні потреби конкретної групи користувачів.
Кожна система такого роду реалізується як програмний продукт, здатний
функціонувати на деякій моделі ЕОМ в певній операційній обстановці. СУБД
загального призначення має засоби налаштування на роботу з конкретною БД в
умовах конкретного застосування. У деяких ситуаціях СУБД загального
призначення не дозволяють добитися необхідних проектних та експлуатаційних
характеристик (продуктивність, обсяг пам'яті). Проте створення спеціалізованих
СУБД досить трудомісткий процес і для того, щоб його реалізувати, потрібні
дуже вагомі підстави. У процесі реалізації своїх функцій СУБД постійно
взаємодіє з базою даних і з іншими прикладними програмними продуктами
користувача, призначеними для роботи з даною БД і додатками. Для того щоб
СУБД успішно справлялася зі своїми завданнями, вона повинна володіти певними
можливостями. [4]
Функції СУБД:
1) управління даними в зовнішній пам'яті. Ця функція надає
користувачам можливості виконання основних операцій, які здійснюються з
даними, - це збереження, вилучення та оновлення інформації. Вона включає в
себе забезпечення необхідних структур зовнішньої пам'яті як для зберігання
даних, які безпосередньо входять в БД, так і для службових цілей, наприклад
для прискорення доступу до даних;
2) управління транзакціями. Транзакція - це послідовність операцій над
БД, розглянутих як єдине ціле. Транзакція є набором дій, які виконуються з
метою доступу або зміни вмісту бази даних. Прикладами простих транзакцій
може служити додавання, оновлення або видалення в базі даних відомостей
про певний об'єкт. Складна ж транзакція утворюється в тому випадку, коли в
базу даних потрібно внести відразу кілька змін;
12
3) відновлення бази даних. Однією з основних вимог до СУБД є

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

буферів;
8) контроль доступу до даних. СУБД повинна мати механізм, який
гарантує можливість доступу до бази даних тільки санкціонованих
користувачів і захищає її від будь-якого несанкціонованого доступу. В
сучасних СУБД підтримується один з двох поширених підходів до питання
забезпечення безпеки даних: вибірковий підхід або обов'язковий підхід. У
більшості сучасних систем передбачається вибірковий підхід, при якому
якийсь користувач має різні права при роботі з різними об'єктами;
9) підтримка цілісності даних. Термін цілісність використовується для
опису коректності та несуперечності збережених в БД даних. Реалізація
підтримки цілісності даних припускає, що СУБД повинна містити відомості
про ті правила, які не можна порушувати при роботі з даними, і володіти
інструментами контролю за тим, щоб дані та їх зміни відповідали заданим
правилам. [5]
За типом керованої бази даних СУБД поділяються на [6]:
1) ієрархічні;
2) мережеві;
3) реляційні;
4) об'єктно-орієнтовані;
5) об'єктно-реляційні.
Ієрархічні СУБД - підтримують деревоподібну організацію інформації.
Зв'язки між записами виражаються у вигляді відношень предок/нащадок, а у
кожного запису є рівно один батьківський запис. Коли запис видаляється з дерева,
всі його нащадки також повинні бути видалені.
Ієрархічні бази даних мають централізовану структуру, тобто безпеку даних
легко контролювати. На жаль, певні знання про фізичний порядок зберігання
записів все ж необхідні, так як відношення предок/нащадок реалізуються у
вигляді фізичних покажчиків з одного запису на інший. Це означає, що пошук
14
запису здійснюється методом прямого обходу дерева. Записи, розташовані в одній

половині дерева, знаходяться швидше, ніж в інший.
Мережева модель розширює ієрархічну модель СУБД, дозволяючи
групувати зв'язки між записами в множини. З логічної точки зору зв'язок - це не
сам запис. Зв'язки лише висловлюють відносини між записами. Як і в ієрархічній
моделі, зв'язки ведуть від батьківського запису до дочірнього, але цього разу
підтримується множинне наслідування.
Дотримуючись специфікації CODASYL, мережева модель підтримує DDL
(Data Definition Language - мова визначення даних) і DML (Data Manipulation
Language - мова обробки даних). Це спеціальні мови, призначені для визначення
структури бази даних і складання запитів.
У мережній моделі допускаються відносини "багато до багатьох", а записи
не залежать одне від одного. При видаленні записи видаляються і всі її зв'язки,
але не самі пов'язані записи. [7]
У мережній моделі потрібно, щоб зв'язки встановлювалися між існуючими
записами щоб уникнути дублювання і спотворення цілісності. Дані можна
ізолювати в відповідних таблицях і пов'язати з записами в інших таблицях.
У реляційній моделі база даних являє собою централізоване сховище
таблиць, що забезпечує безпечний одночасний доступ до інформації з боку
багатьох користувачів. У рядках таблиць частина полів містить дані, що
стосуються безпосередньо до запису, а частина - посилання на записи інших
таблиць. Таким чином, зв'язки між записами є невід'ємною властивістю
реляційної моделі.
Кожен запис таблиці має однакову структуру. Наприклад, в таблиці, яка
містить описи автомобілів, у всіх записів буде один і той же набір полів:
виробник, модель, рік випуску, пробіг і т.д. Такі таблиці легко зображувати в
графічному вигляді.
У реляційній моделі СУБД досягається інформаційна та структурна
незалежність. Записи не пов'язані між собою настільки, щоб зміна одного з них
15
торкнулося інших, а зміна структури бази даних не обов'язково призводить до

перекомпіляції з нею додатків, що з нею працюють.
У реляційних СУБД застосовується мова SQL, що дозволяє формулювати
довільні, нерегламентовані запити.
Об'єктно-орієнтовані СУБД дозволяють програмістам, які працюють з
мовами третього покоління, інтерпретувати всі свої інформаційні сутності як
об'єкти, що зберігаються в оперативній пам'яті. Додатковий рівень інтерфейсу
забезпечує перехоплення запитів, що звертаються до тих частин бази даних, які
знаходяться в постійному сховищі на диску. Зміни, що вносяться до об'єктів,
оптимальним чином переносяться з пам'яті на диск.
Великим недоліком об'єктно-орієнтованих баз даних є їх тісний зв'язок з
застосовуваним мовою програмування. До даних, що зберігаються в реляційній
СУБД, можуть звертатися будь-які додатки, тоді як, наприклад, Java-об'єкт,
поміщений в ООСУБД, буде становити інтерес лише для додатків, написаних на
Java. [8]
Об'єктно-реляційні СУБД об'єднують в собі риси реляційної та об'єктної
моделей. Їх виникнення пояснюється тим, що реляційні бази даних добре
працюють з вбудованими типами даних і набагато гірше - до призначених для
користувача, нестандартними. Коли з'являється новий важливий тип даних,
доводиться або включати його підтримку в СУБД, або змушувати програміста
самостійно управляти даними в додатку.
Перебудова архітектури СУБД з метою включення в неї підтримки нового
типу даних - не кращий вихід з положення. Замість цього об'єктно-реляційна
СУБД дозволяє завантажувати код, призначений для обробки "нетипових" даних.
Таким чином, база даних зберігає свою табличну структуру, але спосіб обробки
деяких полів таблиць визначається ззовні, тобто програмістом.
За архітектурою СУБД і організації зберігання даних:
1) локальні СУБД (всі частини локальної СУБД розміщуються на
одному комп'ютері);
16
2) розподілені СУБД (частини СУБД можуть розміщуватися на двох і

більше комп'ютерах).
За способом доступу до бази даних СУБД поділяються на:
1) файл-серверні СУБД;
2) клієнт-серверні СУБД;
3) вбудовувані СУБД.
Файл-серверні СУБД. У файл-серверних СУБД файли даних
розташовуються централізовано на файл-сервері СУБД. Ядро СУБД
розташовується на кожному клієнтському комп'ютері. Доступ до даних
здійснюється через локальну мережу. Синхронізація читань і оновлень
здійснюється за допомогою файлових блокувань. Перевагою цієї архітектури є
низьке навантаження на ЦП сервера, а недоліком - високе завантаження локальної
мережі; ускладненість або неможливість централізованого управління;
ускладненість або неможливість забезпечення таких важливих характеристик як
висока надійність, висока доступність і висока безпека. Застосовуються
найчастіше в локальних додатках, які використовують функції управління БД; в
системах з низькою інтенсивністю обробки даних і низькими піковими
навантаженнями на БД. [9]
На даний момент файл-серверна технологія вважається застарілою.
Приклади: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.
Клієнт-серверні СУБД. Такі СУБД складаються з клієнтської частини (яка
входить до складу прикладної програми) і сервера СУБД (див. Клієнт-сервер).
Клієнт-серверні СУБД, на відміну від файл-серверних, забезпечують
розмежування доступу між користувачами і мало завантажують мережу і
клієнтські машини. Сервер є зовнішньою по відношенню до клієнта програмою, і
по потребі його можна замінити іншим. Недолік клієнт-серверних СУБД в самому
факті існування сервера СУБД (що погано для локальних програм - в них
зручніше вбудовуються СУБД) і великих обчислювальних ресурсах, споживаних
сервером.
17
Приклади: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server,

Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, Лінтера.
Вбудовувані СУБД. Вбудована СУБД - бібліотека, яка дозволяє
уніфікованим чином зберігати великі обсяги даних на локальній машині. Доступ
до даних може відбуватися через SQL або через особливі функції СУБД.
Вбудовувані СУБД швидше звичайних клієнт-серверних і не вимагають
установки сервера, тому затребувані в локальному ПЗ, яке має справу з великими
обсягами даних (наприклад, геоінформаційні системи). [10]
Приклади: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL
Server Compact, Лінтера.
Інформаційні системи, створені засобами технології баз даних, іноді
прийнято називати банками даних (БНД). БНД включає в себе:
1) технічні засоби;
2) одну або кілька БД;
3) СУБД;
4) словник або каталог даних;
5) адміністратора;
6) обчислювальну систему;
7) обслуговуючий персонал.
1.3 Обґрунтування вибору СУБД
Проаналізувавши деякі СУБД було виявлено ряд недоліків, а саме:

1) для PostgreSQL:
а) PostgreSQL порівняно з іншими СУБД працює повільно;
б) складно знайти хостинг з підтримкою цієї СУБД;
2) для MySQL:
а) відомі обмеження - в MySQL закладені деякі обмеження
функціоналу, які іноді необхідні в особливо вимогливих додатках;
б) проблеми з надійністю - через деякі способи обробки даних MySQL
(зв'язки, транзакції, аудити) іноді поступається іншим СУБД по надійності;
18
3) SQLite:
а) відсутність системи користувачів - більшість СУБД включають в
свій склад системи управління правами доступу користувачів;
б) відсутність можливості збільшення продуктивності.
Беручи до уваги недоліки розглянутих СУБД для виконання завдання
курсової роботи, а саме створення бази даних для електронного журналу
користувача було обрано СУБД MS SQL через вбудовану підтримку .NET
Framework, платформи, що буде використана для написання клієнтського додатку
для роботи з базою даних, що буде розроблена. Завдяки цій підтримці, процедури
бази даних, що зберігаються, можуть бути написані на будь-якій мові
платформи .NET з використанням повного набору бібліотек, доступних для .NET
Framework. На відміну від інших процесів, .NET Framework виділяє додаткову
пам'ять і будує засоби керування SQL Server, не використовуючи вбудовані
засоби Windows. Це підвищує продуктивність порівняно із загальними
алгоритмами Windows, оскільки алгоритми розподілу ресурсів спеціально
налагоджені для використання у структурах SQL Server.
Microsoft SQL Server — комерційна система керування базами даних, що
розповсюджується корпорацією Microsoft. Мова, що використовується для запитів
— Transact-SQL, створена спільно Microsoft та Sybase. Transact-SQL є реалізацією
стандарту ANSI/ISO щодо структурованої мови запитів (SQL) із розширеннями.
Використовується як для невеликих і середніх за розміром баз даних, так і для
великих баз даних масштабу підприємства.
Microsoft SQL Server як мову запитів використовує версію SQL, що
отримала назву TRANSACT-SQL (скорочено T-SQL), яка є реалізацією SQL-92
(стандарт ISO для SQL) з багатьма розширеннями. T-SQL дозволяє
використовувати додатковий синтаксис процедур, що зберігаються і забезпечує
підтримку транзакцій (взаємодія бази даних з керуючим застосунком). Microsoft
SQL Server та Sybase ASE для взаємодії з мережею використовують протокол
рівня застосунка під назвою Tabular Data Stream (TDS, протокол передачі
табличних даних).
19
Microsoft SQL Server також підтримує Open Database Connectivity (ODBC)

— інтерфейс взаємодії застосунків з СУБД. Версія SQL Server 2005 надає
можливість підключення користувачів через веб-сервер-сервіси, що
використовують протокол SOAP. Це дозволяє клієнтським програмам, не
призначеним для Windows, кроссплатформенно з'єднуватися з SQL Server.
Microsoft також випустила сертифікований драйвер JDBC, що дозволяє
застосункам під керування Java (таким як BEA і IBM Websphere) з'єднуватися з
Microsoft SQL Server 2000 і 2005.
SQL Server підтримує дзеркалювання та кластеризацію баз даних. Кластер
серверу SQL — це сукупність однаково конфігурованих серверів; така схема
допомагає розподілити робоче навантаження між декількома серверами. Усі
сервери мають одне віртуальне ім'я, а дані розподіляються за IP-адресами машин
кластеру протягом робочого циклу. Також у разі відмови або збою на одному з
серверів кластеру доступне автоматичне перенесення навантаження на інший
сервер.
SQL Server підтримує надлишкове дублювання даних за трьома сценаріями:
1) знімок: виконується «знімок» бази даних, який сервер відправляє
одержувачам;
2) історія змін: всі зміни бази даних безперервно передаються
користувачам;
3) синхронізація з іншими серверами: бази даних декількох серверів
синхронізуються між собою. Зміни усіх баз даних відбуваються незалежно на
кожному сервері, а під час синхронізації відбувається звірка даних.
Дублювання такого типу передбачає можливість вирішення протиріч між
базами даних.
1.4 Обґрунтування вибору мови програмування
Оскільки для створення бази даних було обрано СУБД MS SQL, то для
створення клієнтського додатку найкращим рішенням є програмний каркас
ASP.NET MVC, який, як і MS SQL, є продуктом компанії Microsoft і має досить
20
високий рівень взаємодії з компонентами цієї СУБД. Інші мови програмування, як

наприклад PHP, та програмні каркаси, що написані на їх основі, значно
ускладнюють процес взаємодії MS SQL та програмних додатків. ASP.NET MVC
який використовується для написання веб-додатків та реалізує шаблон розробки
MVC (Model-View-Controller). Платформа ASP.NET MVC базується на взаємодії
трьох компонентів: контролера, моделі та представлення. Контролер приймає
запити, обробляє введені користувачем дані, взаємодіє з моделлю і
представленням і повертає користувачеві результат обробки запиту.
Модель являє рівень абстракції, що описує логіку організації даних в
додатку. Представлення отримує дані з контролера і генерує елементи
призначеного для користувача інтерфейсу для відображення інформації.
Представлення повертається у вигляді звичайної веб-сторінки з html-розміткою,
що спрощує її стилізацію та візуальне оформлення для зручності користувача.
Програмний каркас ASP.NET створений мовою програмування C#. C# -
об'єктно-орієнтована мова програмування з безпечною системою типізації для
платформи .NET. Розроблена Андерсом Гейлсбергом, Скотом Вілтамутом та
Пітером Гольде під егідою Microsoft Research (при фірмі Microsoft).
Синтаксис C# близький до С++ і Java. Мова має строгу статичну типізацію,
підтримує поліморфізм, перевантаження операторів, вказівники на функції-члени
класів, атрибути, події, властивості, винятки, коментарі у форматі XML.
Перейнявши багато що від своїх попередників — мов С++, Delphi, Модула і
Smalltalk — С#, спираючись на практику їхнього використання, виключає деякі
моделі, що зарекомендували себе як проблематичні при розробці програмних
систем, наприклад множинне спадкування класів (на відміну від C++).
Також при розробці буде застосований EntityFramework 6, який дозволяє
працювати з сутностями бази даних як з класами мови програмування C#. Це
значно спрощує розробку, масштабування проектів написаних цією мовою,
полегшує доступ до бази даних та обробку даних та значно зменшує кількість
коду, що має бути написаний.
21
Для взаємодії всіх вищеописаних компонентів та зручного керування ними

буде використане середовище розробки MS Visual Studio 2015. Середовище
дозволяє створювати додатки для будь-яких платформ, є дуже продуктивним,
оскільки вміщує в собі безліч інструментів та функцій, серед яких проста
взаємодія з MS SQL Server, на якому і знаходитиметься база даних, що
розробляється, можливість покроково слідкувати за роботою програми, виявляти
можливі помилки та отримувати вказівки щодо їх виправлення.
1.5 Висновки
В даному розділі було описано основні поняття про бази даних та системи
управління базами даних. Наведено інформацію про моделі існуючих систем.
Проведено аналіз предметної області згідно індивідуального завдання. В
наступному розділі буде проведено проектування бази даних за допомогою
методів сутність-зв’язок та нормалізації.
В розділі здійснено обгрунтування вибору СУБД та мови програмування
для створення бази даних та клієнтського додатку.
22
2 ПРОЕКТУВАННЯ БАЗИ ДАНИХ
Предметна область курсової роботи охоплює такі поняття як «присутність»,

«урок», «оцінка», «студент», «викладач» та інші. На основі аналізу предметної
області, приведеного в першому розділі, буде проведено проектування бази даних
за допомогою методів сутність-зв’язок, нормалізації відношень, а також
побудовано ER-модель бази даних.
2.1 Проектування методом сутність-зв'язок
Проектування методом сутність–зв’язок складається з таких етапів:

1) визначення сутностей;
2) визначення зв`язків;
3) визначення атрибутів;
4) визначення ключів сутностей;
5) визначення ступеня зв`язку;
6) визначення класу належності.
На першому етапі необхідно визначити сутності, що повністю описують
предметну область в рамках поставленої задачі. Для створення бази даних
«Електронний журнал викладача» потрібні такі сутності: ОСОБА, РОЛЬ, ГРУПА,
ФАКУЛЬТЕТ, ПРЕДМЕТ, СЕМЕСТР, РІК_НАВЧАННЯ, НОМЕР_УРОКУ,
УРОК, РОЗКЛАД, ПРИСУТНІСТЬ, ОСНОВНИЙ_РОЗКЛАД,
ДОДАТКОВИЙ_РОЗКЛАД.
На другому етапі необхідно визначити зв’язки між сутностями:
ОСОБА – має – РОЛЬ,
ГРУПА – містить – ОСІБ,
ФАКУЛЬТЕТ – має – ГРУПИ,
РІК_НАВЧАННЯ – містить – СЕМЕСТРИ,
РОЗКЛАД – визначає – УРОК,
УРОК – визначає – ПРИСУТНІСТЬ,
23
РОЗКЛАД – визначає – НОМЕР_УРОКУ,

РОЗКЛАД – має – ПРЕДМЕТ,
РОЗКЛАД – визначає – ОСОБУ (викладача),
РОЗКЛАД – розширює – ОСНОВНИЙ_РОЗКЛАД,
РОЗКЛАД – розширює – ДОДАТКОВИЙ_РОЗКЛАД,
ГРУПА – має – РОЗКЛАД,
СЕМЕСТР – містить – РОЗКЛАД.
ПРИСУТНІСТЬ – визначає – ОСОБУ (студент)
На третьому етапі потрібно визначити властивості (атрибути) вказаних
сутностей, що повністю розкриють їх зміст:
РОЛЬ (Ід_ролі, Назва)
ОСОБА (Ід_особи, ПІБ, Email)
ГРУПА (Ід_групи, Назва, Ід_факультету)
ФАКУЛЬТЕТ (Ід_факультету, Назва)
ПРЕДМЕТ (Ід_предмета, Назва)
СЕМЕСТР (Ід_семестру, Тип_семестру, Початок, Кінець)
РІК_НАВЧАННЯ (Ід_року, Рік)
НОМЕР_УРОКУ (Ід_уроку, Номер_уроку, Час_початку, Час_закінчення)
УРОК (Ід_розкладу, Тема, Дата)
РОЗКЛАД (Ід_розкладу, Номер_уроку, Тип_уроку, Аудиторія, Викладач,
Предмет, Ід_семестру, Тип_семестру)
ПРИСУТНІСТЬ (Ід_присутності, Ід_особи, Тип_присутності, Урок, Оцінка)
ОСНОВНИЙ_РОЗКЛАД (Ід_розкладу, День_тижня_основного розкладу)
ДОДАТКОВИЙ_РОЗКЛАД (Ід_розкладу, Дата_додаткового_розкладу)
На четвертому етапі необхідно вказати первинні ключі сутностей. Ключем
сутності називається атрибут або набір атрибутів, що дозволяють однозначно
ідентифікувати екземпляр сутності. У вказаних сутностей будуть такі ключі:
РОЛЬ (<Ід_ролі>, Назва)
ОСОБА (<Ід_особи>, ПІБ, Email)
ГРУПА (<Ід_групи>, Назва, Ід_факультету)
24
ФАКУЛЬТЕТ (<Ід_факультету>, Назва)

ПРЕДМЕТ (<Ід_предмета>, Назва)
СЕМЕСТР (<Ід_семестру>, Тип_семестру, Початок, Кінець)
РІК_НАВЧАННЯ (<Ід_року>, Рік)
НОМЕР_УРОКУ (<Ід_уроку>, Номер_уроку, Час_початку, Час_закінчення)
УРОК (<Ід_розкладу>, Тема, Дата)
РОЗКЛАД (<Ід_розкладу>, Номер_уроку, Тип_уроку, Аудиторія, Викладач,
Предмет, Семестр, Тип_семестру)
ПРИСУТНІСТЬ (<Ід_присутності>, Ід_особи, Тип_присутності, Урок,
Оцінка)
ОСНОВНИЙ РОЗКЛАД (<Ід_розкладу>, День_тижня_основного_розкладу)
ДОДАТКОВИЙ РОЗКЛАД (<Ід_розкладу>, Дата_додаткового_розкладу)
На п`ятому та шостому етапах необхідно визначити ступені зв`язків між
сутностями та класи їх належності. Ступінь зв`язку показує скільки зв`язків може
мати кожен екземпляр сутності з екземпляром сутності, з якою він зв`язаний.
Клас належності може бути обов’язковим та необов’язковим, якщо екземпляри
даної сутності повинні приймати учать у зв’язку, то участь називається
обов’язковою, а якщо екземпляри можуть не приймати участь у зв’язку то
необов’язковою. Зв’язок, що пов’язує дві сутності називається бінарним.
Схематично зв’язки показані на рисунках 2.1, 2.2, 2.3.
25
Рисунок 2.1 – Аналіз зв’язку сутностей ГРУПА та ОСОБА

Оскільки ступінь бінарного зв’язку даних сутностей є M:N, то для
зберігання даних необхідно 3 відношення:
СТУДЕНТИ_ГРУПИ (<Ід_особи, Ід_групи>), де СТУДЕНТИ_ГРУПИ –
відношення, що використовується для зв'язку сутностей ОСОБА і ГРУПА.
Ключем цього відношення буде сукупність ключів сутностей, які воно пов'язує.
Аналогічно, ступінь зв’язку ГРУПА – має – РОЗКЛАД є M:N, тому маємо 3
відношення:
РОЗКЛАД (<Ід_розкладу>, Номер_уроку, Тип_уроку, Аудиторія, Викладач,
Предмет, Семестр, Тип_семетру)
РОЗКЛАД_ГРУПИ (<Ід_розкладу>, <Ід_групи>), де РОЗКЛАД_ГРУПИ –
відношення, що використовується для зв'язку сутностей РОЗКЛАД і ГРУПА.
Ключем цього відношення буде сукупність ключів сутностей, які воно пов'язує.
Ступінь зв’язку ОСОБА – має – РОЛІ є M:N, тому маємо 3 відношення:
РОЛЬ (<Ід_ролі>, Назва)
РОЛІ_ОСОБИ (<Ід_ролі>, <Ід_особи>), де РОЛІ_ОСОБИ – відношення, що
використовується для зв'язку сутностей РОЛЬ і ОСОБА. Ключем цього
відношення буде сукупність ключів сутностей, які воно пов'язує.
26
Рисунок 2.2 – Аналіз зв’язку сутностей ФАКУЛЬТЕТ та ГРУПА

Аналогічно УРОК – визначає – ПРИСУТНІСТЬ, РІК_НАВЧАННЯ – містить
– СЕМЕСТРИ, СЕМЕСТР – містить – РОЗКЛАД, РОЗКЛАД – визначає – ОСОБУ
(викладач), ПРИСУТНІСТЬ – визначає – ОСОБА, РОЗКЛАД – визначає –
НОМЕР_УРОКУ, РОЗКЛАД – має – ПРЕДМЕТ, РОЗКЛАД – визначає – УРОК.
Рисунок 2.3 – Аналіз зв’язку сутностей РОЗКЛАД та ОСНОВНИЙ_РОЗКЛАД
Ступінь бінарного зв’язку – 1:1, клас належності однієї сутності є

обов’язковим, а іншої необов’язковим, тому утворюється 2 відношення. На кожну
сутність виділяється одне відношення з відповідним ключем. Ключ сутності, для
якої клас належності є необов’язковим додається в якості атрибуту у відношення,
що виділене для сутності з обов’язковим класом належності.
Аналогічним є зв’язок сутностей РОЗКЛАД – вказує –
ДОДАТКОВИЙ_РОЗКЛАД.
2.2 Проектування ER-моделі
На основі даних, отриманих в ході проектування бази даних методом

сутність-зв’язок, необхідно створити ER-модель.
Бінарний зв'язок ГРУПА – містить – ОСІБ (рис. 2.4) має ступінь зв’язку M:N
та клас належності О:О. Відповідно до цих параметрів необхідно використання
трьох відношень: по одному для кожної сутності з відповідними ключами
(ОСОБА (<Ід_особи>, ПІБ, Email, Пароль), ГРУПА (<Ід_групи>, Назва,
Ід_факультету)) та одного відношення для зв’язку, що формується з ключів
27
кожної сутності. Ключем цього відношення буде сукупність ключів двох

сутностей (ОСОБИ_ГРУПИ (<Ід_групи, Ід_особи>)).
ОСОБА ГРУПА ОСОБИ_ГРУПИ
<Ід_особи> <Ід_групи> <Ід_особи> <Ід_групи>
1 1 1 2
2 2 2 3
3 3 3 4
4 4 4 1
Рисунок 2.4 – Попередні відношення сутностей ОСОБА та ГРУПА
Так як зв’язки ОСОБА – має – РОЛЬ та ГРУПА – має – РОЗКЛАД мають

такі ж класи належності та ступені зв’язку, то їх відношення будуть побудовані за
таким самим правилом.
Бінарний зв'язок ФАКУЛЬТЕТ – має – ГРУПИ (рис. 2.5) має ступінь зв'язку
1:N, де ФАКУЛЬТЕТ – N-зв’язна сутність та ГРУПА – однозв’язна сутність, та
клас належності О:НО, де однозв’язна сутність є необов’язковою. Тому достатнім
є використання двох відношень – по одному на кожну сутність. За умови, що
ключі залишаються такі ж як у сутностей. Додатково ключ N-зв’язної сутності
додається як атрибут у відношення, що відводиться для однозв’язної сутності.
ФАКУЛЬТЕТ ГРУПА
<Ід_факультету> <Ід_групи> Ід_факультету
1 1 3
2 2 4
3 3 1
4 4 2
Рисунок 2.5 – Попередні відношення сутностей ФАКУЛЬТЕТ та ГРУПА
Зв'язки УРОК – визначає – ПРИСУТНІСТЬ, РІК_НАВЧАННЯ – містить –

СЕМЕСТРИ, СЕМЕСТР – містить – РОЗКЛАД, РОЗКЛАД – визначає – ОСОБУ
(викладач), ПРИСУТНІСТЬ – визначає – ОСОБУ (студент), РОЗКЛАД – визначає
28
– НОМЕР_УРОКУ, РОЗКЛАД – має – ПРЕДМЕТ, РОЗКЛАД – визначає – УРОК

мають такі ж класи належності та ступені зв'язку, тому їх відношення будуть
побудовані за таким самим принципом.
Для зв'язку РОЗКЛАД – розширює – ДОДАТКОВИЙ_РОЗКЛАД (рис. 2.6)
ступінь бінарного зв’язку – 1:1, клас належності сутності РОЗКЛАД є
обов’язковим, а ДОДАТКОВИЙ_РОЗКЛАД – необов’язковим, тому утворюється
2 відношення. На кожну сутність виділяється одне відношення з відповідним
ключем. Ключ сутності, для якої клас належності є необов’язковим додається в
якості атрибуту у відношення, що виділене для сутності з обов’язковим класом
належності.
ДОДАТКОВИЙ_РОЗКЛАД РОЗКЛАД
<Ід_ додаткового_ розкладу> < Ід_розклад> Ід_додаткового_розкладу
1 1 3
2 2 4
3 3 1
4 4 2
Рисунок 2.6 – Попередні відношення сутностей ДОДАТКОВИЙ_РОЗКЛАД та

РОЗКЛАД
Зв'язки РОЗКЛАД – розширює – ДОДАТКОВИЙ_РОЗКЛАД мають такі ж

класи належності та ступені зв'язку, тому їх відношення будуть побудовані за
таким самим принципом.
ER-модель бази даних «Електронний журнал викладача» наведено на рис.
2.10.
29
Рисунок 2.10 – ER-модель бази даних для предметної області «Електронний

журнал викладача»
2.3 Метод нормалізації відношень
Нормалізація схеми бази даних — покроковий процес розбиття одного

відношення (на практиці: таблиці) відповідно до алгоритму нормалізації на
декілька відношень на базі функціональних залежностей.
Нормальна форма — властивість відношення в реляційній моделі даних, що
характеризує його з точки зору надмірності, яка потенційно може призвести до
логічно помилкових результатів вибірки або зміни даних. Нормальна форма
визначається як сукупність вимог, яким має задовольняти відношення.
30
Таким чином, схема реляційної бази даних переходить у першу, другу,

третю і так далі нормальні форми. Якщо відношення відповідає критеріям
нормальної форми n, та всіх попередніх нормальних форм, тоді вважається, що це
відношення знаходиться у нормальній формі рівня n.
Сформуємо універсальне відношення з атрибутів сутностей, що розглянуті
підрозділі 2.1.
R – універсальне відношення, має такі атрибути – (Ід_ролі, Назва_ролі,
Ід_особи, ПІБ, Email, Ід_групи, Назва_групи, Ід_факультету, Назва_факультету,
Ід_предмета, Назва_предмета, Ід_семестру, Тип_семестру, Початок, Кінець,
Ід_року, Рік, Ід_уроку, Номер_уроку, Час_початку, Час_закінчення, Ід_розкладу,
Тема, Дата_уроку, Ід_розкладу, Тип_уроку, Аудиторія, Викладач, Предмет,
Семестр, Ід_присутності, Тип_присутності, Урок, Оцінка, Ід_основного_розкладу,
День_тижня_уроку, Ід_додаткового_розкладу, Дата_додаткового_розкладу).
I НОРМАЛЬНА ФОРМА. Знайдемо первинний ключ універсального
відношення, від якого залежать всі атрибути. Таким первинним ключем є
<Ід_присутності> .
R (<Ід_присутності>, Ід_ролі, Назва_ролі, Ід_особи, ПІБ, Email, Пароль,
Ід_групи, Назва_групи, Ід_факультету, Назва_факультету, Ід_предмета,
Назва_предмета, Ід_семестру, Тип_семестру, Початок, Кінець, Ід_року, Рік,
Ід_уроку, Номер_уроку, Час_початку, Час_закінчення, Ід_розкладу, Тема,
Дата_уроку, Ід_розкладу, Тип_уроку, Аудиторія, Викладач, Предмет, Семестр,
Тип_присутності, Урок, Оцінка, Ід_розкладу_основного, День_тижня_уроку,
Ід_розкладу_додаткового, Дата_додаткового_розкладу).
ІІ НОРМАЛЬНА ФОРМА. Відношення може вважатись приведеним до
другої нормальної форми, якщо воно знаходиться в першій нормальній формі і
кожний не ключовий атрибут функціонально-повно залежить від складеного
ключа.
Первиними ключами є <Ід_присутності>, <Ід_розкладу, Ід_групи>,
<Ід_групи, Ід_особи>, <Ід_ролі, Ід_особи>, з яких три останні є складеними
ключами.
31
R1 = (<Ід_присутності>, Ід_особи_студента, ПІБ, Email, Тип_присутності,

Ід_уроку, Тема, Дата Оцінка, Ід_розкладу, Ід_номеру_уроку, Номер_уроку,
Час_початку_уроку, Час_закінчення_уроку, Тип_уроку, Аудиторія,
Ід_особи_викладача, ПІБ, Email, Ід_предмету, Назва_предмету, Ід_семестру,
Тип_семетру, Старт_семестру, Кінець_семестру, Ід_року, Назва_року,
Ід_розкладу_основного, День_тижня_уроку, Ід_розкладу_додаткового,
Дата_додаткового_розкладу)
R2 (РОЗКЛАД_ГРУПИ) = (<Ід_розкладу, Ід_групи>)
Від частини <Ід_розкладу> ключа <Ід_розкладу, Ід_групи> залежать:
R3 = (<Ід_розкладу>, Номер_уроку, Тип_уроку, Аудиторія, Ід_особи, ПІБ,
Email, Пароль, Ід_предмету, Назва_предмету, Ід_семестру, Тип_семетру,
Старт_семестру, Кінець_семестру, Ід_року, Назва_року, Ід_розкладу_основного,
День_тижня_уроку, Ід_розкладу_додаткового, Дата_додаткового_розкладу).
Від частини < Ід_групи> ключа <Ід_розкладу, Ід_групи> залежать:
R4 = (<Ід_групи>, Назва, Ід_факультету, Назва_факультету),
R5 (СТУДЕНТИ_ГРУПИ) = (<Ід_групи, Ід_особи>).
Від частини < Ід_групи> ключа <Ід_групи, Ід_особи> залежать:
R6 = (<Ід_групи>, Назва, Ід_факультету, Назва_факультету).
Від частини < Ід_особи> ключа <Ід_групи, Ід_особи> залежать:
R7 (ОСОБА) = (<Ід_особи>, ПІБ, Email, Пароль)
R8 (РОЛІ_ОСОБИ) = (<Ід_ролі, Ід_особи>)
Від частини <Ід_ролі> ключа <Ід_ролі, Ід_особи> залежать:
R9 (РОЛЬ) = (<Ід_ролі>, Назва)
Від частини < Ід_особи> ключа <Ід_ролі, Ід_особи> залежать
III НОРМАЛЬНА ФОРМА. Відношення знаходиться в третій нормальній
формі, якщо воно знаходиться в другій нормальній формі і кожен його не
ключовий атрибут нетранзитивно залежить від первинного ключа. Тобто, щоб
звести отримане відношення до третьої нормальної форми, необхідно усунути
транзитивну залежність. Атрибут С залежить від атрибуту А транзитивно, якщо
32
атрибут А функціонально залежить від атрибуту В, та атрибут В функціонально

залежить від атрибуту С, та зворотна залежність відсутня.
R11 (ПРИСУТНІСТЬ) = (<Ід_присутності>, Ід_особи_студента,
Тип_присутності, Ід_уроку, Оцінка)
R12 (УРОК) = (<Ід_уроку>, Тема, Дата)
R13 (РОЗКЛАД) = (<Ід_розкладу>, Ід_номеру_уроку, Тип_уроку,
Аудиторія, Ід_особи, Ід_предмету, Ід_семестру, Ід_року)
R14 (НОМЕР_УРОКУ) = (<Ід_номеру_уроку>, Номер, Час_початку,
Час_закінчення)
R15 (ПРЕДМЕТ) = (<Ід_предмету>, Назва_предмету)
R16 (СЕМЕСТР) = (<Ід_семестру>, Тип_семетру, Старт_семестру,
Кінець_семестру)
R17 (РІК_НАВЧАННЯ) = (<Ід_року>, Назва_року)
R18 (ОСНОВНИЙ_РОЗКЛАД) = (<Ід_основного_розкладу>,
День_тижня_уроку)
R19 (ДОДАТКОВИЙ_РОЗКЛАД) = (<Ід_додаткового_розкладу_>,
R20 (ОСОБА) = (<Ід_особи>, ПІБ, Email)
R21 (ОСОБА) = (<Ід_особи>, Email, ПІБ),
R22 (ПРИСУТНІСТЬ) = (<Ід_присутності>, Ід_особи, Тип_присутності,
Ід_уроку, Оцінка),
R23 (УРОК) = (<Ід_уроку>, Тема, Дата)
R24 (РОЗКЛАД) = (<Ід_розкладу>, Ід_номеру_уроку, Тип_уроку,
Аудиторія, Ід_особи, Ід_предмету, Ід_семестру, Ід_року)
R25 (НОМЕР_УРОКУ) = (<Ід_номеру_уроку>, Номер, Час_початку,
Час_закінчення)
R27 (ПРЕДМЕТ) = (<Ід_предмету>, Назва_предмету)
R28 (СЕМЕСТР) = (<Ід_семестру>, Тип_семеcтру, Старт_семестру,
Кінець_семестру)
33
R29 (РІК_НАВЧАННЯ) = (<Ід_року>, Назва_року)

R30 (ОСНОВНИЙ_РОЗКЛАД) = (<Ід_основного_розкладу>,
День_тижня_уроку)
R31 (ДОДАТКОВИЙ_РОЗКЛАД) = (<Ід_додаткового_розкладу>,
R32 (ГРУПА) = (<Ід_групи>, Назва, Ід_факультету)
R33 (ФАКУЛЬТЕТ) = (<Ід_факультету>, Назва_факультету)
Враховуючи, що в ході нормалізації були отримані дублюючі сутності:
R7=R10=R20=R21=R26, R12=R23, R13=R24, R14=R25, R15=R27, R16=R28,
R17=R29, R18=R30, R19=R31, то необхідно залишити лише одну з дублюючих.
Результуючі сутності: R2, R5, R7, R8, R9, R11, R12, R13, R14, R15, R16,
R17, R18, R19, R32, R33.
В даному розділі було проведено проектування бази даних, за предметною

областю «Електронний журнал викладача», за методом «Сутність-зв'язок» та за
методом нормалізації відношень. Було отримано 16 результуючих сутностей,
встановлено класи належності та ступені зв’язків між сутностями. Побудовано
ER-модель. Дані сутності будуть в подальшому використані для практичної
розробки бази даних.
34
3 ПРАКТИЧНА РЕАЛІЗАЦІЯ БАЗИ ДАНИХ
У попередньому розділі за допомогою методів сутність-зв’язок так

нормалізації було спроектовану базу даних для електронного журналу викладача.
Наступним кроком є практична реалізація таблиць бази даних, створення форм
для зручної роботи користувача з базою, а також створення запитів та звітів.
Розробка здійснюватиметься у середовищі MS Visual Studio 2015 з
використанням SQL Management studio 2014.
3.1 Розробка таблиць
За допомогою технологій ASP.NET MVC та Entity Framework Code First

достатньо описати сутності бази даних у вигляді класів з набором властивостей,
які відповідають атрибутам сутностей, а також зв’язки між сутностями і
програмний каркас сам згенерує таблиці бази даних. Приклад коду для генерації
таблиці сутності ОСОБА
public class User
{
public User()
{
Groups = new HashSet<Group>();
LessonPresences = new HashSet<LessonPresence>();
Roles = new HashSet<Role>();
BaseSchedules = new HashSet<BaseSchedule>();
}
public Guid Id { get; set; }
[Required]
public string Email { get; set; }
[Required]
public string Name { get; set; }
public ICollection<Group> Groups { get; set; }
public virtual ICollection<LessonPresence> LessonPresences { get; set; }
public virtual ICollection<Role> Roles { get; set; }
public ICollection<BaseSchedule> BaseSchedules { get; set;
}
35
Аналогічним чином утворюються таблиці для всіх інших сутностей. Зв’язки

між сутностями можна вказати у вигляді атрибутів до властивостей класу, а також
у контексті створення бази даних:
public static void User(this DbModelBuilder modelBuilder)
{
modelBuilder.Entity<User>()
.ToTable("User")
.HasKey(e => e.Id)
.Property(e => e.Id)
.HasColumnName("Id")
.IsRequired()
.HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);
.Property(e => e.Name)
.HasColumnName("Name")
.IsRequired()
.HasMaxLength(100)
.IsUnicode(true);
.Property(e => e.Email)
.HasColumnName("Email")
.IsRequired()
.HasMaxLength(100)
.IsUnicode(true);
}
Створення контексту бази даних наведено у додатку А.
Для початкового заповнення таблиці осіб використано метод Import(), що
завповнює поля таблиці з файлу з даними, що попередньо підготовлений. Це
досить зручно, оскільки не потрібно здійснювати заповнення таблиці вручну.
public ActionResult Import()
{
var db = new Db();
var file = Server.MapPath("~/App_Data/start.csv");
var groups = db.Groups.ToList();
var students = db.Users.ToList();
var faculty = db.Faculties.Single(e => e.Name == "ФМ");
var studentRole = db.Roles.Single(e => e.Id == Roles.Student);
var teacherRole = db.Roles.Single(e => e.Id == Roles.Teacher);
var adminRole = db.Roles.Single(e => e.Id == Roles.Admin);
using (var fs = new FileStream(file, FileMode.Open, FileAccess.Read, FileShare.None))
{
using (var sr = new StreamReader(fs, Encoding.UTF8))
36
{
while (!sr.EndOfStream)
{
var info = sr.ReadLine().Split(',');
var user =
students.SingleOrDefault(e => e.Email == info[1]);
if (user == null)
{
user = new User
{
Id = Guid.Parse(info[0]),
Email = info[1],
Name = info[2]
};
students.Add(user);
db.Users.Add(user);
}
if (info[3] == "МБІС" || info[3] == "АІМ")
{
if (!user.Roles.Contains(teacherRole))
{
user.Roles.Add(teacherRole);
}
}
else
{
var group = groups.SingleOrDefault(e => e.Name == info[3]);
if (group == null)
{
group = new Group
{
Faculty = faculty,
Name = info[3],
IsDel = false
};
groups.Add(group);
}
if (!user.Groups.Contains(group))
user.Groups.Add(group);
if (!user.Roles.Contains(studentRole))
{
user.Roles.Add(studentRole);
}
}
if (info[1] == "Mariia.Chernetska@vntu.net" && !user.Roles.Contains(adminRole))
{
user.Roles.Add(adminRole);
}
}
37
}
db.SaveChanges();
}
return Content("Completed");
}
Після внесення даних таблиця матиме наступний вигляд (рис. 3.1):
Рисунок 3.1 – Вигляд таблиці «Особа» із заповненими даними
Діаграма реалізованої бази даних виглядає наступним чином (рис. 3.2)
Рисунок 3.2 – Діаграма реалізованої бази даних «Електронний журнал викладача»

38
3.2 Розробка запитів
Так як основною задачею розроблюваного додатку є забезпечення

можливості обліку викладачем відвідуваності уроків студентами, важливими є
запити, за допомогою яких отримується і зберігається дана інформація.
Для більш зручного отримання, обробки та зберігання інформації
використаємо вбудовану мову запитів LINQ, яка входить в склад мови
програмування високого рівня C#.
Сформуємо декілька запитів:
1) запит для отримання інформації про успішність груп університету;
2) запит для отримання детальної інформації про успішність студентів
групи з обраної дисципліни за обраний семестр;
3) запит для отримання розкладу викладача;
4) запит для відображення оцінок та відвідування студентів групи на
певному уроці.
Запит для отримання інформації про успішність груп університету. Для
формування першого запиту визначимо, яку інформацію ми хочемо до нього
помістити. Необхідно відобразити наступну інформацію: назва групи, кількість
відвідувань, кількість оцінок відмінно, кількість оцінок добре, кількість оцінок
задовільно, кількість оцінок незадовільно, кількість пропусків та скільки з них з
поважної причини.
Через наявність великої кількості інформації у базі даних необхідно
обмежити діапазон інформації для обробки в звіті, щоб пришвидшити роботу
додатку. Для цього оберемо діапазон дат, за який і буде отримуватись інформація.
Якщо діапазон не заданий, будемо вважати цей діапазон рівним останнім трьом
місяцям від поточного дня.
В цілому запит для звіту виглядає наступним чином:
var fromDate = (from ?? DateTime.Now.AddMonths(-3)).Date;
var toDate = (to ?? DateTime.Now).Date;
var result = Context.Groups.Select(g => new GroupsReportEntry
{
    Id = g.Id, Name = g.Name, MarksCount = g.Students
39
        .SelectMany(e => e.LessonPresences)
        .Count(e =>
            DbFunctions.TruncateTime(e.Lesson.Date) >= fromDate &&
            DbFunctions.TruncateTime(e.Lesson.Date) <= toDate),
    PerfectCount = g.Students
        .Where(e =>
            DbFunctions.TruncateTime(e.Lesson.Date) <= toDate)
        .Count(e => e.Mark >= 10),
    GoodCount = g.Students
        .Where(e =>
        .Count(e => e.Mark >= 7),
    NotBadCount = g.Students
        .Where(e =>
        .Count(e => e.Mark >= 4),
    BadCount = g.Students
        .Where(e =>
        .Count(e => e.Mark > 0),
    Absent = g.Students
        .Where(e =>
        .Count(e =>
            e.PresenceType == PresenceType.Absent ||
            e.PresenceType == PresenceType.GoodReason),
    GoodReason = g.Students
        .Where(e =>
        .Count(e => e.PresenceType == PresenceType.GoodReason)
});
Для спрощення виконання цього запиту на стороні серверу керування
базами даних використаємо функції бібліотеки DbFunctions, які дозволять
транслювати виклики на отримання лише інформації за певну дату напряму до
СУБД.
40
Запит для отримання детальної інформації про успішність студентів групи з

обраної дисципліни за обраний семестр. Оскільки інформація буде отримана по
певній групі, то необхідно надати можливість користувачеві обрати необхідну
групу зі списку, аналогічно необхідно надати вибір дисципліни та семестру. Через
невелику вибірку інформації немає необхідності в обмеженні часового діапазону,
порівняно з попереднім звітом.
Для кожного студента групи необхідно отримувати наступну інформацію:
ПІБ, кількість оцінок, кількість пропущених занять та середній бал.
Вибір дисциплін та семестрів будемо здійснювати лише з тих, що є у
розкладі:
var @group = Context.Groups.Single(e => e.Id == groupId);
var disciplines = @group.Schedules.Select(e => e.Discipline).Distinct().ToList();
var semesters = @group.Schedules.Select(e => e.Semester).Distinct().ToList();
Запит для отримання необхідної інформації виглядає наступним чином:
var report =
    @group
        .Students.OrderBy(e => e.Name)
        .Select(st => new GroupReportEntry
        {
            Id = st.Id,
            Name = st.Name,
            AbsentCount = st.LessonPresences
                .Where(lp =>
                    lp.Lesson.Schedule.DisciplineId == disciplineId &&
                    lp.Lesson.Schedule.SemesterId == yearOfStudyId &&
                    lp.Lesson.Schedule.SemesterType == semesterType)
                .Count(e => e.PresenceType == PresenceType.Absent),
            Marks = st.LessonPresences
                .Where(lp =>
                .Count(e => e.Mark > 0),
            Average = st.LessonPresences
                .Where(lp =>
                .Count(e => e.Mark > 0) > 0
                ? st.LessonPresences.Where(e => e.Mark > 0)
                    .Average(e => e.Mark)
                : 0
41
        });
У запиті відбувається сортування прізвищ студентів за алфавітом та
обчислення середнього балу студента.
Запит для отримання розкладу викладача. Формування запиту з розкладом
обраного викладача на поточний день відбувається у декілька етапів:
1) формування списку занять згідно основного розкладу;
2) формування списку занять згідно додаткового розкладу;
3) об’єднання цих списків та сортування їх.
Перший крок виконується наступним чином:
var regular = Context.BaseSchedules
                    .Include(e => e.Teacher)
                    .Include(e => e.Discipline)
                    .Include(e => e.LessonNumber)
                    .Include(e => e.AdditionalSchedule)
                    .Include(e => e.RegularSchedule)
                    .Where(e =>
                        e.TeacherId == CurrentUserId &&
                        e.RegularSchedule != null &&
                        e.RegularSchedule.DayOfWeek == today)
                    .ToList();
Директива Include дозволяє нам перезавантажити інформацію з залежних
сутностей (inner join залежної таблиці з вибіркою усіх полів з неї).
Другий крок виглядає майже так само, за виключенням отримання
інформації не про основний, а про додатковий розклад.
Текст запиту:
                var additional = Context.BaseSchedules
                    .Include(e => e.Teacher)
                    .Include(e => e.Discipline)
                    .Include(e => e.LessonNumber)
                    .Include(e => e.AdditionalSchedule)
                    .Include(e => e.RegularSchedule)
                    .Where(e => e.TeacherId == CurrentUserId &&
                                e.AdditionalSchedule != null &&
                                DbFunctions.TruncateTime(
                                    e.AdditionalSchedule.Date) ==
                                dateTime)
                    .ToList();
Третій крок об’єднує ці два запити і виконує сортування по номеру уроку:
var schedules = regular
                    .Union(additional)
42
                    .OrderBy(e => e.LessonNumber.StartTime)
                    .ToList();
Запит для відображення оцінок та відвідування студентів групи на певному
уроці. За допомогою даного запиту необхідно відобразити інформацію про
відвідування кожного студента групи на кожного з уроків даної дисципліни.
Так як кількість уроків з дисципліни не є сталою величиною і може
змінюватись залежно від багатьох факторів, одного запиту недостатньо аби
отримати всю необхідну інформацію. Тому необхідно виконувати отримання
інформації в декількох запитах, які будуть комбінуватись при відображенні.
Запит на отримання списку проведених уроків:
var lessons = await schedules
    .SelectMany(e => e.Lessons)
    .OrderBy(e => e.Date)
    .ToListAsync()
    .ConfigureAwait(false);
Запит на отримання інформації про групу, її студентів та їх відвідування з
оцінками:
var group = await Context.Groups
    .SingleOrDefaultAsync(e => e.Id == groupId)
var students = await group.Students
    .OrderBy(e => e.Name)
    .Select(e =>
        new StudentPresenceVM
        {
            Id = e.Id,
            Name = e.Name,
            Presences =
                lessons.SelectMany(l =>
                    l.LessonPresences
                        .Where(p => p.StudentId == e.Id))
                    .Select(
                        lp =>
                            new PresenceVM
                            {
                                Id = lp.Id,
                                Type = lp.PresenceType,
                                Mark = lp.Mark,
                                Comment = lp.Comment,
                                LessonId = lp.LessonId,
                                Date = lp.Date
                            })
43
                    .ToArray()
        })
    .ToListAsync()
В результаті ці два запити об’єднуються в один об’єкт, який і буде
переданий для формування звіту.
3.3 Розробка форм
На основі утвореної бази даних можна розробити веб-додаток для роботи з

цією базою. Для розробки використано програмний каркас ASP.NET MVC, що
надає можливість швидкої генерації форм. Для авторизації у веб-додатку
використано сторонню авторизацію через систему Office 365, облікові записи в
якій мають всі студенти та викладачі. Вигляд головної сторінки додатку для
викладача показано на рис. 3.3.
Рисунок 3.3 – Головна сторінка для викладача розробленого веб-додатку для

роботи з базою даних
Додаток призначений для адміністратора (зображення головної сторінки для

адміністратора наведено в додатку Д), що вноситиме розклад та для викладачів,
що вестимуть журнал відвідування та успішності. Після авторизації особа, що має
роль адміністратора має доступ до створення різних компонентів розкладу,
наприклад, дисциплін, груп, номерів уроків та ін. Форма додавання групи
виглядає наступним чином (рис. 3.4):
44
Рисунок 3.4 – Форма додавання групи
Код, що утворює дану форму:

@using (Html.BeginForm(null, null, FormMethod.Post, new { enctype = "multipart/form-data"
}))
{
<div class="form-horizontal">
@Html.ValidationSummary(true)
<div class="form-group">
<label class="control-label col-md-2">
Назва
</label>
<div class="col-md-10">
@Html.BootstrapTextBoxFor(model => model.Name)
@Html.ValidationMessageFor(model => model.Name)
</div>
</div>
Прихована
</label>
@Html.EditorFor(model => model.IsDel)
@Html.ValidationMessageFor(model => model.IsDel)
</div>
</div>
Факультет
</label>
@Html.BootstrapDropDownList("FacultyId", String.Empty)
@Html.ValidationMessageFor(model => model.FacultyId)
</div>
</div>
45
<div class="col-md-offset-2 col-md-10">
@Html.ActionLink("Назад до списку", "Index", null, new { @class = "btn btn-default"
})
<input type="submit" value="Створити" class="btn btn-success" />
</div>
</div>
</div>
}
Код, що здійснює обробку форми:
public async Task<ActionResult> Create([Bind(Include="Id,Name,IsDel,FacultyId")] Group
group)
{
if (ModelState.IsValid)
{
group.Id = Guid.NewGuid();
db.Groups.Add(group);
await db.SaveChangesAsync();
return RedirectToAction("Index");
}
ViewBag.FacultyId = new SelectList(db.Faculties, "Id", "Name", group.FacultyId);

return View(group);
}
Одним з основних компонентів бази даних є розклад. Його формування
відбувається у новій формі на основі попередньо введених даних про групи,
факультети та ін. Форма додавання розкладу показана на рис. 3.5.
Рисунок 3.5 – Форма додавання розкладу

46
В формі необхідно вказати всі деталі розкладу, наприклад, номер уроку, тип
заняття, номер тижня та інші. Для збереження введених даних необхідно
натиснути кнопку «Створити».
Рисунок 3.6 – Форма для ведення журналу
Одним з основних завдань додатку є надання можливості викладачам

вказувати присутність студентів на уроках та виставляти отримані ними бали. На
рис. 3.6 показано форму, що надає таку можливість.
У формі навпроти прізвища студента викладач може вказати його
присутність або відсутність на уроці, також поставити бал, отриманий студеном
та, якщо необхідно, залишити коментар. Код, що здійснює обробку цієї форми
наведений у додатку В.
Рисунок 3.7 – Вигляд журналу викладача

47
Результатом заповнення відвідувань студентів та їхніх балів є формування

таблиці, що максимально точно відтворює зовнішній вигляд паперового аналогу
журналу викладача (рис. 3.7).
3.4 Розробка звітів
Одним з найважливіших аспектів викладацької діяльності є звітування про

проведену роботу. Для цього найзручнішим буде представлення інформації у
текстовому (табличному) вигляді.
Відповідно до створених запитів створимо звіти для зручного відображення
інформації.
Звіт про успішність груп університету. Звіт має фільтр, що дає можливість
вибрати діапазон дат, за який буде представлена інформація. Також звіт містить
таблицю, де відображаються отримані результати.
Код формування фільтрів звіту:
<h2>Звіт по групам з @Model.From.ToString("D") по @Model.To.ToString("D") </h2>
@using (@Html.BeginForm())
{
    <div class="row">
        <div class="col-md-1">З:</div>
        <div class="col-md-10">
            @Html.BootstrapDatePickerFor(model => model.From)
        </div>
    </div>
    <div class="row">
        <div class="col-md-1 top10">По:</div>
        <div class="col-md-10 top10">
            @Html.BootstrapDatePickerFor(model => model.To)
        </div>
    </div>
    <button type="submit" class="btn btn-info top10">Оновити</button>
}
Код для формування таблиці звіту:
<table class="table table-bordered">
    <thead>
        <tr>
            <td>Група</td>
            <td>Кількість відвудувань</td>
            <td>Оцінок відмінно</td>
            <td>Оцінок добре</td>
48
            <td>Оцінок задовільно</td>
            <td>Оцінок не задовільно</td>
            <td>Пропусків</td>
            <td>З них з поважної причини</td>
        </tr>
    </thead>
    <tbody>
        @foreach (var item in Model.Items)
        {
            <tr>
                @Html.HiddenFor(e => item.Id)
                <td>@item.Name</td>
                <td>@item.MarksCount</td>
                <td>@item.PerfectCount</td>
                <td>@item.GoodCount</td>
                <td>@item.NotBadCount</td>
                <td>@item.BadCount</td>
                <td>@item.Absent</td>
                <td>@item.GoodReason</td>
            </tr>
        }
    </tbody>
</table>
Рисунок 3.8 – Сторінка звіту про успішність груп університету
Звіт про успішність студентів групи. Звіт має більш деталізований характер,
ніж попередній, оскільки інформація про відівідування та успішінсть наводиться
для кодного студента за певний період по певному предмету. Даний звіт містить
фільтри, що дозволяють обрати групу, для студентів якої буде сформовано звіт,
предмет, рік навчання та семестр. Код, що здійснює формування фільтрів:
49
<h2>Звіт по групі</h2>
@using (Html.BeginForm())
{
    <div class="form-horizontal">
        <div class="form-group">
            <label class="col-sm-2 control-label">Звіт по групі</label>
            <div class="col-md-6">
                @Html.BootstrapDropDownList("Id", (IEnumerable<SelectListItem>)ViewBag.Id)
            </div>
        </div>
            <label class="col-sm-2 control-label">Звіт по предмету</label>
            <div class="col-md-6">
                @Html.BootstrapDropDownList("DisciplineId", (IEnumerable<SelectListItem>)ViewBa
g.DisciplineId)
            </div>
        </div>
            <label class="col-sm-2 control-label">Рік навчання</label>
            <div class="col-md-6">
                @Html.BootstrapDropDownList("YearOfStudyId", (IEnumerable<SelectListItem>)Vie
wBag.YearOfStudyId)
            </div>
        </div>
            <label class="col-sm-2 control-label">Семестр</label>
            <div class="col-md-6">
                @Html.EnumDropDownListFor(e => e.SemesterType, new { @class = "form-
control" })
            </div>
        </div>
    </div>
    <button type="submit" class="btn btn-info top10">Оновити</button>
}
Результат відображається у табличному вигляді (рис. 3.9). Код, що формує
таблицю:
<table class="table table-bordered">
    <thead>
        <tr>
            <td>Студент</td>
            <td>К-сть оцінок</td>
            <td>Пропущено занять</td>
            <td>Середній бал</td>
        </tr>
    <tbody>
        @foreach (var item in Model.Items)
        {
50
            <tr>
                @Html.HiddenFor(e => item.Id)
                <td>@item.Name</td>
                <td>@item.Marks</td>
                <td>@item.AbsentCount</td>
                <td>@item.Average.ToString("F2")</td>
            </tr>
        }
</table>
Рисунок 3.9 – Сторінка звіту про успішність студентів групи
Звіт, що містить розклад викладача. Розклад відображається на головній

сторінці додатку на поточний день (рис. 3.10). Звіт об’єднує велику кількість
інформації, що міститься в базі даних, а саме: номер уроку, тип розкладу, номер
тижня, дисципліна, аудиторія та групи, для яких необхідно провести заняття.
Код, що формує звіт:
        <h2>Сьогодні у вас є заняття</h2>
    <table class="table table-hover">
        <tr>
            <th>Номер тижня</th>
            <th>Тип розкладу</th>
            <th>Номер уроку</th>
            <th>Дисципліна</th>
            <th>Тип уроку</th>
            <th>Аудиторія</th>
            <th>Групи</th>
        </tr>
51
        @foreach (var item in ((IEnumerable<BaseSchedule>)ViewBag.TeacherSchedules).OrderB
y(e => e.LessonNumber.StartTime))
        {
            <tr>
                <td>
                    @Html.DisplayFor(modelItem => item.WeekNumber)
                </td>
                <td>
                    @if (item.RegularSchedule != null)
                    {
                        <text>Основний</text>
                    }
                    else
                    {
                        <text>Додатковий</text>
                    }
                </td>
                <td>
                    @Html.DisplayFor(modelItem => item.LessonNumber.DisplayName)
                </td>
                <td>
                    <a href="@Url.Action("Details", "Presence", new {id = item.Id, dateTime = DateTim
e.Now})">@Html.DisplayFor(modelItem => item.Discipline.Name)</a>
                </td>
                <td>
                    @item.LessonType.GetDisplayValue()
                </td>
                <td>
                    @Html.DisplayFor(modelItem => item.RoomNumber)
                </td>
                <td>
                    @foreach (var group in item.Groups)
                    {
                        @Html.ActionLink(group.Name, "Index","Presence",new { groupId = group.Id, dis
ciplineId = item.DisciplineId, lessonType = item.LessonType},null)
                        if (group != item.Groups.Last())
                        {
                            <text>, </text>
                        }
                    }
                </td>
            </tr>
        }
    </table>
}
52
Рисунок 3.10 – Сторінка звіту, що містить розклад викладача
Інформація про виводиться у зручному для користувача вигляді. Назва

кожної групи у стрічці з розкладом є посиланням, що дозволяє відкрити звіт про
оцінки та відвідування студентів цієї групи.
Звіт, що містить оцінки та присутність студентів групи на певному уроці.
Таблиця, що містить інформацію даного звіту максимально точно відтворює
паперовий аналог журналу викладача (рис. 3.11). Кожен рядок відповідає
певнному студенту, стовпець – даті проведення заняття. На перетині рядка і
стовпця міститься інформація, що студент був відсутнім на уроці з невідомих
причин (н), студент має поважну причину відсутності, наприклад, хвороба (хв), та
оцінка, якщо він її отримав в ході проведення уроку, або просто крапка, якщо
жодна з попередніх умов не була виконана.
Код для представлення звіту:
<div class="table-responsive">
<table class="table table-condensed table-bordered table-hover table-striped">
    <thead>
    <tr>
        <td>Прізвище Ім'я студента</td>
        @foreach (var lesson in Model.Lessons)
        {
            <td theme="@lesson.Theme">@lesson.Date.ToString(Extentions.DatePickerDateForma
t)</td>
        }
    </tr>
    @foreach (var student in Model.Students)
    {
        <tr>
            <td style="white-space: nowrap">@student.Name</td>
            @foreach (var lesson in Model.Lessons)
            {
53
                var presence = student.Presences.FirstOrDefault(e => e.LessonId == lesson.ScheduleI
d && e.Date == lesson.Date);
                if (presence != null)
                {
                    <td comment="@presence.Comment">
                        @switch (presence.Type)
                        {
                            case PresenceType.Absent:
                            {
                                <text>н</text>
                                break;
                            }
                            case PresenceType.GoodReason:
                            {
                                <text>хв.</text>
                                break;
                            }
                            case PresenceType.Present:
                            case PresenceType.Late:
                            {
                                if (presence.Mark > 0)
                                {
                                    <text>@presence.Mark.ToString("F0")</text>
                                }
                                else
                                {
                                    <text>.</text>
                                }
                                break;
                            }
                            default:
                                throw new ArgumentOutOfRangeException();
                        }
                    </td>
                }
                else
                {
                    <td>н</td>
                }
            }
        </tr>
    }
</table>
</div>
54
Рисунок 3.11 – Звіт, що містить оцінки та присутність студентів групи на певному

уроці
Кожен рядок відповідає певнному студенту, стовпець – даті проведення

заняття. На перетині рядка і стовпця міститься інформація, що студент був
відсутнім на уроці з невідомих причин (н), студент має поважну причину
відсутності, наприклад, хвороба (хв), та оцінка, якщо він її отримав в ході
проведення уроку, або просто крапка, якщо жодна з попередніх умов не була
виконана.
У розділі було описано практичну реалізацію бази даних «Електронний

журнал викладача» та програмного додатку для роботи з нею. Було наведено
частини коду, що відповідають за генерацію таблиць, утворення зв’язків між
ними, формування запитів та звітів. Описано інтерфейс додатку, форми та
таблиці, з якими працюватиме користувач бази даних та програмного додатку.
55
ВИСНОВКИ
В результаті виконання курсової роботи було досягнута поставлена мета, а

саме розроблено базу даних «Електронний журнал викладача» та програмний
додаток для управління розробленою базою даних.
У першому розділі було проаналізовано предметну область, наведено
теоретичні відомості про бази даних, системи управління ними, моделі даних,
наведено ряд недоліків існуючих систем управління базами даних, а також обрано
СУБД MS SQL для виконання завдання курсової роботи. Також здійснено
порівняння мов програмування та обрано програмний каркас ASP.NET MVC,
написаний мовою C# для створення додатку для керування базою даних.
У другому розділі здійснено проектування бази даних «Електронний
журнал викладача» методом сутність-зв’язок, проведено декомпозицію
відношень, та перевірено результати за допомогою методу нормалізації. Також
було створено ER-модель бази даних.
В третьому розділі описана практична реалізація бази даних «Електронний
журнал викладача». Описано процес створення таблиць та зв’язків між ними,
наведено частини коду, що за це відповідають. Наведено приклади запитів, що
використовуються в ході роботи додатку. Також описано процес розробки
інтерфейсу, форм та таблиць, за допомогою яких користувач здійснюватиме
керування базою даних, вноситиме зміни та переглядатиме результати. Показано
процес утворення звітів для зручного представлення зведених даних.
Користувачами розробленої бази даних та додатку можуть бути викладачі
університету, а також деканати та (або) певна відповідальна за заповнення
розкладу особа (наприклад, адміністратор бази даних). Розроблені база даних та
додаток повністю вирішують поставленні задачі, а саме: керування розкладом
викладача, ведення журналу викладача, отримання звітів про успішність
студентів.
56
ПЕРЕЛІК ПОСИЛАНЬ
1. Фуфаев Э. Базы данных / Э. Фуфаев, Д. Фуфаев. – Москва: Academia,

2013. – 320 с.
2. Кузнецов С. Базы данных / Сергей Кузнецов. – Москва: Academia, 2012. – 496
с.
3. Пирогов В. Информационные системы и базы данных. Организация и
проектирование / Владислав Пирогов. – СПб.: БХВ-Петербург, 2009. – 528 с.
4. Тарасов С. СУБД для программиста. Базы данных изнутри / Сергей Тарасов.
– Москва: Соломон, 2015. – 320 с.
5. Маркин А. Разработка отчетов в информационных системах / Александр Маркин. –
Москва: Диалог-МИФИ, 2012. – 312 с.
6. Бураков П. В. ВВЕДЕНИЕ В СИСТЕМЫ БАЗ ДАННЫХ / П. В. Бураков,
В. Ю. Петров. – Санкт Петербург, 2010. – 128 с.
7. Basit A. SQL Server 2014 Development Essentials / Masood-Al-Farooq Basit
A. – Москва: Книга по Требованию, 2014. – 214 с.
8. Албахари Д. C# 5.0. Справочник. Полное описание языка / Д. Албахари,
Б. Албахари. – Москва: Вильямс, 2014. – 1008 с.
9. Бондарь А. Microsoft SQL Server 2014 / Александр Бондарь. – СПб: БХВ-
Петербург, 2015. – 592 с.
10. Грофф Д. SQL. Полное руководство / Д. Грофф, П. Вайнберг, Э. Оппель.
– Москва: Вильямс, 2014. – 960 с.
57
ДОДАТКИ
58
Додаток А
Лістинг створення контексту бази даних
public class Db : DbContext
{
public Db() : base("name=Db") { }
public virtual DbSet<AdditionalSchedule> AdditionalSchedules { get; set; }
public virtual DbSet<BaseSchedule> BaseSchedules { get; set; }
public virtual DbSet<Discipline> Disciplines { get; set; }
public virtual DbSet<Faculty> Faculties { get; set; }
public virtual DbSet<Lesson> Lessons { get; set; }
public virtual DbSet<LessonNumber> LessonNumbers { get; set; }
public virtual DbSet<LessonPresence> LessonPresences { get; set; }
public virtual DbSet<RegularSchedule> RegularSchedules { get; set; }
public virtual DbSet<Group> Groups { get; set; }
public virtual DbSet<Role> Roles { get; set; }
public virtual DbSet<Semester> Semesters { get; set; }
public virtual DbSet<User> Users { get; set; }
public virtual DbSet<YearOfStudy> YearOfStudies { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.AdditionalSchedule();
modelBuilder.BaseSchedule();
modelBuilder.Discipline();
modelBuilder.Group();
modelBuilder.Lesson();
modelBuilder.LessonNumber();
modelBuilder.LessonPresence();
modelBuilder.RegularSchedule();
modelBuilder.Role();
modelBuilder.Semester();
modelBuilder.User();
modelBuilder.YearOfStudy();
}
}
59
Додаток Б
Форма для ведення журналу
Рисунок Б.1 – Вигляд форми заповнення присутності та оцінок

60
Додаток В
Лістинг обробки форми для ведення журналу
public class PresenceController : BaseController
{
public async Task<ActionResult> Index(Guid groupId, Guid disciplineId, LessonType
lessonType)
{
var discipline = await Context.Disciplines
.SingleOrDefaultAsync(e => e.Id == disciplineId)
.ConfigureAwait(false);
var schedules = await Context.BaseSchedules
.Where(e =>
e.Groups.Any(g => g.Id == groupId) &&
e.DisciplineId == disciplineId &&
e.LessonType == lessonType)
.ToListAsync()
var lessons = await schedules
.SelectMany(e => e.Lessons)
.OrderBy(e => e.Date)
.ToListAsync()
var group = await Context.Groups
.SingleOrDefaultAsync(e => e.Id == groupId)
var students = await group.Students
.OrderBy(e => e.Name)
.Select(e =>
new StudentPresenceVM
{
Id = e.Id,
Name = e.Name,
Presences =
lessons.SelectMany(l =>
l.LessonPresences
.Where(p => p.StudentId == e.Id))
.Select(
lp =>
new PresenceVM
{
Id = lp.Id,
Type = lp.PresenceType,
Mark = lp.Mark,
Comment = lp.Comment,
LessonId = lp.LessonId,
Date = lp.Date
61
})
.ToArray()
})
.ToListAsync()
var result = new PresenceReport
{
Group = group,
Students = students,
Lessons = lessons,
LessonType = lessonType,
Discipline = discipline
};
return View(result);
}
//
// GET: /Presence/
public async Task<ActionResult> Details(Guid id, DateTime? dateTime)
{
var baseSchedule = Context.BaseSchedules.Single(e => e.Id == id);
if (baseSchedule.RegularSchedule != null && dateTime == null)
return new HttpStatusCodeResult(400, "Date not provided");
var date = (baseSchedule.RegularSchedule == null
? baseSchedule.AdditionalSchedule.Date
: dateTime.Value).Date;
var lesson =
baseSchedule.Lessons.FirstOrDefault(
e => e.Date.Date == date);
var schedule = new LessonPresenceVM
{
Date = lesson?.Date??date,
Theme = lesson?.Theme ?? "",
Groups = baseSchedule.Groups.Select(g => new GroupVM
{
Id = g.Id,
Name = g.Name,
Students = g.Students.Select(s =>
{
var presence =
Context.LessonPresences.FirstOrDefault(
e => e.LessonId == id && e.StudentId == s.Id);
return new StudentVM
{
Id = s.Id,
Name = s.Name,
Comment = presence?.Comment ?? "",
PresenceType =
presence?.PresenceType ?? PresenceType.Absent,
62
Mark = presence?.Mark ?? 0
};
}).ToArray()
}).ToArray(),
Discipline = baseSchedule.Discipline.Name,
Teacher = baseSchedule.Teacher.Name,
LessonNumber = baseSchedule.LessonNumber.DisplayName,
WeekNumber = baseSchedule.WeekNumber,
Semestr = baseSchedule.Semester.Name
};
return View(schedule);
}
[HttpPost]
public async Task<ActionResult> Details(Guid id, LessonPresenceVM value)
{
var schedule = Context.BaseSchedules.SingleOrDefault(e => e.Id == id);
var lesson =
Context.Lessons.SingleOrDefault(e => e.ScheduleId == value.Id);
if (lesson == null)
{
lesson = new Lesson
{
ScheduleId = value.Id,
IsDel = false,
Theme = value.Theme,
Date = value.Date
};
Context.Lessons.Add(lesson);
}
else
{
lesson.Theme = value.Theme;
lesson.Date = value.Date;
}
foreach (var studentVm in value.Groups.SelectMany(e => e.Students))
{
var presence =
lesson.LessonPresences.SingleOrDefault(
e => e.StudentId == studentVm.Id);
if (presence == null)
{
presence = new LessonPresence
{
StudentId = studentVm.Id,
Comment = studentVm.Comment ?? "",
IsDel = false,
Lesson = lesson,
Mark = studentVm.Mark,
63
PresenceType = studentVm.PresenceType
};
lesson.LessonPresences.Add(presence);
}
else
{
presence.Comment = studentVm.Comment ?? "";
presence.Mark = studentVm.Mark;
presence.PresenceType = studentVm.PresenceType;
}
}
await Context.SaveChangesAsync().ConfigureAwait(false);
return View(value);
}
}
64
Додаток Д
Головне вікно програми
Рисунок В.1 – Головна сторінка додатку для адміністратора бази даних

KursovaBD E25ouob3.zp2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KursovaBD E25ouob3.zp2

Uploaded by

Copyright:

Available Formats

ЗМІСТ

Однією з проблем сучасного ВНЗ є контроль. У зв'язку з великою кількістю

1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

База даних (англ. database) – це сукупність даних, організованих відповідно

1.1 Предметна область

При аналізі предметної області теми «Електронний журнал викладача» слід

Присутність студента має на увазі, що деякий студент був присутній на

1.2 Поняття реляційної бази даних та СУБД

База даних (англ. database) – це сукупність даних, організованих відповідно

Вузол - це сукупність атрибутів даних, що описують інформаційний об’єкт.

Рисунок 1.1 – Графічне зображення ієрархічної структури даних

В мережній моделі зв'язок "один до багатьох" (1:N) означає, що значенню

Рисунок 1.2 – Графічне зображення мережної структури даних

В реляційній моделі зв'язок "багатьох до багатьох" (N:N) указує на те, що

неї контрольований доступ. За ступенем універсальності розрізняють два класи

3) відновлення бази даних. Однією з основних вимог до СУБД є

власний набір буферів оперативної пам'яті з власною дисципліною заміни

запису здійснюється методом прямого обходу дерева. Записи, розташовані в одній

торкнулося інших, а зміна структури бази даних не обов'язково призводить до

2) розподілені СУБД (частини СУБД можуть розміщуватися на двох і

Приклади: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server,

1.3 Обґрунтування вибору СУБД

Проаналізувавши деякі СУБД було виявлено ряд недоліків, а саме:

Microsoft SQL Server також підтримує Open Database Connectivity (ODBC)

1.4 Обґрунтування вибору мови програмування

високий рівень взаємодії з компонентами цієї СУБД. Інші мови програмування, як

Для взаємодії всіх вищеописаних компонентів та зручного керування ними

2 ПРОЕКТУВАННЯ БАЗИ ДАНИХ

Предметна область курсової роботи охоплює такі поняття як «присутність»,

2.1 Проектування методом сутність-зв'язок

Проектування методом сутність–зв’язок складається з таких етапів:

РОЗКЛАД – визначає – НОМЕР_УРОКУ,

ФАКУЛЬТЕТ (<Ід_факультету>, Назва)

Рисунок 2.1 – Аналіз зв’язку сутностей ГРУПА та ОСОБА

Рисунок 2.2 – Аналіз зв’язку сутностей ФАКУЛЬТЕТ та ГРУПА

Рисунок 2.3 – Аналіз зв’язку сутностей РОЗКЛАД та ОСНОВНИЙ_РОЗКЛАД

Ступінь бінарного зв’язку – 1:1, клас належності однієї сутності є

2.2 Проектування ER-моделі

На основі даних, отриманих в ході проектування бази даних методом

кожної сутності. Ключем цього відношення буде сукупність ключів двох

Рисунок 2.4 – Попередні відношення сутностей ОСОБА та ГРУПА

Так як зв’язки ОСОБА – має – РОЛЬ та ГРУПА – має – РОЗКЛАД мають

Рисунок 2.5 – Попередні відношення сутностей ФАКУЛЬТЕТ та ГРУПА

Зв'язки УРОК – визначає – ПРИСУТНІСТЬ, РІК_НАВЧАННЯ – містить –

– НОМЕР_УРОКУ, РОЗКЛАД – має – ПРЕДМЕТ, РОЗКЛАД – визначає – УРОК

Рисунок 2.6 – Попередні відношення сутностей ДОДАТКОВИЙ_РОЗКЛАД та

Зв'язки РОЗКЛАД – розширює – ДОДАТКОВИЙ_РОЗКЛАД мають такі ж

Рисунок 2.10 – ER-модель бази даних для предметної області «Електронний

2.3 Метод нормалізації відношень

Нормалізація схеми бази даних — покроковий процес розбиття одного

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

R1 = (<Ід_присутності>, Ід_особи_студента, ПІБ, Email, Тип_присутності,

атрибут А функціонально залежить від атрибуту В, та атрибут В функціонально

R29 (РІК_НАВЧАННЯ) = (<Ід_року>, Назва_року)

В даному розділі було проведено проектування бази даних, за предметною

3 ПРАКТИЧНА РЕАЛІЗАЦІЯ БАЗИ ДАНИХ

У попередньому розділі за допомогою методів сутність-зв’язок так

3.1 Розробка таблиць

За допомогою технологій ASP.NET MVC та Entity Framework Code First

Аналогічним чином утворюються таблиці для всіх інших сутностей. Зв’язки

Рисунок 3.1 – Вигляд таблиці «Особа» із заповненими даними

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

Рисунок 3.2 – Діаграма реалізованої бази даних «Електронний журнал викладача»