テーブル設計を理解していこう
それでは、まずはデータベースのテーブルから理解していきましょう。はじめに、皆さんの環境にサンプルデータが入ったデータベース環境を構築し、その後で資料と実際の環境を見比べていきます。
まずはデータベース環境の構築です。phpmyadminにアクセスし、［新規データベースを作成する］のテキストボックスに、データベース名「ec」を入れて［作成］をクリックしてください。
うまく動作した場合、画面左側に「ec」と表示されるので、上の［SQL］タブをクリックします。サンプルソースをダウンロードし、SQLフォルダ内にあるcreate_table.sqlの内容をコピーペーストして［実行する］をクリックします。
「SQLは正常に実行されました」と表示されたら、上の［SQL］タブをもう一度クリックし、同じ手順でサンプルソースのinsert.sqlを実行します。実行後、左側に4つのテーブル名が表示されます。
テーブル名の横のアイコンをクリックするとテーブルの中身が表示されるので、まずはどのようなレコードが入っているか、眺めてみてください。
データベースの中身を確認できましたか？ ではこれから、｢設計書｣と呼ばれるものに目を通していきます。「設計」とは、システム内部の構造のことです。そして、「設計書」とは、個人やチームでの理解の共有のために作成する資料で、データベースのカラム名などの決めごとや、画面遷移、各画面の詳細機能を記述したものです。
まずは、サンプルソースフォルダ内にある「ECテーブル設計書.pdf」を開いてください。この資料は、データベースのテーブルのカラム名や型などを記したもので、一般的にプロジェクトを進める際、このような資料を用意し、システム内部の構造をチームやお客様との間で共有します。
テーブル設計書は4ページで構成され、それぞれ以下のテーブルに関する設計情報が記述されています（以下文中の「主キー」に関しては第6回を参照ください）。先ほど作成したテーブルの中身と、資料の説明を読み比べながら、理解を進めていってください。
商品情報テーブル（m_items）
このテーブルに商品の情報を格納します。主キーは商品コードカラムで、商品コードを数値で格納します。商品を追加する場合、実際にはサイト管理者向けの画面より追加を行いますが、今回の連載ではそういった画面を用意しないので、直接INSERT文を実行して商品の追加を行う必要があります。その他、カラムに関していくつか説明を加えておきます。
- 「商品単価」カラム
- 「画像」カラム
- 「削除フラグ」カラム
商品単価を格納します。税抜きであることに注意しましょう。税込み金額をデータベースに格納した場合、消費税率を変更してデータベースのレコードをすべて入れ替えなければなりません。
実際の画像そのものではなく、画像のファイル名が格納されており、実際の画像はサーバ上にファイルとして格納されています。
このカラムに1が入っているレコードは、画面に表示されません。取り扱わなくなった商品は、もちろんSQLのDELETE文でテーブルより消去すればいいわけですが、それでは何かの手違いで消してしまった場合に元に戻せなくなります。そのような手違いも考慮して、こうしたカラムを持たせることで「事実上」の削除状態とします。このような削除の方法を「論理削除」と呼びます。反対にDELETE文でレコードそのものを抹消することを「物理削除」と呼びます。
会員情報テーブル（m_customers）
このテーブルには会員情報を格納します。初期状態で既にサンプルデータが入っていますが、実際には「会員登録」画面からのみ登録が可能です。「会員コード」カラムに関しても、説明を加えておきます。
- 「会員コード」カラム
主キーであり、重複があってはならないカラムです。この会員コードは、ログイン時のログインIDとしても使用します。
購入履歴テーブル（d_purchase）、購入履歴詳細テーブル（d_purchase_detail）
これら2つのテーブルは購入履歴を格納するテーブルで、cart.phpで［注文確定］ボタンクリック時にレコードが追加されます。購入履歴テーブルには購入情報のサマリー（誰が、いつ、いくら買ったか）を格納し、購入履歴詳細テーブルにその内訳の商品情報を持ちます。
これら2つのテーブルは、「購入ID」カラムで紐付きます。購入履歴テーブルの1レコードに対して、複数の購入履歴詳細テーブルのレコードが紐付きます。
購入IDカラムの番号は、データベースが自動的に採番（番号の割り当て）するようになっています。create_table.sqlで、d_purchaseテーブルを作成している部分を見てください。order_idの行が、
order_id bigint auto_increment
となっているかと思いますが、このようにauto_incrementというキーワードを型の後に付加することで、そのカラムに格納する数値を、1から順に、データベースが自動的に採番してくれます。
もしも、「会員コード」カラムや「購入日」カラムなどが重複の無い主キーになるのであれば、これらを用いて紐付けをしても構いません。しかし、同じ日に同じお客様が購入することは当然あるので、これらを紐付けに用いることはできません。そこでorder_idという重複の無い一意の番号を各レコードにつけることで、紐付けに役立てています。
その他、いくつかのカラムに関して説明を加えておきます。
- 注文履歴テーブルの「会員コード」カラム
- 注文履歴詳細テーブルの「商品コード」カラム
- 注文履歴詳細テーブルの「決済時商品単価」カラム
会員情報テーブルの「会員コード」を格納しておくカラムです。このように会員情報の主キーを格納しておけば、主キーを手がかりにお客様の住所・氏名なども照合できます。ただし、引越しなどでお客様の住所が変更になった場合、会員コードのみを保存しておく今回の設計では、引越し前の住所が分からなくなってしまいます。引越し前の住所も遡って調べることができるようにするならば、会員コードと併せて決済時の住所・氏名なども購入履歴テーブルに保存しておく必要があります。
商品情報テーブルの「商品コード」カラムを格納します。購入履歴テーブルの「会員コード」カラムと同様、商品名が購入後に変更になる場合もありますから、必要があれば別カラムを用意し、決済時の商品名も保持しておきます。
決済時の商品単価を税込みで格納します。商品情報テーブルには税抜きで保存していますが、こちらは税込みです。ここで税抜きで保存すると、将来的に消費税率が変わった際に決済金額を知るのが困難になります。
