(57)【要約】【課題】データの変遷を容易に提供すること。【解決手段】実施形態に係るデータ管理装置は、記憶部と、格納部と、検索部とを有する。記憶部は、所定の事物に関する属性情報と、属性情報が事物の属性に該当する期限を示す有効期限とを対応付けて記憶する。格納部は、属性情報を更新する旨の更新要求を受け付けた場合に、記憶部に記憶されている有効期限のうち現時点が有効期限内であることを示す有効期限を、かかる有効期限に対応する最新属性情報が事物の属性に該当しなくなった日付に更新し、更新要求に含まれる新たな属性情報と新たな属性情報が現時点で事物の属性に該当することを示す有効期限とを記憶部に格納する。検索部は、属性情報の検索要求を受け付けた場合に、検索要求に含まれる属性情報を記憶部から検索する。【選択図】図１
2013171495.tif 000002
【特許請求の範囲】
【請求項１】
所定の事物に関する属性情報と、当該属性情報が当該事物の属性に該当する期限を示す有効期限とを対応付けて記憶する記憶部と、
前記属性情報を更新する旨の更新要求を受け付けた場合に、前記記憶部に記憶されている有効期限のうち現時点が有効期限内であることを示す有効期限を、当該有効期限に対応する最新属性情報が前記事物の属性に該当しなくなった日付に更新し、前記更新要求に含まれる新たな属性情報と当該新たな属性情報が現時点で前記事物の属性に該当することを示す有効期限とを前記記憶部に格納する格納部と、
前記属性情報の検索要求を受け付けた場合に、当該検索要求に含まれる属性情報を前記記憶部から検索する検索部と
を備えたことを特徴とするデータ管理装置。
【請求項２】
前記格納部は、
前記更新要求に含まれる新たな属性情報と、前記記憶部に記憶されている前記最新属性情報とが異なる場合に、前記最新属性情報に対応する有効期限を更新するとともに、前記新たな属性情報を前記記憶部に格納する
ことを特徴とする請求項１に記載のデータ管理装置。
【請求項３】
前記記憶部は、
前記事物に関する属性情報の種別毎に、当該属性情報と当該属性情報の有効期限とを対応付けて記憶する履歴記憶部を有し、
前記格納部は、
前記更新要求を受け付けた場合に、当該更新要求に含まれる新たな属性情報の種別に対応する履歴記憶部に記憶されている最新属性情報の有効期限を更新するとともに、前記新たな属性情報を当該履歴記憶部に格納し、
前記検索部は、
前記検索要求を受け付けた場合に、当該検索要求に含まれる属性情報の種別に対応する履歴記憶部から当該属性情報を検索する
ことを特徴とする請求項１又は２に記載のデータ管理装置。
【請求項４】
前記記憶部は、
前記有効期限として、前記属性情報が前記事物の属性に該当することとなった最初の日付と、前記属性情報が前記事物の属性に該当する最終の日付とを記憶し、
前記格納部は、
前記新たな属性情報と当該新たな属性情報が前記事物の属性に該当する最初の日付である有効日付とを含む更新要求を受け付けた場合に、前記記憶部に記憶されている最新属性情報に対応する有効期限における最終の日付を前記有効日付の前日の日付に更新し、前記新たな属性情報を前記記憶部に格納するとともに、当該新たな属性情報の有効期限における最初の日付に前記有効日付を格納する
ことを特徴とする請求項１〜３のいずれか一つに記載のデータ管理装置。
【請求項５】
前記属性情報の種別と当該種別に対応する属性情報とを記憶する履歴記憶部を識別するための識別情報とを対応付けて記憶する属性管理記憶部をさらに備え、
前記格納部は、
前記更新要求を受け付けた場合に、当該更新要求に含まれる新たな属性情報の種別に対応する履歴記憶部の識別情報を前記属性管理記憶部から取得し、取得した識別情報によって特定される履歴記憶部に記憶されている最新属性情報の有効期限を更新するとともに、前記新たな属性情報を当該履歴記憶部に格納し、
前記検索部は、
前記検索要求を受け付けた場合に、当該検索要求に含まれる属性情報の種別に対応する履歴記憶部の識別情報を前記属性管理記憶部から取得し、取得した識別情報によって特定される履歴記憶部から当該属性情報を検索する
ことを特徴とする請求項１〜４のいずれか一つに記載のデータ管理装置。
【請求項６】
データ管理装置が実行するデータ管理方法であって、
所定の事物に関する属性情報と当該属性情報が当該事物の属性に該当する期限を示す有効期限とを対応付けて記憶する記憶部に記憶されている属性情報を更新する旨の更新要求を受け付ける受付工程と、
前記受付工程において前記更新要求が受け付けられた場合に、前記記憶部に記憶されている有効期限のうち現時点が有効期限内であることを示す有効期限を、当該有効期限に対応する最新属性情報が前記事物の属性に該当しなくなった日付に更新し、前記更新要求に含まれる新たな属性情報と当該新たな属性情報が現時点で前記事物の属性に該当することを示す有効期限とを前記記憶部に格納する格納工程と、
前記属性情報の検索要求を受け付けた場合に、当該検索要求に含まれる属性情報を前記記憶部から検索する検索工程と
を含んだことを特徴とするデータ管理方法。
【請求項７】
所定の事物に関する属性情報と当該属性情報が当該事物の属性に該当する期限を示す有効期限とを対応付けて記憶する記憶部に記憶されている属性情報を更新する旨の更新要求を受け付ける受付手順と、
前記受付手順において前記更新要求が受け付けられた場合に、前記記憶部に記憶されている有効期限のうち現時点が有効期限内であることを示す有効期限を、当該有効期限に対応する最新属性情報が前記事物の属性に該当しなくなった日付に更新し、前記更新要求に含まれる新たな属性情報と当該新たな属性情報が現時点で前記事物の属性に該当することを示す有効期限とを前記記憶部に格納する格納手順と、
前記属性情報の検索要求を受け付けた場合に、当該検索要求に含まれる属性情報を前記記憶部から検索する検索手順と
をコンピュータに実行させることを特徴とするデータ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データ管理装置、データ管理方法及びデータ管理プログラムに関する。
【背景技術】
【０００２】
従来、情報システムでは、膨大なデータがデータ記憶装置などにより管理されることが多い。例えば、企業内の情報システムでは、膨大なデータが共有資産として管理されている。このようなデータ記憶装置には最新データが保持され、データの変更履歴についてはログ（例えば、トランザクションログなど）として保持されることが多い。このため、利用者は、データの変更ログを参照することで、過去データの取得が可能となる。
【０００３】
ここで、上述した膨大なデータ及び変更ログに関する技術の一例について説明する。上記の通り、企業内には膨大なデータが存在するが、かかる膨大なデータは、異なる情報システムにおいて蓄積されたり、組織毎に異なるフォーマットで蓄積されたりする。近年では、このような膨大なデータの有効活用を図る技術が知られている。例えば、企業内の情報システムを連結することでデータ連携を図るＥＡＩ（Enterprise  Application  Integration）や、企業内の知識共有を図るナレッジマネジメントや、多くのデータベースにおいて共通して保持される基本的な情報（例えば、製品、顧客、会計、社員に関する情報など）であるマスターデータを統合活用するためのＭＤＭ（Master  Data  Management）など技術が知られている。また、ＤＷＨ（Data  WareHouse）においては、現在のデータだけでなく過去のデータを用いた時間変化を含む分析が可能となりつつある。
【０００４】
上記例において、ＭＤＭでは、基本的に最新データのみをマスターデータとして保持し、過去データの管理を省くことによりデータのスリム化とデータアクセス処理の軽減を図っている。また、ＭＤＭでは、マスターデータの変更ログが保持されることが多いので、過去データの参照を可能である。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ＭＤＭ  Ｏｎｅ  ＭＩ、”ＡＳＴＥＲＩＡ  ＭＤＭ  Ｏｎｅ  ＭＩ  機能一覧”、［online］、［平成２４年２月１日検索］、インターネット＜http://www.infoteria.com/jp/asteriamdmone/product/mi_function.php＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来のデータ管理手法では、データの変遷を容易に提供することが困難であった。例えば、上記のマスターデータに社員ＩＤ及び所属組織に関するデータが保持されており、利用者が、特定の社員における所属組織の変遷を閲覧するものとする。このとき、上記の従来手法によりデータ管理が行われている場合、利用者は、データの変遷が記憶されているトランザクションログ自体を解析することにより、所属組織の変遷を閲覧することができるとも考えられる。しかし、かかる手法では、膨大なトランザクションログを解析することになるので、利用者にかかる手間が増大する。また、利用者は、トランザクションログを用いてロールバックすることにより過去データを閲覧することができるとも考えられる。しかし、かかる手法は、過去の複数時点におけるマスターデータの状態に何度もロールバックすることを要するので、データの変遷を閲覧する作業としては現実的でない。このようなことから、上記従来のデータ管理手法では、特定のデータの変遷を利用者に提供することも困難であった。
【０００７】
本願の開示する技術は、上記に鑑みてなされたものであって、データの変遷を容易に提供することができるデータ管理装置、データ管理方法及びデータ管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
実施形態に係るデータ管理装置は、所定の事物に関する属性情報と、当該属性情報が当該事物の属性に該当する期限を示す有効期限とを対応付けて記憶する記憶部と、前記属性情報を更新する旨の更新要求を受け付けた場合に、前記記憶部に記憶されている有効期限のうち現時点が有効期限内であることを示す有効期限を、当該有効期限に対応する最新属性情報が前記事物の属性に該当しなくなった日付に更新し、前記更新要求に含まれる新たな属性情報と当該新たな属性情報が現時点で前記事物の属性に該当することを示す有効期限とを前記記憶部に格納する格納部と、前記属性情報の検索要求を受け付けた場合に、当該検索要求に含まれる属性情報を前記記憶部から検索する検索部とを備えることを特徴とする。
【発明の効果】
【０００９】
実施形態に係るデータ管理装置、データ管理方法及びデータ管理プログラムは、データの変遷を容易に提供することができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例１に係るデータ管理装置の構成例を示す図である。
【図２】図２は、実施例１に係るマスターデータテーブルの一例を示す図である。
【図３】図３は、実施例１に係るデータ管理装置による格納処理手順を示すフローチャートである。
【図４】図４は、実施例１に係るデータ管理装置による検索処理手順を示すフローチャートである。
【図５】図５は、参考例に係るデータ管理装置が有するデータ例を示す図である。
【図６】図６は、参考例に係るデータ管理装置による検索処理手順を示すフローチャートである。
【図７】図７は、実施例２に係るデータ管理装置の構成例を示す図である。
【図８】図８は、実施例２に係る社員ＩＤテーブルの一例を示す図である。
【図９】図９は、実施例２に係る組織履歴テーブルの一例を示す図である。
【図１０】図１０は、実施例２に係る内線履歴テーブルの一例を示す図である。
【図１１】図１１は、実施例２に係るデータ管理装置による格納処理手順を示すフローチャートである。
【図１２】図１２は、実施例２に係るデータ管理装置による検索処理手順を示すフローチャートである。
【図１３】図１３は、実施例２に係る属性管理テーブルの一例を示す図である。
【図１４】図１４は、データ管理プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００１１】
以下に、本願に係るデータ管理装置、データ管理方法及びデータ管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本願に係るデータ管理装置、データ管理方法及びデータ管理プログラムが限定されるものではない。
【実施例１】
【００１２】
［実施例１に係るデータ管理装置の構成］
まず、図１を用いて、実施例１に係るデータ管理装置について説明する。図１は、実施例１に係るデータ管理装置１００の構成例を示す図である。実施例１では、図１に示したデータ管理装置１００が、基本的な情報（例えば、製品、顧客、会計、社員に関する情報等）であるマスターデータを記憶するものとして説明する。
【００１３】
図１に例示するように、実施例１に係るデータ管理装置１００は、ＩＦ（interface）部１１０と、記憶部１２０と、受付部１３１と、格納部１３２と、検索部１３３とを有する。
【００１４】
ＩＦ部１１０は、データ管理装置１００以外の他の装置との間でデータを送受信する。例えば、ＩＦ部１１０は、通信制御を行う電子回路や、ＮＩＣ（Network  Interface  Card）等によって実現される。
【００１５】
記憶部１２０は、各種データを記憶する記憶デバイスであり、例えば、ハードディスク、光ディスク、又は、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ（Flash  Memory）等の半導体メモリ素子によって実現される。
【００１６】
実施例１に係る記憶部１２０は、図１に例示するように、マスターデータテーブル１２１を有する。マスターデータテーブル１２１は、所定の事物に関する属性情報と、かかる属性情報が事物の属性に該当する期間を示す有効期限とを対応付けて記憶する。
【００１７】
ここで、図２に、実施例１に係るマスターデータテーブル１２１の一例を示す。図２に例示したマスターデータテーブル１２１は、特定の事物である社員に関する各属性情報を記憶する。具体的には、マスターデータテーブル１２１は、図２に示すように、「ＩＤ」、「社員ＩＤ」、「組織名」、「内線」、「部屋番号」、「ｓｔａｒｔＤａｔｅ」、「ｅｎｄＤａｔｅ」といった項目を有する。なお、「社員ＩＤ」、「組織名」、「内線」及び「部屋番号」は、社員の属性情報に該当する。
【００１８】
「ＩＤ」は、マスターデータテーブル１２１に記憶されるレコードを識別するための識別情報を示す。すなわち、「ＩＤ」は、マスターデータテーブル１２１における主キー（Primary  Key）に該当する。
【００１９】
「社員ＩＤ」は、社員を識別するための識別情報を示す。かかる「社員ＩＤ」は、企業内において各社員に割り当てられる。「組織名」は、社員が所属している組織や部署等の名称を示す。「内線」は、社員に割り当てられている内線電話の番号を示す。「部屋番号」は、社員が職務を遂行する建物や部屋等を識別するための識別情報を示し、例えば、社員の作業机が置かれている部屋を示す。
【００２０】
「ｓｔａｒｔＤａｔｅ」は、かかるｓｔａｒｔＤａｔｅを含むレコード内の各属性情報が社員の属性に該当することとなった最初の日付、又は、かかるｓｔａｒｔＤａｔｅを含むレコードがマスターデータテーブル１２１に格納された日付を示す。「ｅｎｄＤａｔｅ」は、かかるｅｎｄＤａｔｅを含むレコード内の各属性情報が社員の属性に該当する最終の日付、又は、かかるｅｎｄＤａｔｅを含むレコードの次に新たなレコードがマスターデータテーブル１２１に格納された日付の前日を示す。なお、図２に示した例のように、レコード内の各属性情報が現在も社員の属性に該当する場合には、「ｅｎｄＤａｔｅ」に情報が記憶されないか、又は、現在も属性に該当することを示す所定の値（例えば、データ管理装置１００が運用されないことが想定される日付「３０００−１−１」等）が記憶される。以下の実施例では、各属性情報が現在も社員の属性に該当する場合には、「ｅｎｄＤａｔｅ」に情報が記憶されない例を用いて説明する。
【００２１】
すなわち、マスターデータテーブル１２１に記憶されている各属性情報（社員ＩＤ、組織名、内線、部屋番号）は、「ｓｔａｒｔＤａｔｅ」によって示される日付から「ｅｎｄＤａｔｅ」によって示される日付の間において、社員の属性に該当することを示す。言い換えれば、「ｓｔａｒｔＤａｔｅ」及び「ｅｎｄＤａｔｅ」は、レコード内の各属性情報が社員の属性情報として有効である期限を示す。
【００２２】
例えば、図２に示したＩＤ「０００００１」によって識別されるレコードは、社員ＩＤ「１１２２」の社員が、２００９年１０月１日（「ｓｔａｒｔＤａｔｅ」）から２０１０年３月３１日（「ｅｎｄＤａｔｅ」）において、組織名「Ｇ１１」の組織（部署）に属し、内線番号「１１１１」が割り当てられ、部屋番号「１−１００１」によって示される部屋において職務を遂行していたことを示す。
【００２３】
また、例えば、図２に示したＩＤ「０００００３」によって識別されるレコードは、社員ＩＤ「１１２２」の社員が、２０１１年１２月１日（「ｓｔａｒｔＤａｔｅ」）から現在において、組織名「Ｇ１３」の組織（部署）に属し、内線番号「３３３３」が割り当てられ、部屋番号「１−１００１」によって示される部屋において職務を遂行していることを示す。
【００２４】
このように、実施例１に係るマスターデータテーブル１２１は、各社員の属性情報を記憶するとともに、有効期限（「ｓｔａｒｔＤａｔｅ」及び「ｅｎｄＤａｔｅ」）によって各属性情報を履歴管理する。
【００２５】
なお、実施例１に係るマスターデータテーブル１２１は、特定の事物の属性を示す属性情報を記憶する場合には、少なくとも特定の事物を識別するための識別情報（以下、「特定情報」と表記する場合がある）を記憶する。例えば、図２に示したマスターデータテーブル１２１は、特定の事物「社員」の属性として、「社員ＩＤ」、「組織名」、「内線」及び「部屋番号」を記憶する。この例の場合、マスターデータテーブル１２１は、特定の事物である社員を識別するための特定情報「社員ＩＤ」を記憶する。
【００２６】
また、図２の例では、マスターデータテーブル１２１が「ＩＤ」を記憶する例を示し、以下の実施例では、マスターデータテーブル１２１が「ＩＤ」を記憶する例を用いて説明する。ただし、主キーが不要な場合には、マスターデータテーブル１２１は、「ＩＤ」を記憶しなくてもよい。
【００２７】
図１の説明に戻って、受付部１３１は、ＩＦ部１１０を介して、マスターデータテーブル１２１を更新する旨の更新要求を受け付ける。例えば、受付部１３１は、マスターデータテーブル１２１の更新を要求する他の装置から、更新要求とともに更新データを受け付ける。
【００２８】
ここで、実施例１に係る受付部１３１によって受け付けられる更新データについて説明する。実施例１における更新データには、マスターデータテーブル１２１に記憶されている全ての属性情報が含まれるものとする。例えば、マスターデータテーブル１２１が図２に示した例の場合、組織名のみを更新するための更新データであっても、社員ＩＤ、組織名、内線、部屋番号が含まれる。また、実施例１における更新データには、このような社員ＩＤ、組織名、内線及び部屋番号の組合せであるレコードが複数含まれる場合もある。
【００２９】
また、実施例１における更新データには、更新対象の属性情報を有効にする日付（以下、「有効日付」と表記する場合がある）が含まれる場合もある。かかる「有効日付」は、更新対象の属性情報が上記特定の事物の属性に該当することとなる最初の日付を示す。言い換えれば、「有効日付」は、組織、内線、部屋番号の変更が社員に発令される日付を示す。例えば、図２に示した例において、社員ＩＤ「２２３３」の社員が組織名「Ｇ１３」の組織に「２０１２年１月１日」付けで所属することになったものとする。このとき、社員ＩＤ「２２３３」の組織名を「Ｇ１３」に更新するための更新データには、社員ＩＤ「２２３３」及び組織名「Ｇ１３」に加えた、社員が新たな組織に属する最初の日付である「２０１２年１月１日（データとしては、２０１２−１−１や２０１２０１０１等）」が含まれる場合がある。更新データの送信元は、更新データに有効日付を含めることで、属性情報が変更となる日に更新データをデータ管理装置１００に送信しなくても、マスターデータテーブル１２１に属性情報が変更日を登録することができる。
【００３０】
なお、上記例では、データ管理装置１００が他の装置から更新データを受信する例を示したが、データ管理装置１００は、利用者によって直接操作されることによって更新データを受け付けてもよい。例えば、データ管理装置１００は、図示しない入力部（キーボード、マウス等）及び表示部（液晶表示装置等）を有し、かかる入力部を介して利用者により更新データが入力されてもよい。かかる場合には、受付部１３１は、入力部を介して入力された更新データを受け付ける。
【００３１】
格納部１３２は、受付部１３１によって受け付けられた更新データをマスターデータテーブル１２１に格納する。具体的には、格納部１３２は、更新要求を受け付けた場合に、マスターデータテーブル１２１に記憶されている属性情報のうち最も新しい社員の属性情報に対応する有効期限（ｓｔａｒｔＤａｔｅ、ｅｎｄＤａｔｅ）をかかる最も新しい属性情報が社員の属性に該当しなくなったことを示す有効期限に更新する。さらに、格納部１３２は、更新要求に含まれる新たな属性情報と、かかる新たな属性情報が現時点で社員の属性に該当することを示す有効期限とをマスターデータテーブル１２１に格納する。
【００３２】
より具体的に説明すると、格納部１３２は、受付部１３１によって更新データが受け付けられた場合に、更新データに含まれる特定情報と同一の情報がマスターデータテーブル１２１に記憶されているか否かを判定する。言い換えれば、格納部１３２は、更新対象となるレコードがマスターデータテーブル１２１に存在するか否かを判定する。例えば、図２に示したマスターデータテーブル１２１の例では、社員に関する属性情報を記憶するので、更新データには少なくとも社員ＩＤが含まれる。この例の場合、格納部１３２は、更新データに含まれる特定情報「社員ＩＤ」がマスターデータテーブル１２１に記憶されている場合には、更新対象となるレコードが存在すると判定する。一方、格納部１３２は、更新データに含まれる特定情報「社員ＩＤ」がマスターデータテーブル１２１に記憶されていない場合には、更新対象となるレコードが存在しないと判定する。
【００３３】
そして、格納部１３２は、更新対象となるレコードが存在しない場合には、更新データに含まれる各属性情報を新たなレコードとしてマスターデータテーブル１２１に格納する。このとき、格納部１３２は、更新データに有効日付が含まれる場合には、「ｓｔａｒｔＤａｔｅ」に有効日付を格納し、更新データに有効日付が含まれない場合には、「ｓｔａｒｔＤａｔｅ」に現在日付を格納する。また、格納部１３２は、「ｅｎｄＤａｔｅ」には情報を格納しない。
【００３４】
一方、格納部１３２は、更新対象となるレコードが存在する場合には、更新対象となるレコードのうち、「ｅｎｄＤａｔｅ」に情報が記憶されていないレコードを最新レコードとして特定する。そして、格納部１３２は、かかる最新レコードに記憶されている各属性情報が、更新データに含まれる各属性情報と全て同一であるか否かを判定する。このとき、格納部１３２は、更新データと最新レコードが同一である場合には、かかる更新データを用いた格納処理を行わない。
【００３５】
一方、格納部１３２は、更新データと最新レコードが同一でない場合には、更新データに含まれる有効日付から「１日（２４時間）」を減算した日付を最新レコードの「ｅｎｄＤａｔｅ」に格納する。このとき、格納部１３２は、更新データに有効日付が含まれない場合には、現在日付から「１日（２４時間）」を減算した日付を最新レコードの「ｅｎｄＤａｔｅ」に格納する。また、格納部１３２は、受付部１３１によって受け付けられた更新データを新たなレコードとしてマスターデータテーブル１２１に格納する。このとき、格納部１３２は、上記例と同様に、「ｓｔａｒｔＤａｔｅ」に有効日付又は現在日付を格納し、「ｅｎｄＤａｔｅ」に情報を格納しない。
【００３６】
かかる格納部１３２による格納処理について図２に示した例を用いて説明する。ここでは、マスターデータテーブル１２１に、ＩＤ「０００００１」であるレコードのみが記憶されているものとする。この状態において、受付部１３１によって、社員ＩＤ「１１２２」、組織名「Ｇ１２」、内線「１１１１」、部屋番号「１−１００１」及び有効日付「２０１０−４−１」を含む更新データが受け付けられたものとする。かかる場合に、格納部１３２は、更新データに含まれる社員ＩＤ「１１２２」がマスターデータテーブル１２１に記憶されているか否かを判定する。ここの例では、マスターデータテーブル１２１には社員ＩＤ「１１２２」が記憶されているので、格納部１３２は、更新対象となるレコードが存在すると判定する。かかる場合に、格納部１３２は、社員ＩＤ「１１２２」と一致するレコード（社員ＩＤが「１１２２」であるレコード）のうち、「ｅｎｄＤａｔｅ」がＮＵＬＬであるレコードを最新レコードとして特定する。ここの例では、格納部１３２は、ＩＤが「０００００１」であるレコードを最新レコードとして特定する。
【００３７】
そして、格納部１３２は、ＩＤが「０００００１」であるレコードの「ｅｎｄＤａｔｅ」に、更新データに含まれる有効日付「２０１０−４−１」から１日を減算した日付「２０１０−３−３１」を格納する。さらに、格納部１３２は、更新データに含まれる社員ＩＤ「１１２２」、組織名「Ｇ１２」、内線「１１１１」及び部屋番号「１−１００１」を新たなレコードとしてマスターデータテーブル１２１に格納する。このとき、格納部１３２は、新たなレコードの「ｓｔａｒｔＤａｔｅ」に有効日付「２０１０−４−１」を格納し、「ｅｎｄＤａｔｅ」に情報を格納しない。このようにして、格納部１３２は、図２のＩＤ「０００００２」に示した例のようなレコードをマスターデータテーブル１２１に新たに格納する。
【００３８】
なお、格納部１３２は、新たなレコードのＩＤについては、マスターデータテーブル１２１に記憶されていない番号を付与する。例えば、格納部１３２は、マスターデータテーブル１２１に記憶されているＩＤの最大値に「１」をインクリメントした値を新たなレコードのＩＤとする。
【００３９】
また、上記例の後に、受付部１３１によって、社員ＩＤ「１１２２」、組織名「Ｇ１３」、内線「３３３３」、部屋番号「１−１００１」及び有効日付「２０１１−１２−１」を含む更新データが受け付けられたものとする。かかる場合に、格納部１３２は、図２に示した例のように、ＩＤが「０００００２」であるレコードの「ｅｎｄＤａｔｅ」に「２０１１−１１−３０」を格納し、ＩＤが「０００００３」であるレコードを格納する。
【００４０】
また、受付部１３１によって、社員ＩＤ「２２３３」、組織名「Ｇ１２」、内線「２２２２」、部屋番号「１−１００１」及び有効日付「２０１１−４−１」を含む更新データが受け付けられたものとする。かかる場合に、格納部１３２は、マスターデータテーブル１２１に社員ＩＤ「２２３３」が記憶されていないので、図２に示した例のように、ＩＤが「０００００４」であるレコードをマスターデータテーブル１２１に新たに格納する。
【００４１】
検索部１３３は、ＩＦ部１１０を介して検索要求を受け付けた場合に、かかる検索要求に従って、マスターデータテーブル１２１から各種データを検索する。例えば、検索部１３３は、特定情報、及び、検索対象の属性情報の名称（カラム名）を含む検索要求を受け付ける。かかる場合に、検索部１３３は、検索要求に含まれる特定情報をキーとして、「検索対象の属性情報」及び「ｓｔａｒｔＤａｔｅ」をマスターデータテーブル１２１から検索する。そして、検索部１３３は、検索結果の属性情報をｓｔａｒｔＤａｔｅの降順にソートする。さらに、検索部１３３は、ソート後の属性情報に同一の属性情報が連続して存在する場合には、連続する属性情報のうち、最後の属性情報を除く他の属性情報を削除する。そして、検索部１３３は、ソートかつ重複情報削除後の属性情報及びｓｔａｒｔＤａｔｅが記載された検索結果一覧を生成し、生成した検索結果一覧を検索要求の送信元に通知する。
【００４２】
かかる検索部１３３による検索処理について図２に示した例を用いて説明する。例えば、検索部１３３が、社員ＩＤ「１１２２」、及び、検索対象の属性情報の名称「内線」を含む検索要求を受け付けたものとする。かかる場合に、検索部１３３は、社員ＩＤ「１１２２」をキーにマスターデータテーブル１２１を検索することで、「内線」及び「ｓｔａｒｔＤａｔｅ」を取得する。ここの例では、検索部１３３は、内線「１１１１」及びｓｔａｒｔＤａｔｅ「２００９−１０−１」の組合せと、内線「１１１１」及びｓｔａｒｔＤａｔｅ「２０１０−４−１」の組合せと、内線「３３３３」及びｓｔａｒｔＤａｔｅ「２０１１−１２−１」の組合せとを取得する。そして、検索部１３３は、ｓｔａｒｔＤａｔｅの降順にソートすることで、内線を「３３３３」、「１１１１」、「１１１１」に並び替える。さらに、検索部１３３は、内線「１１１１」が連続して存在するので、かかる２個の内線のうち先頭の「１１１１」を削除する。そして、検索部１３３は、内線「３３３３」及びｓｔａｒｔＤａｔｅ「２０１１−１２−１」、内線「１１１１」及びｓｔａｒｔＤａｔｅ「２００９−１０−１」の順に記載された検索結果一覧を検索要求の送信元に通知する。これにより、かかる検索結果一覧を参照するユーザは、社員ＩＤが「１１２２」である社員に割り当てられた内線番号の変遷を確認することができる。
【００４３】
なお、上記では、検索部１３３が、検索結果をｓｔａｒｔＤａｔｅの降順に並び替える例を示した。しかし、検索部１３３は、検索結果をｓｔａｒｔＤａｔｅの昇順に並び替えてもよい。また、検索部１３３は、ｓｔａｒｔＤａｔｅではなくｅｎｄＤａｔｅを検索してもよい。かかる場合には、検索部１３３は、ｅｎｄＤａｔｅがＮＵＬＬである属性情報が最新であるものとしてソートを行う。また、検索部１３３は、ｓｔａｒｔＤａｔｅ及びｅｎｄＤａｔｅの双方を検索してもよい。
【００４４】
また、上記例では、データ管理装置１００が他の装置から検索要求を受信することとするが、データ管理装置１００は、利用者によって直接操作されることによって検索要求を受け付けてもよい。例えば、データ管理装置１００は、図示しない入力部及び表示部を有し、かかる入力部を介して利用者により検索要求が入力されてもよい。かかる場合には、検索部１３３は、入力部を介して入力された検索要求に従って、上記の検索処理を行う。
【００４５】
また、図１に示した受付部１３１、格納部１３２及び検索部１３３は、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路により実現される。また、例えば、受付部１３１、格納部１３２及び検索部１３３は、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）等によって、図示しない記憶装置に記憶されているプログラムがＲＡＭ（Random  Access  Memory）を作業領域として実行されることにより実現される。
【００４６】
［実施例１に係るデータ管理装置による格納処理手順］
次に、図３を用いて、実施例１に係るデータ管理装置１００による格納処理の手順について説明する。図３は、実施例１に係るデータ管理装置１００による格納処理手順を示すフローチャートである。なお、以下では、マスターデータテーブル１２１が、図２に例示した各種情報を記憶する場合を例に挙げて説明する。すなわち、データ管理装置１００は、特定情報として社員ＩＤが含まれる更新データを受け付けるものとする。
【００４７】
図３に示すように、データ管理装置１００の格納部１３２は、受付部１３１によって更新データが受け付けられた場合に、かかる更新データに含まれる行数（レコード数）だけ、ループ１に示した処理を繰り返し行う。
【００４８】
具体的には、格納部１３２は、１行目の更新データに含まれる特定情報「社員ＩＤ」と同一の情報がマスターデータテーブル１２１に存在するか否かを判定する（ステップＳ１０１）。
【００４９】
そして、格納部１３２は、更新データの社員ＩＤがマスターデータテーブル１２１に存在しない場合には（ステップＳ１０１否定）、更新データに含まれる社員ＩＤ、各属性情報（組織名、内線、部屋番号など）と、ｓｔａｒｔＤａｔｅ及びｅｎｄＤａｔｅをマスターデータテーブル１２１に新たなレコードとして格納する（ステップＳ１０２）。このとき、格納部１３２は、更新データに有効日付が含まれる場合には、ｓｔａｒｔＤａｔｅに有効日付を格納し、更新データに有効日付が含まれない場合には、ｓｔａｒｔＤａｔｅに現在日付（すなわち、更新日）を格納する。また、格納部１３２は、ｅｎｄＤａｔｅには情報を格納しない。
【００５０】
一方、格納部１３２は、更新データの社員ＩＤがマスターデータテーブル１２１に存在する場合には（ステップＳ１０１肯定）、かかる社員ＩＤと一致するレコードのうち最新レコードに記憶されている各属性情報が、更新データに含まれる各属性情報と全て同一であるか否かを判定する（ステップＳ１０３）。そして、格納部１３２は、更新データの属性情報と同一の属性情報が最新レコードに記憶されている場合には（ステップＳ１０３肯定）、かかる更新データを用いた格納処理を行わない。
【００５１】
一方、格納部１３２は、更新データと最新レコードとが同一でない場合には（ステップＳ１０３否定）、更新データに含まれる有効日付から「１日」を減算した日付、又は、現在日付（更新日）から「１日」を減算した日付を最新レコードの「ｅｎｄＤａｔｅ」に格納する（ステップＳ１０４）。また、格納部１３２は、更新データに含まれる社員ＩＤ、各属性情報（組織名、内線、部屋番号など）と、ｓｔａｒｔＤａｔｅ及びｅｎｄＤａｔｅを新たなレコードとしてマスターデータテーブル１２１に格納する（ステップＳ１０５）。このとき、格納部１３２は、更新データに有効日付が含まれる場合には、ｓｔａｒｔＤａｔｅに有効日付を格納し、更新データに有効日付が含まれない場合には、ｓｔａｒｔＤａｔｅに現在日付（更新日）を格納する。また、格納部１３２は、ｅｎｄＤａｔｅには情報を格納しない。
【００５２】
［実施例１に係るデータ管理装置による検索処理手順］
次に、図４を用いて、実施例１に係るデータ管理装置１００による検索処理の手順について説明する。図４は、実施例１に係るデータ管理装置１００による検索処理手順を示すフローチャートである。なお、以下では、マスターデータテーブル１２１が、図２に例示した各種情報を記憶する場合を例に挙げて説明する。
【００５３】
図４に示すように、データ管理装置１００の検索部１３３は、検索要求を受け付けた場合に、検索要求に含まれる社員ＩＤをキーに、マスターデータテーブル１２１から検索対象の属性情報を検索する（ステップＳ２０１）。このとき、検索部１３３は、ｓｔａｒｔＤａｔｅについても検索する。
【００５４】
そして、検索部１３３は、検索結果の属性情報をｓｔａｒｔＤａｔｅに基づいて、ソートする（ステップＳ２０２）。例えば、検索部１３３は、検索結果の属性情報を新しい順にソートする。そして、検索部１３３は、ソート後の属性情報において連続する属性情報のうち、最後の属性情報を除く他の属性情報を削除する（ステップＳ２０３）。この後に、検索部１３３は、検索結果一覧を検索要求の送信元に通知する。
【００５５】
［実施例１の効果］
上述してきたように、実施例１に係るデータ管理装置１００において、記憶部１２０は、所定の事物に関する属性情報と、かかる属性情報が事物の属性に該当する期限を示す有効期限（ｅｎｄＤａｔｅに対応）とを対応付けて記憶するマスターデータテーブル１２１を有する。また、格納部１３２は、属性情報を更新する旨の更新要求を受け付けた場合に、マスターデータテーブル１２１に記憶されている有効期限のうち現時点が有効期限内であることを示す有効期限を、かかる有効期限に対応する最新属性情報が事物の属性に該当しなくなったことを示す有効期限に更新する。さらに、格納部１３２は、更新要求に含まれる新たな属性情報と、かかる新たな属性情報が現時点で事物の属性に該当することを示す有効期限とをマスターデータテーブル１２１に格納する。また、検索部１３３は、属性情報の検索要求を受け付けた場合に、かかる検索要求に含まれる属性情報をマスターデータテーブル１２１から検索する。
【００５６】
このように、実施例１に係るデータ管理装置１００は、各属性情報とともに、かかる属性情報の変更履歴を有効期限としてマスターデータテーブル１２１内で管理する。言い換えれば、データ管理装置１００は、各属性情報の変更履歴をログとして管理するのではなく、同一のマスターデータテーブル１２１内で管理する。これにより、実施例１に係るデータ管理装置１００は、マスターデータテーブル１２１に記憶されているデータの変遷を容易に検索することができるので、データの変遷を容易に提供することができる。
【００５７】
また、実施例１に係るデータ管理装置１００において、格納部１３２は、更新要求に含まれる新たな属性情報と、マスターデータテーブル１２１に記憶されている最新属性情報とが異なる場合に、かかる最新属性情報に対応する有効期限を更新するとともに、新たな属性情報をマスターデータテーブル１２１に格納する。
【００５８】
これにより、実施例１に係るデータ管理装置１００は、同一の属性情報を連続してマスターデータテーブル１２１に格納することを防止できる。この結果、データ管理装置１００は、同一の更新データを重複して受け付けた場合であっても、データの変遷があった際にマスターデータテーブル１２１を更新することができるので、データの正確な変遷を提供することができる。
【００５９】
［参考例に係るデータ管理装置］
ここで、上記実施例１に係るデータ管理装置１００における効果を明確にするために、図５及び図６を用いて、参考例に係るデータ管理装置９００によるデータ管理について説明する。なお、参考例に係るデータ管理装置９００は、一般的に考え得るデータ管理装置の一例に該当する。図５は、参考例に係るデータ管理装置９００が有するデータ例を示す図である。図５に示した例では、データ管理装置９００は、マスターデータテーブル９１と、ログデータテーブル９２とを有する。
【００６０】
マスターデータテーブル９１は、最新データのみを保持する。すなわち、図５に示したマスターデータテーブル９１は、社員ＩＤ「１１２２」である社員の現在の属性情報として、組織名「Ｇ１３」、内線「３３３３」及び部屋番号「１−１００１」を記憶し、社員ＩＤ「２２３３」である社員の現在の属性情報として、組織名「Ｇ１２」、内線「２２２２」及び部屋番号「１−１００１」を記憶する。このように、一般的には、データ管理装置９００は、マスターデータテーブル９１に示した例のように、最新のマスターデータのみを保持する。ログデータテーブル９２は、マスターデータテーブル９１の更新ログを記憶する。図５に示した例では、ログデータテーブル９２は、マスターデータテーブル９１の更新時に用いられた更新コマンド（ＳＱＬ文など）を変更内容に記憶する。
【００６１】
データ管理装置９００が上記のマスターデータテーブル９１及びログデータテーブル９２を保持する場合、利用者は、ログデータテーブル９２を解析することにより、例えば特定の社員における所属組織の変遷を確認することが可能になるとも考えられる。しかし、ログデータテーブル９２には膨大なログが記憶されているので、ログデータテーブル９２を解析する手法では、利用者にかかる手間が増大する。また、利用者は、マスターデータテーブル９１を用いてマスターデータテーブル９１をロールバックすることにより、過去データを閲覧して特定の社員における所属組織の変遷を確認することが可能になるとも考えられる。しかし、かかる手法は、過去の複数時点におけるマスターデータの状態に何度もロールバックすることを要するので現実的ではない。
【００６２】
また、データ管理装置９００がログデータテーブル９２を解析することにより、特定の社員における所属組織の変遷を出力することも考えられる。しかし、ログデータテーブル９２の解析処理が複雑となり、データ管理装置９００にかかる負荷が増大する。この点について、図６を用いて説明する。図６は、参考例に係るデータ管理装置９００による検索処理手順を示すフローチャートである。なお、図６は、データ管理装置９００による検索処理として考え得る処理を示したものである。また、ここでは、データ管理装置９００が社員ＩＤ「１１２２」における組織名の変遷を検索する場合を例に挙げて説明する。
【００６３】
図６に示した例では、データ管理装置９００は、社員ＩＤ「１１２２」の組織名を検索する旨の検索要求を受け付けた場合に、マスターデータテーブル９１から、社員ＩＤ「１１２２」の組織名「Ｇ１３」を検索し、最新組織名として保持する（ステップＳ１１）。続いて、データ管理装置９００は、社員ＩＤ「１１２２」をキーにログデータテーブル９２の変更内容を検索する（ステップＳ１２）。そして、データ管理装置９００は、検索結果を新しい順にソートする（ステップＳ１３）。
【００６４】
続いて、データ管理装置９００は、検索結果の数（変更内容の数）だけループ１に示した処理を繰り返し行う。具体的には、データ管理装置９００は、ソート後の検索結果である変更内容のうち最も新しい変更内容に組織名変更又は組織名追加が含まれるか否かを判定する（ステップＳ１４）。例えば、データ管理装置９００は、変更内容に「ｕｐｄａｔｅ」及び「組織名」の文字列が含まれるか否かを判定したり、変更内容に「ｉｎｓｅｒｔ」及び「組織名」の文字列が含まれるか否かを判定したりする。そして、データ管理装置９００は、変更内容に組織名変更又は組織名追加が含まれる場合には（ステップＳ１４肯定）、かかる変更内容に含まれる組織名が最新組織名と異なるか否かを判定する（ステップＳ１５）。そして、データ管理装置９００は、最新組織名と異なる場合には（ステップＳ１５肯定）、かかる最新組織名を保持したまま、変更内容に含まれる組織名を新たな最新組織名として保持する（ステップＳ１６）。データ管理装置９００は、ソート後の変更内容について、変更内容の新しい順に上記ステップＳ１４〜Ｓ１６における処理を繰り返し行う。
【００６５】
このようにして、データ管理装置９００は、社員ＩＤ「１１２２」における組織名の変遷を検索する。しかし、データ管理装置９００は、図６の処理を行う場合には、ステップＳ１４においてＳＱＬ文等を文字列解析することになるので処理負荷が増大する。また、図６に示した処理手順は、実施例１に係るデータ管理装置１００による検索処理（図４を参照）と比較すると、処理ステップ数が多く処理効率が悪い。
【００６６】
以上のように、実施例１に係るデータ管理装置１００は、マスターデータテーブル１２１に記憶されているデータの変遷を容易に検索することができ、その結果、データの変遷を容易に提供することができる。
【実施例２】
【００６７】
上記実施例１では、データ管理装置１００が図２に示したマスターデータテーブル１２１を保持する例について説明した。しかし、データ管理装置は、マスターデータテーブルを属性情報毎に分割して保持してもよい。実施例２では、マスターデータテーブルを属性情報毎に分割して保持する例について説明する。
【００６８】
［実施例２に係るデータ管理装置の構成］
まず、図７を用いて、実施例２に係るデータ管理装置について説明する。図７は、実施例２に係るデータ管理装置２００の構成例を示す図である。なお、以下では、既に示した構成部位と同様の機能を有する部位には同一符号を付すこととして、その詳細な説明を省略する。図７に例示するように、実施例２に係るデータ管理装置２００は、記憶部２２０と、格納部２３２と、検索部２３３とを有する。
【００６９】
記憶部２２０は、例えば、ハードディスク、光ディスク、又は、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子によって実現される。実施例２に係る記憶部２２０は、図２に例示したマスターデータテーブル１２１に記憶される属性情報の種別毎に、かかる属性情報の変更履歴を異なる履歴テーブルに記憶する。具体的には、記憶部２２０は、図７に例示するように、社員ＩＤテーブル２２１と、組織履歴テーブル２２２と、内線履歴テーブル２２３とを有する。
【００７０】
社員ＩＤテーブル２２１は、社員の社員ＩＤを記憶する。図８に、実施例２に係る社員ＩＤテーブル２２１の一例を示す。図８に示すように、社員ＩＤテーブル２２１は、「社員ＩＤ」、「ｓｔａｒｔＤａｔｅ」、「ｅｎｄＤａｔｅ」といった項目を有する。これらの項目は、図２に示した項目に対応する。
【００７１】
「社員ＩＤ」は、図２に示した社員ＩＤに対応する。かかる「社員ＩＤ」は、社員ＩＤテーブル２２１における主キーに該当する。「ｓｔａｒｔＤａｔｅ」は、かかるｓｔａｒｔＤａｔｅを含むレコード内の社員ＩＤが社員の属性に該当することとなった最初の日付、又は、かかるｓｔａｒｔＤａｔｅを含むレコードが社員ＩＤテーブル２２１に格納された日付を示す。「ｅｎｄＤａｔｅ」は、かかるｅｎｄＤａｔｅを含むレコード内の社員ＩＤが社員の属性に該当する最終の日付、又は、かかるｅｎｄＤａｔｅを含むレコードの次に新たなレコードが社員ＩＤテーブル２２１に格納された日付の前日を示す。なお、実施例２では、社員の社員ＩＤが変更されることはないものとする。すなわち、社員ＩＤテーブル２２１の「ｅｎｄＤａｔｅ」には情報が記憶されることはない。ただし、社員が退職した場合などには、かかる社員に対応する社員ＩＤテーブル２２１の「ｅｎｄＤａｔｅ」には「退職日」等が記憶される。
【００７２】
組織履歴テーブル２２２は、各社員における組織名の変更履歴を記憶する。図９に、実施例２に係る組織履歴テーブル２２２の一例を示す。図９に示すように、組織履歴テーブル２２２は、「社員ＩＤ」、「組織名」、「ｓｔａｒｔＤａｔｅ」、「ｅｎｄＤａｔｅ」といった項目を有する。
【００７３】
「社員ＩＤ」は、図８に示した社員ＩＤに対応する。かかる「社員ＩＤ」は、社員ＩＤテーブル２２１の社員ＩＤを参照先とする外部キー（Foreign  Key）に該当する。「組織名」は、図２に示した組織名に対応する。「ｓｔａｒｔＤａｔｅ」は、かかるｓｔａｒｔＤａｔｅを含むレコード内の組織名が社員の属性に該当することとなった最初の日付、又は、かかるｓｔａｒｔＤａｔｅを含むレコードが組織履歴テーブル２２２に格納された日付を示す。「ｅｎｄＤａｔｅ」は、かかるｅｎｄＤａｔｅを含むレコード内の組織名が社員の属性に該当する最終の日付、又は、かかるｅｎｄＤａｔｅを含むレコードの次に新たな組織履歴テーブル２２２に格納された日付の前日を示す。
【００７４】
内線履歴テーブル２２３は、各社員における内線の変更履歴を記憶する。図１０に、実施例２に係る内線履歴テーブル２２３の一例を示す。図１０に示すように、内線履歴テーブル２２３は、「社員ＩＤ」、「内線」、「ｓｔａｒｔＤａｔｅ」、「ｅｎｄＤａｔｅ」といった項目を有する。
【００７５】
「社員ＩＤ」は、図８に示した社員ＩＤに対応し、社員ＩＤテーブル２２１の社員ＩＤを参照先とする外部キーに該当する。「内線」は、図２に示した内線に対応する。「ｓｔａｒｔＤａｔｅ」は、かかるｓｔａｒｔＤａｔｅを含むレコード内の内線が社員の属性に該当することとなった最初の日付、又は、かかるｓｔａｒｔＤａｔｅを含むレコードが内線履歴テーブル２２３に格納された日付を示す。「ｅｎｄＤａｔｅ」は、かかるｅｎｄＤａｔｅを含むレコード内の内線が社員の属性に該当する最終の日付、又は、かかるｅｎｄＤａｔｅを含むレコードの次に新たな内線履歴テーブル２２３に格納された日付の前日を示す。
【００７６】
なお、図７では図示することを省略したが、実施例２に係る記憶部２２０は、上記の各テーブル以外にも、各社員の属性情報毎に、かかる属性情報の変更履歴を記憶する履歴テーブルを有する。例えば、記憶部２２０は、各社員における部屋番号の変更履歴を記憶する「部屋番号履歴テーブル」を有する。
【００７７】
図７の説明に戻って、格納部２３２は、受付部１３１によって受け付けられた更新データを記憶部２２０内の社員ＩＤテーブル２２１、組織履歴テーブル２２２、内線履歴テーブル２２３等に格納する。
【００７８】
具体的には、格納部２３２は、受付部１３１によって更新データが受け付けられた場合に、更新データに含まれる特定情報（ここの例では、社員ＩＤ）と同一の情報が社員ＩＤテーブル２２１に記憶されているか否かを判定する。そして、格納部２３２は、更新データの社員ＩＤが社員ＩＤテーブル２２１に記憶されていない場合には、更新データに含まれる社員ＩＤを社員ＩＤテーブル２２１に新たなレコードとして格納する。このとき、格納部２３２は、更新データに有効日付が含まれる場合には、「ｓｔａｒｔＤａｔｅ」に有効日付を格納し、更新データに有効日付が含まれない場合には、「ｓｔａｒｔＤａｔｅ」に現在日付を格納する。また、格納部２３２は、「ｅｎｄＤａｔｅ」には情報を格納しない。
【００７９】
また、格納部２３２は、更新データに含まれる属性情報の種別に対応する履歴テーブルを記憶部２２０から選択する。そして、格納部２３２は、選択した履歴テーブル（以下、「選択テーブル」とする）に、更新データに含まれる特定情報（ここの例では、社員ＩＤ）と同一の情報が記憶されているか否かを判定する。そして、格納部２３２は、更新データの社員ＩＤが選択テーブルに記憶されていない場合には、更新データに含まれる社員ＩＤ及び属性情報を新たなレコードとして選択テーブルに格納する。このとき、格納部２３２は、更新データに有効日付が含まれる場合には、「ｓｔａｒｔＤａｔｅ」に有効日付を格納し、更新データに有効日付が含まれない場合には、「ｓｔａｒｔＤａｔｅ」に現在日付を格納する。また、格納部２３２は、「ｅｎｄＤａｔｅ」には情報を格納しない。
【００８０】
一方、格納部２３２は、更新データの社員ＩＤが選択テーブルに記憶されている場合には、選択テーブルに記憶されているレコードのうち、更新データに含まれる社員ＩＤと同一であり、かつ、「ｅｎｄＤａｔｅ」に情報が記憶されていないレコードを最新レコードとして特定する。そして、格納部２３２は、更新データに含まれる属性情報と、最新レコードの属性情報とが同一であるか否かを判定する。そして、格納部２３２は、更新データの属性情報と最新レコードの属性情報とが同一である場合には、かかる更新データに含まれる属性情報を選択テーブルに格納しない。
【００８１】
一方、格納部２３２は、更新データの属性情報と最新レコードの属性情報とが同一でない場合には、更新データに含まれる有効日付から「１日（２４時間）」を減算した日付を最新レコードの「ｅｎｄＤａｔｅ」に格納する。このとき、格納部２３２は、更新データに有効日付が含まれない場合には、現在日付から「１日（２４時間）」を減算した日付を最新レコードの「ｅｎｄＤａｔｅ」に格納する。また、格納部２３２は、更新データに含まれる属性情報を新たなレコードとして選択テーブルに格納する。このとき、格納部２３２は、上記例と同様に、「ｓｔａｒｔＤａｔｅ」に有効日付又は現在日付を格納し、「ｅｎｄＤａｔｅ」に情報を格納しない。
【００８２】
かかる格納部２３２による格納処理について図８〜図１０に示した例を用いて説明する。ここでは、社員ＩＤテーブル２２１が図８に示した状態であり、組織履歴テーブル２２２が図９に示した状態であり、内線履歴テーブル２２３が図１０に示した状態であるものとする。
【００８３】
この状態において、受付部１３１によって、社員ＩＤ「１１２２」、組織名「Ｇ１４」、内線「３３３３」、部屋番号「１−１００１」及び有効日付「２０１２−１−１」を含む更新データが受け付けられたものとする。かかる場合に、格納部２３２は、更新データに含まれる社員ＩＤ「１１２２」が社員ＩＤテーブル２２１に記憶されているので、社員ＩＤテーブル２２１を更新しない。
【００８４】
続いて、格納部２３２は、更新データに含まれる社員ＩＤ「１１２２」及び組織名「Ｇ１４」の組合せが、組織履歴テーブル２２２に記憶されていないので、組織履歴テーブル２２２に記憶されている社員ＩＤ「１１２２」のレコードのうち、ｅｎｄＤａｔｅがＮＵＬＬである最新レコード（図９の３行目のレコード）のｅｎｄＤａｔｅに、有効日付「２０１２−１−１」から１日を減算した日付「２０１１−１２−３１」を格納する。さらに、格納部２３２は、更新データに含まれる社員ＩＤ「１１２２」及び組織名「Ｇ１４」を新たなレコードとして組織履歴テーブル２２２に格納する。このとき、格納部２３２は、新たなレコードの「ｓｔａｒｔＤａｔｅ」に有効日付「２０１２−１−１」を格納し、「ｅｎｄＤａｔｅ」に情報を格納しない。
【００８５】
続いて、格納部２３２は、更新データに含まれる社員ＩＤ「１１２２」及び内線「３３３３」の組合せが、内線履歴テーブル２２３に記憶されているので、内線履歴テーブル２２３を更新しない。このようにして、格納部２３２は、更新データに部屋番号「１−１００１」を用いて、図示しない部屋番号履歴テーブルを更新する。
【００８６】
検索部２３３は、検索要求を受け付けた場合に、かかる検索要求に従って、記憶部２２０から各種データを検索する。例えば、検索部２３３は、特定情報、及び、検索対象の属性情報の名称（カラム名）を含む検索要求を受け付ける。かかる場合に、検索部２３３は、検索要求に含まれる検索対象の属性情報の種別に対応する履歴テーブルを記憶部２２０から選択し、検索要求に含まれる特定情報をキーとして、「検索対象の属性情報」及び「ｓｔａｒｔＤａｔｅ」を履歴テーブルから検索する。そして、検索部２３３は、検索結果の属性情報をｓｔａｒｔＤａｔｅの降順にソートし、ソート後の属性情報及びｓｔａｒｔＤａｔｅが記載された検索結果一覧を検索要求の送信元に通知する。
【００８７】
かかる検索部２３３による検索処理について図９に示した例を用いて説明する。例えば、検索部２３３が、社員ＩＤ「１１２２」、及び、検索対象の属性情報の名称「組織名」を含む検索要求を受け付けたものとする。かかる場合に、検索部２３３は、組織履歴テーブル２２２を検索対象の履歴テーブルとして選択する。そして、検索部２３３は、社員ＩＤ「１１２２」をキーに組織履歴テーブル２２２を検索することで、「組織名」及び「ｓｔａｒｔＤａｔｅ」を取得する。ここの例では、検索部２３３は、組織名「Ｇ１１」及びｓｔａｒｔＤａｔｅ「２００９−１０−１」の組合せと、組織名「Ｇ１２」及びｓｔａｒｔＤａｔｅ「２０１０−４−１」の組合せと、組織名「Ｇ１３」及びｓｔａｒｔＤａｔｅ「２０１１−１２−１」の組合せとを取得する。そして、検索部２３３は、ｓｔａｒｔＤａｔｅの降順にソートすることで、組織名を「Ｇ１３」、「Ｇ１２」、「Ｇ１１」に並び替える。そして、検索部２３３は、組織名「Ｇ１３」及びｓｔａｒｔＤａｔｅ「２０１１−１２−１」、組織名「Ｇ１２」及びｓｔａｒｔＤａｔｅ「２０１０−４−１」、組織名「Ｇ１１」及びｓｔａｒｔＤａｔｅ「２００９−１０−１」に順に記載された検索結果一覧を検索要求の送信元に通知する。これにより、かかる検索結果一覧を参照するユーザは、社員ＩＤが「１１２２」である社員の所属組織の変遷を確認することができる。
【００８８】
なお、上記では、検索部２３３が、検索結果をｓｔａｒｔＤａｔｅの降順に並び替える例を示した。しかし、検索部２３３は、検索結果をｓｔａｒｔＤａｔｅの昇順に並び替えてもよい。また、検索部２３３は、ｓｔａｒｔＤａｔｅではなくｅｎｄＤａｔｅを検索してもよい。かかる場合には、検索部２３３は、ｅｎｄＤａｔｅがＮＵＬＬである属性情報が最新であるものとしてソートを行う。また、検索部２３３は、ｓｔａｒｔＤａｔｅ及びｅｎｄＤａｔｅの双方を検索してもよい。
【００８９】
また、図７に示した格納部２３２及び検索部２３３は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。また、例えば、格納部２３２及び検索部２３３は、ＣＰＵやＭＰＵ等によって、図示しない記憶装置に記憶されているプログラムがＲＡＭを作業領域として実行されることにより実現される。
【００９０】
［実施例２に係るデータ管理装置による格納処理手順］
次に、図１１を用いて、実施例２に係るデータ管理装置２００による格納処理の手順について説明する。図１１は、実施例２に係るデータ管理装置２００による格納処理手順を示すフローチャートである。なお、以下では、記憶部２２０が図８〜図１０に示した各履歴テーブルを有する場合を例に挙げて説明する。
【００９１】
図１１に示すように、データ管理装置２００の格納部２３２は、受付部１３１によって更新データが受け付けられた場合に、かかる更新データに含まれる行数（レコード数）だけ、ループ１に示した処理を繰り返し行う。具体的には、格納部２３２は、更新データ内の１レコードについて、記憶部２２０に記憶されている履歴テーブルの数だけ、ループ２に示した処理を繰り返し行う。なお、格納部２３２は、社員ＩＤテーブル２２１、組織履歴テーブル２２２、内線履歴テーブル２２３、図示しない部屋番号履歴テーブルの順に格納処理を行うものとする。
【００９２】
かかるループ２における処理について説明する。格納部２３２は、更新対象の履歴テーブルが社員ＩＤテーブル２２１であるか否かを判定する（ステップＳ３０１）。このとき、格納部２３２は、更新対象の履歴テーブルが社員ＩＤテーブル２２１である場合には（ステップＳ３０１肯定）、更新データに含まれる特定情報「社員ＩＤ」と同一の情報が社員ＩＤテーブル２２１に記憶されているか否かを判定する（ステップＳ３０２）。
【００９３】
そして、格納部２３２は、更新データの社員ＩＤが社員ＩＤテーブル２２１に記憶されていない場合には（ステップＳ３０２否定）、更新データに含まれる社員ＩＤを社員ＩＤテーブル２２１に新たなレコードとして格納する（ステップＳ３０３）。このとき、格納部２３２は、更新データに有効日付が含まれる場合には、「ｓｔａｒｔＤａｔｅ」に有効日付を格納し、更新データに有効日付が含まれない場合には、「ｓｔａｒｔＤａｔｅ」に現在日付を格納する。また、格納部２３２は、「ｅｎｄＤａｔｅ」には情報を格納しない。また、格納部２３２は、更新データの社員ＩＤが社員ＩＤテーブル２２１に記憶されている場合には（ステップＳ３０２肯定）、かかる更新データに含まれる社員ＩＤを社員ＩＤテーブル２２１に格納せずに、ステップＳ３０１に戻る。
【００９４】
また、格納部２３２は、更新対象の履歴テーブルが社員ＩＤテーブル２２１でない場合には（ステップＳ３０１否定）、更新データに含まれる特定情報「社員ＩＤ」と同一の情報が更新対象の履歴テーブルに記憶されているか否かを判定する（ステップＳ３０４）。例えば、格納部２３２は、更新対象の履歴テーブルが組織履歴テーブル２２２である場合には、更新データに含まれる社員ＩＤが組織履歴テーブル２２２に記憶されているか否かを判定する。
【００９５】
そして、格納部２３２は、更新データの社員ＩＤが更新対象の履歴テーブルに記憶されている場合には（ステップＳ３０４肯定）、更新対象の履歴テーブルから、かかる社員ＩＤと一致するレコードを抽出し、抽出したレコードのうちｅｎｄＤａｔｅがＮＵＬＬである最新レコードを特定する。そして、格納部２３２は、更新データに含まれる属性情報と同一の属性情報が最新レコードに記憶されているか否かを判定する（ステップＳ３０５）。
【００９６】
例えば、更新対象の履歴テーブルが組織履歴テーブル２２２であるものとする。かかる場合に、格納部２３２は、組織履歴テーブル２２２から、更新データに含まれる社員ＩＤと一致するレコードのうちｅｎｄＤａｔｅがＮＵＬＬである最新レコードを特定し、特定した最新レコードに更新データに含まれる組織名が記憶されているか否かを判定する。
【００９７】
そして、格納部２３２は、更新データの属性情報が最新レコードに記憶されていない場合には（ステップＳ３０５否定）、更新データに含まれる有効日付から「１日」を減算した日付、又は、現在日付（更新日）から「１日」を減算した日付を最新レコードの「ｅｎｄＤａｔｅ」に格納する（ステップＳ３０６）。さらに、格納部２３２は、更新データに含まれる社員ＩＤ及び属性情報と、ｓｔａｒｔＤａｔｅ及びｅｎｄＤａｔｅとを新たなレコードとして更新対象の履歴テーブルに格納する（ステップＳ３０７）。このとき、格納部２３２は、更新データに有効日付が含まれる場合には、ｓｔａｒｔＤａｔｅに有効日付を格納し、更新データに有効日付が含まれない場合には、ｓｔａｒｔＤａｔｅに現在日付（更新日）を格納する。また、格納部２３２は、ｅｎｄＤａｔｅには情報を格納しない。
【００９８】
例えば、更新対象の履歴テーブルが組織履歴テーブル２２２であるものとする。かかる場合に、格納部２３２は、更新データの組織名が組織履歴テーブル２２２の最新レコードに記憶されていない場合に、更新データに含まれる有効日付から「１日」を減算した日付等を最新レコードの「ｅｎｄＤａｔｅ」に格納する。さらに、格納部２３２は、更新データに含まれる社員ＩＤ、組織名、ｓｔａｒｔＤａｔｅ及びｅｎｄＤａｔｅを新たなレコードとして組織履歴テーブル２２２に格納する。
【００９９】
また、格納部２３２は、更新データの属性情報が最新レコードに記憶されている場合には（ステップＳ３０５肯定）、かかる更新データに含まれる社員ＩＤ及び属性情報を更新対象の履歴テーブルに格納せずに、ステップＳ３０１に戻る。
【０１００】
また、格納部２３２は、更新データの社員ＩＤが更新対象の履歴テーブルに記憶されていない場合には（ステップＳ３０４否定）、更新データに含まれる社員ＩＤ及び属性情報と、ｓｔａｒｔＤａｔｅ及びｅｎｄＤａｔｅとを新たなレコードとして更新対象の履歴テーブルに格納する（ステップＳ３０８）。このとき、格納部２３２は、更新データに有効日付が含まれる場合には、ｓｔａｒｔＤａｔｅに有効日付を格納し、更新データに有効日付が含まれない場合には、ｓｔａｒｔＤａｔｅに現在日付（更新日）を格納する。また、格納部２３２は、ｅｎｄＤａｔｅには情報を格納しない。
【０１０１】
［実施例２に係るデータ管理装置による検索処理手順］
次に、図１２を用いて、実施例２に係るデータ管理装置２００による検索処理の手順について説明する。図１２は、実施例２に係るデータ管理装置２００による検索処理手順を示すフローチャートである。なお、以下では、記憶部２２０が図８〜図１０に示した各履歴テーブルを有する場合を例に挙げて説明する。
【０１０２】
図１２に示すように、データ管理装置２００の検索部２３３は、検索要求を受け付けた場合に、検索対象の属性情報を記憶する履歴テーブル（組織履歴テーブル２２２、内線履歴テーブル２２３、部屋番号履歴テーブルなど）から、検索要求に含まれる社員ＩＤをキーに、検索対象の属性情報を検索する（ステップＳ４０１）。
【０１０３】
そして、検索部２３３は、検索結果の属性情報をｓｔａｒｔＤａｔｅの降順にソートする（ステップＳ４０２）。この後に、検索部２３３は、ソート後の検索結果一覧を検索要求の送信元に通知する。なお、記憶部２２０内の各履歴テーブルには、同一の属性情報が連続して記憶されることがないので、検索部２３３は、連続する属性情報を削除する処理を行わなくてよい。
【０１０４】
［実施例２の効果］
上述してきたように、実施例２に係るデータ管理装置２００において、記憶部２２０は、属性情報の種別毎に、かかる属性情報と有効期限とを対応付けて記憶する履歴テーブルを有する。また、格納部２３２は、更新要求を受け付けた場合に、更新要求に含まれる新たな属性情報の種別に対応する履歴テーブルに記憶されている最新属性情報の有効期限を更新するとともに、新たな属性情報を履歴テーブルに格納する。また、検索部１３３は、検索要求を受け付けた場合に、検索要求に含まれる属性情報の種別に対応する履歴テーブルから属性情報を検索する。
【０１０５】
このように、実施例２に係るデータ管理装置２００は、属性情報毎に異なる履歴テーブルにて、かかる属性情報の変更履歴を管理する。これにより、実施例２に係るデータ管理装置２００は、更新のあった属性情報のみを更新することができるので、記憶部２２０に管理するデータ量を削減することができる。また、実施例２に係るデータ管理装置２００は、連続して重複する属性情報を各履歴テーブルに格納しないので、連続して重複する属性情報を削除する等の処理を要しない。この結果、実施例２に係るデータ管理装置２００は、データの変遷を容易に提供することができる。
【０１０６】
なお、上記実施例２において、データ管理装置２００は、記憶部２２０内の各履歴テーブルが記憶する属性名を属性管理テーブルにて管理してもよい。図１３に、実施例２に係る属性管理テーブル２２４の一例を示す。図１３に示すように、属性管理テーブル２２４は、「属性名」、「テーブル名」といった項目を有する。「属性名」は、記憶部２２０内の各履歴テーブルが記憶する属性情報の名称（カラム名）を示し、属性情報の種別に該当する。「テーブル名」は、「属性名」によって示される属性情報を記憶する履歴テーブルの名称を示す。
【０１０７】
すなわち、図１３の例では、社員ＩＤテーブル２２１が「社員ＩＤ」を記憶し、組織履歴テーブル２２２が「組織名」を記憶し、内線履歴テーブル２２３が「内線」を記憶することを示している。
【０１０８】
実施例２に係る格納部２３２は、かかる属性管理テーブル２２４を参照することにより、更新対象の履歴テーブルを選択することができる。また、実施例２に係る検索部２３３は、かかる属性管理テーブル２２４を参照することにより、検索対象の履歴テーブルを選択することができる。これにより、格納部２３２及び検索部２３３は、属性情報の種別が膨大となり、履歴テーブルの数が膨大になった場合であっても、属性管理テーブル２２４を参照することにより、更新対象の履歴テーブルを容易に選択することができる。
【０１０９】
なお、上記例では、図１３に例示した属性管理テーブル２２４が属性名「社員ＩＤ」及びテーブル名「社員ＩＤテーブル」のレコードを記憶する例を示した。しかし、格納部２３２や検索部２３３は、「社員ＩＤ」のような基本的な情報がどのテーブルに記憶されているかを予め認識している場合もある。かかる場合には、属性管理テーブル２２４は、属性名「社員ＩＤ」及びテーブル名「社員ＩＤテーブル」のレコードを記憶しなくてもよい。
【実施例３】
【０１１０】
上述したデータ管理装置は、上記実施例以外にも種々の異なる形態にて実施されてよい。そこで、実施例３では、上記のデータ管理装置の他の実施例について説明する。
【０１１１】
［管理対象のデータ］
上記実施例では、データ管理装置１００又は２００が、マスターデータを管理する例を示した。しかし、上記実施例に係るデータ管理装置１００又は２００は、マスターデータ以外のいかなるデータを管理する場合にも適用することができる。
【０１１２】
［データ構造］
また、上記実施例では、データ管理装置１００又は２００が、特定情報（上記実施例では、「社員ＩＤ」）を含むデータを管理する例を示した。しかし、上記実施例に係るデータ管理装置１００又は２００は、特定情報を含まないデータを管理する場合にも適用することができる。例えば、上記実施例１に係るデータ管理装置１００は、社員ＩＤの数だけ、マスターデータテーブルを有してもよい。この場合、データ管理装置１００は、社員ＩＤを含まないマスターデータテーブルを有することになる。かかる場合に、データ管理装置１００の格納部１３２は、更新データに含まれる社員ＩＤに基づいて、更新対象のマスターデータテーブルを選択することとなる。そして、格納部１３２は、選択したマスターデータテーブルの最新レコード内の属性情報と、更新データに含まれる属性情報とが全て一致するか否かを判定し、一致する場合には格納処理を行わずに、一致しない場合には、更新データに含まれる属性情報をマスターデータテーブルに格納する。同様に、上記実施例２に係るデータ管理装置２００は、社員ＩＤの数だけ、履歴テーブルを有してもよい。この場合、データ管理装置２００は、社員ＩＤを含まない履歴テーブルを有することになる。
【０１１３】
［更新データ］
また、上記実施例では、更新データに全ての属性情報が含まれる例を示した。しかし、更新データには、特性情報（上記実施例では、「社員ＩＤ」）と、更新対象の属性情報のみが含まれてもよい。例えば、組織名を更新するための更新データには、社員ＩＤと、更新後の組織名と、有効日付とが含まれ、内線及び部屋番号については含まれなくてもよい。この例の場合、実施例１に係るデータ管理装置１００の格納部１３２は、更新データに含まれる社員ＩＤ及び組織名の組合せがマスターデータテーブル１２１の最新レコードに記憶されている場合には、格納処理を行わない。一方、格納部１３２は、かかる組合せが最新レコードに記憶されていない場合には、最新レコードのｅｎｄＤａｔｅを更新するとともに、更新データに含まれる属性情報を新たなレコードとしてマスターデータテーブル１２１に格納する。このとき、格納部１３２は、更新データに含まれない属性情報については、最新レコードにおける属性情報を新たなレコードにコピーする。
【０１１４】
［システム構成］
また、上記実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図２、図８〜図１０、図１３に示した各種情報は一例であって任意に変更することができる。一例を挙げると、図２に示したマスターデータテーブル１２１は、社員の氏名、住所、携帯電話番号、役職等の情報を記憶してもよい。また、図２に示したマスターデータテーブル１２１は、社員に関するマスターデータではなく、製品、顧客、会計等に関するマスターデータを記憶してもよい。
【０１１５】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図１に示した受付部１３１と格納部１３２とは統合されてもよい。同様に、図７に示した受付部１３１と格納部２３２とは統合されてもよい。
【０１１６】
［プログラム］
また、上記実施例において説明したデータ管理装置１００又は２００が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、データ管理装置１００又は２００が実行する処理をコンピュータが実行可能な言語で記述したデータ管理プログラムを作成することもできる。この場合、コンピュータがデータ管理プログラムを実行することにより、上記実施例と同様の効果を得ることができる。さらに、かかるデータ管理プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたデータ管理プログラムをコンピュータに読み込ませて実行することにより上記実施例と同様の処理を実現してもよい。以下に、図１に示したデータ管理装置１００と同様の機能を実現するデータ管理プログラムを実行するコンピュータの一例を説明する。
【０１１７】
図１４は、データ管理プログラムを実行するコンピュータ１０００を示す図である。図１４に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。
【０１１８】
メモリ１０１０は、図１４に例示するように、ＲＯＭ（Read  Only  Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１４に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図１４に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図１４に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図１４に例示するように、例えばディスプレイ１０６１に接続される。
【０１１９】
ここで、図１４に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記のデータ管理プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。例えば、図１に例示した受付部１３１と同様の情報処理を実行する受付手順と、格納部１３２と同様の情報処理を実行する格納手順と、検索部１３３と同様の情報処理を実行する検索手順とが記述されたプログラムモジュール１０９３が、ハードディスクドライブ１０３１に記憶される。
【０１２０】
また、上記実施例で説明した記憶部１２０が保持する各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、受付手順、格納手順、検索手順を実行する。
【０１２１】
なお、データ管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、データ管理プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local  Area  Network）、ＷＡＮ（Wide  Area  Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【符号の説明】
【０１２２】
１００  データ管理装置
１２０  記憶部
１２１  マスターデータテーブル
１３１  受付部
１３２  格納部
１３３  検索部
２００  データ管理装置
２２０  記憶部
２２１  社員ＩＤテーブル
２２２  組織履歴テーブル
２２３  内線履歴テーブル
２２４  属性管理テーブル
２３２  格納部
２３３  検索部
【図１】
2013171495.tif 000003
【図２】
2013171495.tif 000004
【図３】
2013171495.tif 000005
【図４】
2013171495.tif 000006
【図５】
2013171495.tif 000007
【図６】
2013171495.tif 000008
【図７】
2013171495.tif 000009
【図８】
2013171495.tif 000010
【図９】
2013171495.tif 000011
【図１０】
2013171495.tif 000012
【図１１】
2013171495.tif 000013
【図１２】
2013171495.tif 000014
【図１３】
2013171495.tif 000015
【図１４】
2013171495.tif 000016