Введение

Очень важно постоянно анализировать свое предприятие, рассматривая, какого рода данными нужно управлять, и соответственно обновлять эти данные. XML удобен своей гибкостью, но чтобы сделать данные надежными, важно определить структуру и процессы обработки XML-данных на основе этой структуры. Для определения структуры используется XML-схема.

В результате процесса бизнес-анализа XML-схема обновляется (развивается). Вот типичные сценарии развития XML-схемы.

• Развитие XML-схемы (совместимость снизу вверх).
  XML-схема развивается, оставаясь совместимой с существующей XML-схемой. Таким образом, имеющиеся XML-данные соответствуют новой XML-схеме без изменения XML-данных.
• Развитие XML-схемы (без совместимости) и преобразование XML-данных.
  XML-схема развивается, но не остается совместимой с существующей XML-схемой. Существующие XML-данные преобразуются в соответствии с новой XML-схемой.
• Развитие XML-схемы (без совместимости) и управление XML-данными без преобразования.
  XML-схема развивается, но не остается совместимой с существующей XML-схемой. Существующие XML-данные не преобразуются, и управление ими осуществляется с помощью существующей XML-схемы.

В этой статье рассматриваются перечисленные сценарии.

В начало

Развитие XML-схемы (совместимость снизу вверх)

XML-схема развивается, оставаясь совместимой с существующей XML-схемой. Таким образом, имеющиеся XML-данные соответствуют новой XML-схеме без изменения XML-данных.

Например, в этой статье используется следующая простая информация о клиентах. Существующая XML-схема приведена в листинге 1. А в листинге 2 приведен пример XML-данных, соответствующих этой схеме.

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust1.xsd">
    <name>cust1</name>
    <address>address1</address>
    <phone>11-2222-3333</phone>
    <email>cust1@sample.com</email>
</customer>

XML-схема из листинга 1 зарегистрирована с помощью следующих команд. (О регистрации XML-схем и импортировании XML-данных говорилось в первой части этого цикла статей: "Управление XML-схемами в DB2. Часть 1: Управление XML-схемами и проверка данных XML" (см. раздел Ресурсы).

Примечание. Команды DB2 нечувствительны к регистру. Местоположение XML-схем и данных чувствительно к регистру. Чувствительно ли к регистру физическое место, такое как '/work/customer1.xsd', зависит от используемой операционной системы. (Windows® нечувствительна к регистру. Linux® и UNIX® чувствительны к регистру.)

REGISTER XMLSCHEMA 'cust1.xsd' FROM '/work/cust1.xsd' AS SAMPLE2.CUST1;
COMPLETE XMLSCHEMA SAMPLE2.CUST1;

Следующие команды создают таблицу T1 и импортируют XML-данные, приведенные в листинге 2, в таблицу T1.

CREATE TABLE T1 (ID INT NOT NULL PRIMARY KEY, XMLDATA XML NOT NULL);
IMPORT FROM /work/cust1.del of del XML FROM /work 
   XMLVALIDATE USING SCHEMA SAMPLE2.CUST1 INSERT INTO T1;

Файл cust1.del, используемый в приведенной выше команде IMPORT, содержит следующую информацию. В столбце ID установлено значение 1.

1, "<XDS FIL='cust1.xml'/>"

Следующий SQL-оператор получает идентификатор объекта XML-схемы, реляционный ID и местоположение схемы, используемой для проверки каждой записи из таблицы T1. Он использует внешнее соединение, так что результат содержит как непроверенные записи, так и записи, проверенные по XML-схемам, от которых уже отказались.

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    65020719620281344 SAMPLE2      CUST1        cust2.xsd

  1 record(s) selected.

Предполагается, что элемент phone в примере XML-данных – это номер домашнего телефона клиента. Теперь к XML-данным можно добавить номер сотового телефона.

Можно определить новую XML-схему, которая остается совместимой с существующей XML-схемой. Для этого не будем менять существующие элементы, а добавим новый элемент номера сотового телефона (cell-phone) и сделаем добавленный элемент опциональным (minOccurs="0"). См. листинг 3.

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="cell-phone" minOccurs="0" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

Зарегистрируем XML-схему из листинга 3 с помощью следующих команд.

REGISTER XMLSCHEMA 'cust2.xsd' FROM '/work/cust2.xsd' AS SAMPLE2.CUST2;
COMPLETE XMLSCHEMA SAMPLE2.CUST2;

XML-схема cust2.xsd совместима со схемой cust1.xsd, так что cust1.xsd можно заменить на cust2.xsd.

Для этого выполним следующую команду UPDATE XMLSCHEMA.

UPDATE XMLSCHEMA SAMPLE2.CUST1 WITH SAMPLE2.CUST2;

Эта команда заменяет схему cust1.xsd, зарегистрированную с использованием реляционного ID SAMPLE2.CUST1, на cust2.xsd.

В листинге 4 приведен пример XML-данных, соответствующих новой XML-схеме.

<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust1.xsd">
    <name>cust2</name>
    <address>address2</address>
    <phone>22-3333-4444</phone>
    <cell-phone>090-4444-5555</cell-phone>
    <email>cust2@sample.com</email>
</customer>

Выполним следующую команду, чтобы вставить XML-данные в таблицу T1 после их проверки по XML-схеме с реляционным ID SAMPLE2.CUST1. Она будет успешной.

IMPORT FROM /work/cust2.del of del XML FROM /work
   XMLVALIDATE USING SCHEMA SAMPLE2.CUST1 INSERT INTO T1;

Файл cust2.del, используемый в приведенной выше команде IMPORT, содержит следующую информацию. В столбце ID установлено значение 2.

2, "<XDS FIL='cust2.xml'/>"

Следующий SQL-оператор снова показывает, по какой XML-схеме проверен каждый набор XML-данных.

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    65020719620281344 SAMPLE2      CUST1        cust2.xsd
          2    65020719620281344 SAMPLE2      CUST1        cust2.xsd

  2 record(s) selected.

XML данные с идентификационным номером 2 проверяются по новой XML-схеме. Как показывает полученный результат, ID объекта не изменился даже после обновления XML-схемы. Проверенные XML-данные (в этом примере — XML-данные с идентификационным номером 1) соответствуют и новой XML-схеме.

Реляционный ID тоже не изменился, но местоположение схемы теперь соответствует местоположению новой XML-схемы. Следующий SQL-оператор получает реляционный ID и местоположение для каждой зарегистрированной XML-схемы.

db2 => SELECT OBJECTID,
              substr(OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(OBJECTNAME,1,12) OBJECTNAME,
              substr(SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM SYSCAT.XSROBJECTS;

OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
-------------------- ------------ ------------ ----------------
   65020719620281344 SAMPLE2      CUST1        cust2.xsd
   66857945295662336 SAMPLE2      CUST2        cust2.xsd

  2 record(s) selected.

Как показывает результат, обе записи указывают на одно и то же местоположение схемы. В этой ситуации XML-данные не проверены с использованием местоположения схемы. Приведенная ниже проверка XML-данных с использованием местоположения схемы cust2.xsd не удается, так как невозможно сказать, какая из XML-схем с местоположением cust2.xsd используется.

db2 => INSERT INTO T1(ID, XMLDATA) VALUES (22, 
XMLVALIDATE(XMLPARSE(DOCUMENT 
'<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust2.xsd">
    <name>cust2-2</name>
    <address>address2-2</address>
    <phone>33-4444-5555</phone>
    <cell-phone>090-5555-6666</cell-phone>
    <email>cust2-2@sample.com</email>
</customer>'))
);
DB21034E  Команда была обработана как SQL-оператор, поскольку это не допустимая команда 
процессора командной строки. В результате SQL-обработки она возвратила:
SQL16196N.  XML-документ содержит неправильно определенный элемент customer.  
Код причины = "37"  SQLSTATE=2200M

Если удалить одну из XML-схем, как показано ниже, то приведенный выше оператор INSERT выполнится успешно.

DROP XSROBJECT SAMPLE2.CUST2;

Таким образом, после замены существующей XML-схемы на новую эту новую XML-схему необходимо удалить. Для этого можно использовать опцию DROP NEW SCHEMA команды UPDATE XMLSCHEMA.

UPDATE XMLSCHEMA SAMPLE2.CUST1 WITH SAMPLE2.CUST2 DROP NEW SCHEMA;

Другая особенность заключается в том, что местоположение схемы тоже меняется. В результате местоположение схемы, указанное в существующих XML-данных, не соответствует действительности. Эту проблему можно решить, зарегистрировав новую XML-схемус с существующим местоположением, как показано ниже.

REGISTER XMLSCHEMA 'cust1.xsd' FROM '/work/cust2.xsd' AS SAMPLE2.CUST2;
COMPLETE XMLSCHEMA SAMPLE2.CUST2;

Затем опять обновим XML-схему с опцией DROP NEW SCHEMA.

UPDATE XMLSCHEMA SAMPLE2.CUST1 WITH SAMPLE2.CUST2 DROP NEW SCHEMA;

В этом случае местоположение схемы можно использовать при проверке XML-данных даже после замены XML-схемы.

Если XML-схема развивается как совместимая с существующей XML-схемой, существующими XML-данными можно управлять с помощью новой XML-схемы без изменений. С другой стороны, чтобы сохранить совместимость снизу вверх, недавно добавленные элементы и атрибуты должны быть факультативными, так что их существование проверить нельзя, даже если вновь добавленная информация будет обязательной. (В приведенном выше примере добавлен элемент cell-phone. Но он добавлен как факультативный, так что XML-данные без элемента cell-phone тоже успешно пройдут проверку.) О других требованиях для улучшения совместимости можно узнать в Информационном центре по DB2 и из статьи "Развитие XML-схем с использованием DB2 pureXML" на DeveloperWorks. См. раздел Русурсы.

В начало

Развитие XML-схемы (без совместимости) и преобразование XML-данных

При этом сценарии XML-схема развивается без сохранения совместимости с существующей XML-схемой. Существующие XML-данные преобразуются, чтобы соответствовать новой XML-схеме.

В листинге 5 в элемент phone добавляются элементы home и cell, которые управляют соответственно домашним и сотовым телефонами клиентов. Соответствующая XML-схема приведена в листинге 6.

<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust3.xsd">
    <name>cust3</name>
    <address>address3</address>
    <phone>
      <home>44-5555-6666</home>
      <cell>090-6666-7777</cell>
    </phone>
    <email>cust3@sample.com</email>
</customer>

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="phoneType"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:complexType name="phoneType">
        <xs:sequence>
            <xs:element name="home" type="xs:string"/>
            <xs:element name="cell" type="xs:string"/>
        </xs:sequence>
    </xs:complexType>
</xs:schema>

XML-схема и XML-данные (листинги 5 и 6) зарегистрированы и импортированы, как показано ниже.

REGISTER XMLSCHEMA 'cust3.xsd' FROM '/work/cust3.xsd' AS SAMPLE2.CUST3;
COMPLETE XMLSCHEMA SAMPLE2.CUST3;
IMPORT FROM /work/cust3.del of del XML FROM /work
   XMLVALIDATE USING SCHEMA SAMPLE2.CUST3 INSERT INTO T1;

Файл cust3.del, используемый в приведенной выше команде IMPORT, содержит следующую информацию. В столбце ID установлено значение 3.

3, "<XDS FIL='cust3.xml'/>"

Следующий SQL-оператор снова показывает, по какой XML-схеме проверен каждый набор XML-данных.

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    65020719620281344 SAMPLE2      CUST1        cust1.xsd
          2    65020719620281344 SAMPLE2      CUST1        cust1.xsd
         22    65020719620281344 SAMPLE2      CUST1        cust1.xsd
          3    68398419340809216 SAMPLE2      CUST3        cust3.xsd

  4 record(s) selected.

XML-данные с идентификаторами 1, 2 и 22 соответствуют XML-схеме cust2.xsd из листинга 3. (В листинге 3 XML-схема с использованием реляционного ID SAMPLE2.CUST1 заменена на схему cust2.xsd, которая зарегистрирована с тем же местоположением, что и cust1.xsd.)Эти наборы XML-данных, чтобы они соответствовали cust3.xsd, необходимо изменить следующим образом.

1. Элементы home и cell нужно добавить в /customer/phone.
2. Значение /customer/phone меняется на /customer/phone/home.
3. Если определен путь /customer/cell-phone, значение переносится в /customer/phone/cell, а /customer/cell-phone удаляется.
4. Значение атрибута xsi:noNamespaceSchemaLocation меняется на cust3.xsd. (Этого не требуется, если при проверке XML-данных используется реляционный ID.)

Выполним следующий SQL-оператор, чтобы применить указанные выше изменения к XML-данным, проверенным по XML-схеме с использованием реляционного ID SAMPLE2.CUST1, и проверим измененные XML-данные по XML-схеме с использованием местоположения схемы cust3.xsd.

UPDATE T1
SET XMLDATA=XMLVALIDATE(XMLQUERY(
 'declare namespace xsi="http://www.w3.org/2001/XMLSchema-instance";
  copy $new := $XMLDATA
  modify (
    do replace $new/customer/phone with 
      <phone>
        <home>{$new/customer/phone/text()}</home>
        <cell>{$new/customer/cell-phone/text()}</cell>
      </phone>,
    do replace value of $new/customer/@xsi:noNamespaceSchemaLocation with "cust3.xsd",
    do delete $new/customer/cell-phone )
  return  $new'))
WHERE XMLXSROBJECTID(XMLDATA)=(SELECT OBJECTID FROM SYSCAT.XSROBJECTS WHERE
OBJECTSCHEMA='SAMPLE2' AND OBJECTNAME='CUST1')

Следующий SQL-оператор снова показывает, по какой XML-схеме проверен каждый набор XML-данных. Результат указывает на то, что все записи подтверждаются XML-схемой с использованием местоположения cust3.xsd.

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    68398419340809216 SAMPLE2      CUST3        cust3.xsd
          2    68398419340809216 SAMPLE2      CUST3        cust3.xsd
         22    68398419340809216 SAMPLE2      CUST3        cust3.xsd
          3    68398419340809216 SAMPLE2      CUST3        cust3.xsd

  4 record(s) selected.

Выполним следующий SQL-оператор, чтобы увидеть ID и XML-данные в таблице T1.

SELECT ID, XMLSERIALIZE(XMLDATA AS VARCHAR(500)) FROM T1;

Пространство имен можно добавить или изменить с помощью оператора UPDATE, но необходимо преобразовать все элементы. Если cust3.xsd в листинге 6 имеет пространство имен "http://www.sample.com/customer3", работает следующий оператор UPDATE.

UPDATE T1
SET XMLDATA=XMLVALIDATE(XMLQUERY(
 'declare namespace xsi="http://www.w3.org/2001/XMLSchema-instance";
  declare namespace cust="http://www.sample.com/customer3";
  copy $new := $XMLDATA
  modify (
    do replace $new/customer with 
      <cust:customer xsi:schemaLocation="http://www.sample.com/customer3 cust3.xsd">
        <cust:name>{$new/customer/name/text()}</cust:name>
        <cust:address>{$new/customer/address/text()}</cust:address>
        <cust:phone>
          <cust:home>{$new/customer/phone/text()}</cust:home>
          <cust:cell>{$new/customer/cell-phone/text()}</cust:cell>
        </cust:phone>
        <cust:email>{$new/customer/email/text()}</cust:email>
      </cust:customer> )
  return  $new'))
WHERE XMLXSROBJECTID(XMLDATA)=(SELECT OBJECTID FROM SYSCAT.XSROBJECTS WHERE
OBJECTSCHEMA='SAMPLE2' AND OBJECTNAME='CUST1')

В начало

Развитие XML-схемы (без совместимости) и управление XML-данными без преобразования

При этом сценарии XML-схема развивается без сохранения совместимости с существующей XML-схемой. Существующие XML-данные не преобразуются, и управление ими осуществляется с помощью существующей XML-схемы. DB2 может содержать разные типы XML-данных в одном и том же столбце.

Этот сценарий требует, чтобы приложение обрабатывало каждый набор XML-данных по своей XML-схеме.

Выше упоминалось о проблеме развития XML-схемы при сохранении совместимости снизу вверх, когда новые элементы и атрибуты невозможно проверить. В данном случае они проверяются. И если существующие элементы и атрибуты не изменились, одна и та же программа может использоваться с различными XML-схемами. (Но нужно рассмотреть тот случай, когда значения вновь добавленных элементов и атрибутов получить невозможно.)

В примере на рисунке 1 приложение хранит пары идентификаторов объектов XML-схемы и их версии. Это те версии, которые уже присваивались, и структура XML (то есть XML-схема) каждой версии известна. В качестве указателя версии можно использовать реляционный ID или местоположение схемы. При получении XML-данных приложение получает также ID объекта XML-схемы. Затем приложение определяет XML-схему по версии, связанной с ID объектом схемы, и обрабатывает XML-данные в соответствии с их версией.

В примере на рисунке 2 приложение идентифицирует XML-схему, используемую для XML-данных, по значению из другого столбца (в данном примере - дата создания). При получении XML-данных приложение извлекает также данные из столбца для определения XML-схемы и обрабатывает XML-данные по этой схеме. На рисунке 2 приложение ведет таблицу, в которой реляционный ID ставится в соответствие диапазону дат создания. Вместо реляционного ID для определения XML-схемы можно использовать местоположение схемы или что-то вроде номера версии.

Вместо проверки XML данных с помощью функции/опции XMLVALIDATE посредством операторов INSERT/UPDATE или команды IMPORT можно использовать триггеры. Следующие операторы CREATE TRIGGER предназначены для проверки XML-данных оператором UPDATE по XML-схеме с реляционным ID SAMPLE2.ORDER2008, если значение столбца CREATION_DATE равно или превышает 2008-01-01 (Листинг 7), и по XML-схеме с реляционным ID SAMPLE2.ORDER2002, если значение столбца CREATION_DATE находится между 2002-01-01 и 2007-12-31 (листинг 8). То же можно сделать для оператора INSERT, на который также влияет команда IMPORT. Существует команда LOAD, аналогичная команде IMPORT. Хотя команда LOAD не активизирует триггер, она имеет опцию XMLVALIDATE с таким же синтаксисом, как у команды IMPORT.

CREATE TRIGGER UPDATE_ORDER2008 NO CASCADE BEFORE UPDATE ON SAMPLE2.ORDER
  REFERENCING NEW AS N
  FOR EACH ROW
  WHEN (N.CREATION_DATE >= '2008-01-01')
   BEGIN ATOMIC
   SET (N.XMLDATA) = XMLVALIDATE(N.XMLDATA ACCORDING TO XMLSCHEMA ID SAMPLE2.ORDER2008);
   END

CREATE TRIGGER UPDATE_ORDER2002 NO CASCADE BEFORE UPDATE ON SAMPLE2.ORDER
  REFERENCING NEW AS N
  FOR EACH ROW
  WHEN (N.CREATION_DATE < '2008-01-01' AND N.CREATION_DATE >= '2002-01-01')
   BEGIN ATOMIC
   SET (N.XMLDATA) = XMLVALIDATE(N.XMLDATA ACCORDING TO XMLSCHEMA ID SAMPLE2.ORDER2002);
   END

В начало

Заключение

Если XML-схема развивается как совместимая с существующей XML-схемой, существующими XML-данными можно управлять с помощью новой XML-схемы без изменений. Даже после развития XML-схемы можно использовать реляционный идентификатор или местоположение схемы для определения XML-схемы, используемой для проверки XML-данных. Однако при использовании местоположения схемы после замены существующей XML-схемы новой новая XML-схема должна быть удалена. Кроме того, при регистрации новой XML-схемы перед заменой существующей XML-схемы ее необходимо зарегистрировать в том же месте, что и существующая XML-схема.

Проблема развития XML-схемы с сохранением совместимости снизу вверх заключается в том, что при наличии вновь добавленных элементов и атрибутов XML-данные невозможно проверить. Другая проблема – XML-данные, скорее всего, будут плохо отражать новые требования, что чревато ошибками. Для решения этих проблем приходится развивать XML-схему без сохранения совместимости с существующей XML-схемой. Существуют два сценария такого развития: преобразование существующих XML-данных для достижения совместимости с новой XML-схемой и управление XML-данными как есть с помощью соответствующей им XML-схемы.

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Оригинал статьи(EN).
  
  
• Управление XML-схемами в DB2. Часть 1: Управление XML-схемами и проверка данных XML (Масахиро Окава, developerWorks, февраль 2010 г.): первая статья этого цикла, посвященная тому, как управлять XML-схемами и проверять данные XML с помощью местоположения схемы и реляционного ID.
  
  
• Информационный центр IBM DB2 9.7 для Linux, UNIX и Windows : дополнительные сведения о развитии схем и использовании команд DB2. (EN)
  
  
• Изменение зарегистрированных объектов XSR: дополнительную информацию по регистрации XSR-объектов можно получить в Информационном центре DB2.(EN)
  
  
• Эволюция схем XML: прочтите этот раздел Информационного центра DB2, чтобы узнать больше. (EN)
  
  
• Команда REGISTER XMLSCHEMA: дополнительная информация об этой команде в документации по DB2. (EN)
  
  
• Команда UPDATE XMLSCHEMA: описание синтаксиса команды в Информационном центре DB2.(EN)
  
  
• Представление каталога SYSCAT.XSROBJECTS: дополнительная информация в Информационном центре DB2. (EN)
  
  
• Скалярная функция XMLXSROBJECTID: читайте об этой функции в Информационном центре DB2.(EN)
  
  
• Функция XMLVALIDATE : дополнительная информация об этой функции в документации по DB2.(EN)
  
  
• Команда IMPORT: дополнительная информация о команде IMPORT в документации по DB2.(EN)
  
  
• Обработка XML-данных с помощью триггеров: раздел Информационного центра DB2 с дополнительной информацией об использовании триггеров для обработки XML-данных.(EN)
  
  
• Руководство по pureXML DB2 9: информация о хранилище данных pureXML, проектировании и администрировании гибридной базы данных в IBM Redbook. (EN)
  
  
• Evolving your XML schemas using DB2 pureXML (Khurram Faraaz, Ronny Bartsch, Susan Malaika; март 2008 г.): как использовать репозиторий XML-схем для управления изменением XML-схем с течением времени (EN).
  
  
• Preserving XML queries during schema evolution (Mirella Moura Moro, Susan Malaika, Lipyeow Lim; июнь 2007 г.): руководство по составлению запросов, которые хорошо ведут себя при изменении XML-схемы (EN). Эта статья расширяет таксономию изменений, которым можно подвергать XML-схему в процессе ее эволюции. Кроме того, в ней рассматривается влияние этих изменений на процесс проверки (прямой и обратной) и оценки запросов.
  
  
• Update XML in DB2 9.5 (Matthias Nicola and Uttam Jain, developerWorks, октябрь 2007 г.): XQuery Update Facility позволяет изменять, вставлять и удалять отдельные элементы и атрибуты XML-документов. Статья посвящена новой функциональности XML XQuery Update Facility и содержит примеры типовых операций обновления XML, помогая избежать распространенных ошибок. (EN)
  
  
• Начните с IBM DB2 Express-C: посетите главную страницу DB2 Express-C. (EN)
  
  

Об авторе

Масахиро Окава (Masahiro Ohkawa) входит в состав группы разработки инструментов для работы с базами данных лаборатории Yamato Software Development Laboratory (YSL), IBM Japan.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Развитие XML-схемы (совместимость снизу вверх)
• Развитие XML-схемы (без совместимости) и преобразование XML-данных
• Развитие XML-схемы (без совместимости) и управление XML-данными без преобразования
• Заключение
• Ресурсы
• Об авторе
• Комментарии