Решение задачи поиска данных
|
Скачать 0.94 Mb.
|
СОДЕРЖАНИЕ
ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ БД – база данных; ДИПЯ – дескрипторный информационно-поисковый язык; ИС – информационная система; ИПС – информационно-поисковая система; ИПТ – информационно-поисковый тезаурус; ИПЯ – информационно-поисковый язык; ЛВС – локальная вычислительная сеть; ОС – операционная система; ПО – программное обеспечение; ПЭВМ – персональная электронная вычислительная машина; СУБД – система управления базами данных; ADO (ActiveX Data Objects) – технология доступа к данным; ASP (Active Server Pages) – активные серверные страницы; DAO (Data Access Object) – технология доступа к данным формата Access; DSN (Data Source Name) – имя источника данных; MS SQL Server (Microsoft SQL Server) – СУБД архитектуры клиент-сервер; ODBC (Open Database Connectivity) – протокол (интерфейс) взаимодействующий с открытыми базами данных; OLE DB (Object Linking and Embedding Database) – обмен информацией между базами данных; RDC (Remote Data Control) – управление удаленными данными; RDO (Remote Data Object) – объекты доступа к удаленным данным; SQL (Structured Query Language) – структурированный язык запросов; HTTP (Hyper Text Transfer Protocol) – протокол передачи гипертекста; XML (Extendable Markup Language) – язык разметки документов и обмена данными. ВВЕДЕНИЕ В современном обществе информация имеет огромное значение и представляет собой большие потоки данных, требующие надежного хранения, систематизации и поиска. Указанные задачи в той или иной степени решены многими разработчиками и реализованы в виде приложений различной структуры, работающих с текстовыми файлами, базами данных и документами Интернета [9-14]. Конкуренция среди фирм-разработчиков программного обеспечения привела к появлению множества форматов данных, с которыми работают коммерческие программы, например, doc, html, xls, поэтому возникает потребность в создании программного продукта, отличительной особенностью которого была бы возможность работы с различными типами файлов при поиске необходимой информации. Дипломная работа как раз и посвящена разработке средств автоматизации процессов поиска информации в документах разных форматов. Структурно пояснительная записка к работе включает в себя четыре главы и одно приложение, в котором приведен листинг разработанной программы. В первой главе анализируются структуры данных и принципы организации процессов поиска в информационных системах. Традиционными являются задачи поиска данных в файлах текстового формата (текстовых документах и файлах, содержащими тексты программ) и в документах формата HTML, а также в системах, использующих базы данных. В настоящее время достаточно широко используются системы для работы с базами данных, функционирующие в корпоративных сетях. В корпоративной сети данные находятся в ее узлах, при этом физически они могут находиться на компьютерах различных моделей и производителей, функционирующих под управлением различных операционных систем, доступ к данным может осуществляться разнородным программным обеспечением, а сами компьютеры могут быть значительно удалены друг от друга. Кроме того, локальные базы данных могут быть разноформатными вследствие создания их на протяжении значительных интервалов времени разными разработчиками. Таким образом, корпоративные базы данных по своей сути являются распределенными и гетерогенными. Основная задача при поиске информации в таких базах данных состоит в идентификации формата данных и обеспечении доступа к данным конкретного формата. Вторая глава посвящена решению задачи поиска данных в информационных системах. В ней осуществляется выбор способов поиска и доступа к данным различных форматов, а также рассматриваются основы разработки приложения для поиска информации. Третья глава является наиболее важной, в ней приводится программная реализация приложения, описывается структура программы поиска данных в информационных системах, рассматривается использование провайдеров для доступа к данным, а также использование дополнительных возможностей при работе с различными типами данных. Четвертая глава посвящена вопросам использования разработанного программного средства, применения приложения для поиска в информационных системах, оценки эффективности использования данного приложения. Здесь же приведены рекомендации по внедрению полученных результатов. Цель данной работы заключалась в создании универсального приложения, позволяющего обеспечить автоматизацию процесса поиска информации в документах разных форматов и пригодного для работы пользователей с небольшим опытом использования информационных технологий. 1. ОБОСНОВАНИЕ НЕОБХОДИМОСТИ РАЗРАБОТКИ СРЕДСТВ АВТОМАТИЗАЦИИ ДОСТУПА К ДАННЫМ, ПОСТАНОВКА ЗАДАЧИ 1.1. Анализ структуры и принципов организации данных различных форматов В процессе развития цивилизации объем научной и технической информации удваивался, начиная с 17 в., примерно каждые 10-15 лет. Поэтому одной из важнейших проблем человечества является рациональное использование огромных потоков информации в любой отрасли его жизнедеятельности. Подсчитано, например, что в настоящее время специалист должен тратить около 80% своего рабочего времени, чтобы уследить за новыми печатными работами в его области деятельности. Увеличение объемов информации и растущий спрос на нее обусловили появление отрасли техники, связанной с автоматизацией обработки информации – информатики, которая ставит проблему поиска и обработки информации на первое по важности место. Существует очень простое понятие данных как большого количества форматированного представления информации, которую пользователи могут получать, используя различные приложения. Универсальная программа для работы с данными и один тип представления информации выглядят идеальным вариантом, хотя на практике это решение по различным причинам труднодостижимо. Поэтому чаще всего под данными понимают любой набор хранящейся в компьютере информации. В основу проектирования программы поиска информации должны быть положены представления конечных пользователей конкретной организации – концептуальные требования к системе. Именно конечный пользователь в своей работе принимает решения с учетом получаемой в результате доступа к данным информации. От оперативности и качества этой информации будет зависеть эффективность работы организации. Частота использования различных форматов данных представлена на рисунке 1.1.  Рисунок 1.1 – Диаграмма форматов данных и их примерное процентное соотношение относительно общего объема данных При рассмотрении наиболее часто используемых форматов данных основное внимание следует уделить рассмотрению работы с базами данных в силу их сложности (например, по сравнению с текстовыми документами) и широкого распространения. Как и в общем случае работы с данными в основу проектирования базы данных (БД) должны быть положены представления конечных пользователей конкретной организации. При рассмотрении требований конечных пользователей к базе данных необходимо принимать во внимание следующее:
1.2. Анализ технологий доступа к базам данных На заре эпохи баз данных разработчикам достаточно было знать только те базы данных, которые они использовали. Но базы данных и их технологии развивались довольно быстро – от реляционных баз данных к нереляционным информационным хранилищам, таким, как электронная почта и файловые системы. Развитие баз данных сейчас идет в ногу со стремительными изменениями в технике. А с появлением клиент-серверных и многоуровневых архитектур разработчикам уже приходится разбираться во всем многообразии технологий баз данных – ODBC, DAO, RDO, OLE DB, ADO и RDS. Как только мы начинаем углубляться в какую-то новую технологию, мы забываем, как она развивалась и что рационального за ней стоит. Проследив развитие технологий баз данных от ODBC до ADO.NET, проще выбрать подходящую технологию и оптимизировать ее для своих целей [1,3]. ODBC. В большинстве систем проектирования баз данных приложения основываются на одном типе баз данных. В таких простых схемах разработчик приложения может программировать напрямую, используя системный интерфейс базы данных. Хотя подобный подход обеспечивает быстрый и эффективный доступ к данным, могут возникать проблемы, когда задача расширяется, и разработчику приходится дорабатывать программу. При данном подходе это означает, что каждая готовая программа должна иметь различные версии с поддержкой всевозможных типов баз данных. Если компании расширяются или объединяются одна с другой, приложение должно получить доступ к базам данных, основанным на различных платформах. Технология ODBC обеспечивает общий интерфейс для доступа к разнородным базам данных стандарта SQL. ODBC использует язык SQL как стандарт для доступа к данным. На рисунке 1.2 показана архитектура ODBC. Этот интерфейс очень удобен: одно приложение может обращаться к различным базам данных SQL через общий набор команд. Таким образом, разработчик может создавать и распространять приложения, не привязываясь к конкретной базе данных.  Рисунок 1.2 – Архитектура ODBC Можно также добавить драйвер базы данных, чтобы приложение могло работать с базой данных по выбору пользователя. Как показано на рисунке 1.5, менеджер драйверов является промежуточным звеном между приложением и базами данных. Интерфейс ODBC содержит набор функций, который управляет каждым инструментом базы данных. Если приложению нужно сменить используемую базу, разработчик просто заменяет один драйвер другим, и приложение может работать как обычно, без необходимости модификации кода программы. DAO и RDO. ODBC использует низкоуровневый интерфейс, поэтому программисты на С и С++ реально задействуют все преимущества технологии ODBC. Программисты на Visual Basic (VB) не имеют простого доступа к интерфейсу ODBC. До появления VB 6.0 разработчики применяли высокоуровневый доступ к данным. На рисунке 1.3 показано, как программисты VB используют технологию Data Access Object (DAO) для доступа к данным.  Рисунок 1.3 – Технология доступа к данным DAO DAO базируется на технологии баз данных Microsoft Jet – процессоре баз данных, предназначенном для Microsoft Access. Jet был первым объектно-ориентированным интерфейсом для связи с Access. Приложения, использующие Access, могут задействовать DAO для прямого доступа к данным. Поскольку DAO создавалась сразу же вслед за Access, применение этой технологии – самый быстрый и наиболее эффективный способ доступа к базам данных Access. DAO может работать и с отличными от Access базами данных, такими, как SQL Server и Oracle. DAO использует ODBC, но, поскольку метод DAO спроектирован специально для взаимодействия с Jet, то Jet транслирует запросы между DAO и ODBC. Этот дополнительный шаг трансляции и является причиной замедления работы с базами данных, отличными от Access. Чтобы преодолеть это ограничение, разработчики Microsoft создали RDO. На рисунке 1.4 показано, что RDO обращается к ODBС API напрямую, минуя Jet.  Рисунок 1.4 – Технология доступа к данным RDO Затем было введено ODBCDirect, расширение DAO, которое отодвигает RDO на задний план. На рисунке 1.5 показано, как DAO-приложение, используя ODBCDirect, обращается к базе данных, минуя проблемы, которые вызывает Jet.  Рисунок 1.5 – Архитектура доступа ODBCDirect OLE DB. Спустя несколько лет ODBC становится стандартом для клиент-серверного доступа к базам данных. ODBC обеспечивает стандартный интерфейс, который требует функций SQL и оптимизирован под методы SQL. Однако что произойдет, если нужно будет обратиться к нереляционной базе данных, в которой не используются принципы SQL (например, Microsoft Exchange Server, хранилище которого не содержит данные реляционно). Рассмотрим OLE DB. Технология OLE DB построена на ODBC и расширяет ее до компонентной архитектуры, которая обеспечивает высокоуровневый интерфейс доступа к данным. Эта архитектура предоставляет постоянный доступ к SQL-данным, не SQL-данным и неструктурированным источникам данных по локальным сетям и Internet ADO. OLE DB обеспечивает связывание для программистов на С и C++, а также программистов, использующих языки с С-подобными вызовами функций. Такие языки, как VB и VBScript, не поддерживают тип данных «указатель» (адресных переменных). Следовательно, они не могут использовать связывание в стиле С и прямое обращение к OLE DB. Вероятно, для большей путаницы разработчики Microsoft ввели еще одну объектную модель доступа к данным: ADO. ADO работает с объектами DAO и RDO, а также поддерживает более простые модели, чем DAO и RDO (хотя с избыточной функциональностью, так что можно выполнить операцию несколькими способами). Объектная иерархия в ADO более однородная, чем в DAO. ADO содержит несколько встроенных объектов, которые упрощают доступ к данным из информационных хранилищ. На рисунке 1.6 показано несколько способов, с помощью которых приложение связывается с базой данных. Например, VB-программист может использовать ADO для соединения приложения с провайдером OLE DB. Если база данных не поддерживает OLE DB, приложение может задействовать ODBC. Программист на Visual C++ может применять ADO или соединяться напрямую через OLE DB.  Рисунок 1.6 – Различие маршрутов приложений в ADO Для доступа к записи ADO требуется просканировать набор строк последовательно. Для доступа к нескольким таблицам необходимо выполнить запрос на объединение JOIN, чтобы получить результат в виде набора строк. Хотя объект Recordset поддерживает доступ к данным без соединения с ними, ADO изначально был спроектирован для данных, с которыми установлено соединение. Такой метод доступа заставляет хранить важные ресурсы на стороне сервера. Вдобавок для передачи набора строк следует использовать метод упорядочивания, названный COM marshalling. COM marshalling – это процесс преобразования типов данных, который, естественно, занимает полезные ресурсы системы. Начиная с ADO 2.1, Microsoft добавляет поддержку XML в объектную модель ADO, что позволяет хранить набор строк Recordset как XML-документ. Однако только при появлении ADO 2.5 ряд ограничений XML, который сохранялся в версии ADO 2.1 (например, жесткая иерархия объектов Recordset), был устранен. Хотя ADO может преобразовать документ XML в набор Recordset, он в состоянии читать только документы в собственной схеме, известной как Advanced Data TableGram (ADTG). В поисках механизма доступа к несвязанным данным Microsoft расширяет ADO и вводит службу Remote Data Services (RDS). RDS создана после ADO и разрешает передачу объекта Recordset клиенту (например, в Web-браузер) при отсутствии активного соединения. Однако RDS, как и ADO, использует упорядочивание COM marshaling для передачи набора строк от сервера клиенту. 1.3. Выбор способа доступа к гетерогенным базам данных Существуют различные способы связи приложений с базами данных [1 – 4, 7]. Для выбора наиболее рационального из них рассмотрим возможности каждого. Программный интерфейс DB Library. Программный интерфейс DB Library представляет собой естественный интерфейс SQL Server, реализованный как набор функций. В документации Microsoft не рекомендует применять этот интерфейс, так как вместо него гораздо удобнее пользоваться другими, которые мы рассмотрим далее. Фактически в новой версии SQL Server этот интерфейс оставлен только для совместимости с разработанными ранее приложениями. Программный интерфейс ODBC. Программный интерфейс ODBC создан специально для доступа к реляционным базам данных. Это универсальный интерфейс, доступный не только в SQL Server, но и при работе с другими (в том числе нереляционными) базами данных. Предполагается, что разработчик базы данных предоставляет в распоряжение прикладных программистов драйвер ODBC, и все обращения к базе данных выполняются с использованием интерфейса ODBC, предоставляемого этим драйвером. Преимущества организации доступа к базам данных через унифицированный интерфейс ODBC очевидны – программы, обращающиеся к базам данных, становятся менее зависимыми от этих баз данных. Однако это только в теории. На практике отличия в реализации драйверов ODBC не всегда позволяют добиться полной независимости. Заметим, что программный интерфейс ODBC выполнен как набор функций. Поэтому он непосредственно доступен только из программ, составленных на традиционных языках программирования, таких как C++. Следовательно, этот интерфейс можно использовать при взаимодействии сервера Web с базами данных только через расширения CGI и ISAPI. Технология ASP не позволяет обращаться непосредственно к интерфейсу ODBC, так как серверные сценарии способны вызывать интерфейсы объектов СОМ только посредством механизма автоматизации (известным ранее как OLE Automation). Объектный интерфейс Remote Data Object. Современные технологии Microsoft в области Интернета основаны не на программных интерфейсах – Win32 или ODBC, а на объектных интерфейсах, доступных в модели компонентных объектов СОМ. Упрощенно такую модель можно представить в виде набора интерфейсов, реализующих методы и свойства. Проведя аналогию между моделью компонентных объектов СОМ и обычными классами языка программирования C++, можно сказать, что методы соответствуют функциям-членам класса, а свойства – переменным, определенным в классе. На самом деле свойства в модели компонентных объектов СОМ тоже реализуются через функции, однако суть дела от этого не меняется. Свойства используются преимущественно для хранения данных, а методы – для выполнения операций над данными или другими объектами. Теперь вернемся к интерфейсам SQL Server. Специально для упрощения доступа к SQL Server из приложений Microsoft Visual Basic и Visual Basic for Applications разработан объектный интерфейс Remote Data Object (RDO). Он реализует все основные возможности интерфейса ODBC, но не применяется при разработке приложений Web. Объектный интерфейс OLE DB. Другой объектный интерфейс, разработанный для предоставления доступа к базам данных, называется OLE DB. Фактически OLE DB представляет собой открытый стандарт, предназначенный для организации универсального доступа к базам данных. Причем имеются в виду не только реляционные БД, но и нереляционные, такие, как серверы почты, базы данных на мэйнфреймах с методами доступа IMS, VSAM и т.д. Компоненты OLE DB состоят из трех элементов: провайдера (provider), потребителя (consumer) и служебного элемента, выполняющего обработку и передачу данных. В роли потребителя могут выступать приложения, составленные на языке программирования C++, или объекты ADO, которые рассмотрим ниже. Такие приложения получают доступ к базам данных посредством объектного интерфейса OLE DB. Задача провайдера OLE DB – реализовать интерфейс OLE DB. В составе OLE DB поставляются провайдеры для интерфейсов ODBC, для текстовых файлов и некоторые другие. Пользуясь провайдером ODBC, потребители интерфейса OLE DB могут получить доступ к базам данных через драйвер ODBC. Объектный интерфейс OLE DB не реализует механизм автоматизации. Поэтому есть возможность задействовать OLE DB только в расширениях CGI и ISAPI сервера Web, но не в страницах ASP (строго говоря, к объектам OLE DB можно обращаться через интерфейс ADO). Тем не менее, интерфейс OLE DB иногда удобнее интерфейса ODBC, особенно в тех случаях, когда сервер Web должен обращаться к нереляционным базам данных. Он рекомендуется как средство для создания системных утилит, работающих с базами данных, а также для создания инструментов для разработки приложений. Объектный интерфейс ActiveX Data Objects. На сегодняшний день наиболее перспективным, несомненно, является интерфейс ActiveX Data Objects (ADO). Посредством этого интерфейса приложения (как обычные, так и ориентированные на использование технологий Интернета) могут подключаться к базам данных, извлекать, обрабатывать и обновлять информацию в них. ADO представляет собой интерфейс уровня приложений, созданный поверх объектного интерфейса OLE DB. При этом интерфейс OLE DB обеспечивает универсальный доступ к данным. Такой доступ обеспечивается, в свою очередь, с помощью провайдеров, таких, как Microsoft OLE DB Provider для ODBC (MSDASQL) или Microsoft OLE DB Provider для SQL Server (SQLOLEDB). Технология Active Data Objects (ADO) – это программное расширение технологии ASP, которое реализовано компанией Microsoft для обеспечения доступа к базе данных. В технологии ADO поддерживаются следующие основные функции (хотя отдельные машины баз данных могут поддерживать только некоторые из них): • независимо создаваемые объекты; • поддержка хранимых процедур с входными, выходными и возвращаемыми параметрами; • курсоры различных типов (включая возможность поддержки разных специальных курсоров конечных пользователей); • пакетное обновление; • поддержка ограничений для числа возвращаемых строк или других параметров запроса; • поддержка нескольких наборов данных, возвращаемых хранимыми процедурами или пакетными операторами. Технология ADO предназначена также для выполнения роли простого в использовании интерфейса прикладного уровня с механизмами OLE DB. Методы технологии ADO вызываются с помощью интерфейса OLE-автоматизации, который в настоящее время доступен во многих инструментах разработки и языках программирования. Основными преимуществами технологии ADO является простота использования, высокое быстродействие, небольшие потребности в оперативной памяти и незначительные затраты дискового пространства. Объектный интерфейс ActiveX Data Objects (ADO) построен на основе интерфейса OLE DB. Модель ADO представляет собой набор объектов и значительно упрощает разработку приложений с базами данных, так как позволяет использовать высокоуровневые средства разработки и серверные сценарии. Это возможно, в частности, потому, что объекты ADO реализуют средства автоматизации. В результате интерфейс ADO доступен из приложений, составленных с применением целого спектра инструментальных средств, в частности Delphi 7 [1 – 4]. 1.4. Принципы организации поиска в Интернете Прогресс в компьютерной технике и электронных средствах связи сделал возможной переработку огромных объемов информации и представление ее в Интернете [9 –14]. Доступ к информации упростился, но одновременно существенно обострились и стали наиболее злободневными вопросы поиска и целенаправленного отбора материалов, содержащих необходимую информацию. Резко возросла актуальность поиска путей и новых подходов для предотвращения реальной угрозы бесконтрольного разрастания информации и превращения Интернета в свалку данных. Или, другими словами, прилагается все больше усилий, чтобы не допустить ситуацию, когда создать нечто из ничего легче, чем найти нечто среди всего. Процесс поиска в Интернете происходит следующим образом. Пользователь составляет поисковые фразы и через интерфейс (например, Internet Explorer) находит материалы, содержащие часть или все слова из поисковой фразы. Основные проблемы подобного поиска:
Каждый пользователь Интернета знаком с ситуацией: находишь не то, что ищешь, то есть указанные проблемы решаются в недостаточной степени. Поиск нередко требует существенных затрат времени. Поиск не всегда заканчивается удачей. Недостатки современных поисковых систем в значительной степени объясняются следующим:
В общем случае мы имеем матрицу, по вертикали которой расположены пользователи, а по горизонтали – материалы Интернета. Причем основной формой представления информации в Интернете являются тексты, и пользователь взаимодействует с Интернетом посредством текстов (например, поисковых фраз). Вопрос сводится к выделению формальных признаков текстов, отражающих их сущность. При выборе критерия необходимо принять во внимание следующее. Особенности мышления людей в существенной степени складываются при обучении. Обучение, в частности, есть процесс установления и закрепления ассоциативных связей. В лингвистическом смысле – это выработка привычек в использовании слов и предикативных определений, употребляемых в любой общественной деятельности. Предполагается, что сфера человеческого бытия (деятельности) в большинстве случаев определяет в существенной степени индивидуальность личности, а относительная частота употребления привычных словесных конструкций свидетельствует о принадлежности человека к той или иной сфере. Также предполагается, что каждому удобнее использовать информацию мировоззренчески близких людей, так как более вероятно, что она находится на востребованном уровне и в требуемом виде. Существенно, что в процессе обучения и жизнедеятельности набор лингвистических привычек качественно меняется, причем в большей степени мы привыкаем к необходимым определениям, то есть устанавливается качественно важное для последующего соотношение: необходимое становится привычным! 1.5. Анализ технологий поиска в Интернете, реализованных в поисковых системах Yahoo, Yandex и Rambler Для поисковой системы Yahoo, Yandex и Rambler важно вычленить привычные связи для наиболее часто употребляемых словесных конструкций, например для поисковых фраз. Таким образом поисковые системы дают возможность пользователям строить поисковые фразы, используя привычные предикативные определения. Например, вы ищете компьютер. Тут же вы получаете выбор: персональный, ноутбук, Unix, софт и т.д. Выбрав Unix, вы сможете решить, хотите ли вы работать на Unix, хотите ли купить Unix-софт или что-то другое. Это и есть поэтапное построение привычного предикативного определения. А возможно ли создание ряда наиболее привычных предикативных определений для поисковых фраз вообще, для всех возможных случаев? Да, возможно. Скоро все мы будем иметь возможность находить привычные поисковые предикативные определения, используя рубрики ведущих поисковых машин. Но слабое место такого подхода в том, что поисковые предикативные определения не коррелируются с предикативными определениями текстов, составленных как отдельными людьми, так и группами людей, использующими какие-то привычные для них предикативные определения. Недостаточно иметь только привычные поисковые предикативные определения, нужно найти авторов текстов, которым они привычны. Цель поиска информации может быть сформулирована как получение текста(ов), содержащего(их) максимальное количество привычных для данного пользователя предикативных определений субъектов и объектов искомой информации. Важным показателем поискового запроса я вляется критерий успеха поиска. Критерий успеха поиска – это степень совпадения, количество лингвистической «схожести» (по определенным характеристикам) искомых текстов и текстов пользователя (информации о личности пользователя). В созданном интеллектуальном интерфейсе Yahoo, Yandex и Rambler исходным является накопление привычных предикативных определений текстов и каждого пользователя в неких профилях. Для этого интерфейс берет каждое предложение каждого текста (как наименьший осмысленный компонент текста) и перебирает все возможные комбинации существительных, прилагательных и глаголов в предложении. Триады «существительные-прилагательные-глаголы» рассматриваются как контекст текста, определяющий взаимоотношение объектов внешнего мира. Для поиска информации достаточно выделить только контекст текстов, отражающих мировоззрение автора(ов) текста. С целью выявления наиболее привычных предикативных определений производится подсчет частоты повторений триад для всего текста. Менее привычные и случайные предикативные определения удаляются из профиля, оставшиеся сортируются в порядке убывания частоты повторения (привычности). Экспериментально установлено, что только 5-7 % от общего числа лингвистически привычных триад повторяются более двух раз в текстах любой величины. Словарный запас каждого человека хотя и велик, но конечен. Известно, что даже профессиональные филологи знают не более 25-30 тысяч слов, а активно используют и того меньше. Профиль, содержащий наиболее привычные предикативные определения текста, называется метрикой данного текста. Для пользователей интерфейса метрика создается на основе наиболее часто повторяемых предикативных определений любого написанного или предпочитаемого пользователем текста. Принципиально важно, что такая метрика позволяет эффективно осуществлять обратную связь в Интернете, где обратная связь есть обратное воздействие субъекта процесса поиска информации на источник информации. Поиск нужного текста по его метрике производится на основе сопоставления метрик пользователя и искомых текстов. Интерфейс проводит сравнение набора привычных пользователю предикативных определений из его метрики с набором привычных предикативных определений метрик текстов определенного раздела. Результат поиска содержит сортированный в порядке убывания список наиболее схожих по метрике текстов. При этом текст рассматривается не как бессмысленное собрание слов, а как осмысленная композиция предикативных определений. С учетом изложенного уточняется формулировка критерия успеха поиска. Следует подчеркнуть, что профили содержат только наиболее привычные предикативные определения контекста текстов, но не передают их содержание непосредственно. Информация, содержащаяся в тексте, не восстанавливается по его профилю. Но для того чтобы поиск информации был эффективен, нужно обеспечить единообразное индексирование одинаковых по содержанию документов и информационных запросов, т.е. необходимо устранить такие явления естественного языка, как синонимия, омонимия и полисемия. Осуществить это можно лишь путем установления контроля за употреблением слов и словосочетаний естественного языка, выступающих в качестве ключевых. Такой контроль обеспечивается составлением специального словаря-справочника. Специфика его в том, что ключевые слова в нем сгруппированы в классы эквивалентности, т.е. группы, обозначающие близкие сто смыслу понятия. Структура тезауруса (словаря) сочетает признаки классификационных схем и перечней предметных рубрик. Термины его должны располагаться в алфавитном порядке, отражая в то же время иерархические отношения между терминами посредством указания более широких – родовых и более узких – видовых, синонимичных или связанных по значению терминов. Необходимость в таком словаре возникает вследствие наличия множества слов с неточно определенным объемом значения, что отрицательно сказывается на результатах индексирования и поиска. Такой тезаурус должен быть единым в масштабах страны или, по крайней мере, региона с тем, чтобы была возможность последующей стыковки разрабатываемых в настоящее время отраслевых ИПС, например в области права. Перед нормированным перечнем терминов не стоит задача стандартизации терминологии, он должен лишь устранить встречающиеся в практике терминологические расхождения применительно к разработке и функционированию информационно-поисковой системы. Перед составителями тезауруса стоит сложная задача – произвести отбор терминов, сгруппировать их в классы и увязать между собой сложные иерархические деревья с тем, чтобы тезаурус обеспечивал удовлетворительную полноту и точность поиска. Сбор терминов осуществляется путем детального свободного индексирования поискового массива (в нашем случае нормативно-правовых актов, составляющих тот или иной институт права). Для облегчения выделения дескрипторов массив в виде списка ключевых слов разбивается на тематические поля. В массиве по льготному пенсионному обеспечению выделены, например, следующие группы или семантические классы: 1) отрасль промышленности, 2) производство, 3) предприятие. 4) цех, 5) участок, 6) профессия, 7) выходные данные документов. Дескрипторный язык состоит из нормативных ключевых слов, у которых искусственно, при помощи соответствующих ссылок и знаков устранены синонимия, омонимия, полисемия. Необходимость подобных искусственных преобразований вызвана тем, что вышеперечисленные особенности естественного языка, хотя и сокращенные, но не устраненные полностью в юридическом языке, не позволяют решить задачу однозначного описания смыслового содержания документов, особенно в поисковых предписаниях. Наиболее важными парадигматическими отношениями ИПТ являются:
|
Похожие:
 |
Обычно определить витальный довольно просто, но иногда бывают и более запутанные случаи Базовой единицей оценки является оценка рел+. Релевантный ответ предоставляет решение пользовательской задачи (бывают запросы, для... |
|
Инструкция по выполнению задания Для выполнения задания предлагается... Проектное задание. Выполнить поэтапно решение задачи дистанционной диагностики и поставки диагноза пациенту на основе предлагаемых... |
 |
Инструкция по работе ответственного за обеспечение безопасности персональных... Настоящая инструкция определяет задачи, функции, обязанности, права и ответственность лица, назначенного ответственным за обеспечение... |
|
Лабораторная работа №1: Создание баз данных В этой утилите можно выполнить типовые задачи обслуживания баз данных, такие как резервирование и восстановление. Здесь можно настраивать... |
|
Тезисы представленные на Внимание! Для поиска своей фамилии или ключевого слова в тексте нажмите Ctrl+F и введите искомое слово в окно поиска!! |
|
2 Решение задачи, удаляющей в файле текст после точки В этом стеке различают несколько уровней, и протоколы высокого уровня всегда базируются на протоколах более низких уровней. В самом... |
|
Лабораторная работа №3 Для того, чтобы структурировать информацию, накопленную в сети Интернет, и обеспечить ее пользователей удобными средствами поиска... |
|
Федеральные клинические рекомендации (протоколы) Доказательной базой для рекомендаций являются публикации, вошедшие в Кохрайновскую библиотеку, базы данных embase и medline. Глубина... |
|
Руководство по эксплуатации системы Регистр онмк и окс «Система Витакарта» Для поиска карты пациента в базе данных на панели инструментов выбираем поиск карты |
|
Конспект лекций по дисциплине «Информационные системы и технологии в науке и образовании» Введение. Содержание дисциплины и порядок ее изучения. Фактографический поиск. Математические модели фактографического поиска. Информационная... |
|
Лекция №11 В этом разделе будет приведен обзор одних из первых систем поиска информации, насчитывающих к настоящему моменту времени многолетнюю... |
|
Инструкция по сверке Планов финансово-хозяйственной деятельности В параметрах поиска в строке Наименование учреждения вводим инн, либо название учреждения. Нажать кнопку Найти. Внизу экрана загрузится... |
|
Описание методов, использованных для сбора/селекции доказательств Доказательной базой для рекомендаций являются публикации, вошедшие в Кохрайновскую библиотеку, базы данных embase и medline. Глубина... |
|
Описание методов, использованных для сбора/селекции доказательств Доказательной базой для рекомендаций являются публикации, вошедшие в Кохрайновскую библиотеку, базы данных embase и medline. Глубина... |
|
Рекомендации для самостоятельной работы студентов по освоению дисциплины... Задачи – формирование навыков самостоятельного поиска информации по заданной проблематике, анализ различных точек зрения на наиболее... |
|
Алгоритмы поиска. Линейный поиск. Двоичный поиск Также, линейный поиск часто используется в виде линейных алгоритмов поиска максимума/минимума |