データモデリングとは
データモデリングとは、データの要素をテーブル、フィールドといったFileMakerの基礎的な要素に割り当てることです。
例えば、見積書を作成するAppを作りたいとします。見積書には、日付、宛名、見積金額などが必要です。さらに、通常は下部に商品の名前、単価、数量などが複数記載されます。この、日付、商品名などが、データの要素となります。
それらの要素をどのテーブルに配置していくか、テーブルが複数ある場合どのように関係しているかを考えるのが、データモデリングです。
見積書を例にとって少し考えてみたいと思います。
見積書には、先ほど挙げた通りの要素があります。まず注目するのは、１つの見積書に複数ある要素と、１つしかない要素を分けていきます。
日付、宛名、見積金額は、１つの見積書に１つしかありません。
対して、商品名、単価、数量といった要素は、１つの見積書に複数あります。この二つに分かれていきます。よって、1つしかない要素、複数ある要素でテーブルを分けます。
筆者は、この場合「見積書マスター」「見積書詳細」といった名前で、テーブルを２つ作成します。
また、見積書のように複数の要素（明細行）がない帳票の場合は、通常1つのテーブルで構わないでしょう。例えば「領収書」は1つテーブルになるでしょう。
迷うモデリング
上記は比較的わかりやすい、決めやすい例です。次に、少し対応に迷うケースを挙げてみます。
「人」と「部署」です。
結論から言いますと、部署ごとにデータをまとめたり（売上など）する必要がある、もしくは可能性としてある場合は、「人」、「部署」を管理するテーブルを分けます。その必要がない場合は、「部署」テーブルは不要でしょう。
納品書を作成するAppを開発するとします。販売担当者がいて、納品書に紐づきます。この時に、担当者ごとの売上をまとめたり、部署ごとにまとめる場合もあるでしょう。こういった場合、納品書というテーブルとは、別に担当者マスターというようなテーブルを作ります。
さらに、部署ごとに売上データなどをまとめたい場合には、部署マスターを作成し、担当者テーブルと紐づかせます。
このように、テーブルの作成には、正解が存在せず、その会社、業務のあり方に応じたモデリングが必要になってきます。
なんでも、計算式だけで解決しようとしない
よくありがちなパターンです。これを行ってしまうと、寿命が短くなる原因となる場合が多いでしょう。もちろん、「単価*数量」のように四則演算や、1つ、2つの関数で計算が済むのようなものは、それで構わないでしょう。
FileMakerには計算タイプのフィールドがあります。設定した計算式の結果を表示するためのフィールドです。リレーション先のフィールドのデータを集計したりすることもできます。
資産の減価償却を行う場合を少し考えてみましょう。
減価償却の計算は、複雑です。例えば、資産のテーブルがあり、簿価というフィールドがあるとします。簿価は、取得価額から、減価償却した額を引くことで計算されます。この簿価のフィールドを計算フィールドとして、計算式を設定し、その中ですべて計算してしまおうというやり方はおススメできません。
この資産テーブルとは別に、減価償却額を決算や月ごとに計上したときに、レコードが作成されるテーブルを作成するべきです。
資産テーブルだけの構成で、簿価フィールドに複雑な計算式を設定してやるやり方もできないことはないですが、担当者が変わったり、5年後10年後見直したときに、計算式が理解できない可能性も十分にあります。ここは、テーブルを分けるのがいいでしょう。
フラグの活用
計算式の代わりに、「フラグ」と「スクリプト」を活用していきます。
「フラグ」は、そのレコードの処理が終わった場合や、逆に処理が必要な場合など、そのレコードの状態を記録するために利用します。
例えば、ある帳票を印刷したときに「印刷済み」というフィールドにデータを設定します。最も簡単なのは、数字タイプのフィールドにして「1」を入力することです。また、タイムスタンプタイプのフィールドにして、印刷したときのタイムスタンプを設定してもいいでしょう。
このように、計算式を設定した計算フィールドでそのレコードが処理するべきものかどうかなどを判定させるのではなく、スクリプト等で処理したらフラグ用のフィールドに「1」などのデータを設定して、判断するようにします。
また、同じように、何かを判断する処理するといった行動を行う場合には、上記の減価償却の例のように、計算式だけで行うのではなく、スクリプトによって処理を行いましょう。
減価償却の例でいうと、毎月今月の償却額を計算し、「減価償却」テーブルに、１資産につき１レコード作っていきます。「資産」テーブルでは、これまでの減価償却額を集計し、それをもとに簿価や当期の償却額を計算していきます。
もし、Appの作り変えなら
もし、これから作ろうとしているAppが、既存のモノの作り変えである場合、その既存のAppについては、忘れてしまいましょう。
その既存のAppがなく初めて作成するものであると考え、どのようにしたら、業務が最適化できるかを主体に、0から作っていきましょう。
