FileMakerで4つのテーブルのTOがあって、それぞれ次の図のようなリレーションシップになっているとします。というか、具体的に書いてもいいのですが、汎用的に記述しようとしているので、テーブルはABCDの4つ、それぞれ主キーフィールドが必要な場合はidフィールドとし、外部キーは、a_idなどのように頭にテーブルの文字を追加したフィールドにしています。つまり、Aテーブルのidと、Bテーブルのa_idが結合時に参照されるフィールドになるということです。Bテーブルはidはなくてもいいので、省略しています。そして、データを実際に入れてみました。
ところで、実用的にはこれは、「マスターがややこしい伝票」と考えればいいです。Aテーブルがまず伝票1枚に対するテーブルで、Bテーブルは伝票の明細です。そして、Cテーブルは商品マスターです。伝票の明細であるBテーブルへの商品記録は、商品マスターの主キー値をc_idフィールドに記録して、その他の値は別途取ってくるという状況のようです。ちなみに、Dは何かといえば、例えば「単価マスター」と考えてみましょう。商品マスターと単価マスターが別々というところで、単純には1対1でうまく管理すれば問題ないと最初は思います。
しかし、作り込んで行くに従って、謎なことが発生します。これらのデータを、AテーブルのTOをレイアウトのTOに指定したレイアウトで見てみると、こんな感じです。ややこしいですが、頑張って数字を追ってください。a_id=101は素直なデータという感じですが、102と103はC、Dテーブルがなんかおかしいかなという感じで、すぐに詳しく説明します。
ここで、SumValueというフィールドが見えています。このフィールドは、Aテーブルに計算フィールドとして作ったものです。「SUM( D::value )」と定義しています。先ほどの伝票で言えば、伝票上の商品の単価合計みたいなものでしょうか？ 実用上、そういう計算をすることはまずないですが、わかりやすく説明するためにあえてそういう言い方をします。
a_id=101つまり、最初のレコードは、SumValueフィールドの値は111です。右端のDテーブルのポータル展開した結果を見ても、思った通りに計算できているようです。
ところがa_id=102はどうでしょうか？もちろん、Dテーブルのポータルに見えているvalueフィールドの値が全部加算されて、12001となっています。a_id=103つまり3つ目のテーブルも同様です。これは、これで正しいのですが、もし、Bテーブルのレベルで見えているレコードに対する加算をしたかったとしましょう。つまり、BテーブルのポータルにDテーブルのvalueフィールドを配置した場合に、その合計が欲しかったとしたらどうでしょう？ つまり、こういうことです。
BテーブルにDValueフィールドを定義して、ポータルに配置してあります。DValueの計算式は「=D::value」です。なので、ここにDテーブルのvalueフィールドを配置しても同じ結果になります。そして、AテーブルにはSumBValueフィールドを定義して、計算式として「=SUM( B::DValue )」を指定してあります。
まず、2レコード目のa_id=102を見てみると、SumValueはBテーブルのポータルにあるvalueの合計ではなく、上から2桁目が多いわけです。SumBValueは正しく計算されているように見えます。しつこいようですが、Bテーブルのポータルが「正しい」という基準が適用されています。a_id=103についてもSumValueは少ない結果になっているように見えますが、SumBValueはBテーブルのポータルに見えているvalueフィールドの値が合計されているように見えます。
もう解答を言ってありますが、いきなりDテーブルのフィールドをSumしても、思った通りの値にならないかもしれません。その場合は、一度Bテーブルで値を参照してからその参照値を合計するという二段階にすればなんとかなります。
しかし、このサンプルは、やってはいけないことに近いことをやっています。Dテーブルのid=404のレコードは2つあります。つまり、idフィールドは主キーにならない状態になっているのです。やってはいけないけど、FileMakerはやれてしまいます。この結果、Aテーブルの2レコード目のSumValueとSumBValueの計算結果が異なるのです。Cテーブルのd_idをよくみると、401のレコードが2つあります。CとDが多対1なら、リレーショナルデータベース的にはOKと言えるかもしれませんが、もし、これが、CとDのレコードが1対1を目指しているのなら間違ったデータとなるかもしれません。
ここでの技術的な説明の根本は、SumValueとSumBValueが違うということです。時と場合によって、どちらが欲しいかは変わってくると思います。何が正しいということは一概には言えないものの、FileMakerのリレーションシップは、こうした「違い」が時として現れます。レコード間の関連の取り方で、集計結果が違うということを理解し、正しい設計を行い、それを逸脱しないようにしなければなりません。特にFileMakerでは主キーの扱いが曖昧です。もちろん、主キーなので重複した値を許可しないようにすれば終わりで、Aテーブルの2レコード目、3レコード目のような状態にはできませんが、いろいろな事情でそうした設定をやっていない場合には、このようなレコードになってしまう可能性があります。また、インポートに至っては、フィールドに「ユニークな値」を設定していても、重複する値を入力可能な場合もあります。緩いプラットフォームは楽な一方で、謎の結果に悩まされるということもありうるのですね。