特許 6229997 データ管理システム及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6229997

(24)【登録日】2017年10月27日

(45)【発行日】2017年11月15日

(54)【発明の名称】データ管理システム及びプログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20171106BHJP

   G06F 17/30 20060101ALI20171106BHJP

【ＦＩ】

   G06F12/00 545A

   G06F12/00 513J

   G06F17/30 220C

【請求項の数】7

【全頁数】20

(21)【出願番号】特願2013-235734(P2013-235734)

(22)【出願日】2013年11月14日

(65)【公開番号】特開2015-95206(P2015-95206A)

(43)【公開日】2015年5月18日

【審査請求日】2016年10月19日

(73)【特許権者】

【識別番号】000005496

【氏名又は名称】富士ゼロックス株式会社

(74)【代理人】

【識別番号】110000039

【氏名又は名称】特許業務法人アイ・ピー・ウィン

(72)【発明者】

【氏名】増田 佳弘

【審査官】 桜井 茂行

(56)【参考文献】

【文献】 特開２００１−３０６３７４（ＪＰ，Ａ）

【文献】 特開２０１０−２１８１３１（ＪＰ，Ａ）

【文献】 特開２００６−０１８６０７（ＪＰ，Ａ）

【文献】 特開２０１２−１２３６８０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００８／０３１３２０９（ＵＳ，Ａ１）

【文献】 特開２０１３−２２８９９９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１３／０２５４２４２（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

属性項目ごとに、当該属性項目の利用対象を示す利用対象情報を記憶する利用対象記憶手段と、
識別情報と該識別情報に対応付けられた１以上の属性項目の属性値とを含むデータを前記利用対象情報ごとに属性項目単位で記憶する複数のデータ記憶手段と、
アプリケーションソフトウェアにより属性値の出力をする場合に、前記利用対象情報が示す利用対象として該アプリケーションソフトウェアが含まれる属性項目を検索し、検索された属性項目に関する属性値を前記複数のデータ記憶手段から取得し、前記利用対象情報と前記識別情報に基づいて統合して出力する統合出力手段と、
を有するデータ管理システム。

【請求項2】

前記利用対象記憶手段が記憶する利用対象情報を変更する利用対象変更手段
をさらに有する請求項１記載のデータ管理システム。

【請求項3】

前記利用対象変更手段は、前記利用対象記憶手段が記憶する利用対象情報について、特定のアプリケーションソフトウェアで用いられることを示す利用対象情報を、複数のアプリケーションソフトウェアで用いられることを示す利用対象情報へと変更する
請求項２記載のデータ管理システム。

【請求項4】

属性項目ごとに、当該属性項目の属性値の記憶先を示す記憶先情報を記憶する記憶先記憶手段
をさらに有し、
前記統合出力手段は、前記記憶先記憶手段が記憶する記憶先情報により特定される取得先から属性値を取得する
請求項1乃至３いずれか記載のデータ管理システム。

【請求項5】

異なる複数の属性項目を関連付ける属性項目関連付け手段と、
前記関連付け手段により関連付けられた属性項目のいずれかの属性値を、前記関連付け手段により関連付けられた他の属性値に反映させる属性値反映手段と
をさらに有する請求項１乃至４いずれか記載のデータ管理システム。

【請求項6】

前記属性項目関連付け手段により関連付けられた属性項目間における属性値の使用権限を設定する使用権限設定手段
をさらに有し、
前記属性値反映手段は、前記使用権限設定手段により設定された使用権限に基づいて反映が許可された場合に属性値を反映させる
請求項５記載のデータ管理システム。

【請求項7】

属性項目ごとに、当該属性項目の利用対象を示す利用対象情報を記憶する利用対象記憶手段と、識別情報と該識別情報に対応付けられた１以上の属性項目の属性値とを含むデータを前記利用対象情報ごとに属性項目単位で記憶する複数のデータ記憶手段とを有するデータ管理システムのコンピュータに、
アプリケーションソフトウェアにより属性値の出力をする場合に、前記利用対象情報が示す利用対象として該アプリケーションソフトウェアが含まれる属性項目を検索し、検索された属性項目に関する属性値を前記複数のデータ記憶手段から取得し、前記利用対象情報と前記識別情報に基づいて統合して出力するステップ
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ管理システム及びプログラムに関する。

【背景技術】

【0002】

特許文献１は、異なるデータセンタクライアントが共通に参照可能な基本データベースと、各データセンタクライアントのみがそれぞれに参照可能なデータセンタクライアント毎の一つ又は複数のカスタムデータ−ベースとを備えた、データセンタシステムであって、カスタムデータベースのデータ項目又は該データベースコマンドのデータ項目が、データセンタクライアント毎に定義可能なカスタムアプリケーションプログラムを介して、基本データベースのデータ項目にリンクされていることを特徴とするデータセンタシステムについて開示している。

【0003】

特許文献２は、データベースにアクセスするプログラムを実行するデータベース装置におけるデータベースへのアクセス制御方法であって、重要度が個別に設定されたデータを蓄積した上記データベースにアクセスする上記プログラムに対して、データアクセス権限を設定するデータアクセス権限設定処理と、上記プログラムが上記データベースのデータにアクセスしようとした時に、当該データの重要度と上記データアクセス権限とに基づいて、当該アクセスの可否を判定して、当該プログラムによる当該データへのアクセスを制御するデータベースアクセス制御処理と、を含むことを特徴とするデータベースへのアクセス制御方法について開示している。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００５−１８２２９７号公報

【特許文献2】特開２００２−１８２９８３号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

本発明の目的は、異なる記憶先に記憶された各情報についてどのアプリケーションソフトウェアに用いられる対象とするかを容易に管理することができるデータ管理システム及びプログラムを提供することである。

【課題を解決するための手段】

【0006】

請求項１に係る本発明は、属性項目ごとに、当該属性項目の利用対象を示す利用対象情報を記憶する利用対象記憶手段と、識別情報と該識別情報に対応付けられた１以上の属性項目の属性値とを含むデータを属性項目単位で記憶する複数のデータ記憶手段と、アプリケーションソフトウェアにより属性値の出力をする場合に、前記利用対象情報が示す利用対象として該アプリケーションソフトウェアが含まれる属性項目を検索し、検索された属性項目に関する属性値を複数の記憶手段から取得し、前記識別情報に基づいて統合して出力する統合出力手段と、を有するデータ管理システムである。

【0007】

請求項２に係る本発明は、前記利用対象記憶手段が記憶する利用対象情報を変更する利用対象変更手段をさらに有する請求項１記載のデータ管理システムである。

【0008】

請求項３に係る本発明は、前記利用対象変更手段は、前記利用対象記憶手段が記憶する利用対象情報について、特定のアプリケーションソフトウェアで用いられることを示す利用対象情報を、複数のアプリケーションソフトウェアで用いられることを示す利用対象情報へと変更する請求項２記載のデータ管理システムである。

【0009】

請求項４に係る本発明は、属性項目ごとに、当該属性項目の属性値の記憶先を示す記憶先情報を記憶する記憶先記憶手段をさらに有し、前記統合出力手段は、前記記憶先記憶手段が記憶する記憶先情報により特定される取得先から属性値を取得する請求項1乃至３いずれか記載のデータ管理システムである。

【0010】

請求項５に係る本発明は、異なる複数の属性項目を関連付ける属性項目関連付け手段と、前記関連付け手段により関連付けられた属性項目のいずれかの属性値を、前記関連付け手段により関連付けられた他の属性値に反映させる属性値反映手段とをさらに有する請求項１乃至４いずれか記載のデータ管理システムである。

【0011】

請求項６に係る本発明は、前記属性項目関連付け手段により関連付けられた属性項目間における属性値の使用権限を設定する使用権限設定手段をさらに有し、前記属性値反映手段は、前記使用権限設定手段により設定された使用権限に基づいて反映が許可された場合に属性値を反映させる請求項５記載のデータ管理システムである。

【0012】

請求項７に係る本発明は、属性項目ごとに、当該属性項目の利用対象を示す利用対象情報を記憶する利用対象記憶手段と、識別情報と該識別情報に対応付けられた１以上の属性項目の属性値とを含むデータを属性項目単位で記憶する複数のデータ記憶手段とを有するデータ管理システムのコンピュータに、アプリケーションソフトウェアにより属性値の出力をする場合に、前記利用対象情報が示す利用対象として該アプリケーションソフトウェアが含まれる属性項目を検索し、検索された属性項目に関する属性値を複数の記憶手段から取得し、前記識別情報に基づいて統合して出力するステップを実行させるプログラムである。

【発明の効果】

【0013】

請求項１に係る本発明によれば、異なる記憶先に記憶された各情報についてどのアプリケーションソフトウェアに用いられる対象とするかを本構成を有しない場合に比較して容易に管理することができる。

【0014】

請求項２に係る本発明によれば、複数のアプリケーションソフトウェア間でデータを共用する際、本構成を有しない場合に比較して、共用されるデータの対象を容易に変更することができる。

【0015】

請求項３に係る本発明によれば、特定のアプリケーションソフトウェア用として利用されていたデータについて他のアプリケーションソフトウェアでも利用されるよう、本構成を有しない場合に比較して容易に変更することができる。

【0016】

請求項４に係る本発明によれば、取得すべき情報の記憶先を本構成を有しない場合に比較して容易に特定することができる。

【0017】

請求項５に係る本発明によれば、属性項目の属性値として関連性のある他の属性項目の属性値を参照し、又は属性項目の属性値の編集内容を関連性のある他の属性項目の属性値にも適用することができる。

【0018】

請求項６に係る本発明によれば、データの完全性又は機密性を管理することができる。

【0019】

請求項７に係る本発明によれば、異なる記憶先に記憶された各情報についてどのアプリケーションソフトウェアに用いられる対象とするかを本構成を有しない場合に比較して容易に管理することができる。

【図面の簡単な説明】

【0020】

【図1】本発明の実施形態に係るデータ管理システム２を示す模式図である。

【図2】本発明の実施形態に係る共用サーバ８、アプリαサーバ４、アプリβサーバ６及び端末装置１０のハードウェア構成の一例を示す模式図である。

【図3】アプリαサーバ４による出力例を示す模式図であり、（ａ）は、ユーザＩＤが"tanaka"である社員の個人情報の出力例を示し、（ｂ）は、ユーザＩＤが"suzuki"である社員の個人情報の出力例を示している。

【図4】アプリβサーバ６による出力例を示す模式図であり、（ａ）は、ユーザＩＤが"tanaka"である社員についての情報の出力例を示し、（ｂ）は、ユーザＩＤが"suzuki"である社員についての出力例を示している。

【図5】各データベースで管理されるデータの一例を示す模式図であり、（ａ）は共用ＤＢ１８により管理されるデータの一例を示し、（ｂ）はアプリαＤＢ１４により管理されるデータの一例を示し、（ｃ）はアプリβＤＢ１６により管理されるデータの一例を示している。

【図6】内部ＩＤを介して各データベースのデータが統合される様子を示す模式図である。

【図7】新規のユーザレコードの登録について説明する模式図である。

【図8】新規にアプリケーションソフトウェアが導入される場合について説明する模式図である。

【図9】本実施形態に係るデータ管理システム２が記憶する属性項目管理情報の一例を示す表である。

【図10】利用対象情報に基づいて統合されたデータの一例を示す模式図であり、（ａ）はアプリαにより表示出力されるデータの一例を示し、（ｂ）はアプリβにより表示出力されるデータの一例を示している。

【図11】利用対象情報が変更された属性項目管理情報の一例を示す表である。

【図12】表示出力されるデータについて示す模式図であり、（ａ）はアプリαにより表示出力されるデータを示し、（ｂ）はアプリβにより表示出力されるデータを示している。

【図13】利用対象情報の変更後におけるアプリβサーバ６により出力されるデータの一例を示す模式図であり、（ａ）は、ユーザＩＤが"tanaka"である社員についての出力例を示し、（ｂ）は、ユーザＩＤが"suzuki"である社員についての出力例を示している。

【図14】データ管理システム２において、アプリα又はアプリβによりデータが統合出力される際の動作の一例を示すフローチャートである。

【図15】データ管理システム２において、属性項目の利用対象を変更する際の動作の一例を示すフローチャートである。

【図16】変形例に係るデータ管理システム２における各データベースで管理されるデータの一例を示す模式図であり、（ａ）は共用ＤＢ１８により管理されるデータの一例を示し、（ｂ）はアプリαＤＢ１４により管理されるデータの一例を示し、（ｃ）はアプリβＤＢ１６により管理されるデータの一例を示している。

【図17】変形例に係るデータ管理システム２が記憶する属性項目管理情報の一例を示す表である。

【図18】変形例に係るデータ管理システム２において、異なる複数の属性項目を関連付ける動作の一例を示すフローチャートである。

【図19】変形例に係るデータ管理システム２において、関連付けられた属性項目の属性値を関連付けられた他の属性値に反映させる動作の一例を示すフローチャートであり、（ａ）は属性値を出力する際の動作の一例を示し、（ｂ）は属性値を編集する際の動作の一例を示している。

【図20】図１９で示した動作例について、上述のようにアクセス権による反映の許否を設けるよう修正したフローチャートである。

【発明を実施するための形態】

【0021】

本発明の実施形態について図面を参照して説明する。
図１は、本発明の実施形態に係るデータ管理システム２を示す模式図である。データ管理システム２は、アプリケーションソフトウェアに基づく処理を行うサーバ４、６と、複数のアプリケーション間で共用されるデータを管理するサーバ８と、端末装置１０とを有し、ネットワーク１２に接続されている。サーバ４はデータベース１４を、サーバ６はデータベース１６を、サーバ８はデータベース１８をそれぞれ備えており、それぞれデータを管理している。

【0022】

なお、本実施形態では、アプリケーションソフトウェアに基づく処理を行うサーバとして、サーバ４とサーバ６を含む構成を例に説明するが、アプリケーションソフトウェアに基づく処理を行うサーバは、１台であってもよいし、３台以上であってもよい。また、アプリケーションソフトウェアに基づく処理を行うサーバと、共用されるデータを管理するサーバとが、１台の筐体として構成されていてもよい。ただし、この場合も、データベースは、サーバごとに構築される。

【0023】

データベース１４〜１８は、いずれも、データを属性項目単位で記憶するよう構成されたデータベースであり、データに対する属性項目の追加、削除などの操作をデータベースのスキーマを変更せずに行なうことができるよう構成されている。

【0024】

本実施形態では、データを属性項目単位で記憶するよう、データベース１４〜１８は、カラム指向型ＮＯＳＱＬデータベースとして構成されている。カラム指向型ＮＯＳＱＬデータベースについては、例えば、本橋信也，河野達也，鶴見利章著，「ＮＯＳＱＬの基礎知識 ビッグデータを活かすデータベース技術」，リックテレコム，２０１２年４月，ｐｐ．６１−６４が参考文献として挙げられる。カラム指向型ＮＯＳＱＬデータベースでは、カラムファミリと呼ばれる情報が存在し、１以上の属性項目をどのようにまとめるかを定義している。

【0025】

サーバ８は、データベース１８において記憶するデータを、アプリケーションソフトウェアからの要求に応じて提供するサーバである。以下、データベース１８を共用ＤＢ１８といい、サーバ８を共用サーバ８という。本実施形態では、共用サーバ８は、サーバ４及びサーバ６に対し、共用ＤＢ１８において記憶するデータを提供する。

【0026】

サーバ４は、アプリケーションソフトウェアαに基づく処理を、データベース１４で記憶するデータを用いて行うサーバである。以下、アプリケーションソフトウェアαをアプリαといい、データベース１４をアプリαＤＢ１４といい、サーバ４をアプリαサーバ４という。ここで、アプリαサーバ４は、アプリαに基づく処理を行う際、共用サーバ８における共用ＤＢ１８で記憶されているデータに加え、アプリαＤＢ１４で記憶するデータを用いて処理を行う。

【0027】

サーバ６は、アプリαとは異なるアプリケーションソフトウェアβに基づく処理を、データベース１６で記憶するデータを用いて行うサーバである。以下、アプリケーションソフトウェアβをアプリβといい、データベース１６をアプリβＤＢ１６といい、サーバ６をアプリβサーバ６という。ここで、アプリβサーバ６は、アプリβに基づく処理を行う際、共用サーバ８における共用ＤＢ１８で記憶されているデータに加え、アプリβＤＢ１６で記憶するデータを用いて処理を行う。

【0028】

なお、アプリα、アプリβは、それぞれ、アプリαＤＢ１４、アプリβＤＢ１６に基づくサービスを提供するアプリケーションソフトウェアである。

【0029】

端末装置１０は、アプリαサーバ４又はアプリβサーバ６に対して処理を要求するクライアント端末である。なお、端末装置１０は、共用サーバ８に対しても処理を要求してもよい。

【0030】

図２は、アプリαサーバ４、アプリβサーバ６、共用サーバ８及び端末装置１０のハードウェア構成の一例を示す模式図である。

【0031】

。
各装置は、図２に示されるように、ＣＰＵ２０、メモリ２２、ハードディスクドライブ（ＨＤＤ）等の記憶部２４、ネットワーク１２を介して他の装置等との間でデータの送信及び受信を行う通信インタフェース（ＩＦ）２６、入出力部２８を有し、これらの構成要素は、制御バス３０を介して互いに接続されている。

【0032】

アプリαサーバ４、アプリβサーバ６及び共用サーバ８において、アプリαＤＢ１４、アプリβＤＢ１６、共用ＤＢ１８の各データベースは、それぞれ各サーバを構成する記憶部２４上に構築されている。

【0033】

ＣＰＵ２０は、メモリ２２または記憶部２４に格納されたプログラムに基づいて処理を実行して、各装置の動作を制御する。

【0034】

なお、本実施形態では、ＣＰＵ２０は、メモリ２２または記憶部２４内に格納されたプログラムを読み出して実行するものとして説明したが、当該プログラムをＣＤ−ＲＯＭ等の記憶媒体に格納してＣＰＵ２０に提供することも可能である。

【0035】

次に、図３及び図４により、アプリαサーバ４及びアプリβサーバ６による処理により出力されるデータについて具体例に基づいて説明する。なお、ここでは、アプリαが、社員の個人情報を管理するサービスを提供し、アプリβが、社員におけるスキャナ装置の利用に関する情報を管理するサービスを提供する場合を一例とするが、アプリαサーバ４及びアプリβサーバ６の提供するサービスはこれらに限定されない。

【0036】

図３は、アプリαサーバ４による出力例を示す模式図であり、図３（ａ）は、ユーザＩＤが"tanaka"である社員の個人情報の出力例を示し、図３（ｂ）は、ユーザＩＤが"suzuki"である社員の個人情報の出力例を示している。ここでは、社員ごとに、当該社員を識別する情報であるユーザＩＤ、当該社員の所属部署、当該社員の国籍、当該社員の住所、当該社員の年齢を出力している。

【0037】

図４は、アプリβサーバ６による出力例を示す模式図であり、図４（ａ）は、ユーザＩＤが"tanaka"である社員についての情報の出力例を示し、図４（ｂ）は、ユーザＩＤが"suzuki"である社員についての出力例を示している。ここでは、社員ごとに、当該社員を識別する情報であるユーザＩＤ、当該社員の所属部署、当該社員がスキャナ装置を利用した際の課金方式、当該社員がスキャナで読み取った読取画像データの保存先フォルダを出力している。

【0038】

ここで、アプリαサーバ４による出力は、共用サーバ８における共用ＤＢ１８が管理するデータと、アプリαＤＢ１４が管理するデータとを統合した出力である。また、同様に、アプリβサーバ６による出力は、共用サーバ８における共用ＤＢ１８が管理するデータと、アプリβＤＢ１６が管理するデータとを統合した出力である。以下、図３及び図４で示した例に基づいて、各データベースで管理されるデータについて説明する。

【0039】

図５は、各データベースで管理されるデータの一例を示す模式図であり、図５（ａ）は共用ＤＢ１８により管理されるデータの一例を示し、図５（ｂ）はアプリαＤＢ１４により管理されるデータの一例を示し、図５（ｃ）はアプリβＤＢ１６により管理されるデータの一例を示している。

【0040】

各データベースは、１以上の属性項目の属性値と、この１以上の属性項目の属性値の集合を識別する識別情報（キー）とを対応付けて記憶する。図５で示した例では、「内部ＩＤ」が識別情報となっている。共用ＤＢ１８では、属性項目「ユーザＩＤ」及び「所属」が、識別情報と対応付けて記憶されている。アプリαＤＢ１４では、属性項目「国籍」、「住所」及び「年齢」が、識別情報と対応付けて記憶されている。アプリβＤＢ１６では、属性項目「課金方式」及び「フォルダ」が、識別情報と対応付けて記憶されている。

【0041】

なお、共用ＤＢ１８はネットワーク上の位置として位置情報ａａａで表される位置に存在し、アプリαＤＢ１４はネットワーク上の位置として位置情報ｂｂｂで表される位置に存在し、アプリβＤＢ１６はネットワーク上の位置として位置情報ｃｃｃで表される位置に存在する。

【0042】

このように、データ管理システム２において、各サーバのデータベースで管理されるデータは、識別情報である内部ＩＤと対応付けられて記憶されており、アプリα（アプリβ）がアプリαＤＢ１４（アプリβＤＢ１６）で管理されているデータと、共用ＤＢ１８で管理されているデータとを統合して出力する際には、内部ＩＤが同じであるデータについて、統合して出力する（図６参照）。

【0043】

次に、新規データの生成について説明する。新規にユーザレコードを登録する場合、ユーザＩＤは、例えば、ユーザ登録手続きの際に指定される一意の情報（例えば、メールアドレス）が用いられ、内部ＩＤは、例えば、ユーザＩＤのハッシュ値が用いられる。具体例を挙げると、"[e-mail]"のハッシュ値（ここでは、１２３４であるとする）が、このユーザに関するレコードの内部ＩＤとなる。なお、内部ＩＤが定まった後に、メールアドレス等の変更によりユーザＩＤが変更された場合でも、内部ＩＤは変更されない。

【0044】

新規のユーザレコードの登録は、共用サーバ８で行われもよいし、アプリαサーバ４で行われもよいし、アプリβサーバ６で行われもよい。図７に示すように、アプリαサーバ４や、アプリβサーバ６で新規のユーザレコードの登録が行われた場合、共用ＤＢ１８においても内部ＩＤと対応付けられてデータが生成される。図７では、アプリαで、ユーザＩＤが"suzuki"であるユーザレコードを登録する場合を例示しており、アプリαを介して登録された属性値のうち、属性項目「ユーザＩＤ」、「所属」については共用ＤＢ１８が管理するデータとして記憶され、属性項目「国籍」、「住所」、「年齢」についてはアプリαＤＢ１４が管理するデータとして記憶されている。

【0045】

次に、新規にアプリケーションソフトウェアが導入される場合について説明する。ここでは、共用サーバ８及びアプリαサーバ４が既存のサーバであり、新たにアプリβサーバ６が導入される場合を例に説明する。なお、ここでは、導入の際、アプリβＤＢ１６にはデータがまだ登録されていないものとする。新規にアプリβサーバ６を導入すると、アプリβの出力では、共用ＤＢ１８のデータを利用するため共用ＤＢ１８が管理する属性項目のデータを出力することはできるが、アプリβＤＢ１６にデータが存在しないので、アプリβＤＢ１６が管理する属性項目については表示対象がない。ここで、図８に示すように、アプリβを介して、アプリβＤＢ１６が管理する属性項目についてのデータを追加すると（図８に示した例では、ユーザＩＤが"tanaka"のユーザに対し属性項目「課金方式」の属性値を追加し、ユーザＩＤが"suzuki"のユーザに対し属性項目「フォルダ」の属性値を追加している）、内部ＩＤと対応付けられて、アプリβＤＢ１６に、追加されたデータが記憶される。

【0046】

次に、データの統合出力の詳細について説明する。上述のように、アプリα（アプリβ）では、アプリαＤＢ１４（アプリβＤＢ１６）で管理されているデータと、共用ＤＢ１８で管理されているデータとを統合して出力する。ここで、データの統合は、利用対象情報（カラムファミリ）を用いて行われる。

【0047】

図９は、本実施形態に係るデータ管理システム２が記憶する属性項目管理情報の一例を示す表である。図９に示されるように、データ管理システム２は、データ管理システム２の各データベースが管理する属性項目ごとに、当該属性項目の利用対象を示す利用対象情報と当該属性項目の属性値の記憶先とを記憶する。なお、属性項目管理情報は、いずれかのデータベースに記憶されていてもよいし、データベースとは異なる記憶形態により記憶されていてもよい。また、物理的な記憶位置も問わず、記憶位置が端末装置１０の記憶部２４であっても、各サーバの記憶部２４のいずれかであってもよい。

【0048】

利用対象情報は、当該属性項目がどのように利用されるかを示す利用対象を定義する情報であり、本実施形態で示した例では、“共用”、“アプリα”、“アプリβ”の３種類のいずれかが付与されている。具体的には、ここでは、共用ＤＢ１８が管理する属性項目について利用対象情報として“共用”が付与されており、アプリαＤＢ１４が管理する属性項目について利用対象情報として“アプリα”が付与されており、アプリβＤＢ１６が管理する属性項目について利用対象情報として“アプリβ”が付与されている。なお、後述するように、属性項目に対して付与されている利用対象情報は変更可能である。

【0049】

データ管理システム２において、アプリα（アプリβ）は、利用対象情報が“共用”又は“アプリα”（“アプリβ”）である属性項目の属性値について、内部ＩＤが同じであるものをデータ管理システム２の各データベースから取得し、統合して出力する。具体的には、アプリα（アプリβ）は、属性項目管理情報を参照し、利用対象情報が“共用”又は“アプリα”（“アプリβ”）である属性項目を検索し、検索された属性項目について属性項目管理情報を参照して記憶先を確認し、この確認した記憶先から属性値を取得する。

【0050】

図１０は、利用対象情報に基づいて統合されたデータの一例を示す模式図であり、図１０（ａ）は、アプリαにより表示出力されるデータの一例を示し、図１０（ｂ）は、アプリβにより表示出力されるデータの一例を示している。

【0051】

以上説明した出力例では、アプリαＤＢ１４（アプリβＤＢ１６）が管理しているデータについては、専らアプリα（アプリβ）における出力に用いられる場合について説明した。次に、アプリαＤＢ１４（アプリβＤＢ１６）が管理しているデータについて、共用ＤＢ１８に管理されているデータのように、他のアプリケーションソフトウェアに提供するようデータ構成を変更することについて説明する。

【0052】

データ管理システム２は、記憶された利用対象情報を変更する利用対象変更手段を備えており、利用対象情報を任意に変更できるよう構成されている。例えば、データ管理システム２は、システム管理者などのユーザの操作による指示に従って、利用対象情報を変更する。

【0053】

ここでは、アプリαＤＢ１４が管理する属性項目「年齢」について、アプリα以外の他のアプリケーションソフトウェアでも利用可能にする場合を想定して説明する。

【0054】

この場合、属性項目「年齢」について、利用対象情報を“アプリα”から“共用”に変更されることにより（図１１参照）、属性項目「年齢」が、アプリαに限らず、アプリβにおいても出力されるよう変更される（図１２参照）。この結果、図１３に示されるように、アプリβによる出力において、属性項目「年齢」の属性値が出力される。なお、図１３において、（ａ）は、ユーザＩＤが"tanaka"である社員についての情報の出力例を示し、（ｂ）は、ユーザＩＤが"suzuki"である社員についての出力例を示している。

【0055】

このように、利用対象変更手段は、例えば、特定のアプリケーションソフトウェアで用いられることを示す利用対象情報を、複数のアプリケーションソフトウェアで用いられることを示す利用対象情報へと変更する。なお、利用対象変更手段は、複数のアプリケーションソフトウェアで用いられることを示す利用対象情報を特定のアプリケーションソフトウェアで用いられることを示す利用対象情報へと変更してもよい。

【0056】

次に、データ管理システム２の動作について説明する。
図１４は、データ管理システム２において、アプリα又はアプリβによりデータが統合出力される際の動作の一例を示すフローチャートである。

【0057】

ステップ１００（Ｓ１００）において、アプリα（アプリβ）は、属性項目管理情報を参照し、利用対象情報が“共用”である属性項目を検索する。

【0058】

ステップ１０２（Ｓ１０２）において、アプリα（アプリβ）は、アプリα（アプリβ）は、属性項目管理情報を参照し、利用対象情報が“アプリα”（“アプリβ”）である属性項目を検索する。

【0059】

ステップ１０４（Ｓ１０４）において、ステップ１００及びステップ１０２で検索された属性項目の属性値を取得する。具体的には、属性項目管理情報を参照して属性値の記憶先を確認し、この確認した記憶先から属性値を取得する。なお、属性値の取得は、全ての内部ＩＤを対象としてもよいし、任意の方法により指定された範囲の内部ＩＤに対応する属性値に限ってもよい。

【0060】

ステップ１０６（Ｓ１０６）において、アプリα（アプリβ）は、内部ＩＤごとにデータを統合し、出力する。

【0061】

図１５は、データ管理システム２において、属性項目の利用対象を変更する際の動作の一例を示すフローチャートである。

【0062】

ステップ２００（Ｓ２００）において、データ管理システム２は、利用対象を変更する属性項目を指定する指示を受付ける。例えば、ユーザが利用対象を変更する属性項目を指定する操作を行うことにより指示が入力される。

【0063】

ステップ２０２（Ｓ２０２）において、データ管理システム２は、利用対象情報の変更指示を受付ける。例えば、ユーザが変更後の利用対象情報を入力する操作を行うことにより指示が入力される。

【0064】

ステップ２０４（Ｓ２０４）において、データ管理システム２は、ステップ２００及びステップ２０２の指示に従って、記憶している属性項目管理情報のうち利用対象情報について書き換えを行う。

【0065】

このように利用対象情報が変更された後、変更された利用対象情報に基づいて図１４に示した一連の処理が行われることにより、変更が反映された出力がなされることとなる。

【0066】

以下、上記実施形態の変形例について説明する。
変形例では、異なる複数の属性項目を関連付ける属性項目関連付け手段と、関連付けられた属性項目のいずれかの属性値を関連付けられた他の属性値に反映させる属性値反映手段とを有する点で、上記実施形態と異なる。変形例では、データ管理システム２は、例えば、システム管理者などのユーザの操作による指示に従って、異なる複数の属性項目の関連付けを行う。

【0067】

異なる属性項目であっても一体的に取り扱いたい場合が考えられる。例えば、異なるデータベースにそれぞれ管理される異なる属性項目について属性値が同じである場合、形式的には異なる属性項目であっても実体的には同じ属性項目を意味しており一体的に取り扱うことが好ましい。また、属性値が同じでなくても一方の属性値が他方の属性値の一部と同じである場合（例えば、ユーザの生活の本拠である場所を表す属性項目「住所」及び「所在地」について、一方の属性値が“神奈川県横浜市”であり、他方の属性値が“神奈川県”である場合）などのように相関関係がある場合についても、異なる属性項目を一体的に取り扱うことが好ましい。

【0068】

ここで、一体的に取り扱うとは、一体的に取り扱われる属性項目のうちいずれかの属性項目の属性値を、一体的に取り扱われる他の属性項目の属性値に反映させることをいい、例えば、属性値を出力する際に当該属性項目と一体的に取り扱われる他の属性項目の属性値を参照して出力したり、属性値を変更した場合に当該属性項目と一体的に取り扱われる他の属性項目の属性値も同様に変更したりすることが該当する。

【0069】

以下、変形例の特徴について、図１６及び図１７により具体例を交えて説明する。
図１６は、変形例に係るデータ管理システム２における各データベースで管理されるデータの一例を示す模式図であり、図１６（ａ）は共用ＤＢ１８により管理されるデータの一例を示し、図１６（ｂ）はアプリαＤＢ１４により管理されるデータの一例を示し、図１６（ｃ）はアプリβＤＢ１６により管理されるデータの一例を示している。図１６に示した例では、アプリβＤＢ１６により管理されるデータとして、属性項目「所在地」が追加されている点で、図５に示した一例と異なる。

【0070】

なお、アプリαＤＢ１４により管理される属性項目「住所」と、アプリβＤＢ１６により管理される属性項目「所在地」は、いずれもユーザの生活の本拠である場所を表す属性項目であるものとする。

【0071】

ここで、アプリαＤＢ１４により管理される属性項目「住所」と、アプリβＤＢ１６により管理される属性項目「所在地」とを関連付ける場合を想定する。データ管理システム２は、例えばシステム管理者などのユーザの指示に従って、属性項目「住所」と属性項目「所在地」とを関連付ける。

【0072】

なお、一体的に取り扱うべき属性項目群をユーザが見つけるのを補助するために、データ管理システム２は、各データベースが管理する属性項目及びその属性値を一覧表示するよう構成してもよい。この場合、例えば、ユーザは、表示された一覧を見て、属性項目の名称と、その属性値とから、一体的に取り扱うべき属性項目群を見つける。

【0073】

一体的に取り扱うべき属性項目群の発見は、データ管理システム２が自動的に行ってもよい。例えば、各データベースが管理する属性項目の名称及びその属性値を参照し、一致又は類似する属性項目群を一体的に取り扱うべき属性項目群として抽出するよう構成してもよい。

【0074】

データ管理システム２は、例えば、関連付けられたことを示す情報を記憶することにより、属性項目の関連付けを実現する。本変形例では、属性項目管理情報として記憶することにより属性項目の関連付けを実現する。

【0075】

図１７は、変形例に係るデータ管理システム２が記憶する属性項目管理情報の一例を示す表である。図１７に示した例では、属性項目「住所」に対し、対応する属性として「所在地」が存在する旨の情報が記憶され、属性項目「所在地」に対し、対応する属性として「住所」が存在する旨の情報が記憶されている。

【0076】

なお、図１７に示した例では、２つの属性項目について互いに関連するものとして関連付けを行っているが、３つ以上の属性項目について相互に関連するものとして関連付けを行ってもよい。

【0077】

データ管理システム２は、このように関連付けについての情報を含む属性項目管理情報を参照し、一体的に取り扱われる属性項目のうちいずれかの属性項目の属性値を、一体的に取り扱われる他の属性項目の属性値に反映させる。

【0078】

以下、図１８及び図１９により、変形例に係るデータ管理システム２の動作について説明する。

【0079】

図１８は、変形例に係るデータ管理システム２において、異なる複数の属性項目を関連付ける動作の一例を示すフローチャートである。

【0080】

ステップ３００（Ｓ３００）において、データ管理システム２は、一体的に取り扱う属性項目群の指定を受付ける。例えば、ユーザが一体的に取り扱う属性項目群を指定する操作を行うことにより、データ管理システム２は一体的に取り扱う属性項目群の指定の指示を受付ける。

【0081】

ステップ３０２（Ｓ３０２）において、ステップ３００で指定された複数の属性項目について、相互に対応する属性項目である旨を属性項目管理情報として記憶する。

【0082】

図１９は、変形例に係るデータ管理システム２において、関連付けられた属性項目の属性値を関連付けられた他の属性値に反映させる動作の一例を示すフローチャートであり、図１９（ａ）は属性値を出力する際の動作の一例を示し、図１９（ｂ）は属性値を編集する際の動作の一例を示している。

【0083】

まず、図１９（ａ）に基づいて属性値を出力する際の動作について説明する。
ステップ４００（Ｓ４００）において、出力対象の属性項目の属性値がデータベース上に格納されているか否かを確認し、属性値が格納されている場合には、ステップ４０２（Ｓ４０２）で、格納されている属性値を出力する。一方、属性値が格納されていない場合には、ステップ４０４（Ｓ４０４）へ移行する。

【0084】

ステップ４０４（Ｓ４０４）において、出力対象の属性項目に関連付けられた属性項目が存在するか否かを確認する。具体的には、属性項目管理情報を参照し、出力対象の属性項目に関連付けられた属性項目があるかを確認する。関連付けられた属性項目がある場合には、ステップ４０６へ移行し、関連付けられた属性項目がない場合には、ステップ４０８へ移行する。

【0085】

ステップ４０６（Ｓ４０６）では、出力対象の属性項目に関連付けられている属性項目の属性値を、出力対象の属性項目の属性値として出力する。一方、ステップ４０８（Ｓ４０８）では、出力すべき属性値がないため出力をしない。なお、ステップ４０６において、出力対象の属性項目に関連付けられている属性項目に属性値がない場合にも、ステップ４０８と同様、出力をしない。

【0086】

次に、図１９（ｂ）に基づいて属性値を編集する際の動作について説明する。
ステップ５００（Ｓ５００）において、属性値の編集指示を受付ける。

【0087】

ステップ５０２（Ｓ５０２）において、ステップ５００で指示された編集内容に従って属性値を変更する。

【0088】

ステップ５０４（Ｓ５０４）において、属性値が編集された属性項目に関連付けられている属性項目が存在するか否かを確認する。関連付けられた属性項目がある場合には、ステップ５０６へ移行し、関連付けられた属性項目がない場合には、終了する。

【0089】

ステップ５０６（Ｓ５０６）において、ステップ５００で指示された編集内容に従って、関連付けられた属性項目の属性値も変更する。

【0090】

以上、関連付けられた属性項目の属性値を関連付けられた他の属性項目の属性値に無条件で反映させる構成について説明したが、関連付けられた属性項目間における属性値の使用権限（アクセス権）を設定し、設定されたアクセス権に基づいて属性項目間の反映が許可された場合に属性値を反映させるよう構成してもよい。

【0091】

例えば、属性項目ごとに、ｎ段階（ｎは２以上の整数）のアクセス権のいずれかを付与し、属性項目間における属性値の反映の際に、両属性項目のアクセス権が予め定められた条件を満たす場合に、反映を許可するよう構成してもよい。なお、属性項目ごとに付与されたアクセス権を示す情報は、例えば、属性項目管理情報として管理される。

【0092】

アクセス権による反映の拒否について、Bell-LaPadulaモデルを用いてデータの機密性を確保してもよいし、Biba Integrityモデルを用いてデータの完全性を確保してのよい。

【0093】

例えば、反映元の属性項目のアクセス権と反映先の属性項目のアクセス権とを比較した際、反映元の属性項目のアクセス権が反映先の属性項目のアクセス権よりも上位段階のアクセス権である場合に、反映先の属性項目の属性値を反映元の属性項目の属性値で書き換えることを禁止するよう構成することにより、データの機密性の確保に資する。

【0094】

また、例えば、反映元の属性項目のアクセス権と反映先の属性項目のアクセス権とを比較した際、反映元の属性項目のアクセス権が反映先の属性項目のアクセス権よりも下位段階のアクセス権である場合に、反映先の属性項目の属性値を反映元の属性項目の属性値で書き換えることを禁止するよう構成することにより、データの完全性の確保に資する。

【0095】

図２０は、図１９で示した動作例について、上述のようにアクセス権による反映の許否を設けるよう修正したフローチャートである。

【0096】

まず、図２０（ａ）に基づいて属性値を出力する際の動作について説明する。図２０（ａ）にあるように、ステップ４０５（Ｓ４０５）が追加されている点で図１９（ａ）に示したフローチャートと異なる。ステップ４０４において、関連付けられた属性項目があると判定された場合、ステップ４０５へ移行する。

【0097】

ステップ４０５では、反映元の属性項目のアクセス権と反映先の属性項目のアクセス権とを比較し、両属性項目のアクセス権が、属性値の参照についての予め定められた条件を満たすか否かを判定し、条件を満たす場合にステップ４０６へ移行し、条件を満たさない場合にステップ４０８へ移行する。

【0098】

次に、図２０（ｂ）に基づいて属性値を編集する際の動作について説明する。図２０（ｂ）にあるように、ステップ５０５（Ｓ５０５）が追加されている点で図１９（ｂ）に示したフローチャートと異なる。ステップ５０４において、関連付けられた属性項目があると判定された場合、ステップ５０５へ移行する。

【0099】

ステップ５０５では、反映元の属性項目のアクセス権と反映先の属性項目のアクセス権とを比較し、両属性項目のアクセス権が、属性値の変更の反映についての予め定められた条件を満たすか否かを判定し、条件を満たす場合にステップ５０６へ移行し、条件を満たさない場合には終了する。

【0100】

以上、本発明の実施形態と変形例について説明したが、アプリα（アプリβ）は、必ずしも複数のデータベースのデータを統合して出力しなくてもよく、アプリαＤＢ１４（アプリβＤＢ１６）が管理するデータだけを出力対象としてもよいし、共用ＤＢ１８が管理するデータだけを出力対象としてもよい。

【0101】

また、本発明の実施形態及びその変形例において、利用対象情報の一例として、“共用”、“アプリα”、“アプリβ”の３種類のいずれかが付与されている例について説明したが、利用対象情報としては、これに限られない。例えば、“アプリα”、“アプリβ”など特定の１つのアプリケーションソフトウェアに限定するのではなく、“アプリα及びアプリβ”、“アプリβ及びアプリγ”などのように特定の複数のアプリケーションソフトウェアに限定する利用対象情報であってもよい。具体的には例えば、属性項目「ユーザＩＤ」についての利用対象情報を“アプリα及びアプリβ”とし、属性項目「所属」の利用対象情報“アプリβ及びアプリγ”としてもよい。この場合、属性項目「ユーザＩＤ」は、アプリαでも利用され、アプリβでも利用されることを示し、属性項目「所属」は、アプリβでも利用され、アプリγでも利用されることを示す。

【符号の説明】

【0102】

２ データ管理システム
４ アプリαサーバ
６ アプリβサーバ
８ 共用サーバ
１０ 端末装置
１４ アプリαＤＢ
１６ アプリβＤＢ
１８ 共用ＤＢ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】