Фреймворк интеграции поисковой машины в информационные системы Текст научной статьи по специальности «Компьютерные и информационные науки»

2. Приложение для управления совместной работой - Comindware [сайт]. URL:

http://www.comindware.com/ru (дата обращения: 12.04.2013).

3. Д. Пинаев. Процессное управление: в чем сила? // БОСС, № 3, 2012. URL:

http://www.bossmag.ru/archiv/2012/boss-03-2012-g/protsessnoe-upravlenie-v-chem-sila.html (дата обращения: 12.04.2013).

4. Ю. Вагнер. BPM без бизнеса // Открытые системы, № 2, 2012. URL:

http://www.osp.ru/os/2012/02/13014103 (дата обращения: 12.04.2013).

5. Руководство по продуктам Comindware [сайт]. URL:

http://www.comindware.com/ru/support/resources (дата обращения: 12.04.2013).

УДК 004.413

ФРЕЙМВОРК ИНТЕГРАЦИИ ПОИСКОВОЙ МАШИНЫ В ИНФОРМАЦИОННЫЕ

СИСТЕМЫ

Крылов Александр Юрьевич, студент, Ивановский государственный химико-технологический

университет, Россия, Иваново, [email protected] Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, [email protected]

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

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

Реализация поиска в современных ИС зачастую представляет собой отдельный функциональный модуль системы, направленный на решение данной задачи. Качество такого модуля во многом определяется результатами его работы: гибкостью, удобством, возможностями масштабирования, скоростью работы и т. д. С целью решения этих задач, разработчик прибегает к самостоятельной реализации таких модулей, которые, в свою очередь [2,3]:

• вынуждают разработчиков ИС повторно разрабатывать подсистему поиска (временные затраты) для каждой системы и типов документов;

• обладают низкой гибкостью и слабым функционалом, в силу того, что не являются основной целью разработки информационной системы;

• требуют технической поддержки и сопроводительной документации в течение всего процесса функционирования (эксплуатации);

• содержат различные ошибки в концепции, архитектуре или программной реализации;

• обладают недостаточной документацией;

• слабо стандартизированы;

• плохо пригодны к модификации, поскольку являются побочным результатом построения ИС.

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

В результате возможно создание некоторого универсального средства (инструмента), предназначенного для реализации поиска в целевой информационной системе, которое

61

значительно облегчило бы разработку поисковых подсистем и их последующую интеграцию в целевую ИС.

Создание такого инструмента позволит обеспечить:

• исключение необходимости повторно разрабатывать подсистему поиска для каждой новой системы;

• наличие единой и полной, а также регулярно обновляемой документации;

• отсутствие наиболее частых и распространенных ошибок, возникающих в процессе разработки и реализации поисковых систем;

• наличие технической поддержки.

Цель разработки данного инструмента (фреймворка) сводится к облегчению процесса разработки и интегрирования поискового функционала в информационную систему.

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

• разработать единую архитектуру поисковых подсистем;

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

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

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

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

• поисковой запрос — набор параметров (инструкция), с помощью которых осуществляется отбор документов;

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

• клиентская часть — часть поисковой подсистемы, выполняемая программным обеспечением, установленным на рабочей станции пользователя системы;

• серверная часть — часть поисковой подсистемы, выполняемая программным обеспечением сервера системы;

• пользователь системы — лицо, составляющее и инициирующее выполнение поискового запроса, а также использующее результаты его выполнения;

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

• программный каркас (фреймворк) — набор программных элементов и правил их использования для реализации поискового функционала.

Для создания целевого программного каркаса необходимо выделить определенные сходства поисковых подсистем, реализованных в рамках различных проектов (информационных систем).

Рассмотрим пример взаимодействия пользователя с поисковой подсистемой:

• пользователь формирует поисковой запрос, описывающий характеристики (параметры) интересующих его документов, предоставляя системе поисковой образ запроса искомого документа (ПОЗ), и инициирует выполнение запроса;

• система производит поиск и выборку документов, соответствующих тем или иным способом организованному поисковому образу документа (ПОД), и предоставляет

62

результаты пользователю;

• пользователь работает с результирующей выборкой документов, возможно, уточняя ПОЗ искомых документов.

Анализируя приведенный сценарий, можно утверждать, что типичная поисковая подсистема должна представлять собой реализацию:

• средств формирования поискового запроса;

• средств передачи поискового запроса поисковому движку;

• средств выполнения бизнес-логики и поиска;

• средств представления результатов поиска и работы с ними в удобной форме.

Обычно поисковая система оперирует документами определенного типа. Если же

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

Данный инструмент должен представлять определенную программную архитектуру, которой должна соответствовать поисковая система. Рассмотрим такую архитектуру на примере ИС, реализованных в виде web-приложения. В соответствии с этим, подсистема поиска, разработанная при помощи данного фреймворка, разделяется на две части: клиентскую и серверную. В данном случае, клиентская часть предоставляет пользователю средства формирования поискового запроса и просмотра результатов поиска (работы с ними). Серверная часть — реализует средства обработки (выполнения) пользовательского поискового запроса.

Рис. 1 - Компонентная структура серверной части подсистемы поиска

Данная часть системы содержит следующие компоненты:

63

• DocumentsManager - компонент, направленный на работу с документами, для которых производится поиск. Организует проверку прав доступа к определенным коллекциям, поиск документов, загрузку метаинфомрации документов и т.д.;

• CollectionsManager - компонент, направленный на работу с коллекциями, по которым производится поиск документов;

• Query — структура. Содержит в себе поисковой образ документа, а так же некоторые параметры, касающиеся сортировки результатов поиска, их максимальное количество, тип соответствия документа поисковому образу и т. д.;

• SearchEngine - компонент, инкапсулирующий в себя логику поиска, динамически подгружая соответствующий коллекции скрипт-обработчик, предназначеный для поиска по указанному типу документов и типу поискового запроса;

• DataSource - компонент, являющийся источником контента. Представляет собою прослойку между подсистемой поиска и базой данных ИС, частью которой он является;

• SecurityManager - компонент, отвечающий за доступ текущего пользователя к той или иной информации (коллекциям, документам);

• SettingsManager - компонент, содержащий в себе параметры/настройки. Такие, как лимит документов-результатов поиска по умолчанию, степень соответствия по умолчанию, сортировка по умолчанию и т. д.

На рис.1 представлена структура серверной части подсистемы поиска. Клиентскую часть подсистемы поиска должна содержать в себе следующие компоненты.

Средства формирования поискового запроса. Представляют собой элементы системы генерации пользовательского интерфейса, предназначенного для редактирования описания поискового образа документа;

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

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

Архитектура разрабатываемой системы должна обеспечивать распределенность, слабую связанность, а так же взаимозаменяемость компонентов системы, оснащенных стандартизированными интерфейсами. Данные задачи позволяет решить следующий подход к разработке решения:

• использование сервис-ориентированной архитектуры [5];

• разработка решения в соответствии со стандартом REST [6].

Преимуществами такого подхода будут являться:

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

• независимость серверной части системы от механизмов поиска, специфических для каждого из используемых в системе форматов документов;

• независимость серверной части системы от типа и формата используемых информационных ресурсов.

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

64

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

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

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

• конфигурируемостью — параметры функционирования системы реализуются в общедоступных форматах (например, xml, json и т. д.), а также доступны для изменения при помощи модификации соответствующих конфигурационных параметров. Такой подход делает реализованную при помощи данного инструмента систему гибкой и конфигурируемой.

Литература

1. Д. Баженов. Архитектура поисковых систем // Блог Дениса Баженова [сайт]. URL: http://bazhenov.me/blog/2013/01/08/search-architecture.html (дата обращения 14.04.2013).

2. Разработка собственной поисковой системы с помощью PHP. URL:

http://www.ibm.com/developerworks/ru/library/os-php-sphinxsearch/ (дата обращения 14.04.2013)

3. Google AdSense [Материал из Википедии — свободной энциклопедии]. URL: http://ru.wikipedia.org/wiki/AdSense (дата обращения 14.04.2013).

4. Документальные информационные системы // ПИЭ/Wiki [сайт]. URL:

http://wiki.mvtom.ru/index.php/Документальные_информационные_системы (дата обращения 14.04.2013).

5. Сервис-ориентированная архитектура // CIT Forum [сайт]. URL: http://citforum.ru/internet/webservice/soa/ (дата обращения 14.04.2013).

6. Знакомьтесь, архитектура REST // Блог HTML-Templates.Info [сайт]. URL: http://html-templates.info/view blog.php?id=6 (дата обращения 14.04.2013).

УДК 004.652.5

МОДЕЛИ И МЕТОДЫ ПОСТРОЕНИЯ СИСТЕМЫ OLAP ДЛЯ ОБЪЕКТНООРИЕНТИРОВАННЫХ БАЗ ДАННЫХ1

Фисун Николай Тихонович, д.т.н., проф., зав. кафедры интеллектуальных информационных систем, ЧГУ им. П. Могилы, г. Николаев, Украина, [email protected]. [email protected] Горбань Глеб Валентинович, асп. кафедры интеллектуальных информационных систем, ЧГУ им. П.

Могилы, г. Николаев, Украина, [email protected]

Введение

В настоящее время в системах поддержки принятия решений (СППР) важное место занимают технологии оперативного (OLAP) и интеллектуального (Data Mining) анализа данных [1, 2]. Данные технологии уже реализованы в некоторых коммерческих системах управления базами данных (СУБД), таких как Microsoft SQL Server, Oracle и других, которые представляют собой реляционные СУБД.

Реляционные базы данных (БД) получили большой успех и на данный момент

1 Статья рекомендована к опубликованию в журнале "Информационные технологии"

65