Электронные издания - Владимир Вуль

Эффективность – главный критерий при определении применяемого метода полнотекстовой выборки. Эффективность поиска издания можно описать двумя характеристиками: точность и охват. Точность µ определяется отношением числа релевантных документов R к общему количеству документов в выборке N (µ = R/N). Охват ∑ характеризуется отношением числа релевантных документов в выборке R к общему числу релевантных документов в базе данных T (∑ = R/T).

В случае идеального поиска все выбранные документы полностью пригодны и исчерпывают список пригодных документов в базе данных, т. е. ∑ = 1 и µ = 1. Однако многочисленные исследования, выполненные различными специалистами, показали что точность и охват связаны друг с другом обратной зависимостью, а максимальное значение суммы µ + ∑ близко к 1,4. Сказанное иллюстрируется графиком, представленным на рис. 7.4.

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

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

Рис. 7.4. График зависимости величины охвата от точности

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

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

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

7.3.3. Оптимизация структуры базы данных

Из двух предыдущих разделов следует, что для лучшей защиты данных от несанкционированного доступа и ускорения работы поисковой системы целесообразно разделить функции поиска документов и их извлечения из базы данных. Для поиска целесообразно использовать атрибуты и ограниченный набор ключевых слов и выражений. Причем предпочтительнее производить атрибутивный поиск, и лишь при незнании пользователем атрибутов может быть организован контекстный поиск по ключевым словам и выражениям. Но и во втором случае пользователь не придумывает эти слова и выражения, а выбирает их из ограниченного множества, предоставляемого ему атрибутивной базой данных. Результатом такого поиска будет извлечение сведений об издании. Целесообразно применение вспомогательной БД сравнительно небольшого информационного объема, в которой хранятся так называемые метаданные – атрибуты документа: автор, название издания, формат, версия, аннотация, резюме, рецензии и отзывы. Для организации поиска по контексту полезно хранить в атрибутивной БД также и ограниченное множество ключевых слов. Это множество должно адекватно отображать ту предметную область, в которой работает издательство.

Рис. 7.5. Общая структурная схема атрибутивной базы данных

Из этого множества автором и редактором каждого издания отбирается подмножество слов и выражений, каждое из элементов которого полностью отвечает тематике данного издания. Возможно и автоматическое извлечение ключевых слов и выражений из аннотации, предисловия, рецензий и прочих документов, в концентрированной форме отражающих особенности издания. Однако затем следует сличить извлеченные автоматически выражения с множеством хранимых в базе данных, оставив только то, что попадает в зону пересечения этих множеств. Это традиционная реляционная БД, организованная в виде совокупности полей, соответствующих структуре метаданных. По атрибутивному запросу клиенту возвращается один документ или список релевантных документов в форме миниатюр, из которых он выбирает нужное издание, за которым может затем обратиться в основное информационное хранилище, если он обладает соответствующими правами доступа. Те же, кто ими не обладает, получает миниатюру, а также некоторые вспомогательные документы, характеризующие издание: аннотацию, рецензии, иногда – оглавление или развернутый план-проспект. Общая структурная схема такой базы данных представлена на рис. 7.5.

7.4. Проектирование хранилища изданий и атрибутивной БД

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

Хранилище данных – это централизованный интегрированный депозитарий информации. В данном контексте слово интегрированный означает, что удалена избыточная и ошибочная информация, выполнено объединение данных и полученная выверенная информация объединена в новую структуру. Хранилища данных отличаются от производственных баз данных или систем оперативной обработки транзакций (on-line transaction processing – OLTP) своим назначением и устройством. Действительно, OLTP-системы проектируются и оптимизируются для регулярного ввода, извлечения и обновления данных, тогда как хранилища данных – для длительного хранения и периодического извлечения данных. В OLTP-системах находятся текущие данные, подверженные частым изменениям, причем отдельные элементы в момент их ввода в базу данных могут быть неполными или даже неизвестными. В хранилищах же накапливаются данные, не меняющиеся со временем и избавленные от ошибок транзакций.

Основой хранилищ данных служит или реляционная модель, или многомерная схема. В реляционных системах трудно представлять отношения между конкретными объектами. Структуры данных в реляционных БД (РБД) плохо подходят для индексации текста. По этой причине в системы, опирающиеся на РБД, дополнительно включают средства полнотекстового поиска. Стоит, однако, иметь в виду, что такие разработчики СУБД, как Informix, Oracle и IBM, работают над улучшением способов работы с текстом в РБД. В ООБД имеется возможность разработать индексные структуры и методы доступа специально для объектов определенного типа. Кроме атрибутов для объектов можно определить семантику, формализованную в операциях над ними, и создать иерархию типов, которая будет отражать все более и более специфическую семантику.

Например, система, построенная на ООБД, может иметь тип данных content-object с операцией play. На следующих уровнях иерархии могут быть подтипы для объектов со специфическим содержанием: audio-object, video-object, animation-object, и подтипы для специфических форматов: WAVaudio-object, MP3-audio-object, MPEG2-video-object и пр. Независимо можно ввести тип text-index, определив для него операции автоматической индексации и выполнения запросов. В ООБД в число атрибутов могут включаться указатели на индивидуальные объекты – что позволяет легко реализовать упомянутые выше отношения вхождения документов.

Резюмируя, отметим, что ООБД сами по себе имеют достаточный потенциал, чтобы стать законченным решением для системы на серверной стороне. Считается, что ООБД уступают реляционным системам в надежности, работоспособности и возможностях передачи данных, т. е. характеристиках, существенных для масштабируемости. Однако, новый Universal Server компании Informix, в котором объединены "объектно-реляционные" средства Illustra с масштабируемостью самой Informix, сможет преодолеть эти недостатки. Программное обеспечение DataBlade, входящее в Informix Universal Server, хорошо согласуется с рассматриваемой архитектурой издательской системы. Помимо того, в DataBlade имеется возможность определять семантику новых типов данных непосредственно в БД.