You are on page 1of 16

Міністерство освіти і науки України

Сумський державний університет


Навчально-науковий інститут бізнесу, економіки та менеджменту
Кафедра економічної кібернетики

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


ДЛЯ ВИКОНАННЯ КУРСОВОГО ПРОЕКТУ
З ДИСЦИПЛІНИ
«СИСТЕМИ ПРИЙНЯТТЯ РІШЕНЬ»

для студентів спеціальності


051 «Економіка» («Економічна кібернетика»)

Суми -2021
2

1.1. Мета й завдання курсового проектування


Мета курсового проектування - закріпити та поглибити теоретичні знання,
набути навичок самостійної практичної роботи з проектування систем прийняття
рішень на основі баз даних та сховищ даних та реалізації їх в середовищі сучасних
програмних засобів.
Завдання курсового проектування такі:
• розвиток теоретичних знань та вмінь застосовувати їх при роз’язуванні
конкретних задач проектування БД і СД;
• набуття вміння вибирати варіанти проектування БД і СД з використанням
відповідних інструментальних засобів (DeductorStudіo, Web-сервер);
• закріплення навичок роботи із сучасними СПР.
Проект має бути розроблений на базі персональних ЕОМ з використанням ПЗ
DeductorStudіo. (Інший спосіб реалізації БД чи СД може бути запропонований
студентом, але його вибір потрібно погодити з керівником курсу).
1.2. Організація курсового проектування
Тема курсового проекту вибирається з переліку, який наведено в додатку 1 чи
може визначатися за місцем роботи чи майбутньої практики студента, але
обов’язково потрібно затвердження керівника курсу.
Вибрану тему студент має оформити у вигляді заяви й подати до кабінету
курсового та дипломного проектування не пізніше як через три тижні після початку
читання лекцій з даної дисципліни.
Після затвердження теми на кафедрі керівник видає студентові завдання на
курсове проектування. Курсовий проект потрібно подати на кафедру в термін,
зазначений у завданні. Якщо проект зданий несвоєчасно, це вважається порушенням
навчального плану.
1.3. Структура та оформлення курсового проекту.
Структуру курсового проекту наведено в додатку 2.
3
Титульна сторінка (титул) оформляється відповідно ГОСТ 2.105-79 ЕСКД
(додаток 3).
Анотація. У ній стисло висвітлюється головна ідея курсового проекту,
розкривається його основний зміст, зазначаються застосовувані методи та
обґрунтовується новизна матеріалу. Форма викладу ствердна, наприклад: "у проекті
запропоновано...", "наведено..."," показано..." і тощо.
Оптимальний обсяг анотацї - 400 знаків.
Реферат.
Реферат має містити таку інформацію:
• відомості про обсяг проекту (загальна кількість сторінок тексту, кількість
ілюстрацій, таблиць, назв у списку використаних літературних джерел);
• перелік ключових слів (записаних у називному відмінку в один рядок через
кому), який має відбивати зміст реферованого проекту;
• об’єкт дослідження;
• технічні засоби, використані при дослідженні;
• результат досягнуті в процесі науково-дослідної роботи, їх новизна та ступінь
упровадження;
• рекомендації щодо практичного застосування здобутих результатів із
зазначенням ефективності, сфери використання, основних конструкторських і
техніко-економічних характеристик.
Оптимальний об’єм реферату - 800-1000 знаків.
Зміст. Являє собою перелік назв усіх розділів та пунктів із зазначенням сторінок,
з яких починаються розділи чи пункти проекту.
Вступ. Розкриває мету курсового проекту, обґрунтовує потребу розробки бази чи
сховища даних для досліджуваної задачі чи комплексу задач.
4
Розділ І. Дослідження предметної області.
Цей розділ розбивається на чотири підрозділи.
1.1. Характеристика предметної області. При описі предметної
області неодхідно описати характеристику функціональної задачі, для якої
буде проектуватись база даних (сховище даних). При описі характеристики
задачі потрібно вказати призначення, техніко-економічну сутність задачі і
обгрунтування необхідності її розв'язання: привести перелік об'єктів, при
управлінні якими розв'язується задача; описати призначення і використання
вихідної інформації; привести періодичність розв'язання і термін видачі
вихідної інформації; вказати умови, за яких припиняється автоматизоване
розв'язання задачі, при необхідності перерахувати зв'язки даної задачі з
іншими задачами інформаційної системи /привести інформаційну модель/,
описати розподіл дій між персоналом і технічними засобами при різних
ситуаціях розв'язання задачі;
1.2. Опис вхідних повідомлень. Цей підрозділ повинен містити опис
джерел інформації, а також форми та характеристики первинної документації,
використовуваної на вході для розв’язку функціональних задач.
В тексті описують призначення і способи одержання вхідної інформації, а
потім приводять перелік і опис вхідних повідомлень /табл. 1/. До табл. 1 заносять
вхідні документи, які будуть використані для формування оперативних файлів бази
даних, файли, які потрапляють на вхід задачі чи комплексу з інших задач та їх
комплексів, а також документи та файли, які носять довідковий характер і можуть
бути віднесені до умовно-постійної інформації.

Таблиця 1

Перелік і опис вхідних повідомлень


Назва вхідного Форма Термін і частота Джерело
повідомлення подання надходження
Ідентифікатор
Касовий КAS_P Первинний Протягом дня Каса
приходний ордер документ комер-
ційного
банку
5
Форми документів наводяться в додатку до курсового проекту. З форм
первинної документації вибирається перелік атрибутів, який підлягає зберіганню в
сховищі даних. Якщо на вході задачі крім первинних документів
використовуються ще якісь вхідні повідомлення (інформаційні масиви, які
сформовані в інших підсистемах чи задачах, нормативно-довідкова інформація і
тощо), ці вхідні повідомлення також підлягають опису й аналізу на предмет того, чи
потрібно їх інформацію відображувати в базі даних, і якщо потрібно, то які
атрибути мають зберігатись в ній. Щодо кожного вхідного повідомлення слід
зазначити, де ким і з якою періодичністю воно формується.
1.3. Опис вихідних повідомлень. Структура вихідних повідомлень та їх
характеристики. Мають бути описані всі різновиди вихідних повідомлень:
машинограми, що видаються на друк, вихідні файли, які формуються на виході
досліджуваних задач для інформаційного зв’язку з іншими задачами, відеокадри,
що видаються на екран за запитом користувачів. Усі вихідні повідомлення
аналізуються з точки зору забезпеченості формування їх на основі вхідних
атрибутів, які описані в підрозділі 1.2. Якщо для формування якихось граф
вихідних повідомлень не вистачає вхідних атрибутів, потрібно повернутись на крок
назад (до зовнішнього проектування) і дообстежити предметну область з метою
поповнення переліку вхідних атрибутів. Крім того, необхідно ретельно
проаналізувати ті графи вихідних повідомлень, які отримуються розрахунковим
шляхом. Здебільшого всі розрахункові показники, що дістаються за допомогою
обчислень, у базі даних не зберігаються, оскільки при потребі їх завжди можна
обчислити. Виняток становлять лише ті розрахункові показники, які потрібно
зберігати в СД для інформаційного зв’язку з іншими задачами чи для подальшого
розв’язування аналізованої задачі. Наприклад, показник "сума нарахованої
заробітної плати " є розрахунковим, але його слід зберігати в СД у вихідному файлі,
який формується задачею нарахування заробітної плати, оскільки він буде
використовуватися як вхідний при розв’язку задач нарахування премій і доплат, а
також відпускних.
6
Усі форми вихідних повідомлень наводяться в додатку до курсового
проекту.
Вихідні повідомлення їх призначення і використання приводяться в /табл. 2/.

Таблиця 2

Перелік і опис вихідних повідомлень


Назва Ідентифікатор Форма Періодичність Термін Користувач
вихідного подання і видання видання і інформації
повідомлення
вимоги до допустимий
час затримки
неї
1 2 3 4 5 6
Відомість УТР-10 Документ Раз на З0 (31) -ше Бухгалтерія
нарахованої місяць число до 1400
год.
заробітної
плати

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


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

Кожну формулу потрібно проаналізувати на достатність атрибутів на вході


задачі для формування необхідного переліку вихідних показників, які формуються
розрахунковим шляхом. Коли для формування тих чи інших показників вихідних
повідомлень не вистачає вхідних атрибутів, то, як і в попередньому випадку,
потрібно повернутися до вивчення вхідних повідомлень, дообстежити предметну
область з метою поповнення необхідних вхідних атрибутів.
7
Розділ 2 . Розробка інфологічної моделі.
Цей розділ має бути виконаний за методикою інфологічного проектування.
Сутність інфологічного проектування полягає у визначенні інформаційних
об’єктів (сутностей) предметної області, які підлягають зберіганню в БД,
визначенню характеристик об’єктів та структурних зв’язків між ними.
Результатом інфологічного моделювання є інформаційно-логічна модель (ІЛМ)
предметної області та опис її складових елементів. Інфологічна модель має
задовольняти всі вимоги користувачів та прикладних програм.
Інформаційні об’єкти необхідно нормалізувати і подати в третій, четвертій
чи п’ятій нормальній формі.
При інфологічному моделюванні у вигляді інформаційних запитів та
запитальних зв’язків подаються всі запити до СД, які можуть надходити як від
користувачів, так і від прикладних програм. Тобто запитами та запитальними
зв’язками необхідно описати всі форми вихідних повідомлень, що видаються як у
регламентному так і в нерегламентному режимі. Усі запити мають бути подані в
канонічному вигляді.
На підставі аналізу запитальних зв’язків будуються структурні зв’язки між
інформаційними об’єктами. Побудувавши структурні зв’язки, дістанемо графічне
подання інфологічної моделі (граф ІЛМ), яке потрібно перевірити на повноту та
коректність. Інфологічна модель відповідає вимогам повноти і коректності, якщо
на ній можна виконати всі запити до БД, які ставляться з боку користувачів та
прикладних програм. У результаті такої перевірки можуть бути вилучені
надлишкові (дублюючі) структурні зв’язки, виконано агрегування кількох об’єктів,
які мають семантично споріднені атрибути, в один інформаційний об’єкт або
навпаки: до ІЛМ можуть бути внесені додаткові структурні зв’язки та об’єкти, які
були не враховані спочатку. Опис складових кожного інформаційного об’єкту
виконують в таблиці 3. Крім структури та форматів атрибутів кожного
інформаційного об’єкта в таблиці 3 описуються бізнес-правила, шо задають умови
цілістності даних. Умови цілістності можуть задавати такі бізнес-правила:
первинний ключ – проставляється ПК, якщо атрибут є первинним ключем;
8
умова на допустимі значення - задаються якщо в базі даних на значення
атрибута накладаються якісь обмеження (діапазон значень, не більше не менше
певного значення, не нуль і т.п.), а також якщо задається певне значення за
змовчанням;
Обов’язкове поле – вказує на умову наявності значення атрибута у кожному
записі (проставляємо "так", якщо значення атрибуту не може бути пустим , "ні" - в
протилежному випадку, якщо значення поля може бути пустим) ;
Індексне поле – ознака проставляється, якщо поле може виступати як індексне,
а також вказується допускається чи не допускається дублювання значення індексу.
Тобто, можливі такі варіанти заповнення цієї ознаки:
ІДД – це значить, що поле є індексним, в якому допускається дублювання
значень;
ІНД – це значить, що поле є індексним, в якому не допускається дублювання
значень.
Опис атрибутів інформаційного об’єкту "Кредит"
Таблиця 3
Назва Форм Обов"язко Обмеже Первин Виводимість Дублюванн Умови на Індекс
атрибута ат вий ння на ний значень я значень, % допустимі не
(необов"я право (втори значення поле
з ковий) звертан н ний)
ня ключ
Код Мають ПК ІДД
клієнта N(8) так право –– Так
Дата 01.01.2003
началь
подання D(8) так ник –– Так -
заявки 31.12.2003
та
Термін
9(2) так нспектор Так Так
кредит -
Код ного ВК ІДД
виду 9(1) так відділу –– Так 1-7
кредит
у
Сума N(5,3) так Так
кредит
у
9
Проектування інфологічної моделі необхідно виконати використовуючи
CASE-засоби (пакет Erwіn чи інший пакет автоматизації проектування БД). В цьому
ж розділі чи в додатках потрібно надати стисле керівництво користувача по
розробці інфологічної (логічної) моделі бази даних з використанням CASE-засобів,
яка повинна обов’язково ілюструватися екранними формами.
Розділ 3. Проектування даталогічної моделі.
На відміну від інфологічного проектування, на яке не впливають особливості
конкретної БД або СД, даталогічне проектування - це проектування в середовищі
DeductorStudio. Розділ 3 має складатися з двох підрозділів.
У підрозділі 3.1 необхідно подати обгрунтування цього вибору
DeductorStudio або іншого середовища розробки. Слід також навести короткий опис
вибраної системи і перелік тих вимог та обмежень, які можуть вплинути на
результати проектування на даному етапі.
У підрозділі 3.2 слід описати процедури відображення інфологічної моделі
на модель вибраної БД чи СД. Здобутий результат перевірити на повноту з точки
зору задоволення всіх інформаційних запитів і описати у вигляді схеми даталогічної
моделі.
10
Розділ 4. Проектування та реалізація БД на фізичному рівні.
Цей розділ має також складатися з двох підрозділів.
У підрозділі 4.1 потрібно виконати опис файлів даталогічної моделі в
термінах мови опису даних (МОД), вибраної БД, навести структуру СД з описом
вимірів та фактів спроектованого OLAP-куба.
Підрозділ 4.2. має містити реалізацію основних запитів та вітрин даних, що
формуються на основі інформації, що міститься в сховищі даних. Роздруковки
отриманих запитів повинні бути приведені в додатках до курсового проекту.
У висновках приводиться аналіз результатів проектування СД та пропозиції
щодо подальшого їх практичного впровадження та використання.
Перед текстом роботи має бути титульна сторінка (дод. 5), яка виконується
згідно з ГОСТ 2.105-79. Наприкінці тексту слід навести список літератури, яка
використовувалась при виконанні проекту. Якщо в курсовому проекті
використовувались цитати чи якийсь цифровий матеріал, запозичений з
літературних джерел, то потрібно відповідні бібліографічні посилання (джерело,
сторінка).
Умовні та графічні позначення, термінологія та визначення мають
відповідати стандартам. Курсовий проект потрібно переплести та подати у
електронному вигляді. Студент здає роботу на перевірку керівнику в термін,
затверджений на кафедрі. Після перевірки керівник проекту може допустити його до
захисту або віддати на доопрацювання.
1.5. Захист курсового проекту. Допущений до захисту проект підписується
керівником і захищається на комісії, до якої входять два-три викладачі кафедри (з
урахуванням керівника проекту).
Студент робить коротку доповідь (5-10 хв.),в якій викладає сутність проектної
розробки, наголошуючи при цьому на розроблених ним пропозиціях, а потім
відповідає на запитання.
За результами захисту виставляється оцінка, яка заноситься до залікової
книжки та у відомість з підписами членів комісії.
11
В додатку до проекту наводяться форми первинних документів,та
вихідних повідомлень, структури джерел даних та сховища даних, структура
сценарію створення та наповнення СД, обробки початкових даних та представлень,
що отримуються за запитами користувачів.
12
ДОДАТОК 1
ТЕМАТИКА КУРСОВИХ ПРОЕКТІВ.

1. Проектування СД для визначення норм витрат матеріалів на виготовлення


виробу.
2. Проектування СД для визначення трудомісткості та нормативних розцінок на
один виріб.
3. Проектування СД для визначення нормативної собівартості товарної продукції.
4. Проектування СД для рішення задачі обліку випуску готової продукції.
5. Проектування СД для рішення задачі обліку відвантаження готової продукції.
6. Проектування СД для рішення задачі обліку реалізації готової продукції.
7. Проектування СД для визначення потреби в сировині та основних матеріалах
для основного виробництва на рік (квартал).
8. Проектування СД для визначення потреби в покупних комплектуючих
матеріалах для основного виробництва на рік (квартал).
9. Проектування СД для визначення ліміта матеріалів по цеху на місяць.
10. Проектування СД для визначення нормативної чисельності робітників по
підприємству на рік (квартал).
11. Проектування СД для рішення задачі з обліку наявності та руху матеріалів на
складі.
12. Проектування СД для рішення задачі з обліку наявності та руху особового
складу організації.
13. Проектування СД для визначення та нарахування погодинної заробітної плати.
14. Проектування СД для визначення та нарахування відрядної бригадної
заробітної плати.
15. Проектування СД для рішення задачі з обліку наявності та руху коштів на
розрахунковому рахунку та в касі підприємства.
16. Проектування СД для управління електронним магазином.
17. Проектування СД для визначення амортизаційних відрахувань по підприємству.
18. Проектування СД для визначення та аналізу інвестиційної привабливості
підприємств, що приватизуються.
13
19. Проектування СД для аналізу обсягів продаж продукції торгівельною фірмою.
20. Проектування СД для аналізу доходу від збуту готової продукції.
21. Проектування СД для аналізу діяльності системи електронної комерції.
22. Проектування СД для аналізу страхового портфеля страхової фірми.
23. Проектування СД для рішення задачі обліку акціонерів та нарахування
дивідентів акціонерам АТ.
24. Проектування СД для проведення маркетингових досліджень попиту на
товарному ринку.
25. Проектування СД для проведення маркетингових досліджень коньюнктури
товарного ринку.
26. Проектування СД для проведення маркетингових досліджень
конкурентоздатності товарів на товарному ринку.
27. Проектування СД для визначення кредитоспроможності позичальника
(юридичних осіб) та ризику при їх кредитуванні.
28. Проектування СД для визначення кредитоспроможності позичальника (фізичних
осіб) та ризику при його кредитуванні.
29. Проектування СД для аналізу клієнтської бази комерційного банку.
30. Проектування СД для аналізу інвестиційного портфеля комерційного банку.
31. Проектування СД для аналізу готівкового обігу коштів в комерційному банку
32. Проектування СД для рішення задачі по формуванню кредитних договорів та
контролю за їх виконанням в комерційному банку.
33. Проектування СД для аналізу кредитного портфелю комерційного банку.
34. Проектування СД для рішення задачі з обліку нарахування дивідентів за
акціями комерційного банку.
35. Проектування СД для аналізу депозитного портфелю комерційного банку.
36. Проектування СД для рішення задачі з обліку акціонерів комерційного банку.
37. Проектування СД для рішення задачі з обліку депозитних рахунків
комерційного банку.
38. Проектування СД для рішення задачі з обліку карткових платіжних операцій
комерційного банку.
14
39. Проектування СД для рішення задачі з обліку емісії пдастикових карток.
40. Проектування СД для рішення задачі з обліку експортно-імпортних операцій
комерційного банку.
41. Проектування СД для рішення задачі з обліку роботи обмінних валютних
пунктів комерційного банку.
42. Проектування СД з обліку та контролю надходження податкових платежів від
юридичних осіб.
43. Проектування СД з обліку та контролю надходження прибуткового податку від
фізичних осіб.
44. Проектування СД з обліку та формування страхових договорів (полісів) за
окремими видами страхових продуктів.
45. Проектування СД з обліку та контролю сплати страхових внесків за страховими
договорами (полісами).
46. Проектування СД для білінгової системи розрахунків за послуги мобільного
зв’язку.
47. Проектування СД для контролю виконання навантаження викладачами ВУЗу.
48. Проектування СД для аналізу і контролю успішності студентів ВУЗу.
49. Проектування СД для надання послуг дистанційної освіти.
50. Проектування СД туристичного агенства.
51. Проектування СД автотранспортного підприємства.
52. Проектування СД для обліку роботи поліклініки.
53. Проектування СД для обліку роботи видавництва.
54. Проектування СД для обліку роботи готелю.
55. Проектування СД для обліку роботи торгівельно-закупівельного підприємства.
56. Проектування СД для обліку та аналізу роботи мережі магазинів.
15
ДОДАТОК 2
СТРУКТУРА КУРСОВОГО ПРОЕКТУ
ТИТУЛЬНА СТОРІНКА
АННОТАЦІЯ
РЕФЕРАТ
ЗМІСТ

ВСТУП
1. ДОСЛІДЖЕННЯ ПРЕДМЕТНОЇ ОБЛАСТІ.
1.1. Характеристика функціональної структури предметної області.
1.2. Опис вхідних повідомлень.
1.3. Опис вихідних повідомлень.
1.4. Опис основних процедур перетворення даних.
2. РОЗРОБКА ІНФОЛОГІЧНОЇ МОДЕЛІ.
2.1. Інформаційні об’єкти та їх характеристика.
2.2. Запити та запитувальні зв’язки.
2.3. Структурні зв’язки та їх представлення на графі ІЛМ.
2.4. Автоматизація проектування інфологічної моделі.
3. РОЗРОБКА ДАТАЛОГІЧНОЇ МОДЕЛІ.
3.1. Обгрунтування та вибір середовища розробки.
3.2. Автоматизація даталогічного проектуваня та її результати
4. ПРОЕКТУВАННЯ ТА РЕАЛІЗАЦІЯ СД.
4.1. Опис джерел інформації, фактів та вимірів СД.
4.2. Структура та реалізація СД.
4.3. Опис та реалізація представлень, отриманих при роботі з СД
ВИСНОВКИ.
СПИСОК ЛІТЕРАТУРИ.
ДОДАТКИ.
16

ДОДАТОК 3.
Міністерство освіти і науки України
Сумський державний університет
Навчально-науковий інститут бізнесу, економіки та менеджменту
Кафедра економічної кібернетики

КУРСОВИЙ ПРОЕКТ

з дисципліни ________________________________
на тему: _____________________________________

Студент _______________ група ____ курс_______

Керівник проекту______________________________

Суми 20__ р.

You might also like