ВСТУП
Даний курсовий проект створений в СУБД Ассе ss 2000. Перевагою даної БД є швидкість і наочне надання всієї необхідної інформації про співробітників та їх продуктивної діяльності. В даний час відбувається бурхливий розвиток комп'ютерних технологій. Це природно обумовлене підвищенням попиту на якісну та зручну інформацію практично в кожній галузі промисловості. За багато років роботи підприємства накопичили великі обсяги інформації, яка продовжує збільшуватися, виникає необхідність у її обробці. Зрозуміло, що працювати з величезною купою паперової інформацією довго і трудомістко, виходом з такого стану справ стало створення БД.
Це значно полегшило роботу різних інформаційних служб. Але в сучасному технократичному світі всіляких даних, відомостей не просто багато, а гігантська кількість. Найчастіше одержуючи інформацію з різних джерел, співробітники підприємства спостерігали дублювання даних. Це нікого не радувало. Перед творцями особистої картотеки поставало питання: як розмістити інформацію так, щоб мінімально використовувати фізичне дисковий простір, оперативну пам'ять і при цьому забезпечити оперативний доступ до даних
Комп'ютерні технології проникли у більшість підприємств, навчальних закладів, дослідницьких інститутів. Це полегшило обробку величезної кількості інформації, пошуку даних. Велика допомога надана відділу кадрів. Тепер зовсім не важко робити швидко і якісно різні вибірки, запити з особового складу працівників інституту, по успішності студентів інституту і т.д.
1 ПОСТАНОВКА ЗАВДАННЯ
1.1 Загальна постановка задачі
Метою написання даного ПП є проектування бази даних, яка міститиме докладну інформацію про співробітників та їх діяльності, надавати докладну інформацію про їх відділах, завданнях видані і виконані співробітниками.
У цілому, база даних «Записна книжка керівника» повинна:
забезпечувати можливість запитувати, відшукувати, змінювати і систематизувати інформацію про співробітників, завдання та відділах в БД;
мати зручний користувальницький інтерфейс для роботи з базою даних користувача, який не є спеціалістом в області обробки даних;
містити систему допомоги, необхідну довідкову інформацію та інформацію про програму;
містити необхідні запити і форми для обробки інформації, що зберігається;
забезпечувати захист від несанкціонованого доступу (використовувати паролі і захист на рівні користувачів);
контролювати надмірність (передбачати архівацію даних), несуперечність, збереження і достовірність інформації, що зберігається в БД інформації.
містити необхідну інформацію про співробітників, завданнях і відділах та надавати її на вимогу.
1.2 Основні складові компоненти проектованої БД
Для реалізації поставленого завдання в проектовану БД необхідно включити наступні розділи:
інформація про співробітників;
інформація про завдання;
інформація про відділи.
2 ОПИС ПРЕДМЕТНОЇ ОБЛАСТІ
База даних «Записна книжка керівника» нам потрібна для зручності стеження за виконанням завдання різними співробітниками. Кожен керівник має свою записну книжку, яка необхідна йому для запису завдань, які він видає своїм співробітникам і для оцінки виконання цих завдань. У ній він вказує дані про співробітників його підприємства: прізвище, ім'я, по батькові співробітника, домашню адресу, контактний телефон (телефон може бути як домашнім, так і мобільним, тобто включає в себе 13 символів), також відділ, в якому він працює (включає в себе ділянку і цех (цех позначається абревіатурою)), обов'язково вказує займану посаду співробітника. Кожному співробітникові керівник видає завдання і заносить відомості про нього, такі як: яке завдання видано, дата видачі (яке повинно вводитися не раніше сьогоднішнього числа), дата виконання завдання (обмеження такі ж як і у дати видачі) та оцінка виконання завдання (оцінка ставитися за п'ятибальною системою). Причому за одним співробітником може бути закріплено кілька завдань і одне завдання можуть виконувати кілька співробітників. За цій базі даних ми можемо зробити запит про те, хто яке завдання виконав і на яку оцінку або знайти співробітників, які займають одну посаду. Також в базі існує архівація даних. Архівація відбувається по ПІБ співробітника.
3 ОПИС СХЕМИ ОБ'ЄКТ-СТАВЛЕННЯ
Виходячи з моєї предметної області, я виділила наступні об'єкти: «Співробітники», «Відділ», «Посада», «Завдання». Кожен об'єкт має деякі властивості. Об'єкт «Працівники» має властивості: ПІБ, «Адреса», «Телефон»; Об'єкт «Відділ» має властивості: «ділянку», «цех»; У «Посади» є властивість: «назва посади»; В об'єкта «Завдання »властивість:« найменування завдання ».
Виділимо необхідні відносини між об'єктами з схеми об'єкт-відношення, представленої на малюнку 3.1:
1. СПІВРОБІТНИКИ відносяться до ВІДДІЛУ;
2. СПІВРОБІТНИКИ мають ПОСАДУ;
СПІВРОБІТНИКИ виконують ЗАВДАННЯ.
«Відділ» і «Співробітники» мають відношення один до багатьох, так як в одному відділі може працювати декілька співробітників і співробітник може значиться лише в одному відділі. «Співробітники» відноситься до «Посади» як багато до одного: багато співробітників можуть мати одну й ту ж посаду. «Працівники» з «Завданням» перебуває у відношенні багато до багатьох, так як багато різних завдань можуть виконувати багато співробітників. Тому в їх відношенні я виділила окремі властивості: дату видачі, дату виконання і оцінку.
Малюнок 3.1 - Схема об'єкт-відношення
4 ВИБІР І ОБГРУНТУВАННЯ МОДЕЛІ ДАНИХ
Велика кількість розроблених до теперішнього часу різноманітних СУБД пов'язано з існуванням різних моделей даних. При проектуванні БД ми стикаємося із завданням вибору найбільш підходящої моделі даних для конкретної предметної області.
З наведеної схеми (рисунок 3.1) видно, що між об'єктами існують зв'язки мають тип як «один до багатьох», так і «один до одного». Це дозволяє здійснити проектування БД з використанням як реляційної, так і мережевій моделі даних. Перевагу було віддано реляційної моделі даних.
БД може бути заснована на одній моделі або на сукупності кількох моделей. Будь-яку модель даних можна розглядати як об'єкт, який характеризується своїми властивостями (параметрами), і над нею, як над об'єктом, можна проводити будь-які дії.
Будь-яка модель повинна забезпечувати такі операції над БД:
- Пошук зазначеного елемента бази;
- Перехід від одних даних до інших;
- Рух по записах;
- Пошук запису;
- Видалення запису;
Існують три основних типи моделей даних - реляційна, ієрархічна і мережна.
4.1 Ієрархічна модель даних
В ієрархічній моделі зв'язку між даними описують за допомогою упорядкованого графа (або дерева). Тип є складовим. Він включає в себе підтипи («піддерева»), кожен з яких, у свою чергу, є типом «дерево». Кожен з елементарних типів, включених в тип "дерево", є простим або складеним типом «запис».
Таким чином, ІМД представляє собою упорядковану сукупність екземплярів типу «дерево» (дерев), що містять екземпляри типу «запис» (записи).
Відповідно до визначення типу «дерево», можна зробити висновок, що між предками і нащадками автоматично підтримується контроль цілісності зв'язків. Основне правило контролю цілісності формулюється наступним чином: нащадок не може існувати без батька, а деяких батьків може не бути нащадків. Механізми підтримки цілісності зв'язків між записами різних дерев відсутні.
Дані в базі з наведеною схемою для розробленого ПП можуть виглядати, наприклад, як показано на малюнку 4.1.
Малюнок 4.1 - Приклад ієрархічної моделі даних для проектованої БД
Кореневими є тип Співробітники, який у свою чергу має свої підлеглі типи. Співробітники має такі підлеглі типи як Відділ, Посада та Завдання. До достоїнств ІМД відносять ефективне використання пам'яті ЕОМ і непогані показники часу виконання основних операцій над даними. А саме: пошук зазначеного примірника БД, перехід від одного дерева до іншого, перехід від одного запису до іншого всередині дерева, вставка нового запису в зазначену позицію, видалення поточного запису. ІМД зручна для роботи з ієрархічно упорядкованою інформацією. Недоліком ІМД є її громіздкість для обробки інформації з досить складними логічними зв'язками, а також складність розуміння для звичайного користувача.
4.2 Мережева модель даних
Мережева модель дозволяє відображати різноманітні взаємозв'язки елементів даних у вигляді довільного графа, узагальнюючи тим самим ІМД.
СМД складається з набору записів та набору відповідних зв'язків. На відміну від ІМД в СМД запис-нащадок може мати довільну кількість записів-предків (зведених батьків).
Схема СМД для даної БД показана на малюнку 4.2. Типи зв'язків тут позначені написами на з'єднують типи записів лініях.
Малюнок 4.2 - Мережева модель даних
Аналізуючи схему, бачимо, що всі елементи пов'язані один з одним. Будь-який елемент може бути виражений через інші елементи. З одного боку це добре, але з іншого погано: на формування типів зв'язку не накладаються особливі обмеження, що приводить при виконанні основних операцій над даними до негативних для проектованої БД ситуацій. Наприклад, у додатковій таблиці з'являться записи, які не мають батьківських записів в основній таблиці.
Тому недоліком СМД є висока складність і жорсткість схеми БД, побудованої на її основі, а також складність для розуміння і виконання обробки інформації в БД звичайним користувачем. Крім того, в СМД ослаблений контроль цілісності зв'язків внаслідок допустимості встановлення довільних зв'язків між записами. Таким чином, для розробленої в пункті 3 схеми об'єкт-відношення дану модель даних застосовувати небажано.
Перевагою СМД є можливість ефективної реалізації за показниками витрат пам'яті й оперативності. У порівнянні з ІМД мережева модель надає великі можливості в сенсі допустимості освіти довільних зв'язків.
4.3 Реляційна модель даних
Реляційна модель даних деякої предметної області являє собою набір відносин (двовимірних таблиць), що змінюються в часі.
У загальному випадку можна вважати, що реляційна БД включає одну або декілька таблиць, об'єднаних смисловим змістом, а також процедурами контролю цілісності та обробки інформації в інтересах вирішення деякої прикладної задачі. Наприклад, при використанні СУБД Microsoft Access у файлі БД поряд з таблицями зберігаються й інші об'єкти бази: запити, звіти, форми, макроси та модулі.
Гідність РМД полягає в простоті, зрозумілості та зручності фізичної реалізації на ЕОМ. За допомогою однієї таблиці зручно описувати найпростіший вид зв'язків між даними, а саме поділ одного об'єкта, інформація про який зберігатися в таблиці, на безліч підоб'єктів, кожному з яких відповідає рядок або запис таблиці. Фізичне розміщення даних у реляційних базах на зовнішніх носіях легко здійснюється за допомогою звичайних файлів. Проблеми ж ефективності обробки даних цього типу виявилися технічно цілком можна вирішити.
Основними недоліками реляційної моделі є наступні: відсутність стандартних засобів ідентифікації окремих записів і складність опису ієрархічних і мережевих зв'язків.
Перехід від схеми об'єкт - відношення до реляційної моделі даних здійснюється наступним чином: всі об'єкти схеми об'єкт - відношення це певні таблиці назву полів яких є властивостями об'єктів, якщо відношення має властивості то воно також є таблицею в отриманій реляційної моделі даних
Для проектованої бази даних реляційна модель представлена на малюнку 4.3.
Малюнок 4.3 - Реляційна модель даних
Таким чином, після розгляду наведених вище моделей даних для розробленої в пункті 3 схеми об'єкт-відношення була обрана РМД, яка проста і зрозуміла для користувача і відповідає вимогам досліджуваного курсу.
5 ОБГРУНТУВАННЯ ВИБОРУ СУБД
Основи сучасної інформаційної технології складають бази даних (БД - це структурована певним чином сукупність даних, що відносяться до конкретного завдання) та системи управління базами даних (СКБД представляє собою комплекс інструментальних засобів, програмних і мовних, реалізують централізоване управління БД і забезпечують доступ до даних (зміни , додавання, видалення, резервного копіювання і т.д.), роль яких як єдиного засобу зберігання, обробки і доступу до великих обсягів інформації постійно зростає. Швидкий розвиток потреб застосувань БД висуває нові вимоги до СУБД: природні та ефективні подання до БД різноманітних відносин між об'єктами предметних областей (наприклад, просторово-часових із забезпеченням візуалізації даних); СУБД повинна забезпечувати пошук, модифікацію і збереження даних, а також оперативний доступ (час відгуку), захист цілісності даних від апаратних збоїв та програмних помилок, розмежування прав і захист від несанкціонованого доступу, підтримка спільної роботи декількох користувачів з даними.
Цим вимогам відповідають багато сучасних СУБД, в тому числі і Access. МА включає в себе традиційні технології і можливості реляційних СУБД, надає засоби створення бази нормалізованих даних і форм для діалогової роботи з нею та зручним графічним інтерфейсом. З побудовою бази нормалізованих даних тісно пов'язана розробка та ефективна реалізація завдань користувача. Для ренію багатьох завдань досить використовувати такі об'єкти Access, як форми, запити, звіти. Ці об'єкти легко створюються в діалоговому режимі. Для реалізації цілісного додатки користувача в деякій предметній області виникає необхідність у створенні макросів і модулі на мові Visual Basic for Applications (VBA). Механізм обробки подій, що виникають у процесі діалогової роботи з даними, дозволяє об'єднувати в додатку користувача окремі запити, форми і звіти і отримувати нестандартні ренію в практичних додатках користувача.
Програма Microsoft Access 2000 є реляційної СУБД, яка може функціонувати під управлінням операційних систем Windows 95/98 / Me, Windows NT, Windows XP, і дозволяє реалізувати поставлену мету. Забезпечує зручність роботи користувача: є можливість створення користувацьких інтерфейсів при використанні Visual Basic для додатків, автоматизація розробки різних об'єктів. Для побудови і виконання запитної функції в Access 2000 дуже зручним і доступним є мова запитів за зразком QBE, підтримуваний потужним інтерфейсом користувача, а також вбудовану мову запитів SQL, який є зручним мовою управління базами даних.
Програма Microsoft Access 2000 має невеликий обсяг допоміжного програмного забезпечення, внаслідок чого пред'являє менше вимог до пам'яті, чим програми Microsoft Access пізніх версій. Крім того, для проектування необхідної БД немає необхідності у використанні можливостей більш пізніх програм Office або інших фірм виробників. Цілком достатньо коштів, наданих користувачеві Microsoft Access 2000.
6 опис концептуальної моделі реляційної
БАЗИ ДАНИХ
6.1 Схема даних
Схема даних, відображає логічне уявлення реляційної моделі даних для проектованої БД.
Побудувати іншу концептуальну модель для даної БД таким чином, щоб вона відповідала специфіці предметної області і в інформаційному плані зберігала всі можливості наведеної вище моделі без додавання нових об'єктів, практично неможливо.
Нормалізація - це розбиття таблиці на дві або більше, що володіють кращими властивостями при включенні, зміну і видалення даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в якому кожен факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечливості збережених даних.
Таблиця знаходиться в першій нормальній формі (1НФ) тоді і тільки тоді, коли жодна з її рядків не містить в будь-якому своєму полі більше одного значення і жодна з її ключових полів не порожній.
Таблиця знаходиться в другій нормальній формі (2НФ), якщо вона задовольняє визначенню 1НФ і всі її поля, що не входять в первинний ключ, пов'язані повної функціональної залежністю з первинним ключем.
Таблиця знаходиться в третій нормальній формі (3НФ), якщо вона задовольняє визначенню 2НФ і не одне з її не ключових полів не залежить функціонально від будь-якого іншого не ключового поля.
ПІБ С50 | Адреса С25 | Телефон С7 | Цех С3 | Ділянка С3 | Посада С10 | Завдання С50 | Дата видачі D8 | Дата виконання D8 | Оцінка N1 |
Малюнок 6.2 - Таблиця даних у 1НФ
Малюнок 6.3 - Функціональна залежність для 1НФ
Малюнок 6.4 - Таблиці даних під 2НФ
Після представлення таблиць у 2НФ, уявімо шапки таблиць в 3НФ:
Співробітники
# КС | ПІБ | Адреса | Телефон | КВ # | КД # |
Посада
# КД | Посада |
Про завдання
КЗ # | КС # | Дата видачі | Дата виконання | Оцінка |
Завдання
# КЗ | Завдання |
Відділ
# КВ | Ділянка | Цех |
Малюнок 6.5 - Таблиці даних у 3НФ
6.2 Опис і обгрунтування полів таблиць
У проектованої базі даних реалізовано 5 таблиць. Нижче для кожної таблиці наведено опис, обгрунтування полів, обмеження на вхідну інформацію, необхідні маски введення, використовувані підстановки. Всі приклади заповнених таблиць наведені в додатку В.
Таблиця «Працівники» (таблиця 6.2.1):
# КС
-Ключ: первинний ключ;
-Лічильник;
-Довге ціле [3];
-Збіг не допускаються, так як це первинний ключ, він вважає запису в таблиці.
2. ПІБ
- Текстове [50];
- Обов'язкове поле, тому що назва підприємства - це головна особливість, за якою можна розрізняти співробітників;
- Порожніх рядків немає, так як не може бути підприємство без назви;
- Збіг допускаються, тому що в різних співробітників може бути однакові ПІБ;
3. Адреса
- Текстове [25];
- Обов'язкове поле, тому що в кожного співробітника має свою адресу;
-Збіги допускаються, тому що різні співробітники можуть проживати за однією адресою;
4. Телефон
-Текстове [7];
-Поле не обов'язкове, так як співробітник може не мати телефону;
-Збіги допускаються, тому що різні співробітники можуть мати один телефон;
5. Відділ
-Тип довге ціле [2];
-Обов'язкове поле, так як кожен співробітник працює у відділі;
-Збіги допускаються, так як кілька співробітників працюють в одному відділі;
-Підстановка: з таблиці «Відділ», поле «# КО»;
-Зовнішній ключ.
6. Посада
-Тип довге ціле [2];
-Обов'язкове поле, так як кожен співробітник повинен мати свою посаду;
-Збіги допускаються, так як кілька співробітників можуть мати одну посаду;
-Підстановка: з таблиці «Посади», поле «# КД»;
-Зовнішній ключ.
Таблиця 6.2.1 «Співробітники»
Таблиця «Завдання» (таблиця 6.2.2):
# КЗ
-Ключ: первинний ключ;
-Лічильник;
-Довге ціле [3];
-Збіг не допускаються, так як це первинний ключ, він вважає запису в таблиці.
Завдання
- Текстове [50];
- Обов'язкове поле, так як це основне поле таблиці;
- Порожніх рядків немає, так як завдання повинне мати текст;
- Збіги не допускаються, так як записи про два однакових завданнях не потрібні.
Таблиця 6.2.2 «Завдання»
Таблиця «Відділ» (таблиця 6.2.3):
1. # КВ
-Ключ: первинний ключ;
-Лічильник;
-Довге ціле [3];
-Збіг не допускаються, так як це первинний ключ, він вважає запису в таблиці.
2. Ділянка
- Текстове [3];
- Обов'язкове поле, так як ділянка повинна мати назву;
- Збіги не допускаються, тому що різні ділянки повинні мати різні імена.
3. Цех
- Текстовий [3];
- Обов'язкове поле, оскільки цех повинен мати назву
- Збіги не допускаються, тому що різні цехи повинні мати різні назви.
Таблиця 6.2.3 «Відділ»
Таблиця «Посади» (таблиця 6.2.4):
1. # КД
-Ключ: первинний ключ;
-Лічильник;
-Довге ціле [3];
-Збіг не допускаються, так як це первинний ключ, він вважає запису в таблиці.
2. Посада
- Текстове [20];
- Обов'язкове поле, так як це основне поле таблиці;
- Порожніх рядків немає, так як поле не може мати пусте назва;
- Збіги не допускаються, тому що різні посади повинні мати різні назви.
Таблиця 6.2.4 «Виріб»
Таблиця «Про завдання» (таблиця 6.2.5):
1. Співробітник
-Тип довге ціле [2];
-Обов'язкове поле, так як кожен завдання повинне виконуватися співробітником;
-Збіги допускаються, так як кілька співробітників можуть виконувати одне завдання;
-Підстановка: з таблиці «Працівники», поле «# КС»;
-Зовнішній ключ.
2. Завдання
-Тип довге ціле [2];
-Обов'язкове поле, так як кожен співробітник повинен виконувати завдання;
-Збіги допускаються, так як кілька співробітників можуть виконувати одне завдання;
-Підстановка: з таблиці «Завдання», поле «# КЗ»;
-Зовнішній ключ.
Дата видачі
-Тип дата [10];
- Обов'язкове поле, так як завдання повинне мати дату видачі;
-Збіги допускаються, тому що різні завдання можуть видаватися в один день;
- Маска: 00.00.0000;
-Значення за замовчуванням = Date ();
- Умова на значення = Date () так як завдання повинне мати поточну дату видачі.
Дата виконання
-Тип дата [10];
- Не обов'язкове поле, так як завдання може видаватися без терміну виконання;
-Збіги допускаються, тому що різні завдання можуть мати один термін виконання;
- Маска: 00.00.0000;
- Значення за замовчуванням = Date ()
- Умова на значення> = Date () and> (дата видачі), так як завдання не може бути виконано раніше, ніж видано.
Оцінка
-Тип довге ціле [1];
-Поле не обов'язкове, так як завдання може бути не виконано на поточний момент;
-Збіги допускаються, тому що завдання можуть виконуватися на одну оцінку;
-Підстановка: використовується фіксований набір значень;
Таблиця 6.2.5 "Про завданнях»
7 КОМПЛЕКТ ПОСТАВКИ І ПОРЯДОК ВСТАНОВЛЕННЯ БД
Для нормального функціонування даного ПП необхідно:
- Операційна система Windows 95 і вище;
- Офісний додаток Microsoft Access 2000;
- Не менше 64 Мбайт оперативної пам'яті;
- 40 Мбайт дискового простору.
База даних поставляється в саморозпаковується архіві «Записна книжка керівника. Exe», в якому міститься файл «Записна книжка руководітеля.mdb». Для початку, необхідно розпакувати архів в потрібну директорію, запустити потрібний файл. Перед вами з'явиться вікно, що запрошує пароль. У початковому варіанті БД існує два паролі: для адміністратора і керівника. Пароль для адміністратора «admin», для керівника - «ruk». Гість може увійти, натиснувши кнопку «ОК». Далі з'явиться головна форма і меню, за допомогою яких користувач може працювати з базою даних.
ВИСНОВКИ
Результатом проведеної роботи є база даних «Записна книжка керівника» в СУБД Microsoft Access, що має зручний користувальницький інтерфейс, призначений для роботи різних груп користувачів.
База даних може надати користувачеві всю необхідну інформацію про виконувані завдання. Таким чином, головну мету написання даного курсового проекту, а саме створення БД, що дозволяє автоматизувати облік виконуваних і виконаних завдань.
Розроблена база даних може мати широке застосування. Її можуть використовувати прикладні програмісти, навчальні заклади, студенти, що проходять курс за подібною тематикою. Особливо рекомендується використовувати БД статистичними організаціям: зникне необхідність у багатотомних паперових картотеках, в стомлюючої ручній роботі над розробкою статистичних даних. Також, дану базу може використовувати кожен керівник для зручності запису даних про завдання і співробітників. Крім того, комп'ютер може вести пошук і змінювати дані набагато швидше людини і краще виконувати механічну роботу.
База даних проста у використанні, що навіть недосвідчений користувач зможе легко розібратися, як з нею працювати. Для розуміння її функціонування не потрібно знань особливих розділів проектування баз даних, спеціальних навичок програмування і знань економічних дисциплін. Чи не виникне проблем з використанням цієї БД і при наявності комп'ютера, що володіє мінімальною обчислювальною потужністю.
Список використаної літератури
Хомоненко А. Д., Циганкова В. М., Мальцев М. Г. Бази даних: Підручник для вищих навчальних закладів / За ред. проф. А. Д. Хомоненко. - Видання друге, доповнене і перероблене - СПб.: КОРОНА принт, 2002.
Дейт К. Дж. Введення в системи баз даних, 6-е видання: Пер. з англ. - К.; М.; СПб.: Видавничий дім «Вільямс», 2000.
Пасько В. Access 97 - К.: Видавнича група BHV, 2000. - 368с.
Дейт К., Дж. Введення в системи баз даних, 6-е видання - К.; М.; СПб.: Через видавничої дім "Вільямс", 2000.
Бекаревич Ю.Б., Пушкіна Н.В. MS Access 2000 за 30 занять. - СПб.: БХВ-Петербург, 2001. - 512 с.: Іл.
Методичні вказівки з оформлення студентських робіт / Укл.: Л. А. Білозерський та ін - Донецьк: ДГІІІ, 2000р.
Додаток Б
КЕРІВНИЦТВО КОРИСТУВАЧА
Б.1 Загальні відомості
Розроблена БД призначена для надання користувачу всієї необхідної інформації для автоматизації продуктивної діяльності промислового підприємства.
Дана БД має зручний графічний інтерфейс. При запуску програми, з'являється головне меню, що містить всі пункти, необхідні для роботи з додатком. При необхідності додати, переглянути або змінити інформацію потрібно вибрати допомогою клавіш управління курсором або <Tab> необхідну кнопку з назвою форми, і натиснути <Enter> або відкрити форму кліком миші.
Для запуску програми потрібно запустити файл «Записна книжка керівника. Mdb» в СУБД MS Access.
Б.2 Введення, видалення, додавання і редагування даних
Введення даних здійснюється у формах за допомогою клавіатури. Для введення даних необхідно виділити покажчиком миші необхідне поле або перейти на нього за допомогою клавіш управління курсором або <Tab>, і ввести дані. Аналогічним чином здійснюється редагування даних.
Додавання даних здійснюється у формах так само, як і у всіх БД.
На видалення записів користувачі «Гість» не мають права. Видаляти записи з таблиць або форм можуть тільки користувачі «Adminstrator» та «Керівник», використовуючи відповідні клавіші в формах.
Б.3 Перегляд звітів
Для перегляду звітів необхідно натиснути відповідні кнопки на головній формі.
Б.4 Використання довідкової інформації і вихід з програми
Довідкова інформація в БД. У цілому для здійснення необхідних дій потрібно читати написи на кнопках або поруч з ними і натискати на ці кнопки.
Додаток В
Лістинг ПРОГРАМНИХ МОДУЛІВ
Private Sub Кнопка2_ Click ()
On Error GoTo Err_ Кнопка 2_Click
Dim stDocName As String
Dim stLinkCriteria As String
Dim a As Long
stDocName = ChrW (1075) & ChrW (1083) & ChrW (1072) & ChrW (1074) & ChrW (1085) & ChrW (1072) & ChrW (1103)
If Список 0.Value = "Адміністратор" Then
If Поле 4.Value = "admin" Then
DoCmd.Close
DoCmd.OpenForm stDocName,,, stLinkCriteria
Form _Главная.Надпісь27. Caption = "Адміністратор"
DoCmd. RunCommand acCmdWindowUnhide
Else: a = MsgBox ("Введено невірний пароль")
End If
Else
If Список 0.Value = "Керівник" Then
If Поле 4.Value = "ruk" Then
DoCmd.Close
DoCmd.OpenForm stDocName,,, stLinkCriteria
Form_ Головна. Напис 27.Caption = "Керівник"
Else: a = MsgBox ("Введено невірний пароль")
End If
Else
If Список 0.Value = "Гість" Then
DoCmd.Close
DoCmd.OpenForm stDocName,,, stLinkCriteria
Form_ Головна. Напис 27 = "Гість"
Form_ Головна. Кнопка 5.Enabled = False
End If
End If
End If