定義や設定に関わるものと、実データのものを分けて考える
FileMaker 7以降、データベースの中に複数のテーブルを持てるようになり、リレーショナルデータベースの機能を持つことができるようになりましたが、他のRDBシステムと同様に考えられる面もある一方で違うところもあります。FileMaker特有の概念を実際の動作とあわせて解説しましょう。
FileMakerは当初、1つのファイルが1つのデータベースでそこには1つのテーブルだけがありました。これは概念的には分かりやすいものの複雑なシステムを組むことはかえって難しくなり、Ver.6まではリレーションの機能があるものの、独特なノウハウをマスターしないとシステム構築はできないほどでした。もちろん、FileMaker 7以降の改良により、独特なノウハウが必要な環境から一般的なデータベースに近くなったのはよく知られるところです。
しかしながら、従来の考え方、機能は、当然ながら互換性を維持するために残されています。データベースの定義のダイアログボックスには昔からフィールド定義をそこで行っていましたが、従来は「テーブルの定義」という操作はなかったため、FileMakerになってその機能を加える必要が出てきました。そして、データベースの定義のダイアログボックスでその作業が行えるようになったのです。リレーションシップはむしろ以前のテーブル間結合とは大きく違うので、操作の互換性は取られていないのですが、逆にレイアウト機能のように見かけはあまり変わっていない機能もあります。
従来の機能との親和性や互換性を保ってのアップデートを行うというのは、それなりインストルベースのアプリケーションでは当然のことではあります。特に、業務ユーザが多いFileMakerでは「変わらない」ことが大きな要求にもなってしまいます。しかしながら、マルチテーブル化は激しい変化であることは言うまでもありません。これまでのFileMaker開発者は少なからず面食らったことでしょう。もちろん、発売後何年も経過した執筆時点でも、まだまだ「FM7アレルギー」を訴える人もいます。
移行をすすめる上でおそらく従来の利用者に対する配慮は最大限にされたことと想像します。そのため、名称を同じものにも関わらず、概念に変化が出てくるものが発生しました。それが小さなことならさておき、「テーブル」という考え方そのものがむしろFileMaker 7では変化したと考えるべきでしょう。
データベースの定義ダイアログボックスには、「テーブル」というタブがあり、そこにテーブルが一覧されています。これはまぎれもなくテーブルですが、FileMakerでのテーブルにはいろいろな概念のものが含まれています。たとえば、明示的、あるいは暗黙的に、以下のものをテーブルと呼んでいます。
従来はある程度それを抽象的に、ある意味では混同して考えていてもあまり支障は出ませんでしたが、FileMaker 7以降は概念を別々に分ける必要があると考えます。
その根本的な考えは、テーブルの定義と、実データを伴ったテーブルを、別々のものとして考えるということです。この章では、以下のような定義で、それぞれの対応を取ることにします。
| 名称 | 意味 |
|---|---|
| テーブル定義 | 「テーブル」タブで定義されている１項目。さらに「フィールド」タブでは、テーブル定義のなかでも重要なフィールド定義の参照し編集できる。 |
| テーブル | データを伴ったテーブル。言い換えれば、表形式に利用可能な一連のデータ。テーブルは、「リレーションシップ」のタブでの１つのボックスに対応する。 |
ここで、英語版のFileMakerは、前者をTable、後者をTable Occurrenceと呼んでいます。「Table Occurrence」は、Tableが何度でも登場するという意味合いもあるのですが、むしろ「テーブルを実現化したもの」のような意味もあるでしょう。そして、略してTOと呼ぶこともあります。
しかし日本語版のFileMakerは、TableもTOもどちらも「テーブル」と呼びます。想像するに、ローカライズを行う段階で、「テーブルオカーレンス」と言っても通じにくいだろう…といったような議論があったのかと思いますし、一方で同じ名前にするのはどうだろうかという議論もあったかと思われます。経緯はともかく、現状のFileMaker 8でも、どちらも同じ「テーブル」として参照し、区別していません。
英語版でTableとTOのうち、前者が「Table」と言っているのは、従来のVer.6までがすでに「テーブルの定義」のことを「テーブル」と呼んでいた名残ではないかと思われます。従来まではテーブルの定義がある意味での設計のすべてだった訳ですから、テーブル定義がまさにテーブルという存在においての重要なものだったわけです。
しかしながら、あえて言えば、TableとTOとして参照するよりも、「テーブル定義」と「テーブル」として参照する方が素直ではないかと筆者は考えます。Ver.6までとの互換性や親和性は、もはやマルチテーブル化ではむしろ足かせにかるとも言えます。以下、日本語版にならってTOという言葉は使いません。テーブルには「定義」と「データをともなった実体」があって、それぞれ「テーブル定義」と「テーブル」と呼べばいいでしょう。つまり、今までの考えに「定義」ということを分離したにすぎない訳です。
ここからは、前記のように「テーブル定義」と「テーブル」として参照します。第２章でも説明をしたように、テーブル、つまりリレーションシップの定義で登場する１つのボックスを、レイアウトが利用します。つまり、レイアウトは、どのテーブルを使うのかということを指定する必要がある訳です。
レイアウトを作成するときには、使用するテーブルを指定しますし、後から「レイアウトの設定」のダイアログボックスを呼び出して変更することもできます。
実際のテーブル定義、そしてリレーションシップのグラフでのテーブル、さらにレイアウトは、いずれもFileMakerを操作して作るものです。つまり、データベース上に定義されたものです。
FileMakerで「コンテキスト」というちょっと分かりづらい用語が使われます。計算式を設定するときに、ポップアップメニューでコンテキストを選択するような場面で出てきます。この「コンテキスト」はきわめて概念的な用語ではありますが、いちばん近い日本語は「状況」と思っていいでしょう。状況と言っても、実際のデータに絡んで結果的にそうなっている状況ということです。定義と実際は違うと言えば違います。たとえば、伝票と明細は確かにリレーションシップが定義されていますが、もし、テーブルに全くデータがないだとか、あるいは明細テーブルに一切レコードがないというようなときには、実際に関連づけられたレコードは存在しないことになります。この場合は「コンテキストは存在しない」と言ってもいいでしょう。ただこの言い方はFileMaker内部の動作定義とはやや異なります。コンテキストは、「実際のデータの状況」という意味合いでまずは漠然と理解していただいて、データベースの動作を見てみましょう。
テーブル定義に対応する実在のデータとして実データがあります。テーブルは、実データの内容をもとにしたレイアウトなどで使えるデータが群ですが、検索により絞り込みが行われてすべてのレコードがそこにあるかどうかは分かりません。つまり、テーブルという存在に対するコンテキストとして、その時々でかわるデータがあるわけです。さらに、テーブルはレイアウトで表示しますが、ここではすべてのフィールドがあるわけではありません。配置したフィールドだけが表示され、場合によっては異なるテーブルのフィールドが表示されます。また書式設定もされています。ここでも、レイアウトは定義されるものですが、実際にウインドウに表示するときにはデータによってその表示結果は異なります。つまり、コンテキストに応じてレイアウトがウインドウに表示される結果が決められるわけです。ここでは、実際のデータが絡むという意味での「コンテキスト」を考えることにします。
その状況を図示しました。「テーブル」「テーブル定義」「レイアウト」はFileMakerの中で明示的に作ることができるものです。「テーブル」は、リレーションシップでのボックスの１つとして作ることができます。
これに対するデータの存在を下の段に対応させます。テーブルの定義に従って、「実データ」が存在します。これがデータベースのストレージ部分と言えるでしょう。そして、テーブルという存在が、レコードのセットを定義します。すべてのレコードかもしれませんが、絞り込まれているかもしれません。そして、あるフィールドでソートされている可能性もあります。さらに、テーブルを利用してレイアウトが表示されますが、レイアウトでは、フィールドが選択されつつ、どのように配置されるかといった点が定義されています。こうしたデータの流れがあって、ウインドウに実際に表示されるというわけです。状況を作り出すものとしての「コンテキスト」は、テーブルとレイアウトの実データから派生した局面であると考えれば良いでしょう。
では、実際にFileMakerを動かしてみて、テーブルとレイアウトの関係を確かめてみましょう。そのためのデータベース「テーブルコンテキスト.fp7」を作成します。同名のテーブルが自動的に定義されますが、これは使わないで、他に「マスター」「詳細」というテーブルを定義します。名前が示す通り、マスターと詳細テーブルが1対多の関係を持つということを想定していますが、これはリレーションについて検討するときに改めて説明しましょう。
「マスター」テーブルのidフィールドは、1から順番に数値が自動的に入力されるようになっています。ここでは、レコードとして入力されたデータの振る舞いを見たいのですが、あえて他にはフィールドは定義しないで利用することにしました。gNumMasterはグローバルフィールドとしました。グローバルフィールドの振る舞いもあとから検討します。
「詳細」テーブルの「id」フィールドは、1001から順番に数値が自動的に入力されるようにしました。「マスターid」フィールドは、「マスター」テーブルとのリレーションを取るための外部キーフィールドです。gNumDetailはグローバルフィールドです。
「リレーションシップ」のタブには自動的に3つのテーブルが見えているはずですので、とりあえず、「マスター」のidと「詳細」の「マスターid」をドラッグして結んでおきます。
さらにリレーションシップに、同一のテーブル定義である「マスター」をもとにしたテーブルをもう１つ用意しておきます。元々あるテーブルは「マスター」ですが、新たに付け加えるテーブルは「別のマスター」という名前にします。ダイアログボックスの左下のボタンをクリックして、さらに表示されるダイアログボックスで「マスター」というテーブル定義を選択して、「テーブルの別の名前」に「別のマスター」とキー入力してOKボタンをクリックします。
ここまでの作業で、自動的に「マスター」テーブルに結びついた「マスター」レイアウトが作成されています。このレイアウトで、新たにレコードを作っておきます。Ctrl+Nキーでざっと10個ほど作っておけばいいでしょう。
次に、テストで使う新たなレイアウトを作ります。レイアウトモードにして、Ctrl+Nキーを押すなどして、新たに作りますが、1つは図にあるように「マスター」レコードをもとにした「マスターA」というレイアウトにします。見やすいように「表レイアウト/レポート」をレイアウトタイプとして選択すればいいでしょう。なお、配置するフィールドはすべてを選択するなど、引き続く作業は適当に行っておきます。そして、作成したレイアウトがどれか分かりやすいように、「レイアウト：マスターA」と書かれたテキストをレイアウトのヘッダ領域に配置して起きました。もちろん、フォントなど、適当に設定をしておきます。
もう１つレイアウトを作ります。１から作ってもいいのですが、ここであえて「複製」をしてみます。レイアウトの複製は、作業上よく行うことですが、改めて何が複製されるかも考えつつ作業をしてみましょう。
複製したレイアウトは「レイアウトA のコピー」という名前ですので、「レイアウト」メニューの「レイアウトの設定」を選択して表示されるダイアログボックスで、レイアウト名を「マスターB」に変更しておきます。そして、「レコードを表示」のところで「別のマスター」テーブルを選択しておきます。また、ヘッダに配置したテキストも、「マスターB」と書き換えておきます。
さらに、もともとレイアウトに含まれているフィールドの設定も変更します。たとえば、idフィールドは、「マスター」テーブルのidフィールドの内容を表示しますが、レイアウト設定を変更してもこの設定は特に変わりません。ここでは「マスター」ではなく「別のマスター」のidフィールドを表示させたいので、レイアウト上のフィールドをダブルクリックして表示されるダイアログボックスの「データを表示」のところでテーブルを選択し直します。これをしないと意図しない結果になります。図はidフィールドに対して行っていますが、レイアウトを複製したときにはこの作業はレイアウト上のたくさんのフィールドで行わないといけないこともあります。
以上で、テーブル定義「マスター」をもとにしたテーブル「マスター」と「別のマスター」を利用するレイアウト「マスターA」と「マスターB」が作成されました。この状況で次のように作業をしてみます。
1最初に「マスターA」のレイアウトを見ます。検索は行っていないので、10個のレコードがすべて見えています。
2検索モードにして、idフィールドの値が5より小さいレコードだけに絞り込みます。条件として「<5」を入力して「検索」ボタンをクリックします。
3検索した結果、条件とおり、idフィールドの値が5より小さなレコードだけが表示されました。
4ここで、左側のステータスエリアの「レイアウト」からレイアウトとして「マスターB」を選択します。初めてこのレイアウトでの表示をしているので、ここではすべてのレコード、つまり10レコードが全部見えています。同じテーブル定義の「マスター」をもとにしている「マスターA」レイアウトでは4レコードだけしか見ていないのですが、こちらでは全部見ている点に注意をしてください。
5「マスターB」のレイアウトでは、検索条件を「3より大きい」として検索を行います。
6レイアウトの「マスターB」では、3より大きなレコードだけが表示されています。
7ステータスエリアでレイアウトとして「マスターA」を選択します。やはり、以前に検索を行ったときと状況は変わらず、5より小さな数字のレコードだけが表示されています。
以上の流れから明らかなように、テーブルにあるデータは10個ですが、別々のテーブルを作り、それと結びついているレイアウトで異なる条件で検索すると、それぞれのレイアウトでは見えているレコードは異なります。
つまり、テーブル定義があって、その定義にのっとってレコードが記録されます。それを実際のレイアウトに結びつけるのではなく、「テーブル」という存在があり、それをいくつも作ることができます。それぞれのテーブルでは検索結果を持っていて、結果的に別々のレコードのセットをレイアウトに提供することができると考えればいいでしょう。これらは、別々のコンテキストが定義されていると表現できます。
検索結果がテーブルにあると考えてもかまわないことを、念のため、改めて確認をします。ここまでに使っている「マスター」テーブルを利用する「マスターA」レイアウトがありました。これに加えて、同じく「マスター」テーブルを利用する、別の「マスターC」というレイアウトを作ります。「マスターC」は、単に「マスターA」の複製を作り、ヘッダの見出しを書き換え、レイアウト情報で、レイアウト名を「マスターC」としただけです。あとの設定は同一です。ここでは、4つのレコードがある状態で結果を見てみます。「マスターA」で、4つのすべてのレコードが見えています。このとき、単に「マスターC」に切り替えると、「マスターA」と同様、4つのレコードがすべて見えています。
「マスターA」を表示 |
「マスターC」も同じレコードが表示 |
ここで、「マスターA」でレコードの絞り込みを行います。ここでは、前の状態から2つのレコードをCtrl＋Tで省略して、2つのレコードを表示するようにしました。検索と省略は結果的には同じことをしているのです。さて、「マスターC」に切り替えると、こちらは省略を行った結果の2つのレコードが見ています。レイアウトごとに絞り込み結果を記録しているのではなく、テーブル側に絞り込み結果が記録しており、ここでの例では、それぞれ絞られたレコードのセットを異なる2つのレイアウトに表示していることになります。
「マスターA」でレコードを絞り込んだ |
やはり「マスターC」でも同じレコードが表示 |
レイアウトが違っても、同一のテーブルを利用していれば、レコードのセットは同一のものがレイアウトに対して供給されます。ここではフィールドが事実上１つだけなので、見かけも同じですが、通常はレイアウトごとに使用するフィールドや配置などが異なります。つまり、同じデータでも見え方が異なると考えれば、同じテーブルを使っていても異なるコンテキストがレイアウトを複数用意することで実現します。ただし、このことは、データベースの構造というよりも、レポートやユーザインタフェースのバリエーションをレイアウトを作ることによって実現できるというFileMakerの初期からある機能をコンテキストとして表現したにすぎないことになります。
では、この状況で、レコードを追加した場合にどうなるかを見てみましょう。「マスターA」では「<5」、「マスターB」では「>3」という条件で絞り込まれています。「マスターA」レイアウトを表示して、Ctrl+Nで新しくレコードを作ります。ここでは、id=11というデータを持ったレコードが新たに作られて表示されているのが分かります。ところが、ここで「マスターB」レイアウトに切り替えても、新しいid=11のレコードは見えていません。つまり、ある条件で検索をかけていると、新しくレコードが追加されたとしても、レコードのセットに加わるのは表示しているレイアウトの場合であると言えるでしょう。
ここで理解すべきことは「テーブル」は検索条件を覚えているというよりも、検索した結果のレコードのセットを持っているということです。もちろん、検索条件は覚えてはいるのですが、レコードの追加で再検索は自動的には行わないということです。
では、レイアウトで検索を行っていない状態ではどうでしょうか。以下は、結果を見やすくするために、テーブル定義の「マスター」に、id=1〜3の3つのレコードがある状態で作業を行っています。そして「マスターA」「マスターB」とも検索を行っていないですべてのレコードを表示している状態にしています。ここで「マスターB」のレイアウトで表示しているときに、新規にレコードを作ります。もちろん、4つ目のレコードが定義されてこの「マスターB」レイアウト上にレコードが登場します。
ここで、レイアウトをすべてのレコードを表示している「マスターA」レイアウトに切り替えると、今度は新しく作ったレコードは見えています。
以上をまとめると、次のことが分かります。
次にレコードの削除とテーブルとの動作についてチェックしてみましょう。以前と同じく、id=1〜10の10個のレコードがある状態で、「マスターA」レイアウトではidが5より小さいレコードだけに絞られており、「マスターB」レイアウトではidが3より大きなレコードだけに絞られているとします。この状態で、どちらのレイアウトにも表示されているid=4のレコードを削除してみます。「マスターB」レイアウトで、Ctrl+E等でレコードを削除します。ダイアログボックスで確認されるので「削除」ボタンをクリックします。もちろん、即座にレコードは消えてなくなりますが、ここで別のレイアウト「マスターA」に切り替えてもやはりレコードはなくなっています。
レコードの削除の場合は、状況にかかわらず、すべてのテーブルに対して結果は反映されると考えていいでしょう。動作としては当然のことですが、レコードの追加とは違いがあることはチェックポイントになります。
さらに、レコードのフィールドの値を編集した場合も同様にチェックしてみましょう。異なるテーブルに結びつけられている2つのレイアウトで同じレコードが表示されるようにしておき、一方でフィールドの値を変更します。そしてレイアウトを切り替えると、対応したレコードのフィールドは編集した結果になっています。こうした動作はFileMakerを使っている人に取っては当然と思われるかもしれませんが、ここでは、削除や修正についてはすべてのテーブルに即座に反映されるという結果がポイントになります。
FileMaker 7の1つの新機能として、マルチウインドウ表示があります。単にウインドウを複数利用できると思われがちですが、テーブルとの関連ではこの動作も知っておく必要があります。
ここまでに使っている「テーブルコンテキスト」データベースで、「マスターA」レイアウトで表示し、すべてのレコードを表示しておきます。この状態で、「ウインドウ」メニューから「新規ウインドウ」を選択すると、同じデータベースを表示するウインドウが開かれますが、通常は同一のレイアウトが表示されます。
新しいウインドウは「テーブルコンテキスト-2」のような名前がつきますが、マクロ等で新たにウインドウを作成するようなときには自由に名前を付けることができます。ここではデフォルトのままで使用します。新しいウインドウで、検索を行います。ここでは、idフィールドの値が6より小さいレコードだけに絞り込みます。
結果は次の通りです。検索したウインドウでは検索結果に従ってレコードがしぼられていますが、背後のウインドウでは同じレイアウトが選択されているにもかかわらず、手前のウインドウでの検索前後で違いはありません。つまり、同じレイアウトでも、ウインドウが違うと「異なるもの」ということになります。
ウインドウが異なっている場合、同じレイアウトでも違う結果になります。これはFileMakerの世界では「コンテキストが違う」という考え方につながるものです。
ウインドウが異なっていたり、レイアウトが異なっていたりする場合、同一のレコードをその上で表示し編集することができます。このときに注意したいのは、あるウインドウで編集中のレコードは、別のウインドウでの編集ができません。たとえば、ボタンをクリックしてウインドウを出して同じレコードを編集するようなユーザインタフェースはよくありますが、そのままだと「編集できない」というエラーが出るということです。この場合は、ボタンをクリックして実行されるマクロで、他のフィールドを選択するなどして、フィールドの編集を確定してからウインドウを表示するといったスクリプトを組むと良いでしょう。
さらに注意すべきなのは、あるフィールドが変更され確定しない段階では、レコード全体が他のウインドウからの変更ができない状態になることです。従って、変更仕様としているフィールドと違うフィールドも、同様に編集できないというメッセージが出て編集作業に入れません。
ただし、異なるレコードである場合や、あるいは変更途中でないような場合にはエラーは出ません。たとえば、フィールドを単に変更しようとして、その中に文字カーソルが点滅する状態になっているだけだと、他のレイアウトでの変更は可能です。
ネットワークで共有したデータベースを異なるコンピュータから接続して利用してみます。それぞれ、異なるユーザで接続していると考えていいでしょう。ここでの結果は明らかに、ユーザごとに見える結果は異なるということです。つまり、ウインドウが違う場合とユーザが違う場合は、いずれも同様に、異なるコンテキストであるということです。
以下、WindowsとMac OS Xで動くそれぞれのFileMaker Pro 8で、同一のレイアウトを表示しています。Windows側で適当に省略するなどして絞り込みをしていますが、Mac OS Xの方でも同様に省略をして絞り込みを行います。それぞれ、異なる絞り込み結果でレイアウト上では見えています。
もちろん、実用的な意味で考えれば、あるユーザがあるレイアウトで検索してしまった場合、同時に開いている他のユーザでも検索がなされる…というのでは問題があります。同じデータを共有していたとしても、そのデータをどのように加工し、どのように見たいかはユーザごとに違うはずです。従って、同じレイアウトでも違う結果が見えるというのは実用上必要とされる機能です。
ユーザによって状況が違うということで、ここでは「ユーザごとにコンテキストが存在する」という言い方もできるでしょう。
リレーションシップを定義した場合のテーブルとテーブルの関係を見てみましょう。ここまでのところでは、レイアウトに表示したテーブルには、検索結果が適用されるということが分かっています。リレーションを取っているレコードをポータルに表示した場合を探ってみます。
1「マスター」レイアウトは「マスター」テーブルをもとにしています。そこにポータルを配置しますが、ポータルはリレーションシップを取っているテーブル「詳細」と関連づけており、そのテーブルのフィールドを並べています。
2「マスター」テーブルは、id=1、id=2のレコードが存在します。そして、「詳細」テーブルは、このように、「マスターid」フィールドが1ないしは2のレコードが存在しているとします。ここでは、それぞれのテーブルに手作業でデータを入力しました。
3「マスター」レイアウトを表示します。ポータルは「詳細」テーブルで「マスターid」フィールドの値が1のレコードが確かに表示されています。id=2のレコードを表示すると、確かに「マスターid」が2のレコードがポータルに表示されています。
4「詳細」レイアウトに切り替えます。このレイアウトは「詳細」テーブルに結びついています。ここで、idが1005より大きいレコードに絞り込みました。
5「マスター」レイアウトに切り替えて、id=1のレコードを見てみます。ここでは、以前と同じく、「詳細」でのid=1001, 1003のレコードが見えています。
以前の検証で、「テーブルには検索条件が適用される」と見ることができると説明しましたが、この結果からすると、「詳細」で検索をかければ、「詳細」をポータルで展開しているレイアウトでも影響が出るはずですが、そうではありません。
ここでも、「コンテキストが違う」という考え方を適用しなければなりません。ある１つのテーブルが、レイアウトで表示される場合と、ポータルで表示される場合とで、「コンテキストが違う」のです。言い換えれば、リレーションシップの定義に従って、一連のテーブルが作られ、それが1つのレイアウトに展開されるのです。
この場合、レイアウトが参照しているテーブルに対して、そのテーブルからリレーションが定義されたテーブルが存在します。図では、後者は下のテーブルです。ここに対する「絞り込み」はリレーションシップの設定が適用されます。前のレイアウトで言えば、「マスターid」フィールドで絞り込みが下のテーブルに対して行われます。「ソート」については、リレーションシップでの定義、あるいはポータルの定義として行われます。
図の下のテーブルは、前に説明したデータベース上の作業では別のレイアウトに結びつけられていますが、ここで、テーブルとレイアウトのセットがコンテキストの基本になることを思い出してください。リレーションシップの関連テーブルとして利用したときには、そのテーブルは、参照しているレイアウトとは切り離されたコンテキストとなるのです。
ここまでに使ったデータベースでは、テーブル間の関連性はシンプルなER図で記述できます。一方、その中身をコンテキストとして考えた場合、テーブル同士の結合から生まれた新しいレコードのセットが作られます。結合の定義から生まれた関連テーブルのレコードのセットがそれぞれのマスターテーブルのレコードに付加され、そうして構築されたものがやはりテーブルであるということがコンテキストの源になるわけです。それをレイアウトに展開するわけです。
データベースのリレーション定義はER図で記述できることは知られている通りです。一方、FileMakerのリレーションシップ図はER図とは違うとも言われています。シンプルなデータベースの場合は、さほど大きな違いは見えないのですが、テーブルを複数配置するあたりがER図とはテイストの違うものであることは確かです。ER図は、関係を簡潔に表すものですが、FileMakerはそこに実際のデータがどう絡むかということを考慮しましょうということを込めてリレーションシップ図が作られます。
たとえば、顧客マスターは、ER図的には、いろいろなテーブルからの関連付けが行われることになります。従って、1つのエンティティから、複数のエンティティに結合線が引かれます。こうした関係だけに注目するのがER図のポイントでもあります。
一方、FileMaker的な考えとしては、そこに実データを絡めます。ある顧客マスターは、伝票作成時に使うかもしれません。一方、顧客ごとの売上総額などを集計するときに使うかもしれません。それらは同じデータではありますが、1つを選択する、あるいはあるグループの1つとして扱うなど、場面によって出てきてほしいデータが異なります。そうしたデータを絡めた局面を「コンテキスト」と考えればいいでしょう。これら顧客マスターを使う局面ごとに、別々のテーブルをリレーションシップに定義するという考え方が、FileMakerのコンセプトとも言えます。
グローバルフィールドは、通常のフィールドとはいろいろな意味で動作が違います。まず、複数のウインドウを表示した状態で、グローバルフィールドの動きを見てみましょう。2つのウインドウで同一のレイアウト「マスターA」を表示しています。ここで、当然ながら、グローバルフィールドですので、どのレコードでもグローバルフィールドのgNumMasterは同じ値になっています。あるウインドウでグローバルフィールドを変更し、フィールドの編集を終えると、即座に同じレイアウトはもちろん、他のウインドウでも新しく書き換えた値がgNumMasterフィールドに見えています。
検索結果は同じレイアウトでもウインドウによって違う結果を出しますが、グローバルフィールドは、保存しているデータでもあるので、すべてのウインドウで同じ値を表示するのはある意味当然のことと考えることができるでしょう。
では、上記のような状態で、異なるコンピューからつまりは違うユーザでデータベースを開いて、グローバルフィールドを変更します。以下の図では、Mac OS Xで開いて、gNumMasterの値を9999にしましたが、こうしても、Windows側で開いているデータベースは4545のままです。これが、普通のフィールドであれば、「ユーザごとに違う」ということはありませんが、グローバルについてはユーザごとに違う値を取るという、独特な動きをします。しかしながら、ウインドウごとに違うというわけでもないというところも注意が必要です。
データベースを開いたときのグローバルフィールドの初期値ですが、おおざっぱに言えば、そのデータベースを最後に閉じたときにそのグローバルフィールドに存在していた値になります。最後の１人のユーザでログインしている状態で、そこでデータベースを閉じれば、そのときのグローバルフィールドの値が初期値になり、以後、開くたびに、グローバルフィールドの値はその値で初期化されます。
もっとも、この説明が正しいかどうかは突っ込みどころかもしれませんが、重要なのは、あるユーザでログインをしたとき、そのユーザが以前に入力していたグローバルフィールドの値が得られているということは保証の限りではないということです。つまり、マルチユーザで使う限りは、グローバルフィールドの初期値は、必ず自分で設定してから使わないといけないということに他なりません。