［データベース設計編］参照整合性制約機能を多用してはいけない

　参照整合性（Referential Integrity）とは，テーブル間のデータの整合性を保つための仕組みである。例えば，「受注テーブルの商品番号カラムには，商品テーブルの商品番号カラムに同じ値がなければならない」といった制約を維持するための仕組みである（図1）。RDBMSはこの整合性を維持するための機能として，「参照整合性制約」といった機能を持つことが多い。これは，定義された参照整合性をチェックし，整合性を逸脱するような値がテーブル内に存在しないようにする機能である。この機能を使用する場合は，テーブル定義の際に「Constraint句」を用いることが多い。

図1●参照整合性

　参照整合性制約機能は，誤ったデータがテーブルに含まれないようにするには効果的な機能である。だが，むやみに使うと問題を引き起こすことがあるので，注意が必要だ。

データ移行時にエラー

　最も問題が起こりやすいのは，データを移行する際だ。先の受注テーブルと商品テーブルのケースで見てみよう。「受注テーブルの商品番号カラムには，商品テーブルの商品番号カラムに同じ値がなければならない」といった制約があると，データを移行する際，先に受注テーブルを移行させようとすると参照整合性違反となり，RDBMSはエラーを返す。必ず，商品テーブルのデータ移行後に，受注テーブルのデータ移行を行わなければならない。

　さらに，参照整合性が設定されている状態で大量のデータを移行しようとすると，参照整合性を設定していないときに比べて処理時間が大幅に長くなる。先の例でいえば，受注テーブルのデータを挿入するたびに商品テーブルを確認する必要があるので，大幅な性能劣化を引き起こす。

　この処理性能の問題は，一時的に参照整合性制約を解除する（または，チェックを行わないモードを使用する）などの方法で回避できる。しかし，一時的とはいえ制約を解除すると，誤ったデータが混入される可能性がある。別の方法でデータのチェックを行うくらいなら，RDBMSの参照整合性制約機能を利用する意味はほとんどなくなってしまう。

　データ移行時だけでなく，通常業務処理の中でも問題になるケースがある。例えば，1週間後に発売を予定している商品を先行して仮受注するような業務処理があった場合だ。まだ発売していないので商品テーブルにはその商品番号のレコードが存在しないとしよう。仮受注のデータも受注テーブルで管理しようとしても，商品テーブルにない商品番号のデータは追加できない。このような業務処理は実行できなくなってしまう。仮受注のときのみ，一時的に参照整合性制約を解除するといった方法は良い設計とはいえない。

　参照整合性の確保は，RDBMSの機能でしか実現できない訳ではない。データ入力時にアプリケーションで確実にチェックすることで，誤ったデータの混入を防ぐことができる。論理モデル上参照整合性が定義されたとしても，そのすべてをRDBMSの参照整合性制約機能で実装しようと考えるのは間違いである。アプリケーションで実装するのが難しいケースに限って利用するなど，むやみに使わないようにすべきである。