JP4735030B2

JP4735030B2 - 情報管理システム

Info

Publication number: JP4735030B2
Application number: JP2005139228A
Authority: JP
Inventors: 一智牛嶋
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-05-12
Filing date: 2005-05-12
Publication date: 2011-07-27
Anticipated expiration: 2025-05-12
Also published as: US20060259813A1; US7680813B2; JP2006318146A

Description

本発明はデータの業務上の価値に応じてデータ管理方法を決定する情報ライフサイクル管理システムに係わり、特に “管理対象データの分類基準と分類されたデータに対して適用するデータ管理方法との対応付け“を行なうポリシー群を事前に定義しておき、定義されたポリシーの内容に従い、管理対象データの管理方法の決定を行なうシステムに関する。

一般にＩＬＭ(Information Lifecycle Management)と呼ばれる情報ライフサイクル管理を実現する情報管理システムでは、データの生成から廃棄に至る一連のライフサイクルにおいて、管理対象データの業務的価値が時間的に変化することに着目し、予め指定されたポリシーに従って、その時々の業務的価値に応じて適切なデータ管理方法を選択/適用することで、システム全体におけるデータ管理コスト削減を目指す。

例えば、「直近一ヶ月における利用頻度の高い有望顧客に関しては、関連する取引データを信頼性の高いディスク装置に配置する」などのポリシーを定義した場合、個々の顧客に関する利用ログなどを参照した上で、ポリシーに照らしてその重要度を判断し、対応する取引データを信頼性やバイト単価の異なるディスク装置に自動的に移動することで、システムのトータルコスト（機器コスト、運用コスト含む）を低減する。管理対象データに付随するメタデータや蓄積されるログ情報の内容を参照して、時間経過と共に変化する管理対称データの業務価値を判断し、実施コストの異なる様々なデータ管理方法を自動的に使い分けることで、システム全体で必要となるデータ管理コストを低減させることとなる。

管理対象データに対するデータ管理方法の適用方針を定義するポリシーは、データ管理方法の変更操作における操作対象データを絞り込むための条件部と操作内容を指示するコマンド部からなる。情報ライフサイクル管理を実用システムに対して適用する場合、ポリシーの条件部の記述においては、ファイルシステムなどから得られるデータ作成日時や最終アクセス日時情報などの単純なメタデータだけでは不十分で、顧客区分や文書の業務分類など業務レベルの概念を用いて条件設定を行ないたいとのニーズが強い。

また一般に、管理対象データの粒度がより細かく、またより複雑な条件のポリシー記述が可能な程、木目の細かい効率の良いデータ管理を実現することが出来る。しかし、データの管理単位を細かくし、ポリシーの記述範囲を拡大すると共に、個々の管理対象データについて取得が必要となるメタデータやログ情報の範囲が拡大し、情報ライフサイクル管理の実施コスト増大につながる。

情報ライフサイクル管理の実現において、業務レベルでのポリシー定義を可能にしたり、メタデータやログ情報の収録管理コストを削減したりするために利用可能と思われる従来の技術を列挙すると、以下の通りである。
“Query Processing, Resource Management, and Approximation in a Data Stream Management System“,CIDR2003（非特許文献１）には検索処理対象となる各データリソースに対して、ウインドウ条件（件数やデータ生成時刻等に関する制限）が設定され、検索処理対象となるデータの範囲を問合せ毎に明示的に指定して、限定する技術が開示される。この技術を「ストリームＤＢ方式」と呼ぶ。

“Implementing Data Cubes Efficiently“,SIGMOD96（非特許文献２）は、データベースシステムでの検索処理において、予め頻繁に投入されることが予想される検索処理の共通部分について、事前にその一部を実行し結果を保持することで、検索処理効率の向上を図る技術を開示する。この技術を「マテリアライズドビュー方式」と呼ぶ。

Hector Garcia-Molina, Jeffery D. Ullman, Jennifer Widom著、“Ｄａｔａbase System Implementation“、p.605-p.612（非特許文献３）には、「ラッパー」と呼ばれるデータ形式変換プログラムと「メディエータ」と呼ばれる個別データからより上位の概念に相当するデータを生成するプログラムとを予め定義し、個別データを業務レベルの概念と対応させ、業務レベルの用語を用いて検索処理の定義を行なえるようにする技術が開示される。この技術を「ラッパーアンドメディエータ方式」と呼ぶ。
上記三つのいずれの方式においても、システムに投入された問合せの内容に応じて、検索対象となるデータ本体に対して適用される問合せ処理の内容を変更することを行なっているが、データ本体そのものに対しては影響を及ぼさない。

Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Singh Manku, Chris Olston, Justin Rosenstein, Rohit Varma: "Query Processing, Approximation, and Resource Management in a Data Stream Management System" CIDR 2003

Venky Harinarayan, Anand Rajaraman, Jeffrey D. Ullman: "Implementing Data Cubes Efficiently" SIGMOD Conference 1996: pp.205-216 Hector Garcia-Molina, Jeffery D. Ullman, Jennifer Widom, "Ｄａｔａbase System Implementation" pp.605-612

上記「ストリームＤＢ方式」「マテリアライズドビュー方式」および「ラッパーアンドメディエータ方式」では、システムに投入された問合せの内容に応じて、対象となるデータ本体に対して適用される問合せ処理の内容を変更することを行なっている。しかし、上記従来のいずれの方法も、例えば情報ライフサイクル管理の実現に適用した場合にデータリソースに付随するメタデータ/ログ情報の管理方法に対して変更を加えるものとはならない。

事前に設定されたポリシーに従って、管理対象データに付随するメタデータやログ情報を参照し、システムの振舞いを変更するデータ管理システムにおいて、より柔軟で実務的な管理を実現するためには、ポリシー定義で利用できる用語を拡大したり、管理対象データの粒度を縮小したりするなどしてポリシーの表現力を増すことが望まれる。しかし、そのためにポリシー記述の複雑化や保持が必要なメタデータやログ情報のデータ量が増大したのでは管理コストがかえって増大する。したがって本発明ではポリシー定義を容易にし、管理コスト増大を抑えながら、効率的で柔軟な情報ライフサイクル管理を実現することを課題とする。

ポリシーの定義内容に応じて取得が必要なメタデータやログ情報の範囲が変化するが、本発明では、ポリシー記述で使用される業務レベルの用語とメタデータやログ情報との間の対応関係を定義するオントロジを導入し、ポリシーと合わせて解析することで、情報取得が必要な範囲を明確に決定できるようにして、ポリシー定義容易化と運用管理コスト削減を図る。

本発明では、設定されたポリシーの内容に応じて、データリソースに付随するメタデータログ情報に対してその管理に関する設定変更を行なう場合があり、例えばログ情報に対する参照が過去１ヶ月に限定される場合は、１ヶ月より古いログ情報を自動的に削除することを行なう。このように、本発明方式では、情報ライフサイクル管理実現のためにデータリソースに付随するメタデータ/ログ情報の管理方法の変更を行なう点が上述の従来技術と大きく異なる。

事前定義されたポリシーに基づき、リソース管理の最適化を図る情報ライフサイクル管理システムでは、複雑なポリシーを定義しようとしたり、管理対象となるリソースの数を増大させようとしたりすると、取得が必要なメタデータやログ情報の種別も膨大となり、その取得に要するコストが増大する。

本発明では、ポリシー定義を行なう際に利用される業務レベルの用語と管理対象データに付随するメタデータやログ情報との間の対応関係を定義するオントロジを導入し、個別システムにおけるメタデータ/ログ情報の取得可能性やコマンドの実行可能性を考慮しながら、メタデータ/ログ情報の取得範囲を決定することで、
１．定義されたポリシーの実施に対して必要となる最小限となるメタデータ/ログ情報取得条件が決定されるため、効率的な情報ライフサイクル管理の実現を図れるとともに、
２．業務レベルの用語を用いてポリシー定義を行なえるようになり、ポリシーで参照される条件の定義が変更された場合も、対応関係を差し替えることで、自動的にメタデータやログ情報の取得条件が変更されるため、ポリシー定義の容易化と管理コスト低減を図ることが出来る。

図１に、本発明におけるデータ管理方式を備える情報ライフサイクル管理システムの実施形態の一例を示す。
本実施例における情報ライフサイクル管理システムでは、管理対象となる文書ファイルやメールなどの業務データは、プロジェクトや業務の状況に応じてその価値が変動すると考え、その時々の価値に応じたデータ管理手法を適用することで、費用対効果の高い情報管理を実現することを目指す。

本システムは、大きく、ポリシー記述で使用される用語とメタデータやログ情報との間の対応関係を表すオントロジを定義するためのオントロジ定義モジュール（１）、
上記定義済みのオントロジで出現する用語を用いて定義される、データリソースのグループ分けとそれらに適用する情報管理手法方針を対応付けるポリシーを定義するためのポリシー定義モジュール（２）、上記定義済みポリシーを参照して、具体的なデータリソースのグループ分けと情報管理手法の対応付けの決定を行なう情報ライフサイクル管理モジュール（３）、上記情報ライフサイクル管理モジュールが決定したグループ分けと情報管理手法の指定に基づき、各データリソースの管理手法を変更するデータリソース管理モジュール（４）、及び、前記定義済みポリシーとそれらポリシーの成立を前提として稼動する業務サービスの対応関係を管理し、ポリシーが成立しなくなった場合に対応業務サービスの停止を行なうサービス実行制御モジュール（５）から成る。

まず上記オントロジ定義モジュール（１）が備えるオントロジ定義手段（１１）では、管理対象となる各データリソースとそれらを参照する業務の対応関係を表す用語（オントロジ）を定義し、これらを上記情報ライフサイクル管理モジュール（３）が備えるオントロジ定義レジストリ（３１）に登録する。さらに上記ポリシー定義モジュール（２）が備えるポリシー定義手段（２１）では、データリソースのグループ分けを行なうための「条件部」とグループ分けされたデータリソースに対する適用する「コマンド部」を組とするポリシーを定義し、これらを上記情報ライフサイクル管理モジュール（３）が備えるポリシー定義レジストリ（３４）に登録する。このとき上記オントロジ定義レジストリ（３１）には、条件変換オントロジとコマンド変換オントロジの二種類のオントロジが登録されており、ポリシー定義の際、条件部を定義する際には、上記オントロジ定義レジストリに登録された条件変換用オントロジを参照して定義し、コマンド部を定義する際には、上記オントロジ定義レジストリに登録されたコマンド変換用オントロジを参照して定義する。

また、データリソース管理モジュール（４）が備えるリソース集合管理手段（４２）は、データリソースに対して適用可能な操作一覧を備え、メタデータ/ログ情報取得手段（４１）は、上記情報ライフサイクル管理モジュール（３）が備えるメタデータ/ログ情報設定変更手段（３８）からの指示に従って、前記リソース集合管理手段（４２）が管理するデータリソースからのメタデータやログ情報の取得を行ない、これを上記情報ライフサイクル管理モジュール（３）が備えるメタデータ/ログ情報レジストリ（３３）に登録する。

引き続いて前記情報ライフサイクル管理モジュール（３）が備えるポリシー解析手段（３５）は、前記ポリシー定義レジストリ（３４）から登録済みのポリシーを取り出し、前記オントロジ定義レジストリ（３１）に定義されたオントロジを参照して、前記ポリシーをポリシー実行プランに変換し、ポリシー実行プランレジストリ（３６）に登録する。前記ポリシー実行プランは、実際に操作対象となるデータリソース集合を決定するとともに、それらに適用すべき操作を決定する。このとき、もし取り出されたポリシーがログ情報出力用領域の不足などで実行できないことが判明した場合は、サービス実行制御モジュール（５）が備えるサービス実行制御手段（５１）に対して、どのポリシーが実行できなかったかを通知し、そのポリシーの成立を前提として稼動する業務サービスの停止を行なう。

前記情報ライフサイクル管理モジュール（３）が備える前記ポリシー実行プランレジストリ（３６）は、前記ポリシー実行プランを実施する場合には、まずポリシー実行プランの条件部を対象リソース決定手段（３２）に、またコマンド部をコマンド実行手段（３７）に送付する。前記対象リソース決定手段（３２）では、送付された条件部に指示されたデータリソースの絞込み条件に従って、オントロジ定義レジストリ（３１）に登録された条件変換オントロジとメタデータ/ログ情報レジストリ（３３）に登録されたメタデータ/ログ情報を参照しながら、操作対象データリソース集合を決定する。決定されたデータリソース集合は、前記コマンド実行手段（３７）に送付され、既に送付済みのコマンド部の指示に従って、適切なデータ管理操作が適用される。

図２において、情報ライフサイクル管理モジュール（３）が備えるポリシー解析手段（３５）の概略フローを示す。
ポリシー解析手段（３５）は、まず３種類のポリシー集合PS,QS,ESの初期化を行なった後（２０２）、ポリシー定義レジストリに登録されたポリシーのうち、未実行のポリシーを取り出し（２０３）、候補ポリシー集合PSの要素として登録する（２０４）。もし、未実行のポリシーがない場合は終了する（２０７）。続いてポリシー集合PSからポリシーP１を取り出し（２０５）、ポリシーP１の条件部の評価可能性を判定する。もし評価可能である場合は、そのポリシーP１を評価可能ポリシー集合QSに登録し、評価可能でない場合は、図３に示す処理フローにしたがって、ポリシーP１を変換して再びポリシー集合PSに登録する（２０６）。もし、ポリシー集合PSが空となり取り出すべきポリシーが存在しない場合は、評価可能ポリシー集合QSからポリシーP２を取り出し（２０８）、ポリシーP２のコマンド部の実行可能性を判定する。

もし実行可能である場合は、そのポリシーP２を実行可能ポリシー集合ESに登録し、評価可能でない場合は、図４に示す処理フローにしたがって、ポリシーP２を変換して再びポリシー集合QSに登録する（２０９）。もし、ポリシー集合QSが空となり取り出すべきポリシーが存在しない場合は、実行可能ポリシー集合ESから、評価値が最良となるポリシーPPを選び、ポリシー実行プランに送付する。さらにこのとき、ポリシー解析手段では、適用可能なポリシーPPからメタデータ/ログ情報に対する参照範囲情報を生成し、これをデータリソース管理モジュールモジュールが備えるメタデータ/ログ情報取得手段に送付する（２１１）。さらに実行可能ポリシー集合ＥＳが空となり取り出すべきポリシーが存在しない場合は、前記サービス実行制御手段に対して不成立となったポリシーＰの情報を送付する（２１２）。

図３に、ポリシー集合PSから取り出されたポリシーに対する処理フローを示す。
候補ポリシー集合PSから取り出した候補ポリシーP１については、まずポリシーの条件部SPに関する評価可能性を図５に示すフローにしたがって判定する（３０１）。もし条件部SPが評価可能状態にある場合は、ポリシーPを評価可能ポリシー集合QSに登録し（３０２）、もし評価可能でない場合は、条件変換オントロジを参照し、条件部SPに出現する述語パターンが一致する変換規則集合TRを決定する（３０３）。もし、集合TRが空の場合は、その候補ポリシーは評価可能とはならないため、候補ポリシーＰ１を破棄し（３０４）、新たな候補ポリシーの検討を行う（２０５）。変換規則集合TRが空でない場合は、それぞれの変換規則を候補ポリシーに適用し、条件節を書き換えた新しい候補ポリシー群をPSに登録する（３０６）。このとき、さらに他の実施例として、TRに含まれる適用可能な変換規則をすべて適用するのではなく、各変換規則に対して評価関数を適用して得られる評価値に基づいて適用する変換規則を絞り込む（３０５）ことも考えられる。

図４に、ポリシー集合QSから取り出されたポリシーに対する処理フローを示す。
評価可能ポリシー集合QSから取り出した評価可能ポリシーP２については、まずポリシーのコマンド部CPに関する適用可能性を図６に示すフローにしたがって判定する（４０１）。もしコマンド部CPが実行可能状態にある場合は、ポリシーPを適用可能ポリシー集合ESに登録し（４０２）、もし評価可能でない場合は、コマンド変換オントロジを参照し、コマンド部CPに出現するコマンドパターンが一致する変換規則集合DRを決定する（４０３）。もし、集合DRが空の場合は、その候補パリシーは適用可能とはならないため、評価可能ポリシーＰ２を破棄し（４０４）、新たな候補ポリシーの検討を行う（２０８）。変換規則集合DRが空でない場合は、それぞれの変換規則を候補ポリシーに適用し、コマンド節を書き換えた新しい候補ポリシーをQSに登録する（４０６）。このとき、他の実施例として、DRに含まれる適用可能な変換規則をすべて適用するのではなく、各変換規則に対して評価関数を適用して得られる評価値に基づいて適用する変換規則を絞り込む（４０５）ことが考えられる。

図５に、ポリシーの評価可能性を判定する処理フローを示す。ポリシーの評価可能性判定処理では、ポリシーの条件部ＳＰを構成する最初の条件節SPCについて（５０２）、条件節SPCを構成する述語が条件変換オントロジにおいて、評価可能フラグが付与されているかどうかを判定する（５０３）。もし評価可能フラグが付与されていない場合は、そのポリシーはまだ評価可能な状態ではないとして判定結果を返し（５０６）、評価可能フラグが付与されている場合は、次の条件節（５０４）について同様の判定を行なう（５０３）。条件部ＳＰを構成する全ての条件節の述語について、評価可能状態である場合は、そのポリシー全体を評価可能として判定結果を返す（５０５）。

図６に、ポリシーの適用可能性を判定する処理フローを示す。ポリシーの適用評価可能性判定処理では、ポリシーのコマンド部CＰを構成する最初の条件節CPCについて（６０２）、コマンド節ＣPCに含まれるコマンドがコマンド変換オントロジにおいて、適用可能フラグが付与されているかどうかを判定する（６０３）。もし適用可能フラグが付与されていない場合は、そのポリシーはまだ適用可能な状態ではないとして判定結果を返し（６０６）、適用可能フラグが付与されている場合は、次の条件節（６０４）について同様の判定を行なう（６０３）。コマンド部ＣＰを構成する全てのコマンド節のコマンドについて、適用可能状態である場合は、そのポリシー全体を適用可能として判定結果を返す（６０５）。

以下では、本実施例における情報ライフサイクル管理方法を、架空のオフィス情報システムにおける業務データの機密管理に関する具体例に対して適用した場合について述べる。
本具体例では、業務データはいくつかのファイルシステムに分けて格納され、それぞれの業務データにはその所有者が設定される。また所有者はそれぞれいずれかの業務プロジェクトに属し、業務プロジェクトに対してはそのプロジェクトの機密レベルが予め設定されるとする。

図７に、本具体例におけるファイル配置情報や組織情報をＲＤＦ(Resource Description Framework)のグラフ表現で示す。
ＲＤＦは、複雑な相互関係を持つデータを、主語(Subject)、述語(Predicate)、目的語(Object)の三つの単語を順番に組み合わせた三つ組（RDF Triple）の集まりで表現するものである。例えば図１３-(a)に示す架空の家系図は、Gomez, Morticia, Wednesday, Pugsleyの４名から成り立つ家族を表す。この家系図の内容をＲＤＦで表現した場合、次の３個の三つ組で表現される。

（Gomez, spouseOf, Morticia）
（Gomez, parentOf, Wednesday）
（Gomez, parentOf, Pugsley）
そのグラフ表現においては、矢印に述語、矢印の根元に主語、矢印の先に目的語を対応させて示す。上記の家系図をグラフ表現した場合、図１３-(b)のようになる。

本具体例ではプロジェクト名がそれぞれＡ及びＢである２つのプロジェクトが存在し、プロジェクトAにメンバーa1が、プロジェクトBにメンバーb1及びb2が所属している。このときメンバーa1はファイルx1を、メンバーb1はファイルy1及びy2を所有し、ファイルx1はファイルシステムＸの配下にあり、ファイルy1及びy2はファイルシステムＹの配下にあるとする。またプロジェクトＢはその機密レベルとして“confidentail“が指定されている。
これをＲＤＦで表現すると以下のようになる。
（Ａ, rdf:type, プロジェクト), （B, rdf:type, プロジェクト),
（a1, rdf:type, メンバ), （b1, rdf:type, メンバ), （b2, rdf:type, メンバ),
（x1, rdf:type, ファイル), （y1, rdf:type, ファイル), （ｙ2, rdf:type, ファイル),
(X, rdf:type, ファイルシステム), （Ｙ, rdf:type, ファイルシステム),
(a1, ilm:belongsTo, A), (b1, ilm:belongsTo, B), (b2, ilm:belongsTo, B),
(x1, ilm:owns, a1), (y1, ilm:owns, b1), (y2, ilm:owns, b1),
(x1, ilm:belongsTo, X), (y1, ilm:belongsTo, Y), (y2, ilm:belongsTo, Y)
(B, ilm:securityLevel, “confidential“)
図８に本具体例におけるポリシーの記述の例を示す。本例では、ポリシーの条件部をＲＤＦデータに対する検索言語であるＲＤＱＬで記述し、ポリシーのコマンド部に起動すべきコマンドスクリプト名を引数付きで記述する。

ＲＤＱＬ (A Data Oriented Query Language for RDF Models)は、蓄積されているRDFデータモデルから条件にあったものを取り出す機能を提供する検索言語である。RDFに対する検索は、RDFモデルとクエリパターンとのパターンマッチングによって実現される。例えば、先の家系図の例に対して配偶者の関係にある人物の組を得たい場合は、次のようなクエリによって?person1及び?person2にパターンマッチするリソースを取得することが出来る。

RDQLクエリ：SELECT ?person1, ?person2 WHERE (?person1, spouseOf, ?person2)
検索結果：{person1= Gomez, person2=Morticia}
図８に示すポリシーの条件部は、プロジェクトの機密レベルが“confidentail“で、かつそのプロジェクトの管轄内にあるデータリソースの内、種別がファイルで、そのデータアイテムに過去一週間以内のアクセス履歴が存在するデータリソースを絞り込むことを指示する。また図８に示すポリシーのコマンド部は、上記条件部で絞り込まれたデータリソースに対して、アクセスログを取得するように設定変更することを指示する。

図９に本具体例で登録されているオントロジの内容を示す。オントロジは、条件変化用のオントロジとコマンド変換用のオントロジの２種類がある。本具体例では、条件変換用オントロジが３個、コマンド変換用オントロジが１個定義されている。
図９に示す条件変換用オントロジの一つ目のオントロジは、ポリシーの条件部に現れる「プロジェクトの管轄内(ilm:belongsTo)にあるデータリソース」は「プロジェクトに所属(ilm:belongsTo)するメンバーが所有(ilm:owns)するデータリソース」と変換できることを示す。

二つ目のオントロジは、「プロジェクトに所属(ilm:belongsTo)するメンバー」は、「プロジェクトを構成(meta:memberOf)するメンバー」と変換できることを示す。
三つ目のオントロジは、「メンバーが所有(ilm:owns)するデータリソース」は、「メンバーが所有者(meta:owner)であるデータリソース」と変換できることを示す。
さらに図９に示すコマンド変換用オントロジの一つ目のオントロジは、「データ種別がファイルであるデータリソースに対するアクセスログの取得を指示するコマンド」は、「そのデータリソースが属する(meta:decendantOf)ファイルシステムに対しするアクセスログの取得を指示するコマンド」に変換できることを示す。

図１０に、本実施例において評価可能な述語の一覧及び適用可能なコマンドの一覧を示す。ファイル情報に関しては、データリソースの所有者情報(meta:owner),ファイルシステムに対するデータリソースの所属関係(meta:decendantOf)及びファイルに対するアクセス履歴情報(meta:accesshistory,meta:accesstime)が評価可能なメタデータとして登録されており、プロジェクト組織情報に関しては、プロジェクトの機密レベル(meta:securityLevel)とプロジェクトに対するメンバーの所属関係(meta:memberOf)が評価可能なメタデータとして登録されている。また、本実施例において適用可能なコマンドとしては、ファイルシステムに対するアクセスログの取得コマンドが実行可能として登録されているとする。ただし、リソースの種別を表す述語rdf:typeは常に評価可能な述語と見做す。

また本具体例におけるファイル情報に関するメタデータ及び組織情報に関するメタデータは、それぞれ図１１,図１２に示す通りとする。
このとき、まずポリシー解析手段は、ポリシー定義レジストリに登録された図８に示すポリシーを候補ポリシー集合ＰＳに登録する。引き続き候補ポリシー集合ＰＳからポリシーＰ１として前記登録したポリシーを取り出す。

「ポリシーＰ１」
<条件部>
SELECT ?dataitem
WHERE
(?project, meta:securityLevel, “confidential“),
(?dataitem, ilm:belognsTo, ?project),
(?dataitem, rdf:type, “file“),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY 1WEEK
USING ilm FOR <http://ilm/ontology.rdf#>
<コマンド部>
Set accesslog On dataitem
本ポリシーの評価可能性を判定すると、本ポリシーの２番目の条件節（?dataitem, ilm:belongsTo, ?project）を参照すると、本条件節を構成する述語ilm:belongsToは評価可能な述語として登録されていないので、条件変換オントロジーを参照し、条件部に対して適用可能な変換規則の集合ＴＲとして、条件変換オントロジ#1を得る。ポリシーＰ１に対して条件変換オントロジ#1を適用すると、以下のポリシーＰ１１を得る。

「ポリシーＰ１１」
<条件部>
SELECT ?dataitem
WHERE
(?project, meta:securityLevel, “confidential“),
(?member, ilm:belognsTo, ?project),
(?dataitem, ilm:owns, ?member),
(?dataitem, rdf:type, “file“),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY 1WEEK
USING ilm FOR <http://ilm/ontology.rdf#>
<コマンド部>
Set accesslog On dataitem
本ポリシーの評価可能性を判定すると、本ポリシーの２番目及び３番目の条件節を構成する述語が評価可能な述語として登録されていないので、さらにポリシーＰ１１に対して適用可能な変換規則として条件変換オントロジ＃２、＃３を得る。ポリシーＰ１１に対してこれらのオントロジを順次適用することで、以下のポリシーＰ１２を得る。

「ポリシーＰ１２」
<条件部>
SELECT ?dataitem
WHERE
(?project, meta:securityLevel, “confidential“),
(?member, meta:memberOf, ?project),
(?dataitem, meta:owner, ?member),
(?dataitem, rdf:type, “file“),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY 1WEEK
USING ilm FOR <http://ilm/ontology.rdf#>
<コマンド部>
Set accesslog On dataitem
ポリシーＰ1２に関しては、ポリシーを構成する全ての条件節の述語が評価可能となるので、このポリシーを評価可能ポリシー集合ＱＳに登録する。

引き続き、評価可能ポリシー集合QSに登録された前記ポリシーP12をポリシーＰ２として取り出す。ポリシーＰ２の適用可能性を判定すると、ポリシーＰ２のコマンド部に記述されるファイルに対するアクセスログの取得コマンドは実行可能として登録されていないので、コマンド変換オントロジを参照し、コマンド部に対して適用可能な変換規則の集合ＤＲとして、コマンド変換オントロジ#1を得る。ポリシーP2に対してコマンド変換オントロジ#1を適用すると、以下のポリシーP21を得る。

「ポリシーＰ21」
<条件部>
SELECT ?filesystem
WHERE
(?project, meta:securityLevel, “confidential“),
(?member, meta:memberOf, ?project),
(?dataitem, meta:owner, ?member),
(?filesystem, rdf:type, “filesystem“),
(?dataitem, meta:decendantOf, ?filesystem),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY 1WEEK
USING ilm FOR <http://ilm/ontology.rdf#>
<コマンド部>
Set accesslog On filesystem
変換の結果得られたポリシーＰ21は、コマンド部が本実施例において適用可能となるため、このポリシーを適用可能ポリシー集合ESに登録する。

以上の操作の結果、評価可能ポリシー集合にはポリシーＰ21のみが登録されている状態になるので、このポリシーをポリシー実行プランレジストリに送付する。
さらにこのとき、ポリシー解析手段では、適用可能となったポリシーP21で参照されるメタデータ/ログ情報の参照範囲情報として、以下のような一覧リストを作成し、データリソース管理モジュールモジュールが備えるメタデータ/ログ情報取得手段に対して送付する。

(?project, meta:securityLevel, “confidential“),
(?member, meta:memberOf, ?project),
(?dataitem, meta:owner, ?member),
(?filesystem, rdf:type, “filesystem“),
(?dataitem, meta:decendantOf, ?filesystem),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime) ?acctime > TODAY 1WEEK
前記メタデータ/ログ情報取得手段では、受け取ったメタデータ/ログ情報一覧リストを参照し、リソース集合管理手段に対し、一覧リストにあるメタデータ/ログ情報（meta:securityLevel,meta:memberOf,meta:owner,meta:decendantOf,meta:accesshistory,meta:accesstime）を収集するように設定の変更を指示する。このときさらにアクセス履歴に関するログ情報(ilm:accesstime)に関しては、参照されるアクセス履歴の範囲が過去１週間以内であるので、ログの保持期間が過去１週間となるように設定することとなる。

このときもし、適用可能ポリシー集合が空であり、ポリシーレジストリから取り出されたポリシーに対して、適用可能なポリシーが生成されなかった場合は、サービス実行制御モジュールが備えるサービス実行制御手段に対して、適用不可となったポリシーとして送付を行なう。サービス実行制御手段では、適用不可となったポリシーを動作前提とするサービスが登録されていた場合は、当該サービスを停止するようにする。

ポリシー実行プランレジストリに送付されたポリシーは、その条件部が対象リソース決定手段に送付され、そのコマンド部がコマンド実行手段に送付される。対象リソース決定手段では送付された条件部に含まれるＲＤＱＬを解釈し、操作対象となるデータリソースを絞り込む。今回の実施例の場合は、ファイルシステムＹが対象リソースとして選択される。選択されたデータリソースはコマンド実行手段に送られ、先に送付されたコマンド部に記述されたコマンドが選択されたデータリソースに対して適用され、ファイルシステムＹに対して、アクセスログを取得するように設定変更が行なわれる。

本発明によれば、データの生成から廃棄に至る一連のライフサイクルにおいて、ビジネス戦略やビジネスモデルの変化により管理対象データの業務的価値が時間的に変化することに対応して、情報の取得、保持、廃棄の条件の変更を容易に行える情報管理システムが得られるので、この分野で利用可能性が高い。

本発明による情報ライフサイクル管理システムを示すブロック図である。本発明の実施例におけるポリシー解析手段の全体処理を示すフローチャートである。ポリシー条件部変換及びポリシー集合QSへの登録処理を示すフローチャートである。コマンド変換及びポリシー集合ESへの登録処理を示すフローチャートである。ポリシー条件部の評価可能性判定処理を示すフローチャートである。ポリシーコマンド部の適用可能性判定処理フローチャートである。本実施例の適用例におけるファイル配置や組織情報に関するＲＤＦグラフである。適用例におけるポリシー定義を示す図である。適用例におけるオントロジ定義を示す図である。適用例における評価可能メタデータ/ログ情報あるいは適用可能コマンド定義を示す図である。適用例におけるファイル情報メタデータを示す図である。適用例における組織情報メタデータを示す図である。架空の家系図とそのRDFグラフ表現である。

符号の説明

１：オントロジ定義モジュール
２：ポリシー定義モジュール
３：情報ライフサイクル管理モジュール
４：データリソース管理モジュール
５：サービス実行制御モジュール
１１：オントロジ定義手段
２１：ポリシー定義手段
３１：オントロジ定義レジストリ
３２：対象リソース決定手段
３３：メタデータ/ログ情報レジストリ
３４：ポリシー定義レジストリ
３５：ポリシー解析手段
３６：ポリシー実行プランレジストリ
３７：コマンド実行手段
３８：メタデータ/ログ情報設定変更手段
４１：メタデータ/ログ情報取得手段
４２：リソース集合管理手段
５１：サービス実行制御手段。

Claims

データリソースに対して適用されるデータ管理方式を、前記データリソースに付随するメタデータとアクセスログ情報の少なくとも一方と、前記データリソースに対しての前記データ管理方式の適用の仕方を示す情報であるポリシーと、に基づいて決定し、前記データリソース中のデータを前記データ管理方式を用いて管理するデータ管理システムにであって、
前記ポリシーの定義に用いる用語と、メタデータとアクセスログ情報の少なくとも一方と、を対応付ける情報であるオントロジを決定するオントロジ決定手段と、
前記オントロジに基づいて前記ポリシーを定義し、前記定義されたポリシーを用いて、前記データリソースと、前記データリソースに適用する前記データ管理方式と、を対応付けるポリシー決定手段と、
前記データリソースに対して適用する操作の内容を示す前記ポリシーのコマンド部に基づいて前記ポリシーが実行可能であるかを判定し、前記実行可能と判定された前記ポリシーに基づいて、前記メタデータとアクセスログ情報の少なくとも一方に対する参照範囲を指定する参照範囲情報を生成するポリシー解析手段と、
前記ポリシー解析手段が生成した前記参照範囲情報に基づき、前記参照範囲の前記メタデータとアクセスログ情報の少なくとも一方を取得し、前記参照範囲の前記メタデータとアクセスログ情報の少なくとも一方が付随する前記データリソースを、前記実行可能と判定された前記ポリシーを用いて前記対応付けられた前記データ管理方式を用いて管理するように設定するデータ管理設定手段と、
を有することを特徴とするデータ管理システム。
請求項１に記載のデータ管理システムにおいて、前記オントロジに前記データ管理システムで前記参照範囲が定義され、前記ポリシー解析手段は、定義済みポリシーにおいて参照される前記データリソースに付随するメタデータとアクセスログ情報の少なくとも一方の内容が前記オントロジに登録された前記参照範囲を逸脱する場合は、前記ポリシーの判定を行なえないこととする、ことを特徴とするデータ管理システム。
請求項１に記載のデータ管理システムにおいて、前記オントロジに前記データ管理システムにて適用可能なデータ管理に関するコマンドの範囲が定義されており、前記ポリシー解析手段は、定義済みポリシーにおいて指定されるデータ管理に関するコマンドの内容が前記オントロジに登録された範囲を逸脱する場合は、当該ポリシーの適用を行なえないこと、とすることを特徴とするデータ管理システム。
請求項２あるいは３のいずれかに記載のデータ管理システムにおいて、事前定義されたポリシーと管理対象である前記データリソースを参照するサービス群との間の依存関係を保持し、前記ポリシー解析手段において、ポリシーの判定あるいは適用を行なえないことを検知した場合に、当該ポリシーに依存するサービスの停止を行なうサービス実行制御手段を有することを特徴とするデータ管理システム。