特許 6378497 情報処理装置、情報処理方法及びプログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6378497

(24)【登録日】2018年8月3日

(45)【発行日】2018年8月22日

(54)【発明の名称】情報処理装置、情報処理方法及びプログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20180813BHJP

【ＦＩ】

   G06F12/00 512

【請求項の数】5

【全頁数】17

(21)【出願番号】特願2014-36228(P2014-36228)

(22)【出願日】2014年2月27日

(65)【公開番号】特開2015-162039(P2015-162039A)

(43)【公開日】2015年9月7日

【審査請求日】2017年2月17日

【前置審査】

(73)【特許権者】

【識別番号】397073201

【氏名又は名称】株式会社電通国際情報サービス

(74)【代理人】

【識別番号】100113608

【弁理士】

【氏名又は名称】平川 明

(74)【代理人】

【識別番号】100185236

【弁理士】

【氏名又は名称】関 誠之

(72)【発明者】

【氏名】樋口 清志

【審査官】 月野 洋一郎

(56)【参考文献】

【文献】 国際公開第２０１１／１１１５３２（ＷＯ，Ａ１）

【文献】 特開平０６−００４５８６（ＪＰ，Ａ）

【文献】 特開２００１−１１７９２５（ＪＰ，Ａ）

【文献】 特開２００９−００３９６８（ＪＰ，Ａ）

【文献】 特開２００２−１０８６６４（ＪＰ，Ａ）

【文献】 特開昭６３−１４３６４２（ＪＰ，Ａ）

【文献】 米国特許第０５９７８８１０（ＵＳ，Ａ）

【文献】 特開２００８−２４３１９３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

マルチテナントデータベースにおいて複数のテナントが共有する単一の物理テーブルに対してデータ操作を行う情報処理装置であって、
テナント毎に定義される論理テーブルのカラムと前記単一の物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づき、前記論理テーブルにおけるレコードを前記単一の物理テーブルにおける第１のレコード及び当該第１のレコードとは前記カラムのデータ型の組み合わせが異なる第２のレコードに分解し、前記論理テーブルにおける前記分解されたレコードの各カラムのデータを前記第１のレコードと前記第２のレコードにおける、前記分解されたレコードの各カラムと同じデータ型のカラムに登録すると共に、前記第１のレコードと前記第２のレコードとの接続関係を示す情報を付与して登録する登録部と、
前記マッピング情報及び前記接続関係を示す情報に基づき、前記第１のレコード及び前記第２のレコードを前記単一の物理テーブルから読み出し、結合して出力する抽出部と、
を備える情報処理装置。

【請求項2】

前記単一の物理テーブルは、データ型の異なる複数のカラムを含む
請求項１に記載の情報処理装置。

【請求項3】

前記マッピング情報において前記論理テーブルにおける１つのレコードが前記単一の物理テーブルにおける３以上のレコードと対応付けられている場合、
前記登録部は、前記マッピング情報に基づき、前記論理テーブルにおける１つのレコードを、前記単一の物理テーブルにおける３以上のレコードに分解し、当該３以上のレコードの接続関係を示す情報を付与して登録し、
前記抽出部は、前記マッピング情報に基づき、前記３以上のレコードを前記単一の物理テーブルから読み出し、結合して出力する
請求項１又は２に記載の情報処理装置。

【請求項4】

マルチテナントデータベースにおいて複数のテナントが共有する単一の物理テーブルに対してデータ操作を行う情報処理方法であって、
テナント毎に定義される論理テーブルのカラムと前記単一の物理テーブルのカラムとの
対応付けを前記テナント毎に定義するマッピング情報に基づき、前記論理テーブルにおけるレコードを、前記単一の物理テーブルにおける第１のレコード及び当該第１のレコードとは前記カラムのデータ型の組み合わせが異なる第２のレコードに分解し、前記論理テーブルにおける前記分解されたレコードの各カラムのデータを前記第１のレコードと前記第２のレコードにおける、前記分解されたレコードの各カラムと同じデータ型のカラムに登録すると共に、前記第１のレコードと前記第２のレコードとの接続関係を示す情報を付与して登録する登録ステップと、
前記マッピング情報及び前記接続関係を示す情報に基づき、前記第１のレコード及び前記第２のレコードを前記単一の物理テーブルから読み出し、結合して出力する抽出ステップと、
をコンピュータが実行する情報処理方法。

【請求項5】

マルチテナントデータベースにおいて複数のテナントが共有する単一の物理テーブルに対してデータ操作を行うプログラムであって、
テナント毎に定義される論理テーブルのカラムと前記単一の物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づき、前記論理テーブルにおけるレコードを、前記単一の物理テーブルにおける第１のレコード及び当該第１のレコードとは前記カラムのデータ型の組み合わせが異なる第２のレコードに分解し、前記論理テーブルにおける前記分解されたレコードの各カラムのデータを前記第１のレコードと前記第２のレコードにおける、前記分解されたレコードの各カラムと同じデータ型のカラムに登録すると共に、前記第１のレコードと前記第２のレコードとの接続関係を示す情報を付与して登録する登録ステップと、
前記マッピング情報及び前記接続関係を示す情報に基づき、前記第１のレコード及び前記第２のレコードを前記単一の物理テーブルから読み出し、結合して出力する抽出ステップと、
をコンピュータに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本件は、情報処理装置、情報処理方法、プログラム及びデータ構造に関する。

【背景技術】

【0002】

従来、１つのシステムのリソースを複数のユーザで共有することにより、コストの低減を図るマルチテナント型のアーキテクチャが提案されている。例えば、テナント用の情報処理装置から入力されたデータ内の各カラムに対してシリアライズ処理の対象であるか否かを判断し、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理してデータスキーマのシリアル化カラム内のカラムに格納するという技術が提案されている（特許文献１）。この技術によれば、予め設定されたカラム数に制限されることがなくなる。また、シリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドに対しては、検索等のデータベースシステムが提供する機能を適用することができる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】国際公開第２０１１／１１１５３２号パンフレット

【発明の概要】

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

【0004】

上述した技術では、将来的に検索対象となる可能性のあるデータについて、予め「シリアライズ対象ではない」と判断して機能フィールドの適切なカラムに格納しておく必要がある。そして、シリアライズ対象か否かの判断は、アプリケーションの開発者によって行われるか、又はプログラムコード若しくは実行履歴の解析によって行われるとされている。しかしながら、設計ミスが生じる可能性があるとともに、将来的な仕様の変更を見越して設計を行うのは困難であるという問題があった。

【0005】

そこで、本発明は、マルチテナントシステムで用いる汎用的なデータベースにおいて、カラム数の制約を排除するとともに、ＤＢＭＳ（DataBase Management System：データベース管理システム）が提供する機能の利用性を向上させることを目的とする。

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

【0006】

本発明の一側面に係る情報処理装置は、マルチテナントデータベースにおいて複数のテナントが共有する物理テーブルに対してデータ操作を行う。具体的には、テナント毎に定義される論理テーブルのカラムと物理テーブルのカラムとの対応付けをテナント毎に定義するマッピング情報に基づき、論理テーブルにおける第１のレコードを、物理テーブルにおける第２のレコード及び第３のレコードに分解し、当該第２のレコードと当該第３のレコードとの接続関係を示す情報を付与して登録する登録部と、マッピング情報及び接続関係を示す情報に基づき、第２のレコード及び第３のレコードを物理テーブルから読み出し、結合して出力する抽出部とを備える。

【0007】

このようにすれば、テナントが定義する論理テーブルのレコードを、複数のレコードに分解して物理テーブルに登録することができ、物理テーブルにおけるカラム数の制約を排除することができる。また、論理テーブルのカラムは、対応付けられている物理テーブルのカラムに登録されるため、ＤＢＭＳが提供する検索等の機能は論理テーブルの各カラムに間接的に適用できる。すなわち、マルチテナントシステムで用いる汎用的なデータベースにおいて、カラム数の制約を排除するとともに、ＤＢＭＳが提供する機能の利用性を向
上させることができるようになる。

【0008】

また、物理テーブルは、データ型の異なる複数のカラムを含むようにしてもよい。このようにすれば、ＤＢＭＳが提供する機能の利用性をさらに向上させることができる。

【0009】

また、マッピング情報において論理テーブルにおける１つのレコードが物理テーブルにおける３以上のレコードと対応付けられている場合、登録部は、マッピング情報に基づき、論理テーブルにおける１つのレコードを、物理テーブルにおける３以上のレコードに分解し、当該３以上のレコードの接続関係を示す情報を付与して登録し、抽出部は、マッピング情報に基づき、３以上のレコードを物理テーブルから読み出し、結合して出力するようにしてもよい。このように、論理テーブルにおける１つのレコードを物理テーブルにおける３以上のレコードに分解して保持すれば、カラム数の制約はなくなる。

【0010】

また、情報処理装置は物理テーブルを複数備え、マッピング情報は、論理テーブルと複数の物理テーブルのいずれかとの対応付けをさらに定義するようにしてもよい。このように物理テーブルを分散させることにより、レコード数の増加にともなるレスポンスの悪化を抑制することができるようになる。

【0011】

本発明の他の側面に係るデータ構造は、マルチテナントデータベースにおいて複数のテナントが共有する物理テーブルに適用される。具体的には、テナント毎に定義される論理テーブルのレコードを一意に特定するための情報を保持する１又は複数のカラムと、論理テーブルのレコードが、物理テーブルにおいて複数のレコードに分解して登録される場合における、当該複数のレコードの接続関係を示す情報を保持するカラムと、論理テーブルの複数のカラムに保持される値をそれぞれ独立に保持する複数のカラムとを含む。

【0012】

このようにすれば、テナントが定義する論理テーブルのレコードを、複数のレコードに分解して物理テーブルに登録することができ、物理テーブルにおけるカラム数の制約を排除することができる。また、論理テーブルの複数のカラムに登録保持される値をそれぞれ独立に保持する複数のカラムを含むため、ＤＢＭＳが提供する検索等の機能は論理テーブルの各カラムに間接的に適用できる。すなわち、マルチテナントシステムで用いる汎用的なデータベースにおいて、カラム数の制約を排除するとともに、ＤＢＭＳが提供する機能の利用性を向上させることができるようになる。

【0013】

上記課題を解決するための手段の内容は、本発明の課題や技術的思想を逸脱しない範囲で可能な限り組み合わせることができる。また、上記手段をコンピュータが実行する方法を実施したり、上記手段をコンピュータに実行させるプログラムを提供等したりするようにしてもよい。プログラムは、コンピュータが読み取り可能な記録媒体に記録して提供するようにしてもよい。コンピュータが読み取り可能な記録媒体とは、情報を電気的、磁気的、光学的、機械的、又は化学的作用によって蓄積し、コンピュータによって読み取ることができる記録媒体をいう。このような記録媒体のうち、コンピュータから取り外し可能なものとしては、例えば光ディスク、光磁気ディスク、フレキシブルディスク、磁気テープ、メモリカード等がある。また、コンピュータに固定された記録媒体としてＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、ＲＯＭ（Read Only Memory）等がある。

【発明の効果】

【0014】

本発明によれば、マルチテナントシステムで用いる汎用的なデータベースにおいて、カラム数の制約を排除するとともに、ＤＢＭＳが提供する機能の利用性を向上させることができる。

【図面の簡単な説明】

【0015】

【図1】システム全体の概略構成を示す図である。

【図2】マルチテナントシステムの一例を示す機能ブロック図である。

【図3】コンピュータの一例を示す装置構成図である。

【図4】テナントＡの論理テーブルの一例を示す表である。

【図5】テナントＡの論理テーブルの一例を示す表である。

【図6】テナントＢの論理テーブルの一例を示す表である。

【図7】物理テーブルの一例を示す表である。

【図8】メタデータの一例を示す表である。

【図9】データ操作処理の一例を示す処理フロー図である。

【図10】設定処理の一例を示す処理フロー図である。

【図11】データ型の対応関係を説明するための図である。

【図12】インデックステーブルの一例を示す表である。

【図13】テーブルスペースを説明するための図である。

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

【0016】

以下、図面を参照して本発明を実施するための形態について説明する。以下の実施の形態の構成は例示であり、本発明は実施の形態の構成に限定されない。

【0017】

＜システム構成＞
図１は、システムの概略構成の一例を示す図である。図１の例では、本発明に係るマルチテナントシステム１と、テナント端末２（図１では、２ａ及び２ｂ）とが、ネットワーク３を介して接続されている。マルチテナントシステム１は、複数のテナント（すなわち、複数のユーザ）に対してハードウェアリソース及びソフトウェアリソースを共通に使用させるシステムであり、本発明に係るデータ構造を有する物理テーブルを使用させる。すなわち、いわゆるＳａａＳ（Software as a Service）を提供するシステムである。また
、テナント端末２は、それぞれネットワーク３を介してマルチテナントシステム１に対しデータ操作を要求したり、結果を受け取ったりする。便宜上、テナント端末２ａはテナントＡの端末であり、テナント端末２ｂはテナントＢの端末であるものとする。図１では２つのテナント端末を示しているが、テナント端末の数は２つには限られない。

【0018】

＜マルチテナントシステム＞
図２は、マルチテナントシステム１の一例を示す機能ブロック図である。図２のマルチテナントシステム１は、ＤＢＭＳ１１と、メタデータ記憶部１２と、設定部１３と、要求受付部１４と、変換部１５と、結果応答部１６とを有する。

【0019】

ＤＢＭＳ１１は、データベース（例えば、ＲＤＢ（Relational Database））の運用管
理に必要な機能を提供するシステムであり、物理テーブル１１１と、データ操作部１１２とを有する。物理テーブル１１１は、所定のデータ構造（スキーマ）で物理的なファイルとしてデータレコードを格納する記憶装置である。本実施形態では、データ構造が同一の物理テーブル１１１を、複数のテナントが共有する。すなわち、異なるテナントのデータを同一の物理テーブル１１１に保持する。また、データ操作部１１２は、レコードの挿入（登録）、レコードの選択（検索）、レコードの更新、レコードの削除等の操作を物理テーブル１１１に対して行う。なお、ＤＢＭＳ１１は、様々なベンダーが提供する既存の製品を利用することができる。

【0020】

また、メタデータ記憶部１２は、各テナントが業務等に応じて定義する論理テーブルのデータ構造と物理テーブル１１１のデータ構造との対応付けを示すメタデータを記憶する。本実施形態では、物理テーブル１１１は各テナントに共通であり、汎用的なデータ構造を有している。そして、メタデータにおいて、論理テーブルの１カラム（「列」、「項目
」、「フィールド」とも呼ぶ）に対し、物理テーブル１１１の１カラムを割り当てる。このとき、対応するデータ型のカラムを割り当てるものとする。なお、メタデータを「マッピング情報」とも呼ぶ。

【0021】

ここで、各テナントが定義する論理テーブルの１レコードは、物理テーブル１１１の１レコードで保持できない場合がある。例えば、物理テーブル１１１のカラム数の方が論理テーブルのカラム数よりも少ない場合は論理テーブルのレコードを物理テーブルの１レコードでは保持することができない。また、あるデータ型のカラムが、物理テーブル１１１に予め用意された数の方が論理テーブルに定義された数よりも少ない場合も、論理テーブルのレコードを物理テーブルの１レコードで保持することができない。このような場合、論理テーブルにおける１レコードを、物理テーブル１１１における２以上のレコードに分解して保持する。このため、物理テーブル１１１は、複数のレコードの接続関係（「ページ」とも呼ぶ）を示すカラムを含む。そして、メタデータは、論理テーブルのカラムと、物理テーブル１１１のカラム及びページとを対応付けることで、値を１対１に対応付けるものとする。

【0022】

設定部１３は、ネットワーク３を介してテナント端末２からメタデータを設定するための命令を受け付け、メタデータ記憶部１２に記憶させる。また、要求受付部１４は、ネットワーク３を介してテナント端末２からデータ操作を行うための要求を受け付け、変換部１５に渡す。変換部１５は、メタデータ記憶部１２が記憶するメタデータに基づいて、テナント端末から受け付けたデータ操作要求を、ＤＢＭＳにおいて実行可能なデータ操作命令（「クエリ」、「問合せ」とも呼ぶ）に変換し、ＤＢＭＳ１１のデータ操作部１１２に伝送する。同様に、データ操作部１１２から取得したデータ操作の結果を受け取り、各テナントの論理テーブルにおける項目に変換して結果応答部１６に渡す。結果応答部１６は、テナント端末２から受け付けたデータ操作要求の結果を、テナント端末２へ送信する。

【0023】

＜装置構成＞
図３は、コンピュータの一例を示す装置構成図である。マルチテナントシステム１及びテナント端末２は、図３に示すようなコンピュータである。図３に示すコンピュータ１０００は、ＣＰＵ（Central Processing Unit）１００１、主記憶装置１００２、補助記憶
装置１００３、通信ＩＦ（Interface）１００４、入出力ＩＦ（Interface）１００５、ドライブ装置１００６、通信バス１００７を備えている。ＣＰＵ１００１は、プログラム（「ソフトウェア」又は「アプリケーション」とも呼ぶ）を実行することにより本実施の形態に係る処理を行う。主記憶装置１００２は、ＣＰＵ１００１が読み出したプログラムやデータをキャッシュしたり、ＣＰＵの作業領域を展開したりする。主記憶装置は、具体的には、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等である。補助記憶装置１００３は、ＣＰＵ１００１により実行されるプログラムや、本実施の形態で用いる設定情報などを記憶する。補助記憶装置１００３は、具体的には、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等である。主記憶装置１００２や補助記憶装置１００３は、マルチテナントシステム１の物理テーブル１１１やメタデータ記憶部１２、その他の一時データを記憶する手段として働く。通信ＩＦ１００４は、他のコンピュータとの間でデータを送受信する。通信ＩＦ１００４は、具体的には、有線又は無線のネットワークカード等である。マルチテナントシステム１及びテナント端末２は、通信ＩＦ１００４を介してインターネット等のネットワーク３に接続されている。入出力ＩＦ１００５は、入出力装置と接続され、ユーザから操作を受け付けたり、ユーザへ情報を提示したりする。入出力装置は、具体的には、キーボード、マウス、ディスプレイ、タッチパネル等である。ドライブ装置１００６は、磁気ディスク、光磁気ディスク、光ディスク等の記憶媒体に記録されたデータを読み出したり、記憶媒体にデータを書き込んだりする。以上のような構成要素が、通信バス１００７で接続されている。なお、これらの構成要素はそれぞれ複数設けられていてもよいし、一部の構成要素（例えば、ドライブ
装置１００６等）を設けないようにしてもよい。また、入出力装置がコンピュータと一体に構成されていてもよい。また、ドライブ装置１００６で読み取り可能な可搬性の記憶媒体や、フラッシュメモリのような可搬性の補助記憶装置１００３、通信ＩＦ１００４などを介して、本実施の形態で実行されるプログラムが提供されるようにしてもよい。そして、ＣＰＵ１００１が所定のプログラムを実行することにより、図３に示したコンピュータをマルチテナントシステム１として働かせる。

【0024】

＜データ構造＞
次に、物理テーブル１１１のデータ構造と論理テーブルのデータ構造との対応関係の一例を説明する。図４〜図６に示す表は、テナントＡ又はテナントＢがマルチテナントシステム１において保持している論理テーブルと格納データの一例である。図４は、テナントＡが管理する「user」テーブルのカラム名と登録されたレコードの一例を示す表である。図４に示す「user」テーブルは、「名前」、「性別」、「身長」、「体重」及び「誕生日」の各カラムを有する。なお、データ型は、例えば、「名前」及び「性別」が文字列型、「身長」及び「体重」が固定小数点型、「誕生日」が日付型である。図５は、テナントＡが管理する「div」テーブルに登録されたデータの一例を示す表である。図５に示す「div」テーブルは、「部署名」及び「部署種別」の各カラムを有する。なお、データ型は、例えば、「部署名」及び「部署種別」とも文字列型である。図６は、テナントＢが管理する「item」テーブルに登録されたデータの一例を示す表である。図６に示す「item」テーブルは、「商品名」、「商品種別」、「単位名」、「価格」及び「発売日」の各カラムを有する。なお、データ型は、例えば、「商品名」、「商品種別」、「単位名」が文字列型、「価格」が整数型、「発売日」が日付型である。

【0025】

図７に示す表は、物理テーブル１１１のデータ構造と格納データの一例である。図７の物理テーブルは、「TenantID」、「TypeID」、「DataID」、「PageID」、「Char1」、「Char2」、「Num1」、「Num2」、「Date1」、「Date2」等のカラムを有する。なお、データ型は、例えば、「TenantID」、「TypeID」、「Char1」及び「Char2」が文字列型、「Num1」及び「Num2」が数値型、「Date1」及び「Date2」が日付型である。なお、各カラムのデータサイズ（「データ長」とも呼ぶ）は、可変長としても固定長としてもよい。図７には明示していないが、データ型は同一であってデータサイズが異なる複数のカラムを設けてもよい。

【0026】

「TenantID」のカラムには、マルチテナントシステム１のユーザであるテナントを識別するための識別情報が登録される。本実施形態では、テナント端末２のユーザがマルチテナントシステム１を利用する際、まず、テナントの識別情報（例えば「TenantID」）及びパスワードを用いて認証処理を行うものとする。そして、基本的に各テナントは物理テーブル１１１に登録されたレコードのうち、「TenantID」のカラムに自身の識別情報が登録されたレコードに対して選択、更新、削除等の操作を行うことができるものとする。また、各テナントが物理テーブル１１１に新たなレコードを挿入する場合、「TenantID」のカラムに自身の識別情報を登録するものとする。このようにすることで、ハードウェアリソースからアプリケーション及びデータベース構造までを共有したＳａａＳを実現することができる。

【0027】

「TypeID」のカラムには、各テナントにおいて論理テーブルを識別するための識別情報が登録される。また、「DataID」のカラムには、各論理テーブルにおいてレコードを一意に特定するための識別情報が登録される。各論理テーブルにおいてレコードを一意に特定できるように「DataID」の値を付与（採番）すれば、「TenantID」、「TypeID」及び「DataID」の複合キーによって各テナントの論理テーブルにおけるレコードを一意に特定できるようになる。なお、図７に示すように、全ての論理テーブルにおいてレコードを一意に特定できるように「DataID」の値を付与するようにしてもよい。

【0028】

「PageID」のカラムには、論理テーブルにおける１レコードが物理テーブル１１１において複数のレコードに分解されて登録される場合の接続関係（接続順序）を表す情報が登録される。なお、図７の例では、接続関係を表す情報として、通し番号を登録している。図７の例では、「DataID」及び「PageID」によって、論理テーブルのカラムを特定することができるため、物理テーブル１１１の複数のレコードから論理テーブルにおける１レコードを復元できるようになる。なお、「TenantID」、「TypeID」、「DataID」及び「PageID」のカラムを複合キーとして物理テーブル１１１のレコードを一意に特定できるようにしてもよい。

【0029】

また、「Char1」、「Char2」、「Num1」、「Num2」、「Date1」、「Date2」・・・のカラムには、論理テーブルの各カラムの値が登録される。すなわち、これらは、論理テーブルの複数のカラムに保持される値をそれぞれ独立に保持するカラムである。例えば、「Char1」及び「Char2」は、文字列型のカラムである。また、「Num1」及び「Num2」は、数値型のカラムである。「Date1」及び「Date2」は、日付型のカラムである。なお、図７はカラムの構成を簡略化した例であり、物理テーブル１１１は、他のデータ型のカラムをさらに有していてもよいし、各データ型のカラムを３列以上有していてもよい。また、物理テーブル１１１に設けられる各データ型のカラム数は、同数でなくてもよい。例えば、物理テーブル１１１は、文字列型のカラムを３０列、数値型のカラムを１０列、日付型のカラムを５列設けるといった定義が可能である。ただし、マルチテナントシステムにおいては汎用性が求められるため、平均的に各データ型のカラム数を決定したり、テナントのニーズや使用実績等に基づいて各データ型のカラム数を決定してもよい。なお、論理テーブルのデータ構造と物理テーブル１１１のデータ構造との対応付けは、テナント毎に予めメタデータに定義される。

【0030】

図８は、メタデータとして登録される内容の一例を示す表である。メタデータは、例えばテナントごとにＤＢＭＳ上のテーブル又はファイルシステム上のファイルとして保持される。本実施形態では、テナント（例えば「テナントＡ」、「テナントＢ」等）及び論理テーブル（例えば「user」テーブル、「div」テーブル、「item」テーブル等）の組合せ
に対して、物理テーブル１１１の「TypeID」が一意に割り当てられる。さらに、メタデータは、図４〜図６に示した論理テーブルのカラムと図７に示した物理テーブルのカラムとの対応付けを示している。また、本実施形態では、論理テーブルの１レコードを物理テーブル１１１において複数のレコードに分解して登録する場合がある。よって、論理テーブルの「カラム名」に対し、物理テーブル１１１の「対応カラム名」及び分解された各レコードを一意に特定するための「PageID」が対応付けられている。図７の「DataID」の値が「００１」〜「００４」のレコードのように、ある「DataID」に対し「PageID」が１のみである場合、論理テーブルのレコードは分解されずに物理テーブル１１１に格納されていることがわかる。一方、図７の「DataID」の値が「００５」及び「００６」のレコードのように、「DataID」の値が同一であって「PageID」の値が２以上のレコードが存在する場合、論理テーブルのレコードは複数に分解されて物理テーブル１１１に格納されていることがわかる。このように、「PageID」のカラムは、物理テーブル１１１における複数のレコード間の接続関係を示すデータともいえる。

【0031】

本実施形態では、基本的にテナント毎に論理テーブルやメタデータが定義される。ただし、各テナントが共通に利用するマスターデータを用意するようにしてもよい。例えば、郵便番号と住所の一部を対応付けて記憶する郵便番号マスタを、各テナントに共通のメタデータで保持するようにしてもよい。このような郵便番号マスタの内容は郵便制度の規格によって決まるため、各テナントが共通に利用する方が効率的である。共通のメタデータはファイルシステム上のファイルとしてマルチテナントシステム１の管理者が一元管理し、各テナントのメタデータはＤＢＭＳ上のレコードとして「TenantID」と関連付けて管理
するようにしてもよい。

【0032】

＜データ操作処理＞
図９は、データ操作処理の一例を示す処理フローである。なお、マルチテナントシステム１は、テナント端末２から接続の要求を受ける際、まず所定の認証処理を行うことでテナントを識別しているものとする。また、予めメタデータ記憶部には図８に示したメタデータが保持されているものとする。

【0033】

マルチテナントシステム１の要求受付部１４は、テナント端末２からデータ操作に係る要求を受け付ける（図９：Ｓ１）。要求は、例えば、論理テーブルに対してレコードの挿入、選択、更新、削除等を要求するクエリ（例えば、ＳＱＬ等の問合せ言語）として受け付ける。そして、要求受付部１４は、要求を変換部１５に伝送する。なお、要求は、各テナントのいわゆる業務アプリケーションから発行されるものであってもよい。例えば、ネットワーク３に接続された顧客の端末から商品購入の要求を受けた場合に、マルチテナントシステム１のアプリケーションがデータ操作の要求を生成するようにしてもよい。

【0034】

マルチテナントシステム１の変換部１５は、メタデータ記憶部１２に記憶されているメタデータに基づいて、要求受付部１４から受けた要求を物理テーブル１１１に対する要求に変換する（Ｓ２）。ここでは、図８に示したメタデータに基づき、クエリの内容を修正する。すなわち、レコード間の接続関係を示す情報である、物理テーブルのカラム「PageID」に保持された値に基づいて、１又は２以上のレコードを仮想的に１つのレコードとして扱う。具体的には、「TenantID」の値が要求元のテナントの識別情報と一致するレコードを操作の対象とする条件を付加する。また、操作対象のテーブルを物理テーブル１１１に変更し、変換前の要求における操作対象の論理テーブルの指定を、カラム「TypeID」の値の指定に置き換える。さらに、変換前の要求におけるカラムの指定を、物理テーブル１１１のカラム及び「PageID」の指定に置き換える。

【0035】

例えば、テナントＢが検索を行うために次のようなクエリ１Ａを送信する例について説明する。
（クエリ１Ａ）
SELECT 商品名, 商品種別, 単位名, 価格, 発売日 FROM item WHERE 商品種別=’食品’;

【0036】

この例は、論理テーブル「item」から「商品種別」の値が「食品」のレコードを抽出し、「商品名」、「商品種別」、「単位名」、「価格」及び「発売日」の各項目の値を表示させる要求である。そして、クエリ１Ａは、変換部１５によって、次のようなクエリ１Ｂに変換される。なお、物理テーブル１１１の物理名は「DataTable」であるものとする。
（クエリ１Ｂ）
SELECT p1.Char1, p1.Char2, p2.Char1, p1.Num1, p1.Date1
FROM DataTable p1 LEFT OUTER JOIN DataTable p2
ON p1.DataID=p2.DataID and p2.PageID=2
WHERE p1.Char2=’食品’
AND p1.TenantID=’B’ AND p1.TypeID=’item’ AND p1.PageID=1;

【0037】

この例では、「PageID」の値が１のレコードと「PageID」の値が２のレコードとを自己結合させいる。また、図８のメタデータに基づき、論理テーブルの「商品種別」は物理テーブル１１１において「PageID」が１の「Char2」（すなわち、p1.Char2）に変換されて
いる。なお、ＤＢＭＳ１１からは「PageID」が１のレコードと２のレコードとをそれぞれ抽出し、変換部１５が仮想的な１つのレコードに結合するという構成にしてもよい。また、「PageID」の値が３以上のレコードがある場合、変換後のクエリにおいて３つ以上のレコードを自己結合させることも可能である。

【0038】

次に、テナントＢがレコード数の計数を行うために次のようなクエリ２Ａを送信する例について説明する。
（クエリ２Ａ）
SELECT COUNT(*) FROM item WHERE 商品種別=’食品’;

【0039】

クエリ２Ａは、変換部１５によって、次のようなクエリ２Ｂに変換される。
（クエリ２Ｂ）
SELECT COUNT(*)
FROM DataTable p1 LEFT OUTER JOIN DataTable p2
ON p1.DataID=p2.DataID and p2.PageID=2
WHERE p1.Char2=’食品’
AND p1.TenantID=’B’ AND p1.TypeID=’item’ AND p1.PageID=1;

【0040】

この例でも、「PageID」が２のレコードを自己結合させ、「PageID」が１のレコードを選択（SELECT）している。また、図８のメタデータに基づき、論理テーブルの「商品種別」は物理テーブル１１１において「PageID」が１の「Char2」（すなわち、p1.Char2）に
変換されている。なお、ＤＢＭＳ１１からは「PageID」が１のレコードと２のレコードとをそれぞれ抽出し、変換部１５が仮想的な１つのレコードに結合して計数するという構成にしてもよい。

【0041】

次に、テナントＢがレコードの挿入（INSERT）を行うために次のようなクエリ３Ａを送信する例について説明する。
（クエリ３Ａ）
INSERT INTO item VALUES(‘テレビ’, ‘家電’, ‘台’, 30000, 7/29);

【0042】

クエリ３Ａは、変換部１５によって、次のようなクエリ３Ｂ及びクエリ３Ｃに変換される。なお、要求を受け付けた時点において、物理テーブル１１１には「DataID」が004の
レコードまでが登録されており、新たに挿入されるレコードの「DataID」には005が採番
されるものとする。
（クエリ３Ｂ）
INSERT INTO DataTable(TenantID, TypeID, DataID, PageID, Char1, Char2, Num1, Date1)
VALUES(‘Ｂ’, ‘item’, 005, 1, ‘テレビ’, ‘家電’, 30000, 7/29);
（クエリ３Ｃ）
INSERT INTO DataTable(TenantID, TypeID, DataID, PageID, Char1)
VALUES(‘Ｂ’, ‘item’, 005, 2, ‘台’);

【0043】

レコードの挿入の場合、変換部１５はメタデータを参照し、論理テーブルにおける１レコードが物理テーブル１１１における複数のレコードに対応付けられている場合、「PageID」ごとに挿入を行うクエリを生成する。上記の例では、「PageID」が「１」のレコード（第１のレコード）を挿入するクエリ３Ｂ、及び「PageID」が「２」のレコード（第２のレコード）を挿入するクエリ３Ｃが生成されている。

【0044】

以上、メタデータにおいて論理テーブルのレコードが物理テーブル１１１の複数のレコードに分解して対応付けられている場合のデータ操作の一例について説明した。テナントＡのレコードのように論理テーブルにおけるレコードが物理テーブル１１１においても分解されずに登録されている場合は、「TenantID」及び「TypeID」の条件を追加し、カラム名の変換を行うが、「PageID」は「１」のみであり、結合や分解を行う必要はない。

【0045】

また、レコードの更新については、要求に対し選択と同様の変換を行い、条件に該当するレコードを更新するクエリを生成する。レコードの削除については、例えば、条件に該当するレコードと「DataID」の値が同一のレコードを削除するクエリを生成する。

【0046】

その後、マルチテナントシステム１のＤＢＭＳ１１は、物理テーブル１１１に対しデータ操作を実行する（Ｓ３）。本ステップでは、ＤＢＭＳ１１のデータ操作部１１２が物理テーブル１１１に対し変換後のクエリを発行して挿入、選択、更新、削除等のデータ操作を行い、実行結果を変換部１５に出力する。以上のように、変換部１５及びＤＢＭＳ１１は、受けた要求に応じて、「登録部」、「抽出部」、「更新部」、「削除部」等として機能する。また、データ操作処理のＳ２〜Ｓ４は、受けた要求に応じて、「登録ステップ」、「抽出ステップ」、「更新ステップ」、「削除ステップ」として働く。

【0047】

次に、変換部１５は、メタデータ記憶部１２のメタデータに基づいて出力結果を変換し、結果応答部へ出力する（Ｓ４）。ここでは、例えば、物理テーブル１１１のカラム名を論理テーブルのカラム名に置き換える。

【0048】

そして、マルチテナントシステム１の結果応答部１６は、ネットワーク３を介して要求元のテナント端末２に対して結果を送信する（Ｓ５）。なお、結果応答部１６は、マルチテナントシステム１の図示していないアプリケーションに対して結果を渡すようにしてもよい。

【0049】

以上のように、本実施形態に係るマルチテナントシステムでは、各テナントが定義する論理テーブルのレコードを、必要に応じて複数のレコードに分解して物理テーブルに登録する。よって、マルチテナントシステムにおいて汎用的な物理テーブルを用意する場合であっても、カラム数の制約を排除することができる。また、本実施形態に係るマルチテナントシステムは、論理テーブルにおけるカラムをそれぞれ物理テーブルにおける独立したカラムとして登録する。よって、ＤＢＭＳが提供する検索等の機能を利用する際にはいずれのカラムであっても条件に指定することができるようになっている。このように、マルチテナントシステムで用いる汎用的なデータベースにおいて、カラム数の制約を排除するとともに、ＤＢＭＳが提供する機能の利用性を向上させることができるようになっている。

【0050】

＜設定処理＞
図１０は、メタデータ等の設定を行う設定処理の一例を示す処理フロー図である。上述したデータ操作処理の前に、図１０に示すような設定処理を行う。

【0051】

マルチテナントシステム１の設定部１３は、テナント端末２から要求を受け、メタデータ記憶部１２に論理テーブルのカラムと物理テーブル１１１のカラムとの対応付けを設定する（図１０：Ｓ１１）。本ステップでは、図８に示したようなメタデータが登録される。

【0052】

本実施形態では、物理テーブル１１１に様々なデータ型のカラムを用意しておくことを特徴の１つとしている。このようにすれば、カラムのデータ型に応じてＤＢＭＳが提供する検索や集計等の機能を適用することができる。なお、論理テーブルのカラムに設定されるデータ型と物理テーブルのカラムに設定されるデータ型とは必ずしも１対１に対応していなくてもよい。例えば、図１１に示すようにカラム間のデータ型を設定するようにしてもよい。ここで、論理テーブルにおける「選択肢型」とは、予め定義された複数の選択肢の中からいずれかを指定することができるデータ型である。たとえば、優先度を示す項目に、あらかじめ定義された「最高」、「高」、「中」、「低」等の選択肢のいずれかを指定できるようにする。また、論理テーブルにおける「参照型」とは、別データへの参照を
表現するデータ型である。また、論理テーブルにおける「バイナリデータ型」とは、ＤＢＭＳで用意されているＢＬＯＢ型のようなバイナリデータを扱う型である。マルチテナントシステム１内において、バイナリデータの格納手段（たとえば、ファイルシステムやクラウドサービス上のストレージサービスなど）を別途準備し、物理テーブル内のカラムには格納手段へのポインタとなるＬｏｂＩＤを格納するようにしてもよい。そして、設定によって格納手段をＤＢ又はファイルシステム等に切り替え可能としてもよい。また、論理テーブルにおける「ロングテキスト型」とは、ＤＢＭＳの文字列型カラムのデータサイズの上限を超える文字列を格納可能とするデータ型である。例えば、ＤＢＭＳネイティブの型であるＣＬＯＢを利用し、バイナリデータ型と同様に切り替え可能としてもよい。

【0053】

なお、物理テーブル１１１のカラムは、すべて文字列型としてもよい。この場合、ＤＢＭＳ１１は、数値や日付もすべて文字列として物理テーブル１１１に格納する。そして、例えば集計のような処理は、ＤＢＭＳの機能を利用するのではなくマルチテナントシステム１の図示していないアプリケーションが実行するようにする。予め物理テーブル１１１に様々なデータ型のカラムをそれぞれ複数用意する場合、使用しないデータ型のカラムが増えてしまう可能性もあるところ、例えばカラムをすべて文字列型とすれば、物理テーブルのカラムを有効に利用可能となる。また、このような場合であっても、論理テーブルにおけるカラムをそれぞれ物理テーブルにおける独立したカラムに登録すれば、各カラムに対して検索のようなＤＢＭＳが提供する機能を利用できる。

【0054】

また、上述の通り、データ型が同一であってデータサイズが異なる複数のカラムを設けてもよい。例えば、物理テーブル１１１には、文字列型（最大長：２５６文字）のカラムと文字列型（最大長：２０００文字）のカラムとを設けておく。そして、例えば、論理テーブルの短文字列型のカラムを物理テーブル１１１の文字列型（最大長：２５６文字）のカラムにマッピングし、論理テーブルの長文字列型のカラムを物理テーブル１１１の文字列型（最大長：２０００文字）のカラムにマッピングする。物理テーブル１１１にデータ型は同一であってデータサイズが異なる複数のカラムを設けておくことにより、ユーザは格納データに応じて十分な最大長のカラムを選択することができ、テーブルに保存されるデータ量を削減したり、データ処理時に使用するバッファメモリを節約することができる。

【0055】

また、物理テーブル１１１は、一部のカラムに予めインデックス（ＩＮＤＥＸ）を付与しておくようにしてもよい。インデックスは、ＤＢＭＳ１１の機能を利用して付与することができる。この場合、Ｓ１１においては、論理テーブルのカラムのうち多く検索に用いられることが想定されるカラムを、物理テーブル１１１におけるインデックス付きのカラムにマッピングする。このようにすることで、図９に示したデータ操作処理において検索処理を高速化することができる。

【0056】

なお、利用するＤＢＭＳの方式によっては、ｎｕｌｌ値に対してもインデックスを付与し、データ領域を占有する場合がある。本実施形態に係る物理テーブルの各カラムには必ずしも論理テーブルのカラムがマッピングされるとは限らないところ、このような方式のＤＢＭＳの場合にインデックスを付与するのは好ましくない。このような場合は、図１２に示すようなインデックステーブルを別途設けるようにしてもよい。インデックステーブルは、例えば、データ型の種類に応じて、文字列型用のインデックステーブル、数値型用のインデックステーブル等を設ける。そして、メタデータにおいてインデックスの付与が設定されたカラムについてはインデックステーブルにカラムの値をコピーして（すなわち同期させて）検索に用いるようにする。

【0057】

また、設定部１３は、テナント端末２から要求を受けた場合、メタデータ記憶部１２にテーブルスペースの設定をする（Ｓ１２）。ここで、テーブルスペースとは、複数用意さ
れる物理テーブルの各々を指す概念である。複数のテーブルスペースを用意することで、いわゆるパーティショニングのように物理テーブルを分散させることができる。

【0058】

図１３は、テーブルスペースを説明するための図である。図１３に示すように、メタデータにおいて、各論理テーブルがいずれのテーブルスペースを利用するのか対応付けを設定する。また、物理テーブルはテーブルスペースの数だけ用意され、それぞれメタデータで対応付けられた論理テーブルのレコードが登録される。図１３の例では、「Default」
テーブルスペースに「DataTable_Default」という物理テーブルが対応付けられ、「TenantID」及び「TypeID」をキーとしてパーティショニングする。また、「DateBase」テーブ
ルスペースには「DataTable_DateBase」という物理テーブルが対応付けられ、「Date1」
及び「TenantID」をキーとしてパーティショニングする。

【0059】

このような例において、「DateBase」テーブルスペースには、注文日等の項目を有し、レコードが日々増加するトランザクションデータを格納するものとする。一般的に物理テーブルのレコードが増加するほどレスポンスは低下していくところ、保持するレコード数の増加が見込まれる論理テーブルを物理テーブル上分けて管理することができる。

【0060】

さらに、テーブルスペースの各々について、各データ型のカラム数に差をつけてもよい。例えば、文字の保存を優先するテーブルスペース（文字保存優先型）と、数値の保存を優先するテーブルスペース（数値保存優先型）を定義しておく。そして、文字保存優先型の物理テーブルには、例えば、文字列型のカラムを８０列、数値型のカラムを１０列、日付型のカラムを１０列設ける。また、数値保存優先型の物理テーブルには、例えば、文字列型のカラムを１０列、数値型のカラムを８０列、日付多型のカラムを１０列設ける。ユーザが論理テーブルを定義する際には格納するデータの見通しが立つため、適切なテーブルスペースを選択することが可能であり、テーブルに保存されるデータ量を削減したり、データ処理時に使用するバッファメモリを節約することができる。

【0061】

＜その他＞
本発明は、上述の例に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更を加え得るものである。

【0062】

例えば、物理テーブル１１１として、メインの物理テーブルと補助的な物理テーブルとを設けておくようにしてもよい。この場合、例えば、１ページ目（PageIDが１）のカラムをメインの物理テーブル（メインテーブル）に記憶させ、２ページ目以降（PageIDが２以上）のカラムを補助的な物理テーブル（補助テーブル）に記憶させる。このようにすれば、メインテーブルのレコードと論理テーブルのレコードとは１対１に対応づけられ、メインテーブルのカラム「DataID」に対してユニークインデックスを張ることができるようになる。また、例えば図２の変換部１５を介さずに、ユーザがＳＱＬ等で直接ＤＢＭＳを参照するような場合、メインテーブルのレコード件数が論理テーブルにおけるレコード件数となるため、メンテナンス等が行い易くなる。

【符号の説明】

【0063】

１ マルチテナントシステム
１１ ＤＢＭＳ
１１１ 物理テーブル
１１２ データ操作部
１２ メタデータ記憶部
１３ 設定部
１４ 要求受付部
１５ 変換部
１６ 結果応答部
２ テナント端末
３ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】