正規化

1)初めに
今回はデータベースの正規化についてご説明させていただきたいと思います。前回に説明をしましたER図というのは下図の通り、各テーブルの設計ができてそれらを集めてきてテーブル間の構成を表したものになります。ちなみに「エンティティ」というのは「テーブル」のことをいいますし、「アトリビュート」というのは「テーブル内で定義される項目」の意味になります。

出典:http://it-koala.com/entity-relationship-diagram-1897

ER図というのはいきなり書くことが出来ません。まずは夫々のテーブルを設計するために、テーブルの正規化をしてもらってそこからER図を作っていくことになります。つまりは、ER図を作成する上でも正規化の知識は必須になるのです。

下図のように例えば、取引予定リストというような伝票があったとします。伝票は下図のようにExcelのような形でデータを整理していたり、紙媒体として管理されていたりします。これらのすでに存在する伝票から、管理する項目をリストアップしていくことから始めます。

出典:http://gomocool.net/gomokulog/?p=514

ただし、現在存在している伝票、帳票類のみから項目をピックアップしていくと、結果的に現状のデータを整理しているだけになってしまいます。もちろん、現状会社で使用しているデータを整理することは大変に有意義なことかと思いますが、こういう項目も管理できたりよりよくなるといった項目がある場合には、そのような項目もピックアップしていくとよいでしょう。

ピックアップされた項目から下図の通りデータの正規化を行い、さらに、正規化した結果を使ってER図という形でまとめていきます。

出典:http://gomocool.net/gomokulog/?p=514


出典:http://it-koala.com/entity-relationship-diagram-1897

テーブル設計を行っていく上でこの正規化はすごく重要な作業となります。

2)第一正規化
第一正規化は繰り返しの配列構造を無くします。具体的には、上図の取引先リストから、「取引番号」「取引予定日」「顧客コード」「顧客名」・・・などの項目を全部ピックアップしてそれを下図のように表形式として、横に並べます。

出典:http://gomocool.net/gomokulog/?p=514

上図の取引先リストはexcelで管理されていましたが、下図の売上伝票は典型的な紙媒体の伝票の例になります。「売上日」「得意先コード」などの項目はヘッダー部分に該当し、「商品コード」「商品名」は明細部分に該当します。

出典:http://www.kogures.com/hitoshi/webtext/db-seikika/

上図の伝票のデータ項目のピックアップの仕方によっては、下図のように「商品1」の「商品コード」、「商品2」の「商品コード」、「商品3」の「商品コード」というようにデータを取得してしまうかもしれません。第一正規化で繰り返しの配列構造を無くすとは、「商品1」の「商品コード」、「商品2」の「商品コード」、「商品3」の「商品コード」というような繰り返し項目をなくすという意味です。その結果、下図の下部分の図のような形とします。

出典:http://www.kogures.com/hitoshi/webtext/db-seikika/

次に、表形式に項目をピックアップした中で、どの項目を主キーにするかということを検討しなければなりません。主キーとは1行を特定できる項目です。具体的には下図の中では、取引番号と明細番号となります。(取引番号は濃い青で明細番号は明るい緑の箇所です。)ちなみに明細番号というのは行番号を表しています。「1行を特定できる」とは、取引番号の値と明細番号の値が分かると下図の表の中で特定の1行を指し示すことが出来るということです。

出典:http://gomocool.net/gomokulog/?p=514

その結果、取引先リストのヘッダー項目である「取引番号」「取引予定日」「顧客コード」「顧客名」は同じ値となっています。そのことを「無理くり同じ項目が来ている」と表現しているわけです。テーブルの中でどの項目が主キーかということは、非常に重要なので、テーブルを見るときは、常にどの項目が主キーかを意識するようにして下さい。

2)第二正規化
第二正規化というのは、主キーを構成するキーの一部が部分関数従属しないようにテーブルを分離します。具体的には、先ほどの取引先リストで「取引番号」項目と「明細番号」項目が主キーとなりました。その場合の一部とは、「取引番号」項目であり、「明細番号」項目を指します。さらに「部分関数従属しない」とは「取引番号」項目の値が決まればそれで特定できる項目がないのか、あるいは「明細番号」項目の値が決まればそれで特定できる項目がないのかを探すということです。

「取引番号」項目が決まると、「取引予定日」「顧客コード」「顧客名」が決まりますので、この部分を分離するのが、第二正規化となります。

出典:http://gomocool.net/gomokulog/?p=514

3)第三正規化
第二正規化で主キーの一部で決まるものを別のテーブルにしましたが、第三正規化では主キー以外の項目で部分関数従属しないようにテーブルを分離します。例えば下図の「取引予定」テーブルにおいて主キーは「取引番号」です。(下図の赤丸部分が該当箇所です。)

出典:http://gomocool.net/gomokulog/?p=514

取引予定」テーブルの主キーではない項目とは、「取引予定日」「顧客コード」「顧客名」「合計」項目が該当します。主キーではない項目で「部分関数従属」とは、「顧客コード」項目の値が決まったら「顧客名」項目の値も決まります。あるいは、「取引明細」テーブルの中で主キーは「取引番号」項目と「明細番号」項目ですが、主キーではない項目で、「商品コード」項目の値が決まったら「商品名」「商品単価」項目の値が決まります。

テーブルを分離する時に気をつけないといけないのは、下図のように「取引予定」テーブルから「顧客」テーブルを分けたときに、「取引予定」テーブルに「顧客コード」項目を残しておかないと、そもそも「取引予定」テーブルと「顧客」テーブルに関連があったという事実が失われてしまいますので、注意が必要です。

出典:http://gomocool.net/gomokulog/?p=514

「商品」テーブルについても同様です。「取引明細」テーブルから「商品コード」項目を削除してしまうと、「取引明細」テーブルと「商品」テーブルが関係しているという繋がりの項目がなくなってしまうので、注意が必要です。

出典:http://gomocool.net/gomokulog/?p=514

テーブルとテーブルの関連性というのは下図のER図でいうとエンティティ間を繋ぐ線のことです。つまり、下図の左上の「顧客」マスタ内に「顧客ID」という主キー項目があり、その右横に「注文」テーブルの中に「顧客ID」という項目があります。テーブルを結合するためには関連する項目が必ず必要となります。

出典:http://it-koala.com/entity-relationship-diagram-1897

4)主キーを補う
下図ではここで第一正規化で主キーを「年月日」項目、「得意先名」項目、「商品コード」項目としています。

出典:http://www.kogures.com/hitoshi/webtext/db-seikika/

この場合、同じ年月日に同じ得意先から同じ商品の注文はないという前提となっています。業務的にその企業では同じ日に同じ得意先から同じ商品の注文はないのかもしれませんが、それは会社の業務内容に依存します。例えば、午前中に発注が来て、午後からも同じ商品が発注が来たという場合には、この主キー設定は正しくないということになります。つまりすでに存在している項目だけから正規化していくと必ずしも良くない主キーを設定してしまうことになる場合があります。

この時は、「売上番号」という項目を売上ファイルに新規に追加してやり、売上番号を主キーにすることで問題が解決します。同様に明細に関しても、「商品コード」項目を主キーにしても業務的に問題ない場合もありますが、これだと同じ伝票内に同じ商品を複数登録できなくなってしまいます。その場合には、「明細番号」という項目を新たに追加することで解決します。

出典:http://gomocool.net/gomokulog/?p=514

実際紙伝票などで管理していると、「売上番号」だとか「明細番号」といった項目は定義されていない場合があります。その場合は項目を補ってテーブル設計していく必要があります。

出典:http://www.kogures.com/hitoshi/webtext/db-seikika/

5)おわりに
データベースの設計およびテーブル設計というのはexcelなどのデータや紙伝票からデータをリストアップした後、第一正規化、第二正規化、第三正規化と順をおって作業を進めていきます。それぞれの作業手順としてはそれほど複雑なものではありません。しかし、実際に使いこなすには色々と演習問題などを行いながら手法に慣れていくことが重要です。


弊社は、主に中小企業様向けの業務システム開発ホームページ制作パソコンサポートコンサルティングなど、ITに関する様々なサービスを格安で提供しております。
特に小規模な業務システム開発の分野では、主にAccess(アクセス)を利用した柔軟で効率的な開発を得意としており、関西でダントツの実績があります。

業務システム開発に関しては、以下のような内容で対応しております。
・顧客管理などの単機能なシステムは20万円~50万円が多い。
・受注から入金まで業務全体システムで100万円~350万円ぐらいが多い。
・Access(アクセス)-SQLserverで大規模システム開発は350万円~1500万円が多い。

詳細は、Access(アクセス)、Excel(エクセル)、WEBサイト製作による小規模システム開発のページをご参考ください。

大阪商工会議所からの推薦を受けて、中小企業庁運営の中小企業支援事業に専門家として登録されました。
通称ミラサポ。3回まで無料でのコンサルティングが可能です。ご興味がある方はご連絡ください。
https://www.mirasapo.jp/


(近畿大学にて非常勤講師も務めたバリバリの技術屋が経営する会社)

Access(アクセス)Excel(エクセル)SQL server バーコード Webシステムを使った業務システムのシステム開発の無料相談を受付中

株式会社 アイライト 担当:内藤 響(Naito Ko)
〒550-0005 大阪市西区西本町1丁目5番9号 日清ビル 5F
(四つ橋線 本町駅 24番出口すぐ)
まずは、メール・電話でご相談ください。
TEL : (06) 6599-8890 E-mail : info@ai-light.com
お電話が混んでいる場合が多いので、つながりにくい場合は
TEL : (06) 6535-5117までお願いします。


株式会社アイライト公式HP
https://www.ai-light.com/
(Access・Excelでシステム開発会社を探されている法人様はこちら)

Access・Excelに関する情報を掲載(Access・Excel倶楽部)
https://www.ai-light.com/accessclub/

ITでお困りのことがございましたら、まずはご相談(コンサルティング)
https://www.ai-light.com/itconsulting.html

格安ホームページ制作所
https://www.ai-light.com/hp2

YouTubeチャンネル(無料動画配信中)
https://www.youtube.com/user/ailightcom

ニコニコチャンネル(月額固定で見放題)
http://ch.nicovideo.jp/ai-light