ЗАСТОСУВАННЯ МОВИ XML в базах даних

Тепер (нарешті) ми можемо приступити до вивчення питання про те, яке значення мають описані вище особливості мови XML, зокрема, для організації роботи баз даних Безумовно, що є потреба зберігати документи XML (можливо, точніше слід сказати, дані XML) в базах даних, а також мати можливість витягувати і оновлювати ці дані на вимогу Насправді, існує також прямо протилежна потреба, а саме отримувати звичайні дані або дані, відмінні від XML (зокрема, результати деякого запиту) і перетворювати їх у форму XML, так, щоб їх можна було (наприклад) передавати у вигляді документа XML деякого споживачеві Почнемо з докладного вивчення першого з цих вимог

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

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

1 Документ може бути розділений (Це-технічний термін), І різні його фраг менти представлені у вигляді значень різних атрибутів різних кортежів різних відносин

2 Документ може бути збережений не в звичайній базі даних, а скоріше власне в базі даних XML (Тобто в такій базі даних, яка замість відносин містить документи XML як такі)

Розглянемо кожен з цих варіантів по черзі

Зберігання документів у вигляді значень атрибута

Такий підхід коротко згадувався в підрозділі Розробка мови XML розділу 273, де була вказана можливість доповнення змінної відносини деталей Р для включення атрибутів DRAWING і DESCRIPTION По суті, таку ідею можна реалізувати, як описано нижче

■ Перш за все, необхідно визначити новий тип даних, скажімо, XMLDOC, значе нями якого є документи XML після цього можна визначити, що кон Конкретні атрибути конкретної змінної відносини належать до цього типу

20 Мабуть, винятком слід вважати flower power (Всемогутнє вираз FLWOR)

(Автор приносить свої вибачення, оскільки він не міг втриматися від спокуси навести цей каламбур)

Примітка Як було показано вище, мова XML як такий є досить багатослівним будь-який документ XML цілком може в пять або десять разів перевищувати за обсягом представлені в ньому ^ відформатовані дані, тому обробка таких документів у вихідній формі іноді стає надзвичайно неефективною Таким чином, може виявитися доцільною організація зберігання подібних документів в деякій стислій формі (Можливо, у вигляді даних, підданих синтаксичному аналізу) Але, безумовно, такі сообра вання не мають ніякого відношення до розглянутої моделі

■ Кортежі, містять значення XMLDOC, можна вставляти і видаляти з вико ристанням звичайних реляційних операторів INSERT І DELETE, а значення XMLDOC, що містяться в таких кортежах, повністю замінювати із застосуванням звичайної реляційного оператора UPDATE Крім того, безумовно, значення XMLDOC можуть

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

■ Як і всі типи, тип XMLDOC повинен мати безліч повязаних з ним операто рів Розглянуті оператори приблизно повинні надавати можливість вибірки та оновлення атрибутів зі значеннями у вигляді XMLDOC на більш низькому рівні деталізації, забезпечуючи (наприклад) доступ до окремих елементів або атрибутів XML У разі вибірки такі оператори, мабуть, повинні бути дуже схожими на оператори, застосовувані в мові XQuery вони можуть навіть викликатися за допомогою замаскованих викликів виразів XQuery, хоча вбудована (безпосередня) підтримка має бути більш дружньою

по відношенню до користувача Але повинні також підтримуватися оператори оновлення

■ Необхідно також передбачити оператори для перевірки того, що дане кон кретного значення XMLDOC відповідає деякому заданому визначенню DTD або деякої заданою схемою XML (тобто є допустимим) (Безумовно, зна чення XMLDOC повинні бути формально правильними за визначенням, але вони все ще можуть виявитися неприпустимими)

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

■ Документи вже існують

■ Операції звичайно виконуються з усім документом у цілому, а не з окремими його фрагментами

■ Документи рідко оновлюються

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

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

По суті, цей підхід є прийнятним для додатків, які іноді називають додатками, орієнтованими на роботу з документами [277] Такими є додатки, в яких в Зрештою аналізовані документи в основному призначені для використання людьми і складаються головним чином з тексту на природній мові

Принцип розділяй і публікуй

У другому підході будь-які нові типи даних не використовуються Замість цього документи XML поділяються на фрагменти (наприклад, на окремі елементи і атрибути XML), після чого ці фрагменти зберігаються у вигляді значень різних реляційних атрибутів в різних частинах бази данних21 Тому слід зазначити, що в цьому випадку база даних не містить документи XML як такі Це означає, що СУБД не має інформації про існування таких документів, а той факт, що деякі значення в базі даних можуть бути скомбінована певним чином для створення якогось документа XML, відомий розробнику деякої прикладної програми (можливо, Web-сервера), але не відображено у СУБД

Але слід зазначити, що при цьому в прикладній програмі передбачена можливість створити документ XML зі звичайних даних бази, тому фактично досягається друга з спочатку заданих цілей А саме, надається можливість отримати результат запиту до звичайних даними (відмінним від XML) і перетворити їх у форму XML Таке перетворення називається публікацією (Розглянутих даних) таким чином, термін публікація, в тому сенсі, в якому він застосовується в даному контексті, є протилежним терміну поділ, також визначеному в цьому розділі До речі, слід зазначити, що правила перетворення, якими керуються у своїх діях програми при виконанні таких операцій розділення та публікації, самі зазвичай зберігаються у формі документів XML

Між іншим, здатність публікувати відмінні від XML дані у формі XML

може також розглядатися як здатність підтримувати подання XML даних, відмінні від XML (Точніше, така публікація може розглядатися як підтримка уявлень XML, призначених для вибірки Якщо ж має бути дозволено оновлення таких уявлень, то для цього буде потрібно підтримка з боку відповідної функції поділу) Зрештою, немає будь-яких причин, за якими (Використовуючи термінологію глави 2) зовнішній і концептуальний рівні системи повинні були бути обовязково засновані на одній тій же моделі даних фактично в

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

Проте, при використанні зазначеного підходу виникають певні проблеми, викликані тими причинами, які можна вважати різновидом невідповідності типів даних (див главу 25) між реляційної моделлю і так званої моделлю XML, яка, як вже було показано в даній главі, фактично являє собою стару ієрархічну модель, але в дещо іншому вигляді При цьому одна з проблем полягає в тому, що дочірні вузли будь-якого конкретного батьківського вузла в ієрархічній моделі XML утворюють не безліч, а послідовність (тобто вони впорядковані), тоді як

21 Виродженим окремим випадком цього підходу є зберігання всього документа у вигляді символьного рядка в позиції одного атрибута окремого кортежу Крім того, необхідно враховувати, що даний і попередній підходи не слід вважати взаємовиключними – може виявитися прийнятним будь-який з них, залежно від того, які дії надалі буде потрібно виконувати з даними Можуть навіть використовуватися одночасно обидва підходи – можливо, навіть стосовно до одного і того ж документу

кортежі у відношенні не впорядковані Тому, якщо задано певний документ D на мові XML, то можлива ситуація, що деякі властивості документа D (інформаційні або інші) будуть втрачені після поділу та збереження D в реляційній базі даних А якщо це відбувається, то не можна дати гарантії, що при публікації даних у формі XML буде виконана реконструкція документа D в його точної первісної форми Зокрема, цілком імовірно, що не буде однаковою розстановка пробільних символів в оригінальній і (повторно) опублікованої версії D

Примітка Підхід за принципом розділяй і публікуй іноді неформально називають як застосування колекції XML. Нижче перераховані деякі фактори, під впливом яких такий підхід може виявитися найбільш прийнятним

У реляційній базі даних вже є необхідні дані і потрібно забезпечити їх взаємодію з відповідними даними в документах XML

■ У незмінному вигляді вимагається зберігати тільки ті частини документів, які содер жать символьні дані (тому дескриптори можуть бути поставлені у відповідність іменам реляційних атрибутів)

■ Операції часто виконуються з окремими елементами або атрибутами

■ Операція поновлення застосовуються часто і важливо забезпечити високу вироб дітельность оновлення

■ В обробних програмах використовуються існуючі реляційні ін терфейса

Взагалі кажучи, підхід за принципом розділяй і публікуй є найбільш підходящим для таких додатків, які іноді називають додатками, орієнтованими на обробку даних [277] Такими є додатки, в яких документи містять (як правило) оперативну інформацію, або інформацію, призначену для підтримки прийняття рішень, а не текст на природній мові

Бази даних XML

Основна причина, по якій в даній главі згадується цей третій підхід, складається просто в прагненні всебічно розглянути дану тему Зрештою, як показано в розділі 3, реляційна модель є необхідною і достатньою для представлення взагалі будь-яких даних Неможливо також оскаржувати те, що зроблені величезні вкладення в дослідження і розробку, а також у створення комерційних продуктів в тій області, яку можна в цілому назвати реляційної інфраструктурою (Тобто зроблені величезні зусилля щодо забезпечення підтримки відновлення, організації паралельної роботи, захисту та оптимізації, не кажучи вже про підтримку цілісності, а також по всіх інших напрямках, які розглядалися в цій книзі) Тому, на думку автора, було б нерозумно повністю переключатися на розробку принципово нової технології баз даних, притому що не можна знайти будь-яких достатньо переконливих причин для прийняття подібного рішення, не кажучи вже про те, що будь-яка така технологія буде, безумовно, страждати від недоліків, аналогічних тим, які вже виявляються в технології ієрархічних баз даних (див, наприклад, розділ 13 роботи [15] або анотації до [273] і [276])

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*