- 仕様変更時のダウンタイムを最小限にする
- 同一システムが複数の拠点やユーザにより運用される場合、アップグレードが容易
- データベースに重大な損傷が発生した場合、データファイルのみ再構築すれば良い
- 公開マスタ（郵便番号、宅配便仕訳コード等）の更新・入替が容易
2.は、多数のユーザが運用するアプリケーション、パッケージやネットからダウンロードするようなアプリケーションで大いに役立つ。
今日は上記1.について。
FileMaker Ver6以前は1ファイルに1テーブルしか付属させることができず、更にそのファイル毎にリレーション、スクリプト、値一覧、アクセス権限といったオブジェクトも作成・管理をしていた。
小社のある得意先は、FileMaker Ver5.5のデータベースを現在も運用しており、そのファイル数は約60、そのうち数千～200万弱のレコードを保持するファイルが数十ある。 FileMaker Ver3で開発を初め、納品後に仕様変更と追加を十数年にわたり重ねてきた。 FileMakerのバージョンが上がりアップグレードを行いたいのは山々であったが、規模が大きくなり過ぎアップグレードには多くの費用がかかるため、今日まで旧システムを延命してきている。
さて、このようなシステムで仕様変更が発生し、その変更が多くのファイルに及んだ場合、どうやって納品するか？ システム屋は大変である。 まず最初に考えられるのは、開発を行ったデータベース（開発版）のクローン（ファイルのデータ無コピー）を作成し、そのクローンに運用中のデータベース（運用版）の全データを取り込むことが考えられる。この方法は単純だが、レコード数が数十万を超えるファイルが多くそのファイルに仕様変更が含まれる場合、非常にデータ移行作業に時間がかかり、システムのダウンタイムも長くなる。 また、作業中のミス、例えばデータ取込ミスや、取込後の主キーの設定漏れ、などの重大なリスクも抱えている。
次に考えられるのが、仕様変更があったファイルを、a.レコード数が少ないファイル、b.仕様変更が多いファイル、3.仕様変更が少なくデータが多いファイルに分け、a.とb.については上述のクローンへのデータ取り込みで、c.については、運用版のファイルに開発版で行ったのと同じ変更を直接入れる、という方法である。 この方法は「データの多いファイルに変更が少ない」場合、システムのダウンタイムを大幅に減らせる可能性があるが、逆に作業のリスクは増すことになる。つまり、FileMaker Ver6以前で規模の大きな仕様変更が発生すると、簡単な納品方法はなかったのである。
もし、上記のような仕様もデータも大規模なシステムが、データとアプリケーションに厳密に分離されているシステムであったらどうだろうか。 仕様変更がデータ側、つまりテーブルに及ばないのであれば、アプリケーションファイルを入れ替えるだけ、ダウンタイムはせいぜい1分前後となる。 仕様変更が複数のテーブルに及んだり、テーブルの新規追加があったとしても、一部フィールドを追加し、新規テーブルをコピーすればよいだけである。この作業はオンラインでバックアップを取った後であればサーバを落とすことなく実行可能である。 データファイルの作業を行った後、アプリケーションファイルを入れ替えれば作業終了である。
ダウンタイムを最小限にしたい、“落せないシステム”において、分離モデルは特に有用である。
（土屋）
【関連リンク】
分離モデルにおけるSUM/ExcecuteSQL関数の問題と対策
土屋企画の講習 ― 分離モデルに基づく請求書システムを作る（対象者：中級、4時間×2日）
FileMaker の分離モデル
【分離モデルに基づく在庫管理テンプレートのご案内】
分離モデルに基づき開発された在庫管理システムテンプレート「FMEasy在庫」の紹介記事は→こちら。
「FMEasy在庫」フリー版/開発版のダウンロードは→こちら
【関連リンク】
分離モデルにおけるSUM/ExcecuteSQL関数の問題と対策
土屋企画の講習 ― 分離モデルに基づく請求書システムを作る（対象者：中級、4時間×2日）
FileMaker の分離モデル
【分離モデルに基づく在庫管理テンプレートのご案内】
分離モデルに基づき開発された在庫管理システムテンプレート「FMEasy在庫」の紹介記事は→こちら。
「FMEasy在庫」フリー版/開発版のダウンロードは→こちら
【FMEasy在庫 の画面】
（2012/12/20追記）
