「Refってなに？」後編です。

前編ではRefの基礎的な部分について解説しました。
後編では、AppSheetの具体的なRefの機能に焦点をあてて解説していきます。

① Is a part of

早速、超重要機能です。この設定を間違えるとかなり使いづらいシステムになりますので、しっかりと理解しましょう。

設定方法は、「Type Details」の「Ia a part of」にチェックを入れることで機能がONになります。

「Is a part of」を一言でいうと、

「親テーブルのレコードを消したときに、子テーブルの関連するレコードも消すか？」

ということです。

つまり、どういうことか。
具体例でみていきましょう。

Refで結びつけたテーブルは下記のようになっています。

Is a part ofがONになっている場合、親テーブルのレコードを消すと、子テーブルのレコードも一緒に消えます。

逆に、Is a part ofがOffになっている場合は、親テーブルのレコードを消しても、子テーブルのレコードは消えません。
子テーブルの参照先がNoneになるだけです。

これだけ聞くと、なんとなくONにしておいた方が良い気もしますが、これはケースバイケースで、慎重に判断しなければなりません。

「Is a part of」ON・OFFの使い分け

ONの具体例

• 親：請求書ヘッダ／子：請求書明細
• 親：見積書ヘッダ／子：見積明細
• 親：点検報告書／子：点検写真リスト

上記のような、

「子のレコードを、親のレコードがまとめる」

といった場合は、基本的にONにしておくべきです。

例えば、「親：請求書ヘッダ／子：請求書明細」

請求書システムは、請求書ヘッダ（締日や支払日、顧客情報、合計金額）と請求書明細（各商品の個数、単価、詳細など）の2つに分けます。
各明細（子のレコード）を、請求書ヘッダ（親のレコード）がまとめている状態です。
もし、請求書ヘッダを消して、請求書明細だけが残っていたとしても、何の意味もありません。
それどころか、余計なデータが入っており、データベースとして不適切といえます。

こういった場合のシステムでは、Is a part ofをONにしておかないと、思わぬトラブルに繋がります。

OFFの具体例

• 親：部署マスタ／子：社員名簿
• 親：顧客マスタ／子：注文履歴
• 親：商品カテゴリ／子：商品リスト

上記のように、

「子のレコードにとって、親のレコードは一部の要素」

といった場合は、OFFにしておきましょう。

例えば、「親：部署マスタ／子：社員名簿」

親の部署マスタ（営業部、経理部、総務部など）は、子である社員名簿にとっては、一部の要素にすぎません。
組織再編などで、営業部が無くなって、テーブルから削除した場合、Is a part ofがONになっていると、そこに所属していた社員も消えてしまいます。

部署が無くなっても社員は残るため、ここはOFFにしておく必要があります。

② Input mode

Input modeは、Viewでの表示方法を選択できます。

左から、Auto、Buttons、Dropdownと3種類あります。

それぞの表示形式は以下の通りです。

• Autoを選択した場合

入力内容に合わせて「Buttons」と「Dropdown」のどちらかを自動で適用します。

• Buttonsを選択した場合

• Dropdownを選択した場合

基本的にはDropdownをおすすめしますが、特にこだわりが無ければ、Autoで良いでしょう。

③ Related 〇〇s

これは、Refを使った際に、参照先（親）テーブルに自動で生成されるバーチャルカラムです。

Refになった場合、親テーブルの一つのレコードの中に、子テーブルのレコードが複数結びついている状態になります。

例えば、従業員テーブルでは、佐藤A子さんの複数の出勤情報が格納されています。

そのため、カラムタイプはList形式になっており、関数を使う際に注意は必要です。

Enumでも使えるRef

これまでは、カラムタイプをRefにした場合の解説でしたが、カラムタイプをEnum・EnumListにした場合でも、Refを使うことができます。
カラムタイプをEnum、もしくはEnumListを選択し、BasetypeをRefとすることで、Refの参照先を選択肢として表示します。

ただし、カラムタイプをRefにする場合と、Enumで使うRefは、根本的に異なるものなので、その違いをしっかりと理解しておきましょう。

Enumはあくまで選択肢としてのリスト

最大の違いは、親テーブルと関連付かないことです。

つまり、親テーブル「Related 〇〇s」が表示されません。

なぜなら、Enumに設定するRefはあくまでも「選択肢を他テーブルから参照する」ということが目的だからです。

（テーブルの関連性がないため、「Related 〇〇s」消えている）

また、親テーブルにRelated 〇〇sが表示されないため、親テーブルから子テーブルの一覧を参照することもできません。

通常のRefとEnumのRefの使い分け

では、通常のRefとEnum、EnumListでのRefはどのような基準で使い分ければ良いのでしょうか？

一番簡単なのは、

「親テーブルにRelated 〇〇sが必要かどうか」

を基準すると良いです。

例えば、「注文と商品」「従業員と部署」のようの、明確な階層構造があったり、親テーブルから関連する子テーブルを参照したいような場合は、通常のRefを使うのが良いでしょう。

逆に、ステータス管理（未着手、進行中、完了など）を別のテーブルで管理しており、それを参照したいだけの場合や、EnumListを使って複数選択させたいとき（通常のRefでは複数選択できません）には、EnumやEnumListでのRefを使うと良いです。

最後に

ここまでで、Refの基本的な機能を紹介していきました。

Refの機能はAppSheetに限らず、色々なノーコードシステムでも使うので、実際に手を動かして習得してもらえればと思います。

また、Refは他にも、まだまだ奥が深いので、わからないことがあれば是非質問してください。