JP2020113210A - 情報処理装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】マルチテナントデータベースにおいて複数のテナントが単一の物理テーブルを共有する場合において、特にカラムの定義の変更の取消し操作を容易にするための技術を提供する。【解決手段】情報処理装置は、マルチテナントデータベースにおいて複数のテナントが共有する物理テーブルに対してデータ操作を行う。具体的には、情報処理装置は、テナント毎に定義される論理テーブルのカラムと物理テーブルのカラムとの対応付けをテナント毎に定義するマッピング情報に基づいて、テナントのユーザに応じたデータ操作を行うデータ操作部と、論理テーブルのカラムについて定義を変更する操作の入力を受けた場合、物理テーブルのカラムは保持したまま、マッピング情報において削除対象のカラムと物理テーブルのカラムとの対応付けを削除するテーブル定義操作部とを備える。【選択図】図２

Description

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

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

特許第６３７８４９７号公報

マルチテナントデータベースにおいて複数のテナントが単一の物理テーブルを共有する場合、例えばあるテナントユーザのデータ操作に起因して誤ったデータ削除が行われたときは、容易にはテーブル全体をロールバックさせることができないという問題があった。すなわち、他のテナントユーザの正常なデータにも影響が及ぶため、物理テーブル全体を過去の状態に戻すことが実際的でない。また、上述のように、汎用的な物理テーブルを複数のテナントが所望の論理テーブルとして利用するような場合には、テーブルの追加や削除、カラム単位の変更のたびに１つの物理テーブルに対するテーブル操作が生じるところ、複数のテナントが物理テーブルを共有しているため特に誤操作の取消しを行う際の影響が及ぶ範囲がテナントごとに別個のテーブルを作成させる場合と比べて大きくなってしまうという問題があった。

そこで、本発明は、マルチテナントデータベースにおいて複数のテナントが単一の物理テーブルを共有する場合において、特にカラムの定義の変更の取消し操作を容易にするための技術を提供することを目的とする。

本発明の一側面に係る情報処理装置は、マルチテナントデータベースにおいて複数のテナントが共有する物理テーブルに対してデータ操作を行う。具体的には、情報処理装置は、テナント毎に定義される論理テーブルのカラムと物理テーブルのカラムとの対応付けをテナント毎に定義するマッピング情報に基づいて、テナントのユーザに応じたデータ操作を行うデータ操作部と、論理テーブルのカラムについて定義を変更する操作の入力を受けた場合、物理テーブルのカラムは保持したまま、マッピング情報において削除対象のカラムと物理テーブルのカラムとの対応付けを削除するテーブル定義操作部とを備える。

カラムの削除を、マッピング情報の変更により論理的に行うため、例えば削除の取消しを行う場合において、物理テーブルへの影響を抑えることができる。すなわち、マルチテナントデータベースにおいて複数のテナントが単一の物理テーブルを共有する場合において、特にカラムの削除の取消し操作を容易にするための技術を提供することができる。

また、テーブル定義操作部は、マッピング情報に対する変更の履歴を記憶装置に記憶させるようにしてもよい。このようにすれば、履歴に基づいてマッピング情報を過去の状態に復元することができる。

また、テーブル定義操作部は、論理テーブルに対して新たなカラムを追加する場合、マッピング情報に対する変更の履歴において既に論理テーブルのカラムと対応付けられた物理テーブルのカラムを避けて、論理テーブルに対して追加された新たなカラムと、物理テーブルのカラムとの対応づけを行うようにしてもよい。このようにすれば、論理テーブルから削除されたカラムのフィールドに保持されていたデータを、物理テーブルにおいては保持させておくことができる。

また、テーブル定義操作部は、定義を変更した論理テーブルのカラムについて変更を取り消す操作の入力を受けた場合、マッピング情報において削除したカラムと物理テーブルのカラムとの対応付けを登録するようにしてもよい。このようにすれば、論理テーブルから削除されたカラムを復元することができる。また、論理テーブルから削除されたカラムのフィールドに保持されていたデータを、物理テーブルにおいては保持させてあれば、カラムの復元と同時に当該カラムのフィールドに保持されていたデータも復元することができる。

また、テーブル定義操作部は、デフラグの指示を受けた場合、論理テーブルのカラムと対応付けられていない物理テーブルのカラムのフィールドからデータを削除し、論理テーブルのカラムに対して物理テーブルのカラムを対応付けし直すようにしてもよい。このようにすれば、物理テーブルの利用を効率的にすることができる。

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

本発明によれば、マルチテナントデータベースにおいて複数のテナントが単一の物理テーブルを共有する場合において、特にカラムの定義の変更の取消し操作を容易にするための技術を提供することができる。

システムの概略構成を示す図である。 マルチテナントサーバ及びテナント装置の一例を示すブロック図である。 物理テーブルのテーブル構造の一例を示す図である。 テナントＡがマルチテナントサーバに保持させる論理テーブルと格納データの一例である。 テナントＡがマルチテナントサーバに保持させる論理テーブルと格納データの一例である。 テナントＢがマルチテナントサーバに保持させる論理テーブルと格納データの一例である。 メタデータとして登録される内容の一例を示す表である。 メタデータとして登録される内容の一例を示す表である。 メタデータとして登録される内容の一例を示す表である。 物理テーブルに格納されるレコードの一例を示す図である。 メタデータの設定により論理テーブルを作成する設定処理の一例を示す処理フロー図である。 データ操作処理の一例を示す処理フローである。 定義変更処理の一例を示す処理フロー図である。 テーブル構造を変更した後の論理テーブルの一例を示す図である。 テーブル構造を変更した後のマッピング情報の一例を示す図である。 テーブル構造を変更した後の物理テーブルの一例を示す図である。 定義復元処理の一例を示す処理フロー図である。 テーブル構造を復元した後のマッピング情報の一例を示す図である。 テーブル構造を復元した後のマッピング情報の他の例を示す図である。 テーブル構造を復元した後の論理テーブルの一例を示す図である。 デフラグを行った後のマッピング情報の一例を示す。

以下、図面を参照して本発明を実施するための形態について説明する。

＜システム構成＞
図１は、システムの概略構成の一例を示す図である。図１の例では、本発明に係るマルチテナントサーバ１と、テナント装置２（図１においては、「２ａ」、「２ｂ」、・・・）とが、ネットワーク３を介して接続されている。マルチテナントサーバ１は、複数のテナントユーザに対して、共通したハードウェアリソース及びソフトウェアリソースを使用させるマルチテナントサービスを提供する装置である。マルチテナントサーバ１は、所定のテーブル構造（「データベース構造」又は「スキーマ」とも呼ぶ）を有する物理テーブルを、複数のテナントユーザに使用させる。テナント装置２は、マルチテナントサービスを利用する企業の社員等のようなテナントユーザが使用する装置である。便宜上、テナント装置２ａはあるテナントＡの端末であり、テナント装置２ｂは他のテナントＢの端末であるものとする。テナントの数は２つには限られず、複数のテナント装置２が存在し得る。各テナント装置２は、ネットワーク３を介してマルチテナントサーバ１と通信可能に接続され、データ操作を要求したり、処理結果を受け取ったりする。

＜装置構成＞
図２は、マルチテナントサーバ１及びテナント装置２の一例を示すブロック図である。

マルチテナントサーバ１は、一般的なコンピュータであり、通信インターフェース（Ｉ／Ｆ）１１と、入出力装置１２と、記憶装置１３と、演算装置１４と、バス１５とを備える。通信Ｉ／Ｆ１１は、例えば有線のネットワークカードや無線の通信モジュール等であり、所定のプロトコルに基づき通信を行う。入出力装置１２は、例えばキーボードやマウス、ディスプレイ等のユーザインターフェースであり、入力装置と出力装置（例えば、表示装置）とを含む。また、タッチパネルのように入力装置と出力装置とが組み合わされていてもよい。

記憶装置１３は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の主記憶装置や、ＨＤＤ（Hard-disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置（二次記憶装置）を含む。主記憶装置は、プロセッサが読み出したプログラムを一時的に記憶したり、プロセッサの作業領域を確保したりする。補助記憶装置は、プロセッサが実行するプログラムや、各テナントの業務で使用するデータ等を記憶する。図２の例では、記憶装置１３内に機能ブロックを示している。具体的には、記憶装置１３は、物理テーブル１３１と、メタデータ１３２とを含む。物理テーブル１３１は、各テナントのデータを、例えば共通のテーブル構造を有する物理的なファイルとしてデータレコードを格納するＲＤＢ（Relational Database）のテーブルに格納する。テーブ
ル構造は、例えばＤＢＭＳ（Database Management System）がサポートするデータ定義言語で定義される。なお、物理テーブル１３１は、いわゆるインメモリデータベースであってもよい。また、いわゆるＮｏＳＱＬのようなデータモデルのデータベースであってもよい。メタデータ１３２は、各テナントに固有のテーブルの論理構造と、上述した物理テーブル１３１のテーブル構造との対応付けを定義するマッピング情報を含む。本実施形態では、物理テーブル１３１は各テナントが共通に使用する汎用的なテーブル構造を有している。そして、メタデータにおいて、論理テーブルの属性（「カラム」、「列」とも呼ぶ）に対し、物理テーブル１３１のカラムを割り当てる。このとき、論理テーブルにおいて必要なデータ型の属性を物理テーブル１３１の中から割り当てるものとする。

演算装置１４は、ＣＰＵ（Central Processing Unit）等のプロセッサであり、プログ
ラムを実行することにより本実施の形態に係る各処理を行う。図２の例では、演算装置１４にも機能ブロックを示している。具体的には、演算装置１４は、ＤＢＭＳ１４１、データ操作部１４２及び定義操作部１４３として機能する。ＤＢＭＳ１４１は、ＲＤＢのようなデータベースの運用管理に必要な機能を提供するシステムであり、物理テーブル１３１に対してレコードを生成、更新、削除、検索等する。なお、ＤＢＭＳ１４１は、様々なベンダーが提供する既存の製品を利用することができる。データ操作部１４２は、各テナントに固有のテーブルに対する操作の指示を各テナントのユーザから受け、物理テーブル１３１に対する命令に変換し、ＤＢＭＳ１４１に操作させる。例えば、データ操作部１４２は、メタデータ１３２が記憶するマッピング情報に基づいて、テナント装置２から受け付けたデータ操作要求を、ＤＢＭＳにおいて実行可能なデータ操作命令（「クエリ」、「問合せ」とも呼ぶ）に変換する。定義操作部１４３は、各テナントのユーザの操作に基づき、各テナントに固有のテーブルの論理的なテーブル構造等を生成、更新、削除する。以上のような構成要素が、所定の形式の信号線であるバス１５を介して接続されている。

また、テナント装置２も、一般的なコンピュータであり、通信インターフェース（Ｉ／Ｆ）２１と、入出力装置２２と、記憶装置２３と、演算装置２４と、バス２５とを備える。通信Ｉ／Ｆ２１は、例えば有線のネットワークカードや無線の通信モジュール等であり、所定のプロトコルに基づき通信を行う。入出力装置２２は、例えばキーボードやマウス、ディスプレイ等のユーザインターフェースであり、入力装置と出力装置（例えば、表示装置）とを含む。また、タッチパネルのように入力装置と出力装置とが組み合わされていてもよい。

記憶装置２３は、ＲＡＭ、ＲＯＭ等の主記憶装置や、ＨＤＤ、ＳＳＤ、フラッシュメモリ等の補助記憶装置を含む。主記憶装置は、プロセッサが読み出したプログラムを一時的に記憶したり、プロセッサの作業領域を確保したりする。補助記憶装置は、プロセッサが実行するプログラムや、マルチテナントサーバ１との間で送受信される情報等を一次的に又は永続的に記憶する。

演算装置２４は、ＣＰＵ等のプロセッサであり、プログラムを実行することにより本実
施の形態に係る各処理を行う。図２の例では、演算装置２４に機能ブロックを示している。具体的には、演算装置２４は、入出力制御部２４１として機能する。入出力制御部２４１は、入出力装置２２を介してユーザの操作を受け付け、マルチテナントサーバ１へデータ操作を要求したり、マルチテナントサーバ１から結果を受信してユーザに提示したりする。以上のような構成要素が、所定の形式の信号線であるバス２５を介して接続されている。

＜テーブル構造＞
図３は、物理テーブルのテーブル構造の一例を示す図である。物理テーブル１３１のテーブル構造は、各テナントが共通に使用する汎用的なものであり、テナントＩＤ（TenantID）、タイプＩＤ（TypeID）、データＩＤ（DataID）、ページＩＤ（PageID）、文字列型の項目１（Char1）、文字列型の項目２（Char2）、数値型の項目１（Num1）、数値型の項目２（Num2）、日付型の項目１（Date1）、日付型の項目２（Date2）等の属性（カラム）を含む。また、属性名の下に括弧書きでデータ型の一例が示されている。すなわち、テナントＩＤ、タイプＩＤ、データＩＤ、文字列型の項目１、２は、例えば文字列型の属性である。ページＩＤ、数値型の項目１、２は、例えば数値型の属性である。また、日付型の項目１、２は、例えば日付型の属性である。なお、各属性のデータサイズ（「データ長」とも呼ぶ）は任意であり、可変長としてもよいし、固定長としてもよい。

テナントＩＤのフィールドには、マルチテナントサーバ１を使用するテナントを識別するための識別情報が登録される。テナント装置２のユーザがマルチテナントサーバ１を利用する際、テナントの識別情報であるテナントＩＤ及びパスワードを用いて認証処理を行うものとする。そして、各テナントは物理テーブル１３１に登録されたレコードのうち、テナントＩＤのフィールドに自身の識別情報が登録されたレコードに対して選択、更新、削除等の操作を行うことができる。また、各テナントが物理テーブル１３１に新たなレコードを挿入する場合、テナントＩＤのフィールドには自身の識別情報を登録するものとする。

タイプＩＤのフィールドには、各テナントにおいて論理テーブルを識別するための識別情報が登録される。また、データＩＤのフィールドには、各論理テーブルにおいてレコードを一意に特定するための識別情報が登録される。各論理テーブルにおいてレコードを一意に特定できるようにデータＩＤの値を付与（採番）すれば、テナントＩＤ、タイプＩＤ及びデータＩＤの複合キーによって各テナントの論理テーブルにおけるレコードを一意に特定できる。なお、他のテナントを含めた全ての論理テーブルにおいてレコードを一意に特定できるようにデータＩＤの値を付与するようにしてもよい。

ページＩＤのフィールドには、論理テーブルにおける属性が物理テーブル１３１に予め定義された属性には収まらない場合において、論理テーブルの１レコードに含まれる属性を複数のレコードに分解して物理テーブル１３１に登録するときの、分解後の複数のレコードに付与される通し番号を表す情報が登録される。すなわち、各テナントが定義する論理テーブルの１レコードは、物理テーブル１３１の１レコードで保持できない場合がある。例えば、物理テーブル１３１のカラム数の方が論理テーブルのカラム数よりも少ない場合は論理テーブルの１レコードを物理テーブル１３１の１レコードでは保持することができない。また、あるデータ型の属性について、物理テーブル１３１に予め用意された属性の数の方が、論理テーブルに定義された属性の数よりも少ない場合も、論理テーブルの１レコードを物理テーブルの１レコードで保持することができない。このような場合、論理テーブルにおける１レコードを、物理テーブル１３１における２以上のレコードに分解して保持する。このため、物理テーブル１３１は、複数のレコードの接続関係（「ページ」とも呼ぶ）を示す属性を含む。そして、データＩＤ及びページＩＤによって、論理テーブルの属性を一意に特定することができ、物理テーブル１３１に登録された複数のレコード
から論理テーブルにおける元のレコードを復元できる。

また、文字列型の項目１、文字列型の項目２、数値型の項目１、数値型の項目２、日付型の項目１、日付型の項目２・・・のフィールドには、各々に対応付けられた論理テーブルの各属性のフィールドに登録された値が登録される。なお、図３はテーブル構造を簡略化した例であり、物理テーブル１３１は、他のデータ型の属性をさらに有していてもよいし、図３に示すデータ型の属性を３列以上有していてもよい。また、物理テーブル１３１に設けられる各データ型のカラム数は、同数でなくてもよい。例えば、物理テーブル１３１には、文字列型のカラムを３０列、数値型のカラムを１０列、日付型のカラムを５列設けるような定義が可能である。なお、論理テーブルの属性と物理テーブル１３１の属性との対応付けは、テナント毎に予めメタデータにおいて定義される。

図４〜図６は、テナントＡ又はテナントＢがマルチテナントサーバ１に保持させる論理テーブルと格納データの一例である。図４は、テナントＡが管理するユーザテーブルに登録されるレコードの一例を示す表である。ユーザテーブルは、「名前」、「性別」、「身長」、「体重」及び「誕生日」の各属性を有する。また、図４〜図６においては、属性名の下に括弧書きでデータ型の一例を示している。すなわち、例えば、「名前」及び「性別」が文字列型、「身長」及び「体重」が固定小数点型、「誕生日」が日付型である。

図５は、テナントＡが管理する部署テーブルに登録されるレコードの一例を示す表である。部署テーブルは、「部署名」及び「部署種別」の各属性を有する。なお、データ型は、例えば、「部署名」及び「部署種別」とも文字列型である。

図６は、テナントＢが管理する商品テーブルに登録されるレコードの一例を示す表である。商品テーブルは、「商品名」、「商品種別」、「単位名」、「価格」及び「発売日」の各属性を有する。なお、データ型は、例えば、「商品名」、「商品種別」、「単位名」が文字列型、「価格」が整数型、「発売日」が日付型である。

図７〜図９は、メタデータとして登録される内容の一例を示す表である。メタデータは、例えばＤＢＭＳ上のテーブル又はファイルシステム上のファイルとして保持される。また、メタデータには、テナント（例えば「テナントＡ」、「テナントＢ」等）、論理テーブル（例えば「ユーザテーブル」、「部署テーブル」、「商品テーブル」等）、及び履歴（バージョン）に対応づけて、論理テーブルのテーブル構造と物理テーブルのテーブル構造との対応関係を表す情報が登録される。履歴は、当該論理テーブルの改訂の段階を特定するための識別情報であり、数字や日時等で表される。

図７の例では、論理テーブルの「名前」、「性別」、「身長」、「体重」及び「誕生日」の各属性が、それぞれ物理テーブルのページＩＤ「１」における「Char1」、「Char2」、「Num1」、「Num2」及び「Date1」に対応付けられている。図８の例では、論理テーブ
ルの「部署名」及び「部署種別」の各属性が、それぞれ物理テーブルのページＩＤ「１」における「Char1」及び「Char2」に対応付けられている。図９の例では、論理テーブルの「商品名」、「商品種別」、「価格」及び「発売日」の各属性が、それぞれ物理テーブルのページＩＤ「１」における「Char1」、「Char2」、「Num1」、「Date1」に対応付けら
れ、論理テーブルの「単位名」の属性が物理テーブルのページＩＤ「２」における「Char1」に対応付けられている。

図９に示すように、論理テーブルの１レコードを複数のレコードに分解して物理テーブル１３１に登録する場合がある。すなわち、商品テーブルには「商品名」、「商品種別」及び「単位名」という３つの文字列型の属性が存在するところ、物理テーブルの文字列型の属性は、「Char1」及び「Char2」の２つであり、商品テーブルに含まれる属性は、物理
テーブルの１レコードに対応付けることができない。そこで、商品テーブルの１レコードを、「商品名」、「商品種別」、「価格」及び「発売日」と、「単位名」とに分け、物理テーブルにおける２つのレコードに対応付けている。このとき、２つのレコードは、ページＩＤの値で識別する。

図１０は、物理テーブルに格納されるレコードの一例を示す図である。図１０は、図３にテーブル構造を示した物理テーブル１３１に対し、図７〜図９に示したメタデータに基づいて、図４〜図６に示した複数のテナントの論理テーブルに登録されるレコードを格納する例を表す。例えば、図１０において、「DataID」のフィールドに「００１」が登録され、「PageID」のフィールドに「１」が登録されたレコードは、図４に示したユーザテーブルの１レコード目に登録された情報を、図７に示したメタデータに基づいて物理テーブル１３１の対応する属性のフィールドに格納したものである。また、図１０において、「DataID」のフィールドに「００５」が登録され、「PageID」のフィールドに「１」及び「２」が登録された２つのレコードは、図６に示した商品テーブルの１レコード目に登録された情報を、図７に示したメタデータに基づいて２つのレコードに分割し、物理テーブル１３１に格納される、対応するページＩＤのレコードの、対応する属性のフィールドに格納したものである。

以上のように、本実施形態では、原則的にテナント毎に論理テーブルやメタデータが定義され、業務データなどのデータレコードは、複数のテナントが共通で使用する物理テーブル１３１に格納される。ただし、各テナントが共通に利用するマスターデータを用意するようにしてもよい。例えば、郵便番号と住所の一部を対応付けて記憶する郵便番号マスタを、各テナントに共通のメタデータで保持する。このような郵便番号マスタの内容は郵便制度の規格によって決まるため、各テナントに同一のものを利用させる方が効率的である。共通のメタデータは、例えばマルチテナントサーバ１の管理者が一元管理し、物理テーブル１３１に所定のテナントＩＤと対応付けて格納するようにしてもよいし、ファイルシステム上のファイルに格納するようにしてもよい。

＜テーブル構造定義処理＞
図１１は、メタデータの設定により論理テーブルを作成する設定処理の一例を示す処理フロー図である。テナント装置２の入出力制御部２４１は、入出力装置２２を介してテナントのユーザによりテーブルの作成を要求する操作を受け付け、通信Ｉ／Ｆ２１を介してマルチテナントサーバ１へテーブル作成要求を送信する（図１１：Ｓ１）。本ステップでは、図４〜図６に示したような論理テーブルを作成するための要求を受け付ける。例えば、要求はＳＱＬにおけるＣＲＥＡＴＥ文によって当該論理テーブルを作成するための命令が記述され、所望の論理テーブルのテーブル構造を含む。

一方、マルチテナントサーバ１の定義操作部１４３は、通信Ｉ／Ｆ１１を介して要求を受信すると（図１１：Ｓ２）、論理テーブルの属性に対応付けて物理テーブルのカラムを割当てる（図１１：Ｓ３）。例えば、定義操作部１４３は、図３〜図６に示したような論理テーブルのテーブル構造を受信すると、当該テーブルに含まれる属性を抽出すると共に、当該属性とデータ型が同じであって未割当ての属性を物理テーブルから抽出し、両者を対応付けて記憶させることで、図７〜図９に示したようなマッピング情報を作成する。そして、作成したマッピング情報を、記憶装置１３のメタデータ１３２に格納する（図１１：Ｓ４）。

また、定義操作部１４３は、マッピング情報を登録した旨の操作結果をテナント装置２に送信し（図１１：Ｓ５）、テナント装置２の入出力制御部２４１は、操作結果を受信する（図１１：Ｓ６）。なお、入出力制御部２４１は、入出力装置２２に操作結果を出力させるようにしてもよい。以上で、テーブル構造定義処理を終了する。

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

テナント装置２の入出力制御部２４１は、入出力装置２２を介してテナントのユーザにより、データ操作を要求する操作を受け付け、通信Ｉ／Ｆ２１を介してマルチテナントサーバ１へデータ操作要求を送信する（図１２：Ｓ１１）。データ操作とは、例えば、論理テーブルへのデータレコードの挿入、更新、削除、選択の少なくともいずれかである。要求は、例えば、論理テーブルに対し、ＳＱＬ等の問合せ言語によるクエリとして受け付ける。

一方、マルチテナントサーバ１のデータ操作部１４２は、テナント装置２からデータ操作に係る要求を受信する（図１２：Ｓ１２）。そして、データ操作部１４２は、メタデータ１３２に格納されているマッピング情報に基づいて、データ操作に係る要求を物理テーブル１３１に対する要求に変換する（図１２：Ｓ１３）。本ステップでは、図７〜図９に示したメタデータに基づき、クエリの内容を修正する。

具体的には、「TenantID」の値が要求元のテナントの識別情報と一致するレコードを操作の対象とするよう、データ操作に係る要求に条件を付加する。また、操作対象のテーブルを物理テーブル１３１に変更するため、変換前の要求における操作対象の論理テーブルの指定を、「TypeID」に登録された値の指定に置き換える。さらに、変換前の要求における属性名を、物理テーブル１３１における属性名と「PageID」の値との組合せに置き換える。

例えば、テナントＢが検索を行うために次のようなクエリ１Ａを送信する例について説明する。
（クエリ１Ａ）
SELECT 商品名, 商品種別, 単位名, 価格, 発売日 FROM 商品テーブル WHERE 商品種別=
’食品’;
この例は、商品テーブルから「商品種別」の値が「食品」のレコードを抽出し、「商品名」、「商品種別」、「単位名」、「価格」及び「発売日」の各フィールドの値を表示させる要求である。そして、クエリ１Ａは、データ操作部によって、次のようなクエリ１Ｂに変換される。なお、物理テーブル１３１の物理名は「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;

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

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

クエリ２Ａは、データ操作部１４２によって、次のようなクエリ２Ｂに変換される。
（クエリ２Ｂ）
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;

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

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

クエリ３Ａは、データ操作部１４２によって、次のようなクエリ３Ｂ及びクエリ３Ｃに変換される。なお、要求を受け付けた時点において、物理テーブル１３１には「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, ‘台’);

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

なお、テナントＡのレコードのように論理テーブルにおけるレコードが物理テーブル１３１においても分解されずに登録されている場合は、「PageID」は「１」のみであるため、結合や分解を行う必要はない。また、レコードの更新については、要求に対し選択と同様の変換を行い、条件に該当するレコードを更新するクエリを生成する。レコードの削除については、例えば、条件に該当するレコードと「DataID」の値が同一のレコードを削除するクエリを生成する。

その後、マルチテナントサーバ１のＤＢＭＳ１４１は、物理テーブル１３１に対しデータ操作を実行する（図１２：Ｓ１４）。本ステップでは、ＤＢＭＳ１４１が物理テーブル１３１に対し変換後のクエリを発行して挿入、選択、更新、削除等のデータ操作を行う。また、データ操作部１４２は、メタデータ１３２に格納されたマッピング情報に基づいてデータ操作の結果を変換する（図１２：Ｓ１５）。ここでは、例えば、物理テーブル１３１のカラム名を論理テーブルのカラム名に置き換える。

そして、マルチテナントサーバ１のデータ操作部１４２は、通信Ｉ／Ｆ１１を介して要求元のテナント装置２に対して結果を送信し（図１２：Ｓ１６）、テナント装置２の入出力制御部２４１は、変換後の結果を受信する（図１２：Ｓ１７）。入出力制御部２４１は、受信した結果を、例えばモニタ等の入出力装置２２に出力させるようにしてもよい。

＜テーブル構造変更処理＞
図１３は、定義変更処理の一例を示す処理フロー図である。テナント装置２の入出力制御部２４１は、入出力装置２２を介してテナントのユーザによりテーブル構造の変更又はテーブルの削除を要求する操作を受け付け、通信Ｉ／Ｆ２１を介してマルチテナントサーバ１へテーブル構造の変更要求を送信する（図１３：Ｓ２１）。本ステップでは、論理テーブルに属性を追加又は削除したり、論理テーブル全体を削除したりするための要求が送信されるものとする。例えば、要求はＳＱＬにおけるＡＬＴＥＲ ＴＡＢＬＥ文によって記述され、所望の論理テーブル構造に関する記述を含む。

一方、マルチテナントサーバ１の定義操作部１４３は、通信Ｉ／Ｆ１１を介して要求を受信すると（図１３：Ｓ２２）、必要に応じて論理テーブルの属性に対応付けて物理テーブルのカラムを割当てる（図１３：Ｓ２３）。例えば、既存のテーブルに新たな属性を追加するような場合、新たな属性に物理テーブル１３１の属性を対応付ける。

図１４は、テーブル構造を変更した後の論理テーブルの一例を示す図である。例えばテナントＡのユーザは、図３に示したユーザテーブルを、図１４に示すテーブル構造に変更するものとする。すなわち、図３に示したユーザテーブルから「性別」の属性を削除し、「国籍」の属性を「誕生日」の属性の次に追加する。なお、「国籍」のフィールドに登録されているデータ「日本」は、例えば、テーブル構造の変更とは別にデータ操作により更新される情報である。この場合、定義操作部１４３は、論理テーブルに新たに追加する属性に対し、物理テーブルにおけるデータ型が同じ属性を対応付ける。なお、本実施形態では、定義操作部１４３は、各論理テーブルのメタデータを参照し、物理テーブルの属性のうち過去の履歴においても未割当ての属性を原則的に対応付けるものとする。また、物理テーブルにおいて、論理テーブルに新たに追加される属性を割当てるための属性が不足する場合は、ページＩＤをインクリメントして物理テーブルの属性を割当てる。また、定義操作部１４３は、メタデータを更新し、新たな論理テーブルに関する履歴情報を記憶させる（図１３：Ｓ２４）。

図１５は、テーブル構造を変更した後のマッピング情報の一例を示す図である。図７に示したマッピング情報と比較すると、図１５の例では、履歴の値がインクリメントされ、論理テーブルにおける「性別」の属性が削除されると共に、論理テーブルにおける「国籍」の属性に対応付けて、物理テーブルのページＩＤが「２」且つ対応属性名が「Char1」
の属性が登録されている。したがって、メタデータにより論理テーブルからは「性別」の属性が論理的に削除される。一方、論理テーブルから削除された「性別」の属性に対応付けられていた、物理テーブルのページＩＤ「１」のレコードの対応属性名「Char2」の属
性に関しては、原則的に再割り当てを行わない。そして、物理テーブル１３１においては、「性別」に対応付けられていたページＩＤ「１」のレコードの対応属性名「Char2」の
フィールドに格納されていたデータは、物理テーブル１３１から削除も上書きもされずに残る。

図１６は、テーブル構造を変更した後の物理テーブルの一例を示す図である。図１６の例は、上述した履歴「２」のメタデータに基づいて、テーブル構造を変更した後の物理テーブル図１６に示すように、ユーザテーブルの属性「国籍」のフィールドに登録されるデータ「日本」は、ページＩＤ「１」のレコードの属性「Char2」に上書きされるのではな
く、ページＩＤ「２」のレコードの属性「Char1」に格納される。

また、定義操作部１４３は、テーブル定義を更新した旨の操作結果をテナント装置２に送信し（図１３：Ｓ２５）、テナント装置２の入出力制御部２４１は、操作結果を受信する（図１３：Ｓ２６）。なお、入出力制御部２４１は、入出力装置２２に操作結果を出力させるようにしてもよい。以上で、テーブル構造定義処理を終了する。

＜テーブル構造復元処理＞
図１７は、定義復元処理の一例を示す処理フロー図である。テナント装置２の入出力制御部２４１は、入出力装置２２を介してテナントのユーザにより、テーブル構造について過去の履歴の状態への復元を要求する操作を受け付け、通信Ｉ／Ｆ２１を介してマルチテナントサーバ１へテーブル構造の変更要求を送信する（図１７：Ｓ３１）。本ステップでは、例えば、所望の論理テーブルのメタデータを参照し、過去の履歴の一覧をユーザに提示すると共に、ユーザが指定する履歴を取得する。例えば、テナントＡのユーザがユーザテーブルのテーブル構造を、図７に示した履歴「１」の状態に復元したものとして説明する。

一方、マルチテナントサーバ１の定義操作部１４３は、通信Ｉ／Ｆ１１を介して要求を受信すると（図１７：Ｓ３２）、指定された履歴に基づいてメタデータを更新する（図１７：Ｓ３３）。例えば、履歴の値をインクリメントし、指定された過去の履歴のテーブル定義と同様のマッピング情報を新たに登録する。

図１８は、テーブル構造を復元した後のマッピング情報の一例を示す図である。図１８の例では、履歴の値がインクリメントされ、その他のマッピング情報は図７に示した履歴「１」のマッピング情報が復元されている。したがって、メタデータにより論理テーブルからは「国籍」の属性が論理的に削除され、履歴「２」のマッピング情報においては削除された「性別」の属性が元の位置に復元されている。テーブル構造の復元処理においても、物理テーブル１３１のフィールドに格納されている情報は変更されない。物理テーブル１３１において論理テーブルの属性「性別」に対応付けられていた、ページＩＤ「１」のレコードの対応属性名「Char2」のフィールドに格納されていたデータは、図１５に示し
た履歴「２」へのテーブル構造変更時にもそのまま残されているため、図１８に示した履歴「３」へのテーブル構造変更後にユーザが論理テーブルを参照した場合は、論理テーブルから「性別」の属性を削除する前に、「性別」のフィールドに登録されていたデータが復元されることになる。すなわち、テーブル構造の復元後に論理テーブルである「ユーザテーブル」の全レコードを選択すると、図４に示したようなレコードが抽出される。

また、定義操作部１４３は、テーブル定義を復元した旨の操作結果をテナント装置２に送信し（図１７：Ｓ３４）、テナント装置２の入出力制御部２４１は、操作結果を受信する（図１７：Ｓ２６）。なお、入出力制御部２４１は、入出力装置２２に操作結果を出力させるようにしてもよい。以上で、テーブル構造定義処理を終了する。

＜効果＞
一般的に、複数のテナントが単一の物理テーブルを共有する場合、物理テーブルのロー
ルバックのような処理は多くのテナントへ影響が及ぶため実施しづらい。本実施形態によれば、論理テーブルにおける属性の削除をマッピング情報の変更により論理的に行い、物理テーブル１３１においては属性及びそのフィールドに格納されたデータを物理的には削除しない。よって、論理テーブルにおける属性の復元時には、マッピング情報の変更により、属性の削除前にフィールドに格納されていたデータを読み出すことができるようになる。このように、本実施形態に係るテーブル構造変更処理及びテーブル構造復元処理によれば、マルチテナントデータベースにおいて複数のテナントが単一の物理テーブルを共有する場合において、属性の削除の取消し操作を容易にすることができる。

＜変形例＞
上述した実施形態の構成は例示であり、本発明の要旨を逸脱しない範囲において変更することができる。

上述の実施形態は、属性のデータ型を変更する操作について適用することもできる。すなわち、図１２のＳ２１において、ある属性についてデータ型を変更する操作が行われた場合、Ｓ２３においては、物理テーブルにおいて、以前のデータ型の属性は保持しつつ、新たなデータ型の属性を追加し、フィールドに記憶されている値を以前の属性から新たな属性へコピーする。例えば、ユーザが固定小数点型の属性について整数型に変更する操作を行った場合、物理テーブルの固定小数点型の属性のフィールドに格納されていたデータを、整数型の属性のフィールドにコピーする。このとき、小数点以下の桁は切り捨てられる。そして、Ｓ２４においては、マッピング情報において、論路テーブルの属性と以前のデータ型の属性との対応づけを削除し、代わりに新たなデータ型の属性を対応付ける。また、図１３のＳ３１において変更前の属性の復旧の要求が送信された場合は、Ｓ３３において、メタデータにおける論理テーブルの属性との対応付けを物理テーブルにおける以前の属性に戻すことで、復旧処理を行うことができる。従って、固定小数点型の属性について整数型に変更し、小数点以下の桁を切り捨ててしまった場合に、変更前のデータに復元するような処理ができる。以上のように、本発明は、属性の削除や属性のデータ型の変更といった、属性について定義を変更する操作が行われた場合に、マッピング情報において論理テーブルの対象のカラムと物理テーブルの以前の属性との対応付けを削除することで、物理テーブルにおける以前の属性は復旧できるように保持しておくものである。

また、テーブル定義の復元は、属性単位で実施できるようにしてもよい。すなわち、テナントのユーザからは属性単位で復元の指示を受け付ける。例えば、図１５に示した履歴「２」のテーブル構造の変更後に、「国籍」の属性を残しつつ、図７に示した履歴「１」のテーブル構造に存在した「性別」の属性を復元した新たなテーブル構造を定義できるようになる。

図１９は、テーブル構造を復元した後のマッピング情報の他の例を示す図である。図１９の例では、履歴の値がインクリメントされ、「性別」の属性に関しては図７に示した履歴「１」のマッピング情報が復元されている。このとき、「国籍」の属性に関しては図１５に示した履歴「２」のマッピング情報から変更されていない。

図２０は、テーブル構造を復元した後の論理テーブルの一例を示す図である。すなわち、テーブル構造の復元後に論理テーブルである「ユーザテーブル」の全レコードを選択すると、図２０に示したようなレコードが抽出される。図１８に示した履歴「３」へのテーブル構造変更後にユーザが論理テーブルを参照した場合は、論理テーブルから「性別」の属性を削除する前に、「性別」のフィールドに登録されていたデータが復元されることになる。また、「国籍」のフィールドに登録されていたデータは、図１４に示したものがそのまま残っている。

また、図７〜図９、図１５、図１７、図１８に示したメタデータは、論理テーブルのすべての属性について対応する物理テーブルの属性を対応付けたマッピング情報を含んでいる。しかし、メタデータは、履歴間の差分に係る情報のみを保持するようにしてもよい。例えば、図１５に示したメタデータに代えて、図７に示したメタデータから論理テーブルの属性「性別」が削除され、論理テーブルの属性「国籍」が、物理テーブルのページＩＤ「２」のレコードの対応属性名「Char1」に対応付けられて追加されたことを示す情報の
みを蓄積するようにしてもよい。このようにすれば、メタデータのデータ量増加を抑えることができる。

また、物理テーブルの属性のうち、メタデータの過去の履歴において既に割り当てがなされた属性を、再割り当てできるようにしてもよい。テーブル構造の変更を繰り返すと、物理テーブルにおいて利用される属性が断片化し、リソースの利用が非効率的になる場合がある。そこで、任意の履歴のテーブル構造に基づいて、論理テーブルの属性に対応付ける物理テーブル１３１の属性を、物理テーブル１３１の先頭から詰め直す（デフラグする）。例えば、論理テーブルの属性と対応付けられていない物理テーブルの属性のフィールドからデータを削除し、論理テーブルの属性に対して物理テーブルの属性を対応付けし直す。

図２１は、図１５に示したマッピング情報に対してデフラグを行った後のマッピング情報の一例を示す。図２１の例では、論理テーブルから削除された「性別」の属性に対応付けられていた、ページＩＤ「１」のレコードの対応属性名「Char2」のフィールドを、論
理テーブルの属性「国籍」に割り当て直している。このようにすれば、ユーザテーブルの１レコードを物理テーブル１３１の１レコードで格納することができ、リソースの利用を効率的にすることができる。

本発明は上述の処理を実行するコンピュータプログラムを含む。さらに、当該プログラムを記録した、コンピュータ読み取り可能な記録媒体も本発明の範疇に属する。当該プログラムが記録された記録媒体については、コンピュータに、この記録媒体のプログラムを読み込ませて実行させることにより、上述の処理が可能となる。ここで、コンピュータ読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータから取り外し可能なものとしては、フレキシブルディスク、光磁気ディスク、光ディスク、磁気テープ、メモリカード等がある。また、コンピュータに固定された記録媒体としては、ハードディスクドライブやＲＯＭ等がある。

１ ：マルチテナントサーバ
１１ ：通信Ｉ／Ｆ
１２ ：入出力装置
１３ ：記憶装置
１３１ ：物理テーブル
１３２ ：メタデータ
１４ ：演算装置
１４２ ：データ操作部
１４３ ：定義操作部
１５ ：バス
１６ ：物理テーブル
２ ：テナント装置
２１ ：通信Ｉ／Ｆ
２２ ：入出力装置
２３ ：記憶装置
２４ ：演算装置
２４１ ：入出力制御部
２５ ：バス
３ ：ネットワーク

Claims (7)

1. マルチテナントデータベースにおいて複数のテナントが共有する物理テーブルに対してデータ操作を行う情報処理装置であって、
   テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記テナントのユーザに応じたデータ操作を行うデータ操作部と、
   前記論理テーブルのカラムについて定義を変更する操作の入力を受けた場合、前記物理テーブルのカラムは保持したまま、前記マッピング情報において対象のカラムと前記物理テーブルのカラムとの対応付けを削除するテーブル定義操作部と、
   を備える情報処理装置。
2. 前記テーブル定義操作部は、前記マッピング情報に対する変更の履歴を記憶装置に記憶させる
   請求項１に記載の情報処理装置。
3. 前記テーブル定義操作部は、前記論理テーブルに対して新たなカラムを追加する場合、前記マッピング情報に対する変更の履歴において既に前記論理テーブルのカラムと対応付けられた物理テーブルのカラムを避けて、前記論理テーブルに対して追加された新たなカラムと、前記物理テーブルのカラムとの対応づけを行う
   請求項２に記載の情報処理装置。
4. 前記テーブル定義操作部は、定義を変更した論理テーブルのカラムについて変更を取り消す操作の入力を受けた場合、前記マッピング情報において削除したカラムと前記物理テーブルのカラムとの対応付けを登録する
   請求項１から３のいずれか一項に記載の情報処理装置。
5. 前記テーブル定義操作部は、デフラグの指示を受けた場合、前記論理テーブルのカラムと対応付けられていない前記物理テーブルのカラムのフィールドからデータを削除し、前記論理テーブルのカラムに対して前記物理テーブルのカラムを対応付けし直す
   請求項１から４のいずれか一項に記載の情報処理装置。
6. マルチテナントデータベースにおいて複数のテナントが共有する物理テーブルに対してデータ操作を行う情報処理装置が、
   テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記テナントのユーザに応じたデータ操作を行うステップと、
   前記論理テーブルのカラムについて定義を変更する操作の入力を受けた場合、前記物理テーブルのカラムは保持したまま、前記マッピング情報において削除対象のカラムと前記物理テーブルのカラムとの対応付けを削除するステップと、
   を実行する情報処理方法。
7. マルチテナントデータベースにおいて複数のテナントが共有する物理テーブルに対してデータ操作を行う情報処理装置に、
   テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記テナントのユーザに応じたデータ操作を行うステップと、
   前記論理テーブルのカラムについて定義を変更する操作の入力を受けた場合、前記物理テーブルのカラムは保持したまま、前記マッピング情報において削除対象のカラムと前記物理テーブルのカラムとの対応付けを削除するステップと、
   を実行させるためのプログラム。

Images