セブンイレブンのレシートから第三正規形を求める

##ことの発端
近くのコンビニに立ち寄り色々買ったあと、寒空の下レシートを見ながら歩いていたら、レシートからわかる情報で正規化してみたいと思い実践したので、その時のことを記事にします。

## 正規化とは
正規化とは、データの整合性を保ったまま冗長性をなくし、データを効率的に管理するためにテーブルを分離していくことです。
簡単に言えば、**データを使いやすいように整理したり変形したり分割したりすること**です。
より具体的に述べると、RDBを利用する際にオリジナルのテーブルの関連性を失わないように項目を整理して、複数のテーブルに分離することになります。
正規化をすることで、データの更新や削除が非常に容易になるだけでなく、スキーマの理解がしやすくなり、データを効率的に管理できるようになります。

### 正規化の手順
正規化には第一正規化から第五正規化までの5段階の手順があります。
しかし、一般的に利用されるのは**第三正規化**までになります。
正規化されていない状態を**非正規形**と呼び、第一正規化された状態を**第一正規形**、第二正規化された状態を**第二正規形**、第三正規化された状態を**第三正規形**と呼びます。
一連の流れを横軸にすると以下のような状態になります。

<img width="513" alt="Screen Shot 2018-11-04 at 4.05.53.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/338a13e4-a2d2-fc93-5ee9-15744da7dc15.png">


それぞれの手順でどのようなことを行うかを記載すると、それぞれ以下の様な状態を目指します。
**第一正規化**→繰り返し項目を分離して独立した行にする。
**第二正規化**→主キーが決まればひととおり決まる項目を取り出し、表を分離。
**第三正規化**→主キー以外の項目間に従属関係があれば、それらを取り出して表を分離。

##使用するレシート
今回使用するレシートは以下のものを使用します。
![Scan.jpeg](https://qiita-image-store.s3.amazonaws.com/0/255007/70500a04-9be0-2e45-6094-c59dca60f1bc.jpeg)

##項目の確認
上記のレシートを見ると以下の様な情報があると思います。（全項目については今回は対象としません）
* 一枚のレシートの中で繰り返し登場する項目は```(繰り返し)```と記載しました。

* 店舗名
* 住所
* 電話番号
* 日付
* 商品名 (繰り返し)
* 単価 (繰り返し)
* 数量 (繰り返し)
* 合計金額

このレシートから読み取れる訳ではないのですが、今後必ず必要となりそうなものを先に用意しておこうと思います。
必要となりそうな項目は以下の様なものがあると予測します。(あくまで予測ですが、必要なはずです)

* レシートID
    * 受注番号の様に一度の買い物を一括りとできる識別番号
* 店舗コード
    * 店舗名や住所を紐づける為の識別番号
        * これがないと店舗名が変わった場合に、変更対象の該当するレコード(レシート)の分だけ店舗名を変更するUPDATEをかけなければいけなくなります。
* 商品コード
    * 商品を紐づける識別番号
        * これが必要な理由は店舗コードと同様の理由です。

##上記の項目をエクセルにまとめる
レシートのままだとどうにもやりにくいので一旦スプレッドシートにまとめました。

レシートに記載されている項目を一つの枠としてそのまま以下の様に記入しました。
<img width="1089" alt="Screen Shot 2018-11-04 at 15.40.15.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/edc52561-fd2e-02fc-69e8-4927f1ffaf7d.png">

オレンジ色になっているところは今回私が適当に当てはめたものになります。
ここからはスプレッドシートを使ってデータを扱っていきます。

##非正規形
上記に示した状態が正規化を行う前の状態、つまり非正規形の状態です。
一つのレシートに記載されている内容がそのまま一つのレコードとして保持されています。
今のままだと以下の問題点があります。

1. データが冗長的すぎる
   * 例えばレッドブルの単価が変わったとき、レッドブルが含まれている注文データ全てを更新する必要がある。
2. データの整合性が保たれていない
    * もし新たにレッドブル2という商品が追加されたとしても、レッドブル2が購入されない限り、レッドブル2はデータベースに保存されないので存在しないことになってしまいます。
    * また、購入されたレシートが1件しかない場合、データが削除されてしまうと、その商品の存在が消えることになってしまいます。

上記の問題は一つのレコードに対して、**いくつもの事実が記録されている**ことが問題になっています。

##第一正規化
非正規形の問題点は上記にてお伝えした通りです。その問題点を解消するために正規化を実施していきましょう。

まず正規化の第一ステップとして第一正規化を行います。
第一正規形は**1レコード1事実**にします。

どのようなことをするかと言うと、**繰り返し項目をなくす**ことを目標とします。

そのために行うこととして、繰り返し項目を含まないようにレコードを分割し、**主キー**を見つけます。
**主キー**とは、行に対する一意の値をもった属性です。
主キーがわかれば他の項目も紐づくようにわかるものが主キーとして設定されます。

今回の場合でレコードを分割し、それぞれ主キーを決定すると以下の様になると思います。
<img width="1026" alt="Screen Shot 2018-11-04 at 15.40.30.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/39c92223-5c52-c403-83a3-fc725d54ff44.png">

背景が赤色の項目を主キーとしました。
上記の例だとレシートIDと商品コードが主キーとなります。
繰り返し項目となっていた商品コード、商品名、単価、数量を別レコードとして分割しました。

繰り返し項目を排除したことで、第一正規化は完了です。
上記によって求められた形が第一正規形です。

##第二正規化
続いて第二正規化を実行していきます。
第二正規化は**部分関数従属の排除**をします。

つまり、**主キーが複合キーになっていて、その部分キーに関数従属がある場合、これを別テーブルに分離**します。

**複合キー**とは、購入詳細テーブルのレシートIDと商品コードのように、行の内容を決める一意の値が複数ある場合にそれらの総称です。

また、上述したような部分キーに関数従属がある様な状態のことを、**部分関数従属**と言います。

つまり第二正規化では複合キーがあるテーブルにおいて、いずれかの部分キーによって関数従属しているものを別テーブルとして切り出すということです。

今回の場合だと、まず第一正規形から複合キーに関数従属する要素をテーブルに切り出して、そのテーブルを購入詳細テーブルとし以下の様なテーブルにします。
>
**テーブルを分割する際には、リレーションを保持するために他のテーブルと共通する項目(今回であればレシートID)がそれぞれのテーブルにも必要**となることです。
このようなキーを**外部キー**といいます。

そして、切り出された購入詳細テーブルのうち部分キーの商品コードが商品名と単価の関数従属しているので、こちらを別テーブルとして切り出すことになります。
<img width="426" alt="Screen Shot 2018-11-04 at 15.45.10.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/7e1f7807-da3c-447f-7bb5-d9e1ae3f3ef0.png">


この様に部分関数従属性をもった要素を別テーブルに切り出す第二正規化を行うと以下のような第二正規形を生成することができます。

<img width="1080" alt="Screen Shot 2018-11-04 at 15.48.48.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/0311437b-7dd4-b743-2798-8b8133d08137.png">



##第三正規化
第3正規化では主キー以外の項目によって一意に決まる項目を別表に移します。
今回のポイントは推移的関数従属になります。
第三正規化は、推移的関数従属している項目を別テーブルに切り出します。
**推移的関数従属**とは、Aの値が決まるとBの値が決まり、Bの値が決まるとCの値が決まるという関係で、CはAに推移的に関数従属していると言えます。
今回の例で言うと、購入テーブルのレシートIDと店舗コードが該当します。
<img width="552" alt="Screen Shot 2018-11-04 at 15.45.28.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/8aa8a8d6-d043-bd2a-ed9f-68b4d6180fad.png">


レシートIDが決まることで店舗コードが決まり、店舗コードがわかることで店舗名や住所が決まるといった具合です。

つまり、店舗コードにより関数従属している項目が第三正規化の対象となります。
また今回の正規化では、**導出項目**を削除します。
**導出項目**とは、計算によって求められるもののことを言います。今回の例で言うと、合計金額が導出項目に当たります。
<img width="552" alt="Screen Shot 2018-11-04 at 15.45.28 copy.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/6204a489-bd15-6845-4294-01c73428223e.png">


以上の第三正規化によって推移的関数従属性を別テーブルに切り出し、導出項目を削除した第三正規形は以下のようになります。
<img width="1097" alt="Screen Shot 2018-11-04 at 15.41.08.png" src="https://qiita-image-store.s3.amazonaws.com/0/255007/b96f3c0a-57cc-fb53-b3c6-f12aa47b18b0.png">

これにより正規化を終了することができました。
この後にも第五正規形が続いていくのですが、一般的には第三正規形までを求めることになると思うので、今回はここで正規化を終了します。


##終わりに
思いつきではありましたが、無事にセブンイレブンのレシートから正規化を実行することができました。正規化について勉強し直すきっかけにもなりましたので、非常に有意義でした。
理論として学ぶことのおおい正規化ですが、実際のデータを使って実践的に学ぶのは非常に面白かったです。

間違い等ございましたら、ぜひご指摘いただけるとありがたいです。
ありがとうございました。
(コンビニで買いすぎていることをかなり反省します)

####謝辞
第一正規化についてご指摘いただいた@mamu_taさん,
ありがとうございました！