Q1.

データ検索についてはXQueryが実質スタンダードになりつつあるように感じられるが、更新については今後W3Cの勧告を待ちつつ、XQuery Updateへと一本化されることになるのか？

全体的な流れはそうであると認識しています。弊社製品に関してはマーケットの要求に応えつつ優先度を考慮し対応していくことになります。【株式会社サイバーテック 白井】

おそらくそうなることでしょう。無論ベンダー毎に若干の拡張は行われると思います。【株式会社ジャストシステム 加藤】

TX1はW3C標準に準じた機能をサポートする方針です。将来XQuery Update Facilityをサポートする予定です。【東芝ソリューション株式会社 松井】

XQuery Update Facility 1.0が、2008年3月14日に勧告候補になっており、2007年10月出荷のDB2 9.5には、その中のTransform式が実装されています。このTransform式は、厳密には勧告候補のmodify()ではなく、modify　do　・・となっていますが、DB2はSQLとXQueryのハイブリッドの利点を利用して、update SQL文のset句（やselect文中）にXQueryのxmlqueryを記述することができます。アプリケーション処理による単純なset句の右辺でのXML列全体の置換とTransform式を比較すると、XML更新処理としてDB2にかなりの部分を任せられるので、総合的に高速なXML列データの更新が可能です。今後XQueryの機能拡張がDB2に実装された場合にどのような実装になるか予想することはできませんが、既に実装されたTransform式が直ちに別な機能に置き換わることはないと考えられます。【日本アイ・ビー・エム株式会社 大沼】

XQuery UpdateがXMLデータ更新系の有力な標準候補であることは間違いないがリリース時期や実装するミドルウェアの対応状況によっては標準化はされたものの実システムでは別手段で更新系を実現するケースが出てくることも考えられる。XQuery Updateで提案されているような、Insert/Delete/Replace/Rename/Transformといった仕様の使い勝手に関しても疑問が残る。（オーバースペックの感がある）【PFUソフトウェア株式会社 松山】

XQuery Updateが主流となる可能性が高いと考える。【XMLDB部会メンバー 飯島（パネリスト）】

Q2．

現在XMLDBは、文書管理や商品管理といった分野で多く利用されているが、昨今では工場などの製造現場においてもXMLデータが利用されることが出てきた。それをふまえて、現状RDB一色の製造現場のシステム（見積りワークフロー、トレーサビリティ、機械の生産実績、データの自動収集など）にもXMLDBが利用されていく可能性はあるか？またあるとすれば、どのような技術課題がクリアされる必要があるか？

製造現場にて弊社製品を採用いただいた実績がございます。技術課題とは異なりますが、導入の際にはお客様側の業務データ整理に時間がかかることが多いです。そこからXML化をしXMLDBに格納という流れになります。XMLDBが持つ構造変更への柔軟性により、弊社製品を使用したシステムリリース後にデータ構造の変更が発生した際もシステムを改修することなく運用いただいております。【株式会社サイバーテック 白井】

製造現場でも図面・ドキュメント管理は行われており、そうしたニーズにXMLDBは応えていくと思われる。例えば生産のトリガーに出図が関わっているケースなどもあり、生産活動と直結しているケースも多く、当然、堅牢性、復旧性が重視される。【株式会社ジャストシステム 加藤】

見積もりワークフローは、設計プロジェクトの管理などと同じように、文書管理/コンテンツ管理の一例と考えます。製造のプロセスは非常に複雑で関連する情報も多様です。弊社の事例では、設計プロセスを1つのXMLで記述し、プロジェクトの進捗やワークフロー、成果物を管理し、成果物についても帳票を中心にXMLにするという方法をとることが多いようです。この分野はXMLDBの成功領域なので特に大きな課題はないと思います。製品のライフサイクルが短縮化され、技術の進歩が速いため、トレースすべき情報もどんどん変化するという状況では、トレース情報をXMLで記述したいというご要望はたくさん頂きます。またトレーサビリティーは従来のロット管理から、一品管理、さらには部品レベルの管理へと詳細化されデータ量が巨大になる傾向にあります。一方でトレースは万一の事故に際して利用されることが多いため、リアルタイムの検索のニーズは少なく、いかにディスクの使用量を減らすかが重要になります。この観点ではXMLはCSVなどと比べるとデータ量が多くなるため、データベース化に際してもRDBの方が有利ではないかと思います。弊社ではXMLの高効率圧縮技術の研究をしており、将来的には柔軟性と高圧縮を両立したデータベースが提供可能と考えています。機械の点検保守情報の収集にXMLが使われている事例は多くあります。ただし、故障診断などで利用した後で蓄積して分析に利用するというところまでできている例は知りません。自動収集される品質情報は複雑なためデータベース化するのが困難であるという理由をよく聞きます。XMLDBはデータの格納はできるのですが、分析という観点では力不足です。現状は確率された分析手法をアプリケーションで実現しています。この領域でのXMLの活用を加速するには、XMLに対するデータマイニングやOLAP技術の発達が必要でしょう。【東芝ソリューション株式会社 松井】

RDFのトリプル集合のように主語、述語、目的語のような汎用の構造表記（RDBのSelfJoinのような構造）で部品表のような階層構造を表現すると、小さくて膨大な量のXMLインスタンスを処理することになり、性能上の課題となり得ますが、既に展開済みの部品表とか、部品記述・仕様記述に関しては、設計自由度や保守容易性、アクセス及び更新性能の面で場合によっては、RDBより良い適合性を、XMLDBは持つ可能性があります。特に、今後長期間のデータ保持が必須となり、スキーマの変更やデータ充填率の低いまばらなデータの格納には、XML列の採用を検討し得ると考えられます。また、製造現場のシステムの全てにおいてXMLDBが最適なわけではなく、RDBが適している部分もあります。XMLDBとRDBの両方を併せ持ち、その両方を適材適所で選択できるハイブリッドDBがこのようなシステムにおいては、適していると考えられます。DB2はそのようなハイブリッドDB機能を実現しております。【日本アイ・ビー・エム株式会社 大沼】

(R/X)DBMSからみたプラント系システムのポイントは、データ量と信頼性にあると考えている。現在利用されているように、設計文書や手順書、チェックリストなどの文書系あるいは、BOMなどの部品管理の利用にはXMLデータをそのまま利用することは今後も利用されていくと思われるが、状態監視や品質管理などの場合にリアルタイムな（かつ単純構造）なデータの場合にはRDBで日々のトランザクションを管理し、ウェアハウス的な集約データをXMLで管理するような分業が考えられる。【PFUソフトウェア株式会社 松山】

RDBをつかったシステムを使用していて業務に支障がなければ、XMLDBをつかったシステムの出番はないかもしれません（そのまま使用されたほうがよいと考えます）。仮に支障があったとして、それがデータ構造の柔軟性、拡張性といったXMLDBのメリットで解決できるのであれば、XMLDBが利用されるのではないでしょうか。例えば、例として挙げられている見積書の承認では、Excelで作成した見積書をワークフローに流すような利用方法もあります。Excelから任意の構造のXMLデータを生成する当社のモジュールを利用して、Excelファイルの中身を項目別にXMLDB化する仕組みです。見積書内の項目を追加削除してもバックエンドのDBはXMLDBなので、テーブルの修正などなくそのまま使い続けることができます。また、医療系では、詳細は申し上げられませんが、電子カルテや検査機器のデータを自動収集し、再利用するシステムの構築も検討しております。【株式会社メディアフュージョン　梅本】

ユビキタスコンピューティングの各機器が持つデータがXMLデータである場合、製造現場にXMLDBが入る可能性が高いと考える。ただし、RDBのリプレースではなく、既存のRDBで管理しているデータのほかにXMLデータが増える。技術課題はストリーミングデータ処理技術と登録性能。【XMLDB部会メンバー 飯島

（パネリスト）】

Q3.

RDBを利用する場合と比較して、XMLDBを利用したほうがシステム構築期間が短くなるという話を聞くが本当か？

ケースバイケースですが、同じか長くなる場合が多いと考えております。XMLDBに精通した技術者が少ないこと、XMLDBを採用する業務ではデータ構造がそもそも複雑であること、運用中のデータ構造変更を想定した開発を行うこと...等があげられます。【株式会社サイバーテック 白井】

ケースバイケース。ウォータフォール型の開発スタイルであればRDBと変わらないだろう。プロトを作りながら要件と仕様を固める反復型開発スタイルなら強みを発揮する。また、処理・管理対象のデータ形式がXMLに確定しているケースであればXMLDBの利用はシステム構築を楽にする。（ただし、ファイル粒度の処理でよいのであれば、必ずしもそうとは言えないが）【株式会社ジャストシステム 加藤】

弊社の事例では、初期構築の段階では、XMLとRDBでコストに大きな違いはありません。システムの機能強化や、パッケージのカスタマイズではRDBと比べて工数を大きく削減できます。また、XMLDBは変更が容易なのでフェーズ開発に向いています。RDBと比べるとより細かいフェーズに分けたリリースができるため、ニーズの強さに応じたスピードで構築することが可能です。【東芝ソリューション株式会社 松井】

極少数の開発人数での短期間の開発プロジェクトの場合、RDBのadd columnでの動的対応や列名のViewによる変更などよりタグ名の追加・変更による直接データを変更するほうが効率が良い場合があります。しかしながら、複数のDB管理者が居り、きちんとXML Schemaを管理する開発プロジェクトでは、XML列を採用することだけにより構築期間が大幅に短縮することはあまり期待できないと思われます。それよりも、開発期間中の仕様の変更や、細部まで仕様を詰めないプロトタイピングのような開発プロジェクトの場合、或いは今後大きく仕様が変化したり法律等で仕様がかなりの頻度で変化するといった将来に渡って変化が予測される開発プロジェクトの場合、XML列で設計することにより将来既に開発されたプログラムの保守と追加要件のプログラムとの間の影響を少なくできたり、新規データ・モデルへの移行が容易になったりすることで、保守ワークロードや追加開発のワークロードや保守開発期間を短縮することが可能になります。【日本アイ・ビー・エム株式会社 大沼】

対象システムに依存することもあり一概には言えないが開発プロセスをシステム稼動までと捕らえた場合、両者のスキルが同じと仮定した場合は、両者に違いはないと思う。ただし、システム稼動後の保守フェーズにおいて、システム変更に伴うデータ構造の変更が発生する場合には、XML(DB)の方が、データ設計変更は容易になることが期待できる。【PFUソフトウェア株式会社 松山】

ケースによると思いますが、XMLDBを利用したほうがシステム構築期間が短くなることはあると思います。すでにXML形式でデータが存在する、データ構造が複雑でテーブル設計に時間がかかる、データ構造がなかなか固まらない（変更が多発する）、といった場合はXMLDBを利用したほうが短期間でシステムを構築することができることがあります。若干お話がそれてしまいますが、システム構築期間を短くする（システム開発コストを小さくする）ため、当社ではデータ登録によくExcel（とExcelから任意の構造のXMLデータを生成するモジュール）を利用します。データを入力するための画面をひとつひとつ作成するとなると、多様なデータ構造を管理する場合、そのデータ構造分の画面が必要になります。当然、その分期間、コストを必要とします。その点、Excelならデータ入力用のフォームを作成することは簡単ですし、前述のモジュールを使えば、簡単にXMLデータを生成するための設定を行うことができます。【株式会社メディアフュージョン　梅本】

システム全体の構築基幹は変わらないと認識している。データ構造検討は短くなるが、性能対策などに時間がかかると思われる。【XMLDB部会メンバー 飯島（パネリスト）】

Q4.

ユーザがXMLDBパッケージを購入した場合、自身で十分な性能を引き出すためのチューニングや設定を行うことはできるのか？

できます。RDBでも言えることだとは思いますが、最適なチューニングを行うためには製品の詳細な理解が必要です。また製品によってチューニング可能な内容も異なります。

最初はベンダーにご相談いただくのがベストと思われます。【株式会社サイバーテック 白井】

製品自体やベンダーのサポートスタンスにもよるが、基本的に可能である。【株式会社ジャストシステム 加藤】

XMLDBでもチューニングの基本は、ディスクへのデータ配置、索引(アクセスパス)の最適化、クエリのチューニングです。データ配置や索引設定はDBMSレベルで可能です。クエリのチューニングについては、カスタマイズ可能なようにパッケージが作成されていることが多いです。【東芝ソリューション株式会社 松井】

DB2の場合、通常のRDBに追加したXML機能なので、基本的なチューニングや設定は、RDB部分と共通となっています。DB2対応されたXMLDBパッケージの場合、今迄のDB2のRDB部分のKnow−Howが十分生かせると考えられます。また、DB2ではユーザのチューニングにかけるワークロードを軽減する仕組みとしてのセルフ・チューニング・メモリー・マネージャー（STMM：DB2が利用する複数のメモリー空間の大きさをDB2自身がチューニングする)や大容量DBでは必須のデータ圧縮などの機能を実装しています。これらの機能は、RDBだけでなく大きなXML文書を格納する可能性の高いXMLDBにおいても非常に有効です。【日本アイ・ビー・エム株式会社 大沼】

XMLDBに限らず、RDBもそうですが、パフォーマンスチューニングはデータ構造やシステム要求によって対処が異なります。従ってパッケージを導入したからといって十分なパフォーマンスを得られるとは限りません。製品の特性に応じた、チューニングは必要です。XMLDBの場合、RDBほどはパフォーマンス・チューニングに関するノウハウやツールが普及していないのも現実です。【PFUソフトウェア株式会社 松山】

当社の製品については、ご自身でチューニングや設定していただいているお客様もいらっしゃいますが、当社へご依頼になる方もいらっしゃいます。正確な数字ではありませんが、前者と後者の比率は同じくらいだと感じます。【株式会社メディアフュージョン　梅本】

一般的なDBにおいては、性能を向上させるためのパラメータを用意している。それらは、インデクス設定、メモリ割り当て、データ構造、問い合わせ式の書き方などであり、これらを適切に設定することによって性能チューニングをする事は可能である。当然、ユーザがこれらパラメータを設定することでチューニングを行う事は可能である。しかし、最適なチューニングをユーザのみで行う事は困難であると考える。最適なチューニングを行う上では、専門家によるサポートが必要と考えている。【XMLDB部会メンバー 飯島（パネリスト）】

Q5.

RDBの世界では常識となっている可用性のしくみはXMLDBにもあるのか？

弊社製品では他社様のミドルウェアと組み合わせることで可用性を実現することができます。【株式会社サイバーテック 白井】

製品による。【株式会社ジャストシステム 加藤】

TX1 では次のように障害に対する対応を提案しています。

・データベース障害(ディスク障害、データの論理障害等)の対策

  ●オンラインバックアップ機能

    DBMSを止めずにバックアップできます

  ●エクスポート/インポート機能

    データの論理バックアップを行います。

    重要なデータなどの部分バックアップも行えます。

・システム障害(サーバ障害)

  クラスタ構成とストレージを利用したシステム構成を推奨します。

  DB はストレージシステムに置き、サーバは複数台でクラスタ構成することを推奨します。

  クラスタシステムでは、弊社ClusterPerfect, VERITAS Cluster Serverとの連携の実績があります。【東芝ソリューション株式会社 松井】

DB2のpureXMLは通常のRDBに追加したXML機能なので、基本的な可用性の仕組みは、RDB部分と共通となっています。故に、DBを止めないでバックアップを取得したり再編成を実行できるといったオンライン・ユーティリティーばかりで無く、対故障性向上や災害対策システム構築用の可用性を向上するHigh Availability機能、他のシステムとの連携機能である連合DB（Federation）やデータの差分コピー機能（Replication）等も利用可能です。【日本アイ・ビー・エム株式会社 大沼】

いわゆるハイブリッドXMLDBは、既存RDBと同じ仕組みを持つ。【XMLDB部会メンバー 飯島（パネリスト）】

Q6.

XMLDBベンダーへの質問です。何故XMLDBMSの製品化を決定されたのか、その背景をお聞かせください。

従来よりXMLDB、OODBを使用した開発を手がけており、構造化モデルを扱うことができ、OODBなどと異なり標準的なXQuery等の問い合わせ言語を用いてデータを２次利用できるXMLDBの可能性を確信したためです。【株式会社サイバーテック 白井】

弊社ではXMLおよびXMLDBの研究を長年行っており、 シーズとなる技術の蓄積がありました。製品を市場に投入するに 際して行った調査によると、米国ではＲＤＢベンダーがＸＭＬ機能を 強化して市場を押さえるので、XMLDB専用製品は特定領域に限られるというものでした。しかし日本では、日本語という特殊のためか市場の構造に違いがありました。そこでＴＸ１には次のような特徴を 持たせることで、製品化することにしました。

１．テラバイト級の大容量データでも高速に検索する。データ量が 増大しても性能が劣化しないことが重要です。特に検索性能に ついて独自の技術で強化をしています。

２．非定形なデータ への対応。どんなに複雑な構造で、データ構造が揃っていなくても、 データの登録と検索が容易に行えるということを意味します。
３．全文検索。ＸＭＬデータにはドキュメント指向のものが多いため タグを指定した中間一致や、複数のタグにまたがったキーワード 検索が高速に簡単に行えることが重要となります。 特に全文検索については東芝が長年培った日本語処理技術を 応用しています 。【東芝ソリューション株式会社 松井】

お客様のお持ちになっているデータの内、既にRDB等に格納されている構造化データは全体の１０−１５％であり、残りの構造化されていないデータの有効活用が、CIOの大きな関心の的になっています。この期待に対応する為の一つの解決法として、提供されたのがDB2のpureXMLによるハイブリッドDBMSです。【日本アイ・ビー・エム株式会社 大沼】

受託開発の中で必要性を感じたこと、日本市場にはまだ製品がなかったことがXMLDBの開発に踏み切ったきっかけです。【株式会社メディアフュージョン　梅本】

お客様のニーズにこたえて。【XMLDB部会メンバー 飯島（パネラー参加）】

Q7.

XMLDBではこれまで性能や大容量対応がアピールされてきたが今後も同じ傾向か？

構造化モデルを有効に扱った開発がされていなかったために、本来XMLの特徴と関係がない、大容量対応等がアピールされてきた面がありますが、今後はXML本来のアピールポイントである構造変更のし易さ、柔軟性が注目されてくると考えております。【株式会社サイバーテック 白井】

今後は、XMLやXMLDBの特性を活かす柔軟なユーザインターフェースへの指向も重要視されるだろう。【株式会社ジャストシステム 加藤】

傾向的には変わりないと思います。どこかで聞いたことがありますが、speed, speed, speedです。【東芝ソリューション株式会社 松井】

XML文書は、一般的にRDBの行レコードより巨大であり、長期間の保存を必要とするので大容量とその検索スピードがアピールされてきました。DB2のpureXMLはそれらに加えて、トランザクショナルXML処理を標榜しています。今後、増加してくるであろうXMLトランザクション・データの領域にも、利用フィールドが拡大していくと考えています。【日本アイ・ビー・エム株式会社 大沼】

今後、下記の点をアピール・強化されることをDBベンダーに期待します。

　1)アプリケーションとの親和性（RubyOnRailsのようなRAD開発への対応）

　2)スケーラビティティ（分散したXMLデータのバイディング）

　3)2とは逆に、SmallFootPrint（SQLiteのようにブラウザ組み込みなど）

【PFUソフトウェア株式会社 松山】

実際に製品の導入を検討する段階では、お客様の課題・要求に対するXMLDBの利用方法、類似事例が気になるところだと思います。当社では、数年前から、製品の性能などについてのアピールよりも、これらの情報をご提供することに注力しており、今後も注力していく予定です。【株式会社メディアフュージョン　梅本】

情報セキュリティの観点が比重を増すと考える。【XMLDB部会メンバー　飯島(パネリスト)】

Q8.

XMLDBの価格はいくらが適正か？

現状の市場規模を考えると現時点では現在の価格が適正と考えております。今後市場規模が拡大すれば変わる可能性はございます。逆にどのくらいの価格帯やライセンス体系であれば、普及が加速されるかといった情報について是非、ベンダー各社にフィードバックいただければと思います。【株式会社サイバーテック 白井】

RDB並になるべきとは思います。【株式会社ジャストシステム 加藤】

現時点で弊社の価格設定は適切だと考えています。将来的にはXMLDBに限らずソフトウェアのライセンスのあり方が大きく変わると思われます。弊社もお客様に納得していただけるライセンスの考え方を随時取り入れていきます。【東芝ソリューション株式会社 松井】

お客様の期待効果によって適正価格は決まりますが、RDBでも十分価格の期待に答えていると考えられますので、XMLでも十分ご期待に答えているし、今できない事を解決できることになるので、価格を超えた効果を得られると確信しております。【日本アイ・ビー・エム株式会社 大沼】

システム規模、可用性のレベルにより変わるため、一概には言えない。【XMLDB部会メンバー 飯島（パネリスト）】

Q9.

データ系のXMLの管理はXMLDB-XQueryの検索で良いと思うのですが、文書系のXMLについては、意味の解釈があいまいな検索が必要と思うので、XQueryの能力外と考えます。これはXMLDBの機能拡張で補うか、新しいアーキテクチャーのDBで扱うべきなのか、どちらが考えられるのでしょうか。

全文検索に関しては現在のXMLDBでも実現できておりますし、今後もXMLDBの機能拡張で補うものと考えております。自由文検索等の検索に関してはそれに特化した製品が出ておりますのでそれと組み合わせて要件を満たすものと考えております。【株式会社サイバーテック 白井】

XMLDBのアーキテクチャは製品によってまちまち。あいまい検索も可能なアーキテクチャのXMLDBもある。一方、別の自然文検索製品を付属して、機能補完しているXMLDBもある。【株式会社ジャストシステム 加藤】

XQuery の全文検索機能拡張言語として、現在、W3C 勧告候補(Candidate　Reccomendation) の XQuery Full Text(XQFT) があります。TX1 では、XQFT のサポートと、XQFT に対しても日本語に特徴的な曖昧検索を行うためのオプション追加を行っています。【東芝ソリューション株式会社 松井】

この課題はRDBの頃から、Likeのような文字検索ではできない事があることが判っており、

DB2でも、全文検索機能（NetSearchExtenderやText Extender）を併用することにより、この機能をRDBの頃から提供してきました。DB2はハイブリッドDBとして、pureXMLに対しても全文検索機能を提供しています。この機能を用いることで、SQL/XMLやXQueryと共に、違和感無く全文検索を行うことができます。【日本アイ・ビー・エム株式会社 大沼】

システム要件、ご予算などによると考えます。「意味の解釈があいまいな検索」が、文字の揺らぎや類義語、専門分野などでの代替語などをシステムが理解したかのように検索できること、だと　　すると、シソーラス（辞書）とそれを利用するための機能が必要になります。シソーラスをXML形式で用意し、XMLDBの機能拡張でそれを利用してもよいでしょうし、外部アプリケーションからXPathやXQueryを発行して利用してもよいと思います。最近の全文検索エンジンではこうしたあいまい検索を得意としているものもありますので、そうしたものを利用する手もあると思います。【株式会社メディアフュージョン　梅本】

XMLDBの拡張機能となる。例えば、既存RDBの全文検索にも表記のゆれを吸収する機能などが拡張されて存在する。これと同様である。【XMLDB部会メンバー 飯島（パネリスト）】

Q10. ハイブリッドXMLDBという分類名をどう考えられますか

・名は体を表わしておりよい

・ハイブリッドは不要、XMLDBでよい

・XMLデータもXMLTypeカラムに入れるデータ項目のひとつ。よってデータベースと単に言うだけでよい

・仲間内では別の名前で呼んでいる。

・その他

名は体を表わしておりよい。ハイブリッドXMLDBとネイティブXMLDBは用途が異なるため、この分類で良いと考えます。【株式会社サイバーテック 白井】

ハイブリッドXMLDBではなく、「ハイブリッドRDB」でしょうね。「XMLネイティブ・ストレージとXQueryもサポートするRDB」という意味です。おっしゃるように、「XMLデータもXMLTypeカラムに入れるデータ項目のひとつ。よってデータベースと単に言うだけでよい」というのも一理あるが、RDB＝Table+SQL　という基本型をXMLのサポートによって、XML専用領域とAPIを大きく増強するはめになった。もはや「XMLは一つのデータタイプだ」と涼しい顔でいられない事態であり、従来のＲＤＢがハイブリットなＲＤＢに進化したといえる。ただ、もしネイティブXMLDB製品が市場から消えたら、「ハイブリッド型」が消えて、また単にRDBと呼ばれるようになるでしょうね。【株式会社ジャストシステム 加藤】

DB2 9が、最初に2006年に発表されてきた時の呼び名がハイブリッドDBなので違和感は感じられませんが、ハイブリッドXMLDBという分類は違和感があります。XMLDB単体と、XMLDBとRDBの複合体であるハイブリッドDBではユーザに提供する価値や使用感が全く異なります。それ故、XMLDBとは別にハイブリッドDBと言うカテゴリーで扱うのが適切だと思います。

しかしながら、RDBをベースにしたpureXMLとのハイブリッドであるので、もしNativeXMLDBにRDB機能が実装された場合、正しくSQL処理ができるようになっていない限り、それをハイブリッドDBと呼ぶのかどうかには、違和感が感じられます。更に、データストアは実質RDBだが表面的にXMLDB機能を提供するものや、その逆にデータストアは実質XMLDBだが表面的にRDB機能を提供するようなものがあった場合に、それらはハイブリッドというべきではなく、RDBのXML機能拡張、XMLDBのRDB機能拡張として、厳密に区別すべきだと思いますし、その方が、ユーザから見たときの誤解をなくすことができると思います。DB2は、XML拡張機能としてXML Extenderを提供してきましたが（pureXMLにもXMLをRDB列に分解する機能を含んでいますが）、そのときにはハイブリッドDBとは呼んでいませんでした。【日本アイ・ビー・エム株式会社 大沼】

ハイブリッドXMLDBでもいいとは思いますが何と何のハイブリッドかが分かり難いですね。XML-RDBとか、XML対応RDBの方が、名は体を表していると思います。【PFUソフトウェア株式会社 松山】

XMLデータもXML Typeカラムに入れるデータ項目のひとつ。よってデータベースと単に言うだけでよい。【XMLDB部会メンバー 飯島（パネリスト）】

Q11.

XQueryについての印象はどうですか？

・標準なのでやむ終えない

・キライ

・より良い物に改良されていくと思う

・少なくとも自社製品ではSQL/XMLが使われると思う。

・データバインディングに期待（O/Xマッピング）

より良い物に改良されていくと思う。

現状でも十分有用なものと考えておりますが、さらに改良されていくものと思います。【株式会社サイバーテック 白井】

XMLDBへのアクセスにおいてXPathこそXML的ですね。一方、XQueryはXML的かな？　ロジックはJavaとかCといった従来の言語で記述してもいいのでは、と個人的に思います。【株式会社ジャストシステム 加藤】

個人的な感想で良いのなら、「キライ」。XMLに比べて、仕様が大き過ぎます。他の言語と同様にどんどん肥大化していくのでは。TX1 では標準に準拠しつつ、ユーザの要求に即してサポート範囲等を決めていきたいと思います。【東芝ソリューション株式会社 松井】

XQueryでないとXML処理ができないわけではなく、ハイブリッドの効果をだすためにもSQL/XMLとの複合利用が必要と思われます。ただ、一種のプログラミング能力を持ったXQueryは、万人向きではないよう一面を持っていますので、今後の標準の拡張に期待したいと思っています。【日本アイ・ビー・エム株式会社 大沼】

より良い物に改良されていくと思う。

理由：RDBを意識しすぎている感があるため、XQuery自身がXMLでないため　【PFUソフトウェア株式会社 松山】

より良い物に改良されていくと思う。【XMLDB部会メンバー 飯島（パネリスト）】

Q12.

データベースとしては、セキュリティは大切な要素と考えられます。見せてよい項目、更新の可/不可（参照のみさせたい）などのコントロールはXMLDBの場合、どのように実現されているのでしょうか？やはりAP側で考慮する（作りこむ）のでしょうか？

弊社製品(NeoCore)の場合はデータベースの機能として実現しております。【株式会社サイバーテック 白井】

製品による。【株式会社ジャストシステム 加藤】

TX1 では、パス指定で、要素レベルまでのアクセス権をユーザごとに設定できます。課題は検索性能とセキュリティーの両立です。今のところ両立できないので、パス指定での要素レベルのセキュリティ設定に留めています。XMLDB でのセキュリティ機能として、例えば、<level>タグとユーザの権限を比較するとか、<acl>タグとユーザIDを比較するといった、内容に応じたセキュリティ設定も考えられると思います。　【東芝ソリューション株式会社 松井】

DB2はハイブリッドDBですので、あくまでもRDBの機能の拡張としてXML列が実装されています。それ故、１XML列の中の要素のセキュリティ機能（ACLや暗号化）は、実装されていません。DB2の機能を利用して実装するには、Viewを利用して特定のUser向けのTransform式やXSLTRANSFORMを実行するしかありません。トランザクショナルXML処理を標榜しているので、これらのオーバーヘッドが気になりますが、今後に期待したいと思っております。【日本アイ・ビー・エム株式会社 大沼】

当社のお客様では、アプリケーション側でアクセスコントロールを実現されています。XMLデータ内の属性（attribute）にコントロール用の値を持たせることが多いように感じます。【株式会社メディアフュージョン　梅本】

DB側での制御が有効。AP毎にアクセス権制御機構を作りこむのは大変である。【XMLDB部会メンバー 飯島（パネリスト）】

Q13.

データ構造の柔軟性がITにとって、本当にメリットか？

はい、そのように考えておりますし、データ構造の柔軟性を具体的に理解いただけるデモをお客様に対して行うと、多くのお客様に可能性を感じていただけております。【株式会社サイバーテック 白井】

柔軟性は必要です。

柔軟性が必要となる典型的な例としては以下の2つがあります。

１．複数のユーザの意見を調整すると、無難な要件定義となってしまって、本当に必要なデータベースが構築できない。

２．世の中の変化への対応。

一方で、柔軟なデータ構造を使いこなすためのガイドや仕組み、標準化の整備、教育等が必要と考えます。【東芝ソリューション株式会社 松井】

開発期間中の仕様の変更や、細部まで仕様を詰めないプロトタイピングのような開発プロジェクトの場合、或いは今後大きく仕様が変化したり、法律等で仕様がかなりの頻度で変化するといった、将来に渡って変化が予測される開発プロジェクトの場合、XML列で設計することにより、将来既に開発されたプログラムの保守と追加要件のプログラムとの間の影響を少なくできたり、新規データモデルへの移行が容易になったりすることで、保守ワークロードや追加開発のワークロードや保守開発期間を短縮することが可能になります。この意味でのデータ構造の柔軟性はITにとってメリットになると考えております。変化の無いデータモデルでは、強いてデータ構造の柔軟性が必要になるかどうか不明です。【日本アイ・ビー・エム株式会社 大沼】

柔軟性を必要としない場合もあるでしょうから、どのようなところでもメリットとなるとは思いません。ただ、メリットとなるところもあると思います。【株式会社メディアフュージョン　梅本】

データの形式や項目が頻繁に変わる業務に対応する業務システムでは、システム変更が容易であり、メリットとなる。【XMLDB部会メンバー 飯島（パネリスト）】

Q14.

設計ノウハウや利用メリットなどをユーザにどのように指導していますか？

弊社マーケティング活動を通して設計ノウハウ、利用メリットを啓蒙しております。また案件提案時や導入支援を通してユーザ様の支援をしております。【株式会社サイバーテック 白井】

どのプロジェクトでも、XML, XMLDB についての教育の時間を作ってもらっています。また、プリセールスエンジニアがコンサルティングを行っています。それでも、XMLの開発効率の良さで、プロジェクト全体でのコストアップにはなりません。【東芝ソリューション株式会社 松井】

XMLの開発経験やIBMとのXML案件の協業を実施しているXML Innovation Center（XIC)のBusiness　Partner様と一緒に設計ノウハウの共有やお客様への情報提供を実施しております。

XIC -　http://www.ibm.com/jp/software/data/xic/

【日本アイ・ビー・エム株式会社 大沼】

設計ノウハウについては、当社製品の教育プログラムを持っており、その中で開発会社様などにお伝えしています。実際に設計を当社と共同で行い、ノウハウをお伝えすることもあります。利用メリットについては、事例を例にご説明したり、実際に抱えていらっしゃる課題をヒアリングし、それがどのように解決されるかをご説明しています。【株式会社メディアフュージョン　梅本】