ずっと延び延びになっていた FMP7 ベースのシステムへの移行がようやく動き始めました。これまでの各種要素技術の基礎調査をひとまず終了し、今はこれまで FMP6 で作って来た30個以上のファイル群からなるデータベースシステムを、FMP7 で一から組み直すための検討を行なっています。
これまでの制限だらけだった FMP6 に比べて、FMP7 では「こんなこともできるのか〜、これまで苦労して実現していたのに…」ということがいくつもあって、今更ながらこのメジャー・アップデートのありがたみを実感しています。
FMP6 から FMP7 への仕様上の変更点については、ファイルメーカー社のサイトや、さまざまな書籍にまとめられていますので、ここでは私自身が「変わったな〜」と感じた点をまとめます。
(本記事は随時更新しますのでご了承ください。タイムスタンプは更新時のものに直します)
○リレーションの孫引き・ひ孫引きができるようになった
FMP6 では複数階層のリレーションの定義はできても、直接呼び出せるのは直下のもの(親→子)だけでした。孫のデータを引っ張ってくるのに、子のテーブルに孫データを読み込む計算フィールドを持たせたりしなければなりませんでした。
FMP7 ではリレーションでつながっていればどのテーブルにあるデータでもレイアウト上に置くことができます。また何階層も離れているリレーションフィールドを検索条件としても、高速にインデックスサーチを行なうことができます。(今私の実験しているデータベースでは、最大5階層での検索やリレーションフィールドの表示も充分高速に動作しています。1万レコード以上あります。)
従来、使い勝手や検索性を考えてテーブル構造を不自然な形にせざるをえなかったこともありましたが、FMP7 ではちゃんと正規化した形でテーブルを組むことができます。
一方、従来のリレーションはあくまでも二つのテーブルの関係を定義するだけのものだったのに対し、FMP7 ではシステム全体に影響してきます。はじめてデータベースを作る人はもちろん、FMP6 でのやり方がしみついてしまった(私のような)人も、再度基本と応用力をしっかり身につけてゆく必要があると思います。その意味で、基本の確認には「リレーションで極めるファイルメーカー7」を、応用力については「FileMaker 7 キーコンセプト」日本語版がきっと役に立つと思います。特に「FileMaker 7 キーコンセプト」で解説されている Table Occurence の概念は、FMP7 日本語版のオンラインヘルプではとんでもない誤訳になっていますので、ぜひこちらをお読みください。
○ポータルの入れ子はやっぱりできない
せっかく孫引きができるようになったのですが、残念ながらポータルの入れ子は FMP7 でもできません。ここは従来同様、ユーザインタフェースでカバーしないといけません。
ただし、ポータル内に孫・ひ孫のリレーションフィールドを置くことはできます。つまり「親→子」が「1対多」のためポータルにした場合、「子→孫」や「子→ひ孫」が「1対1」なら、「親→子」ポータル行にそのまま孫やひ孫のフィールドを置けます。上述の「計算フィールドによる疑似参照」が必要ないということです。
○複数ウィンドウを開けるようになった
FMP7 では一つのファイルに複数テーブルを持つことができるようになりましたので、当然ながら一つのファイルに対して複数ウィンドウを開けないと困ってしまう訳ですが、さらに同じテーブル・同じレイアウトに対しても複数ウィンドウが開けるようになったのは、ユーザエクスペリエンスの点では効果が大きいと思います。例えば、あるレコードの情報を見ながら、別のレコードの編集をする、ということが簡単にできてしまいます。
一方、いつ、どのウィンドウを開くか、閉じるかをよく考えて作らないと、かえってユーザを混乱させてしまうことになります。設計者はユーザが使っている様子をよくイメージして、ウィンドウのコントロールを考えなければなりません。
2005年07月15日
この記事へのコメント
コメントを書く
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/5110736
※ブログオーナーが承認したトラックバックのみ表示されます。
この記事へのトラックバック
http://blog.seesaa.jp/tb/5110736
※ブログオーナーが承認したトラックバックのみ表示されます。
この記事へのトラックバック

