[FMRP] 繰り返しフィールド、ポータル、ポータルフィルタ

しばらくさぼってしまっていましたが、FileMaker Relationship Patternsの続きです。

カテゴリ:1対多

名前:繰り返しフィールド

問題:

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策:

繰り返しフィールドを必要な数、つまり複数のエンティティに対応するフィールドの数だけ定義して、レイアウト上に配置する

フォース:

TO間の結合を定義するのではなく、フィールドのオプション設定として、繰り返す数の上限を1より大きな値に設定する事で、繰り返しフィールドを用意する

繰り返しフィールドで複数のレコードに対する保存は確保できるが、厳密な意味でのテーブル間結合ではなく、第一正規形も満たしていない点を考慮する必要がある

複数エンティティを起点としたリレーションシップは確保できず、集計処理などができない。たとえば、伝票で明細を繰り返しフィールドで作れば「伝票」という帳票は作成できるが、明細行のレコードに関して商品ごとの売り上げ集計はできなくなる。

繰り返し数の上限は、データベースの定義で決める必要がある。繰り返し数が後から足りなくなった場合に増やす事もできるが、データベースの設計変更を伴う

繰り返しフィールドはスクロールができないため、レコード数が多数になると、レイアウトの広い範囲を繰り返しフィールドが占めてしまい、使い勝手が悪いレイアウトができてしまう

関連パターン:

ポータル


カテゴリ:1対多

名前:ポータル

問題:

1エンティティに対して複数のエンティティが存在する場合に、複数のエンティティを一覧表示したい

解決策:

レイアウト上にポータルを配置して、レイアウトのTOとリレーションシップでつながっている別のTOを割り当てる。これにより、レイアウトのTOのレコードと対応関係にあるポータルのTOのレコードが、ポータルに一覧される

フォース:

典型的な1対多の展開である。リレーションで直接つながっているTOだけでなく、複数のTOを経由した先のTOでもポータルには配置できる。

ポータルの中にポータルは配置できない。ポータルの中では1対1のリレーションシップの先の単一のフィールドしか配置できない。

関連パターン:

ポータルフィルタ、繰り返しフィールド


カテゴリ:1対多

名前:ポータルフィルタ

問題:

ポータルに表示するレコードを条件に応じて制限したいが、制約をリレーションシップで定義したくない

解決策:

ポータルフィルタの設定を行う

フォース:

FileMakerのリレーションシップの制約の1つは、複数のTOが存在するTOGにおいて、すでに2つ先になっているTOと直接結合することができないことである。つまり、条件の設定をSQLのように柔軟にできないため、リレーションシップだけで必要なレコードに絞り込むことが困難な場合も出てくる。ポータルフィルタは単にレコードに式をあてはめて、表示するかどうかを判定するだけである。ただし、式に使えるフィールドはリレーションシップに影響する可能性が発生するが、1つの解決方法はグローバルフィールドを用いて条件を与え、式で判定させるということができる点がある。従って、レイアウトに表示するという状況では、リレーション以外に制約を与える方法が存在するため、すべてをリレーションで解決する必要はない。

フィルタにより一部のレコードだけが表示されるが、フィルタの式の結果がすべてtrueつまり、フィルタ前のすべてのレコードを一度は読み込むため、レイアウトを表示した最初のときに非常に時間がかかるケースも発生する。FIleMaker 12の段階では、サーバサイドでフィルタを適用しているのではなく、クライアントサイドで適用していることが原因と考えられる。

関連パターン:

ポータル

INTER-Mediatorのターゲット指定を汎用化する

INTER-Mediatorでのターゲット指定は、タグ要素のclass属性に、IM[table@field@target] といった形式で記述するものだ。これにより、tableで指定したコンテキストにあるfieldというフィールドのデータを、そのタグ要素に埋め込む。targetを省略すると、フォーム要素以外ではテキストノードとして追加し、フォーム要素ではvalueやcheckedなどの適切な属性に設定される。targetでは、Ver.3.8現在、属性名、innerHTML、nodeText、$target、#target、style.styleNameをサポートしている。

このところ、いろいろなものをINTER-Mediatorで作っていて、ある同じようなパタンが頻繁に発生していることに気付いた。それは、

あるフィールドのデータがあれば表示し、なければ表示しない

という動作である。稀に逆もあるのだが、基本は同じだ。これを実現するために、たとえば、FileMakerだと、計算フィールドを利用する。あるフィールドfieldに対して、計算フィールドdisplayField = if ( field != “”; “block” ; “none” )を定義する。そしてたとえば、こんな感じのHTMLを書く。

<div class=”IM[table@displayField@style.display]”>
データ:<span class=”IM[table@field]”></span>
</div>

SQLデータベースなら、ビューを利用するのがいいだろう。たとえば、こんな感じだろうか?

CREATE VIEW tableview AS
SELECT field, if(LENGTH(field)>0, ‘block’, ‘none’) AS displayField FROM table;

これで対処はできるとは言え、もう少し簡単にならないかと考えてしまう。こうしたよくあることを手軽に対処できるというのはフレームワークに要求されることだ。もちろん、1つの方法は、ターゲット指定の3つ目のパラメータを増やす事だ。たとえば、こんなのはどうだろう?

<div>
データ:<span class=”IM[table@field|table@field@parentVisibility]”></span>
</div>

parentVisibilityという名前の属性はないので、HTMLのルールとのコンフリクトはない。フィールドの値が “” あるいは長さが0であれば、visibilityだったら自分自身、parentVisibilityだったら1レベル上位のノードのdisplayスタイルをnoneにするというところだ。

ということで、機能を増やしました…というのはなんかこの段階に来てやることかなと疑問に考えた。もっと汎用的にすべきではないのか?

そこで考えたのが、次のような仕様である。tagetの代わりに、プログラムのステートメントのような書き方をするということ。たぶん、これがいちばん汎用的と思われる。

table@field@object.method(parameters)

だが、いきなりこれだけですというのは敷居を高くするだけじゃないのかと思われるだろう。もちろん、その解決策はある。object.method(parameters)に対するエイリアスを定義することで、従来通りの記述をサポートするようにする。つまり、…@$onclickや、…@innerHTMLという記述はサポートする。ただし、これらはエイリアスという位置づけにする。ただ、内部的には#や$の扱いが微妙だが、これはif文をがんばって書くしかないだろう。

objectは、次の書き方をサポートしようと考えている。(self) (parent) (enclosure) (repeater) つまり、カッコの中に決められたキーワードを記述する。methodとparametersは任意だ。ただ、parametersは(“a”,’b’)なんて書いたときにカッコ内をそのまま渡すのはセキュリティ上の問題が出そうな感じありありであるので、ここは制約を付けることにする。

ターゲットの3つ目に記述する処理のためのオブジェクトINTERMediatorTargetを作っておく。たとえば、そこに、次のように、setInnerHTMLメソッドがあるとしよう。ここでの関数の最初の引数は、フィールドのデータであるというルールを適用することにする。

INTERMediatorTarget {
setInnerHTML: function(d) {
this.innerHTML = d;
}
}

ターゲット指定は table@field@(self).setInnerHTML() と記述する。そして、[(self).setInnerHTML()」のエイリアスが「innerHTML」であるというわけである。

ノード展開の処理では、ターゲット指定のあるノードnodeに対して、その指定に従ったフィールドのデータfieldDataが得られている。ということは、以下のようにapplyを使えばいいということになる。これは、INTER-Mediator内部の話であって、アプリケーションを作る側は気にしなくてもいい。

INTERMediatorTarget.setInnerHTML.apply( node, [fieldData] );

このノードに展開する仕上げに相当する値をセットする部分が現状ではひどくifの応酬となっているので、まずはそれを緩和したい。また、上記のような仕組みだと、INTERMediatorTargetオブジェクトへのメソッド追加や既存メソッドの書き換えにより、フレームワークの動作を改変することも可能だし、独自のターゲット指定記述を作る事もできる。

INTERMediatorTargetに記述する関数では、前記のように第1引数にフィールド値を設定するのはいいとして、汎用性を高めるために、2、3引数はフィールド名とコンテキスト名にする。これで、コンテキストやフィールドに応じて動作を変える事もできてします。

こういう実装を考えているところである。

[FMRP]TOの名前付け

パターンとして微妙、あるいはパターンと言えるほどの考察がないのじゃないのかと思われる1つのパターンを紹介しましょう。しかしながら、問題点は明確であると思います。

カテゴリ:要素

略称:ネーミング

名前:TOの名前付け(Ver.1.0)

問題:

  • TOは任意の名前が設定できる。そして自動的に名前が設定されてしまうが、そのままにすると後から混乱が生じる。
  • TOの名前は、元になるテーブル定義の名前とはまったく関係ない名前をつけてしまうこともできてしまう。
  • 1つのテーブル定義に対してたくさんのTOを定義することも多く、TO選択のポップアップメニューは混乱しがちである。TO選択時に目的のTOを確実に素早く探し出せる名前付けルールが必要である

解決策:

  • TOには、TOグループを端的に示す「グループ名」と、どのテーブルをもとしているかを示す「テーブル名」を含めた名前を付ける

フォース:

  • 1つのソリューションで一貫した名前付けのルールを持たせないと混乱する
  • グループ名とテーブル名だけでは、時として同じ名前の異なるTOが登場し、完全な名前付けができない。そこで、バリエーションにあるように、「用途名」といった補助的な名前を追加する必要が発生する

バリエーション:

  • 「グループ名_テーブル名」を基本とする。TOグループ内で同じテーブル定義を元にしたTOが複数登場する場合には、用途に応じて、「グループ名_テーブル名_用途名」、あるいは、「グループ名_用途名_テーブル名」をTO名とする。この名前付けルールだと、TO選択のポップアップメニュー等で、同一TOグループの項目がまとまる。その中で後半のテーブル名や用途名を見つけ出すという作業になる。TOグループを基準に考える場合には適した方法であると言える。
  • 「テーブル名_グループ名」を基本として、前記のバリエーションと同様に、さらに用途名を付け加える。この名前付けルールだと、TO選択のポップアップメニュー等で、同一のテーブル定義をもとにしたTOがまとまる。その中で後半のTOグループ名や用途名を見つけ出すという作業になる。テーブル定義名を基準に考える場合には適した方法であると言える。
  • TOの結合の流れに従って名前を付ける。名前からリレーションシップの中での関係が一目瞭然になるが、TO名が長くなり過ぎる傾向がある

関連パターン:(TBD)

FileMakerリレーションパターンの前提知識

本当はこれを最初にまとめないといけないのかもしれません。そもそも、パターンの記述を読み込むための前提知識は前提知識として定義できるはずです。パターン集ではあまりそういう記述を見ませんが、パターンなのか、たんなる機能なのかを判断する上でも、必要な情報と考えます。つまり、前提知識はパターンではないというところが出発点です。前提知識は、問題解決というよりも、単一の機能であるとも言えるかもしれません。以下、見出しが前提知識として提示します。

テーブル、フィールドといったデータベースの基本

データベースあるいは表形式のデータそのものは、フォーマットです。もしかすると、広い意味でのシステム構築パターンには「データベースを使う」というのがあるかもしれませんが、ここではリレーショナルデータベースを使用した場合の設計に関する問題解決にフォーカスしているので、フィールドやレコードといった存在、あるいはその概念は前提知識とします。

テーブル演算によるデータ処理

テーブル演算そのものは、パターンでないと考えますが、パターンの中で特定のテーブル演算を使うことはあり得ます。言い換えれば、テーブル同士の演算があるという前提から出発している話なので、これらも前提知識とします。

リレーションシップによるテーブル結合

前項と同じ意味ですが、テーブル同士は結合できるという事実も、前提知識です。いや、むしろ、この仕組みが出発点なのです。これはパターンではなく、いちばんコアな意味での前提知識と言えるでしょう。

FileMakerに関する機能

ここの切り分けが難しいところですし、どこまでの機能が前提知識で、どこからがパターンなのかは問題解決への貢献度や、自明さから考えることになるでしょう。「レイアウト」というのは機能であり、動作は明確であり、目的を持って使えるものです。しかしながら、レイアウトの機能でも「データに応じて文字列の色を変更したい」という問題点から出発すれば、「条件付き書式」はパターンかもしれません。一方、条件付き書式に対するトレードオフはFileMakerで実装しているかどうかの問題しかなく、問題解決で発生する葛藤は薄いでしょう。そうなると、「条件付き書式」はやっぱり単なる機能でしかないかなと考えるわけです。機能そのものがパターンになり得る場合も一部はあると考えますしかしながら、一般には機能そのものはパターンにはなり得ないと考えます。

他に項目を思い付いたらまた追記します。

[FMRP]種類フィールドを持つテーブル

前回の、FileMakerリレーションパターンの記事は、「いいね」が非常に少なくなり、みんなが引いているのが分かりますが、ともかく進めましょう。前回は、「種類フィールドを持つテーブル」というパターンがなぜ問題解決につながるのかを説明しました。パターンでは、そうした発見を、パターン記述にします。そのとき、適当に書き散らすのではなく、項目を決めておくのが一般的です。それもふまえて、「種類フィールド」パータンを記述したのが以下の通りです。

カテゴリ:リレーションシップ

略称:種類フィールド

名前:種類フィールドを持つテーブル(Ver.1.0)

問題:

  • 異なる種類の情報を一元的に管理をしたい
  • 異なる種類の情報を1つのテーブルでまとめて管理をしたい

解決策:

  • 種類ごとにテーブルを作るのではなく、単一のテーブルにさまざまな種類のデータをまとめて記録する。
  • 一般には種類ごとに必要なフィールドは異なるので、テーブルの定義では、複数の種類に必要なフィールドが混在する。不要なフィールドはつかなければ良い。
  • 一部のフィールドは、異なる種類で共通に使って良い。たとえば、「完了」フラグや、「発生日」といったフィールドがその例である。
  • そのときに、1つ1つのレコードに対して、いくつかある情報の種類のどれなのかを記録するためのフィールドが必要になる。そのフィールドには通常は番号を入力して、番号で情報の種類を特定することになる。

フォース:

  • 種類に対応したフィールドを求めるような仕組みはデータベースには一般にはない。そういう仕組みの構築も面白そうではあるが、実用的な意味と、限られた時間でシステム構築する上では、種類を特定する番号と、利用するフィールドの対応付けはドキュメンテーションで済ませることで大きな問題は発生しない。
  • フィールドの命名規則で、おのおののフィールドがどの種類の情報に関連したものかを明示する方法も考えられるが、一長一短がある。たとえば売り上げに関するフィールドは「sales_金額」「sales_個数」、コンタクト情報に関するフィールドは「con_名前」などとする。一見分かりやすそうに見えるが、異なる種類の情報でも、共通に使いたいフィールドが出てきたとき、名前を変えるべきなのかどうなのか、迷う事になる。また、複数の情報にまたがって使うようになっても名前が単一の情報を示してると、誤解を生じる。一般に、開発中のドメインについての理解があれば、「仕入金額」「受注個数」「担当者名前」などの名称で、概ね何の種類の情報かは分かるのが一般的だろう。種類に応じたフィールド名は、メンテナンスの問題が生じないかどうかをよく検討する必要がある。種類を特定するキーワードを入れないとすれば、これもドキュメンテーションにより各フィールドの利用方法を周知させる必要が発生する。
  • 粒度の小さな情報(たとえば、日時のみ、商品名のみ)を一元化したい場合には、このパターンではなく、別のパターン(名称未定、商品名についてはマスター処理と同等)を適用すべきである。このパターンは、複数のフィールドからなる情報がいくつも種類があり、それらをまとめて管理したい場合の1つの設計指針である。

バリエーション:

  • 種類フィールドを持つテーブルのレコードと、実際のデータがあるレコードを1対1でリンクを取ってもよい。たとえば、すでにある種のテーブルが利用されている上で、別の種類の情報と一元的に管理をしたい場合は、新たな情報については種類フィールドを持つテーブルにまとめるとしても、既存のテーブルに対してはリンクを取るだけにすることもできる。このとき、種類フィールドを持つテーブル側に外部キーフィールドーを設定し、元から存在するテーブルの主キー値を代入して対応付けをすれば良い。通常は、種類フィールドを持つテーブルから元からあるテーブルへの参照が多いと考えられるからである。
  • 情報の種類によって表示すべき情報が異なっている場合でも、それらを一覧したい場合もある。そのときは、表示用文字列の計算フィールドを作成すれば良い。たとえば、売り上げ情報なら金額、コンタクト情報なら相手と要件など、種類フィールドの値に応じた計算式を作る事で、1つのフィールドに種類によって異なる内容を表示させることはそれほど難しくはない。
  • あるテーブルから、種類フィールドを持つテーブルの特定の種類のレコードだけを参照したい場合、画面に表示するだけならポータルフィルタを利用できる(別パターンとしてまとめる予定)。また、リレーションシップ自体が特定の種類のレコードに絞られた状態にしたい場合、種類フィールドを持つテーブルとは違う方のテーブルに定数フィールド(別パターンとしてまとめる予定)を用意し、その定数フィールドと、種類フィールドを持つテーブルの種類フィールドの間にリレーションシップを定義する。

関連パターン:ポータルフィルタ、定数フィールド

フォースについて

パターンにおけるフォースの説明は大変難しいのですが、問題と解決策では記述しきれないことをフォースとしてまとめるというのが1つの方法です。フォースの1つの役割は、パターンを適用したり展開するときの前提条件や、制約条件を記述できる点があります。さらに広い意味では、人間の意思に近いものもフォースと言えるかもしれません。まさに、ある種の力関係、力学的作用、そういうものが働くことによってパターンが成り立つというその状況を記述するための項目になります。

FMリレーションパターンの作成方針

パターンに要求されるもっとも根本的なことは、問題解決のために利用できることです。ありがちな間違った理解は、技法に名前をつけることと混同していることです。あるいは、「自慢の得意技」を集めたものになってしまったとき、単に技法のカタログにしかなりません。問題解決のために必要な事は、当然ながら「問題点」の抽出と、その問題点の一般化による解決手段の提示が含まれている必要があります。

一方、ちょっと違う見方をすると、どこからが「機能」で、どこからが「パターン」なのかという線引きが分からないということもあります。パターンの世界では、いくつかの要件が組み合わされることの矛盾とそのトレードオフを示すということがパターンに対して要求されるということがよく言われますが、これは1つのヒントです。問題が発生するということは、おそらく要求が単純ではない、つまり、複数の要求があってあちらが立てばこちらが立たずという状況になっているということが言えるわけです。1つの機能でそうした複雑な問題に立ち向かえるかもしれませんが、もし、そうした機能があるとしたら、パターンというよりも、「チョイス」と言えるわけです。FileMakerの世界では、複雑な問題を簡単に解決ことができる「プラグイン」が存在します。では、「プラグイン」はパターンかというと、そうではないと私は思います。単一の機能に帰着するものは、シンプルな、つまり、1対1で事が終わるような問題と解法であり、知っているのかどうか、あるいは挙げられているのかどうかといった、ドキュメントの問題や、記憶しているかどうかといった問題で帰着する訳です。

では、パターンとして論じるものはどんなものがあるのでしょうか。次のような問題があるとしましょう。

最初の問題

顧客管理をしていて、顧客1人が1レコードを確保している(前提)。全社的な情報共有のために、顧客の購買記録と、顧客へのコンタクト記録をデータベースに記録したい(要望)。どのように、ソリューションを作るのが適切か?

FileMakerが得意な人は、もうあれこれ解決策は頭の中を巡るでしょう。もちろん、未確定な要素もあるので、そこはそれぞれです。また、上記の問題は、「問題点」がはっきり分かりません。その上で、まずはこう考えるのではないでしょうか。

  1. 購買記録、コンタクト記録は、別テーブルを用意してリレーションシップを定義する。いずれも、顧客レコードとは1対多の関係になる
  2. 特定の顧客に対してのそれぞれの記録は、顧客のレイアウトに、ポータルをそれぞれ配置すればとりあえずは参照できる
  3. 購買記録は他のテーブルにすでに残している事が判明した(状況の追加)。もともと、顧客とのリレーションシップは存在する
  4. コンタクト記録の入力をする場合、入力しやすいユーザインタフェースを作らないと、利用してもらえないのではないか

みなさんがさらに考えた事があれば、追加してください。ポイントは、ここまでは、FileMakerの単純な機能についての検討をしたということです。4については、いろいろあるかもしれませんが、要はFileMakerの機能の組み合わせということで帰着できるでしょうし、おそらくユーザ分析しないとこれ以上は議論できません。この状況から、パターンを抽出するのはちょっと無理かなと思います。FileMakerを勉強すれば、迷うところはありません。しかし、打ち合わせをしているうちに、どうもこういう問題ではないかと問題が拡張されてきます。

状況が追加された問題

顧客管理をしていて、顧客1人が1レコードを確保している(前提)。全社的な情報共有のために、顧客の購買記録と、顧客へのコンタクト記録をデータベースに記録したい(要望)。ただし、購買記録はすでにテーブルが存在する。一方、コンタクトと購買の関連を知りたいというのはユーザの要望としてでてきた。どのように、ソリューションを作るのが適切か?

ここでのポイントは、まず、「購買記録」テーブルは存在し、そこにおそらく販売担当者がレコードを追加する仕組みがすでに動いているということが想定され、自由に設計できない範囲が出てきました。一方、コンタクトは初出の機能だとしたら、ともかく、自由に作れそうです。

さて、「コンタクトと購買の関連を知る」というのは一種の非機能要求です。関連って何? 知るというのはどういう状況? ここの解決はユーザインタビューなどの要求工学的手法になるでしょう。開発者と顧客で喧々諤々の議論の結果、「購買情報」と「コンタクト情報」を交えたリストを1人の顧客に対して見えるようにするという基調の機能でいいのではないかとなってきました。大分具体的になってきました。

ここで、「購買記録」「コンタクト記録」が別々のテーブルにあるとして、統合的なリストを作りたいということが要求としてクリアになりました。問題点は「複数のテーブルを1つのテーブルのように扱う」ということでかなり抽象的に表現できそうです。ですが、まずは、FileMaker的にどのように解決できるでしょうか、いくつか案を考えてみます。

  1. コンタクトも購買テーブルの1レコードとして記録する。つまり、購買の特別な状況としてコンタクトがある。しかし、そうすると、現在の購買テーブルを利用している別のフォームで、コンタクトを見せないようにしないと行けない場合も出てくる。既存の作成物への変更なく終わらせるのはかなり難しい。
  2. コンタクトテーブルを作るのはもちろん、コンタクトテーブルの1レコードとして購買を記録できるようにする。既存の購買処理には表面的には手を加えなくてもよさそうだが、購買記録を付けたとときに、同時に新しいコンタクトテーブルへのレコード追加も必要となる。スクリプトを加えることで、既存の購買機能はそのままに機能の追加だけでできそうだが、購買機能側に、通販、Webなどなど状況ごとにレイアウトがあったりなんかすると、これは作業としてはコンプリートするのがかなり大変かもしれない。
  3. コンタクトテーブルは作るが、第三の(第4かな?)、「コンタクト&購買」テーブルを作る。まとめリストはそちらから取得する。この場合、前の2と同様、購買処理時に「コンタクト&購買」テーブルを作る必要があると同時に、コンタクトテーブルについても同じように、別のテーブルにレコードが必要になる。

どうでしょう、一長一短ありますね。まさにここでどうトレードオフをするのかが開発者の腕の見せ所でもありますし、それを成功させるために、より詳細に要求を詰めることもあるかもしれません。ただ、4つ目があるんですが、それは実はパターンそのものなので、以下に記述します。

こうした分析をすると、1つのパターンが見えて来ます。ここでは「種類フィールドを持つテーブル」と名付けます。どういうものかをまずはまとめます。

  • 複数の異なる情報を1つにまとめたリストとして表示する必要がある場合に適用可能
  • 新規にテーブルを作成し、テーブルの1つのフィールドにそのテーブルの種類を示す「種類」フィールドを確保する。一般には数値フィールドが良く、何らかの方法で、数値と種類の対応はドキュメント化しておく
  • 種類A、B、Cがあったとき、それらに必要なフィールドを、すべて新規に作ったテーブルに確保しても良い
  • 種類A、Bは新たな項目、一方、種類Cはすでにテーブルで存在する場合、種類Cを記録しているテーブ売るに対する外部キーを、新たに作ったテーブル上に確保する。また、外部キーは種類ごとに用意する

前に示した解決案2と3の折衷案的です。なぜ、3ではないのかというと、3のやり方はオブジェクト指向的な言い方で言えば、抽象クラスに相当するレコードを作る事です。1エンティティに常に2レコードを作るというのは、たとえばポータルなどを含めて、FileMakerではスクリプトを作成する以外に実現のしようがない機能です。そうした仕組みが広範囲に渡りそうなのが解決案3です。ここでは、すでに作ってしまった「購買記録」レコードのメンテナンスのためにスクリプトや改造をがんばって加えるとしても、新たに発生した「コンタクト」情報は素直に作ればいいだろうということで上記のような手法が考えられるということです。

「種類フィールドを持つテーブル」は、さまざまなトレードオフを考える基礎になるということで、パターンであると言えるかと思います。パターンは解決を約束するものではないので、これをベースに考えるということです。この問題で発生した、新たな記録テーブルと、既存の記録テーブルの混在という点についても指針があります。

ここまでがんばって読まれた方だと、容易に分かるかと思いますが、上記のパターンの箇条書きを理解するには、リレーショナルデータベースの基本的なことはみんな知っていないといけません。もちろん当然なのですが、言い換えれば「1対多のリレーションを取る」とか「ポータルに配置する」というのはパターンとは言えないと思います。もっとも、「ポータルフィルタ」は問題解決との関連があるので、パターンの1つと考えています。そこの線引きは難しいですね。一般にパターンカタログでは、パターンだけのカタログになっていますが、これから随時紹介する「FileMakerリレーションパターン」では、前提知識的なものもコンパクトにまとめて行くつもりでもあります。

FileMakerリレーションパターンを始めます

FileMakerのパターンについては、以前にいくつかサイトがあったようですが、fmpatterns.comだったかは応答なくなっていますし、こちらはリンク切れ気味です。まあ、オブジェクト指向の世界では90年代にパターンのブーム的なものもあったのですが、FMについては、2000年代の後半あたりにそのムーブメントがやってきて、そろそろおしまいなのでしょうか?

とは言え、パターン自体は確立した手法でもあるので、私の著書「リレーションで極めるFileMaker」(改訂版はRとの共著)にある解説内容を、パターンとして記述することを今検討中です。最近日本でも翻訳が出た「SQL Antipatterns」にも触発されました。

英語でのFileMakerに関するパターンは、誰かがWikiを立ち上げて、それにみんなが記述するという方法は取っていまして、まずはみんなの英知を集めいたいという意思は感じられます。ところが、パターン記述の定石とも言える、「決められた項目に従って記述する」ということが結局守られず、名前とやり方だけが掲載されていて、微妙に自慢大会状態になっていました。

パターンがなぜ使われるかというと、問題解決につながるからです。そのためには、開発作業に名前を付けるのはパターンの本質ではなく、発生した問題からパターンにたどり着くパスが必要なのです。そういう記述を、現状では工夫して行うということになりますが、やっていく必要があります。それを意識しながら、パターンを記述して行きたいと思っています。

ということで、これは前振りでした。