(57)【要約】【課題】  データの格納場所が分散する場合においても正しくかつ効率的にデータにアクセスできる情報管理システムを提供すること。【解決手段】  マスタデータベースサーバ３が、データベースのデータからキャッシュデータを作成する処理方法と、作成されたキャッシュデータの更新先となるキャッシュサーバ２の場所と、を関連付けてロジックとして記録する手順と、マスタデータベースサーバ３がクライアント端末１から受信したデータをデータベースに登録する手順と、マスタデータベースサーバ３がロジックを基にして、データベースに登録されたデータからキャッシュデータを作成する手順と、マスタデータベースサーバ３がロジックを基にして作成されたキャッシュデータを送信してキャッシュサーバ２に登録させる手順と、を実行することを特徴とする。【選択図】      図１
2005196382.tif 000002
【特許請求の範囲】
【請求項１】
データベースを保持するマスタデータベースサーバと、前記データベースの内容の少なくとも一部を保持するキャッシュサーバと、を含んで構成される情報管理システムによるデータ登録方法であって、
前記マスタデータベースサーバが前記データベースのデータからキャッシュデータを作成する処理方法と、前記作成されたキャッシュデータの更新先となる前記キャッシュサーバの場所と、を関連付けてロジックとして記録する手順と、前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行ったクライアント端末に対して前記データベースに登録するデータを入力させるための入力用フォームを送信する手順と、前記マスタデータベースサーバが前記入力用フォームにデータが入力された入力済フォームを受信する手順と、前記マスタデータベースサーバが前記入力済フォームのデータを前記データベースに登録する手順と、
前記マスタデータベースサーバが前記ロジックを基にして、前記データベースに登録されたデータから前記キャッシュデータを作成する手順と、前記マスタデータベースサーバが前記ロジックを基にして作成されたキャッシュデータを送信して前記キャッシュサーバに登録させる手順と、を実行することを特徴とするデータ登録方法。
【請求項２】
前記マスタデータベースサーバが、前記キャッシュデータを作成する手順は、前記キャッシュサーバの場所ごとに前記キャッシュデータを作成し、前記キャッシュサーバに登録させる手順は、前記キャッシュサーバの場所ごとに作成された前記キャッシュデータを登録させることを特徴とする請求項１に記載のデータ登録方法。
【請求項３】
前記マスタデータベースサーバが格納する前記データベースのデータはクラスの集合として構成され、前記クラスは少なくとも１つの属性を有するものとし、前記入力用フォームを送信する手順は、前記クラスが有する属性を入力欄として作成された前記入力用フォームを送信することを特徴とする請求項１または請求項２に記載のデータ登録方法。
【請求項４】
前記データ登録方法は、前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行った前記クライアント端末を認証する手順、および、前記認証する手順の結果が前記データベースのデータに関連付けられたポリシに適合するかどうかを検証する手順を含むものとし、前記入力済フォームのデータを前記データベースに登録する手順は、前記検証する手順に適合したデータについてのみ、前記データベースに登録することを特徴とする請求項１ないし請求項３のいずれか１項に記載のデータ登録方法。
【請求項５】
データベースを保持するマスタデータベースサーバを含んで構成される情報管理システムによるデータ参照方法であって、
前記データベースによって管理されるデータは、少なくとも１つの属性を有するクラスの集合として構成され、前記データベースは、前記クラスと、前記クラスの属性名と、前記クラスの属性値の格納場所を示すデータロケーションと、対応関連を管理するクラスデータベースと、前記クラスの属性値を管理するマスタデータベースとして構成され、
前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行ったクライアント端末から検索条件の入力を受信する手順と、前記マスタデータベースサーバが前記検索条件に含まれる属性名を有するクラスを前記クラスデータベースから検索する手順と、前記マスタデータベースサーバが前記クラスデータベースから検索されたクラスに対応する属性値を、前記データロケーションを用いて前記マスタデータベースから取得する手順と、前記マスタデータベースサーバが前記取得した属性値および前記検索条件に含まれる属性名との組を含めた検索結果を前記クライアント端末に送信する手順と、を実行することを特徴とするデータ参照方法。
【請求項６】
前記クラスデータベースは、前記クラス間における上位概念および下位概念の関連を示す情報を含めて保持するものとし、前記クラスデータベースから検索する手順は、前記検索条件に含まれる前記属性名を有するクラスが抽出された場合に、前記属性名を有するクラスの下位概念となるクラスを抽出されたものとみなすことを特徴とする請求項５に記載のデータ参照方法。
【請求項７】
前記データ参照方法は、前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行ったクライアント端末を認証する手順、および、前記認証する手順の結果が前記クラスに関連付けられたポリシに適合するかどうかを検証する手順を含むものとし、前記検索結果を前記クライアント端末に送信する手順は、前記検証する手順に適合したデータについてのみ、前記クライアント端末に送信することを特徴とする請求項５または請求項６に記載のデータ参照方法。
【請求項８】
データベースを保持するマスタデータベースサーバと、前記データベースの内容の少なくとも一部を保持するキャッシュサーバと、を含んで構成される情報管理システムによるデータ参照方法であって、
前記キャッシュサーバが前記キャッシュサーバにアクセスを行ったクライアント端末から検索条件を受信する手順と、前記キャッシュサーバが前記検索条件に適合するデータを前記キャッシュサーバ内のキャッシュデータベースから検索する手順と、前記キャッシュサーバが前記検索条件に適合するデータが前記キャッシュサーバ内に存在しない場合には、前記検索条件を含む検索要求を前記マスタデータベースサーバに送信する手順と、を実行することを特徴とするデータ参照方法。
【請求項９】
管理対象となるデータを保持するマスタデータベースサーバであって、前記マスタデータベースサーバは、少なくとも１つの属性を有するクラスの集合として構成される前記管理対象となるデータを、前記クラスと、前記クラスの属性名と、前記属性名に対応する属性値の格納場所を示すデータロケーションと、対応関連を管理するクラスデータベースと、前記クラスの属性値を管理するマスタデータベースと、に分離して管理する構成とすることを特徴とするマスタデータベースサーバ。
【請求項１０】
前記マスタデータベースサーバは、前記管理対象となるデータの処理に対する許可情報を示すポリシを保持するポリシ記録部と、前記ポリシに関する検証処理を行うポリシ処理部と、を含めて構成することを特徴とする請求項９に記載のマスタデータベースサーバ。
【請求項１１】
前記マスタデータベースサーバは、前記管理対象となるデータからキャッシュデータの作成処理方法および作成された前記キャッシュデータの更新先の場所を示すロジックを記録するロジック記録部と、前記ロジックに従ってキャッシュデータを更新するロジック処理部と、を含めて構成することを特徴とする請求項９または請求項１０に記載のマスタデータベースサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報管理システムによるデータ登録方法、データ参照方法、ならびに、情報管理システムにおけるマスタデータベースサーバに関する。
【背景技術】
【０００２】
行政サービスなどの様々な業務がコンピュータによって実現される環境が普及し始めている（例えば、特許文献１参照）。これらのサービスを行う場合に、サービスに使用されるデータは、例えば、データベース（以下、適宜ＤＢ（Data Base）と表記する）によって管理されている。データベースは、２次元の表形式でデータを管理するリレーショナルデータベースなどの種類がある（特許文献１など）。
【０００３】
データベースは、サービスを行うアプリケーションソフトと連携して、データの登録およびデータの参照を行う。つまり、アプリケーションソフトは、データの登録およびデータの参照などのデータへのアクセスが発生した場合に、データベースにそれらのアクセスを依頼する。アクセスの依頼を受けたデータベースは、その依頼に適合するようなデータの読み書きを実現する。なお、データを参照する場合の検索条件を記述するために、例えば、ＳＱＬ（Structured Query Language）などのデータベース用の言語が使用されている。
【特許文献１】特開２００１−２５６０８５号公報（段落０００７）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ここで、円滑なサービスを実現するためには、サービスに使用されるデータは、正しくかつ効率的にアクセスできるように管理されていることが必要となる。例えば、同一の概念を示すデータ（Ａ氏の住所など）が、データを担当する行政の区分などの理由により、複数の場所に分かれて保存されている場合がある。その場合、そのデータを更新する際には、保存されている複数の場所について、同時に同一のデータに更新する必要がある。そうしないと、同一の概念を示すデータに不整合が発生して、サービスの円滑な運営に支障をきたしてしまう。
【０００５】
また、データの増加に伴って、個々のデータに対する検索処理量も増加する。よって、効率的にアクセスするためには、個々のデータに対する検索処理に対して、データの増加の影響が受けにくいような検索手法が必要となる。そうしないと、例えば、住民全員を扱うような行政システムなどにおいて、データ量の増加によって、システムの運用が困難になる。
【０００６】
そこで、本発明では、前記した問題を解決し、データの格納場所が分散する場合においても正しくかつ効率的にデータにアクセスできる情報管理システムを提供することを主な目的とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するため、請求項１に記載のデータ登録方法は、データベースを保持するマスタデータベースサーバと、前記データベースの内容の少なくとも一部を保持するキャッシュサーバと、を含んで構成される情報管理システムによるデータ登録方法であって、
前記マスタデータベースサーバが前記データベースのデータからキャッシュデータを作成する処理方法と、前記作成されたキャッシュデータの更新先となる前記キャッシュサーバの場所と、を関連付けてロジックとして記録する手順と、前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行ったクライアント端末に対して前記データベースに登録するデータを入力させるための入力用フォームを送信する手順と、前記マスタデータベースサーバが前記入力用フォームにデータが入力された入力済フォームを受信する手順と、前記マスタデータベースサーバが前記入力済フォームのデータを前記データベースに登録する手順と、
前記マスタデータベースサーバが前記ロジックを基にして、前記データベースに登録されたデータから前記キャッシュデータを作成する手順と、前記マスタデータベースサーバが前記ロジックを基にして作成されたキャッシュデータを送信して前記キャッシュサーバに登録させる手順と、を実行することを特徴とする。
【０００８】
請求項２に記載のデータ登録方法は、請求項１に記載のデータ登録方法であって、前記マスタデータベースサーバが、前記キャッシュデータを作成する手順は、前記キャッシュサーバの場所ごとに前記キャッシュデータを作成し、前記キャッシュサーバに登録させる手順は、前記キャッシュサーバの場所ごとに作成された前記キャッシュデータを登録させることを特徴とする。
【０００９】
請求項３に記載のデータ登録方法は、請求項１または請求項２に記載のデータ登録方法であって、前記マスタデータベースサーバが格納する前記データベースのデータはクラスの集合として構成され、前記クラスは少なくとも１つの属性を有するものとし、前記入力用フォームを送信する手順は、前記クラスが有する属性を入力欄として作成された前記入力用フォームを送信することを特徴とする。
【００１０】
請求項４に記載のデータ登録方法は、請求項１ないし請求項３のいずれか１項に記載のデータ登録方法であって、前記データ登録方法は、前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行った前記クライアント端末を認証する手順、および、前記認証する手順の結果が前記データベースのデータに関連付けられたポリシに適合するかどうかを検証する手順を含むものとし、前記入力済フォームのデータを前記データベースに登録する手順は、前記検証する手順に適合したデータについてのみ、前記データベースに登録することを特徴とする。
【００１１】
請求項５に記載のデータ参照方法は、データベースを保持するマスタデータベースサーバを含んで構成される情報管理システムによるデータ参照方法であって、
前記データベースによって管理されるデータは、少なくとも１つの属性を有するクラスの集合として構成され、前記データベースは、前記クラスと、前記クラスの属性名と、前記クラスの属性値の格納場所を示すデータロケーションと、対応関連を管理するクラスデータベースと、前記クラスの属性値を管理するマスタデータベースとして構成され、
前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行ったクライアント端末から検索条件の入力を受信する手順と、前記マスタデータベースサーバが前記検索条件に含まれる属性名を有するクラスを前記クラスデータベースから検索する手順と、前記マスタデータベースサーバが前記クラスデータベースから検索されたクラスに対応する属性値を、前記データロケーションを用いて前記マスタデータベースから取得する手順と、前記マスタデータベースサーバが前記取得した属性値および前記検索条件に含まれる属性名との組を含めた検索結果を前記クライアント端末に送信する手順と、を実行することを特徴とする。
【００１２】
請求項６に記載のデータ参照方法は、前記クラスデータベースは、前記クラス間における上位概念および下位概念の関連を示す情報を含めて保持するものとし、前記クラスデータベースから検索する手順は、前記検索条件に含まれる前記属性名を有するクラスが抽出された場合に、前記属性名を有するクラスの下位概念となるクラスを抽出されたものとみなすことを特徴とする請求項５に記載の。
【００１３】
請求項７に記載のデータ参照方法は、請求項５または請求項６に記載のデータ参照方法であって、前記データ参照方法は、前記マスタデータベースサーバが前記マスタデータベースサーバにアクセスを行ったクライアント端末を認証する手順、および、前記認証する手順の結果が前記クラスに関連付けられたポリシに適合するかどうかを検証する手順を含むものとし、前記検索結果を前記クライアント端末に送信する手順は、前記検証する手順に適合したデータについてのみ、前記クライアント端末に送信することを特徴とする。
【００１４】
請求項８に記載のデータ参照方法は、データベースを保持するマスタデータベースサーバと、前記データベースの内容の少なくとも一部を保持するキャッシュサーバと、を含んで構成される情報管理システムによるデータ参照方法であって、
前記キャッシュサーバが前記キャッシュサーバにアクセスを行ったクライアント端末から検索条件を受信する手順と、前記キャッシュサーバが前記検索条件に適合するデータを前記キャッシュサーバ内のキャッシュデータベースから検索する手順と、前記キャッシュサーバが前記検索条件に適合するデータが前記キャッシュサーバ内に存在しない場合には、前記検索条件を含む検索要求を前記マスタデータベースサーバに送信する手順と、を実行することを特徴とする。
【００１５】
請求項９に記載のマスタデータベースサーバは、管理対象となるデータを保持するマスタデータベースサーバであって、前記マスタデータベースサーバは、少なくとも１つの属性を有するクラスの集合として構成される前記管理対象となるデータを、前記クラスと、前記クラスの属性名と、前記属性名に対応する属性値の格納場所を示すデータロケーションと、対応関連を管理するクラスデータベースと、前記クラスの属性値を管理するマスタデータベースと、に分離して管理する構成とすることを特徴とする。
【００１６】
請求項１０に記載のマスタデータベースサーバは、請求項９に記載のマスタデータベースサーバであって、前記マスタデータベースサーバは、前記管理対象となるデータの処理に対する許可情報を示すポリシを保持するポリシ記録部と、前記ポリシに関する検証処理を行うポリシ処理部と、を含めて構成することを特徴とする。
【００１７】
請求項１１に記載のマスタデータベースサーバは、請求項９または請求項１０に記載のマスタデータベースサーバであって、前記マスタデータベースサーバは、前記管理対象となるデータからキャッシュデータの作成処理方法および作成された前記キャッシュデータの更新先の場所を示すロジックを記録するロジック記録部と、前記ロジックに従ってキャッシュデータを更新するロジック処理部と、を含めて構成することを特徴とする。
【発明の効果】
【００１８】
このような情報管理システムおよびその使用方法によれば、管理対象となるデータは、クラスを管理するクラスデータベースと、クラスの属性値を管理するマスタデータベースとに分離して管理される。よって、属性値を管理するマスタデータベースが物理的に分散されて配置された場合においても、クラスデータベースがそれらの分散されたマスタデータベースに格納されたデータを一元管理する。これにより、データの整合性が保たれ、正しくデータにアクセスすることが可能となる。
【００１９】
また、情報管理システムおよびその使用方法によれば、検索処理は、クラスデータベース内の属性名からの第１の検索と、マスタデータベース内の属性値からの第２の検索、の２段階に分けて検索される。そして、第１の検索で抽出された検索結果の候補は、属性値を参照されずに選ばれるので、属性値のデータ量の増加には、全く影響を受けずに済む。したがって、データ量の増加の影響が受けづらい効率的なデータアクセスが可能となる。
【発明を実施するための最良の形態】
【００２０】
以下に、本発明が適用される情報管理システムの一実施形態について、図面を参照して詳細に説明する。まず、本実施形態の情報管理システムの構成について、図１から図５を参照して説明する。
【００２１】
図１は、情報管理システムの構成図である。情報管理システムは、管理するデータを効率的にアクセスさせる機能を有する。このため、情報管理システムは、データベースへのアクセスをする際に使用されるクライアント端末１と、データベースの内容の少なくとも一部を保持するキャッシュサーバ２と、データベースの内容を保持するマスタＤＢサーバ３と、を含んで構成される。なお、情報管理システムを構成する各装置は、ネットワークによって接続されている。
【００２２】
キャッシュサーバ２は、データベースの内容の少なくとも一部であるキャッシュデータを保持するキャッシュＤＢ２１と、キャッシュデータに関する処理を行うキャッシュＤＢ処理部２２と、キャッシュデータに対する許可情報となるポリシを保持するポリシ記録部２３と、ポリシに関する処理を行うポリシ処理部２４と、を含んで構成される。
【００２３】
マスタＤＢサーバ３は、属性値へのデータロケーションを有するクラスＤＢ３１と、クラスに関する処理を行うクラスＤＢ処理部３２と、データベースの内容を保持するマスタＤＢ３３と、データベースの内容に関する処理を行うマスタＤＢ処理部３４と、データベースの内容の処理に対する許可情報となるポリシを保持するポリシ記録部３５と、ポリシに関する処理を行うポリシ処理部３６と、キャッシュデータの作成方法および作成されたキャッシュデータの更新先を示すロジックを格納するロジック記録部３７と、ロジックに従ってキャッシュデータを更新するロジック処理部３８と、を含んで構成される。
【００２４】
図２および図３は、クラスＤＢ３１の構成図である。図２は、管理する対象となるデータの関連をグラフで表記したものであり、図３（Ａ）および図３（Ｂ）は、図２のグラフをデータとして管理するためのデータ構造を示すものである。
【００２５】
まず、図２に示されるグラフは、１つのデータ（概念）を１つの丸で示し、その丸の中にデータ（概念）の名称（“人間”、“著作者”、“音楽家”など）を記している。以降、これらの各データ（概念）の単位を、“クラス”と呼ぶことにする。そして、図２に示されるグラフは、クラスとクラスとの間を、矢印でつないでいる。これは、矢印で接続されたクラス間に、上位概念（スーパークラス）／下位概念（サブクラス）の関連があることを示している。つまり、矢印の元となるクラスは、矢印の先となるクラスの上位概念に相当する。例えば、矢印の元となる“人間”は、矢印の先となる“著作者”および“評論家”の上位概念に相当する。なお、クラス間の関連（上位概念／下位概念）を矢印として示したが、これはあくまで関連の一例であり、複数のクラスが同一の概念を示す同義関連など、上位概念／下位概念とは別の関連を示すことも可能である。なお、同義関連は、双方向の矢印によって示されている。
【００２６】
また、図３（Ａ）に示される表は、図２に示される１つのクラスを、１つのレコード単位としたデータ構造を示すものである。図３（Ａ）に示される表の各レコードは、レコードを識別するためのクラスＩＤと、クラスの名称を示すクラス名と、レコードからみて上位概念となるクラスのクラスＩＤと、レコードからみて下位概念となるクラスのクラスＩＤと、レコードが有する属性ＩＤのリストと、レコードに対応するデータの格納先を示すデータロケーションＩＤと、同義関連のクラスＩＤと、データの利用許可情報を示すポリシインスタンスと、ロジックインスタンスと、を含めて構成される。
【００２７】
ここで、データロケーションＩＤの表記形式について、図３（Ａ）では簡略化した文字列としたが、データの格納先となるコンピュータのアドレスと、そのコンピュータ内にＤＢが複数存在する場合における格納先となるＤＢを特定する情報と、格納先となるＤＢが複数のテーブルを有している場合における格納先となるテーブルを特定する情報と、格納先となるテーブルにおける格納する場所（変数名）を示す情報と、の組として表現される。
【００２８】
なお、属性名とは、各クラスが有する固有の情報である属性の名称であり、例えば、図３（Ａ）および図３（Ｂ）によると、クラス名“人間”は、“氏名”、“年齢”、“性別”という３つの属性をもつことが示されている。なお、属性名（例えば“年齢”）に対応する属性値（例えば“２０歳”）は、クラスＤＢの内部に保有するのではなく、マスタＤＢ３３に格納され、データロケーションＩＤからマスタＤＢ３３内の属性値にアクセスできる。つまり、各クラスが有する属性名と、属性名に対応する属性値とを分離して管理する構成が、本発明の特徴となる。これにより、クラスＤＢ３１では、属性名を用いた検索処理が可能となる。
【００２９】
そして、図４（Ａ）は、マスタＤＢ３３の構成図を示し、図４（Ｂ）は、ポリシ記録部３５の構成図を示し、図４（Ｃ）は、ロジック記録部３７の構成図を示している。
【００３０】
図４（Ａ）の各レコードは、図３（Ａ）に示した各レコード（クラスの情報）からデータロケーションＩＤによって参照されるデータである。１つのクラス（例えば“著作者”）は、複数の属性（例えば“氏名”、“年齢”、“性別”、“著作物”、“著作種別”）をもってもよい。そして、各属性は、属性名（例えば“年齢”）と属性値（例えば“２３歳”）との組として構成される。また、図４（Ａ）の各レコードは、そのレコードに関連するポリシインスタンスおよびロジックインスタンスも併せて、対応付けられている。
【００３１】
図４（Ｂ）の各レコードは、図４（Ａ）に示した各レコード（クラスの情報）からポリシＩＤによって参照されるデータである。１つのポリシインスタンスは、複数の属性（例えば“参照可能な主体”、“書き換え可能な主体”、“参照可能期間”、“利用目的”）をもってもよい。そして、各属性は、ポリシの属性名（例えば“参照可能期間”）とポリシの属性値（例えば“２０００年４月〜２００３年３月”）との組として構成される。ここで、“参照可能な主体”とは、クライアント端末１から、あるデータ（例えば“Ａ氏”というデータ）を参照させる際のアクセス制限を示すものである。例えば、“参照可能な主体”が“一般会員のみ”とは、“一般会員がクライアント端末１を介して所定のデータを参照する”という処理を許可するが、“非会員がクライアント端末１を介して所定のデータを参照する”という処理を拒絶するという制限となる。なお、これらのポリシは、例えばＸＡＣＭＬ(eXtensible Access Control Markup Language)に従って表記される。
【００３２】
図４（Ｃ）の各レコードは、図４（Ａ）に示した各レコード（クラスの情報）からロジックインスタンスによって参照されるデータである。ここでは、１つのクラス（データロケーションＩＤが“ｂｂｂ”となる）が、複数の更新先のキャッシュサーバ２に反映される例を示している。つまり、マスタＤＢ３３に格納されているデータロケーションＩＤ“ｂｂｂ”に対応するデータは、アドレス“８０１”、“８０２”、“８０３”という３つのキャッシュサーバ２にそれぞれ更新される。なお、ロジック記録部３７は、マスタＤＢ３３に格納されているデータをそのまま更新先のキャッシュサーバ２に送信する替わりに、マスタＤＢ３３に格納されているデータに、加工処理（ロジックの属性値に対応）を施してから更新先のキャッシュサーバ２に送信してもよい。
【００３３】
なお、図４（Ｃ）は、加工処理の一例として、各キャッシュサーバ２への更新処理をマシンごとに異なる処理とする一例を示している。このように、ロジックの属性値をマシンごとに登録しておくことにより、同一のデータから、キャッシュサーバ２ごとに異なるロジックの属性値を実現できるので、マシンごとの柔軟なキャッシュデータの更新が可能となる。
【００３４】
図５は、キャッシュＤＢ２１の構成図である。なお、図５（Ａ）のキャッシュＤＢ２１は、アドレス“８０１”のキャッシュサーバ２に存在する。なお、キャッシュＤＢ２１は、一時保管するデータに加え、そのデータのマスタＤＢサーバ３における格納場所を示す図５（Ｂ）に示すような“情報ソース情報”を含める。この“情報ソース情報”は、キャッシュされたデータが、どのマスタＤＢサーバ３のクラスから更新されたかを示すものである。また、キャッシュＤＢ２１に格納されたデータのアクセス許可情報を示すポリシは、マスタＤＢサーバ３と同様に、ポリシ記録部２３に記録されている。
【００３５】
以上、情報管理システムの構成について、説明した。次に、本実施形態の情報管理システムの動作について、説明する。情報管理システムの動作は、主に３つに分類できる。第１の動作は、クライアント端末１から入力されたデータを、マスタＤＢサーバ３およびキャッシュサーバ２に書き込むデータ登録の処理である。第２の動作は、クライアント端末１から入力された検索条件を基にしたマスタＤＢサーバ３からのデータ参照である。第３の動作は、クライアント端末１から入力された検索条件を基にしたキャッシュサーバ２からのデータ参照である。これらの動作の関連は、データ登録（第１の動作）が行われた後、マスタＤＢサーバ３からのデータ参照（第２の動作）またはキャッシュサーバ２からのデータ参照（第３の動作）が行われる。まず、本実施形態の情報管理システムの動作のうち、データ登録の処理について、図１から図５を参照しつつ、図６に示すフローチャートに沿って説明する。
【００３６】
図６は、データ登録の処理を示すフローチャートである。まず、マスタＤＢサーバ３は、クライアント端末１からのアクセスに応じて、認証処理を行う（Ｓ１０１）。認証処理は、例えば、クライアント端末１が送信したユーザＩＤとパスワードとの組が、マスタＤＢサーバ３に登録されている場合に、マスタＤＢサーバ３がそのクライアント端末１のアクセスを許可し、ログインさせる処理である。
【００３７】
次に、マスタＤＢサーバ３は、クライアント端末１にデータを入力させるための入力用フォームを作成し、その入力用フォームをクライアント端末１に送信する（Ｓ１０２）。ここで、入力用フォームは、クラスＤＢ３１に格納されたデータに従って作成される。例えば、“音楽家”に関するデータを入力させる入力用フォームを作成する場合、クラスＤＢ処理部３２は、クラスＤＢ３１から“音楽家”に対応するクラスを検索し、そのクラスに含まれる属性名“氏名、年齢、性別、著作物（音楽）”を、それぞれ入力用フォームの入力欄とする。
【００３８】
また、クラスＤＢ３１は、各属性名に対して、その属性名に対応する属性値の入力形式を特定する情報を有してもよい。例えば、属性名“年齢”は、入力形式が整数値という形式に特定される（図３（Ｂ）参照）。そして、入力用フォームの入力欄は、予めクラスＤＢ３１に登録された入力形式を特定する情報に従った形式のものとなる（例えば整数値以外の文字列を入力すると、警告を出すようなテキスト入力欄）。これにより、例えば、属性名“年齢”に、“東京都”を入力するなどの入力ミスを低減することが可能となる。そして、クライアント端末１は、受信した入力用フォームにデータを入力し、入力済フォームをマスタＤＢサーバ３に返信する（Ｓ１０３）。
【００３９】
さらに、マスタＤＢサーバ３は、ポリシの検証（Ｓ１０４）を行う。ポリシの検証は、例えば、認証処理（Ｓ１０１）によって特定されたユーザが、ポリシにおける“書換可能な主体”に適合するかを検証する処理である。なお、ポリシの検証に失敗（不適合）した場合、入力済フォームのデータは、マスタＤＢサーバ３への登録が許可されていないため、破棄される。そして、ポリシの検証に成功した場合には、マスタＤＢサーバ３は、入力済フォームの内容をデータベース（マスタＤＢ３３）に保存する（Ｓ１０５）。
【００４０】
また、マスタＤＢサーバ３は、データベースに保存された内容を基にしてキャッシュサーバ２のキャッシュの更新（Ｓ１０６）を行う。つまり、ロジック処理部３８は、ロジック記録部３７のロジックに従ってデータを加工し、ロジック記録部３７に記述された更新先の各キャッシュサーバ２に、加工したデータを送信する。ここで、更新先のキャッシュサーバ２ごとに異なったデータの加工処理を行うことにより、情報管理体系が複雑になることによる情報取得の遅延を抑制することができる。
【００４１】
以上、データ登録の処理について、説明した。次に、本実施形態の情報管理システムの動作のうち、マスタＤＢサーバ３からのデータ参照について、図１から図６を参照しつつ、図７に示すフローチャートに沿って説明する。
【００４２】
図７は、マスタＤＢサーバ３からのデータ参照の処理を示すフローチャートである。まず、マスタＤＢサーバ３は、クライアント端末１からのアクセスに応じて、認証処理を行う（Ｓ２０１）。次に、クライアント端末１は、検索条件の入力を受け付けて、その検索条件をマスタＤＢサーバ３に送信する（Ｓ２０２）。なお、検索条件の入力形式は、例えば、ＳＱＬまたはＲＤＱＬ（RDF Data Query Language）である。
【００４３】
そして、マスタＤＢサーバ３は、受信した検索条件を基にしてクラスＤＢ３１からの検索（Ｓ２０３）を行う。なお、クラスＤＢ３１は、属性値を有していないため、受信した検索条件に含まれる属性名を検索キーとして、その属性名を有しているクラスを抽出する処理が、クラスＤＢ３１からの検索処理である。例えば、図３において、検索条件が“年齢が３０歳以上となる人間”の場合、検索条件は属性名“年齢”と属性値“３０歳以上”との組として表現される。よって、マスタＤＢサーバ３は、属性名“年齢”を有するクラスをクラスＤＢ３１から抽出し、その結果、“人間”およびその下位概念に相当するクラス（例えば“著作者”）を得る。ここで、“ポリシ”および“ロジック”は、属性名“年齢”を有していないので、抽出されない。これにより、検索条件の属性名を有していないクラスは、属性値を一切参照されることなく、検索対象から除外されるので、検索に関する処理量は、属性値を参照する方式に比べて軽減できる。
【００４４】
さらに、マスタＤＢサーバ３は、（Ｓ２０３）の検索結果として抽出されたクラスに対応するポリシについてポリシインスタンスを参照することによって取得し、そのポリシの検証（Ｓ２０４）を行う。なお、ポリシの検証は、例えば、認証処理（Ｓ２０１）によって特定されたユーザが、ポリシにおける“参照可能な主体”に適合するかを検証する処理、および、現在の時刻がポリシにおける“参照可能期間”に適合するかを検証する処理である。そして、ポリシに適合せず、検証に失敗したクラスは、検索結果から除外される。
【００４５】
そして、マスタＤＢサーバ３は、検索結果となるクラスに対応するデータの取得し、そのデータをクライアント端末１に送信する（Ｓ２０５）。さらに、クライアント端末１は、受信した検索結果のデータを提示する（Ｓ２０６）。検索結果のデータの提示は、例えば、クライアント端末１に接続されたディスプレイ装置への画面出力である。
【００４６】
以上、マスタＤＢサーバ３からのデータ参照の処理について、説明した。次に、本実施形態の情報管理システムの動作のうち、キャッシュサーバ２からのデータ参照について、図１から図７を参照しつつ、図８に示すフローチャートに沿って説明する。
【００４７】
図８は、キャッシュサーバ２からのデータ参照の処理を示すフローチャートである。まず、キャッシュサーバ２は、クライアント端末１からのアクセスに応じて、認証処理（Ｓ３０１）を行う。次に、クライアント端末１は、検索条件の入力を受け付け、その検索条件をキャッシュサーバ２に送信する（Ｓ３０２）。そして、キャッシュサーバ２は、受信した検索条件を基にしてキャッシュＤＢ２１からの検索（Ｓ３０３）を行う。さらに、キャッシュサーバ２は、検索結果となるクラスに対応するポリシを取得し、そのポリシの検証（Ｓ３０４）を行う。そして、キャッシュサーバ２は、検索対象となるデータがキャッシュＤＢ２１に存在するかを確認（Ｓ３０５）する。
【００４８】
もし、検索対象となるデータがキャッシュＤＢ２１に存在する場合（Ｓ３０５、Ｙ）、キャッシュサーバ２は、キャッシュＤＢ２１からの検索結果となるデータ（クラスの属性値）の取得（Ｓ３０６）を行う。そして、キャッシュサーバ２は、（Ｓ３０６）で取得した検索結果のデータを、クライアント端末１に送信する（Ｓ３０８）。そして、クライアント端末１は、検索結果のデータを提示する（Ｓ３０９）。
【００４９】
一方、検索対象となるデータがキャッシュＤＢ２１に存在しない場合（Ｓ３０５、Ｎ）、キャッシュサーバ２自らは検索結果を返信できないので、キャッシュサーバ２は、マスタＤＢサーバ３に検索要求を転送し、処理を終了する（Ｓ３０７）。
【００５０】
以上、情報管理システムの動作について、説明した。次に、情報管理システムを後記するセマンティックＷｅｂシステムに適用する一例を示す。
【００５１】
図９は、本発明の情報管理システムが適用されるセマンティックＷｅｂシステムの構成図である。セマンティックＷｅｂシステム１Ａは、Ｗｅｂ上にあるデータを用いて問題解決を行う機能を有する。なお、セマンティックＷｅｂシステム１Ａは、ネットワークを介して、サービス提供者の端末８Ａおよび、ユーザ端末９Ａからのアクセスを受け付ける。このため、セマンティックＷｅｂシステム１Ａは、サービスの提供に使用されるデータを処理するサービスデータ処理部１０Ａと、サービスの提供に使用されるコンテンツを記録するコンテンツ記録部２０Ａと、コンテンツに対応する機械的処理が可能なメタデータを記録するメタデータ記録部３０Ａと、ユーザによって登録されたデータを処理するユーザデータ処理部６０Ａと、ユーザによって登録された配信許諾に関するデータであるオプトインを記録するオプトイン記録部７０Ａと、ユーザによって登録されたユーザの個人情報を記録する個人情報記録部８０Ａと、概念の集合および概念間の相互関連が定義された辞書データを処理するオントロジ辞書処理部１１０Ａと、概念の集合および概念間の相互関連が定義された辞書データを記録するオントロジ辞書記録部１２０Ａと、ユーザによって登録されたデータとサービスの提供に使用されるデータとを照合するデータ照合部１５０Ａと、データ照合部によって照合されるデータを記録する照合対象データ記録部１６０Ａと、データ照合部によって照合された結果を記録する照合結果記録部１７０Ａと、を含めて構成される。
【００５２】
ここで、コンテンツ記録部２０Ａに記録されるコンテンツについて、例えば、映像データ（サービスが映像データの配信である場合）などのサービスがセマンティックＷｅｂシステム１Ａからユーザ端末９Ａへ一方向で提供されるケースだけでなく、申請書データ（サービスが行政に関する申請手続きである場合）などのサービスがセマンティックＷｅｂシステム１Ａとユーザ端末９Ａとの双方向のやりとりによって実現されるケースも対応する。
【００５３】
また、メタデータ記録部３０Ａに記録されるメタデータは、コンテンツ記録部２０Ａに記録されるコンテンツを説明するものである。例えば、コンテンツが書籍データである場合には、メタデータは、書籍データを説明する書誌情報である。
【００５４】
さらに、オプトイン記録部７０Ａに記録されるオプトインは、ユーザによって登録された配信許諾に関するデータである。例えば、オプトインは、ユーザによって指定された“行政情報のうちの医療情報の配信を許諾する”という旨を示す情報である。これにより、ユーザは、自分の興味のあるサービスへの意思表示を登録する。そして、オプトインは、セマンティックＷｅｂシステム１Ａからユーザ端末９Ａに提供されるサービスを選択する用途で用いられる。
【００５５】
そして、個人情報記録部８０Ａに記録されるユーザの個人情報は、セマンティックＷｅｂシステム１Ａからユーザ端末９Ａに提供されるサービスを選択する用途で用いられる。また、ユーザの個人情報は、提供されるサービスについて、ユーザの個人情報に応じてサービスの内容を変化させるという用途にも使用される。
【００５６】
以上説明したセマンティックＷｅｂシステム１Ａは、以下のように本発明を適用することができる。なお、適用形式は、管理される情報にアクセスするクライアント端末１を、ユーザ端末９Ａ、または、サービス提供者の端末８Ａのうちのどちらに適用するかによって、２種類のケースに分類できる。
【００５７】
まず、第１のケースは、サービスの提供を受けるユーザ端末９Ａが、セマンティックＷｅｂシステム１Ａに登録した情報にアクセスする場合である。この場合は、情報管理システムにおけるクライアント端末１がユーザ端末９Ａに対応するとともに、情報管理システムにおけるマスタＤＢサーバ３がセマンティックＷｅｂシステム１Ａに対応する。そして、情報管理システムにおいて管理する情報を格納するクラスＤＢ３１およびマスタＤＢ３３は、コンテンツ記録部２０Ａ、メタデータ記録部３０Ａ、オプトイン記録部７０Ａ、個人情報記録部８０Ａのうち、少なくとも１つに適用される。
【００５８】
次に、第２のケースは、サービスの提供を行うサービス提供者の端末８Ａが、セマンティックＷｅｂシステム１Ａに登録した情報にアクセスする場合である。この場合は、情報管理システムにおけるクライアント端末１がサービス提供者の端末８Ａに対応するとともに、情報管理システムにおけるマスタＤＢサーバ３がセマンティックＷｅｂシステム１Ａに対応する。そして、情報管理システムにおいて管理する情報を格納するクラスＤＢ３１およびマスタＤＢ３３は、コンテンツ記録部２０Ａ、メタデータ記録部３０Ａ、オプトイン記録部７０Ａ、個人情報記録部８０Ａのうち、少なくとも１つに適用される。
【００５９】
以上説明した本発明は、発明の趣旨を逸脱しない範囲で広く変形実施することができる。
【００６０】
例えば、クラスが有する属性名は、１つの名称とする代わりに、名前空間と名前空間内における名称との組として表記してもよい。例えば、名前空間“交通券”は、“出発地”、“目的地”、“料金”の３つの属性をもち、名前空間“飲食メニュー”は、“料理名”、“カロリー”、“料金”の３つの属性をもつとする。ここで、属性“料金”は、名前空間“交通券”と、名前空間“飲食メニュー”とで同一の名称が使われているが、異なる概念として使用したい場合もある。そこで、名前空間“交通券”における“料金”を属性名“交通券／料金”とし、名前空間“飲食メニュー”における“料金”を属性名“飲食メニュー／料金”とする。これにより、２つの属性名は異なるものとなるので、異なる概念として扱うことが可能となる。
【００６１】
また、マスタＤＢ３３およびキャッシュＤＢ２１は、属性値というデータを保持することとしたが、属性値に加えてその属性値を処理するための手続き（プログラム）を含めて保持してもよい。手続き（プログラム）は、例えば、属性値のデータが映像形式である場合における映像再生プログラムである。これにより、属性値のデータとして、テキスト形式だけでなく、映像や音声などの様々な種別のデータを、データベースが扱うことが可能となる。
【００６２】
そして、マスタＤＢサーバ３のマスタＤＢ３３は、１つのハードウェア（ＨＤＤ（Hard Disk Drive）などの記録媒体）に限定されるものではなく、複数のハードウェアおよびそれらをネットワークとして接続した集合体として構成されてもよい。これは、マスタＤＢ３３が例えば個人情報を扱う場合に、行政の区分によって管理するデータが分割される事象を反映したものである。その場合、データ本体であるマスタＤＢ３３は分散管理されるが、そのデータのクラスを示すクラスＤＢ３１は、１つのハードウェアとして集中させてもよい。これにより、分散管理されていた情報を統合管理することが可能となり、データの整合性がとれることで、ユーザの利便性、サービス提供者の利便性が向上する。
【００６３】
また、マスタＤＢ３３およびキャッシュＤＢ２１は、属性名と属性値との組でデータを管理する。そのため、属性がコンテンツなのか、そのコンテンツを説明するメタデータなのかは、特に区別はしない。これにより、コンテンツからの検索と、メタデータからの検索を同様の形式で行うことが可能となる。
【００６４】
そして、マスタＤＢサーバ３は、（Ｓ２０２）で受信した検索条件について、クラスＤＢ３１からの検索（Ｓ２０３）、ポリシの検証（Ｓ２０４）、データの取得（Ｓ２０５）を順に行うこととしたが、検索条件に適合するデータを得るために、（Ｓ２０３）から（Ｓ２０５）までの検索処理をまとめて１回とすると、その検索処理を複数回行うこととしてもよい。例えば、検索条件が“年齢が３０歳以上の人によって作成された著作物を得ること”の場合、第１の検索処理として、属性名“年齢”が属性値“３０歳以上”となる人間を抽出することとし、第２の検索処理として、属性名“著作者”が属性値として第１の検索処理となる人間に含まれるような著作物を抽出することとする。このように、検索処理を複数回行うことにより、複雑な検索条件にも対応することが出来る。
【００６５】
また、ポリシの検証（Ｓ２０４）とデータの取得（Ｓ２０５）との順序は、ポリシの検証（Ｓ２０４）を先とし、データの取得（Ｓ２０５）を後としたが、逆の順序としてもよい。ただ、ポリシの検証（Ｓ２０４）を先とする場合は、データの取得（Ｓ２０５）の対象となるデータは、ポリシに適合したデータに絞られるので、データの取得処理を軽減することが可能となる。
【００６６】
そして、クラスＤＢ３１からの検索（Ｓ２０３）処理は、所定の属性を有しているクラスを検索することとしたが、あるクラスが所定の属性を有していることが抽出された場合は、そのクラスの下位概念に相当するクラスも所定の属性を有していることが期待できる。その場合、所定の属性を有しているクラスの関連（下位概念）を調べることにより、下位概念に相当するクラスの属性を参照する処理を省略することが出来る。
【図面の簡単な説明】
【００６７】
【図１】本発明の一実施形態に関する情報管理システムの構成図である。
【図２】本発明の一実施形態に関するクラスＤＢのデータ構造をグラフ化した図である。
【図３】本発明の一実施形態に関するクラスＤＢの構成図である。
【図４】本発明の一実施形態に関するマスタＤＢサーバが有するデータ構造の構成図である。
【図５】本発明の一実施形態に関するキャッシュサーバが有するデータ構造の構成図である。
【図６】本発明の一実施形態に関するデータ登録の処理を示すフローチャートである。
【図７】本発明の一実施形態に関するマスタＤＢサーバからのデータ参照の処理を示すフローチャートである。
【図８】本発明の一実施形態に関するキャッシュサーバからのデータ参照の処理を示すフローチャートである。
【図９】本発明の一実施形態に関する情報管理システムを適用するセマンティックＷｅｂシステムの構成図である。
【符号の説明】
【００６８】
１      クライアント端末
２      キャッシュサーバ
３      マスタＤＢサーバ
２１    キャッシュＤＢ
２３    ポリシ記録部
２４    ポリシ処理部
３１    クラスＤＢ
３３    マスタＤＢ
３５    ポリシ記録部
３６    ポリシ処理部
３７    ロジック記録部
３８    ロジック処理部
【図１】
2005196382.tif 000003
【図２】
2005196382.tif 000004
【図３】
2005196382.tif 000005
【図４】
2005196382.tif 000006
【図５】
2005196382.tif 000007
【図６】
2005196382.tif 000008
【図７】
2005196382.tif 000009
【図８】
2005196382.tif 000010
【図９】
2005196382.tif 000011