XML文書検索へのディレクトリ技術の応用 有田 憲司 富士通株式会社 (株)富士通南九州システムエンジニアリング 1. はじめに 2.2 TAGの追加に対応可能な柔軟性 現在電子カルテは黎明期にあると考えられ、特定 XMLはメタ言語としての性質を持っている。つ の文書や特定の診療科のみで電子カルテを試行し、 順次適用範囲を拡大していくという導入手法が多く 見られる。コンピュータシステム上は新たなDTDや スキーマが発生するという事になる。また長期的に まりXML はそれ自身で様々な用途に特化したマー クアップ言語を定義できる。これによる最大のメ リットはデータの再利用性を高められるという事で あろう。これには2つの側面がある。一つはDTDの は医療の変遷によって新たなTAGが発生する可能 性は高いと考えられる。 したがって新たな文書やTAGが追加されても、ア プリケーションの修正や、データベースの再構築が 標準化によりデータの交換が容易になるという面で あり、MML はその一例である。 もう一つは XML で記述された文書それ自体が データベースと成り得るという面である。高性能な 不要な柔軟性を持つ事が望ましい。 検索機能を持てば、XML で記述された電子カルテ システム全体があたかも巨大なデータベースのよう に機能する。 2.3 大量データの検索性能 検索対象となる文書は膨大な数になる事が予想さ れる。1回の記録単位を1文書として計算した場合、 大学病院規模であれば5年間で1千万件を超えるで あろうと試算している。これ程の件数を実用的な速 そのような検索機能の実現は電子カルテのデータ としての価値を高め、電子カルテシステムの普及と 利用率向上に役立つと考える。 度で検索するには効率的なIndex が必須であろう。 検索の度に文書の実体を検索していたのでは満足で きる性能を出す事は難しい。 2. XML検索システムに求められる機能 2.1 TAGを意識した検索 山田太郎という患者のカルテを検索する場合、患 3. 既存の技術の評価 者氏名を表すTAG内に"山田太郎"という文字列を 持つカルテのみがヒットすれば良く、山田太郎医師 の書いたカルテや、山田太郎さんを父親に持つ患者 3.1 全文検索システム 一口に全文検索システムと言っても検索のロジッ のカルテはヒットしない事が望ましい。XML の特 性を活かして効率的な検索を行うにはTAGと文字 列の組での検索が必須であると考える。 さらに効率的な検索を行うためには、文字列の クはそれぞれ独自の方法であるが、一般的には検索 の適合度を判断するのに字句の登場回数や登場した 位置等を使用している。検索用のIndexが文書の構 造やTAG を意識していない為、新たな文書やTAG が発生しても設計変更が不要な点が長所である。 しかし上記の長所がそのまま欠点にもなる。TAG を意識した検索を行う事は不可能であるため、特定 『前方一致』 『後方一致』 『部分一致』の他に、自然言 語を検索する場合は文字間の空白や些細な違いを無 視した『曖昧検索』、数値データの『大小比較』や『近 似値』検索等の実現が望まれる。 のTAGと値をダイレクトに指定した検索を行う事 ができない。検索精度には自ずと限界があり、目的 のデータに辿り着くまでに何度も絞込みを行う事に なる。 応用としては、<文書種別>が"退院時サマリ"で <最終診断名>に"肺上皮癌"という文字を含み、< 退院日>が"1998年以降"のカルテを検索する等と いう事が考えられる。 3.2 データベース(ＲＤＢ) 特定のデータ構造にマッチしたインデックスを作 1 成する事が可能であり、想定した範囲内であれば高 速な検索が期待できる。最近見られるXMLをRDB スタンドアローンなディレクトリサーバとして機能 する。X.500とLDAPの関係はSGMLとXMLの関係 の複数のテーブルにマッピングする技術を使えば、 に似ており、上位規格の10%の労力で主要な90%の これまでアプリケーション開発のネックであった、 機能を実現する事ができるよう設計されている。 RDBでXMLの階層構造を扱う事の難しさからは逃 れる事ができる。 サーバ製品は富士通をはじめ、Netscape やSun、 しかしスキーマが固定されるため拡張性に難があ り、設計時に想定したパターン以外のデータを格 納・検索する事はできない。稼動後にアプリケー Oracleその他大手ベンダより発売されている。多く の製品がマルチプラットホームに対応しており、主 要な商用UNIX、WindowsNT、Linux上で動作する。 ションやデータベースの設計変更を行う事は可能な 限り避けたい所である。 3.3 ＸＱＬ オープンソースのプロダクトとしてOpenLDAPがあ る。最近では W i n d w o s 2 0 0 0 に搭載された ActiveDirectoryもLDAPを採用している。クライア ント側は既にInternet Explorer やNetscape Navigator XMLの検索言語としてW3CのXSLワーキンググ ループによって定められたXQLがある。XML専用 の設計であり、文書の構造やTAGを意識した完全な 検索を行う事ができる。また検索の自由度も高い。 に搭載されている。 LDAP を使用した事例としては、Netscape の OpenDerectoryプロジェクトや日経BPのFind'Xで、 Webページをディレクトリを使って分類、検索する しかし現在の実装ではDOMを使用して文書毎に 検索する仕様であるため、複数の文書を串刺しで検 索する場合はプログラム的な工夫が必要である。ま サービスを提供している。またCNN.COMではユー ザのプロファイルをディレクトリを使って管理し、 ユーザに合ったバナー広告を表示している。 たIndexを使わない仕様であるため、性能面では全 く期待できない。 ※最近XML 対応を謳ったデータベース製品がいく ディレクトリとは所謂フォルダの意味ではなく、 英語本来の『登録簿』的な意味である。エントリ(電 子カルテでは患者やカルテに相当)とその属性(氏名 や病名を表すTAGに相当)の組を階層構造で持つこ つか発表されている。残念ながらまだ実際に使った 事がないため個々の製品の機能についてはコメント できないが、上記の拡張性と性能の問題が解決され ているのであれば期待が持てる。 とができる。各属性は複数の値(氏名や病名に相当) を持つ事ができ、属性と値の組により検索する事が できる。検索条件としては"前方一致"、"後方一致 "、"部分一致"、"近似値"、"大小比較"等が予め準 以上の内容をまとめてみると、『全文検索エンジ ンの柔軟性』 『データベースの性能』 『XQLのヒット 備されており、これらの条件を組み合わせて検索を 行う事が可能である。⇒高いヒット率が期待できる この条件式(フィルタ)もRFC1960で定義された標準 率』を満たせばXML の検索エンジンとして満足で きる物となろう。 このような条件を満たす検索エンジンを検討した 結果、現時点では通常のデータベースや全文検索シ 規格である。 ステムを使用する事は難しいと判断し、インター ネットディレクトリ技術として注目を集めつつある LDAPを使った検索システムを考案した。 4. LDAPとは？ Lightweight Directory Access Protocolの略で、イン ターネットディレクトリを利用するためのプロトコ ルとしてIETF により開発されたオープンなイン ターネット標準規格でありRFC1777と1778で定義 されている。(LDAPv3はRFC2251∼2256) LDAPは元々X.500 Directory Serviceのフロントエ ンドとして開発された物であるが、現在では完全に 2 各エントリがどのような属性を持つかはオブジェ クトクラスにより定義されるが、ExtensibleObjectク ラスを使用すれば任意の属性を持つ事ができる。す なわち設計時に想定していなかったTAG も属性と して格納できる。高速な検索を行う為には属性毎に リを追加し、文書内のTAGを文書エントリの属性と して、TAG内の文字列を属性の値として格納する。 Indexを作成する必要があるが、これも多くの商用 LDAPサーバではシステム稼動中に動的に追加する 事が可能である。⇒柔軟性が高い LDAPツリーに XML文書のエントリを登録する ルールさえ決まれば、どのようなXML 文書であれ LDAPに登録する事ができる。したがって電子カル テに留まらず様々なXML 文書の検索に応用する事 LDAPはトランザクション処理を持っていない。 が可能であると考える。 したがって更新系の機能は貧弱であり基幹系のシス テムに適用するのは難しいが、その軽量故に動作は 非常に高速である。Mindcraft社のベンチマークテス トによると、Netscape Directory サーバの場合 PentiumPro 200MHzクラスのサーバで183件/秒の検 索性能を出している。(エントリ数が1万件の場合) 実際に我々が行ったベンチマークでは、Pentium 200MHzクラスのサーバで、100万件のデータから10 件を検索するのに5秒以下であった。⇒検索性能が 高い 5. 実装 XML 文書全体を LDAPのツリー構造にマッピン グさせて格納し、参照時に再構築する事も可能では あるが今回はその様な手法は採用していない。カル テ(XML文書)の実体は完全な形の文書として存在す る必要が有るため、LDAPで文書構造を表現する必 6. 考察 昨年から『ヒット率』 『検索性能』 『柔軟性』とい う3点をキーワードにいくつかの XML 文書の検索 手法を模索した。当初LDAPはその選択肢の一つに 要は無いと考えたからである。文書構造を表現する 為にはXML 文書内の各エレメントをLDAPエント リとして登録する必要があるため、検索の性能面で もデータ容量面でも不利である。LDAPはXML文書 過ぎなかったが、実際にプロトタイプを作成して評 価した結果、文書の検索に非常に有効であった。人 気Webサイトで、LDAPを使った分類、検索サービ スを行い出した事はその証明であろう。 の実体へのポインタとして使用している。 現時点ではアプリケーション開発環境が充分とは 言えないが、 『機能』 『標準』といった面で他の手法 より有利であると考える。 クライアントはカスタムアプリケーションを作成 した。複雑な検索フィルタの入力補助や非同期検 索、検索結果のソーティング等の機能が必須である と判断したからである。またXML 文書の表示には スタイルシート(XSL)を使用し、参照時に任意のス 参考文献 タイルシートを選択する事を可能としている。 検索処理自体はLDAP検索フィルタ(RFC1960)を 『XML開発事例 エレクトロニックコマース(XML by (著者:Sean 発行するだけであるため、LDAPサーバの種類に依 Example:Building E-Commerce Applicatons)』 McGrath / 発行:アスキー出版局) 存しない。実際にOpenLDAP、Netscape Directoryサー バ、InfoDirectoryを使用して互換性テストを行った 『LDAPインターネット ディレクトリ アプリケー ション プログラミング(LDAP:Programming Directoryが、どのサーバを使用しても同じ結果を得る事がで Enabled Applications with Lightweight Directory Access Protocol)』(著者:Tim Hows、Mark Smith / 発行:プレン サーバ側でXML文書をLDAPに登録する機能は、 ティスホール出版) DOM を使用した汎用的な物としている。基幹系シ M i n d c r a f t B e n c h m a r k s R e p o r t s : h t t p : / / www.mindcraft.com/perfreports/ldap/netscape/ ステムで入力されたXML 文書をパースし、該当す る患者のエントリが無ければ新規に患者エントリを dirserver10.html きた。 追加する。その後患者エントリの下に文書のエント 3
© Copyright 2024 Paperzz
