Основные компоненты АРМ учета
Практический опыт указывает на то, что простейший АРМ учета должен содержать следующие подсистемы: непосредственно учет (ПСУ), подсистема хранения и работы с предысторией (ППР), подсистема восстановления данных после сбоя (ПВ), подсистема обмена данными и их согласования (ПОД).
В ПСУ необходимо реализовать следующие функции: ввод и проверка данных, специфические поиски, вывод печатных отчетов. Входные данные следует проверять на наличие очевидных ошибок (неправильные даты, время и т.п.), на дублирование , при этом сразу необходимо учесть что в большинстве случаев действительно необходимо хранить несколько абсолютно идентичных с точки зрения предметной области записей и вместе с тем система должна их как-то различать. Необходимо обеспечить целостность и непротиворечивость данных. Целостность для АРМ учета в простом случае означает наличие всех компонент на которые имеются ссылки, так например если в предметной базе есть код улицы, то в соответствующем справочнике эта улица должна быть. Следует обратить внимание на операции удаления данных, особенно при работе со справочниками. Непротиворечивость данных необходимо поддерживать постоянно, а не только на этапе ввода данных, возможны случаи, когда правильные входные данные потребуют изменения уже имеющихся или последующая обработка потребует таких изменений. Следует обратить внимание на операции ввода/редактирования так например если в предметной базе есть код улицы, соответствующий улице 1, то нельзя редактировать справочник улиц так чтобы этому коду соответствовала другая улица (кроме случая переименования).
ППР является самой трудоемкой и сложной. Значимость предыстории для ежедневной работы зависит от предметной области, но даже если особой необходимости в ней якобы нет, она необходима. В идеале ППР должна знать все о всех данных когда-либо находившихся в системе и операциях совершавшихся над ними, возможно еще некоторую специфическую информацию (имя оператора, выданные печатные формы и др.). ППР должна обеспечивать возможность восстановить состояние системы на любой момент в прошлом, провести некоторый анализ динамики данных. С этой целью следует вести протокол работы системы. В системах предназначенных для больших ЭВМ, серверов данных, в частности основанных на стандартном языке описания запросов SQL эти вопросы обсуждаются давно. Тем не менее современные системы ППР не являются идеальными и прежде всего из-за несовершенства информационной модели. В настольных узкоспециализированных системах эта подсистема вместе с системойвосстановления данных после сбоя обычно заменяются подсистемой резервного копирования и восстановления (ПКВ).
При реализации ПКВ следует обратить наибольшее внимание на безопасность как самих данных, так и ранее созданных резервных копий (то есть исключить возможность уничтожения основных данных в результате ее работы, например путем случайного восстановления данных из старого архива). Ранее созданные резервные копии должны периодически удаляться, но с определенным умыслом и в определенной последовательности, можно например воспользоваться классическими схемами резервного копирования 1-2, 1-2-3. Следует остерегаться ситуации, когда многократное повторение операции резервного копирования приведет в уничтожению предыдущих резервных копий. Такая ситуация возможна, в частности, у неопытного пользователя. Данные могут быть общими для нескольких пользователей (например находится на сервере файлов) в этом случае невозможны операции удаления файла и замены его другим. ПКВ должна по крайней мере оповещать пользователя (с занесением в протокол) о проводящихся ей операциях и их результатах. ПКВ может быть реализована двумя процедурами: Процедурой создания архива данных (ПАД) и процедурой восстановления данных из архива (ПВД).
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.