asu.ugatu.ac.ruasu.ugatu.ac.ru/library/99/metodichka.docx · web viewОглавление....

ОглавлениеВведение.........................................................................................................3

Лабораторная работа №1. Изучение основных возможностей

программного продукта Яндекс.Сервер. Установка окружения, установка и

настройка приложения..........................................................................................12

Цели и задачи работы.............................................................................12

Теоретические сведения.........................................................................12

Методика выполнения работы...............................................................14

Подготовка окружения.......................................................................14

Установка программного продукта Яндекс.Сервер.........................15

Получение доступа к веб-приложению.............................................19

Проверка доступа к панели управления............................................20

Конфигурирование Яндекс.Сервер, параметры конфигурационного

файла...............................................................................................................21

Задание для самостоятельного выполнения.........................................23

Отчет по лабораторной работе...............................................................23

Лабораторная работа №2. Настройка информационно-поисковой

системы Яндекс.Сервер для поиска по SQL базе данных. Сравнение

поисковых механизмов методом анализа иерархий..........................................25

Цели и задачи работы.............................................................................25


Модель булева поиска........................................................................25

Модель ранжированного поиска........................................................28



Настройка Яндекс.Сервер для работы с MySQL.............................31

Установка MySQL ODBC Connector.................................................31

Создание источника данных..............................................................33

Настройка Яндекс.Сервер..................................................................35

Использование встроенного в WordPress механизма поиска.........37

Использование полнотекстового индекса MySQL..........................37

Выбор системы поиска для веб-приложения методом анализа

иерархий.........................................................................................................40


Отчет о лабораторной работе.................................................................46

Лабораторная работа №3. Изучение основных возможностей

программного продукта Apache Solr. Обработка XML документов с

использованием XSLT преобразования..............................................................47

Цели и задачи...........................................................................................47




Добавление документов в поисковый индекс..................................51

Формирование запросов.....................................................................53

Расширенный синтаксис запросов.....................................................54

Взаимодействие Solr с другими системами, XSLT преобразование

.........................................................................................................................54


Отчет по лабораторной работе...............................................................63

ВведениеВ широком смысле информационная система это совокупность

технического, программного и организационного обеспечения, а также

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

принимающих решения надлежащей информацией.

Существует несколько классификаций информационных систем, одной

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

классификации информационные системы подразделяются на:

1. ИС обработки данных или решающие ИС, в которых данные

подвергаются обработке по сложным алгоритмам. К таким системам

относятся автоматизированные информационные системы и системы

поддержки принятия решений.

2. Информационно-справочные или информационно-поисковые ИС, в

которых нет сложных алгоритмов обработки данных, а целью системы

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

Мы будем рассматривать информационно-поисковые ИС в контексте

корпоративного поиска.

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

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

пользователь – это рабочий стол и все, что на этом рабочем столе есть и где

мы можем выполнять поиск информации – это могут быть как файлы

документов, электронная почта, возможно, доступ к личной папке на

файловом сервере.

Вторая вещь, которая находится вокруг нас – это корпоративное

окружение и здесь мы имеем уже другой набор объектов – корпоративный

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

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

электронная почта и корпоративная информационная система. В

определенной ситуации может потребоваться выполнить поиск и по

документам в этих системах.

И третья вещь – это Интернет. Здесь есть просто сайты, библиотеки,

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

информации, по которым можно выполнять поиск.

Рисунок 1 Поисковое окружение сотрудника предприятия

На текущий момент существует большое количество исследований на

тему поиска в Интернете, но достаточно мало по поводу использования

корпоративного поиска. Наша дисциплина будет сосредоточена именно на

корпоративном поиске.

Рассмотрим различные уровни поиска:

Персональный или настольный поиск – на данном уровне выполняет

поиск по файлам и папкам, находящимся на локальном компьютере,

например, по файлам, загруженным из интернета.

Корпоративный поиск. Есть два вида корпоративного поиска –

интранет и поиск по публичному сайту. Поиск внутри интранет – это поиск

внутри корпоративной сети или информационной системы. Вы можете

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

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

корпоративной сети. Поиск по общедоступному сайту - поиск по данным,

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

Персональный поиск

Корпоративный поиск

Веб-поиск

сотрудники озона могут искать товары с помощью своего общедоступного

корпоративного сайта.

Веб поиск – поиск по общедоступным документам.

Перейдем конкретно к корпоративному поиску, зачем он нужен и какие

преимущества он дает. Все преимущества, которые дает корпоративный

поиск можно объединить в три большие группы:

1. Непосредственные преимущества для конечного пользователя – он

может быстро найти требуемую ему информацию.

2. Финансовые преимущества:

a. Сокращение времени поиска информации. Обычно сотрудник

проводит 20-50% времени в поисках необходимой ему

информации. Сокращая это время, мы делаем его работу более

эффективной.

b. Улучшение поиска по общедоступному корпоративному сайту

позволяет повысить уровень продаж – посетители сайта в

большей степени находят именно то, что они искали.

3. Преимущества стратегического уровня

a. Мониторинг тенденций активности поиска – предлагать именно

то, что чаще всего ищут пользователи. В большей степени

относится к общедоступным корпоративным сайтам.

b. Отслеживание трендов в поведении пользователей. При выходе

нового продукта и публикации информации о нем на

корпоративном сайте необходимо, чтобы именно на него

совершалась большая часть переходов. Если это не так, то стоит

пересмотреть систему поискового ранжирования.

Рассмотрим общую структуру системы корпоративного поиска. Это

упрощенная структура и состоит она из следующих частей:

1. Робот-паук (crawler), который загружает и собирает данные.

2. Индексатор – механизм, который индексирует содержимое данных,

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

создавать индекс, так и, например, выделять какие-либо сущности из

этой информации.

3. Система ранжирования – когда пользователь вводит какой-либо запрос,

он получает отсортированный список результатов поиска. Сортировкой

как раз и занимается система ранжирования.

4. Представление пользователю – отображение результатов поиска

пользователю – с навигацией, изображениями или какими-либо

другими возможностями.

Рисунок 2 Структура корпоративной поисковой системы

Рассмотрим корпоративный поиск на конкретном примере. Здесь мы

видим подсистему поиска в системе электронного документооборота БОСС-

Референт. Кроме строки поиска у нас есть еще масса дополнительных

параметров или фасетов, которые ограничивает результаты поиска.

Представление пользователю (user interface)

Система ранжирования (ranking system)

Индексатор (indexer)

Робот-паук (crawler)

Рисунок 3 Поиск в СЭД БОСС-Референт

Как мы видим, корпоративный поиск гораздо более сложный, чем

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

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

Отличительные особенности корпоративного поиска:

1. Сбор и индексирование данных из различных источников и различных

форматов данных. Кроме того необходимо выполнять ранжирование

результатов, которые относятся к разным сущностям – к веб-

страницам, документам, вложенным в них файлам.

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

понадобится выполнять какие-либо дополнительные действия с

результатами поиска.

3. Появление специальных систем корпоративного поиска, которые

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

статистике на конец 2011 года 20% организаций имеют такие системы.

Статистика предоставлена яндексом.

4. Недостаточно высокое качество поиска и удобство использования по

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

параметров, чтобы хоть что-то найти по сравнению с веб-поиском.

Рассмотрим разницу между корпоративным и веб-поиском, почему для

корпоративного поиска не всегда можно использовать те же механизмы, что

и для веб-поиска. Рассмотрим отличия на каждом из уровней:

1. Уровень сбора данных

a. Наличие документов в различных формата – не все форматы

удобны и пригодны вообще для сбора данных. Если с

текстовыми документами и веб страницами все просто, то для

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

собрать эти данные, а затем объединить их в документы, так как

в реляционных БД сущность документ будет разделена по

нескольким таблицам.

b. Составные документы или документы, относящиеся к одному

логическому объекту или бизнес-процессу. Каждый бизнес-

процесс в своей основе имеет набор документов, которые он

обрабатывает, все они относятся к нему и должны

рассматриваться как единый набор документации. Первая

проблема, которая здесь встает, это не только поиск документов

по одному бизнес-процессу, но и определение критерия этого

поиска.

c. Удаление документов или выход из строя узлов сети. При выходе

из строя некоторого узла сети нельзя со 100% уверенностью

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

должны быть удалены из индекса, может быть этот узел просто

находится на техническом обслуживании.

d. Ограничение на доступ к документам. В результаты конкретного

поиска должны попадать только те документы, к которым

конкретный пользователь имеет доступ – он не должен видеть

все документы, а только свои.

2. Уровень индексирования

a. Данные часто полностью или частично структурированы. В

рамках корпоративной системы можно, например,

организационными мерами обеспечить структурирование

информации внутри документа – можно будет определить, кто

автор документа, на какую тему этот документ и т.п.

b. В рамках корпоративного поиска обычно выполняется поиск не

просто абстрактной информации, а определенных объектов –

документов, сотрудников организации в справочнике

организации, принтеров в AD и т.п.

c. Необходимость работы совместно с корпоративной системой

контроля доступа.

d. Несовпадение словаря терминов – в разных документах одни и те

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

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

составлен заранее.

e. Необходимость индексирования специальных символов,

которые в повседневности не имеют смысла, например,

регистрационные номера документов.

f. Наличие более сложного интерфейса поиска – корпоративный

поиск должен удовлетворять большему количеству критерий,

чем простой поиск.

3. Уровень ранжирования результатов поиска

a. Результатам поиска может соответствовать только один

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

поиска может очень сильно сократиться так, что результатом

будет один или два документа.

b. Документы связаны друг с другом только по смыслу,

гиперссылок между ними нет.

c. Документы изначально не размечаются таким образом, чтобы

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

учетом того, что поисковые системы будут выполнять по ним

поиск, в то время как в КИС просто создаются документы, о том,

что с ними будут в дальнейшем выполняться какие-либо

действия, никто не задумывается.

d. Использование контекста поиска для выдачи релевантных

результатов.

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

только тех, которые находятся на первой странице.

f. Нет спама и страниц, которые специально продвигаются.

g. Многие корпоративные системы имеют свои системы поиска,

поэтому необходимо их использование для того, чтобы не

выходит за рамки контекста системы. Бухгалтерская система

должна выдавать только данные бухгалтерии, и ничего больше.

4. Уровень представления пользователю

a. Поиск персонализирован, так как есть возможность получить

контекст – известен конкретный пользователь, который

выполняет поиск и все его предыдущие запросы.

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

корпоративных системах. Пользователь может использовать и

специализированные приложения для поиска. Необходимо

продумать взаимодействия поисковой ИС с другими системами.

c. Необходимость дать пользователю больше возможностей для

поиска, чем просто страница с полем для ввода запроса и

выводом результатов. Вполне возможно, что корпоративному

пользователю потребуется найти что-то еще, связанное с

текущими результатами.

Как измерить результативность поиска? Методы, которые

применяются в веб-поиске не подходят для оценки эффективности

корпоративного поиска.

1. Оценка качества взаимодействия – насколько полно используются все

возможности поисковой системы.

2. Успешность выполнения поставленных задач – насколько хорошо

поисковая ИС справляется со своими задачами.

3. Удовлетворенность пользователей – насколько пользователь

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

использовать.

№1. Лабораторная работа Изучение основных

возможностей программного продукта

. . , Яндекс Сервер Установка окружения установка

.и настройка приложения Целии задачи работы

Цель работы: получение практических навыков установки и настройки

программного продукта Яндекс.Сервер.

Задачи работы:

1. Установка и настройка Яндекс.Сервер

2. Добавление источников данных в коллекцию документов

3. Выполнение поиска по коллекции по заданным ключевым словам

Теоретические сведенияНачнем с определения понятия информационный поиск. Когда вы

просматриваете свои лекции, вы уже выполняете информационный поиск,

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

определен следующим образом:

Информационный поиск – это процесс поиска в большой коллекции

(хранящейся, как правило, в памяти компьютера) некоторого

неструктурированного материала (обычно документа), удовлетворяющего

информационные потребности.

Термин информационный поиск был введен Кульвином Муерсом в

1950 году. Он считал, что можно создать внешний носитель информации

(memex), который может стать расширенной памятью человека.

Информационным поиском в таком понимании занимаются уже

отдельные специалисты, например, библиографы, помощники юристов. Но

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

например, выполняя поиск в интернете. В настоящее время информационный

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

традиционный поиск по ключу.

К информационному поиску относятся также и некоторые другие

задачи, которые не попадают под указанное выше базовое определение. Под

неструктурированными данными понимаются данные, которые не имеют

ясной, семантически очевидной и легко реализуемой на компьютере

структуры. В реальности полностью неструктурированных данных не

существует, даже обычные текстовые документы имеют структуру, они

разделены на разделы, которые оформлены заголовками, текст разбит на

абзацы, абзацы на предложения. Все эти структуры очевидны для

естественного языка, но не всегда пригодны для автоматизированного

поиска.

Определим основные понятия:

1. Коллекция (collection) – группа документов, по которой выполняется

поиск. Также ее называют корпусом (corps) или массивом текстов

(body of texts).

2. Информационная потребность (information need) – это тема, о которой

пользователь хочет знать больше. Ее следует отличать от запроса –

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

удовлетворить свою информационную потребность.

3. Документ называется релевантным (relevant), если с точки зрения

пользователя он содержит ценную информацию, удовлетворяющую его

информационную потребность.

4. Термины (terms) – элементы индексирования, как правило, это

обычные слова.

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

используют два основных статистических показателя:

1. Точность (precise) определяет, какая часть возвращенных результатов

является релевантной по отношению к информационной потребности

пользователя.

2. Полнота (recall) показывает, какая доля релевантных документов

возвращена системой.

Методика выполненияработыПодготовка окружения

Для установки Яндекс.Сервер необходима серверная версия Windows.

В случае, если на Вашем компьютере установлена серверная версия ОС, то

данный шаг можно пропустить.

1. Устанавливаем vmWare Player

2. Добавляем в список доступных виртуальных машин Window 2003 R2 Server

a. Запускаем vmWare Player

b. Выбираем пункт Open a virtual Machine

c. Указываем путь к файлу с виртуальной машиной Windows 2003 R2 Server

3. Виртуальная машина появилась в списке, запускаем ее

Установка программного продукта Яндекс.Сервер

Для выполнения лабораторных работ первоначально необходимо

установить программный продукт Яндекс.Сервер. Первоначальная

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

для Windows:

Запускаем установочный файл в соответствии с платформой, на

которую производится установка.

Принимаем лицензионное соглашение

Указываем папку для установки. Лучше указывать папку без

специальных символов (скобок, пробелов, символов кроме букв и цифр)

Все готово

Также для правильной работы Яндекс.Сервера необходимо установить

ActivePerl. Выбираем версию в соответствии с разрядностью операционной

системы

Принимаем лицензионное соглашение

Устанавливаем все компоненты

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

запуск при помощи файла yandex-server.exe из папки с установленным

приложением. На экране появляется консоль приложения. В консоль будут

выводиться системные сообщения, например, сообщения об ошибках.

Получение доступа к веб-приложению

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

открыть браузер и ввести в адресной строке адрес http :// localhost :17000/

http://localhost:17000/

В браузере будет показана ошибка, что в настройках не определена ни

одна коллекция документов

Проверка доступа к панели управления

Также проверим доступ к административной панели приложения. Для

этого откроем в браузере страницу http :// localhost :17000/ admin /

По умолчанию, создана единственная коллекция, документы которой

находятся в папке /data установленного приложения.

http://localhost:17000/admin/

Для проверки запустим индексирование коллекции и поиск по ней. Для

этого воспользуемся кнопками возле названия коллекции

После того, как индексирование завершено, можно запустить поиск и

снова перейти по адресу http :// localhost :17000/

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

Конфигурирование Яндекс.Сервер, параметры

конфигурационного файла

Конфигурирование Яндекс.Сервер производится с помощью

конфигурационного файла yandex.cfg, который находится в папке с

установленным приложением, который представляет собой файл в формате

XML.

Рассмотрим структуру конфигурационного файла. Комментарии к

параметрам даны непосредственно в конфигурационном файле<Server> # порт, на котором работает Яндекс.Сервер # Port 17000

# Адрес, на котором работает Яндекс.Сервер # IPAddress 127.0.0.1

# Имя хоста, на котором работает Яндекс.Сервер # Host localhost

http://localhost:17000/

# путь к файлу, в который будут выводиться сообщения Яндекс.Сервера ServerLog yandex.log

# настройка авторизованого доступа к административному режиму </Server >

# коллекция документов<Collection autostart="yes">

# autostart - позволяет определить порядок работы индексатора и поиска# yes - автоматически загружается при старте Яндекс.Сервера# no - не запускается автоматически, при старте# must - завершает работу Яндекс.Сервера, если одна из коллекций не

стартовала при запуске

# директория, в которой будут размещены вновь созданные индексные файлыIndexDir workindex

# выдача тестовой информации<IndexLog>

# Путь к файлу протокола индексирования.FileName index.log

# Уровень выдачи тестовой информации.Level verbose moreinfo info debug moredebug

</IndexLog>

# Конфигурационный файл может включать несколько секций DataSrc, каждая# из которых описывает источник данных. Одна коллекция может содержать# несколько источников данных<DataSrc id="ftds">

# id - уникальное имя источника данных

<Ftds># ftds определяет, что текущий источник данных является источником# в качестве хранилища выступает файловая система

# также возможны следующие источники данных:# webds - индексирование веб-страниц# ftds - индексирование файлов# odbcdc - индексирование БД с подключением через ODBC# mysqldc - индексирование данных в СУБД MySQL

<Folder inherited="no"># атрибут inherited определяет, нужно ли проводить

индексирование# подпапок с параметрами родительской папки

# абсолютный путь к папке с даннымиPath C:\Program Files\Yandex\Server\data

</Folder><Extensions>

# список типов файлов для индексирования# поддерживаются следующие типы файлов:# text/html .html, .htm, .shtml# text/plain .txt# audio/mpeg .mp3# text/rtf .rtf# application/pdf .pdf# application/msword .doc# application/vnd.ms-excel .xls# application/vnd.ms-powerpoint .ppt# application/x-shockwave-flash .swfapplication/pdf .pdf

</Extensions></Ftds>

</DataSrc>

</Collection>

Задание для самостоятельного выполнения1. Запустить Яндекс.Сервер на порту 80, чтобы к поисковому интерфейсу

можно было получить по адресу http :// localhost /

2. Определить два источника данных со следующими параметрами:

C:\docCollection\doc 1. Наследовать параметры индексирования от родительской папки

2. Индексировать только документы MS Word

C:\docCollection\pdf 1. Наследовать параметры индексирования от родительской папки

2. Индексировать только документы в формате PDF

3. Выполнить индексирование коллекции и провести тестовый поиск по следующим ключевым словам:

a. HKEY_CURRENT_USER

b. UNIX File System

c. debugger_is_present

d. Keeper

e. Управление требованиями

f. CMMI

g. Data Mining

По каждому из указанных ключевых слов в тестовой коллекции есть

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

документы.

Отчетполабораторной работеОтчет по лабораторной работе должен включать в себя:

1. Титульный лист, название, цель работы

http://localhost/

2. Скриншоты результатов поиска с различными вариантами запросов

№2. Лабораторная работа Настройка

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

. Яндекс Сервер для поиска по SQL .базе данных

Сравнение поисковых механизмов методом

анализа иерархий Целии задачи работы

Цель работы: настройка информационно-поисковой системы

Яндекс.Сервер для работы с СУБД MySQL. Сравнение методом анализа

иерархий встроенной в веб-приложение системы поиска, полнотекстового

индекса, предлагаемого СУБД и информационно-поисковой системы

Яндекс.Сервер.


1. Конфигурирование Яндекс.Сервера для работы с СУБД MySQL.

2. Проверка возможностей поисковой системы, встроенной в CMS WordPress.

3. Проверка возможностей поиска с использованием полнотекстового индекса, встроенногов СУБД MySQL.

4. Сравнение различных технологий поиска с использованием метода анализа иерархий.

Теоретические сведенияМодель булева поиска

Рассмотрим один из самых простых алгоритмов информационного

поиска – булев поиск.

Модель булева поиска – это модель информационного поиска, в ходе

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

выражения, то есть выражения, в котором термины используются в

сочетании с булевыми операциями AND, OR, NOT. В рамках данной модели

документ рассматривает как набор слов.

Рассмотрим модель булева поиска на конкретном примере. На портале

кафедры АСУ есть большой набор учебных документов и нам необходимо

определить, в каких документах используются слова «Информационная

система» AND «Проектирование» AND NOT «Мехатроника».

Для этого можно прочитать все лекции от начала до конца и исключить

из рассмотрения лекции, в которых встречается слово «Мехатроника», а

простейший компьютерный метод решения этой задачи сводится к

последовательному просмотру (linear scanning) всех документов. Этот метод

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

корпоративного применения он не годится – нет возможности постоянно

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

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

при каждом запросе заранее составляется поисковый индекс. Опишем

создание индекса на рассмотренном ранее примере.

Для каждого термина (или слова, в конкретном примере) составляется

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

или нет. В результате мы получим бинарную матрицу инцидентности

«термин-документ» (term-document incidence matrix). В зависимости от

направления просмотра этой матрицы мы можем получить либо вектор

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

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

Для обработки рассмотренного ранее запроса «Информационная

система» AND «Проектирование» AND NOT «Мехатроника» нужно взять

вектор каждого из терминов и выполнить для них поразрядную операцию

AND.

Рассмотрим теперь более реалистичный сценарий, где количество

документов исчисляется сотнями тысяч и миллионами (пример, среднее

количество документов, создаваемое ИС с 5000 активных пользователей –

около 10000 в сутки, следовательно, в месяц создается около 3 млн.

документов).

Цель любой информационно-поисковой системы – найти в коллекции

документы, которые являются наиболее релевантными по отношению к

произвольным информационным потребностям, сообщаемых системе при

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

При таком масштабе у нас получится сильно разряженная матрица,

которая содержит 98% нулей, поэтому используется другой подход –

инвертированный индекс. Инвертированный индекс строится по

следующему алгоритму:

1. Собираются все документы, которые будут проиндексированы.

Совокупность всех документов называется пространство поиска.

Каждый документ в этом пространстве имеет уникальный

идентификатор (docID).

2. Размечаем текст, превращая каждый документ в список лексем (tokens).

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

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

индексируемые термины.

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

документов, в которых он встречается. Кроме того, возможно указания

словопозиции (posting) – места, где данный термин встречается. В

результате этого получим список пар «термин-docID». Полученный на

данном этапе список сортируется в алфавитном порядке, многократные

повторения одного термина в документе объединяются, а термины из

одного документа группируются вместе.

Такая структура инвертированного индекса является наиболее

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

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

следующим образом:

1. Каждый из терминов булева запроса обнаруживается в словаре.

2. Находится список словопозиций каждого из терминов в документах.

3. Находим пересечение списков словопозиций для каждого из терминов.

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

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

Такая модель поиска наиболее широко распространена в

корпоративных информационных системах, так как набор параметров, по

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

максимально релевантные результаты.

Модель ранжированного поиска

Альтернативой модели булева поиска является модель ранжированного

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

запросы в свободной форме, то есть набирают простые текстовые запросы не

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

лучше удовлетворяют этим запросам.

Модель ранжированного поиска появилась в связи с развитием

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

условиям:

1. Поиск должен стать малочувствительным к опечаткам и неточному

выбору слов.

2. Необходимо находить сложносоставные слова или целые фразы,

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

рассматривается как самостоятельная языковая лексема.

3. Модель булева поиска позволяет определить лишь наличие или

отсутствие термина, но хотелось бы иметь ранжированный по

определенному критерию результат поиска, например, по частоте

упоминания определенного термина в документе.

Модель ранжированного поиска реализована во всех современных

поисковых системах и обычно выставлена на первое место, но они также

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

результаты, но используются гораздо реже.


Для выполнения лабораторной работы необходимо иметь

установленную и настроенную СУБД MySQL, а также веб-приложение

WordPress. Данные программные продукты можно найти в дополнительном

материале к данной лабораторной работе.

СУБД MySQL, а также веб-сервер Apache, необходимые для работы с

WordPress собраны в пакет прикладных программ Denwer. Запуск Denwer

осуществляется с помощью исполняемого файла run.exe из

директории /WebServers/Denwer.

Для начала проверим функционирование установленной копии

WordPress. Для этого в браузере откроем страницу http :// wordpress / Здесь мы

видим установленную копию свободной системы управления содержимым

WordPress.

http://wordpress/

Данная система используется как платформа для ведения блогов, но

может быть дополнительно расширена модулями для решения более

широкого круга задач. В качестве хранилища данных данная система

использует СУБД MySQL. Мы будем использовать WordPress как интерфейс

для управления данными, хранящимися в СУБД.

Версия WordPress, необходимая для выполнения данной лабораторной

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

может быть расширен. Вход в панель управления веб-приложением

осуществляется по адресу http :// wordpress / wp - admin / Для входа нужно

указать логин и пароль. В данной инсталляции логин и пароль – admin.

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

http://wordpress/wp-admin/

Настройка Яндекс.Сервер для работы с MySQL

Для использования MySQL в качестве источника данных ее

необходимо зарегистрировать как источник данных ODBC в системе. Для

этого первоначально нужно установить MySql ODBC Connector и создать

новый источник данных.

Установка MySQL ODBC Connector

Установка выполняется с использованием стандартного мастера

установки:

Создание источника данных

Для создания источника данных перейдем в Администрирование –

Источники данных ODBC.

Создаем новый пользовательский DSN путем нажатия на кнопку

Добавить. Выбираем в качестве драйвера MySQL ODBC 5.1 Driver

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

соответствии с приведенными на рисунке

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

кнопки Test. На этом создание источника данных завершено.

Настройка Яндекс.Сервер

Для того, чтобы иметь возможность выполнять поиск по MySQL базе

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

параметры подключения к источнику данных: <DataSrc id="odbcds">

# название источника данныхName: testOdbcSource<Odbcds>

# название ODBC-источника данныхDataSourceName : mysqlDataSource

# запрос на выборку конкретного документа из БДDocQuery : SELECT post_title, id, post_content FROM wp_posts

# условие фильтрации (для выборки одного документа)DocFilter : WHERE id=$1

# запрос для выборки списка документовUrlQuery : SELECT id FROM wp_posts

# тип возвращаемых данныхMimeType : text/html

# кодировка документовCharset : utf-8

# поле, определяющее дату создания документаTimeStamp : post_date

# путь к шаблону для индексированияTemplate : c:/doc.tmpl

</Odbcds> </DataSrc>

Также для индексирования необходимо создать файл шаблона

документа (doc.tmpl) со следующим содержимым:<HTML><HEAD><META NAME="m_time" CONTENT="$1"><TITLE>$1</TITLE></HEAD><BODY>$3</BODY></HTML>

Путь к данному файлу указывается в параметре Template источника

данных. Данный шаблон используется при генерации страницы на основе

полученных из MySQL данных, т.е. данные из базы сначала извлекаются,

затем формируется страница по шаблону и после этого производится ее

индексирование.

После повторного индексирования документов в индекс будут

добавлены записи из базы данных. Запустим поисковый модуль и выполним

поиск.

К сожалению, в виду ошибки в работе Яндекс.Сервера с ODBC

источниками данных ссылка на документ формируется некорректно, в виду

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

Использование встроенного в WordPress механизма поиска

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

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

специальное поле для ввода.

Поиск осуществляется на лету, без составления какого-бы то ни было

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

данные.

Использование полнотекстового индекса MySQL

MySQL имеет возможность создания полнотекстового индекса, по

которому возможно выполнение поиска. Каждая таблица MySQL может

содержать несколько полнотекстовых индексов, которые формируются по

нескольким полям.

Для создание полнотекстового индекса воспользуемся утилитой

phpMyAdmin, которая доступна по адресу http://localhost/Tools/phpMyAdmin/

Выберем базу данных wordpress, перейдем в таблицу wp_posts. В

представлении Structure выберем поля post_title и post_content, и нажмем

кнопку Fulltext.

http://localhost/Tools/phpMyAdmin/

Таким образом мы создали полнотекстовый индекс в таблице wp_posts

по двум полям. Напишем простой PHР-скрипт, который позволит нам

выполнять запросы к MySQL. <form action="ftsearch.php"><table width="100%">

<tr><td>Текст запроса:</td><td><input type="text" name="q" style="width: 100%;"

value="<?php echo $_GET['q']; ?>"></td><td><input type="submit" value="Выполнить поиск"></td>

</tr></table></form>

<?phpmysql_connect("localhost", "root", "");mysql_select_db("wordpress");

if (!empty($_GET['q'])) {$q = "SELECT * FROM `wp_posts` WHERE MATCH (post_title,

post_content) AGAINST ('".$_GET['q']."');";$res = mysql_query($q) or die(mysql_error());

echo "<ul>";while ($r = mysql_fetch_assoc($res)) {

if ($r['post_status'] == 'publish') {if (!empty($r['post_title'])) {

echo "<li><a href='http://wordpress/?p=".$r['ID']."' target='_blank'>".$r['post_title']."</a></li>";

}}

}echo "<ul>";

}?>

Сохраним содержимое в файл ftsearch.php в

директории /WebServer/home/wordpress/www/ и обратимся к нему в браузере

по адресу http :// wordpress / ftsearch . php

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

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

Использование полнотекстового индекса более предпочтительно, так

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

например, при использование встроенных механизмов WordPress, но, с

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

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

простых запросов и небольших объемов хранилища использование поиска по

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

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

большее количество полей, а также создан индекс из нескольких таблиц.

http://wordpress/ftsearch.php

Выбор системы поиска для веб-приложения методом анализа

иерархий

Общая информация о МАИ

Метод Анализа Иерархий (МАИ) — математический инструмент

системного подхода к сложным проблемам принятия решений. МАИ не

предписывает лицу, принимающему решение (ЛПР), какого-либо

«правильного» решения, а позволяет ему в интерактивном режиме найти

такой вариант (альтернативу), который наилучшим образом согласуется с его

пониманием сути проблемы и требованиями к ее решению.

Анализ проблемы принятия решений в МАИ начинается с построения

иерархической структуры, которая включает цель, критерии, альтернативы и

другие рассматриваемые факторы, влияющие на выбор. Следующим этапом

анализа является определение приоритетов, представляющих относительную

важность или предпочтительность элементов построенной иерархической

структуры, с помощью процедуры парных сравнений.

Задачи принятия решения можно рассмотреть следующим образом:

Пусть имеются:

1. несколько однотипных альтернатив (объектов, действий и т.п.),

2. главный критерий (главная цель) сравнения альтернатив,

3. несколько групп однотипных факторов (частных критериев, объектов,

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

Требуется каждой альтернативе поставить в соответствие приоритет

(число) – получить рейтинг альтернатив. Причем чем более предпочтительна

альтернатива по избранному критерию, тем больше ее приоритет.

Принятие решений основывается на величинах приоритетов.

Схема метода анализа иерархий

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

приоритеты критериев и каждая из альтернатив оценивается по

проранжированным критериям.

Сначала сравниваются попарно критерии для определения их

приоритетов, поскольку на конечный выбор альтернативы критерии

влияют по-разному в зависимости от их значимости.

Затем аналогичным образом сравниваются и альтернативы по

отношению к каждому из критериев.

Алгоритм МАИ

Определение иерархии целей.

Установление приоритетов критериев методом попарного сравнения.

Установление приоритетов альтернатив по каждому критерию.

Определение глобального приоритета альтернатив.

1.1.1.1 I этап – Составление иерархии целей Определение глобальной цели

Определение промежуточных целей (подцелей)

Определение критериев достижимости промежуточных целей

Формирование альтернатив

1.1.1.2 II этап – Установление приоритетов критериев Формирование матрицы попарных сравнений критериев. (При

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

Ранжирование критериев

o Оценка компонент собственного вектора каждого критерия

o Нормализация оценок

Оценка согласованности матрицы

Шкала предпочтений объектов

Степень превосходства (b)

Описание степени превосходства

0 Объекты не сравнимы

1 Объекты одинаково важны

3 Умеренное превосходство одного над другим

5 Существенное превосходство одного над другим

7 Значительное превосходство одного над другим

9 Абсолютное превосходство одного над другим

2,4,6,8 Промежуточные значения степеней превосходстваМатрица попарного сравнения критериев

аij = b, аji = 1/b → матрица диагональная и обратно симметричная

Критерий 1

...

Критерий j

...

Критерий n

Критерий 1

1 ...

а1j ...

а1n

... ... ...

... ...

...

Критерий i

а i1 ...

аij ...

аin

... ... ...

... ...

...

Критерий n

а n1 ...

аnj ...

1

Ранжирование критериев

Оценка компонент собственного вектора каждого критерия

Нормализация оценок

y iн показывает вклад каждого критерия в достижение цели

y i=N√∏j=1

N

aij

y i’=y i

∑i=1

N

y i

Оценка согласованности матрицы

Вычисление максимального собственного числа матрицы (λmax)

Вычисление индекса согласованности (ИС)

Вычисление оценки согласованности (ОС)

λ i=∑i=1

n

aij× y iн

Значения случайной согласованности (СС)

n 1 2 3 4 5 6 7 8 9 10

СС 0 0 0,58 0,9 1,12 1,24 1,32 1,41 1,45 1,49

ОС ≤ 0,1 матрица согласованна

0,1<ОС ≤ 0,2 согласованность матрицы приемлема

ОС > 0,2 согласованность матрицы не приемлема

Сводная таблица для расчета приоритета критериев/альтернатив

Критерий

1... Критерий j ...

Критерий

nyi yiн λi

Критерий 1 1 ... а1j ... а1n y1 y1н λ1

... ... ... ... ... ... ... ... …

Критерий i а i1 ... аij ... аin yi yiн λi

... ... ... ... ... ... … … …

Критерий n а n1 ... аnj ... 1 yn ynн λn

Суммы по

столбцу

K1 … Kj … Kn Y 1 λmax

λmax=∑i=1

n

λ i

ИС=λmax−nn−1

1.1.1.3 III этап – Установление приоритетов альтернатив по критериямАльтернативы сравниваются попарно с целью получения локальных

векторов приоритета по каждому критерию.

Матрица попарных сравнений альтернатив по i-му критерию

Альтернатива

1

... Альтернатива i ..

.


k


1

1 ... x1j ..

.

x1k

... ... ... ... ..

.

...


i

x i1 ... xij ..

.

xik

... ... ... ... ..

.

...


k

x k1 ... xkj ..

.

1

В результате для каждого i-го критерия будет получен

нормализованный вектор приоритетов альтернатив

x1iн, …, хkiн.

IV этап – Определение глобального приоритета альтернатив

Крит. 1 Крит. 2 … Крит. j … Крит. n Оценка

Нормализованный

вектор приоритетов

критериев y1н y2н … yjн … ynн

Альтернатива 1 x11н x12н … x1jн … x1nн A1

… … … … … … … …

Альтернатива k xk1н xk2н … xkjн … xknн An

Aopt=max Ai Задание для самостоятельного выполнения

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

механизмов для веб-приложения на основе следующих критериев (3

указанных и 2 добавить самостоятельно):

Удобство использования

Скорость поиска

Сложность конфигурирования

Альтернативы:

Яндекс.Сервер

Встроенный поиск в веб-приложение

Встроенный поиск в СУБД

Отчетолабораторной работеОтчет по лабораторной работе должен включать в себя:


2. Скриншоты результатов поиска с использованием различных средств

3. Результаты выбора механизма поиска с использованием метода анализа иерархий

4. Выводы о проделанной работе

Ai=∑j=1

n

( x ijн× y jн)

№3. Лабораторная работа Изучение основных

возможностей программного продукта Apache Solr.

Обработка XML документов с использованием XSLT

.преобразования Целии задачи

Цель работы:

Получение практических навыков по работе с Apache Solr


Подготовка окружения для работы с Apache Solr

Развертывание Apache Blaze

Индексирование тестовой коллекции

Преобразование результатов поиска из XML в HTML с использованием XSLT

Теоретические сведенияThe Apache Lucene — это свободная библиотека для

высокоскоростного полнотекстового поиска, написанная на Java. Может

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

лингвистики (аналитическая философия).

Основные возможности:

Масштабируемая и высокоскоростная индексация

o свыше 95GB в час на современном оборудовании

o требуется малый объем RAM — «heap» всего 1MB

o размер индекса примерно 20-30 % от размера исходного текста

Мощный, точный и эффективный поисковый алгоритм

o ранжированный поиск — лучшие результаты показываются первыми

o множество мощных типов запросов: запрос фразы, wildcard запросы, поиск интервалов и т. д.

o поиск основанный на «полях» (таких как, заголовок, автор, текст)

o возможность сортировать по различным полям

o multiple-index поиск с возможностью объединения результатов

o возможность одновременного поиска и обновления индекса

Кроссплатформное решение

o исходный код полностью написан на Java

o наличие портов на другие языки программирования

Apache Solr – открытая корпоративная поисковая платформа, созданная

на базе Apache Lucene. Основные возможности Apache Solr включают в себя

мощный полнотекстовый поиск, подсветку результатов поиска, фасетный

поиск, динамическую кластеризацию результатов, интеграцию с СУБД и

поддержку индексирования документов разных форматов (например, MS

Word и PDF). Также имеется возможность создания распределенной

поисковой системы и репликация поискового индекса.

Проект Apache Solr написан на Java и запускается как самостоятельное

приложение в контейнере сервлетов, например, на Apache Tomcat. Solr

использует Lucene как поисковый механизм и имеет REST HTTP/XML и

JSON интерфейс для взаимодействия с другими приложениями.

Blaze – отдельный проект, который представляет собой готовый к

работе виртуальный сервер с уже установленным и настроенным Apache Solr.

Blaze также не является готовым решением для организации корпоративного

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

поиска, вместо установки и настройки Apache Lucene.


Для начала работы с Blaze его необходимо подключить как новую

виртуальную машину к VMWare Player. Данная операция выполнялась в

первой лабораторной работе, в случае возникновения проблем обратитесь к

ней.

Blaze представляет собой дистрибутив OpenSUSE Linux с

установленным и настроенным Apache Solr.

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

Для входа логин root, пароль linux.

Для того, чтобы получить доступ с хост-машины к виртуальной

необходимо изменить режим эмуляции сетевого адаптера с Bridged (по-

умолчанию для данной виртуальной машины) в режим NAT. Для этого в

настройках виртуальной машины, в разделе Network Adapters указываем

NAT вместо Bridged.

Запускаем виртуальную машину, в процессе загрузки нам будет

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

SUSE Linux.

В данном примере это адрес https ://192.168.81.129:54984/ Чтобы

получить доступ к Solr нужно перейти по адресу http://ip-адрес/solr/admin/, в

данном случае http ://192.168.81.129/ solr / admin /

Веб-интерфейс Solr

http://192.168.81.129/solr/admin/

https://192.168.81.129:54984/

Все результаты, возвращаемые Solr представлены в формате XML. Это

необходимо для успешной интеграции с другими системами, так как XML

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

Добавление документов в поисковый индекс

Solr запущен, но на данный момент он не содержит каких-либо данных

в поисковом индексе. Можно добавить документы в индекс путем отправки

Solr инструкций в формате XML на добавление (обновление), удаление

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

удаления, обновления индекса.

В общем случае, для того, чтобы обновить документ в индексе нужно

на адрес /solr/update отправить XML-документ. Для отправки данный на

сервер воспользуется php скриптом, который будет брать содержимое XML

файлов из текущей директории и отправлять их Solr, а затем делать

подтверждение внесенных изменений:<?php

echo "POSTing data to solr<br />";$url = "http://192.168.81.129/solr/update";

$files = scandir(".");foreach ($files as $file) {

if (strpos($file, ".xml") !== false) {echo "Processing file ".$file."<br />";$tCurl = curl_init();curl_setopt($tCurl, CURLOPT_URL, $url);curl_setopt($tCurl, CURLOPT_HTTPHEADER, array(

'Content-type: text/xml'));curl_setopt($tCurl, CURLOPT_HEADER, 0);$data = file_get_contents($file);curl_setopt($tCurl, CURLOPT_POSTFIELDS, $data);curl_exec($tCurl);

$tCurl = curl_init();curl_setopt($tCurl, CURLOPT_URL, $url);curl_setopt($tCurl, CURLOPT_HTTPHEADER, array(

'Content-type: text/xml'));curl_setopt($tCurl, CURLOPT_HEADER, 0);$data = "<commit/>";curl_setopt($tCurl, CURLOPT_POSTFIELDS, $data);curl_exec($tCurl);

}}

?>

Мы можем поместить данный скрипт в директорию с тестовыми XML-

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

например, так:C:\>d:\WebServer\usr\local\php5\php-cgi.exe d:\WebServer\home\test\www\index.php

Или открыв в браузере страницу, которая вызовет данный скрипт.

В результате мы добавили в Solr документы. Solr, в отличие от других

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

XML-документ на поля и индексирует каждое из них.

Для проверки выполним запрос по ключевому слову Dell и в результате

мы получим также ответ от сервера в формате XML:<response><lst name="responseHeader">

<int name="status">0</int><int name="QTime">10</int><lst name="params">

<str name="indent">on</str><str name="start">0</str><str name="q">Dell</str><str name="rows">10</str><str name="version">2.2</str>

</lst></lst><result name="response" numFound="1" start="0"><doc>

<arr name="cat"><str>electronics</str><str>monitor</str>

</arr>

<arr name="features"><str>30" TFT active matrix LCD, 2560 x 1600, .25mm dot pitch, 700:1

contrast</str>

</arr><str name="id">3007WFP</str><bool name="inStock">true</bool><str name="includes">USB cable</str><str name="manu">Dell, Inc.</str><str name="name">Dell Widescreen UltraSharp 3007WFP</str><int name="popularity">6</int><float name="price">2199.0</float><float name="weight">401.6</float>

</doc></result></response>

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

из исходного XML-документа.

Формирование запросов

Так как документ в поисковом индексе представляет собой набор

полей, то возможно формировать сложные поисковые запросы, которые при

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

Примеры:

1. По содержанию значения в каком-либо поле документа

Формат: значение

Пример: video

2. По содержанию в поле определенного значения

Формат: имяПоля:значение

Пример: name:video

3. По значению поля, находящемуся в определенном интервале

Формат: имяПоля:[a TO b]

Пример: popularity:[0 TO 10]

Возможно также использование маски *, то позволяет

ограничивать интервал только с одной из сторон, например, [* TO

10] – значение определенного поля меньше 10.

4. По отсутствию какого-либо значения в поле

Формат: -имяПоля:значение

Пример: -popularity:10

Также возможно использование интервальных значений

5. По обязательному наличию поля или какого-либо его значения в документе

Формат: +имяПоля

Пример: +price

Расширенный синтаксис запросов

Solr содержит также и расширенный интерфейс формирования

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

определять структуру результатов. Для перехода в расширенный интерфейс

необходимо перейти по ссылке Full Interface на странице Solr.

Оно обладает дополнительно следующими возможностями:

1. Разделить запрос на две части: запрос на выборку данных и условия запроса

2. Определить количество возвращаемых результатов

3. Определить перечень полей результата

4. Отладка запроса – просмотр последовательности формирования результата

5. Подсветка указанных полей результата

Взаимодействие Solr с другими системами, XSLT преобразование

Solr возвращает результаты поиска в формате XML. Данный формат

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

неудобен для восприятия и дальнейшей обработки. Для того чтобы

стилизовать XML используется XSLT.

XSLT (eXtensible Stylesheet Language Transformations) — язык

преобразования XML-документов. Спецификация XSLT входит в состав XSL

и является рекомендацией W3C.

При применении таблицы стилей XSLT, состоящей из набора

шаблонов, к XML-документу (исходное дерево) образуется конечное дерево,

которое может быть сериализовано в виде XML-документа, XHTML-

документа (только для XSLT 2.0), HTML-документа или простого текстового

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

дерева пишутся на языке запросов XPath.

XSLT имеет множество различных применений, в основном в области

web-программирования и генерации отчётов. Одной из задач, решаемых

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

общей парадигмы MVC. Другой стандартной задачей является

преобразование XML-документов из одной XML-схемы в другую.

В процессе выполнения XSLT-преобразования задействованы:

один или несколько входных XML-документов;

одна или несколько таблиц cтилей XSLT;

XSLT-процессор;

один или несколько выходных документов.

В простейшем случае XSLT-процессор получает на входе два

документа — входной XML-документ и таблицу стилей XSLT — и создает

на их основе выходной документ.

Язык XSLT является декларативным, а не процедурным. Вместо

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

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

Само преобразование ведется по фиксированному алгоритму.

В первую очередь XSLT процессор разбирает файл преобразования и

строит XML дерево входного файла. Затем он ищет шаблон, который лучше

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

шаблона. Инструкции в каждом шаблоне могут либо напрямую говорить

XSLT процессору "создай здесь такой-то тег", либо говорить "обработай

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

Каждый XSLT-процессор должен выполнить следующие шаги для

подготовки к трансформации:

1. Прочитать таблицу стилей XSLT с помощью XML-парсера и перевести

его содержимое в дерево узлов (дерево таблицы стилей), согласно

модели данных XPath. Синтаксические ошибки «времени компиляции»

определяются на этой стадии. Таблицы стилей могут быть

модульными, поэтому все включения (инструкции xsl:include,

xsl:import) также будут обработаны на этой стадии с целью объединить

все шаблонные правила и иные элементы из других таблиц стилей в

единое дерево таблицы стилей.

2. Прочитать входные данные XML с помощью XML-парсера, перевести

его содержимое в дерево узлов (исходное дерево), согласно модели

данных XPath. XML-документ может ссылаться на другие XML-

источники с помощью вызова функций document(). Эти вызовы обычно

обрабатываются во время выполнения, так как их расположение может

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

происходить вовсе. (Пример выше не ссылается на какие-либо другие

документы.)

3. Удалить пустые узлы из таблицы стилей XSLT, кроме тех, которые

являются потомками от элементов xsl:text. Это позволяет исключить

появление «лишних» пробелов.

4. Удалить пустые текстовые узлы из исходного дерева, если инструкции

xsl:strip-space присутствуют в исходном документе. Это позволяет

исключить появление «лишних» пробелов. (Пример выше не

использует эту возможность)

5. Пополнить XSLT-дерево тремя правилами, которые предоставляют

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

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

узла; оно даёт инструкцию процессору обработать каждого потомка

корневого узла. Второе правило — для любых текстовых узлов или

узлов атрибутов; он даёт команду процессору сделать копию этого узла

в результирующем дереве. Третье правило — для всех узлов

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

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

часть или все шаблоны-правила, заданные по умолчанию. Если шаблон

не содержит явных правил, встроенные правила будут применены для

рекурсивного обхода исходного дерева и только текстовые узлы будут

скопированы в результирующее дерево (узлы атрибутов не будут

достигнуты, так как они не являются «детьми» их родительских узлов).

Полученный таким образом результат обычно нежелателен, так как он

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

исходного XML-документа.

Затем процессор проделывает следующие шаги для получения и

сериализации результирующего дерева:

1. Создаёт корневой узел результирующего дерева.

2. Обрабатывает корневой узел исходного дерева. Процедура обработки узла описана ниже.

3. Сериализует результирующее дерево, если необходимо, согласно подсказкам, описанным инструкцией xsl:output.

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

1. Производится поиск наиболее подходящего шаблона правила. Это

достигается проверкой соответствия шаблона (который является

выражением XPath) для каждого правила, указывая узлы, для которых

правило может быть применено. Каждому шаблону процессором

назначается относительный приоритет и старшинство для облегчения

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

также может помочь разрешению конфликтов между шаблонами,

которые соответствуют одинаковым узлам, но это не оказывает

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

2. Элементы в пространстве имён XSLT (обычно имеющие префикс xsl:)

трактуются как инструкции и имеют специальную семантику, которая

указывает на то, как они должны интерпретироваться. Одни

предназначены для добавления узлов в результирующее дерево, другие

являются управляющими конструкциями. Не XSLT-элементы и

текстовые узлы, обнаруженные в правиле, копируются, «дословно», в

результирующее дерево. Комментарии и управляющие инструкции

игнорируются.

Инструкция xsl:apply-templates при её обработке приводит к выборке и

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

выражения XPath. Все узлы обрабатываются в том порядке, в котором они

содержатся в исходном документе.

XSLT расширяет библиотеку функций XPath’s и позволяет определять

XPath-переменные. Эти переменные имеют разную область видимости в

таблице стилей, в зависимости от того, где они были определены и их

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

переменных не могут быть изменены во время обработки.

Хотя эта процедура может показаться сложной, однако она делает

XSLT по возможностям похожей на другие языки web-шаблонов. Если

таблица стилей состоит из единственного правила, предназначенного для

обработки корневого узла, в результат просто копируется всё содержимое

шаблона, а XSLT-инструкции (элементы 'xsl:…') заменяются вычисляемым

содержимым. XSLT предлагает даже специальный формат («literal result

element as stylesheet») для таких простых, одношаблонных трансформаций.

Однако, возможность определять отдельные шаблоны и правила сильно

увеличивает гибкость и эффективность XSLT, особенно при генерации

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

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

поиска - сохраним один из результатов в XML-файл и для XSLT-

преобразования воспользуемся следующим скриптом:<?php// Объект исходного XML-документа$xml = new DOMDocument("1.0", 'UTF-8');$xml->load('select.xml');

// Объект стиля$xsl = new DOMDocument(null, 'UTF-8');$xsl->load('xslt.xsl');

// Создание парсера$proc = new XSLTProcessor();

// Подключение стиля к парсеру$proc->importStylesheet($xsl);

// Обработка парсером исходного XML-документа$parsed = $proc->transformToXml($xml);

// Вывод результирующего кодаecho $parsed;?>

Данный скрипт загружает XML-документ из файла select.xml и

применяет к нему xsl-стиль из файла xslt.xsl.

Листинг файла select.xml<?xml version="1.0" encoding="UTF-8"?><response>

<lst name="responseHeader"> <int name="status">0</int> <int name="QTime">3</int> <lst name="params"> <str name="explainOther"/> <str name="fl">*</str> <str name="indent">on</str> <str name="start">0</str> <str name="q">*</str> <str name="hl.fl"/> <str name="qt">standard</str> <str name="wt">standard</str> <str name="fq">-video +price:[200 TO *] +popularity:[3 TO 6]</str> <str name="rows">10</str> <str name="version">2.2</str> </lst></lst><result name="response" numFound="3" start="0"> <doc> <arr name="cat">

<str>electronics</str><str>hard drive</str></arr>

<arr name="features"><str>SATA 3.0Gb/s, NCQ</str><str>8.5ms seek</str><str>16MB cache</str></arr>

<str name="id">6H500F0</str> <bool name="inStock">true</bool> <str name="manu">Maxtor Corp.</str> <date name="manufacturedate_dt">2006-02-13T15:26:37Z</date> <str name="name">Maxtor DiamondMax 11 - hard drive - 500 GB - SATA-300</str> <int name="popularity">6</int> <float name="price">350.0</float> </doc> <doc> <arr name="cat"><str>electronics</str><str>monitor</str></arr> <arr name="features"><str>30" TFT active matrix LCD, 2560 x 1600, .25mm dot

pitch, 700:1 contrast</str></arr> <str name="id">3007WFP</str> <bool name="inStock">true</bool> <str name="includes">USB cable</str> <str name="manu">Dell, Inc.</str> <str name="name">Dell Widescreen UltraSharp 3007WFP</str> <int name="popularity">6</int> <float name="price">2199.0</float> <float name="weight">401.6</float> </doc> <doc> <arr name="cat"><str>electronics</str><str>monitor</str></arr> <arr name="features"><str>19" TFT active matrix LCD, 8ms response time, 1280 x

1024 native resolution</str></arr> <str name="id">VA902B</str> <bool name="inStock">true</bool>

<str name="manu">ViewSonic Corp.</str> <str name="name">ViewSonic VA902B - flat panel display - TFT - 19"</str> <int name="popularity">6</int> <float name="price">279.95</float> <float name="weight">190.4</float> </doc></result></response>

Листинг xslt.xsl<?xml version="1.0" encoding="UTF-8" ?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml"> <xsl:output method="xml" indent="yes" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"/>

<xsl:template match="/"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-

8" /> <title>test1</title> <style type="text/css"> h1 { padding: 10px; padding-width: 100%;

background-color: silver } td, th { width: 40%; border: 1px solid silver; padding:

10px } td:first-child, th:first-child { width: 20% } table { width: 650px } </style> </head> <body> <xsl:apply-templates/> </body> </html> </xsl:template>

<xsl:template match="result/doc"> <h1>

<xsl:value-of select="str[@name='name']"/></h1><table>

<tr><td>Popularity</td><td><xsl:value-of

select="int[@name='popularity']"/></td></tr><tr>

<td>Price</td><td><xsl:value-of

select="float[@name='price']"/></td></tr>

</table> </xsl:template>

<xsl:template match="lst"></xsl:template>

</xsl:stylesheet>

В результате из XML-документа мы получаем HTML-документ с

форматированием и оформлением:

В приведенном выше примере используется два шаблона: первый – для

формирования структуры html-документа, воторой для вывода каждого

отдельного результата поиска: <xsl:template match="result/doc"> <h1>

<xsl:value-of select="str[@name='name']"/></h1><table>

<tr><td>Popularity</td><td><xsl:value-of

select="int[@name='popularity']"/></td></tr><tr>

<td>Price</td><td><xsl:value-of

select="float[@name='price']"/></td></tr>

</table> </xsl:template>

Рассмотрим основные части шаблона:<xsl:template match="result/doc"> … </xsl:template>

Данный блок определяет вывод узлов, которые попадают под шаблон

match="result/doc", т.е. находятся внутри узла doc, который

находится внутри узла result.<xsl:value-of select="str[@name='name']"/>

Вывод значения узла str, который содержит атрибут name, значение

которого равно name. Как видим, вывод значений из узлов xml-документа

отделен от форматирования, что позволяет определить его отдельно. В

данном случае, у нас определена html-таблица, в которую выводятся

значений из двух узлов результата поиска.<table>

<tr><td>Popularity</td><td></td>

</tr><tr>

<td>Price</td><td> </td>

</tr></table>

Задание для самостоятельного выполненияС использованием расширенного интерфейса запросов сформировать

следующие запросы:

1. Выбрать документы, содержащие в названии (поле name) video и не находящиеся в категории music (поле категории – cat)

2. Из результата предыдущего запроса вывести только следующие поля:

a. features

b. name

c. price

3. Выбрать документы, значение параметра стоимость (поле price) лежит в пределах от 100 до 200 и вывести в результаты только поля название и стоимость.

4. Вывести три любых документа из поискового индекса.

5. Вывести документы, значение параметра стоимость в которых больше 200, в документе нет упоминания слова video, популярность (поле popularity) лежит в пределах от 3 до 6. Вывести только название.

6. В XSL-шаблон добавить вывод еще трех полей:

a. Дата производства (manufacturedate_dt)

b. Наличие на складе (inStock)

c. Категория (cat)

Отчетпо лабораторной работеОтчет по лабораторной работе должен включать в себя:


2. Запросы и результаты запросов из задания для самостоятельного выполнения

3. Скорректированный XSL-шаблон и результаты XSLT-преобразования

4. Выводы о проделанной работе

asu.ugatu.ac.ruasu.ugatu.ac.ru/library/99/metodichka.docx · web viewОглавление....

Documents