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

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

略称：種類フィールド

名前：種類フィールドを持つテーブル（Ver.1.0）

問題：

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

解決策：

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

フォース：

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

バリエーション：

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

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

フォースについて

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

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

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

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

最初の問題

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

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

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

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

状況が追加された問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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