第２６話 テーブル設計について（設計からリレーションシップグラフへ）
エヌ・ケイ・カスタマイズの沖田でございます。今回は、前回はテーブル設計からER図（Entity Relationship Diagram)を作成するところを学んできました。ER図はClaris FileMakerのカスタムAppでリレーションシップグラフを作成していく上での設計図になります。
今回は、設計図からリレーションシップグラフを作成していきましょう。
以下の記事は、FileMaker Master Book 初級編（バージョン 19 対応）より、
Claris FileMaker 公式トレーニング教材
「2.9.12 インポートとエクスポート（33ページ）・5.5.1 インポート（103ページ）」を元に掲載しています。
この文献から、インポートの方法や変換可能な形式について学びました。文献の執筆者、関係者の方々に深謝いたします。
なお、このブログ記事の趣旨は、弊社所属スタッフの FileMaker 学習の成果を公開することを目的とし、同時に、参考文献の内容の紹介に資するものであることを Claris International Inc. が確認しています。
ER 図の中では1 つのテーブルは必ず1 回だけしか登場しない、と説明しました。しかし、Claris FileMaker Pro Advanced のリレーションシップグラフでは、1 つの実体テーブルから作成されたテーブルオカレンスはいくつあっても構いません。テーブルオカレンスグループも、機能やレイアウトによって複数作成して使い分けます。
そのためには、もう1 つ理解しておくことがあります。
コンテキスト
「コンテキスト」を意識するということです。見慣れない言葉かもしれません。意味合いとしては「立ち位置」です。果物屋さんの売上管理カスタムApp から例をあげると、
・ 商品はイベントテーブルでは明細行に対して関連付けられるデータ
・ マスタテーブルとしては産地や品種のあるモノとしてのデータ
となります。ある人（「A」さんとします）は、両親からは子供です。会社からは従業員、配偶者や子からはお父さん、趣味のサークルではメンバーです。
Claris FileMaker Pro Advanced は、さまざまな場所で指定するテーブルオカレンス名を通じて、どのコンテキストから表示や計算や処理をおこなうか、を判断しています。
例えば、計算式で2 つ以上のテーブルのフィールド（関連しているもの）を使用して正しく計算できるのは、参照元のテーブルオカレンス名からリレーションシップグラフで定義したリレーションシップの先にある参照先のテーブルオカレンスがわかる、つまりどのコンテキストからみたものなのかがわかるからなのです。
テーブルオカレンス名とフィールドは次のように表示されます。
タスク管理 :: タスク
→ TO 名タスク管理のタスクフィールド
関係ないコンテキストに移動したら？
あるレイアウトで検索、ソート後、同じ実体テーブルだけど、別のテーブルオカレンスグループのコンテキストのレイアウトに切り替えるとどうなるでしょうか。検索結果の対象レコードも、ソートもされていません。スクリプトもコンテキストが違うとエラーになります。
いまどのレイアウトにいるか
コンテキストを意識するわかりやすい方法はレイアウトです。どのレイアウトで実行される計算式、スクリプトなのかを考えます。
コンテキストから自由なもの
グローバル格納はコンテキストから自由です。この特性を便利に使うことがあります。
果物屋さんの売上管理カスタムAppの例ですと、リレーションシップグラフは以下のようになります。
これは、第２５話でありましたER図のリレーション概念を元に３つのテーブルオカレンスグループになっています。
ER 図とは違うテーブルオカレンスグループが複数あるリレーションシップグラフ
数字とUUID
通常、Claris FileMaker Pro Advanced のデフォルトのフィールドの自動作成では「主キー」フィールドに計算値自動入力で Get（UUID ）関数 が設定されています（計算値自動入力については後述）。新規レコードを作成すると「主キー」フィールドに次のような文字列が自動入力されます。
E47E7AE0-5CF0-FF45-B3AD-C12B3E765CD5
UUID（Universally Unique IDentifier）は、全世界でユニークになる（重複する確率が限りなく0 である）識別子です。Claris FileMaker Pro Advanced 独自の考え方ではなく標準化がなされている世界的なものです。
主キー数字の連番にするか、UUID を使うか、の選択はカスタムApp の役割などによって決定します。ユニークな数字でも充分に主キーとなります。また、リレーションシップ成立の仕組みがすぐに確認できること、などを重視する場合は数字の連番を採用しても問題ありません
UUID が良いけれど、フィールドタイプを数字にしたい場合は Get（UUID 番号）関数を利用してください。
まとめ
作成方法はいろいろありますが、１つの実態テーブルからテーブルオカレンスはいくつでも作れるので、機能ごとにテーブルオカレンスグループ（TOG)を作ることで、後々のメンテナンスやカスタムAppの開発者以外の人が改修などする際にもメンテナンスがしやすくなります。
今回はここまでになります。ありがとうございました。
参考文献：Claris FileMaker 公式トレーニング教材 から、「FileMaker Master Book 初級編」 等を参考にしています
https://content.claris.com/fmb19_reg-ja
