Monthly Archives: March 2013

[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つの役割は、パターンを適用したり展開するときの前提条件や、制約条件を記述できる点があります。さらに広い意味では、人間の意思に近いものもフォースと言えるかもしれません。まさに、ある種の力関係、力学的作用、そういうものが働くことによってパターンが成り立つというその状況を記述するための項目になります。

電子書籍が売れないとしたら、その理由は?

電子書籍問題の三部作、最後の記事です。今回は、取り次ぎは金融であるというお話です。出版流通での取次というシステムは、電子出版の注目とともに、より世間に知られることになりました。是非はともかく、これまで何十年の間、出版業界を支えていたのは事実です。

この話は、以前に出版を行う会社に居たときに聞いた話で、今は違っているかもしれませんが、大筋はそのままだと思います。その会社の話だけでなく、複数の会社でそうなっているというのを聞きました。出版社が書籍を出版し、取次に納品し、取次が書店に納品する、そして定価販売を義務づけられているけど、書店は自由に返品でき、それは出版社へも返品できるというのが原則でした。むかし、その原則にコンピュータ系ではおそらくただ1社アスキーだけが「返品不可」をやっていたのも記憶されます。しかし、普通は返品自由なので、書店にとってはリスクが低く、とりあえず注文するという気軽な発注にもつながります。

出版社にとっての出版から返品までのサイクルは、早く半年くらい、長くて1年あるいはそれ以上ということを聞いた事があります。今はもっと早いのかもしれません。このとき、驚くことに、出版時の納品によって、出版社は納品しただけの売り上げが立つらしいのです。そして、返品の度に買い取りになるのか、清算になるのか分かりませんが、取次に対しての支払いと、返品されてきた書籍の引き取りが発生します。つまり、出版直後はほんとうに読者の手に渡っていないのに出版社は売り上げになるという仕組みです。事実上、取次が出版社に対して金融しているのと変わらないという気がしますが、どうでしょう?

従って、出版を始めたばかりの出版社は、出だしがきわめて好調です。全部売れるからです(笑)。しかし、しばらくすると、返品の山で実は売り上げていないことが分かります。そうなると、ともかく、タイトル数を増やして突っ込むことで、売り上げを確保するという悪循環が始まるかもしれません。しかし、返品がどっさりとは言え、私の感覚だと、5〜10冊のうち1冊が大きく売れて、残りが損益分岐点程度なら、出版社は十分黒字になると思っています。全部が損益分岐点では人件費が出ません。ですが、時々ヒットを出すくらいでもうまく回るようです。返品があっても、またじわじわ売れるかもしれないし、ともかく、時々ヒットを打つくらいの感じでなんとか行くのです。

電子書籍は売れないと言われます。電子書籍は、まさに売れた分しかカウントされないので、過去の書籍に比べて売れている感じがしないのかもしれません。しかしながら、実は取次による金融システムによって、紙の書籍は売れているという錯覚に陥っている可能性も否定できません。出版後1ヶ月程度で、売れているかどうかは紙の書籍の場合、なかなか分かりません。最近は書店が減っているので大分分かるのかもしれませんが、一方の電子書籍はまさに生データなのです。出版社としてお金がきちんと(かどうかは問題あるんだけど)入ってくるビジネスに主軸を置くのは当然です。そして、お金の論理で「電子書籍は売れないですから」と言う訳です。

電子書籍の世界に、紙の書籍の取次のような金融的システムはあるでしょうか? 取次の闇の部分だけを引き合いにして邪魔者扱いするのはもうやめましょう。現状はともかく、古い時代に書籍の購入者から業界を含めて、読者の利益とみんなが儲かる仕組みを彼らは構築してきたのだとも言えます。ユーザの論理は重要ですが、業界として成り立つ仕組みがないと、絵空事で終わってしまいます。iPhoneが、Apple独自の流通網App Storeによって成り立ち、そしてそれが成功の一員となったことを改めて思い出し、電子出版にも紙の出版物と同様な業界モデルを本格的に模索をしなければならない時期にあるのではないでしょうか。

電子出版のコンテンツが限られるとすれば、その理由は?

日本でもiBooksが開始されました。けっこう時間がかかったという気がしますが、iPadが出た頃の盛り上がりの期待ほどでもないという点からは、時間がかかってサービスが立ち上がったところで誰も損はしていないのかもしれません。

さて、電子出版と言ったときにいろいろなコンテンツが考えられますが、やはり、既存の書籍や雑誌等の紙媒体と同等なコンテンツというのが1つの大きなジャンルになるのは疑いもない事実です。今回は、従来型書籍の電子化において、どうしてタイトルが増えないのかという点についての1つの見方を書きます。とはいえ、今現在はかなり増えていると思いますが、「元年」と言われて2年くらいはほんとにコンテンツが増えませんでした。もちろん、リーダや販売方法などといった、技術的な問題やインフラの問題もあり、そこは多くの人の興味がそそられるところでしょう。しかしながら、契約の問題はあまり深入りされることもなく過ごされています。

紙の書籍を出版すると、筆者と出版社はいわゆる「出版契約」という契約を結びます。正しくは、執筆前に契約するのですが、まあ、そういう事例はほとんどなく、通常は筆者が書き終わって出版するまでの間に取り交わします。文面に、「原稿をいついつまでに作成し…」などと寒い条項があるのは気にせずに進めます(大笑)。また、契約を結ばなくても、一般的な出版契約が結ばれたとみなされる点についても、かなり以前に裁判があって確定しているというのを聞いた事があります。借地権みたいなルールがあるのです。その契約書は、多くの出版社は、日本書籍出版協会のヒナ型を使っています。出版に興味のある方は、ぜひともこの契約を読んでください。最近では、電子出版に対応したバージョンもあります。

この出版契約で微調整するとしたら、印税などのお金の部分と、日時といった時間的要素だけでしょう。他の部分を調整したことを聞いた事はありません。その結果、出版権という権利が出版社に設定され、出版に関する権利を独占的に有することになります。筆者、つまり著作権者は著作物なのに自分で任意の方法で公開する事は契約上できなくなります。契約上の文言は時代とともに変化していますが、独占的な権利を持つという点はずっと同じです。

以前だと、出版物の流通経路は、出版社から書店に至るものしかなかったので、独占契約をしても、他のルートがあったわけではありません。もっとも、A社よりB社の方がたくさん売ってくれそうだとか、A社の担当者と喧嘩しておざなりにされたので別の出版社に変わりたいと言っても、そう簡単には出版した本の出版社は変更できるものではありません。私の経験でも、版元の会社が解散するので別の会社から改訂版を出すようなこと少しありましたが、これはレアケースでしょう。

結果的に、紙の出版物は、出版社が電子出版化することを決定しない限りは、電子出版として出回らないのです。筆者がどんなに希望しても、出版社の決定がなされないといけません。もっとも、出版社に多大な利益をもたらす筆者の場合はそれなりに意見は通るかもしれませんが、それはごく一部の話です。大多数は関係ないという感じです。出版社も電子出版に乗り気ですが、口を揃えて言うのが「電子出版は売れない」という話です。この話は回を改めますが、安定したビジネスの枠組みから出られない出版社ほど、電子化しないということになるわけです。たぶん、この3年ほどで、出版社を中心とした出版界の枠を出てしまった人は決して少なくはありません。その理由は、電子出版に対して消極的な態度を見せた出版社に対する不満が大きいと思います。契約で権利を保持するのはもちろん必要なことですが、独占権を持ちつつ権利を行使しないというのが、現在限られたコンテンツしか電子書籍になっていない状況を生み出しているのです。

ちなみに、出版権は、一般には書籍を廃版にすると消滅されることになりますが、契約の解除をしないと、いつまでも出版社に権利は残ります。私は何度か解除の依頼を出した事がありますが、交渉とか何もなく、即座に対応してくれました。出版社に取っては廃版となると一切お金にならないものは持っていても仕方ないですもんね。でも、在庫が山積みになっていると、なかなか廃版にはなりません。資産の破棄となり、そこで損失が発生するので、実は、廃版というのは会計的な意味でも大変なことなのです。

契約と言えば、私はいくつかの書籍で、珍しく出版前に契約をしたことがあります。がんばって、決められた日付までに原稿を提出して、そこから出版されたのは半年以上経過していました。契約書では、提出後3ヶ月くらいの期間で出版社は発刊するという文言があったのです。ちょっと釈然としないのですが、紳士的に「どうなってんの?」と問い合わせて返ってきた答えがこれまた絶妙でした。原稿の受け取り日は、出版社が自由に決められると言ってきました。つまり、私が書き終わって提出した日ではなく、出版社がさて編集始めるかと決めた日が「受取日」になるというものです。契約と言ってもいい加減なものです。まあ、この出版社はあまりいい末路でもなかったのですが、こういう経緯があっただけに、申し訳ないですが、同情する気にはなれませんでした。

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リレーションパターン」では、前提知識的なものもコンパクトにまとめて行くつもりでもあります。