(57)【要約】【課題】データ分析・活用を行うために、共通データ基盤から取得したデータを適切な形に検証・加工するが、その結果を共通基盤にフィードバックしたい場合がある。【解決手段】共通データ基盤１０３に、フィードバックデータを受け取る機能３０５と、フィードバックデータの元となったデータを格納する保持部３０４と、フィードバックデータを保持する保持部３０６と、それぞれの配置場所のデータベース３０８とを有する。さらに、共通データ基盤１０３内およびデータ活用・分析を行うシステム１０５，１０６内それぞれの加工処理の実行順序制御を行う機能と、フィードバックデータを効率的に、統一した形式に変換保存する機能１２０１とを有する。【選択図】図３
2016009263.tif 000002
【特許請求の範囲】
【請求項１】
複数の提供元から収集した機器に関する多様なデータを蓄積して管理する管理システムと、当該管理システムから供給されたデータを利用する分析システムを含むデータ活用システムであって、
前記管理システムからはアクセスができないように構築され、前記管理システムで利用できない非共有データを扱う保持システムを有し、
前記管理システムは、
蓄積した前記データから前記分析システムによる分析に適した供給データを生成する生成手段と、
生成された前記供給データを前記分析システムに供給する供給手段とを有し、
前記分析システムは、
前記保持システムから前記非共有データを取得する取得手段と、
取得した前記非共有データと前記供給データとを利用して分析を行う分析手段とを有することを特徴とするデータ活用システム。
【請求項２】
前記分析手段は、取得した前記非共有データを用いて前記供給データを修正した修正データを用いて分析を行うことを特徴とする請求項１に記載のデータ活用システム。
【請求項３】
前記分析システムは、前記修正データを前記管理システムに対して送信する送信手段をさらに有することを特徴とする請求項１又は２に記載のデータ活用システム。
【請求項４】
前記管理システムは、生成した前記供給データとは別に前記修正データを管理する管理手段をさらに有することを特徴とする請求項１乃至３のいずれか一項に記載のデータ活用システム。
【請求項５】
前記管理システムは、前記分析システムとは別の第二の分析システムに対して前記修正データを供給することを特徴とする請求項１乃至４のいずれか一項に記載のデータ活用システム。
【請求項６】
前記管理システムは、前記共有データと該共有データを修正して得た前記修正データとを関連付けてそれぞれの保存場所を記憶するデータ配置記憶手段をさらに有することを特徴とする請求項２に記載のデータ活用システム。
【請求項７】
前記分析手段は、対象の共有データに関連付けた前記非共有データを取得し、前記供給データと前記非共有データとで同一であるべき項目を比較し、当該項目を、前記非共有データに一致させるよう前記共有データを修正して修正データを生成することを特徴とする請求項２に記載のデータ活用システム。
【請求項８】
前記管理システムは、前記供給データを、該供給データを修正して得た修正データを前記管理手段による管理を受容するか否かを示す受容可否情報とともに管理し、
前記分析システムは、前記修正データを前記管理システムに対して送信する際に、当該修正データの元となった前記供給データの前記受容可否情報を参照し、受容するのであれば、前記修正データを前記管理システムに対して送信し、前記管理システムにより管理させることを特徴とする請求項３に記載のデータ活用システム。
【請求項９】
前記管理システムはさらに、前記送信手段により送信された前記修正データの形式を、該修正データの元となる供給データと同じ形式に変換する手段を有することを特徴とする請求項３に記載のデータ活用システム。
【請求項１０】
前記管理システムはさらに、前記送信手段により送信された前記修正データのうち、該修正データの元となる供給データとの差分を管理することを特徴とする請求項４に記載のデータ活用システム。
【請求項１１】
前記管理システムはさらに、前記生成手段および前記分析手段による処理の順序を、前記修正データに対する処理が、該修正データの元となる供給データに対する処理よりも先にならないよう制御することを特徴とする請求項１乃至８のいずれか一項に記載のデータ活用システム。
【請求項１２】
複数の提供元から収集した機器に関する多様なデータを蓄積して管理する管理システムと、当該管理システムから供給されたデータを利用する分析システムと、前記管理システムからはアクセスができないように構築され、前記管理システムで利用できない非共有データを扱う保持システムとを含むデータ活用システムによるデータ処理方法であって、
前記管理システムは、蓄積した前記データから前記分析システムによる分析に適した供給データを生成し、
生成した前記供給データを前記分析システムに供給し、
前記分析システムは、前記保持システムから前記非共有データを取得し、
取得した前記非共有データと前記供給データとを利用して分析を行うことを特徴とするデータ処理方法。
【請求項１３】
データソースから提供された供給データを格納する第１の格納手段と、
前記第１の格納手段に格納した供給データを加工した修正データを格納する第２の格納手段と、
前記供給データと該供給データを加工した前記修正データとを関連付けて、それぞれが格納された場所を示す配置情報を格納する第３の格納手段と、
要求に応じて、前記第３の格納手段により格納された前記配置情報を応答する応答手段と
を有することを特徴とするデータ活用システム。
【請求項１４】
データソースから提供された供給データを第１の格納手段に格納する第１の格納工程と、
前記第１の格納手段に格納した供給データを加工した修正データを第２の格納手段に格納する第２の格納工程と、
前記供給データと該供給データを加工した前記修正データとを関連付けて、それぞれが格納された場所を示す配置情報を第３の格納手段に格納する第３の格納工程と、
要求に応じて、前記第３の格納手段により格納された前記配置情報を応答する応答工程と
を有することを特徴とするデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば分析用データに対して抽出・加工・格納等を行うデータ活用システム及びデータ処理方法に関する。
【背景技術】
【０００２】
企業内では、様々な目的のデータの分析・活用を促進するため、全社のデータを同一のストレージに収集管理する共通データ基盤を用意することがある。データ分析・活用の工程の中で重要な位置を占めるのが、ETL処理と呼ばれる処理で、企業の基幹システムなどに存在するデータを抽出(Extract)し、分析に利用しやすい形に加工(Transform)し、分析データベースに書き出す(Load)、これら一連の処理を指し示す。前記加工の処理には、データそのものの加工やデータ項目の追加、不要なデータを削除するフィルタリングの他、データ検証のプロセスも含まれる（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2012-141847号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
さまざまな提供元からさまざまなデータを収集して、蓄積する管理システムにおいて、蓄積されたデータは様々な分析システムにより多様な用途で分析のために利用されることになる。分析システムに対して供給されるデータは、さまざまなルールや外部取得されるデータを参考に、整形、修正、フィルタなどの加工が行われることが望まれる。しかしながら、この加工のために参考となり得るデータの利用には、様々なセキュリティ方針、取りつかい規約（契約）などによる制約があることが多い。
【０００５】
そこで、本発明は、上記観点を考慮し、適切にデータ活用が運用できるようなデータ活用システム及びデータ処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本発明は以下の構成を有する。
【０００７】
第１の側面によれば、複数の提供元から収集した機器に関する多様なデータを蓄積して管理する管理システムと、当該管理システムから供給されたデータを利用する分析システムを含むデータ活用システムであって、
前記管理システムからはアクセスができないように構築され、前記管理システムで利用できない非共有データを扱う保持システムを有し、
前記管理システムは、
蓄積した前記データから前記分析システムによる分析に適した供給データを生成する生成手段と、
生成された前記供給データを前記分析システムに供給する供給手段とを有し、
前記分析システムは、
前記保持システムから前記非共有データを取得する取得手段と、
取得した前記非共有データと前記供給データとを利用して分析を行う分析手段とを有する。
【０００８】
第２の側面によれば、データソースから提供された供給データを格納する第１の格納手段と、
前記第１の格納手段に格納した供給データを加工した修正データを格納する第２の格納手段と、
前記供給データと該供給データを加工した前記修正データとを関連付けて、それぞれが格納された場所を示す配置情報を格納する第３の格納手段と、
要求に応じて、前記第３の格納手段により格納された前記配置情報を応答する応答手段と
を有する。
【発明の効果】
【０００９】
本発明は、データ分析・活用するシステムが、共通データ基盤へデータ検証・修正した結果をフィードバックすることでき、その他のデータ分析・活用システムが精度の高くなったデータも利用することができるようになる。
【図面の簡単な説明】
【００１０】
【図１】ネットワーク構成図
【図２】ハードウェア構成図
【図３】実施形態１におけるコンポーネント図
【図４】実施形態１におけるETL制御部のフローチャート
【図５】実施形態１における修正データ受付部のフローチャート
【図６】実施形態１におけるアプリETL処理部のフローチャート
【図７】実施形態１における基盤ETL処理部のフローチャート
【図８】実施形態２におけるコンポーネント図
【図９】実施形態２におけるETL制御部のフローチャート
【図１０】実施形態２におけるアプリETL処理部のフローチャート
【図１１】実施形態２における基盤ETL処理部のフローチャート
【図１２】実施形態３におけるコンポーネント図
【図１３】実施形態３における修正データ受付部のフローチャート
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための形態について図面を用いて説明する。
［実施形態１］
＜データ活用システムの構成＞
実施形態１におけるデータ活用システムを構成している各装置について、図１を参照して詳細に説明する。図１は、データ活用システムのネットワーク構成図である。データ活用システムを構成しているのは、データソース１０１、１０２、共通データ基盤１０３、非共有データ管理サーバー１０４、分析サーバー１０５、１０６である。データソース１０１、１０２は、企業内の基幹システムなどに相当するサーバーで、業務に必要となる様々なデータを登録・蓄積しているシステムである。ここでは、データの提供元であるデータソースとしてデータソース１０１、１０２の２つを列挙しているが、より多くのシステムがデータソースとして存在していてもよい。なお本実施形態において「・」（中黒）は、「・」で結んだもののうちの少なくともいずれか一つを表すものとする。たとえば「登録・蓄積」とは、「登録および蓄積の少なくともいずれか一つ」を表す。データソース１０１、１０２は汎用コンピュータのほか、温度等の種々のセンサーや、画像を撮影するカメラ等など、データを出力する種々のデバイスであってもよい。データソース１０１，１０２は、図１においては共通データ基盤１０３にネットワーク１１０を介して接続されている。共通データ基盤１０３は、分析に必要となるデータをデータソース１０１、１０２から取得あるいは収集し、統一された形式に変換した上で保持する管理システムである。管理システムである共通データ基盤１０３は、分析システムのために、形式変換やデータ補完やフィルタ処理などを行って、共有データ（供給データ）を生成し、収集した多様なデータを蓄積する。共通データ基盤１０３は、１つのコンピュータにより構成されてもよいし、複数のコンピュータを組み合わせたシステムとして構成されていてもよい。非共有データ管理サーバー１０４は、データの機密性やセキュリティ規約などの理由で、共通データ基盤１０３上に保持・共有することができないデータを保持している保持システムである。非共有データ管理サーバー１０４は、管理システムである共通データ基盤１０３からアクセスできないように構築されている。分析サーバー１０５、１０６は、共通データ基盤１０３上のデータを利用してデータ分析・活用を行うシステムである。非共有データ管理サーバー１０４は、ネットワーク１１１を介して分析サーバー１０５に接続され、分析サーバー１０５，１０６は、ネットワーク１１１を介して共通データ基盤１０３に接続されている。もちろん全ての構成要素が同一のネットワークに接続されていてもよい。いずれにしても、図１の各構成要素が通信で接続されていればよい。
【００１２】
図２は、本発明の実施形態に係る１０１〜１０６の各装置を構成するハードウェアの構成図である。図２において、中央処理ユニット（ＣＰＵ）２０２は装置全体の制御を行う。ＣＰＵ２０２はハードディスク（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、ランダムアクセスメモリ（ＲＡＭ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。読み出し専用メモリ（ＲＯＭ）２０４は記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。ＲＡＭ２０３は一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。ディスプレイ２０６は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インターフェース２０８は外部装置Ｉ／Ｆであり、プリンター、ＵＳＢ機器、周辺機器を接続する。キーボード２０７は指示入力手段である。指示入力のためのデバイスにはポインティングデバイスもある。システムバス２０１は、装置内におけるデータの流れを司るものである。ネットワークインターフェースカード（ＮＩＣ）２０９は、インターフェース２０９、ネットワーク１１０〜１１２を介して外部装置とのデータのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。
【００１３】
＜データ活用システムの機能要素＞
図３は、本実施形態におけるデータ活用システムが持つ各機能を表すコンポーネント図である。各機能は、プログラムまたはデータをＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで保持し、必要に応じてＲＡＭ２０３に読み出し、ＣＰＵ２０２にて実行されることで実現されるものとする。もちろん専用ハードウェアのみや、専用ハードウェアとソフトウェアとの組み合わせにより実現することもできる。これは他の実施形態についても同様である。
【００１４】
データソース提供部３０１、３０２は、それぞれデータソース１０１、１０２で保持するデータを外部システムからの要求に従って提供する機能を有する。基盤ETL処理部３０３は、データソース３０１、３０２からデータを取得し、共通データ基盤１０３としての統一した形式に変換した上で、共通データ保持部３０４に変換データを保存する機能を有する。共通データ保持部３０４は、基盤ETL処理部３０３が処理したデータを保存し、要求に従って指定された保存データを読み出す機能を有する。なお共通データは共有データと呼んでもよい。修正データ受付部３０５は、外部システムからの要求に従って修正されたデータを受信し、受信したデータを修正済み共通データ保持部３０６に保存した上でETL制御部３０７にその旨通知する機能を有する。通知する内容には、単に修正済みデータを保存したことのみならず、保存した修正済みデータを特定するための情報（すなわち識別情報）も含む。修正済み共通データ保持部３０６は、修正データ受付部３０５からの書き込み要求に従ってデータを保存し、外部システムからの要求に従って指定された保存データを読み出す機能を有する。ETL制御部３０７は、２つの機能を有する。一つ目は、共通データ基盤１０３内にデータを保存したソフトウェア（あるいは機能ユニット）からの通知を受け付け、データ配置DB３０８にその情報（たとえばデータの配置場所を示す情報）を書き込む機能である。２つ目は、共通データ基盤１０３内のデータにアクセスするにあたり、そのアクセス先の問い合わせを受け付け、データの配置場所を返す機能である。前者の機能によりETL制御部３０７は、修正データ受付部３０５から受信した、修正済み共通データ保持部３０６にデータを保存した旨の通知に応じて、そのデータの配置場所をデータ配置DB３０８に記録する。また、修正前の対応するデータとの対応を示す情報、例えば識別情報を記憶しておく。データ配置DB３０８は、共通データ基盤１０３内に配置されたデータの配置情報を記録しているデータベースであり、データ配置記憶部と呼ぶこともできる。
【００１５】
非共有データ保持部３０９は、非共有データ管理サーバー１０４で保持するデータを外部システムからの要求に従って提供する機能を有する。ただし、本実施形態では、非共有データ保持部３０９に保持されている情報は機密度の高い想定であり、分析サーバー１０５からのアクセスしか受け付けない状態となっている。
【００１６】
アプリETL処理部３１０は、共通データ基盤１０３に保持しているデータと非共有データ管理サーバー内のデータとを取得し、共通データ基盤データの検証・修正を実施した上で、アプリデータ保持部３１１へ書き込む機能を有する。またアプリETL処理部３１０は、検証・修正した共通データ基盤データを共通データ基盤１０３へフィードバックする機能も有する。アプリデータ保持部３１１は、アプリETL処理部３１０で処理したデータを保存し、アプリケーション３１２の要求に従ってデータを読み出す機能を有する。アプリケーション３１２は、アプリデータ保持部３１１に保存されているデータを、データの活用用途に合わせて表示・レポーティングする機能を有する。
【００１７】
アプリETL処理部３１３は、共通データ基盤１０３に保持しているデータを取得し、アプリデータ保持部３１４へ書き込む機能を有する。アプリデータ保持部３１４は、アプリETL処理部３１３で処理したデータを保存し、アプリケーション３１５の要求に従ってデータを読み出す機能を有する。アプリケーション３１５は、アプリデータ保持部３１４に保存されているデータを、データの活用用途に合わせて表示・レポーティングする機能を有する。表１にデータ配置DB３０８に保存されている情報の例を示す。
【００１８】
【表１】
2016009263.tif 000003
【００１９】
IDはデータベースの各レコードに固有の識別子である。Data Source（データソース）はデータ取得元、Data Category（データカテゴリ）はデータの種類、Date（日付）は何日の更新差分かを示しており、この３項目で対象のデータを特定する識別子を形成する。Feedback Acceptable（フィードバック受容フラグ、受容可否情報とも呼ぶ）、Version（バージョン）、URIは、それぞれのデータの属性情報であり、Feedback Acceptableは、アプリETL処理部３１０などが、取得したデータを検証・修正した場合、フィードバックしてよいかどうかを示すフラグである。ここでいうフィードバックとは、修正等の加工が施されたデータを、データ配置DB３０８に書き戻すことである。Versionは、各データ識別子に対してフィードバックがあった場合、固有に、例えばインクリメンタルに割り振られるデータの版を意味する属性である。URIは、各データ識別子の各バージョンに対して、どこから取得可能かを表す共通データ基盤内の配置先（すなわちデータの所在）を示す値である。なおデータソース、データカテゴリ、更新日の３項目でデータをユニークに識別することが困難であれば、他の項目を追加して識別子としても良い。
【００２０】
表１の例では、レコード１００（IDが１００のレコード）と、レコード１０２とは同一の識別子を有するデータであり、バージョンがそれぞれ１と２である。そしてバージョン１はオリジナルのデータであることを示す。すなわち、レコード１００がオリジナルのデータを示し、レコード１０２はレコード１００で示されるオリジナルデータに基づく修正済みデータのフィードバックであり、それぞれURIで示された別々の場所に保存されていることがわかる。このように、識別子によりデータのアイデンティティすなわち同一性を示して元となるデータ（供給データ）とその修正データとを関連付け、バージョンによりオリジナルデータであるか加工済みの派生データであるかを示すことで、一方のデータから他方のデータを特定することができる。なおフィードバック受容フラグは、ユーザーに指定させたり予め定めた値を設定したりすることで、値を設定できる。たとえばデフォルト値を可（TRUE）としておき不可（FALSE）のものだけ特に指定したり、その逆であったり、あるいはすべてを指定させてもよい。
【００２１】
＜ETL制御部によるリクエストの処理＞
図４は、ETL制御部３０７が、基盤ETL処理部３０３、修正データ受付部３０５、アプリETL処理部３１０、３１３からアクセスされた場合の動作を表すフローチャートである。なお、フローチャートで示す手順がＲＡＭ２０３，ＲＯＭ２０４，ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００２２】
ステップ４０１では、ETL制御部３０７は呼び出されたメソッドによって、アクセスリクエストの種類を判定し、データ配置情報更新リクエストの場合はステップ４０２に、データ配置情報取得リクエストの場合にはステップ４０３に分岐する。この時、データ配置情報更新リクエストには、更新しようとするデータのデータ識別子であるData Source、Data Category、Dateの各値と、属性値であるFeedback AcceptableとURIとが含まれる。一方、データ配置情報取得リクエストには、取得しようとするデータの識別子であるData Source、Data Category、Dateそれぞれの値と、Versionを示す値とが含まれる。
【００２３】
ステップ４０２では、ETL制御部３０７は、データ配置DB３０８から、リクエストに含まれるData Source、Data Category、Dateがいずれも同一のデータで、かつ最大のVersionを持つデータのFeedback Acceptableを参照する。この時、参照したFeedback AcceptableがTRUEの場合、すなわちフィードバック可の場合にはステップ４０３に、FALSEの場合、すなわちフィードバック不可の場合にはステップ４０４にと分岐する。
【００２４】
ステップ４０３では、ETL制御部３０７は、データ配置DB３０８に、リクエストされたデータの配置情報を追記する。この時のVersionは、データ配置DB３０８に含まれる、Data Source、Data Category、Dateがいずれも同一のデータのうちで最大のVersionに１を加えた値が割り当てられる。この後、リクエストを成功裡に処理した旨（すなわち成功応答）をリクエスト元に応答する。ステップ４０４では、ETL制御部３０７はリクエストされたデータが、フィードバック可能なデータでない旨を示す情報（例外）を返信する。
【００２５】
ステップ４０５では、ETL制御部３０７は、要求されているデータのURIをデータ配置DB３０８から検索し、取得する。ステップ４０６では、ETL制御部３０７はステップ４０５にて取得したURIとフィードバック受容フラグの値とをリクエスト元にレスポンスとして返す。レスポンスはURIのみであってもよい。
【００２６】
＜修正データ受付部３０５による修正済みデータの保存＞
図５は、修正データ受付部３０５がアプリETL処理部３１０からアクセスされた場合の動作を示すフローチャートである。なお、フローチャートで示す手順がＲＡＭ２０３,ＲＯＭ２０４,ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００２７】
ステップ５０１では、修正データ受付部３０５は、アプリETL処理部３１０からのリクエストに基づいて修正データを受け取る。このときのリクエストには、データ配置DB３０８に登録しようとしているレコードの識別子Data Source、Data Category、Dateの値と、属性としてFeedback Acceptableを示す値と、アプリETL処理部３１０で修正されたデータとが含まれる。ステップ５０２では、修正データ受付部３０５は、ETL制御部３０７に対して、データ配置情報更新リクエストを行う。このリクエストには、Data Source、Data Category、Date、Feedback Acceptableに加えて、データ配置先予定のURIを示す値が含まれる。前記データ配置先予定URIは、修正データ受付部３０５が修正済み共通データ保持部３０６上のURIを動的に生成した値である。このリクエストに応じて、ETL制御部３０７は図４の手順を実行し、リクエストに応じて配置情報を追記するか、フィードバックが不可であれば、例外を応答する。
【００２８】
ステップ５０３では、修正データ受付部３０５はステップ５０２で実施したデータ配置情報更新リクエストの結果、例外が発生したかどうか、すなわちETL制御部３０７から例外応答を受信したか否かを判定し、例外が発生していなければ、すなわち例外応答を受信せず、たとえば成功応答を受信しているならステップ５０４を実行し、例外が発生していれば、すなわち例外応答を受信していれば処理を終了する。ステップ５０４では、修正データ受付部３０５はステップ５０２にて生成した修正済み共通データ保持部３０６上のデータ配置先予定URIで示される保存場所に修正データを配置（すなわち登録あるいは保存）する。
【００２９】
＜アプリETL処理部３１０、３１３による検証及び修正＞
図６は、アプリETL処理部３１０、３１３の動作を示すフローチャートである。この手順では、ETL処理部３１０、３１３が、共通データ基盤１０３から取得したデータ（共有データ）を、非共有データ保持部３０９から取得したデータを用いて検証し、検証結果に応じて修正して、修正済みデータの登録を要求するまでの手順を一例として示す。なお、フローチャートで示す手順がＲＡＭ２０３，ＲＯＭ２０４，ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００３０】
ステップ６０１では、アプリETL処理部３１０、３１３は、ETL制御部３０７にデータ配置情報取得リクエストを送信する。データ配置情報取得リクエストにはデータの識別子が含まれ、データ配置情報取得リクエストを受信したETL制御部３０７は図４の手順を実行して、該当するデータのURIとFeedback Acceptableとを応答し、アプリETL処理部３１０、３１３は取得対象データのURIとFeedback Acceptableの値を取得する。ステップ６０２では、アプリETL処理部３１０、３１３は、ステップ６０１で取得したURIからデータを取得する。ステップ６０３では、アプリETL処理部３１０、３１３は、取得対象の非共有データがあるかどうかを判定し、あればステップ６０４へ、なければステップ６１０へと分岐する。取得対象の非共有データとは、本例では、ステップ６０２で取得したデータの検証に利用可能なデータであり、例えば共通データ保持部３０４のデータベースと非共有データ保持部３０９のデータベースとをあらかじめ関連付けておき、ステップＳ６０２で取得したデータの保存されているデータベースと関連付けられたデータベースが非共有データ保持部３０９にあるなら、取得対象の非共有データがあるものと判定できる。本実施形態では、アプリETL処理部３１０は取得対象の非共有データが存在するので、ステップ６０４を、アプリETL処理部３１３は取得対象の非共有データは存在しないので、ステップ６１０を実行する流れとなる。ステップ６０４では、アプリETL処理部３１０は、非共有データ保持部３０９からデータを取得する。ステップ６０５では、アプリETL処理部３１０は、ステップ６０２で取得したデータをステップ６０４で取得したデータを用いて検証する。本ステップでの検証例は後述する。
【００３１】
ステップ６０６では、アプリETL処理部３１０は、検証結果に問題があったかどうかを判定し、問題があればステップ６０７へ、問題がなければステップ６１０へと分岐する。ステップ６０７では、アプリETL処理部３１０は、検証した結果問題のあったデータを修正する。本ステップでの検証及び修正例は後述する。ステップ６０８では、アプリETL処理部３１０は、ステップ６０１で取得したFeedback Acceptableの値を参照し、TRUEであればステップ６０９へ、FALSEであればステップ６１０へと分岐する。ステップ６０９では、アプリETL処理部３１０は、ステップ６０７で修正したデータを修正データ受付部３０５に送信する。ステップ６１０では、アプリETL処理部３１０、３１３は、アプリデータ保持部３１１、３１４にそれぞれデータをロードする。表２に共通データ保持部３０４に保存されている共有データの例として修理記録のデータベースを示す。また表３に非共有データ保持部３０９に保存されている非共有データの例として生産システムのデータベースを示す。
【００３２】
【表２】
2016009263.tif 000004
【００３３】
【表３】
2016009263.tif 000005
【００３４】
上記表２および表３を用いて、ステップ６０５にて実行されるデータ検証の例について説明する。まず表２は修理記録を表すデータであり、データが手動で入力されるものとする。このため、正しいProduct Type（FFF）を略語（F3）で記入されてしまう場合がある。一方表３は生産記録を表すデータであり、ラインごとにProduct Type（製品種別）が固定されており、Product ID（製品ＩＤ）は連番で割り当てられるため、表２に比べると信頼性が高い。そこで、これらデータベースを互いに関連付けておき、表２の共有データを表３の非共有データを用いてステップ６０５で検証する。本例では製品ＩＤをキーとして、対応する製品ＩＤを持つ表３のデータを用いて、表２のデータを比較し、検証する。すると、表２にあるProduct IDがAa10005のProduct Type（"F3"）が、表３における同じ製品ＩＤの製品タイプ（"FFF"）と相違しており、その製品種別に誤りがあることがわかる。このような比較処理をデータの検証と呼ぶ。
【００３５】
また、表２および表３を用いて、ステップ６０７にて実行されるデータ修正の例について説明する。上記データの検証を例にとると、共有データのうち、誤りが見いだされたProduct IDがAa10005のレコードのProduct Typeを、非共有データのうち対応する製品ＩＤの製品種別に一致するよう、その値「FFF」に書き換えることが表２のデータを正しいデータにすることを意味する。このような処理をデータの修正と呼ぶ。
【００３６】
＜基盤ETL処理部３０３によるデータ更新処理＞
図７は、基盤ETL処理部３０３の動作を示すフローチャートである。図７は基盤ETL処理部３０３がデータソースそれぞれからデータを取得してデータベースを更新する手順を示す。なお、フローチャートで示す手順がＲＡＭ２０３，ＲＯＭ２０４，ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００３７】
ステップ７０１では基盤ETL処理部３０３は、データソース提供部３０１から前日更新データを取得する。ステップ７０２では基盤ETL処理部３０３は、データソース提供部３０２から前日更新データを取得する。ステップ７０３では基盤ETL処理部３０３は、ETL制御部３０７に対してデータ配置情報更新リクエストを送信する。ステップ７０４では基盤ETL処理部３０３は、共通データ保持部３０４にデータを格納する。この手順で、１日単位でデータベースを更新することができる。なおステップ７０４では共通データ保持部３０４へデータを格納しているが、データの性質などによって予め非共有データであることが指定されたデータについては、非共有データ保持部３０９に格納する。
【００３８】
アプリケーション３１２，３１５が共有データを利用してデータ処理を行う際には、たとえば加工済みのデータ用いるのであれば、データの識別子をキーとして共通データ保持部３０４から上述した各構成要素の手順によって該当するデータを取得し、そのうち最もバージョンの大きいデータを用いてデータ処理を行えばよい。また、加工前のオリジナルのデータを用いるのであれば、識別子に加えてバージョンとして１を指定し、それをキーとして該当するデータを取得して、それを用いてデータ処理を行えばよい。あるいは、データの識別子をキーとして共通データ保持部３０４から上述した各構成要素の手順によって該当するデータを取得し、そのうち最もバージョンの小さいデータを用いてデータ処理を行ってもよい。
【００３９】
このようにして、本実施形態により、加工前のデータと加工済みのデータとを保存し、管理することが可能となった。このため、データ分析・活用するシステムが、共通データ基盤へデータ検証・修正した結果をフィードバックすることでき、その他のデータ分析・活用システムが精度の高くなったデータも利用することができるようになる。
【００４０】
［実施形態２］
実施形態１で説明したデータ活用システムは、毎日その前日に更新されたデータをデータソースから取り込んで処理するシステムである。よって各ETL処理部（基盤ETL処理部３０３、アプリETL処理部３１０、３１３）は、それぞれの実行順序に依存関係を持っている。例えば、基盤ETL処理部３１０が完了しないと、アプリETL処理部３１０、３１３は対象となるデータを取得することができない。また、その日に処理すべきデータ量に応じて各ETL処理にかかる時間が異なるため、それぞれのETL処理を実行する時間を事前に決定するのは困難である。そこで本実施形態では、各ETL処理部が処理対象とするデータの情報を保持するDBを設け、各ETL処理部の実行順序を制御できるようにする。
【００４１】
図８は、本実施形態におけるデータ活用システムが持つ各機能を表すコンポーネント図である。各機能は、プログラムまたはデータをＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで保持し、必要に応じてＲＡＭ２０３に読み出し、CPU２０２にて実行されるものとする。ETL処理定義DB８０１は、本データ活用システムにおいてどのETL処理部がどのようなデータを処理対象とするかという情報を管理するデータベースである。また、本実施形態においてETL制御部３０７は、各ETL処理部（基盤ETL処理部３０３、アプリETL処理部３１０、３１３）からの問い合わせに対し、ETL処理定義DB８０１を参照することで、実行可否を返答する機能を有する。図８の３０１〜３０６、３０８〜３１５は、図３と同様である。表４にETL処理定義DB８０１に保存されている情報の例を示す。
【００４２】
【表４】
2016009263.tif 000006
【００４３】
表４の各行（レコード）は、それぞれのETL処理の定義を表しており、IDは各ETL処理を一意に識別するIDであり、1以上の値が割り当てられているものとする。またETL Module（ＥＴＬ処理部）はETL処理部を表す値が格納される。Data Source（データソース）はデータ取得元、Data Category（データ種別）はデータの種類で、表１と同様である。Target Version（対象バージョン）は、ETL処理する対象のデータを表しており、Source（ソース）とBase（ベース）とNewer（より新しい）の3種類の値が格納される。例えば、Target VersionがSourceの場合、ETL Module欄で指定されたETL処理部がデータソース１０１もしくは１０２から直接取得するデータを対象とすることを表す。Target VersionがBaseの場合、ETL Moduleで指定されたETL処理部が共通データ保持部３０４に格納されているデータを対象とすることを表す。Target VersionがNewerの場合、ETL Moduleで指定されたETL処理部が共通データ保持部３０４もしくは修正済み共通データ保持部３０６に格納されているより新しいバージョンのデータを対象とすることを表す。Status（ステータス）は、ETL Moduleで指定されたETL処理部が現在どのような状態にあるのかを示しており、Ready（準備完了）, Waiting（待機中）, Running（実行中）のいずれかの状態を取る。ETL処理定義DB８０１は、例えば予め管理者等により定義され、格納される。ただし、ステータスは状況に応じて図９の手順に示すように更新される。
【００４４】
＜ETL制御部３０７によるリクエストの処理＞
図９は、本実施形態においてETL制御部３０７が、基盤ETL処理部３０３、修正データ受付部３０５、アプリETL処理部３１０、３１３からアクセスされた場合の動作を表すフローチャートである。なお、フローチャートで示す手順がＲＡＭ２０３,ＲＯＭ２０４,ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００４５】
ステップ９０１ではETL制御部３０７は、呼び出されたメソッドによってリクエストを判定し、データ配置系リクエストの場合には図４のステップ４０１へ、実行可否判断リクエストの場合はステップ９０２へ、実行完了通知リクエストの場合はステップ９０７へ分岐する。実行可否判断リクエストおよび実行完了通知リクエストはアプリETL処理部３１０、３１３や基板ETL処理部３０３等のETL処理部から送信され、それぞれのリクエストには、表４におけるETL Module、Data Source、Data Categoryの各値を示す値が含まれる。実行可否判断リクエストは、ETL Module、Data Source、Data Categoryで特定される対象ETL処理が、その時点でリクエスト元により実行できるか否かに関する応答を求める要求である。実行完了通知リクエストは、対象ETL処理を当該リクエスト元が実行したことを通知するリクエストである。
【００４６】
ステップ９０２ではETL制御部３０７は、リクエストに含まれるETL Module、Data Source、Data CategoryとETL処理定義DB８０１に格納されている情報から対象ETL処理を特定する。例えばETL Module、Data Source、Data Categoryとして「基盤ETL処理部３０３」、「101」、「Data_A」という値がリクエストに含まれる場合、表４のデータベースでは、該当するレコードのIDは１であり、対象ETL処理はIDが１のETL処理であることがわかる。なおこの実行可否判断リクエストはいずれかのETL処理部が処理の可否の情報を求めて発行することができ、その場合にはリクエスト元のETL処理部を示す値がETL Moduleとして採用される。もちろんその限りではなく、いずれかの項目が空のリクエストもあり得る。
【００４７】
ステップ９０３ではETL制御部３０７は、特定した対象ETL処理のStatusを確認し、StatusがWaitingでなければステップ９０４へ、StatusがWaitingであればステップ９０６へ分岐する。ステップ９０４ではETL制御部３０７は、ETL処理定義DB８０１に格納されている対象ETL処理のStatusをRunningに変更する。ステップ９０５ではETL制御部３０７は、対象ETL処理のIDをリクエスト元のETL処理部へレスポンスとして返信する。ステップ９０６ではETL制御部３０７は、対象ETL処理のStatusがWaitingで実行が禁止されているため、実行不可を意味する値（例えば−１）をリクエスト元のETL処理部へレスポンスとして返信する。
【００４８】
リクエストが実行完了通知の場合には、ステップ９０７では、ステップ９０２と同様の処理を行う。ステップ９０８ではETL制御部３０７は、対象ETL処理のTarget Versionを参照し、Target VersionがSourceであればステップ９０９へ、Target VersionがBaseであればステップ９１４へ、Target VersionがNewerであればステップ９１８へ分岐する。
【００４９】
ステップ９０９ではETL制御部３０７は、ETL処理定義DB８０１に格納されている対象ETL処理のStatusをReadyに変更する。ステップ９１０でETL制御部３０７は、対象ETL処理と対象データ（Data SourceとData Categoryのペア）が同一かつTarget VersionがBaseのETL処理をETL処理定義DB８０１から検索し、存在すればステップ９１１へ、存在しなければステップ９１２に分岐する。ステップ９１１ではETL制御部３０７は、ステップ９１０で存在が確認できたETL処理のStatusをReadyに変更する。
【００５０】
ステップ９１２でETL制御部３０７は、対象ETL処理と対象データ（Data SourceとData Categoryのペア）が同一かつTarget VersionがNewerのETL処理をETL処理定義DB８０１から検索し、存在すればステップ９１３へ、存在しなければ処理を終了する。ステップ９１３ではETL制御部３０７は、ステップ９１２で存在が確認できたETL処理のStatusをReadyに変更する。
【００５１】
ステップ９１４ではETL制御部３０７は、ETL処理定義DB８０１に格納されている対象ETL処理のStatusをWaitingに変更する。ステップ９１５でETL制御部３０７は、対象ETL処理と対象データ（Data SourceとData Categoryのペア）が同一かつTarget VersionがNewerのETL処理をETL処理定義DB８０１から検索し、存在すればステップ９１６へ、存在しなければ処理を終了する。ステップ９１６ではETL制御部３０７は、ステップ９１５で存在が確認できたETL処理のStatusをReadyに変更する。
【００５２】
ステップ９１７ではETL制御部３０７は、ETL処理定義DB８０１に格納されている対象ETL処理のStatusをWaitingに変更する。
【００５３】
以上のようにして、実行可否判断リクエストに対しては、ステータスが待機中（waiting）であれば実行不可を応答し、それ以外のステータスであれば対象ETL処理のIDを応答してそれが実行可能であることを示す。また、実行完了通知リクエストに対しては、実行された対象ETL処理が、対象バージョンが「ソース」のデータ、すなわちデータソース３０１，３０２から得たデータ（すなわち図８では基板ETL処理部３０３による処理対象）であれば、対象ETL処理のみならず、同一のETL処理であって、対象バージョンが「ベース」データ（すなわち共通データ保持部３０４のデータ）および「より新しい」データ（すなわち修正済み共通データ保持部３０６のデータ）についてもステータスを「準備完了」とし、それぞれの対象ETL処理を実行可能とする。また、実行された対象ETL処理が、対象バージョンが「ベース」のデータ、すなわち共通データ保持部３０４から得たデータ（すなわち図８ではアプリETL処理部３１０による処理対象）であれば、対象ETL処理を「待機中」として実行不可とし、一方同一のETL処理であって、対象バージョンが「より新しい」データ（すなわち修正済み共通データ保持部３０６のデータ）についてはステータスを「準備完了」とし、それぞれの対象ETL処理を実行可能とする。また、実行された対象ETL処理が、対象バージョンが「より新しい」データ、すなわち修正済み共通データ保持部３０６から得たデータ（すなわち図８ではアプリETL処理部３１３による処理対象）であれば、対象ETL処理を「待機中」として実行不可とする。このように、ETL処理は、データソースからのデータに対しては常に許可されている。また、共通データ保持部３０４に保存したデータおよび修正済み共通データ保持部３０６に保存したデータに対するETL処理は、それぞれのデータの保存場所に保存されてから一度ずつ許可される。
【００５４】
＜アプリETL処理部３１０、３１３による検証及び修正処理＞
図１０は、本実施形態におけるアプリETL処理部３１０、３１３の動作を示すフローチャートである。なお、フローチャートで示す手順がＲＡＭ２０３,ＲＯＭ２０４,ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００５５】
ステップ１００１ではアプリETL処理部３１０、３１３は、ETL制御部３０７に実行可否判断リクエストを送信する。ステップ１００２ではアプリETL処理部３１０、３１３は、ステップ１００１で送信した実行可否リクエストの戻り値が実行不可、例えば−１であるかどうかを判別し、−１でなければステップ６０１へ、−１であればステップ１００３へ分岐する。ステップ１００３ではアプリETL処理部３１０、３１３は、一定時間待機した後、再度ステップ１００１を実行する。ステップ１００４ではアプリETL処理部３１０、３１３は、ETL制御部３０７に実行完了通知リクエストを送信する。図１０のステップ６０１〜６１０は、図６のステップ６０１〜６１０と同様である。
【００５６】
＜基盤ETL処理部３０３によるデータ更新処理＞
図１１は、本実施形態における基盤ETL処理部３０３の動作を示すフローチャートである。なお、フローチャートで示す手順がＲＡＭ２０３,ＲＯＭ２０４,ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００５７】
図１１のステップ１００１〜１００４は、図１０のステップ１００１〜１００４と同様である。ただし実行主体は基盤ETL処理部３０３となる。図１１のステップ７０１〜７０４は、図７のステップ７０１〜７１０と同様である。
【００５８】
本実施形態により、それぞれの実行順序に依存関係を持っている各ETL処理部の実行順序を適切に制御することが可能となる。
【００５９】
［実施形態３］
前記実施形態で説明したデータ活用システムでは、アプリETL処理部３１０にて検証・修正したデータは共通データ基盤１０３にフィードバックされる。しかし、フィードバックされるデータは、共通データ基盤１０３が管理する他データと異なる形式（圧縮方式や文字コード、ファイルフォーマット）の場合も考えられる。この場合、フィードバックデータを利用しようとするアプリETL処理部３１３は、取得するデータの形式が変わる可能性があり、実装が困難である。また、修正対象レコードがわずかであった場合でも、アプリETL処理部３１０が共通データ基盤１０３から取得したデータ丸ごとフィードバックされる可能性があり、この場合冗長なデータが共通データ基盤１０３上に大量に存在することになる。そこで、本実施形態では、フィードバックデータを適切な形式に変換する機構を設け、適切な形式で適切な部分（あるいは必要な部分）だけ保持するようにする。
【００６０】
図１２は、本実施形態におけるデータ活用システムが持つ各機能を表すコンポーネント図である。各機能は、プログラムまたはデータをＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで保持し、必要に応じてＲＡＭ２０３に読み出し、CPU２０２にて実行されるものとする。
【００６１】
修正データ変換部１２０１は、共通データ保持部３０７内のデータとフィードバックデータを比較し、差分だけ抽出する機能を有する。また、修正データ変換部１２０１は、修正データ受付部３０５から受け取ったデータを共通データ基盤として定める形式（圧縮形式、文字コード、ファイルフォーマット）に変換する機能をも有する。本実施形態においては、修正データ受付部３０５は、修正データ変換部１２０１を内包する。修正データ受付部３０５は、アプリETL処理部３１０から受け取ったフィードバックデータを修正データ変換部１２０１にて処理させた後で、修正済み共通データ保持部３０６に保存し、ETL制御部３０７にその旨通知する機能を有する。図１２の３０１〜３０４、３０６〜３１５、８０１は、図８と同様である。
【００６２】
＜修正データ受付部３０５による修正済みデータの保存＞
図１３は、本実施形態において修正データ受付部３０５がアプリETL処理部３１０からアクセスされた場合の動作を示すフローチャートである。なお、フローチャートで示す手順がＲＡＭ２０３,ＲＯＭ２０４,ＨＤＤ２０５のいずれかの記憶手段に記憶され、ＣＰＵにより実行される。
【００６３】
図１３のステップ５０１〜５０２は、図５のステップ５０１〜５０２と同様である。ステップ１３０１では、修正データ受付部３０５はステップ５０２で実施したデータ配置情報更新リクエストの結果、例外が発生したかどうかを判定し、例外が発生していなければステップ１３０２を実行し、例外が発生していれば処理を終了する。ここで、ステップ１３０２〜１３０５の処理は、修正データ受付部３０５が修正データ変換部１２０１を呼び出して実行する処理である。
【００６４】
ステップ１３０２では、修正データ受付部３０５がステップ５０１で受け取った表１のData Source、Data Category、Dateに該当するパラメータを用いて、修正データ変換部１２０１がETL制御部３０７にVersion1のデータのURIを要求し取得する。ステップ１３０３では修正データ変換部１２０１が、ステップ１３０２で取得したURIにある元データとステップ５０１で修正データ受付部３０５が受け取った修正データを比較する。ステップ１３０４では修正データ変換部１２０１が、ステップ１３０３で比較した結果、結果元データから変更された修正データのみを差分として抽出する。ステップ１３０５では修正データ変換部１２０１が、ステップ１３０４で抽出した差分データの文字コードやフォーマット、圧縮形式などを、共通データ基盤１０３で定められた形式に変換する。ステップ１３０６では、修正データ受付部３０５がステップ５０２にて生成した修正済み共通データ保持部３０６上のデータ配置先予定URIに、ステップ１３０５で変換したデータを配置する。
【００６５】
本実施形態により、共通データ基盤１０３がアプリETL処理部からフィードバックされたデータを、利用する他のアプリETL処理部が使いやすいように共通データ基盤の他のデータと同じ形式で、余分な重複データを含むことなく効率的に配置することが可能となる。
【００６６】
以上のように、データ分析・活用を行うために、共通データ基盤から取得したデータを検証あるいは適切な形に加工して共通基盤にフィードバックしたい場合、例えば、データの性質上、機密度、セキュリティ方針、取りつかい規約などの理由で共通データ基盤には配置できないデータを利用して共通データ基盤上に配置したデータを検証・修正する場合がある。そのような場合にも、上記それぞれの実施形態に係る発明によれば、修正済みのデータと、修正前の当該データとをそれぞれ別々に管理保存することで、修正前後のデータを利用可能となる。これによって、たとえば「精度が悪いデータが上がってくる割合」を検討したい場合など、修正前のデータを取得したい場合には、修正前のデータを利用でき、精度の高いデータを利用したい場合には、修正後のデータを利用することができる。
【００６７】
［その他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００６８】
１０１...データソース、１０２...データソース、１０３...共通データ基盤、１０４...非共有データ管理サーバー、１０５...分析サーバー、１０６...分析サーバー
【図１】
2016009263.tif 000007
【図２】
2016009263.tif 000008
【図３】
2016009263.tif 000009
【図４】
2016009263.tif 000010
【図５】
2016009263.tif 000011
【図６】
2016009263.tif 000012
【図７】
2016009263.tif 000013
【図８】
2016009263.tif 000014
【図９】
2016009263.tif 000015
【図１０】
2016009263.tif 000016
【図１１】
2016009263.tif 000017
【図１２】
2016009263.tif 000018
【図１３】
2016009263.tif 000019