
- •1 Організаційні положення
- •1 Аналіз предметної області.
- •2. Постановка завдання
- •3. Проектування концептуальної моделі
- •4. Розробка логічної структури бази даних.
- •5. Реляційна модель.
- •6. Визначення типів даних в заданому форматі
- •7. Створення глобальної схеми зв'язків. Підтримка цілісності даних.
- •Запит «Кількість путівок клієнта»
- •9. Проектування форм. Структура та призначення існуючих форм.
- •2. Проектування реляційної бази даних
- •5. Проектування збережених процедур
- •6. Розробка механізмів керування даними
- •7 Розробка технології доступа до бази даних
- •8. Проектування керівництва користувача
- •9. Вимоги до технічного забезпечення
1 Організаційні положення
Організаційні положення визначають порядок отримання індивідуального завдання, проведення консультацій і захисту, а також контролю керівником графіка виконання КР.
1 Індивідуальне завдання
1.1. Видається викладачем не пізніше третього тижня поточного навчального семестру на відповідному бланку.
1.2. Студент має право на вибір власної теми завдання з належним обґрунтуванням доцільності її розробки і можливості виконання. В цьому випадку студент заздалегідь звертається з відповідною мотивованою заявою на ім'я завідувача відповідальної кафедри.
2. Консультації
2.1. Проводяться згідно графіка кафедри на протязі навчального семестру. Кількість годин на консультації визначається навчальним планом з даної дисципліни.
2.2. Керівник консультує та організує роботу студентів з питань КР. На прохання студента переглядає (і схвалює чи рекомендує доопрацювати) окремі матеріали роботи.
2.3. На консультаціях здійснюється контроль за виконанням студентом загального чи індивідуального поетапного графіка виконання КР з відповідними відмітками в журналі викладача. Керівник візує до захисту чи відхиляє виконану і підписану студентом роботу.
2.4. Якщо студент подає на розгляд (захист) не самостійно виконану КР, про що, зокрема, свідчить його некомпетентність у рішеннях та матеріалах роботи, ухвалою кафедри (на подання керівника) КР до захисту в комісії не допускається, що супроводжується записом «не допущений» у заліковій відомості. Такий самий запис робиться у відомості, якщо КР не завершена на час захисту або не може бути допущенa до захисту з причин невиконання встановлених нормативних вимог. У всіх названих випадках запис «не допущений» еквівалентний оцінці «незадовільно», тобто свідчить про появу академічної заборгованості, яка може бути ліквідована на загальних підставах.
2.5. У терміни після закінчення дії графіка проектування (загального чи індивідуального) керівник продовжує консультації, але розглядає на предмет допуску до захисту матеріали вже закінченої та підписаної роботи.
3. Поетапний графік виконання КР.
3.1. Поетапний графік виконання КР керівник доводить до студентів разом з отриманням індивідуального завдання.
3.2. Термін дії графіка закінчується за тиждень до захисту.
3.3. В разі порушення студентом загального поетапного графіка виконання КР керівник допомагає студенту в складанні індивідуального графіка (контролює його виконання після затвердження зав. кафедрою).
4.Захист.
4.1. Здійснюється на протязі останнього тижня до початку екзаменаційної сесії та на протязі екзаменаційної сесії згідно відповідного графіка захисту.
4.2. До захисту допускаються студенти, які мають КР, підписану керівником.
4.3. Захист КР проводиться перед комісією і включає доповідь тривалістю 3-5 хвилини, демонстрування роботи, розробленої програми на ЕОМ і відповіді на запитання членів комісії. В доповіді вказується тема, основні особливості прийнятого методу розв'язування, основні характеристики розроблених алгоритмів та програм і результати їх тестування.
4.4. КР оцінюється за 5-бальною системою згідно наступних критеріїв:
5 балів — виставляється, якщо студент повністю виконав вимоги технічного завдання на курсову роботу, розробив оптимальний алгоритм розв'язання і оптимальний варіант його реалізації на програмному рівні, а також вміє творчо мислити, вільно орієнтуватись у вивченому матеріалі, при відповідях на запитання показує високий рівень знань, пояснювальна записка оформлена з дотриманням відповідних державних стандартів.
4 бали — виставляється, якщо по переліченим вище показникам є незначні недоліки:
- повнота відповідей не зовсім достатня;
- є дрібні неточності в структурі алгоритмів і програм;
- неохайність при оформленні пояснювальної записки;
3 бали — виставляється при істотних недоліках за вказаними вище показниками;
при цьому є обов'язковим розуміння і знання основного змісту КР і в основному правильна структура розроблених алгоритмів і програм, оформлення пояснювальної записки без грубого порушення стандартів.
Структура курсової роботи.
У роботі повинен бути проведений загальний аналіз предметної області (ПО), визначено функції, які реалізуються в розробленій базі даних, вказані обмеження, якщо такі є. На основі аналізу здійснюється постановка комплексу розглянутих завдань.
Титульний лист
Зміст
Анотація
Вступ
1 Аналіз предметної області.
2 Постановка завдання
3 Проектування концептуальної моделі
4 Розробка логічної структури бази даних.
5 Реляційна модель.
6 Визначення типів даних в заданому форматі
7 Створення глобальної схеми зв'язків. Підтримка цілісності даних.
8 Запити. Структура та призначення. SQL-запит.
9 Проектування форм. Структура та призначення існуючих форм.
10 Інструкція користувача.
Висновки
Література
Додатки
Проектування інформаційної системи на основі бази даних. Проектування інформаційної системи бази даних грунтується на дослідженні інформації, що циркулює всередині даної предметної області. Предметна область (ПО) - це сукупність об'єктів, процесів і зв'язків між ними (банк, завод, склад і т Д..).
При дослідженні ПО виконується семантичний аналіз інформації даної предметної області. Семантика - це смислова сторона інформації.
Розглянемо деякі поняття, необхідні для опису досліджуваної предметної області.
Інформаційний об'єкт (ІВ) - джерело інформації. він може бути матеріальним (цех, склад, документ ...) і нематеріальним (факти, події, процеси, явища ...). Інформаційний об'єкт - це будь-яка реальна або абстрактна сутність, про яку накопичується інформація. Відомості про об'єкти можуть надходити з різних повідомлень і документів. Кожен об'єкт характеризується набором атрибутів. Атрибути - це властивості, якими володіє даний об'єкт. Атрибут є найпростішою неподільною одиницею інформації, яка відображає кількісну або якісну характеристику об'єкта. Відомості про атрибути отримують на етапі передпроектного обстеження. Тут же враховуються обмеження і допущення. Склад атрибутів являє собою структуру інформаційного об'єкта. Атрибути, які однозначно визначають кожен екземпляр об'єкта, є ключовими. За значенням ключа можна відшукати потрібний екземпляр об'єкта. Інші атрибути об'єкта називаються неключовими або описовими. Ключ і описові атрибути знаходяться у функціональній залежності. Ключ може бути простим і складеним. Наприклад в об'єкті «студент» буде складовою ключ: номер_групи + номер_студента.
Інформація в реляційних базах даних зберігається в декількох взаємопов'язаних двовимірних таблицях, в кожній з яких знаходиться інформація про один об'єкт.
Між всіма об'єктами, виявленими в передпроектному проектуванні, треба встановити типи зв'язків. Зв'язки можуть бути "один - до - одного" (1:1), "один - до - багатьох" (1: N), «багато - до - багатьох" (N: N).
Зв'язок "один - до - одного» має місце, коли кожному примірнику однієї об'єктної множини відповідає тільки один екземпляр іншої об'єктної множини.
Зв'язок «один - до - багатьох» має місце, коли кожному примірнику однієї об'єктної множини відповідає кілька примірників іншої об'єктної множини.
Цей тип зв'язку найбільш часто використовується в концептуальній моделі.
Зв'язок «один - до - багатьох» має місце, коли кожному примірнику однієї об'єктної множини відповідає кілька примірників іншої об'єктної множини. І навпаки, кожному примірнику другої об'єктної множини відповідає кілька примірників першої об'єктної множини.
На підставі виявлених зв'язків будується концептуальна модель.
Приклад розробки інформаційної системи