App Makerのリレーションを15分で理解する

どうもこんばんは、みかんです。

**！！！！とつぜんですがたいせつなおしらせ！！！！**

2020年1月27日
App Maker の提供終了に向けた対応のご案内
https://support.google.com/a/answer/9682494?p=am_announcement&visit_id=637157414793613981-426262357&rd=1


??!???!?!?!???!?

残念ながら2021年1月19日には終了してしまうそうです(涙)
移行先はAppSheetかApp EngineかGoogleフォームだそうです・・・

消すのは忍びないので記事は残して置きますが、何かの間違いじゃ無い限り役に立つことはないでしょう・・・


**！！！！おしらせはおわりです！！！！！**

今回は「App Makerのリレーションを15分で理解する」という題で書いてみます。
下記ステップでやっていきます。

* 1 下準備
* 2 実行してみる
* 3 簡単にリレーションを理解する
* 4 リレーションデータソースを知る

# 1 下準備

今回もサンプルからスタートします。

[サンプル: リレーション](https://developers.google.com/appmaker/samples/relations?hl=ja)

|![ap01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/c93f16bb-9999-8f61-99f5-803caeda2b0b.png)|
|:-:|

こんな感じです。まずは恒例の日本語化を。

|![ap02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/0909dabd-7474-a716-3c88-8d3573bf0bde.png)|
|:-:|

ジャン

# 2 実行してみる

動作を見ていきましょう。

|![ap05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/e8a99043-f479-6d95-859c-b731465ecb58.png)|
|:-:|

「メイン」画面です。
部署に所属する従業員の一覧が表示できる画面になります。
1件もデータが入っていないので空っぽですね。

青い「管理画面」という文字を押してみます。

|![ap04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/44223270-0902-a66b-4b8c-f7ff17495202.png)|
|:-:|

画面が切り替わり、データを入力する画面になりました。
部署用と従業員用がありますね。

作り方はちょっと特殊で、まず「+」ボタンを押します。
数秒経つと、各入力ウィジェットが活性化されるので、データを入力します。
フォーカスを外した時点で即データが記録されます。
フォームウィジェットを「Edit」で配置したパターンの作りですね。

早速部署を入れてみます。

|![gif001-compressor.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/f58f300f-1d41-812d-0e65-038d724316dc.gif)|
|:-:|

次に従業員です。

|![gif002-compressor.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/4f3a85ea-3d64-8b02-7626-dad4133d757a.gif)|
|:-:|

部署用のドロップダウンウィジェットに、最初に登録した部署が並んでいることがわかると思います。

入力したら、青い「メイン画面」という文字を押して、一覧に戻ります。

|![gif003-compressor.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/8121477c-4cba-01a6-a7ba-6ba2e620c759.gif)|
|:-:|

部署用ドロップダウンで選択している部署に所属している従業員だけが、一覧に表示されるようになっています。

# 3 簡単にリレーションを理解する

さて、リレーションとは何でしょうか。アプリの動きを見た感じでなんとなくイメージはついていると思いますが、簡単に説明します。

このアプリでは、2つのデータを取り扱っています。「部署」と「従業員」ですね。

|![ap06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/cfb0b208-cde1-cc0a-40be-8fc751a977f7.png)|
|:-:|

データの登録もそれぞれ行いますが、お互い独立して登録してもあまり意味のないデータです。
特に、従業員だけなら分からなくもないですが、部署は単独で存在すること自体に特に意味がありません。

|![ap12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/9cf8c455-6584-241d-2dee-15c71e00fd33.png)|
|:-:|

ですので、「部署」データを有効活用するには、その「部署に所属している従業員」は誰々、というデータも必要になってくることがわかります。
データが３つになりましたね。3つ目が「リレーション」データです。

- 部署
- 従業員
- 部署に所属している従業員 ← リレーションデータ

リレーションデータがあるおかげで、下記画像のような状態が表現できます。

|![ap14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/9145ea8c-7992-c70d-3358-ea92364ec8a9.png)|
|:-:|

ということで、リレーションデータをApp Makerで表現してみようとなります。
リレーションデータは、「とある部署」と「とある従業員」が関連していることがわかるデータになっていれば良いと思います。
イメージは下記です。

|![ap15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/d655474b-ccf8-91ea-271d-0155f5b9746c.png)|
|:-:|

部署Aのデータは2件ありますね。AさんとBさんです。なので、部署Aにはその2名がいるということが表現できています。
部署Bのデータは1件ありますね。Bさんです。Bさんひとりだけの部署ですね。
逆に従業員から考えると、Aさんは部署Aだけですが、Bさんは部署Aにも部署Bにもいるようです。兼務ですかね。

ここで、この関係の性質に名前を付けてみましょう。
1件の「部署データ」は、複数の「従業員データ」と関連を持ちます。部署AにはAさんとBさんがいましたよね。
部署→従業員という方向で見た時、これは**「1対多」(One To Many)**と表現します。

逆もあります。
1件の「従業員データ」は、複数の「部署データ」と関連を持ちます。Bさんは部署Aと部署Bに所属していましたよね。
従業員→部署という方向で見た時、これも**「1対多」(One To Many)**になります。

今、2つのデータに対して2つの関連情報があると定義できたわけですが、２回言うのはめんどくさいので
**「多対多」(Many To Many)**としてしまうことが多いです。

さらに詳細な情報として、関連が0件以上なのか、1件以上なのかということをしっかりと定義したりしますが、今回は省略します。

ということで、サンプルのデータを再度眺めてみると・・・？

|![ap06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/cfb0b208-cde1-cc0a-40be-8fc751a977f7.png)|
|:-:|

**無い**ですよね。３つ目の「部署に所属している従業員」データに相当するモデルが。
じゃあどこにいるのというと、ここにいます。

|![ap07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/f1c0da2a-0f13-dfba-d244-bce7226bebaf.png)|
|:-:|

こっちにもいます

|![ap08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/4b9a8f7e-33dd-dedb-1cb0-a87e62bd386d.png)|
|:-:|

それぞれのモデルに関係するリレーションデータは、こうやって確認できるということですね。
では、部署から見てみましょう。

|![ap07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/f1c0da2a-0f13-dfba-d244-bce7226bebaf.png)|
|:-:|

(-)みたいなアイコンの右の「Emp」は、関連先のモデル名です。
その中に、「Dept」と「Emp」の２つの箱があります。
こいつのことを**リレーションエンド**といいます。

そして見てください。「Dept」のCountが**ONE**で、「Emp」のCountは**MANY**になっています。
これは、先述の

> 部署→従業員という方向で見た時、これは「1対多」(One To Many)と表現します。

をそのまま表現している形です。

このように設定しておくと、App Makerでは部署と従業員がそのように関連づいていると認識してくれます。

逆も見てみましょう。「Emp」から見た場合です。

|![ap08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/4b9a8f7e-33dd-dedb-1cb0-a87e62bd386d.png)|
|:-:|

今度は「MANY」→「ONE」になっていますね。

多数の従業員に対して、部署は1つだけ。

そうです。このサンプルでは、1人の従業員が所属する部署は必ず1つ、という設定になっています。
兼務無しってことですね。

そして、Many To Manyの場合、「「とある部署」と「とある従業員」が関連していることがわかるデータ」は専用のテーブルが必要になるのですが、
One To Manyの場合は、Many側になる方のデータに、One側のIDを示すカラム(フィールド)が一つあれば大丈夫です。

実際、このサンプルでOne To Many(Many To One)のリレーションが設定されていますが、それを表現するためのフィールドが従業員側には生えていたりします。

|![ap09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/2412d792-fd6d-dee6-f98a-2afcb484e49a.png)|
|:-:|

**余談**
ちなみにApp Maker、Many To Manyにしてもやっぱり専用のモデルは増えません。それぞれのモデルにフィールドも増えません。
そこら辺は裏で勝手にやってくれます。
やってくれますが、名前変更とかすると結構地獄なので、Cloud SQL側もチェックできる状態で無い場合はなるべく避けたほうがいいかもしれません。

# 4 リレーションデータソースを知る

簡単に説明できたかあまり自信がありませんが、説明が必要な内容がまだ残っているのでもう少しお付き合いください。

サンプルのデータとしては、次の3種類のデータが設定されていることがわかりました。

- 部署
- 従業員
- 部署に所属している従業員 (従業員は1つの部署のみ所属可能)

そして一覧画面では、部署を選択するとそれに所属している従業員が表示されるようになっていました。
その実現のために、**リレーションデータソース**を活用しています。

「データソースって、モデルのDATASOURCESのアレでしょ？」
となりそうですが違います。あれは別名**クエリデータソース**です。
あの画面にはクエリデータソースしか表示されないので、リレーションデータソースの存在を確認することができません。

ではどこで確認すると良いのでしょうか？
Mainページのテーブルをクリックして見てください。そしてプロパティエディタを開くと・・・？

|![ap10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/1ed7d2eb-b939-f363-4b77-e2c1749c538c.png)|
|:-:|

リレーションデータソースが設定されていることがわかります。これです。
この表記を日本語で表現すると、
「部署: 従業員 （リレーション)」 → 「部署に所属する従業員」
となります。

このテーブルは 「部署に所属する従業員」が表示されるテーブルということになります。
左に置いてある部署選択ウィジェットの設定も見てみましょう。

|![ap11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/46e122dd-98cc-8326-fd7e-63822c559cb3.png)|
|:-:|

valueは、ドロップダウンで選択されているものが入るプロパティですが、そこに
`@datasource.item`が指定されています。
ここで言うdatasourceは「部署」データソースのことなので、
datasource.itemは「現在選択されている部署」を表します。

テーブルに紐付いているリレーションデータソースは「部署: 従業員 （リレーション)」 ということであくまで「部署」のデータソースなので、datasource.itemでの選択結果が同じように適用されます。
そして、リレーションデータソースの場合は、現在選択されている部署自体のデータを取得するのではなく、そのデータに紐付いているデータを取得するデータソースとなっているため、結果として「現在選択されている部署に所属している従業員のデータ」を参照することができる、というわけです。

最後に、どうやって設定するのか？という観点でも解説します。
リレーションデータソースは、大前提として「上位の階層に、リレーションを持つモデルのデータソースが設定されている」ことが設定する条件となっています。
見たほうが早いので、駄目なパターンといけるパターンを示します。

**ダメなパターン**

|![gif004-compressor.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/dcb85c9a-4432-59ca-c9f9-08bfb3c77f95.gif)|
|:-:|

親となるパネルにリレーションの元となるデータソースが無いので、普通に選べるデータソースのみが選択肢に出てきます。

**いけるパターン**

|![gif005-compressor.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26085/ee7bd63a-9a40-9d27-fded-7225d79d519a.gif)|
|:-:|

親に「部署」データソースを設定してあるので、部署に紐づくリレーションデータソースが選択できるようになっています。

これがリレーションサンプルの全貌となります。
リレーションサンプルページにも書いてありますが、これは公式ガイドの方のチュートリアルにも手順が載っています。
そのチュートリアルでは、リレーションデータソースを利用しない方法で部署に所属する従業員を一覧表示する方法も載っています。
その方法はクエリデータソースにおける検索技術に関連してくるため、本記事では割愛します。

以上です。良いApp Makerライフを!