МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ТАВРІЙСЬКИЙ ДЕРЖАВНИЙ АГРОТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ

Факультет Інженерії і

комп’ютерних технологій

Кафедра комп’ютерних наук

МЕТОДИЧНІ ВКАЗІВКИ

до виконання комплексного курсового проекту

з дисциплін «Організація баз даних та знань» та «Веб-технології»

для студентів напряму підготовки

6.050101 “Комп’ютерні науки”

денна форма навчання

Мелітополь,

2017

2

Методичні вказівки до виконання комплексного курсового проекту з

дисциплін «Організація баз даних та знань» та «Веб-технології» для студентів

напряму підготовки 6.050101 “Комп’ютерні науки”. – Таврійський державний

агротехнологічний університет, 2017. – 44 с.

Розробники: асистент Беккауер А.О.

Рецензент: к.т.н., доцент кафедри “Інформаційні технології проектування

ім. В.М.Найдиша” Таврійського державного агротехнологічного

університету, к.т.н., доцент Пихтєєва І.В.

Розглянуто та рекомендовано до друку на засіданні кафедри комп’ютерних

наук

Протокол № від « » 2017 р.

Затверджено методичною комісією факультету ІКТ

Протокол № від « » 2017 р.

3

ЗМІСТ

1 ЗАГАЛЬНІ ВКАЗІВКИ ДО ВИКОНАННЯ КУРСОВОГО ПРОЕКТУ ............. 5

1.1 Загальні положення ......................................................................................... 5

1.2 Завдання та структура комплексного курсового проекту(роботи) ............. 6

1.2.1 Мета та завдання комплексного курсового проекту(роботи) ................ 6

1.2.2 Структура комплексного курсового проекту(роботи) ........................... 6

1.2.3 Порядок здачі та захисту курсового проекту .......................................... 8

1.3 Вимоги до змісту пояснювальної записки ..................................................... 8

1.3.1 Титульний аркуш ........................................................................................ 8

1.3.2 Технічне завдання ...................................................................................... 8

1.3.3 Реферат ........................................................................................................ 9

1.3.4 Зміст ............................................................................................................. 9

1.3.5 Вступ ............................................................................................................ 9

1.3.6 Основна частина ......................................................................................... 9

1.3.7 Висновки ................................................................................................... 10

1.3.8 Список літератури .................................................................................... 10

1.3.9 Оформлення додатків............................................................................... 10

2 ПРАВИЛА ОФОРМЛЕННЯ ТЕКСТОВИХ ДОКУМЕНТІВ ........................... 11

2.1 Загальні положення ........................................................................................ 11

2.2 Вимоги до пояснювальної записки, що містить суцільний текст ............. 12

2.2.1 Побудова документа ................................................................................ 12

2.2.2 Виклад тексту документів ....................................................................... 14

2.2.3 Оформлення формул і розрахунків ........................................................ 15

2.2.4 Оформлення приміток, посилань і виносок .......................................... 16

2.2.5 Оформлення ілюстрацій і додатків......................................................... 16

2.2.6 Побудова таблиць ..................................................................................... 18

2.2.7 Приклади ................................................................................................... 19

3 ВКАЗІВКИ ДО ВИКОНАННЯ РОЗДІЛІВ КУРСОВОГО ПРОЕКТУ ............ 20

3.1 Розділ «1 Аналіз вимог» ................................................................................. 20

3.1.1 Глава «1.1. Постановка завдання» .......................................................... 20

3.1.2 Глава «1.2. Розробка моделі варіантів використання веб-сайту» ....... 20

4

3.2 Розділ «2 Розробка бази даних» .................................................................... 24

3.2.1 Глава «2.1 Опис моделі даних» ............................................................... 24

3.2.2 Глава «2.2 Нормалізація реляційних відношень» ................................. 27

3.2.3 Глава «2.3 Визначення типів даних» ...................................................... 28

3.2.4 Глава «2.4 Обмеження цілісності даних» .............................................. 30

3.2.5 Глава «2.5 Індекси» .................................................................................. 34

3.2.6 Глава «2.6 Тригери» ................................................................................. 35

3.2.7 Глава «2.7 Реалізація SQL-скрипту» ...................................................... 36

3.3 Розділ «3 розробка веб-додатку» .................................................................. 36

3.3.1 Глава «3.1 Структура веб-сайту» ............................................................ 36

3.3.2 Глава «3.2 Макети сторінок веб-сайту» ................................................. 37

3.3.3 Глава «3.3 Програмування серверної частини» .................................... 37

3.3.4 Глава «3.4 Програмування клієнтської частини» ................................. 38

3.3.5 Глава «3.5 Автентифікація користувачів» ............................................. 39

3.3.6 Глава «3.6 Розміщення веб-сайту в Інтернеті» ..................................... 39

СПИСОК ЛІТЕРАТУРИ ............................................................................................. 40

ДОДАТОК А ................................................................................................................ 41

ДОДАТОК Б................................................................................................................. 42

ДОДАТОК В ................................................................................................................ 43

5

1 ЗАГАЛЬНІ ВКАЗІВКИ ДО ВИКОНАННЯ КУРСОВОГО

ПРОЕКТУ

1.1 Загальні положення

Методичні вказівки по комплексному курсовому проекту розроблені

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

6.050101 “Комп’ютерні науки”. Курсовий проект базується на матеріалі,

викладеному в курсах «Організація баз даних та знань», «Веб-технології»,

«Алгоритмізація та програмування», «Теорія алгоритмів», «Ергономіка та

комп’ютерна графіка».

Комплексний курсовий проект є однією з форм роботи студентів, при

виконанні якої всі рішення приймаються самостійно. Роль керівника курсового

проекту при цьому полягає в оцінці принципових рішень, методичної допомоги,

контролі термінів і змісту роботи.

При роботі над проектом (роботою)* студент, відповідно до завдання на

проектування, вирішує конкретні конструкторські, технологічні і організаційно-

економічні задачі. У процесі проектування він повинний виявити уміння

користуватися довідковою літературою, стандартами, табличними матеріалами,

номограмами, кошторисними нормами, періодичною і іншою літературою.

Виконання курсового проекту має своєю метою закріплення теоретичних

знань шляхом розробки бази даних для якої будується діаграма варіантів

використання, діаграма сутностей і зв’язків, проводиться нормалізація реляційних

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

програмування клієнтської та серверної частини, створити ергономічний дизайн.

За прийняті в роботі технічні рішення і достовірність різноманітних обрахувань

відповідає автор роботи (студент).

Розрахунково-пояснювальна записка і графічні роботи виконуються у

відповідності з стандартами ЕСКД та ЕСТД.

6

1.2 Завдання та структура комплексного курсового проекту(роботи)

1.2.1 Мета та завдання комплексного курсового проекту(роботи)

Метою курсового проекту є набуття практичних умінь при виконанні

студентами розробки динамічного веб-сайту зі зберіганням інформації в базі

даних.

Веб-сайт повинен відповідати наступним вимогам:

Зовнішнє оформлення повинно бути естетично гармонійним;

Дизайн сайту не повинен повторювати сайти конкуруючих

фірм/організацій/проектів;

Сайт повинен давати повну і правильну інформацію відповідно до його

призначення;

Адміністративний інтерфейс сайту має бути інтуїтивним та зрозумілим

користувачу початкового рівня.

Для виконання поставленої мети необхідно вирішити наступні задачі:

Проаналізувати вимоги до веб-сайту;

Розробити базу даних веб-сайту;

Розробити інтерфейс користувача веб-сайту;

Розробити програмне забезпечення веб-сайту на стороні сервера;

Розмістити веб-сайт в мережі Інтернет.

1.2.2 Структура комплексного курсового проекту(роботи)

Комплексний курсовий проект(робота) складається з пояснювальної

записки та графічної частини. Розрахунково-пояснювальна записка представляє

собою текстовий документ, що виконується відповідно до вимог ЕСКД. Загальний

обсяг пояснювальної записки повинен становити 30-35 аркушів формату А4,

включаючи ілюстрації.

7

Пояснювальна записка повинна мати наступну структуру:

Титульний аркуш

Завдання на курсовий проект

Зміст

Вступ

1 Аналіз вимог

1.1. Постановка завдання

1.2. Розробка моделі варіантів використання веб-сайту

2 Розробка бази даних

2.1 Опис моделі даних

2.2 Нормалізація відношень

2.3 Визначення типів даних

2.4 Обмеження цілісності даних

2.5 Індекси

2.6 Тригери

2.7 Реалізація SQL-скрипту

3 Розробка веб-додатку

3.1 Структура веб-сайту

3.2 Макети сторінок веб-сайту

3.3 Програмування серверної частини

3.4 Програмування клієнтської частини

3.5 Автентифікація користувачів

3.6 Розміщення веб-сайту в Інтернеті

Висновки

Список літератури

Додатки

Додаток А. HTML і CSS

Додаток Б. Програмування серверної частини

Додаток В. Програмування клієнтської частини

8

1.2.3 Порядок здачі та захисту курсового проекту

Пояснювальна записка вкладається у папку-швидкозшивач з прозорим

верхом формату А4. Порядок розташування розділів проекту має відповідати

структурі приведеній у пункті 1.2.2. В папку-швидкозшивач в кінці також

вкладається конверт з CD/DVD диском на якому має бути записана електронна

версія пояснювальної записки, модель бази даних, SQL-скрипт бази даних,

програмний код веб-сайту та інші супровідні матеріали.

Курсовий проект захищається після перевірки керівником курсового

проекту всіх розділів та програмного коду, про що свідчать підписи керівника та

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

1.3 Вимоги до змісту пояснювальної записки

1.3.1 Титульний аркуш

Титульний аркуш є першим аркушем документа. Він виконується

згідно ГОСТ 2.105-95 на аркушах формату А4 (210x297 мм). Загальний вигляд і

приклад оформлення титульного аркушу наведений у додатку А.

1.3.2 Технічне завдання

Технічне завдання на проектування (завдання на курсовий проект)

видається викладачем. Технічне завдання має бути підписане студентом,

керівником курсового проекту (роботи), завідувачем кафедри, на якій

створоється курсовий проект. Технічне завдання обов’язково має буди

прикріплене до пояснювальної записки. Воно має бути розташоване одразу після

титульного аркушу.

9

1.3.3 Реферат

Реферат має містити коротку анотацію того, що було виконано в роботі по

розділах, коротко викладаються відомості про обсяг курсової роботи, кількість і

характер ілюстрацій, а також про кількість використаних джерел; Приклад

наведено у додатку Б.

1.3.4 Зміст

У текстових документах обсягом більш 10 сторінок поміщають зміст. Він

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

пунктів (якщо вони мають заголовки).

Слово «ЗМІСТ» записують у виді заголовка симетрично тексту

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

літерами, починаючи з прописної. Зміст включають у загальну кількість сторінок

пояснювальної записки. Зміст виконують відповідно до ГОСТ 2.105-95 та ДСТУ

3008-95. Для курсових робіт, перший аркуш змісту оформлюється з основним

написом за формою 2, а інші аркуші проекту за формою 2а згідно ГОСТ2.104.

1.3.5 Вступ

У вступі коротко надається інформація про актуальність розробки веб-

сайту. Також формулюється мета роботи.

Обсяг вступу 1...2 сторінки.

1.3.6 Основна частина

В основній частині висвітлюється аналіз вимог до обраної теми, основні

етапи розробки бази даних та веб-додатку. Розділи, які повинні бути описані в

основній частині вказано у пункті 1.2.2.

10

1.3.7 Висновки

Висновок містить оцінку узагальнених результатів виконання курсового

проекту (роботи) та повинен знаходитися в повному взаємозв'язку із вступом і

основною змістовною частиною. Потрібно дати короткий підсумок по

виконанню кожного з розділів роботи з конкретними результатами здійснення

процедури програмування. Висновок повинен чітко відповідати визначеним

завданням роботи (містити відповіді на поставлені в роботі завдання).

1.3.8 Список літератури

Список повинний містити перелік літератури, використаної при виконанні

проекту. Перелік літератури записується відповідно вимог ДСТУ ГОСТ 7.1:2006.

Приклад оформлення приведений у додатку В.

1.3.9 Оформлення додатків

Додатки оформлюються як продовження пояснювальної записки за ГОСТ

2.105-95. У тексті пояснювальної записки необхідно обов’язково приводити

посилання на додатки.

11

2 ПРАВИЛА ОФОРМЛЕННЯ ТЕКСТОВИХ ДОКУМЕНТІВ

2.1 Загальні положення

Текстові документи підрозділяють на документи, що містять, в основному,

суцільний текст (технічні умови, розрахунки, пояснювальні записки, інструкції і

т.п.), і документи, що містять текст, розбитий на графи (специфікації, відомості,

таблиці і т.п.) і виконують за ГОСТ 2.105-95.

Пояснювальну записку курсових робіт виконують на одній стороні

нелінованих аркушів білого паперу формату А4 (210х297 мм) оформлених згідно

вимог ДСТУ ГОСТ 2.104 – 2006. Пояснювальну записку виконують одним з

наступних способів:

– машинописним, при цьому шрифт друкарської машинки повинний бути

чітким, висотою не менш 2,5 мм, стрічка тільки чорного кольору (напівжирна);

– рукописним – креслярським шрифтом по ГОСТ 2.304 - 81 з висотою букв

і цифр не менше 2,5 мм. Цифри і букви необхідно писати чітко чорними тушшю,

чорнилами або пастою;

– із застосуванням друкуючих і графічних пристроїв виводу ЕОМ (ГОСТ

2.004-88). Рекомендується використовувати шрифт Times New Roman, розмір 14,

інтервал 1,5.

Вписувати в пояснювальну записку, виготовлену машинописним

способом, окремі слова, формули, умовні знаки, а також, виконувати ілюстрації

треба чорними чорнилами, пастою або тушшю.

При виконання текстових документів на звичайних аркушах формату А4

відстань до тексту зверху, знизу і ліворуч від країв аркуша – не менш 20 мм,

праворуч - не менш 10 мм.

Абзаци в тексті починають відступом, рівним 15 – 17 мм.

Помилки, описки і графічні неточності допускається виправляти

підчищенням або зафарбовуванням білою фарбою і нанесенням на тому ж місці

виправленого тексту (графіки) машинописним або рукописним способом.

12

2.2 Вимоги до пояснювальної записки, що містить суцільний текст

2.2.1 Побудова документа

Текст документа при необхідності розділяють на розділи і підрозділи.

Розділи повинні мати порядкові номери в межах усього документа

позначені арабськими цифрами без крапки і записані з абзацного відступу.

Підрозділи повинні мати нумерацію в межах кожного розділу. Номер

підрозділу складається з номерів розділу і підрозділу, розділених крапкою.

Наприкінці номера підрозділу крапка не ставиться.

Розділи, як і підрозділи, можуть складатися з одного або декількох пунктів.

Якщо документ не має підрозділів, то нумерація пунктів у ньому повинна

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

розділу і пункту, розділених крапкою. Наприкінці номера пункту крапка не

ставиться.

Якщо документ має підрозділи, то нумерація пунктів повинна бути в межах

підрозділу і номер пункту повинний складатися з номерів розділу, підрозділу і

пункту, розділених крапками, наприклад:

1 ТИПИ І ОСНОВНІ РОЗМІРИ

1.1

1.2 Нумерація пунктів першого розділу документа

1.3

2 МЕТОДИ ВИПРОБУВАНЬ

2.1 Апарати, матеріали і реактиви

2.1.1

2.1.2 Нумерація пунктів першого підрозділу другого

2.1.3 розділу документа

Перед кожною позицією перелічення слід ставити дефіс або при

13

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

якої ставиться дужка. Для подальшої деталізації перелічень необхідно

використовувати арабські цифри, після яких ставиться дужка, а запис виконується

з абзацного відступу, як показано в прикладі.

Приклад

а) ____________________

б) ____________________

1)__________

2)__________

в)_____________________

Кожний пункт, підпункт і перелічення записують з абзацного відступу.

Заголовки розділів слід друкувати прописними буквами, а підрозділів і

пунктів – малими літерами, починаючи з прописної, без крапки наприкінці, не

підкреслюючи. Переноси слів у заголовках не допускаються. Якщо заголовок

складається з двох речень, їх розділяють крапкою.

Відстань між заголовком і текстом при виконанні документа

машинописним способом повинна дорівнювати 3, 4 інтервалам, при виконанні

рукописним способом – 15 мм. Відстань між заголовками розділу і підрозділу – 2

інтервали, при виконанні рукописним способом – 8 мм (Додаток Д).

Кожний розділ текстового документа рекомендується починати з нового

аркуша (сторінки).

Слово "ЗМІСТ" записують у виді заголовка (симетрично тексту)

прописними буквами. Найменування, включені в зміст, записують малими

літерами, починаючи з прописної букви.

Наприкінці текстового документа приводять “СПИСОК

ВИКОРИСТАНОЇ ЛІТЕРАТУРИ”, яка була використана при його складанні.

Виконання списку і посилання на нього в тексті – за ГОСТ 7.32-2001.

Список літератури включають у зміст документа. Приклад бібліографічного опису

14

творів друку в списку літератури приведений у додатку Г.

Нумерація аркушів документа і додатків, що входять до складу документа,

повинна бути наскрізна.

2.2.2 Виклад тексту документів

Текст пояснювальної записки повинний бути коротким, чітким і не

допускати різних тлумачень.

У пояснювальній записці повинні застосовуватися науково-технічні

терміни, позначення і визначення, встановлені відповідними стандартами, а при

їхній відсутності – загальноприйняті в науково-технічній літературі.

Якщо в пояснювальній записці прийнята специфічна термінологія, то

наприкінці її (перед списком літератури) повинний бути перелік прийнятих

термінів з відповідними роз'ясненнями. Перелік включають у зміст документа.

У тексті пояснювальної записки не допускається:

- застосовувати обороти розмовної мови, техніцизму, професіоналізму;

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

близькі за змістом (синоніми), а також іноземні слова і терміни при наявності

рівнозначних слів і термінів в українській мові;

- застосовувати довільні словотворення;

- застосовувати скорочення слів, крім установлених правилами української

орфографії, що відповідають державним стандартам, а також у даному документі;

- скорочувати позначення одиниць фізичних величин, якщо вони

вживаються без цифр, за винятком одиниць фізичних величин у головках і

боковиках таблиць і в розшифровках літерних позначень, що входять у формули

і рисунки.

У тексті пояснювальної записки, за винятком формул, таблиць і рисунків,

не допускається:

– застосовувати математичний знак мінус (–) перед негативними

значеннями величин (слід писати слово "мінус");

15

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

розмірів у дюймах, які слід записувати ¼ ; ½ (але не 4

1 ,

2

1 ).

При неможливості вказати числове значення у виді десяткового дробу,

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

наприклад: 5/32.

2.2.3 Оформлення формул і розрахунків

У формулах як символи слід застосовувати позначення, установлені

відповідними державними стандартами. Пояснення кожного символу слід давати

з нового рядка в тій послідовності, у якій символи приведені у формулі. Перший

рядок пояснення повинен починатися зі слова "де" з абзацного відступу без

двокрапки після нього. Продовжувати формулу, записану умовними

позначеннями, числовими розрахунками заборонено.

Приклад.

Щільність кожного зразка ρ, кг/м3, обчислюють по формулі (1):

= V

m, (1)

де m - маса зразка, кг;

V - об’єм зразка, м3.

Формули, що йдуть одна за наступною і не розділені текстом, розділяють

комою.

Переносити формули на наступний рядок допускається тільки на знаках

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

При переносі формули на знаку множення застосовують знак “х”.

Формули, за винятком формул, що поміщаються в додатку, повинні

нумеруватися наскрізною нумерацією арабськими цифрами, що записують на

рівні формули праворуч у круглих дужках. Одну формулу позначають – (1).

Посилання в тексті на порядкові номери формул дають у дужках,

наприклад, ... у формулі (1). Допускається нумерація формул у межах розділу. У

16

цьому випадку номер формули складається з номера розділу і порядкового номера

формули, розділених крапкою, наприклад (3.1).

Формули, що поміщаються в додатках, повинні нумеруватися окремою

нумерацією арабськими цифрами в межах кожного додатка з додаванням перед

кожною цифрою позначення додатка, наприклад формула (В.1).

2.2.4 Оформлення приміток, посилань і виносок

Примітки слід поміщати безпосередньо після текстового, графічного

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

букви з абзацу. Якщо примітка одна, то після слова "Примітка" ставиться тире і

примітка друкується теж із прописної букви. Одну примітку не нумерують.

Примітки не повинні містити вимог.

Примітка – Графік побудований за результатами розрахунків.

Декілька приміток нумерують одна за одною арабськими цифрами.

Примітки

1 Веб-додаток є кросплатформним.

2 Для коректної роботи додатку, необхідно щоб у браузері було

увімкнено JavaScript.

У текстовому документі допускаються посилання на даний документ,

стандарти, технічні умови і інші документи. Посилання здійснюються у

квадратних дужках. Наприклад, [8], [1,3,7,15], [2-8].

2.2.5 Оформлення ілюстрацій і додатків

Кількість ілюстрацій повинна бути достатньою для пояснення тексту.

Ілюстрації (креслення, рисунки, графіки, схеми, діаграми) слід розміщувати

безпосередньо після тексту записки, де вони згадуються вперше, або на наступній

сторінці.

Ілюстрації повинні виконуватись відповідно до вимог стандартів. На всі

17

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

Ілюстрації, за винятком ілюстрацій додатків, слід нумерувати арабськими

цифрами наскрізною нумерацією. Якщо рисунок один, то він позначається

"Рисунок 1" . Допускається нумерувати ілюстрації в межах розділу. У цьому

випадку номер ілюстрації складається з номера розділу і порядкового номера

ілюстрації, розділених крапкою. Наприклад – Рисунок 1 .1.

Ілюстрації кожного додатка позначають окремою нумерацією арабськими

цифрами з додаванням перед цифрою позначення додатка. Наприклад – Рисунок

А.3 .

При посиланнях на ілюстрації слід писати "... відповідно до рисунка 2"

при наскрізній нумерації та "... відповідно до рисунка 1.2" при нумерації в

межах розділу.

Ілюстрації при необхідності, можуть мати назву і пояснювальні дані

(підрисунковий текст). Слово "Рисунок" і назву розміщують після пояснювальних

даних наступним чином.

1 – шапка сайту; 2 – навігаційне меню; 3 – основний контент

Рисунок 1 – Інтерфейс сайту

Кожний додаток слід починати з нової сторінки з указівкою нагорі

18

посередині сторінки слова " Додаток " і його позначення, а під ним у дужках для

обов'язкового додатка пишуть слово "обов'язковий", а для інформаційного –

"рекомендований" або "довідковий".

Додаток повинний мати заголовок, що записують симетрично тексту з

прописної букви окремим рядком.

Додатки позначають заголовними буквами української абетки, починаючи

з А за винятком букв Ґ, Є, З, І, Ї, Й, О, Ч, Ь. Після слова "Додаток" іде буква, що

позначає його послідовність. Якщо в документі один додаток, він позначається

“Додаток А”.

2.2.6 Побудова таблиць

Назву слід поміщати над таблицею відповідно до рисунка 2.

Таблиці, за винятком таблиць додатків, слід нумерувати арабськими

цифрами наскрізною нумерацією.

Таблиці кожного додатка позначають окремою нумерацією арабськими

цифрами з додаванням перед цифрою позначення додатка. Якщо в документі одна

таблиця, вона повинна бути позначена "Таблиця 1" або "Таблиця В.1”, якщо вона

приведена в додатку В.

Допускається нумерувати таблиці в межах розділу. У цьому випадку номер

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

крапкою.

На всі таблиці документа повинні бути приведені посилання в тексті

документа, при посиланні слід писати слово "таблиця" із указівкою її номера.

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

необхідності допускається перпендикулярне розташування заголовків граф.

Слово “Таблиця” вказують один раз ліворуч над першою частиною

таблиці, над іншими частинами пишуть слова “Продовження таблиці” із

указівкою номера (позначення) таблиці.

Якщо наприкінці сторінки таблиця переривається і її продовження буде на

19

наступній сторінці, у першій частині таблиці нижню горизонтальну лінію, що

обмежує таблицю, не проводять.

Рисунок 2

Продовження таблиці 1

1 2 3 4 5

4,0 1,0 1,2 1,0 1,2

4,5 1,2 1,4 - -

Рисунок 3

2.2.7 Приклади

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

вимоги документа або сприяють більш короткому їх викладу. Приклади

розміщають, нумерують і оформляють так само, як і примітки.

20

3 ВКАЗІВКИ ДО ВИКОНАННЯ РОЗДІЛІВ КУРСОВОГО

ПРОЕКТУ

Розділи основної частини курсового проекту необхідно створювати

наступним чином:

3.1 Розділ «1 Аналіз вимог»

3.1.1 Глава «1.1. Постановка завдання»

У відповідності до змісту роботи та виданого завдання ставляться мета та

задачі розробки. Виконується у відповідності до розділу 1 даних методичних

вказівок.

В цій главі також слід вказати розміщення Bitbucket репозиторію з

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

Приблизний обсяг розділу – 1 аркуш.

3.1.2 Глава «1.2. Розробка моделі варіантів використання веб-сайту»

Для того, щоб більш точно зрозуміти як повинна працювати система, все

частіше використовується опис функціональності системи через варіанти

використання (Use Case або прецеденти). Варіанти використання це - опис

послідовності дій, які може здійснювати система у відповідь на зовнішні впливи

користувачів або інших програмних систем. Варіанти використання

відображають функціональність системи з точки зору отримання відчутного

результату для користувача, тому вони точніше дозволяють ранжувати функції за

значимістю одержуваного результату.

Варіанти використання призначені в першу чергу для визначення

функціональних вимог до системи і керують усім процесом розробки. Всі основні

види діяльності такі як аналіз, проектування, тестування виконуються на основі

21

варіантів використання. Під час аналізу і проектування варіанти використання

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

архітектуру системи і як повинні поводитися компоненти системи, для того щоб

реалізувати потрібну для користувача функціональність.

Варіанти використання ілюструються за допомогою діаграми варіантів

використання. Діаграма варіантів використання складається з акторів, для яких

система виробляє дію і власне варіанти використання (Use Case), які описують те,

що актор хоче отримати від системи. Актор позначається значком чоловічка, а

варіанти використання - овалом. Додатково в діаграми можуть бути додані

коментарі.

Відповіді на такі питання дозволять визначити акторів, що взаємодіють з

системою:

хто взаємодіє з системою або використовує систему;

хто передає чи приймає інформацію в/з системи;

хто є зовнішнім по відношенню до системи.

Кожен варіант використання показує, як конкретний актор використовує

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

Рисунок 1.1 - Діаграма варіантів використання

22

Між акторами і варіантами використання можуть бути різні види взаємодії.

Основні види взаємодії наступні:

Проста асоціація - відображається лінією між актором і варіантом

використання (без стрілки). Відображає зв'язок актора і варіанта використання.

Спрямована асоціація - те ж що і проста асоціація, але показує, що

варіант використання ініціалізуєтся актором. Позначається стрілкою.

Спадкування - показує, що нащадок успадкує атрибути і поведінку

свого прямого предку. Може застосовуватися як для акторів, так для варіантів

використання.

Розширення (extend) - показує, що варіант використання розширює

базову послідовність дій і вставляє власну послідовність. При цьому на відміну

від типу відносин "включення" розширена послідовність може здійснюватися в

залежності від певних умов.

Включення (include) - показує, що варіант використання включається

в базову послідовність і виконується завжди (на рисунку не показаний).

Існують і інші види взаємодії, але вони менш важливі і рідше

застосовуються.

Для створення діаграми використання можна використовувати редактор

діаграм UML StarUML, або інший.

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

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

використання.

Основний потік описує «ідеальний» хід розвитку подій у варіанті

використання. Альтернативні потоки можуть перехоплювати помилки,

відгалуження і переривання основного потоку.

Основний потік завжди починається з дій головного актора, спрямованих

на ініціацію варіанту використання.

Спеціфікація варіантів використання приведена у таблиці 1.1.

23

Таблиця 1.1 - Специфікація варіанту використання

Варіант використання: Подача заявки

ID: 1

Короткий опис:

Клієнт подає заявку на виконання робіт з обслуговування будинку.

Головні актори:

Клієнт

Другорядні актори:

Немає

Передумови:

1 Клієнт зареєстрований в Системі

Основний потік:

1 Варіант використання починається коли Клієнт вводить команду створення

нової заявки.

2 Клієнт вибирає тип послуги, яку йому треба виконати.

3 Клієнт описує детально роботу, яку необхідно виконати.

4 Система встановлює поточну дату та час подачі заявки.

5 Система присвоює заявці статус 1 - "Очікує розгляду".

Постумови:

1 Диспетчер отримує заявку клієнта на обробку.

Альтернативні потоки:

Немає.

Вдалим способом початку потоку можна визначити таку форму запису:

Прецедент починається, коли <актор> <дія>.

Кожен етап потоку варіанту використання повинен бути виражений в такій

формі:

<Номер> <хтось> <робить деяку дію>.

Використання пасивного стану для опису етапу є невірним: «Вводяться

дані покупця».

24

Альтернативні потоки можуть бути замінені за допомогою ключового

слова «Якщо».

Основний потік:

1 Варіант використання починається коли Клієнт вибирає заявку зі списку.

2 Якщо Клієнт вибирає "видалити заявку".

2.1 Система призначає заявці статус "Відхилена".

3.2 Розділ «2 Розробка бази даних»

3.2.1 Глава «2.1 Опис моделі даних»

Аналіз предметної області складається з аналізу даних та аналізу завдань.

Аналіз даних передбачає документування всіх атрибутів. Аналіз завдань може

потребувати застосування різноманітних методів побудови діаграм для

дослідження зв'язків і способів використання даних, подій, станів даних, а також

детального опису алгоритмів [1].

До ключового результату етапу аналізу належить узгоджена діаграма

сутностей і зв'язків.

Мова ER-моделювання (від англ. Enticy-Relationship — сутність-зв'язок)

— це графічна мова, призначена для опису інформаційних потреб організації.

Мова базується на концепції, згідно з якою інформаційне забезпечення будь-якої

предметної області зображується як сукупність взаємозв'язаних об'єктів. Процес

моделювання полягає у виділенні об'єктів (сутностей предметної області),

визначенні їхніх властивостей і виявленні зв'язків між ними [1, с. 157-171].

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

використання, яка була розроблена в розділі 1. Задача розробника на даному етапі

полягає в виявленні об'єктів даних та їх властивостей в описі варіантів

використання веб-сайта. Такі об'єкти на діаграмі сутностей і зв'язків є сутностями

— реальними або уявними об'єктами, інформація про які має бути зібрана чи

збережена [1]. Відповідно, певні властивості об'єктів представляються

25

атрибутами. Атрибут — це деталь або аспект якісного чи кількісного опису

сутностей, їхньої ідентифікації, класифікації або відображення їхнього стану [1].

Також на діаграмі відображаються зв'язки — пойменовані асоціації двох або

більшої кількості сутностей [1].

Для всіх сутностей слід визначити первинні ключі. На діаграмі вони

позначаються як PK. Первинні ключі є механізмом забезпечення цілісності

відношень.

Діаграма сутностей і зв'язків, яка розробляться на даному етапі, має

максимально відповідати сформованим вимогам до системи, дозволяти зберігати

всю необхідну інформацію. В той же час ця діаграма може мати певні небажані

властивості або аномалії. Їх усунення відбуватиметься в процесі нормалізації

реляційних відношень в наступній главі шляхом еквівалентних перетворень

первинної моделі реляційних відношень.

Пояснювальна записка має містити діаграму сутностей і зв'язків з

необхідними поясненнями.

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

можна створити за допомогою редактора діаграм UML StarUML, або іншого

подібного. Приклад діаграми наведений на рисунку 1.2.

Рисунок 1.2 - Діаграма сутностей і зв'язків

26

Найменування сутностям та атрибутам слід давати латинськими буквами -

англійською мовою або в транслітерації українських літер. В останньому випадку,

можна скористатись яким-небудь зручним онлайн конвертором.

Сутності та атрибути іменуються в однині.

Також при написанні найменувань сутностей та атрибутів слід обрати один

стиль написання та дотримуватись його впродовж всього проекту/роботи.

Загально прийнятими є два стилі написання складових слів:

Верблюжий регістр (від англ. camelCase) — стиль написання

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

кожне слово пишеться з великої літери. Приклади написання у верблюжому

регістрі: firstName, serviceTeam.

Зміїний регістр (від англ. snake_case) — стиль написання, у якому

слова розділяються не пробілами, а символом підкреслення _, причому кожне

слово пишеться з малої літери. Приклади написання у зміїному регістрі:

first_name, service_team.

Для повноти розуміння предметної області необхідно також привести

приклади данних в реляційних відношеннях. Приклад наведено в таблиці 1.2.

Таблиця 1.2 - Реляційне відношення "request"

idReq

uest dateTime user profile service description

serviceTea

m status

145 2016-09-

04 14:25

Супрун

І.О. сантехніка

-Монтаж

водопровод

у

-Заміна

арматури

-Чистка

каналізації

Прочистити

каналізацію

Панасенко,

Мірошниче

нко

2016-09-

04 14:25 -

1

2016-09-

04 16:40 -

3

2016-09-

07 13:15 -

4

146 2016-09-

04 15:05

Ковален

ко П.С. електрика

-Усунення

аварійних

відключень

-Монтаж

електропро

водки

Немає

електрики в

квартирі

Пашко,

Коваль

2016-09-

04 15:05 -

1

2016-09-

04 17:25 -

2

27

3.2.2 Глава «2.2 Нормалізація реляційних відношень»

Діаграма сутностей і зв'язків є, по суті, графічним представленням моделі

реляційних відношень. Задачею даного етапу проекту/роботи є перетворення

отриманої раніше первинної схеми на іншу схему, що еквівалентна в певному

розумінні початковій і в якій відсутні певні небажані властивості, або аномалії.

Схема реляційних відношень (діаграма сутностей і зв'язків) побудована в

п. 2.1 має пройти перевірку на відповідність шести нормальним формам:

перша нормальна форма (1НФ);

друга нормальна форма (2НФ);

третя нормальна форма (3НФ);

нормальна форма Бойса-Кодда (НФБК);

четверта нормальна форма (4НФ);

п'ята нормальна форма (5НФ).

При виконанні цієї глави проекту/роботи слід для кожної нормальної

форми послідовно:

сформулювати та привести в тексті правило нормальної форми;

перевірити всі реляційні відношення, отримані з моменту останнього

еквівалентного перетворення схеми, на відповідність нормальній формі;

в разі, якщо виявлено невідповідність поточної схеми відношень

нормальній формі, слід виконати зведення (еквівалентне перетворення)

відношень до необхідної нормальної форми; в тексті проекту пояснити виконані

перетворення;

привести діаграму сутностей і зв'язків з урахуванням виконаного

перетворення (якщо воно виконувалось); ця схема буде вихідною для наступної

нормальної форми.

Для прикладу розглянемо на відповідність першій нормальній формі

моделі зображеній на рисунку 1.2.

28

Реляційне відношення перебуває в першій нормальній формі (1НФ), якщо

всі йоги атрибути мають атомарні (прості) домени, відтак значення елементів

таблиці є простими [1].

Перевірка реляційних відношень показала, що у відношенні request

наявна невідновідність вимогам 1НФ - атрибут status містить неатомарні

значення. З таблиці 1.2 видно що за цим атрибутом перелічуються всі статуси

відповідної заявки.

Для зведення реляційних відношень до 1НФ виділимо атрибут status в

окреме відношення status і зв'яжимо його з відношенням request. Слід також

вімітити, що аналіз прикладу даних атрибуту status (табл. 1.2) демонструє

моєжливість виділити в новому відношенні додаткові атрибути - дата та час зміни

статусу, коментар до зміни статусу. Результат зведення до 1НФ приведено на рис.

1.3.

Рисунок 1.3 - Діаграма сутностей і зв'язків після приведення до 1НФ

3.2.3 Глава «2.3 Визначення типів даних»

Нормалізовані реляційні відношення отримані в попередній главі не

містять атрибутів, які є зовнішніми ключами, тобто реалізують зв'язки між

29

відношеннями. В проекті/роботі треба представити діаграму з цими атрибутами

(рис. 1.4). Зовнішні ключі слід позначати як FK і пам'ятати, що тип данних

зовнішнього ключа має співпадати з типом даних первинного ключа пов'язаного

відношення. Назви зовнішніх ключів також варто давати у відповідності до назв

пов'язаних відношень.

Рисунок 1.4 - Діаграма сутностей і зв'язків з зовнішніми ключами

Для атрибутів реляційних відношень необхідно визначити:

зазначення типів даних та їхніх розмірів (обов'язкова властивість);

чи є обов'язковим значення атрибута;

чи може значення атрибута дублюватися;

можливі значення за замовчуванням.

30

Ці данні є важливим елементом забезпечення цілісності атрибутів

рляційних відношень.

В проекті/роботі слід задокументувати типи даних за прикладом

наведеним в табл. 1.3.

Таблиця 4.3 - Типи даних реляційного відношення "request"

Атрибут Тип даних Розмір Додаткові обмеженні

цілісності

idRequest BIGINT 20 первинний ключ

dateTime DATETIME - обов'язковий

user INT 10 зовнішній ключ

profile INT 10 зовнішній ключ

description MEDIUMTEXT - обов'язковий

serviceTeam INT 10 зовнішній ключ

3.2.4 Глава «2.4 Обмеження цілісності даних»

Обмеження цілісності — це правила, які обмежують усі можливі стани

бази даних, а також переходи з одного стану в інший. Таким чином, обмеження

цілісності визначають множину «допустимих» станів і переходів між ними. База

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

вимогам цілісності.

Декларативні обмеження цілісності — це обмеження, що фіксують умови,

яким має відповідати база даних. Завдання СКБД - не допускати порушення цих

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

структури даних. Прикладом такого обмеження є: «Фонд зарплати факультету має

бути рівним сумі фондів зарплати всіх його кафедр». Декларативні обмеження

цілісності специфікуються фразою CONSTRAINT в описі таблиці або її полів.

Процедурні обмеження цілісності — це описи дій, спрямованих на

забезпечення цілісності. Прикладом такого обмеження є: «Під час зміни фонду

зарплати будь-якої з кафедр автоматично змінити фонд зарплати факультету так,

щоб він дорівнював сумі фондів зарплати усіх кафедр». Процедурні обмеження

цілісності специфікуються тригерами.

31

За часом перевірки обмеження цілісності поділяються на такі, що:

перевіряються негайно;

мають відкладену перевірку.

Обмеження, що перевіряються негайно, перевіряються безпосередньо у

момент виконання операції, яка може порушити цілісність. Наприклад,

неповторюваність назви факультету перевіряється під час додавання нового рядка

до таблиці, яка містить інформацію про факультети, або під час заміни імені

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

операція блокується.

Обмеження цілісності з відкладеною перевіркою використовуються у

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

виконати дві або більше операції. Прикладом обмеження цілісності, яке не може

бути перевірено негайно, є декларативне обмеження щодо фондів заробітної

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

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

фінансування факультету стає не рівним сумі фондів фінансування його кафедр.

Для того щоб повернути базу даних у несуперечний стан, потрібно виконати ще

одну операцію — оновити фонд фінансування факультету. У такому випадку ці

дві операції об’єднуються в одну транзакцію і обмеження цілісності перевіряється

після її завершення.

За областю дії розрізняють обмеження, що стосуються:

відношення;

атрибута;

зв’язків між відношеннями;

зв’язків між атрибутами.

За можливістю обмежувати переходи бази даних з одного стану в інший

обмеження цілісності поділяються на:

статичні;

динамічні.

32

Статичні обмеження цілісності накладають обмеження на можливі стани

бази даних. Наприклад, декларативні обмеження цілісності, що описуються далі,

є статичними.

Динамічні обмеження цілісності задають обмеження на можливі переходи

бази даних з одного стану в інший.

Цілісність відношень

У реляційній СКБД цілісність відношень визначається за допомогою

первинного ключа, для якого мають виконуватися такі обмеження цілісності:

атрибути первинного ключа не можуть містити NULL-значень;

значення первинного ключа (як окремого атрибута або сукупності

атрибутів) не можуть дублюватися в межах відношення.

Цілісність за первинним ключем специфікується так:

CONSTRAINT <ім’я обмеження> PRIMARY KEY (<перелік полів>)

де <перелік полів> — поля, що складають первинний ключ.

Ця специфікація вказує, які саме поля є ключовими.Для специфікації

можливих ключів використовується фраза UNIQUE.

Механізм підтримки цілісності відношень реалізує СКБД

Цілісність атрибутів

У реляційній СКБД цілісність атрибутів може забезпечуватися:

зазначенням типів даних та їх розмірів (обов’язкова властивість);

визначенням, чи є обов’язковим значення атрибута (NULL/NOT

NULL);

визначенням, чи може значення атрибута дублюватися (UNIQUE):

зміною значення атрибута після його введення;

встановленням умов, яким мають відповідати значення атрибута.

Для похідних атрибутів цілісність має гарантуватися процедурою їхнього

обчислення. Цілісність атрибутів специфікується фразами NULL/NOT NULL і

UNIQUE у визначенні атрибута (поля).

Якщо унікальними мають бути значення не окремих полів, а сукупності

полів, то це вказується так:

33

CONSTRAINT <ім'я обмеження> UNIQUE (<перелік полів>)

Цілісність атрибутів специфікується також зазначенням обмеження

CONSTRAINT <і м’я обмеження> CHECK (<умова>)

Умова визначається на атрибутах відношення. Фраза CHECK може також

вказуватися в означенні атрибута.

Цілісність зв’язків між відношеннями

Цілісність зв’язків між відношеннями визначається зовнішніми ключами.

Під час специфікації зовнішнього ключа вказується відповідний йому первинний

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

Відношення, на яке здійснюється посилання за допомогою зовнішнього

ключа, називається батьківським, а те, яке посилається, — дочірнім.

Якщо зовнішній ключ певного відношення може містити NULL-значення,

це означає, що зв’язок даного відношення з іншим є факультативним. NOT NULL-

специфікація стовпців зовнішнього ключа свідчить, що зв’язок є обов’язковим

Означення зовнішнього ключа свідчить про наявність цілісності за посиланням:

значення зовнішнього ключа має посилатися на значення первинного ключа

іншого відношення. Тобто ситуація, коли зовнішній ключ має значення, відсутнє

серед значень відповідного первинного ключа, розглядається як ситуація, що

порушує цілісність за посиланням.

Механізм підтримки цілісності за посиланням реалізує СКБД. Розглянемо,

як діє механізм під час видалення рядка з батьківської таблиці. Можливі три

варіанти:

рядок батьківської таблиці може бути видалений лише в тому випадку,

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

ключа цього рядка:

під час видалення рядка батьківської таблиці видаляються також усі рядки

в інших таблицях, значення зовнішніх ключів яких посилаються на значення

референційного ключа цього рядка (каскадне видалення);

під час видалення рядка батьківської таблиці всі посилання на значення

видаленого референційного ключа замінюються на NULL.

34

Відсутність фрази [ON DELETE {CASCADE | SET NULL}] вказує на

перший варіант. Фраза ON DELETE CASCADE в специфікації референційної

цілісності вказує на другий варіант, a ON DELETE SET NULL - на третій.

Цілісність зв’язків між атрибутами

Цілісність зв’язків між атрибутами визначається умовою, якій має

відповідати сукупність атрибутів одного або кількох відношень. Такі умови

специфікуються тригерами.

3.2.5 Глава «2.5 Індекси»

Індексація дозволяє прискорити виконання операцій SELECT проте

сповільнює операції INSERT та DELETE. Індекс зберігається в службовій таблиці,

яка містить два поля. Перше поле представляє впорядковане значення індексу а

друге – ідентифікатор запису в таблиці для якої створюється індекс. Індекси

можна створювати як по одному, так і по декількох полях. При вказанні декількох

індексних полів записи групуються по значенню першого індексу, всередині

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

EXAM_MARKS часто використовується для пошуку оцінок окремих студентів.

Створюємо індекс цієї таблиці по полю STUDENT_ID

CREATE INDEX student_marks ON exam_marks(student _id);

Ім’я індекса (в даному випадку student_marks) має бути унікальним в базі

даних. Сама таблиця (exam_marks) повинна бути створена і містити стовпці, по

яких вона індексується. Після створення індексу всі подальші операції з ним

здійснює СУБД. Якщо оцінки студентів необхідно впорядковувати ще й по даті,

то оголошення індексу слід модифікувати

CREATE INDEX student_marks ON exam_marks(student _id,

exam_date)

Для усунення індексу використовується команда DROP INDEX, наприклад

DROP INDEX student_marks;

35

3.2.6 Глава «2.6 Тригери»

Тригери є однією з різновидів збережених процедур. Їх виконання

відбувається при виконанні таблиці будь-якого оператора мови маніпулювання

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

також для відкоту транзакції.

Тригер – це скомпільована SQL-процедура, виконання якої зумовлене

настанням певних подій всередині реляційної бази даних. Застосування тригерів

здебільшого є дуже зручним для користувачів бази даних. І все ж, їх використання

часто пов'язано з додатковими витратами ресурсів на операції введення/виводу. У

тому випадку, коли тих же результатів (з набагато меншими непродуктивними

витратами ресурсів) можна домогтися за допомогою збережених процедур або

прикладних програм, застосування тригерів недоцільно.

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

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

тригери пов'язані. Кожен тригер прив'язується до конкретної таблиці. Всі

вироблені ним модифікації даних розглядаються як одна транзакція. У разі

виявлення помилки або порушення цілісності даних відбувається відкат цієї

транзакції. Тим самим внесення змін забороняється. Скасовуються також всі

зміни, зроблені тригером.

Створює тригер лише власник бази даних. Це обмеження дозволяє

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

об'єктів і т. п.

Тригер являє собою дуже корисний і в той же час небезпечний засіб. Так,

при неправильній логіці його роботи можна легко знищити цілу базу даних, тому

тригери необхідно дуже ретельно налагоджувати.

На відміну від звичайної підпрограми, тригер виконується неявно у

кожному разі виникнення тригерної події, до того ж він не має аргументів.

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

досягаються наступні цілі:

36

перевірка коректності введених даних і виконання складних обмежень

цілісності даних, які важко, якщо взагалі можливо, підтримувати з допомогою

обмежень цілісності, встановлених для таблиці;

видача попереджень, нагадують про необхідність виконання деяких

дій при оновленні таблиці, реалізованому певним чином;

накопичення аудиторської інформації за допомогою фіксації

відомостей про внесені зміни і тих осіб, які їх виконали;

підтримка реплікації.

Основний формат команди CREATE TRIGGER показано нижче:

<Визначення_тригера>::=

CREATE TRIGGER ім'я_тригера

BEFORE | AFTER <подія_тригера>

ON <ім’я_таблиці>

[REFERENCING

<список_старих_чи_нових_ псевдонімів >]

[FOR EACH { ROW | STATEMENT}]

[WHEN(умова_тригера)]

<тіло_тригера>

3.2.7 Глава «2.7 Реалізація SQL-скрипту»

Остаточний варіант SQL-скрипту, який реалізує структуру бази даних,

необхідно приводити в додатках.

3.3 Розділ «3 розробка веб-додатку»

3.3.1 Глава «3.1 Структура веб-сайту»

У даному розділі необхідно описати основне призначення веб-сайту,

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

основні сторінки веб-сайту та коротко описати функціональне призначення

кожної з них.

37

3.3.2 Глава «3.2 Макети сторінок веб-сайту»

Даний розділ повинен містити опис макету веб-сторінок, який може

включати:

вид макету;

інформацію про розмітку макету;

розміри основних елементів макету;

визначення фону для макета.

Для кращого представлення макету рекомендується окрім текстового

опису доповнювати його схематичними зображеннями та скриншотами основних

сторінок.

3.3.3 Глава «3.3 Програмування серверної частини»

Серверні скрипти виконуються сервером за запитом, що посилається

клієнтським додатком (браузером). Можливості серверних скриптів досить багаті.

Серверні скрипти можуть, наприклад, обробляти дані з форм, генерувати

динамічні сторінки або відсилати й приймати cookies. За допомогою серверних

скриптів можна створювати гостьові книги, чати, опитування, зберігати захищені

паролем дані. Також жоден інтернет-магазин не обійдеться без серверних

скриптів з їхньою допомогою користувач може розрахувати загальну вартість

покупки, вносити зміни у свій купівельний «кошик», фіксувати час і дату

замовлення й т.п. Плюс, як уже згадувалося, за допомогою серверних скриптів

можна створювати цілі системи керування сайтом (движки) з убудованими

візуальними редакторами, форумами й т.д.

Для програмування серверної частини можна використовувати мову

програмування php або платформу Node.js, яка використовує мову програмування

JavaScript. Мову програмування кожен студент обирає самостійно,

обгрунтувавши свій вибір.

38

У даному розділі необхідно перерахувати та описати основні модулі, що

були створені при розробці серверної частини. При описанні модулів можна

використовувати короткі фрагменти коду. Повний лістинг коду для серверної

частини сайту необхідно приводити у додатку Б.

3.3.4 Глава «3.4 Програмування клієнтської частини»

Для розробки клієнтської частини сайту (frontend), необхідно

використовувати стандарти розмітки сторінок HTML5, стилі СSS3, JavaScript

актуальної версії.

У даному розділі необхідно показати:

інтерфейс сайту (разом з текстом доцільно використовувати

скриншоти);

описати основні дії при роботі з сайтом;

описати скрипти, які використовувались для програмування

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

Для отримання відмінної оцінки, при верстанні веб-сторінок необхідно

використовувати медіа-запити для створення адаптивного дизайну, щоб веб-

сторінки добре виглядали на екранах з різною роздільною здатністю.

Сайт необхідно розділити на користувальницький та адміністративний

інтерфейс. Доступ до адміністративного інтерфейсу повинні мати лише

зареєстровні користувачі, які прошли авторизацію.

Адміністративний інтерфейс сайту повинен надавати можливість керувати

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

програмуванні серверної частини).

Розробляти frontend сайту необхідно використовуючи основні засади

ергономіки. Інтерфейс має бути приємним на вигляд та зручним для користувача.

Зовнішний вигляд та зручність сайту будуть впливати на фінальну оцінку

за курсовий проект.

39

3.3.5 Глава «3.5 Автентифікація користувачів»

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

створено реєстрацію та авторизацію користувачів на сайті. Та яким чином

відбувається процес автентифікації.

Необхідно зазначити, який модуль відповідає за автентифікацію. Повний

лістинг коду автентифікації приводиться у додатку Б.

3.3.6 Глава «3.6 Розміщення веб-сайту в Інтернеті»

Для того, щоб сайт був доступний із мережі Інтернет необхідно розмістити

його на хостингу.

Для курсового проекту достатньо буде зареєструватись на безкоштовному

хостингу та розмістити на ньому всі файли курсового проекту. Наприклад, можна

скористатись безкоштовним хостингом https://000webhost.com/.

У даному розділі необхідно указати яким хостингом скористались та

коротко описати процес розміщення сайту на хостингу.

40

СПИСОК ЛІТЕРАТУРИ

1. Пасічник В. В. Організація баз даних та знань / В. В. Пасічник, В. А.

Резніченко. – К.: Видавнича група BHV, 2006. – 384 с.

2. Документация по MySQL [Електронний ресурс]. – Режим доступу:

http://www.mysql.ru/docs/

3. Гоше Х.Д. HTML5. Для профессионалов / Х.Д. Гоше. – [2-е изд.]. –

СПб.: Питер, 2015. – 560 с.

4. Роббинс Д.Н. HTML5, CSS3 и JavaScript. Исчерпывающее

руководство / Д.Н. Роббинс. – [4-е изд.]. – М.: Эксмо, 2014. – 516 с.

5. Флэнаган Д. JavaScript. Подробное руководство / Д. Флэнаган. – [6-е

изд.]. – СПб.: Символ-Плюс, 2012. – 1080 с.

6. Фрейн Б. HTML5 и CSS3. Разработка сайтов для любых браузеров и

устройств / Б. Фрейн. – СПб.: Питер, 2014. – 304 с.

7. WebReference.ru [Електронний ресурс]. – Режим доступу:

https://webref.ru/

8. Современный учебник JavaScript [Електронний ресурс]. – Режим

доступу: http://learn.javascript.ru/

9. Mozilla Developer Network [Електронний ресурс]. – Режим доступу:

https://developer.mozilla.org/ru/

10. Node.js v4.5.0 Documentation [Електронний ресурс]. – Режим доступу:

https://nodejs.org/dist/latest-v4.x/docs/api/

11. Express [Електронний ресурс]. – Режим доступу:

http://expressjs.com/ru/

41

ДОДАТОК А

(обов’язковий)

ТАВРІЙСЬКИЙ ДЕРЖАВНИЙ АГРОТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ

ЗАТВЕРДЖУЮ

Зав. кафедрою “Комп’ютерні науки”

доц._______________О.В. Строкань

“_____”_________________20___ р.

КОМПЛЕКСНИЙ КУРСОВИЙ ПРОЕКТ

з дисциплін «Організація баз даних та знань», «Веб-технології» (назва дисципліни)

на тему: «Розробка веб-сайту підприємтсва»

15КНК.ХХХ.000000ПЗ

Студента (ки) курсу групи

_________________________________

_________________________________

________________________ (підпис) Керівник: асистент Беккауер А.О.

____________________________________

(підпис)

Національна шкала ________________

Кількість балів: ____Оцінка ECTS ___

Члени комісії ________________ ____________________

(підпис)

________________ _________________________

(підпис)

________________ _________________________

(підпис) (ініціали та прізвище)

Мелітополь - 20 __ рік

42

ДОДАТОК Б

(обов’язковий)

Р Е Ф Е Р А Т

Прізвище І. Б. Розробка веб-сайту підприємства: курсовий проект / І. Б.

Прізвище; ТДАТУ. – Мелітополь: [б.в.], 2016. – 30 с.

.

У представленому курсовому проекті розглянуто розробку веб-сайту ….

Курсовий проект складається з 3 розділів пояснювальної записки

загальним обсягом __ сторінок та розробленого програмного забезпечення.

Ключові слова: ВЕБ-САЙТ, HTML, CSS, JAVASCRIPT, ВЕБ-СЛУЖБА,

СИСТЕМА КЕРУВАННЯ.

Іл. 7, Табл. 11, Бібл. 28

43

ДОДАТОК В

(обов’язковий)

Бібліографічний опис літератури

… одного автора

Василій Великий. Гомілії / Василій Великий ; [пер. з давньогрец. Л.

Звонська]. — Львів : Свічадо, 2006. — 307 с. — (Джерела християнського Сходу.

Золотий вік патристики ІV—V ст. ; № 14).

… двух авторів

Суберляк О. В., Технологія переробки полімерних та композиційних

матеріалів : підруч. [для студ. вищ. навч. закл.] / О. В. Суберляк, П. І. Баштанник.

— Львів : Растр-7, 2007. — 375 с.

… без автора

Історія Свято-Михайлівського Золотоверхого монастиря / [авт. тексту В.

Клос]. — К. : Грані-Т, 2007. — 119 с. — (Грані світу).

Багатотомні видання

Історія Національної академії наук України, 1941—1945 / [упоряд. Л. М.

Яременко та ін.]. — К. : Нац. б-ка України ім. В. І. Вернадського, 2007— .—

(Джерела з історії науки в Україні). Ч. 2 : Додатки — 2007. — 573, [1] c.

Матеріали конференцій

Економіка, менеджмент, освіта в системі реформування агропромислового

комплексу : матеріали Всеукр. конф. молодих учених-аграрників ["Молодь

України і аграрна реформа"], (Харків, 11—13 жовт. 2000 р.) / М-во аграр.

політики, Харк. держ. аграр. ун-т ім. В. В. Докучаєва. — Х. : Харк. держ. аграр.

ун-т ім. В. В. Докучаєва, 2000. — 167 с.

Нормативно-технічні документи:

ДСТУ 2293-93. Охорона праці: Терміни та визначення. – К.: Держстандарт

України, 1994.- 21 с.

2. ДСТУ EN45001 та ін.: збірник стандартів. – К.: Держстандарт України,

1998. –244 с.

Словники

Машины и оборудование для АПК, выпускаемые в странах СНГ: каталог.

–М.: Росинформагротех, 2001. – 292 с.

44

Дисертації

Петров П.П., Активність молодих зірок сонячної маси: дис. ... доктора фіз.-

мат. наук : 01.03.02 / Петров Петро Петрович. – К., 2005. – 276 с.

Автореферати дисертацій

Новосад І.Я., Технологічне забезпечення виготовлення секцій робочих

органів гнучких гвинтових конвеєрів : автореф. дис. на здобуття наук. ступеня

канд. техн. наук : спец. 05.02.08 „Технологія машинобудування” / І. Я. Новосад.

— Тернопіль, 2007. — 20, [1] с.

Авторські свідоцтва

1А. с. 1007970 СССР, МКИ3 В 25 J 15/00. Устройство для захвата

неориентированных деталей типа валов / В. С. Ваулин, В. Г. Кемайкин (СССР). –

№ 3360585/25–08 ; заявл. 23.11.81 ; опубл. 30.03.83, Бюл. № 12.

Патенти

Пат. 2187888 Российская Федерация, МПК7 H 04 В 1/38, Н 04 J 13/00.

Приемопередающее устройство / Чугаева В.И.; заявитель и патентообладатель

Воронеж. науч.-исслед. ин-т связи. – № 2000131736/09 ; заявл. 18.12.00 ; опубл.

20.08.02, Бюл. № 23 (II ч.).

Частина книги, періодичного, продовжуваного видання

Козіна Ж. Л., Теоретичні основи і результати практичного застосування

системного аналізу в наукових дослідженнях в області спортивних ігор / Ж. Л.

Козіна // Теорія та методика фізичного виховання. — 2007. — № 6. — С. 15—18,

35—38.

Електронні ресурси

Богомольний Б. Р., Медицина екстремальних ситуацій [Електронний

ресурс] ] : навч. посіб. для студ. мед. вузів III—IV рівнів акредитації / Б. Р.

Богомольний, В. В. Кононенко, П. М. Чуєв. — 80 Min / 700 MB. — Одеса : Одес.

мед. ун-т, 2003. — (Бібліотека студента-медика) — 1 електрон. опт. диск (CD-

ROM) ; 12 см. — Систем. вимоги: Pentium ; 32 Mb RAM ; Windows 95, 98, 2000,

XP ; MS Word 97-2000.— Назва з контейнера.

2. Розподіл населення найбільш численних національностей за статтю та

віком, шлюбним станом, мовними ознаками та рівнем освіти [Електронний

ресурс] : за даними Всеукр. перепису населення 2001 р. / Держ. ком. статистики

України ; ред. О. Г. Осауленко. — К. : CD-вид-во "Інфодиск", 2004. — 1 електрон.

опт. диск (CD-ROM) : кольор. ; 12 см. — (Всеукр. перепис населення, 2001). —

Систем. вимоги: Pentium-266 ; 32 Mb RAM ; CD-ROM Windows 98/2000/NT/XP.

— Назва з титул. екрану.