Разработка архитектуры репозитория - Разработка прототипа веб-приложения "Репозиторий электронных ресурсов"

Архитектура системы (в данном случае) - это описание (модель) основной компоновки и взаимодействия частей системы. В разделе показана структура взаимодействия основных компонентов системы.

Определение позиции хранилища данных в архитектуре системы

Система предназначена для поиска электронных ресурсов в уже существующей файловой системе, которая и является хранилищем документов. Для хранения метаданных документа и данных о работе системы необходимо использовать базы данных. Совокупность баз данных и файловой системы представляет собой хранилище данных. Пользовать взаимодействует с базой данных при помощи интерфейса, поэтому общая архитектура системы ни что иное, как интерфейс взаимодействия пользователя с базой данных (рис. 3.5) [14].

Общая архитектура информационно-поисковой системы

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

В служебной базе данных хранится:

Служебная информация о системе и о ее модулях;

Данные о пользователях (рис. 3.6).

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

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

Функциональные требования определяют наличие поиска по определенным параметрам:

По названию документа;

По типу документа;

По автору;

По названию издания/учебно-методического материала/контрольно-измерительного материала в содержании документа;

По периоду публикации (диапазон дат, а именно годов);

По тематике (в соответствии с классификатором УДК).

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

На основе приведенных результатов предлагается следующая архитектурная модель хранилища данных в информационно-поисковой системе (рис. 3.7).

Рисунок 3.7. Архитектурная модель хранилища данных информационно-поисковой системы

Определение функциональных модулей репозитория

В настоящее время процесс работы с документами организован с использованием классической архитектуры "Файл-сервер" (рис. 3.8).

классическое представление архитектуры

Рисунок 3.8. Классическое представление архитектуры "Файл-сервер"

Таким образом, сервер осуществляет хранение данных и кода программы, а клиент производит обработку данных. У такого типа архитектуры имеются как достоинства, так и недостатки, которые представлены в таблице 3.2.

Таблица 3.2. Достоинства и недостатки архитектуры "Файл-сервер"

Достоинства архитектуры

Недостатки архитектуры

Многопользовательский режим работы с данными.

Проблемы многопользовательской работы с данными: последовательный доступ, отсутствие гарантии целостности.

Удобство централизованного управления доступом.

Низкая производительность (зависит от производительности сети, сервера, клиента).

Низкая стоимость разработки.

Плохая возможность подключения новых клиентов.

Высокая скорость разработки.

Ненадежность системы.

Невысокая стоимость обновления и изменения ПО.

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

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

представление многоуровневой архитектуры

Рисунок 3.9. Представление многоуровневой архитектуры "Клиент-сервер"

Информационно-поисковая система разделена на следующие модули, размещение которых возможно на разных площадках, исходя из такого представления архитектуры:

Консоль администратора (позволяет конфигурировать систему и вводить данных о пользователях).

Модуль управления (представляет собой набор скриптов и прикладной интерфейс взаимодействия (API)). Содержит следующие функциональные модули:

Модуль "искателя" документов;

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

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

После выбора источника, компонент искателя собирает из него данные для анализа и индексации.

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

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

Модуль извлечения текста;

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

Модуль обработки текста на ЕЯ;

Выполняет следующие операции по обработке текста:

Нормализует символы текста, а именно приводит все символы к нижнему регистру.

Обрабатывает с использованием методов лингвистического анализа, которые включают в себя:

Графематический; на выходе - отдельно выделенные элементы структуры текста;

Морфологический; на выходе - определенные морфологические характеристики слова и его словоформы;

Синтаксический; на выходе - синтаксическая зависимость слов в предложении

Этапы обработки текста на ЕЯ

Все результаты обработки в результате сохраняются в служебной БД.

Модуль индексации;

Существует два варианта построения индекса:

Полное построение индекса, когда считываются все данные, которые собрал искатель и, которые были проанализированы анализаторами.

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

Модуль поиска;

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

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

Модуль ввода данных.

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

Пользовательский интерфейс(позволяет пользователю взаимодействовать с базой данных, используя доступ к модулю управления).

Сервер с СУБД.

Схема потоков данных информационно-поисковой системы

Для выбора подходящей системы управления базами данных требуется произвести анализ существующих СУБД с точки зрения следующих критериев:

Бесплатная лицензия;

Производительность (скорость обработки запросов влияет на скорость выдачи результата поиска);

Надежность (обеспечивает целостность данных);

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

Поддержка операционной системы MS Windows 7 и более поздних версий.

Похожие статьи




Разработка архитектуры репозитория - Разработка прототипа веб-приложения "Репозиторий электронных ресурсов"

Предыдущая | Следующая