SQLServer2017を使って正規化やテーブル設計をわかりやすく解説！4

前回までで，SQLServerのインストールからテーブルの作成。さらにはSQL文を使ってデータの登録や検索更新登録などが出来るようになりました。今回はその知識をもとに1つのシステム開発をしてみます。システム開発なんていうと身構えてしまうかもしれませんが実際の開発現場で使用するデータ設計，正規化などをわかりやすくかみ砕いて説明していきますので早速やっていきましょう！

注文管理システムを作ってみる

それでは，これまでは基礎的なことをやってきましたので，ここからは，実際の現場でSQLがどのように使われるのかを見ていきましょう。例えばお店の顧客が買ったものを管理するシステムを作るとします。その場合はどのようなデータが必要でしょうか？まず顧客を管理する場合，顧客情報が必要です。顧客情報に何が必要かはそのお店によって異なりますが，顧客から入手できる情報はすべて保存する必要があります。例えば，名前，住所，電話番号，生年月日，カード番号等．．．

これらを顧客テーブルとして定義します。そして，顧客を特定するために，キーも必要です。重複しないものなら何でもよいのですが，名前は重複したり，電話番号も家族で一緒だったり，変化する可能性があるのであまり使いません。こういう場合は通常「顧客ID」などをシステムで採番して重複しないように割り当てます。

顧客情報以外では何が必要でしょうか？顧客が何を買ったかを管理するのであれば，買ったものの情報が必要になります。「注文テーブル」としておきましょう。注文テーブルには，顧客が買ったものを覚えておくようにします。日時，商品名，金額などです。

どんなテーブルがいるかを考えてみる

いま，どんなデータが必要かを簡単に洗い出しました。まとめてみましょう。

※表の一行目はテーブル名です。

電話番号とカード番号は省略しました。

とりあえずこんな感じです。注文テーブルにはキーとして注文Noをいれて，だれが買ったかがわかるように顧客IDを入れています。このテーブル設計でもシステムは作れなくはないですが，注文テーブルは良い設計とは言えません。

例えば，商品を同時にいくつか買う場合，商品ごとに行が必要になります。

これだと，注文Noは別なのに，実際は一度に購入しているのであればうまく表現できていません。日時や顧客IDは無駄に記憶エリアが必要になります。合計の350円も表現できていません。そこでこういったことにならないように正規化ってものを行います。

正規化って何なのだろうって思ってみる

正規化とはデータベースに保存するデータは，重複なく，不足なく，管理できるように設計することです。例えば先ほどの注文データ2件の場合，2件の購入タイミングが同じで，日時が間違えていることに後から気づいた場合，2件のデータを修正する必要があります。修正漏れが発生するリスクがあります。それに，先ほども申した通り，日時や顧客IDが無駄に重複しています。このようなデータはメインのデータと，繰り返し項目のデータの2つに分けます。

この場合メインとは，商品をいくつ買おうと変化しないものとなるので「注文No」「日時」「顧客ID」です。商品はいくつ購入されるかわからないので繰り返し項目として扱います。「商品名」「金額」

まとめると

金額は単価に変更しました。あと，注文と注文明細のつながりがわからなくなるため，注文Noを挿入し，キーが重複しないように注文明細Noを追加しました。注文Noと注文明細Noでキーとします。（キーは複数項目でも可能です）