Oracle працювати з текстовими документами дуже просто, комп’ютерна документація від а до я
Oracle: працювати з текстовими документами дуже просто
Oracle Text є штатна можливість СУБД Oracle зберігати в загальній БД поряд зі звичайними даними документи і будувати запити, що до цих документів, так і до збережених у файлах ОС або в інтернеті. Документи можуть бути представлені різними форматами. Розглядаються початку роботи з Oracle Text з урахуванням використання текстового індексу типу CTXSYS.CONTEXT і оператора CONTAINS.
СКБД Oracle відома в першу чергу як система управління «фактографічними» даними, але з першої половини 90-х років в ній стали з'являтися можливості зберігати і обробляти «складно влаштовані» дані. Однією з перших таких можливостей стала робота в версії 7.3 з частково структурованими даними: текстовими документів.
До наших днів можливість роботи з текстовими документами в Oracle кілька разів змінила назву (SQL * TextRetrieval -> Text Server -> Oracle ConText -> Oracle Text) і істотно розвинулася. Починаючи з версії 9, вона вбудована в стандартну поставку СУБД Oracle, не вимагає, як раніше, окремого ліцензування і автоматично включається до складу типової БД. При відсутності ж в БД цю можливість можна встановити самостійно або за допомогою DBCA, або прогоном сценарію dr0inst.sql (версія 9 і що передують) або ж catctx.sql (з версії 10) в [ORACLE_HOME] / ctx / admin.
Текстові можливості Oracle знаходять внутрішнє вживання, наприклад на Oracle Ultra Search, Content Management (раніше iFS) або в XML DB.
Текстові можливості СУБД Oracle засновані на використанні спеціального виду індексу, що є одним з вбудованих в систему варіантів "предметного" індексу (domain index), що використовується для організації роботи зі складно влаштованими даними. Oracle Text має в готовому вигляді три види текстового індексу:- CTXSYS.CONTEXT - для виконання повнотекстового пошуку по текстових документів;
- CTXSYS.CTXCAT - для виконання спрощеного і прискореного пошуку по «каталогам» (одно-двустрочним текстовим описам);
- CTXSYS.CTXRULE - для побудови «класифікацій» документів при тому, що клас може бути охарактеризована характерних запитів.
Тут розглядаються загальні можливості найбільш популярною різновиди індексу CTXSYS.CONTEXT. Цей вид текстового індексу дозволяє зберігати в БД текстові документи і виконувати повнотекстові запити до документів як внутрішнього зберігання, так і зовнішнього (файлова система, інтернет).
Для зручності створимо спеціального користувача:
Ролі CONNECT і RESOURCE приписані користувачам CTX для простоти прикладу, і використовувати їх в робочій БД неправильно; роль же CTXAPP спожито по суті, так як без неї пользоваттель CTX не зможе звертатися до необхідних об'єктів схеми CTXSYS. Виконаємо:
Зверніть увагу: індекс DOCS_VC2DOC_IDX - не простий, а «прикладної» (domain); точніше - визначеного типу CTXSYS.CONTEXT, тобто «текстовий». У загальному випадку створення такого індексу містить вказівку ряду спеціальних параметрів (приклади будуть далі), але для першого знайомства досить покластися на умолчательную характеристики.
Основою для запитів до документів за індексом типу CTXSYS.CONTEXT є «оператор» CONTAINS. За своїм вживання оператор Oracle SQL практично не відрізняється від функції. Оператор CONTAINS повертає міру, інакше рівень, відповідності документа текстовому запиті ( «relevance»).
Кілька пояснювальних прикладів. підготовка:
Зверніть увагу, що ступінь відповідності документа запиту не є простою частотою вживання в документі слова. Вона залежить також від загальної кількості запитуваних документів і від кількості документів, де є шукані словоформи. Її обчислення в Oracle засноване на формулі Селтона. Результат, який дає формула, відображається на діапазон цілих чисел між 0 та 100.
Наступні кілька прикладів, виконаних самостійно, допоможуть пояснити поведінку оператора CONTAINS і отримати уявлення про деякі додаткові можливості контекстного запиту:
Повний перелік і опису реалізованих операторів для складання контекстного запиту по документам (назва «оператор» тут невдало збігається з ім'ям «оператором» самої функції CONTAINS) мається на документації по Oracle.
На практиці використання звернення до CONTAINS в виразах для формування стовпців в реченні SELECT не завжди зручно і не сприяє ефективності. Вимушена в цьому відношенні міра - використання функції ( «оператора») SCORE, яка повертає той же результат, що і CONTAINS, але яку якомога повторювати в запиті багаторазово без остраху уповільнити обчислення. Однак оскільки операторів CONTAINS в запиті може зустрічатися кілька, придумана спеціальна техніка числових «міток», які визначають відповідність операторів SCORE і CONTAINS в рамках запиту SQL. Мітки вказуються як параметр операторів (ще одна вимушена і не дуже елегантна міра) і вибираються довільно. Приклади цієї техніки:
Практично обробку текстової інформації в Oracle Text забезпечує текстовий індекс. Змістовно він організовує зберігання «зверненого списку», який за пред'явленим пошуковому слову видає список пар <документ, словоместо>. Для цього він зберігає список документів, позицій словоформ в документах і одне або кілька індексованих слів в кожній позиції.
Технічно текстовий індекс влаштований складніше звичайних B-деревовидного або ж поразрядного індексів хоча б тим, що реалізований відразу групою об'єктів і групою структур зберігання. У цьому легко переконатися:
Приклад видачі з таблиці DR $ DOCS_VC2DOC_IDX $ I:
Ще одна відмінність текстового індексу від звичайного в тому, що він не правиться автоматично при правці документа. наприклад:
У силу громіздкості текстового індексу відомості про необхідні виправлення збираються в окремій таблиці, а сама правка виконується у міру потреби вручну:
(Синхронізувати індекс можна і командою ALTER INDEX, але зараз фірма Oracle цього не радить).
Стандартний прийом - створити завдання для планової коригування текстового індексу за розкладом.
Незграбність (частково вимушена) правки текстового індексу компенсується високою швидкістю обертання до нього при запитах до СУБД. Однак спостерігати план виконання запиту доводиться в цьому випадку своєрідно. Звичайна команда EXPLAIN PLAN багато не дасть, але звернення до текстового ( «прикладного") індексу вона відзначить:
(Форма видачі плану відповідає версії 10, по якій готувався матеріал).
Деталі відпрацювання самого текстового (НЕ SQL) запиту спостерігаються через спеціальний таблицю, а не звичну PLAN_TABLE. Створити її можна приблизно так: