Разработка АРМ сотрудника библиотеки (на примере АЧОУ ВПО МФЮА УК Красноармейский)

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

 

1.3 Обоснование целесообразности создания АРМ сотрудника библиотеки АЧОУ ВПО МФЮА УК Красноармейский

 

В библиотеке АЧОУ ВПО МФЮА УК Красноармейский ведется учет книг, выдаваемых студентам в начале учебного года в виде комплектов. Каждой группе, в зависимости от специальности, полагается свой комплект книг, в который входят определенные издания по специальности.

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

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

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

Необходимость автоматизации работы библиотекаря объясняется следующими факторами:

• снижением трудоемкости работы сотрудника библиотеки;
• сокращением времени на заполнение и обработку документов;
• сокращением текущих материальных затрат (т.е. печать карточек учета читателей, приобретение ручек, карандашей, бумаги, скрепок и пр.);
• снижением ошибок ввода, т.е. повышением качества и оперативности документооборота.

Анализ предметной области позволяет выделить следующие функции, которые необходимо автоматизировать:

• ввод, редактирование и удаление данных о книгах;
• ввод, редактирование и удаление данных о читателях;
• учет выдачи книг читателю;
• учет возврата книг читателем;
• формирование комплектов учебной литературы;
• поиск необходимой книги по ее названию или ФИО автора;
• формирование и печать списка должников.

 

 

2. Методологические средства и  технологии проектирования баз данных

 

Процесс разработки структуры базы данных в соответствии с требованиями пользователей называется проектированием базы данных.

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

Жизненный цикл

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

Фаза проектирования состоит из следующих этапов:4

• разработка стратегии,
• системный анализ,
• концептуальное моделирование,
• логическое и физическое проектирование.

Фаза реализации включает следующие этапы:

• реализация,
• документирование,
• опытное внедрение,
• промышленная эксплуатация.

 

Методология проектирования баз данных

Метод – это упорядоченная логическая процедура для выполнения определенной задачи.

Методология – система методов, применяемых в научных исследованиях для обоснования результатов.

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

К методологии проектирования баз данных предъявляются следующие требования:

• Она должна приводить к созданию приемлемой структуры баз данных в разумные сроки и при разумных затратах. Приемлемой считается такая база данных, которая соответствует требования пользователей (эффективность, адаптивность, независимость, защищенность, целостность и т.д), удовлетворяет системным ограничениям (требования к аппаратному обеспечению).
• Она должна быть достаточно общей и гибкой, доступной разработчикам с различным опытом проектирования, использующим различные модели данных и программное обеспечение СУБД.

Методология проектирования баз данных включает следующие основные компоненты:

• Процесс проектирования, состоящий из последовательности фаз и этапов, на каждом из которых необходимо принимать альтернативные решения.
• Методики выполнения требуемых в процессе проектирования расчетов и критерии оценки альтернативных решений на каждом этапе.
• Информационные требования в качестве исходных данных для процесса проектирования, как в целом, так и на каждом этапе.
• Средства описания исходных данных и представления результатов каждого этапа проектирования.

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

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

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

Оценочные критерии подразделяются на количественные (время отклика на запросы, стоимость операций манипулирования, стоимость памяти, стоимость ведения и т.д.) и качественные (гибкость, адаптивность, восприимчивость, совместимость и т.д.)

3) Информационные требования. Они проходят через весь процесс поэтапного совершенствования баз данных. Часто при определении требований к информации бывает полезно подразделять информацию на:

• информацию, отнесенную к принципиальной структуре данных – описание данных и их связей безотносительно конкретных способов их использования и обработки.
• информацию, отнесенную к характеру использования данных – описание требований по обработке данных

4) Средства описания. Это языковые средства описания результатов выполнения всех этапов проектирования. Сюда включаются:

-  Естественный язык, в котором строго определены все необходимые для описания результатов проектирования понятия. Используется, как правило, на этапе стратегии и на всех других этапах.

-  Разработанные стандартные формы, анкеты, бланки. Редко используются на этапе стратегии и практически не используются на этапе проектирования. Более всего подходят для этапа анализа.

-  Специальные формализованные языки концептуального моделирования (семантические сети, исчисление предикатов, ER-языки). Используются в основном на этапе концептуального моделирования.

-  Формализованные языки определения данных (ЯОД) и манипулирования данными (ЯМД). Используются на этапе логического проектирования. Повсеместно используемым для этих целей языков является SQL.

 

2.1 Этапы разработки  базы данных

 

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

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

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

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

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

Ключевые результаты этапа анализа:

• Согласованная диаграмма сущностей и связей
• Согласованные описания задач с достаточным уровнем детализации
• Матрицы Задача: Сущность, Задача: Подразделение и Сущность: Подразделение
• Объемы данных, частота выполнения задач, ожидаемая пользователем производительность.
• Первоначальный вариант стратегии внедрения.
• Необходимость мер по ревизии и контролю данных, резервному, копированию и восстановлению.
• Общее описание неавтоматизируемых процедур.
• Критерии приемлемости, качества, гибкости, производительности.
• Предварительная оценка объема системы.
• Ограничения и предположения.
• Согласованный подход к этапам проектирования и реализации.
• Уточненный план разработки системы.

Этап концептуального моделирования – это построение строгого описания предметной области в терминах некоторого формального языка. Идеи построения концептуальной модели предметной области берут свое начало с публикации рабочей группы ANSI/SPARC по архитектуре СУБД.

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

Ключевые результаты этапа концептуального моделирования: