Когда ХМL-данные не используются

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

· При естественном разбиении данных в реляционной структуре на таблицы, строки и столбцы.

· Если необходимо обновить только некоторые части, а не весь документ.

Преобразование данных из формата SQL в формат XML и наоборот

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

Преобразование наборов символов

В языке SQL поддержка наборов символов зависит от его реализации. Это означает, что приложение DB2 производства компании IBM может поддерживать наборы символов, которые не поддерживаются приложением SQL Server компании Microsoft. SQL Server, в свою очередь, поддерживает наборы символов, которые не поддерживаются приложением Oracle. Несмотря на то что большинство общих наборов символов практически всегда универсально поддерживается тем или иным приложением, использование мало распространенных символов может усложнить перемещение вашей базы данных и приложения с одной платформы реляционной СУБД (РСУБД) на другую.

У XML нет никаких проблем совместимости с наборами символов, поскольку он поддерживает только один набор – Unicode. Этот универсальный набор символов, публикуемый консорциумом Unicode Consortium, представляет собой стандартный набор символов для компьютеров, в котором каждому письменному знаку на любом языке присвоен определенный номер. С точки зрения обмена данными между любыми реализациями языка SQL и XML это очень хорошо. Поставщики РСУБД должны описать преобразование строк из каждого набора символов в символы Unicode и обратное преобразование символов Unicode в строки, состоящие из наборов символов. К счастью, XML не поддерживает множество наборов символов, что освобождает поставщиков от большого количества проблем, связанных с бесчисленными преобразованиями символов.

Преобразование идентификаторов

В отличие от SQL, XML более точно подходит к определению идентификаторов. Прежде чем стать частью XML-документа, символы, допустимые в SQL и недопустимые в XML, должны быть соответствующим образом преобразованы. SQL поддерживает неограниченные идентификаторы. Это означает, что все виды добавочных символов, такие как %, $ и &, будут допустимыми до тех пор, пока они заключены в двойные кавычки. Но такие символы не допустимы для XML. Кроме того, имена в XML, начинающиеся с символов XML, в любых комбинациях уже зарезервированы и, таким образом, не могут использоваться без каких-либо негативных последствий. Именно поэтому идентификаторы SQL, начинающиеся с этих символов, должны быть изменены.

При преобразовании из SQL в XML все идентификаторы конвертируются в Unicode. Любые же идентификаторы языка SQL, которые являются также допустимыми именами XML, остаются неизменными. Символы идентификатора языка SQL, не допустимые для имен XML, заменяются шестнадцатеричным кодом. Полученный результат имеет форму записи типа "_хНННН_" или "_xНННННННН_", где Н– шестнадцатеричный разряд верхнего регистра. Например, символ подчеркивания "_" будет представлен как "_x005F_". Двоеточие– как "_х003А_". Эти представления являются кодами для описания в системе Unicode таких символов, как подчеркивание и двоеточие. В случае, если идентификатор SQL начинается с символов х, т или /, перед такими символами необходимо поставить префикс с кодом в форме "_xFFFF_".

Преобразовать символы из XML-формата в SQL-формат гораздо проще. Все, что для этого необходимо сделать, – это развернуть символы XML-имени в последовательность "_XFFFF_" или "_XFFFFFFFF_". Всякий раз, когда вы находите такую последовательность, заменяйте ее символами, соответствующими символам Unicode. Если же имя XML начинается с символов "_XFFFF_", игнорируйте их.

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

Преобразование типов данных

В SQL:2003 определено, что данные типа SQL преобразуются в наиболее близкую схему XML-данных. Формулировка " наиболее близкая " означает, что все значения, допустимые для SQL-типа, будут допустимы и для типа XML-схемы, а наименее возможные значения, не допустимые для SQL-типа, будут допустимы для типа XML-схемы. Элементы XML, такие как maxlnclusive и minlnclusive, могут ограничивать значения, допускаемые типом XML-схемы, до значений, допускаемых соответствующим SQL-типом. Например, если тип SQL-данных Ограничивает значения типа INTEGER в диапазоне значений от -2157483648 до 2157483647, в XML значение minlnclusive может быть задано числом – 2157483648.

Ниже приведен пример такого преобразования.

<xsd:simpleType><xsd:restriction base="xsd:integer"><xsd:maxlnclusive value="2157483647"/><xsd:minlnclusive value="-21574 83648"/><xsd:annotation><sqlxml:sqltype name="INTEGER"/></xsd:annotation></xsd:restriction></xsd:simpleType>

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

Преобразование таблиц

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

<CUSTOMER><row><FirstName>Abe</FirstName><LastName>Abelson</LastName><City>Springfield</City><AreaCode>714</AreaCode><Telephone>555-llll</Telephone></row><row><FirstName>Bill</FirstName><LastName>Bailey</LastName><City>Decatur</City><AreaCode>714</AreaCode><Telephone>555-2222</Telephone></row>...</CUSTOMER>

Основной элемент документа дал имя таблице (CUSTOMER). Каждая строка таблицы содержится в пределах элемента <row> (в данном примере таких строк две). Кроме того, каждая строка таблицы содержит последовательность элементов столбца (атрибутов), каждый из которых получает имя после связывания со столбцом в исходной таблице (столбцы FirstName, LastName, City, AreaCode, Telephone). Каждый элемент столбца содержит значение данных.