第２２話　テーブル設計（正規化）

エヌ・ケイ・カスタマイズの福山でございます。今回はテーブルの設計について、そもそも、テーブルやリレーションシップの定義は、どうやって考えるのでしょうか。
データを希望通りに利用できるようなテーブルと、そのテーブル同士のリレーションシップの定義の概要を考えることを「データベース設計」とか「データモデリング」などと呼びます。 大変興味深いテーマですが、私からは、ほんの少し基本的な考え方の正規化についてお話させて頂きます。

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

この文献から、テーブルの考え方、データの正規化について学びました。文献の執筆者、関係者の方々に深謝いたします。

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

Claris FileMaker 公式トレーニング教材

手書き感覚で気軽に
設計は、紙に書いたり、絵が描けるソフトウエアでおこなうほうがやりやすい作業です。リレーションシップグラフでの操作と設計は違うものです(設計に従ってリレーションシップグラフができると考えてください)。

テーブルをつくらないとリレーションシップグラフにテーブルオカレンスは現れません。しかし、 設計時にはテーブルは分裂したり統合したり現れたり無くなります。ですから自由なツールを利用する方が合理的です。

データモデリング
データを整理整頓してデータベースで利用できるようにすることです。データモデルの1つとしてリレーショナルデータモデルがあります。Claris FileMaker はリレーショナルデータベース管理システム（RDBMS）ですから、このモデルで考えていきます。

正規化
データモデリングの中で、データを必要に応じてテーブルに分けて関連付けるための作業のことを 「正規化」と呼びます。この作業の目的はデータを効率良く管理できるようにすることです。

情報をテーブルにする
正規化をごく簡単に解説します。テーブルオカレンスの元である実体テーブルを決めていきます。構造の設計に焦点をあてて解説しますので現実味が薄いことがあるかもしれませんがテーブル作成の考え方ととらえてください。簡単なもので考えてみましょう。

果物屋さんの売上管理カスタムApp

をつくります。こんな事情があるとしましょう。
・ 売上を管理したい。
・ なにが売れているか、誰が買ったか知りたい。
・ 売上伝票には買った人や売れた商品の産地や品種を明記するように努めている。
・ 売上金額に従ってスタンプを押す会員カードがありカード作成時の会員の情報がある。

ここから考えられるカスタムAppの役割は次のようなものがありそうです。
・ 売上を記録。
・ 商品情報を管理して売上と関連させる。
・ お客様情報を管理して売上と関連させる。

ここから考えていきます。

なんの情報のあつまりか
これまでに何度も述べて来ましたがテーブルはデータの集まりです。どのようなデータが集まって テーブルになるのでしょうか。とりあえず集めてきたデータは……

・ 青森県のリンゴ、品種は富士
・ 東京都在住の山田 太郎さん、1983/1/5 生まれ
・ 宮崎県のバナナ、品種はもっちりバナナ
・ 埼玉県在住の佐藤 花子さん、1976/3/7 生まれ
・ 愛媛県のミカン、品種は甘平

どうも情報が混ざっているようです。特性を考えて同じものに分けます。

<人(顧客)の情報>
・ 東京都在住の山田 太郎さん、1983/1/5 生まれ
・ 埼玉県在住の佐藤 花子さん、1976/3/7 生まれ

<果物の情報>
・ 青森県のリンゴ、品種は富士
・ 宮崎県のバナナ、品種はもっちりバナナ
・ 愛媛県のミカン、品種は甘平

大きく分けて 2 種類になりました。
テーブルを考えるときには、このように取り扱うデータが『なにかの情報の集まりに分けることができるかどうか』を見極めることが、はじめの一歩です。

当然ですが果物と人は違います。ですから違うテーブルにしたほうがよさそうです。

誰でもここまでは意識せずに自然にテーブルを設計していることが多いはずです。現実にある物事を元に作成することがほとんどですから、その概念を当てはめることができるのです。ここでは、紙に書いて設計していると仮定して四角形を書いてテーブルを表現します。

どのような項目ののあつまりか

テーブルとは、列と行です。つまり表です。テーブルはデータの集まりでデータはフィールド(= 項目)の集まりです。いくつの項目になるでしょうか。例えば、次のデータから考えると、

・ 東京都在住の山田 太郎さん、1983/1/5 生まれ
・ 青森県のリンゴ、品種は富士

データの内容を端的に表すような項目名を考えると、それがフィールド名になります。ほとんどの項目名は自然に浮かんできます。それぞれ3つのフィールドになりました。もうテーブルっぽくなりましたが、さらに考えることがあるのです。

ユニークなレコードにする
違う視点からデータを見ます。

データベースの原則では 1テーブルの中に同じ、つまり重複するレコードがあってはいけません。なぜなら1レコードだけを取りだせないと不便だからです。
重複しないレコードのことを「ユニークなレコード」と呼びます。ユニークとは一意、つまり、唯一のという意味です(普段は、面白い、変わっている、などで使用されることが多い言葉ですがデー タベースの世界ではこのように使います)。
先ほどの「人」テーブルのフィールドは、ユニークという立ち位置から考えるとどれも望ましくあり ません。

・ 同じ都道府県に住んでいる ・ 同姓同名
・ 誕生日が同じ

という人は十分にありえます。データベース化されていなくても、同じように考えて顧客や商品をユニークにするために管理用のコードをつけることがあります。

専用のフィールド
テーブルに対して『ユニークにできるフィールドがあるかどうか』を毎回考えるよりも、あらかじめユニークにするためのフィールドを加えてしまうほうが便利です。

ユニークにする識別子
手軽にユニークにするには、重複しない数値などを自動入力します。この項目はテーブルの中で レコードをユニークにする「識別子」となります。

※「ID」フィールドという名前をつけることもあります。IDは、英語のidentIfier(=識別子)の略称です。 リレーションシップにおける「キー」の考え方から「主キー」という名称を使います。
「人」と「果物」の両方に識別子を加えます。

重要なことですが、この項目は空白なレコードがあってはいけません。必ず空欄不可で設計します。 データが入力されていないと識別子としての役目を果たせません。
このように、データをテーブルにわけて関連づけていくことを正規化と呼び、テーブル設計においてまず重要な作業になります。
今回は、テーブル設計の正規化という考え方について少しご紹介しました。また、次回もよろしくお願いいたします。

参考文献：Claris FileMaker 公式トレーニング教材　から、「FileMaker Master Book 初級編」　等を参考にしています
https://content.claris.com/fmb19_reg-ja