2012-03-30

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追記)

2012-03-21

Hyper-V のゲスト OS の BIOS 不良で泣かされる

Hyper-V てはゲスト OS を複数運用できるため、今となっては弊社の業務に欠かせない存在ですが、当方のブログでもたびたび記事を書いているとおり、過去にも色々とトラブルに泣かされていることも確かです。

 さて、今回も月曜日の朝からゲスト OS が起動して来ないというトラブルに見舞われました。
 Hyper-V マネージャ画面を見ると、「仮想マシンの構成記憶域に接続できません」というエラーメッセージが表示されています。しかも状況は「重大」のようです。



 試しに起動してみると、以下のようなエラーメッセージが返されました。



 
 ゲスト OS の設定を確認してみると、BIOS の読み込みに失敗したとあります。
 BIOS 設定に何らかの障害が発生し、起動不能になった模様です。



 ネットを調べ回ったところ、仮想マシンを削除(仮想ディスクはそのまま残すこと)し、再度追加することで解決するとあったので試したところ、復活しました。

 ただし、システムの状態によっては Windows ライセンス認証がもう一度必要になったり、IP アドレス設定が丸々飛んだりしたりするので、その辺の微調整は必要になるかもしれません。

 ただ、今回のように突然ゲスト OS が起動しなくなる可能性がありますので、同じように BIOS による起動トラブルが発生した場合は、今回の方法をダメ元で試してみるのも一つの方法かもしれません(ただし、自己責任ということでお願いします)

【備忘録】 Team Foundation Server で公開されているソースを取得する方法

Team Foundation Server で共有されているソースにアクセスし、クライアントコンピュータで使用するまでの手順をまとめてみました。

 本記事は、Team Foundation Server がインストール済みであり、かつソースが公開設定されていることが前提になっていますので、Team Foundation Server 側の設定については省略してあります。

 なお、ユーザインタフェースは英語表記になっていますが、一応注釈を付けておりますので、日本語のメニューと読み替えてください。
1. Visual Studio 2010 を起動し、トップ画面の一番上に表示される Connect to Team Foundation Server (Team Foundation Server に接続) をクリックするか、メニューバーより、「Team」→「Connect to Team Foundation Server」を選択します。



2. Connect to Team Project (チームプロジェクトに接続)というダイアログが表示されます。
 初回起動時は接続可能な Team Foundation Server が未登録の状態ですので、サーバを登録する必要があります。
 “Servers...”をクリックします。


3. Add/Remove Team Foundation Server (Team Foundation Server の追加と削除)というダイアログが表示されますので、“Add...”(追加)をクリックします。



4. Team Foundation Server がインストールされているサーバの URL、または Team Foundation Server の名前を入力し、“OK” をクリックします。



5. 上記で登録した Team Foundation Server への接続が行われ、Connect to Team Project (チームプロジェクトに接続) というダイアログに、利用可能なチームプロジェクトの一覧が表示されます。

 特定のプロジェクトを選択することも、すべてのプロジェクトを選択することも可能です。
 以下は、すべてを選択した状態を示しています。
 選択が終わったら、“Connect” (接続)ボタンをクリックします。



6. Team Explorer (チームエクスプローラ)が表示されますので、その中から一番下の Source Control (ソースコントロール)をダブルクリックします。



7. Source Control Explorer (ソースコントロールエクスプローラー)が開きます。
 ソースを取得したいプロジェクトを右クリックし、表示されるサブメニューより、Get Latest Version (最新バージョンを取得)を選択します。



8. Map (マップ)というダイアログが表示されますので、ローカルコピーを保存するためのフォルダを指定します。

 以下では、ローカルのドキュメントフォルダに NekoTFS というプロジェクトフォルダを指定しています。
 “Map” をクリックすると、Team Foundation Server から現在の最新バージョンのソースがコピーされるとともにマッピング設定が行われます。



 これで Team Foundation Server にアクセスしながらソース管理を行うための下準備が整いました。

2012-03-09

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追記)