分離モデルにおけるSUM/ExecuteSQL関数の問題と対策

FileMakerの分離モデルにおいてSUMなどの集計関数を使用すると、計算結果が正しく表示されないことがある。

例：
App.fmp12（アプリファイル）とData.fmp12（データファイル、売上/売上明細テーブルを保持）があり、App側でDataにある2のテーブルを以下のようにリレートする。

◇売上テーブルの計算フィールド

SUM売上：SUM(売上明細::金額)、

SQL売上：ExecuteSQL("SELECT SUM(\"金額\") FROM \"売上明細\" WHERE " & 売上::Id & "=\"fk\"";"";"")

◇レイアウト

上図は新規の売上レコードを作成し、売上明細（ポータル）に入力しているところだが、［SUM売上］と［SQL売上]には本来「40」と表示されるべきところ、誤った値が表示される。

一方、データビューアで、上記の2つの計算フィールドで設定した式を入れてみると、ExecuteSQL側は（恐らく）常に正しい値 40 を表示するが、Sum（売上明細::金額）は正しい値を表示しない。

次にレコードをコミット(保存)してみると、下図のようにすべての4つの項目で正しい値 40 が表示される。

ということで、分離モデルでは上記に関する対策を講じなければならないが、考えられる対策は以下の通り。

1. レコードをコミット（保存）するようにユーザを教育する。
2. 数量、単価を変更したときには、コミットを求めるメッセージを画面に表示する。
3. 計算フィールドの使用を避け、数値型の売上フィールドを用意。ユーザが数値、単価を変更したときには売上フィールドの値が適正に更新されるように設計を行う（スクリプトとスクリプトトリガを利用。このとき、EcecuteSQLの使用が有効と思われる）。

上記1は開発者には一番楽であるが、寛大なユーザばかりとは限らない。

上記2は実装は簡単だが、Webアプリならまだしも、デスクトップアプリ/LANアプリでユーザに操作負担を求めるのはどうか、というのはある。

最後の3の実装はかなり面倒となる。

また、数量や単価を変更したときに、毎回自動コミットするように設計するというのはあり得るが、あまりに美しくない。

ちなみに、小社でリリースしている『FMEasy在庫 R1.0』は上記2を、『売上猫くん Standard R1.0』と『売上猫くん on MySQL R5β』では上記3を採用している。

（土屋）

【関連リンク】

FileMaker の分離モデル
FileMaker の分離モデル - 2


土屋企画の講習 ― 分離モデルに基づく請求書システムを作る（対象者：中級、4時間×2日）

FileMaker の分離モデル - 2

　前回、分離モデルのメリットは以下の4点と書いた。

1. 仕様変更時のダウンタイムを最小限にする
2. 同一システムが複数の拠点やユーザにより運用される場合、アップグレードが容易
3. データベースに重大な損傷が発生した場合、データファイルのみ再構築すれば良い
4. 公開マスタ（郵便番号、宅配便仕訳コード等）の更新・入替が容易

　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在庫」フリー版/開発版のダウンロードは→こちら

【FMEasy在庫 の画面】

（2012/12/20追記）

FileMaker の分離モデル

 今日はお問い合わせ上昇傾向のFileMaker分離モデルについて。　小社ではFileMakerの分離モデル講習をおこなっており、先日もその講習会を開かせて頂いた。

　当方がFileMaker 7以降で開発したパッケージ製品、及び受託開発システムは、必ずほんとんど分離モデルを採用している。　なぜか？　その理由、つまり分離モデルのメリットは以下の4点。

1. 仕様変更時のダウンタイムを最小限にする
2. 同一システムが複数の拠点やユーザにより運用される場合、アップグレードが容易
3. データベースに重大な損傷が発生した場合、データファイルのみ再構築すれば良い
4. 公開マスタ（郵便番号、宅配便仕訳コード等）の更新・入替が容易

仕様変更が予想される業務システムは、仕様変更の度にシステムを長時間ダウンさせるわけにはいかず、かといってシステム担当者（ or 業者）に休日・深夜労働させるのは酷な（だけではなくミスの原因！）ので、1.は特に重要。
　アプリファイルだけの仕様変更であれば、1ファイル入替だけですべてのアップグレード作業が完了。　データファイルに変更があった場合でも、ほとんどの場合は、非常に短い時間でアップグレードを完了させることができる。　
　その為には、単純にアプリとデータのファイルに分けるだけではなく、データファイル側ではビジネスロジック（フィールドオプション/計算式、リレーション、スクリプト）を組み込まないことがキモとなる。

　今回の受講者のはdBaseで長く開発してこられ、事前のFMの勉強もバッチリだったため、ER図と資料を見ながら サンプルアプリ（請求書発行システム）を 一人でほぼ作れるレベルだったので、8時間の講習のうち多くの時間を分離モデルの説明とQ&Aにあてることができた。　これをステップに過去のシステムに劣らない立派なシステムを構築して頂きたい。

（土屋）


【関連リンク】
土屋企画の講習 ― 分離モデルに基づく請求書システムを作る（対象者：中級、4時間×2日）
FileMaker の分離モデル - 2


【分離モデルに基づく在庫管理テンプレート】
分離モデルに基づき開発された在庫管理システムテンプレート「FMEasy在庫」の紹介記事は→こちら。
「FMEasy在庫」フリー版/開発版のダウンロードは→こちら

【FMEasy在庫 の画面】

（2012/12/20追記）