Файл: Александр Иванович ДоронинБизнесразведка.pdf

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

лось несколько псевдонимов, то на каждый из них со- ставлялся персональный учетный лист со ссылками на другие листы. В листах также имелись ссылки на ре- гистратор агентуры или номер агента, который явился источником информации.
Сведения на одного фигуранта, поступающие от разных агентов, заносились на особый лист, где кон- центрировалась вся информация. Листы со сведени- ями о членах одной и той же организации нанизыва- лись на отдельный регистратор, на который делалась ссылка в листе, находящемся на дуге. Таким образом,
уже в 1902 году спецслужбы царской России распола- гали именной картотекой, включавшей 65 тысяч учет- ных карточек, а архивы включали до 200 тысяч фо- тографий «государственных преступников» и «полити- ческие алфавитные списки лиц, разыскиваемых поли- цией с приложением фотографии и состоявших под негласным надзором»{Галвазин С.Н. Охранные струк- туры Российской империи. Формирование аппарата,
анализ оперативной практики. – М., 2001.}.
«Шьется дело!» – устало хмыкали сотрудники Де- партамента полиции, скрепляя досье «цыганской»
иглой с суровой ниткой.
Каждая категория объектов разработки, агентов и секретных сотрудников, каждая форма учета имела собственный цвет документации. Это позволяло ис- ключительно быстро находить любые материалы. В

годы после Октябрьской революции многое из этого передового опыта с успехом применялось на Лубянке для нужд Советской власти.
В качестве зарубежного примера можно привести механическую систему картотечной обработки инфор- мации, разработанную директором ФБР Эдгаром Гу- вером. Он предложил заполнять сведения о преступ- никах на специальных карточках, на которых поми- мо анкетных данных указывались ответы на много- численные вопросы о преступной «специализации»
каждого фигуранта картотеки. Каждый положитель- ный ответ фиксировался путем перфорации соответ- ствующего поля карточки. При необходимости отбора подозреваемых по совокупности определенных при- знаков сквозь соответствующие отверстия (указываю- щие на необходимые признаки) продевались метал- лические спицы, и таким образом, отбирались ис- комые подозреваемые{Костин В.П. Тайная полиция
США. ФБР: прошлое и настоящее, М.: Мысль, 1981.}.
После появления компьютеров правоохранитель- ные органы и спецслужбы стали одними из самых пер- вых и благодарных их пользователей. «Призыв на се- кретную службу» компьютеров, способных за доли се- кунды обрабатывать тысячи записей, положил конец эре картотек, заполненных сотнями тысяч бумажных карточек.

3. Модели представления данных
в электронных базах данных
Внедрение новых информационных технологий не обошлось без трудностей, так как поначалу поиск в электронных картотеках оказался хотя и очень бы- стрым, но зачастую гораздо менее эффективным, чем поиск в обычной картотеке или традиционное изучение архивных дел. Это во многом было связано с тем, что в то время доступ к обрабатываемым данным осуще- ствлялся прикладными программами напрямую, а са- ми данные были организованы в виде плоских файлов.
Возрастающие потребности в обработке информа- ционных массивов стали мощным стимулом развития теоретических основ информационных технологий и их практической реализации. Возникавшие проблемы с логической целостностью данных, а также невозмож- ность представить логические связи между ними в ука- занных выше системах стали причиной возникновения первой модели данных – иерархической.
На сегодняшний день существует четыре модели{Моделирование данных – это выявление сущ- ностей (объектов), которые должны быть предста- влены в базе данных, и связей между ними.} пред- ставления данных: иерархическая, сетевая, реляци-

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

имосвязь «один ко многим».
Иными словами, для данного главного типа объек- та существует несколько подчиненных типов объек- та. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчинен- ных типов объектов. Таким образом, взаимосвязи ме- жду объектами напоминают взаимосвязи в генеалоги- ческом дереве за единственным исключением: для ка- ждого порожденного (подчиненного) типа объекта мо- жет быть только один исходный (главный) тип объекта.
То есть иерархическая модель данных допускает толь- ко два типа связей между объектами: «один к одному»
и «один ко многим».
При моделировании событий, как правило, необхо- димы связи типа «многие ко многим». Как одно из возможных решений снятия этого ограничения можно предложить дублирование объектов. Однако дублиро- вание объектов создает возможности рассогласования данных. Приведу пример: объект «Иванов» может про- ходить как подчиненная связь объекта «Петров», и од- новременно имеется объект «Иванов» с подчиненной связью «Петров». Установить реально существующие связи ближайшего окружения «Иванова» и «Петрова»
в этом случае достаточно проблематично.
Иерархические базы данных по существу являются навигационными, т.е. доступ возможен только с помо- щью заранее определенных связей.

Достоинство иерархической базы данных в том, что ее навигационная природа обеспечивает очень бы- стрый доступ при следовании вдоль заранее опреде- ленных связей. Однако негибкость модели данных и, в частности, невозможность наличия у объекта несколь- ких родителей, а также отсутствие прямого доступа к данным делают ее непригодной в условиях частого выполнения запросов, не запланированных заранее.
Еще одним недостатком иерархической модели дан- ных является то, что информационный поиск из ниж- них уровней иерархии нельзя направить по вышележа- щим узлам.
Чтобы устранить ограничения, свойственные иерар- хической модели данных, в начале 60-х годов, задол- го до появления компьютерных сетей, проектировщики баз данных создают
сетевую модель данных, описы- вающую сети связей между данными.
В сетевой модели данных понятия главного и подчи- ненных объектов несколько расширены. Любой объект может быть и главным, и подчиненным (в сетевой мо- дели главный объект обозначается термином «владе- лец набора», а подчиненный – термином «член набо- ра»). Один и тот же объект может одновременно вы- ступать и в роли владельца, и в роли члена набора.
Это означает, что каждый объект может участвовать в любом числе взаимосвязей.
Сетевая модель базы данных похожа на иерархи-

ческую, однако характер отношений основных ее со- ставляющих принципиально иной. В сетевой модели принята свободная связь между элементами разных уровней, т.е. она допускает связи «многие ко многим».
В качестве примера используемой на сегодняшний день СУБД, поддерживающей принципы сетевой моде- ли данных, можно привести инструментальную СУБД
«Cronos Plus».
Понятие
реляционная модель ввел в 1970 г. Э.Ф.
Кодц. В реляционной модели данных объекты и взаи- мосвязи между ними представляются с помощью та- блиц. Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица представляет один объект и состоит из строк и столбцов. В реляционной базе данных каждая таблица должна иметь первичный ключ
(ключевой элемент) – поле или комбинацию полей,
которые единственным образом идентифицируют ка- ждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель получила наибольшее распространение среди СУБД
для персональных компьютеров.
Название «реляционная» (relational) связано с тем,
что каждая запись в такой базе данных содержит ин- формацию, относящуюся (related) только к конкретно- му объекту. Кроме того, с данными двух типов можно работать как с единым целым, основанным на значе- ниях связанных между собой данных.

Преимуществом реляционной модели перед други- ми моделями является простая и удобная для пользо- вателя схема данных, представляемая в виде таблиц.
Физическая независимость реляционной модели со- стоит в том, что модель данных не включает ника- ких физических описаний. В действительности физи- ческое представление отношений и путей доступа опи- сывается независимо от описания логической схемы отношений.
Недостатком реляционной модели данных является избыточность по полям (из-за создания связей).
В качестве примера можно привести реляционные
СУБД Microsoft Access и Borland Paradox.
Объектно-ориентированная модель данных в от- личие от вышеописанных моделей, в которых инфор- мация и процедуры хранились раздельно (данные и связи между ними – в базе данных, а процедуры – в прикладной программе), позволяет хранить процеду- ры обработки сущностей вместе с данными. Такое со- вместное хранение считается шагом вперед в методах управления данными. Но объектно-ориентированные базы данных являются навигационными, что предста- вляется шагом назад.
Объектно-ориентированная модель непосредствен- но поддерживает связи типа «многие ко многим».

4. Общие принципы создания
информационной системы службы
безопасности предприятия
Как правило, при создании информационной систе- мы службы безопасности предприятия имеются три основные составляющие решения этой проблемы: на- личие вычислительной техники, программного обес- печения и квалифицированных специалистов, способ- ных ее создать и эксплуатировать. Самое главное, с чего необходимо начинать, – четкое определение за- дач, для решения которых будет приобретаться ком- пьютерная техника и программное обеспечение.
Существует всего два пути создания информацион- ной системы. Первый – поставить техническое зада- ние и, продвигаясь путем проб и ошибок, попытаться создать «самое-самое крутое». Как правило, это доро- га в никуда, вымощенная крупными купюрами…
Гораздо экономичнее купить готовое. Программное обеспечение, позволяющее организовать собствен- ный интегрированный банк данных, широко предста- влено на российском рынке, это «Cronos Plus», «Би- нар», «Саиб», «Лагуна», «Галактика», «Ватсон». Во- прос только в том, насколько приемлемым окажется соотношение цена/качество.

В качестве базового программного продукта для со- здания информационной системы СБ предприятия мы с вами будем рассматривать программный комплекс,
реализованный на базе системы управления базами данных «Cronos Plus».
Инструментальная СУБД «Cronos Plus» предназна- чена для комплексной автоматизации широкого спек- тра информационных задач, от справочных до ситуа- ционных и экспертных, в организациях, чья деятель- ность требует анализа разнородных слабоструктури- рованных сведений об экономической, социальной,
политической и иной обстановке.
«Cronos Plus» это минимум ограничений и макси- мум возможностей, доступность и эффективность, гиб- кость и способность к совершенствованию. Систе- ма имеет четырехлетнюю практику эксплуатации. Эта
ИСУБД позволяет отказаться от услуг штата програм- мистов и самостоятельно решать свои информацион- ные, аналитические и прогностические задачи. Систе- ма весьма проста в освоении и эксплуатации. Она обладает мощным поисковым аппаратом, многоуров- невой системой разграничения и контроля доступа к информации и режимам ее обработки, телекоммуни- кационным доступом к удаленному банку через Ин- тернет. Компактно хранит данные и фотографии, име- ет возможность «перенастройки» наполненного бан- ка без процедур реорганизации самим пользователем,