Зберігання XML даних (Storing XML Data) Частина 1, Різне, Інтернет-технології, статті

Марк Скандіна, Бен Чанг, Джайн Ванг

Частина 1


В Oracle Database 10g у вас є кілька можливостей зберігання XML даних. Ви можете розділити XML документ на частини і зберігати дані в одній або кількох реляційних таблицях, поміщати XMLType-и цілком у CLOB-и або зареєструвати XML схему і зберігати їх в об’єктно-орієнтованої пам’яті на мові XML Schema, призначеному для XMLType. Якщо немає необхідності коригування XML-контенту, також можна зберегти XML документи як зовнішні, використовуючи механізм External Tables (Зовнішніх таблиць).

Ця глава дає містить огляд способів зберігання XML, доступних в
Oracle Database 10g і демонструє різні варіанти застосування цих технологій. Даються приклади використання утиліт Oracle SQL * Loader і XML SQL Utility (XSU) для завантаження XML документів в або XMLType-таблицю, або реляційну таблицю в Oracle
Database 10g. Ми почнемо з найпростішого формату збереження: CLOB XMLTypes (XMLType в CLOB).

Зберігання XML документів в CLOB XMLTypes

Використовуючи CLOB XMLType, XML документи зберігаються як CLOB’и c установкою XML інтерфейсів, що надаються XMLType. Не дивлячись на те, що перед завантаженням даних можна опціонально запустити будь XML процес, наприклад, введення даних XML в XML схему або DTD, розміщення CLOB XMLType не потребує ні в якому XML процесі, за винятком перевірки формальної правильності та дозволу існування.

Запит та оновлення CLOB XMLType

Зберігання у вигляді CLOB XMLType найкращим чином консервує оригінальний формат XML документів і дає максимальну гнучкість при розвитку XML схеми.

Однак, зберігання XML документів в CLOB XMLTypes призводить до дорогою надлишкової обробці при запиті XML контенту такими функціями, як XMLType.Extract() або XMLType.ExistsNode(),
оскільки ці операції вимагають під час обробки побудови в оперативної пам’яті дерева XML DOM і виконання функціональних Xpath оцінок. Крім того, будь-яка операція поновлення (update) може бути здійснена тільки на рівні документа. Це означає, що вам необхідно оновлювати весь XML документ після кожного навіть незначної зміни будь-якого XML елемента.

Тому, як правило, слід уникати використання XMLType функцій при виконанні незначних XML оновлень або запитів з задіянням Xpath при діях з CLOB XMLTypes.

Замість XPath-запитів до CLOB XMLTypes, Oracle Text забезпечує пошук по всьому тексту, підтримуючи обмежене безліч [шляхів] XPaths. Ця функціональність дозволяє виконувати ХРath запити в XMLTypes, використовуючи CONTEXT індекс, створюваний Oracle Text, який є дуже корисним і масштабованим механізмом для додатків, що ми обговоримо в розділі 11 (“Searching XML Data”).

Дії з символьними кодуваннями в CLOB XMLTypes

Потрібно знати, що коли XML документ зберігається в Oracle Database, символьна перекодування автоматично виконується перед введенням даних, при цьому по набору символів (character set – кодова таблиця), встановленому в базі даних, конвертуються всі текстові дані, включаючи XML документи. Винятком є ​​зберігання типів даних BLOB, NCHAR і NCLOB.

Внаслідок такого неявного перетворення набору символів, актуальна кодування XML даних і декларована в пролозі
<?XML?> кодування – не одне й те саме. У нинішньому релізі Oracle Database 10g, XMLType API ігнорує декларовану в пролозі
<?XML?> кодування і припускає, що XML дані зберігаються в CLOB XMLTypes в кодуванні бази даних. Отже, при завантаженні клієнтських XML даних необхідно переконатися, що конверсія кодів успішно виконана.

Якщо XML документ спочатку зберігається в кодуванні клієнта, відмінною від алфавіту бази даних, то для того, щоб гарантувати правильність конверсії з кодування клієнта в алфавіт бази даних, необхідно встановити змінну середовища NLS_LANG, яка називає кодову таблицю клієнта. Однак, якщо у змінній встановлена ​​така ж кодування, як і набір символів бази даних, оригінальний текст в базі даних буде збережений “як є” без перевірки правильності символів і конверсії. Іншими словами, якщо змінна середовища NLS_LANG не встановлена ​​або встановлена ​​неправильно, а XML документ має інше кодування, ніж база даних, в базі даних буде зберігається просто сміття.

ЗАУВАЖЕННЯ

Якщо XML документ містить символи, які не включені в алфавіт бази даних, то перед додаванням даних в CLOB XMLTypes ви отримаєте помилку Invalid Character. Можливим рішенням може служити використання NCLOB або BLOB для збереження даних в базі даних і побудова XML програми середнього шару або зовнішньої PL / SQL процедури, іспользющіх XDK API для обробки XML даних.

Через конверсії алфавіту може відбутися конфлікт між чинної кодуванням і кодуванням, декларованої в пролозі
<?XML?>, при зчитуванні XML даних з CLOB XMLTypes, під уникнути чого слід створити реверсивну кодову таблицю (reverse character set) або замінити декларірацію в <?XML?> пролозі, щоб зробити узгодити кодування. Це важливо, тому що синтаксичний аналізатор XML використовує перші 4 байти прологу
<?XML?> для визначення кодування XML документів, та може бути визначено тільки, що алфавіт базується на ASCII-або на EBCDIC-кодування. Якщо він базується на ASCII кодуванні, то синтаксичний аналізатор XML може визначити тільки, що він є UTF-8 або UTF-16. Інакше, це залежить від атрибутів кодування в <?XML?>. Тому, якщо ви маєте XML документ не в UTF-8 або UTF-16 кодуваннях, то ви повинні вкласти правильну XML декларовану кодування, чий алфавіт використовується, як показано нижче:

<?xml version=”1.0″ encoding=’Shift-JIS‘?>

Зберігання XML документів в XMLTypes мовою XML Schema

Для збільшення швидкості ХРath запитів і незначних оновлень XMLTypes, можна створити XMLTypes на осенове XML Schema. Один із способів це зробити – треба зіставити зареєстровані XML схеми з стовпцями або таблицями XMLType, використовуючи XMLSCHEMA. Ви також можете створити XMLType таблиці, спеціфіціруя анотацію DEFAULT TABLE в зареєстрованих XML схемах.

Всі ці підходи створюють XMLTypes, базовані на XML Schema, де набори об’єктно-реляційних таблиць / об’єктів відповідають XML об’єктам, визначеними в XML схемі. Єдина відмінність між створенням заданої за замовчуванням (default) в процесі реєстрації XML схеми таблиці і використанням ключового слова (keyword) XMLSCHEMS полягає в тому, що перше рішення дозволяє XML документів, відповідним зареєстрованої XML схемі, перебувати під управлінням репозиторію Oracle XML DB. Якщо має місце підтримка репозиторію XML DB, можна не тільки отримувати і оновлювати XML в SQL, але також і управляти XML документами, що зберігаються в репозиторії XML DB, використовуючи такі інтерфейсні протоколи, як FTP і HTTP / WebDAV.

Реєстрація XML схеми

Реєстрація XML схеми визначається відображенням XML-to-SQL і ієрархічної об’єктно-реляційної структурою для збереження XML документів в базі даних Oracle. Ми подивимося, як це жделается, використовуючи створених у 8-й главі користувача на ім’я DEMO і папку
WebDAV.

Перше, вам потрібно скопіювати XML схему для записів про клієнтів,
contact_simple.xsd, В папку /public WebDAV. Далі зміст цієї схеми:

<xsd:schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<xsd:element name=”Customer” type=”CustomerType”/>
<xsd:complexType name=”CustomerType”>
<xsd:sequence>
<xsd:element name=”NAME” type=”xsd:string”/>
<xsd:element name=”EMAIL” type=”xsd:string”/>
<xsd:element name=”ADDRESS” type=”xsd:string”/>
<xsd:element name=”PHONE” type=”phoneType”/>
<xsd:element name=”DESCRIPTION” type=”contentType”/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=”ContentType” mixed=”true”>
<xsd:sequence>
<xsd:any minOccurs=”0″ maxOccurs=”unbounded”
processContents=”skip”/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name=”phoneType”>
<xsd:restriction base=”xsd:string”>
<xsd:pattern value=”\(\d{3}\)\d{3}-\d{4}”/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

Для реєстрації цієї XML схеми в XML DB можна застосувати наступну PL / SQL процедуру:

ALTER SESSION SET EVENTS=’31098 trace name context forever’;
BEGIN
DBMS_XMLSCHEMA.registerURI(
‘http://localhost:8080/public/contact_simple.xsd’,
‘/public/contact_simple.xsd’,
LOCAL=>TRUE, GENTYPES=>TRUE, GENBEAN=>FALSE,
GENTABLES=>TRUE);
END;

ЗАУВАЖЕННЯ

Для використання команди ALTER SESSION вам потрібно зареєструватися як SYS і надавати привілеї ALTER SESSION користувачеві DEMO, використовуючи команду “GRANT ALTER SESSION TO DEMO”. Інакше ви отримаєте повідомлення про помилку ORA-01031: Insufficient Privileges (Недостаточнопрівілегій).

У функції DBMS_XMLSCHEMA.registerURI() перший параметр – це схема URI,
http://localhost:8080/public/contact_simple.xsd, Яка унікально ідентифікує зареєстровану XML схему в XML DB. Другий параметр – це XML DB URI (XDBUri),
/public/contact_simple.xsd, звертаються до файлу
contact_simple.xsd
в папці /public репозиторію XML DB.
Наступні параметри визначають регистрируемую схему: локальна – (LOCAL => TRUE) або глобальна (LOCAL => GLOBAL), а також що буде створено: об’єктні типи – (GENTYPES => TRUE) і таблиці по замовчуванням (default) (GENTABLES => TRUE). Параметр GENBEAN НЕ обов’язковий і в даний час не виконує жодної функції. Якщо XML схема зареєстрована як глобальна в XML DB, то вона може бути спільно використовується різними користувачами бази даних. Інакше спільне використання XML схеми не дозволяється. Можна встановити GENTABLES => FALSE, якщо не треба, щоб перед реєстрацією XML схеми Oracle XML DB створював default таблиці. В такому випадку можна створити XMLType таблиці, використовуючи ключове слово XMLSCHEMA, як показано нижче:

CREATE TABLE customer_xmltype_tbl OF XMLTYPE
XMLSCHEMA
“http://localhost:8080/public/contact_simple.xsd”
ELEMENT “Customer”;

Крім того, можна використовувати наступний синтаксис для визначення стовпців XMLType, що зберігаються при использовани XML
Schema:

CREATE TABLE customer_col_tbl(
id NUMBER,
record XMLType)
XMLTYPE COLUMN record STORE AS OBJECT RELATIONAL
XMLSCHEMA “http://localhost:8080/public/contact_simple.xsd”
ELEMENT “Customer”;

Коль скоро для зберігання XMLType стовпців і таблиць застосовуються одні і ті ж прийоми, у наступних секціях ми будемо детально розглядати тільки XMLType таблиці на XML Schema.

В процесі реєстрації XML схеми можна використовувати наступну команду для створення файлі трасування в [директорії, визначається параметром ініціалізації USER_DUMP_DIR], в якому відіб’ються DLL, використовувані для створення об’єктних таблиць і типів даних:

ALTER SESSION SET EVENTS=’31098′ TRACE NAME CONTEXT FOREVER;

Для розміщення файлі трасування необхідно перевірити ID ідентифікатор поточної сесії, звернувшись до уявлень V $ SESSION і V $ PROCESS. Перед запитом до V $ SESSION і V $ PROCESS від імені користувача DEMO, вам необхідно увійти як SYS і дати користувачеві DEMO привілей SELECT з уявлень V $ SESSION і V $ PROCESS, як показано далі:

GRANT SELECT ON V_$SESSION TO DEMO;
GRANT SELECT ON V_$PROCESS TO DEMO;

ЗАУВАЖЕННЯ

Коль скоро V $ SESSION і V $ PROCESS – це просто синоніми уявлень, то ніяких інших привілеїв на них дати не можна.

Застосувавши наступну SQL команду можна знайти ідентифікатор сесії, яка відповідає файлі трасування:

SELECT a.spid
FROM V$PROCESS a, V$SESSION b
WHERE a.addr=b.paddr
AND b.audsid=userenv(‘sessionid’);

Значення, що повертається:

SPID
————
2796

У файлі трасування є ім’я, структуроване як
orclX_ora_<Session_id>.trc і можна дізнатися [значення параметра] USER_DUPM_DIR, виконавши наступну команду від імені SYS:

SQL> SHOW PARAMETERS user_dump_dest
NAME TYPE VALUE
———————————————————–
user_dump_dest string D:\ORACLE\ADMIN\ORCLX\UDUMP

І далі, наявність файлі трасування
orclX_ora_<Session_id>.trc в USER_DUPM_DIR можна перевірити наступною командою:

SQL> host ls d:\oracle\admin\orclX\udump\orclX_ora_2796.trc
orclX_ora_2796.trc

Так як цей файл містить список DDL, що використовуються для створення об’єктних таблиць або типів даних, це потрібна довідка при налагодженні реєстрації XML схеми.

Тепер давайте більш докладно розглянемо створену структуру зберігання, виконавши в SQL * Plus наступну команду:

SQL> SELECT object_name, object_type
2 FROM USER_OBJECTS
3 WHERE object_name LIKE ‘%Customer%’;
OBJECT_NAME OBJECT_TYPE
————————- ——————–
Customer260_TAB TABLE
Customer260_TAB$xd TRIGGER
CustomerType259_T TYPE

Результат показує, що в процесі реєстрації XML схеми були створені три об’єкти. Якщо більш детально подивитися на визначення типів і таблиць, то можна побачити й іншу інформацію про створені об’єктах. По-перше, можна отримати структуру таблиці
Customer260_TAB:

SQL> DESC “Customer260_TAB”;

В результаті маємо наступне:

Name                                        Null?            Type
—————————————– ——– ——————-
TABLE of SYS.XMLTYPE(XMLSchema “http://localhost:8080/public/contact_
simple.xsd” Element ”
Customer”) STORAGE Object-relational TYPE “CustomerType259_T”

ЗАУВАЖЕННЯ

Навіть якщо XML елемент використовує змішаний регістр або нижній регістр (mixed case or lowercase), за замовчуванням імена default таблиці і об’єктів будуть залежні від регістру. Отже, необхідно використовувати подвійні лапки при зверненнях до таких іменам, як “Customer260_TAB”.

Представлена ​​вище структура показує що:


Дивлячись на цю структуру CustomerType259_T, можна побачити, що цей тип містить

SQL> DESC “CustomerType259_T”
“CustomerType259_T” is NOT FINAL
Name Null? Type
———————————– ——– ————————
SYS_XDBPD$ XDB.XDB$RAW_LIST_T
NAME VARCHAR2(4000 CHAR)
EMAIL VARCHAR2(4000 CHAR)
ADDRESS VARCHAR2(4000 CHAR)
PHONE VARCHAR2(4000 CHAR)
DESCRIPTION contentType257_T

Всі XML елементи в XMLType кореспондуються з відповідними типах даних бази даних. У цьому прикладі елементи NAME, EMAIL, ADDRESS і PHONE, як найпростіші типи в XML схемі, збережені як VARCHAR2. Так як в XML схемі немає обмеження на довжину рядка, Oracle XML DB встановив 4000 символів, як значення за замовчуванням ширини даних стовпців. З іншого боку, нові об’єктні типи були створені для складних типів, визначених в XML схемі. В даному прикладі contentType257_T створений для зберігання опису замовників, як показано далі:

SQL> DESC “contentType257_T”;
“contentType257_T” is NOT FINAL
Name Null? Type
———————————- ——– ————————
SYS_XDBPD$ XDB.XDB$RAW_LIST_T
SYS_XDBANY258$ VARCHAR2(4000 CHAR)

Зауважимо, що Oracle XML DB визначає стовпець SYS_XDBANY258 $ як VARCHAR2 (4000) для зберігання елемента <xsd:any/>,
визначеного в елементі <DESCRIPTION>. Стовпець SYS_XDBPD $ – це позиція стовпця дескриптора, створеного XML DB для зберегти DOM точність XML документів. Інформація, така як: коментарі, інструкції обробки, префікси простору імен і список споріднених XML елементів, зберігається в стовпці SYS_XDBPD $. Отже, цей стовпець використовується, щоб зберегти цілісність оригінального XML документа в DOM трансверсалями
(transversals).

Для ще більш детального вивчення таблиці Customer260_TAB
слід запросити подання USER_TAB_COLS:

SQL> SELECT column_name,data_type,

2 CASE WHEN hidden_column=’YES’ THEN ‘hidden’
3 WHEN virtual_column=’YES’ THEN ‘virtual’
4 ELSE null END as attr
5 FROM USER_TAB_COLS
6 WHERE table_name=’Customer260_TAB’
7 ORDER by virtual_column desc, column_name;
COLUMN_NAME DATA_TYPE ATTR
——————– ————————- ——-
SYS_NC_ROWINFO$ XMLTYPE virtual
XMLDATA CustomerType259_T hidden
ACLOID RAW hidden
OWNERID RAW hidden
SYS_NC00007$ RAW hidden
SYS_NC00014$ RAW hidden
SYS_NC_OID$ RAW hidden
SYS_NC00009$ VARCHAR2 hidden
SYS_NC00010$ VARCHAR2 hidden
SYS_NC00011$ VARCHAR2 hidden
SYS_NC00012$ VARCHAR2 hidden
SYS_NC00016$ VARCHAR2 hidden
SYS_NC00008$ XDB$RAW_LIST_T hidden
SYS_NC00015$ XDB$RAW_LIST_T hidden
XMLEXTRA XMLTYPEEXTRA hidden
SYS_NC00004$ XMLTYPEPI hidden
SYS_NC00005$ XMLTYPEPI hidden
SYS_NC00013$ contentType257_T hidden

Зауважимо, що вираз CASE вибирає результат з однієї або більше альтернатив. Воно використовує опцію SELECTOR для специфицирования вирази, чиє значення визначає, яку з альтернатив повертати. Стандартне вираз CASE має наступну форму:

CASE selector
WHEN expression1 THEN result1
WHEN expression2 THEN result2

WHEN expressionN THEN resultN
[ELSE resultN+1]
END;

З запиту можна бачити, що таблиця Customer260_TAB
містить один віртуальний (virtual) стовпець з ім’ям SYS_NC_ROWINFO $, кілька прихованих (hidden) стовпців, включаючи XMLDATA, ACLOID, OWNERID, XMLEXTRA, і набір стовпців
$SYS_NC<number>$.

Віртуальний стовпець SYS_NC_ROWINFO $ – це об’єкт XMLType, який ідентифікує рядка XMLType таблиці. Наприклад, в тригерах XMLType таблиць можна використовувати :new.SYS_NC_ROWINFO$ для звернення до поточної рядку даних.

Стовпець XMLDATA посилається на об’єкти SQL, використовувані для збереження XMLType. Це корисно, коли треба запросити або створити індекси в XMLType, повністю працюючи тільки з об’єктами SQL. В попередньому прикладі XMLDATA – це псевдонім для об’єкта
CustomerType259_T. Отже, можна додати унікальне обмеження цілісності (a unique constraint) на елемент EMAIL, посилаючись на нього, як XMLDATA.EMAIL, що показано далі:

ALTER TABLE Customer260_TAB ADD UNIQUE(XMLDATA.EMAIL);

XMLDATA.EMAIL посилається на об’єкту, зберігаючи контент елементів EMAIL в записах про клієнтів. При наявності обмеження UNIQUE при спробі ще раз додати таку ж запис про клієнта, ви зіткнетеся з наступною помилкою:

ORA-00001: unique constraint (DEMO.SYS_C003626) violated

Деякі з прихованих стовпців Customer260_TAB використовуються репозиторием Oracle XML DB. Наприклад, в Oracle XML DB репозиторії Access Control List (ACL) визначає дозволу для кожного ресурсу. ACLOID специфікує дозволу ACL для XMLType таблиці, а OWNERID специфікує ідентифікатор власника таблиці. Інші приховані стовпці використовуються для побудови ієрархічних відносин між XML елементами.

Виняток становлять XMLDATA і SYS_NC_ROWINFO $. Цими XMLType стовпцями не можна маніпулювати або отримати прямий доступ.

Анотації XML схеми

Для управління відповідність між зберіганням XMLType і схемами XML потрібно використовувати анотації Oracle XML DB. В Oracle Database
10g ці XML Schema анотації представляють собою набір атрибутів, доданих в XML схему, що декларують імена об’єктів SQL, типи даних і різноманітні опції зберігання. Всі ці анотації знаходяться в просторі імен Oracle XML DB,
http://xmlns.oracle.com/xdb, Зазвичай використовують префікс
xdb). Ці анотації, головним чином, можна використовувати, щоб визначити наступне:


Давайте розглянемо наступну анотовану XML схему для записів про клієнтів customer_simple_ann.xsd, випробуємо якусь корисну техніку розробки, а потім зареєструємо її в XML DB.

<xsd:schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xdb=”http://xmlns.oracle.com/xdb” xdb:storeVarrayAsTable=”true“>
<xsd:element name=”Customer” type=”CustomerType”
xdb:defaultTable=”CUSTOMER“/>
<xsd:complexType name=”CustomerType” xdb:maintainDOM=”false“>
<xsd:sequence>
<xsd:element name=”NAME” type=”xsd:string”
xdb:SQLName=”NAME” xdb:SQLType=”VARCHAR2″/>
<xsd:element name=”EMAIL” type=”xsd:string”
xdb:SQLName=”EMAIL” xdb:SQLType=”VARCHAR2″/>
<xsd:element name=”ADDRESS” type=”xsd:string” maxOccurs=”unbounded”
xdb:SQLName=”ADDRESS” xdb:SQLCollType=”ADDRESS_TYPE”
xdb:SQLType=”VARCHAR2″ xbd:maintainOrder=”false“/>
<xsd:element name=”PHONE” type=”phoneType”
xdb:SQLName=”PHONE”/>
<xsd:element name=”DESCRIPTION” type=”contentType”/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=”contentType” mixed=”true”
xdb:SQLType=”CLOB” xdb:maintainDOM=”true“>
<xsd:sequence>
<xsd:any minOccurs=”0″ maxOccurs=”unbounded”
processContents=”skip”/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name=”phoneType”>
<xsd:restriction base=”xsd:string”>
<xsd:pattern value=”\(\d{3}\)\d{3}-\d{4}”/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

Дивлячись на цей приклад, перша річ, яку треба зробити при анотуванні XML схеми полягає в тому, щоб включити оголошення простору імен Oracle XML DB
xmlns:xdb=”http://xmlns.oracle.com/xdb” в елемент
<schema>. Префікс цього простору імен потім використовується, щоб кваліфікувати всі анотації Oracle XML DB.

Далі, xdb:storeVarrayAsTable=”true”, – Це глобальна XML DB анотація, яка говорить XML DB зберегти всі елементи VARRAY у вкладених (nested) об’єктних таблицях. Ця анотація сприяє прискоренню запитів до XML елементам, які визначені за допомогою
maxOccurs>1. Наприклад, в customer_simple_ann.xsd ця анотація впливає на збереження елементів <ADDRESS>.

Далі, ви можете визначити анотацію XML DB
xdb:mapUnboundedStringToLob=”true” в елементі
<schema>, щоб встановити відповідність х рядків в CLOB і безрозмірних двійкових даних в BLOB при табличному зберіганні “поза рядка “(out-of-online). За умовчанням встановлено значення
false. Таким чином, всі безрозмірні рядка визначені в XML схемі і отображаемость в VARCHAR2 (4000), а безрозмірні двійкові дані відображені в RAW (2000) при табличному зберіганні “в рядку” (Inline). Але, як тільки inline-таблиці перестали бути ефективним засобом для зберігання великих XML документів, потрібно встановлювати
xdb:mapUnboundedStringToLob=”true”.

Для всіх глобальних складних і для найпростіших типів можна визначити наступні анотації XML DB, які специфікують відповідні SQL імена і типи даних:


ЗАУВАЖЕННЯ

xdb: SQLName не дозволяється в описах complexType і simpleType. Інакше, ви отримаєте наступну помилку:

ORA-30937: No schema definition for ‘SQLName’
(ORA_30937. Немає опису схеми для ‘SQLName’)

(Простір імен ‘http://xmlns.oracle.com/xdb’) в батьківському
‘complexType’.

В кореневому елементі XML документа потрібно специфікувати атрибут
xdb:defaultTable і опціонально використовувати
xdb:tableProps для установки атрибутів таблиці:


Для всіх XML елементів повинно специфікувати ім’я та тип елемента, якщо їх базовий тип не міститься серед глобальних типів, описаних в XML схемі, яка була анотована. Наступний список XML DB анотацій для XML елементів:


На відміну від запам’ятовування всіх можливих анотацій, ми робимо список найбільш використовуваних XML DB анотацій. В результаті, коли анотується XML схеми, треба мати на увазі наступне.

По-перше, необхідно специфікувати ім’я default таблиці, використовуючи xdb:defaultTable і SQL ім’я для кожного XML елемента і типу даних в XML схемі, для чого використовуються xdb:SQLName,
xdb:CollType або xdb:SQLType. Слід зауважити, що в прикладі:


Визначення SQL імен, використовуючи анотації XML схеми, корисно, тому як згенеровані системою імена запам’ятати не просто. Звичайно ж, має враховувати визначення всіх SQL імен, надрукованих прописними буквами для виключення імен з урахуванням регістра в базі даних, які вимагають використання подвійних лапок при зверненні до об’єктів SQL. Наприклад, без перетворення букв в прописні треба писати “Customer260_TAB”, а не CUSTOMER260_TAB при зверненні до default таблиці, що зберігає записи про клієнтів.

ЗАУВАЖЕННЯ

Для XML документів і типів, якщо не використовуються
xdb:SQLName, xdb:CollType або xdb:SQLType, Oracle XML DB буде використовувати ім’я елемента або типу даних для створення SQL імені. Так як XML регістру залежимо, то і SQL ім’я буде регістро-залежним, вимагаючи всюди використання лапок для посилання на них. Ця анотація також корисна, якщо ім’я XML типу або елемента довге або є конфлікт імен в XML схемі.

Далі слід визначити зберігання, мінімізуючи будь додаткове збереження даних, уникаючи, наприклад, зберігання DOM точності. Це ж треба мати на увазі при організації зберігання піддерев і складних типів, як CLOB’и, коли немає потреби в XPath запитах по контенту, встановлюючи xdb:SQLTypes=”CLOB”.
Oracle XML DB не буде ділити ці XML дані, зберігаючи, таким чином, час і ресурси.

Нарешті, коли обробляються малі, але безрозмірні XML елементи, потрібно зберігати контент, як VARRAY, використовуючи установку
xdb:storeVarrayAsTable=”false”. Для великих безрозмірних елементів можна використовувати вкладені таблиці, в елементі
<schema> спеціфіціруя xdb:storeVarrayAsTable=”true”,
або використовувати вкладені таблиці, встановивши для кращого виконання на елемент xdb:maintainOrder=”false”.

Завантаження XML даних

Після того, як визначено зберігання XMLType, можна завантажувати дані в XMLType таблиці, використовуючи SQL, а саме протокол API або утиліту SQL * Loader.

Використання SQL команд

Найпростіший спосіб для завантаження XML даних в XMLType таблиці – використання команди INSERT SQL, як це показано на наступному прикладі:

INSERT INTO customer VALUES(XMLType(‘<Customer>
<NAME>Steve Joes</NAME>
<EMAIL>Steve.Joes@example.com</EMAIL>
<ADDRESS>Someroad, Somecity, Redwood Shores, CA 94065, U.S.A</ADDRESS>
<PHONE>6505723456</PHONE>
<DESCRIPTION>Very Important US Customer</DESCRIPTION>
</Customer>’).CreateSchemaBasedXML(
‘http://localhost:8080/public/contact_simple_ann.xsd’));

Використовуючи цей підхід, можна сконструювати XMLType примірник з XML в VARCHAR2, CLOB або BFILE і опціонально використовувати функцію
XMLType.CreateSchemaBasedXML() для звернення до зареєстрованої схемою.

Не застосовуючи функцію XMLType.CreateSchemaBasedXML(), можна вставити XML в XMLTypes, базованих на XML Schema, âêëþ ÷ àÿ XML Schema посилання на кореневий елемент XML документа, використовуючи атрибути розміщення XML схеми, серед яких є
xsi:schemaLocation і xsi:noNamespaceSchemaLocation:

INSERT INTO customer

values(XMLType(‘<Customer xmlns:xsi=”http://www.w3.org/2001/XMLSchema
-instance” xsi:noNamespaceSchemaLocation=”http://localhost:8080/public/
contact_simple_ann.xsd”>
<NAME>Steve Joes</NAME>
<EMAIL>Steve.Joes@example.com</EMAIL>
<ADDRESS>Someroad, Somecity, Redwood Shores, CA 94065, U.S.A</ADDRESS>
<PHONE>6505723456</PHONE>
<DESCRIPTION>Very Important US Customer</DESCRIPTION>
</Customer>’));

Атрибут xmlns:xsi=”http://www.w3.org/20041/XMLSchema-instance”
оголошує простір імен для примірника XML Schema. Атрибут
xsi:noNamespaceSchemaLocation=
”http://localhost:8080/public/contact_simple_ann.xsd”
специфікує URL зареєстрованої XML схеми. У цьому прикладі, якщо XML документи не володіє простором імен, використовується
xsi:noNamespaceSchemaLocation. Якщо XML документ містить простір імен, наприклад, XML схема для XML документа визначає цільове простір імен як
targetNamespace=”http://www.example.com/customer”, тоді необхідно використовувати атрибут xsi:schemaLocation, Як
показано нижче:

xsi:schemaLocation= “http://www.example.com/customer
http://localhost:8080/
public/contact_simple_ann.xsd”

Атрибут містить targetNamespace, http://example.com/customer
і URL XML схеми
http://localhost:8080/public/contact_simple_ann.xsd.

Використання інтерфейсів репозиторію Oracle XML DB

Репозиторій XML DB підтримує протоколи взаємодії, включаючи FTP і WebDAV / HTTP, використовуваних для вставки XML і інших типів документів. Як уже говорилося в Розділі 8, ви можете створити папку WebDAV і використовувати її для копіювання або редагування XML файлів в репозиторії XML DB, як якщо б це була ще одна директорія на вашому диску. Коли використовуються протоколи взаємодії, XML документ повинен мати атрибути розташування XML схеми для гарантії того, що дані вставиться в default таблиці, створені при реєстрації XML схеми. У наступному прикладі використовується FTP інтерфейс для вставки записів про клієнтів в default таблицю customer після реєстрації
contact_simple_ann.xsd в XML DB:

D:\>ftp

ftp> open localhost 2100
Connected to [Machine_Name] 220 [Machine_Name].FTP Server (Oracle XML
DB/Oracle Database 10g Enterprise Edition Release X.X.X.X.X) ready.
User ([Machine_Name]:(none)): demo
331 pass required for DEMO
Password:
230 DEMO logged in
ftp> cd public
250 CWD Command successful
ftp> put customer1.xml
200 PORT Command successful
150 ASCII Data Connection
226 ASCII Transfer Complete
ftp: 444 bytes sent in 0.00Seconds 444000.00Kbytes/sec.
ftp> ls customer1.xml
200 PORT Command successful
150 ASCII Data Connection
customer1.xml
226 ASCII Transfer Complete
ftp: 15 bytes received in 0.00Seconds 15000.00Kbytes/sec.
ftp>bye

Після цих операцій новий запис про клієнта вставляється як в репозиторій XML DB в директорію / Public, так і в default таблицю customer. На додаток до двох записів, вставленим з допомогою SQL, тепер існує третя запис в таблиці
customer:

SQL> SELECT count(1) FROM customer;
COUNT(1)
———-
3

Ми обговоримо можливості репозиторію XML DB в секції “Репозиторій Oracle XML DB “. А зараз поки потрібно знати тільки, що не важливо, яка директорія в репозиторії XML DB використовується для зберігання XML документа, нова запис про клієнта буде завжди вставлятися в default XMLType таблицю на такий термін, який буде потрібно для відправки по відповідному URL зареєстрованої XML схеми.

Використання SQL * Loader

SQL * Loader був широко поширеним інструментом для завантаження даних у базу даних Oracle. В Oracle Database 10g SQL*Loader допомагає завантажувати XML дані в XMLType стовпці або XMLType таблиці, незалежно від лежить в основі пам’яті зберігання. Іншими словами, можна використовувати один і той же метод для завантаження XML даних в CLOB або в об’єктно-реляційний XMLType. Крім того, SQL * Loader дозволяє завантаження XML даних, використовуючи обидва методи: традиційний і прямого завантаження. Традиційний шлях – це метод за замовчуванням, який використовує SQL для завантаження даних в базу даних Oracle. Прямий шлях обходить SQL і занурює дані безпосередньо у файли бази даних
Oracle.

Для завантаження XML даних, використовуючи SQL * Loader, необхідно застосовувати керуючий файл, що описує вхідні дані і цільову таблицю і стовпці таблиці. Наприклад, для вставки двох записів про клієнтів: customer3.xml і customer4.xml, в таблицю customer, слід створити керуючий файл, як показано далі:

LOAD DATA
INFILE *
INTO TABLE customer
APPEND
XMLType(XMLDATA)(
lobfn FILLER CHAR TERMINATED BY ‘,’,
XMLDATA LOBFILE(lobfn) TERMINATED BY EOF
)
BEGINDATA
xml/customer3.xml,
xml/customer4.xml

Керуючий файл повідомляє SQL * Loader, що завантажуються дані (LOAD DATA) містяться в керуючому файлі (INFILE *) додаються в кінець (APPEND) таблиці customer (INTO TABLE customer). XMLType (XMLDATA) посилається на нові дані як XMLType. До тих пір поки ця операція є дописує (appending), SQL * Loader буде завантажувати нові дані без перезапису старих записів про клієнтах. Якщо ж замість цього використовувати REPLACE, то старі записи будуть видалені перед вставкою нових даних.

Оператор lobfn – Це поле FILLER. В SQL * Loader поля FILLER використовуються для збирання даних із входів рядків. Іншими словами, поля FILLER не відносяться ні до одного стовпцю таблиці; натомість вони використовуються для пропуску або вибору даних з вхідного потоку. У даному прикладі lobfn використовується для отримання імен XML документів після BEGIN DATA, імена розмежовуються комами (TERMINATED BY ‘,’). Актуальні XML дані в файлах поділяються символом “кінець файла” [end-of-file] (EOF).

Після того як керуючий файл буде створений, слід доповнити [Змінну] середовища PATH директорією $ORACLE_HOME\bin, а потім запустити виконати команду, щоб запустити sqlldr – Утиліту командного рядка SQL * Loader:

D:\>sqlldr userid=demo/demo control=customerLoad.ctl
SQL*Loader: Release X on Thu Jun 26 22:26:53 2003
(c) Copyright 2001 Oracle Corporation. All rights reserved.
Commit point reached – logical record count 2

Userid визначає ім’я та пароль для користувача бази даних, якому належить таблиця customer. Опція
control визначає ім’я керуючого файлу. Результат показує, що дві логічних записи були розпізнані SQL * Loader. Подальша інформація про [виконанні] sqlldr може бути знайдена у файлі <control_file_name>.log. Можна визначити direct=y, якщо потрібно використовувати прямий спосіб завантаження XML даних. У порівнянні з традиційним, прямий спосіб швидше, так як він обходить SQL рівень і просуває XML дані у файли бази даних Oracle без запуску додаткових процедур або примусової перевірки.

Перевірка достовірності XML схеми

В процесі завантаження XML або після оновлення контенту в XMLTypes, базуються на XML Schema, Oracle XML DB просто перевіряє, правильно розширюється XML документ з перевірками об’єктів, замість виконання перевірки достовірності всієї XML Schema. Іншими словами, Oracle XML DB виконує тільки обмежені перевірки для того, щоб упевнитися, що XML документ узгоджується з об’єктно-реляційних зберіганням. Наприклад, XML DB перевірить, существалі чи елемент
<PHONE> до вставки записів про клієнтів. Це не зупинить вставку даних, якщо номери телефонів порушують шаблон рядки, визначений у XML схемі.

Для очищення від неправильних даних, які можуть бути вставлені в XMLTypes, необхідно явно запитувати перевірку достовірності XML Schema. Найпростіший спосіб це зробити – до виконання операцій INSERT створити TRIGGER, як показано нижче:

CREATE OR REPLACE TRIGGER customer_insert
AFTER INSERT ON customer
FOR EACH ROW
DECLARE
doc XMLType;
BEGIN
doc := :new.SYS_NC_ROWINFO$;
XMLType.schemaValidate(doc);
END;

Якщо тільки тригер задіяний, проводиться повна перевірка достовірності всякий раз, коли вставляються дані в таблицю
customer:

INSERT INTO customer VALUES(
XMLType(‘<CUSTOMER xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:noNamespaceSchemaLocation=”http://localhost:8080/public/
contact_simple_ann.xsd”>
<NAME>Steve Joes</NAME>
<EMAIL>Steve.Joes@example.com</EMAIL>
<ADDRESS>Someroad, Somecity, Redwood Shores, CA 94065, U.S.A</ADDRESS>
<PHONE>6505723456</PHONE>
<DESCRIPTION>Very Important US Customer</DESCRIPTION>
</CUSTOMER>’));

Таким чином, цей приклад поверне наступні помилки:

INSERT INTO customer
*
ERROR at line 1:
ORA-31154: invalid XML document
ORA-19202: Error occurred in XML processing
LSX-00333: literal “6505723456” is not valid with respect to the pattern
ORA-06512: at “SYS.XMLTYPE”, line 333
ORA-06512: at “DEMO.CUSTOMER_INSERT”, line 5
ORA-04088: error during execution of trigger ‘DEMO.CUSTOMER_INSERT’

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

SQL> INSERT INTO customer VALUES(
XMLType(‘<Customer xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:noNamespaceSchemaLocation=”http://localhost:8080/public/
contact_simple_ann.xsd”>
<NAME>Steve Joes</NAME>
<EMAIL>Steve.Joes@example.com</EMAIL>
<ADDRESS>Someroad, Somecity, Redwood Shores, CA 94065, U.S.A
</ADDRESS>
<PHONE>(650)572-3456</PHONE>
<DESCRIPTION>Very Important US Customer</DESCRIPTION>
</CUSTOMER>’));

Додано нову правильний запис про клієнта. Слід перевірити статус перевірки достовірності XML Schema äëÿ об’єкта XMLType, використовуючи функцію XMLType.isSchemaValid() або функцію
XMLType.isSchemaValidated():

SQL> SELECT x.isSchemaValid() FROM customer x;
X.ISSCHEMAVALID()
—————–
1
0
…0

Попередній результат показує, що є тільки один запис в таблиці і вона правильна по XML схемі. Записи, вставлені до цього, не мали статусу valid (правильна). Це так тому, що функція
XMLType.schemaValidate() перевіряє на достовірність об’єкт XMLType і оновлює статус достовірності об’єктів XMLType в XML DB.

ЗАУВАЖЕННЯ

Включивши повну перевірку достовірності отримаємо значний негативний ефект при виконанні INSERT, таким чином, це слід використовувати тільки в разі потреби. Звичайно краще проводити перевірку достовірності під час створення документа або на середньому рівні (middle tier).

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


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

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

Ваш отзыв

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

*

*