データベース設計で迷いやすい点
前回はデータベース設計をする際に誰もがぶつかる問題である、「列名に日本語を使うか？」「どのデータ型を使うか？」ということをテーマに取りあげました。今回も引き続き、データベース設計をする際に迷いやすい点をいくつか取りあげてみようと思います。
階層構造のテーブル設計の注意点
今回は前回と同様、SQL Serverのサンプルデータベース「Northwind」を元にして、データベース設計で迷いやすい点について考えてみましょう。図1は「Northwind」をER図にリバースした中から、エンティティ「商品」「商品カテゴリ」をサブウィンドウで表示したものです。
図1：Northwindの「商品」と「商品カテゴリ」エンティティ
図1のように商品を分類するためにカテゴリコードをつけるエンティティ構造はよくあります。しかし実際の販売管理システムにおいては、このようなフラットなカテゴリ構造は不便です。なぜかというと、一般に商品カテゴリなどは表1のように階層構造で分類する必要があるからです。
-
01 ハードウェア
011 パソコン
0111 本体
0112 モニタ
012 プリンタ
0121 本体
0122 トナー
02 ソフトウェア
021 OS
0211 Windows 2000
0212 Linux
022 RDBMS
0221 Oracle
0222 SQL Server
表1：階層構造を持った商品カテゴリ
階層構造（親番号方式）
図2は表1のような階層構造に対応した商品カテゴリの典型的な例です。「親カテゴリ番号」というアトリビュートを追加し、自分の親はどれかという関連情報を持たせています。このような自分の親がわかるエンティティ構造にした場合、表1のパソコン関係の商品カテゴリは表2のようなデータとなります。
図2：階層構造を持った商品カテゴリ（親番号方式）
| カテゴリ番号 | 親カテゴリ番号 | カテゴリ名 |
|---|---|---|
| 01 | ハードウェア |
表2：階層構造を持った商品カテゴリ（親番号方式）のデータ
表2のような親番号指定方式は、よく使われる方法です。しかしパフォーマンス面で難点があるため、カテゴリ数や階層が多い場合にはお勧めできません。なぜなら、カテゴリ数が増えてしまうと検索方式が再帰型になってしまうからです。
例えば、表2において「パソコン（カテゴリ番号 011）関連の商品の売上合計を求める」必要があったとします。この場合、対象となるカテゴリは自分の祖先（親、親の親、親の親の親…）に「011 パソコン」が含まれるものになります。図2で考えると、「011 パソコン」配下のカテゴリがすべて対象になるので、「0111 本体」や「0112 モニタ」にひも付く商品の売上がすべて集計されることになります。
図2のように自分の親だけしかひも付き情報を持っていない場合は、再帰型で祖先に「011 パソコン」が存在するかどうかを探す必要があります。表2程度の階層の深さならよいのですが、階層が深い場合は検索速度が極端に遅くなってしまいます。
関連記事
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
