LoginSignup
0
0

More than 3 years have passed since last update.

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

Last updated at Posted at 2019-12-12

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

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

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 下準備

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

サンプル: リレーション

ap01.png

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

ap02.png

ジャン

2 実行してみる

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

ap05.png

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

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

ap04.png

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

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

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

gif001-compressor.gif

次に従業員です。

gif002-compressor.gif

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

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

gif003-compressor.gif

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

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

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

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

ap06.png

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

ap12.png

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

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

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

ap14.png

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

ap15.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つの関連情報があると定義できたわけですが、2回言うのはめんどくさいので
「多対多」(Many To Many)としてしまうことが多いです。

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

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

ap06.png

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

ap07.png

こっちにもいます

ap08.png

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

ap07.png

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

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

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

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

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

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

ap08.png

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

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

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

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

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

ap09.png

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

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

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

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

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

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

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

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

ap10.png

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

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

ap11.png

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

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

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

ダメなパターン

gif004-compressor.gif

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

いけるパターン

gif005-compressor.gif

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

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0