Програмування на XML для DB2: Частина 1. Розуміння моделі даних XML (исходники), Unix, Операційні системи, статті

Введення


Як зазначено в рекомендаціях w3, Деякі цілі створення XML мають відношення до розробки додатків:



Поки багато уваги приділялося читаності, сериализации і транспортуванні, завдання розробки додатків не наробила стільки галасу.


Дана стаття є першою в серії статей, що показує вплив, який справив XML на розробку додатків, на трьох рівнях:



Основи моделі даних в XML


Традиційно XML використовували для визначення метаданих бізнес-документів. Для управління цими метаданими в додатку використовується об’єктна модель документа (document object model, DOM). Якщо ми подивимося на DOM, то побачимо, що вона забезпечує об’єктний інтерфейс для ієрархічної структури даних XML, а програмний інтерфейс DOM керує цією ієрархією. Іншими словами, DOM можна використовувати як об’єктну оболонку для управління будь-якою структурою даних, яка може бути представлена ​​за допомогою XML.


В XML-моделі даних багато об’єктів даних програми визначаються на XML. Так як XML має ієрархічну структуру, легко зрозуміти взаємозв’язок між об’єктами даних в природному, зручному для читання форматі.







 



Зауваження:
Якщо ваші дані вже представлені в XML-форматі, то залишився процес буде природним і дуже простим. Навіть якщо дані представлені в реляційному форматі, ви все одно можете використовувати запропоновану методику, але потрібно взаємно однозначне перетворення реляційних даних в XML. Для цього можна використовувати SQL / XML-функції публікації і нарізки. Більшість реляційних баз даних підтримують ці функції поряд з іншими технологіями перетворення. Для більшості розробників перетворення реляційних даних в ієрархічні (XML) тільки заради використання моделі даних XML в розробці додатків може здатися непотрібним. Але, будучи розробниками, ми весь час це робимо, коли перетворимо реляційні дані до об’єктним. Можливо, переваги моделі даних XML спонукають багатьох розробників задуматися над використанням цієї технології в розробці додатків, навіть якщо в бізнес-моделі не потрібні XML-дані.
 

Коли модель даних XML визначена, DOM-парсер може її обробити в додатку. Щоб ізолювати код програми від API DOM, який використовується для навігації і управління XML-моделлю, ви можете створити оболонку навколо реалізацій DOM і XPath. Ця оболонка також зробить ваш код більш стерпним.


Я доклав до даної статті приклад Java-оболонки. Ви можете використовувати його як готовий варіант або як шаблон для своєї власної оболонки. Бізнес-логіка програми безпосередньо керує моделлю XML за допомогою API-оболонки. Змінені XML-дані можна легко серіалізовать і передавати між різними об’єктами або різними рівнями в багаторівневих середовищах (SOA).


Порівняння моделі даних XML і об’єктної моделі


Більшість додатків складається з бізнес-об’єктів, керованих ієрархіями об’єктів даних. У загальному випадку об’єкти даних – це тонкі оболонки бізнес-даних. Їх головна мета полягає в тому, щоб керувати поданням упакованих даних бізнес-об’єктів. Ще одна перевага оболонок для об’єктів полягає в тому, що вони дозволяють представляти дані, що зберігаються в реляційних таблицях, у природній ієрархії об’єктів, де можна зафіксувати взаємозв’язок між даними. Велика частина зусиль, що витрачаються на написання коду, йде на створення таких об’єктних оболонок для додатків з бізнес-даними.


Так як XML по своїй суті підтримує взаємозв’язок структур даних, то не має сенсу створювати окрему ієрархію об’єктів, щоб зафіксувати взаємозв’язок між окремими структурами даних. Крім того, у XML є стандартна об’єктна модель – DOM (об’єктна модель документів). Реалізації цієї моделі застосовуються для конструювання, зміни і сериализации XML-даних. Грамотне використання мови XPath спільно з програмними інтерфейсами DOM робить задачу завантаження, зміни та збереження XML-даних в бізнес-додатках тривіальною.


Наочний приклад


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


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


Об’єктна модель даних


У підході з об’єктною моделлю даних нам спочатку треба створити оболонку об’єктів, щоб інкапсулювати замовника (customer) і дані замовлення (order data), див листинги 1, 2 і 3.


Лістинг 1. Створення замовника





public class Customer
{
int customerid;
String firstname;
String lastname;
Items itemspurchased ;
Public Customer (int custid, Connection conn)
{
Statement dbstmt= conn.createStatement();
ResultSet dbResult = dbstmt.executeQuery(“select fname, lname from
customer_table where customerid=custid”);
customerid=custid;
SetFirstName(dbResult.getString(1));
SetLastName(dbResult.getString(2));
}
public String GetFirstName {return firstname;}
public Void SetFirstName (fname) {firstname=fname;}
public String GetLastName {return lastname ;}
public Void SetLastName (lname) {lastname=lname;}
public Items GetItemsList {return itemspurchased; }
public SetItemsList (list) { itemspurchased =list;}
}

Лістинг 2. Створення класу items (покупки)





public class Items
{
Hashtable list=new Hashtable();
Public Items(int custid,Connection conn)
{
Statement dbstmt= conn.createStatement();
ResultSet dbResult = dbstmt.executeQuery(“select itemid, description,
price, date from purchase_table where customerid=custid”)
While (dbResult.rs.next ())
{
tempitem = new Item();
tempitem.SetID(dbResult. getString(1));
tempitem. SetDescription (dbResult. getString(2));
tempitem. Setprice (dbResult. getFloat(3));
tempitem. SetpurchaseDate (dbResult. getString(4));
Additem (tempitem);
}
}
public void AddItem (item oneitem) {list.put(oneitem.GetID(),oneitem);}
public Item GetItem (ItemID) {return list.get(String itemID);}
public Hashtable GetItems(){return list;}
public Items FindItemByPrice (flaot min, float max)
{
Items retList=new Items();
for (Enumeration e=list.elements () ; e.hasMoreElements() ; )
{
item tmpItem=(item)e.nextElement();
float price= tmpItem .GetPrice();
if(price >= min && price <=max)
{
retList.AddItem(tmpItem);
}
}
}
public Items FindItemByDate (purchaseDate) { }
}

Лістинг 3. Створення визначення item (купівля)





public class Item
{
String id;
String description;
String purchaseDate;
Float price;
Public void SetID (String ItemID) {id= ItemID;}
Public void SetDescription (String desc) { description = desc;}
Public void SetpurchaseDate (String pDate) { purchaseDate = pDate ;}
Public void Setprice (float pprice { price = pprice ;}
Public String GetID (){return id;}
Public String GetDescription(){return description;}
Public float GetPrice(){return price;}
}

Цей об’єкт даних можна використовувати в програмі, щоб управляти іншими даними.


Лістинг 4. Управління об’єктами даних у додатку





Customer customer = new Customer (custid,dbConnection)
customer.SetItemList (new Items(custid , dbConnection)) ;
Items list=customer.GetItemsList(). FindItemByPrice(15.0,25.50);
for (Enumeration e=list.elements () ; e.hasMoreElements() ; )
{
System.out.println(((item)e.nextElement()).GetDescription());
}

З представлених прикладів ми бачимо, що код для об’єктів даних експоненціально більше, ніж код, що описує бізнес-логіку. Так як оболонка об’єктів приховує взаємозв’язку між ув’язненими в ній бізнес-даними, необхідно, щоб API оболонки об’єкту були добре задокументовані, щоб розробники додатків розуміли, як правильно їх використовувати.


Просте переміщення між ієрархіями об’єктів вбудовано в об’єктну модель даних, але розширені засоби пошуку і переміщення доводиться реалізовувати для кожного критерію пошуку (наприклад, FindItemByPrice) окремо.


Модель даних XML


Оскільки головним мотивом до використання оболонок об’єктів була інкапсуляція бізнес-даних, їх можна замінити моделлю даних XML.


Лістинг 5. Модель даних XML





<Customer customerid =”” firstname=”” lastname=”” >
<Items>
<Item ID=”” description=”” purchaseDate=”” price=”” />
</Items>
</Customer>

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



– Все, що нам треба зробити для будь-якого заданого покупця – це взяти його XML і додати його в список запитуваних покупок.


Давайте перепишемо код програми з використанням моделі XML для зберігання інформації про покупця і покупках. Щоб створити екземпляр цієї моделі даних XML і керувати ним, ми будемо використовувати клас DOM-оболонки XMLParser. Його можна завантажити в розділі “файли для завантаження”.


Перший випадок – Дані зберігаються в базі даних в форматі XML


Лістинг 6. Переписування додатки з використанням моделі XML





1. Statement dbstmt= conn.createStatement();
2. ResultSet dbResult = dbstmt.executeQuery(“select custXML from
customer_table where customerid=custid”);
3. XMLParse customerXML = new XMLParse(dbResult. getString(1));
4. customerXML.appendNode(“/Customer”, customerXML.createNode (“<Items/>”))
5. dbResult = dbstmt.executeQuery(“select itemXML from purchase_table
where customerid=custid”);
6. While (dbResult.rs.next ()) {
7. Node itemnode= customerXML.createNode (dbResult. getString(1));
8. customerXML.appendNode(itemnode ,”/Customer/Items”,false);
}
9. customerXML.find(“/Customer/Items/item[@price>15.0 and @price <25.5]”,true);
10. for(int i=0;i < customerXML.currentFind.getLength();i++) {
11. System.out.println(customerXML.getValue(“@description”,i));
}

Перший запит (другий рядок) повертає XML-дані в стовпці custXML для заданого покупця. Ця XML-рядок посилається в конструктор DOM-оболонки (третій рядок), який, в свою чергу, за допомогою XML-парсера обробляє ієрархію об’єктів, представлену XML-даними.


Зауваження: Так як у покупця (customerXML) немає жодної покупки, тобто жодного елемента Items (бо ми так визначили в XML-схемі для нашої моделі), ми створюємо новий елемент Items (четвертий рядок) і приєднуємо його як дочірній елемент до Customer.



Результат другого запиту (п’ятий рядок) повертає з бази даних список покупок, придбаних покупцем (в XML-форматі). Кожна покупка в списку (сьома рядок) прикріплюється (восьма рядок) до ієрархії об’єктів в DOM з шляхом Customer / items.


Нарешті, за допомогою XPath ми шукаємо всі покупки в заданій цінової категорії (дев’ята рядок) в ієрархії об’єктів DOM і виводимо опис кожної знайденої покупки (десята рядок).



Другий випадок – Всі дані зберігаються в реляційній базі даних


Так як дані зберігаються не в XML-форматі, нам треба буде зробити всередині запиту перетворення з використанням SQL / XML-функцій публікації.


Лістинг 7. Перетворення з використанням SQL / XML-функцій публікації





1. Statement dbstmt= conn.createStatement();
2. ResultSet dbResult = dbstmt.executeQuery(“select xmlelement( name “Customer” ,
xmlattributes(customerid as “customerid” ),
xmlattributes(fname as “firstname” ),
xmlattributes(lname as “lastname” )
) from customer_table where customerid=custid”);
3. XMLParse customerXML = new XMLParse(dbResult. getString(1));
5. dbResult = dbstmt.executeQuery(“select xmlelement( name “items” ,
xmlelement( name “item” ,
xmlattributes(itemid as “id” ),
xmlattributes(description as “description” ),
xmlattributes(price as “price” ),
xmlattributes(date as “purchaseDate” )
)
) from purchase_table where customerid=custid”);
6. if (dbResult.rs.next ()) {
7. Node itemsnode= customerXML.createNode (dbResult. getString(1));
8. customerXML.appendNode(itemsnode ,”/Customer”,false);
}
9. customerXML.find(“/Customer/Items/item[@price>15.0 and @price <25.5]”,true);
10. for(int i=0;i < customerXML.currentFind.getLength();i++) {
11. System.out.println(customerXML.getValue(“@description”,i));
}

Незважаючи на те, що в нашій базі не було XML, ми за допомогою SQL створили XML-представлення реляційних даних для нашого застосування. Також ми додали зовнішній елемент items, одночасно створюючи XML-елемент items в запиті. Все, що нам залишилося зробити – це додати покупку в форматі XML до покупця в тому ж форматі. Частина програми залишається без змін.


Переваги використання моделі XML перед “чистою” об’єктною моделлю


Оболонки об’єкта даних займають більшу частину коду програми, фактично відволікаючи увагу від бізнес-логіки для управління об’єктами даних. Крім того, цей додатковий код тягне:



Використовуючи методології XML-програмування, можна виключити всю ієрархію об’єктів з оболонкою, дозволивши програмістам приділити більше уваги бізнес-логіки, а не структурі бізнес-даних. XML дає такі переваги при програмуванні:



Проблеми і рішення при адаптації до XML-моделі


Якщо реляційні дані не зберігаються в XML, то їх необхідно перетворити в цей формат. Процес перетворення є громіздким, незважаючи на те, що багато постачальників подбали про необхідний інструментарій. Однак з введенням підтримки “чистого” XML в такі сервери баз даних, як DB2 і Microsoft SQL Server, відпала необхідність у перетворенні і нарізці XML-даних для зберігання в реляційних таблицях. Дані, які зберігаються в XML, за допомогою і XQuery та XML-індексів можна знаходити і повертати в цілості в додаток таким же чином, як ви могли б повернути з бази даних великий символьний об’єкт.


Якщо дані зберігаються в базі даних як чистий XML, для створення XML-запитів треба розуміти призначення функцій SQL / XML і xQuery. Щоб зменшити витрати на перехід на XML-запити, почніть з простого XPath замість складних запитів XQuery.


Процес вивчення та професійного освоєння інтерфейсів DOM та їх реалізацій, а також навігації та пошуку в ієрархії XML з використанням XPath може виявитися складним завданням. Використовуйте допоміжний клас (helper class), прикріплений до даної статті, щоб зменшити необхідність безпосередньо викликати інтерфейси DOM. Цей допоміжний клас обволікає інтерфейси DOM і представляє більш природні API, ніж містяться в коді. Він володіє необхідною функціональністю для обробки і сериализации XML-моделі і для пошуку та зміни даних або метаданих в примірнику XML. Цей клас-оболонка також реалізує XSL-перетворення, простору імен і перевірку на відповідність схемі, якщо це необхідно.


Пряме вбудовування викликів DOM API в бізнес-логіку додатка нераціонально, так як будь-яка зміна в XML-схемі вимагає великих змін в коді програми. Багато виклики API використовуються для переміщення по ієрархії, і це знижує читаність коду. Дані об’єкта, за яким здійснюються навігація і пошук, не такі явні, як в оболонці об’єкта, визначеної користувачем. Наш клас-оболонка виключає необхідність вбудовувати виклики DOM API в бізнес-логіку. Оскільки клас-оболонка переміщується по DOM за допомогою XPath, будь-які зміни у схемі, що впливають на код програми, вимагають зміни тільки в рядках XPath API-викликів оболонки з програми. Завдяки тому, що XPath показує місце положення розглянутого вузла в ієрархії XML, читаність коду програми виявляється дуже високою.


Висновок


Пряме вбудовування викликів DOM API в бізнес-логіку додатка нераціонально, так як будь-яка зміна в XML-схемі вимагає великих змін в коді програми. Багато виклики API використовуються для переміщення по ієрархії, і це знижує читаність коду. Дані об’єкта, за яким здійснюються навігація і пошук, не такі явні, як в оболонці об’єкта, визначеної користувачем. Наш клас-оболонка виключає необхідність вбудовувати виклики DOM API в бізнес-логіку. Оскільки клас-оболонка переміщується по DOM за допомогою XPath, будь-які зміни у схемі, що впливають на код програми, вимагають зміни тільки в рядках XPath API-викликів оболонки з програми. Завдяки тому, що XPath показує місце положення розглянутого вузла в ієрархії XML, читаність коду програми виявляється дуже високою.


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


В ідеалі дані повинні зберігатися в базі даних як чистий XML, але навіть якщо дані знаходяться в реляційних таблицях, все одно у багатьох випадках варто відразу перетворити їх в XML, щоб потім працювати з ними в додатку.


Якщо структури даних, упакованих всередині ієрархії об’єктів, можуть бути перетворені з використанням XML, і якщо головною метою ієрархії об’єктів є управління і відображення структур цих даних в бізнес-логіку, то ієрархію об’єктних оболонок даних можна замінити моделлю DOM.


У другій частині даної серії ви навчитеся адаптувати архітектуру XML-додатків до своїх програм в DB2.


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


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

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

Ваш отзыв

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

*

*