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

При создании информационной среды в любом ведомстве стремятся к построению единой системы. К примеру, единая система информационного обеспечения всех подразделений МВД решает множество проблем — от совместимости при обмене информацией до уменьшения стоимости обучения работе новых сотрудников. На практике, однако, до сих пор используется множество различных систем хранения и анализа данных даже в рамках одной структуры, независимо от решаемой задачи — будь то борьба с организованной преступностью или борьба с незаконным оборотом наркотиков. Наиболее распространены следующие информационно-аналитические системы: CronosPlus (www.cronos.ru), Binar, FaceManager, Flint, «Досье» (www.goal.ru/products/persona.html), НЕВОД (www.linter.ru/nevod_rus.php), «Портрет» (www.portret.tomsk.ru), «Легенда», «Сова» и т.п. Часто на местах можно встретить энтузиастов, которые стремятся что-то улучшить, самостоятельно пытаясь сделать приложения и спроектировать свои базы. И только потратив массу времени, путем проб и ошибок они приходят к пониманию того, что собой должна представлять их система. Но зачем изобретать велосипед, строя хранилища данных, когда можно воспользоваться лучшей мировой практикой?

Хранилища в коммерческих организациях

Обычно при построении хранилищ данных применяются два подхода — «по Биллу Инмону» и «по Ральфу Кимбаллу» [1]. Согласно парадигме Инмона, хранилище данных представляет собой единый источник информации, хранимой в третьей нормальной форме для всей корпоративной системы бизнес-анализа, при этом предприятие имеет одно хранилище данных, на базе которого строятся все витрины. Хранилище данных по Кимбаллу — это конгломерат всех витрин данных предприятия, а информация всегда хранится в параметрической модели (dimensional model) (ее еще иногда называют «моделью измерений»). На практике большинство существующих хранилищ данных ближе к парадигме Кимбалла — хранилища начинали строить по инициативе отдельных департаментов, и изначально, по сути, они были витринами данных, не охватывая предметную область всей корпорации. По мере развития эти витрины данных эволюционировали в хранилища данных [1]. В этой связи можно считать, что путь Инмона революционен, поскольку предполагает, что все информационные системы будут уничтожены и на их месте будет построено что-то единое для всей территориально-распределенной структуры.

Сегодня предприятия вкладывают большие средства в построение хранилищ, однако отчеты о победах на фронте внедрения единых информационных систем — лишь капля в море незавершенных проектов по созданию единых согласованных источников данных; по мнению аналитиков Gartner, в 2007 году более половины проектов по созданию хранилищ данных потерпят неудачу. В различных источниках можно найти множество правильных советов, как не сорвать план по построению единого хранилища данных масштаба предприятия, однако обратим внимание на подход Кимбалла к решению этой проблемы.

По словам самого Кимбалла, его позиция совпадает с тем, к чему приходят люди, которые не читали его книг, но долго занимались созданием хранилищ данных. Действительно, наиболее простой путь — делать витрины данных по мере необходимости и на основе тех источников, которые требуются на текущий момент. За последнее десятилетие в этой отрасли уже сложились свои стандарты и так называемые «лучшие практики». Обычно это толстые книги, где по шагам описано, что и как надо сделать, что не забыть, как поступить в том или ином случае [2, 3]. Более того, ряд предприятий, уже использующих хранилища данных, заказывают работы по переписыванию своих информационных систем — не с целью ускорить их функционирование, а для достижения их соответствия «лучшим практикам» за счет включения более совершенных средств очистки, таблиц сопоставления ключей в исходной базе и ключей в хранилище, подробного документирования вплоть до схем алгоритмов хранимых процедур и т.д.

Хранилища для государственных структур

В государственных структурах, например в МВД РФ (конкретнее — для подразделения ОБНОН, в котором требуется объединение информации из различных источников), несмотря на попытки создания единых территориально-распределенных систем информационного обеспечения, в подразделениях ведомства пользуются привычными упомянутыми ранее унаследованными информационно-аналитическими системами, предоставляющими примерно одинаковые функции:

  • описание типа информации (физические лица, юридические лица, адреса и т.д.) с указанием реквизитов (город, улица, дом и т.д.);
  • ввод данных;
  • построение и выполнение нерегламентированных (ad hoc) запросов без программирования;
  • представление сформированной семантической сети в виде диаграммы.

С помощью этих систем ведется накопление не только актуальных, но и исторических данных, например, один и тот же человек за свою жизнь может сменить несколько фамилий, несколько паспортов, несколько мест жительства и каждое такое изменение отражается в виде добавления нового значения, допустим, атрибута МЕСТО ЖИТЕЛЬСТВА у объекта типа ФИЗИЧЕСКОЕ ЛИЦО. Другими словами, между объектом и значением атрибута реализовано отношение «многие ко многим» (рис. 1).

Рис. 1. Модель хранения данных об объектах и их атрибутах
Переводя модель хранения, представленную на рис. 1, на язык модели измерения, тип объекта можно считать фактом, а атрибуты — измерениями. На реляционном уровне данная модель изображается в виде таблицы фактов, таблиц измерений и сопоставительных таблиц (bridge table) (рис. 2).
Рис. 2. Проблема множественности значений измерений
Принимая во внимание всю важность накопления сведений об изменениях характеристик объектов учета, надо отметить, что на практике для анализа чаще всего используется актуальное состояние объекта. В этом случае — когда хранятся все исторические данные, а требуются только последние, — некоторые виды анализа (например, OLAP) затруднены, поскольку дополнительные сопоставительные таблицы замедляют выполнение поисковых запросов данного типа. Таким образом, в отдельных случаях необходимо построение дополнительной витрины данных, в которой таблица фактов будет ссылаться только на одно, актуальное, значение измерения (рис. 3).
Рис. 3. Параметрическая модель
Пример построения хранилища

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

Все данные в хранилище представлены параметрической моделью — каждая запись из таблицы фактов ссылается на записи в таблицах измерений (схема «звезда»). Если фактом считать звонок с одного телефона на другой, то измерениями будут номер телефона исходящего звонка, номер телефона входящего звонка, время начала разговора и т.д. Дополнительной информацией о каждом номере телефона является ФИО физического лица, за которым закреплен данный номер.

Согласно Кимбаллу, далее нужно выгрузить данные из каждого источника и после необходимых преобразований поместить их в область хранения. Эти действия обычно по расписанию выполняются процедурами ETL (Extraction, Transformation, Loading — «извлечение, преобразование, загрузка»). Чаще всего данные выгружаются в файл, но не все, а только те, которые добавились или изменились со времени последней выгрузки. При этом выполняются следующие преобразования:

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

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

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

Некоторые из перечисленных преобразований уже реализованы в системах учета, используемых в структурах МВД (имеются встроенные средства загрузки данных, ряд средств очистки и т.д.), поэтому для быстрого достижения результата (построения витрины данных, объединяющей несколько источников) можно воспользоваться имеющейся в подразделениях информационно-аналитической системой в качестве «области хранения» (data staging area). Если информационно-аналитическая система выступает в качестве источника данных и в качестве области хранения (рис. 4), то выгрузка содержимого всех таблиц в файл .csv неудобна, так как это может привести к потере логической целостности. Лучше воспользоваться средствами информационно-аналитической системы — выгрузить все новые, а также изменившиеся документы в файл формата .xml.

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

В случае успешной идентификации двух объектов и их объединения в один объект происходит удаление второго и перенаправление атрибутов (рис. 5) и связей на первый объект.

Рис. 5. Удаление дубликатов объектов
Ввиду того, что сам поиск дубликатов и указанные преобразования на реляционном уровне осуществить довольно сложно, более простым решением будет воспользоваться процедурой, уже реализованной в информационно-аналитической системе. Отдельным вопросом является работа со словарями. Если они построены в соответствии с рекомендациями Кимбалла, согласно которым факты ссылаются на измерения, то следует рассмотреть три типа модификаций: изменение значения измерения; добавление нового значения в таблицу измерений; добавление нового столбца в таблицу измерений. Добавление нового столбца в таблицу измерений необходимо для того, чтобы можно было анализировать «альтернативную реальность» — как со значением из одного столбца, так и со значением из другого столбца. Большинство информационных систем, используемых сегодня в структурах МВД, не позволяют накапливать информацию о версиях — обычно в них реализовано только изменение и добавление словарных значений.
Рис. 6. Визуализация витрины данных
Для некоторых видов анализа не требуется производить все действия, приведенные ранее для справки. В рассматриваемом случае (телефонные звонки) наиболее важным для принятия решения видом интеллектуальной обработки является визуализация собранных данных и представление всех телефонных звонков в виде диаграммы связей (рис. 6). Для получения такой диаграммы во многих информационно-аналитической систем МВД есть соответствующие инструменты. Однако, для других видов анализа, предоставляемых такими программными продуктами, как Cognos ReportNet, Business Objects и т.д., наиболее эффективным будет построить хранилище данных в полном соответствии с рассмотренными выше рекомендациями.

Заключение

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

Литература

  2. Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite, The Data warehouse toolkit: expert methods for designing, developing, and deploying data warehouses. Wiley Computer Publishing, 1998.
  3. Ralph Kimball, Margy Ross, The data warehouse toolkit: the complete guide to dimensional modeling. — 2nd ed. Wiley Computer Publishing, 2002.

Виктор Борисов (vict@relex.ru) — зав. отделом НПП «Релэкс» (Воронеж).

«Релэкс» и МВД

Компания «Релэкс» разрабатывает СУБД ЛИНТЕР, которая является единственной на сегодняшний день сертифицированной на наивысший класс защиты данных БД. Компания занимается разработкой приложений для государственных структур, в том числе МВД, куда поставляется, в частности, продукт НЕВОД, появившийся в результате сотрудничества с такими подразделениями МВД как ГУБОП, РУБОП, УБОП и ОБНОН. Опыт взаимодействия с представителями этих подразделений показал, что многие из них разрабатывают собственные хранилища данных, а централизованное внедрение ПО постоянно проваливается. Отсюда следует, что в государственных структурах, как и в бизнесе, создание хранилищ согласно парадигме Инмона часто заканчивается неудачей, а более практичная парадигма Кимбалла доказывает свою жизнеспособность. В подразделениях МВД логичнее создавать витрины данных на местах, а затем их интегрировать.