Способ обработки поисковых запросов для нескольких реляционных баз данных произвольной структуры Российский патент 2020 года по МПК G06F16/901 G06F16/9032 G06F16/9038 

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

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

Наиболее близким к предложенному изобретению является система, раскрытая в патенте РФ на изобретение RU2703350, опубликованном 16.10.2019, в котором раскрывается механизм обработки поискового запроса в системе, использующей базы данных, представляющие информацию в различных форматах. Известный способ обеспечивает поиск информации на основе индивидуальных предпочтений пользователя. Недостатком указанного способа является вероятность недостоверного представления информации в случае использования системы неквалифицированным пользователем, а также невозможность объединения баз данных в одной системе.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

Настоящее изобретение позволяет осуществлять организацию поиска баз данных, а также процедуры проведения поиска. Поиск проводится в закрытой и упорядоченной системе с несколькими реляционными базами данных. Каждая запись из базы данных отнесена к одному определенному классу, имеющему уникальную предварительно заданную кодировку. Запись, которая имеет предварительно заданную кодировку, может иметь несколько возможных вариантов представления для проведения поисковых запросов. Для записи, а также для классов и баз данных имеется предпочтительная форма представления. Формы представления индексируются. При формировании поискового запроса производится, по возможности, трансляция терминов естественного языка запроса в заданную кодировку. Термины естественного языка индексируются. При наличии нескольких вариантов трансляции, все они используются для поиска, в частном случае, путем генерации нескольких параллельных поисковых запросов. Результаты поиска отображаются вместе с формой представления базы данных, в которой найдена уникальная запись. При отсутствии результатов, пользователь уведомляется о том, в каких базах данных обнаружены «близкие результаты», и, после указания базы данных, пользователь уведомляется о том, какие поисковые термины отсутствуют в записях базы данных. Наиболее близкие результаты не отображаются, отображаются только точные результаты. По результатам уточнения, формируются результаты поиска.

КРАТКОЕ ОПИСАНИЕ ГРАФИЧЕСКИХ МАТЕРИАЛОВ

Фиг. 1 иллюстрирует упрощенный пример аппаратной реализации предложенной системы;

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

Фиг. 3 иллюстрирует примерный вариант блок-схемы реализации предложенного способа;

Фиг. 4 иллюстрирует примерный вариант схемы взаимодействия пользователя с элементами описываемой системы, реализующей предлагаемый способ;

Фиг. 5 иллюстрирует примерный вариант архитектуры системы, реализующей предлагаемый способ;

Фиг. 6 иллюстрирует примерный вариант визуального представления онтологической модели;

Фиг. 7 иллюстрирует примерный вариант осуществления обработки поискового запроса;

Фиг. 8 иллюстрируется примерный вариант оценки и пример процесса обработки поискового запроса в целом.

ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ ИЗОБРЕТЕНИЯ

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

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

Как показано на Фиг. 1, примерная компьютерная сеть 900 может содержать множество сетевых устройств, таких как маршрутизаторы, коммутаторы, компьютеры и тому подобное, связанных между собой линиями связи. Например, множество сетевых устройств может соединять одно или несколько пользовательских устройств 910 (или «клиентских устройств» 910), которые могут использоваться пользователем, таких как компьютеры, смартфоны, планшеты и т.д. Каналы связи, соединяющие различные сетевые устройства, могут быть проводными линиями или общими средами (например, беспроводными линиями), где определенные устройства могут поддерживать связь с другими устройствами на основе расстояния, уровня сигнала, текущего рабочего состояния, местоположения и т.п.

Каналы связи могут соединять различные сетевые устройства в любой возможной конфигурации. Один или несколько серверов 920 (например, хост-серверы, веб-серверы, базы данных и т.д.) могут поддерживать связь с сетью 900 и, таким образом, с множеством клиентских устройств 910. Специалистам в данной области техники будет понятно, что в компьютерной сети может использоваться любое количество и расположение узлов, устройств, линий связи и т. д., а иллюстрация, показанная на фиг. 1 является упрощенным примером аппаратной реализации системы.

Пример вычислительной системы, пригодный для реализации элементов предложенного изобретения, показана на Фиг. 2. Как показано на фиг. 2, вычислительная система содержит вычислительное устройство 1000, которое может использоваться в качестве устройства пользователя или сервера, в памяти 1040 которого хранятся операционная система 1042, компьютерные программы 1044 и структуры данных 1045. Память 1040 устройства 1000 связана шиной 1050 с источником питания 1060, по крайней мере, одним процессором 1020 и, по крайней мере, одним сетевым интерфейсом 1010, осуществляющим передачу данных в сеть 900 (Фиг. 1) и из сети 900 (Фиг.1).

Фиг. 3 иллюстрирует вариант блок-схемы реализации предложенного способа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для описания онтологий могут формироваться базы знаний.

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

Извлечение данных из информационных систем, реализованных с применением реляционных СУБД (систем управления базами данных), возможно различными способами, например, с использованием SQL-запросов (SQL Структурированный язык запросов к базам данных) или SPARQL-запросов (SPARQL Язык запросов к данным, представленным по модели RDF (от англ. Resource Description Framework –модель для представления данных, в частности, метаданных. RDF является стандартом для кодирования семантическом вебе (Semantic Web).), а также протокол для передачи этих запросов и ответов на них).

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

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

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

На Фиг. 5 показан примерный вариант архитектуры системы, реализующей предлагаемый способ.

Как показано на Фиг. 5 в рамках осуществления настоящего изобретения осуществляется кэширование данных (535, 545), передаваемых, по крайней мере, в одну семантическую базу данных 515 и, по крайней мере, в одну реляционную базу данных 505. В рамках осуществления настоящего изобретения осуществляется формирование онтологии (семантическая модель предметной области) 555, например, в автоматизированном режиме (средствами описываемой системы) или пользователями, например, аналитиками 525, в частности, на основе понимания сути предметных областей и с учётом фактически имеющихся данных по этим предметным областям в существующих информационных системах. С использованием (в частности, на основе) онтологии аналитиками 525 создаётся мэппинг на реляционные базы данных 505 существующих информационных систем, который позволяет осуществлять создание SQL-запросов и объединять их результаты. В частном случае, построение SQL-запросов определяется формируемыми аналитиками 525 SPARQL-запросами, т.е. в зависимости от того, какие данные необходимы, на основе единого мэппинга (от англ. mapping) осуществляется создание наиболее эффективного SQL-запроса.

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

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

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

Классы сущностей могут включать, например:

- Персонал:

- Пилоты/ летные экипажи (командир, другие лица летного состава);

- Бортпроводники / кабинные экипажи;

- Визовые данные персонала;

- Воздушные суда:

- Воздушные суда (ВС);

- Модели воздушных судов;

- Типы воздушных судов;

- Рейсы:

- Линии;

- Расписание рейсов;

- Проблемы с рейсами (задержки, отмены);

- Контрагенты и договоры:

- Данные контрагентов;

- Договоры и дополнительные соглашения.

На Фиг. 6 показан примерный вариант визуального представления онтологической модели.

Онтологическая модель предметной области может быть сохранена в файле, например, в формате OWL (от англ. Web Ontology Language – язык описания онтологий для семантической сети. Язык OWL позволяет описывать классы и отношения между ними, присущие веб-документам и приложениям).

После создания онтологической модели осуществляется создание мэппинга на существующие реляционные базы данных (505) информационных систем. Для каждого класса сущностей в общем случае создано по одному мэппингу, и для каждого объектного свойства (object property) также осуществляется создание собственного (своего) мэппинга. Мэппинг может быть сохранен, по крайней мере, в одном файле, например, в одном из известных форматов, например, в формате OBDA, причем файл мэппинга может содержать мэппинг для классов сущностей и объектных свойств.

На Фиг. 7 показан примерный вариант осуществления обработки поискового запроса.

В шаге 717 пользователь вводит запрос (поисковый запрос) с использованием интерфейса пользователя (графическом интерфейсе пользователя – GUI, от англ. graphical user interface - графический интерфейс пользователя), в частности в строке поискового запроса (строке поиска, поисковой строке).

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

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

Ключевые слова в нормальной форме с указанием части речи (PoS – Part of Speech) являются результатом удаления «информационного шума». Приведение слов в запросе к нормальной форме может быть выполнено в самом начале шага 727 для осуществления поиска по словарям (синонимов и имен собственных) в нормальной форме.

В частном случае после получения нормальных форм слов осуществляется получение перечня синонимов осуществляется с использованием способов (в частности, по крайней мере, одного из известных) лингвистической обработки. Так, например, для контрагента синонимами могут являться ИНН, компания, предприятие, company; для договора - контракт, соглашение, допник, дополнительное соглашение, КАСУД, документ; для ВС (воздушного судна) - самолет, борт, борты, plane, ac, воздушное судно; для рейса - рейсы, рейсов, авиарейс, расписание, расписания, вылеты; для полета - вылеты, полеты, отправления, прилет, flights; для задержек - Delays, опоздания, задержанные рейсы; для отмененного полета - отменен, отмена, перенесенный, cancelled, cancel; для сотрудника - сотрудник, экипаж, пилот, персонал, паспорт, загран, виза, табельный номер и т.д.

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

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

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

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

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

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

[QueryItem="ВсеЛинии"]

PREFIX : <http://www.моякомпания.рф/моякомпания#>

SELECT *

WHERE {

?Линия :Линия_ID ?ID .

?Линия :Линия_КодАэропорты ?КодАэропорты .

?Линия :Линия_КодГорода ?КодГорода .

?Линия :Линия_КодОбратныеГорода ?КодОбратныеГорода .

?Линия :Линия_КодВидаРейса ?ВидРейса .

?Линия :Линия_ЦелевойРегион ?ЦелевойРегион .

}

Для применения фильтра SPARQL-запрос содержит маркер для замены подстроки на конкретное значение из поискового запроса. Маркер для замены может быть выделен одним из известных символов, например, символом «@», в начале и в конце, и включается в условие фильтрации (FILTER regex(?КодАэропорты, "@КодАэропорта@", "i")), как показано в примерном запросе ниже:

[QueryItem="ВсеЛинии"]

PREFIX : <http://www.моякомпания.рф/моякомпания#>

SELECT *

WHERE {

?Линия :Линия_ID ?ID .

?Линия :Линия_КодАэропорты ?КодАэропорты .

FILTER regex(?КодАэропорты, "@КодАэропорта@", "i") .

?Линия :Линия_КодГорода ?КодГорода .

?Линия :Линия_КодОбратныеГорода ?КодОбратныеГорода .

?Линия :Линия_КодВидаРейса ?ВидРейса .

?Линия :Линия_ЦелевойРегион ?ЦелевойРегион .

}

«@КодАэропорта@» перед исполнением запроса заменяется на конкретный IATA-код аэропорта (код аэропорта ИАТА — трехбуквенный уникальный идентификатор, присваиваемый аэропортам мира международной ассоциацией воздушного транспорта), присутствующий в поисковом запросе пользователя, например, SVO (Шереметьево) или VKO (Внуково). Использование символа «"i"» позволяет реализовать поиск, не учитывающий регистр символов.

Для указания поиска подстроки (непустой связной части строки, например, введенной в поле формы в качестве поискового запроса) могут быть использованы различные, в том числе известные, условия регулярных выражений. Регулярные выражения являются формальным языком поиска и осуществления манипуляций с подстроками в тексте, основанным на использовании метасимволов (от англ. wildcard characters). Для поиска используется строка-образец или маска (от англ. pattern), состоящая из символов и метасимволов и задающая правило поиска. В частном случае поиска подстроки может быть указано ".*Подстрока.*", а для указания любых значений (если условие не задано пользователем в поисковом запросе) может быть использовано ".*".

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

Таблица 1 сопоставления ключевых слов и сущностей.

№ Онтологический класс Ключевые слова 1. ВС Самолет, борт, воздушное судно, ВС, воздушный, транспорт 2. Модель ВС Модель, Модель ВС 3. Авиалиния Линия, авиалиния, направление 4. Аэропорт Аэропорт, порт, город, терминал 5. Контрагент Контрагент, ИНН, компания, предприятие, ООО, ОАО, ЗАО, ПАО 6. Пилот Пилот, лётчик, КВС, второй пилот, командир 7. Договор Договор, соглашение, допсоглашение, контракт 8. Дополнительное соглашение Доп, допсоглашение, допник

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

Таблица 2 сопоставления сущностей и SPARQL-запросов.

№ Онтологический класс Основной SPARQL-запрос Дополнительные SPARQL-запросы 1. ВС Поиск воздушного судна по условиям Поиск модели воздушного судна
Поиск типа воздушного судна
Поиск маршрутов, в которых задействовано воздушное судно 2. Модель ВС Поиск модели воздушного судна по условиям Поиск типа воздушного судна
Поиск перечня воздушных судов по модели 3. Авиалиния Поиск авиалинии по аэропорту Поиск информации по аэропорту начала и его терминалам
Поиск информации по аэропорту конца и его терминалам
Поиск статистики по авиалинии Поиск авиалинии по городу 4. Аэропорт Поиск аэропорта по условиям Поиск терминалов аэропорта
Поиск города, страны и региона, в которых расположен аэропорт 5. Контрагент Поиск контрагента по названию Поиск договоров контрагента
Поиск статистики договоров по контрагенту
Поиск дополнительных соглашений по договорам 6. Пилот Поиск пилота по имени Поиск наград пилота
Поиск обучения пилота
Поиск допусков пилота 7. Договор Поиск договора по дате Поиск дополнительных соглашений, связанных с основным договором
Поиск информации по контрагенту
Поиск статистики по договорам Поиск договора по контрагенту 8. Дополнительное соглашение Поиск доп. соглашения по контрагенту

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

На выходе из третьего этапа осуществляется получение перечня SPARQL-запросов, которые могут быть исполнены.

На Фиг. 8 показан примерный вариант оценки и пример процесса обработки поискового запроса в целом.

В шаге 818 осуществляется получение поискового запроса, например, «Рейсы из Уфы».

В шаге 828 осуществляется выделение ключевых слов «рейс» и «Уфа».

В шаге 838 осуществляется распознавание имен собственных в ключевых словах, в частности, осуществляется поиск имен собственных в словарях имен, фамилий и отчеств (ФИО), городов, полетов, названий самолетов кодов рейсов. Так, осуществляется распознавание «Уфа» в словаре городов.

В шаге 848 осуществляется выбор подходящих SPARQL-запросов, в частности:

1. Рейсы из города N

2. Количество рейсов из города N

3. Параметры аэропорта N,

где вместо «N» осуществляется подстановка значения «Уфа».

В шаге 858 осуществляется оценка ранга каждого запроса как функции важности сущности и степени соответствия запросу пользователя, так первые два запроса (с подставленным значением «Уфа»: «Рейсы из города Уфа» и «Количество рейсов из города Уфа») имеют одинаковое соответствие, так что пользователю предъявляются результаты обоих запросов. Третий запрос имеет соответствие ниже, так как слово «рейс» не связано с запросом.

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

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

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

"Карточка", например, "карточка" контрагента может включать общие сведения о контрагенте; блок «Банковские реквизиты»; Блок переключаемых вкладок: «Показатели» (связанные с договорами данного контрагента); «Договоры» (данного контрагента); «Проверка контрагента» (показатели надежности организации); «Связанные организации» (список аффилированных организаций, в том числе входящих в состав контрагентов компании).

Вкладка «Показатели» может содержать данные о деятельности контрагента, например, представленные в форме графиков: доля контрагента в своей категории, например, доля на текущий год; динамика доли контрагента в своей категории; динамика количества договоров с контрагентом по годам; динамика суммы договоров контрагента по годам.

Вкладка «Договоры» может содержать список договоров контрагента, упорядоченных по дате заключения (от последних к первым), при этом закрытые договоры отображаются в самом низу списка. По каждому договору может быть раскрыт список дополнительных соглашений, при наличии таковых.

Вкладка «Проверка контрагента» может содержать результаты проверки надежности данного контрагента, полученные из сторонней ИС: общий результат (например, «Требуется проверка»); списки обнаруженных по контрагенту факторов: стоп-факторов, факторов риска, факторов надежности.

Вкладка «Связанные организации» может содержать перечень организаций, аффилированных с контрагентом, а также сводные значения показателей по данным организациям (по тем из них, которые также являются контрагентами).

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

«Карточка» договора может содержать полный набор данных о договоре; список всех имеющихся для него дополнительных соглашений (отображаются в карточке как список, по каждому дополнительному соглашению (допсоглашению) может быть открыта подробная карточка).

«Карточка» дополнительного соглашения может содержать полный набор данных о допсоглашении: данные об основном договоре (состав данных по аналогии со списком договоров).

При осуществлении и обработке поисковых запросов запросы могут быть сформулированы, например, как «Полеты из Москвы», «Полеты Москва Париж», «Вылеты из Шереметьево» и т.д. для запроса (списка) полетов. Причем запрос, например, для полетов, может иметь следующий формат (состав) [полет/синонимы] {название города} или [полет/синонимы] {название города 1} {название города 2}, или [полет/синонимы] {название аэропорта}, или [полет/синонимы] {название аэропорта 1} {название аэропорта 2}. Результатом обработки таких запросов являются предъявляемые пользователю данные, например, в формате таблицы полетов (отдельных выполненных рейсов, с фильтрами и т.д.) всех вылетов из аэропорта, всех прилетов в аэропорт.

Список результатов может группироваться по направлению полетов. Так, например, для запроса «полеты Москва Париж» осуществляется отображения результатов, например, в двух таблицах полетов: Москва – Париж и Париж-Москва. Полеты из различных аэропортов города вылета (либо в различные аэропорты города прилета) также могут быть разделены в результатах поиска. Если указан один город, то отображаются полеты из этого города (в любой город); и полеты в этот город (из любого другого города).

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

Фильтры по таблице:

- аэропорт вылета. По умолчанию выбран первый, содержащийся в поисковом запросе. Может быть выбран любой другой или нейтральный вариант «Любой аэропорт»;

- аэропорт прилета. По умолчанию выбран второй, содержащийся в поисковом запросе (если имеется). Может быть выбран любой другой или нейтральный вариант «Любой аэропорт».

- фильтр по номеру рейса (по вхождению подстроки);

- полеты: выполненные / запланированные (переключатель);

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

- задержки (выбор из списка): «Неважно» / «Отсутствуют» / «Любые задержки» / «Задержки взлета» / «Задержки отправления» / «Задержки прибытия».

При осуществлении поиска сотрудника по фамилии и идентификаторам запросы могут быть сформулированы, например, как «Пилот Козлов Москва», «Сотрудник 2345 123456», «Виза 4235467».

Запроса для поиска сотрудника может иметь следующий формат [сотрудник/синонимы] {фамилия сотрудника на русском} {имя сотрудника на русском} {название города проживания сотрудника}, причем каждая переменная опциональна, или [сотрудник/синонимы] {фамилия сотрудника на английском} {имя сотрудника на английском}, причем каждая переменная опциональна, или [сотрудник/синонимы] {табельный номер сотрудника}, или [сотрудник/синонимы] {номер договора с сотрудником}, или [сотрудник/синонимы] {номер паспорта РФ сотрудника}, или [сотрудник/синонимы] {номер заграничного паспорта сотрудника}, или [сотрудник/синонимы] {страна визы сотрудника} {номер визы сотрудника}.

«Карточка» сотрудника может содержать следующие составные части:

- общие сведения о сотруднике, например, ФИО сотрудника, должность сотрудника, дата увольнения, место жительства, дата рождения, возраст, пенсия, допуски, налет общий, налет КВС, трудовой договор с периодом действия, табельный номер, стаж;

- блок переключаемых вкладок: «Основное» (сведения о должностях, обучении, достижениях, персональные данные); «Документы»; «Допуски и налет»; «Нарушения»; «Рейсы».

Вкладка «Основное» может содержать указанные ниже данные:

- таблица должностей в компании «Аэрофлот» (АФЛТ) от последней до первой;

- документы об образовании;

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

- список поощрений;

- персональные данные.

Вкладка «Документы» может содержать указанные ниже данные:

- перечень документов кадрового учета по сотруднику (от последнего до первого);

- данные паспорта;

- данные заграничного паспорта;

- данные по действующим визам (упорядочены по дате истечения действия, по убыванию);

- данные по недействующим визам (упорядочены по дате истечения действия, по убыванию).

Вкладка «Нарушения» может содержать, например, таблицу взысканий.

Вкладка «Рейсы» может содержать, например, таблицу рейсов, на которых работал сотрудник.

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

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

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

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

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

определяют заранее заданные формы отчетов, использующих найденные релевантные записи; и

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

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

3. Способ по п. 1, отличающийся тем, что отображение результатов предусматривает возможность использования более одной формы отчетов для одной записи.

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

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

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

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