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

автор Нежданов И.Ю. 

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

– неопределенность будущего – неизвестность какая информация понадобится завтра;

- неизвестность с чем скоррелирует ранее собранная информация.

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

            Попробуем сформулировать требования к нашему хранилищу информации:

- легкий и быстрый поиск и доступ к искомому материалу;

- возможность хранения в базе огромных объемов информации;

- возможность хранения в одной записи значительного объема информации с возможностью полноценного поиска;

- простота управления хранилищем, в т.ч. копирования и архивирования данных;

- надежность хранилища – исключение потери информации;

- максимально возможное сжатие материала для уменьшения занимаемого места.

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

Простая файловая система

Самый простой способ хранения текстовых данных на ПК это обычная  файловая система. Один файл – один информационный блок. При этом нельзя все файлы сваливать в одну директорию, дав им названия «Инфо-1», «Инфо-2», «Инфо-3» и т.д. При таком подходе очень скоро вы не сможете ориентироваться в своем хранилище.

Для недопущения такой ситуации необходимо придерживаться нескольких простых правил:

- во первых присваивайте файлам осмысленные имена – название объекта интереса, благо современные системы поддерживают длинные имена файлов. Структура же самого имени должна быть следующей: первая часть имени – название объекта интереса, а вторая – характеристика содержания файла. Например «РАО ЕЭС_СМИ_2005», или «Бендукидзе_Состав ФПГ».

- во вторых каждому проекту должна соответствовать своя директория (папка) с названием, соответствующим объекту интереса. При большом количестве материала, в каждой такой папке-проекте можно создать подпапки: «СМИ», «Новости», «Отчетность», «Аналитика».

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

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

Файловая система с программной надстройкой

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

- присвоение неких (заранее вами определенных) атрибутов хранимым файлам;

- виртуальная группировка файлов по принятым блокам (проектам, папкам, группам и т.п.);

- визуальное представление этой виртуальной файловой системы;

- поиск по атрибутам файлов;

- поиск по содержимому файлов, в т.ч. с поддержкой логических операторов.

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

База данных

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

- Информация

- Организация

- Лицо

- Адрес

- Телефон

- Проект

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

- дата ввода информации;

- дата публикации (обнародования);

- автор;

- источник;

- канал поступления;

- название.

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

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

В таблице «Лицо» должна храниться структурированная информация о людях. Структура также зависит от ваших задач.

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

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

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

- создание между двумя таблицами одной единственной связи с комментарием и внесение этого комментария в зависимости от ситуации;

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

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

автор Нежданов Игорь Юрьевич