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

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

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

1つのデータにする

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


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


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


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


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

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

関連を定義する

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

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

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

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

次に、「主キー」と「外部キー」を使ってリレーションシップを定義し、「伝票」と「明細」の2 つのテーブル間に元の売上伝票と同じ関係が成立するようにします。

「明細」テーブルに外部キーを追加し、次のような関連が成立するようになりました。

・ 「 明細」テーブルから、どの「伝票」テーブルのレコードが関連レコードなのか(いつ売り上げた、どのお客様なのか)がわかる
・ 「 伝票」テーブルからは、1回の売上に含まれる「明細」レコードがすべてわかる

この関係のことを「親子」と呼んだりします。「伝票」テーブルが親、「明細」テーブルが子です。
レコードがつくられる順番同じです。先に売上日やお客様があって、果物が買われます。
なお、関連のための照合フィールドは1 つとは限りません。複数フィールドを指定することもあります。

複合キー
2 つ以上のフィールドのデータを計算式などで結合したフィールドを主キーにすることも可能です。
「複合キー」と呼ばれます。

まとめ

今回は、1まとまりの情報から、正規化を利用してテーブル、フィールド、関連の定義の作成を行いました。

終わりに

次回は、さらに掘り下げてテーブル設計を行っていきます。

Follow me!