はじめに

FileMakerにおける分離モデルというのは、ファイルを役割などで分離させて管理するということです。役割というのは、受注管理用ファイル／発注管理用ファイルと　といったことではなく、システムの仕組みとして担う機能を示しています（例：データとレイアウトを分離）。
分離の定義はいろいろありますので、一つの考え方として参考になればと思います。
分離モデルにフォーカスを当てて説明したいので、本筋から外れる部分の説明は省略しています。
記事内で使っている、ちょっと分かり難いかもしれない用語の説明です。
ＦＭ：FileMaker
ＴＯ：テーブルオカレンス
開発者：システムを作る人
ユーザ：システムを使う人
長いので途中で休憩を挟むといいです。
間違い見つけたら教えてくれると嬉しいです。

主な対象者

ある程度の基本が理解できている方。
テーブルとＴＯの違いが何となく分かる。
リレーション組んだことある。
スクリプト引数／戻り値が使える。
次項の「分離モデルで改善したいこと」で共感できる項目がある方。
一歩進んだＦＭ開発手法を学びたい方。
分離モデルに興味はあるけど、どんな観点でどう分けるかわからんぽん。な方。
別に興味は無いけど、仕方ないから暇つぶしに読んでやるか。っていう方。
バージョンは7以降なら恐らく適用できるかと思います（古いの使ったこと無いので信憑性薄い）。
記事の中に出てくるイメージはVer13のものですが、14以降でもほぼ同じはずです（動作が軽いので13使ってます）。

分離モデルで改善したいこと

開発環境で改造したファイルを、本番環境へ適用するのが地獄なんすけど…。
例1）改造手順をぜ～～～んぶメモしておいて、本番環境に全く同じ修正を行う。→ミス多いし規模が大きいと死にたくなる。
例2）毎回開発用のファイルに、本番環境のデータをインポートして入れ替えている。→テーブル多いと死にたくなる。
操作用のレイアウトと、検索などの裏方レイアウトが混在していてややこしいわ～。
改造する際に、どのレイアウトが対象なのか分かり難い。→消していいのか分からんからゴミ溜まる。
操作用⇔検索用のレイアウト切り替えで画面がチラつく。→カッコ悪っ。
同じＴＯを複数のレイアウトで共有していると、現在行や対象レコード件数が変わっていたりする。→元の状態に戻すのめんどくせぇ…。
開発環境にも本番環境と同じマスターを適用したいが、本番環境からマスターデータだけ抜き出すの大変。
編集可能な値一覧が、リリースの度に初期化される…orz
他にもいろいろあるはずですが思いつかないので、誰かコメント欄でFMあるあるを言ってください。

本記事の目的ではないこと

ファイルによって使う人を分けたいんやけど。という分離ではありません。ユーザ管理についてはまた別の機会に。
負荷分散したいんやけど。という分離ではありません。そもそもＦＭは同時に１００人使います　とかには向いてないと考えておりますので…。

おススメの分離構成

レイアウト用のファイル
スクリプト用のファイル
データ用のファイル（トランザクション系）
データ用のファイル（マスター系）
管理者用のファイル

先ずは各ファイルの概要を順番に説明します。

1.レイアウト用のファイル

ユーザが実際に操作する画面や、印刷用のレイアウトを管理します。
検索用などの裏方レイアウトは一切作りません。
このファイルには基本テーブルは作りません。場合によっては一時的に使うテーブルを作成する場合（例えばカレンダーとか）もありますが、恒久的なデータ保存が必要なテーブルは作りません。
レイアウト用のファイルですが、スクリプトももちろん作ります。

2.スクリプト用のファイル

指定されたレコードを検索するなど、バックグラウンドで動く類のスクリプトを定義します。
スクリプトは、「どこから呼び出されても動く」というのを意識して作ります。
このファイルにも実テーブルは作りません。
ＴＯやリレーションは作ります。
これだけ読んでもよーわからん…。と思いますので、後で具体例を使って説明します。

3.データ用のファイル（トランザクション系）

テーブルを定義するファイルです。トランザクション系というのは、ざっくり言うと頻繁に更新されるデータのことです（いいかげん）。例えば発注管理システムを作るとして、発注の度に作成されるデータがトランザクションデータです。次のマスター系の説明と併せて理解してください。
このファイルにはレイアウトは作成しません。
ＴＯもリソーステーブルと同名のもの以外は作りません。
当然リレーションも一切作りません。

4.データ用のファイル（マスター系）

こちらもテーブルを定義するファイルです。マスター系というのは、ざっくり言うと滅多に更新されないデータのことです（超いいかげん）。例えば発注管理システムを作るとして、発注先のコード／名称／住所を定義するテーブルがマスターデータです。
カスタム値一覧も、利用者が変更できる類のものはこのファイルに定義します。
このファイルにはレイアウトは作成しません。
ＴＯもリソーステーブルと同名のもの以外は作りません。
当然リレーションも一切作りません。

5.管理者用のファイル

テーブルに保存されている、生データを参照するためのファイルです。生データと言うのは、チェックボックスや値一覧などに変換されていない元データのことです。
このファイルは必須ではありませんが、保守の観点で作ることを強くおすすめします。
生データを参照するのが目的ですので、表示方法が「表形式」のみのレイアウトを作ります。
基本は開発者が保守目的で使うファイルなので、制約は特にありません。

まとめておきます

	ファイル	テーブル	ＴＯ	リレーション	レイアウト	スクリプト	カスタム値一覧
1.	レイアウト用	一時的なものだけＯＫ※1	〇	〇	ユーザ用	〇	変更ないやつだけ※2
2.	スクリプト用	一時的なものだけＯＫ	〇	〇	裏方用※3	〇	×
3.	トランザクション用	〇	テーブル名と同じやつだけ	×	×	×	×
4.	マスター用	〇	テーブル名と同じやつだけ	×	×	×	〇
5.	管理者用	システムと無関係なものはＯＫ	自由	自由	自由	自由	自由
※1：表示用に使うものなど（カレンダーとか）
※2：男/女や、未実施/実施中/完了など（むしろ変更されると困るやつ）
※3：検索用やレコード作成用など

チュートリアル

動物園のシステムを例に進めていきましょう。オラ、ワックワクすっぞ！

要件

飼育員が管理できる
飼育員の基本情報（氏名、性別など）
同じ飼育員を重複して登録できないようにしたい
飼育の記録が管理できる
動物の種類、名前、実施内容、実施者、実施日時
動物の種類や実施内容は楽に入力したい

上記をふまえ、以下のようなシステムを作ります。

飼育員一覧
新規／編集／削除のボタンを配置
新規／編集ボタンで編集画面へジャンプ
飼育員編集画面
性別はラジオボタンで選択可能
同一氏名の飼育員は登録不可
飼育記録一覧
新規／編集／削除のボタンを配置
新規／編集ボタンで編集画面へジャンプ
飼育記録編集画面
動物の種類、実施内容はリストから選択
リストの選択候補はユーザが編集可能
飼育員は登録されているデータから選択

手順

【1】５つのファイルを作成しましょう。

名前は「システム名」＋役割にします。

ZooLayout.fmp12（レイアウト用）
ZooScript.fmp12（スクリプト用）
ZooTransaction.fmp12（トランザクション系データ用）
ZooMaster.fmp12（マスター系データ用）
ZooAdmin.fmp12（管理用）

ZooLayoutは解説を分かり易くするために「Layout」を付加しましたが、このファイルが基点となるので、実際にはシステム名だけにするのがおススメです。

【2】テーブルを作っていきます。

「飼育員」、「飼育記録」の２つを用意しましょう。
飼育員は更新頻度の少ないデータなので、ZooMaster.fmp12に作成。
飼育記録は頻繁に更新されるデータなので、ZooTransaction.fmp12に作成。

《飼育員》

フィールド名	型	補足
id	数値	シリアル値　裏で使用するユニーク値
氏名	テキスト	姓＋名
性別	テキスト	男 or 女
《飼育記録》

フィールド名	型	補足
id	数値	シリアル値　裏で使用するユニーク値
飼育員id	数値	実施した飼育員のid
動物種	テキスト	対象動物の種類
動物名	テキスト	対象動物の名前
実施内容	テキスト	実施した内容（えさや掃除など）
実施日	日付	実施した日付
実施時刻	時刻	実施した時刻

テーブル生成時にレイアウトも自動で作られますが、削除してください。→データ用のファイルからはデータ更新をさせないため。
ファイルの作成時にデフォルトで生成されている、テーブル／ＴＯ／レイアウトは残しておきます。→ＦＭの仕様的に最低１つはレイアウトが必要なため。
idフィールドはレコードを特定するためのキーです。利用有無に関わらず必ず定義しておくと良いでしょう。

【3】作成したテーブルを管理ファイルで参照可能にします

ZooAdmin.fmp12を開き、テーブル定義で２つのＴＯ（飼育員、飼育記録）を追加します。それぞれZooMaster.fmp12、ZooTransaction.fmp12から読み込みます。
それぞれのテーブルを参照するための、レイアウトを作成します。レイアウト名はテーブル名を同じにします。
表示形式は「表形式」のみにします。全ての列を参照可能にしておいてください。
こんな感じの画面になります。飼育員／飼育記録の２つ分を作成してください。

【4】レイアウトを作っていきます。

ZooLayout.fmp12を開き、テーブル定義で２つのＴＯ（飼育員、飼育記録）を追加します。

【5】飼育員一覧画面を作ります。

新規レイアウト作成→テーブルは「飼育員」、レイアウト名は「飼育員一覧」にします。
表示形式は「リスト形式」のみにします。
新規ボタン／削除ボタン／編集ボタンも作っておきます（スクリプトは未設定で良いです）。
一覧は参照のみ可能としたいので、フィールドは編集不可にしておいてください。
こんな感じになります。

【6】飼育員編集用の画面を作ります。

新規レイアウト作成→テーブルは「飼育員」、レイアウト名は「飼育員編集」にします。
表示形式は「フォーム形式」のみにします。
今回の趣旨から外れるので、登録／キャンセルボタンは実装しません（別記事で書いてます。最後にリンク貼ってます。）。
idは編集不可にしてください。また、タブ順設定も外しておきましょう（新規レコード生成時にフォーカスが入ってしまうため）。
性別はラジオボタンで選択できるようにします。値一覧はZooLayout.fmp12に直接定義して良いです。→性別のようにユーザが自由に設定する必要の無いもの（むしろ変更されては困るもの）はレイアウトファイルへ定義します。
閉じるボタンを配置します。こんな感じになりました。
閉じるボタンのスクリプトも実装してしまいます。レイアウト切り替えで飼育員一覧へ戻るだけです。

【7】飼育員一覧の新規ボタンを実装します。

ZooLayout.fmp12に新規スクリプト「飼育員新規作成」を追加します。

本来レイアウト切り替え等を行った後は、エラーチェックを入れるべきですが、これも本筋からは外れるので別の機会に。
飼育員一覧の新規ボタンに割り当てます。
ブラウズモードにして動作確認してみてください。

【8】飼育員一覧の削除ボタンを実装します。

これは単純に、レコード削除の標準スクリプトを呼び出すだけで良いでしょう。

【9】飼育員一覧の編集ボタンを実装します。

こちらも簡単で、レイアウト切り替えで「飼育員編集」へ移動するだけです。

【10】飼育員の氏名重複チェックを実装します。

ZooScript.fmp12を開き、テーブル定義で「飼育員」のＴＯを追加します。
続いて飼育員用のレイアウトを追加します。レイアウト名はテーブル名と同じにします。レイアウトが存在するだけで良いので、内容の設定は特に何もしません。
新規スクリプト「飼育員重複チェック」を追加します。

氏名は引数で受け取ります。重複があればスクリプトの戻り値としてFalseを返します。
最後は現在のスクリプト終了でTrueを返すのを忘れずに。
飼育員編集画面の「氏名」フィールドに、スクリプトトリガーとして設定します。

オプションのスクリプト引数には氏名フィールドの内容をセットします。
動作を確認してみてください。飼育員編集画面で登録済みの飼育員と同じ名前を入力すると、エラーになると思います。

【11】飼育記録一覧を作成します。

【5】と同じ手順なので、演習としてやってみてください。レイアウト名は「飼育記録一覧」です。
完成イメージは以下のようになります。

【12】飼育記録編集用の画面を作ります。

こちらも【6】と同じ手順なので、演習としてやってみてください。レイアウト名は「飼育記録編集」です。
動物の種類と実施内容は、カスタム値一覧を使います。カスタム値一覧はZooMaster.fmp12に定義します。

ZooMaster.fmp12側の設定　※こっちに実際のカスタム値を定義

ZooLayout.fmp12側の設定　※こっちはZooMaster.fmp12のカスタム値一覧を参照

フィールドへの設定はこんな感じですね。実施内容も同じです。

本筋から少し外れますが、せっかくなので飼育員はリレーションを使った値一覧を使います。
リレーションシップグラフで「飼育員」のＴＯを作成し（元々ある「飼育員」とは別に作ります　なぜかは別の機会に）、名前を「飼育記録.飼育員」に変更します。飼育記録に繋がっている飼育員　という意味です。

作成したＴＯを「飼育記録」とデカルト積（「Ｘ］のやつ）で繋ぎます。フィールドはidにしてください。
作ったＴＯで値一覧を作成して、飼育員idに設定します。

「２番目のフィールドの値も表示」にチェックします。
idが表示されると格好悪いので「２番目のフィールドの値のみを表示」もチェックしておきます。
完成イメージはこんな感じです。

【13】飼育記録一覧の新規ボタンを実装します。

【7】を参考に作ってみてください。スクリプト名は「飼育記録新規作成」です。きっとできるはず！
スクリプトができたら飼育記録一覧の新規ボタンに割り当ててください。

【14】飼育員一覧の削除ボタン・編集ボタンを実装します。

【8】、【9】と同じです。楽勝ですね。

【15】仕上げを行います。

ファイルメニューからファイルオプションを開き、ZooLayout.fmp12を起動した時に「飼育記録一覧」が表示されるようにします。
飼育記録一覧⇔飼育員一覧の切り替えができるようにしておきます。

飼育記録一覧側　

飼育員一覧側　　

処理は互いにレイアウト切り替えするだけです。

【16】完成！！

お疲れ様でした。とりあえずいろいろ触って遊んでみてください。アレンジ加えてみるのも良いでしょう。完成するとた～のしいな～～

解説

さて、なんとなくシステムっぽいものができてめでたしめでたしではなく、このシステムを例にして分離モデルのポイントを理解します。

リリース楽になってるよ

先ずは、なんと言ってもこれです。レイアウトとテーブル（データ）を分離したので、リリースが楽になりました。具体的な手順としては

開発中はTransactionとMasterの変更を、正確に記録しておきます。
「1」を元に、本番環境のTransactionとMasterを変更します。
本番環境のZooLayout.fmp12を開発環境のファイルで置き換えます。

だけです。簡単ですね。これも具体例を挙げてみます。

開発用の環境で改造を実装

飼育員に「生年月日」を追加します(ZooMaster.fmp12)。

TransactionやMasterに対する修正は、正確に記録しておきます。これを怠るとリリースが失敗します。
また、定義変更の順番も正確に記録します。ＦＭはテーブルやフィールドなどに裏で隠しＩＤを持っており、
これを参照に使っています。なのでこのＩＤがずれると、Layoutファイル側が予期せぬフィールドを参照
するようなことが発生します。これも話すと長くなるので、詳細はまた別の機会に…。
編集画面に追加します。ついでにちょっとデザインも見直しました。ここはみなさんご自由に。
同じように飼育員一覧画面も手を加えます。
ついでにZooAdmin.fmp12にも生年月日を追加しておきます。

これで改造は終わりました。

本番環境へリリース

開発環境でZooMaster.fmp12に対して行った修正を、本番環境のZooMaster.fmp12にも適用します。
開発環境のZooLayout.fmp12とZooAdmin.fmp12を、本番環境へ上書きます。

※FileMakerServerを使っている場合は、本番環境にホストされているファイルを削除して開発環境のファイルをアップします。

手順が楽なのは、上記の例でお分かりいただけたかと思います。
今回のシステムは規模が小さいので恩恵も小さいのですが、これが新規画面を幾つか
追加したり複雑なリレーションを組むような規模の改造になると、より効果を発揮します。
TransactionやMasterのマージが多いと大変なのでは？と考える人もいると思いますが、
実際にこの運用をやってきた経験上、そこまで大変だと思ったことはありません。
FileMakerProAdvancedがあればコピー機能もつかえますので。
逆に無印だとちょっと大変さが２倍マシってところでしょうか…。
無印Proを使っている方は、この機会に是非Advancedの導入をおススメします。
また、テーブル数が少なければ毎回データだけを改造後のファイルへインポートする方が
早いのでは？と思われるかもしれませんが、それは全くその通りです（言い切る）。
マージミスの心配もありませんしｗ
なので、システムの規模や特性によって導入を考えれば良いと思います。

変更可能な値一覧も保持されるよ

変更可能な値一覧（今回のシステムでは「動物種」と「実施内容」）は、ZooMaster.fmp12に定義しているので、ユーザが選択候補を変更していてもその内容が消えることはありません。
「改造済みファイルに本番ファイルのデータインポート」形式でリリースしている場合、値一覧のマージが漏れるということがありますよね。また、気をつけようと思っても数が多いと比較するのも地獄ですね。

操作画面の状態変わらないよ

これが一番説明が難しいんですが、スクリプトファイルを分けることによる恩恵です。
チュートリアルの手順【10】でScriptファイルが登場しました。
同じ氏名の飼育員が登録されていないかをチェックする処理を作りましたが、
この処理をLayoutファイルだけで対応した場合を考えて見ましょう。
方法としては以下の３つが考えられます。

①自己リレーションで氏名をキーにしてチェックする
②「飼育員編集」の画面のままで検索する
③Layoutファイル内に、検索用のレイアウトを作ってそっちで検索する

それぞれの以下のようなデメリットがあります。

①同じチェックをしたい箇所が他にもあった場合、ＴＯが違うと新たにリレーションを作らないといけない（使い回しが効かない）。
②Ｈｉｔした場合、現在レコードの位置が変わってしまうので、再度検索して元のレコードに戻らないといけない。
③検索用レイアウトに設定されているＴＯが、編集用ＴＯと同じだと結局「②」と同じ問題が起こる。しかもレイアウト移動するので画面もチラつく。

これらを解決する手段が、Scriptファイルの分離なのです。

マスターデータだけ抽出するの楽だよ

これはMasterとTransactionが分かれているので、Masterファイルだけを取得すればおしまいですね。

保守の時データ確認し易いよ

これはオマケ程度で。例えば操作用レイアウトのデータを、無理やり一覧形式で見ようとするとこうなりますよね。

性別がフォームと同じスタイルで表示されてます。この例はまだマシですが、
フォントが大きかったり選択肢が多かったりすると非常に見難い状態となりますよね。
Adminファイルは、これをスッキリ生データの状態で見るために使います。
そもそも操作用レイアウトを、自由に一覧形式で見せるのはセキュリティ的な側面から
考えてもあまり良くないです。
ちなみにAdminファイルは直接ファイルを開いても良いですし、Layoutファイルに
入り口を作っても良いと思います。

まとめ

なるべく優しい言葉で説明したつもりですが、それでも難しい箇所があったかもしれません。

分離モデルによる恩恵は幾つもあるのですが、本記事でその中の１つでも理解が進めばとても嬉しいです。

今回は５つのファイルに分離する例でしたが、ログイン用のファイルや別の基幹システム（oracleなど）とやり取りするためのファイルなど、要件によっていろいろな分離方法があります。

まずは今回作ったサンプルをベースに、いろいろご自身で作ってみてください。

こちらも暇があればご覧ください。
　FileMakerでレスポンス悪いときに確認すること
　 FileMakerで登録／キャンセル制御したい
　 FileMakerでアプリ作っていくよ【作って学ぼう】
　FileMaker 一歩進んだシステム開発 -汎化-

FileMakerで分離モデルしてみたい