Складання патенто-правових документів на "Машину для виймання анодних штирів алюмінієвого електролізера" (стр. 13 из 17)
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | Заява_id | Числовий | РК |
| 2 | МПК_id | Числовий | FK |
| 3 | Дата_подання | Дата/час | |
| 4 | Пріоритет | Дата/час | |
| 5 | Назва | Текстовий (50) | |
| 6 | опис | Текстовий (50) | |
| 7 | формула | Текстовий (50) | |
| 8 | креслення | Текстовий (50) | |
| 9 | реферат | Текстовий (50) | |
| 10 | документ сплати збору | Логічний | |
| 11 | документ_депонування | Логічний |
Прдовдення Таблиці 6.1
| 1 | 2 | 3 | 4 |
| 12 | копія попередньої заявки | Текстовий (50) | |
| 1 | 2 | 3 | 4 |
| 13 | переклад заявки | Текстовий (50) | |
| 14 | документ_ПП | Текстовий (50) | |
| 15 | інші документи | Текстовий (50) | |
| 16 | міжнародний звіт пошуку | Текстовий (50) |
Таблиця 6.2 – Автори
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | Автори_id | Текстовий (50) | РК |
| 2 | Особа_id | Числовий | FK |
| 3 | Заява_id | Числовий | FK |
Таблиця 6.3– Заявник
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | Заявник_id | Текстовий (50) | |
| 2 | Заява_id | Числовий | РК |
| 3 | Особа_id | Текстовий (50) | FK |
| 4 | ЄДРПОУ | Числовий |
Таблиця 6.4 – Країна
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | Країна_id | Числовий | РК |
| 2 | Назва | Текстовий (50) | |
| 3 | Код | Числовий |
Таблиця 6.5 – Особа
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | 2 | 3 | 4 |
| 1 | Особа_id | Текстовий (50) | РК |
| 2 | Ім´я | Текстовий (50) | |
| 3 | Тип | Логічний | |
| 4 | Країна_id | Числовий | FK |
| 5 | Місто_id | Числовий | FK |
| 6 | Адреса | Текстовий (50) | |
| 7 | Телефон | Числовий | |
| 8 | Факс | Числовий | |
| 9 | E_mail | Текстовий (50) |
Таблиця 6.6 – Місто
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | Місто_id | Числовий | РК |
| 2 | Місто | Текстовий (50) |
Таблиця 6.7 – МПК
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | МПК_id | Текстовий (50) | РК |
| 2 | МПК_код | Текстовий (50) |
Таблиця 6.8 – Патентний повірений
| № | Назва столбца | Тип даних | Ключ |
| 1 | 2 | 3 | 4 |
| 1 | ПП_id | Текстовий (50) |
Продовження Таблиці 6.8
| 1 | 2 | 3 | 4 |
| 2 | Особа_id | Текстовий (50) | FK |
| 3 | Заява_id | Числовий | РК |
| 4 | №Гос_регістрації | Числовий |
Графічний інтерфейс користувача реалізований з використанням форм MicrosoftAccess. Форми - це об'єкти, в які розташовуються інші об'єкти для створення призначеного для користувача інтерфейсу будь-якого додатку. Модулі складаються з коду, який реалізує функціонування додатку, обробники подій для форм і їх компонент.
В програмі присутні 2 форми, «Пошук», і «Бібліографічні дані», що наведені на рис. 6.2
Рисунок 6.2 – Форма «Бібліографічнідані»
Форма «Пошук», містить поля (критерії), за якими операторвиконує пошук потрібних йому заявок. Форма «Пошук» показана на рисунку 6.3
Рисунок 6.3 – Форма «Пошук»
Були створені запити, за якими оператор веде пошук потрібних йому заявок:
- Знайти заявку за “датою подачі”
- Знайти заявку за “датою публікації”
- Знайти заявку за “номером публікації”
- Знайти заявку за “регістраційним номером”
- Знайти заявку за “назвою”
- Знайти заявку за “МПК”
6.2 Опис функціональності програмного приложення
6.2.1 Діаграма варіантів використання
Для опису функціональних можливостей даного програмного забезпечення використовується діаграма варіантів використання (діаграма прецедентів) мови UML і текстовий опис прецедентів. Діаграма варіантів використання, що представлена на мал. 6.4, показує взаємодію оператора із системою у процесі перегляду заявок на корисну модель.
Рисунок 6.4 –Діаграма варіантів використання
Дана діаграма є вихідним концептуальним представленням або концептуальною моделлю системи в процесі просмотру заявок на корисну модель.
6.2.2 Опис прецедентів
6.2.2.1 Потік подій для прецеденту «Введення інформації»
1. Передумова. Оператор вибрав режим «Введення інформації»
2.Головний потік. Система відображає діалогове вікно, що містить меню для вибору режиму роботи оператора – добавлення інформації, редактування (правка) інформації, видалення інформації. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йому дії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
2.1 Подпотік “Додання інформації о заявке”.
Система відображає діалогове вікно, що містить запит “Додання інформації о заявке” та “Вихід”. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йомудії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
2.2 Подпотік “Правка інформації”.
Система відображає діалогове вікно, що містить запит “Правка інформації” та “Вихід”. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йомудії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
2.2 Подпотік “Видалення інформації о заявке”.
Система відображає діалогове вікно, що містить запит “Видалення інформації о заявке” та “Вихід”. Оператор дає запит на потрібну йому дію. Система відкриває потрібний операторові запит. Оператор виконує потрібні йомудії. Після закінчення роботи оператор дає запит на закінчення роботи. Система зберігає нову інформацію. Прецедент завершується.
6.2.2.2 Потік подій для прецеденту «Перегляд інформації»
1.Передумова. Оператор вибрав режим « Перегляд інформації ».
2.Головний потік. Система відображає діалогове вікно, що містить меню вибору. Користувач вибирає необхідний фільтр. Система фільтрує зображення і надає користувачу. При необхідності користувач запитує інший фільтр. Після закінчення роботи користувач дає запит на закінчення роботи з зображенням. Система зберігає зображення. Прецедент завершується.
6.2.2.3 Потік подій для прецеденту «Друк»
1.Передумова. Оператор вибрав режим «Друк».
2.Головний потік. Користувач дає запит на друк заявки на корисну модель. Система видає оператору параметри друку і запитує дію. Оператор вибирає необхідні параметри. Система роздруковує інформацію о заявке. Оператор дає запит на закінчення роботи. Прецедент завершується.
6.3 Рекомендації до розробки бази даних
Основні відомості
Додаток Microsoft Access 97/2000 (далі Access) є потужною й високопродуктивною 32-розрядною системою керування реляционной базою даних (далі СУБД).
Системні вимоги пропоновані СУБД Access
· Intel 486DX2 – 66 +
· Windows 98/2000/XP або Windows NT (версія не нижче 4.51)
· Не меньш 64 Мб оперативної пам'яті (для спільної роботи з іншими додатками не менш 128 Мб)
· Близько 300 Мб дискового простору (тільки для Access і нових баз даних).
· СУБД розробляються з метою забезпечення ефективної обробки більших обсягів інформації.
· СУБД може легко зв'язувати будь-яка кількість таблиць так, що для користувача вони будуть представлятися однією таблицею. Реалізувати таку можливість в електронних таблицях практично неможливо.
· СУБД мінімізують загальний обсяг бази даних. Для цього таблиці, що містять повторювані дані, розбиваються на кілька зв'язаних таблиць.
Як реляційна СУБД Access забезпечує доступ до всіх типів даних і дозволяє одночасно використати кілька таблиць бази даних. Працюючи в середовищі Microsoft Office, користувач одержує у своє розпорядження повністю сумісні з Access текстові документи (Word), електронні таблиці (Excel), презентації (PowerPoint). За допомогою нових розширень для Internet можна прямо взаємодіяти з даними з World Wide Web і транслювати подання даних мовою HTML, забезпечуючи роботу з такими додатками як Internet Explorer і Netscape Navigator.
Access спеціально спроектований для створення многопользовательских додатків, де файли бази даних є поділюваними ресурсами в мережі. База даних зберігатися в одному файлі, але професійні користувачі воліють розділяти базу даних на два файли: в одному зберігаються об'єкти даних (таблиці, запити), в іншому об'єкти додатка (форми, звіти, макроси, модулі).
В Access реалізована надійна система захисту від несанкціонованого доступу до файлів.
Висновки по розділу
У даному розділі дипломної роботи був розроблен проект бази даних для документів заявки. Функціональні можливості проекту представлені у виді діаграми варіантів використання із описом прецедентів, що демонструє взаємодію оператора із системою в процесі роботи з інформацією про заявки. Архітектурна частина представлена у виді таблиць, що ілюструють загальну архітектурну схему проекту бази даних для роботи з інформацією про заявках.