JP2022089629A - データ処理システム及びキャッシュ更新制御方法 - Google Patents

Abstract

【課題】計画された制約下でのみデータベースのキャッシュを更新可能にし、データベースへのアクセスによる負荷を低減する。【解決手段】データ処理システム１において、データ処理装置は、データベース２１０のデータをキャッシュする分析箇所キャッシュ１５０と、開発者３によって使用され、データ分析のための分析処理を開発するデータ処理開発モジュール１３０と、開発者３によって使用され、分析処理の実行によってデータ分析を行うデータ処理モジュール１４０と、分析箇所キャッシュにおけるデータベースからのキャッシュ更新に関して、ＤＢ管理者から入力される更新制約を設定するキャッシュ管理モジュール１１０と、更新制約に基づいてキャッシュ更新の可否を判断する更新判断モジュール１２０と、を備える。キャッシュ更新が要求されたとき、更新判断モジュール１は、上記判断でキャッシュ更新を可とした場合に、要求されたキャッシュ更新を実行する。【選択図】図１

Description

本発明は、データ処理システム及びキャッシュ更新制御方法に関し、データベース分析に利用されるキャッシュの更新を管理するデータ処理システム及びキャッシュ更新制御方法に適用して好適なものである。

近年、製造業の工場では、基幹系データベースに保存されたセンサデータやログデータ等のデータを分析することによって新しい価値を生み出す、データ分析利活用が進んでいる。このデータ分析においては、データアナリストが、基幹系データベースのデータを参照し分析を行うことにより、生産効率化や可視化が図られる。

一般的なデータ分析の実装では、まず分析対象のデータの取捨選択を行い、データ分析を効率化する開発フェーズを経て、定期的なデータベースの参照及び分析によるデータ分析を行う運用フェーズへ移行する。このうち開発フェーズでは、トライアンドエラーによるデータベース上の各種データ精査をするため、データベースへの頻繁なアクセスによる負荷が発生する。一方で、基幹系データベースの主の役割は稼動ログデータの保存であるため、稼働ログデータの保存処理に支障をきたすような不用意なデータアクセスは低減されることが望ましい。

なお、従来のデータ分析の開発フェーズでは、ウォーターフォール型の管理監視のもと、専門のデータアナリストによるデータベースへのアクセスがされていたため、アクセスは計画化され不用意な負荷は存在しなかった。しかし近年、アナリティクスの民主化の流れによって、多くの専門外のユーザがデータ分析を気軽に扱える環境が構築された結果、管理監視されないデータ分析によって、不用意なデータベースへのアクセス負荷が多く発生している。

ところで、一般的にデータベースへの負荷を低減するためには、キャッシュが有効であることが知られている。これは、データ分析で必要なデータをキャッシュとして一時保存し、分析時にキャッシュを参照することで分析の度データベースへアクセスすることを防ぐものである。

そして、キャッシュデータの更新に関して、例えば特許文献１には、マスターのデータベースへのアクセスを低減する技術が開示されている。具体的には、特許文献１では、「更新期間が経過したキャッシュデータに対する送信要求があった場合、当該キャッシュデータに関連付けられた更新フラグの状態を判定する」こと、及び「更新フラグがオフである場合、当該更新フラグをオンにして、更新期間が経過したキャッシュデータに対応する更新データを取得する」ことが開示されている。

特開２０１２－１４６０７６号公報

ところで、基幹系データベースにおいては、本来は更新すべき古いキャッシュデータであっても、更新によって基幹系データベースに負荷をかけたくないタイミングが存在する。また、データ分析の開発フェーズでは、分析途中で異なるデータのキャッシュに変更されることは、正しい分析結果を得られなくなることに繋がるため、避けなければならない。

しかしながら、上述した特許文献１に記載された手法では、キャッシュデータに更新フラグを付与することによって、期間が経過したキャッシュが参照された際は、そのタイミングでデータベースにアクセスが発生し、キャッシュが更新されてしまう。すなわち、特許文献１に記載された手法では、キャッシュの更新は時間経過に依存した自動的な処理となり、更新タイミングの制御及び自発的なキャッシュの更新ができない、という点で、上述した基幹系データベースにおけるキャッシュ管理に関する要求を満足できないという課題があった。

本発明は以上の点を考慮してなされたもので、計画された制約下でのみデータベースのキャッシュを更新可能にし、データベースへのアクセスによる負荷を低減することが可能なデータ処理システム及びキャッシュ更新制御方法を提案しようとするものである。

かかる課題を解決するため本発明においては、データベースに接続し、前記データベースのデータ分析を行うデータ処理システムであって、前記データ分析の開発フェーズにおいて参照される前記データベースのデータをキャッシュする分析箇所キャッシュと、前記データ分析の開発者によって使用され、前記データ分析のための分析処理を開発するデータ処理開発モジュールと、前記開発者によって使用され、前記データ処理開発モジュールで開発された前記分析処理の実行によってデータ分析を行うデータ処理モジュールと、前記分析箇所キャッシュにおける前記データベースからのキャッシュ更新に関して、前記データベースの管理者から入力される更新制約を設定するキャッシュ管理モジュールと、前記キャッシュ管理モジュールによって設定された前記更新制約に基づいて前記分析箇所キャッシュのキャッシュ更新の可否を判断する更新判断モジュールと、を備え、前記データ処理開発モジュールから前記キャッシュ更新が要求されたとき、前記更新判断モジュールは、前記判断でキャッシュ更新を可とした場合に、前記要求されたキャッシュ更新を実行するデータ処理システムが提供される。

また、かかる課題を解決するため本発明においては、データベースのデータ分析を行うデータ処理システムによるキャッシュ更新制御方法であって、前記データ処理システムは、前記データ分析の開発フェーズにおいて参照される前記データベースのデータをキャッシュする分析箇所キャッシュと、前記データ分析の開発者によって使用され、前記データ分析のための分析処理を開発するデータ処理開発モジュールと、前記開発者によって使用され、前記データ処理開発モジュールで開発された前記分析処理の実行によってデータ分析を行うデータ処理モジュールと、前記分析箇所キャッシュにおける前記データベースからのキャッシュ更新に関して、前記データベースの管理者から入力される更新制約を設定するキャッシュ管理モジュールと、前記キャッシュ管理モジュールによって設定された前記更新制約に基づいて前記分析箇所キャッシュのキャッシュ更新の可否を判断する更新判断モジュールと、を有し、前記データ処理開発モジュールから前記キャッシュ更新が要求されたとき、前記更新判断モジュールは、前記判断でキャッシュ更新を可とした場合に、前記要求されたキャッシュ更新を実行するキャッシュ更新制御方法が提供される。

本発明によれば、計画された制約下でのみデータベースのキャッシュを更新可能にし、データベースへのアクセスによる負荷を低減することができる。

本発明の第１の実施形態に係るデータ処理システム１の構成例を示すブロック図である。 データ処理システム１とユーザとの関係性を説明するための図である。 キャッシュ更新制約登録処理の手順例を示すシーケンス図である。 任意キャッシュ更新処理の手順例を示すシーケンス図である。 ＤＢ情報入力機能１１２による処理の処理手順例を示すフローチャートである。 ＤＢ情報１０１の一例を示す図である。 更新制約入力機能１１１による処理の処理手順例を示すフローチャートである。 キャッシュ更新制約１０２の一例を示す図である。 更新判断モジュール１２０による処理の処理手順例を示すフローチャートである。 更新判定を行うコードの一例である。 接続クエリのコード例である。 更新ログ１６３の一例を示す図である。 分析フロー設計機能１３１による処理の処理手順例を示すフローチャートである。 ＤＢ情報閲覧機能１３２による処理の処理手順例を示すフローチャートである。 描画部１７０による処理の処理手順例を示すフローチャート（その１）である。 描画部１７０による処理の処理手順例を示すフローチャート（その２）である。 登録ＤＢ一覧画面の一例を示す図である。 ＤＢ情報入力画面の一例を示す図である。 キャッシュ更新制約入力画面の一例を示す図である。 分析フロー設計画面の一例を示す図である。 ＤＢ指定画面の一例を示す図である。 ＤＢデータ表示画面の一例を示す図である。 本発明の第２の実施形態に係るデータ処理システム４の構成例を示すブロック図である。 キャッシュ更新制約入力画面の一例を示す図である。 キャッシュ更新制約１０２の一例を示す図である。 適時キャッシュ更新処理の手順例を示すシーケンス図である。 ＤＢ情報閲覧機能１３２による処理の処理手順例を示すフローチャートである。 更新判断モジュール１２０による処理の処理手順例を示すフローチャートである。 管理描画部５１０による処理の処理手順例を示すフローチャートである。 分析描画部６２０による処理の処理手順例を示すフローチャートである。 第１または第２の実施形態に係るデータ処理システム１，４を構成する各装置（コンピュータ装置１０）のハードウェア構成例を示すブロック図である。 キャッシュデータ入替処理を説明するためのイメージ図である。

以下、図面を参照して、本発明の実施形態を詳述する。

（１）第１の実施形態
（１－１）構成
図１は、本発明の第１の実施形態に係るデータ処理システム１の構成例を示すブロック図である。

図１に示したように、本実施形態に係るデータ処理システム１は、データ分析の開発者（後述する図２の開発者３）が使用する１以上のデータ処理装置１００が、データベース管理者（後述する図２のＤＢ管理者２）が管理するデータベース装置２００に接続されて構成される。なお、データ処理システム１とＤＢ管理者２及び開発者３との詳しい関係については、図２を参照して後述する。

また、図１において、ＤＢ情報１０１は、ＤＢ管理者２がデータ処理装置１００に対して付与するデータベース２１０の情報であり、キャッシュ更新制約１０２は、キャッシュ更新の際に課す制約をＤＢ管理者２が記述したものである。ＤＢ情報１０１及びキャッシュ更新制約１０２は、ＤＢ管理者２によってデータ処理装置１００に入力される。

データ処理装置１００は、キャッシュ管理モジュール１１０、更新判断モジュール１２０、データ処理開発モジュール１３０、データ処理モジュール１４０、分析箇所キャッシュ１５０、データ記憶部１６０、及び描画部１７０を備える。

キャッシュ管理モジュール１１０は、ＤＢ管理者２からデータ処理装置１００に対する情報の入力を受け付ける機能として、キャッシュを更新する際の制約であるキャッシュ更新制約１０２を受け付ける更新制約入力機能１１１と、データベース２１０に接続するためのＤＢ情報１０１を受け付けるＤＢ情報入力機能１１２と、を有する。

更新判断モジュール１２０は、キャッシュ管理モジュール１１０が受け付けたキャッシュ更新制約１０２をまとめたキャッシュ更新制約情報１６２を参照し、分析箇所キャッシュ１５０への更新要求があった際に、更新が可能であるか判断する機能を有する。

データ処理開発モジュール１３０は、分析フロー設計機能１３１及びＤＢ情報閲覧機能１３２を有する。分析フロー設計機能１３１は、データ分析を行う際のデータベース参照メソッドや、データの結合、分離、分析処理等のメソッド、分析結果を出力するメソッド等を持ち、開発者３はこれらのメソッドを使用することでデータ分析が可能となる。ＤＢ情報閲覧機能１３２は、データベース２１０への接続を含むメソッドが分析フロー設計機能１３１で呼び出された場合に、データベース２１０の情報（ＤＢ情報１０１）を表示し、データベースクエリの記入欄を提供する機能を持つ。

データ処理モジュール１４０は、開発者３がデータ処理開発モジュール１３０で開発した分析処理を実際に実行する機能を有する。

分析箇所キャッシュ１５０は、データ分析において必要となるデータを格納するキャッシュである。一例として、リレーショナルデータベースでは、スキーマ名やテーブル名、カラム名等のメタデータ１５１や、テーブルの中身のカラムデータ１５２を保存する。

データ記憶部１６０は、登録ＤＢ情報１６１、キャッシュ更新制約情報１６２、及び更新ログ１６３を格納する。登録ＤＢ情報１６１は、キャッシュ管理モジュール１１０のＤＢ情報入力機能１１２によって受け付けられたＤＢ情報１０１をまとめた情報であり、キャッシュ更新制約情報１６２は、キャッシュ管理モジュール１１０の更新制約入力機能１１１によって受け付けられたキャッシュ更新制約１０２をまとめた情報である。また、更新ログ１６３は、キャッシュの更新処理のログを保存する情報である。

描画部１７０は、ユーザ操作を受け付け、キャッシュ管理モジュール１１０及びデータ処理開発モジュール１３０の機能や情報を表示する。また、描画部１７０による表示画面には、後述する更新ボタン１７１を表示することができる。更新ボタン１７１は、必要に応じてユーザが押下操作を行うことによって、分析箇所キャッシュ１５０の対象キャッシュが更新される。

データベース装置２００は、データベース２１０及びデータベースマネジメントシステム２２０を保有する。データベース２１０には、センサデータ（後述する図２のセンサデータ２０１）やログデータ（後述する図２のログデータ２０２）等の工場稼働データが、メタデータ２１１及びカラムデータ２１２として保存される。データベース２１０へのアクセス等は、データベースマネジメントシステム２２０によって管理される。

本実施形態では、上記のように構成されたデータ処理システム１を用いて、ＤＢ管理者２がデータ処理装置１００の分析箇所キャッシュ１５０に対してキャッシュ更新の制約を課し、開発者３が上記制約のもとで更新ボタン１７１を操作することにより、上記制約下で任意に分析箇所キャッシュ１５０を更新できることを説明する。但し、本発明は、このような実施形態に限定されるものではなく、また、本発明の思想ないし趣旨から逸脱しない範囲で、その具体的な構成を変更し得る。

本実施形態において、図１に示したデータ処理システム１は、例えば基幹系データベースの管理者（または管理部門）とデータ分析の開発者とを、ユーザとして想定することができる。

図２は、データ処理システム１とユーザとの関係性を説明するための図である。本実施形態に係るデータ処理システム１のユーザとしては、データベースの管理者（ＤＢ管理者２）と、データ分析の開発者（開発者３）とが想定される。なお、図２では、図１に示したデータ処理システム１の構成の一部について図示を省略している。

図２に示すように、ＤＢ管理者２は、センサデータ２０１やログデータ２０２を格納するデータベース装置２００内のデータベース２１０を管理する。開発者３は、データ処理装置１００内のデータ処理開発モジュール１３０を、描画部１７０を通じて操作し、データ処理フローを設計する。開発者３によって設計された処理フローは、データ処理モジュール１４０によって実際に処理される。また、データ処理装置１００とデータベース装置２００の間では、分析箇所キャッシュ１５０の更新や、データ参照のアクセスが発生する。ここで、開発者３がデータ処理装置１００上でデータベース２１０にアクセスするためには、ＤＢ管理者２から、データ処理装置１００へのアクセス権限の付与及びＤＢ情報１０１（具体的には、ホスト、ポート番号、ユーザ、パスワード等）の提供が必要であり、開発者３は、ＤＢ管理者２による許可なしにデータベース２１０にアクセスして参照を行う行為はできないとする。

（１－２）全体処理
以下では、データ処理システム１で実行される全体処理として、キャッシュ更新制約登録処理及び任意キャッシュ更新処理を説明する。

図３は、キャッシュ更新制約登録処理の手順例を示すシーケンス図である。図３に示す一連の処理は、開発者３がデータ処理装置１００上でデータベース２１０にアクセスできるようにするために、ＤＢ管理者２からデータ処理装置１００に対して、データベース２１０のＤＢ情報１０１及びキャッシュ更新制約１０２を付与する際に、データ処理システム１で実行される処理である。なお、図３に示す一連の処理は、開発者３によるデータ分析よりも前に実行されるとする。

また、図３のシーケンス図では、同一の機能部またはモジュール等によって連続的に実行される一連の処理に対して、それぞれステップ番号を付しており、これは後述する他のシーケンス図でも同様である。

図３に示したステップＳ１０１は、描画部１７０による処理である。ステップＳ１０１において、描画部１７０はまず、ＤＢ管理者２からキャッシュ管理モジュール１１０へのアクセスが行われるとき、ＤＢ情報入力機能１１２にアクセス通知を行う。そして描画部１７０は、登録済みのデータベースに関するデータ（少なくとも登録ＤＢ情報１６１及びキャッシュ更新制約情報１６２）をＤＢ情報入力機能１１２から受信し、当該データを表示する。その後、描画部１７０は、ＤＢ管理者２から新規登録するデータベースの情報（新規登録のＤＢ情報１０１）が入力された場合、当該情報をＤＢ情報入力機能１１２に渡す。その後、描画部１７０は、ＤＢ情報入力機能１１２から、先に渡した新規登録のＤＢ情報１０１が追加された登録ＤＢ情報１６１を受信し、当該データを表示する。次いで、ＤＢ管理者２からキャッシュ更新制約１０２を登録する入力がなされた場合には、描画部１７０は、当該キャッシュ更新制約１０２を更新制約入力機能１１１に渡す。その後、更新制約入力機能１１１から、更新されたキャッシュ更新制約情報１６２を受信し、これを表示する。

図３に示したステップＳ１０２は、ＤＢ情報入力機能１１２による処理である。ステップＳ１０２において、ＤＢ情報入力機能１１２は、描画部１７０からアクセス通知を受け取ったとき、データ記憶部１６０の登録ＤＢ情報１６１から現在のデータベース２１０の情報を取得し、データ記憶部１６０のキャッシュ更新制約情報１６２から現在登録されているキャッシュ更新制約を取得し、データ記憶部１６０の更新ログ１６３からキャッシュ更新のログを取得し、取得したこれらの情報に基づいて登録済みのデータベース２１０の情報を描画部１７０に送信する。また、描画部１７０から新規登録するＤＢ情報１０１を受信すると、ＤＢ情報入力機能１１２は、当該ＤＢ情報１０１を更新制約入力機能１１１に渡し、登録ＤＢ情報１６１に保存する。さらにＤＢ情報入力機能１１２は、更新された登録済みのデータベース２１０の情報を描画部１７０に送信する。

図３に示したステップＳ１０３は、更新制約入力機能１１１による処理である。ステップＳ１０３において、更新制約入力機能１１１は、ＤＢ情報入力機能１１２から新規登録するＤＢ情報１０１を受け取った場合、描画部１７０からのキャッシュ更新制約１０２の送信を待つ。そしてキャッシュ更新制約１０２が入力されると、更新制約入力機能１１１は、更新判断モジュール１２０に、ＤＢ情報１０１、キャッシュ更新制約１０２、及び登録時フラグを渡す。登録時フラグは、当該送信データが登録時に送信されていることを示すフラグである。そして、更新制約入力機能１１１は、入力されたキャッシュ更新制約１０２をキャッシュ更新制約情報１６２に保存し、更新されたキャッシュ更新制約情報１６２を描画部１７０に送信する。

図３に示したステップＳ１０４は、更新判断モジュール１２０による処理である。ステップＳ１０４において、更新判断モジュール１２０は、更新制約入力機能１１１から受信したＤＢ情報１０１、キャッシュ更新制約１０２、及び登録フラグに基づいて、データベース２１０へのアクセスが可能でキャッシュ更新が可能であるか否かを判定する。受信データに登録フラグが含まれ（更新判断モジュール１２０が有する更新フラグがＯＮ）、キャッシュ更新が可能と判定した場合、更新判断モジュール１２０は、データベース２１０に対してメタデータ取得クエリを送信し、データベース２１０から受け取ったメタデータ２１１を、分析箇所キャッシュ１５０のキャッシュに保存する（メタデータ１５１）。

以上のように図３の各処理が行われることにより、ＤＢ管理者２から入力されたデータベース２１０に接続するためのＤＢ情報１０１及びキャッシュ更新制約１０２がデータ処理装置１００に付与されるため、以降は、開発者３がデータ処理装置１００上でデータベース２１０にアクセスできるようになる。

図４は、任意キャッシュ更新処理の手順例を示すシーケンス図である。図４に示す一連の処理は、開発者３が分析フロー設計機能１３１の使用中に分析箇所キャッシュ１５０のキャッシュ更新を行う際に、データ処理システム１で実行される処理である。

図４に示したステップＳ２０１は、描画部１７０による処理である。ステップＳ２０１において、描画部１７０は、開発者３から分析フロー設計機能１３１へのアクセスが行われるとき、分析フロー設計機能１３１にアクセス通知を行う。そして描画部１７０は、分析フロー設計機能１３１から設計中の分析フローに関する情報を受信し、これを表示する。そして、開発者３からフロー設計作成を入力された場合には、描画部１７０は、分析フロー設計機能１３１へフロー設計作成を依頼する。また、開発者３からデータベースの指定（入力ＤＢ指定）が入力された場合には、描画部１７０は、分析フロー設計機能１３１へ入力ＤＢ指定を送信する。また、ＤＢ情報閲覧機能１３２からキャッシュ更新ボタン表示の指示を受信した場合には、描画部１７０は、開発者３に対して更新ボタン１７１を表示する。そして、開発者３によって更新ボタン１７１の押下操作が行われると、描画部１７０は、更新ボタン１７１が押下操作されたことをＤＢ情報閲覧機能１３２に渡す。その後、描画部１７０は、ＤＢ情報閲覧機能１３２から、キャッシュ更新された後のデータベース２１０の情報を受信し、これを表示する。

図４に示したステップＳ２０２は、分析フロー設計機能１３１による処理であり、描画部１７０からデータ処理開発モジュール１３０へのアクセスが発生したときに処理が開始される。このとき、分析フロー設計機能１３１は、既に登録されているデータベース２１０の接続情報を登録ＤＢ情報１６１から取得し、描画部１７０に送信する。ステップＳ２０２では続いて、描画部１７０から入力ＤＢ指定を受信したとき、分析フロー設計機能１３１は、ＤＢ情報閲覧機能１３２に、入力されたデータベースを送信する。入力ＤＢ指定の際、開発者３は、入力ＤＢとして具体的には、データベースのホスト名、データベース名、スキーマ名、テーブル名、ユーザ、及びパスワードを記載する。

図４に示したステップＳ２０３は、ＤＢ情報閲覧機能１３２による処理である。ステップＳ２０３において、ＤＢ情報閲覧機能１３２は、分析フロー設計機能１３１から入力ＤＢに関する接続情報を受け取った場合に、キャッシュ更新制約情報１６２に入力ＤＢを送信し、対象のデータベース２１０に対して設定されているキャッシュ更新制約を取得する。また、ＤＢ情報閲覧機能１３２は、分析箇所キャッシュ１５０において対象のデータベース２１０のキャッシュが存在するか否かを、分析箇所キャッシュ１５０に入力ＤＢを送信することによって確認する。その後、ＤＢ情報閲覧機能１３２は、入力ＤＢとキャッシュ更新制約とを更新判断モジュール１２０に送信し、開発者３がキャッシュの更新を可能であるか否かの結果を取得する。ここで、キャッシュの更新が可能であった場合には、ＤＢ情報閲覧機能１３２は、描画部１７０にキャッシュ更新ボタン（更新ボタン１７１）の表示を通知する。また、描画部１７０から更新ボタン１７１が押下された旨の通知を受け取った場合には、ＤＢ情報閲覧機能１３２は、更新判断モジュール１２０にキャッシュ更新クエリを発行する。そして、キャッシュ更新が行われて更新判断モジュール１２０から更新後のデータベース２１０のデータを受信したときは、ＤＢ情報閲覧機能１３２は、受信したデータを描画部１７０に送信する。

図４に示したステップＳ２０４は、更新判断モジュール１２０による処理であり、開発者３から入力ＤＢ指定が行われた場合に実行される処理である。ステップＳ２０４において、更新判断モジュール１２０は、ＤＢ情報閲覧機能１３２から入力ＤＢ及びキャッシュ更新制約を受信した場合に、当該入力ＤＢが示すデータベース２１０に対してキャッシュの更新が可能であるかを、当該キャッシュ更新制約に基づいて判断し、その判断結果（更新判断結果）をＤＢ情報閲覧機能１３２に送信する。その後、更新判断モジュール１２０は、更新判断結果に拘わらず、更新ログ１６３に上記更新の結果を書き込む。なお、ステップ２０４の時点では、更新判断モジュール１２０は、更新制約入力機能１１１から登録時フラグを受信していないため（図３のステップＳ１０３参照）、データベース２１０へのメタデータ２１１の取得（図３のステップＳ１０４参照）は行わない。

図４に示したステップＳ２０５は、更新判断モジュール１２０による処理であり、開発者３によって更新ボタン１７１の押下操作が行われた場合に実行される処理である。ステップＳ２０５において、更新判断モジュール１２０は、ＤＢ情報閲覧機能１３２からキャッシュ更新クエリを受信した場合に、入力ＤＢが示すデータベース２１０に対して当該クエリを発行し、その結果を受信して分析箇所キャッシュ１５０の更新を行う。その後、更新判断モジュール１２０は、更新結果を更新ログ１６３に書き込む。

（１－３）個別処理
以下では、図３及び図４を参照しながら前述したデータ処理システム１による全体処理において各機能やモジュール等が実行する個別処理について、それぞれ詳述する。

（１－３－１）ＤＢ情報入力機能１１２
図５は、ＤＢ情報入力機能１１２による処理の処理手順例を示すフローチャートである。図５に示す処理は、図３のステップＳ１０２の処理に相当する。

図５によればまず、ＤＢ情報入力機能１１２は、キャッシュ管理モジュール１１０へのアクセスがあったことを描画部１７０から受け取る（ステップＳ３０１）。

次に、ＤＢ情報入力機能１１２は、データ記憶部１６０に格納されている登録済みの登録ＤＢ情報１６１、キャッシュ更新制約情報１６２、及び更新ログ１６３を取得し、描画部１７０に送信する（ステップＳ３０２）。

次に、ＤＢ情報入力機能１１２は、描画部１７０から、ＤＢ管理者２が入力した新規登録するＤＢ情報１０１を受信し（ステップＳ３０３）、受信したＤＢ情報１０１を更新制約入力機能１１１に送信する（ステップＳ３０４）。

そして、ＤＢ情報入力機能１１２は、登録ＤＢ情報１６１にステップＳ３０３で受信したＤＢ情報１０１を格納する（ステップＳ３０５）。

図６は、ＤＢ情報１０１の一例を示す図である。図６に示したＤＢ情報３００は、登録ＤＢ情報１６１に格納される際のＤＢ情報１０１のコードの一例を示したものであり、ＪＳＯＮ形式によってデータベースの情報が記述されている。図６に示したＤＢ情報３００の記述内容は、後述する図１８のＤＢ情報入力画面３６０における入力内容に対応している。このようなＤＢ情報が登録ＤＢ情報１６１に保存されることによって、開発者３は当該データベースにアクセスすることが可能となる。なお、ＤＢ情報１０１の記述形式はＪＳＯＮ形式に限定されるものではなく、例えばデータベース形式等であってもよい。

そして最後に、ＤＢ情報入力機能１１２は、新たに登録されたＤＢ情報１０１を含む登録済みのデータベース２１０の情報（すなわち、ステップＳ３０５による更新後の登録ＤＢ情報１６１）を描画部１７０に送信し（ステップＳ３０６）、一連の処理を終了する。

（１－３－２）更新制約入力機能１１１
図７は、更新制約入力機能１１１による処理の処理手順例を示すフローチャートである。図７に示す処理は、図３のステップＳ１０３の処理に相当する。

図７によればまず、更新制約入力機能１１１は、ＤＢ管理者２が入力したＤＢ情報１０１をＤＢ情報入力機能１１２から受信する（ステップＳ４０１）。ステップＳ４０１の後、更新制約入力機能１１１は、ステップＳ４０１で受信したＤＢ情報１０１のデータベースに対するキャッシュ更新制約１０２が描画部１７０上で入力されるまで待機する（ステップＳ４０２）。

そして更新制約入力機能１１１は、入力されたキャッシュ更新制約１０２を描画部１７０から受信すると（ステップＳ４０３）、ステップＳ４０１で受信したＤＢ情報１０１とステップＳ４０３で受信したキャッシュ更新制約１０２とを更新判断モジュール１２０に送信する（ステップＳ４０４）。この際、更新制約入力機能１１１は登録時フラグを添えて送信する。

次に、更新制約入力機能１１１は、キャッシュ更新制約１０２をキャッシュ更新制約情報１６２に保存する（ステップＳ４０５）。

図８は、キャッシュ更新制約１０２の一例を示す図である。図８に示したキャッシュ更新制約３１０は、キャッシュ更新制約情報１６２に格納される際のキャッシュ更新制約１０２のコードの一例を示したものであり、ＪＳＯＮ形式によってキャッシュ更新の制約が記述されている。図８に示したキャッシュ更新制約３１０の記述内容は、後述する図１９に示すキャッシュ更新制約入力画面３７０における入力内容に対応している。具体的には、キャッシュ更新制約３１０には、制約対象となるスキーマが「ｐｕｂｌｉｃ」であり（コード３１１）、制約の内容として、「８時から１２時は更新禁止であること」（コード３１２）、及び「１２時から１７時は１時間に１回の更新が可能であること」（コード３１３）が記述されている。なお、キャッシュ更新制約１０２の記述形式はＪＳＯＮ形式に限定されるものではなく、例えばデータベース形式等であってもよい。

そして最後に、更新制約入力機能１１１は、新たに入力されたキャッシュ更新制約１０２を含むキャッシュ更新制約情報１６２（すなわち、ステップＳ４０５で更新したキャッシュ更新制約情報１６２）を描画部１７０に送信し（ステップＳ４０６）、一連の処理を終了する。

（１－３－３）更新判断モジュール１２０
図９は、更新判断モジュール１２０による処理の処理手順例を示すフローチャートである。図９に示す処理は、図３のステップＳ１０４、及び図４のステップＳ２０４，Ｓ２０５の処理に相当する。更新判断モジュール１２０は、更新制約入力機能１１１から何らかの入力がなされるまでは待機状態であり、更新制約入力機能１１１からの入力を契機として、図９の処理を開始する。

図９によればまず、更新判断モジュール１２０は、ＤＢ情報１０１及びキャッシュ更新制約１０２が入力されたか否かを判定する（ステップＳ５０１）。当該入力があった場合は（ステップＳ５０１のＹＥＳ）、ステップＳ５０２に移行し、他の入力であった場合は（ステップＳ５０１のＮＯ）、後述するステップＳ５１０に移行する。

ステップＳ５０２において、更新判断モジュール１２０は、ステップＳ５０１で確認されたＤＢ情報１０１及びキャッシュ更新制約１０２に加えて、更新フラグがＯＮになっているか否かを判定する。更新フラグは、更新制約入力機能１１１から登録時フラグを受信したときにＯＮとなるフラグである。したがって、ステップＳ５０２の処理は、更新制約入力機能１１１から登録時フラグが入力されたか否かを判定する処理とも言える。ステップＳ５０２において更新フラグがＯＮである場合は（ステップＳ５０２のＹＥＳ）、ＤＢ管理者２がＤＢ情報１０１及びキャッシュ更新制約１０２を入力した状況の処理とみなし、ステップＳ５０３に移行する。一方、ステップＳ５０２において更新フラグがＯＮでない（ＯＦＦである）場合は（ステップＳ５０２のＮＯ）、開発者３がデータベース２１０を指定した際に当該データベース２１０に対応する分析箇所キャッシュ１５０の更新判断をする状況の処理とみなし、ステップＳ５０６に移行する。

まず、ステップＳ５０２からステップＳ５０３に移行する場合の処理について説明する。ステップＳ５０３～Ｓ５０５の処理は、図３のステップＳ１０４の処理に相当する。

ステップＳ５０３において、更新判断モジュール１２０は、入力されたキャッシュ更新制約１０２に基づいて、分析箇所キャッシュ１５０の更新が可能であるか否かを判定する。分析箇所キャッシュ１５０を更新可能である場合は（ステップＳ５０３のＹＥＳ）、ステップＳ５０４に移行し、分析箇所キャッシュ１５０を更新できない場合は（ステップＳ５０３のＮＯ）、更新判断モジュール１２０は処理を終了する。

図１０は、更新判定を行うコードの一例である。図１０に示した更新判断モジュール３２０では、時間による制約に対して更新の可否を判定している。具体的には、コード３２１において、現在の日時と制約とを照らし合わせ、適合していた場合はデータベースに対してクエリを送信する処理を記述している。また、コード３２２では、現在日時が制約日時の間にあり、かつ制約のスキーマと入力されたデータベースのスキーマとが正しく一致した場合に「１」を返す処理を記述している。

分析箇所キャッシュ１５０が更新可能であるとき、ステップＳ５０４において、更新判断モジュール１２０は、メタデータ取得クエリをデータベース２１０に対して送信する。このメタデータ取得処理は、開発者３が分析フロー設計機能１３１において指定できるデータベースのスキーマやテーブル名を取得するために行う。また、メタデータはデータ分析において参照される頻度が高く、事前にキャッシュに格納した方が、開発時の更新頻度を低減できるためでもある。

図１１は、接続クエリのコード例である。図１１に示した接続クエリ３３０は、メタデータ取得クエリを送信するために更新判断モジュール１２０において実行されるクエリであって、まず、送信先のデータベースを規定し（データベースへの疎通を確認し）、その後のコード３３１において、クエリを送信する処理を記述している。

そして、ステップＳ５０４の終了後、更新判断モジュール１２０は、ステップＳ５０４でデータベース２１０から受信した結果（メタデータ２１１）を分析箇所キャッシュ１５０にメタデータ１５１として保存し（ステップＳ５０５）、処理を終了する。

次に、ステップＳ５０２からステップＳ５０６に移行する場合の処理について説明する。ステップＳ５０６～Ｓ５０９の処理は、図４のステップＳ２０４の処理に相当する。

ステップＳ５０６において、更新判断モジュール１２０は、ステップＳ５０３と同様に、入力されたキャッシュ更新制約１０２に基づいて、分析箇所キャッシュ１５０の更新が可能であるか否かを判定する。

ステップＳ５０６において分析箇所キャッシュ１５０を更新可能である場合は（ステップＳ５０６のＹＥＳ）、更新判断モジュール１２０は、更新可能である旨をＤＢ情報閲覧機能１３２に送信し（ステップＳ５０７）、更新ログ１６３に更新結果を書き込み（ステップＳ５０９）、処理を終了する。一方、ステップＳ５０６において分析箇所キャッシュ１５０を更新できない場合は（ステップＳ５０６のＮＯ）、更新判断モジュール１２０は、更新不可能である旨をＤＢ情報閲覧機能１３２に送信し（ステップＳ５０８）、更新ログ１６３に更新結果を書き込み（ステップＳ５０９）、処理を終了する。

次に、ステップＳ５０１からステップＳ５１０に移行する場合の処理について説明する。ステップＳ５１０～Ｓ５１３，Ｓ５０９の処理は、図４のステップＳ２０５の処理に相当する。

ステップＳ５１０において、更新判断モジュール１２０は、更新制約入力機能１１１からキャッシュ更新クエリが入力されたか否かを判定する。入力がキャッシュ更新クエリであった場合（ステップＳ５１０のＹＥＳ）、開発者３によって更新ボタン１７１が押されたものとみなし、分析箇所キャッシュ１５０の更新を実行するためにステップＳ５１１に移行する。入力がキャッシュ更新クエリ以外であった場合には（ステップＳ５１０のＮＯ）、更新判断モジュール１２０は処理を終了する。

ステップＳ５１１において、更新判断モジュール１２０は、データベース２１０に対して、入力されたキャッシュ更新クエリを送信し、その結果を受信する。そして、更新判断モジュール１２０は、ステップＳ５１１で受信した結果によって分析箇所キャッシュ１５０を更新する（ステップＳ５１２）。

その後、更新判断モジュール１２０は、ステップＳ５１２における更新結果（キャッシュ更新が完了した旨）をＤＢ情報閲覧機能１３２に送信し（ステップＳ５１３）、更新ログ１６３に更新結果を書き込み（ステップＳ５０９）、処理を終了する。

図１２は、更新ログ１６３の一例を示す図である。図１２に示した更新ログ３４０は、更新ごとにログを記録した更新ログ１６３の具体例であり、更新の成否、更新が実行された日時情報、及び更新内容が記載されている。具体的には例えば、ログ３４１の場合、２０２０年９月１５日の１４時１５分に、データベース名「Ｆａｃｔｏｒｙ－Ｃ」のスキーマ「ｐｕｂｌｉｃ」へのＳＥＬＥＣＴクエリが実行され、キャッシュが更新されたことが示されている。

（１－３－４）分析フロー設計機能１３１
図１３は、分析フロー設計機能１３１による処理の処理手順例を示すフローチャートである。図１３に示す処理は、図４のステップＳ２０２の処理に相当し、描画部１７０からデータ処理開発モジュール１３０へのアクセスが発生したときに処理が開始される。

図１３によればまず、分析フロー設計機能１３１は、データ処理開発モジュール１３０へのアクセスがあったことを描画部１７０から受信する（ステップＳ６０１）。これに対し分析フロー設計機能１３１は、分析フロー設計機能の表示を描画部１７０に指示する（ステップＳ６０２）。

次に、分析フロー設計機能１３１は、描画部１７０上でフロー設計機能における作成操作が行われたことを描画部１７０から受信すると（ステップＳ６０３）、登録ＤＢ情報１６１から、ＤＢ管理者２によって登録された全てのデータベース２１０の情報を取得し（ステップＳ６０４）、描画部１７０からの次の入力まで待機する（ステップＳ６０５）。

その後、描画部１７０上で入力ＤＢが指定されると（入力ＤＢ指定）、分析フロー設計機能１３１は、描画部１７０からデータベース、スキーマ、テーブル情報等を受信する（ステップＳ６０６）。この場合、分析フロー設計機能１３１は、ステップＳ６０６で受信した情報をＤＢ情報閲覧機能１３２に送信し（ステップＳ６０７）、その後は再びステップＳ６０５の待機状態に戻る。

（１－３－５）ＤＢ情報閲覧機能１３２
図１４は、ＤＢ情報閲覧機能１３２による処理の処理手順例を示すフローチャートである。図１４に示す処理は、図４のステップＳ２０３の処理に相当する。ＤＢ情報閲覧機能１３２は、描画部１７０の更新ボタン１７１（より具体的には、後述する図２１に示されるＤＢ指定画面３９０におけるスキーマ更新ボタン３９５及びテーブル更新ボタン３９６）の表示／非表示の管理、及び分析箇所キャッシュ１５０内のデータ（例えばメタデータ１５１やカラムデータ１５２）を管理する機能を有する。

図１４によれば、通常、ＤＢ情報閲覧機能１３２は待機状態となっている（ステップＳ７０１）。そして、開発者３から描画部１７０上でデータベース、スキーマ、及びテーブル情報が入力されると、図１３のステップＳ６０７で説明したように、これらの入力情報は分析フロー設計機能１３１によって転送され、ＤＢ情報閲覧機能１３２が受信する（ステップＳ７０２）。

次に、ＤＢ情報閲覧機能１３２は、ステップＳ７０２で受信した入力情報に基づいて、対象のデータベース２１０に対して設定されているキャッシュ更新制約を、キャッシュ更新制約情報１６２から取得する（ステップＳ７０３）。また、ＤＢ情報閲覧機能１３２は、ステップＳ７０２で受信した入力情報に基づいて、分析箇所キャッシュ１５０に対象のデータベース２１０のキャッシュが存在するか否かを確認する（ステップＳ７０４）。

次に、ＤＢ情報閲覧機能１３２は、ステップＳ７０２で受信した入力情報（ＤＢ情報）とステップＳ７０３で取得したキャッシュ更新制約を、更新判断モジュール１２０に送信する（ステップＳ７０５）。これらを受信した更新判断モジュール１２０は、図９のステップＳ５０６～Ｓ５０８で説明したように、分析箇所キャッシュ１５０が更新可能であるか否かを判定し、その結果をＤＢ情報閲覧機能１３２に送信する。

次に、ＤＢ情報閲覧機能１３２は、更新判断モジュール１２０から受信した情報（分析箇所キャッシュ１５０の更新判定結果）が、更新可能であるか否かを判定する（ステップＳ７０６）。更新可能である場合は（ステップＳ７０６のＹＥＳ）、ステップＳ７０７に移行し、更新不可能である場合は（ステップＳ７０６のＮＯ）、後述するステップＳ７１０に移行する。

ステップＳ７０７においてＤＢ情報閲覧機能１３２は、分析箇所キャッシュ１５０が更新可能であることから、更新ボタン１７１を表示する通知を描画部１７０に送信する。なお、更新ボタン１７１の表示／非表示という表現に関して、本説明では、開発者３からの操作を受付可能な表示態様を「表示」と称し、開発者３からの操作を受け付けない表示態様を「非表示」と称する。したがって、例えば後述する図２１に示すテーブル更新ボタン３９６のように、開発者３から操作不能な形態で表示された場合も「非表示」に相当する。

その後、ＤＢ情報閲覧機能１３２は、開発者３による更新ボタン１７１の押下操作（キャッシュ更新ボタン押下）が描画部１７０から通知されたか否かを判定する（ステップＳ７０８）。ステップＳ７０８において、当該通知を受信した場合は（ステップＳ７０８のＹＥＳ）、ステップＳ７０９に移行し、当該通知を受信しなかった場合は（ステップＳ７０９のＮＯ）、ステップＳ７１０に移行する。

ステップＳ７０９において、ＤＢ情報閲覧機能１３２は、更新判断モジュール１２０にキャッシュ更新クエリを発行する。そして、更新判断モジュール１２０からキャッシュ更新の完了通知を受信した段階で、ステップＳ７１０に移行する。当該完了通知の際は、キャッシュ更新後のデータベース２１０のデータも受信する。

ステップＳ７１０では、ＤＢ情報閲覧機能１３２は、分析箇所キャッシュ１５０内の指定されたテーブルデータを表示するために、描画部１７０にデータベース２１０のデータを送信する。その後はステップＳ７０１に戻って待機する。

（１－３－６）描画部１７０
図１５及び図１６は、描画部１７０による処理の処理手順例を示すフローチャート（その１、その２）である。図１５に示す処理は、主に図３のステップＳ１０１の処理に相当し、図１６に示す処理は、図４のステップＳ２０１の処理に相当する。

図１５によればまず、描画部１７０は、ＤＢ管理者２または開発者３からアクセスがあった場合に、そのアクセス先に応じて、キャッシュ管理モジュール１１０の表示を行うか、データ処理開発モジュール１３０の表示を行うかを切り分ける（ステップＳ８０１）。アクセス先がキャッシュ管理モジュール１１０の場合はステップＳ８０２に移行し、アクセス先がデータ処理開発モジュール１３０の場合は、図１６のステップＳ８１０に移行する。

まず、ステップＳ８０１からステップＳ８０２に移行した場合の処理を説明する。前述したように、ステップＳ８０２～Ｓ８０９の処理は、キャッシュ更新制約登録処理における描画部１７０による処理（図３のステップＳ１０１）の処理に相当する。

アクセス先がキャッシュ管理モジュール１１０であった場合、描画部１７０は、既に登録されている登録ＤＢ情報１６１を表示するために、ＤＢ情報入力機能１１２に登録ＤＢ情報１６１の取得を依頼する（ステップＳ８０２）。

そして描画部１７０は、現在登録済みのデータベース２１０に関するデータ（少なくとも登録ＤＢ情報１６１及びキャッシュ更新制約情報１６２）をＤＢ情報入力機能１１２から受信し、受信したデータを登録ＤＢ一覧画面に表示する（ステップＳ８０３）。

図１７は、登録ＤＢ一覧画面の一例を示す図である。図１７に示した登録ＤＢ一覧画面３５０は、登録済みのそれぞれのデータベース２１０に関するデータを表示する画面であって、登録ＤＢ情報１６１及びキャッシュ更新制約情報１６２の他、更新ログ１６３による情報も表示している。具体的には、図１７の登録ＤＢ一覧画面３５０では、ホスト名を示すホスト３５１、ポート番号を示すポート３５２、データベース名を示すＤＢ名３５３、ユーザ名を示すユーザ３５４、パスワードを示すパス３５５、キャッシュ更新制約を示す制約３５６、及び更新ログを示すログ３５７を、登録済みのデータベースごとに表示している。

次に、描画部１７０は、ＤＢ管理者２がＤＢ情報１０１またはキャッシュ更新制約１０２を入力するための入力画面（ＤＢ情報入力画面、キャッシュ更新制約入力画面）を表示し、入力されるまで待機する（ステップＳ８０４）。

図１８は、ＤＢ情報入力画面の一例を示す図である。図１８に示したＤＢ情報入力画面３６０は、登録するデータベース２１０に接続するために必要となるＤＢ情報１０１を入力するための画面であり、具体的には、ホスト名の入力欄３６１、ポート番号の入力欄３６２、データベース名の入力欄３６３、ユーザ名の入力欄３６４、及びパスワードの入力欄３６５を有する。なお、ＤＢ情報入力画面に設けられる入力欄の種類は、図１８の例示に限定されず、データベースの種類に応じて適宜必要な情報をデータベース情報として記載する必要がある。そして、ＯＫボタン３６６の押下操作が行われたときに、入力が確定される。

図１９は、キャッシュ更新制約入力画面の一例を示す図である。図１９に示したキャッシュ更新制約入力画面３７０は、登録するデータベース２１０に課するキャッシュ更新制約１０２を入力するための画面であり、具体的には、入力欄３７１に、制約が必要な対象のスキーマまたはテーブルを入力し、入力欄３７３に、詳細な制約の内容を入力する。図１９の場合は、時間別に細かな更新制限ができる形態で入力欄３７３が実装されている。また、制約の登録が必要ない場合には、即時にキャッシュの更新が可能であるため、チェック欄３７２をチェックすればよい。そして、ＯＫボタン３７４の押下操作が行われたときに、入力が確定される。

更新制約の具体的な内容としては、例えば図１９の場合、０時から８時までの間は、制限なく直ちにキャッシュの更新が可能であり、８時から１２時までの間は、キャッシュの更新ができない制約があり、１２時から１７時までの間は、キャッシュの更新は１時間あたり１回までに制限され、１７時から２４時までの間は、メタデータの更新のみが可能であることを制約として課している（入力欄３７３参照）。なお、キャッシュ更新制約入力画面に設けられる入力欄の形式は、図１９の形式に限定されず、上記した時間別の制約の他にも、更新頻度や、更新に掛かるデータサイズ等によって制限できるようにしてもよい。

次に、描画部１７０は、ＤＢ情報入力画面またはキャッシュ更新制約入力画面の何れにおいて入力が確定されたか（ＤＢ情報１０１またはキャッシュ更新制約１０２の何れが入力されたか）を判定し（ステップＳ８０５）、ＤＢ情報１０１が入力された場合はステップＳ８０６に移行し、キャッシュ更新制約１０２が入力された場合はステップＳ８０８に移行する。

ＤＢ情報１０１が入力された場合、描画部１７０は、入力されたＤＢ情報１０１をＤＢ情報入力機能１１２に送信する（ステップＳ８０６）。ＤＢ情報入力機能１１２では、ステップＳ８０６で送信されたＤＢ情報１０１を登録ＤＢ情報１６１に格納する処理が行われる。そして描画部１７０は、ＤＢ情報入力機能１１２から、入力されたＤＢ情報１０１が反映された登録ＤＢ情報１６１を受信し（ステップＳ８０７）、再びステップＳ８０３の処理に戻る。なお、ステップＳ８０７で受信した情報は、ステップＳ８０３に移行した際に、登録ＤＢ一覧画面の表示内容に反映される。

一方、キャッシュ更新制約１０２が入力された場合、描画部１７０は、入力されたキャッシュ更新制約１０２を更新制約入力機能１１１に送信する（ステップＳ８０８）。更新制約入力機能１１１では、ステップＳ８０８で送信されたキャッシュ更新制約１０２をキャッシュ更新制約情報１６２に格納する処理が行われる。そして描画部１７０は、更新制約入力機能１１１から、入力されたキャッシュ更新制約１０２が反映されたキャッシュ更新制約情報１６２を受信し（ステップＳ８０９）、再びステップＳ８０３の処理に戻る。なお、ステップＳ８０９で受信した情報は、ステップＳ８０３に移行した際に、登録ＤＢ一覧画面の表示内容に反映される。

次に、ステップＳ８０１からステップＳ８１０に移行した場合の処理を説明する。前述したように、ステップＳ８１０～Ｓ８２１の処理は、任意キャッシュ更新処理における描画部１７０による処理（図４のステップＳ２０１）の処理に相当する。

アクセス先がデータ処理開発モジュール１３０であった場合、描画部１７０は、開発者３が現在設計中の分析フローの情報を分析フロー設計機能１３１に受け取りにいく（ステップＳ８１０）。具体的には、描画部１７０は、分析フロー設計機能１３１にアクセス通知を行い、その応答として分析フローの情報を受信する。

そして、描画部１７０は、ステップＳ８１０で分析フロー設計機能１３１から受信した情報を分析フロー設計画面に表示する（ステップＳ８１１）。

図２０は、分析フロー設計画面の一例を示す図である。図２０に示した分析フロー設計画面３８０では、各手順が１つのノードとして表示され、ノードを矢印で繋ぐことによって、処理の順序を設計できる画面を表示している。例えば図２０に例示した処理手順は、テーブル入力ノード３８１で指定したデータベースのテーブルに対して、結合ノード３８２によって結合処理が実行され、その後ＣＳＶ出力ノード３８３で指定する出力箇所へＣＳＶ出力を行うものである。また、分析フロー設計画面３８０において、ボタン３８４は新規に分析フローを作成するためのボタンであり、ボタン３８５は表示中の分析フローを削除するためのボタンである。なお、分析フロー設計画面の表示形態は、図２０の例示に限定されず、各データ分析処理を手順を含めて設計できる機能を有する場合は、分析フロー設計機能１３１に該当する。

次に、描画部１７０は、開発者３からデータベースの指定（設定）を入力可能な画面（ＤＢ指定画面）を表示し、開発者３からの入力、またはＤＢ情報閲覧機能１３２からのキャッシュ更新ボタンの表示通知を受けるまで待機する（ステップＳ８１２）。

図２１は、ＤＢ指定画面の一例を示す図である。図２０の分析フロー設計画面３８０において開発者３がテーブル入力ノード３８１を配置したときに、図２１に示すようなＤＢ指定画面３９０が表示される。図２１に示したＤＢ指定画面３９０では、データベースの指定（設定）を行うことができる。具体的には、選択欄３９１では、接続先のデータベースを選択することができ、入力欄３９２では、データ取得のためのクエリを指定でき、選択欄３９３では、対象のスキーマを選択することができ、選択欄３９４では、対象のテーブルを選択することができる。また、スキーマ更新ボタン３９５及びテーブル更新ボタン３９６は、分析箇所キャッシュ１５０のキャッシュを更新可能な場合に表示される更新ボタン１７１がスキーマ別及びテーブル別に表示されたものである。

図２１の例示においては、スキーマ更新ボタン３９５が操作可能に表示されているため、対象データベースのスキーマを更新可能である。一方、テーブル更新ボタン３９６は操作不可能な表示（広義には非表示）のため、対象データベースのテーブルは更新することができない。そして、図２１のＤＢ指定画面３９０において、接続ＤＢ（選択欄３９１）、スキーマ（選択欄３９３）、及びテーブル（選択欄３９４）が指定されることを、後述するステップＳ８１３におけるデータベース指定操作とする。

ステップＳ８１２の待機状態において開発者３からの入力、またはＤＢ情報閲覧機能１３２からのキャッシュ更新ボタンの表示通知を受けると、描画部１７０はどのような入力であるかを判定し、その内容に応じて移行先を振り分ける（ステップＳ８１３）。具体的には、開発者３からフロー設計作成操作（分析フロー設計画面３８０におけるボタン３８４の操作）があった場合には、ステップＳ８１４に移行し、データベース指定操作（ＤＢ指定画面３９０における上述した操作）があった場合には、ステップＳ８１５に移行し、キャッシュの更新ボタン１７１の押下操作（ＤＢ指定画面３９０におけるスキーマ更新ボタン３９５またはテーブル更新ボタン３９６の操作）が行われた場合には、ステップＳ８１８に移行する。また、ＤＢ情報閲覧機能１３２から更新ボタン１７１の表示通知が入力された場合には、ステップＳ８１６に移行する。なお、フロー設計作成操作及びデータベース指定操作は、描画部１７０によって表示された画面上のボタンまたは入力欄等をユーザが操作することによって入力される。

ステップＳ８１４に移行した場合、描画部１７０は、分析フロー設計機能１３１にフロー設計の作成を通知（依頼）し、その後、ステップＳ８１２に戻る。

ステップＳ８１５に移行した場合、描画部１７０は、指定されたデータベース名を分析フロー設計機能１３１に送信し、その後、ステップＳ８１２に戻る。

ステップＳ８１６に移行した場合、描画部１７０は、更新可能な対象キャッシュの更新ボタン１７１（スキーマ更新ボタン３９５，テーブル更新ボタン３９６）の表示通知をＤＢ情報閲覧機能１３２から受信する。なお、更新ボタン１７１としてスキーマ更新ボタン３９５及びテーブル更新ボタン３９６が設けられる場合、各更新ボタンの対象となるキャッシュは、データベース２１０のそれぞれのメタデータ２１１及びカラムデータ２１２であり、データ別にキャッシュの更新ボタン１７１を表示することができる。

次いで、描画部１７０は、ステップＳ８１６で受信した表示通知に応じて、例えば図２１に例示したスキーマ更新ボタン３９５及びテーブル更新ボタン３９６のように、接続画面上で更新ボタン１７１を表示し（ステップＳ８１７）、その後、ステップＳ８１２に戻る。

ステップＳ８１８に移行した場合、描画部１７０は、開発者３から更新ボタン１７１が押下操作されたことを検出する。次に、描画部１７０は、ＤＢ情報閲覧機能１３２に、更新ボタン１７１が押下された旨を通知する（ステップＳ８１９）。このとき、当該通知には、対象のキャッシュを示す情報が含まれる。図４、図９、及び図１３で説明したように、更新ボタン１７１が押下された通知を受け取ったＤＢ情報閲覧機能１３２は、更新判断モジュール１２０にキャッシュ更新クエリを送信して、分析箇所キャッシュ１５０の対象のキャッシュを更新させる。

次いで、描画部１７０は、ＤＢ情報閲覧機能１３２から、更新後のデータベース２１０のデータまたはメタデータを受信する（ステップＳ８２０）。そして、描画部１７０は、ステップＳ８２０で受信したデータに基づいて、更新後のデータベースのデータまたはメタデータをＤＢデータ表示画面に表示し（ステップＳ８２１）、その後、ステップＳ８１２に戻る。

図２２は、ＤＢデータ表示画面の一例を示す図である。例えば、図２２のＤＢデータ表示画面４００では、テーブル４０１によって、データベース、スキーマ、及びテーブル内のデータを表形式で列挙されている。ＤＢデータ表示画面４００の表示は、開発者３がデータ分析を行う際にキャッシュの内部データを容易に確認できるようにするための補助的な役割を持つ。

以上のように、本実施形態に係るデータ処理システム１は、開発者３がデータ分析を行うデータ処理装置１００に対して、キャッシュの更新を制約するキャッシュ更新制約をＤＢ管理者２から付与できる機能を有する。また、本実施形態に係るデータ処理システム１は、データ分析の開発フェーズにおいて開発者３がデータ処理装置１００におけるキャッシュの更新を自発的に実行可能な機能を有し、当該機能が実行された際は、ＤＢ管理者２から付与されたキャッシュ更新制約に基づく更新可否の判定が行われ、更新が可能な場合に限り（すなわち、キャッシュ更新制約の制約下で）キャッシュ更新が実行される。

このようなデータ処理システム１によれば、キャッシュの更新はＤＢ管理者２が計画した制約下でのみ実行され、データ分析の開発フェーズにおいて開発者３は、上記制約下の任意のタイミングでキャッシュ更新を行うことが可能となる。その結果、キャッシュ更新によるデータベース２１０へのアクセスは、データ分析者（開発者３）が必要とし、かつデータベース管理者（ＤＢ管理者２）が許可する範囲内でのみ発生することになるため、データベース２１０に対するアクセス頻度を低減させ、当該アクセスによる負荷を低減することができる。

また、ユーザ視点で見れば、本実施形態に係るデータ処理システム１では、データ分析の開発フェーズで使用される分析箇所キャッシュ１５０のキャッシュ更新に対して、ＤＢ管理者２がキャッシュ更新制約を課することができる機能が実装されるとともに、開発者３は、キャッシュ更新を自発的に実行可能な機能（更新ボタン１７１）が実装される。そして開発者３がキャッシュ更新の実行を要求した際は、キャッシュ更新制約に基づく更新判断のもとで、更新が可能な場合に限りキャッシュ更新がなされる。すなわち、キャッシュ更新制約を満たす条件下であれば、開発者３は任意のタイミングでキャッシュ更新を行うことができる。

（２）第２の実施形態
上述した第１の実施形態では、図２に示したように、データ処理システム１が１つのデータ処理装置１００を備える構成を中心に説明した。しかし、実際のデータ分析の開発フェーズでは、複数の開発者３が同時にデータ分析を行うことが一般的であり、このような需要に応えるためには、複数のデータ処理装置１００を備える構成とすればよいが、その場合、データ処理装置１００ごとに分析箇所キャッシュ１５０が必要になってしまう。しかし、それぞれのデータ処理装置１００が分析箇所キャッシュ１５０を持つ構成だと、キャッシュの更新のためにデータベース２１０へのアクセスが増加するおそれがあり、また、キャッシュ更新のタイミングが異なるとデータ分析の対象データの整合性がとれなくなるといった問題も想定される。

そこで、以下に説明する第２の実施形態に係るデータ処理システム４では、第１の実施形態に係るデータ処理システム１におけるキャッシュ管理部分（主に、分析箇所キャッシュ１５０やキャッシュ管理モジュール１１０）を、データ分析部分（主に、データ処理開発モジュール１３０やデータ処理モジュール１４０）から分離させ、独立したキャッシュＤＢ管理装置５００として実装する。このように構成されたデータ処理システム４では、分析箇所キャッシュ１５０をデータ分析側の装置（データ分析装置６００）に持つことなく、キャッシュＤＢ管理装置５００側で１つに統一することが可能となる。

なお、第２の実施形態の説明では、第１の実施形態における構成や処理等と共通する点については、同一の符号を用いてその説明を省略する。

（２－１）構成
図２３は、本発明の第２の実施形態に係るデータ処理システム４の構成例を示すブロック図である。図２３に示したように、データ処理システム４は、第１の実施形態に係るデータ処理システム１（図１や図２参照）におけるデータ処理装置１００の代わりに、キャッシュＤＢ管理装置５００及びデータ分析装置６００を備える構成となっている。データ分析装置６００は、データ分析の開発者３が使用するデータ分析側の複数の装置であり、キャッシュＤＢ管理装置５００に接続される。キャッシュＤＢ管理装置５００は、１つの装置で複数のデータ分析装置６００に対するキャッシュ（分析箇所キャッシュ１５０）を提供する、ＤＢ管理者２によって管理されるキャッシュ管理側の装置であり、各データ分析装置６００及びデータベース２１０に接続される。なお、第２の実施形態において好適なデータベース２１０は、例えば基幹系データベースである。

また、図２３に示す構成例では、第２の実施形態を説明する際に重要ではない構成については、図示を省略しているが、データ処理システム４は適宜、第１の実施形態で説明したデータ処理システム１の構成を備えていてもよい。具体的には例えば、データ処理システム４は、キャッシュ管理モジュール１１０内に更新制約入力機能１１１及びＤＢ情報入力機能１１２を有すると考えてよく、また、データベース２１０はデータベース装置２００内に配置される等と考えてもよい。

キャッシュＤＢ管理装置５００は、分析箇所キャッシュ１５０、更新判断モジュール１２０、登録ＤＢ情報１６１、キャッシュ更新制約情報１６２、更新ログ１６３、キャッシュ管理モジュール１１０、要求回数情報５０１、及び管理描画部５１０を備える。このうち、第１の実施形態に係るデータ処理システム１のデータ処理装置１００にはない新たな構成は、要求回数情報５０１及び管理描画部５１０である。

管理描画部５１０は、第１の実施形態における描画部１７０が有する機能のうち、キャッシュＤＢ管理装置５００に関する描画（キャッシュ管理側の描画）のみを行う。

要求回数情報５０１は、データベース２１０に保持される各データについて、全てのデータ分析装置６００からキャッシュ（分析箇所キャッシュ１５０）の更新が要求された回数を記録するデータである。詳細は図２６や図２８の説明において後述するが、本実施形態では、各開発者３がデータ分析装置６００上でデータベース２１０の指定を行った行為をデータ更新要求と見なし、ＤＢ管理者２によって制約された一定回数以上のデータ更新要求が行われた場合に（要求回数情報５０１に保持された要求回数が制約以上となった場合に）、キャッシュ更新処理が実行される。

本実施形態において、ＤＢ管理者２は、キャッシュＤＢ管理装置５００に対して、ＤＢ情報１０１（図２３では図示省略）及びキャッシュ更新制約１０２を登録することができる。そして、前述したようにキャッシュＤＢ管理装置５００は、データベース２１０に接続されている。

データ分析装置６００は、データ処理開発モジュール１３０、データ処理モジュール６１０、及び分析描画部６２０を備える。

データ処理モジュール６１０は、データ処理開発モジュール１３０の分析フロー設計機能１３１によって設計された分析フローを用いてデータ分析用の処理を実行する分析処理実行機能６１１を有する。

分析描画部６２０は、第１の実施形態における描画部１７０が有する機能のうち、データ分析装置６００に関する描画（データ分析側の描画）のみを行う。

以上のように構成されたデータ処理システム４において、複数の開発者３は、それぞれ別のデータ分析装置６００を使用して、データ分析を実行することができる。この際、全てのデータ分析装置６００が参照する分析箇所キャッシュは、キャッシュＤＢ管理装置５００の分析箇所キャッシュ１５０であり、当該キャッシュの更新判断は、キャッシュ更新制約情報１６２に依存する。

（２－２）全体処理
第２の実施形態に係るデータ処理システム４で実行される全体処理について、第１の実施形態における全体処理との相違点を中心に説明する。第２の実施形態では、全体処理として、キャッシュ更新制約処理及び適時キャッシュ更新処理を実行することができる。

第２の実施形態におけるキャッシュ更新制約登録処理は、開発者３がデータ分析装置６００上でデータベース２１０にアクセスできるようにするために、ＤＢ管理者２がキャッシュＤＢ管理装置５００に対して、データベース２１０のＤＢ情報１０１及びキャッシュ更新制約１０２を付与する際に、データ処理システム４で実行される処理である。第２の実施形態におけるキャッシュ更新制約登録処理の処理手順は、描画部１７０が管理描画部５１０に置き換えられる以外は、第１の実施形態において図３に示した処理と同様と考えてよい。但し、第２の実施形態におけるキャッシュ更新制約登録処理では、キャッシュ更新制約１０２に要求回数に関する制約を追加することができる。

図２４は、キャッシュ更新制約入力画面の一例を示す図である。図２４に示したキャッシュ更新制約入力画面７００は、第２の実施形態において、登録するデータベース２１０に課するキャッシュ更新制約１０２を入力するための画面であり、図１９に例示した第１の実施形態におけるキャッシュ更新制約入力画面３７０と比較すると、要求回数制限の入力欄７０１が追加されている。ＤＢ管理者２は、入力欄７０１に所望の規定回数を入力してＯＫボタン３７４の押下操作を行うことにより、開発者３からのデータ更新要求（言い換えればデータ分析装置６００からのキャッシュの更新要求）が何回行われたときにキャッシュ更新処理を実行するかを規定することができる。

図２５は、キャッシュ更新制約１０２の一例を示す図である。図２５に示したキャッシュ更新制約７１０は、第２の実施形態においてキャッシュ更新制約情報１６２に格納される際のキャッシュ更新制約１０２のコードの一例を示したものであり、図８に例示した第１の実施形態におけるキャッシュ更新制約３１０と同様、ＪＳＯＮ形式によってキャッシュ更新の制約が記述されている。キャッシュ更新制約７１０の具体的なコードを確認すると、コード３１１，３１２，３１３は図８のキャッシュ更新制約３１０と同様であり説明を省略する。さらに、図２５のキャッシュ更新制約７１０では、更新要求回数に関するコード７１１において、「１０回」の更新要求があった場合にキャッシュ更新処理を実行することが制約として記述されている。

第２の実施形態における適時キャッシュ更新処理は、データ分析装置６００上で分析フロー設計機能１３１の使用中に、開発者３が入力データベース（データベース２１０）を指定した場合に、データ処理システム４で実行される処理であって、入力ＤＢの指定によるデータ更新要求によって分析箇所キャッシュ１５０のキャッシュ更新が要求される。

図２６は、適時キャッシュ更新処理の手順例を示すシーケンス図である。前述したように第２の実施形態においてはキャッシュ更新制約１０２で更新要求回数が既定されるため、第１の実施の形態における任意キャッシュ更新処理（図４参照）とは異なり、図２６に示す適時キャッシュ更新処理では、更新要求回数も含めたキャッシュ更新制約の制約下でのみ、分析箇所キャッシュ１５０のキャッシュ更新が実行可能とされる。

図４との相違点として、図２６では、処理主体として、描画部１７０が分析描画部６２０に置き換えられ、参照先として要求回数情報５０１が追加されている。また、図２６では、各処理主体による処理として、分析描画部６２０がステップＳ９０１の処理を実行し、分析フロー設計機能１３１がステップＳ９０２の処理を実行し、ＤＢ情報閲覧機能１３２がステップＳ９０３の処理を実行し、更新判断モジュール１２０がステップＳ９０４の処理を実行する。但し、ステップＳ９０２の処理は、図４のステップＳ２０２の処理と同様であり、詳細な説明は省略する。

図２６に示したステップＳ９０１は、分析描画部６２０による処理である。図４の描画部１７０によるステップＳ２０１の処理との差異として、ステップＳ９０１において分析描画部６２０は、ＤＢ情報閲覧機能１３２から更新ボタン表示の情報を受信せず、更新ボタンの表示を行わない。このため、分析描画部６２０は、開発者３によって更新ボタン１７１が押下操作されたことを検出することがなく、キャッシュ更新対象をＤＢ情報閲覧機能１３２に渡すこともない。その他の処理は、図４のステップＳ２０１の処理と同様である。

図２６に示したステップＳ９０２は、分析フロー設計機能１３１による処理である。ステップＳ９０２の処理は、図４のステップＳ２０２の処理と同様であり、説明を省略する。

図２６に示したステップＳ９０３は、ＤＢ情報閲覧機能１３２による処理である。ステップＳ９０３において、ＤＢ情報閲覧機能１３２は、分析フロー設計機能１３１から入力ＤＢに関する接続情報を受け取った場合に、キャッシュ更新制約情報１６２に入力ＤＢを送信し、対象のデータベース２１０に対して設定されているキャッシュ更新制約を取得する。このとき取得するキャッシュ更新制約には、更新要求回数も含まれる。その後、ＤＢ情報閲覧機能１３２は、入力ＤＢを分析箇所キャッシュ１５０に送信することによって、分析箇所キャッシュ１５０において対象のデータベース２１０のキャッシュが存在するか否かを確認し、更新判断モジュール１２０へ入力ＤＢのＤＢ情報及びキャッシュ更新制約を送信する。その後、ＤＢ情報閲覧機能１３２は、キャッシュ更新が行われて更新判断モジュール１２０から更新後のデータベース２１０のデータを受信したときは、受信したデータを分析描画部６２０に送信する。

図２６に示したステップＳ９０４は、更新判断モジュール１２０による処理である。ステップＳ９０４において、更新判断モジュール１２０は、ＤＢ情報閲覧機能１３２からデータベースの情報（入力ＤＢ及びキャッシュ更新制約）を受信した場合に、入力ＤＢが示すデータベース２１０に対してキャッシュの更新が可能であるかを、キャッシュ更新制約に基づいて判断し、その判断結果（更新判断結果）を更新ログ１６３に書込み、要求回数情報５０１に保持する現在の要求回数を「１」増加させる。その後、更新判断モジュール１２０は、要求回数情報５０１から、増加後の要求回数を取得し、キャッシュ更新制約に基づいて、更新が可能で、かつ要求回数が規定された要求回数制限以上であった場合に、対象のデータベース２１０の取得及び分析箇所キャッシュ１５０の更新を行う。そして、更新判断モジュール１２０は、これらの更新結果を更新ログ１６３に書き込み、更新後のキャッシュデータをＤＢ情報閲覧機能１３２に送信する。

（２－３）個別処理
以下では、第２の実施形態における全体処理において各機能やモジュール等が実行する個別処理について、第１の実施形態とは異なる処理を中心に詳述する。

図２７は、ＤＢ情報閲覧機能１３２による処理の処理手順例を示すフローチャートである。図２７に示す処理は、図２６のステップＳ９０３の処理に相当する。第１の実施形態におけるＤＢ情報閲覧機能１３２による処理（図１４参照）と比較して説明すると、図２７におけるステップＳ１００１～Ｓ１００５の処理は、図１４に示したステップＳ７０１～Ｓ７０５の処理とそれぞれ同様である。そして、図２７では、図１４のステップＳ７０６～Ｓ７０９の処理に相当する処理がなく、ステップＳ１００５の後は、ステップＳ１００６（図１４のステップＳ７１０相当）の処理が行われる。

図２８は、更新判断モジュール１２０による処理の処理手順例を示すフローチャートである。図２８に示す処理は、図３のステップＳ１０４及び図２６のステップＳ９０４の処理に相当する。第１の実施形態における更新判断モジュール１２０による処理（図９参照）と比較して説明すると、図２８においては、ステップＳ１１０１（図９のステップＳ５０１と同様）でＹＥＳと判定された場合、その後のステップＳ１１０２～Ｓ１１０９の処理までは、図９のステップＳ５０２～Ｓ５０９の処理と同様であり、その後にステップＳ１１１０～Ｓ１１１５の処理が新規追加されている。また、図２８において、ステップＳ１１０１（図９のステップＳ５０１と同様）でＮＯと判定された場合は、キャッシュ更新クエリの判断を行う図９のステップＳ５１０以降の処理は実行されず、そのまま処理を終了する。

図２８で新規追加されたステップＳ１１１０～Ｓ１１１５の処理について説明する。まず、更新判断モジュール１２０は、キャッシュＤＢ管理装置５００に保持されている要求回数情報５０１に対して、要求回数を「１」加算する（ステップＳ１１１０）。次に、更新判断モジュール１２０は、キャッシュＤＢ管理装置５００に保持されている現在の要求回数（すなわち、ステップＳ１１１０の加算後の要求回数）を取得する（ステップＳ１１１１）。

そして、更新判断モジュール１２０は、ステップＳ１１１１で取得した現在の要求回数と、対象データベースに課せられたキャッシュ更新制約に規定された要求回数制限とを比較し、現在の要求回数が要求回数制限以上であるか否かを判定する（ステップＳ１１１２）。ステップＳ１１１１において現在の要求回数が要求回数制限以上であった場合は（ステップＳ１１１１のＹＥＳ）、ステップＳ１１１３に移行し、現在の要求回数が要求回数制限未満であった場合は（ステップＳ１１１１のＮＯ）、処理を終了する。

ステップＳ１１１３に移行した場合、更新判断モジュール１２０は、データベース２１０に対してキャッシュ更新クエリを送信し、その結果を受信する。そして、更新判断モジュール１２０は、ステップＳ１１１３で受信した結果によって分析箇所キャッシュ１５０を更新する（ステップＳ１１１４）。

その後、更新判断モジュール１２０は、ステップＳ１１１４における更新結果（キャッシュ更新が完了した旨）をＤＢ情報閲覧機能１３２に送信し（ステップＳ１１１５）、処理を終了する。

図２９は、管理描画部５１０による処理の処理手順例を示すフローチャートである。図２９に示す処理は、第１の実施形態においてキャッシュ管理モジュール１１０にアクセスされるときの描画部１７０による処理と同様であり、具体的には、図３のステップＳ１０１（詳細な個別処理としては図１５）の処理に相当する。

なお、図２９では、ステップＳ１２０１においてユーザからのアクセス先がキャッシュ管理モジュール１１０であるかデータ処理開発モジュール１３０であるかを判定しているが、キャッシュＤＢ管理装置５００の管理描画部５１０にアクセスするユーザはＤＢ管理者２であるため、キャッシュ管理モジュール１１０がアクセス先となり、管理描画部５１０はステップＳ１２０２以降の処理を実行する。具体的には、ステップＳ１２０２～Ｓ１２０９の処理は、図１５のステップＳ８０２～Ｓ８０９の処理にそれぞれ相当する。

図３０は、分析描画部６２０による処理の処理手順例を示すフローチャートである。図３０に示す処理は、第１の実施形態においてデータ処理開発モジュール１３０にアクセスされるときの描画部１７０による処理に対応するものであり、具体的には、図４のステップＳ２０１（詳細な個別処理としては図１６）の処理の一部に相当する。

図３０では、ステップＳ１３０１において、ユーザからのアクセス先がキャッシュ管理モジュール１１０であるかデータ処理開発モジュール１３０であるかを判定しているが、データ分析装置６００の分析描画部６２０にアクセスするユーザは基本的には開発者３であるため、データ処理開発モジュール１３０がアクセス先となり、分析描画部６２０はステップＳ１３０２以降の処理を実行する。具体的には、ステップ１３０２～Ｓ１３０７の処理は、図１６のステップＳ８１０～Ｓ８１５の処理にそれぞれ相当する。但し、第２の実施形態では各データ分析装置６００の分析描画部６２０にキャッシュ更新ボタンは表示されないため、分析描画部６２０は、図１６のステップＳ８１６～Ｓ８２１に相当する処理は実行せず、データ処理開発モジュール１３０に関する描画処理のみを行う。

以上のような処理を行うことによって、データ処理システム４は、複数のデータ分析装置６００を備え、複数の開発者３によってそれぞれのデータ分析装置６００が使用される場合であっても、それぞれのデータ分析に用いられるキャッシュがキャッシュＤＢ管理装置５００内の分析箇所キャッシュ１５０に統合して管理され、さらに、そのキャッシュ更新はキャッシュ更新制約のもとでのみ許可されるため、複数のデータ分析装置６００を使用する開発者３から、分析箇所キャッシュ１５０へのデータ更新要求を伴う所定のデータ操作（例えば入力ＤＢの指定）が行われても、基幹系データベース（データベース２１０）へのアクセスの増加を制限することが可能になる。

また、ユーザ視点で見れば、本実施形態に係るデータ処理システム４では、データ分析の開発フェーズで使用される分析箇所キャッシュ１５０のキャッシュ更新に対して、ＤＢ管理者２から、データ別の更新要求回数による制約条件を含む態様で、キャッシュの更新制約を課することができる機能が実装される。また、複数のデータ分析装置６００を利用する開発者３からは、分析箇所キャッシュ１５０へのデータ更新要求を伴う所定のデータ操作（例えば入力ＤＢの指定）を自発的に行うことによって、キャッシュ更新を要求することができる。開発者３からデータ更新が要求された場合は、対象データに課せられた更新制約（更新要求回数に関する更新制約も含まれる）に基づく更新可否判断のもとで、更新が可能な場合に限り、対象データのキャッシュ更新がなされる。したがって、データベース２１０へのアクセス負荷の軽減のために、更新要求回数が規定条件に達しない場合には即座に対象データのキャッシュ更新がなされない状況は発生し得るものの、比較的早期のうちに、開発者３の希望に沿って対象データのキャッシュ更新を実行することができる。

図３１は、第１または第２の実施形態に係るデータ処理システム１，４を構成する各装置（コンピュータ装置１０）のハードウェア構成例を示すブロック図である。具体的には、図３１に示すハードウェア構成例は、データ処理装置１００、データベース装置２００、キャッシュＤＢ管理装置５００、及びデータ分析装置６００に実装することができる。

図３１に示すように、コンピュータ装置１０は、外部記憶装置１１、ＲＡＭ（Random Access Memory）１２、ＲＯＭ（Read Only Memory）１３、ＣＰＵ（Central Processing Unit）１４、出力デバイス１５、通信ＩＦ１６、及び入力デバイス１７を備え、各構成がバス１８を介して相互的に接続される。

データ処理システム１（データ処理システム４）を構成する各装置が有する機能は、コンピュータ装置１０において、例えばＣＰＵ１４がＲＯＭ１３に記憶されたプログラムをＲＡＭ１２に読み出して実行することで実現されてもよいし、昨日の一部または全部を、専用に設計された集積回路等のハードウェアで実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。

外部記憶装置１１は、例えばＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ（Flash Memory）、または光学式記憶装置等である。出力デバイス１５は、データを出力する機能を有し、データ処理装置１００、キャッシュDB管理装置５００、またはデータ分析装置６００に係る画面を、モニタやプリンタ等の出力装置で出力する。通信ＩＦ１６は、データ処理システム１におけるデータ処理装置１００とデータベース装置２００との接続、あるいはデータ処理システム４におけるキャッシュＤＢ管理装置５００とデータ分析装置６００及びデータベース２１０（データベース装置）との接続に用いられる。入力デバイス１７は、ユーザ（ＤＢ管理者２、開発者３）による入力操作を受け付けるキーボードやマウス等であり、例えば第１の実施形態では、ＤＢ管理者２がデータ処理装置１００にＤＢ情報１０１やキャッシュ更新制約１０２を入力する際や、開発者３がデータ処理開発モジュール１３０に対して分析フローを設計したりデータベースを指定したりする際の操作に用いられる。

以上、本発明を実施するための代表的な形態として第１及び第２の実施形態について説明したが、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、第１の実施形態に係るデータ処理システム１（第２の実施形態に係るデータ処理システム４でもよい）において、分析箇所キャッシュ１５０のキャッシュサイズは有限であり、データ処理装置１００（第２の実施形態では複数のデータ分析装置６００）で使用するデータの全てをキャッシュに保存できない場合、キャッシュに存在しないデータにアクセスする際は直接データベース２１０を参照する必要がある。そこで各実施形態の変形例として、このような状況において、例えば更新判断モジュール１２０が、データ処理装置１００（データ分析装置６００）からの参照回数が多いデータを優先的に分析箇所キャッシュ１５０に保存するようなキャッシュデータ入替処理を行うように構成してもよい。以下、キャッシュデータ入替処理について図３２を参照しながら説明する。

図３２は、キャッシュデータ入替処理を説明するためのイメージ図である。図３２の場合、更新ログ１６３には、キャッシュの更新要求が行われた回数（更新要求回数）がデータ別（スキーマ別、テーブル別）に記録されているとする。具体的には、分析箇所キャッシュ１５０内にキャッシュが保存されているデータＡ７２１、データＢ７２２について、それぞれの更新要求回数が「１００回」、「１０回」であることが記録され、分析箇所キャッシュ１５０内にキャッシュが保存されていないデータＣ７２３については、更新要求回数が「５０回」であることが記録されている。

図３２では、データＣ７２３に対してキャッシュの更新が要求されている。ここで、更新判断モジュール１２０においてキャッシュの更新が可能と判断され、データベース２１０にクエリが送信される図９のステップＳ５１１の段階（第２の実施形態では図２８のステップＳ１１１３）において、分析箇所キャッシュ１５０内のデータ容量が一杯で（所定の上限容量や容量率に達している場合と読み替えてもよい）、かつデータＣ７２３の前回キャッシュが分析箇所キャッシュ１５０内に存在しない場合に、更新判断モジュール１２０がキャッシュデータ入替処理を実行する。

キャッシュデータ入替処理では、更新判断モジュール１２０は、更新ログ１６３からデータ別の更新要求回数を取得し、更新が要求されたデータよりも更新要求回数が少なく、かつ分析箇所キャッシュ１５０内に存在するデータを削除し、更新が要求されたデータを新しく分析箇所キャッシュ１５０内に格納する。具体的には、図３２の場合、データＣ７２３（５０回）よりも更新要求回数が少なく、分析箇所キャッシュ１５０内に存在するデータＢ７２２（１０回）が、削除対象とされる。なお、データＡ７２１（１００回）はデータＣ７２３（５０回）よりも要求更新回数が多いため、削除対象に選択されず、分析箇所キャッシュ１５０内のキャッシュが維持される。

本変形例では、以上のようなキャッシュデータ入替処理が行われることにより、更新要求回数が比較的少ないデータＢを分析箇所キャッシュ１５０から削除し、更新要求回数が比較的多いデータＣを分析箇所に格納するため、分析箇所キャッシュ１５０のキャッシュ更新頻度を抑制しながらも、参照回数の多いデータ（スキーマやテーブル）を優先的にキャッシュすることができ、結果として、データベース２１０に直接データを読み込む回数を削減することができる。すなわち、データ処理システム１（データ処理システム４）は、データ処理装置１００（データ分析装置６００）からの参照回数が多いデータを優先的に分析箇所キャッシュ１５０に保存することで、直接データベース２１０が参照される回数を減らし、アクセス負荷を軽減することができる。

なお、以上の説明で参照した各図面において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１，４ データ処理システム
２ ＤＢ管理者
３ 開発者
１０ コンピュータ装置
１１ 外部記憶装置
１２ ＲＡＭ
１３ ＲＯＭ
１４ ＣＰＵ
１５ 出力デバイス
１６ 通信ＩＦ
１７ 入力デバイス
１８ バス
１００ データ処理装置
１１０ キャッシュ管理モジュール
１１１ 更新制約入力機能
１１２ ＤＢ情報入力機能
１２０ 更新判断モジュール
１３０ データ処理開発モジュール
１３１ 分析フロー設計機能
１３２ ＤＢ情報閲覧機能
１４０ データ処理モジュール
１５０ 分析箇所キャッシュ
１５１ メタデータ
１５２ カラムデータ
１６０ データ記憶部
１６１ 登録ＤＢ情報
１６２ キャッシュ更新制約情報
１６３ 更新ログ
１７０ 描画部
１７１ 更新ボタン
２００ データベース装置
２０１ センサデータ
２０２ ログデータ
２１０ データベース
２１１ メタデータ
２１２ カラムデータ
２２０ データベースマネジメントシステム
３５０ 登録ＤＢ一覧画面
３６０ ＤＢ情報入力画面
３７０ キャッシュ更新制約入力画面
３８０ 分析フロー設計画面
３９０ ＤＢ指定画面
４００ ＤＢデータ表示画面
５００ キャッシュＤＢ管理装置
５０１ 要求回数情報
５１０ 管理描画部
６００ データ分析装置
６１０ データ処理モジュール
６１１ 分析処理実行機能
６２０ 分析描画部
７００ キャッシュ更新制約入力画面

Claims (9)

1. データベースに接続し、前記データベースのデータ分析を行うデータ処理システムであって、
   前記データ分析の開発フェーズにおいて参照される前記データベースのデータをキャッシュする分析箇所キャッシュと、
   前記データ分析の開発者によって使用され、前記データ分析のための分析処理を開発するデータ処理開発モジュールと、
   前記開発者によって使用され、前記データ処理開発モジュールで開発された前記分析処理の実行によってデータ分析を行うデータ処理モジュールと、
   前記分析箇所キャッシュにおける前記データベースからのキャッシュ更新に関して、前記データベースの管理者から入力される更新制約を設定するキャッシュ管理モジュールと、
   前記キャッシュ管理モジュールによって設定された前記更新制約に基づいて前記分析箇所キャッシュのキャッシュ更新の可否を判断する更新判断モジュールと、
   を備え、
   前記データ処理開発モジュールから前記キャッシュ更新が要求されたとき、前記更新判断モジュールは、前記判断でキャッシュ更新を可とした場合に、前記要求されたキャッシュ更新を実行する
   ことを特徴とするデータ処理システム。
2. 前記開発者に対する画面表示を行う描画部をさらに備え、
   前記描画部は、前記更新判断モジュールによって前記分析箇所キャッシュのキャッシュ更新を可と判断された場合に、前記キャッシュ更新を要求する操作を行うための更新ボタンを、前記開発者から操作可能な形態で表示する
   ことを特徴とする請求項１に記載のデータ処理システム。
3. 前記キャッシュ管理モジュールは、スキーマ単位またはテーブル単位で、前記データベースに保持されたデータに対して前記更新制約を設定可能とする
   ことを特徴とする請求項１に記載のデータ処理システム。
4. 前記キャッシュ管理モジュールは、前記更新制約において前記キャッシュ更新を許可する時間または頻度を設定可能とする
   ことを特徴とする請求項１に記載のデータ処理システム。
5. 前記分析箇所キャッシュ、前記キャッシュ管理モジュール、及び前記更新判断モジュールを有し、前記管理者によって使用されるキャッシュＤＢ管理装置と、
   データ処理開発モジュール及び前記データ処理モジュールをそれぞれ有し、前記開発者によって使用される複数のデータ分析装置と、
   を備え、
   前記キャッシュＤＢ管理装置において、前記分析箇所キャッシュは、前記複数のデータ分析装置から参照される前記データベースのデータを統合的にキャッシュする
   ことを特徴とする請求項１に記載のデータ処理システム。
6. 前記キャッシュＤＢ管理装置は、前記複数のデータ分析装置からの前記キャッシュ更新の要求回数を記録する更新ログをさらに有し、
   前記キャッシュ管理モジュールは、前記更新制約の少なくとも１つとして前記キャッシュ更新の要求の累積回数を規定し、
   前記データ分析装置において前記開発者から所定のデータ操作が行われたとき、
   前記データ処理開発モジュールは、前記所定のデータ操作の対象データについて、前記キャッシュ更新を前記キャッシュＤＢ管理装置に要求し、
   前記キャッシュＤＢ管理装置の前記キャッシュ管理モジュールは、前記累積回数の規定を含む前記更新制約に基づいて、前記分析箇所キャッシュにおける前記対象データのキャッシュ更新の可否を判断し、当該判断でキャッシュ更新を可とした場合に、前記要求されたキャッシュ更新を実行する
   ことを特徴とする請求項５に記載のデータ処理システム。
7. 前記キャッシュ管理モジュールは、参照回数の多いデータを優先的に前記分析箇所キャッシュにキャッシュさせる機能を有する
   ことを特徴とする請求項１または請求項５に記載のデータ処理システム。
8. データベースのデータ分析を行うデータ処理システムによるキャッシュ更新制御方法であって、
   前記データ処理システムは、
   前記データ分析の開発フェーズにおいて参照される前記データベースのデータをキャッシュする分析箇所キャッシュと、
   前記データ分析の開発者によって使用され、前記データ分析のための分析処理を開発するデータ処理開発モジュールと、
   前記開発者によって使用され、前記データ処理開発モジュールで開発された前記分析処理の実行によってデータ分析を行うデータ処理モジュールと、
   前記分析箇所キャッシュにおける前記データベースからのキャッシュ更新に関して、前記データベースの管理者から入力される更新制約を設定するキャッシュ管理モジュールと、
   前記キャッシュ管理モジュールによって設定された前記更新制約に基づいて前記分析箇所キャッシュのキャッシュ更新の可否を判断する更新判断モジュールと、
   を有し、
   前記データ処理開発モジュールから前記キャッシュ更新が要求されたとき、前記更新判断モジュールは、前記判断でキャッシュ更新を可とした場合に、前記要求されたキャッシュ更新を実行する
   ことを特徴とするキャッシュ更新制御方法。
9. 前記データ処理システムは、前記開発者に対する画面表示を行う描画部をさらに有し、
   前記更新判断モジュールによって前記分析箇所キャッシュのキャッシュ更新を可と判断された場合に、前記描画部が、前記キャッシュ更新を要求する操作を行うための更新ボタンを、前記開発者から操作可能な形態で表示する
   ことを特徴とする請求項８に記載のキャッシュ更新制御方法。
   

Images