КаталогИндекс раздела

О путях и средствах развития автоматизированных информационных систем административного назначения.
Т.В.Гендельман, А.С.Деревянко, М.Н.Солощук, Х.Штир


Опубликовано в:Вестник ХГПУ. Вып. 72., Харков, ХГПУ, 1999.

Автоматизированные информационные системы (АИС) становятся насущной необходимостью административной и управленческой деятельности на всех ее уровнях. Для учреждений госадминистрации, например, узлы управления образуют: как правило, трехуровневое дерево: корнем которого является министерство/ведомство, промежуточными узлами - регион/область, а листьями - районные отделения или аналогичные низовые структуры. На сегодняшний день в Украине деревья, "произрастающие" от разных министерств/ведомств образуют непересекающийся "лес". Уровень автоматизации в различных узлах этого "леса" на сегодняшний день варьируется от многолетнего опыта машинной обработки, восходящего еще к применению ЕС ЭВМ, до нулевого цикла создания АИС.

Большинство АИС, считающихся развитыми по меркам сегодняшнего дня и нашей страны, функционируют на уровнях район - область и укладываются в следующую модель. В период использования ЕС ЭВМ АИС функционировала только на областном уровне и поддерживалась оригинальным программным обеспечением (ПО), использующим сложные форматы файлов ОС ЕС (ISAM, BDAM). Трудности в сопровождении такого ПО наряду с невозможностью дальнейшего использования физически устаревшей техники ЕС ЭВМ заставили руководителей соответствующих служб в конце 80-х - начале 90-х годов пойти на революционные изменения, состоящие в переходе на персональную технику. Программной основой АИС стали промышленно выпускаемые СУБД реляционного типа - FoxPro, PARADOX и т.п. (В последнее время некоторые ведомства внедряют для автоматизации офисной работы Windows 3.11 и Windows 95 и соответственно - СУБД MS Access.) Отказ от перфоносителей и полноэкранное представление информации сделали базы данных (БД) удобными в сопровождении и использовании. Начавшись на среднем уровне иерархии (область), автоматизация на базе ПЭВМ продолжала развиваться прежде всего по направлению вниз (район). При этом ПО областной АИС или некоторое его подмножество просто переносилось в АИС районного филиала. Передача данных из районов, являющихся основным источником исходной информации, в область производилась либо средствами электронной почты либо передачей носителей. Обратное движение данных практически не предусматривалось.

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

Другая модель предшествующего развития - начало автоматизации от корневого узла дерева. При этом права и инициатива регионального уровня по разработке собственного ПО резко ограничивается, использование на нижних уровнях ПО, переданного из центра носит императивный характер, а отношения между уровнями по обмену данными строго регламентируется на уровне внутриведомственных приказов/инструкций. Применяемые же программные средства и принципиальные подходы этой модели - те же, что и в предыдущей, с той лишь разницей, что инерция персональной обработки имеется здесь и на корневом уровне. С ростом размеров накопленных БД и развитием требований к их обработке, однако, начинают проявляться ограничения персональных СУБД. Прежде всего это сказывается на проблеме актуализации данных. На уровне региональной АИС объемы исходных данных возрастают настолько, что для их хранения оказываются уже недостаточными ресурсы ПЭВМ с рядовыми техническими характеристиками, и ПЭВМ, составляющие АИС регионального уровня, объединяются в локальную сеть (ЛС) с хранением данных на файловом сервере. Файловый сервер, однако, не может обеспечить одновременный доступ к БД со многих автоматизирован- ных рабочих мест (АРМ). Поэтому наряду с централизованным хранением применяется копирование некоторых подмножеств данных в локальные файловые системы отдельных АРМ. При этом неизбежно начинают возникать расхождения между централизованной БД и локальными копиями ее отдельных частей. Это требует установления строгих правил периодической коррекции централизованной БД и ограничений на обработку одного и того же подмножества данных на разных АРМ. Аналогичная проблема возникает и с актуализацией централизованной БД данными от филиалов. С развитием как АИС филиалов, так и АРМ ЛС трудоемкость мероприятий по администрированию БД возрастает и постепенно отбирает на себя все больше ресурсов - как технических, так и людских.

По-видимому, в перспективе развитие управленческих АИС должно стремиться к созданию единой БД с достаточно оперативной актуализацией информации на всех уровнях иерархии. Не менее важным является и развитие горизонтальных связей - обмена данными между БД различных ведомств, который на сегодняшний день происходит эпизодически и исключительно в "режиме off-line". При этом все большую значимость будут приобретать вопросы контроля доступа к данным, практически не обеспечиваемого в сегодняшних АИС. В первом варианте данной статьи мы указывали на возможность того, что в не столь отдаленном будущем и в нашей стране актуальным станет вопрос о контроле прав организаций и ведомств на сбор и хранение информации о гражданах, а тем более - на предоставление доступа к этой информации третьим лицам. В ноябре 1997г. Конституционный суд Украины признал конфиденциальными сведения о месте рождения гражданина, его семейном положении, образовании - достаточно характерные пункты анкеты и, соответственно, поля записи в БД. Таким образом, предусмотренная нами возможность уже стала реальностью.

Для управления доступом АИС прежде всего должна быть доступной только для зарегистрированных пользователей. Это требование не поддерживается персональными СУБД. Попытки обойти это ограничения персональных СУБД производятся в основном по двум направлениям: использование возможностей регистрации и контроля прав доступа, предоставляемых сетевыми средствами, и разработка собственного ПО. Первое направление не может дать удовлетворительных результатов хотя бы из-за того, что доступ в сети контролируется на уровне файлов, в то время, как для АИС необходим более дифференцированный контроль. Что касается второго направления, то совершенно очевидно, что программы, создаваемые полупрофессионалами, не могут быть сравнимими с промышленно выпускаемыми средствами защиты и контроля ни по функциональным возможностям, ни по надежности.

С другой стороны, персонификация доступа к информации и возможность назначения индивидуальных прав доступа как к горизонтальному, так и к вертикальному срезам таблиц реляционной БД являются изначальными свойствами языка SQL. Хотя некоторые персональные СУБД (FoxPro, MS Access) и предоставляют возможность формулирования запросов на подмножестве SQL, именно средства контроля доступа и средства многопользовательского режима в это подмножество не входят. В полном объеме эти средства реализуются только в корпрративных СУБД, называемых SQL-серверами, и обеспечиваются операторами присвоения/лишения прав (GRANT/REVOKE) и созданием видов (CREATE VIEW). Самые первые из этих СУБД - DB/2 и Oracle - с самого начала создавались как многопользовательские - и в смысле учета индивидуальных прав доступа, и в смысле обеспечения параллельной обработки. Современные версии SQL-серверов способны обеспечить работу АИС в режиме клиент/сервер, причем серверная часть должна функционировать в среде операционной системы (ОС) с вытесняющей многозадачностью, а клиентская может работать и в однозадачной среда MS DOS или Windows.

Средства режима клиент/сервер, заложенные в корпроативные СУБД, обеспечивают для клиента "прозрачный" доступ к удаленной БД, как к локальной, в том числе и "интерактивный SQL" - возможность ввода любых запросов в командной строке. Последнее представляется нам излишним для АИС, так как с одной стороны, это средство вряд ли может быть удобным для конечного пользователя, не владеющего языком SQL, а с другой - позволят "взломщику" использовать ошибки администратора в назначении прав доступа. Предлагаемая нами модель следующая. Хранение данных осуществляется централизовано на сервере ЛС в среде корпоративной СУБД (в ее многопользовательской инсталляции). Непосредственными клиентами СУБД являются выполняющиеся здесь же на сервере процессы. Каждый такой процесс обслуживает одно АРМ ЛС и порождается динамически при начале сеанса на данном АРМ. Естественно, что для порождения этих процессов на сервере должен существовать резидентный процесс-монитор, осуществляющий обработку команд типа logon/logoff от АРМ. На ПК, обеспечивающем АРМ, функционирует ПО "конечного клиента" для конкретного АРМ, которое, во-первых, обеспечит удобный интерфейс конечного пользователя, а во -вторых, ограничит спектр формулируемых клиентом запросов. ПО АРМ может существенно различаться для разных рабочих мест - от существенно специализированных АРМ с малым количеством возможных запросов и полностью проблемно-ориентированным интерфейсом до АРМ широкого профиля с большим диапазоном возможных запросов и формулированием их, например, в интерфейсе по типу QBE (query by example - запрос по образцу).

В представлении большинства пользователей ПЭВМ многозадачные и многопользовательские ОС и корпоративные СУБД связываются со значительным объемом вычислительных ресурсов, недостаточным при теперешнем состоянии их материальной базы. Это представление, однако, ошибочно, во-первых, потому, что объем ресурсов, доступных радовому пользователю постоянно возрастают, а во-вторых, потому, что производители многопользовательских программных средств предпринимают значительные усилия по снижению ресурсоемкости своих продуктов. Тот же или незначительно больший объем ресурсов, который позволяет пользователю инсталлировать Windows 95 и несколько приложений для нее, позволит инсталлировать и многозадачную ОС, и корпоративную СУБД. Иногда в качестве аргумента в пользу однопользовательских ОС и персональных СУБД фигурирует возможность без особых проблем работать с нелицензионными копиями ПО. Этот аргумент, безусловно, должен быть решительно отвергнут, так как ни о каких гарантиях защиты данных в этом случае речи быть не может.

Из современных многопользовательских средств, доступных на аппаратной платформе ПЭВМ следует назвать:

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

Каковы же перспективы дальнейшего развития АИС? По-видимому, АИС для возможно не столь отдаленного будущего должна базироваться на модели клиент/сервер. Информация в такой модели должна быть распределена с точки зрения корневого уровня (по регионам) и централизована - по всем ведомствам - на региональном уровне. Региональный уровень, таким образом, выступает в роли основного сервера, обслуживающего запросы клиентов как сверху, так и снизу. Наиболее вероятной (а может быть, и единственно возможной) аппаратной базой такого сервера может быть мэйнфрейм семейства IBM System/390 - новое поколение больших ЭВМ, известных в нашей стране по семейству ЕС ЭВМ - аналогу предшествовавших IBM System/ 360 и System/370. Для обеспечения связей с клиентами могут использоваться дополнительные вычислительные мощности среднего класса, например, ЭВМ семейства IBM AS/400 в конфигурации сетевого сервера. АИС низового уровня (областного ведомства, районного филиала) будут обеспечиваться локальными сетями ПЭВМ, возможно, с использованием персональных серверов.

При ориентации на такую модель развития интегрированной АИС в несколько более выигрышной ситуации оказываются те узлы, в которых процесс автоматизации информационных служб находится еще в стадии становления и еще не стала традиционной модель персональной обработки информации. При проектировании своих АИС они могут сразу же делать ставку на названные выше персональные средства, позволяющие сделать даже локальную БД достаточно целостной и защищенной с одной стороны, а с другой стороны - обеспечить эволюцтонную интеграцию локальной АИС в АИС большего масштаба. Такая ориентация - еще один аргумент в пользу продуктов фирмы IBM. IBM является на сегодняшний день единственным производителем аппаратного и программного обеспечения, чьи продукты перекрывают весь спектр мощностей вычислительных систем. Для любых аппаратных средства и ОС IBM естественным является взаимодействие в распределенной среде с узлами сети, представленными другими аппаратными платформами и другими ОС фирмы IBM, но обеспечивается также и взаимодействие с продуктами других производителей. Что же касается DB/2, то это продукт, реализованный на всех платформах фирмы IBM и совместимый с аналогичными продуктами других фирм.

Выводы.

1.Административные АИС должны разрабатываться на базе многозадач ных ОС и локальной, а в перспективе - и глобальной сетевой среды.
2.Важнейшим вопросом, решаемым ПО таких АИС, должен стать вопрос контроля доступа к данным. Средства такого контроля предоставляемые персональными СУБД и средствами коммуникаций не являются достаточными. Базой для построения системы контроля доступа к АИС должны стать средства, предоставляемые языком SQL и корпоративными СУБД, дополненные специализированным ПО.
3.Уже сейчас персональная вычислительная техника и ПО, обеспечивающие вышеназванные требования, являются доступными.
4.Для АИС, уже функционирующих в чисто персональной среде неизбежен скорый переход в среду многопользовательскую. Своевременное осознание этой неизбежности руководителями и специалистами и самостоятельное иницирование соответствующих проектов могут сделать такой переход менее болезненным.
5.Учитывая тенденции к интеграции, при выборе средств, составляющих аппаратную и программную базу АИС следует отдавать предпочтение таким средствам, для которых гарантирована длительная эволюционная программа развития и обеспечиваются наилучшия возможности интеграции как в однородные, так и в неоднородные среды.


КаталогИндекс раздела