FileMakerの分離モデル
FileMakerの構造
FileMakerは、基本的にファイル、テーブル、フィールド定義、リレーション、レイアウト、スクリプトで構成されており、プログラムとデータという切り分けした概念はありません。
FileMakerは、簡単にデータベースを構築することを目的のひとつにしているアプリケーションであり、フィールド設計をしたらレイアウトができ、そこにすぐに入力することができる…という簡便さを求めてきたので、これはこれで正しい進化だと思います。（以降、この標準的な１ファイル形式を「単体モデル」と言います）
単体モデルの弱点
しかし、単体モデルの場合、困った問題も出てきます。一人で作って一人で使うものや、月に数日しか使わないようなものならいいのですが、本格的な業務系システムともなると、複数のユーザーが日夜アクセスするのが当たり前になってきます。そうなると、運用中の修正や追加の開発をどうするか、という問題が出てきます。
簡単な修正なら、運用しながら、ササッと直すことも可能ですが、少し規模の大きい改修となると、システムをいじりながら並行してデータ入力も行うなどというのは危険すぎます。どうしても一旦、システムを止めてアクセスなしの状態で行う必要が出てきます。しかし運用中の業務システムを平日・日中、頻繁に長時間止めることはできません。どうしても休日や深夜での対応となります。これではなかなかじっくり落ち着いてテストや検証ができません。タイムリミット（月曜の朝までには絶対完了していなければならない！）もありますし、焦ってやるとデータを失ったり、大失敗するリスクもあります。
分離モデルとは
単体モデルの弱点をいくらかでも解消する方法として、分離モデルという考え方が出てきました。プログラムとデータを分離し、プログラムだけを入れ替えることによって、短い停止時間でシステムを更新しようというものです。大規模開発を前提としたデータベースシステムでは当然のアプローチですが、FileMakerでは最近のバージョンまで、これがうまくできませんでした。
実際には、最低２つのファイルを用意し、１つをプログラム（以下、mainという）ファイル、１つをデータ（以下、dataという）ファイルとして作っていきます。とはいえ、そのための特別なファイル形式があるわけではありませんので、あくまでも「自分の中での」切り分けです。
mainファイルにはデータの容れ物である実テーブルは作りません。mainファイルにデータの入る実テーブルを作ってしまうとメンテナンスがとてもやっかいなことになります。mainファイルには、dataファイルのテーブルのショートカットのようなもの（テーブルオカレンスという）を置きます。それを”あたかも”実テーブルのようにして扱い、それを使ってリレーションを組んだり、レイアウトを設計したり、自動実行のためのスクリプトを作成したりします。下図は、実際に運用中のmainファイルのリレーション図です。拡大して見せるわけにはいきませんが、ごっちゃごちゃです。^_^；)
一方、dataファイルのほうには、実際にデータの入る実テーブルがメインになります。メンテナンス用のレイアウトやどうしても必要なスクリプト以外は極力書かないようにします。リレーションも最低限必要なものだけにして、あくまでもデータの容れ物としてシンプルな状態にしておきます。こうすることによって、mainファイルだけを上書きすれば、最新のシステムにアップグレードでき、なおかつデータは最新状態ですぐに再開できるというわけです。
こうやって書くとけっこう簡単に見えますが、なかなか一筋縄ではいきません。
例えば、あるフィールドの初期値がルックアップや計算式で別テーブルのフィールドを参照（利用）しているような場合、フィールドへの値セットに関連する処理は、そのファイルにリレーションがないとルックアップや計算ができませんので、dataファイルにリレーションが必要になります。
また、アクセス権を複雑に定義しているような場合、データ操作に直接関係するdataファイルのスクリプトで制御しなければならないケースもあります。システムが意図したとおりに動かない場合、mainファイルでどう工夫してもダメで、dataファイル側でやらないといけなかった、ということも多々ありました。（そもそも分離モデルを解説した参考書もないので、試行錯誤にならざるをえないのですが…）
分離モデルの運用方法
ここでは、すでに本番用のmainファイルとdataファイルが稼働中であるものとします。
1.最初にやるのは、この本番用ファイルを丸ごとコピーし、ローカル（自分のPC）に置くことです。ローカルのmainファイルを開け、Verナンバーを一つ上げておきます。私の場合、本番用がVer1.0.0ならば、「Dev Ver1.0.1」とします。これで開発用ローカルのmainファイルであることを識別します。このへんをいいかげんにアバウトにやってしまうと、勘違いして本番用を直接いじってしまったりします。もっとも注意すべき点です。
2.ローカルに置いた開発用mainファイルの修正や追加機能の実装などを行います。本番用とは切り離されていますので、データをいじっても問題ありません。どうせあとで捨てるファイルですので、必要ならばテストデータを作っても大丈夫です。もしdataファイルのフィールドの追加や変更が必要になるなら、その旨を記録したメモを必ず残すべきです。記憶に頼っては危険です。メンテナンス時に迷わないように、確実に正確にフィールド定義できるようなフォーマットを作っておくほうがいいと思います。（分離モデル否定派？の人も多いようですが、もしかしら、このへんの面倒くささを指摘しての発言かもしれません。確かに面倒ですが…）
3.改修作業が終わったら、ユーザーにシステム停止日時を事前に連絡して、アクセスしないようにしてもらいます。ここだけは深夜や休日になりますが、それほど時間も掛かりませんし、作業負荷も低いので、私の場合は、自宅からVPNで接続して、mainファイルの入れ替えを行っています。
ただdataファイルの変更や新規フィールドへの値投入などがあると、それは本番用のdataファイルを直接いじりますのでちょっと時間が掛かってしまいますので時には出社して作業する場合もありますが、単体システムではまず現実的でない大規模な改修も余裕をもってできますので、それは妥協するしかありません。
4.改修作業が終わりテストも済んだら、本番用の最新ファイルを再び、ローカルにコピーします。これが次回の開発用になります。
これを繰り返して行います。
このような方法が採れるのは、FileMakerはファイル同士の関連付けの際、「パスを指定しなければ同階層にあるものを探す」という設定が可能なので、mainファイルとdataファイルが同一フォルダにあり、それがさっきまでのファイルとは別のものであっても同名のファイルであれば、そのままアクセスするからです。ローカルならばローカルのdataファイル、サーバーならばサーバー上にあるdataファイルをアクセスしますので、それが混乱することはありません。
分離モデルの弱点
FileMakerは、元々分離モデルを前提に設計されたものではなく、「別ファイルのテーブルもあたかも同列に扱える」という程度のものです。
また、フィールド定義を変更したり、新たにフィールドを追加するときは、どうしてもdataファイルを触ることになりますので、初回にリリースしたら、dataファイルには一切触らないというわけにもいきません。さらに、あまり使いたくないのですが、計算フィールドを使っている場合、計算式を変更する場合もdataファイルを直接触ることになります。
もっともやっかいなのが、フィールドの追加です。運用中に追加するわけですので、当然、そのフィールドにデータは入っていません。空白のままでも問題ないフィールドならいいのですが、運用途中で必要になるフィールドの場合、何かしらフラッグ的な用途が欲しくなって追加する場合が結構あります。ということは、空白では具合が悪いので、過去のレコードも何らかのルールに則って、値を埋め込む必要があります。このへんになってくるとかなり神経を使う処理になってきます。タイムスタンプを利用していると、値更新で修正タイムスタンプも更新されてしまいますでの、このへんの工夫も必要になるところです。
さらに新しい計算フィールドが大量に必要になった場合（そういうケースもたまにある）、それを手入力するがけっこうな手間です。メモ帳に計算式だけを用意しておき、コピペで貼っていくか、ひとつ作ったらフィールドの複製で流用するとか、いろいろ考えないとなかなか大変です。ただこれは単体モデルでも同じですが。別ファイルからテーブルのインポートやフィールドのコピペもできるようなのですが、手順を間違うとやっかいなのでつい手作業でやってしまいます。
もうひとつ、とてもやっかいな問題があります。FileMaker社が認識しているかどうかわかりませんが、dataファイルの新規フィールドを使ったレイアウトをmainで作った場合、ローカルの環境では上手く動作しており、本番用のdataファイルのフィールド追加を先にやっておいたとしても、本番用のmainが入れ替わったあとでテストしてみるとレイアウト上のフィールド指定が正しく割り当たっていないことがけっこうな頻度で発生します。新規フィールドのつもりで見てみると、既存の関係ないフィールドが割り当たっていたりします（注；これはFileMaker11までの話です。FileMaker12ではそこまで検証していません）。追加フィールドを単純にテーブルの最下段に追加するときはよくて、途中に挟んだときにズレるような気もしますが、どこに置こうともフィールド名での関連付けを確実にしてほしいところです。ただ現状では回避策がわからないので、mainを入れ替えたときは、新規または変更したレイアウトのフィールドズレの確認と修正は必須になっています。
とはいっても、やはり分離モデル
いろいろ問題がありますので、それなら単体モデルでいいのでは？と思われるかもしれませんが、分離モデルでなければまともな業務システムはできなかっただろうなと思います。FileMakerは「運用しながら直す」という面がとても強力で魅力的です。ユーザーの意見や要望を聞きながら改修していくことで、ようやく使えるものになっていったのではないかと思っています。
作ったはいいがメンテが大変、しかも改修は業者に依頼…というシステムではどうしてもフットワークが悪くなり、使いにくいまま使い続けることが多くなり生産性も上がりません。「不具合や要望は、都度まとめておいて、一括して依頼」という一見合理的なやり方もかつてはありましたが、それでうまくいった試しがありません。実際はもっと細々した話だったり、今週中にほしい！という要望だったりします。そういう諸々の条件や環境を考えるとFileMakerの分離モデルもなかなか捨てたものではないという気もします。
ただ、FileMaker識者？の中では、大がかりな業務システムをFileMakerで作ること自体が無謀だ、単体モデルでできないようなシステムにFileMakerを使うべきではない、という意見もあるようですが、どうなんでしょう。それについてはここでは特に反論はしません。