RDBとXML DBで格納できるデータの違いを理解しよう

RDBは、正規化された表の中にデータを格納します。XMLデータも格納する事は出来ますが、検索パフォーマンス低下やXMLの特長である柔軟性や拡張性を損なう事があります。
ある程度のXMLデータをハンドリングする際は、専門特化したXMLデータベース(XML DB)の方がパフォーマンス面では有利です。

XMLデータベースとは?RDBとどこが違うの?

XML DBとは、XMLのタグと階層構造を分解せず、そのまま格納できるXMLのハンドリングに特化したデータベース製品のことです。ここではRDBとの違いやXML DBの得意分野を解説します。

XMLデータベースって何?

XMLドキュメントは、タグに値の意味を持ち、階層構造を表現しています。 XMLデータベースとは、単純に言えば、タグ、階層構造を分解せずに、XMLをそのまま格納できる「XMLのハンドリングに特化したデータベース製品」のことです。高い柔軟性を持つXMLフォーマットのデータをそのままの構造で格納し、データ更新・構造変更・高速検索を可能にした、次世代の情報基盤を担うデータベースソフトウェアです。

つまり、XMLデータベースとは、以下の3つが大きな特長です。

  • XMLのハンドリングに専門特化したデータベース(XMLのハンドリングは重い処理)
  • データモデルがツリー型のみ(テーブルの概念を持たず、柔軟性に富む)
  • Xpath/XQueryをサポートしている(テーブルを持たないため、SQLは不要)

※注:リレーショナルデータベース(RDB)にもXML型が扱えるように機能拡張した製品があり、「ハイブリッドデータベース」と分類される事もありますが、テーブル型アーキテクチャがベースであるため、XMLデータベースとは異なります。

RDBとどこが違うの?

XMLで表現されたデータを現在の主流RDBに格納しようとすると厄介なことになってきます。XMLドキュメントを分解し、RDBのテーブル構造とXMLドキュメントの階層構造を複雑にマッピングしなければならず、パフォーマンスの低下や開発効率の低下につながってしまうからです。

XML/XML DBのサイバーテック:RDBはXMLとテーブル形式の間でマッピングが必要

一方、XMLデータベースではXMLドキュメントをそのままの形で格納し、利用することができます。これにより複雑なマッピング処理が不要になり、高いパフォーマンスを保ったままでの検索や開発効率の向上が可能になるのです。

XML/XML DBのサイバーテック:XMLの階層構造をそのまま格納・利用できるXMLデータベース

企業の中では、データモデルの追加や変更が日常的なeビジネス、あるいは構造の未確定な紙情報をとりあえず電子化する場合など、スピードと柔軟性の求められる情報系システムにおいてXMLデータベース(XML DB)は大きな威力を発揮します。

XML DBの得意なところは?苦手なところは?

RDBが現在のような高いシェアを獲得できたのは、信頼性、堅牢性、高速性、利便性など、さまざまな面で優れていたからと言えます。もちろん、今でも十二分にそのメリットは発揮されていますし、RDBがXMLデータベースに劣るというわけでもありません。しかし、速断性や即応性が切に要求される現在のビジネス環境においては、RDBでは対応しきれないという現実もあります。

RDBには、まず厳密なスキーマを決定してからデータを格納するという大前提があります。テーブルやフィールドをどのように構成するかという設計を確定するまでは、それ以後の開発に取りかかることもできないのです。これは、あまり変更されることがない基幹系ならともかく、めまぐるしく変化するeビジネスなどにおいては致命的な遅れになりかねません。

これに対しXMLデータベースでは、データ構造をいつでも自由かつ容易に更新することが可能です。そのため、とりあえずデータベースを作成してアプリケーションの開発(あるいは運用)に取りかかり、必要に応じてダイナミックにデータモデルを変更するといった柔軟な使い方ができるのです。データモデルの追加や変更が日常的なeビジネス、あるいは構造の未確定な紙情報をとりあえず電子化する場合など、スピードと柔軟性の求められるシーンにおいてXMLデータベースは大きな威力を発揮するのです。

逆に、基幹システムや会計システムのような変化しない、または変化を望まない定型データについては、RDBを利用するのが良いでしょう。

RDBとXMLデータベースの違い

  RDB XML DB
データ構造 表/ER(テーブル) 階層/ツリー
検索文 SQL Xpath、XQuery
格納するデータの構造 定型的 半定型的
データ型定義の必要性 必須 なくても良い
(スキーマにて定義可能)
データスキーマの必要性 必須 なくても良い
スキーマ構造変更時にかかる
データベースの変更コスト
高い ほぼゼロ
大量データの高速な一括処理 強い 若干弱い
ビジネスロジック変更時にかかる改修コスト(DB側) 高い 最小で済む
ビジネスロジック変更時にかかる改修コスト(PG側) 相応の工数が必要 最小限の工数で済む

御相談、ご質問はこちら

サービスご案内資料や、特別資料「マニュアル作成の効率化とコストダウンを実現するポイントとは? 」がダウンロードできます。

最新事例の公開情報や、イベント・セミナー情報をお届けします。

pagetop ボタン
サイバーテックお知らせ画像
©2003 CyberTech corporation ltd. All Rights Reserved.