出力されるリストラクチャリングビューの動的な変更
今日使われている大部分のXML変換は静的なものであるため、最終的なXML構造に特定の値を含めるか除外させる場合には、そのための変更を事前に施しておかなくてはなりません。これに対してSQLベースの変換では静的なXMLフォーマッティング用の処理を必要としませんが、それは動的なSELECTリストを用いることで、図4に示したような単純かつ動的なデータアイテム出力の取り込みや除外が行えるためです。
具体的な処理としては下記のようなSQLクエリを用いることになります。
SELECT EmpID, DpndID, Invoice, Address FROM Transform
このクエリについてはSELECTにてCustノードを取り込んでいない点に注意してください。これによりCustノードが排除され、その位置にInvoiceおよびAddrノードがプロモーションされるという、変換済み構造に対してのさらなる変更が施されます。こうした動的なSELECTリストはクエリごとに変更でき、その際にTransformationビューに組み込む変換ロジックを修正する必要はありません。つまりこの方式を用いれば、操作性と柔軟性と再利用性を有す、非常に強力な動的変換が行えるのです。
レッグ順の変更とノードの複製
次のサンプルでは（図5を参照）、図1に示したオリジナルのStoreViewデータ構造を基にして、各種の変換を施しています。図5におけるStoreViewビューを構成しているのは、CustViewとEmpViewの2つのビューです。ここでの変換処理で行う作業は、各ノードを分離することでStoreViewからCustViewを抽出することです。その次に行うのはCustビューの再構成で、その際には結合（join）の実行順を変更することでAddrとInvoiceのレッグ（leg）の順番を意図的に変更していますが、これが機能するのは、この構造が上から下および左から右の方向に構成されているためです。これがどのような変更となるかは、サンプルの構造図を比較することで確認してください。
SELECT Cust.custid, Invoice.invid, Invoice.invcustid, Addr.addrid,
Addr.addrcustid, invoice2.invid NewInv
FROM Storeview Cust
LEFT JOIN StoreView Addr ON Cust.custid=Addr.addrcustid
LEFT JOIN StoreView Invoice ON Cust.custid=Invoice.invcustid
LEFT JOIN StoreView Invoice2 ON Addr.addrcustid=Invoice2.invcustid
EmpViewとCustviewデータの組み合わせで生じる複製データは、出力データがXML化される際に自動的に取り除かれます。またこの変換では、追加ノードのInvoiceを選択して、図5におけるAddrノードの下に配置するようにしています。
先に見たリストラクチャリングのサンプルでは、フラグメントを用いてデータの移動を行っていました。それに対してこのサンプルでは、ノードレベルでの処理を行っています。ノードレベル方式は詳細な制御を施せる反面、フラグメント方式は一般的に扱いが簡単であり、またノードレベルにはない重要な機能が利用できます。通常、1つのグループに属すノード群は最適化された構造にまとめられているケースが多く、再結合に使用可能な値（外部キーなど）が当該グループ中に残されていない場合があります。そうした際のソリューションとなるのがフラグメント方式であり、次のサンプルで見るようにこの方式では、移動対象を変化させることなく1つのグループとして操作できるのです。
