教科書的ではなく、現場にあったデータベース設計のコツ

データベース設計で迷いやすい点

   前回はデータベース設計をする際に誰もがぶつかる問題である、「列名に日本語を使うか？」「どのデータ型を使うか？」ということをテーマに取りあげました。今回も引き続き、データベース設計をする際に迷いやすい点をいくつか取りあげてみようと思います。

階層構造のテーブル設計の注意点

   今回は前回と同様、SQL Serverのサンプルデータベース「Northwind」を元にして、データベース設計で迷いやすい点について考えてみましょう。図1は「Northwind」をER図にリバースした中から、エンティティ「商品」「商品カテゴリ」をサブウィンドウで表示したものです。


   図1のように商品を分類するためにカテゴリコードをつけるエンティティ構造はよくあります。しかし実際の販売管理システムにおいては、このようなフラットなカテゴリ構造は不便です。なぜかというと、一般に商品カテゴリなどは表1のように階層構造で分類する必要があるからです。

01 ハードウェア
         011 パソコン
               0111 本体
               0112 モニタ
         012 プリンタ
               0121 本体
               0122 トナー

02 ソフトウェア
         021 OS
               0211 Windows 2000
               0212 Linux
         022 RDBMS
               0221 Oracle
               0222 SQL Server

階層構造（親番号方式）

   図2は表1のような階層構造に対応した商品カテゴリの典型的な例です。「親カテゴリ番号」というアトリビュートを追加し、自分の親はどれかという関連情報を持たせています。このような自分の親がわかるエンティティ構造にした場合、表1のパソコン関係の商品カテゴリは表2のようなデータとなります。

カテゴリ番号	親カテゴリ番号	カテゴリ名
01		ハードウェア
011	01	パソコン
0111	011	本体
0112	011	モニタ

   表2のような親番号指定方式は、よく使われる方法です。しかしパフォーマンス面で難点があるため、カテゴリ数や階層が多い場合にはお勧めできません。なぜなら、カテゴリ数が増えてしまうと検索方式が再帰型になってしまうからです。

   例えば、表2において「パソコン（カテゴリ番号 011）関連の商品の売上合計を求める」必要があったとします。この場合、対象となるカテゴリは自分の祖先（親、親の親、親の親の親…）に「011 パソコン」が含まれるものになります。図2で考えると、「011 パソコン」配下のカテゴリがすべて対象になるので、「0111 本体」や「0112 モニタ」にひも付く商品の売上がすべて集計されることになります。

   図2のように自分の親だけしかひも付き情報を持っていない場合は、再帰型で祖先に「011 パソコン」が存在するかどうかを探す必要があります。表2程度の階層の深さならよいのですが、階層が深い場合は検索速度が極端に遅くなってしまいます。