(57)【要約】  複雑なモジュラリティ構成の計算機システムにおいて、各処理サーバやデータウェアハウス等に格納されたスキーマの異なるデータ同士の対応を集約して管理すること等を目的とする。計算機システムには、異なるスキーマ形式で記述されたメタデータの対応関係を示すスキーマ対応情報を保持する記憶部と、スキーマ対応情報に基づいて変換された、第１スキーマ形式とは異なる第２スキーマ形式のメタデータを対応する実データと共に統一ＩＤによって関連付けて記憶する記憶装置と、記憶装置から第２スキーマ形式のメタデータ及び統一ＩＤを取得し、スキーマ対応情報に基づいて第１及び第２スキーマ形式と異なる第３スキーマ形式に変換されたメタデータインデクスを保持するインデクス部と、メタデータに対する、所定のスキーマ形式を有する更新要求に対し、スキーマ対応情報を用いて更新対象とするメタデータの前記統一ＩＤを特定する更新管理部とが含まれる。
2014122732.tif 000002
【特許請求の範囲】
【請求項１】
異なるスキーマ形式で記述されたメタデータの対応関係を示すスキーマ対応情報を保持する記憶部と、
前記スキーマ対応情報に基づいて変換された、第１スキーマ形式とは異なる第２スキーマ形式のメタデータを、対応する実データと共に統一ＩＤによって関連付けて記憶する記憶装置と、
前記記憶装置から前記第２スキーマ形式のメタデータ及び統一ＩＤを取得し、前記スキーマ対応情報に基づいて、前記第１及び第２スキーマ形式と異なる第３スキーマ形式に変換されたメタデータインデクスを保持するインデクス部と、
前記メタデータに対する、所定のスキーマ形式を有する更新要求に対し、前記スキーマ対応情報を用いて、更新対象とするメタデータの前記統一ＩＤを特定する更新管理部と
を有する計算機システム。
【請求項２】
請求項１に記載の計算機システムであって、
前記更新管理部は、前記スキーマ対応情報に基づいて、前記所定のスキーマ形式を有する更新要求のスキーマ形式を前記第２スキーマ形式に変換し、更新対象とするメタデータの前記統一ＩＤを特定するものである計算機システム。
【請求項３】
請求項２に記載の計算機システムであって、
前記更新管理部は、第２スキーマ形式に変換された更新要求に含まれるデータをキーとして、更新対象とするメタデータの前記統一ＩＤを特定するものである計算機システム。
【請求項４】
請求項３に記載の計算機システムであって、
前記更新管理部は、前記キーで前記記憶装置に格納された第２スキーマ形式のメタデータを検索し、検索結果のメタデータに対応する前記統一ＩＤを特定するものである計算機システム。
【請求項５】
請求項１に記載の計算機システムであって、
前記更新管理部は、特定した統一ＩＤが含まれた、前記メタデータインデクスの更新指示を前記インデクス部に出力するものであり、
前記インデクス部は、前記メタデータインデクスの更新指示に含まれる前記統一ＩＤに基づいて更新対象インデクスの更新を行うものである計算機システム。
【請求項６】
請求項５に記載の計算機システムであって、
前記更新管理部は、前記更新要求の所定のスキーマ形式を、前記スキーマ対応情報に基づいて、前記第３スキーマ形式に更に変換し、前記メタデータインデクスの更新指示に更に含めて前記インデクス部に出力するものであり、
前記インデクス部は、前記更新指示に含まれる前記統一ＩＤ及び前記第３スキーマ形式に変換された更新要求に基づいて更新対象インデクスの更新を行うものである計算機システム。
【請求項７】
請求項５に記載の計算機システムであって、
前記更新管理部は、特定した統一ＩＤが含まれた、前記記憶装置に記憶されたメタデータの更新指示を、更に前記記憶装置に出力するものである計算機システム。
【請求項８】
請求項１に記載計算機システムであって、
前記更新要求の所定のスキーマ形式は、少なくとも前記第２スキーマ形式とは異なるものである計算機システム。
【請求項９】
同義のメタデータを異なるスキーマ形式で利用する複数のコンピュータモジュールからなる計算機システムのメタデータ管理方法であって、
前記計算機システムを管理する管理モジュールが、
前記異なるスキーマ形式で記述されたメタデータの対応関係を示すスキーマ対応情報に基づいて、入力された第１スキーマ形式のメタデータを、該第１スキーマ形式と異なる第２スキーマ形式のメタデータに変換して、対応する実データとともに統一ＩＤによって関連付けて記憶装置に出力するステップと、
前記記憶装置に記憶されたデータのメタデータ検索インデクスを管理するインデクスモジュールが、
前記記憶装置から前記第２スキーマ形式のメタデータ及び統一ＩＤを取得し、前記スキーマ対応情報に基づいて、前記第１及び第２スキーマ形式と異なる第３スキーマ形式に変換されたメタデータインデクスを保持するステップと、
前記管理モジュールが、
前記メタデータに対する、所定のスキーマ形式を有する更新要求を受信し、前記スキーマ対応情報を用いて、該更新要求が更新対象とするメタデータの前記統一ＩＤを特定するステップと
を含むメタデータ管理方法。
【請求項１０】
計算機に、
異なるスキーマ形式で記述されたメタデータの対応関係を示すスキーマ対応情報を保持させる手順と、
該スキーマ対応情報に基づいて、入力された第１スキーマ形式のメタデータを、該第１スキーマ形式と異なる第２スキーマ形式のメタデータに変換して、対応する実データとともに統一ＩＤによって関連付けて記憶装に出力させる手順と、
前記スキーマ対応情報に基づいて、前記記憶装置に出力された前記第２スキーマ形式のメタデータ及び統一ＩＤから、前記第１及び第２スキーマ形式と異なる第３スキーマ形式のメタデータインデクスを生成させる手順と、
前記メタデータに対する、所定のスキーマ形式を有する更新要求を受信し、前記スキーマ対応情報を用いて、前記第２スキーマ形式に変換した更新要求によって前記記憶装置に出力させた第２スキーマ形式のメタデータを検索させる手順と、
検索結果に対応する前記統合ＩＤを取得することで、前記更新要求が更新対象とするメタデータの統一ＩＤを特定する手順と
を実行させるプログラムを格納する非一時的な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システム、メタデータ管理方法及び記録媒体に関し、特に、スキーマ形式の異なるデータを処理する計算機システム等に関する。
【背景技術】
【０００２】
近年の計算機システムに処理が求められるデータは、構造化データ、半構造化データ及び非構造データ等、そのデータ種別も多岐におよび且つこれらの大量処理が要求される。このような背景から、データウェアハウス等で大量のデータのデータベースを管理し、このデータウェアハウスのデータを同種又は異種の様々な処理サーバで共有して利用する計算機システムアーキテクチャも出現してきている。例えば、種々の分析処理サーバや、検索用のインデクスを管理する検索サーバ等を任意に追加可能にし、データウェアハウスのデータを共有できるようにしている。多種、大量データ処理の様々なニーズに対応できるモジュラリティ構成の計算機システムである。【０００３】
また、このようなアーキテクチャを有する計算機システムでは、前述の構造化データ、半構造化データ及び非構造データに関する属性情報（以下、「メタデータ」とも呼ぶ。）を利用することも行われている。例えば、データ検索処理では、メタデータによって検索インデクスを生成し、実データそのものが示す情報以外の属性による検索等を実現することで、多次元的なデータ活用を可能とする。【０００４】
ところで、データウェアハウスのデータを共有する処理サーバを容易に拡張できるようにする際には、データウェアハウスに格納されたデータのスキーマと、各処理サーバ内で利用するデータのスキーマの関係を考慮することが必要である。即ち同義のデータであっても、スキーマが異なればデータを共有することができないためである。【０００５】
この点、特許文献１には、変換元構造化データ定義に従った構造化データを、変換先構造化データ定義の形式に変換する際の変換規則であるマッピング定義を作成するマッピング定義作成システムが開示されている。このシステムでは変換元と変換先とで異なる要素の組をマッピングし、このマッピング情報に基づいてデータ定義が変換されたデータを生成するようになっている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００９-２１１５９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１の技術を用いてデータウェアハウス等に格納されたデータのスキーマを各処理サーバで利用するスキーマに変換する機能を処理サーバ毎に実装する構成は、処理サーバの拡張性を阻害する要因となる。【０００８】
更には、データウェアハウス等からスキーマを変換して処理サーバにデータを格納した後に、データウェアハウス等に格納されたデータの更新を行う場合、データウェアハウス側の更新が完了するまでは、処理サーバに格納されたデータの更新処理ができないという問題もある。【０００９】
複雑なモジュラリティ構成の計算機システムにおいて、各処理サーバやデータウェアハウス等に格納されたスキーマの異なるデータ同士の対応を集約して管理することは、多種多様で大量のデータ処理を実現する上で重要な課題であるといえる。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、例えば、特許請求の範囲に記載の構成を適用する。即ち異なるスキーマ形式で記述されたメタデータの対応関係を示すスキーマ対応情報を保持する記憶部と、
前記スキーマ対応情報に基づいて変換された、第１スキーマ形式とは異なる第２スキーマ形式のメタデータを、対応する実データと共に統一ＩＤによって関連付けて記憶する記憶装置と、
前記記憶装置から前記第２スキーマ形式のメタデータ及び統一ＩＤを取得し、前記スキーマ対応情報に基づいて、前記第１及び第２スキーマ形式と異なる第３スキーマ形式に変換されたメタデータインデクスを保持するインデクス部と、
前記メタデータに対する、所定のスキーマ形式を有する更新要求に対し、前記スキーマ対応情報を用いて、更新対象とするメタデータの前記統一ＩＤを特定する更新管理部とを有する計算機システムである。
【発明の効果】
【００１１】
本発明の一側面によれば、スキーマの異なるデータを扱う複数の計算機でデータを共有する計算機システムにおいて、スキーマの異なるデータ同士の対応を集約して管理することができ、システムの可用性や拡張性が増加する。
本発明の他の課題や効果は以下の記載から更に明らかとなる。
【図面の簡単な説明】
【００１２】
【図１】本発明を適用した第１実施形態である計算機システムの概要例を示す模式図である。
【図２】第１実施形態における計算機システムの一構成例を示すブロック図である。
【図３】第１実施形態における計算機システムの統一スキーマ定義の一例を模式的に示す図である。
【図４】第１実施形態における計算機システムの画像スキーマ定義の一例を模式的に示す図である。
【図５】第１実施形態における計算機システムの検索インデクススキーマ定義の一例を模式的に示す図である。
【図６】第１実施形態における計算機システムの更新要求スキーマ定義の一例を模式的に示す図である。
【図７】第１実施形態における計算機システムのスキーママッピングの一例を模式的に示す図である。
【図８】第１実施形態における計算機システムの検索インデクステーブルの一例を模式的に示す図である。
【図９】第１実施形態における計算機システムのシステム構成情報の一例を模式的に示す図である。
【図１０】第１実施形態における計算機システムのメタデータの一例を模式的に示す図である。
【図１１】第１実施形態におけるデータ収集・インデクス生成処理の一例を示すフロー図である。
【図１２】第１実施形態におけるメタデータ更新処理の一例を示すフロー図である。
【図１３】第１実施形態におけるストレージ側のメタデータ更新処理の一例を示すフロー図である。
【図１４】第１実施形態の変形例におけるストレージ側のメタデータ更新処理の一例を示すフロー図である。
【図１５】本発明を適用した第２実施形態である計算機システムの概要例を示す模式図である。
【図１６】第２実施形態における計算機システムの一構成例を示すブロック図である。
【図１７】第２実施形態における更新記録情報の一例を模式的に示す図である。
【図１８】第２実施形態における計算機システムのメタデータ更新処理の一例を示すフロー図である。
【図１９】第２実施形態における計算機システムの更新記録情報を利用した検索処理の一例を示すフロー図である。
【発明を実施するための形態】
【００１３】
以下に、図面を用いて、本発明を実施するための形態を説明する。
〔第１実施形態〕
先ず、図１に、本発明を適用した計算機システム１００の概要を説明する。近年の計算機システムに処理が求められるデータは、構造化データ、半構造化データ及び非構造データ等、そのデータ形式も多岐におよび且つこれらの大量処理が要求される。計算機システム１００は、これら多種及び大量のデータの属性等を含むメタデータを用いて、効率良くデータ管理を行うシステムである。本実施形態では、計算機システム１００の具体的適用例の一つである医療情報システムを例として説明する。
【００１４】
例えば、医療情報システムの分野では、検索要求元や、データソース６、外部システム７といったデータ形式の異なる多岐に渡る独立したシステムが増加し、これら環境間でのデータ共有化が望まれている。例えば、Ａ病院でファーストオピニオンを受けた患者が、Ｂ病院でセカンドオピニオンを受ける場合、ＡとＢでデータ形式（スキーマ等）が相違するとすれば、共有化の妨げとなる。医療も専門化が進み、分類も細分化されると、各機関のシステムが連携した複雑且つ大規模なモジュラリティ構造となる場合もある。計算機システム１００は、データ共有元のシステムに手を加えることなく、各システムのデータを集約して管理することを特徴の１つとする。
【００１５】
計算機システム１００には、ＥＴＬ１、辞書サーバ２、検索サーバ３及びストレージサブシステム５が含まれる。計算機システム１００では、患者のX線画像等の画像データが保持されるデータソース６（サーバ、ストレージ等を有する計算機システムからなる。）から、通信線を介して、画像データ及びその属性情報の収集が行われ、これらが加工され、検索用のメタデータインデックス４が作成されるようになっている。クライアント（例えば、各医療機関の操作端末）等からの検索要求に対して、メタデータインデクス４の検索が行われ、この結果に基づいて要求データが応答されるようになっている。例えば、ＥＴＬ１では、データソース６から画像データの収集が行われ、これらが所定のデータ形式に変換され、ストレージサブシステム５に格納される。検索サーバ３では、ストレージサブシステム５に格納されたデータのメタデータが所定の契機でクロールされ、検索用のメタデータインデクス４が生成される。このような、データソース６から検索サーバ３等へのデータ伝播が定期的（又は任意に）に繰り返されることで、クライアントに対してデータプールを提供するようになっている。
【００１６】
更に、計算機システム１００では、本システムとは独立した制御系である医療情報システム等の外部システム７から、画像データの属性情報（メタデータ）の更新要求を受け付けることができるようになっている。
【００１７】
そして、データソース６に保持される画像データや外部システム７からのメタデータ更新要求に含まれるデータ、更には計算機システム１００を構成する各サーバやストレージサブシステムで使用されるデータのスキーマは夫々異なるものとなっている。このため、計算機システム１００では、それらスキーマの異なるデータが、夫々のサブシステムで使用するスキーマ形式に変換されて、データ伝播が行われるようになっている。先ず、データ収集・インデクス生成処理（Ｓ１〜Ｓ６）を説明し、その後、メタデータ更新処理（Ｔ１〜Ｔ６）を説明する。
【００１８】
ＥＴＬ１には、辞書サーバ２において種々のスキーマ定義２３が対応付けられて生成されたスキーママッピング２７が保持される。ＥＴＬ１では、取得したデータについて、スキーママッピング２７を用いて各サーバやストレージサブシステムにおけるスキーマの対応関係が管理されるようになっている。特に、ＥＴＬ１では、スキーママッピングを用いて取得データのスキーマ変換を行うと共に、その変換したデータについて計算機システム１内部で共通の統一ＩＤを付して、検索サーバ３やストレージサブシステム５とデータ送受信を行う点が、特徴の１つとなる。
なお、スキーママッピングは、スキーマ変換等の処理の際、スキーマ定義２３から動的に生成するようにしてもよいし、予めユーザ等の設定により静的に保持するようにしてもよい。本実施形態では、動的に生成するものとして説明する。
【００１９】
ＥＴＬ１は、所定の契機（定期的若しくは外部からの指示）に、データソース６に保持された画像データ６０ａ〜６０ｃを取得する（Ｓ１）。この取得は、ＥＴＬ１から画像データ６０ａ等を収集（クロール）するものでもよいし、データソース６から出力（プッシュ）されるものでもよい。本実施形態では、クロールするものとして説明する。
データソース６において画像データに付された患者ＩＤ等の属性情報は、計算機システム１００のスキーマとは異なる。そこで、ＥＴＬ１は、辞書サーバ２のスキーママッピング２７を取得して、当該画像データのスキーマ形式が、画像スキーマ形式であることを特定し、必要な項目を画像データの属性情報から抽出する（Ｓ２）。例えば、データソース６における画像データ６０ａの属性情報から、画像スキーマ形式の項目である『ＰａｔｉｅｎｔＩＤ（患者ＩＤ）：１００』及び『ＰａｔｉｅｎｔＮａｍｅ（患者姓名）：佐藤一郎』が抽出される。
【００２０】
ＥＴＬ１は、スキーママッピング２７を参照し、抽出した項目を、ストレージサブシステム５で使用するスキーマ形式である統一スキーマ定義の形式に変換すると共にその変換後のメタデータと画像データに統一ＩＤ５０を割り当て、ストレージサブシステム５に出力する（Ｓ３）。例えば、画像データ６０ａの属性情報から抽出した、画像スキーマ形式上の『ＰａｔｉｅｎｔＩＤ（患者ＩＤ）：１００』及び『ＰａｔｉｅｎｔＮａｍｅ（患者姓名）：佐藤一郎』が、統一スキーマ形式の項目である『ＰＩＤ（患者ＩＤ）:１００』及び『ＰＮａｍｅ（患者姓名）：佐藤一郎』に変換され、統一ＩＤ５０ａとして『ＵＩＤ_００１』が割り当てられ、メタデータ５１ａと画像データ６０ａが関連付けられて、ストレージサブシステム５に格納されるようになっている。
【００２１】
検索サーバ３は、辞書サーバ２にスキーママッピングの生成を要求し、辞書サーバ２から統一スキーマと検索インデクススキーマのスキーママッピングを取得する（Ｓ４）。
その後、検索サーバ３は、所定の契機（既定の更新時刻等）に、ストレージサブシステム５からメタデータ５１ａ、５１ｂ等及びそれらに対応する統一ＩＤ５０ａ、５０ｂを取得（クロール等）し（Ｓ５）、Ｓ４で取得したスキーママッピングを基にメタデータインデクス４ａを生成する。メタデータインデクス４ａには、統一ＩＤ『Ｏｂｊｅｃｔ  ＩＤ＝ＵＩＤ-００１』と、患者名『Ｐａｔｉｅｎｔ  ＩＤ=佐藤一郎』とが対応付けられるようになっている。
【００２２】
次いで、本実施形態の他の特徴の１つである、メタデータ更新処理（Ｔ１〜Ｔ６）について説明する。例えば、患者の姓名等は、婚姻や改名等を原因として姓名が事後的に変更される場合もある。姓名等が変更になると、クライアントが変更後の患者姓名で検索要求をすると、変更前のメタデータを有する画像データを取得できない虞もある。そこで、計算機システム１００では、外部システム７からのメタデータ更新要求に対し、ＥＴＬ１から更新対象システムである検索サーバ３のスキーマ形式を動的に指定して更新要求を行うようになっている。
【００２３】
先ず、外部システム７からＥＴＬ１に、患者の姓名を変更等する更新要求が送信される（Ｔ１）。この更新要求は、変更前の姓名が「佐藤」であった「ＰＡＴ-ＩＤ：１００」について、変更後の姓名を「ＰＡＴ-ＮＡＭＥ：鈴木一郎」とする内容である。外部システム７では、患者のＩＤを「ＰＡＴ-ＩＤ」、患者の姓名を「ＰＡＴ-ＮＡＭＥ」とするスキーマでデータを扱う。即ち検索サーバ３、ストレージサブシステム５及びデータソース６で利用するスキーマとは異なる第４のスキーマ形式のデータである。
【００２４】
これに対し、ＥＴＬ１は、辞書サーバ２から取得したスキーママッピング２７に基づいて、更新要求に含まれるスキーマ項目と一致する他のスキーマ形式を特定する（Ｔ２）。例えば、更新要求に含まれるスキーマ項目のうち「ＰＡＴ-ＩＤ」に対応する統一メタデータのスキーマ項目は『ＰＩＤ』である。そして、この『ＰＩＤ』の値『１００』（『ＰＩＤ：１００』）をスキーマkeyとして特定する（Ｔ２）。
【００２５】
ＥＴＬ１は、『ＰＩＤ：１００』をスキーマkeyとしてストレージサブシステム５に検索要求し、該当するメタデータが検索されると、該当するメタデータに対応付けられた統一ＩＤ５０がＥＴＬ１に送信される（Ｔ３）。例えば、統一ＩＤ５０ａと統一ＩＤ５０ｂがＥＴＬ１に取得される。
【００２６】
ＥＴＬ１は、統一ＩＤ５０ａ及び５０ｂと共に検索サーバ３のスキーマ形式の項目名に変換された更新対象項目及び更新後の値を更新指示メセージに含め、検索サーバ３に対してメタデータインデクスの更新指示を送信する（Ｔ４）。例えば、「統一ＩＤ＝ＵＩＤ_００１、ＵＩＤ_００２」について、「Ｐａｔｉｅｎｔ  Ｎａｍｅ＝鈴木一郎」に更新する旨の要求が送信される。
【００２７】
更新要求を受けた検索サーバ３は、メタデータインデクス４の該当する統一ＩＤを有するインデクスの『Ｐａｔｉｅｎｔ  Ｎａｍｅ』の値を『鈴木一郎』に更新する（Ｔ５）。
その後、ＥＴＬ１は、ストレージサブシステム５に格納された、統一ＩＤがＵＩＤ_００１及び００２であるメタデータ５１ａ及び５１ｂの値を更新する要求をストレージサブシステム５に送信する（ＰＮａｍｅ＝「鈴木」に更新。）（Ｔ６）。
以上が、計算機システム１の概要である。
【００２８】
このように、計算機システム１００は、種々のスキーマが複雑に介在するモジュラティ構成のシステムにおいて、スキーマが異なるデータの共有化インタフェースを提供できるようになっている。
【００２９】
更に、計算機システム１００は、メタデータ更新を受けると、通常のデータ伝播経路以外に、ＥＴＬ１から検索サーバ３に直接的にメタデータインデクス４の更新指示を送信するため、メタデータインデクス４の更新において、ストレージサブシステム５のメタデータ更新を待つ必要がないという特徴も有する。
【００３０】
以下に、計算機システム１について詳細に説明する。
図２に、第１実施形態における計算機システム１００の構成を模式的に示す。計算機システム１００は、ＥＴＬ１、辞書サーバ２、検索サーバ３、ストレージサブシステム５を有し、有線又は無線の通信線（ＰＣＩバス、ＬＡＮ、ＷＡＮ、インターネットを含む。）でデータ通信可能に接続されてなる。計算機システム１００は、更に、外部のデータソース６や外部システム７からデータの送受信が可能に接続され、データの収集や更新要求を受け付けるようになっている。計算機システム１００は、これらデータソース６等から取得したデータを加工し、検索データベースとして機能し、クライアントからの種々の検索要求に対して応答を返信するようになっている。
【００３１】
本実施形態では、各サーバやサブシステムを独立した物理計算機として構成する例を用いて説明するが、これらの一部又は全部が単一の物理計算機に設けられてもよいし、仮想計算機等によって論理的に別の計算機として構成することも可能である。更に、本実施形態では、各サーバの機能をプログラムとＣＰＵとの協働によって実現する例を用いて説明するが、これらの一部をハードウェアとして構成してもよい。
【００３２】
ＥＴＬ１には、ＣＰＵ１０、主記憶１１及び補助記憶１２を有する汎用のサーバ装置を適用するものとする。ＥＴＬ１では、プログラムとＣＰＵ１０との協働によって、収集・格納部１３、更新管理部１４及び統一ＩＤ管理部１５が実現され、データの抽出・変換・書出し（Ｅｘｔｒａｃｔ／Ｔｒａｎｓｆｏｒｍ／Ｌｏａｄ）が行われるようになっている。
【００３３】
具体的には、収集・格納部１３では、患者のＸ線やＭＲＩ画像等の医療画像を格納するデータソース６から、所定の契機（定期又は任意）で画像データのクローリングが行われ、画像データに付帯する患者ＩＤ、患者姓名及び画像生成日時や画像の説明等の属性情報が抽出される。抽出された属性情報は、後述するスキーママッピング２７を用いて、ストレージサブシステム５の統一スキーマ定義２３に適合するメタデータとして加工（変換）されるようになっている。
【００３４】
統一ＩＤ管理部１５では、統一スキーマ定義２３に加工されたメタデータと、画像データとに、統一ＩＤ５０が発行されるようになっている。その後ストレージサブシステム５に送信された統一ＩＤ５０、メタデータ及び画像データは、ストレージサブシステム５内で関連付けられて格納されることとなる。
【００３５】
更新管理部１４では、既にストレージサブシステム５に格納したデータのメタデータに対して、外部システム７から更新要求を受けた場合、更新対象のメタデータに対応するメタデータインデクスの更新要求が検索サーバ３に発行され又ストレージブシステム５の更新対象メタデータが更新されるようになっている。より具体的には、更新管理部１４では、外部システム７からの更新要求に含まれるデータのスキーマから更新対象のメタデータがスキーママッピング２７によって特定され、ストレージサブシステム５内のメタデータから対象データを抽出するためのスキーマｋｅｙが特定される。このスキーマｋｅｙを用いて、ストレージサブシステム５のメタデータが検索され、該当する更新対象データの統合ＩＤ（ＵＩＤ）５０が取得される。その後、更新管理部１４では、取得された統合ＩＤ（ＵＩＤ）５０及び更新するべき値が指定され、メタデータインデクス４の更新指示が、検索サーバ３に出力されるようになっている。
【００３６】
また、更新管理部１４では、外部システム７からの更新要求に対し、検索サーバ３のメタデータインデクス４の更新処理やストレージサブシステム５のメタデータ更新処理の進捗状況に応じた応答を返すようになっている。例えば、何れの更新処理も完了した場合には「更新完了」、一方（例えば、メタデータインデクス４）のインデクス更新処理が完了し、他方（例えば、ストレージシステム５）のメタデータ更新処理がバックグラウンドで進行中の場合は「部分更新完了」、メタデータインデクス４のスキーマ変更処理が進行中である場合には、更なる更新要求の一時中断を示す「更新処理受付不可」等を応答するようになっている。
【００３７】
辞書サーバ２には、ＣＰＵ２０、メモリ２２及び補助記憶２１を有する汎用のサーバ装置を適用するものとする。辞書サーバ２のメモリ２２には、ＣＰＵ２０とプログラムとの協働によって辞書管理部２９が実現される。辞書管理部２９では、ＥＴＬ１や検索サーバ３からの要求に応じて、スキーマ定義２３〜２７が送信されたり、該当するスキーマ定義同士の対応を示すスキーママッピング２７が生成・送信されたりするようになっている。
【００３８】
辞書サーバ２の補助記憶２１には、計算機システム１００を構成する各サーバやストレージサブシステムで利用されるメタデータのスキーマ定義を示す、統一スキーマ２３、医療画像スキーマ２４、インデクススキーマ２５及び更新要求スキーマ２６や、これら定義の対応を示すスキーママッピング２７や、システム構成情報が格納される。各サーバやストレージサブシステムで扱われるメタデータのスキーマは夫々異なるものであり、計算機システム１００では、これらの異なるスキーマ形式のデータが、スキーママッピングを利用して伝播されることが１つの特徴である。
【００３９】
図３に、統一スキーマ定義２３を模式的に示す。統一スキーマ定義は、データ項目名２３ａ、データ型２３及び各項目がスキーマｋｅｙであるか否かの指定を示すスキーマｋｅｙ２３ｃが、対応付けて定義されるものである。データ項目名２３ａの『ＳｃｈｅｍａＮａｍｅ』は、スキーマの名称を示し、『ＵＩＤ（Unified identifer）』は、計算機システム１００を構成するサーバやストレージサブシステムで共通に利用する「統合ＩＤ」を示す。『ＰＩＤ（Patient identife）』は患者のＩＤを示し、『ＰＮａｍｅ』は、患者の姓名を示す。『ＳｔｕｄｙＤａｔｅ』は、画像の撮影日や検査日を示し、『ＳｔｕｄｙＤｅｓｃｒｉｐｔｉｏｎ』は、当該撮影画像の種別（胸部Ｘ線画像、頭部ＭＲＩ画像、心電図等）を始めとした付帯事項等を示す。データ型２３には、ＳｔｏｒｉｎｇやＤａｔａ等のデータ型が定義される。
【００４０】
スキーマｋｅｙ２３ｃは、後述する検索サーバ３のメタデータインデクス４の更新処理において、ＥＴＬ１が、ストレージサブシステム５内から更新対象のメタデータを検索する際のキーとなるデータ項目を指定する情報である。図３では、更新対象データの検索キーとして、”ＰＩＤ“が指定されている例を示している。
【００４１】
図４に、画像スキーマ定義２４を模式的に示す。本スキーマ定義は、ＥＴＬ１が、データソース６から画像データ等を収集し、ストレージサブシステムで利用する統一スキーマ定義２３のスキーマ形式に変換する際に利用されるものである。統一スキーマ定義２３と同様に、患者ＩＤや患者名が定義されるが、データ項目２４ａに示すように、夫々の項目名は、”ＰａｔｉｅｎｔＩＤ”や“ＰａｔｉｅｎｔＮａｍｅ”のように、示す内容は同義であっても他とは異なる形式の項目名を有する。
【００４２】
図５に、検索インデクススキーマ定義情報２５を模式的に示す。本スキーマ定義は、検索サーバ３が、ストレージサブシステム５に格納されたメタデータを読み出し、メタデータインデクスを生成する際に利用されるものである。上述の統一スキーマ定義２３や画像スキーマ定義２４と同様に、示す内容は同義であっても他のスキーマと異なる特有の項目名を有する。
【００４３】
図６に更新要求スキーマ定義２６を模式的に示す。本スキーマ定義は、外部システム７から、患者ＩＤや患者姓名等のメタデータの更新要求を受けた際に利用するものである。他の定義と同様に、内容は同義であっても他のスキーマと異なる特有の項目名を有する。
【００４４】
図７に、図３から図６に示す各種スキーマ定義の対応関係を示す、スキーママッピング２７を模式的に示す。例えば、統一スキーマ定義２３の項目”ＵＩＤ“は、検索インデクススキーマ定義２５の”ＯｂｊｅｃｔＩＤ”に対応する様を示す。同様に、統一スキーマ定義２３の“ＰＮａｍｅ”は、検索インデクススキーマ定義の“Ｐａｔｉｅｎｔ  Ｎａｍｅ”、画像スキーマ定義２４の“ＰａｔｉｅｎｔＮａｍｅ”及び更新要求スキーマ２６の“ＰＡＴ-ＮＡＭＥ”に夫々対応する様を示す。
【００４５】
また、辞書サーバ２では、ＥＴＬ１、検索サーバ３等からスキーマ定義の取得要求やスキーママッピングの生成及び取得要求を受けて、夫々の要求先に送信するようになっているが、これら要求に対応するスキーマ定義やスキーママッピングの組合せの選択は、システム構成情報２８を用いて行うようになっている。
【００４６】
図９に、システム構成情報２８の一例を模式的に示す。システム構成情報２８では、システム名２８ａと、スキーマ定義等の要求先システムのネットワークアドレス２８ｂと、その要求先システムで使用されるスキーマと、システムタイプ２８ｄが対応付けられて管理される。例えば、ＥＴＬ１において、データソース６（図９ではＰＡＣＳ１〜３で示している。）から収集された画像データの属性情報についてスキーマ変換が行われる場合、スキーママッピング２７の生成・取得要求に、収集先であるデータソース６のネットワークアドレスと、出力先であるストレージサブシステム５のネットワークアドレスとが、辞書サーバ２に通知される。
辞書サーバ２では、システム構成情報２８が参照され、通知に含まれる両ネットワークアドレスに対応する夫々のスキーマ定義（統一スキーマ定義２３と画像スキーマ定義２４）から、スキーママッピング２７を生成し、ＥＴＬ１に出力されるようになっている。
【００４７】
図１０に、スキーママッピング２７を用いて統一スキーマ定義の形式に変換され、統合ＩＤ（ＵＩＤ５０ａ）によって対応づけられたメタデータ５１ａを例示する。”ＳｃｈｅｍａＮａｍｅ“として『統一スキーマ』、”ＵＩＤ（統合ＩＤ）“として『００１』、”ＰＩＤ（患者ＩＤ）“として『１００』、”ＰＮａｍｅ（患者姓名）“として『佐藤一郎』、”ＳｔｕｄｙＤａｔｅ（画像撮影日）“として『２０１２／６／２２』、“ＳｔｕｄｙＤｅｓｃ（画像種別/特記事項）”として『Ｓｐｅｓｉａｌｓ（補足事項等）』が記述されている。
【００４８】
図２に戻り、検索サーバ３には、ＣＰＵ３０、メモリ３２及び補助記憶３１を有する汎用のサーバ装置を適用するものとする。検索サーバ３のメモリ３２には、ＣＰＵ３０とプログラムとの協働によってインデクス部３３、検索部３４及び辞書参照部３５が実現される。また、補助記憶３１には、クライアント等からのメタデータ検索要求に対するインデクスであるメタデータインデクス４が格納される
検索サーバ３では、所定の契機（定期又は任意）で、ストレージサブシステムに格納されたメタデータを取得し、スキーママッピング２７を用いて、検索用途のメタデータインデクス４が生成される。それと共に外部システム７からメタデータの内容について更新が発生した場合には、ＥＴＬ１からのメタデータインデクス更新指示に応じて、対象とするメタデータインデクスが更新されるようになっている。
【００４９】
インデクス部３３では、辞書サーバ２から取得された統一スキーマ定義と検索インデクススキーマ定義との対応を示すスキーママッピング２７が参照され、ストレージサブシステム５から取得されたメタデータから、メタデータインデクス４が生成されるようになっている。また、インデクス部３３では、ＥＴＬ１からメタデータインデクス４の更新指示を受けた場合に、更新対象のメタデータインデクスの更新も実行されるようになっている。なお、メタデータインデクスの更新例としては、婚姻や改名等によって、患者の姓が変更となった場合等があげられる。
【００５０】
辞書参照部３５では、メタデータインデクス４の生成時に、辞書サーバ２に対してスキーママッピングの生成及び取得要求が行われるようになっている。
【００５１】
図８に、メタデータインデクス４の一例を模式的に示す。メタデータインデクス４には、“Ｏｂｊｅｃｔ  ＩＤ”欄４ａに統一ＩＤ（ＵＩＤ）５０、“Ｐａｔｉｅｎｔ  Ｎａｍｅ”欄４ｂに鈴木一郎や山田二郎といった患者の姓名、“Ｓｔｕｄｙ  Ｄａｔｅ”欄４ｃに画像撮影日や検診日、そして“Ｓｔｕｄｙ  Ｄｅｓｃｒｉｐｔｉｏｎ”欄４ｄに、撮影画像に関する説明（胸部Ｘ線画像、胸部ＣＴスキャン画像、頭部ＭＲＩ画像）等が登録される。
【００５２】
検索サーバ３では、クライアント等からのメタデータ検索要求に含まれるキーワード等に対応する項目がメタデータインデクス４で検索され、該当する項目がある場合、対応する統一ＩＤ（ＵＩＤ）５０をもって、ストレージサブシステム５に対象データの読み出しが要求され、要求に応じた結果が、クライアントに送信されるようになっている。
【００５３】
したがって、上述のような患者の姓の変更が外部システム７からある場合、ストレージサブシステム５のメタデータのみが先に更新完了され、メタデータインデクス４の更新が完了する前にクライアントから変更「後」の患者名を検索キーに含む検索要求が受信されてしまうと、メタデータインデクス４にヒットするキーワードがなく、クライアントに対して旧姓の画像データが提供されない虞がある。
この点、計算機システム１００では、メタデータ更新要求に際して、メタデータインデクス４が早期に更新されるようになっており又ストレージサブシステムに対する検索対象の実データの読み出し要求がシステム内で共通の統一ＩＤ（ＵＩＤ）５０を用いて行われるようになっていることから、情報更新の頻度が高い傾向にあるクライアントの要求に対して柔軟に対応することができるという利点がある。
【００５４】
ストレージサブシステム５には、ファイル形式で画像データと、メタデータとを格納するファイルストレージ装置を適用するものとする。ストレージサブシステム５には、演算装置、メモリ、データキャッシュ等を有するコントローラ５１が設けられる。コントローラ５１には、ファイルの入出力制御やファイルインタフェースを提供するファイル管理部５３と、ＥＴＬ１からのメタデータ更新要求処理時に、指定されたスキーマ名やスキーマkeyをもとに、該当するメタデータに対応する統合ＩＤ（ＵＩＤ）５０を応答するメタ検索部５４が設けられる。これらの一部をハードウェアとして構成することもできるが、本実施形態では、演算装置とプログラムとの協働により実現される例を用いて説明するものとする。
【００５５】
記憶部５２には、ＨＤＤ等の磁気的記憶媒体や、ＳＳＤ又はフラッシュ等の電子的記録媒体が複数台設けられる。記憶部５２には、ＥＴＬ１によって統合スキーマ形式に変換されたメタデータ５１及び画像データ６０が統合ＩＤ（ＵＩＤ）５０によって関連図けられて格納される。先に示した図２の例では、画像ファイル６０ａの属性情報として「ＰＩＤ:１００」で「ＰＮａｍｅ：佐藤一郎」のメタデータ５１ａが、「ＵＩＤ_００１」の統合ＩＤ５１ａによって関連付けて格納された様が示されている。
【００５６】
最後に、データソース６の構成について説明する。データソース６は、大容量の画像データストレージを想定したストレージサーバシステムを適用するものとする。本実施形態では、例えば、DICOM規格に準拠したストレージサーバで、医療画像データをＰＡＣＳ（Picture Archiving and Communication system）に準拠したデータ形式で保持するものとする。DICOM規格の通信はモダリティ（CTやMRI等の医療機器）からの画像データをアーカイブするのに適しており、格納されるデータ量も膨大であることから、医療用のデータベースとして一般に良く用いられる。
【００５７】
しかしながら、DICOM規格では、各画像データに付され属性情報もユニークな形式であり、異なるデータ形式のシステムでデータを共有する点に課題が残る場合がある。本実施形態では、ETL１が属性情報のスキーマ変換を動的に行うようになっているため、データ量に優れるデータベースを容易に利活用できるという利点があると言える。なお、他のアーカイブストレージ等を適用できることは言うまでもない。
以上が、計算機システムの構成である。
【００５８】
次に、計算機システムの処理の流れについて説明する。なお、以下の説明では、（１）データソース６からの「データの収集・加工及びメタデータインデクス生成」までの処理の流れ（図１におけるＳ１〜Ｓ６）と、（２）外部システムからメタデータ更新要求を受信した際の「メタデータ及びメタデータインデクスの更新処理」（図１におけるＴ１〜Ｔ６）の流れとに分けて説明するものとする。
図１１に、「データ収集及びメタデータインデクス生成処理」の流れを示す。
Ｓ１０１で、ＥＴＬ１の収集・格納部１３は、所定の契機（定期或いは任意）で、データソース６から画像データ６０ａ等を取得する。
Ｓ１０３で、収集・格納部１３は、データ取得元であるデータソース６と、データ
格納先であるストレージサブシステムのネットワークアドレスを指定し、辞書サーバ２にスキーママッピングの生成・取得要求を送信する。
【００５９】
Ｓ１０５で、辞書サーバ２の辞書管理部は、要求を受信し、システム構成情報２８を参照して、要求に含まれたネットワークアドレスに対応するスキーマ定義の組合せを特定し、スキーママッピング２７を生成する。そして生成したスキーママッピング２７をＥＴＬ１に返信する。
【００６０】
Ｓ１０７で、ＥＴＬ１の収集・格納部１３は、データソース６から取得した画像データ６０ａ、６０ｂ・・・に含まれた属性情報を抽出する。
そして、Ｓ１０９で、収集・格納部１３は、スキーママッピング２７を参照し、抽出した属性情報が統一スキーマ定義の形式に変換されたメタデータ５１ａ、５１ｂ・・・を生成する。
【００６１】
Ｓ１１１で、統一ＩＤ管理部１５は、統一ＩＤ５０ａ、５０ｂ・・・を発行し、画像データ６０ａ、６０ｂ・・・及びメタデータ５１ａ、５１ｂ・・・に夫々割り当てる。
Ｓ１１３で、収集・格納部１３は、ストレージサブシステム５に、画像データ６０ａ・・・、メタデータ５１ａ・・・を、割当てた統一ＩＤを指定して格納要求とともに出力する。
そして、Ｓ１１５で、収集・格納部１３は、データソース６に、データ取得の完了通知を出力する。
【００６２】
このようにストレージサブシステム５に格納されたメタデータ群に対し、検索サーバ３がメタデータインデクス生成処理を実行する。
Ｓ１１７で、検索サーバ３の辞書参照部３５は、辞書サーバ２に、メタデータの取得元であるストレージサブシステム５と検索サーバ３のネットワークアドレスを指定して、スキーママッピング２７の生成・取得要求を送信する。
【００６３】
Ｓ１１９で、辞書サーバ２の辞書管理部２９は、上述のＳ１０５と同様に、システム構成情報２８を参照して、ネットワークアドレスを基にスキーママッピングの対象となるスキーマ定義の組合せを特定し、スキーママッピング２７を生成する（ここでは、統一スキーマ定義２３と、検索インデクススキーマ定義２５のマッピングとなる。）。そして、生成したスキーママッピング２７を検索サーバ３に返信する。
なお、スキーマ定義の組合せは、メタデータに含まれるスキーマ名から、対応するインデクススキーマを特定するようにしてもよい。
【００６４】
Ｓ１２１で、検索サーバ３のインデクス部３３は、所定の契機でストレージシステム５のメタデータ群を取得する。なお、この契機は、スケジューラ等によって予め定められた契機であるものとする。好ましくは、ＥＴＬ１からストレージサブシステムへの次回のデータ格納処理が開始される前であって、前回のデータ格納処理が完了した直後からなるべく早いタイミングが好ましい。格納したデータソースをより早期に検索できる状態にするためである。
【００６５】
Ｓ１２３で、インデクス部３３は、ストレージサブシステム５にインデクス対象となる未インデクス状態のメタデータがあるか否かをチェックし、無い場合（S123:No）には処理を終了し、有る場合（S123：Yes）には、Ｓ１２５に進む。
【００６６】
Ｓ１２５で、インデクス部３３は、未インデクスのメタデータをストレージサブシスムから取得する。
Ｓ１２７で、インデクス部３３は、スキーママッピング２７を参照し、統一スキーマ形式のメタデータを検索インデクススキーマ形式に変換し、Ｓ１２９で、メタデータインデクス４に登録し、Ｓ１２３に戻る。
以上が、データ収集・インデクス生成処理である。
【００６７】
次に、外部システム７からメタデータの更新要求の発行時に、更新対象のメタデータ及びそれに対応するメタデータインデクス４を更新する「メタデータ更新処理」を説明する。図１２に、「メタデータ更新処理」の流れを示す。
【００６８】
Ｓ２０１で、ＥＴＬ１の更新管理部１４は、外部システム７から「ＰＡＴ-ＩＤ（患者ＩＤ）：１００」の「ＰＡＴ-ＮＡＭＥ（患者姓名）」を、（従前の「佐藤一郎」から）「鈴木一郎」に更新する旨のメタデータ更新要求を受領する。
【００６９】
Ｓ２０３で、更新管理部１４は、更新要求元の外部システム７のネットワークアドレスと、ストレージサブシステムのネットワークアドレスと、検索サーバ３のネットワークアドレスを指定し、辞書サーバ２に対してスキーママッピングの生成・取得要求を送信する。
【００７０】
Ｓ２０５で、辞書サーバ２の辞書管理部は、システム構成情報２８を参照し、スキーママッピングの生成・取得要求で指定される３つのアドレス毎に、対応するスキーマ定義を特定する。そして、特定した更新要求スキーマ定義２６、統一スキーマ定義２３及び検索インデクススキーマ定義２５からスキーママッピング２７を生成し、これをＥＴＬ１に返信する。
【００７１】
Ｓ２０９で、ＥＴＬ１の更新管理部１４は、スキーママッピング２７を参照し、外部システム７の更新要求で更新対象として指定する「ＰＡＴ-ＩＤ」に対応する統一スキーマ項目名を抽出し、これに「ＰＡＴ-ＩＤ」の実際の識別情報である「１００」の値を加えて、スキーマｋｅｙとして特定する。即ち図７のスキーママッピングの例に示すように、更新要求スキーマ定義の「ＰＡＴ-ＩＤ」に対応する統一スキーマ定義の項目名は「ＰＩＤ」である。よって、「ＰＩＤ：１００」をスキーマｋｅｙとして特定する。
【００７２】
Ｓ２１１で、更新管理部１４は、スキーマ定義の種別と、スキーマｋｅｙとを指定して、ストレーズサブシステム５のメタデータに対して検索を行い、スキーマｋｅｙに該当するメタデータの統一ＩＤを取得する。例えば、本実施形態の場合、ストレージサブシステム５に格納されたメタデータのうち、スキーマｋｅｙ「ＰＩＤ：１００」を有するメタデータは５１ａと５１ｂである。よって、更新管理部１４は、メタデータ内から対応する統合ＩＤ５０ａ（「ＵＩＤ_００１」）と、５０ｂ（「ＵＩＤ_００２」）とを抽出し、特定する（図７参照）。
【００７３】
Ｓ２１３で、更新管理部２１３は、システム構成情報２８を参照し、更新通知対象のサーバを特定する。本実施形態では、システム構成情報２８に登録されているシステムの内、システムタイプが「検索システム」である検索サーバ３を更新対象として特定する。
Ｓ２１５で、更新管理部１４は、スキーママッピング２７を参照し、更新通知対象である検索サーバ３で使用するスキーマ定義（検索インデクススキーマ定義２５）を特定し、辞書サーバから検索インデクススキーマ定義２５を取得する。
【００７４】
Ｓ２１７で、更新管理部１４は、検索インデクススキーマ定義２５を参照して、検索サーバ３に対するメタデータインデクス更新指示のメッセージを生成する。具体的には、外部システム７からのメタデータ更新要求に含まれる更新対象の項目名及び値（「ＰＡＴ-ＮＡＭＥ：鈴木一郎」）を、検索インデクススキーマ形式の「Ｐａｔｉｅｎｔ Ｎａｍｅ：鈴木一郎」に変換する。そして、Ｓ２１１で特定した統合ＩＤ５０ａ及び５０ｂ（「ＵＩＤ_００１」、「ＵＩＤ_００２」）を加えた更新指示メッセージを生成する。
【００７５】
Ｓ２１９で、更新管理部１４は、検索サーバ３に対して更新指示メッセージを送信する。このメッセージを受領した検索サーバ３のインデクス部３３では、メッセージ内の統一ＩＤで、メタデータインデクス４（図８）が検索され、更新対象メタデータインデクスが特定され、対応する「「Ｐａｔｉｅｎｔ Ｎａｍｅ」が「鈴木一郎」に更新される（それまでの「佐藤」から「鈴木」に更新。）。更新の完了後、検索サーバ３は、その旨をＥＴＬ１の更新管理部１４に通知する。
【００７６】
Ｓ２２１で、ＥＴＬ１の更新管理部１４は、検索サーバ３から更新完了の応答を受領し、Ｓ２２３で、外部システム７に更新完了を通知し、メタデータインデクス４の更新処理を完了する。なお、外部システム７に対する応答は、「更新完了」に限らず、「部分更新完了」、「更新処理受付不可」等の場合もあるのは前述の通りである。
この後、Ｓ２２５で、更新管理部１４は、ストレージサブシステム５に格納されたメタデータの更新処理を実行する。
【００７７】
図１３に、ストレージサブシステム５に格納されたメタデータの更新処理の流れを示す。
Ｓ３０１で、ＥＴＬ１の更新管理部１４は、上述のメタデータインデクス更新処理のＳ２１１で取得した統一ＩＤ５０ａ、５０ｂについて、メタデータ更新を行ったか否かをチェックする。未処理の統一ＩＤ５０がない場合（Ｓ301:No.）、処理を終了し、未処理の統一ＩＤ５０がある場合（S301:Yes）、Ｓ３０３に進む。
【００７８】
Ｓ３０３で、更新管理部１４は、ストレージサブシステム５から未処理の統一ＩＤ５０に対応するメタデータを取得する。具体的には、ストレージサブシステム５のメタ検索部５４が、指定された統一ＩＤ５０を基に記憶部５２に格納されたデータを検索し、該当する統一ＩＤに対応するメタデータを、ＥＴＬ１に出力する。
【００７９】
Ｓ３０５で、更新管理部１４は、スキーママッピング２７を参照し、外部システム７の更新要求に含まれる更新対象項目を特定する。更新要求対象を示す項目名「ＰＡＴ-ＮＡＭＥ」は、統一スキーマ形式で記述されたメタデータ上では「ＰＮａｍｅ」である。よって、Ｓ３０７で、更新管理部１４は、メタデータ上の項目名「ＰＮａｍｅ」の値を、「佐藤一郎」から「鈴木一郎」に更新する。
【００８０】
Ｓ３０９で、更新管理部１４は、統一ＩＤを指定して、更新後のメタデータをストレージサブシステム５に格納させる。その後、Ｓ３０１の処理に戻る。
以上が、メタデータインデクスの更新処理及びストレージサブシステムのメタデータ更新処理である。
【００８１】
このように本実施形態の計算機システムによれば、メタデータ更新要求に対し、ＥＴＬ１が、直接検索サーバ３に対してメタデータインデクス４の更新指示を行うため、ストレージサブシステム５のメタデータ更新を待つことなく、インデクスの早期更新ができる。
【００８２】
即ちメタデータインデクス４は、ストレージサブシステムでメタデータ更新が完了してから、検索サーバ３が再度メタデータをクロールすることで、差分更新することもできるが、ストレージサブシステム側のメタデータ更新中は、クロールできない或いはクロールしても更新前後のデータの整合性を保証できないという問題がある。更に、ストレージサブシステムに膨大なデータが格納されている場合には、検索処理を始めとした種々の処理もその分時間を要するし、更新対象のメタデータが多い場合にもその分時間を要する。本計算機システムでは、このようなストレージシステム側の処理時間を考慮することなく、メタデータインデクスを更新できるという顕著な効果がある。
【００８３】
また、本計算機システムによれば、辞書サーバ２のスキーママッピングによって、異なるスキーマを使用するシステム間でのデータ共有を容易にする効果がある。複雑なモジュラリティ構成を有するシステムにおいて、容データ共有や拡張が容易になり、可用性の高いシステム構成の実現に資するものである。
【００８４】
また、本計算機システムによれば、メタデータ及びメタデータインデクスの管理に、システムで共通の統合ＩＤを用いることから、サーバやストレージといったサブシステム間でのデータ管理が容易であるという利点がある。
以上が、第１実施形態の計算機システムである。
【００８５】
〔第１実施形態の変形例〕
上記、第１実施形態の計算機システム１００では、ＥＴＬ１から、ストレージサブシステム５のメタデータ更新が行われる際、サブシステム内に格納された実際の運用系データに対して更新処理が行われるように構成されている（図１２のＳ２２５／図１３）。
【００８６】
メタデータの更新処理中は、サブシステム内のメタデータ間のデータは不整合な状態となる。このような状態で、クライアントから検索要求を受けた検索サーバ３等から、サブシステム内のファイルにアクセスがあると、不整合な状態のファイルデータをクライアントに提供してしまうことも想定できる。
【００８７】
そこで、計算機システム１００の変形例として、ストレージサブシステム５のメタデータ更新処理中は、ファイルアクセス元に対してファイルデータが不整合な状態を見せないようにする計算機システム１１１の構成例を説明する。具体的には、変形例の計算機システム（以下、「計算機システム１１１」という。）では、メタデータ更新前にストレージサブシステム内の運用系データの格納領域（ボリューム）の複製が生成され、複製に対してメタデータ更新を行い、更新完了後に複製と運用系ボリュームが入れ替えられるようになっている（図１２のＳ２２５及び図１３が、後述の図１４の処理となる）。
【００８８】
計算機システム１００との構成の差異は、ＥＴＬ１の更新管理部１４である。変形例では、更新管理部１４を更新管理部１１４（不図示）として説明する。また、ストレージサブシステム５のコントローラ５１は、ボリューム構成を管理する機能を有するものとする。
【００８９】
ＥＴＬ１の更新管理部１１４では、ストレージサブシステム５のメタデータ更新時に、ファイル管理部１５３に運用系ボリュームの複製の作成指示を送信するようになっている。本変形例では、ボリュームの複製としてスナップショットを用いるものとする。その後、更新管理部１１４では、複製ボリューム内のメタデータに対して更新指示が行われる。更新指示には、第１実施形態の計算機システム１００と同様に、更新対象のメタデータに対応する統合ＩＤ５０、統一スキーマ形式に変換された項目名及び更新後の値が含まれる。全てのメタデータ更新の完了後、更新管理部１１４は、複製ボリュームと運用系ボリュームの入替えを指示するようになっている。
【００９０】
ストレージサブシステム５のコントローラ５１では、ＥＴＬ１からのボリューム複製要求及びボリューム入替え要求に応じて、運用系ボリュームのスナップショットによって複製ボリュームを生成する処理及び運用系ボリュームと複製ボリュームの入替処理を行うようになっている。
【００９１】
図１４に、計算機システム１１１における複製ボリュームを用いたメタデータ更新処理の流れを示す。
Ｓ３５１で、更新管理部１１４は、ストレージサブシステム５のコントローラ５１に、運用系ボリュームの複製を作成する指示を送信する。
Ｓ３５３で、コントローラ５１は、運用系ボリュームのスナップショットを生成し、複製ボリュームを作成する。
Ｓ３５５で、更新管理部１１４は、更新対象のメタデータに対応する統合ＩＤ５０、統一スキーマ形式に変換された項目名及び更新後の値が含まれたメタデータ更新要求を、複製ボリュームを対象に指定して送信する。
【００９２】
Ｓ３５７で、ファイル管理部５３は、更新対象となる複製Ｖｏｌ内のメタデータの更新を行い、Ｓ３５９で、更新完了通知を更新管理部１１４に送信する。
Ｓ３６１で、更新管理部１１４は、複製ボリュームと運用系ボリュームの入替え指示を送信する。
Ｓ３６３で、コントローラ５１は、複製ボリュームを運用系ボリュームとし、それまでの運用系ボリュームを運用系から外す入替えを行う。
以上が、複製ボリュームを用いたストレージ側のメタデータ更新である。
【００９３】
このように、変形例の計算機システム１１１によれば、メタデータ更新中のデータ不整合な状態をファイルアクセス元に提供することなくメタデータ更新を行うことができる。
【００９４】
〔第２実施形態〕
第１実施形態及びその変形例の計算機システムにおけるメタデータ更新処理は、外部システム７からメタデータの更新要求を受けた際、ＥＴＬ１から検索サーバ３に更新後のデータ内容を直接送付してメタデータインデクス４を更新させるようになっている。
【００９５】
第２実施形態の計算機システム２００は、メタデータの更新要求を受けたＥＴＬ１が、検索サーバ３に直接的にメタデータの更新要求を行わずに、更新内容を辞書サーバ２に保持しておくようになっている。検索サーバ３が、クライアントからの検索要求を受けたときには、辞書サーバ２に保持された更新内容に基づいて、検索要求の検索条件を更新後の内容が含まれた検索条件に変換し、メタデータインデクス４を検索するようになっている。
【００９６】
図１５に、第２実施形態における計算機システム２００の処理概要を示す。計算機システム２００は、第１実施形態と同様に、データソース６からのデータ収集、ストレージサブシステムへのデータの格納及び検索サーバ３のメタデータインデックス４の生成が行われる。本図では、既にこれらの処理が完了した後のメタデータ更新処理について模式的に示したものである。
【００９７】
Ｔ１０で、ＥＴＬ１は、外部システム７から更新要求を受ける。更新要求は、外部システム７のスキーマ形式で記述されており、「ＰＡＴ-ＩＤ：１００」の「ＰＡＴ-ＮＡＭＥ」を「鈴木一郎」に変更要求する内容である。
【００９８】
Ｔ１１で、ＥＴＬ１は、辞書サーバ２にスキーママッピング２７の生成及び送信を要求する。スキーママッピングは、統一スキーマ定義２３と更新要求スキーマ定義２６の各項目の対応関係を示すものである。
【００９９】
Ｔ１２で、ＥＴＬ１は、スキーママッピングを用いてストレージサブシステム５から更新対象となるメタデータを検索するためのスキーマｋｅｙを特定し、これを用いて更新対象メタデータに関連付けられた統一ＩＤ５０と、そのメタデータとを取得する。取得されたメタデータから、更新対象の項目に対応する更新前の値（「佐藤一郎」）を抽出する。そして、ストレージサブシステム５の内容を更新する。
【０１００】
Ｔ１３で、ＥＴＬ１は、抽出した更新前の値（「佐藤一郎」）と、外部システム７からの更新要求に含まれる更新後の値（「鈴木一郎」）と、「ＰＡＴ-ＮＡＭＥ」といった更新要求スキーマ定義２６で記述された項目を統一スキーマ定義２３の形式に変換した「ＰＮａｍｅ」とを、辞書サーバ２に送信し、格納させる（以下、これらが対応づけられた情報を「更新記録情報」という。）。
【０１０１】
Ｔ１４で、検索サーバ３は、クライアントから検索要求を受けると、検索サーバ３は、辞書サーバ２から更新記録情報とスキーママッピング２７を取得する。このスキーママッピング２７は、統一スキーマ２３と検索インデクススキーマ２５の各項目の対応を示すものである。
【０１０２】
Ｔ１５で、検索サーバ３は、クライアントの検索要求から検索条件「Ｐａｔｉｅｎｔ  Ｎａｍｅ：鈴木一郎」を抽出する。更に、マッピングテーブル２７を用いて、更新記録情報２３０の統一スキーマ定義２３の形式で記述された「ＰＮａｍｅ」を、検索インデクススキーマ定義２６の形式である「Ｐａｔｉｅｎｔ  Ｎａｍｅ」に変換する。検索サーバ３は、検索インデクススキーマ２６の形式に変換された更新記録情報２３０に、クライアントの検索条件「Ｐａｔｉｅｎｔ  Ｎａｍｅ：鈴木一郎」が含まれるか否かを判断し、含まれる場合、更新記録情報２３０の内容に変換されたクライアントの検索条件を新たに生成する。
【０１０３】
そして、変換後の検索条件で、メタデータインデクス４を検索し、その結果をクライアントに返すようになっている。
以上が、計算機システム２００でのメタデータ更新処理の概要である。
【０１０４】
図１６に、第２実施形態の計算機システム２００の構成を示す。第１実施形態等の計算機システム１００と主に相違する点は、ＥＴＬ１の更新管理部２１４と、辞書サーバ２の交信記録情報２３０と、検索サーバ３の検索部２３４が有する機能である。
【０１０５】
更新管理部２１４では、外部システム７からのメタデータ更新要求に応じて、スキーママッピング２７が取得される。その後、これに基づいて変換対象のメタデータの項目名が統一スキーマ定義２３の形式に変換され、更新する値及び更新前の値と共に辞書サーバ２に格納されるようになっている。
【０１０６】
辞書サーバ２から取得するスキーママッピング２７は、統一スキーマ定義２３（ストレージサブシステム５で使用するスキーマ形式）と、更新要求スキーマ定義２６（外部システム７で使用するスキーマ形式）との各項目の対応関係が示されたものである。外部システム７からのメタデータ更新要求には、例えば、「ＰＡＴ-ＩＤ：１００」の「ＰＡＴ-ＮＡＭＥ」を「佐藤一郎」から「鈴木一郎」に変更」する旨の情報が含まれる。更新管理部２１４では、「ＰＡＴ-ＮＡＭＥ：鈴木一郎」が統一スキーマ形式の「ＰＮａｍｅ:佐藤一郎ｏｒ鈴木一郎」に変換され、更新記録情報２３０として辞書サーバ２に格納されるようになっている。
【０１０７】
図１７に、更新記録情報２３０の一例を模式的に示す。更新記録情報２３０には、統一スキーマ名情報２３０ａ（「Ｍｅｄｉｃａｌ」）、統一スキーマ項目名情報２３０ｂ（「ＰＮａｍｅ）」、更新前メタデータ値情報２３０ｃ（「佐藤一郎」）及び更新後メタデータ情報２３０ｄ（「鈴木一郎）」が含まれ、これらが対応付けられて管理されるようになっている。統一スキーマ名２３０ａに格納されている「Ｍｅｄｉｃａｌ」は、図３で示した統一スキーマ定義２３を識別するための識別名である。ＥＴＬ１や検索サーバ３２は、辞書サーバ２の辞書管理部２９に対して、スキーマ名「Ｍｅｄｉｃａ」を指定して問合せることで、統一スキーマ定義２３を取得できる。
【０１０８】
図１６に戻り、検索サーバ３の検索部２３４では、更新記録情報２３０に基づいて、クライアントからの検索要求に含まれた検索条件に、更新後の値も含まれた検索条件が生成されるようになっている。即ちクライアントからの検索条件が、「Ｐａｔｉｅｎｔ  Ｎａｍｅ＝佐藤一郎」を含む場合、この条件に更新後の値である「鈴木一郎」を加えた「Ｐａｔｉｎｅｔ  Ｎａｍｅ＝佐藤一郎ｏｒ鈴木一郎」が含まれた検索条件が生成され、メタデータインデクス４が検索されるようになっている。
【０１０９】
より具体的には、クライアントからの検索要求を受信した検索サーバ３では、検索条件「Ｐａｔｉｅｎｔ  Ｎａｍｅ:鈴木一郎」が抽出される。他方、スキーママッピング２７に基づいて、統一スキーマ形式で記述された更新記録情報２３０の項目が検索インデクススキーマ形式に変換される。変換後の更新記録情報２３０に、抽出した検索条件「Ｐａｔｉｅｎｔ  Ｎａｍｅ:鈴木一郎」を含むものがある場合には、更新後の値である「鈴木一郎」が追加された検索条件に変換されるようになっている。
【０１１０】
その後、変換後の検索条件によってメタデータインデクス４が検索され、検索結果がクライアントに返信されることとなる。
以上が、計算機システム２００の構成である。
【０１１１】
次に、計算機システム２００の処理の流れを説明する。
図１８に、メタデータ更新処理の流れを示す。
Ｓ４０１で、ＥＴＬ１は、外部システム７からメタデータ更新要求（「ＰＡＴ−ＩＤ：１００」、「ＰＡＴ-ＮＡＭＥ：鈴木一郎」）を受信する。
Ｓ４０３で、ＥＴＬ１は、辞書サーバ３にスキーママッピング２７の生成及び取得要求を送信し、統一スキーマ定義２３と更新要求スキーマ定義２６の各項目が対応付けられたスキーママッピングを取得する。
【０１１２】
Ｓ４０５で、ＥＴＬ１は、スキーママッピング２７を参照して、更新要求内で更新対象のメタデータ識別する項目である「ＰＡＴ-ＩＤ」に対応する統一スキーマ定義項目名（「ＰＩＤ」）を特定する。更に、「ＰＩＤ」と、「ＰＡＴ-ＩＤ」に対応する値である「１００」とから、スキーマｋｅｙ「ＰＩＤ：１００」を得る。
【０１１３】
Ｓ４０７で、ＥＴＬ１は、スキーマｋｅｙ「ＰＩＤ:１００」を指定して、ストレージサブシステム５に格納されたメタデータ５１の検索を行う。
Ｓ４０９で、ＥＴＬ１は、検索結果であるメタデータ５１と、そのメタデータに関連付けられた統一ＩＤ５０を取得する。
【０１１４】
Ｓ４１１で、ＥＴＬ１は、スキーママッピング２７を参照して、外部システム７からのメタデータ更新要求の中から、更新対象となる項目名（「Ｐａｔｉｅｎｔ  Ｎａｍｅ」）に対応する統一スキーマ定義項目名（「ＰＮａｍｅ」）を特定する。
【０１１５】
Ｓ４１３で、ＥＴＬ１は、Ｓ４０９で取得したストレージサブシステム５に格納されていたメタデータから、更新対象項目である「ＰＮａｍｅ」の値（「佐藤一郎」／更新前の値）を抽出し、Ｓ４１１で取得した統一スキーマ項目名「ＰＮａｍｅ」と、外部システム７からの更新要求に含まれる更新対象項目の値（「鈴木一郎」／更新後の値）とを辞書サーバ２に送信する。辞書サーバ２は、これらを対応付けて更新記録情報２３０として保持する。
【０１１６】
Ｓ４１５で、ＥＴＬ１は、更新要求元である外部システム７にメタデータ更新を受け付けた旨を送信する。そして、Ｓ４１７で、Ｓ４０７で特定した統一ＩＤに基づいて、ストレージサブシステム５のメタデータの更新を行う。
以上が、メタデータ更新処理である。
【０１１７】
次に、このようにして保持された更新記録情報２３０を用いて、クライアントからの検索要求を処理する検索サーバ３の検索処理について説明する。
図１９に、更新記録情報２３０を用いたメタデータ検索処理の流れを示す。
Ｓ５０１で、検索サーバ３の検索部２３４は、クライアントからの検索要求を受ける。検索要求は、更新後のメタデータの値で送信されてくるものとする（「鈴木一郎」を検索条件とする。）。また、検索要求は、検索サーバ３のスキーマ定義である検索インデクススキーマ定義２５の形式を有する。本例では、「Ｐａｔｉｅｎｔ  Ｎａｍｅ：鈴木一郎」を検索条件としてクライアントから検索要求されるものとする。
【０１１８】
Ｓ５０３で、辞書参照部３５は、辞書サーバ２に、スキーママッピング２７の生成・取得要求を送信し、これを取得する。このスキーママッピング２７は、統一スキーマ定義２３と検索インデクススキーマ定義２５の項目名の対応を示すものである。
また、Ｓ５０５で、辞書参照部３５は、辞書サーバ２に、更新記録情報２３０の取得要求を送信し、これを取得する。
【０１１９】
Ｓ５０７で、検索部２３４は、スキーママッピング２７を参照し、統一スキーマ定義２３で記述された更新記録情報２３０の項目を、検索インデクススキーマ定義２５の形式に変換する。即ち更新記録情報２３０上で患者姓名を示す「ＰＮａｍｅ」を、「Ｐａｔｉｅｎｔ  Ｎａｍｅ」に変換し、項目名「Ｐａｔｉｅｎｔ  Ｎａｍｅ」、更新前メタデータ値「佐藤一郎」、更新後メタデータ値「鈴木一郎」の更新記録情報２３０を得る。
【０１２０】
Ｓ５０９で、検索部２３４は、Ｓ５０７で得た検索インデクススキーマ形式の更新記録情報２３０が、クライアント検索条件「Ｐａｔｉｅｎｔ  Ｎａｍｅ：鈴木一郎」を含むか否かを判断する。含む場合（S509：Yes）、Ｓ５１１に進み、含まない場合（S509：No）、Ｓ５１３に進む。
【０１２１】
Ｓ５１１で、検索部２３４は、スキーマ形式が変換された更新記録情報２３０に基づいて、クライアントからの検索条件を、新たに生成する。即ちクライアントからの検索条件を、「Ｐａｔｉｅｎｔ  Ｎａｍｅ：鈴木一郎」から、「Ｐａｔｉｅｎｔ  Ｎａｍｅ：鈴木一郎ｏｒ佐藤一郎」に変更する。
Ｓ５１３で、検索部２３４は、変更後の検索条件で、メタデータインデクス４の検索を行い、Ｓ５１５で、クライアントに検索結果を返信する。
以上が、検索処理である。
【０１２２】
このように、第２実施形態の計算機２００によれば、メタデータ更新が発生した際、既存のメタデータインデクス４自体を更新することがなく、メタデータインデクス更新負荷が発生しないという効果がある。
【０１２３】
また、クライアントからの検索要求単位でメタデータの更新が反映されたメタデータ検索が可能となる。
【０１２４】
ＥＴＬ１の処理負荷の増加を防止する効果がある。ＥＴＬ１は、ストレージサブシステム５とのデータ格納処理やメタデータ更新処理を始め、データ収集、メタデータ更新要求受付及びスキーマ変換等の処理にも負荷が発生する。メタデータインデクス４の更新処理において、処理負荷を検索サーバ３に移譲できるという効果がある。
【０１２５】
以上、本発明を実施するための形態について説明したが、本発明は、上記種々の例に限定されるものではなく、その趣旨の範囲において種々の構成や処理順序で実現できるものである。
【０１２６】
例えば、上述の実施形態では、各スキーマ形式のメタデータ単位でも格納処理や更新処理の例を説明したが、スキーマの全ての項目を更新可能に構成せずに、更新可能な共通項目とそれ以外の項目に分けて管理してもよい。例えば、患者名に関する部分ついては共通項目として共通メタファイルとして管理し、それに付随する検査履歴についてはこの共通メタデータに紐付けて管理するようにしてもよい。この場合、特定のメタデータについて更新処理を行う際、患者名に関する項目を有する共通メタデータのみを処理の対象とればよく、その他の項目のメタデータは処理対象とならないため、扱うデータ量が減る分、種々の処理負荷かが低減するといいう利点がある。
【０１２７】
更に、メタデータを実データと独立して管理する構成例を示したが、メタデータを実データの付帯情報として管理するデータ管理方法に本発明を適用することも当然に可能である。但し、この構成の場合、メタデータに加えて実データもシステム内の処理に付帯させる必要があるので、種々の処理で扱うデータ量が多くなるという虞もある。
そこで、メタデータの一部又は全部の項目に対するポインタ情報として、実メタデータのポインタファイル（ダミーファイル）を設けて、このポインタファイルを上述のメタデータのように指定して更新処理を行うように構成すると好ましい。
【０１２８】
なお、上記実施形態等で説明した種々のプログラムは、磁気的及び／又は電子的な非一時的な可搬性の記録媒体に記録することもできるし、ネットワークを介して計算機システムにインストールすることも可能であることはいうまでもない。
【符号の説明】
【０１２９】
１・・・ＥＴＬ１、２・・・辞書サーバ、３・・・検索サーバ、４・・・メタデータインデクス、５・・・ストレージサブシステム、６・・・データソース、７・・・外部システム、２３・・・統一スキーマ、２４・・・画像スキーマ、２５・・・インデクススキーマ、２６・・・更新要求スキーマ、２７・・・スキーママッピング、５０ａ・５０ｂ・・・統一ＩＤ、６０ａ・６０ｂ・・・画像ファイル、５１ａ・５１ｂ・・・メタデータ
【図１】
2014122732.tif 000003
【図２】
2014122732.tif 000004
【図３】
2014122732.tif 000005
【図４】
2014122732.tif 000006
【図５】
2014122732.tif 000007
【図６】
2014122732.tif 000008
【図７】
2014122732.tif 000009
【図８】
2014122732.tif 000010
【図９】
2014122732.tif 000011
【図１０】
2014122732.tif 000012
【図１１】
2014122732.tif 000013
【図１２】
2014122732.tif 000014
【図１３】
2014122732.tif 000015
【図１４】
2014122732.tif 000016
【図１５】
2014122732.tif 000017
【図１６】
2014122732.tif 000018
【図１７】
2014122732.tif 000019
【図１８】
2014122732.tif 000020
【図１９】
2014122732.tif 000021
【国際調査報告】
2014122732.tif 000022
2014122732.tif 000023