データベースの正規化
いわずと知れた作成するアプリケーションの設計である。これがないと始まらないというのが本来あるべきものではあるが、このようなしちめんどうくさい作業をちゃんと行ってから作業を開始したほうが後々宵のである。
多くのFileMakerユーザーは、せっかく作った便利で高機能なアプリケーションであっても、作成した人にしか内容が判らす、やがて本人も忘れてしまい、やがてメンテナンス不能となり....といった自体になって行くケースをよく見てきだが、そうならないよう、きちんんとした経緯をここに示してゆくことにする。
これも今回の試みである。
テーブル構造と正規化
※ 適切な正規化が行われたテーブル構造は、使用時のパフォーマンスを向上させます。また、データ量を最小限に抑え、データの重複を防ぐ効果もありますので、正規化はぜひマスターしておいた方が良い規則です。
正規化とは、全テーブルのデータを分析し、効率化されたリレーションを作成するための規則です。

例えば以下のようなテーブルがあるとします。
受付テーブル (非正規形のテーブル)
受付日
患者ID
性
名
名前
住所
診療科
医師名
2005/03/01 P1 東京 太郎 東京 太郎 ○県A市 内科、外科 徳川(内科D1)、豊臣(外科D2)
2005/03/02 P3 福岡 一郎 福岡 一郎 ×県B市 内科 織田(内科D3)
2005/03/03 P4 青森 花子 青森 花子 △県C市 小児科、外科 明智(小児科D4)、豊臣(外科D5)
第一正規化
　第１正規化の規則は、「すべての属性が異なった値をもっている」です。具体的には、非正規形のテーブルに対し、各枠に複数の事柄をいれるのをやめます。そうすると次のようになります。
受付テーブル(第一正規化-1)
受付日
患者ID
性
名
名前
住所
診療科
 医師ID
医師名
2005/03/01 P1 東京 太郎 東京 太郎 ○県A市 内科 D1 徳川
2005/03/01 P1 東京 太郎 東京 太郎 ○県A市 外科 D2 豊臣
2005/03/02 P3 福岡 一郎 福岡 一郎 ×県B市 内科 D3 織田
2005/03/03 P4 青森 花子 青森 花子 △県C市 小児科 D4 明智
2005/03/03 P4 青森 花子 青森 花子 △県C市 外科 D5 豊臣

導出フィールドがある場合、それを排除します。
　『導出フィールド』とは、他のフィールドから値を算出することができるデータのことです。たとえば名前フィールドの値は、姓と名フィールドを結合すれば得られます。この名前フィールドのような列を、導出フィールドと呼びます。正規化を行う際は、このような余分なフィールドを削除する必要があります。
受付テーブル (第一正規化-2)
受付日
患者ID
性
名
住所
診療科
 医師ID
医師名
2005/03/01 P1 東京 太郎 ○県A市 内科 D1 徳川
2005/03/01 P1 東京 太郎 ○県A市 外科 D2 豊臣
2005/03/02 P3 福岡 一郎 ×県B市 内科 D3 織田
2005/03/03 P4 青森 花子 △県C市 小児科 D4 明智
2005/03/03 P4 青森 花子 △県C市 外科 D5 豊臣
一つのの枠に配列（繰り返し）をいれないことが第１正規形です
第二正規化
上記の第１正規形のテーブルのうち，患者IDから性･名・住所が決まります。また，診療科+医師IDから医師が決まります。このようにキーとなる列の値が決まれば、他の列の値が決まるようにテーブルを分割した状態を第２正規形といいます。
この例でいくと、患者テーブルと医師テーブルが分割できそうなので、以下のように２つの別テーブルを作成します。
患者テーブル
患者ID
性
名
住所
P1 東京 太郎 ○県A市
P2 福岡 一郎 ×県B市
P3 青森 花子 △県C市
医師テーブル
医師ID
診療科
医師名
D1 内科 徳川
D2 外科 豊臣
D3 内科 織田
D4 小児科 明智
D5 外科 豊臣
患者テーブル及び医師名テーブルを分割したので、受付テーブルにはキーとなる項目だけ残しておきます。
受付テーブル
受付日
患者ID
診療科
 医師ID
2005/03/01 P1 内科 D1
2005/03/01 P1 外科 D2
2005/03/02 P3 内科 D3
2005/03/03 P4 小児科 D4
2005/03/03 P4 外科 D5
第三正規化
主キーとなる列以外の値によって、他の列の値が決まることがない状態にテーブルを分割した状態をいいます。推移的関数従属関係である部分を、別テーブルに分割するということです。 この場合受付テーブルには 同じ受付日で同じ患者の受付レコードが存在します。これを第３正規化によって正規化するには。受付IDを作成した受付テーブルを作成し、新たに来院履歴テーブルを作成すれば第３正規化が行えます。
受付テーブル
受付ID
受付日
U1 2005/03/01
U2 2005/03/02
U3 2005/03/03
来院履歴テーブル
受付ID
患者ID
診療科
 医師ID
U1 P1 内科 D1
U1 P1 外科 D2
U2 P3 内科 D3
U3 P4 小児科 D4
U3 P4 外科 D5
患者テーブル
患者ID
性
名
住所
P1 東京 太郎 ○県A市
P2 福岡 一郎 ×県B市
P3 青森 花子 △県C市
医師テーブル
診療科
 医師ID
医師名
内科 D1 徳川
外科 D2 豊臣
内科 D3 織田
小児科 D4 明智
外科 D5 豊臣
実は、第3正規化は常に実用性があるとは限りません。たとえば、患者テーブルに都市、電話番号、性別、利用頻度などを登録するような場合、それら全てを別個のテーブルに作成する必要があります。もし本当に別テーブルに切り分けるとしたら、小さいテーブルを数多く作成することになり、パフォーマンスや作業効率の低下を招きます。
　第3正規形は、テーブルの利用形態などをじっくりと考えてから、データの変更頻度や重要度によってケース・バイ・ケースに適用するのが現実的です