XprioriでつくるWebアプリケーション 第10回

これまでの記事は、住所アイテムの閲覧から始まり、認証機能、セキュリティ対応と紹介してきました。前回までの記事で住所録アプリケーションは完成です。今回は住所録アプリケーションへの機能追加ではなく、Xprioriの特徴でもある「やわらかいデータベース」の利点を紹介していきます。

やわらかいデータベースと書きましたが、何がやわらかいのでしょうか。RDBと比較して考えてみましょう。データベースを利用したアプリケーション開発をはじめるに当たって、プログラムの実装前に必要なことはデータベースのスキーマ設計です。RDBはもともと厳密なスキーマ情報を前提としたデータベースですので、スキーマ設計にはE-R図の作成や正規化などが必要となり、これにはかなりの工数がかかります。また、幾つかの工程を経て設計したスキーマも、開発が進むにつれて設計当初のスキーマでは対応できない問題が発生したり、開発が終了し運用に入った段階でデータ項目の変更が生じたりと、スキーマ設計の見直しが必要になって来ることは多いのではないでしょうか。

スキーマ設計の見直しが必要な場合、RDBではデータベースを利用するアプリケーション側への影響が広範囲に及び、修正にかかるコストも大きくなります。そのため、一度決定したスキーマはなかなか変更できないのがRDBを利用したアプリケーションの弱点といえるかもしれません。

RDBに対して、XML DBはスキーマ設計の段階で、どのような構造のXMLにデータを格納するかを考えなければなりませんが、厳密な構造仕様は必要ありません。XML DBの種類によってはスキーマ定義としてDTDやXML Schema を作成し、それらを登録しなければなりませんが、Xprioriではそれらも必要ありません。Xprioriをデータベースとして利用するアプリケーションでは、スキーマ変更によるアプリケーション側の影響範囲が少なく、修正コストも少なくてすみます。ですから、頻繁にデータ項目の変更や追加の要求などが発生する場合も、対応しやすいと言えます。

RDBでは一度決定したスキーマを変更するのが大変であるのに対し、Xprioriではスキーマ変更による修正に柔軟に対応できるという点で「やわらかいデータベース」といえるのです。

では、これまでの記事で紹介してきた住所録アプリケーションにスキーマ変更を行うことで、その「やわらかさ」をみてみましょう。まず、今回の住所録アプリケーションのスキーマをもう一度見てみます。

住所アイテムとして登録する項目は

・ 名称

・ 郵便番号

・ 住所

の3項目であり、格納するXMLのツリー構造は以下のように設計しました。

▲ツリー構造

実際に、Xprioriには現在

<address_book>
  <dummy />
  <item id="000001" >
    <name>根尾太郎</name>

    <zip>145-9999</zip>
    <address>東京都港区竜の門1－2－3</address>
  </item>
  <item id="000002" >
    <name>ネオ株式会社</name>

    <zip>145-8888</zip>
    <address>東京都港区鷲の門1－2－3</address>
  </item>
</address_book>

というXMLが格納されており、そこから住所情報を読み込んでいます。このスキーマをRDBで実現する場合は、下記のような構造の住所アイテムテーブルが必要となるでしょう。（実際のスキーマ設計では郵便番号マスターテーブルや、住所のための都道府県マスターテーブルが必要となるかもしれませんが、ここでは、シンプルなテーブル構成を考えています。）

では、このようなスキーマをもつ住所録アプリケーションに対して、「1つのアイテムに対して、住所だけでなく電話番号も入力できるようにしたい。」という要望があったとします。この要望を可能とするためには下記のようなスキーマ変更が必要です。

住所アイテムとして登録できる項目に「電話番号」を追加し、住所アイテムがもつ情報は

・ 名称

・ 郵便番号

・ 住所

・ 電話番号

となります。

RDBの場合はテーブルに電話番号のカラムを追加するため

というSQLを実行する必要があります。このSQLによってテーブルに電話番号を登録できるようになり、

というアイテムを登録した場合テーブルの中身は

となります。しかしこの場合、電話番号を必要としない住所アイテムに対して、無駄なカラム領域の追加を強制することになるという問題が考えられますし、もし正規化を行う必要があるようなスキーマ変更の場合はインデックスの見直しも必要となり、スキーマ変更はよるデータベース側への影響は大きいといえます。

RDBに対してXML DBの場合は、スキーマ変更によってXMLのツリー構造は

▲変更後のツリー構造

となり、先ほどのアイテムを登録したXprioriが持つデータは

<address_book>
  <dummy />
  <item id="000001" >
    <name>根尾太郎</name>

    <zip>145-9999</zip>
    <address>東京都港区竜の門1-2-3</address>
  </item>
  <item id="000002" >
    <name>ネオ株式会社</name>

    <zip>145-8888</zip>
    <address>東京都港区鷲の門1-2-3</address>
  </item>
  <item id="000003" >
    <name>根尾次郎</name>

    <zip>145-8887</zip>
    <address>東京都港区亀の門1-2-3</address>
    <tel>99-9999-9999</tel>
  </item>

</address_book>

となります。電話番号が不要な住所アイテムはそのままでよいので、新たに登録したアイテムだけ電話番号を持つようになり、既に格納済みのデータへの影響はありません。また、現状のデータベース構造に対して、RDBでSQLを実行したような変更を加える必要はありませんので、その点でもスキーマ変更による影響は少ないといえるでしょう。

このように、Xprioriにはスキーマ変更に伴うデータベース側への影響はほとんどありません。アプリケーション側の影響はどうでしょうか。次回と次々回では、住所録アプリケーションに対してスキーマ変更を行い、アプリケーション側でどのような対応が必要かを紹介します。

▲このページのTOPへ