Décomposition d’un document XML en données relationnelles

a.    dans une arborescence sous forme de fichier (dans l’IFS) en les référençant dans DB2 avec des DataLink
b.    dans une  base de données  relationnelle sous la forme de LOB
c.    dans une base de données XML native
d.    dans une  base de données relationnelle sous la forme de tables : Cette technique est appelée  « le Schredding ». Voir figure 10.

C’est de ce dernier point que nous allons traiter, c’est-à-dire la possibilité de décomposer un document XML en colonnes dans une ou plusieurs tables de façon à préserver la fidélité des données au niveau relationnel (bien que l’ordre des éléments soit ignoré).

Dans quel but ? Par exemple, le désir d’accéder aux données avec des ordres de lecture natifs (STELL/READ, CHAIN etc..) permettant ainsi à vos applications existantes d’accéder à des données XML. Voir tableau 1.

Le concept de « Shredding » est illustré en figure 11. Dans cet exemple, le document XML possède un nom de client, son adresse et des numéros de téléphone. Etant donné la multiplicité des numéros de téléphone, il faudra décomposer ce flux dans deux tables distinctes de type Entête/Détail, avec une table pour les clients et une table pour les numéros de téléphone.

On comprend tout de suite la complexité et la limite du « Shredding » dans ce genre d’exercice surtout si le client possède, tels les numéros de téléphone, de multiples e-mails, plusieurs commandes, plusieurs articles par commande, chaque article possédant plusieurs libellés etc… Le nombre de tables cibles dans la base de donnée relationnelle pourrait croître exponentiellement et malheureusement ce genre de structure, telle que je viens de vous citer, n’est pas rare en XML.

Pour réaliser ce « mapping », le XML Schéma, qui sera encapsulé dans un XSR, doit être annoté d’informations supplémentaires. Puis il faudra appeler la procédure XDBDECOMPXML afin de procéder à la décomposition du document XML dans les différentes tables cibles.

Prenons l’exemple d’une ligne de notre XSD :

<xs:element name= »street » type= »xs:string » minOccurs= »1″/>

On peut lire ici que l’élément « street » est type type « xs :string » et cet élément doit être renseigné au moins une fois. On peut ajouter une annotation  à la définition de cet élément afin qu’il soit mappé dans la colonne STREET de la table ADDRESS. Cette annotation consiste à rajouter deux attributs supplémentaires comme dans l’exemple du listing 1.

Il est aussi possible de faire ce mapping avec des éléments plutôt que des attributs. En figure 10, un XSD annoté pour une décomposition du flux dans nos deux tables et
un exemple plus complet de mapping entre notre document XML et nos deux tables en figure 12.

Si vous décidez de faire du « Shredding » entre un document XML et une ou plusieurs tables, gardez bien à l’esprit que les modèles de données entre ces deux entités sont fondamentalement différentes, modèle hiérarchique pour le premier et relationnel pour le second. Tenter de faire le lien entre ces deux modèles relève d’une gymnastique complexe voire parfois impossible.