Comment cartographier SQL à XML et XML pour SQL

Pour échanger des données entre les bases de données SQL et des documents XML, les différents éléments d'une base de données SQL doivent être traduisible en éléments équivalents d'un document XML, et, bien sûr, vice-versa.

Les jeux de caractères

Dans SQL, les jeux de caractères supportés dépendent de la mise en œuvre que vous utilisez. Cela signifie que DB2 d'IBM peut soutenir les jeux de caractères qui ne sont pas pris en charge par SQL Server de Microsoft. Si vous utilisez un jeu de caractères moins fréquente, la migration de votre base de données et l'application d'une plateforme à l'autre SGBDR peut être difficile.

XML ne supporte qu'un seul, Unicode. Ceci est une bonne chose du point de vue de l'échange de données entre toute mise en œuvre de donnée SQL et XML. Tous les fournisseurs de SGBDR doivent définir un mappage entre les chaînes de chacun de leurs jeux de caractères et Unicode, ainsi que d'une cartographie inverse à partir de Unicode à chacun de leurs jeux de caractères.

Heureusement, XML ne fonctionne pas aussi plusieurs jeux de caractères. Si elle le faisait, les fournisseurs auraient un many-to-many problème qui exigerait plusieurs autres applications et de correspondances inverses à résoudre.

Identifiants

Personnage qui sont légales dans SQL mais illégale en XML doivent être mappés à quelque chose de légal avant qu'ils puissent faire partie d'un document XML. SQL supporte les identificateurs délimités. Cela signifie que les personnages étranges tels que%, $, et sont légales, tant qu'ils sont enfermés à l'intérieur des guillemets. Ces caractères ne sont pas légaux en XML.

En outre, les noms XML qui commencent par les caractères XML dans toute combinaison des cas sont réservés et ne peuvent donc pas être utilisé en toute impunité. Si vous avez des identifiants SQL qui commencent par ces lettres, vous devez les changer.

En passant de SQL pour XML, tous les identifiants SQL sont converties en Unicode. De là, tous les identificateurs SQL qui sont aussi des noms XML juridiques sont laissés inchangés. Caractères d'identification SQL qui sont des noms de XML non juridiques sont remplacés par un code hexadécimal qui soit prend la forme “ _xNNNN_ ” ou “ _xNNNNNNNN_ ”, où N représente un chiffre hexadécimal majuscule.

Par exemple, le trait de soulignement sera représentée par “ _x005F_ ”. Le côlon sera représentée par “ _x003A_ ”. Ces représentations sont les codes pour les caractères Unicode pour le trait de soulignement et du côlon. Le cas où un identifiant SQL commence par les caractères x, m, et l est géré par le préfixe de tous ces cas avec un code dans le formulaire “ _xFFFF_ ”.

Conversion à partir de XML à SQL est beaucoup plus facile. Tout ce que vous devez faire est de numériser les caractères d'un nom de XML pour une séquence de “ _xNNNN_ ” ou “ _xNNNNNNNN_ ”. Chaque fois que vous trouvez une telle séquence, le remplacer par le caractère que l'Unicode correspond à. Si un Nom XML commence par les caractères “ _xFFFF_ ”, ignore les.

Les types de données

Le standard SQL spécifie qu'un type de données SQL doit être mappé sur le possible type de données XML Schema plus proche. La désignation le plus proche possible signifie que toutes les valeurs autorisées par le type de données SQL seront autorisés par le type de schéma XML, et les valeurs moins possible non autorisés par le type SQL seront autorisés par le type de schéma XML.

Facettes XML, tels que maxInclusive et minInclusive, peut restreindre les valeurs autorisées par le type de schéma XML pour les valeurs autorisées par le type SQL correspondant.

Par exemple, si le type de données SQL restreint valeurs de la ENTIER taper à la gamme -2157483648, dans le XML maxInclusive La valeur peut être réglée à 2157483647 et la minInclusive valeur peut être réglée à -2157483648. Voici un exemple d'une telle cartographie:

Tableaux

Vous pouvez mapper une table pour un document XML. De même, vous pouvez mapper toutes les tables dans un schéma ou toutes les tables dans un catalogue. Les privilèges sont maintenus par la cartographie. Une personne qui a le SELECT privilège uniquement sur certaines colonnes de la table sera en mesure de cartographier uniquement les colonnes du document XML.

La cartographie produit en fait deux documents, l'un contenant les données de la table et l'autre qui contient le schéma XML décrivant le premier document. Voici un exemple de la cartographie d'une table SQL à un document contenant des données XML:

AbeAbelsonSpringfield714555-1111FactureMur d'enceinteDecatur714555-2222...

L'élément racine du document a été donné le nom de la table. Chaque ligne du tableau est contenue dans un élément, et chaque élément de ligne contient une séquence d'éléments de colonnes, chacune nommée d'après la colonne correspondante dans la table source. Chaque élément de la colonne contient une valeur de données.

Les valeurs NULL

Parce que les données SQL pourraient inclure des valeurs nulles, vous devez décider comment les représenter dans un document XML. Vous pouvez représenter une valeur nulle soit comme nul ou absent. Si vous choisissez l'option zéro, alors l'attribut xsi: nil = “ true ” marque les éléments de colonne qui représentent des valeurs nulles. Il peut être utilisé de la manière suivante:

FactureMur d'enceinte714555-2222

Si vous choisissez l'option absente, vous pourriez mettre en œuvre comme suit:

FactureMur d'enceinte714555-2222

Dans ce cas, la ligne contenant la valeur NULL est absent. Il n'y a aucune référence à elle.

Comment générer du XML Schema

Lors du mappage de SQL à XML, le premier document généré est celle qui contient les données. La deuxième contient les informations de schéma. Considérons le schéma du document de CLIENT:

Ce schéma est approprié si l'approche nul à NULL manutention est utilisé. L'approche absent exige une définition de l'élément légèrement différente. Par example: