第２４話テーブル設計について

エヌ・ケイ・カスタマイズの泉です。
前回は、ハウスキーピングな項目やフィールド名について説明しましたので、
それを踏まえて、『果物屋さんの売上管理カスタムApp』で必要なテーブルやフィールドを設計していきます。

以下の記事は、FileMaker Master Book 初級編（バージョン 19 対応）より、
「7.7 情報をテーブルにする 2（157ページ）～」を元に掲載しています。

この文献から、テーブルやフィールドの考え方、主キーや外部キーについて学びました。文献の執筆者、関係者の方々に深謝いたします。

なお、このブログ記事の趣旨は、弊社所属スタッフの FileMaker 学習の成果を公開することを目的とし、同時に、参考文献の内容の紹介に資するものであることを Claris International Inc. が確認しています。
Claris FileMaker 公式トレーニング教材

上図のような売上伝票からは、次の項目が考えられます。
＜売上伝票の項目＞
・売上日
・買ったお客様
・買われた果物の名前
・買われた果物の数量
・買われた果物の価格
・売上額
この内容に、ハウスキーピングフィールドを追加するだけでよいでしょうか？

1つのデータにする

前図を、よく確認します。伝票ごとに買われた果物の内容が、1 つだったり複数だったりしています。
つまり、一度の販売で1 つ以上の果物が買われているということです。
正規化で忘れてはいけないルールがもう1 つあります。レコードをユニークにする識別子と同じ考え方です。
1 伝票ごとに、買われた果物が１つでも複数でもデータが入力できるようにしながら、ある伝票で買われた果物を
1 つだけ取り出すせるように考える必要があります。初めは次のように考えます。

テーブルを2 つにわけるのです。
・伝票
・買われたもの＝明細

そして、どちらのテーブルにどの項目がついていくべきか、を見ます（「関係従属性」などと呼びます）。こんな感じです。

＜伝票テーブル＞
・売上日
・買ったお客様
・売上額
＜明細テーブル＞
・買われた果物名
・数量
・価格

これで「１回の伝票情報」レコードと「1 回で買われたものの、1 種類ごとの果物情報」レコードがそれぞれ作成できるようになりました。

しかし、このままでは「明細」テーブルのレコードは、どの「伝票」テーブルのものなのかわかりません。「リレーションシップ」が必要です。照合フィールドを追加します。

関連を定義する

これまでに、1 つのテーブルからユニークな1 レコードを取り出すことができる識別子として各テーブルに「主キー」という名前で設計しました。
多くの場合、識別子を照合フィールドとして指定してリレーションシップを定義します。そして、照合フィールドは「キー」と呼ばれます。大きく分けて2 種類です。

主キー
リレーショナルデータベースでは1 つのレコードを識別できるフィールドを関連の定義に使うことがほとんどです。これが「主キー」です。Primary Key とも呼ばれます。

外部キー
関連先のテーブルに関連元のテーブルの主キーを格納するための項目が必要です。「外部キー」と呼びます。外部キーからみた主キーは常に1 つです。Foreign Key とも呼ばれます。

売上伝票から「明細情報」を切り離すと、「伝票情報」が残ります。
そして、「明細情報」にとって「伝票情報」は、売上日、お客様の名前、売上額などの共通の内容です。