Текстові документи в Oracle: різноманітність джерел, форматів, запитів, Комерція, Різне, статті

Ви думаєте, мені це легко далося? Я працював над джерелами.

І. Ільф, Є. Петров. Золоте теля. Розповідь бухгалтера Берлаги.

Анотація


Продовження статті «Oracle: працювати з текстовими документами дуже просто», В якій було показано, як засобами Oracle Text будувати повнотекстовий індекс типу CTXSYS.CONTEXT до текстових документів, збереженим в БД, і як робити запити за індексом. Тут показано, як можна індексувати документи в полях CLOB, поза БД, а також документи, представлені іншими форматами, ніж чим простим текстовим. 


Інші джерела документів


Приклад таблиці, розглянутої в попередній статті, не цілком реалістичний, так як розмір документів в ньому обмежувався максимум чотирма тисячами байтів для типу VARCHAR2. У той же час Oracle дозволяє створювати індекс типу CTXSYS.CONTEXT ще на поля типу CLOB, XMLTYPE і навіть BFILE і URITYPE. Виконаємо:


TRUNCATE TABLE docs;


DROP INDEX docs_vc2doc_idx;


ALTER TABLE docs DROP COLUMN vc2doc;


ALTER TABLE docs ADD ( clobdoc CLOB );


INSERT INTO docs VALUES ( 1, “Mary had a little lamb” );


INSERT INTO docs VALUES ( 2, “Twinkle, twinkle little star” );


INSERT INTO docs VALUES ( 3, “This Lamb is my lamb” );


CREATE INDEX docs_clobdoc_idx ON docs ( clobdoc ) INDEXTYPE IS ctxsys.context;


Перевірка:


CTX> SELECT CONTAINS ( clobdoc, “little” ) AS score FROM docs;


     SCORE


———-


         4


         4


         0


Наступний приклад показує, що Oracle дозволяє створювати в БД текстовий індекс на документи, що знаходяться поза бази.


Нехай на сервері є каталог c:distrora102docdisk з документацією по Oracle. Там є простий текстовий файл readme.txt:



Створимо в БД покажчик на каталог і перевизначити таблицю DOCS:


CONNECT / AS SYSDBA


CREATE OR REPLACE DIRECTORY docs_dir AS “c:distrora102docdisk”;


GRANT READ ON DIRECTORY docs_dir TO ctx;


CONNECT ctx/ctx


TRUNCATE TABLE docs;


DROP INDEX docs_clobdoc_idx;


ALTER TABLE docs DROP COLUMN clobdoc;


ALTER TABLE docs ADD ( bfiledoc BFILE );


INSERT INTO docs VALUES ( 1, BFILENAME ( “DOCS_DIR“, “readme.txt” ) );


CREATE INDEX docs_bfiledoc_idx ON docs ( bfiledoc ) INDEXTYPE IS ctxsys.context;


Перевірка:


CTX> SELECT CONTAINS ( bfiledoc, “oracle support” ) AS score FROM docs;


     SCORE


———-


        12


Зверніть увагу, що на відміну від попередніх прикладів тут документи зберігаються у файловій системі, а в БД створюється текстовий індекс; саме його і використовує СУБД для обчислення результатів, незважаючи на те, що формально запит звертається до документів. Це може призводити до помилок при спробі витягти сам документ через його зникнення вже після створення індексу – картина цілком звична для тих, хто користується пошуковими машинами в інтернеті.


Як і раніше, зміни в документах не відіб’ються в індексі самі собою. Однак при зберіганні документів в БД система мала можливість фіксувати факт їх зміни і надавала інформацію про неузгодженість вмісту індексу і документів, ніж можна було користуватися, вирішуючи, чи варто оновити індекс; в разі ж зовнішнього зберігання документів відомості про можливі розузгодження накопичуватися в БД не можуть.


Інші формати документів


У тому ж каталозі файлової системи є версії вмісту readme.txt в інших форматах: це readme.htm і readme.pdf. Файл формату HTML має наступний вигляд:



Виконаємо:


TRUNCATE TABLE docs;


DROP INDEX docs_bfiledoc_idx;


ALTER TABLE docs DROP COLUMN bfiledoc;


ALTER TABLE docs ADD ( htmldoc BFILE );


INSERT INTO docs VALUES ( 1, BFILENAME ( “DOCS_DIR“, “readme.htm” ) );


CREATE INDEX docs_htmldoc_idx ON docs ( htmldoc )


INDEXTYPE IS CTXSYS.CONTEXT


PARAMETERS (


   “filter CTXSYS.NULL_FILTER section group CTXSYS.HTML_SECTION_GROUP”


);


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


Перевірка:


CTX> SELECT CONTAINS ( htmldoc, “oracle support” ) AS score FROM docs;


     SCORE


———-


        12


Файл формату PDF має наступний вигляд:



Виконаємо:


TRUNCATE TABLE docs;


DROP INDEX docs_htmldoc_idx;


ALTER TABLE docs DROP COLUMN htmldoc;


ALTER TABLE docs ADD ( autodoc BFILE );


INSERT INTO docs VALUES ( 1, BFILENAME ( “DOCS_DIR“, “readme.pdf” ) );


CREATE INDEX docs_autodoc_idx ON docs ( autodoc )


INDEXTYPE IS CTXSYS.CONTEXT


PARAMETERS (


   “filter CTXSYS.AUTO_FILTER section group CTXSYS.AUTO_SECTION_GROUP”


);


Замість CTXSYS.AUTO_FILTER В параметрах індексу можна вказати CTXSYS.INSO_FILTER. До версії 10 тільки так і треба було чинити, однак з версії 10 фірма радить використовувати новий AUTO-фільтр як більш сучасну і досконалу реалізацію старого INSO-фільтра (купленого свого часу фірмою Oracle у фірми Inso). Фільтр використовується СУБД для попередньої обробки тексту перед побудовою індексу.


Перевірка:


CTX> SELECT CONTAINS ( autodoc, “oracle support” ) AS score FROM docs;


     SCORE


———-


         6


Зверніть увагу на відмінний від попередніх прикладів показник відповідності документа запитуваної комбінації слів (6 проти 12). Ручна перевірка показує, що поєднання “oracle support” в кожному з текстів зустрічається однакове число разів, чотири рази, так що ступінь відповідності всіх документів повинна бути однакова. Останній результат є наслідком особливості обробки документів PDF фільтром CTXSYS.AUTO_FILTER (до версії 10 CTXSYS.INSO_FILTER), застосованому в побудові індексу, і особливостями конкретного документа. Зокрема, згідно з документацією Oracle за версією 10, фільтр CTXSYS.AUTO_FILTER не помічає або «не обов’язково правильно» обробляє:



У нашому документі використана версія PDF 1.4, проте сам документ складений неоднорідне, що призводить до ігнорування при побудові індексу останнього абзацу документа і його заголовка, в яких є два входження комбінації “oracle support” із загальних чотирьох (на це нагадує і зовнішній вигляд останнього абзацу):



Якби документ readme.pdf був складений «правильно», показник його відповідності наш запит також був би 12.


Шорсткості (на жаль!) ​​Обробки документів PDF компенсуються універсальністю AUTO / INSO-фільтра. Це універсальний фільтр, здатний обробити при індексації документів великий перелік різних форматів, в тому числі (крім PDF) простий текстовий, HTML, DOC, RTF і ряд інших (всього понад півтори сотні). Наприклад, виконаємо:


INSERT INTO docs VALUES ( 2, BFILENAME ( “DOCS_DIR“, “readme.txt” ) );


INSERT INTO docs VALUES ( 3, BFILENAME ( “DOCS_DIR“, “readme.htm” ) );


EXECUTE ctx_ddl.sync_index ( “docs_autodoc_idx” )


Перевірка:


CTX> SELECT CONTAINS ( autodoc, “oracle support” ) AS score FROM docs;


     SCORE


———-


         6


        12


        12


У порядку вправи пропонується перевірити роботу фільтра AUTO / INSO на файлах форматів DOC і RTF.


Конкретний формат документа фільтр AUTO розпізнає автоматично. Тим не менш, для деяких популярних форматів фірма Oracle заради кращої ефективності радить використовувати специфічні фільтри: наприклад, для формату HTML – той, що був застосований в прикладі вище. Фільтри (та інші параметри текстового індексу) для форматів HTML і XML дозволяють робити запити з урахуванням розмітки документів.


Параметри індексу


Параметри індексу дозволяють задавати різні властивості індексу, наприклад:


– Фільтри для документа


– Тип місцезнаходження документа


– Тип лексичного аналізатора


– Забезпечення індексом морфологічного, нечіткого пошуку; зберігання префіксів


– Облік структури документа, такий як пропозиції, параграфи або розмітка HTML / XML


– Список неіндексіруемих слів.


Інша назва для параметрів текстового індексу в Oracle – «переваги» (preferences).


Приклад використання як властивості індексу більш зручного, ніж в прикладах вище, обліку місцезнаходження документа:


TRUNCATE TABLE docs;


DROP INDEX docs_autodoc_idx;


ALTER TABLE docs DROP COLUMN autodoc;


ALTER TABLE docs ADD ( docname VARCHAR2 ( 100 ) );


INSERT INTO docs VALUES ( 1, “c:distrora102docdisk eadme.txt” );


INSERT INTO docs VALUES ( 2, “c:distrora102docdisk eadme.htm” );


INSERT INTO docs VALUES ( 3, “c:distrora102docdisk eadme.pdf” );


CREATE INDEX docs_docname_idx ON docs ( docname )


INDEXTYPE IS CTXSYS.CONTEXT


PARAMETERS (


   “filter CTXSYS.AUTO_FILTER


    section group CTXSYS.AUTO_SECTION_GROUP


    datastore CTXSYS.FILE_DATASTORE


);


Перевірка:


CTX> COLUMN docname FORMAT A35


CTX> SELECT docname, CONTAINS ( docname, “oracle support” ) FROM docs;


DOCNAME                             CONTAINS(DOCNAME,”ORACLESUPPORT”)


———————————– ———————————


c:distrora102docdisk eadme.txt                                 12


c:distrora102docdisk eadme.htm                                 12


c:distrora102docdisk eadme.pdf                                  6


Більш того, з кожним параметром пов’язаний один або більше атрибутів. Проте явне вказівку атрибутів додає організаційної складності, так як проводиться технікою викликів системних процедур, і не оформляється запитом SQL.


Підтримка текстовим індексом документів російською


Наведені вище приклади були для текстів англійською. Обробка текстів на різних мовах має відмінності відповідно відмінностей пристрої самих мов. Стандартна поставка Oracle Text здатна працювати з усіма мовами, що підтримуються Oracle, але в рамках порівняно простого контекстного пошуку (про нього і йшла мова вище), для якого відмінності мов несуттєві. Тобто контекстний пошук можливий і для документів російською – це легко перевірити в порядку вправи. В цьому відношенні російський нічим не краще естонського або, скажімо, тамільської мов. Більше того, контекстний пошук в документів, за запевненням документації Oracle, можливий не тільки для мов, перерахованих в таблиці V $ NLS_VALID_VALUES, а й для будь-якої мови, кодування якого включена в Unicode. Для цього, правда, потрібно, щоб Unicode була основною кодуванням для БД (це повинно вказуватися при створенні бази).


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


Для тих, кому не пощастило, розробники Oracle Text дали механізм для самостійної побудови просунутих можливостей запитів. Мені відома лише одна спроба застосувати цей механізм до російської мови, завершилася створенням готового продукту. Подробиці можна знайти за адресою. Там же є російською мовою ряд матеріалів загального характеру по обробці текстових документів. Матеріали цілком підтверджують здогадку про те, що в кінцевому підсумку складність обробки текстових документів порівнянна з складністю природних мов, тобто що робота з текстовими документами в Oracle і де б то не було – це дуже складно.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*