Размещено на http://www.allbest.ru/

3

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

Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

Индексации хранилища текстов на основе естественно-языковой адресации

Симонова Наталья Андреевна

Пермь, 2018 год

Аннотация

В данной работе представлены результаты реализации модуля программной системы для проведения лингвистических исследований, обеспечивающего хранение, поиск и получение текстов из корпусов с использованием индексации на основе естественно-языковой адресации в виде wcf-сервиса. Были проанализирован подход к хранению корпусов в существующих программных продуктах, а также документо-ориентированные СУБД для хранения текстовой информации. Анализ показал необходимость разработки специального модуля с применением индексации. Во второй главе приведен анализ проектирования баз данных и архитектуры, а также технико-экономическое обоснование. Далее описаны реализация, тестирование и публикация wcf-сервиса на Azure.

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

Работа включает 48 страниц основного текста, 31 иллюстрацию, 17 таблиц, 4 приложения. Библиографический список - 27 наименований.

2018 г. Кафедра информационных технологий в бизнесе.

Оглавление

• модуль программный индексация лингвистический
• Введение
• Глава 1.Задача хранения корпусов текстов
• 1.1.Существующие решения для задач корпусной лингвистики
• 1.1.1.Приложение AntConc
• 1.1.2.Приложение CQPweb
• 1.1.3.Библиотека Corsis
• 1.1.4.Семейство GATE
• 1.1.5.Сравнение инструментов
• 1.2.Инструменты для решения задач хранения текстовых документов
• 1.2.1.СУБД MongoDB
• 1.2.2.СУБД OrientDB
• 1.2.3.СУБД Azure Cosmos DB
• 1.2.4.Сравнение документо-ориентированных СУБД
• 1.3.Индексация на основе естественно-языковой адресации
• 1.4.Технология Windows Communication Foundation
• 1.5.Технология Entity Framework
• 1.6.Требования к сервису-хранилищу текстов
• Глава 2.Проектирование хранилища текстов
• 2.1.Проектирование работы сервиса
• 2.2.Проектирование баз данных
• 2.3.Диаграмма классов
• 2.4.Архитектура системы
• 2.5.Технико-экономическое обоснование
• 2.6.Итоги проектирования
• Глава 3.Реализация сервиса для хранения корпусов
• 3.1.Реализация CRUD-функций
• 3.2.Реализация индексации на основе естественно-языковой адресации
• 3.3.Публикация сервиса
• Глава 4.Тестирование
• 4.1.Функциональное тестирование
• 4.2.Интеграционное тестирование
• 4.3.Тестирование индексации на основе естественно-языковой адресации
• Заключение
• Библиографический список
• Приложение
• 

Введение

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

С развитием вычислительной техники появилась возможность автоматически обрабатывать большие массивы документов, поэтому своё развитие получила корпусная лингвистика, которая исследует особенности языка на основе корпусов - наборов текстов, собранных по определенному критерию, например, единому стилю или автору [6]. На основе таких наборов можно выявлять закономерности языка, собирая статистические данные. Такие закономерности или стандартные приемы были выявлены и для научного стиля в английском языке. Примером такой закономерности может быть более частое использование пассивного залога, чем в общей речи [26]. Однако данный вопрос только решается лингвистами и исследование не завершено.

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

Существующие программные продукты (GATE, AntConc и др.) созданы для использования только специалистами-лингвистами и не пригодны для использования непрофессионалами. GATE представляет собой группу программных продуктов, включая настольные, облачные, серверные версии с возможностью расширения функциональности через плагины. Однако параллельная работа с корпусами возможна только, если пользователь устанавливает персональный сервер для хранения данных, а облачная версия может использоваться только как механизм распределенной обработки в виде сервиса [10, 18].

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

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

Для обеспечения таких возможностей данным программам необходимо хранить как отдельные тексты, загружаемые студентами, так и целые корпусы для их дальнейшего исследования. Иногда корпусы могут достигать значительного объема, и поэтому необходимы эффективные алгоритмы поиска по документам, так как в неструктурированных данных поиск может обернуться последовательным перебором. Одним из возможных решений является использование индексации на основе естественно-языковой адресации, которая подразумевает использование цифровых кодов букв в качестве индекса [2, 24].

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

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

Целью работы является разработка модуля для хранения, поиска и получения текстов из корпусов с использованием индексации на основе естественно-языковой адресации в виде web-сервиса.

В соответствии с целью были сформулированы следующие задачи:

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

2. Произвести проектирование web-сервиса для хранения корпусов:

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

2.2. Произвести моделирование статической структуры системы.

2.3. Произвести проектирование архитектуры системы.

3. Реализовать web-сервис для хранения корпусов:

3.1. Реализовать CRUD-функции для корпусов и документов.

3.2. Реализовать индексацию на основе естественно-языковой адресации.

3.3. Произвести функциональное и интеграционное тестирование.

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

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

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

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

Глава 1. Задача хранения корпусов текстов

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

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

1. Возможность хранения больших объемов данных, которая становится всё более важной для задач корпусной лингвистики.

2. Скорость доступа к данным, которая должны быть высокой, так как корпусы и их метаинформация могут достигать большого объема.

3. Формат данных, так как открытость используемых структур является преимуществом для современных систем.

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

1.1 Существующие решения для задач корпусной лингвистики

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

Существует большое количество программных систем для корпусных исследований. Некоторые из них, например AntConc [10], предоставляют различные возможности для исследования текста, однако являются настольными, не имеют встроенных корпусов и возможности многопользовательской работы. Другие приложения для корпусных исследований имеют web-интерфейс, однако большинство из них закреплено за одним или несколькими корпусами (CQPweb [19]). Также существуют бесплатные библиотеки (Corsis [13]) с предоставляемыми программами с пользовательским графическим интерфейсом. Эти программы могут быть использованы только для работы с корпусами пользователя, расположенными на локальном компьютере.

1.1.1 Приложение AntConc

Настольное приложение AntConc не использует базы данных для хранения корпусов, а работает с неаннотированными текстами в текстовом формате, загружая их сразу в оперативную память. Для хранения некоторых результатов работы, например ключевые слова в формате KWIC [23], AntConc использует реляционную СУБД SQLite, без использования какого-либо индексирования. Позиционируя себя как приложения для работы с небольшими корпусами, AntConc не имеет возможности работать с корпусами большого объема из-за использования оперативной памяти, а поиск по документам не ускоряется за счет индексации [10].

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

1.1.2 Приложение CQPweb

Приложение СQPweb построена на двух отдельных технологиях: IMS Open Corpus Workbench и реляционной базе данных MySQL. IMS Open Corpus Workbench (CWB) - это набор программных инструментов с открытым исходным кодом для управления большими корпусами и созданием запросов. CWB использует специальную модель данных (см. рис. Рисунок 1.1) и основанный на ней открытый XML формат данных, а документы в данном формате, после обработки помещаются в базу данных MySQL [19].

Главным преимуществом CQPweb является его гибкость; его более обобщенная модель данных делает его совместимым с любым корпусом. Варианты анализа, доступные в CQPweb, включают: согласование; коллокации; таблицы и диаграммы распределения; списки частот; и ключевые слова или ключевые теги. Система CQPweb же позволяет делать различные запросы к 45 готовым корпусам через веб-интерфейс, однако она не предоставляет возможности работы с новыми корпусами.

Рисунок 1.1. Пример модели данных CWB



1.1.3 Библиотека Corsis

Corsis - это бесплатная библиотека для анализа корпусов с открытым исходным кодом, написанная на языке C#. Также бесплатно предоставляется кросс-платформенный графический интерфейс для работы с библиотекой. Для хранения документов данная библиотека использует XML-основанные файлы. Программа, основанная на данной библиотеке, не использует базу данных, а работает напрямую с XML-основанными файлами, загружая их сразу в оперативную память [13].

Библиотека и программа Corsis являются простыми и открытыми инструментами для простого анализа небольших корпусов, например, составления списка слов и конкорданса.

1.1.4 Семейство GATE

Описанные выше приложения, не считая библиотек, не имеют интерфейсов прикладного уровня, то есть не могут быть настроены под определенные задачи. Таким функционалом, помимо широких встроенных функций для обработки текстов, обладает GATE, один из существующих инструментов для корпоративных исследований. Семейство GATE - это группа программного обеспечения, включающая настольные, облачные, серверные версии с возможностью расширения функциональности через плагины [14, 18].

В продуктах GATE вся информация о документах хранится в открытых форматах XML или OWL в специальных базах данных с реализацией индексов MG4J [15]. MG4J является еще одним решением для полнотекстового поиска в больших документах с использованием методов сжатия c инвертированным индексом [12]. Основным ограничением такого подхода по-прежнему можно назвать память, необходимую для индексов, хотя в современных версиях продуктов GATE она не столь критична [15]. Тем не менее, необходимый объем памяти для реализации MG4J больше, чем гипотетический необходимый объем памяти для индексации на основе естественно-языковой адресации.

GATE Teamware (рис. Рисунок 1.2) - сетевая программная система с открытым исходным кодом для совместной работы над корпусными исследованиями. Однако параллельная работа с корпусами требует установки пользователем персонального сервера для хранения данных и дополнительного администрирования, а облачная версия используется только как сервис распределенной обработки [11].

Рисунок 1.2. GATE Teamware

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

1.1.5 Сравнение инструментов

В таблице Таблица 1.1 приведено сравнение подходов к хранению корпусов и текстов у существующих решений по ранее выделенным критериям.

Таблица 1.1. Сравнение существующих решений

Критерий	AntConc	CQPweb	Corsis	Gate
			Библиотека	Программа
Возможность хранения больших объемов данных	Нет, так как не использует БД, загружает в оперативную память	Да	Является библиотекой	Нет, так как не использует БД, загружает в оперативную память	Да
Скорость доступа к данным	Высокая, так как работа происходит в оперативной памяти	Достаточно высокая за счет использования CWB		Высокая, так как работа происходит в оперативной памяти	Достаточно высокая за счет использования MG4J
Формат данных	Только txt	XML	XML	XML или OWL
Объем дополнительной памяти	Дополнительная память не нужна	Нужна дополнительная память для модели CWB	Является библиотекой	Дополнительная память не нужна	Нужна дополнительная память для индексов MG4J

Приложение CQPweb может быть использовано только для работы со встроенными, заранее обработанными корпусами, поэтому самым эффективным решением является семейство GATE. Однако и GATE, и CQPweb задействуют дополнительную память для ускорения доступа к данным.

1.2 Инструменты для решения задач хранения текстовых документов

В связи с необходимостью хранить и обрабатывать большое количество текстовой информации, было принято решение использовать документо-ориентированную СУБД (один их NoSQL подходов), так как она обеспечивает более простую работу с неструктурированными текстовыми данными, а также многие NoSQL базы специально разработаны для хранения крупных объемов данных с более простой поддержкой масштабирования.

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

Документо-ориентированные базы данных хранят и обрабатывают документы - иерархические самоописываемые структуры данных, обычно хранящиеся в форматах ХМL, JSON, BSON и др. Такие базы данных хранят в себе агрегаты данных, состоящих из скалярных значений, ассоциативных массивов и коллекций. Документы в таких базах данных хранятся в качестве значений, доступных по уникальному ключу, однако открытость структуры позволяет создавать запросы и к части содержимого документа, не загружая его полностью [9].

Основными представителями таких СУБД можно назвать MongoDB, OrientDB, а также предоставляемую порталом Azure CosmosDB и другие.

1.2.1 СУБД MongoDB

Одной из самых популярных документно-ориентированных СУБД является MongoDB, предоставляющая широкие возможности формирования запросов с помощью специального языка, хранения документов в формате JSON или BSON и индексацию. Данная СУБД поддерживает работу на кластерах благодаря специальному механизму асинхронной синхронизации (репликация), а так же обеспечивает масштабируемость, в том числе шардинг [9]. MongoDB является бесплатным продуктом с открытым исходным кодом, написанным на языке C++.

Для работы с базой MongoDB предоставляет специальный язык запросов, позволяющий добавлять, удалять и изменять документы, а также искать документы по некоторым условиям [9].

1.2.2 СУБД OrientDB

OrientDB - это свободно распространяемая СУБД, объединяющая в себе документо- и графо-ориентированные СУБД. OrientDB, как и любая другая документо-ориентированная СУБД, позволяет хранить и обрабатывать документы, но также OrientDB поддерживает хранение отношений между документами. Данная СУБД хранит документы в формате JSON и дает возможность проводить некоторые запросы к базе на SQL и с помощью Gremlin.

Данная СУБД имеет малый размер и обеспечивает простую установку, а новый подход к связям (с помощью указателей) позволяет увеличить скорость доступа к данным. Также OrientDB СУБД имеет REST-архитектуру, поддерживает трензакции и некоторую другую функциональность [9].

1.2.3 СУБД Azure Cosmos DB

В мае 2017 года появилось новое решение Azure Cosmos DB - база данных как сервис, предоставляемая Azure для студентов бесплатно по специальной подписке, которая расширяет предыдущий проект DocumentDB. Данная СУБД поддерживает различные варианты NoSQL, в том числе и документно-ориентированный. С помощью предоставляемого API c данными в Cosmos DB можно работать как посредством SQL и LINQ, так и посредством языка MongoDB и др.

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

1.2.4 Сравнение документо-ориентированных СУБД

Так как все рассмотренные СУБД имеют все необходимые функции , то их сравнение было проведено по нефункциональным критериям:

1. Поддержка различных языков запросов.

2. Простота развертывания на сервере.

3. Цена доступа.

4. Простота взаимодействия с СУБД.

Результаты сравнения представлены в таблице Таблица 1.2.

Таблица 1.2. Сравнение документо-ориентированных СУБД

	Поддержка различных языков запросов	Простота развертывания на сервере	Цена доступа	Простота взаимодействия с СУБД
MongoDB	-	-	+	-
OrientDB	±	-	+	±
Cosmos DB	+	+	±	+

Для разрабатываемого сервиса была выбрана Cosmos DB в качестве СУБД для хранения документов, так как данная СУБД уже является сервисом, не требует сложных настроек, поддерживает различные языки, хоть и предоставляется только по подписке.

1.3 Индексация на основе естественно-языковой адресации

Несмотря на то, что современные документо-ориентированные СУБД имеют инструменты для эффективного поиска данных, доступных по ключам, полнотекстовый поиск может иметь недостаточную производительность. Последовательное чтение текстового файла (чтобы найти конкретное ключевое слово) является медленной операцией, и каждый индексированный подход будет быстрее [5, 24].

Таким образом, применение индексации на основе естественной языковой адресации должно повысить производительность СУБД для полнотекстного поиска, однако, как и для любой индексации, это потребует дополнительных ресурсов: памяти для хранения дополнительной информации и времени на обработку. Главным преимуществом данного подхода является отсутствие необходимости хранения дополнительных индексов, так как индексами служат сами ключевые слова, то есть если стандартная схема поиска информации выглядит как «Имя-Адрес-Маршрут» (Что мы ищем? Где мы ищем? Как туда попасть?), то при использовании индексации на основе естественной языковой хранить адрес нет необходимости (так как он совпадает с именем), и схема сокращается до «Имя-Маршрут» [24].

При использовании индексации на основе естественно-языковой адресации необходима специальная модель данных, которой была выбрана многодоменная информационная модель, основанная на многоуровневых множествах. Доступ до информации, хранимой для слова “beer” представлен на рисунке Рисунок 1.3 [24].

Рисунок 1.3. Доступ к информации на основе естественно-языковой адресации

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

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

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

Одним из отличий данной структуры является то, что деревья разработаны для хранения информации в ограниченной оперативной памяти, а для реализации естественно-языковой адресации была создана подобная структура для хранения на постоянном запоминающем устройстве [24].

Естественно-языковая адресация применялась в графовых базах данных или RDF-репозиториях, основанных на тройках данных (объект-связь-субъект) [24].

Применение индексации в системе ICON на основе естественно-языковой адресации показало следующие преимущества:

· Линейная алгоритмическая сложность.

· Уменьшение необходимой памяти, так как нет необходимости хранить индексы отдельно [22].

1.4 Технология Windows Communication Foundation

Модуль для хранения корпусов и текстов реализован с помощью технологии Windows Communication Foundation (WCF), которая является основой для создания web_сервисов. В отличие от обычного сервиса, WCF позволяет иметь несколько точек доступа, поддерживает сессии на уровне сервиса, а не метода, позволяет использовать различные протоколы и предоставляет некоторые другие расширенные возможности. В качестве хостинга для WCF-сервиса может выступать любое приложение [27].

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

1.5 Технология Entity Framework

При работе с реляционной базой данных используется технология ORM Entity Framework, которая позволяет работать с облачной базой данных SQL Azure [17], как с локальной. Использование Entity Framework обусловлено рядом преимуществ:

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

2. Поддержка LINQ (строгая типизация, проверка запросов на этапе компиляции).

3. Быстрота написания запросов.

4. Поддержка транзакций и параллелизма [20].

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

1.6 Требования к сервису-хранилищу текстов

На основе проведенного анализа сформированы требования к разрабатываемой программе:

1. Сервис должен быть опубликован на облачной платформе Azure.

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

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

4. В качестве нереляционной СУБД должна быть использована документо-ориентированная Azure Cosmos DB.

5. В качестве нереляционной СУБД должна быть использована SQL Azure c помощью технологии Entity Framework.

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

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

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

9. Функциональные требования представлены на диаграмме прецедентов (рис.Рисунок 1.4).

Полное описание прецедентов приведено в приложении А.



Рисунок 1.4. Диаграмма прецедентов

Сервис должен обеспечить возможность выполнения перечисленных ниже функций:

1. Создание/удаление/изменение корпусов текстов.

2. Добавление/удаление/изменение документов в корпусы.

3. Добавление информации о пользователе (регистрация пользователя).

4. Удаление/изменение информации о пользователе.

5. Получение информации о пользователе.

6. Получение информации о документе.

7. Получение информации о корпусе.

8. Поиск документов в базе.

9. Поиск документов по ключевым словам.

Полные требования к системе приведены в приложении B.



Глава 2. Проектирование хранилища текстов

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

2.1 Проектирование работы сервиса

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

Добавление информации о пользователе (регистрация нового пользователя) представлено на рисунке Рисунок 2.1.

Рисунок 2.1. Добавление нового пользователя

Изменение информации о пользователе представлено на рисунке Рисунок 2.2.



Рисунок 2.2. Изменение информации о пользователе

Удаление информации о пользователе представлено на рисунке Рисунок 2.3.

Рисунок 2.3. Удаление информации о пользователе

Получение информации о пользователе представлено на рисунке Рисунок 2.4.

Рисунок 2.4. Получение информации о пользователе



Добавление информации о корпусе (создание нового) представлено на рисунке Рисунок 2.5.

Рисунок 2.5. Добавление информации о корпусе

Изменение информации о корпусе представлено на рисунке Рисунок 2.6.

Рисунок 2.6. Изменение информации о корпусе

Удаление информации о корпусе представлено на рисунке Рисунок 2.7.



Рисунок 2.7. Удаление информации о корпусе

Получение информации о корпусе представлено на рисунке Рисунок 2.8.

Рисунок 2.8. Получение информации о корпусе

Удаление документа представлено на рисунке Рисунок 2.9.



Рисунок 2.9. Удаление информации о документе

Изменение документа представлено на рисунке Рисунок 2.10.

Рисунок 2.10. Изменение информации о документе

Получение документа представлено на рисунке Рисунок 2.11.



Рисунок 2.11. Получение информации о документе

Поиск документа по ключевым словам представлен на рисунке Рисунок 2.12.

Рисунок 2.12. Поиск документа по ключевым словам

Поиск документов по названию представлен на рисунке Рисунок 2.13.



Рисунок 2.13. Поиск документов по названию

Для функции добавления документа было выполнено проектирование работы сервиса в виде диаграммы активностей (рис. Рисунок 2.14).

Рисунок 2.14. Добавление документа

2.2 Проектирование баз данных

На основе поведенного анализа были выделены сущности предметной области. Результаты представлены в виде ERD на рисункеРисунок 2.15.



Рисунок 2.15. Диаграмма сущность-связь

Были выделены следующие сущности и атрибуты:

1. Пользователь с информацией о ФИО, электронной почтой, логине и пароле пользователя.

2. Корпус с информацией о названии корпуса.

3. Документ, содержащий оригинальный файл, плоский текст, аннотацию, строку HTML-разметки и название.

Информация о пользователях и корпусах содержится в реляционной СУБД (рис. Рисунок 2.16), а также ключи нереляционной части хранящихся документов в корпусах (DocumentId), названия документов и оригинальный файл.

Рисунок 2.16. Схема реляционной базы данных



Работа с реляционной базой данной осуществляется с помощью Entity Framework, ниже представлена получившаяся модель (рис. Рисунок 2.17).

Рисунок 2.17. Entity Designer Diagram

В документо-ориентированной базе данных хранится информация о документах. Так как документы в документо-ориентированных СУБД не имеют четкой структуры, была определена примерная схема информации, которая будет храниться в формате JSON (рис. Рисунок 2.18).

Рисунок 2.18. Примерная структура документа в документо-ориентированной базе данных

Гибкость структуры позволит хранить любую дополнительную информацию о документе помимо определенной выше.

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



2.3 Диаграмма классов

Следующим этапом проектирования стало создание диаграммы классов (рис. 2.19). Диаграмма классов контракта сервиса включает в себя классы для работы с выделенными сущностями: User, Document, Corpus, а также интерфейс сервиса.

Рисунок 2.19. Диаграмма классов

ICorporaStorageServise - интерфейс-контракт сервиса (CorporaStorageServise), описывающий доступные другим сервисам операции:

1. AutorizeUser(string Login, string Password) : User - возвращает информацию о пользователе по логину и паролю.

2. GetCorpora(int UserId) : Corpus[] - возвращает список всех корпусов пользователя.

3. GetDocuments(int CorpusId) : Document[] - возвращает список всех документов в корпусе.

4. GetDocument(int Document) : Document - возвращает информацию о документе.

5. MakeCorpus(string Name, Document[] documents) : int - создает общий корпус с выбранными документами (можно создать и пустой корпус, передав пустой массив).

6. MakeCorpus(string Name, Document[] documents, int UserId) : int - создает частный корпус с выбранными документами (можно создать и пустой корпус, передав пустой массив).

7. AddUser(User user) : int - регистрация нового пользователя.

8. UpdateUser(User user) : void - изменение информации о пользователе. По старому идентификатору обновляются все поля.

9. DeleteUser(int userId) : void - удаление информации о пользователе по идентификатору. При этом происходит удаление всех корпусов пользователя.

10. AddDocument(Document document) : int - добавление нового документа.

11. UpdateDocument(Document document) : void - изменение документа. По старому идентификатору обновляются все поля.

12. DeleteDocument(int documentId) : void - удаление документа по идентификатору.

13. UpdateCorpus(Corpus corpus) : void - изменение корпуса. По старому идентификатору обновляются все поля.

14. DeleteCorpus(int corpusId) : void - удаление корпуса по идентификатору. При этом происходит удаление всех документов корпуса.

15. FindDocuments(string Name, int corpusId) : Document[] - поиск документа по имени.

16. FindText(string Text) : Document[] - поиск фрагмента по документам.

Диаграмма классов (рис. Рисунок 2.20.) сервиса включает в себя вспомогательные классы для работы с базами данных: UserModel, DocumentModel, CorpusModel - классы для работы с реляционной базой данной с помощью Entity Framework; AzureDocument - класс для работы с документо-ориентированной базой данных.



Класс реализации сервиса помимо реализации контракта имеет различные вспомогательные методы.

Рисунок 2.20. Диаграмма классов реализации сервиса

Классы для работы с индексацией (рис. Рисунок 2.21) на основе естественно-языковой адресации включают в себя классы структуры индексов: NLAStructure и NLAHeadDocument, которые включают в себя словарь ссылок на класс IndexStructureObject.

Рисунок 2.21. Диаграмма классов для работы с индексацией



Словарь (Dictionary) был выбран, так как его можно сериализовать в формате JSON, а также скорость доступа Dictionary не сильно уступает стандартной реализации хэш_таблицы (Hashtable), а для типов-значений скорость даже превосходит, так как в основе обоих структур лежит хеш-таблица [8, 16].

IndexStructureObject содержит следующий уровень структуры и/или ссылки на идентификаторы документов, в которых содержится соответствующее ключевое слово. Класс NLAStructureHelper содержит методы для добавления идентификатора документа к соответствующему ключевому слову, а также удаления идентификатора документа из всей структуры. Также в классе NLAStructureHelper содержаться вспомогательные методы.

2.4 Архитектура системы

При создании системы в отдельные функциональные блоки были выделены:

1. Компонент для стемминга текста.

2. Контракты сервиса.

3. Реляционная база данных

4. Нереляционная база данных.

5. Сам сервис.

Для описания архитектуры системы была создана диаграмма компонентов, представленная на рисунке 2.22.



Рисунок 2.22. Диаграмма компонентов сервиса-хранилища

CorporaStorageServise.svc - компонент реализации сервиса, который использует библиотеку с контрактом сервиса (CorporaStorageServiseContract.dll), то есть с описанием его интерфейса, а также общую библиотеку (CommonLibrary.dll), в которую войдут все необходимые для реализации стандартов взаимодействия классы.

Для хранения реляционных данных будет использоваться также располагаемая на сервисах Azure база данных SQL Azure (RelationDatabase), предоставляемая как сервис. DocumentDatabase - Cosmos DB, нереляционная база данных как сервис для хранения документов. Также используется сторонняя реализация стеммера по алгоритму стемминга Портера (Stemmer.dll).

2.5 Технико-экономическое обоснование

Стоимость разработки программы составит 40 486 рублей, а её расчет и обоснование выбранных инструментальных средств приведены в приложении C. Расчет стоимости проводился по методологии Work Breakdown Structure (WBS) или иерархическая структура работ. Данная методология была выбрана исходя из текущей стадии жизненного цикла программы, а также она не требует накопленной статистики. Данная методология обладает преимуществами для небольших проектов с небольшим количеством участников, а именно:

1. Не требует сильных затрат.

2. Позволяет увеличить производительность и контроль [25].

2.6 Итоги проектирования

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

Выделенные методы контракта сервиса покрывают все функциональные требования. Также выделение контрактов в отдельные библиотеки позволяет использовать класс ChannelFactory при работе с сервисом.



Глава 3. Реализация сервиса для хранения корпусов

Сервис для хранения корпусов был реализован как WCF-сервис на языке C#, при этом в качестве интегрированной среды разработки программы была использована среда Visual Studio 2017.

3.1 Реализация CRUD-функций

При реализации CRUD функций были использованы API используемых баз данных (Cosmos DB и SQL Azure), а также технология Entity Framework и LINQ для работы с реляционной базой данных. Для увеличения производительности Entity Framework время жизни контекста ограничивался методом сервиса.

CRUD-функций для пользователя и корпуса, а также реляционная часть документа реализуются с помощью LINQ-запросов. Например, добавление пользователя происходит следующим образом (рис. Рисунок 3.1):

Рисунок 3.1. Добавление пользователя

При добавлении или изменении пользователя происходит проверка другого наличия пользователя с таким логином (рис. Рисунок 3.2):

Рисунок 3.2. Проверка наличия другого пользователя с таким логином

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

Для нереляционной части документа используется предоставляемая Microsoft библиотека клиента Azure Cosmos DB, которая позволяет добавлять, удалять, изменять документы из коллекции, а также выполнять LINQ-запросы к документам. Например, добавление документа представлено на рисунке Рисунок 3.3.

Рисунок 3.3. Добавление документа в документо-ориентированную базу данных

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

3.2 Реализация индексации на основе естественно-языковой адресации

Была реализована многомерная древовидная структура в виде многоуровневой хеш-таблицы на основе стандартного класса Dictionary<Tkey, TValue>. Ключом была выбрана подстрока из трех символов. Так как обработка текста и структуры индексов занимает достаточно большое время, данные операции проводятся в отдельных потоках, завершение которых необязательно для завершения метода.

При добавлении нового документа его плоский текст обрабатывается следующим образом для добавления ключевых слов в структуру для индексации на основе естественно-языковой адресации:

1. Очищение текста от знаков препинания и стоп-слов.

2. Стемминг - выделение основ ключевых слов при помощи дополнительной библиотеки.

3. Добавление основы каждого ключевого слова в структуру индексации.

При добавлении в структуру производятся следующие действия:

1. Загружается из документо-ориентированной базы данных файл с соответствующим корнем дерева и десериализуется.

2. Для каждой трехбуквенной (последняя может быть меньше) подстроки с начала слова:

2.1. Получается объект IndexStructureObject по данной подстроке-ключу в текущей структуре.

2.2. Если это последняя подстрока, то идентификатор документа добавляется к списку идентификаторов.

2.3. Иначе загружается или создается структура следующего уровня для данной подстроки, она становится текущей.

2.4. Изменения сохраняются.

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

3.3 Публикация сервиса

Для работы сервиса на портале Azure были созданы базы данных: реляционная SQL Azure и документо-ориентированная Cosmos DB. Таблицы реляционной СУБД создавались с помощью Entity Framework. В документо-ориентированной Cosmos DB были созданы две коллекции: для документов и для сериализованной структуры для индексации на основе естественно-языковой адресации. Далее с помощью предоставляемого Azure профиля публикации веб-приложения и встроенных средств Visual Studio сервис опубликован и доступен по ссылке: https://papercatdatastorage.azurewebsites.net/CorporaStorageService.svc.



Рисунок 3.4. Опубликованный сервис

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



Глава 4. Тестирование

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

4.1 Функциональное тестирование

На этапе функционального тестирования проводилось тестирование основных функций сервиса по методу черного ящика:

1. Добавление нового пользователя.

Результаты тестирования добавления информации о пользователе представлены в таблице Таблица 4.1.

Таблица 4.1. Тестирование добавления информации о пользователе

№	Входные данные	Ожидаемый результат	Реальный результат
1	null	Ошибка «Параметр не может быть null»	Ошибка «Параметр не может быть null»
2	User{ FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login”, Password = “Password”}	В базу данных добавлена информация о пользователе с FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login”, Password = “Password”. UserId сгенерирован	В базу данных добавлена информация о пользователе с FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login”, Password = “Password”. UserId сгенерирован (1)
3	User{UserId = 0, FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login3”, Password = “Password3”}	В базу данных добавлена информация о пользователе с FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login3”, Password = “Password3”. UserId сгенерирован	В базу данных добавлена информация о пользователе с FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login3”, Password = “Password3”. UserId сгенерирован (2)
4	User{ Email = “email@email.com”, Login = “Login4”, Password = “Password4”}	В базу данных добавлена информация о пользователе с Email = “email@email.com”, Login = “Login”, Password = “Password”. UserId сгенерирован	В базу данных добавлена информация о пользователе с Email = “email@email.com”, Login = “Login”, Password = “Password”. UserId сгенерирован (3)
5	User{ Email = “email@email.com”, Password = “Password”}	Ошибка валидации Entity Framework	Ошибка валидации Entity Framework
6	User{UserId = 0, FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login” (Уже существует в БД), Password = “Password”}	Ошибка «Пользователь с таким логином уже существует»	Ошибка «Пользователь с таким логином уже существует»

2. Удаление информации о пользователе.

Результаты тестирования удаления информации о пользователе представлены в таблице Таблица 4.2.

Таблица 4.2. Тестирование удаления информации о пользователе

№	Входные данные	Ожидаемый результат	Реальный результат
1	UserId = 0 (Пользователя с таким id в базе данных нет)	Нет действий	Нет действий
2	UserId = 1 (Пользователь без корпусов)	Удаление информации о пользователе с UserId = 1 из базы данных	Удаление информации о пользователе UserId = 1 из базы данных
3	UserId = 2 (Пользователь с одним корпусом)	Удаление информации о пользователе с UserId = 2 из базы данных, удаление связанного корпуса	Удаление информации о пользователе с UserId = 2 из базы данных, удаление связанного корпуса
4	UserId = 3 (Пользователь с тремя корпусами)	Удаление информации о пользователе с UserId = 3 из базы данных, удаление связанных корпусов	Удаление информации о пользователе с UserId = 3 из базы данных, удаление связанных корпусов



3. Изменение информации о пользователе.

Результаты тестирования изменения информации о пользователе представлены в таблице Таблица 4.3.

Таблица 4.3. Тестирование изменения информации о пользователе

№	Входные данные	Ожидаемый результат	Реальный результат
1	null	Ошибка «Параметр не может быть null»	Ошибка «Параметр не может быть null»
2	User{ FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login”, Password = “Password”}	Ошибка «Такого пользователя не существует»	Ошибка «Такого пользователя не существует»
3	User{UserId = 0, FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login3”, Password = “Password3”}	Ошибка «Такого пользователя не существует»	Ошибка «Такого пользователя не существует»
4	User{ UserId = 3, Email = “email2@email.com”, Login = “Login4”, Password = “Password4”}	В базе данных изменена информация о пользователе с UserId = 3 на Email = “email2@email.com”, Login = “Login”, Password = “Password”	В базе данных изменена информация о пользователе с UserId = 3 на Email = “email2@email.com”, Login = “Login”, Password = “Password”
5	User{ UserId = 3, Email = “email@email.com”, Password = “Password”}	Ошибка валидации Entity Framework	Ошибка валидации Entity Framework
6	User{UserId = 3, FIO = “Фамилия Имя Отчество”, Email = “email@email.com”, Login = “Login” (Уже существует в БД), Password = “Password”}	Ошибка «Другой пользователь с таким логином уже существует»	Ошибка «Другой пользователь с таким логином уже существует»

4. Авторизация пользователя (получение информации о пользователе).

Результаты тестирования авторизации пользователя представлены в таблице Таблица 4.4.



Таблица 4.4. Тестирование авторизации пользователя

№	Входные данные	Ожидаемый результат	Реальный результат
1	Login = “Login4”, Password = “Password”	null	null
2	Login = “Login4”, Password = “Password4”	User { UserId = 4, FIO = null, Email = “email2@email.com”, Login = “Login4”, Password = “Password4”}	User { UserId = 4, FIO = null, Email = “email2@email.com”, Login = “Login4”, Password = “Password4”}

5. Добавление корпуса.

Результаты тестирования добавления корпуса представлены в таблице Таблица 4.5.

Таблица 4.5. Тестирование добавления корпуса

№	Входные данные	Ожидаемый результат	Реальный результат
1	MakeCorpus(Name = “TestName”, Documents = null, UserId = 0)	В базу данных добавлен общий корпус без документов с названием “TestName”	В базу данных добавлен общий корпус без документов с названием “TestName”
2	MakeCommonCorpus(Name = “Test2Name”, Documents = null)	В базу данных добавлен общий корпус без документов с названием “Test2Name”	В базу данных добавлен общий корпус без документов с названием “Test2Name”
3	MakeCorpus(Name = “Test3Name”, Documents [ { DocumentId = 0, FlatText = "Another",

Страница:

•  1 
•  2 
•  3 

дипломная работа "Индексации хранилища текстов на основе естественно-языковой адресации" скачать

Подобные документы

• Система семантического разбора для естественно-языковых текстов

  Понятие семантики; обзор и анализ существующих средств семантического разбора естественно-языковых текстов. Разработка алгоритма работы системы на основе семантического анализа, его реализация на языке программирования; проектирование интерфейса системы.
  
  дипломная работа [1,7 M], добавлен 18.03.2012
  

• Система контент-анализа естественно-языковых текстов

  Морфологические анализаторы (морфологизаторы) на различных языках программирования. Анализ методов и технологий автоматической обработки ЕЯ-текстов. Разработка модуля графематического анализа и создания таблицы лексем. Программная реализация классов.
  
  дипломная работа [3,0 M], добавлен 06.03.2012
  

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

  Проект экспериментального программного комплекса индексирования и поиска неструктурированной текстовой информации в многоязычной среде, состоящего из математических моделей, алгоритмов и программных средств. Исследование характеристик его эффективности.
  
  автореферат [296,5 K], добавлен 31.01.2012
  

• Конструкция корпусов ПК

  Что такое компьютерный корпус. Компьютерный корпус служит для монтажа компонентов компьютерной системы. Какие моменты следует учесть при покупке корпуса. Компоненты. Стандарты корпусов BTX: подробности о новом форм-факторе. Ценовые категории.
  
  курсовая работа [5,1 M], добавлен 04.04.2006
  

• Форматы команд. Способы адресации данных

  Изучение базовых команд ПК на базе МП i286 и их форматов. Изучение прямых способов адресации данных. Наработка практических навыков работы с командами. Разработка регистровой модели выполнения операций передачи данных. Программа реализации команд.
  
  контрольная работа [42,2 K], добавлен 12.03.2011
  

• Программная обработка текстов на естественном языке

  Функциональные возможности, преимущества и недостатки существующих лингвистических процессоров. Проектирование интерфейса взаимодействия облачного хранилища с лингвистическим процессором и компонентов доступа к сервисам. Программный продукт IKVM.NET.
  
  дипломная работа [2,0 M], добавлен 21.09.2016
  

• Интернет, системы адресации. Информационная система "Кадровый учет"

  Возникновение и функции интернета. Системы адресации и протоколы передачи данных. Структура иерархической базы данных. Формирование базы данных учета сотрудников организации, создание таблиц с тремя видами запросов на выборку, конструктор отчетов.
  
  контрольная работа [885,8 K], добавлен 10.11.2010
  

• Анализ тональности текстов на основе ДСМ-метода

  Описание ДСМ-метода автоматического порождения гипотез. Исследование результатов влияния компонентов ДСМ-метода на качество определения тональности текстов. Алгоритм поиска пересечений. N-кратный скользящий контроль. Программная реализация ДСМ-метода.
  
  курсовая работа [727,0 K], добавлен 12.01.2014
  

• Способы обработки данных

  Алгоритм обработки при работе с массивом, типизированным файлом и динамическим списком. Применение для массивов и типизированных файлов произвольной адресации элементов, для динамических списков - последовательной адресации. Блок-схема и текст программы.
  
  реферат [63,5 K], добавлен 24.05.2013
  

• Проектирование корпоративной информационной системы предприятия

  Разработка структуры корпоративной информационной системы ООО НПО "Мир": создание схемы адресации, системы доменных имен; выбор программной и аппаратной конфигураций клиентских станций и развернутых серверов. Расчет стоимости программного обеспечения.
  
  курсовая работа [1,2 M], добавлен 20.02.2013
  

Другие документы, подобные "Индексации хранилища текстов на основе естественно-языковой адресации"

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам