はじめに：ファイル分割の明確な基準はありますか？

Claris FileMaker の開発において、データと UI（画面）を分ける「分離モデル」は、パフォーマンスや保守性の観点から推奨されるアーキテクチャです 。しかし、UI ファイルを分離した後、肝心の「データファイル」をどのように分割すべきかについては、明確なガイドラインが少ないのが実情ではないでしょうか 。

データの性質を考慮せずにファイルを分割すると、リレーションシップグラフが複雑化したり、将来的な拡張が困難になったりするリスクがあります。

本記事では、1999年に Peter Coad らが提唱した「カラーUML（Color UML）」の概念を Claris FileMaker の設計に応用し、データの「色」に基づいてファイルを分割する手法をご紹介します 。

Step 1：データを「4つの色」に分類する

この手法では、システムで扱う全てのデータを、その性質に応じて以下の4つのアーキタイプ（色）に分類することから始めます 。

  1. グリーン（Party, Place, Thing）- 実体

    「誰？どこ？何？」を表す、システムの中核となるマスタデータです。

    例：顧客、従業員、商品、倉庫 

  2. ブルー（Description）- 定義・分類

    「何の種類？どんな区分？」を定義するデータです。グリーンを分類するためのラベルであり、変更頻度が極めて低いのが特徴です。

    例：商品カテゴリ、顧客ランク、配送方法 

  3. ピンク（Moment-Interval）- トランザクション

    「いつ起きた？（いつからいつまで？）」という出来事を記録します。業務の記録としてデータ量が増加し続ける部分です。

    例：受注、出荷、請求、在庫移動 

  4. イエロー（Role）- 役割・関係

    「誰が何として参加しているか？」を表すデータです。実体（グリーン）同士の関係性を定義します。

    例：顧客担当（顧客×従業員）、商品仕入先 

重要なポイント：「イエロー（Role）」は属性か、テーブルか？

ここで一つの疑問が生じるかもしれません。「役割」や「担当」であれば、マスタテーブルの中にある「担当者フィールド」のような属性（フィールド）で十分ではないか、という点です。

カラーUMLにおける「イエロー」は、単なる属性ではなく、独立したテーブルとして定義することに大きな意味があります。その理由は主に2点あります。

  1. 多対多の関係を解決するため 例えば「一人の従業員が複数の顧客を担当」し、かつ「一社の顧客を複数の従業員で分担」するような場合、単一のフィールドでは表現しきれません。イエローはこのような多対多の関係を解決する中間テーブルとして機能します。
  2. 期間や条件を管理するため 関係性には「期間」が伴うことが多々あります。「2023年度の担当者はAさん、2024年度はBさん」といった履歴や、「この仕入先からの購入単価は〇〇円」といった条件を持たせる場合、属性ではなくテーブルとして切り出す必要があります。

逆に言えば、履歴管理が不要で、単に区分を表すだけであれば、それはイエローではなく「ブルー（Description）」として扱うか、単なるフィールドとして定義すれば十分です。



Step 2：色に基づいたファイル分割設計

各テーブルの色が決まれば、それに基づきファイルの配置先を決定します。基本方針は以下の通りです 。

ファイル種別

含める色

特性

Master 系

グリーン ＋ ブルー ＋ イエロー（静的）

変更頻度が低く安定的。複数システムで共有可能な基盤となります。

Transaction 系

ピンク ＋ イエロー（動的）

データが増大し続けるため、アーカイブの対象となります。

UI 系

データなし

画面とロジックのみを保持します。

Step 3：イエローの配置判断と業務別構成

イエロー（関係性）の配置は、その関係が「継続的」か「一時的」かによって判断します 。

  • Master 系へ配置： マスタ同士の継続的な関係（例：顧客担当）。これらはマスタデータの一部とみなせます 。
  • Transaction 系へ配置： トランザクションに紐づく一時的な関係や、集計データ（例：在庫サマリ）。これらは日々の業務処理とともに変動するため、トランザクション系ファイルに配置します 。

中規模以上のシステムでは、全てのトランザクションを1つのファイルにするのではなく、以下のような業務ドメインごとの分割が推奨されます 。

  • Master.fmp12（共有マスタ）
  • Sales.fmp12（販売管理：受注、出荷、請求など） 
  • Purchasing.fmp12（仕入管理：発注、支払など） 
  • Inventory.fmp12（在庫管理：在庫移動、棚卸など） 

まとめ

カラーUMLを用いることで、「なぜそのテーブルをそのファイルに置くのか」という設計意図を論理的に説明できるようになります。

  • 肥大化する「ピンク」を業務ごとに切り出す。
  • システム全体で共有すべき「グリーン・ブルー」を一元管理する。
  • 複雑になりがちな「イエロー」を、その性質（静的・動的）に合わせて適切に配置する。

感覚的な設計から脱却し、拡張性と保守性に優れたシステムを構築するための指針として、ぜひこの手法を取り入れてみてはいかがでしょうか。