(57)【要約】本発明の目的は、予め設定されたカラム数に制限されずに、かつ、データベースシステムが提供する全ての機能を適用可能なマルチテナント型データベースシステムを提供することにある。  本発明のデータベースシステムは、複数のテナント用の情報処理装置とデータベースと制御装置とを備える。データベースには、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマが格納される。制御装置は、テナント用の情報処理装置から入力されたデータ内の各カラムに対してシリアライズ処理の対象であるか否かを判断し、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理してデータスキーマのシリアル化フィールド内のカラムに格納する。
2011111532.tif 000002
【特許請求の範囲】
【請求項１】
複数のテナント用の情報処理装置と、
シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマが格納されるデータベースと、
前記テナント用の情報処理装置から入力されたデータ内の各カラムに対してシリアライズ処理の対象であるか否かを判断し、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理して前記データスキーマの前記シリアル化フィールド内のカラムに格納する制御装置と、
を含むデータベースシステム。
【請求項２】
前記制御装置は、シリアライズ処理の対象ではないと判断されたカラムのデータについては、前記データスキーマの前記機能フィールド内のいずれかのカラムに格納する、
請求項１記載のデータベースシステム。
【請求項３】
前記制御装置は、前記各テナント用の情報処理装置から入力されるデータが前記データスキーマ上のどのカラムに格納されるべきかを示すデータ構造情報を備え、前記テナント用の情報処理装置からデータを受け取ると、前記データ構造情報に基づいて前記データを前記データスキーマに格納する、
請求項１または２に記載のデータベースシステム。
【請求項４】
前記データ構造情報は前記テナント用の情報処理装置の識別子と対応付けられており、
前記テナント用の情報処理装置は、前記データスキーマに格納すべきデータとともに前記テナント用の情報処理装置の識別子を前記制御装置に送信し、
前記制御装置は、前記テナント用の情報処理装置の識別子に基づいて参照すべき前記データ構造情報を決定する、
請求項３記載のデータベースシステム。
【請求項５】
前記制御装置は、前記テナント用の情報処理装置から入力された前記テナント用の情報処理装置のプログラムを解析して、前記データ構造情報を更新する、
請求項３または４に記載のデータベースシステム。
【請求項６】
前記制御装置は、前記テナント用の情報処理装置から入力されたデータ検索要求を解析して、前記データ構造情報を更新する、
請求項３ないし５のいずれに記載のデータベースシステム。
【請求項７】
シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマがデータベースに格納され、
テナント用の情報処理装置から入力されたデータの各カラムに対してシリアライズ処理の対象であるか否かを判断し、
シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理して前記シリアル化フィールド内のカラムに格納する、
データベースへのデータ格納方法。
【請求項８】
コンピュータに、
シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマをデータベースに格納するステップと、
テナント用の情報処理装置から入力されたデータの各カラムに対してシリアライズ処理の対象であるか否かを判断するステップと、
シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理して前記シリアル化フィールド内のカラムに格納するステップと、
を実行させるプログラムを格納する記録媒体。
【請求項９】
複数のテナント用の情報処理装置と接続された制御装置であって、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマが格納されるデータベースにアクセスし、前記テナント用の情報処理装置から入力されたデータ内の各カラムに対してシリアライズ処理の対象であるか否かを判断し、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理して当該データスキーマの当該シリアル化フィールド内のカラムに格納する制御装置。
【請求項１０】
テナント用の情報処理装置の識別子に対応付けて、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを含むデータベースのデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の異なるデータ構造を単一のデータスキーマに収容するデータベースシステム（以下、マルチテナント型データベースシステムと呼ぶ。）に関し、特に、予め設定されたカラム数に制限されずに、かつ、データベースシステムが提供する全ての機能を適用可能なマルチテナント型データベースシステムに関する。
【背景技術】
【０００２】
一般的なデータベースシステムでは、単一のテーブルは単一の組織（以下、テナントと呼ぶ。）によって占有的に利用され、その単一のテナントに関連するデータのみが記録される。一方、マルチテナント型データベースシステムでは、単一のテーブルは複数の異なるテナントによって共有され、それら複数の異なるテナントに関連するデータが記録される。この際、記録されるデータにはそれがどのテナントに関連するデータであるかを示す識別子（以下、テナントＩＤ（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）と呼ぶ）が付与される。後から特定のテナントに関連するデータのみを抽出できるようにするためである。これにより、各テナントは他のテナントの存在を意識せずにデータベースの機能を利用できる。
マルチテナント型データベースシステムは、単一のデータベースに複数のテナントを収容することで、テナントあたりの運用コストを軽減させるためのデータベースの利用形態である。利用者であるテナントにとっては、可能な限り一般的なデータベースと同様の形式で利用できることが望ましい。特に、テナント毎に独自のデータ構造を定義できることは重要である。すなわちカスタマイズ要求への対応は重要である。
一般に、データ構造は１つまたは複数のカラムから構成される。各カラムは保存されるデータに関する情報が定義される。カラムに定義される情報には、データの名前（以下、カラム名と呼ぶ。）やデータのタイプ（以下、データ型と呼ぶ。）やデータに課せられる制約などがある。例えば、「日程表」に相当する情報を格納するためのデータ構造を定義する場合を考える。この場合、第１のカラムはカラム名が「日時」、データ型が「日付型」であればよい。また第２のカラムはカラム名が「予定の内容」、データ型が「文字列型」であればよい。また制約には、例えば空のデータの入力を制限することを意味する「Ｎｏｔ  Ｎｕｌｌ」等を定義してもよい。このようにして、「日時」と「予定の内容」から成る一連の「日程表」データが格納されたデータ構造が定義される。
一般的に、カラム名やデータ型や制約等の情報は１つのカラムにつき１種類ずつしか定義できない。そのため、複数の異なるデータ構造を定義するには、それぞれのデータ構造に対して異なるカラム群を割り当てる必要がある。しかしながら、多くのデータベースは１テーブルあたりに定義可能なカラム数に限りがある。そのため、各テナントに独自のデータ構造を定義するためのカラムを排他的に割り当てる方法では、カラムが不足してしまうという問題がある。そのため、特許文献１では、各テナントがカラムを共有しつつ独自のデータ構造を定義するために、カラムに汎用的なデータ構造を持たせる方法が開示されている。
また、本発明に関連する技術が、特許文献２に開示されている。特許文献２には、データの内容に基づいてシリアライズし、カラムの定義を行い、データを格納する旨の記載がある（例えば［００７７］段落等。）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２００７−５３１９４１
【特許文献２】特開２００５−０５６０８５
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１では、利用者であるテナントがデータベースの機能の一部を利用できないという問題がある。なぜなら、特許文献１に記載の技術は、全てのデータを文字列型に変換して記録するために、例えば、数値型のデータを比較する条件で問い合わせを行うことができない。さらに、特許文献１に記載の技術は、問い合わせの結果として得られた数値型のデータに対して演算処理を行うこともできない。よって、これらの機能を適用するには、本来のデータ型に変換する仕組みを新たに設ける必要がある。
また、特許文献１に記載の技術は、最初に設定したカラム数を運用中に変更できないという問題がある。なぜなら、一般的なデータベース（例えば、リレーショナルデータベース）では、運用中にカラム数を変更しようとすると、テーブルにロックをかける必要がある他、データベースに処理負荷をかけてしまうために、一時的にサービスを中断させなければならないからである。また、サービスの中断を避けるために予め多量のカラムを用意しておく方法が考えられるが、過剰なカラム数を設定すると、性能の低下およびハードディスク容量の無駄が生じてしまう。
本発明の目的は、予め設定されたカラム数に制限されずに、かつ、データベースシステムが提供する全ての機能を適用可能なマルチテナント型データベースシステムを提供することにある。
【課題を解決するための手段】
【０００５】
本発明のデータベースシステムは、複数のテナント用の情報処理装置と、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマが格納されるデータベースと、テナント用の情報処理装置から入力されたデータ内の各カラムに対してシリアライズ処理の対象であるか否かを判断し、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理してデータスキーマのシリアル化フィールド内のカラムに格納する制御装置とを備える。
本発明のデータベースへのデータ格納方法は、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマがデータベースに格納され、テナント用の情報処理装置から入力されたデータの各カラムに対してシリアライズ処理の対象であるか否かを判断し、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理してシリアル化フィールド内のカラムに格納する。
本発明の記録媒体が格納するプログラムは、コンピュータに、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマをデータベースに格納するステップと、テナント用の情報処理装置から入力されたデータの各カラムに対してシリアライズ処理の対象であるか否かを判断するステップと、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理してシリアル化フィールド内のカラムに格納するステップと、を実行させる。
本発明の制御装置は、複数のテナント用の情報処理装置と接続された制御装置であって、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを備えたデータスキーマが格納されるデータベースにアクセスし、テナントから入力されたデータ内の各カラムに対してシリアライズ処理の対象であるか否かを判断し、シリアライズ処理の対象と判断された全てのカラムのデータをまとめてシリアライズ処理して当該データスキーマの当該シリアル化フィールド内のカラムに格納する。
本発明のデータベースのデータ構造は、テナント用の情報処理装置の識別子に対応付けて、シリアライズ処理されたデータを格納するためのカラムから構成されるシリアル化フィールドとシリアライズ処理されていないデータを格納するためのカラムから構成される機能フィールドとを含む。
【発明の効果】
【０００６】
本発明は、予め設定されたカラム数に制限されずに、かつ、データベースシステムが提供する全ての機能を適用することができるという効果を有する。
【図面の簡単な説明】
【０００７】
【図１】本発明の第１の実施形態におけるマルチテナント型データベースシステム１を示すブロック図である。
【図２】データスキーマ１２１の一例を示す図である。
【図３】テナント１３が「健康管理をしたい」と考えている場合のデータ構造定義情報３０の例を示す図である。
【図４】テナント１４が「ジョブマッチングをしたい」と考えている場合のデータ構造定義情報４０の例を示す図である。
【図５Ａ】データ構造定義情報３０、４０とカラムマッピング情報５０、５１とデータスキーマ１２１との対応関係の例を示す図である。
【図５Ｂ】第１の実施形態の変形例における、データ構造定義情報３０、４０とカラムマッピング情報５０、５１とデータスキーマ１２１との対応関係の例を示す図である。
【図６】テナント１３が「健康管理をしたい」と考えている場合のデータ構造情報６０の例を示す図である。
【図７】テナント１４が「ジョブマッチングをしたい」と考えている場合のデータ構造情報７０の例を示す図である。
【図８】データ構造情報１０２１を作成する際の動作を示すフローチャートである。
【図９】マルチテナント型データベース１２へのデータ格納動作を示すフローチャートである。
【図１０】データ検索要求（問合せ）に対する処理動作を示すフローチャートである。
【図１１】本発明の第２の実施形態におけるマルチテナント型データベースシステム１１を示すブロック図である。
【図１２】データ構造情報１０２１を作成する際の動作を示すフローチャートである。
【図１３】本発明の第３の実施形態におけるマルチテナント型データベースシステム１３を示すブロック図である。
【図１４】データ検索要求（問合せ）に対する処理動作を示すフローチャートである。
【図１５】制御装置１０のハードウェア構成図である。
【発明を実施するための形態】
【０００８】
次に、本発明の実施の形態について、図面を参照して詳細に説明する。
（第１の実施形態）
図１は、本発明の第１の実施形態におけるデータベースシステム１（以下、マルチテナント型データベースシステム１と呼ぶ。）を示すブロック図である。
本発明のマルチテナント型データベースシステム１は、制御装置１０と第１のデータベース（ＤＢ）１２（以下、マルチテナント型データベース１２と呼ぶ。）と複数のテナント用の情報処理装置１３〜１５とを備える。以下、テナント用の情報処理装置１３〜１５をテナント１３〜１５と呼ぶことにする。図１では、３つのテナントが制御装置１０に接続されているが、これに限定されるものではない。また、制御装置は、記憶媒体に記憶されたプログラムに基づいて動作するコンピュータであってもよい。
制御装置１０は、データ構造情報作成部１０１と第２のデータベース１０２（以下、データベース１０２と呼ぶ。）とデータ変換処理部１０３とシリアライズ処理部１０４とを備える。データベース１０２にはデータ構造情報１０２１が格納されている。
マルチテナント型ＤＢ１２には、データスキーマ１２１が格納されている。図２に、データスキーマ１２１の一例を示す。データスキーマ１２１は、各テナントのデータ構造の違いに対して柔軟性を持たせるためのシリアル化フィールド２０とデータスキーマ１２１本来の機能を利用するための機能フィールド２１とテナントＩＤを示すテナントＩＤフィールド２２とを備える。
機能フィールド２１は数値型フィールド２１１と文字列型フィールド２１２と日付型フィールド２１３とを備える。数値型フィールド２１１は数値型１〜３の３つのカラムから構成される。文字列型フィールド２１２は文字列型フィールド１〜３の３つのカラムから構成される。日付型フィールド２１３は日付型１〜３の３つのカラムから構成される。
なお、本実施形態では、数値型フィールド２１１と文字列型フィールド２１２と日付型フィールド２１３とのいずれのフィールドも３つのカラムから構成されているが、これに限定されるものではない。
また、本実施形態では、機能フィールド２１が数値型フィールド２１１と文字列型フィールド２１２と日付列型フィールド２１３の３つを備えているが、これに限定されるものではない。その他として、Ｂｏｏｌ型フィールドやＢｌｏｂ型フィールド等が含まれても良い。
Ｂｏｏｌ型とはＢｏｏｌｅａｎ型の略であり、Ｔｒｕｅ（真）とＦａｌｓｅ（偽）の２種類の値のいずれかだけを持ちうる最も単純な型である。例えば「社員であるか」を示すデータの型としてＢｏｏｌ型が設定されてによい。この場合、単純にＴｒｕｅかＦａｌｓｅ（つまり、ＹｅｓかＮｏ）を入力してもらうような使い方をする。
Ｂｌｏｂ型とはＢｉｎａｒｙ  Ｌａｒｇｅ  Ｏｂｊｅｃｔ型の略であり、Ｂｌｏｂ型フィールドは、画像などの大きなバイナリデータを格納するために利用される。
シリアル化フィールド２０はシリアル化カラムから構成される。シリアル化カラムにはシリアル化された情報のみが格納される。シリアル化については後述する。
テナントＩＤフィールド２２はテナントＩＤカラムから構成される。テナントＩＤフィールド２２には、各テナントのテナントＩＤが格納されている。テナントＩＤとはテナントを特定する識別子である。本実施形態では、テナント１３のテナントＩＤをＴｉｄ１３、テナント１４のテナントＩＤをＴｉｄ１４、テナント１５のテナントＩＤをＴｉｄ１５として説明することにするが、これに限定されるものではない。
データ構造情報作成部１０１は、テナント１３〜１５から各テナントのデータ構造定義情報およびテナントＩＤを受け取ると、カラムマッピング情報を作成し、これらに基づいてデータ構造情報１０２１を作成する。そして、データ構造情報作成部１０１はデータ構造情報１０２１をデータベース１０２に格納する。
テナント１３〜１５から受け取るデータ構造定義情報には、「カラム名の情報」、「データ型の情報」、「制約に関する情報」および「シリアライズ処理するか否かを示す情報」等が含まれる。「シリアライズ処理するか否かを示す情報」に関しては、例えば、将来的に検索対象となる可能性のあるデータについては「シリアライズ対象ではない」と判断することができる。
図３に、テナント１３が「健康管理をしたい」と考えている場合のデータ構造定義情報３０の例を示す。カラム名としては、年齢、体重、病歴、性別および名前の５種類が設定されている。
データ構造定義情報３０の「年齢」カラムのデータは、「データ型は数値型であり、制約はＮｏｔ  Ｎｕｌｌであり、テナント１３がシリアライズ処理の対象（シリアライズ対象）と考えている」ことを意味している。Ｎｏｔ  Ｎｕｌｌとは空のデータ挿入を許可しないという制約である。なお、図３の例では、「制約」のカラムが空欄の場合、無制約であることを意味している。
また、「体重」カラムのデータは、「データ型は数値型であり、制約は無く、テナント１３がシリアライズ対象でないと考えている」ことを意味している。
また、「病歴」カラムのデータは、「データ型は文字列型であり、制約はなく、テナント１３がシリアライズ対象と考えている」ことを意味している。
また、「性別」カラムのデータは、「データ型は文字列型であり、制約はなく、テナント１３がシリアライズ対象でないと考えている」ことを意味している。
また、「名前」カラムのデータは、「データ型は文字列型であり、制約はなく、テナント１３がシリアライズ対象であると考えている」ことを意味している。
図４に、テナント１４が「ジョブマッチングをしたい」と考えている場合のデータ構造定義情報４０の例を示す。カラム名としては、ＴＯＥＩＣスコア、専門分野および興味分野の３種類が設定されている。
データ構造定義情報４０の「ＴＯＥＩＣスコア」のカラムのデータは、「データ型は数値型であり、制約はＣｈｅｃｋ（１０以上９９０以下）であり、テナント１４がシリアライズ対象でないと考えている」ことを意味している。Ｃｈｅｃｋとは、検査内容に合致しない値を挿入できない制約である。Ｃｈｅｃｋ（１０以上９９０以下）とは、ＴＯＥＩＣスコアが１０以上９９０以下の場合のみデータスキーマ１２１へのデータ挿入を許可することを意味している。また、「専門分野」のカラムのデータは、「データ型は文字列型であり、制約はなく、テナント１４がシリアライズ対象ではないと考えている」ことを意味している。また、「興味分野」のカラムは、「データ型は文字列型であり、制約はなく、テナント１４がシリアライズ対象であると考えている」ことを意味している。
なお、データ構造定義情報４０は、図３の場合と同様、「制約」のカラムが空欄の場合、無制約であることを意味している。
制約として、Ｎｏｔ  Ｎｕｌｌ（非Ｎｕｌｌ制約とも呼ばれる。）やＣｈｅｃｋ（検査制約とも呼ばれる。）以外に、Ｕｎｉｑｕｅ（一意性制約とも呼ばれる。）やＲｅｆｅｒｅｎｃｅ（外部キー制約とも呼ばれる。）が使用されても良い。Ｕｎｉｑｕｅとは、同じカラムに同一の値は挿入できないという制約である。一方、Ｒｅｆｅｒｅｎｃｅとは、指定されたあるテーブルのあるコラム内には同じ値がなければ挿入できないという制約である。
データ構造情報作成部１０１は、データスキーマ１２１上のカラムと各テナントのデータ構造定義情報との対応関係を示すカラムマッピング情報を作成する。カラムマッピング情報の作成においては、「シリアライズするか否かを判断する段階」と「シリアライズしないカラムを機能フィールド２１のいずれのカラムに格納するかを判断する段階」とが必要である。
シリアライズするか否かについては、データ構造定義情報における「制約」のカラムと「シリアライズするか否か」のカラムとに基づいて判断される。すなわち、制約が設定されている（第２の条件）か、あるいは、テナントによって明示的にシリアライズしないよう設定されている（第１の条件）場合には、シリアライズすべきでないと判断される。制約が設定されている場合にシリアライズしないと判断する理由は、データベースの機能を利用してカラムに格納されるデータの検査をする必要があるためである（すでにシリアライズ処理された情報を検査することはできない）。
また、テナントによる明示的なシリアライズ処理するか否かの設定は、例えば、カラムを検索の条件としたり演算処理の対象としたりする予定があるか等の理由により、データベースの機能を適用可能とすることを、テナントが直接指定する場合に利用される。
シリアライズされないデータは、「データ型」に基づいて、機能フィールド２１内のいずれかのカラムに割り当てられる。図２に示すように、データスキーマ１２１に予めデータ型毎のカラムをそれぞれ複数個ずつ用意し、シリアライズ処理しないデータとデータ型が一致するカラムを左から順に割り当てるような構成にしても良い。
なお、本実施形態では、テナント間で同じカラムが利用されることになるが、これに限定されるものではない。テナント毎に異なる制約を定義したい等の理由で、テナント間で同じカラムを利用したくない場合には、テナント毎にカラムを分けて割り当てる設定にしても良い。
図５Ａに、データ構造定義情報３０、４０とカラムマッピング情報５０、５１とデータスキーマ１２１との対応関係を示す。
データ構造定義情報３０に対応するカラムマッピング情報５０では、データ構造定義情報３０の「年齢」カラムに対応するデータは数値型１のカラムに格納され、データ構造定義情報３０の「体重」カラムに対応するデータは数値型２のカラムに格納され、データ構造定義情報３０の「病歴」カラムに対応するデータはシリアルフィールド２０のカラムに格納され、データ構造定義情報３０の「性別」カラムに対応するデータは文字列型１のカラムに格納され、データ構造定義情報３０の「名前」カラムに対応するデータはシリアル化カラムに格納されることを意味している。
データ構造定義情報４０に対応するカラムマッピング情報５１では、データ構造定義情報４０の「ＴＯＥＩＣスコア」カラムに対応するデータは数値型１のカラムに格納され、データ構造定義情報４０の「専門分野」のカラムに対応するデータは文字列型１のカラムに格納され、データ構造定義情報４０の「興味分野」のカラムに対応するデータはシリアルフィールド２０のカラムに格納されることを意味している。
次にデータ構造情報１０２１について説明する。データ構造情報１０２１はデータ構造定義情報とカラムマッピング情報とを合わせたものであり、データ構造情報作成部１０１により作成される。
図６に、テナント１３が「健康管理をしたい」と考えている場合のデータ構造情報６０を示す。
データ構造情報６０はデータ構造定義情報３０とカラムマッピング情報５０とを合わせたものである。データ構造情報６０は、「年齢」カラムに関し、データ型は数値型であり、制約はＮｏｔ  Ｎｕｌｌであり、データスキーマ１２１上のカラムは数値型１であることを示している。また、「体重」カラムに関し、データ型は数値型であり、制約はなく、データスキーマ上のカラムは数値型２であることを示している。また、「病歴」カラムに関し、データ型は文字列型であり、制約はなく、データスキーマ上のカラムはシリアルであることを示している。また、「性別」カラムに関し、データ型は文字列型であり、制約はなく、データスキーマ上のカラムは文字列型であることを示している。また、「名前」のカラムに関し、データ型は文字列型であり、制約はなく、データスキーマ上のカラムはシリアルであることを示している。
図７に、テナント１４が「ジョブマッチングをしたい」と考えている場合のデータ構造情報７０を示す。データ構造情報７０は、「ＴＯＥＩＣスコア」カラムに関し、データ型は数値型であり、制約はｃｈｅｃｋ（１０以上，９９０以下）であり、データスキーマ上のカラムは数値型１であることを意味している。「専門分野」カラムに関し、データ型は文字列型であり、制約はなく、データスキーマ上のカラムは文字列型１であることを意味している。「興味分野」カラムに関し、データ型は文字列型であり、制約はなく、データスキーマ上のカラムはシリアルであることを示している。
データ変換処理部１０３は、入力装置および出力装置となるテナント１３〜１５とマルチテナント型データベース１２との間の仲介役となり、テナント独自のデータ構造を持つデータとデータスキーマ１２１との間の形式の違いを吸収する。データ変換処理部１０３は、テナントからデータおよびテナントＩＤの入力を受け取ると、データ構造情報作成部１０１からテナントＩＤに対応づけられたデータ構造情報１０２１を受け取る。そして、データ変換処理部１０３は、データ構造情報１０２１に基いて、保存すべきデータをマルチテナント型データベース１２内の適切なカラムに格納する。このとき、シリアル化フィールド２０のカラムに割り当てられるデータについては、シリアライズ処理部１０４がシリアライズ処理を行った後に挿入する。
また、データ変換処理部１０３は、テナントからデータの問合せ（データ検索要求）およびテナントＩＤの入力を受け取った場合には、マルチテナント型データベース１２からデータ検索要求に対応するデータを取り出す。そして、データ変換処理部１０３はデータ構造情報作成部１０１からテナントＩＤに対応づけられたデータ構造情報１０２１を受け取る。そして、データ変換処理部１０３は、データ構造情報１０２１に基いて、マルチテナント型データベース１２から取り出したデータをテナント独自のデータ構造に変換して、出力装置となるテナントに出力する。このとき、シリアル化フィールド２０のカラムに割り当てられていたデータについては、シリアライズ処理部１０４がデシリアライズ処理を施した上で出力する。
一般的に、シリアライズ処理とは、何らかの構造を持つ複数のデータをまとめて単一のデータに変換する処理であり、変換されたデータは元の複数のデータに復元できる。元のデータに復元することをデシリアライズ処理と呼ぶ。
本実施形態では、一般的に知られているシリアライズ処理の方法を利用することができる。例えば、第１のカラム名が「ｎａｍｅ」で第２のカラム名が「ｎｕｍｂｅｒ」のデータ構造に対し、第１のカラムのデータが「ｓｕｚｕｋｉ」で第２のカラムのデータが「１０」のデータがあるとする。これをシリアライズする方法として、例えば「ｎａｍｅ＝ｓｕｚｕｋｉ＆ｎｕｍｂｅｒ＝１０」などの文字列に変換する方法がある。ただし、好適には処理が高速でシリアライズ後のデータサイズが小さい方法が望ましい。
データ構造情報６０の場合、「病歴」のカラムと「名前」のカラムとがシリアライズ対象である。例えば、病歴が高血圧、名前が鈴木であった場合、「病歴＝高血圧＆名前＝鈴木」となる。一方、データ構造情報７０の場合、「興味分野」のカラムのみがシリアライズ対象である。
次に、本実施形態の動作について説明する。本実施形態では、予めデータ構造情報作成部１０１がデータ構造情報１０２１を作成しておき、その後、マルチテナント型データベース１２上でデータの格納と検索が行われる。まず、データ構造情報１０２１の作成に関する動作について図８のフローチャートを用いて説明する。
データ構造情報作成部１０１は、入力装置となるテナントから、データ構造定義情報およびテナントＩＤを受け取る（ステップＳ８０１）。データ構造情報作成部１０１は、データ構造定義情報内のデータを機能フィールド２１のどのカラムに格納するかを判断し、カラムマッピング情報を作成する（ステップＳ８０２）。そして、データ構造情報作成部１０１は、データ構造定義情報とカラムマッピング情報とからデータ構造情報１０２１を作成し、テナントＩＤと紐付けてデータベース１０２に格納しておく（ステップＳ８０３）。
次に、図９のフローチャートを用いて、マルチテナント型データベース１２へのデータ格納動作について説明する。
データ変換処理部１０３は、入力装置となるテナントから、テナントＩＤを受け取る（ステップＳ９０１）。データ変換処理部１０３は、データ構造情報作成部１０１からテナントＩＤに紐付けられたデータ構造情報１０２１を取得する（ステップＳ９０２）。データ変換処理部１０３は、データ構造情報１０２１に基づいて、これからデータスキーマ１２１に格納するデータの中にシリアル化カラムに格納すべきデータがあるか否かを判断する（ステップＳ９０３）。データ変換処理部１０３は、シリアル化カラムに格納すべきデータがあると判断した場合には、シリアル化カラムに格納するデータをまとめてシリアライズ処理部１０４に送る（ステップＳ９０４）。そして、シリアライズ処理部１０４は、シリアル化カラムに格納するデータをシリアライズ処理し、データ変換処理部１０３に出力する（ステップＳ９０５）。データ変換処理部１０３は、データ構造情報作成部１０１から取得したデータ構造情報１０２１に基づいて、入力装置となるテナントから取得したデータの各カラムを、データスキーマ１２１の機能フィールド２１内のカラムの形式に変換する（ステップＳ９０６）。データ変換処理部１０３は、カラム変換された格納すべきデータおよびシリアライズ処理されたデータをマルチテナント型データベース１２のデータスキーマ１２１に格納する（ステップＳ９０７）。
一方、シリアル化カラムに格納すべきデータがないと判断した場合には、データ変換処理部１０３は、取得したデータ構造情報１０２１に基づいて、入力装置となるテナントから取得したデータのカラムをデータスキーマ１２１内の機能フィールド２１のカラムの形式に変換する（ステップＳ９０６）。そして、データ変換処理部１０３は、カラム変換された格納すべきデータおよびシリアライズ処理されたデータをマルチテナント型データベース１２のデータスキーマ１２１に格納する（ステップＳ９０７）。
次に、図１０のフローチャートを用いて、本実施形態におけるデータの問合せ（データ検索要求）に対する動作について説明する。
データ変換処理部１０３は、入力装置となるテナントから、データ検索要求およびテナントＩＤを受け取る（ステップＳ１００１）。データ変換処理部１０３は、データ構造情報作成部１０１から、テナントＩＤに紐付けられたデータ構造情報１０２１を取得する（ステップＳ１００２）。データ変換処理部１０３は、取得したデータ構造情報１０２１に基づいて、データ検索要求に含まれるテナント独自のデータ構造を持つカラムを、データスキーマ１２１内の機能フィールド２１の適切なカラムに変換する（ステップＳ１００３）。データ変換処理部１０３は、上記データ検索要求をマルチテナント型データベース１２に対して発行し、データを取得する（ステップＳ１００４）。データ変換処理部１０３は、マルチテナント型データベース１２から取得したデータの中にシリアル化カラムに格納されているデータがあるか否かを判断する（ステップＳ１００５）。
データ変換処理部１０３は、シリアル化カラムに格納されているデータがある場合には、シリアル化カラムに格納されたデータをシリアライズ処理部１０４に出力する。そして、シリアライズ処理部１０３は、シリアル化カラムに格納されているデータをデシリアライズ処理し、データ変換処理部１０３に出力する（ステップＳ１００６）。
次に、データ変換処理部１０３は、データ構造情報１０２１に基づいて、デシリアライズ処理されたデータおよび機能フィールド２１に格納されたデータのカラムを、テナント独自のデータ構造で定義された適切なカラムに変換する（ステップＳ１００７）。データ変換処理部１０３は、カラム変換されたデータを出力装置となるテナントに出力する（ステップＳ１００８）。
一方、データ変換処理部１０３は、シリアル化カラムに格納されているデータがない場合には、マルチテナント型データベース１２から取得したデータを、データ構造情報１０２１に基づいてカラム変換する（ステップＳ１００７）。ステップＳ１００７のカラム変換では、機能フィールド２１に格納されたデータが、テナント独自のデータ構造で定義された適切なカラムに変換される。そして、データ変換処理部１０３は、カラム変換されたデータを出力装置となるテナントに出力する（ステップＳ１００８）。
本実施形態では、複数のデータがまとめてシリアライズ処理されてシリアル化カラムに格納されるため、テナントは、事前に用意されたカラム数に制限されずに、任意のカラム数の独自のデータ構造を定義することができる。また、本実施形態のデータスキーマ１２１は、シリアライズ処理されたデータが格納されるシリアル化フィールド２０とシリアライズされていないデータが格納される機能フィールド２１との両方を備えている。よって、テナントはマルチテナント型データベース１２が提供する機能群を柔軟に適用することができる。さらに、本実施形態は、マルチテナント型データベース１２が提供する機能を利用する必要のないデータについては事前に大量のカラムを容易する必要がなくなるため、実際には利用しないカラムによる性能低下やハードウェア資源の無駄を削減できるという効果も有する。
（第１の実施形態の変形例）
次に、第１の実施形態の変形例について説明する。
第１の実施形態は、データスキーマ１２１に予めデータ型毎のカラムをそれぞれ複数個ずつ用意し、シリアライズ処理しないデータとデータ型が一致するカラムを左から順に割り当てるという構成であった。これに対し、本変形例では、データ型が一致するものを同じカラムに格納し、さらに、制約がある場合にはその制約内容も一致するようにデータを格納している点が第１の実施形態とは異なる。その他の構成は第１の実施形態と同様であるため、詳細な説明は省略する。
図５Ｂに、本変形例における、データ構造定義情報３０−１、４０−１とカラムマッピング情報５０−１、５１−１とデータスキーマ１２１―１との対応関係を示す。第１の実施形態では、ＴＯＥＩＣスコアカラムのデータは数値型１カラムに格納されていたが、本変形例では、数値型３カラムに格納される。なぜなら、データ構造定義情報３０−１の年齢カラムで定義されたＮｏｔ  Ｎｕｌｌの制約とデータ構造定義情報４０−１のＴＯＥＩＣスコアカラムで定義されたＣｈｅｃｋの制約とは同じカラムに同居することはできないからである。
本変形例においても、第１の実施形態と同様、複数のデータがまとめてシリアライズ処理されてシリアル化カラムに格納される。そのため、テナントは、事前に用意されたカラム数に制限されずに、任意のカラム数の独自のデータ構造を定義することができる。また、本変形例のデータスキーマ１２１―１は、シリアライズ処理されたデータが格納されるシリアル化フィールド２０とシリアライズされていないデータが格納される機能フィールド２１との両方を備えている。よって、テナントはマルチテナント型データベース１２が提供する機能群を柔軟に適用することができる。さらに、本実施形態は、マルチテナント型データベース１２が提供する機能を利用する必要のないデータについては事前に大量のカラムを容易する必要がなくなる。そのため、実際には利用しないカラムによる性能低下やハードウェア資源の無駄を削減できるという効果も有する。
（第２の実施形態）
次に、第２の実施形態について説明する。
第１の実施形態では、検索対象となる可能性のあるカラムのデータ等については、テナントが予め、データ構造定義情報において「シリアライズ対象ではない」と設定していた。しかしながら、テナントによるシリアライズ対象であるか否かの判断は完全なものではなく、さらに手間がかかるという問題があった。
本実施形態では、制御装置１０Ａがプログラム（ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）等）までを解析して、シリアライズするか否かを自動的に判断する。本実施形態では、入力装置となるテナントのプログラム（ＳＱＬ）上で検索対象となっているカラムのデータについてはシリアライズ処理しないと判断するようにする。
図１１に、第２の実施形態におけるマルチテナント型データベースシステム１１を示す。制御装置１０Ａがプログラム解析部１０５を備える点以外は第１の実施形態と同様の構成である。プログラム解析部１０５が、マルチテナント型データベース１２を利用する外部装置（テナント１３〜１５のいずれか）のプログラム解析によってシリアライズ処理するカラムを判断する点が第１の実施形態とは異なる。
プログラム解析部１０５は、データ構造情報作成部１０１と接続されている。プログラム解析部１０５は、入力装置となるテナントからプログラムの入力を受け、テナントの個別処理を記述する部分からマルチテナント型データベース１２への問合せに関する処理部分を抽出する。そして、プログラム解析部１０５は、問合せ内容から、テナント独自のデータ構造内の各カラムについてシリアライズ処理するか否かを判断する。
例えば、プログラム中から「ＳＥＬＥＣＴ＊ＦＲＯＭ  ｔａｂｌｅ１  ＷＨＥＲＥ  ｃｏｌｕｍｎ１＝１；」というＳＱＬ文が抽出された場合であれば、「ｃｏｌｕｍｎ１」は検索対象のカラムであるため、プログラム解析部１０５はシリアライズ処理すべきでないと判断する。プログラム解析部１０５は、このように判断された結果をデータ構造情報作成部１０１に通知し、データ構造情報１０２１に反映させる。
次に、図１２のフローチャートを用いて、第２の実施形態の動作について説明する。
基本的には、図８のフローチャートと同様であるが、本実施形態では、ステップＳ８０１（本実施形態ではステップＳ１２０１とする。）の後に、プログラム解析部１０５が、入力装置となるテナントからプログラムの入力を受ける（ステップＳ１２０２）。その後、プログラム解析部１０５は、入力されたプログラムから各テナントのマルチテナント型データベース１２への問合せに関する処理部分を抽出して解析する（ステップＳ１２０３）。次に、プログラム解析部１０５は、テナント独自のデータ構造を持つデータの各カラムについてシリアライズ処理するか否かを判断し、データ構造情報作成部１０１に通知する（ステップＳ１２０４）。
図８のステップＳ８０１およびステップＳ８０２に対応する動作（本実施形態ではステップＳ１２０５およびステップＳ１２０６とする。）については第１の実施形態と同様であるため、詳細な説明は省略する。
本実施形態は、入力装置となるテナントの代わりに、プログラム解析部１０５がシリアライズ対象のカラムのデータであるか否かの判断を自動的に行う構成である。そのため、本実施形態によれば、テナントの手間を省き、かつ、シリアライズ対象であるか否かの判断の正確性を向上することができる。
なお、第２の実施形態の変形例として、第１の実施形態と同様に、入力装置となるテナントがシリアライズ対象か否かの情報を含むデータ構造定義情報を作成した上で、さらにプログラム解析部１０５がシリアライズ対象のカラムのデータであるか否かの判断を行ってデータ構造定義情報およびデータ構造情報１０２１を更新するような構成にしても良い。この場合、入力装置となるテナントが予めシリアライズ対象であるか否かの判断を行わないといけないためテナントの手間を省くことはできない。しかし、このような構成によれば、シリアライズ対象であるか否かの判断の正確性を、より一層向上することができる。
（第３の実施形態）
次に、第３の実施形態について説明する。
第２の実施形態では、入力装置となるテナントのプログラム内容からシリアライズ対象のカラムのデータであるか否かを判断していた。しかし、本実施形態では、実行時の動作履歴（実際に制御装置１０Ｂに発行されたＳＱＬ文の内容）を解析して、シリアライズ対象のカラムのデータであるか否かを判断する。
図１３に、本実施形態におけるマルチテナント型データベースシステム１３を示す。本実施形態では、第２の実施形態のプログラム解析部１０５の代わりに、入力された問合せ内容の解析によってシリアライズ処理すべきカラムか否かを判断する問合せ解析部１０６を備える。その他の構成は第２の実施形態と同様であるため、詳細な説明は省略する。
第３の実施形態では、問合せ解析部１０６はデータ構造情報作成部１０１とデータ変換処理部１０３とに接続されている。問合せ解析部１０６は、入力装置となるテナントからマルチテナント型データベース１２に対する問合せおよびテナントＩＤの入力を受け、それらをデータ変換処理部１０３へ通知する。その際、問合せの内容を解析し、テナント独自のデータ構造をもつデータの各カラムについてシリアライズ処理するか否かを判断する。現在シリアライズをする設定となっているカラムがシリアライズ処理すべきでないと判断された場合には、問合わせ解析部１０６はデータ構造情報作成部１０１に対してその旨を通知してデータ構造情報１０２１を更新する。そして、問合わせ解析部１０６は、マルチテナント型データベース１２にアクセスしてシリアル化カラムに格納されているデータを機能フィールド２１のカラムへ移動させる。
次に、図１４のフローチャートを用いて、本実施形態の動作について説明する。
基本的には、図１０と同様であるが、データ変換処理部１０３ではなく問合せ解析部１０６が入力装置となるテナントからマルチテナント型データベース１２に対する問合せおよびテナントＩＤの入力を受ける点が異なる。さらに、問合せ解析部１０６が、入力された問合わせを解析することにより、テナント独自のデータ構造内の各カラムについてシリアライズ処理するか否かを判断する点が異なる。
まず、問合わせ解析部１０６は、入力装置となるテナントから、データの問合せ（データ検索要求）およびテナントＩＤを受け取る（ステップＳ１４０１）。問合わせ解析部１０６はデータ検索要求の解析を行う（ステップＳ１４０２）。問合わせ解析部１０６は、テナント独自のデータ構造内の各カラムについてシリアライズ処理するか否かを判断する（ステップＳ１４０３）。現在シリアライズ処理を行う設定となっているカラムがシリアライズ処理すべきでないと判断された場合、問合わせ解析部１０６は、データ構造情報作成部１０１に対してその旨を通知してデータ構造情報１０２１を更新する（ステップＳ１４０４）。そして、問合せ解析部１０６はマルチテナントデータベース１２にアクセスして、シリアル化カラムに格納されているデータを機能フィールド２１のカラムに移動させる（ステップＳ１４０５）。その後の問合せの処理はデータ変換処理部１０３に委譲される（ステップＳ１４０６）。その後は、第１の実施形態における図１０のステップＳ１００２以降の動作と同様の動作が行われるが、詳細な説明は省略する。
一方、ステップＳ１４０３において、新たなシリアライズ処理すべきでないカラムがないと判断された場合も、問合せ処理はデータ変換処理部１０３に委譲される（ステップＳ１４０６）。その後の動作は、第１の実施形態における図１０のステップＳ１００２以降の動作と同様であるが、詳細な説明は省略する。
本実施形態では、入力装置となるテナントの代わりに、問合わせ解析部１０６がマルチテナント型データベース１２に対するテナントからの問合せ（データ検索要求）を解析してシリアライズ対象のカラムのデータであるか否かの判断を自動的に行う構成である。そのため、本実施形態によればテナントの手間を省き、かつ、シリアライズ対象であるか否かの判断の正確性を向上することができる。また、第２の実施形態ではテナントから入力されたプログラムを解析する構成であったが、本実施形態ではそのステップを省くことができ、処理効率を向上させることができる。
なお、第３の実施形態の変形例として、第１の実施形態と同様に、入力装置となるテナントがシリアライズ対象か否かの情報を含むデータ構造定義情報１０２１を作成した上で、問合せ解析部１０６が、データ検索要求に基づいて、シリアライズ対象のカラムのデータであるか否かの判断を行って、データ構造定義情報およびデータ構造情報１０２１を更新するような構成にしても良い。この場合、入力装置となるテナントが予めシリアライズ対象であるか否かの判断を行わないといけないためテナントの手間を省くことはできない。しかし、このような構成によれば、シリアライズ対象であるか否かの判断の正確性を、より一層向上することができる。
本実施形態では、各テナントが１つのテナントＩＤを持つ構成としたが、これに限定されるものではない。各テナントが複数のテナントＩＤを持ち、各テナントＩＤにそれぞれデータ構造情報１０２１が紐付けられるような構成にしても良い。
なお、本発明の記録媒体に格納されるプログラムは、上述の実施形態で説明した各動作を、コンピュータに実行させるプログラムであれば良い。図１５は、制御装置１０のハードウェア構成図である。図１５に示すように、制御装置１０は、ＣＰＵ（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）２と、通信インターフェース（ＩＦ）３と、メモリ４と、ＨＤＤ（ハードディスクドライブ）５と、入力装置６と、出力装置７との組み合わせで実現される。これらの構成要素は、バス８を通して互いに接続されており、データの入出力を行なう。通信ＩＦ３は、外部のネットワークに接続するためのインターフェースである。入力装置６は、例えば、キーボードやマウスである。出力装置７は、例えばディスプレイなどである。制御装置１０は、ＣＰＵ２が、メモリ４又はＨＤＤ５等の記憶媒体に記憶されているプログラムを実行することにより実現されてもよい。
本発明の実施形態は、以下の付記記載のデータベースシステムであっても良い。
（付記１）データスキーマの機能フィールドはデータ型に基づいて複数のフィールドに分けられており、制御装置は、シリアライズ処理の対象ではないと判断されたカラムのデータのデータ型に基づいて、当該データを機能フィールドのいずれかのカラムに格納することを特徴とするデータベースシステム。
（付記２）予めテナント用の情報処理装置によりシリアライズ処理の対象ではないと設定されているという第１の条件、および、データスキーマへのデータ格納に関して何か制約があるという第２の条件のいずれかを満たすカラムのデータに対しては、制御装置は、シリアライズ処理の対象ではないと判断することを特徴とするデータベースシステム。
以上、実施の形態を参照して本願発明を説明したが、本願発明は以上の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で同業者が理解し得る様々な変更をすることができる。
この出願は、２０１０年３月１０日に出願された日本出願特願２０１０−０５２６３２を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０００９】
１  マルチテナント型データベースシステム
２  ＣＰＵ
３  通信ＩＦ
４  メモリ
５  ＨＤＤ
６  入力装置
７  出力装置
８  バス
１０  制御装置
１０Ａ  制御装置
１０Ｂ  制御装置
１０１  データ構造情報作成部
１０２  データベース
１０３  データ変換処理部
１０４  シリアライズ処理部
１０５  プログラム解析部
１０６  問合せ解析部
１２  マルチテナント型データベース
１２１  データスキーマ
１２１−１  データスキーマ
１３  テナント用の情報処理装置
１４  テナント用の情報処理装置
１５  テナント用の情報処理装置
２０  シリアル化フィールド
２１  機能フィールド
２１１  数値型フィールド
２１２  文字列型フィールド
２１３  日付型フィールド
２２  テナントＩＤフィールド
３０  テナント１３によるデータ構造定義情報
３０−１  テナント１３によるデータ構造定義情報
４０  テナント１４によるデータ構造定義情報
４０−１  テナント１４によるデータ構造定義情報
５０  カラムマッピング情報
５０−１  カラムマッピング情報
５１  カラムマッピング情報
５１−１  カラムマッピング情報
６０  データ構造情報
７０  データ構造情報
【図１】
2011111532.tif 000003
【図２】
2011111532.tif 000004
【図３】
2011111532.tif 000005
【図４】
2011111532.tif 000006
【図５Ａ】
2011111532.tif 000007
【図５Ｂ】
2011111532.tif 000008
【図６】
2011111532.tif 000009
【図７】
2011111532.tif 000010
【図８】
2011111532.tif 000011
【図９】
2011111532.tif 000012
【図１０】
2011111532.tif 000013
【図１１】
2011111532.tif 000014
【図１２】
2011111532.tif 000015
【図１３】
2011111532.tif 000016
【図１４】
2011111532.tif 000017
【図１５】
2011111532.tif 000018
【国際調査報告】
2011111532.tif 000019
2011111532.tif 000020
2011111532.tif 000021
2011111532.tif 000022
2011111532.tif 000023
2011111532.tif 000024