エンティティ所有／被所有関係とトランザクション処理

3. 所有・被所有関係とトランザクション処理サンプル

3.1. 画面操作

以下からは、所有・被所有関係とトランザクション処理のサンプルを解説します。

[コンピュータ商品購入]

図4は、前回の商品参照画面とほとんど同じ画面構成ですが、「購入」ボタンが追加されています。この画面から、商品の参照と購入処理を行います。

• http://9.latest.swsAppEnginejpgm7.appspot.com/addOrd.htm

図4の画面から製品番号として、例えば「PC0001」を入力して「参照」ボタンをクリックすると、図5のように、デスクトップPCのスペック項目が表示されます。

図5の商品表示画面からCPU、メモリーなどのスペックを選択して「購入」ボタンをクリックすると、クラウド・サーバー側での登録処理が行われ、図6のように「購入登録成功」がステータス表示されます。

このほか、プリンタやディスプレイなども、同じ画面から登録処理を行うことができます。図7は、プリンタの登録処理例になっています。

以下では、この画面処理でどのようにエンティティの所有・被所有関係が構成されてトランザクション処理が行われているのかを解説します。

オーダー情報を登録するだけの場合は、前回まで紹介してきたキー・バリュー・ストアによるエンティティ構造の柔軟性のおかげで、1つのエンティティにオーダー情報のすべてを登録することができます。1つのオーダー番号で複数のオーダー品目を登録する場合も同様です。RDBでは正規化によって複数のテーブルに分割しなければならないところを、1種類のテーブル（kind）だけで処理できます。

それでは、どのような部分で、複数のテーブルに分けられているのでしょうか。

図8は、このサンプルで使われているデータ・ストアの構造を表してします。図5～図7の画面からクラウド・サーバーに送られた受注データは、サーブレット（Servlet）を経由してビーンズ（beans）で登録（永続化）が行われますが、ビーンズでの登録処理においては、図8に示した3種類のテーブルに対する更新・追加処理が行われています。

（1）オーダー・マスター（kind名: ordMas）

オーダー・マスターは、全オーダーの合計金額（ordamt）と、最後に登録されたオーダー番号（lastord）が記録されているマスター・テーブルです。App Engineの管理者画面経由で見た場合、オーダー・マスターのエンティティは、次のようになっています。エンティティは1件だけで、オーダー登録のたびに合計金額が更新されます。

（2）店舗別オーダー・マスター（kind名: shopMas）

店舗別オーダー・マスターには、オーダー・データを店舗別に振り分けた際の、店舗名と店舗ごとの売上合計金額が記録されています。

（3）オーダー・トランザクション（kind名: ordTran）

登録されたオーダー・データは、すべてオーダー・トランザクションに追加登録されていきますが、データは店舗ごとに振り分けて記録されます。図13に示した<missing>はプロパティが存在しないことを意味しており、プロパティが存在するけれども値がないという場合は<null>で表示され、明確に区別することができます。

以上のようなテーブル構成をとり、3種類のテーブルがすべて1対多での所有・被所有の関係にある場合、このような関係にあるエンティティはエンティティ・グループと呼ばれます。

App Engineのデータ・ストアでは、単一のエンティティに対してだけ、ACID特性を持つトランザクション処理を保証しています。しかし、このように複数のエンティティを所有・被所有の関係でエンティティ・グループにまとめた場合には、所属する複数のエンティティに対してトランザクション処理が保証されるようになります。

図5の3種類のエンティティのうち、オーダー・マスターのエンティティはルート・エンティティと呼ばれ、親キーを持ちません。