SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

FileMaker Pro 実践チュートリアル(AD)

FileMaker Pro による大規模システム開発

第6回 アクセス制御/ネットワーク負荷の軽減/他システム間の連携を行う

  • X ポスト
  • このエントリーをはてなブックマークに追加

この連載では、システム開発において採用が増えつつある「FileMaker」というデータベースソフトウェアについて、最前線で活躍するエンジニアがリレー形式でその魅力を紹介します。第6回は、FileMakerの機能と認知度の向上に伴い増加してきた、大きい規模でのシステム開発について解説します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

大規模開発への対応

 連載の第3回/第4回/第5回で、FileMaker Proによるプログラミングの基礎を機能ごとに紹介してきました。実際のソリューションでは、これら基本的な部分の組み合わせと積み重ねが、無数のアイデアや発想へとつながっていきます。そういったアイデアの数々は、また機会と場所を改めてお話したいと思いますが、今回はこれまでと少し立ち位置を変え、「大規模開発」について触れることにします。

大規模開発の分類

 「ソリューション」は、シンプルな「機能」を組み合わせた「システム」の集合体です。その集合体が大きくなれば「大規模開発」になっていくわけですが、まずはその形態を大きく3つに分けてみます。

  • 「利用者数が多い」という意味での大規模
  • FileMakerの機能と認知度の向上に伴い、大きい企業規模での導入が増加しています。クライアント規模が、一昔前は多くて30~50人程度だったものが、100~200人超での開発/運用が普通になってきました。
     
  • 「データ量が多い」という意味での大規模
  • FileMaker Pro 7以降、1つのデータベースファイルで管理できるデータ容量が「8TB」になっています。テキストベースでの容量が100MB、200MBになるのは当たり前で、GB単位でのデータを保持するケースも稀ではありません。
     
  • 「連携範囲が広い」という意味での大規模(他システムとの連携も含む)
  • ソリューションが基幹システムに近いところで運用される、あるいは基幹システムそのものである場合などは、必ずと言って良いほど他のシステムとの連携が求められます。

 いわゆる「大規模システム」には、これらの要素をすべて内包していることが多いとは思いますが、これらの視点からFileMakerの開発における留意点についてを話します。

利用者数が多いシステム

FileMakerにおけるデータ操作の簡易さと、それによる危険性

 利用者が増加するということは、多くのデータに多くの人が触れるようになるということです。そこで重要になってくるのが「データの安全性」です。安全性の対象には、データの漏えい以外に、改ざんや消去による紛失なども含まれます。

 FileMakerを一つのツールとしてとらえたとき、その操作性の良さから、データの集約、整理、内容の正規化、書き出しなどの作業が容易です。転じて便利な反面、構築するシステムの制御がおろそかになると、ふとした操作で先述のようなトラブルが発生しまう危険性をはらんでいます。システムの規模や性質にもより、これらの制御をどこまで行うかを見極めることも重要です。

制御の手法

 FileMakerで、さまざまなアクセス規制を行う基本は「アカウントとアクセス権」による管理です。システム起動時に認証するアカウントに対して、テーブル/レイアウト(画面)/フィールド(項目)の表示/編集を制限することが可能です。

 また、FileMaker Pro Advancedを利用すると、画面上部に表示されるメニュー構成(ファイル、編集、表示など)をカスタマイズし、それぞれの画面上で不要なメニューを非表示にできます。不用意な操作や不正な操作を防ぐのに有効です(「カスタムメニュー」の作成には、FileMaker Pro Advancedが必要です)。

図1 特にメニューをセットせずに表示されているため、FileMaker Proの標準メニューが表示されています
図1 特にメニューをセットせずに表示されているため、FileMaker Proの標準メニューが表示されています
図2 カスタムメニューがセットされているため、最小限のメニューしか表示されていません
図2 カスタムメニューがセットされているため、最小限のメニューしか表示されていません

 さらに、「誰が、いつ、どのデータに対して、何をしたか」を管理できればよいですが、FileMakerの標準機能には、いわゆるトランザクション管理がありません(それぞれのレコードに最終更新者や最終更新日時を記録することは可能です)。

 これを実装するには、別途その仕組みを組み込む必要があります。場合によって手法は変わりますが、一例を挙げると次のようなものがあります。

  • データ編集の際、対象となるレコードを編集するのではなく、複製したレコードに対し行い、元レコードには「無効」フラグを立てる。
  •  
  • データ削除に関しても、データを実際に削除するわけではなく、「無効」フラグを立て「削除扱い」のデータとする。

 このようにすることで、「誰が、いつ、どのデータに対して、何をしたか」が明確になり、紛失したデータをある特定時点まで復旧することも可能になります。

直感的なUIデザイン

 もう一点。これは少し視点が異なりますが、利用者の多いシステムで念頭に置くべきことがあります。それは、「感覚的に操作できるユーザーインターフェイスデザイン」です。

 利用者が多いと大変なのが、システムの操作方法の落とし込みや、それに対する問い合わせの対応です。これらを事前に踏まえて、ボタンの配置や、必要最小限の情報の配置を考えていくことが重要です。

 幸い、FileMakerはそういったレイアウトデザインや配置に関して、開発者に高いスキルを求めてきません。ドラッグ&ドロップによる直感的な操作で行えるため、配置作業に手間がかからず、クリエイティブな思考に注力できます。「センス」の多少はあるかもしれませんが、コツとしては分かりやすい画面構成を心掛けるとよいでしょう。

データ量が多いシステム

FileMakerのC/S環境における特性

 この件の予備知識として、C/S(クライアント・サーバ型)環境におけるFileMakerのある便利な特性について触れておきます。

 例えば、「郵便番号簿」のマスターにある特定の同一レコードを、2人のユーザーが画面に表示していたとします。この時、一方がデータの一部を変更すると、当然、変更した側の画面は新しい情報に更新されますが、もう一方の画面ではどうなっているでしょうか。

 一般的なC/Sシステムでは、[更新]ボタンなどの明示的なアクションにより、再度SELECT文を発行して、最新情報を取得することになると思います。ところがFileMakerでのC/Sシステムでは、そのような明示的な操作を行わなくとも、表示されている画面の情報が最新の内容に変更されます。

 簡単に説明すると、データの変更内容を受け取ったFileMaker Serverが、その情報を各クライアントに向けてほぼ即時に配信します。配信対象は、「その情報を画面上に表示している」クライアントです。

 「その情報を画面上に表示している」という部分を念頭に置いて、以下の話を読み進めてください。

ネットワーク上でのデータの流れ

 さて、扱うデータ量が非常に多くなった場合、考慮する点の一つに「データ取得時の反応速度」があります。

 この速度を左右する大きな要因の一つが、ネットワーク上を流れる「データの量」です。呼び出し対象のデータや利用者に比例して増大します。システムの反応速度を保つならば、この「流れるデータ量」が増えないように工夫する必要があります。

 先述のように、FileMakerではクライアントが画面で表示している項目が、データ取得の対象となり、常にそこに向けてデータが配信されます(逆に言えば、その項目を対象にしたリクエストが常に投げ続けられています)。従って、表示しているレイアウトの項目数が多ければ多いほど、流通するデータ量も多くなります。

 画面構成の簡易さから、特に意識せず無造作に項目を並べていくと、情報が見づらくなるだけでなく、トラフィックに余計な負担をかけることになるので、注意した方が良いでしょう。

 ただ、逆に「画面に表示されていない項目はデータが流れてこない」と考えることもできます。さらに言うと、レイアウト上には配置されている項目でも、ウィンドウの表示サイズの外側にある項目は、画面をスクロールして表示されるまでデータが流れません。

 これについては、下記の資料を参照してください。

図3 62件が検索にヒットし、そのうち「51件」を画面上に表示させたFileMakerの画面表示
図3 62件が検索にヒットし、そのうち「51件」を画面上に表示させたFileMakerの画面表示
図4 その際にネットワーク上を流れたデータをキャプチャーしたもの
図4 その際にネットワーク上を流れたデータをキャプチャーしたもの
図5 62件が検索にヒットし、ウィンドウサイズを調整してそのうち「25件」を画面上に表示させたFileMakerの画面表示
図5 62件が検索にヒットし、ウィンドウサイズを調整してそのうち「25件」を画面上に表示させたFileMakerの画面表示
図6 その際にネットワーク上を流れたデータをキャプチャーしたもの
図6 その際にネットワーク上を流れたデータをキャプチャーしたもの

 検索を行った後の一覧表示と、その際にネットワーク上を流れたデータをキャプチャしたものです。

 図3~4は、検索にヒットした件数が62件で、そのうち51件を画面に表示しています。図5~6は、図3~4と同じ検索を行いますが、ウィンドウの高さを狭め、画面に表示されるレコード件数を少なくしています。両方とも検索結果の件数は同じですが、流れているデータ量が異なることが分かります。

 レイアウトに不必要な項目を配置するとトラフィック増加の要因となるため、画面構成をデザインするに当たっては意識したい部分です。

連携範囲が広いシステム

データ連携する手法

 企業規模の大きな所になると、既に基幹システムが稼働しておりマスターデータはそこから引く、あるいは複数のシステムがお互いに必要な情報を補完しあうために、FileMakerで開発したシステムのデータとの連携が必要になってくることが多々あります。

 FileMaker以外のシステムとデータを連携させる方法はいくつかありますが、代表的なものは次のとおりです。

  • A: CSVやXMLデータなどのテキストデータファイルを介し、定期的にインポート/エクスポートする。
  •  
    図7 いくつかのデータ形式でデータのインポート/エクスポートが可能
    図7 いくつかのデータ形式でデータのインポート/エクスポートが可能
     
  • B: 条件が合えば(適用できるドライバがあれば)、ODBCを経由したデータのインポート/エクスポート、あるいはスクリプト「SQLを実行」を使用して、INSERT/UPDATE/DELETEなどを行う。
  •  
    図8 ODBC経由での、外部データ取込みメニュー
    図8 ODBC経由での、外部データ取込みメニュー
    図9 データのインポートの際に発行するSQL文を設定するダイアログ
    図9 データのインポートの際に発行するSQL文を設定するダイアログ
    図10 スクリプト「SQLを実行」で指定する、SQL文を設定するダイアログ
    図10 スクリプト「SQLを実行」で指定する、SQL文を設定するダイアログ
     
     
  • C: さらに条件が合えば(動作環境を満たせば)、外部SQLデータソース(ESS)機能を利用し直接データを参照する。
  • 「外部データソース管理」は、FileMakerのメニューの[ファイル]-[管理]-[外部データソース]から開きます。
     
    図11 外部のデータテーブルを、FileMakerのテーブルとして扱うための「外部データソース管理」設定画面(MySQLの例)
    図11 外部のデータテーブルを、FileMakerのテーブルとして扱うための「外部データソース管理」設定画面(MySQLの例)

 Aは、取り込み側でそのデータを取り込むための処理と、その処理をキックするトリガーが必要となります。その性質上、汎用性はありますが即時性に欠けます。

 Bは、ODBCドライバの有無と、動作確認が条件となります。この場合は、データの送信と取得がFileMaker側のアクションで行えるので、例えば[更新]ボタンのスクリプトに「SQL実行」スクリプトをサブスクリプトで連ねておけば、一連の流れで連携がとれるので、リアルタイムに近い処理が行えます。

 Cは、適用可能範囲が狭くなりますが、他システムのテーブルを直接参照していることになるので、連携の中では一番、即時性が高いでしょう。

データ連携する際の留意点

 まず連携手段にかかわらず注意が必要なのは、「FileMakerにおけるテーブル定義では、桁数という考え方がない(に等しい)」という点です。FileMakerでは、各データタイプごとに保持できる最大データ量の仕様が存在するものの、テーブル定義の際に、各フィールドに桁数を指定することができません。

 従って「テキスト」タイプのフィールドには、データサイズを特に意識しなくても良いくらいの文字数が入力できてしまいます。しかし、他システムとの連携を考えるときには、この「桁数」が大きく影響してきます。

 そのため、それらの桁数を考慮した別の連携用フィールドを必要としたり、書き出したデータを成型し直したりする必要があります。

 また、同様の理由からFileMakerは基本的に「可変長」です。よくホストデータから提供される形式に「固定長」のものがありますが、これらをFileMakerに取り込む時や他システムに提供する時も、この辺りを念頭に置いておく必要があります。

 他システムとの連携を行う場合は、それぞれのシステムのデータの持ち方の特性について、相互理解を深める必要があります。データベースという同じ世界の中でも、それぞれで「常識」というものが存在し、それを外すと担当者同士の会話も通じません。ましてや、システム間の連携がさらに困難なことは言うまでもないでしょう。

 以上のように、FileMakerはシステム開発のプロセスにおいて、「技術やデジタル」な部分よりも「対話やアナログ」な部分に関わる時間を多く取ることができる、大きな特長があります。

まとめ

 冒頭で述べたようにソリューションがシステムの集合体であるとすると、すべてを一貫して同一環境で構築していく懐石やフレンチのフルコースのようなものより、洋食屋のアラカルト的な需要が増えてきていることが最近特に感じられます。

 また得てして、そういう方が「ライス大盛り」にするような融通が効き、好まれたりするものです。また、出張シェフとして、フルコースの一品を供し得ることも忘れてはいけません。

 これらを意識するために今回は、ちょっとだけ俯瞰したところから話を進めてきました。

 まだまだ整理していきたい情報もありますが、また別の機会に場を移して皆さんと一緒に組み上げていきたいと思っています。

 さて、次回よりまた少し新たな皿(展開)へと移っていきます。

 最後になりましたが、この連載が終わる頃には「(お客様からの)注文の多い料理店」を志す人が少しでも増えていることを切に願って、次回にバトンを渡したいと思います。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/2116 2008/09/04 18:47

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング