Автоматизация приложении в среде Access

Курсовая работа

 

Тема:  Автоматизация приложении в среде  Access

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение.

 

Microsoft Access в настоящее  время является одной из самых  популярных среди настольных (персональных) программных систем управления базами данных Среди причин такой популярности следует отметить: 
- высокую степень универсальности и продуманности интерфейса визуального программирования, который рассчитан на работу с пользователями самой различной квалификации. В частности, реализована система управления объектами базы данных, позволяющая гибко и оперативно переходить из режима конструирования в режим их непосредственной эксплуатации; 
- глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав Microsoft Office, а также с любыми программными продуктами, поддерживающими технологию OLE; 
- богатый набор визуальных средств разработки. 
Нельзя не отметить, что существенной причиной такого широкого распространения MS Access является и мощная рекламная поддержка, осуществляемая фирмой Microsoft. В процессе разработки данного продукта на рынок представлялись его различные версии. Наиболее известными (в некотором смысле этапными) стали Access 2.0, Access 7.0 (он впервые был включен в состав программного комплекса MS Office 95). Позже появились версии Access 97 (в составе MS Office 97 и Access 2000 (в составе MS Office 2000). Самой свежей версией является MS Access 2010, входящая в комплект MS Office.

 

Задачей для автоматизации приложении в среде  Access используем в качестве примера разработку приложении библиотеки Международного Института XXI века, позволяющего автоматизировать работу библиотекаря.

 

Требования к приложению:

- работа в среде Microsoft

 

Описание приложения:

Библиотека работает на основе устава. Основные положения  устава:

1. Список пользователей формирует методический отдел или отдел кадров
1. 01\09 в библиотеку подается список пользователей на текущий учебный год.
2. Если нет новых или убывших пользователей, список не подается
3. При отчислении студента или уходе преподавателя, лицо удаляется из приложения библиотеки после подписания приказа или обходного листа
2. Библиотекарь заносит полную информацию о книге имеющейся в наличие в минимальном количестве одна штука. Информация о книге находится на титульном листе книги. При поступлении следующей партии этой же книги формируются только личные номера книг, привязанные к введенному ISBN номеру.
3. Текущая работа библиотекаря по приему и выдачи книг.
4. В конце года библиотекарь, к установленной методическим отделам дате, формирует список должников, пользователей, не сдавших всех книг к заданной дате. Список печатается и за печатью и подписью подается в методический отдел для принятия административных мер.  

 

Личным номером, тут  и далее, называется номер, вписанный  библиотекарем на каждой книге.

 

Функции приложения:

1. регистрация новых книг
1. регистрация данных о книге
2. регистрация всей партии этой книги (присвоение личных номеров    каждой книге)
2. регистрация пользователей библиотекой (список из методического отдела)
3. выдача \ принятие зарегистрированных книг (текущая работа библиотекаря)
4. создание отчетов

 

План разработки приложения:

1. утвердить количество и сущность таблиц
2. определить ключевые поля таблиц
3. разработать интерфейсы ввода \ вывода данных
4. разработать запросы, требуемые заказчиком
5. разработать Администраторскую часть приложения
6. максимально уменьшить возможность ошибок пользователем
7. отладка приложения
8. обработка ошибок приложения

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Автоматизация приложения в среде Microsoft Access

 

Как нетрудно догадаться, процесс разработки конкретного  программного приложения в среде Access в первую очередь определяется спецификой автоматизируемой предметной области. Однако для большинства из них можно выделить ряд типичных этапов. Это:

- разработка и описание  структур таблиц данных;

- разработка схемы  данных и задание системы взаимосвязей  между таблицам 
- разработка системы запросов к таблицам базы данных и (при необходимости их интеграция в схему данных;

- разработка экранных  форм ввода/вывода данных;

- разработка системы  отчетов по данным;

- разработка программных  расширений для базы данных, решающих  специфические задачи по обработке  содержащейся в ней информации, с помощью иструментария макросов и модулей;

- разработка системы  защиты данных, прав и ограничений  по доступу.

Очевидно, что между  перечисленными этапами существует большое количеств обратных связей, подразумевающих возврат к более  ранним шагам, исходя из вновь открывшихся обстоятельств, которые невозможно было заранее учесть ил предвидеть.

 

Итак, для решения задачи рассмотрим: суть и структуру приложения, разработку таблиц, ключей и связей также разработку Форм.

 

 

1.1. Суть и структура приложения

 

Основа решения задачи состоит в том, чтобы правильно, без ошибок организовать приложение. Работа с базами данных, на мой взгляд, делится на два основных этапа. Первый это проектирование структуры и возможностей приложения, утверждение таблиц, ключей и связей между таблицами которые обеспечат целостность данных. Если начать работу по обработке данных при наличии неточностей в структуре данных то мы столкнемся первое повторение данных в разных таблицах и второе будет не просто сортировать, фильтровать данные. Появиться больше возможностей для ошибок. Вторая часть это разработка ввода и представления информации и обработка данных. Основная часть это определиться с организацией хранения данных. Требуется четко сформулировать и формализовать задачу.

  

Для решения поставленной задачи, необходимо создать пять таблиц. Мы создадим две основных таблицы, хранящих статичные данные о пользователях и о книгах. Так как эта информация не пересекается, таблицы не будут связаны друг с другом напрямую. Так же нам понадобиться таблица для объединения этих данных. В этой таблице будут храниться данные о книгах, которые взял пользователь (таблица BooksOfUsers). 

 

Так будут связанные таблицы, образующее целостность данных.

 

 

 

Второй этап это разработка интерфейсов ввода-вывода, фильтров, запросов, отчетов. Обработка данных также очень важная часть работы, но она напрямую зависит от организации хранения данных. Вполне возможно, и как покажет время, так и будет, придется, организовывая структуру хранения данных учитывать и их обработку. Это может выражаться в возникновении необходимостей создавать новые таблицы или добавлять поля в уже созданных таблицах. Как правило, это не осложняет работы и является вполне штатной ситуацией.

После добавления таблиц или полей следует записать изменения  в рабочий журнал, что бы потом не забыть добавить новые формы или поля, если это понадобиться. Также обязательно следует протестировать работу приложения после серьезных структурных изменений. Для этих целей стоит заранее продумать и приготовить тестовые данные и задачи. Держать их следует как в бумажном, так и в электронном виде.

 

 

 

 

 

 

 

 

1.2. Разработка таблиц, ключей и связей 

 

Таблицы приложения:

 

1. Users – данные о пользователях
2. Books – данные о книгах
3. BooksOfUsers – инвентарные номера книг записанных на пользователей
4. InventNumbers – инвентарные номера книг зарегистрированных в библиотеке, вспомогательная таблица для таблицы Books.
5. ServInventNumbers – вспомогательная таблица для выдачи книг

 

Надо отметить, что  не всегда сразу ясно как организовать хранение данных, какие поля в какой таблице создать. На первый взгляд кажется одно, а при непосредственной работе сталкиваешься с непредвиденными сложностями. Так, например мне далеко не сразу было ясно, что понадобиться создавать вспомогательные таблицы. Исходя из поставленной задачи, нам нужно хранить три категории данных. Две статичные и одну динамичную категорию.

Так же очень важный момент, правильно задать ключи таблиц. Ключ таблицы это такое поле, которое встречается только один раз, и по нему можно однозначно найти всю запись, и все что с ней связано в данной таблице.

Непосредственно для  хранения данных необходимо четыре таблицы:

Users будет хранить всю информацию об абонентах. Информация приходит из методического отдела, поэтому проверять ее нет необходимости. Ключом этой таблице целесообразно назначить автоматический счетчик. Таблица Books будет хранить информацию о книгах, информация поступает вместе с партией книг и содержится в сопроводительной документации и на самой книге. Каждой книге министерство печати присваивает идентификационный номер ISBN. По данному номеру можно однозначно идентифицировать книгу, поэтому целесообразно назначить его ключом в этой таблице. Таблица InventNumbers будет содержать личные номера книг поступивших в библиотеку. Личные номера книг повторяться не могут, поэтому это поле будет назначено ключевым в таблице InventNumbers. Таблица BooksOfUsers хранит порядковые номера читателей и личные номера книг, которые они взяли. Как уже было сказано, личные номера книг не могут повторяться, поэтому это поле также будет ключевым в этой таблице.

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

 

 Связанные таблицы приложения. Выделенные поля в таблицах это ключевые поля.

 

 

 

 

 

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

 

  Интерфейсы ввода-вывода служат для ввода-вывода информации. От них требуется наглядность, и визуальность.

 

Нам потребуется две  основных формы ввода-вывода. Первая для кыниг. Она должна содержать текстовые поля ввода для ввода информации о книге и переход на второй уровень заполнения, присвоение личных номеров книгам. Личные номера должен генерировать компьютер по входным данным. Входные данные это, в нашем случае, два параметра количество новых книг и ISBN которому они будут принадлежать. Вводить ISBN второй раз с клавиатуры нецелесообразно поэтому, применяя методы VBA, перенесем его из таблицы первого уровня и запретим его изменение в окне формы второго уровня. Таким образом, нам останется ввести только количество книг поступивших в данной партии.

 

 

Обратите внимание, что мы стараемся ограничить работу пользователя и максимально автоматизировать процесс работы. Это преследует две основных цели, первая оптимизация работы и вторая минимизация ошибок связанная с человеческим фактором.

1.3. Разработка Форм

 

Организуем форму пользователей, форму книг. Автоматически, по количеству новых книг, генерируем личные номера книг и храним их в отдельной таблице. Эти таблицы и формы позволяют хранить и вводить все необходимые для работы данные, и минимизируют возможность ошибок и повторения записей.

 

 

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

Получается, что необходима одна таблица, в которой будет  два поля: порядковый номер пользователя и личный номер книги которую он взял. В этой таблице ключевым полем будет личный номер книги, так как он уникальный, а порядковый номер пользователя может повторяться большое количество раз, так как один пользователь будет брать несколько книг. Эта таблица BooksOfUsers.

 

Создав все эти таблицы, мы обеспечили полное хранение данных, тем самым закончили самую важную часть в разработки приложения, создали костяк.

 

Следующий этап это разработка интерфейсов ввода данных. Вполне логично, что их должно быть столько же, сколько и таблиц, но это не обязательно так. Есть несколько моментов, которые стоит учесть. Часть данных мы вынуждены вводить в ручную, но часть данных может генерировать компьютер. Например, данные о новой книге или пользователе компьютер сгенерировать не может, а вот личные номера книг может.

 

Очень важно, точно оговорить  заранее все условия и требования заказчика. Если посреди разработки приложения будет выяснена не точность, это может дорого стоить. Одна такая неточность была у меня в процессе разработки. Это было связано с ключевым полем таблицы Books, полем ISBN. В начале было обусловлено, что у книги есть уникальный номер и это номер УДК. Просмотрев несколько десятков различных книг, я пришел к выводу, что для хранения этого номера мне хватит длинных целых чисел. Номера были небольшие, что насторожило меня, так как книг выходит миллионы каждый год, если не месяц, а их уникальные номера маловаты. Наш договор не фиксировался на бумаге, что тоже повлияло на последовавшую далее неразбериху. В конечном итоге, когда приложение было почти завершено, я узнал что уникальный номер книги не УДК, а ISBN и тип его данных текст, так как там может встретиться значок или буква. По этой причине пришлось переделать весь проект. Но это было ценным урокам.