2 Оформлення пояснювальної записки

Пояснювальна записка до курсового проекту виконується як комп’ютерний набір тексту або рукописним способом на одній стороні аркуша формату А4 ( 210 х 297 мм) відповідно до ГОСТ 2.301-68.

При комп’ютерному наборі необхідно виконувати оформлення курсового проекту на друкуючих та графічних пристроях виведення персональних комп’ютерів /ГОСТ 2.004-88/ з додержуванням правил Єдиної системи конструкторської документації та Єдиної системи програмної документації.

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

Рекомендований обсяг пояснювальної записки повинен складати 25-30 сторінок друкованого тексту (комп’ютерний набір тексту виконується шрифтом гарнітури “Ariаl”, кегль - 14 пт, курсивом, з полуторним інтервалом). В дану кількість сторінок не включають сторінки, на яких розміщено додатки.

З використанням комп’ютерного способу виконання на сторінці має розташовуватися не більше 40 рядків (відповідно інтервал між рядками – не більше 8 мм).

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

Заголовки структурних елементів і розділів слід розташовувати з абзацного відступу і друкувати малими літерами, починаючи з першої великої літери без крапки в кінці, не підкреслюючи їх. Кожен структурний елемент та розділ слід починати з нової сторінки.

Заголовки підрозділів, пунктів, підпунктів слід починати з абзацного відступу і друкувати маленькими літерами, окрім першої великої, без крапки і не підкреслюючи їх. Абзацний відступ повинен бути однаковим впродовж усього тексту звіту і дорівнювати 5 знакам(15-17 мм). Перенесення слів у заголовку не допускається.

Відстань між заголовком і подальшим чи попереднім текстом за комп’ютерного способу виконання – не менше, ніж 2 рядки. Відстань між основами рядків заголовку, а також між двома заголовками приймають такою, як у тексті.

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

Сторінки пояснювальної записки нумеруються арабськими цифрами, додержуючись наскрізної нумерації і впродовж усього тексту. Номер сторінки проставляється у графі 7 основного напису відповідно до ДСТУ ГОСТ 2.104:2006.

Оформлювальний аркуш курсового проекту, аркуш затвердження з темою і підписами включають до загальної нумерації сторінок звіту, але номер не проставляють. Елементи дати проставляють повно (наприклад, 21.11.2012). Зразок оформлення аркуша затвердження наводиться у додатку Б.

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

• оформлювальний аркуш курсового проекту;

• аркуш затвердження;

• завдання на курсовий проект;

• зміст;

• розділи пояснювальної записки;

• список використаних джерел;

• додатки.

Пояснювальна записка повинна бути виконана у відповідності до стандартів ЄСКД та Єдиної системи проектної документації (ЄСПД), Єдиної системи стандартів автоматизованої системи керування.

3 ЗМІСТ РОЗДІЛІВ ПОЯСНЮВАЛЬНОЇ ЗАПИСКИ

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

Зміст оформлюється відповідно до встановленого зразку (див. додаток Г).

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

1 Вступ

2 Аналіз предметної області

2.1 Специфікація вимог користувачів підсистеми

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

3 Постановка задачі

3.1 Специфікація функціональних вимог

3.2 Опис вхідної інформації

3.3 Опис вихідної інформації

3.4 Алгоритм проектування

4 Проектування інформаційної моделі

4.1 Визначення концептуальної моделі

4.2 Побудова реляційної бази даних

4.3 Тестування підсистеми

4.4 Побудова запитів на мові SQL

5 Розробка інформаційної підсистеми

5.1 Інтерфейс підсистеми

5.2 Опис автоматизованих функцій

Висновки

Список використаних джерел

Додаток А Роздрук екранних форм

У розділі «1 Вступ» вміщено огляд змісту пояснювальної записки і розташовується як окремий розділ.

Вступ повинен містить загальну характеристику курсового проекту, оцінку сучасного стану розв'язуваної науково-технічної проблеми, її актуальність.

У вступі зазначається практичне використання підсистеми, що буде розроблюватися, характеристика об’єкту проектування, мета проекту. Слід стисло навести стан проблеми на сучасному етапі, задачі, питання, які розглядаються у проекті. У вступі доцільно обґрунтувати необхідність виконання проекту, вказати область можливого використання розробленої підсистеми, надати загальну характеристику роботи, що буде виконуватися.

Орієнтований обсяг 1-2 с.

У розділі «2 Аналіз предметної області» необхідно описати підрозділи «2.1 Специфікації вимог користувачів підсистеми» і «2.2 Документи, необхідні для вирішення задачі».

У підрозділі «2.1 Специфікація вимог користувачів підсистеми» наводять аналіз та опис предметної області, визначають вимоги та функції користувачів, що спрямовані на досягнення встановлених цілей.

Рекомендовано розкрити наступні питання:

- аналіз предметної області, тобто надається характеристика організації (підприємства, підрозділу, закладу тощо), для якої буде розроблена дана підсистема та сфери її діяльності;

- визначення сфери застосування інформаційної підсистеми як в теперішньому часі, так і в майбутньому;

- опис організаційної структури організації;

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

- опис вимог, яким повинна задовольняти система;

- опис функціональних обов’язків працівників, які будуть користувачами підсистеми (якщо автоматизується робоче місце фахівця);

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

- класифікацію інформації, яка має оброблятися розроблюваною інформаційною підсистемою.

У підрозділі «2.2 Документи, необхідні для вирішення задачі» необхідно навести перелік первісних документів, що циркулюють на об’єкті автоматизації та описати їх, можливо, надати їх форми.

Зміст документів є загальним для всіх видів автоматизованих систем та, при необхідності, може доповнюватися розробником в залежності від особливостей створеної автоматизованої системи. Допускається включення додаткових відомостей, що можуть бути розміщені у додатках.

Розділ «3 Постановка задачі» складається з чотирьох підрозділів.

У підрозділі «3.1 Специфікація функціональних вимог» необхідно навести наступну інформацію:

- опис призначення, технічно-економічна сутність задачі й обґрунтування необхідності її розв'язання, тобто пояснити для чого та для кого призначено розроблена ІПС;

- опис структури об’єктів автоматизації та перелік показників, що характеризують їх стан, тобто навести перелік класифікованих даних із зазначенням їх параметрів та критеріїв існування/вибору;

- опис можливостей та функцій, які має виконувати ІПС;

- опис періодичності та тривалості процесів;

- обмеження предметної області;

- опис інтерфейсу розроблюваної ІПС, тобто перелічити її структурні елементи: з чого має складатися головна та інші форми, структура цих форм, зв’язок між ними;

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

- опис вимог до організації збирання та передавання на обробку вхідної інформації (із зазначенням строків її надходження), до порядку її контролю та коригування;

- опис зв’язків даного комплексу задач з іншими комплексами інформаційної підсистеми;

- необхідні вимоги до технічних параметрів комп’ютера та типу обраної операційної системи;

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

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

Цей підрозділ повинен містити перелік технологій та методів програмування (СASE-технології при розробці ІПС, клієнт серверна технологія, об’єктно-орієнтоване програмування тощо) і засобів розробки програмного забезпечення, середовище розробки ІПС та вимоги до середовища і апаратної частини (персонального комп’ютера).

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

Приклад 1

Таблиця 3.1 – Вхідна інформація

Назва	Форма подання	Термін і частота використання
Замовлення	Масив оперативної інформації	Не обмежено
Автори	Масив нормативно-довідкової інформації	Не обмежено
Члени клубу	Масив нормативно-довідкової інформації	Не обмежено
Книги	Масив нормативно-довідкової інформації	Не обмежено

Приклад 2

Таблиця 3.2 – Вихідна інформація

Назва	Періодичність видачі	Одержувачі інформації
Чек на купівлю	Після оформлення купівлі	Член клубу, продавець
Замовлення за період	Щомісячно	Персонал книжкового клубу
Розділи	При необхідності	Члени клубу, продавець

Підрозділ «3.2 Опис вхідної інформації» містить наступну інформацію:

- перелік та опис вхідних повідомлень;

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

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

- ідентифікатор;

- форму представлення повідомлення та частоту надходження.

В описі кожної структурної одиниці інформації вхідних повідомлень слід наводити:

- найменування;

- необхідну точність її числового значення (при необхідності);

- джерело інформації (документ, відеограма, пристрій, кодограма, інформаційна база на машинних носіях і т.ін.);

- ідентифікатор джерела інформації.

Приклад 3

Форма 3.1 - Форма вхідного документа “Введення замовлення”

Код замовлення__________

Код консультанта__________

Дата замовлення___________

Дата прибуття_____________

Замовлення:

Код продукту	Кількість	Ціна	Бали

Приклад 4

Таблиця 3.3 – Опис реквізитів вхідної інформації

Найменування реквізитів вхідних документів	Характеристика реквізитів
	тип	макс. довжина
Код замовлення Код консультанта Дата замовлення Дата прибуття Код продукту Кількість Ціна Бали	Текстовий Текстовий Дата Дата Текстовий Числовий Грошовий Числовий	6 6 8 8 6 6 8 6

У підрозділі «3.3 Опис вихідної інформації» необхідно навести наступну інформацію:

- перелік та опис вихідних повідомлень;

- перелік та опис структурних одиниць інформації вихідних повідомлень: показників, реквізитів їх сукупностей, сигналів управління, які мають самостійне змістовне значення або посилання на документи, що містять ці дані.

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

- ідентифікатор;

- форму представлення повідомлення (документ, відеограма, сигнал керування) та вимоги до неї;

- періодичність видачі;

- строки видачі;

- одержувачів інформації та її призначення.

Склад опису допускається доповнювати в залежності від виду та особливостей повідомлення.

В описі кожної структурної одиниці інформації наводять:

- найменування;

- ідентифікатор вихідного повідомлення, яке містить структурну одиницю інформації;

- вимоги до точності обчислень (при необхідності).

Приклад 5

Таблиця 3.4 - Вихідна інформація

Назва	Форма	Звіт
Автори	+	+
Видавництва		+
Замовлення	+	+
Замовлення за період	+
Замовлення за розділами	+
Замовлені книги		+
Книги	+	+
Розділи		+
Чек	+	+
Члени клуба	+	+

Приклад 6

Форма 3.2 – Форма вихідного документа задачі з відомостями про авторів

Звіт

Автори

Код автора	Прізвище	Ім’я	Рік народження	Рік смерті	Примітка

Приклад 7

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

Звіт

Замовлені книги

Код книги ____________ Місто ________________

Код розділу ___________ Ціна __________________

Назва книги ___________ Кількість сторінок ______

Рік видання ____________ Примірників __________

Код видавництва _______ Примітка _____________

Код замовлення	Кількість замовлених книг

Підрозділ «3.4 Алгоритм проектування» відображає розробку і обґрунтування алгоритмів розв'язання поставленої задачі, містить побудову алгоритму, що реалізує обраний метод розв'язання задачі, схематичне зображення алгоритму і його опис. Алгоритм подається згідно з вимогами міждержавного стандарту «ГОСТ 19.701-90 ЕСПД «Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения» ».

Алгоритм проектування (розв’язання задачі) може бути поданий у вигляді:

• схеми;

• в табличній формі;

• опису логіки алгоритму;

• опису у вигляді тексту.

Схему при потребі доповнюють текстом.

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

Опис алгоритму варто виконувати в короткій формі з вказівкою призначення кожного елемента або групи елементів блоків.

Приклад опису алгоритму у вигляді схеми наведено у «Додаток Г».

Розділ «4 Проектування інформаційної моделі» складається з чотирьох підрозділів, що відображають процес від побудови моделі до створення фізичної бази даних і розробки запитів.

Підрозділ «4.1 Визначення концептуальної моделі» - це перший рівень проектування інформаційної підсистеми, на якому розробляється концептуальна модель даних. Ці моделі частіше за все класифікують як об'єктні. В якості засобів моделювання найчастіше обирають семантичне моделювання за допомогою ER-діаграм. Концептуальний проект є обґрунтуванням обраних об’єктних множин та зв‘язків між ними.

При побудові інфологічних моделей рекомендовано використовувати мову ER-діаграмм (Entity-Relationship, або сутність-зв'язок), де сутності зображуються поміченими прямокутниками, асоціації – поміченими ромбами або шестикутниками, атрибути – поміченими овалами (первинний ключ підкреслюють), а зв’язки між ними – ненаправленими ребрами, над якими може проставлятися ступінь зв’язку (1:М або ж M:N ) і необхідне пояснення (див. Рисунок 4.1 і Рисунок 4.2 відповідно).

Рисунок 4.1

Рисунок 4.2

У цьому підрозділі наводяться відомості про інформаційні об’єкти та їх властивості.

При виборі інформаційних об’єктів необхідно реалізувати наступні дії:

- розбити дані, що мають зберігатися у базі даних на таблиці (див. приклад 8);

- присвоїти кожній таблиці унікальне ім’я;

- визначити найбільш корисні характеристики (з точки зору користувача) (див. приклад 9);

- присвоїти обраним характеристикам імена.

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

Приклад 8

Таблиця 4.1 - Реквізитний склад інформаційних об’єктів

Реквізити	Ознака ключа	Назва інформаційного об’єкта
Код автора Прізвище Ім’я Рік народження Примітка	П, У	Автори
Код видавництва Назва	П, У	Видавництва
Код розділу Назва розділу	П, У	Розділи

Приклад 9

Таблиця 4.2 – Характеристики ідентифікаторів інформаційних об’єктів

Назва таблиці	Назва характеристики	Ідентифікатор характеристики
Автори	Код автора	Код_автора
	Прізвище	Фам
	Ім’я	Имя
	Рік народження	Год_рожд
	Рік смерті	Год_см

У підрозділі «4.2 Побудова реляційної бази даних» виявляються зв’язки між інформаційними об’єктами та типи цих зв’язків. Подаються у вигляді таблиці (див. приклад 10).

Приклад 10

Таблиця 4.3 - Зв’язки інформаційних об’єктів

Ключ зв’язку	Головний інформаційний об’єкт	Підлеглий інфор- маційний об’єкт	Тип відношення
Код автора Код книги Код книги Код замовлення Номер карти Код видавництва Код розділу	Автори Книги Книги Замовлення Члени клуба Видавництва Розділи	Автори книг Замовлені книги Автори книг Замовлені книги Замовлення Книги Книги	1:Б 1:Б 1:Б 1:Б 1:Б 1:Б 1:Б

Далі наводиться та описується схема, що відображає об’єкти (таблиці) бази даних, зв’язки між об’єктами та їх типи.

Логічна структура реляційної бази даних визначається сукупністю логічно взаємозалежних реляційних таблиць. Кожна реляційна таблиця має структуру, обумовлену реквізитним складом одного з інформаційних об'єктів отриманої інфологічної моделі. Логічні зв'язки відповідають структурним зв'язкам між об'єктами(або ж таблицями - див. рисунок 4.3).

Рекомендована кількість полів – для головної(головних) таблиці(таблиць) – від 7 до 10; а для підпорядкованих – від 4 до 7. Обов’язково потрібно визначити хоча б одну підпорядковану таблицю. Така обмеженість у кількості полів та таблиць обумовлена обсягами курсового проекту і може бути перевищена на вимогу виконавця проекту. У якості полів, що забезпечують структурні зв’язки, вибирають первинні (для головних таблиць) та вторинні(для підпорядкованих) індекси (ключі). Рекомендована кількість таблиць - від 5 до 8, але не менше 4-х. Може бути і більше, якщо цього потребує виконання завдання, або ж проект відображає складні взаємозв’язки між таблицями.

Рекомендовано такий підхід при переході від моделі «сутність-зв'язок» до реляційної бази даних:

- відношення 1:1 перетворюють шляхом переміщення ключа одного з об'єктів як додаткового атрибута в таблиці другого об'єкта; - у відношенні 1: М в таблицю, що описує об'єкт, потужність якого дорівнює "багато", включається стовпець, який відповідає ключу об'єкта, а для об’єкта, потужність якого дорівнює «один», цей стовпець буде зовнішнім ключем; - для перетворення відношення М: N створюють три таблиці - по одній для кожного об'єкта і перетин, який містить ключі двох інших таблиць.

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

Рисунок 4.3 – Схема даних спроектованої бази даних підсистеми

У підрозділі «4.3 Тестування підсистеми» наводять дані контрольного прикладу, на яких можна перевірити валідність побудованої схеми даних і підсистеми в цілому.

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

У цьому підрозділі наводиться:

• перелік параметрів і стислу характеристику функції із числа тих, що реалізовані у ІПС;

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

• результати обробки вхідних даних програмою, які дозволяють оцінити правильність виконання функцій, що перевіряються, і значення їх параметрів. Допускається результати розрахунку наводити у вигляді таблиць.

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

Таблиця 4.4 – Дані звіту “Члени клубу”

Номер карти	Прізвище	Ім’я	По батькові	Дата народження
102	Іванов	Іван	Петрович	12.12.1960

У підрозділі «4.4 Побудова запитів на мові SQL» необхідно навести декілька різноманітних SQL-запитів, що реалізовані у підсистемі. Обов’язковими є запити на вибірку з параметрами, з використанням складних фільтрів, запити на об’єднання, запити на видалення записів, додавання, змінення. Запити подаються у вигляді скриптів (команд SQL- див. приклади запитів).

Потрібно розробити узгоджену систему SQL-запитів для аналізу та маніпулювання даними, в якій би виконувалися всі основні операції над даними, що були визначені на етапі аналізу предметної області. Виклик запитів здійснюється через форми (або меню).

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

Пропозиція запиту на вибірку виглядає наступним чином: SELECT [предикат] {* | таблиця .* | [таблиця.] Поле1 [AS псевдонім1] [, [таблица.] Поле2 [AS псевдонім2] [, ...]]} FROM табличний вираз [, ...] [WHERE ... ] [GROUP BY ... ] [HAVING ... ] [ORDER BY ... ] Пропозиція SELECT містить такі частини: предикат - один з таких предикатів: ALL, DISTINCT або TOP. Використовуються для вказівки, як обробляти дублюючі записи і яка кількість записів виводиться в результаті виконання запиту, за замовчуванням – ALL.

* - Використовується для вибору всіх полів таблиці; таблиця - ім'я таблиці, в якій знаходиться обране поле; поле1, поле2 - імена вибраних полів, перераховуються через кому, як поле результуючого відношення може бути зазначено будь-який вираз, що використовує набір стандартних функцій (COUNT, AVG, SUM, MIN, MAX) і функцій, вбудованих в СКБД. Псевдонім1, псевдонім2 - імена, використані для заміни оригінальних імен полів, що виводяться.

Пропозиція FROM є обов'язковою частиною оператора SELECT. Визначається список таблиць, на які посилається запит. У якості таблиці може бути використане ім'я збереженого запиту або вираз, що з'єднує таблиці за допомогою операції INNER JOIN, LEFT JOIN або RIGHT JOIN.

Синтаксис операції з'єднання: FROM таблиця1 {INNER | LEFT | RIGHT} JOIN таблиця2 ON таблиця1.поле1 опер_срав таблиця2.поле2,

де INNER JOIN означає, що в результуючу таблицю потраплять комбінації тільки тих рядків першої таблиці, які мають задовольняють заданому оператору порівняння рядок у другій таблиці.

LEFT JOIN - всі рядки з першої таблиці і тільки «збігаються» з другої, а ті рядки першої таблиці, для яких немає «пари», об'єднуються з порожньою записом; аналогічно RIGHT, але в результат потрапляють всі рядки з другої таблиці.

Таблиця1, таблиця2 - імена таблиць, рядки з яких комбінують; поле1, поле2 - імена полів, які з'єднуються, повинні мати однакові типи даних, але не обов'язково однакові імена.

Опер_срав - будь-який оператор порівняння: "=," "<," ">," "<=," ">=," або "<>."

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

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

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

ORDER BY дозволяє визначити умови впорядкованості рядків в результуючій таблиці. Такою умовою є список полів, за якими необхідно упорядкувати рядки. Для кожного з атрибутів можна вибрати (DESC) або (ASC - за замовчуванням).

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

Приклад запиту 1

Завдання: побудувати запит, який вивів би інформацію про товар, що замовлений, якщо знижка більше нуля.

SELECT Tovar.kod_tovara, Tovar.opisanie, Tovar.edenica, Tovar.cena,;

Zakaz.nomer_zakaza, Zakaz.kod_tovara, Zakaz.skidka;

FROM MENEGER!TOVAR INNER JOIN MENEGER!ZAKAZ ;

ON Tovar.kod_tovara = Zakaz.kod_tovara WHERE Zakaz.skidka> 0

Приклад запиту 2

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

SELECT Tovar.kod_tovara, Tovar.opisanie, Tovar.cena, ; Tovar.kolichestvo;

FROM meneger!tovar WHERE Tovar.kolichestvo = ( 0 )

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

Розділ «5 Розробка інформаційної підсистеми» складається з двох підрозділів, що відображають інтерфейс підсистеми та опис автоматизованих функцій.

Підрозділ «5.1 Інтерфейс підсистеми» описує складові частини

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

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

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

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

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

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

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

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

- введення і редагування даних всіх висхідних таблиць (таблиці-довідники за допомогою стандартних елементів управління, а таблиці оперативних даних - за допомогою спеціально розроблених форм);

- зручний перегляд пов'язаних даних;

- виконання автоматизованих розрахунків;

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

- довідкова система(спливаючі підказки, інструкції);

- перегляд результатів запитів;

- друк звітів (простих і з угрупованням).

Рекомендовано запуск підсистеми розпочинати зі старту Головної форми, на якій відобразити назву навчального закладу, тему курсового проекту, прізвище студента та керівника, рік розробки. Якщо система передбачає захист даних від несанкціонованого доступу, або ж виділення груп користувачів, додати запит з вводом паролю.

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

Сучасні СКБД пропонують розробнику набір так званих Майстрів(Wizard), що дозволяють візуально і досить швидко розробити форми, запити, звіти. Для більшої „читабельності” рекомендується використовувати підписи(Caption), коментарі, описи тощо.

У підрозділі «5.2 Опис автоматизованих функцій» розміщують перелік автоматизованих функцій, що реалізовані у розробленій підсистемі. До них відносять:

• опис процедур формування вхідних даних для перевірки працездатності та правильності роботи ІПС, запуску на виконання програми, що перевіряється, і одержання результатів розрахунку (або виконання функцій автоматизованої системи); опис дій оператора при підготовці вхідних даних і перевірці програми на контрольному прикладі.

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

• - вимоги до часового регламенту та характеристикам процесу реалізації автоматизованих функцій (точності, надійності і т. ін.), вирішення задач.

У висновках, що розташовані окремим структурним елементом, тобто як «Висновки», студент повинен навести стислий перелік отриманих результатів, їх оцінку відповідно обраній темі, коротку характеристику розробленої автоматизованої підсистеми, напрямок та можливості вдосконалення даного проекту. У цьому структурному елементі відображають також відповідність вимогам завдання на курсове проектування.

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

У висновках студент вказує, які завдання розв’язані ним у процесі проектування, та які навички та вміння були вдосконалені (отримані) під час виконання курсового проекту.

Список використаних джерел

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

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

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

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