制約の使い方、Unicode使用可否、明細テーブルの設計

はじめに

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

RDBMSの制約とは

   前回、説明したデータベースの標準規格SQL99では「制約」という機能が定義されており、OracleやSQL Serverなどの通常のRDBMSにも実装されています。

   制約とはデータベースに格納されるデータに制約条件を付けるものです。例えば、NOT NULL制約が設定されている項目はNULLを許容しませんので、必ず値がセットされなければなりません。制約を設定した列に、値を指定せずにデータを格納しようとしても、RDBMSが制約違反ということでエラーを返します。

   RDBMSで実装している制約には、表1のようなものがあります。


   これらの制約は、あるからといって必ず使うとは限りません。筆者は仕事柄、様々な会社のデータベースに触れる機会が多いのですが、主キー制約とNOT NULL制約くらいしか使っていないというシステムも非常に多くあります。

どの制約を使うか

   データベース設計を行う場合は、どの制約を使うかという方針を決めなければなりません。ただし、データ整合性チェックをすべて制約に頼ってはいけません。一般にRDBMSの制約を設定したとしても、あくまでも1次チェックはフロントアプリケーション側で行います。

   図1は、典型的なWebアプリケーションの3層構造を示したものです。


   このようなアプリケーションにおいては、下記にあげる3重チェックが行われることになります。

   第1チェックは、クライアント上のJavaスクリプトなどによるチェックです。これは主にユーザビリティを高めるためのチェックであり、ユーザが誤った値を入力したときに即座に過ちを指摘してくれます。

   第2チェックは、サーバサイドのチェックです。このチェックが一切の不整合値入力を許さない砦となります。

   そして、念のためのチェック（第3チェック）がRDBMSの制約です。制約を設定しておけば、上記のような想定アプリケーションを通さずに直接データを入力するようなことがあっても、整合性を確保することができます。また第2のチェックに漏れがあったとしても、制約が張ってあれば最低限の整合性が保たれます。

   この「念のため」というだけの理由で制約を設定すべきかどうか、これが設計者にとって悩ましいところです。制約を設定するとテストデータ作成時に面倒になりますし、制約によってはパフォーマンス低下というデメリットもあるからです。

   筆者の基本方針は、「積極的に制約を設定してデータの整合性を確保する」というものです。ただし、参照整合性制約だけはパフォーマンスが低下するので設定しません。以前は、依存型リレーションのみ設定したのですが、それも中途半端なので最近は一切使わない方針にしました。