図面 (/)

技術 データ検索装置、データ検索システム、データ検索方法およびデータ検索プログラム

出願人 日本電信電話株式会社
発明者 飯塚京士村山隆彦岩嵜雄大森田大翼
出願日 2012年8月2日 (7年7ヶ月経過) 出願番号 2012-172366
公開日 2014年2月20日 (6年1ヶ月経過) 公開番号 2014-032522
状態 未査定
技術分野 検索装置
主要キーワード 履歴期間 一時テーブル メインテーブル 異種データ データ検索プログラム 横断検索 ログソー スキーマ変更
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2014年2月20日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

変更履歴個別管理する各属性情報から構成される情報の検索を容易にすることを課題とする。

解決手段

データ検索装置10は、メインテーブル21のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブル22から、属性情報および変更履歴を取得し、有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成する。そして、データ検索装置10は、作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成する。そして、データ検索装置10は、作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う。

概要

背景

近年、異なるシステムや異なるフォーマット蓄積されたために、統合した利用が困難な共有資産となるデータが多数存在している。このようなデータを利用する既存システムに応じて個別最適化されたスキーマデータ群が、既存の枠組みを超えて参照・有効活用できることが求められている。

例えば、企業内のシステムを連結しデータ連携を図るEAI(Enterprise Application Integration)、企業内の知識共有が可能なようにするナレッジマネージメントマスタデータを統合活用するためのマスタデータマネージメントなどの技術が提供されている。

また、このようなデータを管理する技術として、コード管理ファイル有効期限を付与することにより同一コードに対応する値の変更履歴の管理を可能とする技術が知られている(例えば、非特許文献1参照)。また、このようなデータを管理して検索する技術として、リレーショナルデータベースに格納されているデータをグラフデータ一種であるRDFデータへと変換し、RDFデータを検索する技術が知られている(例えば、非特許文献2参照)。

概要

変更履歴を個別管理する各属性情報から構成される情報の検索を容易にすることを課題とする。データ検索装置10は、メインテーブル21のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブル22から、属性情報および変更履歴を取得し、有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成する。そして、データ検索装置10は、作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成する。そして、データ検索装置10は、作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う。

目的

この発明は、上述した従来技術の課題を解決するためになされたものであり、変更履歴を個別管理する各属性情報から構成される情報の検索を容易に実現することを目的とする

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

所定のデータに関する属性情報変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成部と、前記テーブル作成部によって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成部と、前記グラフ作成部によって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索部と、を備えることを特徴とするデータ検索装置

請求項2

前記テーブル作成部は、前記履歴テーブルから、前記属性情報および前記変更履歴を取得し、全ての属性情報について、前記有効期間が共通する属性情報同士を対応付け、前記有効期間が共通する属性情報の組に対して一意識別できる識別子を付与したテーブルをログテーブルとして作成し、前記ログテーブルの情報に基づき、前記有効期間のうち最も新しい期間の属性情報を記憶するテーブルをカレントログテーブルとして作成することを特徴とする請求項1に記載のデータ検索装置。

請求項3

前記テーブル作成部によって作成されたテーブルを記憶する記憶部をさらに備え、前記検索部は、前記記憶部によって記憶されたテーブルを読み出し、該テーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成することを特徴とする請求項1または2に記載のデータ検索装置。

請求項4

前記グラフ作成部は、前記テーブル作成部で作成されたテーブルを用いて、所定のデータの最新の全属性情報と、その属性情報が有効な期間とをづけたカレントリソースと、所定のデータの最新の全属性情報が不変な期間と、その期間の全属性情報とを紐づけたログリソースと、前記カレントリソースと前記ログリソースの関係情報で構成されたグラフデータを作成することを特徴とする請求項1〜3のいずれか一つに記載のデータ検索装置。

請求項5

前記グラフ作成部は、前記最新の全属性情報、前記カレントリソース、前記不変な期間、前記ログリソース、および、前記グラフデータに加え、前記ログリソース間順序関係をさらに作成することを特徴とする請求項4に記載のデータ検索装置。

請求項6

前記所定のデータを記憶するメインテーブルとともに、該所定のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とが対応付けられた複数の履歴テーブルを記憶する記憶部と、前記記憶部によって記憶された複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成部と、前記テーブル作成部によって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成部と、前記グラフ作成部によって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索部と、を備えることを特徴とするデータ検索システム

請求項7

データ検索装置で実行される情報推薦方法であって、所定のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成工程と、前記テーブル作成工程によって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成工程と、前記グラフ作成工程によって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索工程と、を含んだことを特徴とするデータ検索方法

請求項8

所定のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成ステップと、前記テーブル作成ステップによって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成ステップと、前記グラフ作成ステップによって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索ステップと、をコンピュータに実行させることを特徴とするデータ検索プログラム

技術分野

背景技術

0002

近年、異なるシステムや異なるフォーマット蓄積されたために、統合した利用が困難な共有資産となるデータが多数存在している。このようなデータを利用する既存システムに応じて個別最適化されたスキーマデータ群が、既存の枠組みを超えて参照・有効活用できることが求められている。

0003

例えば、企業内のシステムを連結しデータ連携を図るEAI(Enterprise Application Integration)、企業内の知識共有が可能なようにするナレッジマネージメントマスタデータを統合活用するためのマスタデータマネージメントなどの技術が提供されている。

0004

また、このようなデータを管理する技術として、コード管理ファイル有効期限を付与することにより同一コードに対応する値の変更履歴の管理を可能とする技術が知られている(例えば、非特許文献1参照)。また、このようなデータを管理して検索する技術として、リレーショナルデータベースに格納されているデータをグラフデータ一種であるRDFデータへと変換し、RDFデータを検索する技術が知られている(例えば、非特許文献2参照)。

先行技術

0005

就業管理システムリシテアシリーズ”、[online]、[平成24年7月23日検索]、インターネット<http://lysithea.jp/products/>
“D2RQ”、[online]、[平成24年7月23日検索]、インターネット<http://d2rq.org/>

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

0006

しかしながら、上記した同一コードに対応する値の変更履歴を管理する技術では、検索のためのクエリが複雑化するという課題があった。つまり、複数の属性情報から構成される情報を一意実体が定まるIDに紐付けて統合・管理する場合に、IDに紐付けられた情報を構成する属性情報個々の変更履歴は管理されているが、変更履歴情報横断的に検索する手段については言及されていない。このため、変更履歴を個別管理する各属性情報から構成される情報を検索する場合に、情報のスキーマ構造を把握していなければ、どのような属性情報から構成されるかが分からず、検索のためのクエリが複雑化するという課題があった。

0007

また、上記したRDFデータを検索する技術では、スキーマ構造を知らなくても全属性情報を検索、取得できるようになるが、履歴情報を持つ各属性情報のテーブルを1つに統合するために再構成するスキーマ変更機能を持たないため、全属性情報の変遷を辿る検索の実施にあたり、複数の履歴情報の精査が必要となり、クエリが複雑化するという課題があった。

0008

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、変更履歴を個別管理する各属性情報から構成される情報の検索を容易に実現することを目的とする。

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

0009

上述した課題を解決し、目的を達成するため、データ検索装置は、所定のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成部と、前記テーブル作成部によって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成部と、前記グラフ作成部によって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索部と、を備えることを特徴とする。

0010

また、データ検索システムは、前記所定のデータを記憶するメインテーブルとともに、該所定のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とが対応付けられた複数の履歴テーブルを記憶する記憶部と、前記記憶部によって記憶された複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成部と、前記テーブル作成部によって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成部と、前記グラフ作成部によって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索部と、を備えることを特徴とする。

0011

また、データ検索方法は、データ検索装置で実行される情報推薦方法であって、所定のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成工程と、前記テーブル作成工程によって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成工程と、前記グラフ作成工程によって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索工程と、を含んだことを特徴とする。

0012

また、データ検索プログラムは、所定のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブルから、前記属性情報および前記変更履歴を取得し、前記有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成するテーブル作成ステップと、前記テーブル作成ステップによって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成するグラフ作成ステップと、前記グラフ作成ステップによって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う検索ステップと、をコンピュータに実行させることを特徴とする。

発明の効果

0013

本願に開示するデータ検索装置、データ検索システム、データ検索方法およびデータ検索プログラムは、変更履歴を個別管理する各属性情報から構成される情報の検索を容易にするという効果を奏する。

図面の簡単な説明

0014

図1は、第一の実施の形態に係るデータ検索装置の構成を示すブロック図である。
図2は、社員メインテーブルの一例を示す図である。
図3は、部屋番号履歴テーブルの一例を示す図である。
図4は、職責履歴テーブルの一例を示す図である。
図5は、部屋番号履歴テーブルの一例を示す図である。
図6は、社員ログテーブルの一例を示す図である。
図7は、社員ログ順序テーブルの一例を示す図である。
図8は、社員カレントログテーブルの一例を示す図である。
図9は、RDFデータの一例を示す図である。
図10は、RDFデータの一例を示す図である。
図11は、社員カレントログテーブルの一例を示す図である。
図12は、URIであらわされるカレントリソースグラフ表現した場合におけるノードの一例を示す図である。
図13は、RDFデータの一例を示す図である。
図14は、設定ファイルの一例を示す図である。
図15は、RDFデータの計算機処理フォーマットの一例を示す図である。
図16は、社員ログテーブルの一例を示す図である。
図17は、URIであらわされるログリソースをグラフ表現した場合におけるノードの一例を示す図である。
図18は、RDFデータの一例を示す図である。
図19は、設定ファイルの一例を示す図である。
図20は、RDFデータの計算機処理フォーマットの一例を示す図である。
図21は、RDFデータの一例を示す図である。
図22は、設定ファイルの一例を示す図である。
図23は、RDFデータの計算機処理フォーマットの一例を示す図である。
図24は、マスタデータから作成したRDFデータの一例を示す図である。
図25は、簡単な検索クエリで検索結果を取得できることを説明するための図である。
図26は、簡単な検索クエリで検索結果を取得できることを説明するための図である。
図27は、RDFに変換しているため、外部のRDFデータとの相互接続が容易であることを説明する図である。
図28は、第一の実施の形態に係るデータ検索装置の処理動作を示すフローチャートである。
図29は、第一の実施の形態に係るデータ検索装置の処理動作を示すフローチャートである。
図30は、データ検索プログラムを実行するコンピュータを示す図である。

実施例

0015

以下に添付図面を参照して、この発明に係るデータ検索装置、データ検索システム、データ検索方法およびデータ検索プログラムの実施形態を詳細に説明する。なお、この実施形態によりこの発明が限定されるものではない。

0016

[第一の実施の形態]
以下の実施の形態では、第一の実施の形態に係るデータ検索システムの構成、および処理の流れを順に説明し、最後に第一の実施の形態による効果を説明する。

0017

[データ検索装置の構成]
まず、図1を用いて、図1に示したデータ検索システム100に含まれるデータ検索装置10の構成を説明する。図1は、第一の実施の形態に係るデータ検索装置の構成を示すブロック図である。図1に示すように、データ検索システム100は、データ検索装置10と、マスタデータDB(Data Base)20と、アプリケーション30とを有する。

0018

マスタデータDB20は、メインテーブル21と、メインテーブル21に対応付けられた複数の履歴テーブル22とを格納する。メインテーブル21には、プライマリキーとなる「ID」と、レコードの有効期限である「start Data」および「end Data」と、レコードが存在する間不変な「属性情報」とが格納されている。履歴テーブル22には、「ID」、「属性情報」、および、「start Data」および「end Data」が格納されている。

0019

例えば、メインテーブル21は、図2に例示するように、社員に関する情報を格納するメインテーブルとして「社員メインテーブル」を記憶する。図2の例を挙げて説明すると、社員メインテーブルでは、プライマリキーとなる「ID」と、社員の「氏名」と、社員が所属する組織のIDである「組織ID」と、レコードの有効期限である「start Data」および「end Data」とを記憶する。

0020

また、例えば、履歴テーブル22は、図3および図4に例示するように、社員に関する履歴管理された属性情報を格納した履歴テーブルとして、「部屋番号履歴テーブル」および「職責履歴テーブル」を記憶する。図3の例を挙げて説明すると、部屋番号履歴テーブルは、社員メインテーブルのプライマリキーとなる「ID」と、社員が職務を行う部屋の番号である「部屋」と、レコードの有効期限である「start Data」および「end Data」とを対応付けて記憶する。また、図4の例を挙げて説明すると、職責履歴テーブルは、社員メインテーブルのプライマリキーとなる「ID」と、社員の会社における職責を示す「職責」と、レコードの有効期限である「start Data」および「end Data」とを対応付けて記憶する。

0021

アプリケーション30は、データ検索装置10に対して、検索クエリを送信して検索要求を行い、その検索要求に対する検索結果を受信する。なお、検索処理については、データ検索装置の検索部13の説明で詳述する。

0022

データ検索装置10は、テーブル作成部11、グラフ作成部12、検索部13、変換用DB14およびグラフDB15を有し、マスタデータDB20およびアプリケーション30と接続している。以下にこれらの各部の処理を説明する。

0023

変換用DB14は、後述するテーブル作成部11によって作成されるログテーブル、ログ順序テーブルおよびカレントログテーブルを記憶する。また、変換用DB14は、記憶したログテーブル、ログ順序テーブルおよびカレントログテーブルが、後述するグラフ作成部12によって読み出される。なお、ログテーブル、ログ順序テーブルおよびカレントログテーブルについては、後に詳述する。

0024

グラフDB15は、後述するグラフ作成部12によって作成されたRDFグラフデータを格納する。また、グラフDB15は、記憶したRDFグラフデータが、後述する検索部13によって検索され、読み出される。なお、RDFグラフデータについては、後に詳述する。

0025

テーブル作成部11は、メインテーブル21のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブル22から、属性情報および変更履歴を取得し、有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成し、変換用DB14に格納する。以下に、テーブル作成部11によって実行させる処理について詳しく説明する。

0026

まず、テーブル作成部11は、変換するメインテーブル21をマスタデータDB21から取得し、メインテーブル21に紐付く全ての履歴テーブル22を取得する。例えば、テーブル作成部11は、図2に例示した「社員メインテーブル」が変換するメインテーブルとして指定された場合には、該メインテーブルに紐付く全履歴テーブルとして、図3および図4に例示した「部屋番号履歴テーブル」と「職責履歴テーブル」とをマスタデータDB20から取得する。

0027

そして、テーブル作成部11は、履歴テーブルの中で、履歴情報の無い期間を精査し、履歴の無い期間をNULL値で埋める。例えば、図3の部屋番号履歴テーブルの例では、「2000−4−1から2000−4−31までの期間」および「2002−6−1から2003−5−31までの期間」については、履歴情報が無い期間である。このような場合、テーブル作成部11は、履歴情報の無い期間に対しては、期間とID以外の属性情報にNULL値を入れて、図5に例示するように、履歴の無い期間を無くした部屋番号履歴テーブルを作成する。なお、オリジナルのテーブルにデータを追記することは、安全でないため、ビュー一時テーブルの形で記録しておくことが望ましい。

0028

続いて、テーブル作成部11は、全履歴テーブルで、属性値が変化しない期間を取得し、ログテーブルを構築する。具体的には、テーブル作成部11は、メインテーブル21と関連する属性テーブルに格納されている属性情報を精査し、全ての属性情報において変更しない期間を取得する。そして、テーブル作成部11は、「LogID」を付与して、IDおよび全属性値と属性値が変化しない期間をログテーブルに格納する。

0029

例えば、図4に例示した職責履歴テーブルおよび図5に例示した部屋番号履歴テーブルを精査し、全ての属性情報において変更しない期間を取得してログテーブルを構築した結果、図6に例示するような社員ログテーブルが出来上がる。なお、「LogID」は、一意の値となるように自動的に付与されており、上記の例では、ID+startDataとなっているが、この例に限定されることはない。

0030

そして、テーブル作成部11は、ログテーブルからログ順序テーブルを構築する。具体的には、テーブル作成部11は、ログテーブルの中で、同一IDを持つレコード間順序関係を精査し、順序関係を記録するログ順序テーブルを作成する。このログ順序テーブルには、図7に例示するように、「LogID」と、LogIDの1つ前のログを示す「PrevLogID」、LogIDの次のログを示す「NextLogID」が格納される。図7に例示する社員ログ順序テーブルは、図6の社員ログテーブルを精査した結果、出来上がったテーブルの例である。

0031

続いて、テーブル作成部11は、ログテーブルからカレントログテーブルを構築する。具体的には、テーブル作成部11は、社員ログテーブルの各IDに対して、end Dateの値が最も新しいレコード1つを抽出して、社員ログテーブルの当該抽出したレコードにおけるstart Date以外の値を社員カレントログテーブルに格納する。なお、社員ログテーブルにおけるLogIDは、社員カレントログテーブルにおけるカレントLogIDに対応する。また、社員カレントログテーブルのstart Data値は、社員メインテーブルの同じIDのレコードのstart Data値を入れる。例えば、図2の社員メインテーブルと図6の社員ログテーブルから、図8に例示する社員カレントログテーブルを構築することができる。

0032

その後、テーブル作成部11は、全ての変換するメインテーブルに対して上記で説明した処理を行って、ログテーブル、ログ順序テーブルおよびカレントログテーブルを作成する処理を繰り返し行い、ログテーブル、ログ順序テーブルおよびカレントログテーブルを変換用DB14に格納する。

0033

グラフ作成部12は、テーブル作成部11によって作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータ(例えば、RDF(Resource Description Framework)データ)を作成し、グラフDB15に格納する。以下に、グラフ作成部12によって実行させる処理について詳しく説明する。RDFデータとは、サブジェクトプロパティオブジェクトの3つ組みで表されるラベル付き有向グラフで表せるデータである。図9および図10は、RDFデータをグラフ表現した例である。図9の「emp:1234111」とラベルが付けされた楕円ノードがサブジェクト、「鈴木太郎」とラベルが付けされた長方形ノードがオブジェクト、「emp:氏名」とラベル付けされた有向エッジがプロパティである。RDFデータのノードには、楕円ノードで表現されるRDFリソースと、長方形ノードで表現されるリテラルの2種類のノードがある。RDFリソースとプロパティには、URIなどユニークに識別できるIDをラベルにふられる。RDFリソースは、「rdf:type」でタイプを割り当てることができる。例えば図10では、RDFリソース「emp:1234111」のタイプは「emp:社員」である。

0034

まず、グラフ作成部12は、カレントログテーブルから、カレントリソースと、カレントリソースに繋がる周辺情報を作成する。ここで、カレントリソースとは、カレントログテーブルに格納されているIDに該当する項目が抽出され、URI(Uniform Resource Identifier)化してRDFリソース化したものである。カレントリソースの周辺情報は、カレントリソースをサブジェクトないしはオブジェクトにし、カレントログテーブルのID以外の属性をプロパティに、その属性値をオブジェクトないしはサブジェクトに変換することで作成する。

0035

例えば、図11に例示する社員カレントログテーブルに格納されているデータからは、URIのカレントリソースとして、「http://hogehoge.com/employee#1234111」および「http://hogehoge.com/employee#3399000」が得られる。また、上記したURIであらわされるカレントリソースは、後述のグラフ表現するとき、図12に示すような楕円で囲まれたノードで表現される。

0036

具体的には、グラフ作成部12は、カレントリソースと、カレントリソースに繋がる周辺情報を作成する処理として、カレントログテーブルのレコードごとにRDFデータを変換する。例えば、グラフ作成部12は、IDをRDFリソースに変換し、これをサブジェクトに、ID以外のカレントログテーブルの属性をプロパティに、その属性値をオブジェクトに変換する。ここで、カレントリソースのタイプ、カレントリソースをサブジェクトにするか、オブジェクトにするか、各属性に対応するプロパティ名、各属性値をリテラルにするか、RDFにするか等は、グラフ作成部12が保持する設定ファイルによって事前に定義されている。図14は、図11の社員カレントログテーブルから、カレントリソースとカレントリソースにつながる周辺情報を作成するための設定ファイルの例である。図14の設定ファイルを用いた、カレントリソースの作成方法を説明する。まず、社員カレントログテーブルの「ID」の値と「http://hogehoge.com/employee#」を組み合わせて、タイプが「emp:社員」となるRDFリソース化し、これをカレントリソースとする。次に、図14の設定ファイルを用いた周辺情報の作成方法を説明する。まず、社員カレントログテーブルの「カレントLogID」の値を、「http://hogehoge.com/employee#」と組み合わせてRDFリソース化したものをオブジェクトとし、カレントリソースをサブジェクトとし、プロパティ「emp:カレントlog」を経由してつなげる。また、社員カレントログテーブルの「氏名」の値は、値をそのままリテラル化したものをオブジェクトとし、カレントリソースをサブジェクトとして、プロパティ「emp:氏名」を経由してつなげる。同様に、社員カレントログテーブルの他の値もRDFに変換する。

0037

具体例を挙げると、図13に示すRDFデータは、図8に例示する社員カレントログテーブルのID「1234111」のレコードを変換してRDFデータにしたものである。また、図14に例示するデータは、図13に例示するRDFデータに変換する際に使用した設定ファイルの例であり、各属性に対応するプロパティ名などが定義されている。また、図15に例示するデータは、図13に例示するRDFデータを計算機処理する際のデータフォーマットの例である。

0038

そして、グラフ作成部12は、ログテーブルから、ログリソースと、ログリソースに繋がる周辺情報を作成する。ここで、ログリソースとは、ログテーブルやログ順序テーブルに格納されている「LogID」に該当する項目、ログ順序テーブルに格納されている「NextLogID」および「PrevLogID」に該当する項目が抽出され、URI化してRDFリソース化したものである。ログリソースの周辺情報は、ログリソースをサブジェクトないしはオブジェクトにし、ログテーブルのLogID以外の属性をプロパティに、その属性値をオブジェクトないしはサブジェクトに変換することで作成する。

0039

例えば、図16に例示する社員ログテーブルに格納されているデータからは、URIのログソースとして、「http://hogehoge.com/employee#1234111-2000-4-1」、「http://hogehoge.com/employee#1234111-2000-5-1」等が得られる。なお、URIの「http://hogehoge.com/employee#」の部分は、グラフ作成部12が保持する定義ファイル等で設定されているものとする。また、上記したURIであらわされるログリソースは、後述のグラフ表現するとき、図17に示すような楕円で囲まれたノードで表現される。

0040

具体的には、グラフ作成部12は、ログリソースと、ログリソースに繋がる周辺情報を作成する処理として、ログテーブルから、ログリソースの周辺情報を作成する。例えば、グラフ作成部12は、IDをリソースに変換してサブジェクトにし、LogIDから作成したログリソースをオブジェクトに、IDとログID間の関係性を示す名称をプロパティに変換する。

0041

また、グラフ作成部12は、ログIDをRDFリソースに変換し、これをサブジェクトに、ログIDとID以外のログテーブルの属性をプロパティに、その属性値をオブジェクトに変換する。ここで、ログリソースのタイプ、ログリソースをサブジェクトにするか、オブジェクトにするか、各属性に対応するプロパティ名、各属性値をリテラルにするか、RDFにするか等は、グラフ作成部12が保持する設定ファイルによって事前に定義されている。図19は、図16の社員ログテーブルから、ログリソースとログリソースに繋がる周辺情報を作成するために使用する、設定ファイルの例である。図19の設定ファイルを用いた、ログリソースの作成方法を説明する。まず、社員ログテーブルの「LogID」の値と「http://hogehoge.com/employee#」を組み合わせて、タイプが「emp:社員ログ」となるRDFリソース化し、これをログリソースとする。次に、図19の設定ファイルを用いた周辺情報の作成方法を説明する。まず、社員ログテーブルの「ID」の値を、「http://hogehoge.com/employee#」と組み合わせてRDFリソース化したものをサブジェクトとし、ログリソースをオブジェクトとして、プロパティ「emp: log」を経由してつなげる。また、社員ログテーブルの「氏名」の値は、値をそのままリテラル化したものをオブジェクトとし、ログリソースをサブジェクトとして、プロパティ「emp:氏名」を経由してつなげる。同様に、社員ログテーブルの他の値もRDFに変換する。

0042

具体例を挙げると、図18に示すRDFデータは、図6に例示する社員ログテーブルのID「1234111−2000−5−1」のレコードを変換してRDFデータにしたものである。また、図19に例示するデータは、図18に例示するRDFデータに変換する際に使用した設定ファイルの例であり、各属性に対応するプロパティ名などが定義されている。また、図20に例示するデータは、図18に例示するRDFデータを計算機処理する際のデータフォーマットの例である。

0043

続いて、グラフ作成部12は、ログ順序テーブルから、ログリソース間順序関係情報を作成する。具体的には、グラフ作成部12は、ログIDをRDFリソース化したものをサブジェクトに、前ログを示すプロパティを用意し、PrevLogIDをRDFリソース化したものをオブジェクトに変換する。なお、プロパティ名等は、設定ファイルによって事前に定義されている。図22は、図7のログ順序テーブルから、ログリソース間の順序関係情報を作成するために使用する、設定ファイルの例である。図22の設定ファイルを用いたログリソース間の順序関係情報の作成方法を説明する。まず、社員ログ順序テーブルの「LogID」の値を、「http://hogehoge.com/employee#」と組み合わせてRDFリソース化したものを、サブジェクトとする。次に、プロパティを「emp:prevLog」として、社員ログ順序テーブルの「PrevLogID」の値を、「http://hogehoge.com/employee#」と組み合わせてRDFリソース化したものを、オブジェクトとする。

0044

具体例を挙げると、図21に示すRDFデータは、図7に例示する社員ログ順序テーブルのレコードを変換してRDFデータにしたものである。また、図22に例示するデータは、図21に例示するRDFデータに変換する際に使用した設定ファイルの例であり、各属性に対応するプロパティ名などが定義されている。また、図23に例示するデータは、図21に例示するRDFデータを計算機処理する際のデータフォーマットの例である。

0045

上記の処理によってグラフ作成部12は、図24に例示するように、マスタデータDB20に記憶されたマスタデータからRDFデータを作成する。図24のRDFデータの例は、図2のマスタデータから作成されたグラフデータである。このように、データ検索装置10は、マスタデータのスキーマ構造を知らなくても、属性情報と属性値を取得できるように、マスタデータに記録された実体を表す実体リソースに対して、全ての実体リソースの属性情報と属性値をづくようにスキーマ変更を行う。

0046

また、データ検索装置10は、事前に複数の履歴情報を持つテーブルの履歴情報を精査し、全ての属性情報に対して変更が無い期間を抽出したのち、属性情報の変更が無い期間に対して履歴リソースを割り当て、実体リソースと履歴リソースの関係を定義し、属性情報と上記の属性情報の変更が無い期間の属性値のペアを、上記の履歴リソースと直接紐づくようにスキーマを変換する。また、同じ実体リソースに関係する履歴リソースを、履歴期間順にソートし、履歴の前後関係明記するスキーマに変換する。

0047

図1の説明に戻って、検索部13は、グラフ作成部12によって作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う。具体的には、検索部13は、アプリケーション30からクエリを受け付けると、受け付けたクエリを用いて、グラフDB15に対してデータ検索を行い、検索結果をアプリケーション30に返信する。

0048

ここで、図25および図26の例を用いて、検索処理について具体的に説明する。図25に示すように、検索部13は、検索クエリとして、氏名「鈴木太郎」の2002年8月1日時点の全属性情報を検索するクエリを受け付け、該クエリを用いて、グラフDB15に対してデータ検索を行い、鈴木太郎に関する全属性情報を取得する。例えば、図25の例では、鈴木太郎の属性情報として、所属「111」、職責「研究員」、有効期限「2002−6−1」〜「2003−3−31」、1つ前のログのログID「1234111−2000−5−1」を取得する。

0049

このように、ある時点の全属性情報を検索するクエリが容易に記述できる。つまり、オリジナルのマスタデータのスキーマ構造では、複雑なクエリになってしまうところが、簡単なクエリの記述で、どのような属性情報があるか分からなくとも、全ての属性情報を取得できる。

0050

また、図26に示すように、検索部13は、検索クエリとして、氏名「鈴木太郎」の属性情報の変更履歴を検索するクエリを受け付け、該クエリを用いて、グラフDB15に対してデータ検索を行い、鈴木太郎に関する属性情報の変更履歴を取得し、検索結果としてアプリケーション30に返信する。このように、全属性情報の変更履歴を、簡易なクエリで辿ることができる。つまり、オリジナルのマスタデータのスキーマ構造では、複雑なクエリになってしまうところが、簡単なクエリの記述で、どのような属性情報があるか分からなくとも、全属性情報の変更履歴を取得できる。

0051

このように、データ検索装置10は、ある時点における全属性情報の検索、及び全属性情報個々の変更履歴の検索を、情報のスキーマ構造を知らず、簡単なクエリにより実現可能とする。

0052

また、データ検索装置10は、マスタデータDB20に格納されたマスタデータをRDFデータに変換しているので、外部のRDFデータとの相互接続が容易となる。つまり、RDFデータは、全てのリソースにユニークなIDとなるURIが割り当てられるため、異種データ間での相互接続が容易となる。また、異種データを相互接続するため、近年RDF形式のデータが多数公開されている。異なるURIリソースが同一実体であることも、図27に示すように、「owl:sameAs」プロパティを用いることで表現できる。また、図27に示すように、RDF化することで、マスタデータと外部データとの接続ができ、マスタデータには存在しない情報を辿ることができるようになる。

0053

[データ検索装置による処理]
次に、図28および図29を用いて、第一の実施形態に係るデータ検索装置10による処理を説明する。図28および図29は、第一の実施形態に係るデータ検索装置の処理動作を示すフローチャートである。なお、図28は、テーブル作成部11によって実行される処理を示すフローチャートであり、図29は、グラフ作成部12によって実行される処理を示すフローチャートである。

0054

まず、図28を用いて、テーブル作成部11によって実行される処理について説明する。図28に示すように、テーブル作成部11は、変換するメインテーブルをマスタデータDB21から取得し(ステップS101)、メインテーブルに紐付く全ての履歴テーブル22を取得する(ステップS102)。例えば、テーブル作成部11は、図2に例示した「社員メインテーブル」が変換するメインテーブルとして指定された場合には、該メインテーブルに紐付く全履歴テーブルとして、図3および図4に例示した「部屋番号履歴テーブル」と「職責履歴テーブル」とをマスタデータDB20から取得する。

0055

そして、テーブル作成部11は、履歴テーブル22の中で、履歴情報の無い期間を精査し、履歴の無い期間をNULL値で埋める(ステップS103)。例えば、図3の部屋番号履歴テーブルの例では、「2000−4−1から2000−4−31までの期間」および「2002−6−1から2003−5−31までの期間」については、履歴情報が無い期間である。このような場合、テーブル作成部11は、履歴情報の無い期間に対しては、期間とID以外の属性情報にNULL値を入れて、図5に例示するように、履歴の無い期間を無くした部屋番号履歴テーブルを作成する。

0056

続いて、テーブル作成部11は、全履歴テーブルで、属性値が変化しない期間を取得し、ログテーブルを構築する(ステップS104)。具体的には、テーブル作成部11は、メインテーブル21と関連する属性テーブルに格納されている属性情報を精査し、全ての属性情報において変更しない期間を取得する。そして、テーブル作成部11は、「LogID」を付与して、IDおよび全属性値と属性値が変化しない期間をログテーブルに格納する。

0057

そして、テーブル作成部11は、ログテーブルからログ順序テーブルを構築する(ステップS105)。具体的には、テーブル作成部11は、ログテーブルの中で、同一IDを持つレコード間の順序関係を精査し、順序関係を記録するログ順序テーブルを作成する。このログ順序テーブルには、図7に例示するように、「LogID」と、LogIDの1つ前のログを示す「PrevLogID」、LogIDの次のログを示す「NextLogID」が格納される。

0058

続いて、テーブル作成部11は、ログテーブルからカレントログテーブルを構築する(ステップS106)。具体的には、テーブル作成部11は、社員ログテーブルの各IDに対して、end Dateの値が最も新しいレコード1つを抽出して、社員ログテーブルの当該抽出したレコードにおけるstart Date以外の値を社員カレントログテーブルに格納する。また、社員カレントログテーブルのstart Data値は、社員メインテーブルの同じIDのレコードのstart Data値を入れる。

0059

その後、テーブル作成部11は、全ての変換するメインテーブル21を処理したか判定する(ステップS107)。この結果、テーブル作成部11は、全ての変換するメインテーブル21を処理していない場合には(ステップS107否定)、ステップS101の処理に戻る。一方、テーブル作成部11は、全ての変換するメインテーブル21を処理した場合には(ステップS107肯定)、テーブル作成部11の処理を終了する。

0060

次に、図29を用いて、グラフ作成部12によって実行される処理について説明する。図29に示すように、グラフ作成部12は、カレントログテーブルから、カレントリソースに繋がる周辺情報を作成する(ステップS201)。具体的には、グラフ作成部12は、カレントリソースに繋がる周辺情報を作成する処理として、カレントログテーブルのレコードごとにRDFデータを変換する。例えば、グラフ作成部12は、IDをRDFリソースに変換し、これをサブジェクトに、ID以外のカレントログテーブルの属性をプロパティに、その属性値をオブジェクトに変換する。

0061

そして、グラフ作成部12は、ログテーブルから、ログリソースと、ログリソースに繋がる周辺情報を作成する(ステップS202)。具体的には、グラフ作成部12は、ログリソースと、ログリソースに繋がる周辺情報を作成する処理として、ログテーブルから、ログリソースの周辺情報を作成する。例えば、グラフ作成部12は、IDをリソースに変換してサブジェクトにし、LogIDから作成したログリソースをオブジェクトに、IDとログID間の関係性を示す名称をプロパティに変換する。また、グラフ作成部12は、ログIDをRDFリソースに変換し、これをサブジェクトに、ログIDとID以外のログテーブルの属性をプロパティに、その属性値をオブジェクトに変換する。

0062

続いて、グラフ作成部12は、ログ順序テーブルから、ログリソース間の順序関係情報を作成し(ステップS203)、グラフ作成部12の処理を終了する。具体的には、グラフ作成部12は、ログIDをRDFリソース化したものをサブジェクトに、前ログを示すプロパティを用意し、PrevLogIDをRDFリソース化したものをオブジェクトに変換する。

0063

[第一の実施形態の効果]
上述してきたように、データ検索装置10は、メインテーブル21のデータに関する属性情報の変更履歴と変更された各属性情報が有効であった期間である有効期間とを対応付けて記憶する複数の履歴テーブル22から、属性情報および変更履歴を取得し、有効期間が共通する属性情報同士を対応付けて記憶するテーブルを作成する。そして、データ検索装置10は、作成されたテーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成する。そして、データ検索装置10は、作成されたグラフデータに対して、検索クエリを用いてデータ検索を行う。これにより、変更履歴を個別管理する各属性情報から構成される情報の検索を容易にすることが可能である。このように、マスタデータとその属性値の変更履歴に関する情報をRDFデータの形式に変換してRDFグラフとしてモデル化して格納する仕組み、及びRDFグラフにモデル化されたマスタデータの変更履歴を検索する仕組みを提供することで、マスタデータの履歴情報の横断検索を容易化することが可能である。例えば、ある時点における全属性情報の検索、及び全属性情報個々の変更履歴の検索を、情報のスキーマ構造を知らず、簡単なクエリにより実現可能とする。

0064

また、第一の実施形態によれば、データ検索装置10は、履歴テーブル22から、属性情報および変更履歴を取得し、全ての属性情報について、有効期間が共通する属性情報同士を対応付け、有効期間が共通する属性情報の組に対して一意に識別できるログIDを付与したログテーブルを作成する。このようなログテーブルを用いて、全ての属性値の変更履歴に関する情報をRDFグラフデータとして作成することが可能である。

0065

また、第一の実施形態によれば、データ検索装置10は、履歴テーブル22から、属性情報および変更履歴を取得し、有効期間が共通する属性情報同士を対応付けて記憶するログテーブルを作成するとともに、該属性情報の組同士の順序関係を記憶するログ順序テーブルを作成する。このため、ログリソース間の順序関係をRDFグラフデータとして作成することが可能である。

0066

また、第一の実施形態によれば、データ検索装置10は、履歴テーブル22から、属性情報および変更履歴を取得し、有効期間が共通する属性情報同士を対応付けて記憶するログテーブルを作成するとともに、有効期間のうち最も新しい期間の属性情報を記憶するカレントログテーブルを作成する。このため、カレントログテーブルを用いて、最も新しい属性値の変更履歴に関する情報をRDFグラフデータとして作成することが可能である。

0067

また、第一の実施形態によれば、データ検索装置10は、作成されたログテーブル等を記憶する変換用DB14をさらに備える。そして、データ検索装置10は、変換用DB14によって記憶されたテーブルを読み出し、該テーブルを用いて、所定の期間における各属性情報同士の関係を表現するグラフデータを作成する。このため、データ検索装置10は、作成したテーブルを適切に記憶して、グラフデータを作成することが可能である。

0068

[変換用DB]
上記第一の実施形態では、変換用DB14は、テーブル作成部11によって作成されるログテーブル、ログ順序テーブルおよびカレントログテーブルを記憶し、記憶したログテーブル、ログ順序テーブルおよびカレントログテーブルが、グラフ作成部12によって読み出される場合を説明したが、これに限定されるものでなく、変換用DB14がなくともよい。この場合には、テーブル作成部11は、作成したログテーブル、ログ順序テーブルおよびカレントログテーブルを、グラフ作成部12に通知する。

0069

システム構成
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

0070

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

0071

プログラム
また、上記実施形態において説明したデータ検索装置10が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、第一の実施形態に係るデータ検索装置10が実行する処理をコンピュータが実行可能な言語で記述したデータ検索プログラムを作成することもできる。この場合、コンピュータがデータ検索プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるデータ検索プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されデータ検索プログラムをコンピュータに読み込ませて実行することにより上記第一の実施形態と同様の処理を実現してもよい。以下に、図1に示したデータ検索装置10と同様の機能を実現するデータ検索プログラムを実行するコンピュータの一例を説明する。

0072

図30は、データ検索プログラムを実行するコンピュータ1000を示す図である。図30に例示するように、コンピュータ1000は、例えば、メモリ1010と、CPU1020と、ハードディスクドライブインタフェース1030と、ディスクドライブインタフェース1040と、シリアルポートインタフェース1050と、ビデオアダプタ1060と、ネットワークインタフェース1070とを有し、これらの各部はバス1080によって接続される。

0073

メモリ1010は、図30に例示するように、ROM(Read Only Memory)1011及びRAM1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、図30に例示するように、ハードディスクドライブ1031に接続される。ディスクドライブインタフェース1040は、図30に例示するように、ディスクドライブ1041に接続される。例えば磁気ディスク光ディスク等の着脱可能な記憶媒体が、ディスクドライブ1041に挿入される。シリアルポートインタフェース1050は、図30に例示するように、例えばマウス1051、キーボード1052に接続される。ビデオアダプタ1060は、図30に例示するように、例えばディスプレイ1061に接続される。

0074

ここで、図30に例示するように、ハードディスクドライブ1031は、例えば、OS1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、上記のデータ検索プログラムは、コンピュータ1000によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ1031に記憶される。

0075

また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ1010やハードディスクドライブ1031に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1031に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出し、テーブル作成手順、グラフ作成手順検索手順を実行する。

0076

なお、データ検索プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1031に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してCPU1020によって読み出されてもよい。あるいは、データ検索プログラムに係るプログラムモジュール1093やプログラムデータ1094は、ネットワーク(LAN(Local Area Network)、WAN(Wide Area Network)等)を介して接続された他のコンピュータに記憶され、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。

0077

10データ検索装置
11テーブル作成部
12グラフ作成部
13検索部
14変換用DB
15 グラフDB
20マスタデータDB
21メインテーブル
22履歴テーブル
30アプリケーション
100 データ検索システム

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社ソケッツの「 検索装置および方法」が 公開されました。( 2019/09/19)

    【課題】同一の感性ワードで加重的に絞り込み検索を行えるようにする。【解決手段】同一の感性ワードで加重的に絞り込み検索を行う場合、類似・関連ワード抽出部319が、感性ワードに類似・関連する別のワードを検... 詳細

  • ヤフー株式会社の「 情報処理装置、情報処理方法、及び情報処理プログラム」が 公開されました。( 2019/09/12)

    【課題】ユーザの移動の妨害に応じた適切な対応を可能にする。【解決手段】本願に係る情報処理装置は、取得部と、決定部とを有する。取得部は、ユーザの位置情報と、ユーザが位置するエリアにおいて発生する事象のう... 詳細

  • ヤフー株式会社の「 情報処理装置、情報処理方法、及び情報処理プログラム」が 公開されました。( 2019/09/12)

    【課題】類似のコンテンツを適切に抽出する。【解決手段】本願に係る情報処理装置は、取得部と、検索部とを有する。取得部は、複数のコンテンツの各々に対応する複数のノードが、複数のコンテンツの類似性に応じて連... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ