XML і базы дадзеных

Original on http://www.rpbourret.com/xml/XMLAndDatabases.htm

Гэты артыкул таксама даступная на:

Змест

1.0 Уводзіны

У артыкуле даецца агульны агляд таго, як выкарыстоўваць XML з базамі дадзеных. Ён апісвае, як адрозненні паміж арыентаваных на дадзеныя і дакумент-арыентаваных дакументаў ўплываюць на іх выкарыстанне з базамі дадзеных, як XML, звычайна выкарыстоўваецца з рэляцыйнымі базамі дадзеных, і тое, што родны XML базы дадзеных, і калі іх выкарыстоўваць.

ЗАЎВАГА: Хоць інфармацыя абмяркоўваецца ў гэтым артыкуле (у асноўным) да сучасных, ідэя, што свет XML і базы дадзеных можна ўбачыць праз data-centric/document-centric падзяліць некалькі састарэлі. У той час гэты дакумент быў першапачаткова напісаны (1999), гэта было зручна метафара для ўвядзення роднай базы дадзеных XML, якія затым былі шырока не разумеў, нават у супольнасці баз дадзеных. Тым не менш, гэта заўсёды было нерэальна, так як многія XML-дакументы не з’яўляюцца строга арыентаванай на дадзеныя або дакумент, які арыентаваны, але дзе-то пасярэдзіне. Такім чынам, хоць data-centric/document-centric разрыў зручнай адпраўной кропкай, лепш зразумець адрозненні паміж XML з падтрымкай баз дадзеных і XML роднай базы дадзеных і выбраць адпаведную базу даных у залежнасці ад патрэбаў апрацоўкі. Для больш сучасны погляд на адрозненне паміж XML з падтрымкай XML і айчынных баз дадзеных гл. у главе 1 XML для інтэграцыі інфармацыйных DB2.

2.0 з’яўляецца XML-база дадзеных?

Перш чым мы пачнем гаварыць пра XML і баз дадзеных, мы павінны адказаць на пытанне, што адбываецца, для многіх людзей: “Ці з’яўляецца XML-дадзеных?”

Дакумент XML ўяўляе сабой базу дадзеных толькі ў строгім сэнсе гэтага тэрміна. То бок, гэта збор дадзеных. Шмат у чым, гэта робіць яго не адрозніваецца ад любой іншай файл – у рэшце рэшт, усе файлы, якія змяшчаюць звесткі пра нейкі. У якасці “базы даных” фармаце, XML мае шэраг пераваг. Напрыклад, само сабой, якія характарызуюць (разметка апісвае структуру і імёны тыпаў дадзеных, хоць і не семантыка), гэта партатыўны (Unicode), і яго можна апісваць дадзеныя ў выглядзе дрэва або граф структуры. Ён таксама мае некаторыя недахопы. Напрыклад, ён шматслоўны і доступ да дадзеных, павольна з-за пераўтварэнні разбору і тэксту.

Больш карысным задаць пытанне, ці з’яўляецца XML і навакольных яго тэхналогій складаюць «базу даных» ў больш свабоднай сэнсе гэтага слова – гэта значыць, сістэма кіравання базамі дадзеных (СКБД). Адказ на гэтае пытанне, “Выгляд”. З станоўчага боку, XML прадастаўляе многія з рэчаў, знойдзеных у базах дадзеных: захоўванне (XML-дакументаў), схемы (DTD, XML-схемы, RELAX NG і г.д.), мовы запытаў (XQuery, XPath, XQL XML-QL, QUILT і г.д.), праграмныя інтэрфейсы (SAX, DOM, JDOM), і гэтак далей. На мінус бок, ёй не хапае многіх рэчаў, знойдзеных у рэальных базах дадзеных: эфектыўнае захоўванне, індэксы, бяспека, транзакцыі і цэласнасць дадзеных, шматкарыстальніцкі доступ, трыгеры, запыты ў некалькіх дакументах, і так далей.

Такім чынам, хоць гэта можа быць магчымым выкарыстоўваць XML-дакумент або дакументы, базы дадзеных у асяроддзях з невялікімі аб’ёмамі дадзеных, некалькі карыстачоў, і сціплыя патрабаванні да прадукцыйнасці, гэта не атрымаецца, у большасці вытворчых асяроддзях, якія маюць шмат карыстальнікаў, жорсткія патрабаванні цэласнасці дадзеных , а таксама неабходнасць за добрую працу.

Добры прыклад тыпу “база дадзеных”, для якіх дакумент XML з’яўляецца прыдатным з’яўляецца INI-файлаў -. Гэта значыць, файл, які змяшчае інфармацыю канфігурацыі прыкладання. Значна прасцей прыдумаць невялікі XML-мова і пісаць SAX прыкладанне для інтэрпрэтацыі, што мова, чым пісаць парсер для падзеленых коскамі файлаў. Акрамя таго, XML дазваляе вам мець укладзеныя запісы, тое, што цяжэй зрабіць у падзеленых коскамі файлаў. Тым не менш, гэта наўрад ці база дадзеных, так як чытаць і запісваць лінейна, а затым толькі тады, калі праграма запускаецца і скончылася.

Прыклады больш складаных набораў дадзеных, для якіх дакумент XML можа быць прыдатны ў якасці базы дадзеных асабістых спісаў кантактаў (імёны, тэлефонныя нумары, адрасы і т.п.), закладак браўзэра і апісання МР3 Вы скралі з дапамогай Napster. Аднак, улічваючы нізкую цану і прастату выкарыстання баз дадзеных, як DBASE і доступу, узнікае мала прычын для выкарыстання XML-дакумент як базу дадзеных, нават у гэтых выпадках. Адзінае рэальнае перавага XML у тым, што дадзеныя партатыўнымі, і гэта менш пераваг, чым здаецца з-за шырокай даступнасці прылад для пераўтварэння баз дадзеных XML.

3,0 Навошта выкарыстоўваць базы дадзеных?

Першае пытанне, вы павінны спытаць сябе, калі вы пачынаеце думаць аб XML і базы дадзеных, таму вы хочаце выкарыстоўваць базу дадзеных у першую чаргу. Ці ёсць у вас старыя дадзеныя трэба падаць? Вы шукаеце месца для захоўвання вэб-старонак? База дадзеных, якія выкарыстоўваюцца прыкладанняў электроннай камерцыі, у якіх XML выкарыстоўваецца ў якасці перадачы дадзеных? Адказы на гэтыя пытанні будуць моцна ўплываць на Ваш выбар базы дадзеных і прамежкавага ПА (калі ёсць), а таксама, як вы выкарыстоўваеце гэтую базу дадзеных.

Напрыклад, выкажам здагадку, у вас ёсць электронная камерцыя прыкладанне, якое выкарыстоўвае XML у якасці перадачы дадзеных. Гэта добрая стаўка, што вашы дадзеныя вельмі правільнай структурай і выкарыстоўваецца не-XML-прыкладанняў. Акрамя таго, такія рэчы, як асобы і кадоўкі выкарыстоўваецца XML-дакументаў, верагодна, не важна для вас – бо вы зацікаўлены ў дадзеных, не так, як яно захоўваецца ў дакуменце XML. У гэтым выпадку, вы, верагодна, спатрэбіцца рэляцыйная база дадзеных і праграмнае забеспячэнне для перадачы дадзеных паміж XML-дакументы і базы дадзеных. Калі вашы прыкладанні аб’ектна-арыентаванай, вы маглі б нават хацець сістэмы, якая можа захоўваць гэтыя аб’екты ў базе дадзеных або сериализовать іх як XML.

З іншага боку, выкажам здагадку, у вас ёсць вэб-сайт пабудаваны з ліку прозы арыентаваныя XML-дакументаў. Мала таго, што вы хочаце кіраваць сайтам, вы хацелі б падаць карыстачам магчымасць пошуку яго змест. Вашы дакументы, хутчэй за ўсё, менш рэгулярнай структурай і такія рэчы, як арганізацыя выкарыстання, верагодна, важная для вас, таму што яны з’яўляюцца фундаментальнай часткай таго, як Вашы дакументы будуць структураваныя. У гэтым выпадку, вам можа спатрэбіцца такі прадукт, як родную базу дадзеных XML або сістэма кіравання кантэнтам. Гэта дазволіць вам захаваць фізічную структуру дакумента, падтрымка на ўзроўні дакумента транзакцый і выканання запытаў у мову запытаў XML.

4,0 у параўнанні з дадзенымі дакументаў

Мабыць, найбольш важным фактарам пры выбары базы дадзеных, выкарыстоўваеце вы базу дадзеных для захоўвання дадзеных або дакументаў. Напрыклад, у XML выкарыстоўваць проста як перадачу дадзеных паміж базай дадзеных і (магчыма не-XML) прыкладанні? Або яго выкарыстанне інтэграл, як у выпадку з XHTML і DocBook дакументаў? Як правіла, гэта пытанне аб намерах, але гэта важна, таму што ўсе дадзеныя, арыентаваныя дакументы маюць шэраг агульных характарыстык, як і ўсе дакумент-арыентаваных дакументаў, і гэтыя ўплыву як XML захоўваецца ў базе дадзеных. У наступных двух раздзелах разгледзім гэтыя характарыстыкі.

(Гістарычны зноску: я ўпершыню пачуў тэрміны арыентаваных на дадзеныя і дакумент-арыентаваных на XML-DEV рассылання я не ведаю, хто прыдумаў іх, але я знайшоў паведамленні з 1997 года выкарыстанне тэрміна дакумент-арыентаваных і паведамленні. 1998 выкарыстанне абодвух тэрмінаў.)

4,1 арыентаваных на дадзеныя дакументы

Дадзеныя арыентаваных дакументы з’яўляюцца дакументамі, якія выкарыстоўваюць XML у якасці перадачы дадзеных. Яны прызначаныя для машын спажывання і той факт, што XML выкарыстоўваецца на ўсіх, як правіла, залішнія. Гэта значыць, гэта не важна для прыкладанняў або баз дадзеных, што дадзеныя па якой-то перыяд часу, захоўваецца ў дакуменце XML. Прыклады арыентаваных на дадзеныя дакументы з’яўляюцца заказы на продаж, расклад рэйсаў, навуковыя дадзеныя, і каціроўкі акцый.

Дадзеныя арыентаваных дакументаў характарызуюцца даволі рэгулярную структуру, дробназярністая дадзеных (гэта значыць, самая маленькая незалежная адзінка дадзеных на ўзроўні PCDATA-адзіны элемент або атрыбут) і практычна не змяшаным змесцівам. Парадак, у якім роднасныя элементы і PCDATA адбываецца, як правіла, не мае істотнага значэння, акрамя выпадкаў, калі праверка дакументаў.

Дадзеныя выгляд, які знаходзіцца ў арыентаваных на дадзеныя дакументы могуць узнікаць як у базе дадзеных (у гэтым выпадку вы хочаце выставіць яго як XML), так і па-за базы дадзеных (у гэтым выпадку вы хочаце захаваць яго ў базе дадзеных). Прыкладам Першы з’яўляецца велізарная колькасць састарэлых дадзеных, якія захоўваюцца ў рэляцыйных баз даных; Прыкладам апошняга з’яўляецца навуковым дадзеных, сабраным сістэмы вымярэння і пераўтворыцца ў XML.

Для прыкладу, у наступным парадку продажу дакумент арыентаваных на дадзеныя:

  <SalesOrder SONumber="12345">

   <Customer CustNumber="543">
     <CustName>ABC Industries</CustName>
     <Street>123 Main St.</Street>
     <City>Chicago</City>

     <State>IL</State>
     <PostCode>60609</PostCode>
   </Customer>
   <OrderDate>981215</OrderDate>

   <Item ItemNumber="1">
     <Part PartNumber="123">
      <Description>
        <p><b>Turkey wrench:</b><br />
        Stainless steel, one-piece construction,
        lifetime guarantee.</p>

      </Description>
      <Price>9.95</Price>
     </Part>
     <Quantity>10</Quantity>
   </Item>

   <Item ItemNumber="2">
     <Part PartNumber="456">
      <Description>
        <p><b>Stuffing separator:<b><br />
        Aluminum, one-year guarantee.</p>

      </Description>
      <Price>13.27</Price>
     </Part>
     <Quantity>5</Quantity>
   </Item>

  </SalesOrder>
  

У дадатак да такіх відавочна арыентаваных на дадзеныя дакументы, як продаж парадку, паказаным вышэй, многія прозы багатых дакументы таксама арыентаваных на дадзеныя. Разгледзім, напрыклад, старонка на сайце Amazon.com, які адлюстроўвае інфармацыю аб кнізе. Хоць старонка ў асноўным тэкст, структуру, што тэкст вельмі рэгулярнымі, вялікая частка якіх з’яўляецца агульнай для ўсіх старонак з апісаннем кніг, і кожная частка старонкі канкрэтны тэкст мае абмежаваны памер. Такім чынам, старонка можа быць пабудаваны з простых, арыентаваных на дадзеныя XML-дакумент, які змяшчае інфармацыю аб адной кнізе, і здабываецца з базы дадзеных і стыляў XSL, які дадае стандартны тэкст. Увогуле, любы вэб-сайт, які дынамічна будуе HTML-дакументы сёння, запоўніўшы шаблон з дадзенымі базы дадзеных, верагодна, можа быць заменены серыяй арыентаваных на дадзеныя дакументы XML і аднаго або некалькіх XSL табліцы стыляў.

Напрыклад, разгледзім наступны дакумент, які апісвае палёту:

  <FlightInfo>
   <Airline>ABC Airways</Airline> provides <Count>three</Count>

   non-stop flights daily from <Origin>Dallas</Origin> to
   <Destination>Fort Worth</Destination>. Departure times are
   <Departure>09:15</Departure>, <Departure>11:15</Departure>,
   and <Departure>13:15</Departure>. Arrival times are minutes later.
  </FlightInfo>

Гэта можа быць пабудаваная з наступных дакументаў XML і просты табліцы стыляў:

  <Flights>
   <Airline>ABC Airways</Airline>
   <Origin>Dallas</Origin>
   <Destination>Fort Worth</Destination>

   <Flight>
     <Departure>09:15</Departure>
     <Arrival>09:16</Arrival>
   </Flight>
   <Flight>

     <Departure>11:15</Departure>
     <Arrival>11:16</Arrival>
   </Flight>
   <Flight>
     <Departure>13:15</Departure>

     <Arrival>13:16</Arrival>
   </Flight>
  </Flights>

4,2 Дакумент-Centric Дакументы

Дакумент-арыентаваныя дакументы (як правіла) дакументы, якія прызначаны для спажывання чалавекам. Прыклады кніг, электронная пошта, рэклама, і амаль любы рукапісны дакумент XHTML. Яны характарызуюцца менш рэгулярнай або нерэгулярнай структуры, буйныя крупчастай дадзеных (гэта значыць, самая маленькая незалежная адзінка даных, можа быць на ўзроўні элемента са змяшаным змесцівам або ўсяго дакумента сабе), і шмат змяшаным змесцівам. Парадак, у якім роднасныя элементы і PCDATA адбываецца амаль заўсёды значныя.

Дакумент-арыентаваныя дакументы, як правіла, ад рукі напісана ў XML ці іншы фармат, такі як RTF, PDF, або SGML, які затым пераўтворыцца ў XML. У адрозненне ад арыентаваных на дадзеныя дакументы, яны звычайна не адбываюцца ў базе дадзеных. (Дакументы пабудаваны з дадзеных, устаўленых ў шаблоне, арыентаваных на дадзеныя, для атрымання дадатковай інфармацыі гл канец п. 4.1.) Для атрымання інфармацыі аб ПА можна выкарыстоўваць для пераўтварэння розных фарматах XML, гл спасылкі на розныя спісы праграмнага забеспячэння XML.

Напрыклад, наступнае апісанне прадукту дакумент-арыентаваных:

  <Product>

  <Intro>
  Ключ <ProductName> Турцыя </ ProductName> з <Developer>
Поўны Выраб Labs, Inc </ Распрацоўшчык> з'яўляецца <Summary>
 як гаечны ключ, але не гэтак вялікі. </ Рэзюмэ> </ На галоўную>
 <Description> < Пара> ключ індычка, які пастаўляецца ў <i>
як правай, так і левай версіі (Skyhook апцыянальна) </ I>,
 складаецца з <b> лепшых з нержавеючай сталі </ B>.
 Гатовы-счапленне прагумаванай ручкай хутка адаптуецца да
вашай рукі, нават у greasiest сітуацыях. Рэгуляванне магчымая
 з дапамогай розных карыстацкіх набор. </ Para>

  <Para>You can:</Para>

  <List>
  <Item><Link URL="Order.html">Order your own turkey wrench</Link></Item>
  <Item><Link URL="Wrenches.htm">Read more about wrenches</Link></Item>

  <Item><Link URL="Catalog.zip">Download the catalog</Link></Item>
  </List>

  <Para>Выдаткі індычкі ключ <b> ўсяго $ 19,99 </ B> і, калі Вы
  замовіць зараз, пастаўляецца з <b> ручной крэветкі молат </ B> як
 бонус падарунак.</Para>

  </Description>

  </Product>

04/03 Дадзеныя, дакументы і базы дадзеных

На практыцы адрозненне паміж арыентаваных на дадзеныя і дакумент-арыентаваных дакументаў не заўсёды ясна. Напрыклад, у адваротным выпадку арыентаваных на дадзеныя дакумента, такіх як рахункі-фактуры, могуць змяшчаць крупнозерністой, нерэгулярна структураваных дадзеных, такіх, як частка апісання. А ў адваротным выпадку дакумент-арыентаваных дакументаў, такіх як кіраўніцтва карыстача, можа ўтрымоўваць дробназярністы, рэгулярна структураваныя дадзеныя (часта метададзеных), напрыклад, імя аўтара і дату рэвізіі. Іншыя прыклады ўключаюць юрыдычныя і медыцынскія дакументы, якія напісаны як проза, але ўтрымоўваюць дыскрэтныя элементы дадзеных, такія як даты, імёны і працэдур, а часта і павінны быць захаваныя як поўны камплект дакументаў па юрыдычных прычынах.

Нягледзячы на гэта, якія характарызуюць вашы дакументы, арыентаваных на дадзеныя або дакумент, арыентаваны дапаможа вам вырашыць, якую базу дадзеных для выкарыстання. Як правіла, дадзеныя захоўваюцца ў традыцыйных баз дадзеных, такіх як рэляцыйныя, аб’ектна-арыентаванай, або іерархічныя базы дадзеных. Гэта можна зрабіць іншымі прамежкавага або магчымасці ўбудаваны ў саму базу дадзеных. У апошнім выпадку база дадзеных завецца XML-падтрымкай. Дакументы захоўваюцца ў базе дадзеных роднай XML (база дадзеных, распрацаваная спецыяльна для захоўвання XML) або сістэма кіравання кантэнтам (дадатак, прызначанае для кіравання дакументамі і пабудаваны на базе роднай базы дадзеных XML).

Гэтыя правілы не з’яўляюцца абсалютнымі. Дадзеныя – асабліва часткова структураваных дадзеных – можна захоўваць у роднай XML базы дадзеных і дакументы могуць быць захаваны ў традыцыйных базах дадзеных, калі некалькі XML-асаблівасці неабходныя. Акрамя таго, межы паміж традыцыйнымі базамі дадзеных і XML роднай базы дадзеных пачынаюць сцірацца, так як традыцыйныя базы дадзеных дадаваць уласныя XML-магчымасці і роднай XML базы дадзеных падтрымліваюць захоўванне фрагментаў дакумента ў знешніх (як правіла, рэляцыйныя) базы дадзеных.

Далей у гэтым артыкуле абмяркоўваюцца стратэгіі і пытанні, звязаныя з захоўвання і пошуку дадзеных ( профіль 5 ) і дакументаў ( профіль 6 ). За апошнюю дату пералік прадукцыі, XML базы дадзеных гл. у XML-СКБД.

5,0 захоўвання і выманні інфармацыі

Для перадачы дадзеных паміж XML-дакументы і базы дадзеных, неабходна адлюстраваць XML-схемы дакумента (DTD, XML-схемы, RELAX NG і г.д.), схемы базы дадзеных. Праграмнае забеспячэнне для перадачы дадзеных, то пабудаваны на вяршыні гэтага адлюстравання. Праграмнае забеспячэнне можа выкарыстоўваць XML-мова запытаў (напрыклад, XPath, XQuery, ці ўласны мову) або проста перадача дадзеных у адпаведнасці з адлюстраваннем (XML эквівалент SELECT * FROM табліца).

У апошнім выпадку структура дакумента павінен дакладна адпавядаць структуры чакаецца адлюстравання. Так як гэта часта не так, то прадукты, якія выкарыстоўваюць гэтую стратэгію часта выкарыстоўваюцца з XSLT. Гэта значыць, перад перадачай дадзеных у базу дадзеных, дакумент папярэдне пераўтворацца ў структуру чакаецца картирование; дадзеныя перадаюцца. Акрамя таго, пасля пераносу дадзеных з базы дадзеных, у выніку дакумент трансфармуецца ў структуру, неабходную для працы прыкладання.

05/01 Заданне адлюстравання дакумента схем і схем базы дадзеных

Адлюстравання паміж дакументам схем і схем баз даных ажыццяўляецца на тыпы элементаў, атрыбутаў і тэксту. Яны амаль заўсёды апускаць фізічнай структуры (напрыклад, асобы, CDATA секцыі і кадавання інфармацыі) і некаторыя лагічныя структуры (напрыклад, інструкцыі па апрацоўцы, каментары і парадак, у якім элементы і PCDATA з’яўляюцца ў іх бацькоў). Гэта больш разумна, чым гэта можа гучаць, як базы дадзеных і дадатку маем справу толькі з дадзенымі ў дакуменце XML. Напрыклад, у замове было паказана вышэй, гэта не мае значэння, калі нумар кліента захоўваецца ў раздзеле CDATA, вонкавы аб’ект, ці непасрэдна ў якасці PCDATA, а таксама не мае значэння, калі нумар кліента захоўваецца да або пасля заказу дату.

Адным са следстваў гэтага з’яўляецца тое, што “кругазварот” дакумент – гэта значыць, захоўванне дадзеных з дакумента ў базе дадзеных і затым рэканструкцыю дакумента з гэтых дадзеных – часта прыводзіць да іншага дакумента, нават у кананічным сэнсе перспектыве. Ці з’яўляецца гэта прымальным залежыць ад вашых запатрабаванняў і могуць паўплываць на ваш выбар праграмнага забеспячэння.

Два адлюстравання звычайна выкарыстоўваюцца для адлюстравання XML-дакумента схемы да схеме базы дадзеных: табліцы аснове картирования і аб’ектна-рэляцыйнага адлюстравання.

5.1.1 Табліца Супастаўленне на аснове

Аснове табліц адлюстравання выкарыстоўваецца многімі з прамежкавага, што перадача дадзеных паміж XML-дакумента і рэляцыйнай базы дадзеных. Яна мадэлюе XML-дакументы, як адну табліцу або набор табліц. Гэта значыць, структура дакумента XML павінен быць наступным, дзе элемент <database> і дадатковыя элементы <table> не існуюць у адной табліцы выпадку:

  <database>

   <table>
     <row>
      <column1>...</column1>
      <column2>...</column2>
    ...
     </row>

     <row>
    ...
     </row>
   ...
   </table>
   <table>
   ...
   </table>

 ...
  </database>
  

> 

У залежнасці ад праграмнага забеспячэння, то можна паказаць, ці варта калонкі дадзеныя захоўваюцца ў выглядзе даччыных элементаў або атрыбутаў, а таксама тое, што імёны выкарыстоўваць для кожнага элемента або атрыбуту. Акрамя таго, прадукты, якія выкарыстоўваюць аснове табліц адлюстравання часта па жаданні ўключаць табліцы і слупка метададзеных, альбо ў пачатку дакумента або ў выглядзе атрыбутаў кожнай табліцы або слупка элемента. Звярніце ўвагу, што тэрмін “табліца” звычайна тлумачыцца свабодна. Гэта значыць, пры перадачы дадзеных з базы дадзеных у XML, “стол” можа быць любы набор вынікаў, а пры перадачы даных з XML у базу дадзеных, “стол” можа быць стол або абнаўляюцца гледжання.

Табліца супастаўлення на аснове карысная для пераўтварэння рэляцыйных даных, напрыклад, пры перадачы дадзеных паміж двума рэляцыйнымі базамі дадзеных. Яго відавочным недахопам з’яўляецца тое, што не можа быць выкарыстана для любых XML-дакументаў, якія не адпавядаюць вышэй фармаце.

5.1.2 Object-Relational Mapping

Аб’ектна-рэляцыйнага адлюстравання выкарыстоўваецца усімі XML з падтрымкай рэляцыйных баз дадзеных і некаторыя прамежкавага прадуктаў. Гэта мадэлі дадзеных у XML-дакумент як дрэва аб’ектаў, якія з’яўляюцца спецыфічнымі для дадзеных ў дакуменце. У гэтай мадэлі, тыпы элементаў з атрыбутамі, элемент кантэнту, або змяшаны кантэнт ( складаныя тыпы элементаў ), як правіла, мадэлюецца як класы. Тыпы элементаў з PCDATA толькі змест ( простыя тыпы элементаў ), атрыбуты і PCDATA мадэлююцца як Скалярныя ўласцівасці. Мадэль затым адлюстроўваюцца ў рэляцыйныя базы дадзеных з выкарыстаннем традыцыйных аб’ектна-рэляцыйнага адлюстравання метадаў або SQL 3 прагляды аб’екта. Гэта значыць, класы супастаўляюцца з табліцамі, Скалярныя ўласцівасці адлюстроўваюцца ў слупкі, а аб’ект-знакавых ўласцівасці адлюстроўваюцца на першасны ключ / знешні ключ пар.

(Назва “аб’ектна-рэляцыйнай праекцыі” на самай справе няправільным, так як дрэва аб’ектаў можа быць адлюстраваны непасрэдна на аб’ектна-арыентаваных і іерархічных баз дадзеных. Аднак, гэта выкарыстоўваецца, таму што пераважная большасць прадуктаў, якія выкарыстоўваюць гэта адлюстраванне выкарыстання рэляцыйных баз дадзеных і Тэрмін “аб’ектна-рэляцыйнай праекцыі”, добра вядома.)

Важна разумець, што аб’ект мадэлі, якая выкарыстоўваецца ў гэта адлюстраванне ня Document Object Model (DOM). DOM мадэлі самога дакумента і з’яўляецца аднолькавай для ўсіх XML-дакументаў, у той час як мадэлі, апісанай вышэй мадэлі дадзеных у дакуменце і адрозніваецца для кожнага набору XML-дакументаў, якія адпавядаюць дадзенай XML-схемы. (У адпаведнасці з пагадненнем, тэрмін XML-схемы з ніжняга рэгістра “з” адносіцца да любой схеме XML -. Такіх, як DTD, XML Schema дакумента, або RELAX NG схемы XML-схемы з вялікай літары “S” ставіцца да W3C,. XML Schema мовы) Напрыклад, дакумент заказаў паказана вышэй, можа быць змадэляваны ў выглядзе дрэва аб’ектаў з чатырох класаў – SalesOrder, Customer элемент, а частка – як паказана ў наступнай дыяграме:

           SalesOrder
          /  |  \
       Customer  Item  Item
             |   |
            Part  Part

Былі дрэва DOM пабудаваныя з таго ж дакумента, ён будзе складацца з такіх аб’ектаў, як элемент, Attr, і тэкст:

           Element --- Attr
          (SalesOrder) (SONumber)
        ____/  /  \  \_____
       /    /   \    \
    Element   Text   Element Element
   (Customer) (OrderDate) (Item)  (Item)
     |          |     |
     etc.         etc.   etc.
  

Лі аб’екты ў мадэлі, на самай справе асобніка залежыць ад прадукту. Некаторыя прадукты дазваляюць ствараць класы ў мадэлі, а затым выкарыстоўваць гэтыя аб’екты з гэтых класаў у вашым прыкладанні. З такімі прадуктамі, дадзеныя перадаюцца паміж дакументам XML і гэтыя аб’екты, а таксама паміж гэтымі аб’ектамі і базай дадзеных. Іншыя прадукты выкарыстоўваюць аб’екты толькі як інструмент, каб дапамагчы візуалізаваць адлюстравання і перадачы дадзеных непасрэдна паміж дакументам XML і базы дадзеных. Ці з’яўляецца гэта карысна для стварэння асобніка прамежкавых аб’ектаў, цалкам залежыць ад вашага прыкладання.

(Звязвання XML-дакументаў на аб’екты шырока вядомы як дадзеныя XML-прывязкі, пасля Сонца Java Архітэктура для XML-прывязкі шэрагу прадуктаў рэалізацыі XML прывязкі дадзеных,.. многія з іх можа перадаваць дадзеныя паміж аб’ектамі і базамі дадзеных, а для больш інфармацыю гл ў раздзеле XML Data Binding, рэсурсаў ).

Тое, як аб’ектна-рэляцыйнага адлюстравання падтрымліваецца вар’іруецца ад прадукту да прадукту. Напрыклад:

• Усе прадукты падтрымліваюць адлюстраванне складаных тыпаў элементаў да класаў і простых тыпаў элементаў і атрыбутаў да ўласцівасцяў.

• Усе (?) Прадукты дазваляюць вам вызначыць каранёвай элемент, які не супастаўляецца з мадэллю аб’екта або базы дадзеных. Гэты элемент абалонкі карысна, калі вы хочаце захоўваць некалькі аб’ектаў верхняга ўзроўню ў тым жа дакуменце XML. Напрыклад, калі вы хочаце захоўваць некалькі заказы на продаж у тым жа дакуменце XML, вам трэба абгарнуць іх у адзін каранёвай элемент.

  Пакавальнік элементаў эквівалентна <database> элемента, калі дакумент XML з дапамогай табліцы супастаўлення на аснове утрымоўвае некалькі табліц і прысутнічае толькі для задавальнення патрабаванні аб тым, што XML-дакумент мае адзін каранёвай элемент. Некалькі прадуктаў дазваляюць вызначаць элементы на больш нізкім узроўні, як абгортка элементаў.

• Большасць прадуктаў дазваляе паказаць, ці варта ўласцівасці адлюстроўваюцца ў атрыбуты або даччыныя элементы ў дакуменце XML. Некаторыя прадукты дазваляюць змешваць атрыбуты і даччыныя элементы, а іншыя патрабуюць выкарыстоўваць толькі адзін ці іншы.

• Большасць прадуктаў, дазваляюць выкарыстоўваць розныя імёны ў дакумент XML і базы даных; некалькіх патрабуюць выкарыстоўваць аднолькавыя імёны ў абодвух.

• Большасць прадуктаў дазваляюць паказаць парадак, у якім даччыныя элементы з’яўляюцца ў іх бацькамі, хоць такім чынам, што немагчыма пабудаваць шматлікія мадэлі ўтрымання. На шчасце, падтрымоўваных мадэляў зместу дастаткова для большасці арыентаваных на дадзеныя дакументы. (Дзіця парадак важны, калі вы хочаце праверыць дакумент.)

• Некаторыя прадукты дазваляюць Вам карту складаныя тыпы элементаў для скалярных уласцівасцяў. Гэта карысна, калі тып элемента змяшчае змяшаны кантэнт, такі як <Description> элементам напрыклад заказ на продаж. Хоць <Description> элемент мае даччыныя элементы і тэкст у выглядзе XHTML, гэта больш карысна, каб паглядзець апісанне, адно ўласцівасць, чым разбіць яго на часткі яе кампанент.

• Нешматлікія прадукты падтрымкай адлюстравання PCDATA ў змешаных ўтрымання.

Для поўнага апісання аб’ектна-рэляцыйнага адлюстравання, гл. раздзел 3 ” аддз Прывязка да баз дадзеных “.

5,2 запытаў Мовы

Многія прадукты, перадача дадзеных непасрэдна ў залежнасці ад мадэлі, на якіх яны пабудаваны. Таму што структура дакумента XML, часта адрозніваецца ад структуры базы дадзеных, гэтыя прадукты часта ўключаюць у сябе ці выкарыстоўваюцца з XSLT. Гэта дазваляе карыстачам ператвараць дакументы ў структуры прадыктавана мадэлі перад перадачай дадзеных у базу дадзеных, а таксама наадварот. Паколькі XSLT апрацоўкі могуць быць дарагімі, некаторыя прадукты таксама інтэграваць абмежаваны лік пераўтварэнняў у іх адлюстравання.

Доўгатэрміновае рашэнне гэтай праблемы з’яўляецца рэалізацыя моў запытаў, якія вяртаюць XML. У цяперашні час (лістапад 2002 г.), большасць з гэтых моў спадзявацца на заявы SELECT, убудаваныя ў шаблоны. Гэтая сітуацыя павінна змяніцца, калі XQuery і SQL / XML, завершаны, у якасці асноўных пастаўшчыкоў баз дадзеных ужо працуюць над рэалізацый. На жаль, амаль усе з XML мовы запытаў (у тым ліку XQuery 1.0 і першы выпуск SQL / XML) даступныя толькі для чытання, так што розныя сродкі будуць неабходныя для ўстаўкі, абнаўлення і выдалення дадзеных у найбліжэйшай будучыні. (У доўгатэрміновай перспектыве, XQuery і SQL / XML будзе дадаць гэтыя магчымасці.)

5.2.1 Шаблон запытаў на аснове Мовы

Найбольш распаўсюджаныя мовы запытаў, якія вяртаюць XML з рэляцыйных баз даных на аснове шаблонаў. У гэтых мовах няма наканаваных адпаведнасць паміж дакументамі і базай дадзеных. Замест гэтага, SELECT заявы ўбудаваны ў шаблон і вынікі апрацоўваюцца з дапамогай праграмнага забеспячэння перадачы дадзеных. Напрыклад, наступны шаблон (не выкарыстоўваецца ні адным рэальным прадуктам) выкарыстоўвае <SelectStmt> элементаў для ўключэння ЗЕЬЕСТ і $ імя слупка значэння для вызначэння таго, дзе вынікі павінны быць размешчаны:

  <?xml version="1.0"?>

  <FlightInfo>
   <Introduction>The following flights are available:</Introduction>
   <SelectStmt>SELECT Airline, FltNumber,
         Depart, Arrive FROM Flights</SelectStmt>
     <Flight>
      <Airline>$Airline</Airline>

      <FltNumber>$FltNumber</FltNumber>
      <Depart>$Depart</Depart>
      <Arrive>$Arrive</Arrive>
     </Flight>

   <Conclusion>We hope one of these meets your needs</Conclusion>
  </FlightInfo>
  

Вынікам апрацоўкі такога пра шаблон можа быць:

  <?xml version="1.0"?>
  <FlightInfo>
   <Introduction>The following flights are available:</Introduction>

   <Flights>
     <Flight>
      <Airline>ACME</Airline>
      <FltNumber>123</FltNumber>
      <Depart>Dec 12, 1998 13:43</Depart>

      <Arrive>Dec 13, 1998 01:21</Arrive>
     </Flight>
   ...
   </Flights>
   <Conclusion>We hope one of these meets your needs.</Conclusion>

  </FlightInfo>
  

Шаблон запыту на аснове моў можа быць надзвычай гнуткім. Хоць набор функцый вар’іруецца ад прадукту да прадукту, некаторыя часта сустракаемыя асаблівасці:

• Магчымасць размяшчэння выніковага набору значэнняў у любой кропцы выхаднога дакумента, у тым ліку ў якасці параметраў у наступныя ЗЕЬЕСТ.

• Праграмаванне канструкцый, такіх як цыклы і ўмоўныя аператары.

• Зменныя і вызначэння функцый.

• Параметризация ЗЕЬЕСТ праз параметры HTTP.

Шаблон мовах на аснове запыту выкарыстоўваюцца амаль выключна для перадачы даных з рэляцыйных баз дадзеных для XML-дакументаў. Хоць некаторыя прадукты, якія выкарыстоўваюць на аснове шаблонаў мовы запытаў можа перадаваць дадзеныя з XML-дакументаў у рэляцыйныя базы дадзеных, яны не выкарыстоўваюць іх поўнага мовы шаблонаў для гэтай мэты. Замест гэтага яны выкарыстоўваюць аснове табліц адлюстравання, як апісана вышэй.

5.2.2 SQL-запытаў аснове Мовы

SQL мовах на аснове запыту выкарыстоўваць мадыфікаваныя ВЫБАР заявы, вынікі якога пераўтворыцца ў XML. Шэраг фірмовых SQL мовах на базе ў цяперашні час. Найпростая з іх выкарыстоўвае укладзеныя SELECT, заявы, якія ператвараюцца прама на укладзеныя XML у адпаведнасці з аб’ектна-рэляцыйнага адлюстравання. Наступны выкарыстоўвае SQL 3 аб’ектных уяўленняў, таксама трансфармуецца прама на XML. Апошні выкарыстоўвае OUTER заявы UNION і спецыяльнай разметкі, каб вызначыць, як вынікі пераўтворацца ў XML.

У дадатак да ўласнай моў, шэраг кампаній аб’ядналіся ў 2000 годзе для стандартызацыі XML-пашырэння для SQL. Іх праца з’яўляецца часткай спецыфікацыі ISO SQL, і гэта вядома як SQL / XML, канчатковае зацвярджэнне чакаецца ў канцы 2003 года. SQL / XML уяўляе XML-тып дадзеных і дадае шэраг функцый для SQL, так што можна пабудаваць XML элементы і атрыбуты з рэляцыйных даных.

Напрыклад, наступны запыт:

  SELECT Orders.SONumber,
     XMLELEMENT(NAME "Order",
           XMLATTRIBUTES(Orders.SONumber AS SONumber),
           XMLELEMENT(NAME "Date", Orders.Date),
           XMLELEMENT(NAME "Customer", Orders.Customer)) AS xmldocument
  FROM Orders

будуе выніковы набор з двума слупкамі. Першы слупок утрымоўвае нумар замовы, а другі слупок утрымоўвае XML-дакумента. Існуе адзін XML-дакумент у шэрагу, пабудаваных з дадзеных з адпаведнай радкі ў табліцы Orders. Напрыклад, дакумент на 123 радку для замовы на продаж можа быць:

  <Order SONumber="123">
   <Date>10/29/02</Date>
   <Customer>Gallagher Industries</Customer>
  </Order>

Інфармацыя аб SQL / XML, цяжка знайсці ў Інтэрнэце. Для больш старых інфармацыю і некаторыя ўступныя артыкулы, гл вэб SQLX Група сайта , з якіх канчатковы праект камітэта SQL / XML спецыфікацыя (PDF) даступны.

5.2.3 Мовы XML Query

У адрозненне ад заснаваных на шаблонах мовы запытаў SQL і мовах на аснове запытаў, якія могуць быць выкарыстаны толькі з рэляцыйнымі базамі дадзеных, XML мовы запытаў могуць быць выкарыстаны на працягу якога-небудзь дакумента XML. Каб выкарыстоўваць гэтыя з рэляцыйнымі базамі дадзеных, дадзеныя ў базе дадзеных павінны быць змадэляваныя як XML, што дазваляе запыты да віртуальным дакументаў XML.

З XQuery, альбо табліцу супастаўлення на аснове або аб’ектна-рэляцыйнай праекцыі могуць быць выкарыстаны. Калі аснове табліц адлюстравання выкарыстоўваецца, кожная табліца разглядаецца як асобны дакумент і злучэнні паміж табліцамі (дакументаў) пазначаны ў самым запыце, як і ў SQL Server. Калі аб’ектна-рэляцыйнага адлюстравання выкарыстоўваецца, іерархіі табліц, разглядаюцца як адзіны дакумент, і далучаецца да пазначаны ў адлюстраванні. Здаецца верагодным, што табліца аснове супастаўлення будуць выкарыстоўвацца ў большасці рэалізацый рэляцыйных баз дадзеных, так як яны здаюцца прасцей у рэалізацыі і больш звыклымі для карыстальнікаў SQL.

З XPath, аб’ектна-рэляцыйнай праекцыі павінны быць выкарыстаны для выканання запытаў да некалькіх табліцах. Гэта таму, што XPath не падтрымлівае злучэння паміж дакументамі. Такім чынам, калі ў табліцы супастаўлення на аснове было выкарыстана, можна было б запытаць толькі адну табліцу за раз.

5,3 Захоўванне дадзеных у роднай базы дадзеных XML

Акрамя таго, можна захоўваць дадзеныя ў XML-дакументаў у базе дадзеных роднай XML. Ёсць некалькі прычын для гэтага. Першы з іх, калі вашы дадзеныя полуструктурированные. Гэта значыць, яна мае рэгулярную структуру, але гэтая структура змяняецца досыць таго, што адлюстраванне яго на рэляцыйнай базе дадзеных вынікаў у любым вялікай колькасцю слупкоў з нулявымі значэннямі (што марна прастору) або вялікай колькасці табліц (што з’яўляецца неэфектыўным). Хоць часткова структураваных дадзеных могуць быць захаваны ў аб’ектна-арыентаванай і іерархічных баз дадзеных, вы можаце таксама абраць, каб захаваць яго ў родную базу дадзеных XML у выглядзе дакумента XML.

Другая прычына для захоўвання дадзеных у роднай базе дадзеных XML-пошуку з’яўляецца хуткасць. У залежнасці ад таго, як родную базу дадзеных XML фізічна захоўваюцца дадзеныя, ён мог бы атрымаць дадзеныя нашмат хутчэй, чым рэляцыйныя базы дадзеных. Прычына гэтага ў тым, што некаторыя захоўвання стратэгій, якія выкарыстоўваюцца роднай базы дадзеных XML-крамы цэлых дакументаў разам фізічна ці выкарыстоўваць фізічныя (а не лагічны) паказальнікі паміж часткамі дакумента. Гэта дазваляе дакументы павінны быць атрыманы або без злучэння або з фізічнымі злучэння, абодва з якіх з’яўляюцца хутчэй, чым лагічныя злучэнні выкарыстоўваюцца рэляцыйныя базы дадзеных.

Разгледзім, напрыклад, дакумент заказаў паказана вышэй. У рэляцыйнай базе дадзеных, гэта было б захоўваць у чатыры сталы – SalesOrders, Каталог, кліенты, а часткі – і атрымліваць дакумент запатрабуе далучаецца праз гэтыя табліцы. У роднай базе дадзеных XML, увесь дакумент можа захоўвацца ў адным месцы на дыску, так што атрыманне яго ці фрагмент патрабуецца адзін прагляд індэксу і адно чытанне для вымання дадзеных. Рэляцыйнай базы дадзеных патрабуецца чатыры пошук індэкса і па меншай меры чатыры чытання для вымання дадзеных.

Відавочным недахопам у дадзеным выпадку з’яўляецца тое, што павелічэнне хуткасці дзейнічае толькі пры атрыманні дадзеных у парадку, ён захоўваецца на дыску. Калі вы хочаце атрымаць іншы погляд на дадзеныя, напрыклад, спіс кліентаў і заказаў, якія да іх, прадукцыйнасці, верагодна, будзе горш, чым у рэляцыйнай базе дадзеных. Такім чынам, захоўванне дадзеных у XML-роднай базы дадзеных для падвышэння прадукцыйнасці прымяняецца толькі тады, калі прадстаўленне даных пераважае ў вашым дадатку.

Трэцяя прычына для захоўвання дадзеных у роднай базе дадзеных XML з’яўляецца тое, што вы хочаце выкарыстоўваць XML-спецыфічныя магчымасці, такія як выкананне XML-запытаў. Улічваючы, што мала дадзеных прыкладанняў, арыентаваных трэба гэта сёння, і што рэляцыйныя базы дадзеных рэалізацыі XML мовы запытаў, гэтая прычына з’яўляецца менш пераканаўчай.

Адна з праблем з захоўваннем дадзеных у роднай базе дадзеных XML з’яўляецца тое, што самы родны XML базы дадзеных могуць вяртаць толькі дадзеныя ў выглядзе XML. (Некалькі падтрымкі звязвання элементаў або атрыбутаў да пераменным прыкладанні.) Калі ваша прыкладанне мае патрэбу дадзеныя ў іншым фармаце (што верагодна), ён павінен аналізаваць XML перш чым ён зможа выкарыстаць гэтыя дадзеныя. Ясна, што гэта недахоп для лакальных прыкладанняў, якія выкарыстоўваюць роднай XML базы дадзеных замест рэляцыйнай базы дадзеных, так як ён нясе над галавой не знойдзены ў (напрыклад), ODBC прыкладання. Гэта не праблема з размеркаванымі прыкладаннямі, якія выкарыстоўваюць XML у якасці перадачы дадзеных, так як яны павінны несці гэтыя выдаткі незалежна ад таго, які тып базы дадзеных выкарыстоўваецца.

5,4 тыпаў дадзеных, значэнняў Null, наборы знакаў, і ўсё такое

У гэтым раздзеле разглядаецца шэраг пытанняў, звязаных з захоўваннем дадзеных з XML-дакументаў ў традыцыйных базах дадзеных. (Пытанні аб тыпах дадзеных і двайковыя дадзеныя ставяцца да захоўвання дадзеных ва ўласным XML-баз дадзеных, а таксама.) Як правіла, у вас не будзе выбару аб тым, як перадача даных праграмнае забеспячэнне вырашае гэтыя пытанні. Тым не менш, вы павінны ведаць, што гэтыя праблемы існуюць, бо яны могуць дапамагчы Вам выбраць праграмнае забеспячэнне.

5.4.1 Тыпы дадзеных

XML не падтрымлівае тыпы дадзеных у любым значным сэнсе гэтага слова. За выключэннем неапрацаваных сутнасці, усе дадзеныя ў дакумент XML з’яўляецца тэкстам, нават калі яна ўяўляе сабой іншы тып дадзеных, такія як дата або лік. Як правіла, праграмнае забеспячэнне перадачы дадзеных будзе ператвараць дадзеныя з тэкставых (у дакуменце XML) з іншымі відамі (у базе дадзеных), і наадварот.

Як праграмнае забеспячэнне вызначае, якія пераўтварэнні выканаць, да пэўнага прадукту, але два метаду з’яўляюцца агульнымі. Першы спосаб складаецца ў тым, што праграмнае забеспячэнне вызначае тып дадзеных з схемы базы дадзеных, так як гэта заўсёды даступныя падчас выканання. (Схема XML не абавязкова даступныя падчас выканання і можа нават не існуе). Другі спосаб з’яўляецца тое, што карыстач відавочна паставак тып дадзеных, напрыклад, у адлюстраванні інфармацыі. Гэта можа быць напісана карыстачом ці генеруецца аўтаматычна з схемы базы дадзеных або XML-схемы. Калі генеруецца аўтаматычна, тыпы дадзеных могуць быць атрыманы з схем баз дадзеных і некаторых тыпаў XML-схемы (XML-схемы, RELAX NG).

Яшчэ адна праблема гэта тое, што пераўтварэнні тэкставых фарматаў, прызнаюцца (пры перадачы даных з XML) або могуць быць створаны аўтаматычна (пры перадачы дадзеных у XML). У большасці выпадкаў, колькасць тэкставых фарматаў, якія падтрымліваюцца для вызначанага тыпу дадзеных, верагодна, будзе абмежаваным, напрыклад, для аднаго вызначанага фармату, або тым, падтрымоўванае дадзеных драйверам JDBC. Даты, найбольш верагодна, прычынай праблемы, а дыяпазон магчымых фарматаў велізарны. Лікі, з іх розных міжнародных фарматах, можа выклікаць праблемы.

5.4.2 двайковых дадзеных

Існуюць тры распаўсюджаных спосабу захоўвання двайковых дадзеных у XML-дакументаў: Base64 кадаваньне (MIME-кадоўку, якая адлюстроўвае двайковыя дадзеныя ў падмноства US-ASCII [0-9a-Za-Z + /] – гл RFC 2045 ), шаснаццатковым кадавання ( дзе кожны двайковы актэт кадуецца з дапамогай двух знакаў, якія прадстаўляюць шаснаццаткавыя лічбы [0-9A-Fa-F]), і неапрацаваных сутнасці (дзе двайковыя дадзеныя захоўваюцца ў асобных фізічных асобы з астатняй часткай дакумента XML).

Самая вялікая праблема з двайковыя дадзеныя, што многія (большасць?) Прадуктаў перадачы дадзеных не падтрымліваюць яго, таму не забудзьцеся праверыць, калі ў вас робіць. Другасная праблема ўзнікае, калі неанализируемых сутнасцяў выкарыстоўваюцца. Праблема тут у тым, што большасць (усе?) Прадуктаў перадачы дадзеных не захоўваюць абазначэння і аб’явы сутнасцяў. Такім чынам, пазначэнне, звязаных з пэўным тварам, будуць страчаныя пры перадачы дадзеных з дакумента XML ў базу дадзеных. (Больш падрабязную інфармацыю аб абазначэння гл. раздзел 04/07 рэкамендацыі XML 1.0.)

5.4.3 Null дадзеных

У свеце баз дадзеных, нулявы дадзеных азначае, што дадзеныя, якія проста не існуе. Гэта вельмі адрозніваецца ад значэння 0 (для лікаў) або нулявы даўжыні (для радка). Напрыклад, выкажам здагадку, у вас ёсць дадзеныя, атрыманыя ад метэастанцыі. Калі тэрмометр не працуе, нулявое значэнне захоўваецца ў базе дадзеных, а не 0, а гэта азначае, што-нешта іншае зусім.

XML таксама падтрымлівае канцэпцыю нулявых дадзеных з дапамогай дадатковых тыпаў элементаў і атрыбутаў. Калі значэнне дадатковы тып элемента або атрыбуту з’яўляецца пустым, ён проста не ўключаны ў дакумент. Як і ў базах дадзеных, атрыбутаў, якія змяшчаюць нуль радкоў даўжыні і пустых элементаў не нулявыя: іх значэнне нулявой даўжыні.

Пры супастаўленні структуры дакумента XML ў базу дадзеных і наадварот, вы павінны быць асцярожныя, што дадатковыя тыпы элементаў і атрыбутаў, якія супастаўляюцца з абнуляецца слупкоў, і наадварот. Вынік не рабіць гэтага, верагодна, будзе ўстаўкі памылкі (пры перадачы дадзеных у базу дадзеных) або несапраўдных дакументаў (пры перадачы дадзеных з базы дадзеных).

Паколькі XML-супольнасць, верагодна, больш гнуткія паняцці, што маецца на ўвазе пад нулявым, чым базы дадзеных супольнасці – у прыватнасці, шматлікія карыстачы XML будуць лічыць атрыбуты якія змяшчаюць радкі нулявой даўжыні і пустых элементаў, якія будуць “нулявыя”, – Вы павінны праверыць, як праграмнае забеспячэнне апрацоўвае гэтую сітуацыю. Некаторы праграмнае забеспячэнне прапануе карыстачу выбар вызначэння паняцця “нулявы” ў дакуменце XML, уключаючы падтрымку XSI: нулявой атрыбут з XML-схем.

5.4.4 наборы знакаў

Па вызначэнні, дакумент XML можа ўтрымліваць любы Unicode знак, за выключэннем некаторых кіраўнікоў сімвалаў. На жаль, многія базы дадзеных прапануюць абмежаваныя або не падтрымлівае Unicode і патрабуюць адмысловай настройкі для апрацоўкі не-ASCII сімвалаў. Калі дадзеныя ўтрымоўваюць не-ASCII сімвалаў, не забудзьцеся праверыць, якім чынам і калі абедзве базы дадзеных і праграмнае забеспячэнне перадачы дадзеных, апрацоўваць гэтыя сімвалы.

5.4.5 Інструкцыі па апрацоўцы і Каментары

Інструкцыі апрацоўкі і каментары не з’яўляюцца часткай “дадзеныя” XML-дакумент, і большасць (усе?) Перадачы дадзеных праграмнае забеспячэнне не можа з імі зладзіцца. Праблема ў тым, што яны могуць адбыцца практычна ў любым месцы ў XML-дакумент, і, такім чынам, не лёгка ўпісваюцца ў аснове табліц і аб’ектна-рэляцыйных адлюстраванняў. (Адно ясна непрацаздольнай рашэнне ў рэляцыйнай базе дадзеных, каб дадаць табліцы для інструкцыі апрацоўкі і каментары, дадаваць знешнія ключы ў гэтых табліцах для ўсіх іншых табліц, а таксама праверыць гэтыя табліцы пры апрацоўцы іншы табліцы.) Такім чынам, большасць перадачы дадзеных праграмнага забеспячэння проста адкідае іх. Калі інструкцыі апрацоўкі і каментары важныя для вас, праверыць, якім чынам і калі ваша праграмнае забеспячэнне апрацоўвае іх. Вы маглі б таксама разгледзець магчымасць выкарыстання роднага базе дадзеных XML.

5.4.6 Захоўванне разметкі

Як было адзначана ў раздзеле 5.1.2 , часам бывае карысна захоўваць элементы са змяшаным змесцівам ў базе даных без далейшага разбору. Калі гэта будзе зроблена, разметка захоўваецца з сімвалаў разметкі. Тым не менш, узнікае праблема з тым, як захоўваць сімвалы разметкі, якія не выкарыстоўваюцца для разметкі. У XML-дакуменце, гэтыя захоўваюцца з выкарыстаннем л, GT, узмацняльнік, Quot і APOS асоб. Гэта можа быць зроблена і ў базе дадзеных. Напрыклад, наступнае апісанне:

  <description>

   <b>Confusing example:</b> &lt;foo/&gt;
  </description>
  

могуць быць захаваны ў базе дадзеных, як:

   <b>Confusing example:</b> &lt;foo/&gt;

Праблема ў тым, што не-XML-моў запытаў, такіх як SQL, не правяраць значэння слупкоў для разметкі і арганізацыя выкарыстання і інтэрпрэтаваць іх адпаведным чынам. Такім чынам, калі вы хочаце знайсці радок “<foo/>” з SQL, вы павінны ведаць, што вы на самай справе неабходныя, каб знайсці радок “<foo/>”.

З іншага боку, калі спасылкі на сутнасці пашыраны, праграмнае забеспячэнне перадачы дадзеных не можа адрозніць разметку ад аблічча іх выкарыстаннем. Напрыклад, калі вышэй апісанне захоўваецца ў базе дадзеных наступным чынам, праграмнае забеспячэнне не можа сказаць, ці з’яўляецца <b>, </ B> і <foo/> з’яўляюцца разметкі або тэксту.

  <b>Confusing example:</b> <foo/>

Доўгатэрміновым рашэннем гэтай праблемы з’яўляецца XML-Aware базы дадзеных, у якіх фактычны разметку разглядаюцца асобна ад рэчаў, якія толькі выглядаюць як разметка. Тым не менш, то, верагодна, заўсёды будуць праблемы, калі не-XML-прыкладанняў апрацоўваць XML.

5,5 Фарміраванне XML-схем з рэляцыйнымі схемамі і Vice Versa

Агульны пытанне, пры перадачы дадзеных паміж XML-дакументы і базы дадзеных, як ствараць XML-схемы з схемы базы дадзеных, і наадварот. Перш чым растлумачыць, як гэта зрабіць, варта адзначыць, што гэта падчас распрацоўкі аперацыі. Прычынай гэтага з’яўляецца тое, што большасць дадзеных прыкладанняў, арыентаваных, і практычна ўсе вертыкальныя прыкладанні, працаваць з вядомым наборам XML-схем і схем баз дадзеных. Такім чынам, яны не патрэбныя для стварэння схем падчас выканання. Акрамя таго, як будзе відаць ніжэй, працэдуры для стварэння схем менш дасканалыя. Прыкладанні, якія трэба захоўваць выпадковых XML дакументаў у базе дадзеных, верагодна, варта выкарыстоўваць родную базу дадзеных XML замест стварэння схемы падчас выканання.

Самы просты спосаб для стварэння рэляцыйнай схемы з XML-схем, і наадварот, каб проста жорстка шлях праз аб’ектна-рэляцыйнага адлюстравання, якая мае шэраг дадатковых магчымасцяў. Аналагічныя працэдуры існуюць для працы з аб’ектна-арыентаваных баз дадзеных. (Для крок за крокам прыклады кожнай працэдуры, гл ў раздзеле 4 карты аддз да баз дадзеных ).

Для стварэння рэляцыйнай схемы з схемы XML:

1. Для кожнага складанага тыпу элемента , ствараць табліцы і слупка першаснага ключа.

2. Для кожнага тыпу элемента са змяшаным змесцівам, стварыць асобную табліцу, у якой захоўваецца PCDATA, звязаных з бацькоўскай табліцай праз першасны ключ бацькоўскай табліцы.

3. Для кожнай адназначнай прыкмета таго, што тып элемента, і для кожнага асобна сустракаюцца ў просты элемент дзіцяці , стварыць слупок ў гэтай табліцы. Калі схема XML мае інфармацыю аб тыпе дадзеных, а затым усталяваць тып дадзеных слупка адпаведнага тыпу. У адваротным выпадку, ўсталюйце тып дадзеных для загадзя вызначанага тыпу, напрыклад, CLOB або VARCHAR (255). Калі тып даччынага элемента або атрыбуту не з’яўляецца абавязковым, зрабіць слупок дапушчальным.

4. Для кожнага шматзначнае атрыбуту і для кожнага шматкроць адбываюцца просты элемент дзіцяці, стварыць асобную табліцу для захоўвання каштоўнасцяў, звязаных з бацькоўскай табліцай праз першасны ключ бацькоўскай табліцы.

5. Для кожнага дзіцяці складаны элемент, спасылка табліцы тыпу бацькоўскага элемента ў табліцу тыпу даччынага элемента з першаснага ключа бацькоўскай табліцы.

Для стварэння XML-схемы з рэляцыйнай схемы:

1. Для кожнай табліцы, стварыце элемент тыпу.

2. Для кожнага тыпу дадзеных (без ключа) слупок ў гэтай табліцы, а таксама для слупка першаснага ключа (ёй), дадаць атрыбут да тыпу элемента або PCDATA толькі для даччынага элемента да яго ўтрыманню мадэлі.

3. Для кожнай табліцы, да якой першасны ключ ідзе на экспарт, дадаць даччыны элемент да мадэлі зместу і працэсу табліцы рэкурсіўна.

4. Для кожнага вонкавага ключа, дадайце даччыны элемент да мадэлі ўтрымання і працэсаў знешняй табліцы ключавых рэкурсіўна.

Ёсць шэраг недахопаў, да гэтых працэдур. Многія з іх лёгка выправіць ўручную, напрыклад, імя сутыкненняў і указаннем тыпаў дадзеных слупкоў і даўжыні. (DTD не ўтрымліваюць інфармацыю аб тыпе дадзеных, так што немагчыма прадказаць, якія тыпы дадзеных павінны быць выкарыстаны ў базе дадзеных. Звярніце ўвагу, што тыпы дадзеных і даўжыні можна прадказаць, зыходзячы з дакумента XML-схемы.)

Больш сур’ёзнай праблемай з’яўляецца тое, што дадзеныя «мадэль» выкарыстоўваецца дакумент XML, часта адрозніваецца (і звычайна больш складаны), чым найбольш эфектыўную мадэль для захоўвання дадзеных у базе дадзеных. Напрыклад, разгледзім наступны фрагмент XML:

  <Customer>
   <Name>ABC Industries</Name>
   <Address>
     <Street>123 Main St.</Street>

     <City>Fooville</City>
     <State>CA</State>
     <Country>USA</Country>
     <PostCode>95041</PostCode>

   </Address>
  </Customer>
  

Працэдура для стварэння рэляцыйнай схемы з схемы XML будзе Стварае некалькі табліцы: адзін для кліентаў, і адзін для адрасоў. Тым не менш, у большасці выпадкаў гэта мела б больш сэнсу для захоўвання адрасы ў табліцы кліентаў, а не асобнай табліцы.

<address> Элемент добры прыклад таго, пакавальнік элементаў. Wrapper элементы звычайна выкарыстоўваюцца па двух прычынах. Па-першае, яны дапамагаюць забяспечыць дадатковую структуру, што робіць дакумент больш зразумелым. Па-другое, яны звычайна выкарыстоўваюцца ў якасці формы ўводу дадзеных. Напрыклад, <address> элемент можа быць перададзена праграме, якая пераўтворыць ўсе адрасы да спісу аб’ектаў, незалежна ад таго, дзе яны адбываюцца.

Хоць абгортка элементы карысныя ў XML, яны звычайна выклікаюць праблемы ў выглядзе дадатковай структуры, калі яны супастаўляюцца з базай дадзеных. Па гэтай прычыне, яны як правіла, варта выключыць з схемы XML перад стварэннем рэляцыйнай схеме. Паколькі малаверагодна, што схема XML можа і не павінен быць зменены на пастаяннай аснове, гэта прыводзіць да неадпаведнасці паміж фактычным дакументаў і дакументаў чакаецца праграмнае забеспячэнне перадачы дадзеных, так як абалонка элементы не ўключаны ў адлюстраванні. Гэта можа быць вырашана шляхам пераўтварэння дакументаў у час выканання, напрыклад, з XSLT: абгортка элементы будуць ліквідаваны да перадачы дадзеных у базу дадзеных і ўстаўляюцца пасля пераносу дадзеных з базы дадзеных.

Нягледзячы на гэтыя недахопы, апісаныя вышэй працэдуры па-ранейшаму ўяўляюць добрую адпраўную кропку для стварэння XML-схемы з рэляцыйнай схемы і наадварот, асабліва ў вялікіх сістэмах.

6,0 захоўвання і пошуку дакументаў

Існуюць дзве асноўныя стратэгіі захоўвання XML-дакументаў: захоўваць іх у файлавай сістэме або ў выглядзе BLOB ў рэляцыйнай базе дадзеных і прымаць абмежаванае XML-функцыянальнасці, ці захоўваць іх у базе дадзеных роднай XML.

06/01 Захоўванне дакументаў у файлавай сістэме

Калі ў вас ёсць просты набор дакументаў, такіх як невялікі набор дакументацыі, самы просты спосаб для іх захоўвання ў файлавай сістэме. Пасля гэтага можна выкарыстоўваць такія інструменты, як GREP для запытаў іх і SED, каб змяніць іх. (Поўны пошук тэксту XML-дакументы, відавочна, недакладна, паколькі яны не могуць лёгка адрозніць разметку ад тэксту і не можа зразумець сутнасць іх выкарыстаннем. Тым не менш, у невялікім сістэмы, такія недакладнасці могуць быць прымальнымі.) Калі вы хочаце простае кіраванне транзакцыямі, Вы можаце размясціць дакументаў у сістэме кантролю версій, такіх як CVS або RCS.

6,2 Захоўванне дакументаў у BLOB-

Ледзь больш складаны варыянт складаецца ў захоўванні дакументаў, як двайковыя аб’екты ў рэляцыйнай базе дадзеных. Гэта дае шэраг пераваг баз дадзеных: кантроль транзакцый, бяспека, шматкарыстальніцкі доступ, і так далей. Акрамя таго, многія рэляцыйныя базы дадзеных маюць прылады для пошуку тэксту і можа рабіць такія рэчы, як паўнатэкставы пошук, блізкасць пошук, пошук сінонімаў, і невыразны пошук. Некаторыя з гэтых інструментаў робяцца XML-ведаць, што дасць магчымасць устараніць праблемы, звязаныя з пошукам XML-дакументаў, як чысты тэкст.

Калі вы захоўваеце XML-дакументаў, як BLOB, вы таксама можаце лёгка рэалізаваць свой уласны просты XML-Aware індэксацыі, нават калі база дадзеных не можа праіндэксаваць XML. Адзін са спосабаў зрабіць гэта, каб Стварае некалькі табліцы, табліцы індэкса (вядомы як столік у DB2, дзе ідэя ўзнікла) і планшэт. Дакумент табліца ўтрымоўвае першасны ключ і BLOB слупок, у якім дакумент захоўваецца. Індэкс табліцы змяшчае слупок, які змяшчае значэння для індэксавання і знешні ключ, які паказвае на першасны ключ планшэце.

Калі дакумент захоўваецца ў базе дадзеных, шукалі усе асобнікі элемента або атрыбуту індэксацыі. Кожны асобнік захоўваецца ў індэкснай табліцы, нараўне з першасным ключом дакумента. Значэнне слупка затым індэксуецца, што дазваляе прымяненне для хуткага пошуку пэўнага элемента або значэнне атрыбуту і атрымаць адпаведны дакумент.

Напрыклад, выкажам здагадку, у вас пакет дакументаў, якія адпавядаюць наступным DTD і хочуць пабудаваць паказальнік аўтараў:

  <!ELEMENT Brochure (Title, Author, Content)>

  <!ELEMENT Title (#PCDATA)>
  <!ELEMENT Author (#PCDATA)>
  <!ELEMENT Content (%Inline;)> <!-- Inline entity from XHTML -->
  

Вы можаце захоўваць іх ў наступнай табліцы:

  Authors           Brochures
  ----------------------   ---------
  Author   VARCHAR(50)   BrochureID INTEGER
  BrochureID INTEGER     Brochure  LONGVARCHAR
  

Калі Вы ўстаўляеце брашуру ў базу дадзеных, Дадатак ўстаўляе брашуру ў табліцы брашуры, а затым скануе яго на элементы <author>, захоўвання сваіх каштоўнасцяў і брашуры ідэнтыфікатар ў табліцы аўтараў. Затым прыкладанне можа атрымаць брашуры аўтара з простымі ЗЕЬЕСТ. Напрыклад, каб атрымаць усе брашуры напісаныя аўтарам Чэн, прыкладанне выконвае інструкцыю:

  SELECT Brochure
  FROM Brochures
  WHERE BrochureID IN (SELECT BrochureID FROM Authors WHERE Author='Chen')

Больш складаныя табліцы індэкса будзе утрымоўваць чатыры калонкі: тып элемента або імя атрыбуту, тып (элемент або атрыбут), значэнне і дакумент, які сведчыць асобу. Гэта можа захоўваць значэння некалькіх канструкцый разметку ў адной табліцы і павінны быць праіндэксаваныя на імя, тып і значэнне. Даць агульны SAX-прыкладанне для запаўнення такі табліцы было б адносна лёгка.

6,3 Родныя Базы дадзеных XML

Калі вам трэба больш магчымасцяў, чым прапануюць адзін з простых сістэм, апісаных вышэй, вы павінны разгледзець родную базу дадзеных XML. Родныя базы дадзеных XML, гэта базы дадзеных, распрацаваны адмыслова для захоўвання XML-дакументаў. Як і ў іншых базах дадзеных, яны падтрымліваюць такія функцыі, як транзакцыі, бяспека, шматкарыстальніцкі доступ, праграмных інтэрфейсаў API, мовы запытаў, і так далей. Адзінае адрозненне ад іншых баз дадзеных з’яўляецца тое, што іх унутраная мадэль грунтуецца на XML, а не што-небудзь іншае, напрыклад, рэляцыйнай мадэлі.

Родныя базы дадзеных XML, якія найбольш часта выкарыстоўваюцца для захоўвання дакументаў арыентаваных дакументаў. Асноўнай прычынай гэтага з’яўляецца іх падтрымка XML, мовы запытаў, якія дазваляюць вам задаваць пытанні тыпу: “Дайце мне ўсе дакументы, у якіх трэці пункт пасля пачатку раздзеле змяшчаецца адважнае слова”, або нават проста абмежаваць поўным пошук тэксту на пэўныя часткі дакумента. Такія запыты відавочна цяжка спытаць у мове, як SQL Server. Іншая прычына заключаецца ў тым, што родныя базы дадзеных XML, захаваць рэчы, як парадак дакумента, інструкцыі апрацоўкі і каментары, а часта і захаваць CDATA раздзелаў, арганізацыя выкарыстання, і гэтак далей, у той час як XML з падтрымкай баз дадзеных няма.

Родныя базы дадзеных XML таксама шырока выкарыстоўваецца для інтэграцыі дадзеных. Хоць інтэграцыі дадзеных гістарычна была выканана праз Федэратыўныя рэляцыйных баз дадзеных, яны патрабуюць усё крыніцы дадзеных для супастаўлення з рэляцыйнай мадэллю. Гэта відавочна нездзяйсняемае для шматлікіх тыпаў дадзеных і XML-мадэль дадзеных забяспечвае значна большую гнуткасць. Родныя базы дадзеных XML таксама апрацоўваць змены схемы лягчэй, чым рэляцыйныя базы дадзеных і можа апрацоўваць schemaless дадзеныя. Абодва з’яўляюцца важнымі фактарамі пры інтэграцыі дадзеных з крыніц, не пад вашым непасрэдным кантролем.

Трэцім асноўным варыянтам выкарыстання для ўласных баз дадзеных XML з’яўляецца часткова структураваных дадзеных, такіх як знаходзіцца ў галіне фінансаў і біялогіі, якія мяняюцца так часта, што канчатковае схем часцяком не ўяўляецца магчымым. Таму што родны базы дадзеных XML не патрабуюць схем (як і рэляцыйных баз дадзеных), яны могуць апрацоўваць такія дадзеныя, хоць і прыкладанні часта патрабуюць людзі на яе апрацоўку.

Канчатковы асноўных выкарыстанне мясцовых баз дадзеных XML у апрацоўцы схемы эвалюцыі. Хоць родныя базы дадзеных XML, не забяспечваюць поўнага рашэння якім-небудзь чынам, яны даюць вялікую гнуткасць, чым рэляцыйныя базы дадзеных. Напрыклад, родны базы дадзеных XML не патрабуюць існуючыя дадзеныя, якія будуць перанесены ў новую схему, можа апрацоўваць змены схемы, для якіх не існуе шляху міграцыі дадзеных і можа захоўваць дадзеныя, нават калі яно адпавядае невядомай версіі схемы.

Іншае выкарыстанне родных баз дадзеных XML ўключаюць прадастаўленне дадзеных і метададзеных кэшы для працяглых аперацый, апрацоўкі вялікіх дакументаў, апрацоўкі іерархічных дадзеных, а таксама выступае ў якасці сярэдняга ўзроўню кэша дадзеных. Для поўнага абмеркавання варыянтаў выкарыстання для ўласных баз дадзеных XML, гл Пераход Native: Варыянты выкарыстання для ўласных баз дадзеных XML.

6.3.1 Што такое роднай базы дадзеных XML?

Тэрмін «роднай базы дадзеных XML” упершыню атрымаў вядомасць у маркетынгавую кампанію для Таміна, родны базы дадзеных XML ад кампаніі Software AG. Магчыма з-за поспеху гэтай кампаніі, тэрмін увайшоў у агульнае карыстанне сярод кампаній, якія распрацоўваюць падобныя прадукты. Недахопам гэтага з’яўляецца тое, што, быўшы маркетынгавы тэрмін, ён ніколі не меў фармальнага тэхнічнага вызначэння.

Адзін з магчымых азначэнняў (распрацаваны членамі XML: DB спіс рассылання ) з’яўляецца тое, што родныя базы дадзеных XML, які:

Першая частка гэтага вызначэння аналагічная вызначэння іншых тыпаў баз даных, канцэнтруючы ўвагу на мадэлі, якая выкарыстоўваецца базы дадзеных. Варта адзначыць, што дадзены роднай базы дадзеных XML можна захоўваць больш інфармацыі, чым змяшчаецца ў мадэлі ён выкарыстоўвае. Напрыклад, яна можа падтрымліваць запыты, заснаваныя на мадэлі дадзеных XPath, але захоўваць дакументы ў тэкставым выглядзе. У гэтым выпадку, такія рэчы, як CDATA секцыі і арганізацыя выкарыстання захоўваюцца ў базе дадзеных, але не ўключаныя ў мадэль.

Другая частка вызначэнні гаворыцца, што асноўнай адзінкай захоўвання ў базе дадзеных роднай XML з’яўляецца дакументам XML. Хаця, здаецца, магчыма, што родныя базы дадзеных XML можа прызначыць гэтую ролю фрагменты дакументаў, ён запоўнены дакументаў на ўсіх (?) Роднай базы дадзеных XML сёння.

(Асноўны адзінкай захоўвання з’яўляецца самым нізкім узроўнем кантэксту, у якім дадзены элемент дадзеных адпавядае, і эквівалентная радку ў рэляцыйнай базе дадзеных. Яе існаванне не выключае магчымасці атрымання больш дробныя адзінкі дадзеных, такіх як фрагменты дакументаў ці асобных элементаў , а таксама не выключае аб’яднання фрагментаў з аднаго дакумента з фрагментамі на іншы дакумент. У рэляцыйных тэрмінах, гэта раўнасільна таму, што існаванне радкоў не выключае выманне асобных значэнняў слупкоў або стварэння новых радкоў з існуючых радкоў.)

Трэцяя частка вызначэнні гаворыцца, што асноўнай фармат захоўвання дадзеных не мае значэння. Гэта праўда, і аналагічна, заявіўшы, што фізічны фармат захоўвання выкарыстоўваюцца рэляцыйныя базы дадзеных не ці звязана гэтая база даных з’яўляецца рэляцыйнай.

6.3.2 падтрымкай XML архітэктуры баз дадзеных

Архітэктуры роднага баз дадзеных XML, можна падзяліць на дзве вялікія катэгорыі: тэкставыя і на аснове мадэляў.

6.3.2.1 на аснове тэксту роднай Базы дадзеных XML

Тэкставыя роднай базы дадзеных XML гэта той, які захоўвае XML у выглядзе тэксту. Гэта можа быць файл у файлавай сістэме, BLOB ў рэляцыйнай базе дадзеных, або уласны фармат тэксту. (Варта адзначыць, што рэляцыйныя базы дадзеных, якая дадала XML-Aware апрацоўкі CLOB (Character Large Object) слупкоў, па сутнасці, роднай базы дадзеных XML у дачыненні да гэтых здольнасцяў.)

Агульным для ўсіх тэкставых роднай XML базы дадзеных індэксы, якія дазваляюць запыт рухавік лёгка пераходзіць у любую кропку ў любым дакуменце XML. Гэта дае такія базы дадзеных велізарная перавага ў хуткасці пры атрыманні цэлых дакументаў або фрагментаў дакумента. Гэта таму, што база дадзеных можа выканаць адзін прагляд індэкса, становішча галоўкі дыска адзін раз, і, мяркуючы, што патрэбны фрагмент захоўваецца ў сумежных байт на дыску, атрымаць увесь дакумент або фрагмент ў адной чытаць. У супрацьлегласць гэтаму, зборка дакументаў з кавалкаў, як гэта робіцца ў рэляцыйнай базе дадзеных, а некаторыя на аснове мадэляў роднай XML базы дадзеных, патрабуе шматразовага пошуку індэкса і некалькі аперацый чытання.

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

6.3.2.2 аснове мадэлі падтрымкай XML Базы дадзеных

Другая катэгорыя родных баз дадзеных XML з’яўляецца заснаваны на мадэлі роднай базы дадзеных XML. Замест таго каб захоўваць XML-дакумент у выглядзе тэксту, яны будуюць ўнутраную мадэль аб’екта з дакумента і захаваць гэтую мадэль. Як захоўваецца мадэль залежыць ад базы дадзеных. Некаторыя базы дадзеных крамы мадэлі ў рэляцыйных ці аб’ектна-арыентаваных баз дадзеных. Напрыклад, захоўванне DOM ў рэляцыйнай базе дадзеных можа прывесці ў табліцах, такіх як элементы, атрыбуты, PCDATA, сутнасці і EntityReferences. Іншыя базы дадзеных выкарыстоўваецца уласны фармат захоўвання аптымізавана для сваёй мадэлі.

(Для прыкладу просты, заснаваны на мадэлі роднай XML базы дадзеных пабудаваныя на рэляцыйнай базы дадзеных, гл Сістэма, апісаная Маркам Бербек на XML-L спіс рассылкі для снежні 1998 сістэма выкарыстоўваюцца пяць сталоў -. вызначэння атрыбутаў, элемент / атрыбут асацыяцыі, вызначэння мадэлі зместу, значэння атрыбутаў і значэнняў элементаў (PCDATA або паказальнікі на іншыя элементы) -. і мадэль, якая ўключае ў сябе толькі элементы, атрыбуты, тэкст і парадак дакумента Шукайце тэмы азагалоўленым ” Запіс рэшт, Змешаная зместу і захоўвання XML-дакументы на рэляцыйныя базы дадзеных “і” захоўванне XML-дакументаў на рэляцыйныя базы дадзеных “.)

На аснове мадэляў роднай XML базы дадзеных пабудавана на іншыя базы дадзеных, верагодна, маюць такую ж прадукцыйнасць, гэтыя базы дадзеных пры атрыманні дакументаў па той відавочнай прычыне, што яны належаць на гэтыя сістэмы для атрымання дадзеных. Тым не менш, дызайн баз дадзеных, асабліва для роднай XML базы дадзеных пабудавана на аснове рэляцыйных баз дадзеных, мае значныя магчымасці для варыяцый. Напрыклад, базы дадзеных, якія выкарыстоўваліся прама аб’ектна-рэляцыйнай адлюстраванне DOM можа прывесці да сістэмы, якія патрабуюць выканання асобных ВЫБАР запыты для атрымання дзецьмі з кожнага вузла. З іншага боку, большасць такіх баз дадзеных аптымізаваць іх захоўвання мадэляў і пошуку праграмнага забеспячэння. Напрыклад, Рычард Эдвардс апісаў сістэму захоўвання DOM ў рэляцыйныя базу дадзеных , якая можа атрымаць любы фрагмент дакумента (уключаючы ўвесь дакумент) з адной ЗЕЬЕСТ.

На аснове мадэляў роднай XML базы дадзеных, якія выкарыстоўваюць уласны фармат захоўвання, верагодна, маюць такую ж прадукцыйнасць, тэкставыя роднай XML баз дадзеных пры атрыманні дадзеных у тым парадку, у якім ён захоўваецца. Гэта таму, што большасць (?) Выкарыстоўваць такія базы дадзеных фізічных паказальнікаў паміж вузламі, якія павінны забяспечыць такую ж прадукцыйнасць, выманне тэксту. (Што адбываецца хутчэй, таксама залежыць ад фармату высновы. Text-сістэмы на базе відавочна хутчэй пры вяртанні дакументаў у выглядзе тэксту, у той час як на аснове мадэлі сістэмы, відавочна, хутчэй вяртаюцца дакументы, як дрэвы DOM, мяркуючы, што іх карты мадэль лёгка DOM.)

Як тэкставыя роднай XML базы дадзеных, на аснове мадэлі роднай базы дадзеных XML, верагодна, сутыкнуцца праблем з прадукцыйнасцю пры атрыманні і вяртанні дадзеных у любой форме, выдатнай ад той, у якой яна захоўваецца, напрыклад, пры звароце іерархіі або яго часткі. Ці будуць яны быць хутчэй або павольней, чым тэкст сістэм, заснаваных не ясна.

6.3.3 Асаблівасці Роднай Базы дадзеных XML

У гэтым раздзеле коратка абмяркоўваецца шэраг функцый, даступных у роднай XML-баз дадзеных. Яна павінна дапамагчы даць вам прадстаўленне аб тым, якія функцыі даступныя ўжо сёння і якія функцыі варта чакаць у будучыні.

6.3.3.1 Калекцыі дакументаў

Многія родныя базы дадзеных XML падтрымліваецца паняцце калекцыі. Гэта гуляе ролю, аналагічную табліцу ў рэляцыйнай базы дадзеных або каталога ў файлавай сістэме. Напрыклад, выкажам здагадку, вы выкарыстоўваеце роднай XML-дадзеных для захоўвання заказаў. У гэтым выпадку, вы можаце вызначыць набор заказаў, так што запыты над заказаў можа быць абмежаваная дакументамі ў гэтай калекцыі.

У якасці іншага прыкладу, выкажам здагадку, што вы захоўваеце кіраўніцтваў для ўсіх прадуктаў кампаніі ў роднай XML-дадзеных. У гэтым выпадку, вы можаце вызначыць іерархію калекцый. Напрыклад, вы, магчыма, калекцыі для кожнага прадукту, і на працягу гэтай калекцыі, калекцыі для ўсіх кіраўнікоў у кожным кіраўніцтве.

Будзь калекцыі могуць быць укладзенымі залежыць ад базы дадзеных.

6.3.3.2 Мовы запытаў

Амаль усе родныя XML базы дадзеных падтрымліваюць адзін або некалькі моў запытаў. Найбольш папулярнымі з іх з’яўляюцца XPath (з пашырэннямі для запытаў на некалькі дакументаў) і XQuery, хоць шматлікія ўласныя мовы запытаў падтрымліваюцца таксама. Пры разглядзе роднай базы дадзеных XML, вы, верагодна, варта пераканацца, што мова запытаў падтрымлівае вашыя патрэбы, паколькі яны могуць вагацца ад паўнатэкставы пошук стылю на неабходнасць рекомбинировать фрагменты з некалькіх дакументаў.

У будучыні, самым родным XML базы дадзеных, хутчэй за ўсё, падтрымка XQuery ад W3C.

6.3.3.3 абнаўлення і выдалення

Родныя базы дадзеных XML, ёсць цэлы шэраг стратэгій, накіраваных на абнаўленне і выдаленне дакументаў, ад простай замены або выдалення існуючага дакумента з зменамі праз жывое дрэва DOM з мовамі, якія вызначаюць, як змяніць фрагменты дакумента. Большасць з гэтых метадаў з’яўляюцца прыватнай уласнасцю. Аднак, два некалькі стандартных моў для абнаўлення XML-дакументы з’явіліся:

• XUpdate , ад XML: DB ініцыятывы , з’яўляецца XML-арыентаваны мова. Ён выкарыстоўвае XPath для ідэнтыфікацыі набору вузлоў, то паказвае, ці варта ўстаўляць і выдаляць гэтыя вузлы, а таксама ўстаўляць новыя вузлы да або пасля іх. XUpdate была ўкаранёна ў шэрагу роднай XML-баз дадзеных.

• Набор пашырэнняў XQuery быў прапанаваны членамі W3C XQuery рабочай групы і Патрык Lehti. Варыяцыі на гэтых пашырэнняў былі рэалізаваны ў шэрагу родных баз дадзеных XML, і здаецца верагодным, што яны будуць асновай абнаўлення сінтаксісу XQuery.

Нягледзячы на гэтыя мовы, абнаўленне здольнасці, верагодна, застануцца фрагментаваныя да абнаўлення сінтаксіс фармальна патрапяць у XQuery.

6.3.3.4 Здзелкі, блакаванне, і паралелізм

Практычна ўсе родныя XML базы дадзеных падтрымліваюць аперацыі (і, як мяркуецца, адкаты падтрымкі). Тым не менш, блакаванне часцяком на ўзроўні цэлых дакументаў, а не на ўзроўні асобных вузлоў, так шматкарыстальніцкай паралелізму можа быць адносна нізкім. Ці з’яўляецца гэтае пытанне залежыць ад прыкладання і што ўяўляе сабой “дакумент”. Напрыклад:

• Дакумент чале кіраўніцтва карыстача і пісьменнікі рэдагаваць кіраўнікоў. Дакумент блакавання на ўзроўні наўрад ці выкліча праблемы паралелізму, а двух пісьменнікаў абнаўлення той жа чале, у той жа час малаверагодна.

• Дакумент захоўвае ўсе дадзеныя аб продажах кампаніі вядзе і прадаўцоў выходзіць на новыя прывесці інфармацыю аб продажах. Дакумент блакавання на ўзроўні, верагодна, выкліча праблемы паралелізму, а шанцы двух прадаўцоў абнаўлення прывесці інфармацыю ў той жа час досыць высокая. На шчасце, гэта можа быць хоць бы часткова вырашана шляхам стварэння аднаго продажаў прывесці дакумент у патэнцыйнага кліента.

• Дакумент змяшчае дадзеныя, якія выкарыстоўваюцца ў працоўных працэсаў, такіх, як фінансавы кантракт. Кожны крок працоўны працэс чытае дадзеныя з дакумента і дадае свае ўласныя дадзеныя. Напрыклад, адзін крок можа выконваць праверку крэдытаздольнасці і дадаць кошт крэдыту ў дакуменце. Яшчэ адным крокам можа праверыць на рэшткі па рахунках на іншых кантрактаў з аднаго кліента і дадайце агульнага непагашанай астатак. Калі вузел блакавання на ўзроўні выкарыстоўваецца, некаторыя з гэтых крокаў могуць выконвацца паралельна. Калі дакумент блакавання на ўзроўні выкарыстоўваюцца, яны павінны быць выконваюцца паслядоўна, каб пазбегнуць канфліктаў пісаць. Гэта можа прывесці да непрымальным затрымак ў вялікіх аб’ёмах прыкладанняў.

Праблема з узроўню вузла блакавання яе рэалізацыі. Блакаванне вузла звычайна патрабуе блакавання свайго бацькі, які ў сваю чаргу, патрабуе блакавання свайго бацькі, і гэтак далей аж да каранёвага, эфектыўна блакавання за ўсё дакумента. Каб зразумець, чаму гэта так, разгледзім транзакцыя, якая чытае канчатковага вузла. Калі здзелка не набыць замкі на продкі ліставай вузел, іншая транзакцыя можа выдаліць продак ліставай вузел, у сваю чаргу, выдаленне канчатковага вузла. Аднак, таксама відавочна, што іншая транзакцыя павінна быць у стане абнавіць тыя часткі дакумента, а не на прамым шляху ад кораня да канчатковага вузла.

Частковае рашэнне гэтай праблемы з’яўляецца прапанаваная Stijn Dekeyser, і інш. Хоць яны не цалкам перасцерагчы сябе ад праблемы блакавання продкі мэтавага вузла, яны сапраўды робяць гэтыя замкі больш гнуткім, адзначаючы іх запытаў вызначаюць шлях ад вузла да заблакаваны мэтавага вузла. Гэта дазваляе іншым аперацыях з мэтай вызначэння іх канфліктам з транзакцыямі, якія ўжо маюць замкі. (З-за ацэнкі запытаў, каб набыць замкі недазваляльна дорага, фактычна схема некалькі больш абмежаваным, чым тое, што апісана тут, але гэта агульная ідэя.) Для спасылкі на артыкулы, якія апісваюць іншыя схемы блакіроўкі, гл навуковых артыкулаў часткі XML / База дадзеных Спасылкі. Звярніце ўвагу, што некалькі родных баз дадзеных XML, падтрымліваюць вузел блакавання на ўзроўні, але я не ведаю, як яны рэалізуюць яго.

У будучыні, самым родным XML базы дадзеных, хутчэй за ўсё, прапануем ўзроўню вузла замыкання.

6.3.3.5 інтэрфейс прыкладнага праграмавання (API)

Амаль усе родныя базы дадзеных XML прапануе праграмныя інтэрфейсы API. Яны, як правіла ў выглядзе ODBC-падобны інтэрфейс, з дапамогай метадаў для падлучэння да базы дадзеных, вывучэнне метададзеных, выканання запытаў і атрымання вынікаў. Вынікі, як правіла, вяртаюцца ў выглядзе радка XML, DOM дрэва, або SAX Parser ці XMLReader па вяртанні дакументам. Калі запыты могуць вяртаць некалькі дакументаў, то метады для перабору набору вынікаў таксама даступныя. Хоць большасць родных XML базы дадзеных падаюць ўласныя інтэрфейсы, два незалежнасць ад пастаўшчыка баз дадзеных XML API, былі (у цяперашні час), распрацаванай [ліпені 2004]:

• XML: DB API з XML: DB.org гэта мова праграмавання, нейтральны, выкарыстоўвае XPath ў якасці мовы запытаў, і ў цяперашні час пашырана для падтрымкі XQuery. Ён быў рэалізаваны цэлы шэраг роднай базы дадзеных XML і можа быць рэалізаваны на працягу неместный баз дадзеных, а таксама.

• JSR 225: XQuery API для Java (XQJ) заснаваны на JDBC і выкарыстоўвае XQuery ў якасці мовы запытаў. Яна распрацоўваецца на аснове Java Sun, Community Process (JCP), а таксама праект версія. Таму што гэтая ініцыятыва на чале з IBM і Oracle, яго наступнай распаўсюджанае сцвярджэнне здаецца вельмі верагодным.

Большасць мясцовых XML базы дадзеных таксама прадастаўляюць магчымасць выконваць запыты і вяртаюць вынікі па пратаколе HTTP.

6.3.3.6 кругазвароту

Адна з важных асаблівасцяў родных баз дадзеных XML, што яны могуць туды-назад XML-дакументаў. Гэта значыць, вы можаце захоўваць XML-дакумент у родную базу дадзеных XML і атрымаць «аднолькавыя» дакумент назад. Гэта важна, каб дакумент-арыентаваных прыкладанняў, для якіх такія рэчы, як падзелы CDATA, арганізацыя выкарыстання, каментары і інструкцыі па апрацоўцы з’яўляюцца неад’емнай часткай дакумента. Гэта таксама важна для многіх юрыдычных і медыцынскіх прыкладанняў, якія па законе абавязаныя захоўваць дакладныя копіі дакументаў.

(Круглы адключэння менш важная для арыентаваных на дадзеныя прыкладанняў, якія звычайна клапоцяцца толькі пра элементаў, атрыбутаў, тэксту і іерархічным парадку. Усе праграмнае забеспячэнне, перадача дадзеных паміж XML-дакументамі і базамі дадзеных можна туды-назад іх. Яна таксама можа туды-назад брат парадку (парадак элементаў і PCDATA ў іх аднаго з бацькоў) у абмежаванай ліку выпадкаў, якія важныя для арыентаваных на дадзеныя прыкладанняў. Аднак, паколькі ён не можа туды-зваротна брат парадку, у цэлым, а таксама не могуць туды-назад інструкцыі па апрацоўцы, каментары, і фізічную структуру (спасылкі на сутнасці, раздзелы CDATA і гэтак далей), яна не падыходзіць для дакумент-арыентаваных прыкладанняў.)

Усе родныя XML базы дадзеных могуць туды-зваротна дакументы на ўзроўні элементаў, атрыбутаў, PCDATA і парадку дакумента. Колькі яшчэ яны могуць туды-назад залежыць ад базы дадзеных. Як правіла, тэкставыя роднай XML баз дадзеных туды-назад XML-дакументы дакладна, а на аснове мадэлі роднай XML баз дадзеных туды-назад XML-дакументаў на ўзроўні іх мадэлі дакумента. У выпадку асабліва мінімальныя мадэлі дакумента, гэта азначае, кругазварот на ўзроўні менш кананічныя XML.

Паколькі ўзровень кругазвароту трэба цалкам залежыць ад вашага прыкладання, вы можаце выбраць адзін з многіх родных XML баз дадзеных або быць абмежаваны толькі некаторыя з іх.

6.3.3.7 Remote Data

Некаторыя родныя базы дадзеных XML можа ўключаць у сябе выдаленых дадзеных у дакументах, якія захоўваюцца ў базе дадзеных. Як правіла, гэта дадзеныя, атрыманыя з рэляцыйнай базы дадзеных з ODBC, OLE DB або JDBC і мадэлюецца з дапамогай таблічнага адлюстравання ці аб’ектна-рэляцыйнага адлюстравання. Лі дадзеныя жыць – гэта значыць ці абнаўлення дакумента ў родную базу дадзеных XML адлюстраваны ў выдаленай базе дадзеных – залежыць ад роднай базы дадзеных XML. У рэшце рэшт, самы родны XML базы дадзеных, хутчэй за ўсё, падтрымка жыць выдаленых дадзеных.

6.3.3.8 індэксы

Усе родныя базы дадзеных XML падтрымку індэксах, як спосаб павысіць хуткасць выканання запытаў. Гэтыя тры тыпу індэксаў. Значэнне індэкса паўнатэкставага індэксу і значэння атрыбутаў, якія выкарыстоўваюцца для вырашэння запытаў, такіх як, “Знайсці ўсе элементы і атрыбуты, значэнне якога” Санта Круз “. Структурныя індэкс індэксуе размяшчэнне элементаў і атрыбутаў і выкарыстоўваюцца для вырашэння запытаў, такіх як, “Знайсці ўсе адрасы элементаў”. Значэнне і структурныя індэксы аб’ядноўваюцца для вырашэння запытаў, такіх як, “Горад Знайсці ўсе элементы, значэннем якога з’яўляецца” Санта Круз “. Нарэшце, паўнатэкставыя індэксы індэкс асобных лексем ў тэкст і значэнні атрыбутаў, якія выкарыстоўваюцца для вырашэння запытаў, такіх як, “Знайсці ўсе дакументы, якія змяшчаюць словы« Санта-Крус “,” або, у спалучэнні са структурнымі індэксы, “Знайсці ўсе дакументы , якія ўтрымліваюць словы “Санта Круз” ўнутры элемента адрасы “.

Большасць мясцовых XML базы дадзеных падтрымліваюць абодва значэння і структурных паказчыкаў. Некаторыя родныя базы дадзеных XML падтрымлівае паўнатэкставыя індэксы.

6.3.3.9 Знешняя сістэма захоўвання дадзеных Entity

Складанае пытанне, калі трэба захоўваць XML-дакументаў, як звяртацца з вонкавымі арганізацыямі. Гэта значыць, яны павінны быць пашыраныя і іх значэннем, якія захоўваюцца з астатняй часткай дакумента, або павінна быць спасылка на сутнасць застаецца на месцы? Існуе няма адназначнага адказу на гэтае пытанне.

Напрыклад, выкажам здагадку, што дакумент уключае ў сябе знешні агульны асобнік, які выклікае CGI-праграмы на бягучы прагноз надвор’я. Калі дакумент будзе выкарыстоўвацца ў якасці вэб-старонкі, каб даць бягучыя справаздачы надвор’е, было б памылкай пашырыць спасылкі на сутнасць, а вэб-старонка больш не будзе вяртаць дадзеныя ў рэальным часе. З іншага боку, калі дакумент былі часткай калекцыі гістарычных дадзеных пра надвор’е, было б памылкай не пашыраць спасылкі на сутнасць, як дакумент будзе заўсёды атрымліваць бягучыя дадзеныя, а не якая змяшчае гістарычныя дадзеныя.

У якасці іншага прыкладу разгледзім кіраўніцтва карыстача, якая складалася з нічога, акрамя спасылкі на знешнія аб’екты, якія паказваюць на галовах кіраўніцтва. Калі некаторыя з гэтых кіраўнікоў былі выкарыстаны ў іншых дакументах, такіх як кіраўніцтва для розных мадэляў аднаго і таго ж прадукту, было б памылкай пашырыць гэтыя спасылкі, так як гэта прывядзе да некалькі копій аднаго і таго ж кіраўніка.

Я не ведаю, як родны базы дадзеных XML справіцца з гэтай праблемай. У ідэале, яны павінны дазволіць паказаць, ці варта пашыраць вонкавыя спасылкі на сутнасці ад выпадку да выпадку.

6.3.4 Нармалізацыя, спасылкавых цэласнасці, і маштабаванасць

Для многіх людзей, асабліва тых, з рэляцыйнай базай дадзеных фоны, родны базы дадзеных XML, узнікае шэраг спрэчных пытанняў, у прыватнасці ў дачыненні да пытанняў, звязаных з захоўваннем дадзеных (у адрозненне ад дакументаў). Гэтыя пытанні абмяркоўваюцца ў наступных раздзелах.

6.3.4.1 Нармалізацыя

Нармалізацыя ставіцца да працэсу праектавання схемы базы даных, у якой дадзена частка даных прадстаўлена толькі адзін раз. Нармалізацыя мае шэраг відавочных пераваг, такіх як скарачэнне дыскавая прастора і выключае магчымасць супярэчлівыя дадзеныя, якія могуць паўстаць, калі дадзены фрагмент дадзеных, якія захоўваюцца ў больш чым адным месцы. Гэта адзін з краевугольных камянёў рэляцыйнай тэхналогіі і тэмпературы ўспышкі ў дыскусіях аб захоўванні дадзеных ва ўласным баз дадзеных XML.

Перш чым абмяркоўваць нармалізацыю далей, карысна адзначыць, што гэта не з’яўляецца праблемай для многіх дакумент-арыентаваных дакументаў. Разгледзім, напрыклад, збор дакументаў, якія апісваюць прадуктаў кампаніі. У многіх такіх калекцый, ёсць толькі невялікі аб’ём дадзеных, які з’яўляецца агульным для ўсіх дакументаў – апавяшчэнне аб аўтарскім праве, карпаратыўныя адрасы і нумары тэлефонаў, лагатыпы, і гэтак далей – і гэтая сума настолькі малая ў адносінах да агульнага, што Амаль ніхто не лічыць яе нармалізацыі. (З іншага боку, іншыя наборы дакументацыі маюць значнае перакрыцце паміж дакументамі і іх варта нармалізацыі.)

Як рэляцыйных баз дадзеных, няма нічога ва ўласным XML-баз дадзеных, якое прымушае вас нармалізаваць вашы дадзеныя. Гэта значыць, вы можаце ствараць дрэнныя захоўвання дадзеных з роднай базы дадзеных XML, гэтак жа лёгка, як вы можаце з рэляцыйнай базай дадзеных. Такім чынам, важна разгледзець структуру вашых дакументаў, захоўваць іх у базе дадзеных роднай XML. (Роднай баз дадзеных XML, ёсць адна перавага над рэляцыйнымі базамі дадзеных тут. Паколькі ўласныя базы дадзеных XML не маюць схем баз даных, вы можаце захоўваць падобныя дакументы з больш чым адной схемы ў базу дадзеных, у той жа час. Хоць вы, магчыма, трэба перабудаваць запыты і пераўтвараць існуючыя дакументы – нетрывіяльны працэс – гэта можа палегчыць пераход працэсу).

Нармалізацыя дадзеных для роднай базы дадзеных XML шмат у чым гэтак жа, як гэта для нармалізацыі рэляцыйных баз дадзеных: вы павінны стварыць свой дакументаў, з тым, што дадзеныя не паўтараюцца. Адно з адрозненняў паміж роднай базы дадзеных XML і рэляцыйных баз дадзеных з’яўляецца тое, што XML падтрымлівае мнагазначныя ўласцівасці ў той час як (у большасці), рэляцыйныя базы дадзеных няма. Гэта дазваляе “нармалізаваць” дадзеныя ў XML-роднай базы дадзеных такім чынам, што немагчыма ў рэляцыйнай базе дадзеных.

Разгледзім, напрыклад, заказаў на продаж. Ён складаецца з загалоўка, такія як нумар замовы, дату і нумар кліента, і аднаго або некалькіх пазіцый, якія ўтрымліваюць нумар, колькасць і агульная кошт. У рэляцыйнай базе дадзеных, інфармацыю загалоўка павінны захоўвацца ў асобнай табліцы з пазіцый, паколькі Ёсць некалькі элементаў на кожнай радку загалоўка. У роднай базе дадзеных XML, гэтая інфармацыя можа захоўвацца ў адным дакуменце без надмернасці, так як іерархічная прырода XML дазваляе дадзенай бацькоўскі элемент, каб мець некалькі дзяцей.

На жаль, у рэальным свеце нармалізацыі ці не з’яўляецца гэта проста. Напрыклад, што адбываецца, калі вы хочаце заказаў ўтрымліваць інфармацыю аб кліентах, такіх як імёны кантактаў і дастаўкі і білінг адрасы? Ёсць два варыянты тут. Па-першае, вы можаце дубляваць інфармацыю аб кліентах у кожным заказаў для гэтага кліента, што прыводзіць да надмернасці дадзеных і ўсе праблемы, якія яна цягне за сабой. Па-другое, вы можаце захоўваць інфармацыю аб кліентах і асобна альбо прадастаўляць XLink ў парадку дакумента продажу заказчыку дакумент або аб’яднання двух дакументаў, калі дадзеныя запытваюцца. Пры гэтым мяркуецца, што альбо XLinks падтрымліваюцца (у большасці выпадкаў, яны не з’яўляюцца, хоць падтрымка плануецца) або мову запытаў падтрымлівае далучаецца (таксама не заўсёды дакладна).

На практыцы, Ёсць няма выразных адказаў. Рэальныя рэляцыйныя даныя часта не нармальна для павышэння прадукцыйнасці, так што наяўнасць ненармальных XML-дадзеных можа быць не так дрэнна, як здаецца, але гэта рашэнне, якое вы павінны зрабіць. Калі вы захоўваеце дакумент-арыентаваных дакументаў і могуць нармалізаваць іх з дастатковай ступенню – такіх, як захоўванне кіраўнікоў або працэдуры ў выглядзе асобных дакументаў і ўступленне ў іх для стварэння канчатковага карыстальніка дакументы – тады родныя базы дадзеных XML, верагодна, добрым рашэннем для вас , тым больш што ён прадаставіць вам магчымасці, такія як XML, мовы запытаў не сустракаюцца ў іншых базах дадзеных. Калі вы захоўваеце арыентаваных на дадзеныя дакументы і роднай базы дадзеных XML паляпшае прадукцыйнасць прыкладання або прадастаўляе полуструктурированные захоўвання дадзеных, што вы не можаце знайсці ў іншай базе дадзеных, то вы павінны яго выкарыстоўваць. Але калі вы апынецеся па сутнасці будынка рэляцыйнай базы дадзеных у вашым родным базу дадзеных XML, вы можаце спытаць сябе, чаму вы не выкарыстоўваеце рэляцыйныя базу дадзеных, у першую чаргу.

6.3.4.2 Цэласнасць дадзеных

Цесна звязаная з нармалізацыяй з’яўляецца спасылкавых цэласнасці. Спасылкавых цэласнасць азначае дзеянні паказальнікі на адпаведныя дадзеныя і з’яўляецца неабходнай часткай падтрымання ўзгодненага стану базы дадзеных: Гэта вам не добра, калі заказ змяшчае нумар заказчыка, і няма адпаведнай запісу кліента. Аддзел дастаўкі не будзе ведаць, куды адпраўляць тавары, набытыя і бухгалтэрыя не будзе ведаць, куды адпраўляць рахункі-фактуры.

У рэляцыйнай базе дадзеных, спасылкавых цэласнасць азначае забеспячэнне таго, знешнія ключы паказваюць на сапраўдны першасныя ключы – гэта значыць праверкі таго, што першасны ключ радкі якія адказваюць любым знешніх ключом існуе. У роднай базе дадзеных XML, спасылкавых цэласнасці азначае забеспячэнне таго, “паказальнікі” у дакументах XML паказваюць на сапраўдныя дакументы або фрагменты дакументаў.

Паказальнікі ў XML-дакументаў ў некалькіх формах: ID / IDREF атрыбуты, ключ / keyref палёў (як яны вызначаны ў схемах XML), XLinks, а таксама розныя ўласныя механізмы. Апошняе ўключае ў сябе канкрэтнага мовы “спасылкі” элементы і атрыбуты, такія як спасылка атрыбут <element> элемент XML-схемы, а для канкрэтнай базы дадзеных сувязь механізмаў. Хоць канкрэтнага мовы “спасылкі” элементы і атрыбуты, вельмі распаўсюджаны, спецыфічныя для базы дадзеных сувязяў механізмы не з’яўляюцца.

Спасылкавых цэласнасць базы дадзеных у родным XML можна разбіць на дзве катэгорыі: цэласнасць ўнутраных паказальнікаў (паказальнікі ў дакумент) і цэласнасць знешніх паказальнікаў (паказальнікі паміж дакументамі). Спасылкавых цэласнасці ўнутраных паказальнікаў, якія выкарыстоўваюць нестандартныя механізмы ніколі не выконваецца, бо роднай базы дадзеных XML, няма ніякага спосабу выяўлення такіх паказальнікаў. Спасылкавых цэласнасці ўнутраных паказальнікаў, якія выкарыстоўваюць стандартны механізм, такія як ID / IDREF або ключ / keyref, па меншай меры часткова падтрымліваецца праз праверку.

Прычына таго, што такая падтрымка частковай тым, што большасць родных XML баз дадзеных выконваць праверку толькі тады, калі дакумент ўстаўляецца ў базу дадзеных. Такім чынам, калі абнаўлення выконваюцца на ўзроўні дакумента – гэта значыць, шляхам выдалення, а затым замяніць дакумент – праверка з’яўляецца дастатковым для забеспячэння цэласнасці ўнутраных паказальнікаў. Але калі абнаўлення выконваюцца на ўзроўні вузла – гэта значыць, устаўка, змяненне і выдаленне асобных вузлоў – то базы дадзеных неабходна выканаць дадатковыя работы (напрыклад, праверку ўсіх змен), каб гарантаваць цэласнасць ўнутраных паказальнікаў. Толькі некалькі родных баз дадзеных XML гэта зрабіць, калі такія маюцца.

Спасылкавых цэласнасць знешніх паказальнікаў (наколькі я ведаю) не падтрымліваецца, нават некалькі баз дадзеных, якія падтрымліваюць знешнія паказальнікі. Калі знешні паказальнік паказвае на рэсурс, які захоўваецца ў іншых месцах у базе дадзеных, няма ніякіх падстаў не ўжываць цэласнасці паказальнік. Аднак, калі паказальнік паказвае на рэсурс па-за базы дадзеных, адсутнасць прымусовых разумна. Напрыклад, выкажам здагадку, што дакумент змяшчае XLink, які паказвае на дакумент на знешні вэб-сайт. Базы дадзеных, відавочна, не мае кантролю над ці апошні дакумент існуе, і таму не можа разумна захавання цэласнасці XLink.

У будучыні, самым родным XML базы дадзеных, хутчэй за ўсё, падтрымкі спасылкавых цэласнасці ўнутраных паказальнікаў, якія выкарыстоўваюць стандартныя механізмы. Многія родныя базы дадзеных XML, верагодна, падтрымліваць знешнія паказальнікі нейкі, а таксама цэласнасць знешніх паказальнікаў, якія паказваюць на рэсурсы, якія захоўваюцца ў базе дадзеных. На дадзены момант, аднак, яно да прыкладанняў для забеспячэння цэласнасці паказальнікаў – як унутраных, так і знешніх – у большасці выпадкаў.

6.3.4.3 Маштабаванасць

Маштабаванасць добра па-за маёй вобласці ведаў, так што большасць з таго, што варта, з’яўляецца спекуляцыяй. Увогуле, я думаю, што родныя базы дадзеных XML будзе маштабаваць вельмі добра ў некаторых асяроддзях і вельмі дрэнна ў іншых.

Як іерархічныя і рэляцыйныя базы дадзеных, родны базы дадзеных XML выкарыстоўваюць індэксы, як спосаб знайсці дадзеныя першапачаткова. Гэта азначае, што пошук дакументаў і фрагментаў дакумента звязана выключна для індэксацыі памеру, а не дакумент памеру або колькасці дакументаў, і што родныя базы дадзеных XML можна знайсці пачатак дакумент або фрагмент так хутка, як іншыя базы дадзеных, выкарыстоўваючы тую ж тэхналогію індэксавання. Такім чынам, родны базы дадзеных XML будзе маштабе, а таксама іншых баз дадзеных у гэтым стаўленні.

Як іерархічных баз дадзеных і ў адрозненне ад рэляцыйных баз дадзеных, многія мясцовыя XML базы дадзеных фізічна спасылку звязаных дадзеных. У прыватнасці, тэкставыя роднай XML базы дадзеных фізічна група дадзеных, звязаных разам, і на аснове мадэлі роднай XML базы дадзеных, якія выкарыстоўваюць уласныя сістэмы захоўвання дадзеных часта выкарыстоўваюць фізічныя паказальнікі на групу звязаных дадзеных. (На аснове мадэляў роднай XML базы дадзеных пабудавана на рэляцыйных базах дадзеных, такіх як рэляцыйныя базы дадзеных самі, выкарыстоўваючы лагічныя сувязі.)

Паколькі фізічныя сувязі хутчэй арыентавацца, чым лагічныя сувязі, родны базы дадзеных XML, такія як іерархічныя базы дадзеных, можа здабываць дадзеныя хутчэй, чым рэляцыйныя базы дадзеных. Такім чынам, яны павінны добра маштабуецца ў дачыненні да вымання дадзеных. На самай справе, яны павінны маштабе нават лепш, чым рэляцыйныя базы дадзеных у гэтых адносінах, так як маштабаванасць, звязаныя з адзінай пачатковай пошуку індэкса, а не некалькі пошукаў патрабуецца рэляцыйная база дадзеных. (Варта адзначыць, што рэляцыйныя базы дадзеных, таксама прапануюць фізічнай звязванне дадзеных, у выглядзе кластарных індэксаў. Аднак такая сувязь прымяняецца да асобных табліцах, а не ўсёй іерархіі.)

На жаль, гэта маштабаванасць абмежавана. Як іерархічных баз дадзеных, фізічнае праводкі ў роднай базы дадзеных XML прымяняецца толькі да пэўнай іерархіі. Гэта значыць, атрыманне дадзеных у іерархіі, у якой яна захоўваецца вельмі хутка, але атрыманне тых жа дадзеных у розныя іерархіі не з’яўляецца. Напрыклад, выкажам здагадку, што інфармацыя аб кліентах захоўваецца ўнутры кожнага дакумента заказу на продаж. Атрыманне дакументаў заказаў будзе вельмі хуткім, так як гэта парадак, у якім захоўваюцца дадзеныя. Атрыманне іншы погляд на дадзеныя, такія як спіс заказаў для дадзенага кліента, будзе значна павольней, так як фізічныя сувязі больш не дзейнічаюць.

Каб вырашыць гэтую праблему, родны базы дадзеных XML шырока выкарыстоўваюць індэксы, часта індэксацыі ўсіх элементаў і атрыбутаў. Хоць гэта дапамагае паменшыць час пошуку, ён павялічвае час абнаўлення, так як падтрыманне такіх паказчыкаў могуць быць дарагімі. Гэта не праблема толькі для чытання асяроддзях, але могуць быць праблемы ў моцна транзакцыйнай асяроддзі.

Нарэшце, родны базы дадзеных XML маштабе значна горш, чым рэляцыйныя базы дадзеных у пошуках неиндексированных дадзеных. Абодва роднай базы дадзеных XML і рэляцыйных баз дадзеных павінны шукаць дадзеныя лінейна ў гэтым выпадку, але сітуацыя нашмат горш, у родных баз дадзеных XML з-за менш поўнай нармалізацыі. Напрыклад, выкажам здагадку, вы хочаце знайсці ўсе заказы на продаж з названай даты і даты, якія не індэксуюцца. У рэляцыйнай базе дадзеных, гэта азначае, прачытаўшы ўсе значэння ў слупку OrderDate. У роднай базе дадзеных XML, гэта азначае, чытанне кожнага дакумента заказаў ва ўсёй яе паўнаце і шукае <OrderDate> элементаў. Мала таго, што ўтрыманне кожнага элемента <OrderDate> чытаць, утрыманне ўсіх іншых элементаў чытаюцца, а таксама. Што яшчэ горш, у тэкставых роднай XML базы дадзеных, тэкст павінен быць разабраны і пераўтворацца ў фармат даты, перш чым яго можна параўнаць з устаноўленага тэрміну.

Такім чынам, будзе маштабаванасць будзе праблемай для вас? Гэта сапраўды залежыць ад вашага прыкладання. Калі ваша прыкладанне звычайна патрабуецца дадзеныя ў прадстаўленне, у якім ён захоўваецца, то родныя базы дадзеных XML, павінны добра маштабуецца. Гэта характэрна для многіх дакумент арыентаваных дакументаў. Напрыклад, дакументы, якія складаюць кіраўніцтва карыстальніка амаль заўсёды быць адноўленая ў поўным аб’ёме. З іншага боку, калі ваша прыкладанне не мае пераважнага гледжання дадзеных, то маштабаванасць можа быць праблема.

На гэтым мы завяршаем апісанне роднай XML-баз дадзеных. У наступных двух раздзелах мы разгледзім две спецыялізаваныя тыпы роднай базы дадзеных XML: ўстойлівыя DOM, і сістэмы кіравання кантэнтам.

6,4 стойкіх заморскіх (PDOMs)

Устойлівымі або DOM PDOM з’яўляецца спецыялізаваным тыпам роднага XML базы дадзеных, якая рэалізуе DOM больш нейкага пастаяннага захоўвання. У адрозненне ад большасці родных баз дадзеных XML, які можа вярнуць дакументы, як дрэвы DOM, DOM дрэва вяртаецца PDOM знаходзіцца пад напругай. Гэта значыць, змены, унесеныя ў дрэва DOM, адлюстроўваюцца непасрэдна ў базе дадзеных. (Ці з’яўляецца змены на самай справе зробленыя неадкладна або ў выніку выкліку здзейсніць метаду залежыць ад базы дадзеных.) У большасці роднай базы дадзеных XML, DOM дрэва вярнуўся ў дадатак копіі, і змены ўносяцца ў базу дадзеных або з дапамогай Мова XML абнавіць або замяніць ўвесь дакумент.

Таму што PDOM дрэвы жывуць, базы дадзеных, як правіла, мясцовы. Гэта значыць, яна знаходзіцца ў тым жа прасторы працэсу, як дадатак, ці, па крайняй меры на адной машыне, хоць гэта і не абавязкова патрабуецца. Гэта робіцца для павышэння эфектыўнасці, як PDOM больш выдаленай базы дадзеных запатрабуе частых зваротаў да выдаленага сервера.

PDOMs служаць той жа ролі для прыкладанняў, DOM, што аб’ектна-арыентаваных баз дадзеных служаць для аб’ектна-арыентаваных прыкладанняў: яны забяспечваюць пастаяннае сховішча для дадзеных прыкладанні, а таксама выступае ў якасці віртуальнай памяці для прыкладанняў. Апошняя роля асабліва важна для прыкладанняў, DOM, якія працуюць з вялікімі дакументамі, як DOM дрэвы могуць лёгка перавысіць XML-дакументаў у памерах у 10 разоў. (Фактычны каэфіцыент залежыць ад сярэдняга памеру тэксту ў дакуменце, з дакументамі, якія змяшчаюць малы сярэдні памер тэксту, якія маюць значна вышэй фактараў).

6,5 Сістэмы кіравання кантэнтам

Сістэмы кіравання кантэнтам з’яўляюцца яшчэ адным спецыялізаваным тыпам роднай базе дадзеных XML. Яны прызначаныя для кіравання дзейнасцю чалавека пісьмовыя дакументы, такія як кіраўніцтва карыстальніка і афіцыйныя дакументы, і пабудаваны на базе роднай базы дадзеных XML. Базы дадзеных, як правіла, схаваныя ад карыстальніка ззаду пярэдняй часткі, якая забяспечвае такія функцыі, як:

Тэрмін сістэма кіравання кантэнтам, у адрозненне ад дакументаў сістэмы кіравання, адлюстроўвае той факт, што такія сістэмы звычайна дазваляюць парушыць вашы дакументы на асобныя фрагменты кантэнту, напрыклад у якасці прыкладаў, працэдур, раздзелаў або бакавых панэляў, а таксама метададзеныя, такія як аўтар імёны, перагляду дат і нумароў дакументаў, замест таго, каб кіраваць кожным дакументам у цэлым. Гэта не толькі спросціць такія рэчы, як, якім чынам каардынаваць працу некалькіх пісьменнікаў, якія працуюць на тым жа самым дакуменце, ён дазваляе сабраць цалкам новыя дакументы з існуючых кампанентаў.

7,0 Прадукты XML базы дадзеных

За апошнюю дату спіс базы дадзеных прадуктаў, якія вы можаце выкарыстоўваць з XML, гл Прадукты XML базы дадзеных.

8,0 Дадатковыя спасылкі

Для спасылкі на розныя XML / рэсурсы базы дадзеных, уключаючы праграмнае забеспячэнне і многае іншае паперы гл. XML / База дадзеных Спасылкі старонцы.

9,0 Каментары і зваротная сувязь

Калі ласка, дасылайце каментары і зваротную сувязь з Рональд Буру на rpbourret@rpbourret.com.

Дзякуючы Малахія дэ Aelfweald, Майкл Чэмпіён, Йорн Клаузен, Джон Коваль, Марк Cyrenne, Кельвін Джын, Марк дэ Graauw, Інга Macherius, Ларс Марцін, Нік Литон, Эван Ленц, Мортэн Примдейл, Майкл Рысь, Уолтар Пэры, Кимбро Staken, Джым Тиви, Філіп Vauclair, Дылан Уолш, Irsan Widarto, а іншыя за іх каментары і цярпенне.

Дзякуй таксама Леанід Чарняк, Раман Уфимцев, Патрык Peccatte і Fang Вэньцзе для іх пераклады гэтага дакумента на рускую, французскую і кітайскі мовы.