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

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

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

略称:種類フィールド

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

問題:

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

解決策:

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

フォース:

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

バリエーション:

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

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

フォースについて

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

Leave a Reply