Зміст
1 Введення
2 Організаційно-технологічна частина
2.1 Призначення і функціонування інформаційної системи (АС)
2.2 Середовище розробки: MS Access
2.2.1 Особливості розробки АІС в середовищі Access з написанням моделей VBA
2.2.2 Структура програми VBA
2.2.3 Код програми на Visual Basic for Application (VBA)
3 Розрахунково-конструкторська частина
3.1 Опис вихідних даних для проектування системи
3.2 Розробка контекстної діаграми
3.3 Розробка програмної системи
3.3.2Технологія проектування баз даних
3.3.3 Визначення сутностей
3.3.4 Визначення взаємозв'язків між сутностями і обліковою інформацією
3.3.5 Завдання первинних і альтернативних ключів, визначення атрибутів сутностей
3.3.6 Приведення моделі до необхідного рівня нормальної форми
3.3.7 Опис фізичної моделі
3.3.8 Розробка інтерфейсу користувача
3.4 Алгоритм роботи інформаційної системи
3.5 Інструкція користувача
3.5.1 Призначення інформаційної системи
3.5.2 Умови виконання програми. Системні вимоги
3.5.3 Виконання програми
4 Економічна частина. Техніко-економічне обгрунтування вартості створення інформаційної системи
4.1 Складання відомості автоматизованих інформаційних послуг (АІУ)
4.2 Розрахунок собівартості автоматизованих інформаційних послуг
4.3 Розрахунок обсягів АІУ за договірними цінами
4.4 Розрахунок показників по праці та заробітної плати
4.5 Показники фінансового плану
4.6 Розрахунок податків
4.7 Складання бізнес - плану
4.8 Розрахунок логістики підприємства
5 Техніка безпеки
5.1 Забезпечення техніки безпеки і охорона праці оператора ЕОМ
5.2 Шкідливі чинники під час роботи з ЕОМ
5.3 Ергономічні вимоги до робочого місця
6 Висновок
7 Література
Додаток А Головна форма
Додаток Б Код програми на Visual Basic for Application (VBA)
1 Введення
Темою мого диплома є автоматизація діяльності бібліотеки Вузу. Розроблена автоматизована інформаційна система створена для більш ефективного та швидкого обслуговування користувачів бібліотеки вузу.
Дана інформаційна система призначена для двох типів користувачів як обслуговуючого персоналу так і для самих читачів. Розроблена система дозволяє скоротити час пошуку та оформлення видачі необхідної видання читачеві, а так само надає автоматизований пошук книги самому читачеві.
Ця система розроблена в СУБД Microsoft Access 2000, т. к. Access є програмним засобом, призначеним для створення структури нової бази, наповнення її вмістом, редагування вмісту та відбору даних відповідно до заданого критерію, їх упорядкування, оформлення і подальшої видачі їх на пристрої висновку або передачі по каналах зв'язку. При розробці інформаційної системи був використаний вбудований мова програмування Visual Basic for Application (VBA), який дозволяє створити інтегровану систему.
В економічній частині дипломного проекту наведено розрахунок техніко-економічного вигоди впровадження даної інформаційної технології АІС бібліотеки вузу.
У розділі «Техніка безпеки» передбачені заходи допустимих норм для співробітника, що працює з комп'ютером.
2 Організаційно-технологічна частина
2.1 Призначення і функціонування програмного продукту «Бібліотека ВНЗ»
2.2 Середовище розробки: СУБД Microsoft Access
Система управління базами даних (СКБД) - це комплекс програмних засобів, призначених для створення структури нової бази, наповнення її вмістом, редагування вмісту, відбір відображуваних даних відповідно до заданого критерію, їхнє упорядкування, оформлення і наступна видача на пристрої виводу або передачі по каналах зв'язку.
Дана інформаційна система розроблялася c допомогою бази даних Microsoft Access 2002. Access входить в набір інструментальних програмних засобів, є настільною СУБД, легка у використанні навіть для неспеціалістів в програмуванні, саме тому ми вибрали саме цю середовище для розробки нашої інформаційної системи.
MS Access є однією з популярних систем проектування та супроводження бази даних, вона являє собою повнофункціональну СУБД, в яку входять таблиці даних, екранні форми для введення даних в ці таблиці, запити і звіти для отримання нової інформації по даних з таблиць, макроси і модулі для додаткового програмування.
Завдяки тому, що таблиці, форми, запити, звіти, модулі та макроси є самостійними об'єктами, вони при цьому зберігаються разом в єдиному файлі бази даних (файл має розширення. Mdb), створення зв'язаних за змістом даних і перевірка обмежень цілісності, а також створення і модифікація таблиць, форм, запитів, звітів, модулів і макросів значно полегшується.
Система управління базами даних MS Access підтримує реляційну модель даних з механізмом посилальної цілісності. Тому в базах даних СУБД MS Access дані представляються у вигляді таблиць і функціональних бінарних зв'язків між таблицями. Додатковий засіб представлення даних - запити. Запит є віртуальну таблицю, яка формується на вимогу на основі заздалегідь складеного опису запиту за даними з фізичних таблиць бази даних. Ніяких інших відмінностей між фізичними таблицями і запитами немає. У всіх операціях вони беруть участь на рівних правах. Основне призначення запитів - вистава для виведення додаткової інформації, а також приховування від користувачів складних запитів: користувач звертається до системи з простим запитом до віртуальних даними, а всю роботу по їх формуванню (за заздалегідь складеним складного запиту) бере на себе СУБД.
Механізм посилальної цілісності в даний час є загальновизнаним для використання в реляційних моделях для реалізації функціональних бінарних зв'язків типу 1:1 або 1: М між зв'язаними таблицями. Він відповідає бінарному групового відношенню при визначенні бази даних в термінах груп і групових відносин. Цей механізм заснований на методі подання бінарної зв'язку між сутностями через атрибут: первинний атрибут схеми вихідної (батьківської) сутності включається як вторинний атрибут у схеми атрибутів підпорядкованої (дочірньої) сутності.
У системі управління базами даних MS Access в рамках таблиць діють механізми визначення та організації контролю стандартних правил цілісності даних у реляційних моделях. Між таблицями діє механізм опису і контролю обмежень посилальної цілісності для бінарних функціональних зв'язків. У таблицях діють також механізми визначення та організації контролю явних обмежень цілісності даних, таких, як формати даних, допустимі діапазони значень даних при введенні.
Таким чином, сутності в базі моделюють таблицями. Властивості об'єктів (атрибути) моделюють полями (стовпчиками таблиць). Один з атрибутів суті повинен бути ідентифікатором - первинним ключем (наприклад, код інструменту). Зв'язки між сутностями можна моделювати двояко: або таблицею, або з атрибутом (посилальна цілісність). При цьому обидві таблиці, між якими повинна бути створена зв'язок, повинні мати один і той же атрибут, який цей зв'язок і реалізує.
Тільки в одній з таблиць (батьківської) він буде ідентифікує атрибутом - первинним ключем, а в іншій (підпорядкованої) - звичайним атрибутом (у цьому випадку його називають вторинним ключем). І в обох таблицях він повинен мати один і той же тип даних (ім'я може бути різним).
Для представлення бінарних зв'язків типу М: М можна використовувати або таблицю, або дві функціональні зв'язку: 1: M і M: 1 з проміжною таблицею (прийом описаний нижче в мережевій моделі).
Схему бази даних для СУБД MS Access проектують з урахуванням перерахованих особливостей, тобто реалізують етап відображення схеми инфологической моделі в схему датологіческой моделі програмного забезпечення.
У вікні бази даних Access 2000 з'явилися нові засоби перегляду і маніпулювання об'єктами бази даних:
панель інструментів дозволяє швидко виконувати команди створення, відкриття та управління об'єктами бази даних;
смуга об'єктів призначена для перегляду об'єктів бази даних. Її вертикальне розташування більш зручне у використанні;
нові ярлики у вікні бази даних прискорюють створення об'єктів за допомогою майстрів або відкриття нових об'єктів у режимі конструктора;
налаштування способів вибору і відкриття об'єктів у вікні бази даних. При необхідності можна змінити режим, встановлений за умовчанням, так що вибір об'єкта відбувається при зупинці покажчика на ньому, а відкриття після клацання;
вибір об'єкта шляхом введення його імені.
До нових можливостей, що полегшує роботу з даними та проектування бази даних відносяться наступні:
підтримується блокування на рівні записів на додаток до звичайної блокування, яка блокувала всі записи на 4-Кбайтних сторінці.
можна вільно переміщатися між діалоговими вікнами пошуку, заміни та роботи з даними;
автоматичне виявлення помилок перейменування дозволяє коригувати загальні помилки, викликані переміщенням форм, звітів, таблиць, запитів, полів, текстових боксів та інших елементів управління;
підтримка світової 16 розрядного стандарту кодування символів Unicode;
підтримка роботи з даними у форматі валюти євро. Щоб побачити на екрані значення величини в форматі євро-валюти, можна використовувати установку (#,###.##) властивості Формат.
можливість роздруківки звіту про взаємозв'язки таблиць бази даних, які представляються користувачеві для перегляду у вікні Зв'язки;
використання Microsoft ActivX Object (ADO) для доступу і маніпулювання даними в базах даних сервера.
2.2.1 Особливості розробки АІС в середовищі Access з написанням моделей VBA
При розробці системи в середовищі Access використовувався мова програмування VBA.
VBA (Visual Basic for Application) - це мова програмування, підтримуваний всіма додатками пакета Microsoft Office. VBA - відносно нескладний мова програмування, який дуже простий і зручний в освоєнні і дозволяє швидко отримати відчутні результати - конструювати професійні програми для вирішення практично будь-яких завдань у середовищі Microsoft Windows. Можна сказати, що мова VBA є прямим спадкоємцем мови програмування Basic, але, тим не менше, в порівнянні з ним він зробив крок далеко вперед. Тому і можливостей, як внутрішніх (наприклад, в частині виведення на екран всіляких форм), так і щодо взаємодії з іншими додатками, у нього набагато більше.
Слід зауважити, що, будучи розвиненим мовою програмування, VBA також включає в себе повноцінну інтегроване середовище розробки з повним набором спеціалізованих вікон, що спрощують проектування, налагодження і тестування програм. Інтегроване середовище розробки VBA представлена додатком, званим редактором Visual Basic. Цей редактор має типове для додатків Windows вікно з панеллю меню і цілим набором панелей інструментів, які дозволяють отримати доступ до цілого ряду вікон, що надають інструментальні засоби, необхідні для створення програм. Крім того, редактор VBA включає спеціалізовані засоби для швидкого створення призначеного для користувача інтерфейсу, що перетворює його у візуальну середовище розробки додатків.
2.2.2 Код програми на Visual Basic for Application (VBA)
Код програми на Visual Basic for Application (VBA) представлений в додатку Б.
3 Розрахунково-конструкторська частина
У процесі розробки програмного продукту важливу роль відіграє проектування програми.
Розробку програми необхідно почати з аналізу предметної області та постановки завдання.
Щоб добре спроектувати систему, необхідно чітко уявляти собі вирішуване завдання. Для цього, в першу чергу, потрібно скласти набір вимог, який пред'являється до кінцевого продукту. Набір вимог складається виходячи з того, що хоче замовник, і що йому насправді потрібно.
Це не завжди одне і те ж. І мистецтво розробника полягає в тому, щоб представити замовнику те, що йому потрібно, а замовнику при цьому здавалося, що це якраз те, що він хоче.
Щоб сформулювати реальні вимоги до системи, необхідно якомога більше інформації про предметну область.
Дана інформаційна система "Приймальна комісія" призначена для приймальної комісії Челябінського монтажного коледжу, тому набір вимог до неї я склала, виходячи з вимог замовника.
3.1 Опис вихідних даних для проектування системи
Розглянемо визначення вимог інформаційної системи «Бібліотеки ВНЗ». Дана система призначена для абстрактного замовника, тому набір вимог до неї складається, виходячи з власного уявлення про завдання автоматизації роботи бібліотеки вузу.
Сформулюємо вимоги до нашого проекту.
ІС Бібліотеки вузу призначена для введення, зберігання і обробки інформації про друковані видання, що надходять до бібліотеки, читачів, які відвідують бібліотеку.
Інформація про читачів повинна включати особисті дані і дані про друковані видання, які він бере на абонемент або в читальний зал.
ІС «бібліотеки вузу» повинна забезпечити виконання наступних дій:
Прийом нових читачів;
Прийом новий друкованих видань;
Облік своєчасний здачі та відстеження заборжників;
4) ІС «Бібліотеки ВНЗ» повинна підтримувати обслуговування різні категорії читачів, які мають специфічні характеристиками:
Студенти вузу;
Разові читачі (абітурієнти, стажисти);
Викладачі;
Інші працівники ВНЗ;
Один і той же читач може брати книги, як на абонементі, так і в читальному залі, якщо він не числиться в боржниках.
5) ІС «Бібліотеки ВНЗ» повинна відстежувати читачів, які порушують правила користування бібліотекою - заборжників.
Створення графа відповідно до вимог до системи
Система буде вирішувати наступні функції:
1. Формування каталогу книжок.
1.1 Введення даних про надійшла літературі.
1.2 Перегляд звітів по запитах.
2. Складання картки читача.
2.1. Запис нового читача.
2.1.1 Введення книг видаються читачеві.
2.2. Отримання звітів картки читача і виданих йому книгах.
3. Введення даних про читачів боржниками.
3.1 Введення даних.
3.2 Отримання звітів про поточні боржниками.
4. Пошук книги.
4.1 Вибір критерію пошуку.
4.1.1 Отримання звітів про результат пошуку.
5. Вихід з програми.
6. Довідка.
Подання графа сценарію завдання представлено на малюнку 1.
Рис.1 Граф сценарію завдання «Бібліотека вищого навчального закладу»
3.2 Розробка контекстної діаграми
Контекстної діаграма дозволяє наочно уявити бізнес-процеси, що протікають в даній інформаційній системі, документообіг та інформаційні масиви При побудові даної діаграми використовується принцип ієрархічного упорядкування - принцип організації складових частин системи. Побудова ієрархії діаграм починається з побудови системи у вигляді найпростішого компонента - одного блоку і дуг. Дуги - це функції даної системи (вхідні і вихідні дані, механізм роботи системи і інформація). Отримана модель може служити основою для створення програмно-інформаційної системи.
Контекстна діаграма показана на малюнку 2.
Рисунок 2 - Контекстна діаграма
3.3 Розробка програмної системи
3.3.1 Опис системи з використанням мови моделювання UML
Приступимо до створення моделі програми «Бібліотеки ВНЗ». На основі описаних вимог і обмежень виділимо класи користувачів системи, визначимо вимоги до них і дамо опис системи з точки зору користувача. У системі позначень UML таким описом є подання використання (Use-Case View). Це подання може складатися з декількох діаграм використання (Use-Case Diagram), які описують окремі частини системи і систему в цілому. Спочатку складемо діаграму використання, що описує систему в цілому
Опис системи з даної мови моделювання представлено на малюнках 3,4.
Рисунок 4 - Представлення роботи системи в цілому
Рисунок 4 - Представлення роботи системи в цілому
3.3.2Технологія проектування баз даних
База даних - спеціальним чином організована сукупність даних великого обсягу та складної структури, побудована з урахуванням принципів інтеграції, що забезпечує одноразовий введення даних та їх багатоаспектне використання.
В основу проектування бази даних повинні бути покладені уявлення кінцевих користувачів конкретної організації - концептуальні вимоги до системи. Від оперативності і якості інформації буде залежати ефективність роботи організації.
При розгляді вимог кінцевих користувачів необхідно брати до уваги наступне:
База даних повинна задовольняти актуальним інформаційним потребам організації. Отримана інформація повинна за структурою і змістом відповідати важливість справ.
База даних повинна забезпечувати одержання необхідних даних за прийнятний час, тобто відповідати заданим вимогам продуктивності.
База даних повинна задовольняти виявленим і знову виникаючим вимогам кінцевих користувачів.
База даних повинна легко розширюватися при реорганізації і розширенні предметної області.
База даних повинна легко змінюватися при зміні програмної та апаратної середовища.
Завантажені в базу даних коректні дані повинні залишатися коректними.
Дані до включення в базу даних повинні перевірятися на достовірність методом верифікації.
Доступ до даних, розміщених у базі даних, повинні мати тільки особи з відповідними повноваженнями.
Етапи проектування бази даних з урахуванням розглянутих вище аспектів представлені на рисунку 5.
Малюнок 5 - Проектування бази даних
3.3.3 Визначення сутностей
Сутність (об'єкт) - в реляційній теорії баз даних елемент інформаційної системи, інформація про який зберігається. об'єкт можемо бути реальним і абстрактним. Кожен об'єкт має певним набором властивостей, які запам'ятовуються в інформаційній системі.
При проектуванні бази даних книжкового магазину можна виділити наступні сутності:
ЧИТАЧ;
ДРУКАРСЬКЕ ВИДАННЯ;
ВИДАЧА;
КАТАЛОГ;
ЧИТАЧ-боржниками;
3.3.4 Визначення взаємозв'язків між сутностями та створення моделі даних
На підставі вищевикладеного визначаємо об'єкти моделі даних і зв'язку між ними. Виділяємо довідкову інформацію та облікову інформацію. До довідників відносяться: каталог книг, читачі, розділ, типи читачів. До таблиць облікової інформації відносяться: видача книг, боржниками
Далі помістимо схему сутностей і зв'язків між ними, виконану в ERWIN і подану на малюнку 4. Дана технологія призводить всі відносини між сутностями інформаційної системи до третьої нормальній формі.
Визначимо для перерахованих вище сутностей взаємозв'язку.
Отримана після цього інформаційна модель представлена на рисунку 6.
Малюнок 6 - Інформаційна модель на другому етапі
Усі зв'язки між об'єктами (рисунок 6) є зв'язками «один до багатьох», тобто одного запису даних першого об'єкта (основного) відповідає кілька записів другого об'єкта (підлеглого).
3.3.5 Завдання первинних і альтернативних ключів, визначення атрибутів сутностей
Атрибут - це інформаційне відображення властивостей об'єктів. Кожен об'єкт характеризується низкою основних атрибутів. Кожен атрибут у моделі повинен мати унікальне ім'я - ідентифікатор. Атрибут при реалізації інформаційної моделі на будь-якому носії інформації часто називають елементом даних, полем даних або просто полем.
Ключовим елементом даних називається такий елемент, за яким можна визначити значення інших елементів даних.
Первинний ключ - це атрибут (або група атрибутів), які єдиним чином ідентифікують кожну рядок у таблиці.
Альтернативний ключ - це атрибут (або група атрибутів), неспівпадаючий з первинним ключем і унікально ідентифікує екземпляр об'єкта.
Атрибути і первинні ключі сутностей для інформаційної моделі, що включаються до складу бази даних «Приймальна комісія», наведені в таблиці 1.
Таблиця 1 - Первинні, альтернативні ключі і атрибути
Сутність | Первинний ключ | Атрибути |
1 | 2 | 3 |
Каталог_кніг | Реєстраційний _ № | Реєстраційний _ № Автор Назва Год_ізданія Дата_регістраціі Дата_спісанія Розділ Абонемент1 Абонемент2 Чітальний_зал Кількість Видавництво |
Читачі | № читацького квитка | № читацького квитка ПІБ Ознака (код) Адреса Паспортні дані Дата_запісі Дата_вибитія Група Факультет Кафедра Степень_званіе Право користування |
Видача_кніг | реєстраційний № № читацького квитка АбонементА1 АбонементА2 Чітальний_зал Кількість Дата_видачі Дата_возврата Фактіческая_дата_возвра Кол_сдал | |
Боржниками | Код | Код реєстраційний № № читацького квитка кількість |
Тіпи_чітателей | Код_чітателя | Код_чітателя Тіп_чітателя |
Розділ | Код_раздела | Код_раздела Розділ |
3.3.6 Приведення моделі до необхідного рівня нормальної форми
Теорія нормалізації заснована на тому, що певний набір таблиць має кращі властивості при включенні, модифікації і видалення даних, ніж всі інші набори таблиць, за допомогою яких можуть бути представлені ті ж дані. Введення нормалізації відносин при розробці інформаційної моделі забезпечує мінімальний обсяг фізичної пам'яті, що прямо відображається на якості функціонування інформаційної системи. Нормалізація інформаційної моделі виконується в кілька етапів:
Дані, представлені у вигляді плоскої двовимірної таблиці, є першою нормальною формою реляційної моделі даних. Перший етап нормалізації полягає в утворенні двовимірної таблиці, що містить всі необхідні атрибути інформаційної моделі, в усуненні складових (складних) атрибутів і у виділенні ключових атрибутів. Перший етап нормалізації моделі системи представлений вище в таблиці 1.
Відношення призначено в другій нормальній формі, якщо вона є ставленням в першій нормальній формі і кожен атрибут, який не є первинним атрибутом в цьому відношенні, повністю залежить від будь-якого можливого ключа цього відношення. Приведення відносин до другої нормальної форми полягає в забезпеченні повної функціональної залежності всіх атрибутів від ключа за рахунок розбиття таблиці на декілька таблиць, в яких всі наявні атрибути мають повну функціональну залежність від ключа цієї таблиці. У процесі приведення моделі до другої нормальної форми в основному виключаються аномалії дублювання даних, а також аномалії включення і видалення даних. Другий етап нормалізації також можна спостерігати у таблиці 1.
Відношення призначено в третій нормальній формі, якщо воно задане в другій нормальній формі і кожен атрибут цього відношення, не є первинним, нетранзитивно залежить від кожного можливого ключа цього відношення. Третій етап нормалізації полягає в усуненні аномалій включення і видалення даних. Її видно з таблиці 1 і на малюнку 7.
У загальному випадку при проектуванні бази даних необхідно дотримуватися таких правил:
Виключати повторювані групи - для кожного набору пов'язаних атрибутів створювати окрему таблицю і постачати її первинним ключем. Виконання цього правила автоматично призводить до першої нормальної форми.
Виключати надлишкові дані - якщо атрибут залежить тільки від частини складеного ключа, переміщати атрибут в окрему таблицю. Скрізь, де можливе використання ідентифікаторів замість опису, треба виносити в окрему таблицю список ідентифікаторів з поясненнями до них. Виконання цього правила призводить до другої і третьої нормальним формам.
Був зроблений аналіз фізичної і логічної моделі, в ERWin 4.0, який показав відсутність у таблицях аномалій. Схема даних, спроектована в ERWin 4.0 представлена на рисунку 8.
3.3.7 Опис фізичної моделі
Видача книг | ||||
Найменування поля | Тип даних | Розмір | Примітка | |
1 | 2 | 3 | 4 | 5 |
1 | реєстраційний № | Числовий | Довге ціле | № книги при реєстрації |
2 | № читацького квитка | Числовий | Довге ціле | |
3 | Абонемент | Логічний | ||