Примерная структурная схема реляционной модели АСУН третьего уровня изображена на рис.8.

Описанная автоматизированная система в течение ряда лет используется в МВД Республики Башкортостан, обеспечивая весь необходимый спектр работ связанных как с процедурой сбора и обработки поступающей информации, так и выполнение поисковых и аналитических запросов.

Программный комплекс обеспечивает обработку информации в следующих режимах:

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

· почтовом (справочном, поисковом режимах, и режиме пакетной загрузки), работающем через почтовую систему.

Обеспечивает выполнение следующих основных функций:

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

· выгрузку информации и ее пересылку с использованием почтовой системы в ПК «Паспорт-Центр» «ИБД-Ф» в едином формате обмена (ЕФО);

· прием и загрузку информации о лицах объявленных в розыск, поступающей из ПК «Паспорт-Центр» «ИБД-Ф» в формате ЕФО по почтовой системе;

· ведение словарей и классификаторов;

· формирование и выдачу статистической информации об объектах учета;

· справочный режим по основным объектам учёта с получением «досье» на интересуемый объект (в т.ч. по установочным данным лица, серии-номеру паспорта);

· разделение уровней доступа пользователей к информации по режимам обработки (ввод, запросы) и видам доступной информации;

Рис. 8 - Структурная схема реляционной модели АСУН третьего уровня

Во всех внешних интерфейсах АСУН верхнего уровня, через которые осуществляется обмен структурированными данными в рамках (ФЦП «Электронная Россия») используется подмножество метаязыка XML. Описание структур всех обменных данных доступно для взаимодействующих сторон, обмен данными построен на основе информационных объектов, снабженных отчуждаемыми метаописаниями. Из АСУН верхнего уровня организована следующая выгрузка необходимой информации в формате межведомственного информационного обмена, согласно положений ФЦП «Электронная Россия»:

- ежедневная передача информации (с применением ЭЦП) в МНС РФ по РБ

- ежедневная передача информации в ФМС России и МВД России по всем выданным паспортам

- ЦИК России по РБ о жителях РБ достигших избирательного возраста

Но как показывает практика сотрудникам ОВД порой недостаточно информации содержащейся в задачах реализованных ИЦ МВД по РБ и они хотят дополник свои учеты дополнительной информацией или создать свой дополнительный учет. В качестве примера рассмотрим информационно-поисковую систему лиц, представляющих оперативный интерес сотрудника РУВД с помощью инструментального средства FAKT.

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

В главной таблице «Лицо» хранятся анкетные данные лица, представляющего оперативный интерес, а в подчиненной, например - «Судимость» - сведения о всех его судимостях. Возможность установления связей между отдельными таблицами позволяет автоматически получать дополнительные сведения об объекте поиска из всех связанных таблиц. Заметим, что межтабличная связь может устанавливаться не только между двумя таблицами, но и между группой таблиц. Необходимым условием межтабличной связи является наличие у них одинаковых полей, обычно индексных. Когда две таблицы связываются с помощью некоторого поля, то одна из таблиц рассматривается как главная, а другая - как подчиненная. В данном случае в качестве главной будет выступать таблица «Лицо», а в качестве подчиненной - таблица «Судимость». Поля, с помощью которых осуществляется связывание таблиц, называются ключевыми. В нашем случае ключевым является поле «Порядковый номер» таблицы «Лицо». Связанное с ним поле «Лицо» таблицы «Судимость» называется внешним ключом. При организации связи та таблица, в которой индексное поле является ключевым, является главной.

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

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

Формы являются информационным отражением реальных объектов, учет которых осуществляется в той или иной информационно-поисковой задаче и представляет собой набор полей. По желанию пользователя в форме могут быть интегрированы и другие элементы - надписи, командные кнопки, списки, иллюстрации и т.д. Формы можно раскрасить любыми доступными красками, использовать для оформления растры и графические элементы (линии и прямоугольники). Форма может занимать несколько экранных страниц. При размещении полей на экранной странице надо исходить не только из соображения целесообразности, но и придерживаться удобства восприятия и наглядности экранных форм. Заголовки, пояснения, надписи являются элементами оформления экранной формы. Значение текстовых полей в экранной форме может быть записано буквами, цифрами, знаками, а также их комбинациями, например, «Фамилия», в значении которого используются символы русского алфавита.

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

В процессе описания задачи и создания БД образуются три основные группы объектов: таблицы, формы и запросы. Конструирование названных объектов производится отдельно друг от друга. Если таблицы и формы используются для наглядного представления информации в базе данных, то для отбора информации в БД используют такое средство, как запрос. Запрос представляет собой средство отбора записей. Он содержит точную формулировку критерия отбора, заданную пользователем. Система управления базой данных, выполняя запрос, перебирает записи базы и отбирает только нужные. Причем пользователь может ограничить сферу поиска, отсортировать отобранные записи, связать несколько таблиц.

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

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

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

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

Кроме чисто программных, важное место при решении поставленной задачи должны занимать и организационные меры. Анализ выводов, сделанных специалистами ГИАЦ МВД России, занимающихся обменом информацией в периферийных центрах показал, что основная трудность при обмене состоит в том, что используемые базы данных содержат много ошибок. Искажение информации в базах данных происходит из-за частого конвертирования рабочих файлов в форматы разных СУБД, с которыми приходится взаимодействовать, и программных ошибок в подсистемах ввода. Избежать дополнительных конвертации можно, используя базы данных сформированные, например, на основе инструментального средства FAKT, что связано с тем, что проблемы конвертации уже проработаны ИЦ МВД по РБ. Кроме того устранения ошибок можно добиться с помощью регулярной сверки и чистки баз данных.

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

Программный комплекс FAKT - интегрированный, технологический программный комплекс, обеспечивает создание банков данных по различным видам учетов и ориентирован на решение учетно-статистических, информационно-поисковых и розыскных задач, снабжен системой защиты данных, удобным генератором запросов и отчетных форм, поисково-аналитическими режимами работы, надежными сервисными функциями обслуживания. Комплекс реально эксплуатируется в каждом горрайоргане МВД Республики Башкортостан в течении 8-9 лет. Комплекс снабжен обширными возможностями интерактивной подстройки к требованиям пользователя (изменение структуры данных, экранных и отчетных форм), генератор запросов позволяет получить практически любой запрос. Скорость ответа на запросы находится на уровне характеристик лучших систем. Повышенное внимание уделяется помехозащищенности и надежности хранения данных, реализованы технологии распределенного взаимодействия задач. Комплекс FAKT предназначен для создания и ведения баз данных с одновременным обслуживанием до 20 локальных баз, каждая из которых может обеспечить учет до 46 видов документов. Реализован аппарат создания и ведения индексных и гипериндексных файлов, связывания их в мультигруппы и внешние группы независимо от того, где находятся данные в одной базе данных или в разных. Реализована возможность выборочного копирования информации, создания резервных копий, работает поисковый генератор с поиском по любой совокупности признаков с возможностью задания сложных формул (с использованием операторных скобок, макро средств, запоминанием транзакций запроса и возможностью его повторения в любое время, возможностью многократного уточнения запроса и отката к предыдущему запросу). Разработан аппарат вывода списков по наборной таблице реквизитов на печатающее устройство, в файл на винчестере или дискете. Конфигурация операционной системы должна обеспечивать программе пользователя не менее 570 КВ RAM, и параметр files в config.sys со значением не менее 20. Для реализации некоторых режимов работы и полноценного функционирования ядра Факта необходимо наличие WINDOWS98 и выше. Если объемы баз данных таковы, что их архивные копии превосходят объемы дискет, то рекомендуется избегать создания архивных копий на дискетах, и использовать режим записи в файл на винчестере с последующим копированием этого файла стандартными системными средствами.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22