特開 2024-139155 データウェアハウス

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024139155

(43)【公開日】2024-10-09

(54)【発明の名称】データウェアハウス

(51)【国際特許分類】

   G06Q 40/06 20120101AFI20241002BHJP

【ＦＩ】

G06Q40/06

【審査請求】未請求

【請求項の数】4

【出願形態】ＯＬ

(21)【出願番号】P 2023049973

(22)【出願日】2023-03-27

(71)【出願人】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100216677

【弁理士】

【氏名又は名称】坂次 哲也

(72)【発明者】

【氏名】安藤 隆浩

(72)【発明者】

【氏名】花田 秀隆

(72)【発明者】

【氏名】浅場 雅司

(72)【発明者】

【氏名】林 哲浩

(72)【発明者】

【氏名】藤井 航介

【テーマコード（参考）】

5L040

5L055

【Ｆターム（参考）】

5L040BB57

5L055BB57

(57)【要約】

【課題】資産運用業務に係る管理システム等において各種データソースから取得したデータのコードを統一的に扱えるようにする。
【解決手段】複数の外部データソース２からデータを取得して素ＤＢ４１に格納するデータ取得部１０と、素ＤＢ４１に格納されたデータを標準データに加工して標準ＤＢ４２に格納する標準データ作成部２０と、標準ＤＢ４２に格納されたデータからデータ提供先３に応じた業務用データを作成して業務用ＤＢ４３に格納する業務用データ作成部３０とを有し、標準ＤＢ４２は、銘柄コードテーブルと銘柄コードリファレンステーブルとを有し、標準データ作成部２０は、データソース毎に同一銘柄には同一の統一銘柄コードを発番して銘柄コードテーブルにレコードを作成し、データソースを横断して同一銘柄には同一の統一銘柄コードリファレンスを発番して銘柄コードリファレンステーブルにレコードを作成する。
【選択図】図１

【特許請求の範囲】

【請求項1】

資産運用業務に係るデータウェアハウスであって、
資産運用業務に係る複数のデータソースからデータを取得して、レイアウトおよびフォーマットを維持して第１のデータベースに格納するデータ取得部と、
前記第１のデータベースに格納されたデータを、データソース毎の差異がない標準データに加工して第２のデータベースに格納する標準データ作成部と、
前記第２のデータベースに格納されたデータから、データの提供先における資産運用業務の目的に応じた業務用データを作成して第３のデータベースに格納する業務用データ作成部と、を有し、
前記第２のデータベースは、
データソースの種類、コードの種類、コード、および統一コードの値をそれぞれ保持する項目を少なくとも有するコードテーブルと、統一コードリファレンス、および統一コードの値をそれぞれ保持する項目を少なくとも有するコードリファレンステーブルと、を有し、
前記標準データ作成部は、
前記第１のデータベース内のデータについて、データソース毎に、コードが付与されている対象要素について同一の対象要素であると識別したものには同一の前記統一コードを発番して前記コードテーブルにレコードを作成し、
前記統一コードが付与された対象要素について、データソースを横断して同一の対象要素であると識別したものには同一の前記統一コードリファレンスを発番して前記コードリファレンステーブルにレコードを作成する、データウェアハウス。

【請求項2】

請求項１に記載のデータウェアハウスにおいて、
前記対象要素は銘柄、発行体、およびポートフォリオのいずれかである、データウェアハウス。

【請求項3】

請求項２に記載のデータウェアハウスにおいて、
前記標準データ作成部は、
前記第１のデータベース内のデータについて、データソース毎に、同一の銘柄であると識別したものにつき、資産運用業務の目的に応じてデータソース毎に設定された優先順位に基づいて決定したデータソースにおける銘柄属性を、当該銘柄に係る前記統一コードリファレンスと関連付けてマスタデータとして前記第３のデータベースに格納する、データウェアハウス。

【請求項4】

請求項１に記載のデータウェアハウスにおいて、
前記第２のデータベースは、
ベンチマークとポートフォリオとの関連を保持するテーブルを、前記ベンチマークの階層に応じて階層構造として有する、データウェアハウス。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、資産運用業務を支援する技術に関し、特に、各業務アプリケーションやシステムに対して共通のデータ共有基盤となるデータウェアハウスに適用して有効な技術に関するものである。

【背景技術】

【0002】

資産運用会社では資産運用業務を行うためにポートフォリオ管理システムが用いられる場合がある。一般的なポートフォリオ管理システムでは、投資信託／投資顧問口座の基幹系バックオフィスシステムや外部情報ベンダーシステムのデータソース毎に採番された固有銘柄コードが接続される結果、同一銘柄でもデータソースの違いによって異なる銘柄コードが格納・管理されている。

【0003】

資産運用会社全体において、投資信託／投資顧問口座を横断した同一銘柄の保有比率等のモニタリングや、同一銘柄に対して外部情報ベンダーシステムが提供する銘柄特性情報（市場時価等）を関連付けした運用報告書を作成する業務等において、各種データソースの固有銘柄コードを同一銘柄として取り扱いたい場合、ＩＳＩＮ（International Securities Identification Number）コードや証協コード等の既存の規格銘柄コードへマニュアルで変換する業務を行うのが一般的である。

【0004】

銘柄コードの変換に関して、例えば、特開２０１８－６０５４３号公報（特許文献１）には、ファンドの運用状況を管理する金融商品管理システムにおいて、クライアント端末から残高データ等がアップロードされた際に、それぞれの銘柄に設定されているＩＳＩＮコードやＳＥＤＯＬ（Stock Exchange Daily Official List）コード等の外部コードを用いて、複数の銘柄が業務的に同一なものか否かを判断し、業務的に同一と判断される銘柄コードを、自社の銘柄コード体系（バックオフィスシステム等で利用している既存のコード体系）に変換して統一することが記載されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１８－６０５４３号公報

【発明の概要】

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

【0006】

特許文献１等の従来技術によれば、ＩＳＩＮコードや証協コード等の規格銘柄コードを基準に同一銘柄か否かを判断し、自社の銘柄コード体系（もしくは規格銘柄コード）に変換して統一することが可能である。

【0007】

しかしながら、例えば、規格銘柄コードを媒介として、投資信託／投資顧問口座のバックオフィスシステムでの固有銘柄コードを外部情報ベンダーシステムの固有銘柄コードと関連付ける（もしくは変換する）場合、コーポレートアクション等による規格銘柄コードの変更の履歴情報や、規格銘柄コード以外の上場市場（国、通貨）を考慮した銘柄の識別が十分に行えない結果、外部情報ベンダーシステムから誤った銘柄属性情報（例えば、市場時価等）を取得してしまう等の業務上のミスが発生し易い状況となっている。このようなコードの識別に係る業務ミスは、銘柄コード以外にも、発行体（企業）コードやポートフォリオコード、国コード、通貨コード等でも同様に発生し得る。

【0008】

そこで本発明の目的は、資産運用業務に係る管理システム等において各種データソースから取得したデータのコードを統一的に扱えるようにするデータウェアハウスを提供することにある。

【0009】

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

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

【0010】

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

【0011】

本発明の代表的な実施の形態によるデータウェアハウスは、資産運用業務に係るデータウェアハウスであって、資産運用業務に係る複数のデータソースからデータを取得して、レイアウトおよびフォーマットを維持して第１のデータベースに格納するデータ取得部と、前記第１のデータベースに格納されたデータを、データソース毎の差異がない標準データに加工して第２のデータベースに格納する標準データ作成部と、前記第２のデータベースに格納されたデータから、データの提供先における資産運用業務の目的に応じた業務用データを作成して第３のデータベースに格納する業務用データ作成部と、を有し、前記第２のデータベースは、データソースの種類、コードの種類、コード、および統一コードの値をそれぞれ保持する項目を少なくとも有するコードテーブルと、統一コードリファレンス、および統一コードの値をそれぞれ保持する項目を少なくとも有するコードリファレンステーブルと、を有するものである。

【0012】

そして、前記標準データ作成部は、前記第１のデータベース内のデータについて、データソース毎に、コードが付与されている対象要素について同一の対象要素であると識別したものには同一の前記統一コードを発番して前記コードテーブルにレコードを作成し、前記統一コードが付与された対象要素について、データソースを横断して同一の対象要素であると識別したものには同一の前記統一コードリファレンスを発番して前記コードリファレンステーブルにレコードを作成する。

【発明の効果】

【0013】

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

【0014】

すなわち、本発明の代表的な実施の形態によれば、資産運用業務に係る管理システム等において各種データソースから取得したデータのコードを統一的に扱うことが可能となる。

【図面の簡単な説明】

【0015】

【図1】本発明の一実施の形態であるデータウェアハウスの構成例について概要を示した図である。

【図2】従来技術における取引残高と銘柄属性のデータから運用報告書を作成する例について概要を示した図である。

【図3】本発明の一実施の形態における取引残高と銘柄属性のデータから運用報告書を作成する例について概要を示した図である。

【図4】本発明の一実施の形態における銘柄コードリファレンスに関連するテーブルの構成例について概要を示したＥＲ図である。

【図5】本発明の一実施の形態における銘柄コードリファレンスに関連する各テーブルの具体的なデータの例について概要を示した図である。

【図6】本発明の一実施の形態における国コードリファレンスに関連するテーブルの構成例について概要を示したＥＲ図である。

【図7】本発明の一実施の形態における国コードリファレンスに関連する各テーブルの具体的なデータの例について概要を示した図である。

【図8】本発明の一実施の形態における銘柄マスタに関連するテーブルの構成例について概要を示したＥＲ図である。

【図9】本発明の一実施の形態における銘柄マスタに関連する各テーブルの具体的なデータの例について概要を示した図である。

【図10】本発明の一実施の形態におけるベンチマークポートフォリオに関連するテーブルの構成例について概要を示したＥＲ図である。

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

【0016】

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

【0017】

＜概要＞
資産運用業務では、取引残高のデータに各種の外部システムから取得した銘柄属性のデータを付与して様々な帳票を作成している。しかし、取引残高のデータに含まれている銘柄コードと、各種の外部システムから取得した銘柄属性のデータにおける銘柄コードとが異なった種類のものであることが多々ある。そのため、資産運用業務の現場では、手作業で取引残高と銘柄属性とを関連付けた上で各種帳票を作成しているのが現状である。

【0018】

図２は、従来技術における取引残高と銘柄属性のデータから運用報告書を作成する例について概要を示した図である。図中の左端の矩形はそれぞれデータソース（データの接続元）を示している。例えば、自社の投資信託バックオフィスシステムや投資顧問バックオフィスシステム、他社のバックオフィスシステム、Ｂｌｏｏｍｂｅｒｇ（登録商標、以下同様）などの外部情報ベンダーシステムなどが示されている。

【0019】

従来、例えば、自社のバックオフィスシステムから取得した取引残高および銘柄属性のデータにおける銘柄コードに対して、外部情報ベンダーシステムの銘柄属性のデータにおける銘柄コードを手作業で関連付けていた。他社バックオフィスシステムの取引残高のデータについては、データソース毎にユニークな銘柄コードを発番した上で、同様に外部情報ベンダーシステムの銘柄属性のデータにおける銘柄コードを手作業で関連付けていた。そして、各バックオフィスシステムの取引残高データと、関連付けられた外部情報ベンダーシステムの銘柄コードを使用して、運用報告書を作成していた。このような流れの場合、各バックオフィスシステムの銘柄コードに対して外部情報ベンダーシステムの銘柄コードを関連付ける作業以降を人が手作業で行う必要があり、手作業での作業範囲は広いものとなっていた。

【0020】

これに対し、図３は、本発明の一実施の形態における取引残高と銘柄属性のデータから運用報告書を作成する例について概要を示した図である。図２と同様に、図中の左端の矩形はそれぞれデータソースを示している。本実施の形態では、自社・他社のバックオフィスシステムやフロントオフィスシステム、外部情報ベンダーシステムから取得した銘柄属性のデータにおける銘柄コードに対して、データソース毎にユニークな統一銘柄コードを発番して銘柄コードテーブルに格納し、全ての銘柄コードを一元的に管理する。そして、銘柄コードや国・通貨コードを参照して同一の銘柄を識別し、識別された同一のものについて銘柄コード間の関連付け（クロスリファレンス）を作成して銘柄コードリファレンステーブルに格納する。

【0021】

そして、自社・他社のバックオフィスシステムから取得した取引残高のデータに対して、銘柄コードリファレンステーブルに基づいてそれぞれのシステムにおける銘柄コードに関連付けられた外部情報ベンダーシステムの銘柄コードを関連付け、取引残高のデータとこの銘柄コードを使用して、運用報告書を作成する。このような流れの場合、取引残高のデータに対する外部情報ベンダーシステムの銘柄コードの関連付けまでは、本実施の形態のデータウェアハウスが行うことになり、運用報告書の作成のみ手作業で行えばよく、手作業での作業範囲を大幅に小さくすることができる。

【0022】

すなわち、本実施の形態のデータウェアハウスは、資産運用業務におけるデータの一元管理において、上述したように、各種データソースの銘柄コードを関連付け、データに関連性（クロスリファレンス）・統一性（統一コード）を持たせることで、データソース単独のデータでは得られなかった付加価値を付与することを可能とする。そして、本実施の形態では、銘柄コードに限らず各種データソースの多種多様なコードを関連付けるために必要となるクロスリファレンスと統一コードを、一定の条件の下、日々のトランザクションデータから自動生成する。

【0023】

具体的には、各種データソース毎にユニークなコード（銘柄コード、発行体コード、ポートフォリオコード）を発番する。銘柄コードについては、基幹系バックオフィスシステム（他社ベンダー含む）における銘柄属性データもしくはトランザクションデータ（取引・残高データ）を起点に発番する。また、発行体コードおよびポートフォリオコードについては、基幹系バックオフィスシステム（他社ベンダー含む）における発行体属性データおよびポートフォリオ属性データを起点にそれぞれ発番する。

【0024】

そして、データソース毎の銘柄コードについてクロスリファレンスを生成してその変更履歴を管理する。すなわち、基幹系バックオフィスシステムを起点としたデータソース毎の「統一銘柄コード」を発番して管理し、これに、ＩＳＩＮコード等の規格銘柄コードと通貨・国コードに基づいて同一であることを識別した外部情報ベンダーシステムの銘柄コード（例えば、ＢｌｏｏｍｂｅｒｇでのＢＢＧＩＤ（ブルームバーググローバルＩＤ））とを関連付け（クロスリファレンス）する。

【0025】

本実施の形態のデータウェアハウスは、基幹系バックオフィスシステム（他社ベンダー含む）や外部情報ベンダーシステムから定期的に接続してデータを取得することで、規格銘柄コードや外部情報ベンダーシステムの銘柄コード、銘柄属性（銘柄名称等）が変更されたことを検知した場合、新旧の銘柄コード等の情報を履歴として保持して管理するとともに、上記のクロスリファレンスにも自動的に反映させる。さらに本実施の形態では、銘柄マスタテーブルに保持する銘柄属性にも銘柄名称等の変更を履歴とともに自動的に反映する。

【0026】

さらに本実施の形態のデータウェアハウスは、銘柄コードについての上記のような統一コードおよびクロスリファレンスの仕組みを、発行体コードやポートフォリオコードについても適用し、これらのコードの統一コードや、マスタテーブルにおける属性情報を自動的に生成することも可能である。

【0027】

＜システム構成＞
図１は、本発明の一実施の形態であるデータウェアハウスの構成例について概要を示した図である。データウェアハウス１は、上述したように、各種の外部データソース２から取得したデータを一元的に管理するとともに、資産運用業務を行うポートフォリオ管理システムなどの各種のデータ提供先３にそれぞれ利用可能な形でデータを整備して提供するデータ共有基盤としての機能を有する情報処理システムである。

【0028】

データウェアハウス１は、例えば、１つ以上のサーバ機器もしくはクラウドコンピューティングサービス上に構築された１つ以上の仮想サーバ等により実装され、図示しないＣＰＵ（Central Processing Unit）により、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の記録装置からメモリ上に展開したＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェアや、その上で稼働するソフトウェアを実行することで、上述したデータ共有基盤としての各種機能などを実現する。

【0029】

このデータウェアハウス１は、例えば、ソフトウェアとして実装されたデータ取得部１０、標準データ作成部２０、および業務用データ作成部３０などの各部を有する。また、データベースとして実装された素データベース（ＤＢ）４１、標準ＤＢ４２、および業務用ＤＢ４３などの各データストアを有する。なお、これらの他に、例えば図示しないユーザインタフェース機能や各種管理機能（ユーザ管理、ログ管理、稼働制御機能など）を有していてもよい。

【0030】

データ取得部１０は、基幹系バックオフィスシステム（他社ベンダー含む）や外部情報ベンダーシステムなどの外部データソース２からデータを取得する機能を有する。これらのシステムと図示しないネットワークを介して接続してデータの転送やアップロードを受ける構成であってもよいし、表計算ソフト等により作成されたユーザデータを取得する機能を有していてもよい。

【0031】

取得したデータは、対象の外部データソース２でのレイアウトおよびフォーマットのまま素データとして素ＤＢ４１に格納し、ユーザに開示可能とする。すなわち、接続対象の外部データソース２のデータと、素ＤＢ４１での格納先のテーブルおよび項目のマッピングは１対１とし、他データとの依存関係も持たないものとする。これにより、データの取得から開示までを迅速化して即時性の高いデータ開示を可能にするとともに、外部データソース２との接続仕様を単純化することでデータの追加や項目変更に容易に対応することを可能とする。

【0032】

標準データ作成部２０は、複数の外部データソース２から取得した素データを、データウェアハウス１における標準のレイアウトに加工／クレンジングする機能を有する。加工／クレンジングして得た標準データは、標準ＤＢ４２に格納し、ユーザに開示可能とする。標準データに加工等してデータソースによる差異を排除することで、複数の外部データソース２のデータについて一元管理を容易とし、データの品質向上を図ることができる。

【0033】

上記のような機能を実現するため、標準データ作成部２０は、例えばさらに、コードリファレンス作成部２１およびマスタ管理部２２などの各部を有する。コードリファレンス作成部２１は、例えば、同一銘柄であっても各外部データソース２によって異なる銘柄コードなどの各種コードについて、各外部データソース２のコード間の関連付け（クロスリファレンス）を行う機能を有する。コードリファレンスの構成や作成手法等については後述する。

【0034】

マスタ管理部２２は、複数のデータソースから取得した素データにおいて、同じデータであってもデータソース毎に表示形式や記載が異なる銘柄属性や発行体属性、国や通貨などのデータについて、各データソースのレコードを１つのレコードに束ねてマスタデータを生成する機能を有する。このとき、銘柄名など複数のデータソースのレコードに存在する項目については、事前に登録されたデータソース毎の優先順位に基づいてマスタデータとする値を決定する。マスタデータの管理手法等についても後述する。

【0035】

業務用データ作成部３０は、標準ＤＢ４２に格納された標準データを入力として、非正規化するなどにより各データ提供先３でのそれぞれの業務の用途別に適した業務用データを生成する機能を有する。例えば、対象のデータ提供先３毎に、標準ＤＢ４２の標準データから業務用データを生成するプログラム等を予め設定しておく等することができる。生成した業務用データは業務用ＤＢ４３に格納し、ユーザ（データ提供先３）に開示可能とする。データ提供先３での業務用途別にフォーマットや作成タイミングなどが異なるデータを作成して保持することで、他の業務に影響を与えずに出力項目等を変更することができるなど柔軟な対応をすることが可能となる。

【0036】

上述したように、本実施の形態のデータウェアハウス１では、素ＤＢ４１、標準ＤＢ４２、および業務用ＤＢ４３の３階層の構成でデータを保持している。素データや業務データは変更が入りやすいため、それぞれの変更を吸収する緩衝用として標準データの層を設けている。このような構成とすることで、業務スピードを確保しつつ、複数のデータ提供先３がデータを共有することを可能とする。

【0037】

＜コードリファレンス（銘柄コード）＞
図４は、本発明の一実施の形態における銘柄コードリファレンスに関連するテーブルの構成例について概要を示したＥＲ（Entity Relationship）図である。また、図５は、図４の各テーブルの具体的なデータの例について概要を示した図である。

【0038】

図４において、素データ（素ＤＢ４１）における複数のデータソース毎の銘柄属性のテーブルの例として、バックオフィスシステム、外部情報ベンダーの銘柄属性テーブル、およびベンチマーク構成銘柄のテーブルが示されている。これら各テーブルは、銘柄の属性情報に係るデータ項目として、例えば、各データソースでの独自の銘柄コードと、データ基準日（適用開始日）、ＩＳＩＮコードやＣＵＳＩＰ（Committee on Uniform Securities Identification Procedures）番号などのコードの項目をそれぞれ保持している。

【0039】

図５の上段の表では、バックオフィスシステムの銘柄属性のテーブルの具体例として、バックオフィスシステム「ＴＸ」の銘柄属性のテーブルの例が示されており、ある銘柄について「ＴＸ」で管理されている銘柄コードが「ＴＸ１」であり、ＩＳＩＮコードが「ＩＳＩＮ１」であることが示されている。また、外部情報ベンダーの銘柄属性テーブルの具体例としてＢｌｏｏｍｂｅｒｇの銘柄属性のテーブルの例が示されており、ある銘柄についてのＢＢＧＩＤが「ＢＢＧ１」、ＩＳＩＮコードが「ＩＳＩＮ１」、ＣＵＳＩＰ番号が「ＣＵＳＩＰ１」であることが示されている。また、ベンチマーク構成銘柄のテーブルの具体例としてＭＳＣＩ（モルガン・スタンレー（登録商標、以下同様）・キャピタル・インターナショナル）指数の構成銘柄のテーブルの例が示されており、ある銘柄についてＭＳＣＩ銘柄コードが「ＭＳＣＩ１」、ＣＵＳＩＰ番号が「ＣＵＳＩＰ１」であることが示されている。

【0040】

図４に戻り、本実施の形態では、標準データ（標準ＤＢ４２）において、データソース毎の銘柄コードを統一的に管理する銘柄コードテーブル４２ａを有している。上述した素データにおける各テーブルと銘柄コードテーブル４２ａとは図示するような関係にある。銘柄コードテーブル４２ａは、例えば、データソース名、銘柄コード種類、銘柄コード、適用開始日／終了日、および統一銘柄コードなどの各項目を有する。ここで、統一銘柄コードとは、データソース毎に、その中での複数の銘柄コードの種類（例えば、独自の銘柄コードやＩＳＩＮコード、ＣＵＳＩＰ番号等）間で統一したものとして発番した銘柄コードである。

【0041】

図５の中段の表では、銘柄コードテーブル４２ａの具体例が示されている。ここでは、図の上段のバックオフィスシステム「ＴＸ」の銘柄属性テーブル、Ｂｌｏｏｍｂｅｒｇの銘柄属性テーブル、およびＭＳＣＩ構成銘柄のテーブルにおいてそれぞれ個別のカラムとしていわゆる「横持ち」になっている銘柄コード（システム固有の銘柄コードやＩＳＩＮコード、ＣＵＳＩＰ番号などの規格銘柄コード等）を、個別のレコードとして「縦持ち」にしている。すなわち、各レコードについて、データソース名と銘柄コード種類のカラムによって、どのデータソースにおいて保持されている何の銘柄コードかを識別可能とし、銘柄コードのカラムで実際に設定されているコードの値を保持している。

【0042】

そして、実体は同一の銘柄である銘柄コードには、データソース毎にユニークとなる統一銘柄コードを発番している。例えば、図中の上から２行のレコード（データソース名がバックオフィスシステム「ＴＸ」のレコード）は、それぞれ異なる２種類の銘柄コードを有しているが、実体は「ＴＸ」内では同一の銘柄を示すものであることから、同じ「Ｃ１」という統一銘柄コードが付与されていることを示している。ＢｌｏｏｍｂｅｒｇやＭＳＣＩ構成銘柄についても同様に、Ｂｌｏｏｍｂｅｒｇ内で同一の銘柄を示すものには同じ「Ｃ２」という統一銘柄コードが付与され、ＭＳＣＩ構成銘柄内で同一の銘柄を示すものには同じ「Ｃ３」という統一銘柄コードが付与されていることを示している。

【0043】

図４に戻り、本実施の形態では、上記の銘柄コードテーブル４２ａに対して、さらに銘柄コード間の関連性を分離して管理する銘柄コードリファレンステーブル４２ｂを有する。銘柄コードテーブル４２ａと銘柄コードリファレンステーブル４２ｂとは図示するような関係にある。銘柄コードリファレンステーブル４２ｂは、例えば、統一銘柄コードリファレンス、および統一銘柄コードなどの各項目を有する。

【0044】

図５の下段の表では、銘柄コードリファレンステーブル４２ｂの具体例が示されている。ここでは、図の中段の銘柄コードテーブル４２ａの各レコードについて、データソースを横断して（すなわちデータウェアハウス１内において）実体として同一の銘柄を示すものについて、ユニークとなる統一銘柄コードリファレンスを発番し、これに各データソースでの対象銘柄の統一銘柄コードを関連付けている。

【0045】

同一の銘柄であるか否かは、例えば、Ｂｌｏｏｍｂｅｒｇの銘柄属性（銘柄コードテーブル４２ａにおけるデータソース名が「ＢＢＧ」のレコード）を基準とし、これと同じ銘柄コードを有するものを同一銘柄であると判断する。図５の例では、データソース名「ＢＢＧ」（統一銘柄コード「Ｃ２」）におけるＩＳＩＮコード「ＩＳＩＮ１」と、データソース名「ＴＸ」（統一銘柄コード「Ｃ１」）におけるＩＳＩＮコード「ＩＳＩＮ１」が同じであることから、統一銘柄コード「Ｃ１」と「Ｃ２」の各レコードは同一銘柄であると判断する。同様に、データソース名「ＢＢＧ」におけるＣＵＳＩＰ番号「ＣＵＳＩＰ１」と、データソース名「ＭＳＣＩ」（統一銘柄コード「Ｃ３」）におけるＣＵＳＩＰ番号「ＣＵＳＩＰ１」が同じであることから、統一銘柄コード「Ｃ１」と「Ｃ３」の各レコードも同一銘柄であると判断する。

【0046】

銘柄コードリファレンステーブル４２ｂでは、同一銘柄であると判断されたこれらの統一銘柄コード「Ｃ１」、「Ｃ２」、「Ｃ３」に対して、同じ統一銘柄コードリファレンス「ＣＲ１」が発番されたことを示している。このように、銘柄コードテーブル４２ａと、銘柄コードリファレンステーブル４２ｂを分離して管理することで、新しい銘柄コードの追加や既存の銘柄コードの修正の際の影響範囲を極小化することができ、これらの作業を容易に行うことが可能となる。

【0047】

なお、図４、図５の例では、各データソースの銘柄属性のデータから統一銘柄コードを発番して銘柄コードテーブル４２ａを生成しているが、取引残高などのトランザクションデータから生成するように構成することも可能である。

【0048】

また、例えば一部の私募債等、Ｂｌｏｏｍｂｅｒｇの銘柄属性から銘柄コードを取得することができない非上場銘柄については、対象のデータソースにおける固有の銘柄コードを用いて統一銘柄コードを発番するようにしてもよい。これにより、例えば、非上場銘柄（店頭市場銘柄）の為替予約について、為替オーバーレイポートフォリオで一括して運用会社として発注し、各ファンドにアロケーションするというような場合にも、発注システムでの銘柄コードにより発番された統一銘柄コードによって、ファンド横断で同一の為替予約取引の発注であることを識別することが可能となる。

【0049】

銘柄コードテーブル４２ａにおいて、各レコードに適用開始日／終了日の情報を保持することで、例えば、外部データソース２において銘柄コードの追加・削除や修正がされた場合に、対象の銘柄コードのレコードを上書きするのではなく別レコードで履歴として保持（バージョン管理）する。これにより、例えば、過去の任意の時点での銘柄コードの値を遡って参照できるとともに、将来銘柄コードが変更されるタイミングで自動的に新しい銘柄コードに切り替えることも可能である。

【0050】

＜コードリファレンス（国コード）＞
図６は、本発明の一実施の形態における国コードリファレンスに関連するテーブルの構成例について概要を示したＥＲ図である。また、図７は、図６の各テーブルの具体的なデータの例について概要を示した図である。本実施の形態では、国コードや通貨コードについても、上述した銘柄コードにおけるコードリファレンスの構成や手法に従って統一的に管理する。

【0051】

上述の図４の例と同様に、図６において、素データ（素ＤＢ４１）における複数のデータソース毎の銘柄属性のテーブルの例として、バックオフィスシステム、トレーディング業務システム、外部情報ベンダーの銘柄属性テーブル、およびベンチマーク構成銘柄のテーブルが示されている。これら各テーブルは、銘柄の属性情報に係るデータ項目として、例えば、各データソースでの独自の国コードと、データ基準日（適用開始日）、国名などの項目をそれぞれ保持している。

【0052】

図７の上段の表では、バックオフィスシステムの銘柄属性のテーブルの具体例として、バックオフィスシステム「ＴＸ」の銘柄属性のテーブルの例が示されており、ある国について「ＴＸ」で管理されている国コードが「ＴＸ１」であり、国名が「ＵＳＡ」であることが示されている。また、トレーディング業務システムの具体例として、トレーディングシステム「ＳＢＡ」の銘柄属性のテーブルの例が示されており、ある国について「ＳＢＡ」で管理されている国コードが「ＳＢＡ１」であり、国名が「Ｕ．Ｓ．Ａ．」であることが示されている。また、外部情報ベンダーの銘柄属性テーブルの具体例としてＢｌｏｏｍｂｅｒｇの銘柄属性のテーブルの例が示されており、ある国についてＢｌｏｏｍｂｅｒｇでの国コードが「ＢＢＧ１」であり、国名が「Ｕ Ｓ Ａ」であることが示されている。また、ベンチマーク構成銘柄のテーブルの具体例としてＭＳＣＩ指数の構成銘柄のテーブルの例が示されており、ある国についてＩＳＯ（国際標準化機構）の国名コードが「ＵＳＤ」であり、ＭＳＣＩでの国名が「アメリカ」であることが示されている。

【0053】

図６に戻り、本実施の形態では、上述の図４の例と同様に、標準データ（標準ＤＢ４２）において、データソース毎の国コードを統一的に管理する国属性テーブル４２ｃを有している。上述した素データにおける各テーブルと国属性テーブル４２ｃとは図示するような関係にある。国属性テーブル４２ｃは、例えば、データソース名、国コード、適用開始日／終了日、国名称、および統一国コードなどの各項目を有する。ここで、統一国コードとは、データソース毎にある国についてユニークなものとして発番した国コードである。

【0054】

図７の中段の表では、国属性テーブル４２ｃの具体例が示されている。ここでは、図の上段のバックオフィスシステム「ＴＸ」の銘柄属性テーブル、トレーディングシステム「ＳＢＡ」の銘柄属性テーブル、Ｂｌｏｏｍｂｅｒｇの銘柄属性テーブル、およびＭＳＣＩ構成銘柄のテーブルにおいてそれぞれ保持している国コードを、国名称とともに個別のレコードとして保持している。そして、各国コードに対してデータソース毎にユニークとなる統一国コードを発番している。国コードの場合、上述した銘柄コードの場合と異なり、ある国についてデータソース単位では１つのレコードのみとなり、その各レコードにユニークな統一国コード（図中の例では「Ｃ１」～「Ｃ４」）が付与されていることを示している。

【0055】

図６に戻り、本実施の形態では、上記の国属性テーブル４２ｃに対して、さらに国コード間の関連性を分離して管理する国コードリファレンステーブル４２ｄを有する。国属性テーブル４２ｃと国コードリファレンステーブル４２ｄとは図示するような関係にある。国コードリファレンステーブル４２ｄは、例えば、統一国コードリファレンス、および統一国コードなどの各項目を有する。

【0056】

図７の下段の表では、国コードリファレンステーブル４２ｄの具体例が示されている。ここでは、図の中段の国属性テーブル４２ｃの各レコードについて、データソースを横断して（すなわちデータウェアハウス１内において）同一の国を示すものについて、ユニークとなる統一国コードリファレンスを発番し、これに各データソースでの対象国の統一国コードを関連付けている。なお、同一の国であるか否かの判断は、国名称や通貨コード、通貨名などに基づいてシステムが自動的に判断してもよいし、手動で設定・定義するようにしてもよい。

【0057】

そして、図７の国コードリファレンステーブル４２ｄでは、同一の国に係る統一国コード「Ｃ１」～「Ｃ４」に対して、同じ統一国コードリファレンス「ＣＮ１」が発番されたことを示している。このように、国属性テーブル４２ｃと、国コードリファレンステーブル４２ｄを分離して管理することで、銘柄コードと同様に、新しい国コードの追加や既存の国コードの修正が容易となる。また、標準データから業務データを生成する際に、同一国に係る統一国コードに対して業務毎に優先順位を設定しておくことで、同一国でありながらデータソース毎にそれぞれ異なって設定されている国名称のうち、対象業務においていずれを優先的に使用するかを容易に制御することが可能である。

【0058】

＜マスタデータ更新（銘柄属性）＞
図８は、本発明の一実施の形態における銘柄マスタに関連するテーブルの構成例について概要を示したＥＲ図である。また、図９は、図８の各テーブルの具体的なデータの例について概要を示した図である。本実施の形態では、複数の外部データソース２から送られてくる銘柄属性について、レイアウトや金額単位、日付項目等の表示形式や、通貨、国などのコードを統一して銘柄マスタを生成・更新し、統一的・統合的に管理する。

【0059】

上述の図６の例と同様に、図８において、素データ（素ＤＢ４１）における複数のデータソース毎の銘柄属性のテーブルの例として、バックオフィスシステム、トレーディング業務システム、外部情報ベンダーの銘柄属性テーブル、およびベンチマーク構成銘柄のテーブルが示されている。これら各テーブルは、銘柄の属性情報に係るデータ項目として、例えば、各データソースでの独自の銘柄コードと、データ基準日（適用開始日）、銘柄名などの項目をそれぞれ保持している。

【0060】

図９の上段の表では、バックオフィスシステムの銘柄属性のテーブルの具体例として、バックオフィスシステム「ＴＸ」の銘柄属性のテーブルの例が示されており、ある銘柄について「ＴＸ」で管理されている銘柄コードが「ＴＸ１」であり、銘柄名が「株式会社ＡＢＣ」であることが示されている。また、トレーディング業務システムの具体例として、トレーディングシステム「ＳＢＡ」の銘柄属性のテーブルの例が示されており、ある銘柄について「ＳＢＡ」で管理されている銘柄コードが「ＳＢＡ１」であり、銘柄名が「ＡＢＣ」であることが示されている。また、外部情報ベンダーの銘柄属性テーブルの具体例としてＢｌｏｏｍｂｅｒｇの銘柄属性のテーブルの例が示されており、ある銘柄についてＢｌｏｏｍｂｅｒｇでの銘柄コードが「ＢＢＧ１」であり、銘柄名が「ＡＢＣ Ｌｔｄ．」であることが示されている。また、ベンチマーク構成銘柄のテーブルの具体例としてＭＳＣＩ指数の構成銘柄のテーブルの例が示されており、ある銘柄についてＭＳＣＩでの銘柄コードが「ＭＳＣＩ１」であり、銘柄名が「（株）ＡＢＣ」であることが示されている。

【0061】

図８に戻り、本実施の形態では、標準データ（標準ＤＢ４２）において、データソース毎の銘柄属性を統一的に管理する銘柄マスタテーブル４２ｅを有している。上述した素データにおける各テーブルと銘柄マスタテーブル４２ｅとは図示するような関係にある。銘柄マスタテーブル４２ｅは、例えば、統一銘柄コード、適用開始日／終了日、および銘柄名などの各項目を有する。この統一銘柄コードは、上述の図４、図５の例の銘柄コードテーブル４２ａにおける統一銘柄コードと同内容であり、同様の手法によって発番される。

【0062】

図９の中段の表では、銘柄マスタテーブル４２ｅの具体例が示されている。ここでは、図の上段のバックオフィスシステム「ＴＸ」の銘柄属性テーブル、トレーディングシステム「ＳＢＡ」の銘柄属性テーブル、Ｂｌｏｏｍｂｅｒｇの銘柄属性テーブル、およびＭＳＣＩ構成銘柄のテーブルにおいてそれぞれ保持している銘柄コードに対して発番されたユニークな統一銘柄コード（「Ｃ１」～「Ｃ４」）を、それぞれに対応する銘柄名とともに個別のレコードとして保持している。

【0063】

図８に戻り、本実施の形態では、上記の銘柄マスタテーブル４２ｅに対して、業務データ（業務ＤＢ４３）において、同一銘柄について銘柄属性を統一して統合的に管理する業務目的別銘柄マスタテーブル４２ｆを有する。銘柄マスタテーブル４２ｅと業務目的別銘柄マスタテーブル４２ｆとは図示するような関係にある。業務目的別銘柄マスタテーブル４２ｆは、例えば、統一銘柄コードリファレンス、適用開始日／終了日、および銘柄名などの各項目を有する。この統一銘柄コードリファレンスは、上述の図４、図５の例の銘柄コードリファレンステーブル４２ｂにおける統一銘柄コードリファレンスと同内容であり、同様の手法によって発番される。

【0064】

図９の下段の表では、業務目的別銘柄マスタテーブル４２ｆの具体例が示されている。ここでは、図の中段の銘柄マスタテーブル４２ｅの各レコードについて、データソースを横断して（すなわちデータウェアハウス１内において）同一の銘柄を示すものについて、ユニークとなる統一銘柄コードリファレンスを発番し、対応する銘柄名として、対象の業務目的や金融商品に応じて優先的に採用するデータソースの銘柄名を設定する。

【0065】

例えば、運用報告書作成業務用の銘柄名としてはベンチマーク構成銘柄から取得したものを優先的に採用するものとした場合、ベンチマーク構成銘柄の銘柄名「（株）ＡＢＣ」が銘柄名として設定されることを示している。なお、上記の例でベンチマーク構成銘柄に対象銘柄が含まれていない場合は、予め設定された優先順位が次順位のデータソースにおける銘柄名を採用するようにしてもよい。また、クーポンなど業務目的による差異がないような銘柄属性項目については、複数の業務で共通的に用いる金融商品別属性として管理するようにしてもよい。

【0066】

本実施の形態において、上述した銘柄コードについてのクロスリファレンスの仕組みや銘柄属性マスタの統一的・統合的管理の仕組みは、銘柄コード以外にも、例えば、発行体コードやポートフォリオコードなどについて同様に適用することができ、これらについても統一コードを発行してマスタ属性を自動的に生成することができる。

【0067】

＜ベンチマーク・ポートフォリオ管理＞
従来、資産運用の戦略を練る上では、ポートフォリオの収益率の分析が重要であり、ベンチマーク指標の分析はポートフォリオほど重要視されていなかったが、ベンチマークの分析もポートフォリオと同列に重要であるという認識が広がってきた。しかし、従来はポートフォリオのデータとベンチマークのデータは別々に管理されており（基幹系バックオフィスシステムがない情報ベンダーなどではポートフォリオデータがないこともある）、統合的な分析が有効にできない状況にあった。

【0068】

そこで、本実施の形態では、ポートフォリオデータとベンチマークデータとを関連付け、ベンチマークもポートフォリオ属性と同様に１つの属性として、ベンチマークポートフォリオという属性として１つのテーブル内で統一的に管理する。これにより、ポートフォリオとベンチマークを同じデータ階層や構造で見ることができ、例えば、両者の構成銘柄の差分等に基づいて乖離要因を分析することなどが可能となる。

【0069】

図１０は、本発明の一実施の形態におけるベンチマークポートフォリオに関連するテーブルの構成例について概要を示したＥＲ図である。図の左から、口座－ベンチマーク（ＢＭ）関連テーブル４２ｇは、口座とベンチマークの関係の定義を保持するテーブルであり、固定ポートフォリオコード、およびトータルベンチマークコードなどの項目を有する。固定ポートフォリオコードは、ポートフォリオを特定するコードであり、トータルベンチマークコードは、全体でのベンチマークを特定するコードである。固定ポートフォリオコードとトータルベンチマークコードとの関係は１対多であり、参考ベンチマーク等の複数のベンチマークコードを持つことができる構成となっている。

【0070】

ＢＭトータル－アセット関連テーブル４２ｈは、トータルベンチマークと資産別レベルでのベンチマーク（アセットベンチマーク）との関係の定義を保持するテーブルである。同様に、ＢＭアセット－セクター関連テーブル４２ｉは、アセットベンチマークとセクター（業種）別レベルでのベンチマーク（セクターベンチマーク）との関係の定義を保持するテーブルである。同様に、ＢＭセクター－銘柄関連テーブル４２ｊは、セクターベンチマークと銘柄別レベルでのベンチマーク（銘柄ベンチマーク）との関係の定義を保持するテーブルである。

【0071】

これらの各テーブルはベンチマークの階層に従って階層構造を有しているが、図示するようにテーブルの構成を全て同じとし、実体としては同一のテーブルにおいて、例えば、構成コード区分に指定された区分（資産コードかセクターコードか銘柄コードか）によりいずれの階層のベンチマークを対象としたレコードであるのかを識別できるようにしてもよい。

【0072】

最下層のＢＭ銘柄構成定義テーブル４２ｋは、銘柄別レベルでのベンチマークの構成の定義を保持するテーブルであり、例えば、私募投信銘柄とベンチマークとの関連付けを想定したものである。なお、１階層上のＢＭセクター－銘柄関連テーブル４２ｊは、例えば、国・通貨レベルでの複合ベンチマークの計算などを想定したものである。なお、図１０の例に示した各テーブルはいずれも標準ＤＢ４２に格納される。

【0073】

以上に説明したように、本発明の一実施の形態であるデータウェアハウス１によれば、各種データソースの銘柄コードを関連付け、データに関連性・統一性を持たせることで、データソース単独のデータでは得られなかった付加価値を付与することが可能となる。そして、銘柄コードに限らず各種データソースの多種多様なコードを関連付けるために必要となるクロスリファレンスと統一コードを、一定の条件の下、日々のトランザクションデータから自動生成する。

【0074】

そして、基幹系バックオフィスシステムや外部情報ベンダーシステムから定期的に接続してデータを取得することで、規格銘柄コードや外部情報ベンダーシステムの銘柄コード、銘柄属性（銘柄名称等）が変更されたことを検知した場合、新旧の銘柄コード等の情報を履歴として保持して管理するとともに、クロスリファレンスにも自動的に反映させる。さらに銘柄マスタテーブルに保持する銘柄属性にも銘柄名称等の変更を履歴とともに自動的に反映する。これにより、過去の任意の時点でのコードの値を遡って参照できるとともに、コードが変更されるタイミングで自動的に新コードに切り替えることも可能である。

【0075】

さらには、銘柄コードについての統一コードおよびクロスリファレンスの仕組みを、発行体コードやポートフォリオコードについても適用し、これらのコードの統一コードや、マスタテーブルにおける属性情報を自動的に生成することも可能である。

【0076】

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

【0077】

なお、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

【0078】

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

【0079】

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

【産業上の利用可能性】

【0080】

本発明は、各業務アプリケーションやシステムに対して共通のデータ共有基盤となるデータウェアハウスに利用可能である。

【符号の説明】

【0081】

１…データウェアハウス、２…外部データソース、３…データ提供先、
１０…データ取得部、
２０…標準データ作成部、２１…コードリファレンス作成部、２２…マスタ管理部、
３０…業務用データ作成部、
４１…素ＤＢ、４２…標準ＤＢ、４２ａ…銘柄コードテーブル、４２ｂ…銘柄コードリファレンス、４２ｃ…国属性テーブル、４２ｄ…国コードリファレンス、４２ｅ…銘柄マスタテーブル、４２ｆ…業務目的別銘柄マスタテーブル、４２ｇ…口座－ＢＭ関連テーブル、４２ｈ…ＢＭトータル－アセット関連テーブル、４２ｉ…ＢＭアセット－セクター関連テーブル、４２ｊ…ＢＭセクター－銘柄関連テーブル、４２ｋ…ＢＭ銘柄構成定義、４３…業務用ＤＢ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】