FileMaker Server 7 Advanced には、FMP6までで使われていた CDML ファイルを、FileMaker Web Publishing Engine で使える XSL に自動コンバートしてくれるツール FileMaker CDML Converter が付属しています。
これを使って、試しに当方で現在 FileMaker Pro 6 でのシステムにて使っている CDML ファイルをコンバートしてみました。
続きを読む
2005年01月13日
2005年01月11日
FileMaker Pro 6 のデータベースを 7 に変換
FileMaker Pro 7 ではデータベースファイルのフォーマットが新しくなり、従来の FileMaker Pro 6 で開発したデータベースは新しいフォーマット (.fp7) にコンバートしなければなりません。
FileMaker Pro 7 で古い形式のデータベースを開こうとすると、自動的にコンバートするか聞いてきます。
現在 FileMaker Pro 6 にて運用しているデータベースシステムを、試しに .fp7 にコンバートしてみました。
続きを読む
FileMaker Pro 7 で古い形式のデータベースを開こうとすると、自動的にコンバートするか聞いてきます。
現在 FileMaker Pro 6 にて運用しているデータベースシステムを、試しに .fp7 にコンバートしてみました。
続きを読む
2004年12月23日
FMP 7 でカスタムWeb
FileMaker 7 でカスタム Web システムを開発する場合、以下の方法があります。
○FileMaker Server 7 Advanced の Web Publishing Engine & XSLT
○FX.php を使って PHP で組む
従来の CDML にて作成したテンプレートは、FMS7Aに付属のツールで XSLT にコンバートすることが出来ます。（ただし若干の制限あり。試しにやってみた結果は改めて書きたいと思います。）
XSLT は、フィールド値の挿入や条件分岐、リピートなどしかできなかった CDML に比べると遥かに強力です。ただ、書いたソースはなかなか読めなくて（特にCDMLからコンバートしたものは！）、メンテナンス性はどうかな？といった印象です。
もう一つの FX.php はファイルメーカー社ではなく、Chris Hansen により提供されている、フリーでオープンソースの PHP ライブラリです。FMP 6 の頃からありますが、FMP 7 にも対応しました。
これにより、PHP での様々なツールやライブラリ、開発ノウハウを利用することが出来ます。ウチの次のシステムはこれを使って開発をする予定です。
○FileMaker Server 7 Advanced の Web Publishing Engine & XSLT
○FX.php を使って PHP で組む
従来の CDML にて作成したテンプレートは、FMS7Aに付属のツールで XSLT にコンバートすることが出来ます。（ただし若干の制限あり。試しにやってみた結果は改めて書きたいと思います。）
XSLT は、フィールド値の挿入や条件分岐、リピートなどしかできなかった CDML に比べると遥かに強力です。ただ、書いたソースはなかなか読めなくて（特にCDMLからコンバートしたものは！）、メンテナンス性はどうかな？といった印象です。
もう一つの FX.php はファイルメーカー社ではなく、Chris Hansen により提供されている、フリーでオープンソースの PHP ライブラリです。FMP 6 の頃からありますが、FMP 7 にも対応しました。
これにより、PHP での様々なツールやライブラリ、開発ノウハウを利用することが出来ます。ウチの次のシステムはこれを使って開発をする予定です。
2004年12月21日
複数テーブルを一つのファイルにすると、ファイルを開く時間は早くなるか？
FileMaker Pro 6 でリレーショナルデータベースを作るとファイルの数がたくさんになって、これをネットワーク、特にLANでなくもっと遅いネットワークで使用すると、ファイルを開くだけでしばらく待たされ、あげくにタイムアウトして接続が切れてしまう事がありました。
FileMaker Pro 7 では一つのファイルに複数のテーブルを持たせる事が出来るようになりました。この場合、上記のような問題は解決されるのでしょうか？
FileMaker Pro 7 で、複数テーブルからなるリレーショナルデータベースを、FileMaker Pro 6 のときのと同じようにテーブル毎にファイルに分けた場合と、全く同じ構成のものを単一ファイルにした場合とで、国際ネットワークを介して開いた場合のレスポンスを比較してみました。
複数ファイルの場合はやはり一つ一つのファイルを開くのに時間がかかります。（FileMaker Pro 6 のときよりちょっと早いような気がしますが）
単一ファイルの場合、確かに早くなります。ファイル一つ分の時間しかかからないようです。
FileMaker Pro 7 では一つのファイルに複数のテーブルを持たせる事が出来るようになりました。この場合、上記のような問題は解決されるのでしょうか？
FileMaker Pro 7 で、複数テーブルからなるリレーショナルデータベースを、FileMaker Pro 6 のときのと同じようにテーブル毎にファイルに分けた場合と、全く同じ構成のものを単一ファイルにした場合とで、国際ネットワークを介して開いた場合のレスポンスを比較してみました。
複数ファイルの場合はやはり一つ一つのファイルを開くのに時間がかかります。（FileMaker Pro 6 のときよりちょっと早いような気がしますが）
単一ファイルの場合、確かに早くなります。ファイル一つ分の時間しかかからないようです。
2004年12月20日
FileMaker Pro 7 カスタムwebで複合検索できるか
FileMaker Pro 6 のカスタムwebではできなかった、-lop=andと-lop=orを組み合わせた複合検索は、FileMaker Pro 7 カスタムwebでもできない。
ということは、やはり
等の処置が必要ということ。
ということは、やはり
複合検索の条件に合う計算フィールドを定義して、これで検索する。
データベース側で検索スクリプトを定義して、それを呼び出す。
大きめの条件で抽出し、HTML変換時にいらないものを落とす。
等の処置が必要ということ。
Table Occurrence その２
さて、ここまでの基本を理解したら、今度はこれをどのように活用するかが大切です。
”Knockin'on Seven's Door” という、FileMaker Pro 7 の開発者向け情報ポータルサイドがあります。ここで、”Key Concepts in FileMaker 7”というドキュメントの存在を知りました。これは “Database Interst Group for FileMaker”というサイトで公開されています。
このドキュメントは、”TO≠Table” を強いメッセージとして打ち出していて、TOを理解する事がFileMaker Pro 7 での開発にとても重要であると言っています。私もこのドキュメントを読んで、TOの重要性に気づいた訳です。
※なおこのドキュメントの日本語訳は、上記”Knockin'on Seven's Door”にて公開予定との事です。楽しみですね。
さらにこのドキュメントでは、”Table Occurrence Group (TOG)”という概念を導入しています。先の例で言えば、A1とB1は一つのTOGに属し、A2とB2はまた別のTOGに属することになります。
あるTOGに属するデータから、別のTOGに属するTOのデータを参照する事は出来ません。従って、データベースシステムを設計するにあたり、どういった切り口からデータを見せるかを考え、TOGを形成してゆく事になります。先の例で言えば、テーブルAを主テーブルとしてデータを見せる切り口(Point-of-View, POV)と、テーブルBを主テーブルとしてデータを見せる切り口(POV)があり、それぞれにTOGを定義する事になるわけです。
「べつに従来の FileMaker Pro 6 のやり方でも、ちゃんとできていたのだから、なんでそんな面倒くさい事をやらないといけないのか」と考える方もいらっしゃると思います。はい、私は思っちゃいました。
でもよく考えると、これまでのやり方では、複雑なシステムではたくさんのリレーションがあちらこちらに定義され、まるでスパゲッティのようになっていて、全体像を把握する事は簡単ではありませんでした。特に FileMaker Pro 7 ではリレーションの「孫引き」ができるようになったので、つながり合ったいくつものテーブルをひとつのTOGとして管理できることは大いにメリットがあるように思います。
ただし、ここらへんはもっともっと FileMaker Pro 7 での開発経験を積まないと、わからない世界かもしれません。
※先の例ではA->B, B->A というリレーションで説明しましたが、これはA->Bで定義された２つの異なるリレーションの場合でも同じです。
※私の理解や説明にも間違いや、「もっとこういうメリットがある！」という箇所がきっとあると思います。気づかれた方はぜひ教えていただけると幸いです。
”Knockin'on Seven's Door” という、FileMaker Pro 7 の開発者向け情報ポータルサイドがあります。ここで、”Key Concepts in FileMaker 7”というドキュメントの存在を知りました。これは “Database Interst Group for FileMaker”というサイトで公開されています。
このドキュメントは、”TO≠Table” を強いメッセージとして打ち出していて、TOを理解する事がFileMaker Pro 7 での開発にとても重要であると言っています。私もこのドキュメントを読んで、TOの重要性に気づいた訳です。
※なおこのドキュメントの日本語訳は、上記”Knockin'on Seven's Door”にて公開予定との事です。楽しみですね。
さらにこのドキュメントでは、”Table Occurrence Group (TOG)”という概念を導入しています。先の例で言えば、A1とB1は一つのTOGに属し、A2とB2はまた別のTOGに属することになります。
あるTOGに属するデータから、別のTOGに属するTOのデータを参照する事は出来ません。従って、データベースシステムを設計するにあたり、どういった切り口からデータを見せるかを考え、TOGを形成してゆく事になります。先の例で言えば、テーブルAを主テーブルとしてデータを見せる切り口(Point-of-View, POV)と、テーブルBを主テーブルとしてデータを見せる切り口(POV)があり、それぞれにTOGを定義する事になるわけです。
「べつに従来の FileMaker Pro 6 のやり方でも、ちゃんとできていたのだから、なんでそんな面倒くさい事をやらないといけないのか」と考える方もいらっしゃると思います。はい、私は思っちゃいました。
でもよく考えると、これまでのやり方では、複雑なシステムではたくさんのリレーションがあちらこちらに定義され、まるでスパゲッティのようになっていて、全体像を把握する事は簡単ではありませんでした。特に FileMaker Pro 7 ではリレーションの「孫引き」ができるようになったので、つながり合ったいくつものテーブルをひとつのTOGとして管理できることは大いにメリットがあるように思います。
ただし、ここらへんはもっともっと FileMaker Pro 7 での開発経験を積まないと、わからない世界かもしれません。
※先の例ではA->B, B->A というリレーションで説明しましたが、これはA->Bで定義された２つの異なるリレーションの場合でも同じです。
※私の理解や説明にも間違いや、「もっとこういうメリットがある！」という箇所がきっとあると思います。気づかれた方はぜひ教えていただけると幸いです。
Table Occurrence
FileMaker Pro 7 でのデータベース設計についていろいろ調べているうちに、"Table Occurrence" という概念の理解と活用が不可欠であるように思えて来ました。
"Table Occurrence (略してTO)" については、日本語のヘルプの中では明確に定義もなく、また翻訳もそのときどきに応じて「テーブルの別の名前」とか「固有の名前を持つ新規のテーブル」というように訳されていて、いまひとつ要領を得ません。
※ところで日本語ヘルプの「リレーションシップグラフについて」のセクションの翻訳はひどいですね。原文で "Because the graph is never a cycle," (グラフはループを作ることはできないので、) という文章が、「グラフの表示を切り替えることはできないため、」と訳されていて、全く意味が通じません。
※"Table Occurrence" はどのように訳すのがいいでしょうか。Mac OSを使っている方には「テーブルのエイリアス」というのがイメージをつかみやすいかもしれません。何か良い訳語はないでしょうか？ 現実的にはTOで通してしまう事になるのでしょうが、FileMaker Pro 7 を理解する上での大切な概念ですので、ぜひわかりやすい訳語をつくりたいものです。
TOとは、FileMaker Pro 6 でリレーションに名前をつけて管理していたものに替わる概念です。リレーションシップグラフでテーブル間のリレーションを定義するとき、実体としてのテーブルに別の名前をつけて定義する事が出来ます。これが TO です。FileMaker Pro 7 ではリレーションは、このTO名で管理されます。
それではなぜ従来のやり方ではなく、TOが必要なのでしょうか？
FileMaker Pro 6 では「一方向」だけだったリレーションが、FileMaker Pro 7 ではすべて「双方向」に動作するようになりました。また、リレーションはループを描くように定義する事が出来なくなりました。
FileMaker Pro 6 では テーブルA -> テーブルB のリレーション（「リレーション１」とします）と、それとは別の B->A のリレーション（「リレーション２」）を、それぞれリレーションに名前をつけて定義できたのですが、FileMaker Pro 7 のリレーショングラフでこれをやろうとすると、A<->B間のリレーションがループを描くことになってしまうため、定義できません。（無理に定義しようとすると、A<->Bのリレーションは「リレーション１とリレーション２を複合したもの」になってしまい、本来やりたかったものとは全く違うリレーションになってしまいます）
では FileMaker Pro 7 ではどうすればよいのでしょうか。
まず、テーブルAのTOすなわちA1を定義します。続いてテーブルBのTOすなわちB1を定義します。そしてA1とB1の間に「リレーション１」を定義します。
さらに、テーブルAの新たなTOすなわちA2と、テーブルBの新たなTOすなわちB2を定義します。そしてそのA2とB2の間に「リレーション２」を定義します。
※文章だけでは判りづらいかもしれません。ぜひ自分でやってみてください。
"Table Occurrence (略してTO)" については、日本語のヘルプの中では明確に定義もなく、また翻訳もそのときどきに応じて「テーブルの別の名前」とか「固有の名前を持つ新規のテーブル」というように訳されていて、いまひとつ要領を得ません。
※ところで日本語ヘルプの「リレーションシップグラフについて」のセクションの翻訳はひどいですね。原文で "Because the graph is never a cycle," (グラフはループを作ることはできないので、) という文章が、「グラフの表示を切り替えることはできないため、」と訳されていて、全く意味が通じません。
※"Table Occurrence" はどのように訳すのがいいでしょうか。Mac OSを使っている方には「テーブルのエイリアス」というのがイメージをつかみやすいかもしれません。何か良い訳語はないでしょうか？ 現実的にはTOで通してしまう事になるのでしょうが、FileMaker Pro 7 を理解する上での大切な概念ですので、ぜひわかりやすい訳語をつくりたいものです。
TOとは、FileMaker Pro 6 でリレーションに名前をつけて管理していたものに替わる概念です。リレーションシップグラフでテーブル間のリレーションを定義するとき、実体としてのテーブルに別の名前をつけて定義する事が出来ます。これが TO です。FileMaker Pro 7 ではリレーションは、このTO名で管理されます。
それではなぜ従来のやり方ではなく、TOが必要なのでしょうか？
FileMaker Pro 6 では「一方向」だけだったリレーションが、FileMaker Pro 7 ではすべて「双方向」に動作するようになりました。また、リレーションはループを描くように定義する事が出来なくなりました。
FileMaker Pro 6 では テーブルA -> テーブルB のリレーション（「リレーション１」とします）と、それとは別の B->A のリレーション（「リレーション２」）を、それぞれリレーションに名前をつけて定義できたのですが、FileMaker Pro 7 のリレーショングラフでこれをやろうとすると、A<->B間のリレーションがループを描くことになってしまうため、定義できません。（無理に定義しようとすると、A<->Bのリレーションは「リレーション１とリレーション２を複合したもの」になってしまい、本来やりたかったものとは全く違うリレーションになってしまいます）
では FileMaker Pro 7 ではどうすればよいのでしょうか。
まず、テーブルAのTOすなわちA1を定義します。続いてテーブルBのTOすなわちB1を定義します。そしてA1とB1の間に「リレーション１」を定義します。
さらに、テーブルAの新たなTOすなわちA2と、テーブルBの新たなTOすなわちB2を定義します。そしてそのA2とB2の間に「リレーション２」を定義します。
※文章だけでは判りづらいかもしれません。ぜひ自分でやってみてください。
