データベース設計
ここでは「テーブルとリレーション」で示したデータベース（売上DB）の設計に関しての補足的な話を進めていきます。通常、データベース（DB）を設計を考える際には、業務上の実際の書類（ここでは「売上伝票」）や扱いたいデータ形式（ここでは「商品売上データ」）を元に設計していくことになります。しかしDB設計の観点では、これらのほとんどがデータの保存や活用に適した形をしていません。ですので、仮にそのままの形でDBに保存してしまうと、他の集計や他の業務で使用できないようなデータとして保存されてしまいます。それではデータベースを使う意味がありませんので、DB設計においてはデータ項目間のまとまりやデータ同士のつながりについて分析し、データ本来の姿で保存するためのテーブルやリレーションを考えることになります。
とはいうものの、まずはそんなに難しく考えずにやってみましょう。通常、売上集計と言われると「売上伝票」を集計して「商品売上データ」を作成します。ということは、「売上伝票」のデータから「商品売上データ」を加工、修正して作れるようにテーブルやリレーションを考えれば良いわけです。そこで「売上伝票」がどういうデータから出来ているか考えます。
まずは売上伝票には伝票１枚ごとの情報として伝票Ｎｏ、日付、メモといったものがあります。あと消費税率も伝票を作成した日付に応じて決まってくる隠れた項目として考えられます。その売上伝票１枚の中に売り上げた各商品ごとの明細情報（売上伝票明細）が複数商品分記載されています。各商品情報には商品名の他に売り上げた時点での商品単価や数量も記載されます。これにより、売上伝票のデータのテーブルと売上伝票明細のデータのテーブルがあって、伝票ごとに割り振られている伝票Ｎｏで連結（リレーション）しているということが分かります。このとき、消費税率や商品単価はその時々によって変わる性質がある、時系列の要素のある項目であることにも注意しておいて下さい。また、商品には管理用の商品コードやその名称、現時点での単価といった情報があることが想像できますので、商品のデータのテーブルも必要でしょう。このようにしてまずどういうデータを取り扱うテーブルが必要かを考え、次に各々のテーブルに関して必要な項目を見つけていきます。このように、業務が理解できていればテーブルやりレーションは直感的な発想で大枠を設計することができます。
テーブルやリレーションの大枠の設計が終わると正規化を行います。正規化とは複数のテーブルに同じ意味の項目がある場合は適切なテーブルにのみ持たせるようにしたり、１つのテーブルに同じ意味で名前が異なる項目が複数ある場合は別のテーブルに切り出したりしてデータベースのスリム化を行うことです。正規化には理論があり、第一正規形から第五正規形までありますが、通常は第三正規形程度まで正規化します。（正規化理論についての難しい話しはここでは割愛しますが、データ項目の関連を見直したり、重複項目を排除すると第三正規形かそれに近いものになります。）
正規化はしすぎると処理速度が低下するので、正規化の後、状況に応じて非正規化して同じ意味の項目を複数のテーブルに持たせ直したりもします。正規化や非正規化については若干難しい部分もありますが、業務を十分に理解した上ででてくる大枠的なテーブルは自然と適度な正規化と非正規化がなされている場合も多いので、自身が使う業務アプリケーションのDB設計の際には、それほど神経質にならずに進めてみるのもいいでしょう
このようにして「データの性質」に基づいて設計されたテーブルやリレーションはさまざまな業務に向けて加工、集計できるようになります。業務用アプリケーションにおいてはDB設計の良し悪しは機能の柔軟性や拡張性に大きく作用するため、アプリケーション設計より先にDB設計をある程度しっかりしておくことをお奨めします。こういった具合にデータから着目してアプリケーション全体の設計を進めていく手法をデータ思考アプローチ（DOA）と呼びます。
DB設計において、テーブルとリレーション（テーブル間のつながり）を示す図として「ER図」というものを使います。Eはエンティティ（テーブルのことです）、Rはリレーションの頭文字です。売上DBの場合、リレーションは商品マスタと売上伝票明細データは商品コードで、売上伝票データと売上伝票明細データは伝票Ｎｏで連結されます。下記に売上DBのER図を示します。
（ER図）
まず、売上伝票データの伝票Noと売上伝票明細データの伝票Noがリレーションしています。売上伝票１枚に付き、その明細にはn行のデータがあるので、売上伝票データと売上伝票明細データは1対n結合ということになります。また、商品マスタの商品コードと売上伝票明細データの商品コードがリレーションしています。商品は複数の売上伝票に載ってきますので、商品マスタと売上伝票明細データも1対n結合となります。DBの設計を考える上ではどの項目がリレーションするのか、また、テーブルの結合対比はどうなのかということがとても重要になります。ちなみにテーブルの結合については1対0結合、1対1結合、1対n結合、n対n結合などがあります。
また、テーブルには用途によって大きく３種類に分けることが出来ます。
- マスタテーブル
- 主キーとして独自のコード体系を持ち、他のテーブルに参照されることになるテーブルです。時系列要素を含まないことが多いです。
- データテーブル
- 主キーとして独自のコードを持たず、明細データなど純粋なデータとなるテーブルです。トランザクションテーブルとも呼びます。時系列要素を含むデータを取り扱うことが多いです。
- ワークテーブル
- 一時的な集計用に用いられるテーブルです。集計過程で発生するデータなので保管の必要はありません。
テーブルのネーミングの際に＊＊マスタとか＊＊データ、＊＊トランという名前を付けることによって、テーブルの用途が分かりやすくなります。今回の売上DBの場合は商品に関しては独自のコード体系を持つマスタテーブル、売上伝票や売上伝票明細は時系列的な要素の強いデータテーブルということで設計しています。
また、データ項目にも型があります。文字列や整数値、日付を格納する型などがあります。具体的な型の名称についてはDB製品によってバラバラです。日付のデータについては日付型のデータとして取り扱うことも可能ですが、業務アプリケーションのDB設計では取り扱いのしやすさなどを考慮して文字列型（yyyy/mm/dd形式）として設計することもしばしばあります。
またテーブルやデータ項目の名称については、データベース上でのテーブル名や項目名（カラム名といいます）はソフトウェア業界では名称を英語訳してアルファベット小文字で書くことが多いようです。ただ、業務アプリケーションを自作するに当たっては、テーブル名やカラム名を日本語で分かりやすく書くことをお奨めします。少なくともSQL Serverではテーブル名やカラム名に日本語が対応していて不具合もめったにありません。可読性は格段に上がりますのでお試しください。
